Every design change triggers a risk reassessment. The real question is not whether to reassess, it is how deep the reassessment has to go. Small changes get a documented review against the existing hazard list. Changes that touch the clinical function, the user interface, the materials, the software architecture, or the risk controls themselves need a full ISO 14971 pass. And under MDR Article 120 as amended by Regulation (EU) 2023/607, significant changes to legacy devices close the transitional path entirely.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • ISO 14971:2019+A11:2021 treats risk management as a lifecycle activity. The risk file is never finished; it is updated on every change that could affect a hazard, a probability, a severity, or a risk control.
  • MDR Annex I Section 3 requires manufacturers to establish, implement, document and maintain a risk management system, including the updating of risk management documentation in light of production and post-production information.
  • Article 120 governs the transitional regime for legacy devices. Devices benefitting from the extended transitional provisions under (EU) 2023/607 must not undergo significant changes in design and intended purpose, or the transitional privilege falls away.
  • MDCG 2020-3 is the authoritative interpretation of "significant change" under Article 120, with flowcharts covering design, intended purpose, and software changes.
  • Triage matters. A typo fix in the IFU is not the same as a materials change on a patient-contacting component. The change control procedure has to tell these apart with written criteria, not with case-by-case gut feel.

Why this matters (Hook)

A Class IIa software-controlled infusion pump ships with an NB-approved technical file. Six months into production, the development team improves the pump's pressure monitoring algorithm to reduce false alarms. The change is, in the engineers' view, "just a tuning parameter". The QA team logs it in the change control system. Nobody opens the ISO 14971 file.

Two things can go wrong here. The first is technical: a parameter change that reduces nuisance alarms might also reduce sensitivity to a real occlusion, which is a safety-relevant shift in probability and severity. The second is regulatory: depending on how the change is framed, it can be a significant change to the design under Annex II, which means a notified body review, or worse, if the device is on the Article 120 transitional path, loss of the transitional privilege entirely.

Tibor has audited more than one startup where the change control system was scrupulous about logging what was changed and completely silent about whether the risk file had been reviewed. The two workflows ran in parallel. In both cases the finding was the same: a mandatory update of the risk management file that had not happened, and a conversation with the NB that the founder had not been expecting.

Felix's coaching experience is that founders underestimate how often design changes happen. In the first two years post-launch, a typical Class IIa device goes through dozens of them. Bug fixes. Label updates. Supplier swaps. Algorithm tweaks. Each one is a decision point. Each decision has to be logged and routed through the risk file with written criteria, not by whoever happens to be around.

What MDR actually says (Surface)

Three places in MDR carry the design change rules, and they have to be read together.

Annex I Section 3. Manufacturers shall establish, implement, document and maintain a risk management system. Risk management shall be understood as a continuous iterative process throughout the entire lifecycle of a device, requiring regular systematic updating. In carrying out risk management, manufacturers shall identify and analyse the known and foreseeable hazards associated with each device, estimate and evaluate the risks, eliminate or control the risks, and evaluate the impact of information from the production phase and the post-market surveillance system on hazards and the frequency of occurrence of hazards, on estimates of their associated risks, as well as on the overall risk, benefit-risk ratio and risk acceptability.

Annex II. The technical documentation, including the risk management documentation required by Section 5 of Annex II, must be kept up to date. Changes to the design, manufacture, or performance of the device that affect the technical documentation must be reflected in the file.

Annex IX. For devices under full QMS assessment, the manufacturer must inform the notified body of any substantial change to the approved QMS or the product range covered, and of any plan for substantial changes to the device or to its intended purpose. The notified body assesses the changes and decides whether the existing certificate remains valid or a supplementary certificate is required.

Article 120(3) as amended by Regulation (EU) 2023/607. Devices lawfully placed on the market under the former Directives may continue to be placed on the market under the extended transitional provisions, provided among other conditions that there are no significant changes in the design and intended purpose. MDCG 2020-3 provides the significant-change flowcharts used in practice.

