> ## Documentation Index
> Fetch the complete documentation index at: https://docs.withdovetail.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> Comprehensive introduction into the world of medical device regulatory requirements.

## Overview

Medical device software operates within a **complex regulatory landscape** designed to ensure patient safety and device effectiveness. Understanding these requirements early in your development process is essential for bringing compliant devices to market efficiently and maintaining regulatory approval throughout the product lifecycle.

This guide provides a comprehensive overview of the regulatory framework governing software medical devices across major markets including the **European Union (EU MDR)**, **United States (FDA)**.

This guides strucuture is directly based on the **FormlyAI** Roadmap, and offers a more detailed description of the regulatory requirements for each task on the roadmap, as well as examples for the finished documents.

The actual amout and scope of tasks can differ for each user as they are based directly on the applied regulations. Things like region, device characteristics and device class all influence the regulatory requirements.

Each Roadmap is individually tailored to you device characteristics and the subsequent regulatory requirements. With the completion of the Roadmap, you will have a complete set of documents that fullfill your specific set of requirements.

## Key Regulatory Frameworks

<Tabs>
  <Tab title="US FDA">
    The **US Food and Drug Administration (FDA)** regulates medical devices under Title 21 of the Code of Federal Regulations. The FDA uses a risk-based classification system (Class I, II, III) with various regulatory pathways including 510(k) clearance, De Novo classification, and Premarket Approval (PMA). The agency emphasizes quality systems, clinical data, and cybersecurity for software devices.

    Subject to the applicable product characteristics and product risk class, the following standards will be supported:

    * **21 CFR Part 820** – Quality System Regulation (QSR)
    * **21 CFR Part 807** – Establishment Registration and Device Listing
    * **21 CFR Part 801** – Labeling Requirements
    * **21 CFR Part 11** – Electronic Records and Electronic Signatures (where applicable)
    * **21 CFR Part 812** – Investigational Device Exemptions
    * **21 CFR Part 814** – Premarket Approval
    * **ISO 14971** – Application of Risk Management to Medical Devices
    * **IEC 62304** – Medical Device Software – Software Lifecycle Processes
    * **IEC 60601 series** – Safety and Essential Performance of Medical Electrical Equipment
    * **IEC 62366** – Application of Usability Engineering
    * **ISO 10993 series** – Biological Evaluation of Medical Devices

    <Note>
      **Software-specific considerations**: FDA categorizes Software as Medical Device (SaMD) based on healthcare situation and state of healthcare decision.
    </Note>
  </Tab>

  <Tab title="EU MDR">
    The **Medical Device Regulation (MDR) 2017/745** governs medical devices in the European Union. This regulation applies to devices intended for medical purposes including diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease. It emphasizes clinical evidence, post-market surveillance, and enhanced transparency requirements.

    Subject to the applicable product characteristics and product risk class, the following standards will be supported:

    * **General Safety and Performance Requirements (GSPR)** – Annex I, MDR 2017/745
    * **ISO 13485** – Quality Management Systems – Requirements for regulatory purposes
    * **ISO 14971** – Application of Risk Management to Medical Devices
    * **IEC 62304** – Medical Device Software – Software Lifecycle Processes
    * **IEC 60601 series** – Safety and Essential Performance of Medical Electrical Equipment
    * **IEC 62366** – Application of Usability Engineering
    * **ISO 10993 series** – Biological Evaluation of Medical Devices
    * **EN ISO 14155** – Clinical Investigation of Medical Devices
    * **MEDDEV 2.7/1 rev. 4** – Clinical Evaluation: A Guide for Manufacturers

    <Note>
      **Software-specific considerations**: Software is classified as a medical device if it has a medical purpose. Classification depends on the healthcare decision it informs or enables.
    </Note>
  </Tab>

  <Tab title="EU IVDR">
    The **In Vitro Diagnostic Regulation (IVDR) 2017/746** governs in vitro diagnostic medical devices in the European Union. This regulation applies to devices intended to examine specimens from the human body to provide diagnostic, screening, or monitoring information. It introduces stricter requirements for clinical evidence and performance evaluation of IVDs.

    Subject to the applicable product characteristics and product risk class, the following standards will be supported:

    * **General Safety and Performance Requirements (GSPR)** – Annex I, IVDR 2017/746
    * **ISO 13485:2016** – Quality Management Systems
    * **ISO 14971** – Risk Management for Medical Devices
    * **ISO 18113 series** – Labelling and Instructions for Use of IVDs
    * **ISO 15189:2022** – Medical Laboratories – Quality and Competence
    * **CLSI Guidelines** – Various clinical and performance validation standards
    * **ISO 20916** – Clinical Performance Studies for IVDs
    * **ISO 17511** – Metrological Traceability of Values Assigned to Calibrators and Control Materials

    <Note>
      **IVD-specific considerations**: IVD software classification depends on the risk class of the IVD device and the healthcare decision it enables or influences.
    </Note>
  </Tab>
