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.

ISO 13485:2016 §7.3 Design and Development Last updated: March 12, 2026

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
Auditor focus: Are design inputs comprehensive? Do they trace to your product scope? Is there evidence of customer/regulatory input, not just internal assumptions?

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
Auditor focus: Can every design output be tested? Is the traceability complete and bidirectional? Are safety and regulatory requirements explicitly addressed?

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
Key distinction (auditor focus): A luminance meter test is verification (did we build the output right?). A usability study where clinicians read the display in a simulated ward is validation (did we build the right thing for real use?).

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.

User Needs Template (ISO 13485 §7.3.3 Design Inputs) ───────────────────────────────────────────────────── UN-001 | Display & Usability "Clinician shall be able to read patient SpO2 in ambient light conditions up to 500 lux" Source: Customer | Priority: High | Regulatory Ref: IEC 60601-1-6 (usability) UN-002 | Patient Safety "Device shall not cause skin irritation or sensitization during 72-hour continuous use" Source: Regulation (IEC 60601-1-2 skin contact; ISO 10993) | Priority: High | Regulatory Ref: ISO 10993-5 Cytotoxicity, IEC 60601-1-2 §7.3.3 UN-003 | Battery Life "Battery shall last at least 8 hours of continuous monitoring at nominal SpO2 measurement rate" Source: Customer | Priority: Medium | Regulatory Ref: None UN-004 | Measurement Accuracy "SpO2 measurement accuracy shall be ±3% in range 70–100% SpO2 per clinical studies" Source: Regulation (FDA 510(k) guidance on SpO2 devices) | Priority: High | Regulatory Ref: FDA-2001-D-0001 SpO2 Accuracy UN-005 | Wireless Connectivity "Wireless transmission shall comply with FCC Part 15 and shall not cause interference with clinical equipment" Source: Regulation | Priority: High | Regulatory Ref: FCC Part 15.109, IEC 60601-1-2 EMC UN-006 | Biocompatibility "Patient-contacting adhesive shall not leach chemicals harmful to skin tissue" Source: Regulation | Priority: High | Regulatory Ref: ISO 10993-1, -5, -9

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.

Requirements Template (ISO 13485 §7.3.4 Design Outputs) ────────────────────────────────────────────────────── REQ-001 | High-Contrast OLED Display for Readability "The display SHALL maintain a contrast ratio of at least 5:1 (per WCAG 2.0 AA) when measured at 500 lux ambient illumination per IEC 62366 photometer standards" Traced to: UN-001 (Usability in ambient light) Priority: High | Test Gate: TG-001 | Status: Approved REQ-002 | Hypoallergenic Patient Contact Materials "Patient-contacting adhesive materials SHALL be medical-grade silicone with proven biocompatibility per ISO 10993-5 (cytotoxicity) and ISO 10993-9 (sensitization)" Traced to: UN-002 (No skin irritation), UN-006 (Biocompatibility) Priority: High | Test Gate: TG-002 | Status: Approved REQ-003 | Battery Operating Life "The rechargeable lithium polymer battery SHALL provide continuous operation for at least 8 hours at 25°C ambient temperature and nominal SpO2 measurement polling rate (once per second)" Traced to: UN-003 (Battery life) Priority: Medium | Test Gate: TG-003 | Status: Approved REQ-004 | SpO2 Measurement Accuracy (Specification) "The device firmware algorithm SHALL produce SpO2 readings within ±3% absolute error when compared to laboratory CO-oximetry reference standard across SpO2 range 70–100%" Traced to: UN-004 (Measurement accuracy) Priority: High | Test Gate: TG-004 | Status: Approved REQ-005 | Wireless Transmission Compliance "The 2.4 GHz wireless transceiver SHALL emit RF power within FCC Part 15.209 limits (max −17 dBm/MHz) and demonstrate radiated immunity per IEC 61326-1 to prevent clinical equipment interference" Traced to: UN-005 (Wireless compliance) Priority: High | Test Gate: TG-005 | Status: Approved REQ-006 | Adhesive Leaching Control "Patient-contact adhesive formulation SHALL not release >5 µg/mL of leachable compounds when tested per ISO 10993-5 (3T cytotoxicity extraction, 24 hr, 37°C)" Traced to: UN-002, UN-006 (Biocompatibility, no skin irritation) Priority: High | Test Gate: TG-002 | Status: Approved

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?"

