The A, B, Cs of SaMD Development
Overview of the IMDRF ‘s “Software as a Medical Device”: Possible Framework for Risk Categorization and Corresponding Considerations
In my other articles or the glossary, you’ll have likely come across several terms like Software as a Medical Device, SaMD changes, risk categorization, or intended use. Today, let’s dive into the source—the IMDRF—and explore exactly how this terminology applies to successful SaMD development.
What is the IMDRF, and why should we care about it?
The International Medical Device Regulators Forum (IMDRF) is a “voluntary group of global medical device regulators from around the world.” Their goal is to harmonize regulatory requirements internationally for medical devices. In the process, they provide helpful guidance for Digital MedTech entrepreneurs.
More specifically to SaMDs, this group authored “Software as a Medical Device”: Possible Framework for Risk Categorization and Corresponding Considerations. This document acts as a guide to help SaMD manufacturers, regulators, and developers to define and categorize their solutions, and it points out new considerations needed for technologies that are rapidly transforming the healthcare industry.
The aim of this article, however, is not to exhaustively interpret the document into lay terms, but rather to offer a succinct overview that serves as a jumping off point for planning digital health innovation. To begin, let’s quickly define the main topic—Software as a Medical Device:
Software as a Medical Device, or SaMD, refers to a software product that is intended for medical purposes but is independent from “hardware” or physical medical devices (e.g., thermometers, X-ray machines, artificial hearts, etc.). While SaMDs are generally used in combination or interfaced with other products, they are not essential to the functioning of other physical medical devices. SaMDs are considered medical devices for regulatory purposes, they run on general-purpose computing platforms, and they can include mobile apps that meet the defining criteria of a medical device. (Paraphrased from the IMDRF key definitions document—also a recommended resource).
Next, let’s talk about how we describe SaMDs.
The A, B, Cs of Characterization: Generating a SaMD Statement
When we describe SaMDs, we need to consider questions regarding the intended use. In other words, how does the information provided by the software influence a healthcare decision or action (A) and in which healthcare situation does it function (B)? Additionally, all manufacturers need to iterate core functionality (C).
A) What’s the significance of information provided or where does the SaMD fit into the scheme of things? For example, does it:
Treat or diagnose (triggers action)?
Drive clinical management (guides next actions by aiding triage, treatment, or diagnosis)?
Inform clinical management or practice (not trigger action)?
B) What’s the severity of the situation or condition?
Critical, life-threatening, or incurable, meaning it requires major interventions and that the solution should only be operated by specialized trained personnel
Serious, implying that accurate and timely actions are needed to successfully treat and/or prevent irreversible health conditions or unnecessary interventions
Non-serious, meaning that accurate and timely actions are indeed important but not “critical,” and where the solution could potentially be operated by a lay user
C) Description of the core functionality
This last aspect deals with the specific features or functions of the software “essential to the intended significance of the information provided by the SaMD to the healthcare decision in the intended healthcare situation or condition.” In other words, how does it accomplish aspects A and B?
A + B = Risk Categorization
Aspects A and B help categorize risk, which is divided into four categories, with IV signifying the highest risk or impact and I the lowest impact in regard to avoiding “death, long-term disability or other serious deterioration of health, mitigating public health.” If your solution functions in more than one health care situation (e.g., in both critical and non-serious), the higher level will determine categorization. The graph below quickly summarizes risk levels.
To further illustrate how this works, let’s look at two examples of SaMDs in stroke care:
One SaMD offers diagnostic image analysis for acute stroke treatment by quickly differentiating between hemorrhagic and ischemic stroke. The speed and accuracy of this analysis is critical to interventions and concerns patients in life-threatening conditions. Any guesses as to how this category rates? IV.
In contrast, another example SaMD utilizes data in order to generate scores for the risk of developing stroke and to create prevention strategies. This one rates only a category II. While it does detect early signs of and potentially could treat a serious condition, it’s not time critical and implies a “non-serious” care situation.
Our “C” or description of core functionality, on the other hand, has little to do with categorization, except for the fact that it’s essential for managing SaMD changes and with changes comes recategorization of risk.
“Developing SaMD that are safe entails identifying risks and establishing measures that give confidence that the risks are acceptable.”
Because software functions in a dynamic socio-technical ecosystem, there are unique challenges to developing and regulating SaMDs. Not only must software operate in the existing workflows, but with new systems, platforms, data sets and care settings connecting, it’s not easy to predict emergent behaviors and results. Additionally, unexpected results will vary significantly from that of hardware medical devices. Thus, new considerations are needed to ensure safety, efficacy, and security.
To address these issues, the IMDRF recommends the IEC 62304 risk-based decision model for SaMD life-cycle development, which follows three principles: 1) Risk management; 2) Quality management; and 3) methodical and systematic systems engineering according to best industry practices. This entails safety considerations present from the start, post market surveillance, and predicting and addressing problems arising from user operation or software updates. Ideally, the system also needs monitoring features to detect errors automatically or proactively—before they can impact patient health.
In addition, these areas merit developers’ full attention:
SaMD changes (read more here) require systematic approaches and verification of safety and effectiveness, as well as potential recategorization.
The socio-technical environment must be taken into account, as SaMDs function in an large ecosystem of various hardware, networks, manufacturers, physical locations, workflows, and, of course, users. Developers need to take measures to see that their solution functions as intended and without misuse through user “finagling” or confusion.
Considerations concerning the technology and system environment are also vital, as the SaMD must operate in connection and collaboration with other technologies without endangering its intended function or the function of other systems.
And last, but surely not least, information security ranks among the top considerations, since storing, sending, and accessing secure data requires special measures for authorization, identification, verifying data integrity, and integrating security software/spyware updates.
Inadequate considerations can lead to “incorrect, inaccurate, and/or delayed diagnoses and treatments; and/or additional cognitive workload (which may, over time, make clinicians more susceptible to making mistakes),” or “loss of information, delayed, corrupted, or mixed patient information, or inaccurate information which may lead to incorrect or inaccurate diagnoses and/or treatments.” Needless to say, “adequate” considerations should be a top priority for developers.
To dive into the details of this SaMD Framework, check out the whole document here.