Design-Cycle Layer

3. Design-Cycle Layer

3.1 Technical File (hardware)

What this module is, in one paragraph. The Technical File is the MDR Annex II dossier root — the structured set of documents demonstrating that a device meets the General Safety and Performance Requirements (Annex I), describes its design, manufacturing, intended use, and clinical evaluation. FDA 21 CFR 820.30 (Design Controls) demands the same evidence reorganised as a Design History File (§820.30(j) DHF), Device Master Record (§820.181 DMR), and Device History Record (§820.184 DHR). ISO 13485:2016 §7.3 (Design and Development) structures the lifecycle from planning (§7.3.2) through review (§7.3.4), verification (§7.3.6), validation (§7.3.7), transfer (§7.3.8), and changes (§7.3.9). Wrapper’s TF module is the dossier-root: hierarchical sections per regulatory framework, AI-classified document attachments, regulatory-framework tagging (MDR / FDA QMSR / ISO 13485 / EU AI Act / UKCA), device-class tagging (I / IIa / IIb / III / Implant), per-section completeness status, gap analysis against the applicable framework checklist. The standard hardware tab set covers Use Case → Requirements → Risk → Design Input → Design Output → a configurable series of Test tabs.

Regulatory pathway summary. Supports CE marking under MDR Annex II §1-8 (TF compilation) + Annex III (post-market TF) + Annex IX/X/XI NB routes; FDA design-controls evidence under 21 CFR 820.30(c)-(j) including DHF; FDA Device Master Record §820.181 + Device History Record §820.184; ISO 13485:2016 §7.3.1-9; MDSAP TF chapter (Chapter 2); UK MDR 2002 Part II §7A.

Regulatory Specificity

Table 1 — Which regulation applies in which case

Table 2 — Regulatory problem solved

Table 3 — Conformity-assessment pathway impact

Why these regulations are non-negotiable. Without a current and complete TF satisfying MDR Annex II §1-8 (Device description, IFU, Design and manufacturing, GSPR conformity, Benefit-risk, V&V, Specific aspects, plus Annex III post-market), CE certificate issuance is blocked at NB Annex II review — typical delay 4–8 weeks per re-submission cycle. FDA 21 CFR 820.30 is one of the four most-cited design-controls subparts in Form-483 observations; deficient DHF compilation routinely surfaces in Warning Letters.

Who uses this module and when. RA Lead and PRRC daily during development and submission cycles. Engineering daily for section updates. QMS Manager for §7.3.4 design review evidence. NB Auditor opens it at every audit — typically the first screen they request.

3.2 SaMD Technical File

What this module is, in one paragraph. Software as a Medical Device (SaMD) — software intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device — requires evidence the hardware TF cannot represent. MDR Annex II still applies, but the content of each section shifts: "Design Output" is no longer a mechanical drawing but a frozen software release; "Design Input" includes the AI training dataset specification; risk includes drift, bias, and automation-bias. FDA’s SaMD framework + Clinical Decision Support guidance + PCCP final guidance + GMLP principles layer onto MDR; IEC 62304:2006+A1:2015 (Software Lifecycle) + IEC 81001-5-1:2021 (Health-Software Cybersecurity) + ISO 14971:2019 (Risk Management) specify the lifecycle and risk processes; EU AI Act Reg. 2024/1689 Annex IV specifies the AI technical documentation structure. Wrapper’s SaMD TF is a sibling of the hardware TF with 15 software-shaped tabs replacing the hardware tab set: Intended Use & Claims, Software Requirements, Architecture / SOUP / Interfaces, Algorithm / Model Registry, Dataset & Ground Truth, Risk Management, Cybersecurity, Verification, Clinical Validation, Usability / Human-AI Team, Labeling / Transparency, Release & Configuration, PCCP / AI Change Control, Post-Market AI Performance, Regulatory Submissions. Each tab carries citations to MDR Annex II, FDA SaMD/CDS/PCCP, IEC 62304, IEC 81001-5-1, ISO 14971, and EU AI Act Annex IV — so a single SaMD TF entry presents itself in five regulator lenses without duplicate evidence.

