Production and post-production risk management under MDR is the part of the lifecycle where most risk management files quietly die. EN ISO 14971:2019+A11:2021 clause 10 and MDR Articles 83 to 86 require a continuous feedback loop between post-market surveillance and the risk management file. The good version runs continuously. The bad version updates every two or three years, by which time reality has moved and the file no longer reflects the device.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • EN ISO 14971:2019+A11:2021 clause 10 requires the manufacturer to establish, document, and maintain a system to actively collect and review information from production and post-production phases.
  • MDR Articles 83 to 86 require a post-market surveillance system planned, proportionate to risk class, and integral to the quality management system.
  • The feedback loop runs in both directions: PMS data triages into the risk management file, and risk management output (updated probabilities, severities, new hazards) flows back into the PMS plan and benefit-risk analysis.
  • The good case: risk file updated continuously from triaged PMS feedback, by risk category, on a defined cadence.
  • The bad case: PMS data collected but the risk management file stays frozen for years while the real device ages in the field.
  • Auditors detect the bad case in five minutes by looking at the revision history of the risk management file versus the PMS reporting dates.

Why the lifecycle loop is where risk files die

Tibor has audited enough risk management files to recognise the signature of a file that has stopped being maintained. The version number is 1.0 from three years ago. The last change was a typo fix six months after launch. The hazard analysis still uses the probability estimates the team made at the design stage, before a single device left the factory. The benefit-risk analysis still references the pre-market clinical data. Meanwhile the PMS reports in the same submission describe eight complaints, two trends in a specific failure mode, and a revised understanding of how the device is used in the field.

That gap is where notified body findings land. The file and the field data no longer describe the same device. Either the PMS data was ignored, or the team never closed the loop between PMS and risk management in the first place.

Felix coached a startup that shipped their Class IIa device, set up a complaint handling system, and believed they were compliant because complaints were logged. They were not compliant. Logging complaints is not feedback. The complaints have to be triaged against hazard categories, analysed for trend, weighed against the risk estimates in the file, and used to update probabilities, severities, and sometimes the benefit-risk conclusion. None of that was happening. The team was running a ticketing system and calling it post-production risk management.

The lifecycle loop is the engineering discipline that keeps the risk management file alive as the device moves from prototype through production into field use. When the loop works, the file is trustworthy. When the loop fails, the file becomes a historical artefact and the audit finds out.

What EN ISO 14971 and MDR actually require

EN ISO 14971:2019+A11:2021 clause 10 is titled Production and Post-Production Activities. It requires the manufacturer to establish, document, and maintain a system to actively collect and review information from production and post-production phases, for the medical device or similar devices. The information to be collected includes information generated during production, information generated by the user, information generated by the supply chain, information about publicly available information, and information about the state of the art.

Clause 10.3 then requires that the collected information be reviewed for possible relevance to safety, particularly whether previously unrecognised hazards or hazardous situations are present, whether an estimated risk is no longer acceptable, whether the overall residual risk is no longer acceptable, and whether the state of the art has changed. If any of these are true, the risk management file must be updated, and appropriate actions must be taken for devices already placed on the market.

MDR Articles 83 to 86 complement clause 10 from the regulatory side. Article 83 requires a post-market surveillance system planned, established, documented, implemented, maintained, and updated by the manufacturer as an integral part of the quality management system. Article 83(3) is explicit that PMS shall, in particular, be used to update the benefit-risk determination and improve the risk management. Article 84 requires a PMS plan referenced in Annex III. Article 85 requires a PMS report for Class I devices. Article 86 requires a periodic safety update report (PSUR) for Class IIa, IIb, and III devices.

Annex III then specifies the content of the PMS plan, including the methods and protocols to assess collected data, and the methods and tools to investigate complaints and analyse market-related experience. Annex III requires that the PMS plan be part of the technical documentation, which means auditors read it side by side with the risk management file.

The legal position is therefore unambiguous. The PMS system is not a separate process. It is a formal feedback channel into risk management. If the two systems do not talk to each other, both are out of compliance.

The good case and the bad case

Tibor has seen both cases often enough to describe them precisely.

The good case. The team defines risk categories at the start of the risk management process. Usability hazards, mechanical hazards, electrical hazards, software hazards, biological hazards, and so on. The PMS plan mirrors those categories. Every complaint, service report, literature finding, and vigilance signal is triaged on arrival into a risk category. A defined cadence (typically monthly for high-volume devices, quarterly for lower volume) reviews the triaged data against the risk management file. Probabilities get updated when trend data supports a change. Severities get updated when a complaint reveals an outcome worse than the original estimate. New hazards get added when a PMS finding reveals a situation the original hazard analysis missed. The risk management file shows a revision history with small, frequent updates tied to specific PMS inputs. The PSUR under Article 86 references the updates explicitly. The benefit-risk analysis gets revisited when a material change emerges.

The bad case. PMS data is collected but stored in a complaint ticketing system. Nobody triages it into risk categories. The risk management file sits untouched for two or three years because nobody scheduled a review. When the notified body asks for a PSUR, the team pulls a complaint count from the ticketing system, writes a summary that says no new hazards were identified, and files it. The risk management file still shows the 2022 version. The hazard analysis still uses the pre-market probability estimates. The benefit-risk analysis still references the launch-day clinical data. The field has moved. The file has not. The auditor opens the revision history, opens the complaint log, opens the PSUR, and the gap becomes visible in five minutes.

