Medical device regulatory frameworks — how they actually interlock, and where the seams fail

The regulatory frameworks don't operate in isolation, and most of the serious compliance problems originate at the interfaces between them, not inside any single one.

A Class II connected insulin pump in the US and EU markets is subject to: FDA 21 CFR Part 820 (quality system), 21 CFR Part 803 (MDR reporting), the 2023 Section 524B cybersecurity requirements, IEC 62304 (software lifecycle), ISO 14971 (risk management), IEC 60601-1 plus applicable collaterals (electrical safety and EMC), IEC 62366-1 (usability), ISO 10993 (biocompatibility if there's patient contact), EU MDR 2017/745, ISO 13485:2016 (quality management), plus the EU AI Act if there's an AI component. That's eleven frameworks. They're not independent.

This guide walks through the major ones and the interactions that actually drive submission and audit outcomes.

FDA 21 CFR Part 820 — the base layer for US market

Part 820 is the FDA Quality System Regulation. Section 820.30 — design controls — is where most engineering teams spend their regulatory energy. The 2024 revision aligned Part 820 substantially with ISO 13485:2016, reducing the dissonance between US and international quality system requirements. Didn't eliminate it entirely.

Part 820 is inspected through QSIT (Quality System Inspection Technique). Inspectors pull threads across modules — complaint to CAPA to design change to risk update. The frequency of 483 observations in the design controls category (820.30), production and process controls (820.70), and CAPA (820.100) tells you where inspection time concentrates.

FDA premarket pathways — 510(k), PMA, De Novo

510(k) Premarket Notification is for Class II devices substantially equivalent to a predicate. No clinical trials in most cases. The 510(k) still requires a complete DHF, performance testing, biocompatibility assessment, IEC 62304 package for software-containing devices. The predicate comparison is where most submissions live or die.

PMA Premarket Approval is for Class III devices. Clinical evidence is required. The documentation depth makes 510(k) look light. Reviewers examine design decisions at the unit level. FDA may conduct a pre-approval inspection.

De Novo is for novel low-to-moderate-risk devices without a predicate. You propose the classification and the special controls. De Novo clearances become predicates for future 510(k)s, which is why De Novo sponsors often find themselves writing regulatory framework for an entire device class.

EU MDR 2017/745 — the notified body reality

EU MDR replaced the MDD in 2021 and represents a material increase in regulatory rigor. The Technical File (or Design Dossier for Class III and implantables) documents conformity with the General Safety and Performance Requirements in Annex I. Think of the Technical File as the EU equivalent of the DHF, with substantial overlap plus EU-specific elements.

EU MDR introduced expanded clinical evidence requirements, unique device identification (UDI), post-market clinical follow-up, and the Person Responsible for Regulatory Compliance (PRRC). Notified body capacity has been the operational bottleneck since MDR's effective date — backlogs extending submission timelines beyond what regulations alone would suggest.

ISO 13485:2016 isn't explicitly mandated by MDR, but it's the practical QMS standard notified bodies audit against. For dual-market manufacturers, aligning to ISO 13485 and the 2024 Part 820 revision covers most ground with one QMS implementation.

EU IVDR 2017/746 — reclassification nobody was ready for

EU IVDR governs in vitro diagnostics. The reclassification from IVDD to IVDR brought the majority of diagnostics under notified body review for the first time. Class A, B, C, D based on intended use and risk, with Class D covering the highest-risk diagnostics (HIV detection, blood grouping reagents). For IVD manufacturers the transition has been painful — performance evaluation, performance studies, metrological traceability, and technical documentation requirements are more demanding than IVDD ever required.

IEC 62304 — software lifecycle

Software lifecycle processes for medical device software, organised around three safety classes determined by the harm severity a software failure could contribute to. Class A (no/negligible), B (non-serious), C (serious/death). FDA recognises IEC 62304 as a consensus standard. EU MDR and IVDR require it for software-containing devices.

The interaction with ISO 14971 is direct — safety classification comes out of the risk analysis. The interaction with IEC 62366 is through usability-related hazards that flow through both. The interaction with Section 524B is through cybersecurity controls that have to appear in the software requirements.

IEC 60601 — medical electrical equipment

Family of standards for medical electrical equipment safety. IEC 60601-1 is the general standard (Edition 3.2 consolidated 2020). Collateral standards address cross-cutting requirements — electromagnetic compatibility (1-2, Edition 4.1 raised immunity substantially), usability (1-6, aligned with IEC 62366), alarms (1-8), environmentally conscious design (1-9), home healthcare (1-11), emergency medical services (1-12). Particular standards (60601-2-x and the 80601-2-x family that migrated out) cover specific device types.

For hardware medical equipment, IEC 60601 is where design verification testing actually happens — at accredited test laboratories running against specific editions recognised by the target market.

ISO 14971 — the substrate

Risk management for medical devices. Hazard identification, risk estimation, risk evaluation, risk control, residual risk, benefit-risk analysis, post-production monitoring. The risk management file is a living document throughout the device lifecycle.

ISO 14971 is the substrate every other framework builds on. IEC 62304 software classification comes from the 14971 file. IEC 62366 hazard-related use scenarios come from the 14971 file. IEC 60601 essential performance definitions come from the 14971 file. EU MDR Annex I requires ISO 14971 conformance as part of Annex II technical documentation. Every framework refers back to 14971, which is why inconsistencies in the risk file propagate into inconsistencies across every other framework's documentation.

ISO 13485:2016 — the QMS anchor

QMS requirements specific to medical devices. Required for EU CE marking, the base of MDSAP, accepted by most major regulators globally. Covers management responsibility, resources, product realisation (including design and development controls), measurement and improvement.

For manufacturers in multiple markets, ISO 13485 is the consolidating standard. Implementing to ISO 13485 and adding market-specific requirements on top is more efficient than implementing each market's requirements independently.

IEC 62366-1 — usability

Usability engineering process. Use specification, user interface specification, use scenarios, hazard-related use scenarios, formative and summative evaluation, the Usability Engineering File. The 2015 edition with A1:2020 tightened the link to ISO 14971 through hazard-related use scenarios. FDA recognises it; EU MDR requires it.

ISO 10993 — biocompatibility

Biological evaluation of medical devices. Multi-part series. 10993-1:2018 is the planning framework. 10993-18:2020 covers chemical characterisation. 10993-17:2023 is the toxicological risk assessment standard that FDA has only partially recognised, creating the bifurcation dual-submission programs currently navigate.

The EU AI Act — the newer overlay

Full enforcement begins August 2026. Most AI-embedded medical devices will be high-risk under both EU MDR and the EU AI Act simultaneously. Dual conformity means Annex IV documentation under the AI Act in addition to Annex II/III documentation under MDR. The overlap is substantial; the non-overlap includes AI Act-specific elements like fundamental rights impact assessment, algorithmic transparency obligations, and post-market monitoring of automated systems.

Section 524B — cybersecurity as a submission requirement

Effective October 2023. Cyber devices — any device with software and internet connectivity — must include cybersecurity content in submissions: post-market vulnerability management plan, update and patch processes, SBOM. FDA uses Refuse to Accept for submissions missing required cybersecurity content. This isn't guidance; it's statute.

Where the frameworks actually fail together

Most serious compliance problems aren't about failing a single framework. They're about records that disagree across frameworks. The risk control wording in the 14971 file doesn't match the software requirement wording in the IEC 62304 documentation. The use scenario list in the UEF doesn't align with the hazards in the risk file. The SBOM format in the Section 524B submission doesn't match the SOUP inventory in the IEC 62304 package. The Technical File for EU MDR references a clinical evaluation that tests a slightly different intended use than the US 510(k).

Each inconsistency is a finding. Each finding delays a submission or generates an audit nonconformity. None of them are caught by reading any single framework in isolation — they're caught by reading across. Reviewers and auditors read across. Every time.

Why this matters for platform choice

A documentation platform that treats each framework as a separate artefact will accumulate drift across frameworks. The only way to avoid cross-framework drift is to maintain the underlying engineering record as the single source of truth and render each framework's required documentation as a view into that record.

MANKAIND is built around that premise. The risk file, the software requirements, the usability file, the DHF, the Technical File, the SBOM — all views into the same engineering record. Inconsistencies can't develop because the underlying data is shared. When the risk analysis updates, every framework's view updates with it. That's the architectural answer to the cross-framework drift problem, and it's why submissions produced from integrated platforms generate substantially fewer AI requests than submissions produced from fragmented documentation environments.

Frequently asked questions about medical device regulatory frameworks

What are the main medical device regulatory frameworks?

The main frameworks are FDA 21 CFR Part 820 (US quality system), EU MDR 2017/745, EU IVDR 2017/746, ISO 13485:2016 (quality management), ISO 14971 (risk management), IEC 62304 (software lifecycle), IEC 60601 (medical electrical equipment), and IEC 62366 (usability engineering).

What is the difference between 21 CFR 820 and EU MDR?

21 CFR Part 820 is the US FDA quality system regulation focused on US market access; EU MDR is the European medical device regulation required for CE marking. The 2024 revision of Part 820 aligned more closely with ISO 13485:2016. EU MDR adds notified body oversight, UDI, and significantly expanded clinical evidence requirements compared to the previous MDD.

Which frameworks apply to software as a medical device (SaMD)?

IEC 62304 is the foundational software lifecycle standard. ISO 14971 covers risk management including software safety classification. IEC 62366 applies when there is a user interface. FDA recognises all three; EU MDR and IVDR require IEC 62304 conformance for software-containing devices.

Is ISO 13485 certification required for FDA 510(k)?

No, ISO 13485 is not mandatory for a 510(k), but FDA's 21 CFR Part 820 quality system regulation is. The 2024 Part 820 revision aligned closely with ISO 13485:2016, so manufacturers pursuing both US and EU markets typically implement to ISO 13485 and meet Part 820 as a consequence.