As technology advances across all healthcare fields, Software plays a significant role in all products. It is widely integrated into digital platforms serving both medical and non-medical purposes. Medical device software is one of three types of Software related to medical devices.

The other two types of medical device software include Software that is an integral part of the medical device (medical device software) and Software used in manufacturing or maintaining the medical device.

Software as a Medical Device Introduction

The International Medical Device Regulators Forum (IMDRF) defines SaMD as “software intended for one or more medical purposes that perform those purposes without being part of a hardware medical device.”

FDA defines SaMD as “Software that meets the definition of a device in 181 section 201(h) of the FD&C Act and is intended to be used for one or more medical purposes without being part of a hardware device.”

The use of SaMD is experiencing a steady rise, with its application extending to various technology platforms such as medical device platforms, commercial “off-the-shelf” platforms, and virtual networks, among others.

This kind of software was previously referred to as “standalone software,” “medical device software,” or “health software” by industry professionals, international regulators, and healthcare providers, often leading to confusion with other software categories.

How Do I Know if My Product is SaMD?

As a member of the International Medical Device Regulatory Forum (IMDRF), the FDA recognizes the structural similarity between the two organizations’ definitions of SaMD. The definitions provided by the FDA and IMDRF highlight two criteria that must be satisfied for software to be designated as SaMD.

To evaluate if the Software is a medical device, it is important to assess its compliance with the regulatory authority’s definition. The IMDRF emphasizes that the Software must be “intended for one or more medical purposes”. On the other hand, the FDA references FD&C, or the Federal Food, Drug, and Cosmetic Act, Section 201(h),  which outlines the definition of a device. This section defines a device as follows: 

According to Section 201(h) of the FD&C, a device encompasses various articles such as tools, implements, instruments, machines, devices, appliances, in vitro reagents and other similar or related items, including components and accessories.

1. An article must also be legally recognised in the National Formulary, the United States Pharmacopoeia, or an analogous revision in order to meet the requirements of Section 201(h) of the FD&C Act’s definition of a device.     

2. The product is intended to be used in the diagnosis of disease or other conditions as well as in the treatment, mitigation, treatment, or prevention of disease in people or animals, according to the definition of a device under FD&C Section 201(h).   

3. In addition, a product must be intended to change any structure or function of the human or animal body without compromising its primary function for it to qualify as a device under Section 201(h) of the FD&C Act.

In addition, the definition of a device in Section 201(h) of the FD&C Act states that it must not achieve its primary purpose by chemical action in or on the human or animal body, nor must it rely on metabolism to achieve its purpose.

Note that the term “device” does not include software features that are excluded by Section 520(o). To apply this definition, it is essential to establish the intended use and indications for the use of your product. To refresh your understanding,

1. The intended use of a device refers to its designated purpose or the specific function for which the device is intended to be utilised. In other words, it defines the intended or intended application of the device.

2. Indications for use pertain to the diseases or conditions that a device is designed to diagnose, treat, prevent, cure, or mitigate. These indications specify the target patient population and provide insights into why the device would be used on individuals with those diseases or conditions.

Once the intended use and indications for the use of your product are defined, the second and third points in the FDA’s definition of a medical device will help determine whether your product falls under the regulatory scope of a medical device. These criteria will clarify whether your product meets the requirements for medical device regulation.

If you intend to market your software product in the United States, I recommend carefully reviewing the FDA’s guidance on Policy for Device Software Functions and Mobile Medical Applications.

This guidance provides valuable insights into the specific software functions that the FDA classifies as medical devices and functions that are not considered medical devices and, therefore, not subject to FDA regulation. Familiarizing yourself with this guidance will provide you having a thorough awareness of the regulatory environment for software products in the medical field.

If you’re still unsure about whether your product qualifies as a medical device, contacting the FDA directly for clarification is safest. Contacting the FDA now will provide reliable advice and ensure you receive accurate information tailored to your specific product and situation.

Is My Software Considered SaMD or SiMD?

When a product is found to fit the definition of a medical device, the second portion of the IMDRF and FDA definition of software as a medical device (SaMD) must be taken into account.

