What is the Difference Between SiMD and SaMD?

Published:

Content Type:

Blog

Author Info:

Topics:

Related Services:

The World Health Organization (WHO) estimates that there are around 2 million different types of medical devices in the world which are categorized into over 7,000 generic device groups.[1] Medical devices are used for a variety of purposes, including diagnosing illness, monitoring treatments, assisting disabled people, and treating acute and chronic illnesses.[2] The average hospital in the United States has 10 to 15 medical devices per bed.[3] The US medical equipment and supplies distribution industry includes more than 10,000 establishments (single-location companies and units of multi-location companies) with a combined annual revenue of about $230 billion.[4]

Over the last 25 years, the amount of software used in and around medical devices has increased. We have seen an acceleration in this trend, thanks to the emergence of the “internet of things” (IoT) and the availability of a multitude of commercial off-the-shelf platforms such as personal computers, smartphones, virtual networks, wireless connectivity, cheaper and better sensors, cloud computing, big data, artificial intelligence (AI), and machine learning (ML). This is transforming how work gets accomplished across every industry.

As software is becoming a more crucial component in medical devices and pervasive in healthcare, the good news is that the FDA has recognized the need to guide the MedTech industry with white papers and guidance about the design and development of digital health devices. The existing regulations address public health risks of software when embedded in an established medical device and they have recognized that their “traditional approach to moderate and higher risk hardware-based medical devices” is not well suited for the faster iterative design, development, and validation used for “software device functions.”

Updating Guidelines

To keep up with this evolution, the FDA published a guidance document “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act”. This provided the MedTech industry with the FDA’s current thinking regarding the amended device definition related to medical device software. The FDA refined what software functions are excluded from the definition of a device. This resulted in new guidance and minor updates to current guidance documents affecting software to better align with this evolution of software.

The FDA updated and released a guidance document titled “Policy for Device Software Functions and Mobile Medical Applications” issued Sept 27, 2019, which replaced the previous version issued in 2015. The FDA has previously clarified that when a software application is used to analyze medical device data, it has traditionally been regulated as an accessory to a medical device or as medical device software. The guidance further defines for traditional medical devices the certain software functions that are device functions (now referred to as “device software functions”)–those functions that can pose potential risks to public health. For example, software function(s) (typically mobile apps) that transform a mobile platform into a regulated medical device are the focus of the FDA’s regulatory oversite. They vary depending on the intended use and software functions. SaMD ranges from software that allows a smartphone to view images obtained from a magnetic resonance imaging (MRI) medical device for diagnostic purposes to Computer-Aided Detection (CAD) software that performs image post-processing to help detect breast cancer. Because SaMD and medical devices so often work together contributes to why SaMD and SiMD are often confused.

To better understand the differences between SaMD and SiMD, the focus will be on how to determine if your device is a SaMD. It is important to remember that SaMD is not software that supports the functioning of medical device hardware (that’s SiMD).

Does Your Device Qualify as SaMD?

Rule 1: It Qualifies as a Medical Device

The FDA regulates software which meets the definition of a device as specified in section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act)

According to the International Medical Device Regulators Forum (IMDF), a medical device is “an instrument, apparatus, implement, machine, contrivance, implant, or in vitro reagent,” used alone or in combination for one or more medical purposes.

What does this mean?

  • There is a medical benefit to its use
  • There is a patient risk if it malfunctions or is used incorrectly
  • It can be used to inform, prevent, diagnose, monitor, treat or alleviate disease
  • It does not achieve its intended primary action by pharmacological, immunological, or metabolic means
  • It can provide patient data, and informs healthcare providers of options for treating, diagnosing, preventing, or mitigating a disease

Rule 2: It Can Be Used as a Standalone Device

There are two different types of software related to medical devices: Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD). Only SaMD can function on its own.

> SaMD is a standalone medical device and can perform one or more medical purposes without being part of a hardware medical device.

Examples Include:

  • An app that calculates appropriate insulin dosage based on a person’s blood glucose levels
  • Software that draws data from other digital devices to determine risk factors associated with epileptic seizures
  • Software that uses artificial intelligence to look at MRI image to identify anomalies missed by other diagnostic tools (like an electrocardiogram)
  • Software required by a hardware medical device to perform the hardware’s medical device intended use, even if sold separately from the hardware medical device
  • Software required by a hardware medical device to perform the hardware’s medical device intended use, even if sold separately from the hardware medical device

> According to the US Food and Drug Administration (FDA), SiMD refers to software that is incorporated into a medical device to control its performance or provide specific functions. SiMD is also known as embedded software, firmware, or microcode.

Examples Include:

  • Software embedded in a pacemaker, defibrillator that monitors heart rhythm, calculates responses, and delivers electrical impulses
  • Software that powers infusion pumps, glucose meters, and smart pens
  • A mobile application that is the primary interface for reading continuous waveform data from an implanted or wearable EKG loop monitor
  • Software required by a hardware medical device to perform the hardware’s medical device intended use, even if sold separately from the hardware medical device

