Introduction to Software as Medical Device: What is SaMD?

Let’s start by explaining what SaMD is. The term Software as a Medical Device is defined by the International Medical Device Regulators Forum (IMDRF) as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”

In short, SaMD is an independent software that is a standalone medical device, intended to treat, diagnose, monitor or drive patients’ care. Some examples of SaMD can be a companion app that provides patient education and personalized goal setting, followed by progress tracking and real-time expert support. Another example could be a mobile app that monitors a patient’s heart rate or glucose levels and makes treatment recommendations to the patient and/or patient’s doctor.

It’s important to note that Fitness and Wellness apps are not considered SaMD as per the (IMDRF) International Medical Device Regulators Forum EU MDR 2017/745 and 520(o)(1)(A) – (D) of the FD&C Act (FDA). This includes most digital health applications that offer virtual care services in which a clinician is directly involved in all care decision-making. Software that does not diagnose, treat, mitigate or prevent the disease is not qualified as SaMD.

Some examples of digital health applications that are not regulated by the FDA:

• Apps tracking activity level and sleeping patterns for healthy patients
• Meditation and relaxation applications
• Diet and nutrition applications focused on patient education
• Digital health applications that help patients connect virtually with members of their care team to regularly manage overall health or a particular condition
• Digital health services that help patients connect with clinicians that prescribe medication for low-acuity needs
• Electronic Health Record software (EHRs) and patient portals where individuals can access their care plans and appointment information

Software In a Medical Device (SiMD) refers to software that is embedded into physical medical devices and controls and manages those devices to ensure they are performing their intended use. SiMD either powers the mechanics of a medical device or processes the information produced by the medical device itself. If a medical device cannot work or be used without specific software, then the necessary software can be considered a SiMD.

There’s a difference between SaMD and SiMD: Software that is embedded as part of a hardware medical device and is necessary to drive the intended medical purpose is NOT a SaMD.

However, if the software interfaces with other hardware medical devices and acts as an additional enhancement for its medical purposes, it can be considered a SaMD.

To illuminate the difference between SaMDs and SiMDs, see the examples below.

• A mobile app that connects with a sensor to continuously monitor glucose levels
• A mobile app connected with an electrocardiogram (ECG) hardware device that monitors and displays a single-channel ECG
• An app that analyzes or processes radiological images to detect cancer
• Apps that perform support for individual patients with drug dose calculations

The apps run on either mobile phones, desktops, or smartwatches, but the SaMD is not embedded in the medical device itself.

• Software that is embedded in pacemakers
• Software that displays MRIs and other types of medical imaging on mobile devices
• Software that is embedded into and manages an infusion pump

Below you can see some visual examples showing SiMD and SaMD.

• EHR apps or platforms
• Healthcare payroll platforms
• Healthcare personnel training software
• Software that analyzes and monitors the performance or functioning of a medical device

Before starting the design and development phase, it’s crucial to analyze your medical device software idea and apply proper safety classification. The FDA categorizes medical devices into safety classes based on their risks and the regulatory controls necessary to provide a reasonable assurance of safety and effectiveness.

This is crucial because regulations and compliance can change depending on classification, like the type of pre-marketing submission, required applications for FDA clearance, or approval to go to market.

Classification depends on the intended use and indications of use of the software device. Additionally, classification is risk-based, meaning it reflects the level of risk patients take on by using certain medical device software.

FDA classifies SaMD using the same risk classes as it does for traditional medical devices: Class I, Class II, and Class III. Class I devices represent the lowest risk to users, while Class III devices signify the highest risk.

Class I devices, which pose the least risk and chance of harm, are subject to standard FDA controls. Many Class I devices fall under the exemption from premarket approval.

Class II devices pose a moderate risk, requiring additional data to confirm safety and effectiveness, that is why they’re governed by both general and special controls. Their regulation depends on the FDA’s prior approval of a similar device through the FDA 510(k) pathway. Class II devices can be exempt from premarket approval or opt for the newer De Novo pathway when a suitable predicate isn’t found.

Class III devices, with the highest risk as they support or sustain life, must adhere to general controls, special controls, and rigorous premarket approval (PMA). This PMA scrutinizes device-specific safety and effectiveness, mostly based on clinical trial data.