Regulatory pathway summary. Supports MDR Annex II adapted for SaMD; FDA SaMD final guidance (2017) + Clinical Decision Support guidance (2022) + PCCP final guidance (2024) + GMLP joint principles (FDA/Health-Canada/MHRA); IEC 62304:2006+A1:2015 software lifecycle (§5 development + §6 maintenance + §7 risk + §8 configuration + §9 problem resolution); IEC 81001-5-1:2021 health-software cybersecurity activities; ISO 14971:2019 (software risk integration); EU AI Act Reg. 2024/1689 Annex IV technical documentation; IMDRF/SaMD/N12 risk categorisation.

Regulatory Specificity

Table 1 — Which regulation applies in which case

Table 2 — Regulatory problem solved

Table 3 — Conformity-assessment pathway impact

Why these regulations are non-negotiable. Under EU AI Act Art. 11 + Annex IV, AI-enabled high-risk medical devices must carry Annex IV technical documentation before placing on the market after 2 August 2026 — without it, the device is unmarketable. FDA SaMD evidence is required at premarket review; without PCCP, every iterative AI update triggers a new submission cycle. IEC 62304 is mandatory for any SaMD intended for CE marking — without IEC 62304 §5 + §6 evidence, the NB cannot accept the TF.

Who uses this module and when. SaMD Engineering Lead daily during development. AI/ML Lead daily for Model Registry and Dataset tabs. Cybersecurity Officer for Cybersecurity tab. RA Lead at submission planning and during the §7.3 design review cycle. FDA reviewer at premarket review and post-market PCCP audits. NB Auditor at SaMD-aware CE audit and surveillance.

3.3 Master Technical File (MTF) Log

What this module is, in one paragraph. An MTF — Master Technical File — is the set of static documents that surround the live design matrix (use-cases, requirements, risks, verification tests). The MTF holds Plans (Design Plan, Risk-Management Plan, Clinical-Evaluation Plan, PMS Plan, PMCF Plan), the GSPR checklist (MDR Annex I — one row per requirement with justification, evidence document, harmonised-standard citation), the standards list, NB Certificates, the Declaration of Conformity, the IFU master, the regulatory strategy, the PRRC appointment letter (MDR Art. 15), the company-level ISO 13485 + MDSAP certificates, plus the SOPs and policies that the TF references. MDR Annex II demands all of these and CE marking is blocked until they are present, approved, and current. The MTF Log replaces folder-and-spreadsheet tracking with a structured, auditable, dashboard-driven log where every artefact has status, owner, expiry date, and a link to the device(s) it covers (by UDI).

Regulatory pathway summary. Supports CE marking under MDR Annex II + Annex III, NB conformity assessment routes Annex IX/X/XI; FDA design-controls evidence under 21 CFR 820.30 (QMSR effective 2 Feb 2026); ISO 13485:2016 §7.3 / §7.3.10; MDSAP TF chapter; UKCA under UK MDR 2002 Part II; EU AI Act Annex IV.

Regulatory Specificity

Table 1 — Which regulation applies in which case

Table 2 — Regulatory problem solved

Table 3 — Conformity-assessment pathway impact

Why these regulations are non-negotiable. Without a current, signed Risk-Management Report aligned to ISO 14971:2019 and a GSPR row for every applicable requirement of MDR Annex I, a Notified Body cannot close Annex II §5 / §6 dossier review — CE certificate issuance is paused. An expired NB certificate (5-year cap, MDR Annex VII §4.8) removes the device from the EU market by operation of law (MDR Art. 56(4)); there is no grace period.

Who uses this module and when. The PRRC and RA Lead daily. The QMS Manager dashboard weekly. Internal Auditors during pre-surveillance dry-runs. NB Auditors open it directly at surveillance audit or unannounced visit.

3.4 UDI Registry

