Near-misses vs device failures — what MAUDE actually tells a European RA

#qms #medtech #compliance

I monitor vigilance and post‑market data as a daily job. I live in Annex II/IX/XIV when I’m writing Technical Files or PMCF plans, and I also keep an eye on external sources — not least MAUDE, the FDA’s Manufacturer and User Facility Device Experience database. It’s tempting to treat MAUDE like a crystal ball: search a competitor, find a pattern, fix your product. To be fair, it’s useful — but it is not what most people expect.

Near-miss vs device failure — definitions that matter

First, a quick operational distinction I use in my files (and which feeds risk-management and CAPA):

Near‑miss: an event in which a device did not cause harm but had the potential to do so (intercepted failure, recovered error, or an instance where use‑environment or user action nearly led to an incident). In ISO 14971 terms this is a hazardous situation that did not lead to harm but had potential.
Device failure / incident: a malfunction or performance issue that resulted in harm (injury, deterioration of health, or death) or a serious deterioration as defined in MDR vigilance provisions.

Why this matters: near‑misses are leading indicators — they let you act before patient harm. Device failures are lagging indicators — they tell you something has already gone wrong and must be reported and corrected per your legal obligations.

What MAUDE shows (and what it doesn’t)

In practice this means treating MAUDE as a signal source, not definitive evidence.

What MAUDE is good for:

Surface-level pattern spotting across manufacturers — repeated device malfunctions, recurring software version mentions, or repeated user‑interface complaints often appear in narratives.
Revealing use‑environment and user behaviour issues (off‑label use, user errors, connection/compatibility problems).
Early warnings about packaging, labelling, and connector compatibility problems — those show up frequently in free text.

What MAUDE is not:

A root‑cause confirmation tool. Most entries are preliminary — they report what someone observed, not what your internal investigation later found.
A complete dataset. It’s US‑centric, has mixed submitter quality (manufacturer vs user submissions), duplicates, and variable narrative clarity.
A substitute for your vigilance obligations under MDR Articles 87–92 (vigilance and post‑market surveillance in the EU) or 21 CFR Part 803 (US MDR) — you still need to report, investigate, and take corrective action per the applicable regulations.

How I use MAUDE in a practical PMS programme

I don’t monitor MAUDE because it’s novel — I use it as part of a connected PMS feed. Steps I follow:

Regular scans: weekly keyword and competitor searches. The keywords include device model identifiers, software versions, and common failure modes we know from our risk register.
Triage: not every hit becomes an investigation. My triage criteria usually include:
- Any mention of patient harm (mandatory escalation).
- Recurrent themes across multiple reports.
- New or unexpected modes of failure not listed in the current risk analysis (ISO 14971).
Open an investigation in the QMS: even a near‑miss gets a record. Traceability is essential — link the MAUDE entry to a complaint record, risk assessment, and any CAPA. In an eQMS this should be a connected workflow: an alert creates a review task, which then maps to a CAPA if needed.
Risk reassessment and trending: if the near‑miss changes the likelihood or severity in the risk assessment, update the ISO 14971 record and the technical documentation (Annex II content, where applicable).
Feed into PSUR/PMCF: aggregate signals for periodic safety update reports and PMCF activities per MDR Articles 87–92 and your PMCF plan.

Near‑misses: why they’re often underused

From audits and NB interviews I’ve run, the same themes recur:

Near‑misses get logged as “anecdotes” in a project spreadsheet and never make it into formal complaint/CAPA workflows. This destroys traceability and prevents trend analysis.
Where software or human factors are involved, MAUDE narratives often hint at user confusion — but unless you treat those hints as design signals, you won’t prevent the incident.
Teams fear over‑reporting. To be fair, there’s regulatory noise: not every near‑miss requires a field safety corrective action. But under ISO 13485 and MDR PMS expectations, you must capture user feedback and evaluate it objectively.

Practical triggers that have worked for me

I use simple, reviewable triggers for escalating a near‑miss into CAPA-driven assessment:

Repetition: same failure mode appears X times across independent reports within Y months (define X/Y for your device risk).
Severity drift: a near‑miss points to a failure mode that could reasonably lead to serious harm if frequency increases.
New mode: a type of failure not previously evaluated in the risk analysis.
External corroboration: MAUDE plus similar signals from other registries, literature, or distributor/clinical feedback.

Set these as configurable thresholds in your eQMS so that automated CAPAs or investigation records are created. That is controlled assistance, not magic: the action is driven by the trigger, but investigators still review and authorise.

A few dos and don’ts

Do:

Treat MAUDE as a complementary data source for PMS and PSUR.
Link each external hit to your traceable QMS record (complaint, risk assessment, CAPA).
Use near‑misses to drive preventive actions — changes to IFU, training, or design modifications.

Don’t:

Use MAUDE narratives as final evidence of root cause.
Ignore near‑misses because they didn’t cause harm this time.
Let trends sit in spreadsheets outside the QMS; you need reviewability and traceability for audits.

Final note

To be blunt: vigilance that starts only after harm is visible is too late. Near‑misses are the early warning bells, and MAUDE is one of several bell towers. Integrate those bells into your QMS so that investigation, CAPA, risk reassessment, and documentation all live in the same connected workflow — that’s how you convert signals into safer devices.

How are you currently using MAUDE or other external databases in your PMS process, and what’s the most actionable near‑miss you’ve turned into preventive change?