DEV Community: dflood_qms

Why Traceability Breaks After a Design Change

dflood_qms — Wed, 22 Apr 2026 12:22:56 +0000

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

Why Most QMS Systems Still Fail at Change Impact Analysis

dflood_qms — Wed, 15 Apr 2026 13:10:45 +0000

Most QMS systems are designed to document change.

But that’s not where the real challenge is.

In practice, the problem starts after a change is approved.

What else did that change affect?

In most MedTech teams, this is still handled manually.

A requirement gets updated. But the related risk is not revisited.

A design change goes through. But the verification plan stays the same.

A deviation is closed. But no one checks what it means for the Technical File.

Everything is documented. But the connections are not.

So QMS managers end up doing the same thing over and over again.

Jumping between modules.

Cross-checking documents.

Trying to reconstruct the logic behind decisions.

Not because the system is missing data, but because it doesn’t show how that data is connected.

This is usually where traceability starts to break.

Not in big, obvious ways. In small gaps that only become visible during an audit.

A missing update. An outdated assumption. A link that was never made.

Most systems are not built to handle this.

They store records. They track workflows.

But they don’t actively evaluate the impact of change across the system.

And that’s exactly what auditors are starting to focus on.

Not just whether something was recorded, but whether the logic holds together.

If one thing changed, how did you make sure everything affected by that change was updated?

That’s a very different question.

What’s becoming clear is that documenting change is not enough.

Understanding change impact is the actual work.

That means being able to see:

which requirements are affected

which risks need to be re-evaluated

which tests are no longer valid

what needs to be updated before anything is implemented

Not after.

We’ve been working on this problem from a system perspective.

What happens if change is not treated as an isolated action, but as something that propagates?

What happens if the relationships between requirements, risk, and verification are actually used?

The approach we ended up with is simple in principle.

An event happens.

Its impact is analyzed across the system.

The necessary updates become visible.

Traceability is maintained as part of the workflow.

Instead of investigating impact manually, the system surfaces it.

If you’re dealing with MDR or FDA expectations, this is where things usually get difficult.

Not documentation, but consistency.

Not records, but connections.

If you want a more detailed breakdown of how this works in practice, we put it together here:

https://qmswrapper.com/ai-qms-for-medical-devices/

And if you’re curious how this looks inside an actual QMS workflow:

https://qmswrapper.com/qms-software-demo/

Most QMS systems help you record what changed.

Very few help you understand what that change actually means.