What this module is, in one paragraph. Every medical device placed on the EU or US market must carry a Unique Device Identifier (UDI) — a globally unique identifier resolved through an issuing agency (GS1, HIBCC, ICCBBA, IFA). MDR Art. 27 + Art. 29 + Annex VI Part C require manufacturers to assign and register both a Basic UDI-DI (the device-group identifier) and a UDI-DI (the device-variant identifier) to every device, and to register them in EUDAMED. FDA UDI Rule (21 CFR 830) imposes the equivalent in the US (GUDID database). The UDI is the cross-module key by which a regulator says "show me everything about this device" and gets a coherent answer — vigilance events, supplier components, design records, clinical evaluations, training assignments all join by UDI.

Regulatory pathway summary. Supports MDR Art. 27 (UDI system) + Art. 29 (registration of devices) + Annex VI Part C (UDI system details); FDA 21 CFR 830 (UDI Rule); IMDRF/UDI WG/N7 (UDI guidance); EUDAMED UDI/Devices module (mandatory 28 May 2026); GS1 / HIBCC / ICCBBA / IFA issuing-agency rules.

Regulatory Specificity

Table 1 — Which regulation applies in which case

Table 2 — Regulatory problem solved

Table 3 — Conformity-assessment pathway impact

Why these regulations are non-negotiable. EUDAMED UDI/Devices is mandatory 28 May 2026 — without a registered Basic UDI-DI and UDI-DI per variant, the device cannot be placed on the EU market after that date. 21 CFR 830 enforced by FDA at GUDID; missing UDI is a refusal-to-accept finding at premarket review.

Who uses this module and when. RA Lead at every device launch and every variant. PRRC at every EUDAMED submission. QA at every labelling revision. Vigilance team at every incident logging.

3.5 Traceability Matrix (TFM)

What this module is, in one paragraph. A Traceability Matrix is the live grid linking Requirements ↔ Risks ↔ Design Inputs ↔ Design Outputs ↔ Tests ↔ Verification records — the single artefact every Notified Body asks to see first because it answers, in one screen, whether the entire design is internally consistent. MDR Annex II §6 (V&V) demands this traceability; FDA 21 CFR 820.30(f) (design verification) + §820.30(g) (design validation) demand the same in FDA jurisdiction; ISO 13485:2016 §7.3.6 + §7.3.7 specify the lifecycle activities; ISO 14971 §6 demands that every risk control is verified; IEC 62304 §5.6 + §5.7 demand the equivalent for software V&V and software risk control. Wrapper’s Matrix is a configurable grid where admins build column sets per regulatory framework, cells link to entities, revisions track per cell, locks prevent uncontrolled edits, and revisions are approval-bound (the Matrix is one of the seven polymorphic ObjectApproval object types).

Regulatory pathway summary. Supports MDR Annex II §6 (V&V traceability); FDA 21 CFR 820.30(f) (design verification) + §820.30(g) (design validation) + §820.30(e) (design review); ISO 13485:2016 §7.3.6 (verification) + §7.3.7 (validation); ISO 14971 §6 (risk-control implementation) + §7 (risk-control verification); IEC 62304 §5.6 + §5.7 (software V&V and risk).

Regulatory Specificity

Table 1 — Which regulation applies in which case

Table 2 — Regulatory problem solved

Table 3 — Conformity-assessment pathway impact

Why these regulations are non-negotiable. V&V traceability is the #1 finding at NB Annex II audits — a Matrix that does not show every Risk Control linked to a Verification record fails ISO 14971 §7.1. FDA 21 CFR 820.30(g) (design validation) is one of the top-five design-controls Form-483 observations year-on-year.

Who uses this module and when. Engineering lead daily during development. RA Lead at every design review (§7.3.4). Risk owner at every risk-control update. NB Auditor at every TF assessment.

3.6 Risk Management (ISO 14971)

