For several crucial reasons, developing medical software applications comes with a significantly higher level of responsibility than developing more common applications. These reasons primarily revolve around the need to gain the trust of healthcare professionals and ensure patient safety. So, what inspires healthcare professionals to trust your solution? Furthermore, are there tangible differences in the software development life cycle (SDLC) for these solutions, and if so, what precisely sets them apart?
Regulations and compliance
Regulations play a significant role in establishing and maintaining the credibility of medical software and devices. They are put in place to ensure medical products’ safety, effectiveness, and quality, including software applications. Hence, compliance with regulatory requirements demonstrates that a solution has undergone rigorous evaluation and meets specific standards.
Regulatory authorities
Regulatory authorities from many countries joined an international forum called the International Medical Device Regulations Forum (IMDRF) to promote the harmonization and convergence of medical device regulations.
However, note that the guidelines published by IMDRF are not binding, and the interpretation of the same definition can vary from country to country, depending on the local regulatory authority (e.g., FDA in the USA).
Note, also, that if your country does not yet have a regulation for medical software, adopting the IMDRF guidelines is the way to go.
SaMD, SiMD
Before exploring the intricacies of developing software as a medical device, let’s better understand the terminology, as it can be confusing sometimes.
For example, SaMD (Software as a Medical Device), explained below, is not explicitly used in the European Union (EU) regulatory framework. SaMD is more commonly associated with the United States Food and Drug Administration (FDA) and other international regulatory bodies.
If you are in the US, the most common terms you’ll encounter are SaMD and SiMD.
- SaMD (Software as a Medical Device)
Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.
- SiMD (Software in a Medical Device)
A set of electronic instructions is used to control, diagnose, monitor, or assist in treating patients. It encompasses embedded software within a medical device and software that operates on general-purpose computing platforms, such as personal computers or mobile devices, used in connection with a medical device.
In layperson’s terms, SaMD can operate independently as the software is the device, while SiMD has to be part of a medical device or even control it. Remember that despite discussing software applications, they are still classified and regulated as medical devices.
The definitions provided above are simplified excerpts aimed at conveying the main idea. In reality, the definitions are more intricate and comprehensive.
SaMD characterization and risk characterization
Now that we have a rough understanding of a SaMD, we must characterize it. This characterization is important for many reasons, some of which are:
- It drives regulatory compliance
- Defines the number of activities in our SDLC
- Helps identify and understand the potential risks
In other words, characterization is required for further categorization. To determine the proper categorization of our SaMD, the following factors need to be considered:
- Intended use: The purpose for which the manufacturer intends the SaMD.
- State of healthcare situation or condition: Refers to the severity of the healthcare situation or condition in which the SaMD is intended to be used.
- Significance of information provided by SaMD to the healthcare decision: Refersto the importance of the information delivered by the SaMD, which helps healthcare professionals in making decisions about patient care.
A proper definition of “intended use” is crucial as it contributes to the other two factors, which are then used to determine the risk class.
According to the guidance published by the IMDRF, they recommend using the following table to identify the risk category.
| State of healthcare situation or condition | Significance of information provided by SaMD to the healthcare decision | ||
| Treat or Diagnose | Drive Clinical management | Inform Clinical management | |
| Critical | IV | III | II |
| Serious | III | II | I |
| Non-Serious | II | I | I |
Note: Even though the table above has four classes, the FDA classifies medical devices into three risk classes based on the potential harm they could cause to patients:
- Class I: Low to moderate risk
- Class II: Moderate to high risk
- Class III: High risk
Risk classification and premarket submissions
The risk classification and intended use of SaMD determine the type of premarket submission required for FDA approval. The three common types of submissions are:
- Premarket Notification (510k): This submission is typically required for lower-risk SaMD that is substantially equivalent to an already legally marketed device (a.k.a predicate device)
- Premarket Approval (PMA): This submission is typically required for higher-risk SaMD, especially those that fall under Class III
- De Novo Classification Request: This one is used in case SaMD does not have a predicate device and is considered a novel technology
Software safety classification and SDLC
In the previous sections, we looked at the framework proposed by IMDRF to describe the risk level associated with the intended use of the SaMD and its impact on patient safety.
In this section, let’s look at another framework that will help us classify our solution based on the potential harm caused by software failures. The reason we need to do this is because this classification will help in identifying the appropriate level of rigor required for
- Development
- Testing and QA processes
As a medical device software developer, we must comply with the IEC 62304 Medical Device Software – Software life cycle process. It is an international standard that specifies life cycle requirements for developing medical software (and software within medical devices).
IEC 62034 defines many processes divided into activities, with the development process having the most activities.
Note that IEC 62304 does not require you to implement all activities. The exact activities are defined by the software safety classification which indicates the amount of harm our software can cause to the patient in case of a failure.
The IEC 62304 classification system categorizes software failures into three levels, determined by the potential severity of resulting injuries:
- Class A: No injury
- Class B: Non-serious injury
- Class C: Serious injury or death
Based on the safety classification, IEC 62304 guides key activities to consider when developing medical device software. As you might have guessed, the higher the class, the higher the rigor driving the development and testing activities.
The table below shows which of the requirements apply to various safety classes:
| Software Documentation | Class A | Class B | Class C |
| 5.1 SW Development Planning | ✔ | ✔ | ✔ |
| 5.2 SW Requirement Analysis | ✔ | ✔ | ✔ |
| 5.3 SW Architectural Design | ✔ | ✔ | |
| 5.4 SW Detailed Design | ✔ | ||
| 5.5 SW Unit Implementation and Verification | ✔ | ✔ | ✔ |
| 5.6 SW Integration and Integration Testing | ✔ | ✔ | ✔ |
| 5.7 SW System Testing | ✔ | ✔ | ✔ |
| 5.8 SW Release | ✔ | ✔ | ✔ |
Last, note that the lifecycle process has no Continuous Delivery (i.e., automated deployment). This requires that every new release be accompanied by extensive documentation to allow the regulators to assess its safety and efficacy properly. The documentation plays a crucial role in the auditing process as it serves as evidence to demonstrate that the solution has undergone thorough design validation and testing (i.e., think about SaMD as Software + Documentation).
So, in summary, the IMDRF SaMD categorization and the IEC 62304 software safety classification provide complementary perspectives on the risk and safety aspects of medical device software:
- IMDRF categorization emphasizes the intended use and information provided
- IEC 62304 classification focuses on potential harm resulting from software failures.
Examples:
| Class A | Blood pressure monitor app. This app allows users to measure their blood pressure at home and track their blood pressure readings over time. It can also be used to set reminders for taking medication or other blood pressure-related tasks. |
| Sleep tracking app. This app allows users to track their sleep patterns and identify potential sleep disorders. It can also be used to set reminders for going to bed and waking up. | |
| Class C | Implantable cardiac defibrillator. This device is implanted in the chest of patients who are at risk of sudden cardiac death. It monitors the patient’s heart rhythm and delivers an electrical shock if it detects a life-threatening arrhythmia. |
| A software system that controls and adjusts anesthesia delivery during surgical procedures. |
As you can see, Class A SaMD devices are typically simpler in design and pose a lower risk to patients than Class C SaMD devices. Class C SaMD devices are often used for more critical applications.
AI and machine learning
AI is transforming the medical device software industry, constantly developing new applications. Undoubtedly, it is a game-changer with the potential to revolutionize how we diagnose and treat diseases.
Whether detecting a potentially cancerous growth in an X-ray image or answering a question in a human-readable format with the help of modern LLMs, ML models use vast amounts of data to learn to draw inferences.
However, the data keeps changing every second, and many solutions implement a feedback loop where the inference quality is rated and fed back to the model for continuous learning.
The continuous adaptation of ML models to changing data challenges the regulatory decision-making process. This is because, technically speaking, a retrained model could be considered a new device and, thus, require a new premarket submission.
Quoting the FDA: “The FDA’s traditional paradigm of medical device regulation was not designed for adaptive artificial intelligence and machine learning technologies. Under the FDA’s current approach to software modifications, the FDA anticipates that many of these artificial intelligence and machine learning-driven software changes to a device may need a premarket review.”
A few years ago, the FDA published a discussion paper, “Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) – Discussion Paper and Request for Feedback.”
In this paper, the FDA proposes a new framework to regulate ML solutions based on the risk categorization principles discussed above. This approach will allow the FDA to embrace the iterative nature of ML solutions while continuously assuring patient safety.
The main idea is to apply the FDA’s Total Product Lifecycle (TPLC) approach, a regulatory framework for overseeing software products (including medical device software), to continuously adaptive ML solutions.
One of the principles that the proposed approach is based upon states that the manufacturers should “Conduct premarket review for those SaMD that require premarket submission to demonstrate reasonable assurance of safety and effectiveness and establish clear expectations for manufacturers of AI/ML-based SaMD to continually manage patient risks throughout the lifecycle.”
The idea is based on the “predetermined change control plan” principle submitted during the initial premarket review. This plan would include the following two documents:
- SaMD Pre-Specifications, SPS – The types of anticipated modifications
- Algorithm Change Protocol, ACP – The associated methodology.
During the first premarket review, we have to supply two documents: one parameterizing the anticipated modifications and another one describing the change controls that must be followed to ensure that the device remains safe and effective after the modification(s).
As long as the modifications to the ML model remain within the scope of SPS and ACP, no new premarket review will be required.
Summary
In this article, we only covered the tip of the iceberg when it comes to the complex world of medical device development, specifically focusing on Software as a Medical Device (SaMD)
The development of SaMD brings about unique challenges and requires a deep understanding of regulatory frameworks and the impact of constantly adaptive technologies.
Navigating these challenges while ensuring compliance is crucial for developers and manufacturers to deliver safe and reliable medical software solutions that enhance patient care and improve healthcare outcomes.
