Requirements Traceability Matrix for Medical Devices: A Complete Compliance Guide

What This Guide Covers

If your DHF has ever been questioned during an audit because an auditor could not follow a requirement from its source through to verification, you already understand the cost of weak traceability. This guide walks through exactly what a Requirements Traceability Matrix (RTM) must contain for medical device development, which regulatory clauses require it, where most teams fail, and how an integrated ALM+QMS platform eliminates the manual work of maintaining it.

Why the RTM Is Not Optional

The RTM is the documentary spine of your design control process. Without it, you cannot demonstrate that every user need has been translated into a design input, every design input has been implemented, and every implementation has been verified and validated.

FDA 21 CFR Part 820.30 requires design controls that establish and maintain procedures to ensure device design is correctly translated into specifications. ISO 13485:2016 Clause 7.3 extends that requirement across the full design and development lifecycle, from planning through transfer. Neither regulation names the RTM explicitly, but both require the traceability it provides. In practice, every FDA investigator and ISO notified body auditor expects to see one.

The MDR (EU 2017/745) reinforces this through Annex II technical documentation requirements, which demand a description of the design stages applied and traceability between general safety and performance requirements and the evidence that satisfies them.

Failing to maintain an RTM is not a documentation style choice. It is a design control gap.

What a Compliant RTM Must Cover

A minimal RTM maps requirements to tests. A compliant RTM for a medical device does significantly more. Here is what your matrix must trace:

The Core Traceability Chain

1. User Needs (UNs) - The starting point. Captured from clinical inputs, market research, patient risk considerations, and intended use definitions (ISO 13485:2016 Clause 7.3.2).

1. Design Inputs (DIs) - Translated requirements derived from user needs. These become the technical and functional specifications that define what the device must do (21 CFR §820.30(c), ISO 13485:2016 Clause 7.3.3).

1. Design Outputs (DOs) - The actual implemented artifacts: hardware schematics, software modules, firmware builds, manufacturing specifications, labeling (21 CFR §820.30(d), ISO 13485:2016 Clause 7.3.4).

1. Risk Controls - Every requirement with a safety implication must link to the corresponding risk control in your risk management file (ISO 14971:2019 Clause 6, Clause 7). The RTM is where risk management and design control intersect.

1. Verification Records - Evidence that each design output meets its corresponding design input (21 CFR §820.30(f), ISO 13485:2016 Clause 7.3.6). This includes test protocols, test reports, analysis records, and inspection results.

1. Validation Records - Evidence that the device as built meets user needs and intended use (21 CFR §820.30(g), ISO 13485:2016 Clause 7.3.7). Clinical evaluation, usability testing, and simulated use studies live here.

1. Design Changes - Any change to a design input or output must be traceable through the matrix. Untraced changes are a common FDA 483 observation.

What Bidirectional Traceability Means in Practice

Bidirectional traceability means you can move in both directions across the matrix:

• Forward trace: From user need to design input to output to verification to validation. This proves nothing was missed.
• Backward trace: From a test result back to the requirement it satisfies. This proves nothing untraceable was implemented.

An RTM that only maps forward is incomplete. Auditors will run both directions.

Regulatory Clause Reference Summary

The Seven Most Common RTM Failures

1. Traceability Stops at Verification

Many teams build an RTM that maps user needs to design inputs to test cases. They stop there. Validation records, post-market data links, and risk control evidence are kept in separate documents with no formal connection. Auditors see this as a broken chain.

2. Risk Controls Are Not Linked

The risk management file is maintained in a separate spreadsheet or document. The RTM has no column for risk controls. This means you cannot demonstrate at a glance that every hazard-related requirement has a corresponding control, and every control has been verified as effective.

3. The RTM Is a Snapshot, Not a Living Document

Teams build the RTM late in development, populate it from memory, and treat it as a pre-submission artifact. When design changes happen (and they always do), the RTM is not updated. By the time an audit occurs, the matrix no longer reflects the actual device.

4. Requirements Lack Unique Identifiers

Without stable, unique requirement IDs, you cannot reliably link requirements across the matrix. "Requirement 7" in the design spec may or may not match "Requirement 7" in the test protocol. Auditors cannot reconcile them without interrogating your team.

5. Coverage Gaps Are Not Visible

No mechanism exists to identify orphaned requirements (inputs with no corresponding output or test) or orphaned tests (verification records that satisfy no stated requirement). These gaps are invisible until an auditor finds them.

6. Software Requirements Are Treated Separately

For software-containing devices, IEC 62304 requires traceability from system requirements to software requirements to software architecture to unit tests. Teams often maintain this in a separate development tool with no linkage to the QMS-level RTM. The result: a fragmented traceability story across two systems.

7. Change Control Breaks Traceability

A design change is processed through the CAPA or change control process, the design output is updated, but the RTM is not revised to reflect the impact. The matrix now shows a requirement verified against a version of the output that no longer exists.

How to Build a Compliant RTM: Step-by-Step

Step 1: Establish Your Requirement Taxonomy

Before building the matrix, define your requirement levels and naming convention. A typical hierarchy for a medical device:

