Traceability Matrix for Medical Devices: From User Needs to V&V — Complete Implementation Guide

Why the Traceability Matrix Is the Most Audited Document in Your DHF

During an FDA inspection or a Notified Body audit, the investigator will pick a high-risk user need and ask you to trace it — down to the design output, the code module, and the verification test. Then they will ask you to trace it back up to the clinical validation. If there is a single break in that chain, the device may be considered non-compliant. Under the FDA's Quality Management System Regulation (QMSR), effective February 2, 2026, which incorporates ISO 13485:2016 Clause 7.3 by reference, the requirement for traceability of design outputs to design inputs is now codified into US federal law.

The requirements traceability matrix (RTM) is the single most efficient way to demonstrate these linkages. Yet many medical device companies still rely on disconnected spreadsheets, email threads, or memory to connect their design elements. This guide covers everything you need to build, maintain, and audit-proof your traceability matrix — from first principles to implementation.

What Is a Traceability Matrix?

A traceability matrix is a structured document or database that maps the relationships between every level of your design hierarchy. At minimum, it links:

• User Needs — what the user requires the device to do
• Design Inputs — measurable, verifiable engineering requirements derived from user needs
• Design Outputs — specifications, drawings, code, and other deliverables that embody the inputs
• Risk Controls — hazard mitigations derived from ISO 14971 risk analysis
• Design Verification — evidence that design outputs meet design inputs (did we build it right?)
• Design Validation — evidence that the device meets user needs and intended use (did we build the right thing?)

For software medical devices, the matrix also extends to:

• Software Requirements (IEC 62304 Section 5.2)
• Software Architecture (Section 5.3)
• Software Detailed Design (Section 5.4)
• Source Code / Implementation (Section 5.5)
• Unit, Integration, and System Testing (Sections 5.5–5.7)

Regulatory Basis

Bidirectional Traceability: The Engineering Discipline

Traceability in medical device development must be bidirectional:

• Forward traceability: Every user need traces to at least one design input, which traces to at least one design output, which traces to at least one verification test and one validation activity. This proves completeness — nothing was left untested.
• Backward traceability: Every verification and validation test traces back to at least one design input and user need. This proves necessity — no orphan tests exist.

Gaps in either direction are audit findings. A test suite with 2,000 passing tests provides no verification value if those tests cannot be linked to specific requirements. Conversely, a traceability matrix showing 100% requirement coverage with corresponding test results is strong verification evidence, even if the total test count is modest.

Why Backward Traceability Matters for Change Impact Analysis

When a design input changes — say, the material specification for a catheter shaft is updated — the RTM lets you immediately identify every downstream artifact that is affected: the drawing, the supplier specification, the verification test protocol, and potentially the risk assessment. Without this linkage, change impact analysis becomes guesswork, and you risk shipping a device with unverified changes.

Building the Matrix: Step-by-Step

Step 1: Capture User Needs

User needs are the voice of the customer — what clinicians, patients, or technicians need the device to do. They should be captured during the initial concept phase from:

• Clinical observations and user interviews
• Competitive product analysis
• Regulatory gap analysis
• Post-market surveillance data from predicate devices

Example: "The infusion pump must allow a nurse to program a drug delivery rate in under 30 seconds."

Each user need gets a unique identifier (e.g., UN-001).

Step 2: Translate User Needs into Design Inputs

Design inputs are measurable engineering requirements. The FDA's Guidance on Design Control (1997) states that inputs must be "comprehensive" and address "all relevant aspects." A user need often decomposes into multiple design inputs.

Example: UN-001 decomposes into:

• DI-001.1: "The device shall have a touchscreen interface with minimum 5-inch display."
• DI-001.2: "The rate entry screen shall display numeric keypad with minimum 12mm touch targets."
• DI-001.3: "The software shall accept rate input and confirm within 2 seconds."

The key rule: every design input must be measurable and verifiable. Avoid ambiguous terms like "lightweight" or "user-friendly."

Step 3: Define Design Outputs

Design outputs are the tangible artifacts that embody the inputs. These include:

