Overview of Risk Management for Medical Device Software & SaMD
Software itself is not risky. Nobody gets directly injured by bad code or a poorly designed UI and, unlike hardware, software does not fail randomly.
That being said, software can definitely expose someone to a hazardous situation because software is viewed to have 100% probability of failure when it does occur. Therefore, this makes software rightfully subject to risk management oversight, including special considerations for software-controlled medical devices.
In this post, we’ll cover the basics of risk management for embedded software or stand-alone Software as a Medical Device (SaMD), so you have an understanding of what is required before, during, and after coding.
Standards and guidance affecting software for medical devices and SaMD
Many guidance documents and market-specific regulatory documents exist to guide developers and compliance professionals. However, at the root of risk management compliance lie two core documents.
- ISO 14971:2019– This is an international risk management standard for medical devices. It has a valuable companion guidance document ISO/TR 24971:2020. We assume you have a basic understanding of risk management and ISO 14971 but if you need a refresher, start with our excellent series on medical device risk management.
- IEC 62304:2015– This international standard defines the life-cycle requirements for medical device software and expects that you have implemented a risk management process according to ISO 14971.
These two standards will serve as your core guide to risk management, but there are many other related documents pertaining to software risk management and cyber security that are also extremely useful. Before reading further we recommend that you open our list of relevant documents in a separate window.
IEC 62304 and life-cycle management for medical device software
IEC 62304:2015 is a harmonized standard specifically created for medical device software and is accepted by the US FDA and European regulators, although many of the elements are foundational to any robust software development process. IEC 62304 provides a framework for processes, activities, and documentation associated with designing and maintaining medical device software. It applies to all SaMD and embedded software used in medical devices.
As we mentioned earlier, IEC 62304 assumes that you are applying ISO 14971 risk management and have a quality management system in place that complies with ISO 13485 or the US FDA Quality System Regulation (21 CFR Part 820). It further assumes that software risk management is part of a broader system that defines higher-level activities for design inputs and design (product) validation. How do they mesh with one another? You can think of ISO 14971 as the overarching risk management process that covers all product development activities, while IEC 62304 is a subset of that effort, focusing on software risk management, configuration management, and problem resolution. It is also a companion to IEC 60601-1, Edition 3.1, Clause 14, which deals with Programmable Electrical Medical Systems (PEMS) or those devices that have software associated with them.
Your software risk level determines depth of compliance with IEC 62304
The application of IEC 62304 starts with a base assessment of risk. The risk classes in the standard are straightforward but placing your software into one of the three classes shown below should not be taken lightly, as it has a big impact on the code development and maintenance process. Remember, the risk classes below are independent of the overall risk classification of your device according to US FDA or EU regulations. Here are the three IEC 63204 categories defined in:
- Class A – The software CANNOT contribute to a hazardous situation or if it does the risk is acceptable.
- Class B – The software CAN contribute to a hazardous situation which results in an unacceptable risk of possible non-serious injury.
- Class C – The software CAN contribute to a hazardous situation which results in an unacceptable risk of possible serious injury or death.
These are of course simple terms, as the categorization also needs to include considerations of risk control and risk acceptability.
You are required to address all activities within IEC 62304, but tailor the rigor and amount of documentation proportional to the risk associated with your software. If your software falls into Class A or B, some aspects of IEC 62304 will not apply, as shown in the following table. You have to take a “worst-case” approach in assessing your risk level as this is the approach regulators will take for classifying your software. It would be difficult to generate additional documentation for software if your classification is not accepted by a regulatory reviewer. Unless you are developing Class I (regulatory classification) and Class A (risk classification) software, your risk justification and documentation will ultimately be reviewed by the US FDA or a European Notified Body. If you have determined your device to be Class A according to IEC 62304 and your Notified Body sees it as Class B, you’ll have to justify why you did not document architecture design and integration testing. If your software falls somewhere between classes take the conservative approach but don’t be overly conservative, because there are meaningful documentation differences between Class A and B, or Class B and C. Going from Class A to B may not affect the risk of your software, so think carefully about your classification and document the logic behind your decision.
Risk management requirements in the EU MDR relevant for software or SaMD
ISO 14971 and IEC 62304 are international standards intended to help you meet regional requirements, such as those imposed by FDA or the EU Medical Device Regulation (MDR 2017/745). Let’s talk about the EU MDR first. (Download a full-linked copy of the MDR here.) Here are the sections you will want to review:
Annex I, Chapter 1, Sections 1-9 – Deals 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.
Annex I, Chapter 1, Section 15 – This 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 is relevant because it 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 must support analytical accuracy and resolution of measurement.
Annex 1, Chapter 1, Section 17 – 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.
Annex 1, 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.
And, of course, you’ll want to confirm the classification of your software using Annex VIII, Chapter III, Rule 11.
US FDA requirements for SaMD and embedded software
The US Food and Drug Administration (FDA) publishes a variety 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.
While compliance with FDA Design Controls is essential for any medical device manufacturer, specific FDA recommendations pertaining to software are not contained within the Quality System Regulation. Instead, the FDA addresses this using individual guidance documents. There are a variety of guidance documents pertaining to medical device software risk management and cyber security and we have compiled a comprehensive list here.
Want to learn more?
Oriel STAT A MATRIX offers a variety of training classes that can bring your understanding of risk management to the next level. Our ISO 14971 risk management class is one of our most popular along with our cybersecurity training. Of course, our risk consultants are ready to help as well.