How PMS Outputs Connect Back to Technical Documentation and Clinical Evaluation

The feedback loop most teams set up late

One of the most consistent audit findings related to post-market surveillance under MDR is not a missing PMS plan or a late PSUR — it is the absence of a documented feedback loop between PMS outputs and the rest of the technical file. Manufacturers often run PMS activities and produce the required reports, but the reports sit in isolation. The risk management file from initial certification hasn't been touched. The CER was written three years ago and hasn't been updated since. Nothing in the PMS report connects to anything else.

MDR is explicit about this. Article 83(1) requires the PMS system to actively gather, record, and analyse data and draw conclusions that feed into risk management, clinical evaluation, and technical documentation. "Feed into" is not metaphorical — there need to be documented processes and actual outputs that show this happening.

What PMS outputs are supposed to do

Think of your PMS system as having two types of output: reporting outputs (PSUR, PMSR) and feedback outputs (updates to risk management, CER, technical documentation). Most teams are better at the first type than the second. The regulatory requirement covers both.

The PSUR and PMSR are the summary documents — they synthesise what you found and what you concluded. But the action items that follow from those conclusions are the feedback outputs. A PSUR that concludes "no new significant risks identified, benefit-risk profile unchanged" with no corresponding confirmation in the risk management file is not a complete loop.

The connection to risk management

Your risk management file (ISO 14971 in practice, Annex I Chapter I of MDR as the requirement) must reflect the current state of knowledge about your device's risks. When PMS data changes that knowledge — new complaint patterns, new literature, post-market incidents — the risk management file must be reviewed and, if warranted, updated.

The review does not have to result in a change. If your PMS data confirms that the existing risk controls are adequate and no new risks have been identified, document that conclusion in the risk management file as a PMS-triggered review with no change required. That documentation is what auditors look for. A risk management file that has not been reviewed since initial certification, combined with years of PMS reports, suggests the feedback loop isn't working.

What triggers a mandatory risk management update (not just a review):

• A new risk identified through PMS data that was not in the original risk assessment
• A change in the frequency or severity of a known risk that alters the risk acceptability determination
• Evidence that an existing risk control is less effective than assumed at the time of initial certification
• A field safety corrective action — any FSCA is by definition a signal that risk management needs attention

The connection to clinical evaluation

The clinical evaluation report (CER) must also be kept current. Article 61(11) requires the CER to be updated as part of the PMS system. The PMCF evaluation report is the primary PMS input to the CER — it provides the post-market clinical data that the CER uses to demonstrate continued benefit-risk acceptability.

A few things that teams miss here:

The PMCF evaluation report feeds the CER, but the CER is the broader document. The PMCF evaluation report covers clinical data gathered through PMCF activities. The CER also incorporates vigilance data, complaint data, literature, and the overall benefit-risk assessment — drawing on the full PSUR, not just PMCF outputs.

Update timing for the CER is not the same as for the PSUR. The PSUR has defined intervals (annual for Class IIb and III, biennial for Class IIa). The CER must be updated "when necessary" — which in practice means whenever PMS data reveals something that changes the benefit-risk picture, or when the PMCF evaluation report provides new clinical findings. Linking CER updates to PSUR cycles is a reasonable approach, but it must be documented.

Notified Bodies look for the version chain. If your CER is on version 3 and your PSUR covers three annual cycles, there should be evidence that the CER was reviewed at least at each PSUR cycle. If the version history shows the CER on v1.0 from 2022 and the PSUR is on its third annual update, someone will ask why.

The connection to technical documentation

Technical documentation is the top-level document set. When risk management or the clinical evaluation changes, the technical documentation must reflect those changes. This creates a chain: PMS data → risk management update or CER update → technical documentation update.

Not every PMS finding triggers a technical documentation change. Most cycles will conclude that no significant changes are required. But the conclusion — and the reasoning — must be documented. "PMS cycle completed, no changes required to technical documentation" is a valid outcome if it is backed up by the PSUR analysis. An undocumented assumption is not.

Device labelling and instructions for use (IFU) are part of the technical documentation and are specifically called out in the PSUR content requirements (Article 86). The PSUR must assess whether the IFU remains appropriate given current PMS data. If post-market experience shows users consistently misinterpreting a safety warning, that is a signal that the IFU needs attention — and a PSUR that notes "IFU remains appropriate" without addressing that pattern has a problem.

Building the feedback loop in practice

The most reliable way to ensure the feedback loop actually works is to build it into your PMS procedure as explicit steps, not as an aspiration. At the conclusion of each PSUR or PMS review cycle:

1. Document a formal PMS-triggered risk management review — even if no changes result.
2. Document whether the CER requires updating — and if so, trigger the update. If not, document why not.
3. Document whether any technical documentation sections require updating — including IFU, labelling, and performance specifications.
4. If any FSCAs occurred during the period, verify that the risk management file was updated at the time of the FSCA (it should have been — don't wait for the PSUR cycle to address FSCA-related risk management updates).

The output of this process is a brief closure document: "PMS cycle [date], no changes required / the following updates triggered." This document becomes part of your PMS file and gives an auditor a clear evidence trail.

When the loop is missing

Teams that don't have a documented PMS-to-technical-file feedback loop typically discover the problem during Notified Body review or competent authority audit. The finding is usually framed as a non-conformity against Article 83 (systematic failure to use PMS outputs) or against the specific PSUR content requirement in Article 86 (PSUR does not address whether technical documentation requires revision).

The fix is not complex, but retrofitting it requires going back through historical PSUR cycles and documenting — retrospectively — what the conclusions were and whether updates were triggered. That is a significant documentation effort. Building the loop prospectively, from the next cycle forward, is much easier.

Where to go from here

The PMS plan resource in this category covers how to define the feedback loop obligations within the PMS plan itself. The PSUR structure resource explains what the PSUR must conclude about technical documentation and labelling adequacy.