I spend most of my day turning scattered documents into a coherent Technical File for notified-body review. One recurring theme: "traceability" frequently exists as a paper trail — spreadsheets, PDFs, and emails — rather than as connected evidence. To be fair, the regulation expects traceability (see Annex II on Technical Documentation), but auditors and notified bodies want to see that the evidence is linked so you can follow a requirement all the way to verification, production and post‑market feedback.
In practice this means an eQMS that only stores documents is necessary but not sufficient. What actually proves you control the device lifecycle is an eQMS that links records to the design history and to the traceability matrix they support.
Why "traceability" often looks like paperwork
I've sat in audits where reviewers ask for:
- the requirements item,
- the related risk control,
- its verification report,
- the change request that implemented it,
- and the CAPA or complaint that showed it worked in the field.
When those items live in separate silos, you answer with filenames and folder paths. Reviewers then ask for time-consuming exports or screenshots. That is a slow, error-prone exercise and it invites follow-ups.
To be fair, small teams start with spreadsheets because they’re fast. Spreadsheets let you map requirements to tests and keep a traceability matrix. But once you have multiple design changes, supplier non‑conformances and PMCF data, the number of cross‑references explodes. The risk: the matrix drifts from the actual records. Per Article 10 obligations, you must keep records up to date and demonstrable — auditors will test that.
What "linked evidence" actually looks like
I find it useful to define the minimum set of linked relationships every eQMS should support:
- Requirement -> Design Input ID
- Design Input -> Design Output(s)
- Design Output -> Verification/Validation Report(s)
- Design Output -> Risk Control(s) (where applicable)
- Change Request -> Impacted Design Outputs/Verification
- CAPA/Complaint -> Root Cause -> Corrective Action -> Verification of Effectiveness
- Production batch record -> Device History Record -> Relevant Test Reports
When these relationships are persistent and queryable, you can navigate from a single requirement to all downstream evidence in seconds. That's the difference between "traceability" and "an audit project".
Practical steps I've used — not theory
If you’re a two-person RA/QA team with a quarter until your next audit, do this:
- Start with the Advanced Design Control Traceability Matrix (or your equivalent).
- Populate the high‑level links first: requirement IDs, main outputs, key verification reports.
- Enforce unique IDs.
- Every design input, output, change and CAPA should have a persistent ID. No filename-based tracking.
- Link at the time of action.
- When an engineer raises a change, they must select the impacted Design Output IDs. If the eQMS warns about linked test reports or risk items, even better.
- Make the links auditable.
- Ensure the eQMS stores who made the link and when (audit trail). Notified bodies often ask about change histories.
- Add verification endpoints.
- For every corrective action, link the verification evidence back to the originating CAPA and to the impacted design outputs.
- Export for review.
- The eQMS should produce a report (PDF/CSV) that shows a requirement and all linked evidence. If auditors ask for a zip of the DHF, this reduces manual assembly time.
What auditors actually want to see
Notified bodies rarely want to read everything. They want reproducible links. A reviewer may sample a requirement and expect to trace:
- how it was implemented (design output),
- how it was verified (V&V report),
- whether the field confirmed it (complaint trends or PMCF/PSUR),
- and what you changed when it failed (change request + CAPA effectiveness).
They will test the integrity: ask for the link between a complaint and the CAPA that closed it; ask for the verification report that demonstrates the CAPA worked. If you can click through in your eQMS, you pass quickly. If you hand over ten PDFs and a spreadsheet, you get follow-ups.
Tools and workflows that actually matter
To cut through vendor marketing, focus on a few capabilities:
- connected workflow integration (change control, CAPA, risk, docs),
- traceable linking with persistent IDs,
- reviewability (who approved what, when),
- controlled assistance for routine link suggestions (e.g. the system proposing related documents when you raise a change),
- exportable Design History File / Technical File snippets.
To be clear: AI-driven or AI-assisted CAPA suggestions are useful only if the suggestions are reviewable and traceable. The tool must not hide the rationale; auditors will ask how a link was made or changed.
Final thought
Traceability is not a checkbox. It's a living property of your quality system. Until your eQMS can show the links — not just the documents — you will spend auditing cycles reassembling evidence rather than demonstrating control.
How have you structured links between CAPAs, changes and design outputs in your QMS so an auditor can follow a requirement end-to-end?
Top comments (0)