Medical device regulatory frameworks—a complete guide for engineering teams

Medical device regulatory frameworks are not a compliance checklist—they are the accumulated codification of what rigorous engineering for patient safety looks like. Understanding them is not a regulatory affairs function separate from engineering. It is foundational knowledge for any engineer working in this industry, because the design decisions you make and the documentation you create are shaped by these frameworks from the first day of development.

This guide covers the major frameworks in depth—what each requires, how they interrelate, and what they mean for your development program. The frameworks do not operate in isolation. A single medical device may be subject to four, six, or eight overlapping standards and regulations simultaneously. Understanding the structure of each and how they connect is the prerequisite for building a development process that satisfies them all without duplicating effort.

FDA—21 CFR Part 820 Quality System Regulation

21 CFR Part 820 is the FDA regulation that defines quality system requirements for medical device manufacturers in the United States. It establishes the design controls framework under section 820.30—the foundation of DHF requirements, design input and output documentation, design review, verification, validation, and change control. The 2024 revision of Part 820 aligned the regulation more closely with ISO 13485:2016, reducing the documentation dissonance that manufacturers previously managed across the two systems.

Part 820 is not just a document control regulation. It is a system design regulation—it requires that your quality system itself be documented, maintained, and capable of producing evidence of compliance on demand. FDA inspectors executing a Quality System Inspection Technique (QSIT) audit are evaluating whether the system works as designed, not just whether documents exist.

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

The three primary FDA premarket pathways determine the documentation depth and evidence standard required to bring a device to market.

510(k)—Premarket Notification is the pathway for Class II devices that are substantially equivalent to a legally marketed predicate device. The substantial equivalence determination requires demonstrating that the device has the same intended use as the predicate and the same or different technological characteristics that do not raise new questions of safety and effectiveness. A 510(k) submission must include design and performance testing data, biocompatibility assessment, software documentation (IEC 62304 for software-containing devices), and a complete technical description. The DHF must demonstrate that design controls were followed—FDA reviewers do review design control documentation in 510(k) submissions, particularly for complex or software-containing devices.

PMA—Premarket Approval is the pathway for Class III devices—those that present the highest patient risk and for which substantial equivalence cannot be established. PMA requires clinical evidence of safety and effectiveness, typically from controlled clinical trials. The PMA application includes a full manufacturing section, a comprehensive design control section, and a clinical section. FDA may conduct a pre-approval inspection of manufacturing facilities. The design documentation depth required for PMA submissions exceeds 510(k) requirements at every level.

De Novo is the pathway for novel Class II devices without a legally marketed predicate. Manufacturers petition FDA to create a new classification with defined special controls. De Novo approval creates a legally marketed device that can itself serve as a predicate for future 510(k)s. Because the manufacturer is essentially writing the regulatory framework for a new device type, the design rationale documentation must be especially rigorous—you must articulate why your proposed special controls are sufficient to provide reasonable assurance of safety and effectiveness.

EU MDR—Medical Device Regulation 2017/745

The EU Medical Device Regulation replaced the Medical Device Directive in 2021 and represents a substantial increase in regulatory rigor for devices sold in the European Union. EU MDR requires a Technical File or Design Dossier (for Class III and implantables) that documents conformity with the General Safety and Performance Requirements in Annex I. The Technical File is the EU equivalent of the DHF—it must contain design and manufacturing information, clinical evaluation, risk management documentation, and post-market surveillance planning.

EU MDR introduced significant changes relative to the MDD: expanded clinical evidence requirements, a unique device identification (UDI) system, post-market clinical follow-up requirements, and a person responsible for regulatory compliance (PRRC) function. Notified bodies—the independent organizations that assess conformity for Class IIa, IIb, and III devices—apply significantly higher scrutiny under MDR than they did under the MDD.

ISO 13485:2016 certification is not mandated by EU MDR, but it is the practical standard for demonstrating QMS conformity. Most notified bodies require it as a condition of CE marking assessment. For manufacturers pursuing both FDA clearance and EU CE marking, aligning the quality system to ISO 13485 and the 2024 Part 820 revision is the most efficient path.

