A notified-body auditor asked for the change impact analysis behind a single component revision. I had thirty minutes of evidence and fourteen documents I hadn't mapped to the change.
That was the day I learned change impact analysis isn't paperwork you do at the end of a change. It's the part you should have started with.
I work at a contract manufacturer in Bangalore. Three global medtech OEMs send us drawings, we make components, they ship finished devices. Every component change — a supplier resin tweak, a tolerance tightening, a post-cure profile update — has to ripple back through the Technical File of the OEM who owns the device. That's where the time sink lives. ISO 13485 §7.3.9 and §8.5.6 cover change control, but neither tells you how to do it on a Friday afternoon with three changes in flight.
What "impact" actually means across the Technical File
When a single raw-material component changes, here are the documents that should be on the impact map for a Class IIb device under EU MDR:
- Device Master Record (DMR) and Device History Record (DHR) entries
- Design History File (DHF) — drawing revision, BOM
- Risk Management File (ISO 14971) — is the new material still within the established risk envelope?
- Material specification and incoming inspection procedure
- Supplier qualification records and the supplier's own PPAP / COA trail
- Process validation protocol (IQ/OQ/PQ) — does the change invalidate the prior validation?
- Labeling and IFU — anything that touches material content, sterilisation claims, MR-conditional language
- Sterilisation validation, where applicable
- Biocompatibility file (ISO 10993 series) — any new material touches this
- Post-market surveillance plan and the trending thresholds
- Clinical evaluation report — does the change touch claimed equivalence?
- CAPA register — any open CAPAs tied to the old material
- Change Control record itself (the audit trail of the change)
- Regulatory submission impact — does this need a notification to the notified body or a new DoC?
That's fourteen. I've seen it go higher when an OEM's regulatory team adds their own layers.
Why nobody maps it
Three honest reasons from my own floor:
- It's invisible work. A change request lands, the engineering team closes the technical task, and the QA team is expected to "handle the documents." There's no visible deliverable until the auditor asks.
- The systems are fragmented. The drawing lives in PLM. The risk file is in one eQMS. The supplier COA trail is in another. The CAPA register is in a third. Cross-linking is manual.
- We assume small change equals small impact. A 0.05 mm tolerance tightening doesn't feel like a regulatory event. It is.
What I tried — and where it broke
My first attempt was a 14-row spreadsheet. It worked for two years. Then the OEM updated their IFU and added two more documents I hadn't known about, and the spreadsheet quietly went stale. That's the failure mode: matrices rot, and a stale matrix is worse than no matrix because it gives the auditor false confidence.
My second attempt was a Python script that took the change description, queried a small Postgres schema of document metadata, and produced a draft impact list. Better — but it depended on someone keeping the document metadata up to date, and we all know how that goes. Process automation is only as good as the metadata feeding it.
The current setup is a Grafana dashboard over the change-control table, with a "documents potentially impacted" column flagged from a combination of document tags and a manually maintained cross-reference matrix. It's honest about being semi-automated. The traceability is there for the auditor, and the reviewability is human-controlled.
This is the part where I'll be candid about tooling. I have some involvement with qmsWrapper — they market themselves as "The AI QMS that automates impact analysis," and the Smart Form Assistant for Medical Device QMS is genuinely useful for device makers trying to keep their DHF, risk file, and change records connected. The connected workflow pitch — one place where change, CAPA, risk, and document control actually link — is the right framing for an OEM with a single Technical File to defend.
It does not, however, fit my CMO-side supplier-quality work. I have 40+ suppliers of my own. My impact map runs sideways across supplier COAs, incoming-inspection records, and sub-tier audit trails — not down into a single device's Technical File. The shape of the problem is different. I'm not their customer, and pretending a device-maker eQMS solves CMO supplier work has burned us before. AI-driven CAPA assistance on the device side is one problem; supplier-side non-conformance chasing across a multi-tier BOM is a different shape entirely.
I work on qmsWrapper and have given this honest read because their connected-workflow story genuinely impresses me on the device-maker side, and genuinely doesn't fit mine.
Practical takeaways
If you're a QA tech lead staring down a change-impact backlog before your next audit:
- Build the document list before the change, not after. The list is the deliverable.
- Maintain the cross-reference matrix as a living artefact. Stale matrices are worse than no matrix.
- Whatever automation you layer in, keep the human review visible. AI-assisted impact mapping is fine; AI-only impact mapping with no audit trail is a finding waiting to happen.
- Treat the CAPA register as part of the impact map, not separate from it. A change that closes (or opens) CAPAs is itself a CAPA event — and CAPA-driven risk assessment should follow the change, not lag it.
The cheapest audit defence isn't the cleverest tool. It's the boring artefact, kept current, that an auditor can read in five minutes.
What does your change-impact map look like today — and is it the artefact you'd hand an auditor without rewriting it first?
Top comments (0)