FDA and EU Risk Requirements for Medical Device Software & SaMD

In our first post, we talked about international risk management standards and guidance applicable to medical device software, including the ISO 14971 and IEC 62304 standards. 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 Europe

ISO 14971 and IEC 62304 are international standards intended to help you meet regional requirements, such as those imposed by the European Medical Devices Directive (MDD 93/42/EEC) and the EU Medical Device Regulation (MDR 2017/745). The EU MDR will soon replace the MDD and goes into effect in May 2021, so we will focus on it in this article. You may find this PDF copy of the EU MDR to be a helpful reference tool as it contains quick links to each section of the EU MDR.

How medical device software and SaMD are classified in Europe

Annex VIII, Chapter III of the EU MDR deals with how medical devices are classified. The section within Chapter III that pertains to software is Rule 11. Here’s a summary of what Rule 11 says: If the software is used for diagnosis or therapeutic purposes, then it is considered a Class IIa medical device UNLESS:

• Failure could cause a serious deterioration of health or surgical intervention – then it is Class IIb (e.g., software driving monitoring of a respiratory or circulatory system).
• Failure could cause death or irreversible deterioration of health – then it is Class III (e.g., software driving an active implantable device).
• If it does not meet any of the criteria noted above, it is Class I (e.g., imaging software from CT scans).

Annex 1 of the EU MDR (General Safety and Performance Requirements) contains two sections directly and indirectly affecting software. Chapter 1, Section 15 briefly notes that with 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).

Section 17 deals with PEMS (Programmable Electrical Medical System), 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 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 necessitate 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. Wondering what that means’ Read this.

Link to risk management and usability requirements in the European MDR

You will want to read Annex 1, 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 lay persons. 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, the US Food and Drug Administration (FDA) has a number of 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, as 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 December 2017, the FDA released a draft 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:

• Off-the-shelf (OTS) software
• Cybersecurity for networked devices containing OTS
• Postmarket cybersecurity management
• Software validation
• 510(k) and PMA submissions for software

Want to learn more?

As embedded software and SaMD play an increasingly important role, it is critical that developer and regulatory professionals understand their regulatory obligations. Oriel STAT A MATRIX 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 Medical Device Software Development, Verification, and Validation 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.