• Engineering drawings and 3D models
• Software source code
• Bill of materials
• Assembly procedures
• Specifications for components and materials

Each output is linked to the input(s) it satisfies. A single input may produce multiple outputs.

Step 4: Map Risk Controls

ISO 14971 requires that risk control measures be verified for effectiveness. The RTM should link each identified hazard to its risk control measure, and then trace that control to the design input and the verification test that proves it works.

Example hazard chain:

• Hazard: "Pump delivers incorrect dose" → Risk Control: "Dose limit alarm at 999 mL/hr" → Design Input: DI-045 → Verification Test: V-045-01

Step 5: Plan and Execute Verification

For each design input, define how you will verify that the design output meets the input. Methods include:

Step 6: Plan and Execute Validation

Validation confirms that the device, as a whole, meets user needs and intended use. This typically involves:

• Clinical evaluation or investigation
• Simulated-use testing with representative users
• Bench testing under simulated clinical conditions
• Comparison to predicate devices

Validation must use production-equivalent units, not prototypes.

Step 7: Maintain and Update

The RTM is a living document. It must be updated whenever:

• A design input is added, modified, or deleted
• A verification or validation test changes
• A risk control is updated
• A design change is implemented through the ECO process

Traceability Matrix Structure: Template

A practical RTM typically takes the form of a table with the following columns:

Software-Specific RTM Additions

For software medical devices compliant with IEC 62304, add these columns:

Tools and Software

Spreadsheet-Based RTM

For early-stage startups and simple devices, a controlled Excel spreadsheet can work. Best practices:

• Use one worksheet per device
• Apply data validation to prevent broken links
• Use color coding for status tracking
• Maintain version control in your document control system
• Lock completed rows to prevent accidental changes

eQMS and ALM Platforms

As complexity grows, purpose-built tools offer significant advantages:

The critical evaluation criteria: Can the tool demonstrate bidirectional traceability during an audit? Can it generate reports showing coverage gaps? Does it maintain audit trails?

Common Audit Findings and How to Avoid Them

Finding 1: Incomplete Traceability

What auditors see: A user need with no verification test, or a verification test with no linked design input.

How to fix: Run a coverage analysis monthly. Every user need must have at least one design input, every design input at least one verification test. Use conditional formatting or automated reports to flag gaps.

Finding 2: Orphan Tests

What auditors see: Test protocols that do not trace back to any design input. These are tests that verify something, but nobody can explain what or why.

How to fix: Before executing any test, confirm it has a linked design input. Archive tests that verify superseded requirements with proper justification.

Finding 3: Broken Links After Design Changes

What auditors see: The RTM references "DWG-1045 Rev A" but the current revision is Rev C. The verification test was executed against Rev A and never repeated for Rev C.

How to fix: Every design change through the ECO process must trigger an RTM update. The change control procedure should include a mandatory step: "Update traceability matrix and re-verify affected requirements."

Finding 4: Risk Controls Not Traced

What auditors see: The risk management file identifies a risk control measure, but the RTM has no link between that measure and a design input or verification test.

How to fix: Integrate your risk management file and RTM. Every risk control in the ISO 14971 risk register should map to at least one design input.

Finding 5: Software Traceability Gaps (IEC 62304)

What auditors see: For a software safety classification B or C device, the software requirements cannot be traced to unit tests, or the software architecture elements cannot be traced to detailed design specifications.

How to fix: IEC 62304 Section 5.7.1 explicitly requires traceability between software requirements, architecture, detailed design, and test results. Build this into your software development SOP.

Traceability in Agile Development

A common misconception is that Agile development is incompatible with design controls and traceability. It is not. The FDA has clarified through AAMI TIR45 that Agile is acceptable, provided that each sprint produces the required documentation.

Practical approach:

1. Maintain user stories in a tool that supports traceability linking (Jira with a compliance plugin, or an ALM platform)
2. Each user story maps to a design input
3. Each sprint produces verification evidence linked to the stories completed in that sprint
4. Design reviews occur at sprint boundaries or at defined cadences
5. The RTM is updated at the end of every sprint

