MDR Art. 88 caught us off guard — how I set up trend detection so it won't happen again

I work in a 200-person Class II medical device company where our day-to-day incident log is mostly low-severity customer complaints and a handful of isolated device issues. Individually, none of those events would meet the threshold for vigilance. Then a competent authority review flagged an unreported "trend" under MDR Art. 88 — not because of one dramatic failure, but because a cluster of small events, reviewed in aggregate, showed a clear increase.

We survived the inquiry, but it was a blunt lesson: if your organization treats incidents only one-by-one, MDR Art. 88 can quietly make you non-compliant. This is what I changed, and how I automated the plumbing so the QA team doesn't have to watch a spreadsheet forever.

Why trends matter differently from single events

• Single event = root-cause focus, CAPA for that device/batch/supplier.
• Trend = system-level signal. A collection of non-serious reports can indicate emerging risk, design drift, or a supplier quality collapse.
• MDR Art. 88 expects manufacturers to report trends to the competent authority when they indicate a statistically significant increase in incidents that could affect public health.

That means your QMS needs to spot aggregate signals and link them into risk assessment and reporting — not just close complaints one-by-one.

What we did: three practical changes

1. Centralize incident data

   • We moved every complaint, service report, and field action record into a single table (our PMS incident feed).
   • Standardized taxonomy: event_type, symptom_code, device_id, lot, root_cause (when known), severity, date_received.
   • Why: you can't detect trends from inconsistent fields.

2. Add basic automated signal detection

   • We adopted a simple rolling-window detection script that runs nightly:
     • normalize event_type to reduce noise (map free text to codes)
     • compute rolling counts by event_type/device_family over configurable windows (e.g., 3 months vs 12 months rolling average)
     • flag event_type/device_family pairs where recent activity materially exceeds baseline
   • Example pseudo-query:

    SELECT event_type, device_family,
      SUM(CASE WHEN date >= date_sub(current_date, interval '3 months') THEN 1 ELSE 0 END) AS recent_count,
      AVG(monthly_count) OVER (PARTITION BY event_type, device_family) AS baseline_avg
    FROM incidents
    GROUP BY event_type, device_family;
   

• We avoid hard-coded thresholds — the tool suggests a ratio and adds a human review step before anything gets escalated.

1. Make it part of the controlled workflow
   • Any automated flag creates a review item in our CAPA/Change system (traceable, assigned, due dates).
   • The reviewer must:
     • reclassify severity if warranted,
     • run a root-cause scoping question set,
     • decide: monitoring only, initiate CAPA, or notify competent authority per PMS plan.
   • All decisions are audited (who reviewed, what evidence, what risk reassessment was done).

Practical detection methods that worked for us

• Rolling windows and relative increases (recent window vs historical baseline) — robust against seasonality if you pick appropriate windows.
• Control charts or CUSUM for repeated failure modes where the baseline is stable.
• Cluster detection: group by device_family + symptom_code rather than individual product ID to catch systemic issues early.
• Lightweight natural-language mapping for free-text complaints — use a maintainable mapping table rather than a black-box model.

Automation and regulatory hygiene

• Use your QMS/API/webhooks to pull incident data nightly. If your QMS doesn't expose APIs, build an ETL from exports but keep the process auditable.
• Keep detection logic under change control. Any tweak to the rule (window size, mapping) must be reviewed and recorded.
• Make outputs reviewable: automated flags should include the underlying data (case IDs, timestamps) so a reviewer can validate the signal without re-querying different systems.
• Integrate with risk management (ISO 14971): every trend review should document whether the hazard analysis or risk controls need updating.

What we learned the hard way

• Noise is the enemy. Initially we got too many false positives because we grouped by overly broad symptom codes. Tuning taxonomy reduced review workload.
• Don't rely on single-authority thresholds. Different competent authorities may expect different levels of granularity or timelines — your PMS plan should define when to file a trend report.
• Auditability beats fancy models. A simple, explainable rule that lives in change control holds up better during audits than an opaque machine-learning model that nobody can fully justify.

Minimal checklist to implement this in 4–6 weeks

• central incident table and taxonomy
• nightly ingestion and normalization
• one simple rolling-window detection script
• auto-create review tasks in your QMS (traceable)
• documented decision tree for "monitor / CAPA / notify"
• change control and versioning for the detection rules

Closing thoughts

Trends under MDR Art. 88 are an inherently aggregate problem — they don't respect the ticket-based mindset most engineering teams use. Automating detection doesn't replace human judgment, but it makes sure the human review happens before a regulator notices a pattern you missed.

How have you instrumented trend detection for PMS in your organization? Any tips on balancing sensitivity vs. false alarms, or favorite lightweight tools/scripts to share?