PMS Data Sources and Thresholds in Practice

The gap between listing data sources and using them

Every PMS plan lists data sources. The question auditors and Notified Bodies are increasingly asking is: do you actually use them, and do you know what you're looking for? A plan that names eight data sources but has no defined threshold for any of them has not solved the signal detection problem — it has just created a longer list of things to review without a decision framework attached.

The practical challenge is two-sided. You need to know where your signal might come from, and you need to know in advance what would constitute a signal worth acting on. Both halves need to be in the plan. This resource focuses on both: what data sources are genuinely useful, and how to set thresholds that actually function.

Data sources: what works in practice

Complaint data from your own system. This is always the primary source and the one with the most direct regulatory consequence. Complaints that qualify as serious incidents must feed into vigilance reporting — so the first analysis layer is always: does this complaint meet the Article 2(64) definition of a serious incident? Below that threshold, complaint patterns over time are your most reliable early-warning system. Track complaint rate per unit sold, not raw complaint count — otherwise volume growth masks a genuine signal.

Post-market clinical follow-up (PMCF) data. PMCF is a PMS data source, not a separate parallel system. Data collected through registries, surveys, or literature should land in your PMS data analysis. The PMCF evaluation report is where you document what the data showed; the PMS plan is where you specify how you will collect it.

Scientific literature. Mandatory under MDR, and more useful than it sounds. The target is not just your own device — it is literature on devices with the same intended purpose, same technology, same materials, especially if those devices have had adverse event reports that yours hasn't seen yet. MDCG 2019-9 sets the methodological expectations for literature surveillance in clinical evaluation; the same rigour applies to PMS literature monitoring.

Competitor adverse event databases. In practice this means MAUDE (US FDA), MHRA Yellow Card, and national competent authority databases. These are underused by most manufacturers. If a competitor's device with similar technology has a cluster of failures at a specific use point, that's a signal worth tracking even before your own users report it. EUDAMED's PMS module, once operational, is intended to make EU adverse event data more accessible.

Feedback from sales and service networks. This is the data source most often managed outside the quality system. Field service reports, verbal feedback from customers reported by sales teams, and user training observations can all contain early signal that never makes it into the complaint log because it wasn't framed as a complaint. Building a lightweight but systematic capture mechanism for this channel is worth the effort — and auditors sometimes ask about it.

Real-world use data, where accessible. For some device types — particularly SaMD and connected devices — usage data can be collected directly. Session counts, error codes, use interruptions, and software exceptions can all provide signal. If you collect this data, your PMS plan should explain how it is reviewed and what patterns would constitute a signal.

Setting thresholds: the part most plans skip

Thresholds need to be defined in advance, not assessed in hindsight. An auditor reading your PMS plan should be able to answer: at what point would this manufacturer be required to escalate? If the answer requires interpretation, the threshold is not specific enough.

A practical approach is to think in terms of rate triggers and pattern triggers.

Rate triggers are the easier type: complaint rate per 1,000 units sold exceeds X%, or serious incident rate exceeds Y per quarter. These require you to set X and Y based on your risk management file — what rate of adverse events did your risk analysis consider acceptable? Your PMS threshold should be set below your risk file acceptance criteria, so that PMS triggers corrective review before you are in actual non-conformance.

Pattern triggers are harder to define but often more useful. Two or three complaints in the same use scenario, involving the same user step or device component, may each be below your rate threshold but together constitute a signal. Pattern triggers require you to specify what combination of events — by type, location, user group, or device batch — would require escalation regardless of rate.

One thing that trips teams up: thresholds for reporting within your PMS system are separate from thresholds for external vigilance reporting. The internal PMS threshold is lower — it triggers your own investigation. The vigilance threshold is set by MDR Article 87 and the implementing regulation (2017/745). You cross one before the other, and your plan needs to be clear about the distinction.

Documenting thresholds so they survive an audit

Thresholds buried in narrative paragraphs are hard to verify. The clearest format is a table in your PMS plan: data source, signal definition, threshold value or pattern descriptor, escalation trigger, responsible function, and escalation path. If an auditor can read that table and understand in two minutes what would make you act and who would act first, the threshold section is doing its job.

Review thresholds annually, or whenever you have a significant product or market change. A threshold set for a mature product in a controlled clinical environment may be too permissive for a device now being used in general practice by a broader user population. The threshold review is part of the plan review — they should happen together.

Where to go from here

The vigilance reporting resource in this category covers what happens once a threshold is crossed and a serious incident is identified. The PMS plan structure resource covers how to document the complete signal-to-action framework. If you are setting up PMS for a SaMD product, the SaMD post-market surveillance resource addresses the specific data sources and thresholds relevant to software-based devices.