The key is that the traceability chain is maintained incrementally, not retroactively. Attempting to create a traceability matrix after development is complete risks substantial rework and is a major audit liability.

Traceability and EU MDR Technical Documentation

Under EU MDR Annex II, technical documentation must include evidence that the device meets the General Safety and Performance Requirements (GSPR) in Annex I. The GSPR checklist itself is a form of traceability matrix — each GSPR requirement must map to:

1. Whether it applies to the device (with justification if not)
2. The harmonised standard or common specification used to demonstrate compliance
3. The specific evidence (test report, clinical data, label review) that proves conformity

This GSPR traceability should be cross-referenced with the design control RTM to ensure consistency. A common finding during Notified Body audits is that the GSPR checklist references evidence that does not match the design control documentation.

Traceability vs. Document Control

Traceability and document control are related but distinct:

• Document control ensures that every document has a unique identifier, revision history, approval status, and controlled access.
• Traceability ensures that the content of those documents is logically linked across the design hierarchy.

A document can be perfectly controlled (correct revision, approved, stored in the eQMS) but still have broken traceability (the verification test it references has been superseded). Both systems must work together.

Comparison: Manual RTM vs. Automated ALM

FAQ

Is a traceability matrix legally required by name? Neither ISO 13485 nor 21 CFR 820.30 explicitly mandates a "traceability matrix" by that name. However, the underlying requirements — demonstrating that design outputs meet inputs, that verification confirms this, and that the DHF contains evidence of these linkages — effectively require one. In practice, auditors expect to see it, and not having one makes inspections significantly more difficult.

Can I use Jira for my traceability matrix? Jira can be part of your traceability system, but it is not a DHF by itself. To use Jira effectively, you need compliance-focused plugins (such as Ketryx, ComplianceQuest, or Xray) that enforce bidirectional links, audit trails, and electronic signatures compliant with 21 CFR Part 11. Plain Jira without these controls will not satisfy an auditor.

How often should the RTM be reviewed? The RTM should be reviewed at every design review milestone and updated after every design change. At minimum, conduct a coverage analysis monthly during active development and quarterly during maintenance.

What happens if a requirement has no test? This is a compliance gap. Every design input must have at least one verification activity. If a requirement genuinely cannot be tested, document the rationale (e.g., it is verified through analysis or inspection instead) and ensure the alternative method is recorded in the RTM.

Does the RTM need to cover legacy devices? If a legacy device is still on the market and subject to post-market surveillance, the design history should include some form of traceability. For devices transitioning from MDD to EU MDR, the GSPR compliance exercise often reveals traceability gaps that must be addressed.

How does traceability relate to UDI under EU MDR? UDI (Unique Device Identification) provides device-level traceability in the supply chain. The RTM provides design-level traceability within the DHF. They serve different purposes but both contribute to the overall goal of ensuring that what is on the market can be traced back to its design specifications.

What is the difference between the RTM and the DHF index? The DHF index is a table of contents for the Design History File — it lists all the documents and their locations. The RTM is a cross-reference tool that shows how the content of those documents relates to each other. You need both.

How do I handle traceability for AI/ML medical devices? AI/ML devices require additional traceability layers: training data provenance, model version control, performance validation datasets, and predetermined change control plans (per FDA's 2025 PCCP guidance). Each model version should trace back to its training data, validation results, and the clinical performance claims it supports.

Key Takeaways

1. The RTM is not optional. While not named explicitly in regulations, the underlying requirements make it a practical necessity for passing FDA and Notified Body audits.
2. Build it early, maintain it continuously. Retroactive RTM creation is expensive and error-prone. Start during design planning and update at every change.
3. Bidirectional traceability is the gold standard. Every link must work in both directions — forward from user need to test, and backward from test to user need.
4. Integrate risk controls. Your ISO 14971 risk management file and RTM must be cross-referenced so that every risk control traces to a verified design element.
5. Choose tools proportional to your complexity. A well-maintained spreadsheet beats a poorly configured ALM platform, but as complexity grows, purpose-built tools become essential.