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

#qms #medtech #compliance

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

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.
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.

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?

DEV Community