• UN-XXX: User needs
• DI-XXX: Design inputs (functional, performance, safety, regulatory)
• DO-XXX: Design outputs (hardware, software, labeling, manufacturing specs)
• RC-XXX: Risk controls (from ISO 14971 risk management file)
• VER-XXX: Verification tests
• VAL-XXX: Validation activities

Assign unique IDs at the point of creation. Do not renumber.

Step 2: Capture Requirements at the Source

User needs belong in your design and development plan (ISO 13485:2016 Clause 7.3.2). They must be captured with enough specificity to be testable. "The device must be easy to use" is not a user need. "The device must allow a trained nurse to complete setup in under two minutes without reference to the instructions for use" is.

Step 3: Translate Each User Need to Design Inputs

For every user need, identify the design inputs that satisfy it. A single user need may generate multiple design inputs. Document the rationale for the translation. This is the evidence that user needs were properly understood and interpreted.

Step 4: Link Risk Controls

For every design input with a safety or performance implication, check your risk management file. If a hazardous situation exists that the requirement addresses, create a formal link between the design input and the risk control. If no risk link exists, that absence must be a documented, justified decision.

Step 5: Map Outputs to Inputs

Every design output must be traceable to at least one design input. If an output exists with no corresponding input, either a requirement is missing or the output should not exist. Run this check at every design review (ISO 13485:2016 Clause 7.3.5).

Step 6: Assign Verification and Validation Evidence

For each design input, identify the verification method (test, inspection, analysis, demonstration) and the corresponding protocol and report. For the full set of user needs, document how validation activities confirm the device meets intended use.

Step 7: Lock and Baseline at Design Reviews

At each formal design review gate, baseline the RTM. Record which version of the RTM was reviewed and approved. This creates the audit trail showing that traceability was assessed and approved at each stage of development.

Step 8: Maintain Through Change Control

Every approved design change must include an RTM impact assessment as part of the change package. If a design input changes, the corresponding outputs, verifications, and risk links must be reviewed and updated.

The Integration Problem Most Teams Face

Most medical device teams maintain their RTM across at least two systems: a requirements or ALM tool for engineering content, and a QMS platform for CAPA, design reviews, and DHF management. The gap between these systems is where compliance breaks down.

When a requirement changes in the ALM tool, someone must manually update the QMS. When a CAPA drives a design change, someone must trace its impact through the requirements. When an auditor asks for the full traceability chain from a user need through to a CAPA closed in response to a post-market complaint, you are assembling evidence across multiple disconnected databases.

This is not a process failure. It is a structural problem created by using tools that were not designed to work together.

How Orcanos Addresses RTM Compliance End-to-End

Orcanos is built as a single platform that covers both ALM and QMS functions, which means the RTM is not a separate artifact you maintain alongside your quality records. It is a live view into the relationships that already exist across your development and quality data.

Within Orcanos, requirements are captured with unique IDs at the point of authoring. Design inputs link directly to user needs. Risk controls from the risk management module link to the same requirement records. Verification and validation tests are created and executed within the platform and automatically reflected in the traceability matrix. Design reviews reference the current state of the RTM, with electronic approval creating a timestamped, signed audit record.

When a design change is initiated, Orcanos surfaces every linked artifact: the requirements affected, the tests that need to be re-run, and the risk controls that need reassessment. The change cannot be closed without completing that impact chain. This is not a configuration add-on. It is how the system is structured.

For software-containing devices, Orcanos supports IEC 62304 traceability from system requirements through software requirements to test records, within the same platform that holds your ISO 13485 design controls and ISO 14971 risk records. The IEC 62304-to-ISO 13485 traceability gap that creates audit findings for so many teams is closed within a single system.

During an audit, the RTM in Orcanos is not assembled from exports. The auditor (or your QA team preparing for the audit) can navigate the live matrix, follow any link in either direction, and pull the underlying evidence without leaving the platform.

RTM Compliance Checklist

Use this during design reviews and pre-audit assessments:

1. Every user need has a unique ID and a corresponding design input (ISO 13485:2016 Clause 7.3.3)
2. Every design input links to at least one design output (ISO 13485:2016 Clause 7.3.4)
3. Every design output with a safety implication links to a risk control (ISO 14971:2019 Clause 6-7)
4. Every design input has an assigned verification method and a corresponding test record (ISO 13485:2016 Clause 7.3.6)
5. Validation activities are documented and linked to user needs (ISO 13485:2016 Clause 7.3.7)
6. Bidirectional traceability has been confirmed: forward and backward traces are clean
7. No orphaned requirements or orphaned tests exist in the matrix
8. For software devices: IEC 62304 software requirements trace to system-level design inputs
9. The RTM was reviewed and baselined at each formal design review gate
10. All design changes have been assessed for RTM impact and the matrix reflects the current approved design
11. The RTM version referenced in the DHF matches the approved design output version

Next Step

If your current RTM lives in a spreadsheet or is split across an ALM tool and a separate QMS, the checklist above will surface gaps that are difficult to close without structural change.

Orcanos integrates your requirements, risk management, design controls, and CAPA into a single audit-ready platform, so your RTM is maintained automatically as your team works, not assembled manually before each audit.