In most medical device teams, traceability doesn’t fail all at once.
It breaks quietly.
A requirement gets updated.
The change is approved.
Work continues.
And everything looks fine.
Until someone asks a simple question:
What else did that change affect?
The assumption that causes the problem
Most QMS processes assume that once a change is approved, the impact is understood.
But approval is not impact analysis.
Approval means someone agreed to the change itself.
It does not mean every downstream dependency was identified, reviewed, and updated.
That gap is where traceability starts to break.
Where traceability actually fails
You see it in small things first:
A requirement is updated, but the related risk is not re-evaluated
A design input changes, but the verification plan stays the same
A test still references an outdated version
A document is revised, but nothing links back to why
Individually, these don’t look critical.
Together, they create a system where everything is documented, but nothing is connected.
The audit moment
This usually surfaces during an audit.
An auditor doesn’t ask for the document.
They ask for the logic behind the change.
What triggered it
What it impacted
What was updated
How you verified it
And suddenly, the team is reconstructing the story:
Jumping between CAPAs, documents, risk files, and test records
Trying to prove that everything is aligned
Most teams can reconstruct it.
But it takes time.
And it’s rarely complete.
The real issue is not missing data
The data exists.
Requirements are there.
Risks are documented.
Tests are executed.
The problem is that these elements are not kept in sync when something changes.
Traceability is not about having links.
It’s about maintaining those links as the system evolves.
Why this keeps happening
Because impact analysis is still treated as a manual task.
Someone needs to:
remember what might be affected
check multiple systems or modules
decide what needs updating
create follow-up actions
This works in small systems.
It doesn’t scale in real MedTech environments.
What needs to change
Traceability cannot depend on memory or manual cross-checking.
It has to be part of the change itself.
The moment a change is proposed, the system should already be answering:
what is connected
what is affected
what needs to be updated
Not after approval.
Not during audit preparation.
But at the moment the change happens.
Final thought
Most teams don’t have a traceability problem.
They have a change visibility problem.
They approve the change.
But they don’t see everything that changes with it.
If this sounds familiar, this breakdown explains it well in the context of change impact inside a QMS:
https://www.qmswrapper.com/ai-qms-for-medical-devices
Top comments (0)