Medical Device Design Input Traceability Matrix Worksheet
A design traceability matrix shows that every design input is realised in a design output and checked by a verification. It is the quickest way for an auditor, or your own design review, to see gaps.
| Input ID | Design input requirement | Source | Design output | Verification method | Verification record | Status | Linked risk ID | |
|---|---|---|---|---|---|---|---|---|
Use one row per design input. Every row should have a design output, a verification method and a record reference before design transfer. Keep a copy in the design history file.
Need traceability pulled from PLM and ERP?
Optional review of automating the requirement to record trace.
Optional. The tool and every export work without this. No spam.
How to use the matrix
List each design input as a row with a unique ID and its source. Add the design output that satisfies it, choose test, inspection, analysis or demonstration for verification, and record the protocol or report number. Link a risk ID if the input is a risk control, so risk management and design controls point at each other. Update the status as testing proceeds and export to Excel for design reviews.
Why it matters
ISO 13485 7.3 and 21 CFR 820.30 require design inputs to be documented, outputs to trace to inputs, and verification to be recorded. ISO 14971 expects risk control measures to be verified for implementation and effectiveness. For software, IEC 62304 requires traceability between requirements, tests and risks. A single matrix serves all three.
- Gaps show up as blank cells
- Supports design review evidence
- Links risk controls to verification
- Feeds the design history file index
Common mistakes
Teams write inputs that cannot be tested, such as 'device shall be easy to use', and then have no acceptance criteria. Others list outputs without versions, so the trace breaks after a change. Make each requirement measurable, reference released document revisions, and re-run the matrix review after every design change.
Frequently Asked Questions
Does every input need a verification?
Yes. Each design input should be verified by test, inspection, analysis or demonstration, with a record. Some inputs are covered by validation instead, but that should be stated explicitly.
Where does the matrix live in the DHF?
It is usually a controlled document listed in the design history file index and revised under change control as the design evolves.
Can I use this for software requirements?
Yes. Add columns for software item IDs and unit test references if you need IEC 62304 level traceability.
How often should I review it?
At every design review and after every design change, and before design transfer to confirm no row is open.
If your requirements and tests sit in PLM, ERP and spreadsheets, Netray can help build a single traced view. Ask for a short review.
Related Tools
Medical Device Design Verification Protocol Template
Fill-in design verification protocol with objective, samples, test method, acceptance criteria, deviations and approval lines.
Engineering & PLMMedical Device Change Control Request Template
Change request form with impact assessment on regulatory filings, risk files, validations and labeling.
Quality & InspectionMedical Device Supplier Evaluation Scoring Worksheet
Weighted scoring of critical and non-critical suppliers with approval status, for ISO 13485 clause 7.4 purchasing controls.
Compliance & ContractsMedical Device Post-Market Surveillance Plan Template
Plan template covering data sources, analysis methods, trend triggers and reporting for post-market surveillance.
More Engineering & PLM tools
See all- Design History File Index Template
- SAP Super BOM Design Worksheet
- SAP Engineering Change Number Checklist
- SAP Document Info Record Template
- SAP Change Master and Revision Level Log
- SAP Engineering Change Request (ECR) Template
- SAP BOM Usage and Item Category Reference
- SAP Engineering Change Obsolescence Exposure Calculator
- SAP Engineering Change Affected Materials Impact Worksheet