What this module is, in one paragraph. ISO 14971:2019 defines the Risk Management Process for medical devices: hazard identification (§5) → risk analysis (§5.4) → risk evaluation (§5.5) → risk-control option analysis (§6.2) → risk-control implementation (§6.3) → residual risk evaluation (§7) → risk-benefit analysis (§8) → risk-management report (§9). MDR Annex I §3 requires risk-management throughout the device lifecycle and MDR Annex II §5 requires the risk-management file in the TF. FDA 21 CFR 820.30(g) requires risk analysis as part of design validation. IEC 62304 §5.7 integrates software risk into the lifecycle. EU AI Act Art. 9 requires an AI Risk Management System for high-risk AI. Wrapper’s Risk module carries the full ISO 14971 chain: hazard log → evaluation (severity × probability) → control → benefit-risk → control-verification, each chain element revision-locked, approval-bound, and linkable to the Traceability Matrix and Verification tests. A separate RiskDiscussion AI assistant helps SMEs identify and refine hazards conversationally without ever auto-mutating the risk file (HITL by design).

Regulatory pathway summary. Supports ISO 14971:2019 §3-§10 (risk-management process); MDR Annex I §3 + §4 (general safety) + Annex II §5 (risk-management file); FDA 21 CFR 820.30(g) (design validation including risk analysis); IEC 62304 §5.7 (software risk in V&V) + §7 (software risk management); EU AI Act Art. 9 (AI risk management system); ISO/IEC 23894:2023 (AI risk management); ISO/TR 24971:2020 (guidance on ISO 14971).

Regulatory Specificity

Table 1 — Which regulation applies in which case

Table 2 — Regulatory problem solved

Table 3 — Conformity-assessment pathway impact

Why these regulations are non-negotiable. Risk-control verification gaps (ISO 14971 §7.1) are among the top-three risk-management findings at every NB audit. Under MDR Annex I §1, a device is not safe within the meaning of MDR if its risks have not been reduced as far as possible — without a complete RMF, the CE certificate cannot be issued.

Who uses this module and when. Risk owner daily during development. RA Lead at every §7.3.4 design review. PRRC at every risk-management report sign-off. NB Auditor at every TF audit — a frequent first-screen request.

3.7 Training

What this module is, in one paragraph. ISO 13485:2016 §6.2 (Human Resources) requires the manufacturer to determine the necessary competence for personnel performing work affecting product quality, provide training or take other actions to achieve the necessary competence, evaluate the effectiveness of the actions taken, maintain appropriate records of education, training, skills, and experience. FDA 21 CFR 820.25 (Personnel) imposes the equivalent. MDR Annex IX §2.2 specifies that the NB audits personnel competence. MDSAP Chapter 3 specifies the training-records inspection criteria. Wrapper’s Training module is the production-grade implementation: training assignments per person, role/group matrices (Person × Document, Group × Document, etc.), retraining schedules, competence evidence, plus 8 AI sentinels firing on regulated triggers (approval of a SOP revision, new role assignment, CAPA escalation, scheduled effectiveness scan, scheduled recertification-risk scan, etc.) that produce structured retraining findings in the AI Findings inbox — the QMS Manager approves which trainees need retraining; the system fans assignments out automatically. Acknowledgement of training-change is PIN-signed under Part 11.

Regulatory pathway summary. Supports ISO 13485:2016 §6.2 (competence + training); FDA 21 CFR 820.25 (personnel) + §820.20(b)(3) (organisation responsibility); MDR Annex IX §2.2 (NB audit of personnel); MDSAP Chapter 3 (Training); EU AI Act Art. 14 (HITL via PIN-signed acknowledge).

Regulatory Specificity

Table 1 — Which regulation applies in which case

Table 2 — Regulatory problem solved

Table 3 — Conformity-assessment pathway impact

Why these regulations are non-negotiable. ISO 13485 §6.2 is one of the most-audited clauses at every NB surveillance — particularly the effectiveness evaluation sub-clause (§6.2(c)), which is one of the top-five ISO 13485 stage-2 findings. FDA 21 CFR 820.25 is among the top-ten Form-483 citations in design-controls inspections.

Who uses this module and when. Trainees see assignments in /todo. QA drives matrix view daily. Auditors drive audit-log view. HR + QMS Manager at every role change. NB Auditor at every surveillance audit.