IMDRF has described the concept and SaMD risk categories in detail for the medical app development industry to follow.

IMDRF identified four categories of medical devices (I, II, III, IV) which are based on the levels of impact on the patient or public health. It is vital to provide accurate information on how the device will treat, diagnose, drive, or inform clinical management in order to avoid death, long-term disability or other serious deterioration of health. Category IV has the highest level of impact and risk, Category I the lowest.

An example of a Category I medical device would be an app that calculates BMI. This is used as a data point to inform someone that they may need to gain or lose weight, but it doesn’t directly impact patient outcomes. That patient may have a serious or critical condition related to their weight (anorexia, for example), but that information is not directly treating or driving the clinical management of the condition.

Category II could include software intended for healthcare professionals that uses an algorithm to analyze patient information, such as blood pressure, heart rate, weight, and age to determine which treatment plan is likely to be most effective in treating the patient’s condition. These patient-specific treatment recommendations would otherwise not be available to the health care professional.

A Category III could include a treatment planning system that provides detailed parameters to support the treatment of a particular tumor or a SaMD that provides information to healthcare providers for the diagnosis of a benign lesion.

For the highest risk classification, Category IV, an example would be software that analyzes inputs to diagnose and make treatment decisions for acute stroke patients or meningitis in children.

IMDRF categorization can be a helpful tool many companies leverage for determining the risk class of their SaMD in the EU context as you will see below that EU MDR and EU IVDR adopted 4 different classes.

The Medical Device Coordination Group (MDCG) of the European Commission classifies Medical Device Software into Class I, IIa, IIb or III. For devices subject to the IVDR, the MDR categorizes them into four classes labeled as A, B, C, and D. In the EU, device classification follows a rules-based approach. Similar to other device types, the classification is based on the device’s intended use and associated risks.

The MDCG 2019-11 document provides guidance on medical device classification, including software, as detailed on page 27. Annex IV includes SaMD classification examples based on the IMDRF framework.

When you develop software as a medical device you must comply with specific regulations. To ensure compliance, it’s recommended you follow IEC 62304, which is a well-known harmonized standard that is recognized by the FDA. The IEC 62304 standard describes software life cycle requirements that should be applied when developing medical device software. IEC 62304 is not mandatory, but it is globally recognized and widely adopted as an international standard.

In the IEC 62304 standard, businesses developing software must classify each software-based system based on the severity and possible harm that it can cause for patients. The IEC 62304 standard has its own safety classification:

• Class A: No injury or damage to health is possible
• Class B: Non-SERIOUS INJURY is possible
• Class C: Death or SERIOUS INJURY is possible

This diagram demonstrates the steps to follow when specifying software safety classification according to IEC 62304:

Based on the above graph, to classify your software, you start with the highest class – C, and you answer questions about your software that will guide you eventually to determine its software safety classification.

What I want to highlight is that the above software safety classification is not a determination of how safe your software is. Instead, it is the basis for determining how rigorous your software development process must be. The safety of your device is tied to your design and development procedures, not only its safety classification.

Remember, your IEC 62304 safety classification doesn’t directly equate to the risk classification under US or EU regulations, though its strongly correlated. For instance, a class C safety class may suggest your device could be classified as class III in the US or EU, but a lower risk class is also possible for a class C safety device.

Essentially, IEC 62304 classification specifies the rigor required in software development related to safety, not a definitive risk class, nor does it indicate the actual safety of a completed SaMD.

As you can see, classification is not easy. Depending on the market that you’re planning to have your device, you may need to understand how to follow every one of these classification methods. That’s why it’s important to think about your safety classification from the very beginning and if needed consult it with experts in the field.

In the next article in our series, we will talk about medical device software development, its potential challenges and factors that can help you accelerate development and make it less complicated. Sign up for the SaMD newsletter to get early access to all HTD thought leadership content.

Healthcare is complex, and often so are the software systems that support it. Expert teams like HTD Health can help businesses design systems that are highly configurable and scalable. HTD offers SaMD strategy consulting, software design, and software development services. If you have a project in mind, reach out to info@htdhealth.com for a free consultation.