EU MDR makes post-market surveillance part of the QMS

Post-market surveillance is a device-level system

The direct answer in Article 83 of the EU Medical Device Regulation is that post-market surveillance is planned, established, documented, implemented, maintained, and updated for each device. Its design is proportionate to risk class and appropriate for device type. The regulation makes that system an integral part of the manufacturer's quality management system rather than a downstream repository that begins and ends with complaint intake.

A regulatory-quality record should therefore connect device identity and configuration, intended purpose, market and lifecycle state, risk class, surveillance plan, data sources, collection periods, review, conclusions, actions, approvals, and technical-documentation updates. Product-family grouping may be appropriate in a defined context, but it should not erase which device, category, population, or evidence period a conclusion covers.

The data must support conclusions and actions

Article 83 describes active and systematic gathering, recording, and analysis of relevant quality, performance, and safety data throughout the device lifetime. The data inform benefit-risk determination, risk management, design and manufacturing information, instructions and labeling, clinical evaluation, safety summaries, corrective-action needs, usability and performance improvement, and trend reporting. A signal feed is therefore an input, not the completed surveillance process.

The system should preserve provenance, denominator and exposure context where available, coding and normalization, duplicate handling, review logic, uncertainty, trend method, threshold, medical and quality assessment, decision, action, and follow-up. Automation can route and reconcile evidence, but qualified people remain accountable for clinical significance, reportability, field action, risk acceptance, and the conclusions placed in controlled records.

The plan and reports have distinct roles

Article 84 bases surveillance on a plan that is part of the technical documentation for devices other than custom-made devices. Articles 85 and 86 then distinguish outputs: a post-market surveillance report for class I devices and a periodic safety update report for class IIa, IIb, and III devices. The PSUR includes the benefit-risk conclusions, principal post-market clinical follow-up findings, and sales and population information described in the regulation.

A platform should keep plan, execution evidence, analysis, report, review, submission or availability status, and corrective action linked but separately versioned. A generated report is not proof that the underlying plan was executed, the data were complete, or an authority or notified body accepted every conclusion. Class, implantable status, custom-made status, timing, route, and applicable transitional provisions need explicit review.

A current source does not decide a product's obligations

EUR-Lex identifies the act as in force and provides a current consolidated text while also warning that consolidated text is a documentation tool and that authentic versions are the Official Journal texts. Regulatory teams need the applicable text, amendment history, effective dates, device facts, market status, and any relevant guidance or authority interpretation before turning article-level requirements into a workflow.

Buyers should test whether software maintains that lineage and can reconstruct the evidence behind a surveillance conclusion without overstating compliance. This analysis does not classify a device, determine reporting or PSUR obligations, interpret a serious incident, establish conformity, or replace the regulation, authorized standards text, notified-body direction, competent-authority guidance, clinical judgment, quality judgment, or legal advice.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

RegQuality Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.