When Post-Market Data Requires a Technical File Update

The technical file as a living document

One of the most common misunderstandings about the technical file under EU MDR is that it is a submission document — something you build to get approval, then store. It is not. The MDR requires that technical documentation be kept up to date. Annex II does not set a specific review schedule, but the post-market surveillance requirements in Annex III create a continuous feedback loop that is supposed to flow back into the technical file.

In practice, this means that every time your post-market surveillance system generates a meaningful output — a periodic safety update report (PSUR), a PMCF evaluation report, a serious incident analysis, or a trend report — someone needs to ask: does this change what the technical file says? If the answer is yes, the technical file must be updated. If the answer is unclear, the review itself should be documented.

What can trigger an update

New clinical data that affects the benefit-risk balance The PMCF evaluation report is the main vehicle here. If your PMCF study collected data that strengthens or changes the understanding of device performance — or if a PMCF study reveals a safety signal that was not previously identified — the clinical evaluation report needs to be updated, and the benefit-risk assessment in the technical file follows.

Post-market clinical follow-up data that contradicts the pre-market clinical evaluation is a particularly sensitive situation. A Notified Body at a surveillance audit will look for whether you identified the discrepancy and how you addressed it. Leaving it unresolved in the technical file — or not mentioning it at all — is a finding.

Vigilance and serious incident data A single serious incident does not necessarily trigger a technical file update by itself. But a pattern — recurring incidents of the same type, or incidents that suggest the risk management file underestimated a hazard — does. The PSUR, which must be prepared for Class IIa, IIb, and III devices, consolidates this data and requires an explicit assessment of whether the benefit-risk balance is still acceptable. If the PSUR concludes it is, document the basis for that conclusion. If the PSUR identifies a need to revise the risk management file, the benefit-risk analysis in the technical file needs to be updated in step.

Complaints and non-conformity data suggesting a systematic issue Field complaints are not automatically a technical file trigger, but when the complaint data shows something systematic — a failure mode occurring more often than the risk management file anticipated, or a use error pattern that the usability file did not capture — the risk management file needs to be reviewed and, if updated, the technical file follows.

Design changes and manufacturing changes Any change that affects the device description, the manufacturing process, the materials, or the software version may require a technical file update. How significant the update needs to be depends on the nature of the change. Minor changes may require only a targeted update of the affected section and a note in the change control record. Changes that affect the GSPR demonstration — particularly those involving new materials, new software functionality, or changes to safety-critical components — typically require a broader review and update of the GSPR matrix, the relevant test reports, and the benefit-risk assessment.

New or revised harmonised standards If a harmonised standard you used to demonstrate GSPR compliance is revised, you need to assess whether your current demonstration still holds. If the new version of the standard introduces requirements that your device does not yet meet, that is a gap that needs to be closed — and the technical file needs to reflect the updated standard reference and the updated demonstration.

How to decide whether an update is needed

The practical test is: if a Notified Body auditor read the post-market data alongside the current technical file, would they find anything inconsistent or unexplained? If new data introduces a finding not mentioned in the clinical evaluation, or a risk not addressed in the risk management file, or a complaint pattern not captured in the hazard analysis, the answer is yes.

The PSUR is the right tool to make this assessment formal and documented. Each PSUR should include an explicit conclusion on whether the technical file requires updating as a result of the post-market data reviewed. If the conclusion is that no update is needed, document the reasoning. If an update is needed, initiate it through change control and reference the PSUR as the trigger.

What the update itself has to cover

When a post-market data trigger requires a technical file update, the update needs to do more than add a note. The affected documents need to be revised in controlled versions:

• The clinical evaluation report or summary should reflect the new data and its implications for the benefit-risk assessment.
• The risk management file should be updated if new hazards are identified or if risk estimates change.
• The GSPR matrix should reference the current versions of all updated documents.
• The benefit-risk analysis section of the technical file should reflect the current residual risk picture.

Version control matters here. The updated technical file documents should carry new revision numbers, and the revision history should record what changed and why — with a reference to the post-market data that triggered the review. This is what an auditor is looking for: a documented chain from the post-market finding to the technical file response.

A common failure mode to avoid

Teams often update the risk management file after a post-market event but do not update the clinical evaluation summary or the GSPR benefit-risk entry to match. The result is a technical file where the risk management file says one thing about residual risk and the clinical evaluation says something subtly different. This inconsistency becomes visible in an audit. Keeping these documents in step — as a formal change control output, not just as good intention — is what prevents it.