Competitor monitoring often ends up as a quarterly exercise that satisfies the auditor and changes nothing. Recall notices are pulled, pasted into a table and filed. The data rarely reaches a risk analysis, a design review or a submission.
I understand why. Your own devices, complaint backlog and PSUR deadlines come first. But reports about similar devices are some of the cheapest design and risk information available, and the regulation already expects you to look at them.
What the regulation asks for
EU MDR Articles 83 to 86 set out the post-market surveillance system, its plan and its reports. Annex III lists publicly available information about similar devices among the inputs to that plan.
A quarterly table of competitor recalls is the minimal reading. The same data can do more:
Risk management. If a competitor’s knee implant shows a cluster of aseptic loosening events and your implant shares a similar fixation mechanism, that is a design risk input to evaluate now.
Regulatory positioning. When a notified body asks for evidence of “state of the art” awareness, current comparative surveillance data is stronger than a literature review from 18 months ago.
Design feedback. A pattern of connector failures in a competitor’s infusion pump can shape your own verification testing before the same signal appears in your field data.
Where competitor monitoring breaks down
Collection is manual and infrequent. Someone searches MAUDE by product code once a quarter, downloads a spreadsheet and skims it. With nearly 2.9 million device reports reaching FDA in 2025, a quarterly skim misses emerging signals.
Nothing is classified. Reports land in a folder without a failure mode, a severity trend or a note on relevance to your own portfolio.
The data lives apart. It sits in a separate system from your own surveillance, so it never reaches risk management files, design reviews or PSUR trend analyses.
Nobody owns the analysis. Collection gets assigned. The question “what does this mean for us?” does not, and nothing triggers escalation to engineering or clinical affairs.
A framework that feeds the quality system
Choose the watch list narrowly. Monitor devices that share your predicate, your indication or your core technology. A balloon catheter maker watches balloon catheters with the same coating technology, not every catheter on the market.
Set frequency by risk. Class III devices and anything sharing your mechanism of action deserve continuous monitoring. Class II devices in adjacent product codes can be reviewed monthly.
Classify what you find. Tag every competitor event by failure mode, severity and relevance to your risk management file. This is the slow step, because it takes time and domain expertise.
Write escalation triggers into the SOP. For example, more than a set number of serious injury events in 90 days, for a failure mode present in your risk analysis, triggers a risk management review.
Put it in the documents. Competitor trends belong in PSURs, risk management reports and clinical evaluation updates. Data that never appears there was collected for its own sake.
Three patterns to watch
Recall clustering. Two or more recalls within 12 months for related failure modes often point to a systemic design or manufacturing issue. Regulators may then ask whether the whole device class is affected.
New injury types. Patient outcomes that don’t appear in your own risk analysis suggest a gap in hazard identification. This matters most for combination products and software-driven devices.
Signals from other regions. A safety signal can appear in EU vigilance data before it shows up in MAUDE. Watching only FDA data means seeing one regulator’s view.
How DeviceWatch handles competitor monitoring
You add competitor product codes beside your own. DeviceWatch pulls new MAUDE reports for those codes on openFDA’s weekly refresh. Each report is summarized and classified by failure mode and severity through the same pipeline as your own devices, then reviewed by a person.
Trend analysis runs across both sets, so comparisons sit in one view. When a competitor signal crosses a threshold you set, you get an alert. The data flows into PSUR and risk management report templates with an audit trail.
More at devicewatch.app.