EU IVDR—In Vitro Diagnostic Regulation 2017/746

The EU In Vitro Diagnostic Regulation governs diagnostic devices—tests, reagents, instruments, and software used to examine specimens from the human body to provide information for diagnosis, monitoring, or treatment. EU IVDR dramatically reclassified IVDs relative to the previous IVDD framework, bringing the vast majority of diagnostics under notified body review for the first time. The IVDR classification system—Classes A, B, C, and D—is based on intended use and risk, with Class D covering the highest-risk diagnostics such as blood grouping reagents and devices for HIV detection.

For IVD manufacturers, EU IVDR requirements include performance evaluation (analogous to clinical evaluation for devices), performance studies, reference intervals documentation, and metrological traceability of values assigned to calibrators and controls. The technical documentation requirements closely parallel EU MDR but with IVD-specific content areas.

IEC 62304—Medical Device Software Lifecycle

IEC 62304 defines the software development lifecycle processes required for medical device software, organized around three safety classes (A, B, C) determined by the severity of harm that could result from a software failure. The standard covers software development planning, requirements, architecture, detailed design, unit implementation and verification, integration testing, system testing, software release, and software maintenance. SOUP (Software of Unknown Provenance) management is a significant component—every third-party dependency must be identified, evaluated for risk contribution, and tracked.

IEC 62304 is recognized by FDA and required under EU MDR and IVDR for software-containing devices. For SaMD programs, it is the foundational engineering standard. It interacts directly with ISO 14971 (risk management), IEC 62366 (usability engineering), and for AI/ML-enabled SaMD, with FDA's evolving guidance on predetermined change control plans.

IEC 60601—Medical Electrical Equipment

IEC 60601 is the family of standards governing the safety and essential performance of medical electrical equipment. IEC 60601-1 is the general standard—covering electrical safety, mechanical safety, radiation safety, and protection against unwanted outputs—and it is supplemented by a large number of part-2 standards specific to particular device types (electrosurgical equipment, infusion pumps, patient monitors, and many others). IEC 60601-1-6 addresses usability engineering (aligned with IEC 62366), and IEC 60601-1-9 covers environmentally conscious design.

For hardware medical devices, IEC 60601 compliance is a precondition for CE marking under EU MDR and is referenced as a consensus standard by FDA. Testing to IEC 60601 is typically performed by accredited test laboratories, and the test reports are submission artifacts that belong in the DHF and Technical File.

ISO 14971—Risk Management for Medical Devices

ISO 14971 is the international standard for risk management for medical devices. It is arguably the most foundational standard in the medical device regulatory framework because every other framework builds on or references it. Risk identification, risk estimation, risk evaluation, risk control, residual risk evaluation, and benefit-risk analysis are the core processes. The standard requires a risk management file that documents the entire risk management process for the device's lifetime—from concept through post-market surveillance.

ISO 14971 interacts with IEC 62304 (software risk classification), IEC 62366 (usability-related risk), IEC 60601 (essential performance), and EU MDR/IVDR (Annex I General Safety and Performance Requirements). Risk controls identified in ISO 14971 must cascade through design decisions, verification testing, and quality system records. In a fragmented development environment, maintaining that cascade manually across separate risk, engineering, and quality systems is one of the most significant sources of regulatory exposure.

ISO 13485—Quality Management Systems for Medical Devices

ISO 13485:2016 specifies requirements for a quality management system specific to the medical device industry. It is the quality system standard that underpins regulatory frameworks globally—required for EU CE marking, recognized by FDA through the Part 820 alignment, and accepted by regulators in Canada, Australia, Japan, Brazil, and most other major markets. ISO 13485 covers management responsibility, resource management, product realization (including design and development controls), and measurement and improvement.

MANKAIND is built to understand this full regulatory landscape. The platform's engineering intelligence is grounded in the specific requirements of each framework—not as a documentation layer applied after engineering decisions are made, but as the context within which engineering decisions are structured from the beginning. When your development process operates inside a platform that understands these frameworks at the data model level, the documentation they require is not a burden to be managed—it is a natural output of the engineering work itself.