</Tabs>

<Tip>
  **Stay Current**: Subscribe to regulatory authority guidance documents and participate in industry associations to stay ahead of evolving requirements.
</Tip>

## Common Compliance Challenges

Medical device software development presents unique regulatory challenges that can delay market entry or compromise compliance. Understanding these challenges helps you prepare effectively.

### Documentation and Process Challenges

**Documentation Burden**: Regulatory compliance generates extensive documentation across all development phases. Many organizations underestimate the volume and interconnectedness of required documents.

Key challenges:

* Managing complex document relationships and dependencies
* Maintaining document consistency throughout the lifecycle
* Ensuring all documents remain current and synchronized
* Establishing efficient review and approval processes

**Traceability Gaps**: Missing traceability links can halt regulatory submissions entirely. Requirements, risks, design elements, tests, and clinical evidence must be traceable throughout the device lifecycle.

Critical areas:

* User needs to system requirements linkage
* Risk analysis to mitigation measures mapping
* Design specifications to verification results connection
* Clinical evidence to safety and effectiveness claims

**Change Control Complexity**: All changes must be controlled and assessed for regulatory impact. Companies often struggle with change classification and impact assessment.

Common issues:

* Determining when changes require regulatory notification
* Assessing cascading effects of software updates
* Managing change documentation and approvals
* Balancing agility with regulatory requirements

### Technical and Development Challenges

**Software Lifecycle Management**: IEC 62304 compliance requires extensive documentation that may not align naturally with agile development practices.

Key considerations:

* Adapting agile workflows to accommodate regulatory checkpoints
* Documenting software architecture and detailed design
* Managing iterative development within regulatory frameworks
* Balancing development speed with compliance requirements

**Clinical Evidence Requirements**: Demonstrating clinical safety and effectiveness is challenging, especially for novel AI/ML applications.

Planning essentials:

* Early clinical strategy development
* Multi-source evidence consideration (literature, real-world data)
* Jurisdiction-specific clinical data requirements
* Novel validation approaches for AI/ML devices

**Verification and Validation Scope**: Determining appropriate V\&V activities for software devices requires balancing thoroughness with efficiency.

Critical factors:

* Risk-based testing strategy development
* Representative test data selection
* AI/ML algorithm validation approaches
* Performance validation across intended use conditions

### Organizational and Resource Challenges

**Regulatory Expertise Gaps**: Software companies often lack in-house regulatory knowledge, leading to inefficient compliance approaches.

Impact areas:

* Misunderstanding of regulatory requirements
* Over-engineering or under-engineering solutions
* Poor regulatory pathway decisions
* Inadequate compliance planning

**Multi-Jurisdictional Complexity**: Global market access requires managing different regulatory requirements across jurisdictions.

Key challenges:

* Varying classification and clinical evidence requirements
* Different submission timelines and processes
* Evolving regulations across markets
* Resource allocation across multiple regulatory tracks

**Resource Allocation**: Regulatory activities consume substantial time, personnel, and financial resources that are often underestimated.

Planning considerations:

* Quality management system implementation costs
* Clinical study investments
* Regulatory submission expenses
* Ongoing compliance maintenance resources

### Post-Market and Ongoing Challenges

**Post-Market Surveillance**: Software devices require specialized monitoring systems for real-world evidence collection and incident management.

Essential elements:

* Real-world performance monitoring
* User experience data collection
* Incident trend analysis and reporting
* Clinical significance assessment of software-related events

**Cybersecurity Evolution**: Rapidly evolving cybersecurity requirements demand adaptive security approaches throughout the device lifecycle.

Ongoing requirements:

* Continuous threat landscape monitoring
* Security update management processes
* Balance between security and usability
* Regulatory compliance with evolving cybersecurity guidance

**Quality Management System Integration**: Implementing ISO 13485 in software environments requires adapting traditional manufacturing QMS concepts.

Adaptation areas:

* Document control for software development
* Design controls in agile environments
* Supplier management for software components
* Corrective action processes for software issues