1. According to the IMDRF definition, Software must be used for its intended purpose only and must not be an integral part of a physical medical device.  

2. According to the IMDRF, the FDA makes it clear that Software as a Medical Device (SaMD) is not a part of a hardware device and is instead intended for standalone usage for one or more medical purposes.

This further limit the scope of Software as a medical device (SaMD), as the Software used to operate or control a hardware device does not fulfil the requirements to be categorised as a SaMD. Instead, this type of Software is referred to as SiMD or “software in a medical device.”

Examples of Software as a Medical Device

That assist in operating a hardware medical device, which falls under the category of Software in a Medical Device (SiMD) and not Software as a Medical Device (SaMD):

1. Software that controls the inflation or deflation of a blood pressure cuff

2. Software that controls the delivery of insulin on an insulin pump

3. Software used in the closed-loop control of a pacemaker.

“firmware,” or “micro-code,” indicating their classification as SiMD rather than SaMD.

Understanding the Criteria for Software as a Medical Device (SaMD)

To qualify as SaMD, a product must have standalone Software that independently carries out the functions defining it as a medical device, distinct from any associated hardware. The IMDRF guidance on “Possible Framework for Risk Categorization and Corresponding Considerations” further provides additional insights and clarifications regarding the SaMD definition.

1. SaMD is a medical device, including in-vitro diagnostic (IVD) medical devices.

2. SaMD can run on general-purpose computing platforms not specifically designed for medical purposes.

3. “Without being part of” means the Software is unnecessary for a hardware medical device to achieve its intended medical purpose.

4. Software intended to drive a hardware medical device does not meet the definition of SaMD.

5. SaMD can be combined, such as being integrated as a module, with other products, including medical devices.

6. SaMD can interface with other medical devices, including hardware medical devices, other SaMD software, and general-purpose Software.

7. Mobile apps that meet the defined criteria are considered SaMD.

Although it is crucial to distinguish between Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD), both types of Software adhere to many common standards for development, including the global standard for software lifecycle procedures is IEC 62304.  lifecycle processes.

If your Software falls under the category of SiMD, you will still find the guidance documents and standards outlined in this guide valuable and applicable.

What are Some Examples of SaMD?

1. Software that enables a mobile device to view diagnostic images from MRI, ultrasound, or X-ray scans.

2. Software that utilizes image processing techniques to aid in detecting breast cancer.

3. Software that diagnoses a medical condition by analyzing data from the tri-axial accelerometer on a smartphone.

4. Software that collects real-time patient data monitored by a healthcare professional and utilized to develop treatment plans.

Clinical Evaluation

Clinical evaluation is a methodical and well-organized process that creates clinical evidence by continuously creating, collecting, analyzing and evaluating clinical data on SaMD to create clinical trials that review the clinical context and performance indicators of SaMD.

The quality and scope of the clinical assessment is based on the SaMD function for the clinical objective, which also ensures that the SaMD   score is clinically valid and can be used consistently and predictably. 

3 Clinical Evaluation Software

To qualify the software, the following three criteria must be met. To qualify your software, you must meet the three criteria outlined below.

1. Valid Clinical Association of a SaMD

2. Analytical/Technical Validation of a SaMD

3. Clinical Validation

1. Valid Clinical Association of a SaMD

Verifying that your software’s output corresponds to the targeted clinical conditions is the main goal here. Use of secondary data analysis, clinical trials (new data generated), professional society guidelines, original clinical research, literature searches, and/or secondary data analysis are all options for carrying out that task. All SaMD should show a reliable clinical association.

2. Analytical/Technical Validation

Does your software correctly process input data to generate accurate, dependable, and precise output data?” is the question we are attempting to answer in this context. Develop supporting documentation that demonstrates your SaMD’s output met your expectations in terms of technicality.

This action is being assessed by a manufacturer as part of the software’s validation and verification phase (V&V).

3. Clinical Validation

SaMD has been evaluated in your target population and for your intended use; users are able to achieve clinically significant results through consistent and dependable use.