While it will not be replacing doctors anytime soon, SaMD nevertheless represents an increasingly critical tool to better treat patients. By helping with aspects of care that can be automated using the latest technology, SaMD can help reduce inefficiencies, improve access, reduce costs, increase quality, and make medicine more personalized for patients.

SaMD’s Defining Characteristics Include:

  1. Improved health outcomes powered by data: SaMD can amplify the effectiveness of medical devices and existing treatment plans as it enables easy and fast collection of high-quality data — which leads to better health outcomes.
  2. Faster production and feedback to drive faster innovation: SaMD enhances and builds on existing medical device functionality through software solutions that are faster, and often cheaper, to update than hardware. It also utilizes the latest technologies to integrate and share health data across various platforms, including the cloud, connected medical devices, smartphones, and more.

Because SaMD can collect large amounts of data quickly, it can also easily solicit user feedback through its availability on, for example, mobile platforms. For companies using or developing SaMD, this fast feedback loop can enable quicker product iterations, shorten time to market, and drive faster innovation.

Software in a Medical Device (SiMD)

The SiMD category is often confused with SaMD; however, if the software in question helps in any way to run a medical device, it is SiMD. Software that powers the functions or performance of a medical device or processes the information that is produced by a medical device is considered SiMD. Also, software that controls the device remotely is SiMD. However, what can be confusing is when SiMD has some of the characteristics of SaMD. For example, SaMD almost always involves some level of internet or wireless connectivity. However, if software helps create that connectivity through WiFi or Bluetooth, it is considered SiMD, as it is a software component within a SiMD.

Regulatory Requirements for Software

Prior to placement of medical devices on the U.S. market, a company must have a documented quality system compliant to the FDA’s Quality System Regulation (QSR) as defined in 21 CFR part 820. If the medical device includes software functions, then the internationally accepted framework for lifecycle processes for medical device software is IEC 62304. This standard defines the processes, activities, and tasks used in the development and maintenance of medical device software. IEC 62304 defines software development lifecycle (SDLC) activities except for design validation of the finished device, i.e., the process for confirming software specifications conform to user needs and intended uses. Design validation is covered by IEC 60601-1 for the software in medical electrical equipment or IEC 82304-1 for software-only products.

IEC 62304 defines processes not development techniques. The standard for quality management systems, ISO 13485 and the US (FDA) CFR 820.30 and guidance on design controls, suggest the design control sequences. The Technical Information Report (TIR) AAMI TIR45 for agile software development is widely used and accepted and is supported by the FDA.

Now that you have an understanding of the basic differences between SiMD and SaMD, there may still be some confusion about what constitutes a “medical device software function”. The best practice is to ask yourself the questions provided in rule 1 and 2. If you have determined your device’s intended use, proposed claims, then best practice would be to generate a regulatory strategy to support your decision on the medical device software function type along with the proper performance testing needed to establish the software as safe and effective.

[1] World Health Organization. Medical devices. 2022. Available at: https://www.who.int/health-topics/medical-devices#:~:text=Such%20health%20technologies%20are%20used,than%207000%20generic%20devices%20groups.

[2] World Health Organization. Medical devices. 2022. Available at: https://www.who.int/health-topics/medical-devices Accessed 7 March 2022

[3] A Corrective Maintenance Management System in a Hospital, Oct.27, 2022;https://www.autymate.com/blog/a-corrective-maintenance-management-system-in-a-hospital

[4] Medical Equipment & Supply Wholesalers Industry Profile, July 15, 2024; https://www.firstresearch.com/Industry-Research/Medical-Equipment-and-Supply-Wholesalers.html#:~:text=The%20US%20medical%20equipment%20and,revenue%20of%20about%20$230%20billion


Monica R. Montanez

Monica R. Montanez

Monica R. Montanez, MS, RAC, CQA currently serves as NAMSA's Principal Strategy Consultant. Monica has over twenty years’ experience in the medical device industry in Regulatory Affairs and Quality Assurance. Her primary focus is navigating the regulatory pathways for electro-mechanical and software driven medical devices worldwide. She has received clearance of many 510(k)s and approval of new indications for PMA device(s) of which 90% involved software. She has broad regulatory expertise in several areas of digital health, including: Software in a Medical Device (SiMD), Software as a Medical Device (SaMD), mobile medical apps, clinical decision support software, telehealth, artificial intelligence, machine learning, interoperability, cybersecurity and human factors engineering, including wireless medical devices -radio frequency (RF), electromagnetic compatibility (EMC) and electromagnetic interference (EMI). While in industry, she assisted in the development of FDA 510(k) guidance and FDA Software guidance directly with FDA. Monica holds a Masters of Science (MS) degree in Regulatory Science (RS) from the University of Southern California (USC) School of Pharmacy. Currently. she holds Regulatory Affairs Certification (RAC) from the Regulatory Affairs Professionals Society (RAPS) and Certified Quality Auditor (CQA) from the American Society for Quality (ASQ).