How MedTech teams move from static DHF storage to a living Design Traceability File (DTF)
Every QMS Manager recognizes this moment:
A design change happens—small on paper, huge in consequences.
And suddenly the same questions return:
- Which requirements does this affect?
- Which risks must be re-evaluated?
- Which tests must be repeated?
- Which documents must be updated?
- How do we prove the chain end-to-end—fast?
This is where traceability often fails.
Not because teams don’t care.
But because their system isn’t built to stay connected.
The hidden pain: your DHF is “stored,” but not “structured”
Most Design History Files (DHF) are treated as document repositories:
folders, PDFs, spreadsheets, exported reports.
That works—until something changes.
Because when a requirement changes, traceability isn’t a filing task.
It’s a lifecycle task.
And lifecycle logic isn’t stored well in static formats.
This is why teams end up with broken links, outdated matrices, and “manual reconciliation” before audits.
The real issue: Traceability is treated like paperwork
In many organizations, traceability is maintained as:
- a spreadsheet
- a table in a document
- a manually updated matrix
It becomes a periodic activity: “Update the TM before the audit.”
But regulators don’t evaluate “your spreadsheet.”
They evaluate your control:
- do you know what changed?
- can you show what it impacted?
- can you show verification/validation evidence?
- can you show risk re-evaluation decisions?
A static DHF makes this harder than it should be.
The shift: from “DHF as archive” to “DTF as living structure”
In qmsWrapper, we needed a term for what most MedTech teams actually lack:
Not another folder.
A living structure where traceability survives change.
That’s why we use:
Design Traceability File (DTF)
A Design Traceability File is the digital map of your development logic—where traceability is built into the structure, not manually maintained as a spreadsheet.
If DHF is the history,
DTF is the operating system of design traceability.
What “living traceability” really means
In practice, Design Traceability File is built around interconnected elements:
- Use Cases
- Requirements (and sub-requirements)
- Risk assessments
- Design Inputs / Design Outputs
- Verification and validation tests
The key is not that these items exist.
The key is that they are connected by design.
So when a requirement changes, you don’t “remember” to update the chain.
Capturing the change is only the first step.
The real challenge is understanding what it impacts.
This is where most systems fail.
We explain this in detail in our AI QMS report
The system shows you the impact path.
This is what QMS Managers want:
less manual maintenance, more controlled clarity.
A simple mental model QMS Managers remember
Here’s the easiest way to explain DTF (Design Traceability File) vs DHF (Design History File) without sounding like marketing:
- DHF = where documents are stored
- DTF = where relationships are managed
The difference is what happens during change.
When a requirement changes:
- DHF makes you search
- DTF makes you see
Why this matters for MDR and FDA expectations
Under MDR, technical documentation must remain current and defensible across the product lifecycle.
Under FDA expectations, traceability and design controls must demonstrate control, not just existence.
Design Traceability File supports that because it keeps:
- requirements tied to risk
- risk tied to verification evidence
- changes tied to affected records
This turns traceability into daily reality—not audit-week panic.
The “one row” advantage (Traceability Log mindset)
Most teams think of traceability as “a big table.”
Design Traceability File makes it thinkable as:
one chain that can be inspected instantly:
Use Case → Requirement → Risk → DI/DO → Tests
If you can see the chain, you can defend it.
Seeing the chain is one thing.
Proving it during an audit is another.
Why “show me the link” breaks most QMS tools
Micro-glossary
- DHF: design history archive (documents, evidence, outputs)
- DTF: living structure that keeps DHF logic connected across changes
- Interconnected forms: structured records that “talk to each other” (so impact doesn’t get lost)
The qmsWrapper Logic
Capture → Structure → Retrieve → Defend
- QES (Capture): Every quality signal becomes a documented Event.
- DTF (Structure): Every requirement, risk, and test remains connected through the lifecycle.
- AI Search (Retrieve): Every decision and link can be retrieved instantly, across modules.
Result: Structured, defensible compliance — not reactive documentation.
Terminology Clarified
- Event: A documented starting point of a quality signal before escalation.
- QES: The controlled intake and triage layer of your QMS.
- DTF: The structured design control environment that keeps traceability intact.
- AI Search: Semantic retrieval across quality, design, risk, and evidence.
What Comes Next
First, we made it possible to capture every signal.
Then, to keep it structurally connected.
Soon, we will show how structured events can be intelligently mapped into controlled execution — always with human approval at critical decisions.
FAQ: AI-Powered QMS for MedTech
Is Design Traceability File replacing DHF?
No. DHF remains your required body of evidence. Design Traceability File is how that evidence stays connected and traceable as changes occur.
Is DTF just a Traceability Matrix?
No. A matrix is an output view. DTF is the underlying structure that keeps the relationships valid.
Why is this better than spreadsheets?
Spreadsheets require manual updates and often miss links after changes. DTF keeps traceability alive through structure.
What’s the benefit in an audit?
You can show impact, risk linkage, and verification evidence without manual “stitching.”
Capture first. Connect next. Mapping is coming.
