Compliance Requirements for Medical Device Software and Software as a Medical Device (SaMD) in the US and EU

Compliance Requirements for Medical Device Software and Software as a Medical Device (SaMD) in the US and EU

In this post, we will discuss specific compliance requirements in the US and Europe for medical device software paired with hardware, and stand-alone software as a medical device (SaMD).

Requirements for Software Risk Management in the US

In the US, the Food and Drug Administration (FDA) regulates software intended for medical purposes, including SaMD. FDA has clarified its stance on SaMD through the Digital Health Center of Excellence, emphasizing that SaMD refers to software intended to be used for one or more medical purposes that perform these functions without being part of a hardware medical device.

Key aspects of SaMD regulation include:

• Quality Management System (QMS): FDA requires a comprehensive QMS for SaMD, ensuring that all aspects of the software’s life cycle – including risk management, clinical evaluation, and post-market surveillance – are covered.
• FDA Design Control (21 CFR Part 820.30): Design controls for medical device software include establishing procedures to ensure that design inputs, verification, and validation testing meet specified requirements.
• FDA Guidance on SaMD Clinical Evaluation: In 2017, FDA issued final guidance on clinical evaluation for SaMD. This document emphasizes the importance of clinical validation and outlines requirements for software intended to support clinical decisions, focusing on risk management and clinical studies.
• FDA Guidance on Decision Support Software (2022): FDA released a final guidance on clinical and patient decision support software. This guidance provides regulatory clarity on lower-risk patient decision support tools, which may not require full FDA regulatory oversight if they merely allow patients to review treatment recommendations.

Requirements for Software Risk Management in Europe

In Europe, the regulation of medical device software is governed by ISO 14971 and IEC 62304 – international standards intended to help you meet regional requirements, such as those imposed by the European Medical Devices Directive (MDD 93/42/EEC), the EU Medical Device Regulation (MDR 2017/745), and EU In Vitro Diagnostics Regulation  (IVDR 2017/746).

How Medical Device Software and SaMD Are Classified in Europe

EU Medical Device Regulation (MDR) 2017/745:

• The EU MDR replaced the Medical Devices Directive (MDD) in May 2021, introducing stricter requirements for software classification and risk management. Annex VIII, Chapter III of the MDR defines the classification rules for medical devices, including software.

Classification of Software Under the EU MDR:

• Rule 11 in the MDR provides classification criteria for software:
  • Class IIa: If the software is used to make medical decisions that affect health, such as diagnostics or therapy, but without serious consequences.
  • Class IIb: If decisions made by the software could lead to serious health deterioration or require surgical intervention (e.g., monitoring software for critical systems like respiratory or circulatory systems).
  • Class III: If the software’s decisions could lead to death or irreversible health deterioration (e.g., software controlling active implantable devices).
  • Class I: If the software’s function does not meet the above criteria, such as imaging software used in medical diagnostics (e.g., CT scan software).

 Classification of Software Under the EU IVDR:

• The IVDR follows a similar classification approach to the MDR, although with specific provisions for in vitro diagnostics. Annex VIII of the IVDR outlines the classification rules for in vitro diagnostic devices, including software. Classification is based on risk to patients, users, and public health.

• Rule 11 in the IVDR provides the classification criteria for software, with the following categories:

• • Class A (low risk): Software that is intended to support general diagnostic functions and does not directly impact patient health or clinical decisions. For example, software used for organizing or managing laboratory data or aiding in routine diagnostic tests that have minimal or no clinical impact. An example could be software used for managing test results or presenting data from diagnostic instruments in a way that doesn’t affect decision making.
  • Class B (moderate risk): Software that provides diagnostic results or has an impact on decision making related to patient health but doesn’t directly influence serious health outcomes. For example, software used to assist with diagnostics or report findings (e.g.,  blood test results) that could influence clinical decisions, but without posing immediate or significant risks to health. An example could include software used for analyzing diagnostic imaging or lab test data that may suggest conditions needing follow-up but isn’t definitive on its own.
  • Class C (high risk): Software that is used to provide critical diagnostic information, which may directly impact patient care or health decisions. This could include software used for high-risk diagnostics for which the results can have a significant effect on the treatment or clinical pathway, and for which the software could influence critical decisions such as diagnostic imaging used for cancer detection or software used in organ transplantation diagnostics. A Class C device might include software used for diagnosing conditions like HIV or cancers, for which the results can have a major impact on treatment and patient outcomes.
  • Class D (very high risk): Software that provides essential diagnostic information for which incorrect decisions could cause serious health risks, irreversible harm, or death. This could include software that influences life-critical decisions or is part of high-risk testing that could lead to direct medical interventions, such as software used in genetic testing or diagnostic software for critical diseases. An example might be software that determines compatibility for organ transplants or genetic testing for certain high-risk conditions for which the results have life-or-death consequences.

Key Considerations for In Vitro Diagnostic Software Under the IVDR:

• • Risk-based classification: Software used in diagnostics is classified based on the potential risk its decisions may pose to the patient, the healthcare provider, and public health. The higher the risk, the more stringent the regulatory oversight.
  • Post-market surveillance: As with the MDR, software under the IVDR is subject to post-market surveillance requirements, especially for high-risk software. Continuous monitoring ensures the software remains effective and safe as new data is gathered, and it includes mechanisms to track adverse events.
  • Clinical performance: Software that is classified as IVD is subject to clinical performance studies. For higher-risk classifications (Class B, C, or D), manufacturers must prove that the software’s performance is clinically validated.
  • Usability and design: Usability is a significant factor in software classification, especially for software intended for non-expert users (e.g., patients or technicians). As such, manufacturers need to design software with clear, understandable outputs and ensure appropriate user training.

General Safety and Performance Requirements

Annex I of the EU MDR/IVDR (General Safety and Performance Requirements) contains two sections directly and indirectly affecting software. Chapter 1, Section 15 briefly notes that devices with a measuring function shall be designed and manufactured in such a way as to provide sufficient accuracy, precision, and stability for their intended purpose, based on appropriate scientific and technical methods. This means:

• Verification testing is crucial to ensure that the software algorithm conducts proper measurements.
• Validation testing is needed to support what the users see and how they may interpret results.
• Performance testing supports analytical accuracy and resolution of measurement (e.g., SpO2 specification +/- 2% within range).

Programmable Electrical Medical Systems (PEMS)

Section 17 of the MDR/IVDR deals with PEMS, which these days is generally referred to as software in a medical device. Almost all current products have microprocessors that run the device, so PEMS is just an older phrase that is sometimes used. These can be devices that incorporate electronic programmable systems and software, or software that is a device unto itself. Meeting the requirements of this section necessitates the following:

• Software verification testing needs to link to hazards identified for the software and/or hardware interface.
• Software life-cycle development is key for managing hazards, verification, validation, and cybersecurity issues.
• Interoperability with other software-controlled devices and connectivity via Wi-Fi, Bluetooth, and networks must be addressed.
• Software shall be developed with the state of the art. If you’re wondering what that means, read this.

Link to Risk Management and Usability Requirements in the European MDR/IVDR

You will want to read Annex I, Chapter 1, Sections 1-9 of the EU MDR dealing with the general requirements, including application of risk management. Although ISO 14971 is not mentioned in the EU MDR, the clauses provide a direct link to risk management principles, so it is important that you review them. Because software is often viewed as a black box, you will need to thoroughly identify all hazards to understand the risks posed to users. Challenges with software often include understanding user impacts, and unforeseen events that can occur with software or software-controlled devices.

Further along in Chapter 1, Section 22 talks about how software must be designed for lay users and their environment. That’s important, because software has a direct impact on usability – not just information presented on screen, but also how users interact with software and the device. As such, as part of the risk management process, it is especially important for you to conduct usability studies if your software is used by laypersons. Usability studies help identify unforeseen risks and document that hazards have been properly identified.

SaMD and Embedded Software Risk Management Requirements from the US FDA

In addition to international standards, there are a number of FDA guidance documents or regulations that pertain to medical device software and/or risk management. Guidance documents issued by FDA reflect their current thinking on a topic. Even in draft format they should be carefully followed and not merely viewed as suggestions. Here are some of the major regulatory obligations you should know:

• FDA Design Control: Medical device software sold in the US is regulated under the US Quality System Regulation (21 CFR Part 820). One of the most important sections affecting software risk management is 21 CFR Part 820.30 on design control. The idea behind design control is to establish and maintain procedures to control the design of a device to ensure that specified design requirements are met. This is not specific to software but definitely includes software such as design inputs, verification testing, and validation testing. Download the corresponding FDA guidance document.
  
  
• FDA Guidance on SaMD Clinical Evaluation: In late 2017, FDA issued a final guidance document on clinical evaluation for Software as a Medical Device (SaMD). This document (based on International Medical Device Regulatory Forum document SaMD N41) is important to review, because it outlines the activities needed to clinically evaluate and validate stand-alone software devices. Other SaMD documents published by the IMDRF do exist, so be sure to check out all documents here.

• FDA Guidance on Decision Support Software: In September 2022, FDA released a final guidance entitled Clinical and Patient Decision Support Software that proposes not to impose regulatory requirements on lower-risk patient decision software that allows patients to review treatment recommendations. The document provides examples of products that fall into this category.

FDA has a number of other guidance documents you should review on these topics, which can be found here.

Want to Learn More?

As embedded software and SaMD play an increasingly important role in healthcare, it is critical that developers and regulatory professionals understand their regulatory obligations. Oriel STAT A MATRIX (part of ELIQUENT Life Sciences) specializes in helping medical device companies and can help you navigate the regulatory maze. Our risk management consulting services and training classes as well as our FDA and EU Medical Device Software Regulations and Standards Training  or Medical Device Cybersecurity class will arm you with the foundational knowledge you need to develop medical device software or SaMD in compliance with US, European, and international risk management requirements.