MDCG 2020-3. The authoritative guidance on what constitutes a significant change in design or intended purpose for Article 120 purposes. It contains decision flowcharts for software, intended purpose, design, and materials. A "yes" on any flowchart exit means the device can no longer ride the transitional provisions and must move directly to an MDR certificate.

EN ISO 14971:2019+A11:2021. The state-of-the-art standard for risk management. Section 10 covers production and post-production activities, including the requirement to review and update the risk file when production or post-production information becomes available, or when design changes occur.

Plain language: MDR says the risk file is a living document, Annex II says changes flow into the technical file, Annex IX says significant changes notify the NB, Article 120 says certain changes end the transitional path entirely, and MDCG 2020-3 is the decision tree for that last question. Every design change has to walk through those five gates.

A worked example (Test)

A startup sells a Class IIb wearable cardiac monitor, CE-marked under MDR, in production for eighteen months. Over a six-week sprint, the team queues up four changes.

Change A: typo correction in the IFU. A single sentence fixed. No new warnings, no new instructions, no change to the use specification. Risk file review is a documented walkthrough confirming no hazards, probabilities, or severities move. The entry in the risk file is a short note dated and signed by the risk management owner. No NB notification.

Change B: supplier change for a passive enclosure screw. The new supplier delivers an equivalent screw under the same mechanical specification. Incoming inspection criteria unchanged. Risk file review is a documented confirmation that no new biocompatibility, mechanical, or usability hazards arise, with a cross-reference to the supplier qualification record. No NB notification under Annex IX because no substantial change.

Change C: firmware update to the beat-detection algorithm, claimed by the developer as a 3% improvement in sensitivity. This is not a minor change. The algorithm sits inside a risk control for a clinical hazard ("missed beat leads to delayed intervention"). Probability estimates and severity assessments depend on algorithm performance. Under ISO 14971 Section 10, this requires a full hazard analysis pass: re-open the hazard table, re-verify every row that touches beat detection, re-verify the verification and validation test cases, run a regression. Under MDCG 2020-3 the team runs the software change flowchart. Under Annex IX, a substantial change to performance characteristics or safety triggers NB notification. The team notifies. The NB decides whether a certificate supplement is needed.

Change D: new claim in the IFU that the device is intended for paediatric use 12-17 years old, previously adult-only. Change to intended purpose. Full stop. Risk file re-opened at the use specification level. New hazard analysis sessions convened with a paediatric clinical expert. New clinical evaluation evidence. NB notification under Annex IX and, if the device were still on a legacy certificate, loss of the Article 120 transitional path per MDCG 2020-3.

Four changes, four different depths of reassessment. The common thread: all four are routed through the change control procedure, all four generate a dated entry in the risk management file, and all four end in a written decision about whether the NB needs to be told.

In Tibor's audit experience the distinction between A and C is where startups fall down most often. The temptation is to treat "it is just a tuning parameter" like a typo, because the engineering effort looks small. The risk management effort is what decides, not the engineering effort.

The Subtract to Ship playbook (Ship)

The Subtract to Ship move on design changes is to build a triage that forces the right depth of reassessment without drowning in bureaucracy.

  1. One change control procedure, one entry point. Every change, however trivial, enters the same pipeline. No side doors. No informal fixes that skip the log.
  2. Triage question tree, written once, used every time. Does the change touch the clinical function? The user interface? The materials in contact with the patient? The software architecture? A risk control? The intended purpose? The claims? Each "yes" pushes the change into a deeper reassessment class.
  3. Four reassessment classes. Class 1: documented walkthrough against existing hazard list, no new analysis. Class 2: targeted hazard analysis on affected rows, verification rerun. Class 3: full ISO 14971 pass, new multidisciplinary session, full V&V. Class 4: full pass plus change to intended purpose, new clinical evaluation, NB notification mandatory.
  4. Every change produces a dated entry in the risk management file. Even Class 1. The audit trail is the evidence. An undocumented decision that a change was "nothing" is indistinguishable from a decision that was never made.
  5. Route Class 3 and Class 4 through MDCG 2020-3 flowcharts before any commitment. For legacy devices under Article 120, the flowchart output determines whether the transitional path survives. For MDR-certified devices, the flowchart informs the Annex IX notification decision.
  6. Multidisciplinary sessions on Class 3 and above. Tibor's consistent observation: the credible risk files are built by teams. For a meaningful design change, the team in the room has to include development, clinical, regulatory, and ideally someone who has used the device in the field. A lone regulatory person updating a table on a Tuesday afternoon is not a reassessment.
  7. Close the MDR ratchet on every reassessment. When residual risk moves, the "reduce as far as possible" question gets asked again, because MDR requires it regardless of whether ISO 14971 would accept the residual risk. This is the trap Tibor sees teams miss most often.
  8. Post-market surveillance feeds back into the change trigger list. If PMS data shows a probability estimate was too optimistic, that is a design change candidate, not just a file update. Tibor's bad-case pattern: PMS data collected but the risk file only updated every two to three years, so probability and severity changes go unnoticed.