The difference between the two cases is not capability or headcount. It is discipline. The good case runs a defined cadence that forces the loop to close. The bad case assumes the loop will happen on its own.

A worked example: software device on a quarterly cadence

Consider a Class IIa software-only device with 4,000 users in the EU, about 30 complaints per quarter, and a PMS plan that commits to a quarterly risk review.

At the end of quarter three, the PMS coordinator collects the complaints, the support tickets tagged as potentially safety relevant, the software defect log, and any literature or regulator communications. She triages each item into one of seven risk categories defined in the risk management file. Five items land in "misinterpretation of on-screen result", four in "system unavailability during critical workflow", three in "workflow integration with hospital IT", and the rest across other categories.

The risk manager reviews the triaged data against the hazard analysis. The five items in "misinterpretation of on-screen result" show a trend: all five relate to a specific edge case in how the device displays borderline values. The original probability estimate for this hazard was "occasional". The post-production data now supports "probable". The risk estimate is recalculated. The controls are reviewed. A change control is opened to revise the on-screen display and update the user-facing documentation. The risk management file version increments. The PMS plan is updated to watch specifically for this failure mode over the next two quarters. The benefit-risk analysis is revisited and the conclusion is re-signed.

All of this happens inside a two-day quarterly review. The PSUR for the next reporting cycle describes the finding, the action, and the updated risk position. The auditor, when he arrives, can walk the trail forward from the PMS triage to the risk file update to the change control to the field action. Nothing is missing.

That is what clause 10 and Articles 83 to 86 look like when they work.

The Subtract to Ship playbook for production and post-production risk

Align risk categories with PMS categories. If the risk management file uses one taxonomy and the PMS plan uses another, the triage step will break. Decide on one taxonomy at the start and enforce it across both documents.

Define a cadence proportionate to volume and risk class. Monthly for high-volume Class IIb and III. Quarterly for typical Class IIa startup volumes. Semi-annual is usually too slow unless volume is very low. Write the cadence into the PMS plan so it is auditable.

Make triage mandatory at complaint intake. Every complaint gets a risk category assigned at the point of logging, not at a quarterly sweep. If the category is ambiguous, escalate for classification. Waiting three months to triage a complaint defeats the feedback loop.

Update the risk management file in small, traceable increments. A risk management file with a clean revision history showing six small updates over eighteen months is more trustworthy than one showing a single massive rewrite every two years. Auditors read revision history first.

Link every risk management file update to its PMS input. The update log should say which complaint or trend or literature item triggered the change. This is the audit trail that proves the loop exists.

Feed updates back into the benefit-risk analysis. If a probability or severity changes materially, the benefit-risk analysis has to be revisited. Most teams forget this step. The notified body does not.

Run a lifecycle review before every PSUR. MDR Article 86 requires the PSUR to summarise the main findings of the PMS and the rationale for any preventive or corrective actions. If the risk management file has not been updated since the last PSUR, the current PSUR will either be dishonest or will reveal that the loop has not been running.

Reality Check

  1. Does your risk management file have a revision history showing regular small updates, or a gap of more than a year since the last change?
  2. Are your PMS categories and your risk management categories using the same taxonomy?
  3. Is complaint triage into risk categories happening at intake, or only at a scheduled sweep?
  4. Do you run a defined lifecycle review cadence (monthly, quarterly, semi-annual) and is it written into the PMS plan?
  5. When was the last time a PMS finding caused a material update to a probability, severity, or control in the risk management file? If the answer is "never", the loop is not working.
  6. Does your benefit-risk analysis get revisited when material risk estimates change, or does it stay frozen at launch?
  7. Could you walk an auditor from a specific complaint to a specific risk management file revision in under five minutes?
  8. Does your PSUR actually describe PMS findings and resulting actions, or does it state that no new findings were identified even though the complaint log says otherwise?

Frequently Asked Questions

Do I have to update the risk management file every time I get a complaint? No. You have to triage every complaint into a risk category and review it at your defined cadence. Updates to the file are triggered when the triaged data shows that a probability, severity, hazard, or control needs to change.

Is quarterly risk review fast enough for my Class IIa device? For most startup Class IIa volumes, quarterly is appropriate. If complaint volume is high or severity trends are emerging, move to monthly. If the device is low volume and low risk, semi-annual may be defensible, but you have to justify the cadence in the PMS plan.

Where does clause 10 feedback show up in the technical documentation? In the updated risk management file, the updated risk management report, the updated benefit-risk analysis, the PMS reports under Annex III, and the PSUR under MDR Article 86. The auditor cross-references all five.

What if the PMS data contradicts our pre-market risk estimates? Then the pre-market estimates were wrong, and the file needs to be updated to reflect the corrected position. This is not a failure. It is the loop working. Hiding the contradiction is the failure.

Does this apply to Class I devices? Yes. The legal hooks differ (Article 85 PMS report instead of Article 86 PSUR) but clause 10 of EN ISO 14971 and the general PMS obligations of Article 83 apply to all classes.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Articles 83, 84, 85, 86 (post-market surveillance). Annex III (technical documentation on post-market surveillance). Annex I General Safety and Performance Requirement 3 (risk management lifecycle).
  2. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices. Clause 10 (Production and post-production activities), including 10.1 General, 10.2 Information collection, 10.3 Information review, 10.4 Actions.
  3. EN ISO 14971:2019+A11:2021, Annex Z relating to MDR Annex I General Safety and Performance Requirements.