Managing Design Changes and Keeping the Technical File Current

The documentation consequence of every design change

One of the most consistent gaps in technical files that have been through a certification cycle is the handling of design changes. The initial technical file is built carefully, submitted, reviewed, and approved. Then the device evolves — a component is substituted, software is updated, a manufacturing process is adjusted, a new market requires a labelling change. Each of these changes has a documentation consequence. If the technical file does not reflect the current device, the technical file does not comply — regardless of how solid it was at the time of initial certification.

This is not a new problem, but MDR has tightened the expectation. The regulation requires that technical documentation be kept up to date. For devices certified by a Notified Body, the rules around what changes require notification or re-examination are set out in the applicable conformity assessment procedure — but the internal obligation to maintain an accurate technical file applies regardless of whether a change needs to be notified externally.

Not all changes are equal — the significance assessment

The first question for any design change is: what impact does this change have on the device's safety, performance, or conformity? This is the significance assessment, and it needs to be documented, not just done.

The factors that determine significance:

• Does the change affect the intended purpose or indications for use?
• Does it affect any characteristic or specification that feeds into the GSPR demonstration?
• Does it introduce new materials, processing steps, or design features with uncharacterised risk?
• Does it affect software functionality, including safety-related software functions?
• Does it affect the device as it is manufactured and sold — not just the design on paper?
• Does it affect the benefit-risk picture in any way?

A change that touches any of these areas is significant and requires a formal technical file update. A change that is clearly cosmetic or administrative — a relabelling of a document reference, a correction of a typographical error in a specification — can be handled with a brief change record that documents why no substantive update was needed. The record is what matters, not just the decision.

The part that catches teams off guard: a change that looks minor in isolation can be significant in the context of the overall device. A material substitution in a non-contact component looks low-risk until you realise the component is adjacent to a sterile pathway. A software update that does not change any safety-related function looks low-risk until you check whether the update affects an IEC 62304 safety class function that was documented in the technical file. Significance assessment needs to be done by people who understand the full device, not just the part being changed.

What a technical file update for a design change has to cover

When a significance assessment concludes that a design change requires a technical file update, the update needs to cover all affected sections — not just the one where the change originated:

Device description and specification (Section 1) If the change affects the device's description, specifications, variants, or accessories, Section 1 needs to be updated. This includes version numbers and date of revision. The device description is the reference point for the rest of the technical file — if Section 1 is outdated, everything that references it is potentially inconsistent.

Design and manufacturing information (Section 2) Any change to drawings, component specifications, manufacturing processes, or supplier documentation needs to be reflected here. If the change involved a design iteration, the design history file (or equivalent) should capture the sequence of changes and the rationale for the final design.

GSPR matrix (Section 3) If the change affects any characteristic relevant to the GSPR demonstration — materials, software, performance, safety features — the relevant GSPR matrix entries need to be reviewed and updated. If the previous GSPR demonstration still holds after the change, document why. If new testing or analysis was done, reference it. If a previously applicable standard is now not applicable (or vice versa), document that change in the matrix.

Risk management file (Section 4) If the change introduces new hazards, changes risk estimates, or affects risk controls, the risk management file needs to be updated. This includes re-evaluating whether residual risks are still acceptable in the context of the benefit-risk balance, and updating the risk management report accordingly.

Verification and validation (Section 5) Design changes often require new or supplemental testing. The updated technical file needs to reference the specific test reports that validate the changed device — not just the reports that validated the original design. Test reports that were written for a previous device configuration are not automatically valid for the changed configuration.

Clinical evaluation (Section 6) Significant design changes may affect the clinical evidence base. If the change alters device performance, introduces new materials, or changes the safety profile, the clinical evaluation report needs to be reviewed and potentially updated. For Class III devices, significant changes may trigger re-examination by the Notified Body — but the clinical evaluation update is an internal obligation that applies regardless.

The change control record — what it needs to show

Every design change, whether significant or not, should generate a change control record. The record does not need to be elaborate, but it needs to show:

• What changed, specifically
• The date of the change
• The significance assessment outcome and the reasoning
• Which sections of the technical file were updated (or a rationale for why no update was needed)
• Sign-off from the appropriate person

At a surveillance audit, a Notified Body auditor will often ask to see your design change history. They are checking whether you have a functioning change control process, whether significant changes were captured, and whether the technical file was updated in step. A gap in the change history — a component substitution that happened but was never formally assessed — is a finding. A change control record that shows a change was assessed as non-significant, with a brief rationale, is defensible even if the auditor would have assessed it differently.

When a change must be notified to the Notified Body

For devices certified under Annex IX (QMS + technical documentation route) or Annex X (type examination route), certain changes must be approved or notified to the Notified Body before implementation. The threshold varies by conformity assessment route and device class, but changes that substantially affect the device's design, intended purpose, or GSPR compliance are generally in scope.

The internal significance assessment feeds directly into this decision. If the significance assessment concludes a change is substantial, the next question is whether it triggers the notification or re-examination obligation under your specific conformity assessment procedure. Your Notified Body will have guidance on their specific requirements — and in cases of doubt, it is better to notify and receive confirmation than to proceed and have the change flagged at a surveillance audit.

A practical check for teams managing multiple change cycles

Technical files that have been through several change cycles can develop internal inconsistencies as sections are updated at different times. A useful periodic check: compare the version dates across key documents in the technical file — the device description, the GSPR matrix, the risk management report, the clinical evaluation summary, and the labelling. If some documents are significantly more recent than others, that is a flag. Either those documents were updated for a reason that should have triggered updates to the others, or the update process was not fully followed. Either way, it is worth investigating before a Notified Body does.