ISO 13485:2016 Quick Start Guide
Medical device design controls under ISO 13485:2016 require rigorous traceability from customer needs through design outputs, verification, and validation. This guide shows how RTMify maps directly to §7.3 design control requirements and accelerates Design History File (DHF) documentation.
For ISO 13485 workbooks, run RTMify Trace with the medical profile. That turns on the medical-specific checks for design inputs, design outputs, verification/validation continuity, and configuration items while preserving the generic matrix behavior.
RTMify Template Mapping to ISO 13485:2016
The RTMify template aligns directly with ISO 13485:2016 Clause 7.3 (Design and Development). Understanding this mapping ensures your design control documentation meets both standard and audit expectations.
| RTMify Field | ISO 13485:2016 Section | Purpose |
|---|---|---|
| User Needs | §7.3.3 Design Inputs | Capture customer requirements, regulatory mandates, performance needs, safety requirements, and applicable standards |
| Requirements | §7.3.4 Design Outputs | Define verifiable specifications derived from and traceable to design inputs |
| Tests (Verification) | §7.3.5 Design Verification | Demonstrate that design outputs conform to design inputs (did we build it right?) |
| Tests (Validation) | §7.3.6 Design Validation | Demonstrate that device meets user needs and intended use (did we build the right thing?) |
| Risks | §7.3 + ISO 14971 | Integrate risk management; trace risks to mitigating requirements and control implementation |
| Traceability Matrix | §7.3.8 Design Transfer | Evidence of complete traceability from inputs through outputs and testing to product realization |
What ISO 13485:2016 Requires
Design Inputs (§7.3.3)
ISO 13485:2016 §7.3.3 mandates that design input requirements shall:
- Include customer and user needs: Clinician usability, patient safety, environmental conditions
- Address regulatory and standards requirements: IEC 60601 series, ISO 14971 risk management, FDA 510(k) guidance, EU MDR annexes
- Define performance and safety requirements: Accuracy, reliability, shelf-life, biocompatibility, electromagnetic compatibility
- Be documented and reviewed: Design input review must identify ambiguities, conflicts, and incompleteness
- Be approved before design output development: Prevents rework; ensures shared understanding
Design Outputs (§7.3.4)
Design outputs are the specifications that implement design inputs. ISO 13485:2016 §7.3.4 requires:
- Verifiable specifications: Each requirement must be testable—include measurement criteria, pass/fail thresholds, and success metrics
- Traceability to design inputs: Every design output must link back to at least one design input; inputs map to outputs
- Performance and safety specifications: Electrical safety limits, biocompatibility grades, accuracy tolerances, latency budgets
- Risk control specifications: How design addresses identified hazards (ISO 14971 link)
- Documentation standards: Hardware specs, firmware design, software requirements specifications, mechanical drawings, material specifications
- Design output review and approval: Ensures specifications are complete, unambiguous, and achievable
Design Verification (§7.3.5)
Verification confirms that design outputs correctly implement design inputs. The standard states:
- Verification shall be performed: Testing, analysis, inspection, or demonstration against approved design outputs
- Includes first articles and samples: Tests on actual production units, not just prototypes
- Addresses all design outputs: Every requirement needs a verification activity; multiple tests per requirement are often necessary
- Covers design outputs derived from harmonized standards: When IEC 60601 mandates a 5:1 contrast ratio, your verification test must confirm it
- Documented and approved: Test plans, test results, and acceptance criteria clearly recorded
Example: REQ-001 states "Display SHALL maintain contrast ratio ≥ 5:1 at 500 lux." Verification includes luminance meter testing per IEC 62366 in a simulated bright-light clinical environment, recorded in a test report approved by Design and Quality.
Design Validation (§7.3.6)
Validation confirms the device meets user needs and intended use. This is distinct from verification:
- Clinical, user, or field validation: Real clinicians, patients, or environments—not just lab conditions
- Addresses high-risk or customer-critical requirements: Usability, efficacy, comfort, reliability under actual conditions
- Risk-based approach: High-risk requirements require robust validation; low-risk requirements may use demonstrated use or clinical data
- Includes intended use scenarios: If your device is for 72-hour continuous wear, validation includes 72-hour continuous wear studies
- Biocompatibility validation: If patient-contacting, ISO 10993 biocompatibility per intended contact duration and type
- Software validation: If device includes software, IEC 62304 software validation (covered in separate guide)
- Documented and approved: Validation protocols, results, and conclusions approved before product release
Design Transfer (§7.3.8)
Once design is verified and validated, design transfer ensures manufacturing can consistently produce the design. This requires:
- Process capability studies: Manufacturing parameters meet design specifications
- First article inspection: Initial production units tested against design outputs
- Manufacturing documentation: Work instructions, process controls, material specifications tied to design outputs
- Traceability matrix: Your RTM proves design outputs are realized in product specifications and manufacturing procedures
Design Changes (§7.3.9)
Post-approval design changes must undergo impact analysis and, if necessary, additional verification and validation:
- Change assessment: Does the change affect regulatory approval, safety, performance, or user needs?
- Re-verification required: If requirement specifications change, test again
- Re-validation required: If the change affects high-risk features or clinical use, clinical validation may be needed
- Post-market surveillance: Ongoing monitoring for unintended consequences
ISO 14971 Risk Management Integration
ISO 13485:2016 requires integration of ISO 14971 (Risk Management). The standard mandates:
- Risk identification: Hazards, hazardous situations, and harms
- Risk analysis: Severity and probability (or likelihood) estimation
- Risk evaluation: Compare estimated risk against risk acceptance criteria
- Risk control: Design mitigations (safest), protective measures, information for users
- Residual risk evaluation: After mitigation, is risk acceptable?
- Risk control verification: Test that mitigations work
Your RTMify Risks table links each identified risk to its mitigating requirement. Example: Risk RSK-101 (display unreadable in bright light) is controlled by REQ-001 (5:1 contrast), verified by test TG-001.
Step-by-Step Walkthrough: Medical Device Example
This example follows a wearable pulse oximetry sensor (SpO2 monitor) through all five steps. The device attaches to a patient's finger and wirelessly transmits real-time oxygen saturation to a clinician's tablet.
Step 1: User Needs (Design Inputs)
Gather requirements from customers (clinicians, hospital procurement), regulations (IEC 60601-1, FDA), and standards. Document each need with its source and priority. These become your §7.3.3 design inputs.
ISO 13485 Requirement: §7.3.3 mandates design inputs include customer needs, regulatory requirements, performance, safety, and applicable standards. Your User Needs table is the evidence for this requirement.
Auditor Questions:
- Are all customer needs represented? (Ask customers during design review)
- Have you identified all applicable standards? (FDA, EU MDR, ISO/IEC standards specific to device type)
- Are performance and safety requirements explicitly stated with acceptance criteria?
- Is there a record of design input review and approval before proceeding to Step 2?
Step 2: Requirements (Design Outputs)
Convert each User Need into one or more verifiable Requirements. Each Requirement is traceable to a User Need and includes acceptance criteria (the test will check against these). These are your §7.3.4 design outputs.
Key Features of Design Outputs:
- Verifiable: Each requirement includes success criteria (e.g., "≥5:1 contrast ratio," "±3% error")
- Traceable: Every requirement maps back to at least one User Need
- Standards-based: Specifications reference applicable standards (IEC, ISO, FDA guidance)
- Implementation-ready: Hardware and software engineers use these specs to design
ISO 13485 Requirement: §7.3.4 requires design outputs be documented, traceable to inputs, and reviewed/approved before implementation. Your Requirements table with traceability is the evidence.
Auditor Questions:
- Is every design output traceable to a design input? (Bidirectional: each input should map to outputs)
- Are acceptance criteria clear and measurable?
- Do specifications address all regulatory requirements from harmonized standards?
- Is there documented evidence of design output review by design, quality, and regulatory teams?
Step 3: Tests (Verification & Validation)
This is where the critical ISO 13485 distinction emerges: Verification (§7.3.5) vs. Validation (§7.3.6).
Verification: Testing the product in controlled lab conditions against the design output specification. "Did we build the requirements right?"
Validation: Testing the product in realistic or clinical conditions against user needs. "Did we build the right thing for the intended use?"
The V&V Distinction (Auditor Focus):
| Aspect | Verification (§7.3.5) | Validation (§7.3.6) |
|---|---|---|
| Question | Did we build the requirements right? | Did we build the right thing for real use? |
| Conditions | Lab, controlled, repeatable | Clinical, field, realistic, variable |
| Who | Engineers, QA testers | Clinicians, patients, users, end customers |
| Standard | Design spec (your REQ) | Customer need (your UN) + regulatory expectation |
| Examples | Luminance meter test, battery rundown, emissions testing, cytotoxicity lab test | Usability study, clinical validation, field trial, patient outcome study |
ISO 13485 Requirement: §7.3.5 and §7.3.6 both state verification and validation activities shall be planned and documented. Your RTMify Tests table with dual V&V entries provides this evidence. Every design output needs verification; high-risk or customer-critical requirements need validation.
Auditor Questions:
- Is verification performed against design outputs (requirements), and validation against design inputs (user needs)?
- Are test protocols (plans) documented before tests are run?
- Are test results traceable back to requirements?
- For failed or inconclusive tests, how is the failure addressed? (Re-design, deviation, risk assessment?)
- Is there a documented conclusion that all verification and validation requirements have been satisfied before product release?
Step 4: Risks (ISO 14971 Integration)
ISO 13485 §7.3 requires integration of risk management per ISO 14971. Each identified hazard must be mitigated by design controls (requirements) and the mitigation effectiveness verified through testing.
ISO 13485 §7.3 and ISO 14971 require clear linkage between identified risks and design controls (requirements) that mitigate them. Your RTMify Risks table is the evidence of this integration.
Auditor Questions:
- Have all potential hazards been identified? (Use FMEA, hazard analysis worksheets)
- Are risks prioritized by severity and probability?
- For each high/medium risk, is there a specific design requirement that controls it?
- Is risk control verification documented (the test proves the mitigation works)?
- After mitigation, is residual risk acceptable per your risk acceptance criteria?
Step 5: RTM Generation & Design History File
Once you have documented User Needs, Requirements, Tests, and Risks, RTMify generates your traceability matrix (RTM) and compiles evidence for your Design History File (DHF). This is your §7.3.8 design transfer documentation.
Traceability Matrix (RTM) Structure
Your RTM proves that every User Need (design input) traces through Requirements (design outputs) to Tests (verification/validation) and Risks (ISO 14971 controls). Auditors expect:
- Forward traceability: User Needs → Requirements → Tests (every need is implemented and tested)
- Backward traceability: Tests → Requirements → User Needs (every test traces back to a need; no orphan requirements)
- Risk-control traceability: Risks → Control Requirements → Verification Tests (every risk is controlled and verified)
- Completeness: All design inputs, outputs, verification, and validation are documented and approved before product release
Design History File (DHF) Contents
Your DHF includes (and RTMify helps organize):
- Design Input Documentation (§7.3.3): User Needs with sources and regulatory references
- Design Output Documentation (§7.3.4): Requirements with traceability and acceptance criteria
- Design Review Records (§7.3.7): Evidence of design team, quality, and regulatory review and approval
- Design Verification Reports (§7.3.5): Test plans, protocols, results for all requirements
- Design Validation Reports (§7.3.6): Clinical/user study plans, results, conclusions
- Risk Management Report (ISO 14971): Hazard analysis, risk evaluation, mitigations, residual risk assessment
- Traceability Matrix (§7.3.8): Complete RTM demonstrating coverage and bidirectional traceability
- Design Transfer Documentation (§7.3.8): Manufacturing process capability, first article inspection
- Design Change History (§7.3.9): All post-approval changes with impact analysis and re-verification/validation
Exporting to DHF
RTMify exports your complete project as a PDF bundle, suitable for regulatory submission:
- User Needs table (with source and regulatory mapping)
- Requirements table (with traceability links to User Needs)
- Tests table (V&V activities, link to Requirements, status)
- Risks table (link to Risk Mitigation Requirements)
- Traceability Matrix (complete coverage matrix)
- Design Input Review and Approval Records
- Design Output Review and Approval Records
Regulators and auditors expect this documentation in your DHF. RTMify's export function provides auditable evidence that you have met all requirements of ISO 13485:2016 §7.3.
When you validate the workbook itself, use rtmify-trace --profile medical your-workbook.xlsx. The medical profile is the mode that surfaces missing design-input/design-output chains and other medical traceability gaps before DHF review.
Frequently Asked Questions
How does this relate to my Design History File?
The RTMify template directly generates your Design History File (DHF) documentation. Each User Need, Requirement, Test, and Risk entry creates traceable records that auditors require. Your RTM becomes §7.3 evidence: design inputs (User Needs), design outputs (Requirements), verification (Tests), validation (Tests with validation type), and design change controls. Export your RTM as PDF for your DHF submission.
Do I need separate verification and validation for every requirement?
Not every requirement needs both. Verification (did we build it right?) applies to all technical requirements. Validation (did we build the right thing?) applies to requirements driven by customer needs and regulatory inputs—especially those affecting safety and performance. For example: a display contrast requirement needs both verification (luminance test) and validation (usability study). A firmware version requirement might only need verification (documentation check). ISO 13485 §7.3.5 and §7.3.6 distinguish these; auditors specifically check this distinction.
How do I handle requirements from harmonized standards (IEC 60601)?
Trace them back to User Needs. When IEC 60601-1 (general safety) mandates a particular electrical safety level, create a User Need with Regulation/Standard source, then derive Requirements that implement it. Example: UN-002 | "Device shall comply with IEC 60601-1 electrical safety" → REQ-002 | "Patient-contacting materials shall not exceed 5 µA leakage current" → Test to verify. This shows regulators that your design intentionally addresses each standard requirement.
What about FDA 21 CFR 820 design controls?
ISO 13485 §7.3 is recognized as equivalent to FDA 21 CFR 820.30 design controls by the FDA (Design Control Guidance for Medical Device Manufacturers, 2023). The mapping: Design Inputs (§7.3.3) = customer needs, regulatory; Design Outputs (§7.3.4) = verifiable specifications; Verification (§7.3.5) = testing to inputs; Validation (§7.3.6) = clinical/user testing; Design Changes (§7.3.9) = change control and impact analysis. Use the same RTMify template for both standards.
Ready to Start Your Design Controls?
RTMify makes it easy to build compliant design controls that auditors expect. Start documenting your design inputs, requirements, and verification/validation activities today.
Begin with RTMify