Tests Template (ISO 13485 §7.3.5 Verification & §7.3.6 Validation) ──────────────────────────────────────────────────────────────── TEST GATE TG-001: REQ-001 (Display Contrast) ───────────────────────────────────────────── T-001 | Verification | Test | Luminance Meter Laboratory Measurement "Using calibrated luminance meter and standard illumination source (500 lux, CIE D65), measure pixel luminance of white display text and black background at 10 points across active display area. Calculate local contrast ratios. Accept if all points ≥ 5:1 per IEC 62366." Evidence: Test Report TRD-001, attachments include meter calibration cert, raw data, analysis T-002 | Validation | Demonstration | Usability Study – Clinical Environment "Recruit 10 clinicians (mixed experience levels) from partner hospital. Have each read 10 simulated SpO2 values displayed on device in hospital ward lighting (measured at 500 lux). Record time-to-read and accuracy. Accept if 100% of readings correct within 5 seconds per task." Evidence: Usability Study Report USR-001, informed consent forms, raw performance data, video recordings TEST GATE TG-002: REQ-002, REQ-006 (Biocompatibility) ────────────────────────────────────────────────────── T-003 | Verification | Test | ISO 10993-5 Cytotoxicity (Accredited Lab) "Submit adhesive material samples to ISO 13485-certified biocompatibility lab (e.g., Nelson Labs). Test per ISO 10993-5 Annex E (3T direct contact, L-929 mouse fibroblast cells, 24 hr, 37°C). Accept if cytotoxicity grade ≤ Grade 1 (non-cytotoxic)." Evidence: Test Report TRD-002 (ISO 17025 accredited), material batch documentation, controls TEST GATE TG-003: REQ-003 (Battery Life) ────────────────────────────────────────── T-004 | Verification | Test | Battery Rundown Test (Controlled Environment) "Place assembled device in environmental chamber at 25°C, 45–65% humidity. Activate continuous SpO2 measurement (1 Hz polling, display on, wireless off) and log battery voltage. Record time to battery depletion (<2V). Accept if battery provides ≥8 hours continuous operation." Evidence: Test Report TRD-003, environmental chamber calibration, voltage log data (CSV), analysis T-005 | Validation | Demonstration | Field Trial – 72-Hour Continuous Wear "Enroll 5 healthy volunteers and 5 patient subjects in 72-hour continuous wear trial. Each subject wears device 24/7 with daily logging of battery status, display readability, comfort, and skin condition. Accept if devices operate ≥8 hours per charge cycle and no subject reports adverse skin reactions." Evidence: Field Trial Report FTR-001, informed consent, daily logs, end-of-study skin assessments

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.

Risks & Mitigations (ISO 13485 §7.3 + ISO 14971 Risk Management) ─────────────────────────────────────────────────────────────── RISK RSK-101: Display Unreadable in Bright Light → Misreading → Delayed Intervention ───────────────────────────────────────────────────────────────────────────────────── Hazard: Display contrast insufficient in ambient light Hazardous Situation: Clinician cannot read SpO2 value in brightly lit OR Harm: Delayed recognition of hypoxia; delayed clinical intervention; patient deterioration Probability: Likely (frequent exposure to bright OR conditions in hospitals) Severity: Critical (patient harm potential: hypoxic injury, organ damage) Risk Level (P × S): HIGH → Requires control Risk Mitigations: Control 1: Design Control (REQ-001 – High-contrast display ≥5:1) Verification: T-001 luminance meter test Validation: T-002 clinician usability study Residual Risk: LOW (high contrast proven in clinical lighting) RISK RSK-102: Skin Irritation from Adhesive Contact ─────────────────────────────────────────────────── Hazard: Adhesive leachates trigger dermatitis Hazardous Situation: Patient wears device 72 hours; skin pH and microbiota altered Harm: Itching, erythema, blistering; patient discontinues use; loss of monitoring Probability: Unlikely (with biocompatible silicone) Severity: Moderate (discomfort, treatment with topical steroid cream) Risk Level: MEDIUM Risk Mitigations: Control 1: Material Selection (REQ-002 – Medical-grade hypoallergenic silicone) Control 2: Leaching Specification (REQ-006 – ≤5 µg/mL leachables per ISO 10993-5) Verification: T-003 ISO 10993-5 cytotoxicity lab test Validation: T-005 72-hour field trial with skin assessment Residual Risk: LOW

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