Reality Check

  1. Does every design change, however trivial, go through the same change control pipeline, or are there informal side doors?
  2. Does the change control procedure have a written triage tree that decides the depth of risk reassessment, or does it rely on case-by-case judgement?
  3. Can the team point to dated risk management file entries for every change in the last twelve months?
  4. For every Class 3 or Class 4 change, is there evidence of a multidisciplinary session with development, clinical, and regulatory in the room?
  5. Has any Class 3 or Class 4 change been walked through the MDCG 2020-3 flowcharts, and was the output recorded?
  6. If the device is on the Article 120 transitional path, is the team confident no completed change has quietly pushed it over the significant-change line?
  7. When a residual risk moved during a reassessment, was the MDR "reduce as far as possible" question asked and answered explicitly?
  8. Does PMS field data trigger design change candidates, or does it sit in a parallel system that never reaches the change control pipeline?

Frequently Asked Questions

Is every design change a significant change under Article 120? No. A significant change in the Article 120 sense is defined narrowly by MDCG 2020-3 with flowcharts covering design, intended purpose, and software. Most routine changes, such as typo fixes and equivalent supplier swaps, are not significant in that sense. The flowcharts are the gate.

If the device is already CE-marked under MDR, does Article 120 matter? Not for that device. Article 120 governs the legacy transition. Once a device has an MDR certificate, the relevant change control rules are Annex II and Annex IX. The MDCG 2020-3 logic is still useful as a mental model but is not the legal gate.

How often should the risk management file be reviewed? Continuously, on every change, and at the cadence set in the risk management plan for production and post-production feedback. Tibor's rule of thumb is that a file not touched in more than twelve months in a live-production device is almost certainly stale, because probability and severity estimates move with real-world data.

Who signs off on a Class 1 walkthrough decision? At minimum the risk management owner named in the plan. For very small teams this is one person; for larger teams, the owner plus the process lead. The key is that the decision is documented, dated, and attributable, not that it is committee-approved.

Does software regression testing count as risk reassessment? Regression testing is verification evidence. Reassessment is the risk management activity that reviews whether hazards, probabilities, severities, and controls have moved. They are related but not the same. A credible Class 3 reassessment includes both: a reviewed hazard analysis and the V&V evidence that supports it.

What if the NB disagrees with our change classification? The NB's assessment wins. Manufacturers who plan Class 3 and Class 4 changes typically pre-consult the NB with the MDCG 2020-3 flowchart output and the draft reassessment before committing to the change. It is faster than being surprised at the next surveillance audit. Felix has seen founders save months of rework this way.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 120 as amended by Regulation (EU) 2023/607, Annex I Section 3, Annex II, Annex IX.
  2. MDCG 2020-3: Guidance on significant changes regarding the transitional provision under Article 120 of Regulation (EU) 2017/745.
  3. EN ISO 14971:2019+A11:2021: Medical devices, application of risk management to medical devices.
  4. EN ISO 13485:2016+A11:2021: Medical devices, quality management systems, requirements for regulatory purposes.