To be fair, swapping a supplier or a component usually starts as a straightforward commercial ask: cheaper, nearer, or the incumbent supplier went bankrupt. In practice it can cascade through the Technical File in ways that surprise engineering and keep regulatory awake at night.
I've seen a Class IIa electro-mechanical device where replacing a temperature sensor produced six weeks of delay before the device could be re-released. The reason wasn't the price or the sensor spec alone — it was all the downstream work nobody budgeted for: risk updates, verification protocols, supplier audits, labelling, software threshold revalidation, and notified-body paperwork.
Why a “small” substitution is not small
Annex II of MDR 2017/745 requires the Technical Documentation to demonstrate that design and manufacturing information is complete and consistent with the device’s intended purpose. A component change touches those threads:
- Design inputs and the Bill of Materials (BOM) change, affecting drawings and traceability.
- Risk management (ISO 14971) needs to reassess hazards introduced by the new part and any failure modes.
- Verification and validation may no longer be valid — even if the new part “meets the same spec”, integration tests and software thresholds can behave differently.
- Supplier controls (incoming inspection, supplier evaluation) must be updated and evidence added to the Technical File.
- Information for users (IFU, labelling) or packaging may need revision if the change affects use, cleaning, or lifecycle.
- Traceability to UDI/UDI-DI and production records must be maintained.
In short: the Technical File is a web, not a folder. Pull one thread and several documents move.
The checklist I actually run before approving a substitution
When a proposed change lands in my inbox I do a quick structured impact analysis. This is the list I use every time — it catches the predictable hidden work.
Documentation to check and update:
- Design history and BOM
- Risk file (ISO 14971) — hazard analysis, risk control measures, risk/benefit
- Verification and validation reports (including software integration tests if thresholds change)
- Manufacturing instructions and acceptance criteria
- Supplier qualification records and incoming inspection plans
- Labelling and IFU where applicable
- Post-market surveillance plan and PMCF triggers (will this change affect clinical performance?)
Stakeholders to involve:
- Design engineering (integration and tolerances)
- Software if thresholds/algorithms are involved
- Quality/supplier management (audit, incoming inspection)
- Regulatory (to assess whether NB notification is needed)
- RA/clinical for potential impact on clinical evidence or claims
Tests and activities I require:
- Updated FMEA / fault-tree analysis
- Targeted bench verification (not “trust the datasheet”)
- Environmental/EMC checks if the component influences emissions or susceptibility
- Packaging drop/vibration if form/fit changes
- Supplier audit or at least a remote assessment and certificates of conformity
A short walk-through: the sensor swap that cost six weeks
We replaced a temperature sensor that “matched” range and accuracy. What broke was subtle:
- The new sensor had a slightly different time constant — the software control loop started oscillating on certain cycles.
- That produced noise spikes that triggered an alarm condition in the device logic; we needed an SQA fix and an additional verification run.
- Our risk file had not considered oscillation-induced alarms for that measurement channel, so the hazard analysis required an update and risk-control documentation.
- Because alarm behaviour changed, we updated the IFU and the labels to clarify behaviour and test requirements for users.
- Notified body? Not every change needs re-certification, but because alarms relate to safety and the software logic changed, we logged it as a “significant change” and prepared the change package for NB review. The NB asked for the new verification reports and the updated risk file.
Two lessons: (a) spec-sheet parity is not system-level parity; (b) the cost is largely review time and re-verification, not the part price.
How I run the analysis efficiently (practical tips)
- Start with a traceability matrix that links requirements → design → verification → risk controls → IFU. If you don’t already have this, create a minimal one for the change.
- Use a change impact template that’s short and enforced. My template asks three binary questions: does this change affect performance? safety? intended use? If yes to any, the checklist expands.
- Keep supplier qualification evidence ready: audit summaries, CAPAs history, certificates. Those are often requested by auditors and NBs first.
- Prioritise targeted verification over full revalidation where justified — show the reasoning in the Technical File.
- Document decisions and who reviewed them. Per Annex II, reviewers and dates matter.
I use eQMS features daily to make this manageable. Automatic change impact analysis that pulls linked documents (requirements, risk items, V&V tests) reduces the “what must I update?” question from dozens of emails to a single, traceable view. Connected workflow and reviewability mean the engineer, QA, and RA see the same checklist and sign off in sequence — audit trails included.
When to involve the notified body (and when you won’t)
Not every supplier swap is NB-level. If the change does not affect safety/performance or intended purpose, you can usually proceed with internal change control and update the Technical File. If the change has the potential to alter clinical performance, safety characteristics, or conformity to GSPRs in Annex I, prepare for NB scrutiny.
In practice: involve your NB early if the change touches software logic, alarms, sterility, implantable parts, or clinical claims. They will ask for the risk file, V&V, and evidence that post-market surveillance will catch residual issues.
Final practical nudge
Budget the hidden work. When procurement negotiates price, add a line item for regulatory impact: update time for risk, V&V, supplier qualification, and NB interaction. It avoids surprises in release schedules.
To be fair, some swaps are genuinely low risk — but your Technical File will always need an explicit story that explains why you classed the change as low risk. That story is what auditors and notified bodies read.
What small substitution surprised you most in your Technical File, and how did you quantify the downstream effort?
Top comments (0)