SaMD (Software as a Medical Device)

SaMD Classification Explained: Navigating EU & UK Regulatory Requirements

SaMD Classification

Are you developing software for healthcare applications? Understanding SaMD classification is crucial to your regulatory journey. In this blog post, we’ll break down the complexities of Software as Medical Device classification in both the EU and UK regulatory frameworks.

What Exactly is SaMD?

Software as Medical Device (SaMD) refers to software that performs a medical function without being part of hardware medical device. This includes mobile apps, cloud-based platforms, and standalone software that healthcare providers use for diagnosis, treatment decisions, or patient monitoring.

The classification of your SaMD determines everything from the documentation you’ll need to prepare to the level of regulatory scrutiny you’ll face.

Why SaMD Classification Matters

Your software’s risk classification directly impacts:

  • The conformity assessment route you must follow
  • The level of clinical evidence required
  • Whether you need a Notified Body (EU) or Approved Body (UK) assessment
  • Post-market surveillance requirements
  • Time-to-market and overall compliance costs

Getting classification wrong can lead to significant delays, unexpected costs, or even regulatory rejection.

SaMD Risk Classification in EU and UK

EU vs. UK SaMD Classification: The Basics

Both the EU and UK classify medical software into four risk categories:

Class I (Lowest Risk)

  • Examples: Simple record-keeping apps, wellness trackers
  • Key feature: Minimal impact on clinical decisions
  • Conformity route: Often self-declaration without Notified Body involvement

Class IIa (Medium-Low Risk)

  • Examples: Apps monitoring non-critical physiological parameters
  • Key feature: Supports decisions for non-serious conditions
  • Conformity route: Requires Notified/Approved Body assessment of technical documentation

Class IIb (Medium-High Risk)

  • Examples: Software for therapy planning, cardiac monitoring apps
  • Key feature: Informs decisions for serious conditions
  • Conformity route: More extensive Notified/Approved Body assessment

Class III (Highest Risk)

  • Examples: Diagnostic software for critical conditions, treatment-determining algorithms
  • Key feature: Decisions affecting life-threatening conditions
  • Conformity route: Most rigorous assessment with extensive clinical evidence

How to Determine Your SaMD Classification

The classification of your SaMD hinges primarily on these factors:

  1. Intended purpose – What medical function does your software perform?
  2. Patient risk – What could happen if your software malfunctions or provides incorrect information?
  3. Healthcare context – Is it used in critical care, routine checkups, or home monitoring?
  4. User profile – Is it designed for healthcare professionals or patients?

The Critical Rules for SaMD Classification

In the EU MDR (Medical Device Regulation), Rule 11 is particularly important for software classification:

  • Class III: If decisions from your software could cause death or irreversible deterioration
  • Class IIb: If decisions could lead to serious health deterioration or surgical intervention
  • Class IIa: For all other decision-support software

Rule 12 governs monitoring software:

  • Class IIb: For monitoring vital parameters where variations could pose immediate danger
  • Class IIa: For monitoring other physiological processes

UK-EU Divergence: What You Need to Know

While the UK initially mirrored the EU approach to SaMD classification, the landscape is changing:

  • The UK is developing its own framework through the MHRA’s Software and AI as a Medical Device Change Programme
  • The UKCA mark replaces the CE mark for the UK market
  • The UK may take a more flexible approach to innovative technologies, particularly AI-driven software
  • Registration processes differ between the two markets

Special Considerations for AI-Based SaMD

If your medical software incorporates artificial intelligence or machine learning:

  • EU approach: The forthcoming AI Act will impose additional requirements based on risk level
  • UK approach: The MHRA has published specific guidance for AI as a medical device
  • Common considerations: Data quality, algorithm validation, explainability, and performance monitoring are key factors in both jurisdictions

Practical Tips for SaMD Developers

For Class I Devices

  1. Document your classification rationale thoroughly
  2. Prepare robust technical documentation
  3. Implement a quality management system (even if not strictly required)
  4. Register with the appropriate authorities (MHRA in UK, member state competent authorities in EU)

For Higher-Risk Devices (Class IIa, IIb, III)

  1. Engage early with Notified/Approved Bodies
  2. Invest in comprehensive clinical evaluation
  3. Implement a certified quality management system (ISO 13485)
  4. Develop robust post-market surveillance processes

For Dual UK-EU Market Access

  1. Create modular technical documentation to address both frameworks
  2. Consider working with both UK Approved Bodies and EU Notified Bodies
  3. Monitor regulatory developments in both jurisdictions
  4. Plan for potentially different clinical evidence requirements

Conclusion

SaMD classification is the crucial first step in your regulatory journey. By understanding the classification rules, conformity assessment routes, and the evolving UK-EU regulatory landscape, you can develop a strategic compliance approach that balances speed-to-market with regulatory rigor.The most successful SaMD developers integrate regulatory considerations into their development process from the very beginning, rather than treating compliance as an afterthought.