Medical device software compliance in the EU and US
Medical software is not regulated only by its code. Its regulatory status depends on intended purpose, clinical role, risks, evidence and the way the software is developed and maintained. MDRC helps companies define the regulatory pathway and build the documentation and processes required for market access.
Is your software a medical device?
Not every healthcare software product is regulated as a medical device. The regulatory status depends on the intended purpose, functions performed, clinical role and the impact of software outputs on healthcare decisions.
Medical device software
Software may be regulated as a medical device when it performs a medical purpose or provides information used for diagnosis, prevention, monitoring, prediction or treatment decisions.
- Clinical decision support systems
- Diagnostic algorithms
- AI-based image or signal analysis
- Patient monitoring software
- Software influencing clinical decisions
Software outside MDR and IVDR
Not all healthcare-related software is a medical device. Applications without a medical intended purpose may fall outside MDR or IVDR requirements.
- Administrative healthcare systems
- Electronic documentation tools
- Scheduling and workflow software
- General wellness applications
- Communication and data management tools
The intended purpose, not the technology itself, determines the regulatory status.
Key regulatory questions
Before selecting a regulatory pathway, companies should define:
- What is the intended purpose?
- Who is the intended user?
- Does the software influence clinical decisions?
- What risks can result from incorrect outputs?
- What evidence is required?
- Which regulatory pathway applies?
Classification determines the regulatory pathway
Medical software classification is one of the first regulatory decisions a company must make. It determines the level of regulatory control, evidence requirements, documentation scope and the pathway to market access.
For software, classification depends not only on the technology itself, but on the intended purpose, clinical role and impact of the software outputs.
Medical software
Intended purpose and clinical function
What is the intended purpose?
What healthcare function does the software perform? Who uses it and how are outputs applied?
No medical purpose
Software may fall outside medical device regulation, depending on its function and claims.
Medical purpose
Further assessment of clinical role, risks and regulatory requirements is required.
MDR / IVDR classification
Regulatory pathway, evidence requirements and conformity assessment route
Intended purpose
The intended purpose defines whether software is considered a medical device and establishes the foundation for classification.
- Healthcare task performed
- Intended users
- Clinical context
- Software claims
Clinical impact and risk
Classification depends on how software outputs influence healthcare decisions and the potential consequences of incorrect results.
- Diagnosis support
- Treatment recommendations
- Patient monitoring
- Risk of harm
Regulatory consequence
The classification determines the documentation, evidence and quality requirements needed for market access.
- Technical documentation
- Risk management
- Clinical evidence
- Notified Body involvement
Regulatory framework for medical software
Medical software compliance is not defined by a single standard. Successful market access requires alignment between regulatory requirements, software development processes, risk controls, clinical evidence and quality management.
MDRC helps companies connect these elements into one coherent regulatory strategy from early development decisions through technical documentation and regulatory assessment.
Software development and control
The development process must be structured, traceable and controlled throughout the software lifecycle.
- IEC 62304
- Software planning
- Requirements and architecture
- Verification and validation
- Change management and maintenance
Safety and performance
Compliance depends on how risks are identified, controlled and linked to safe and effective use of the software.
- ISO 14971
- Cybersecurity considerations
- Usability engineering
- IEC 62366-1
- Benefit-risk logic
Evidence and quality
The software must be supported by evidence, documented appropriately and maintained within an effective quality system.
- Clinical evaluation
- Technical documentation
- ISO 13485
- Post-market surveillance
- Assessment readiness
IEC 62304 and the software lifecycle
Medical device software is assessed not only by its final functionality. Regulators and Notified Bodies need evidence that software was developed, verified, maintained and changed through a controlled lifecycle process.
IEC 62304 provides the framework for managing software development activities and ensuring that processes are planned, documented and traceable.
Planning and requirements
Software development begins with controlled definition of the product, its intended purpose, safety classification, requirements and verification approach.
Development and verification
IEC 62304 requires structured software engineering processes including architecture, implementation, testing, verification and traceability.
Maintenance and changes
Software updates, cybersecurity changes and defect corrections must be controlled, assessed and documented to maintain compliance after release.
Clinical evidence and performance evaluation
Medical software compliance requires more than demonstrating that the software functions correctly. Manufacturers must provide evidence that the software performs its intended purpose and that its outputs are clinically meaningful, reliable and safe for the intended users.
The type and depth of evidence depend on the intended purpose, risk class, clinical role and claims made by the manufacturer.
Clinical claims
Demonstrated clinical value and intended benefits
Clinical evaluation and validation
Clinical relevance, benefit-risk assessment and justification of claims
Performance evaluation
Performance metrics, validation datasets and reliability assessment
Technical verification
Software testing, algorithm verification and data quality assessment
Software development and risk controls
Requirements, lifecycle processes, cybersecurity and risk management
Technical performance
Demonstrates that the software functions as designed.
- Algorithm performance
- Accuracy and reliability
- Verification and validation
- Data quality assessment
- Cybersecurity controls
Performance validation
Demonstrates that software outputs are consistent and reliable.
- Sensitivity and specificity
- Performance metrics
- Reference comparison
- Independent validation datasets
- AI model evaluation
Clinical evaluation
Demonstrates that the software provides meaningful clinical value.
- Clinical claims
- Clinical benefit
- Benefit-risk assessment
- Literature evidence
- Clinical investigation data when required
Cybersecurity, AI and evolving software risks
Connected medical software and AI-enabled technologies introduce new types of risks that must be managed throughout the product lifecycle.
Regulatory compliance requires control of data, algorithms, updates and system behaviour, not only protection against software defects.
Cybersecurity throughout the lifecycle
Medical software must remain secure not only at release, but throughout operation and maintenance.
- Cybersecurity risk assessment
- Secure software architecture
- Access control and authentication
- Vulnerability management
- Security updates
AI-specific considerations
AI-enabled software introduces additional questions related to data, model behaviour and ongoing performance.
- Training and validation data quality
- Bias and representativeness
- Algorithm performance monitoring
- Transparency and explainability
- Human oversight
Post-market control
Software does not remain unchanged after release. Changes must be assessed and controlled.
- Real-world performance monitoring
- Change impact assessment
- Risk updates
- Documentation maintenance
- Continuous compliance
Why software projects fail regulatory assessment
Medical software projects often fail not because the technology is insufficient, but because regulatory considerations are addressed too late or treated as documentation tasks rather than as part of product development.
Regulatory assessment evaluates the connection between intended purpose, software functionality, risks, evidence and development processes.
Regulatory strategy starts too late
Common problem
Regulatory decisions are made after software development is already advanced.
Consequence
Wrong classification, additional evidence requirements or costly redesign.
MDRC approach
Define the regulatory pathway before critical product decisions are made.
Documentation is not the regulatory argument
Common problem
Technical documentation is treated as a collection of separate documents.
Consequence
Missing connection between intended purpose, risks, evidence and requirements.
MDRC approach
Build a structured compliance argument supported by appropriate evidence.
Software lifecycle gaps
Common problem
Software development processes lack sufficient traceability and control.
Consequence
Assessment findings related to requirements, verification, validation or changes.
MDRC approach
Align software lifecycle activities with IEC 62304 expectations.
AI requires regulatory judgment
Common problem
AI-generated documentation is used without sufficient regulatory interpretation.
Consequence
Incorrect assumptions about classification, evidence or risk controls.
MDRC approach
Use AI as a productivity tool while maintaining expert regulatory responsibility.
AI can accelerate regulatory work. It cannot take responsibility for regulatory decisions. MDRC combines software development understanding with medical device regulatory expertise to help companies make informed decisions before problems appear during assessment.
Is your medical software ready for regulatory assessment?
We help companies define the pathway, identify evidence requirements and prepare documentation for Notified Body and FDA review.
Discuss your project
