Closing the Loop: How PMS Outputs Feed Back Into Your Risk Management File

The feedback loop MDR actually requires

Post-market surveillance under MDR is not just a reporting obligation — it is a source of information that is supposed to change things. Specifically, it is supposed to feed back into your risk management process and, where the evidence warrants it, trigger updates to your risk management file, your technical documentation, and potentially your instructions for use or device design. That feedback loop is one of the areas Notified Bodies and competent authorities have been examining most carefully.

The MDR framework — reinforced by ISO 14971:2019 and the MDCG guidance on PMS — makes this explicit. Post-production information is not a separate chapter that gets filed and forgotten. It is input to the risk management process. Your PMS plan should describe how that input flows in, your PMSR or PSUR should document what was found and what conclusions were drawn, and your risk management file should show the effect.

What "triggers a risk file update" actually means in practice

This is where most teams run into difficulty. The PMS process generates data: complaint rates, vigilance signals, literature updates, field safety corrective actions, registry data, competitor incidents reported to regulators. The question is: what does any of this mean for your existing risk analysis?

The answer requires someone to actually look at the PMS data with the risk management file open. Not just compare complaint numbers to acceptable rates — but ask whether the post-market data is revealing hazards, harm scenarios, or harm frequencies that weren't captured in the original risk analysis. If a pattern of use errors is appearing in complaint data, and those use errors aren't reflected in the use-related risk analysis, the file needs to be updated. If post-market literature is changing the understanding of long-term effects for an implantable device, the hazard identification needs to be revisited.

A risk file update doesn't always mean the risk assessment outcome changes. Sometimes you look at new data, conclude the existing risk controls are adequate, and document that conclusion. That documentation is still an update — it is evidence that the feedback loop is active. A risk management file that has not been touched since initial certification, against a background of active PMS, is a gap.

The technical file consequence

When PMS data triggers a risk file update, the update rarely stops there. Risk controls are embedded throughout the technical documentation: in design verification records, in the IFU, in the clinical evaluation's benefit-risk determination. If a risk file update changes a risk estimate or introduces a new risk control, those downstream documents may need to change too.

This is the part that catches teams off guard. A complaint trend gets reviewed, the risk file gets a note, and then no one checks whether the IFU still adequately addresses the use errors that drove the complaint trend. A Notified Body surveillance audit will follow that thread. They will look at the PMS data, look at the risk file update, and then ask to see the IFU revision or the design change record that resulted.

The PMSR and PSUR as the bridge

The Periodic Maintenance Safety Report (PMSR) and Post-Market Surveillance Report (PSUR) are supposed to serve as the documented bridge between PMS data and risk management conclusions. The structure of these reports matters for how well they perform that function.

A PMSR or PSUR that only presents data — complaint volumes, vigilance events, serious incident rates — without drawing conclusions about what the data means for the risk-benefit profile is not meeting its purpose. The report needs to explicitly address: has the benefit-risk determination changed? Are there new or changed risks? Are the existing risk controls still adequate? If the answers are all "no change," document that conclusion and the reasoning. If any answer is "yes," document what is being done about it and when.

Building the connection into your QMS

The feedback loop between PMS and risk management is not something you can improvise during an audit. It needs to be built into the QMS as a defined process: who reviews PMS data against the risk management file, how often, what criteria trigger a formal risk management file update, and what change control process governs that update.

Many manufacturers have a CAPA process, a PMS process, and a risk management process — but the handoffs between them are informal or undocumented. The result is that PMS data may trigger a CAPA without anyone asking whether it also requires a risk file review. Or the risk file gets updated without a change control record. Both are audit findings.

The simplest structure that works: make risk management file review an explicit output of the PMS review cycle, with a documented decision (update required / not required) and a reference to the PMS data that informed it.