Advancements in technology over the past several decades have naturally led to advancements in healthcare. Software as a medical device (SaMD) is particularly poised for growth with one of the latest advancements: the Internet of Things (IoT). Because of this and other factors, the SaMD market is expected to grow at a compound annual growth rate of 21.9 percent from 2020 to 2027, bringing the value to just over $86 million. This growth represents potential lifesaving innovation for providers and patients. However, for manufacturers, especially those that are new to SaMD, it represents new complications in regulatory affairs and risk management.


Software as a Medical Device

Software as a medical device is a product that meets certain criteria. In order to be considered SaMD, a device must match at least one, but not all, of these descriptions:

  • It must be capable of running on general-purpose (nonmedical purpose) computing platforms.  
  • If it is connected to a hardware medical device, but the software is not necessary for the device to achieve its intended medical purpose, it is considered SaMD.
  • The software may be used in combination (e.g., as a module) with other products, including medical devices.
  • It may be interfaced or wirelessly connected with other medical devices, including hardware medical devices, cell phones, tablets, and other SaMD software, as well as general-purpose software.

Examples of SaMD include: 

  • Imaging analytics software for X-ray or CT machines
  • CAD software that performs image post-processing to help detect breast cancer
  • Monitoring analytics software (for example, heart or blood glucose monitor)
  • Mobile apps that meet the definition of SaMD

There’s also an important distinction between software as a medical device (SaMD) and software in a medical device (SiMD). If the software embedded into a physical device is necessary for that device to achieve its intended purpose, it is not considered software as a medical device; it is an accessory to the hardware medical device. Examples include:

  • Ventilators
  • Drug delivery pumps
  • Software used in a closed-loop control in an implantable pacemaker
  • Electromechanical auto injectors such as the Enbrel Mini Cartridge with AutoTouch Autoinjector 
  • Neulasta Onpro chemo treatment

Although there are many nuances between the ways SaMD and SiMD are treated from a regulatory perspective, the primary difference is related to risk—SaMD risks are related to patients, and SiMD risks are related to device hardware.


International SaMD Regulation

The International Medical Device Regulators Forum (IMDRF) sets the worldwide standard on how to categorize software as a medical device from a risk management perspective. The IMDRF categorization framework categorizes the risk of SaMD in levels based on a matrix that includes what the device is doing:

  • Treating or diagnosing
  • Driving clinical management 
  • Informing

And the healthcare situation or condition:

  • Critical
  • Serious
  • Nonserious

According to the framework, the four categories (I, II, III, and IV) are in relative significance to each other, with category IV having the highest level of impact and category I the lowest. The definition of each category is “based on the levels of impact on the patient or public health where accurate information provided by the SaMD to treat or diagnose, drive or inform clinical management is vital to avoid death, long-term disability or other serious deterioration of health, mitigating public health.”

State of healthcare situation or condition

Significance of information provided by SaMD to healthcare decision

Treat or diagnose

Drive clinical management

Inform clinical management














SaMD Regulation in the EU

Device Classification

Software as a medical device is classified in the same way as all medical devices under EU MDR (Classes I, IIa, IIb, and III) and IVDR (Classes A, B, C, and D). As with all other types of devices, classification depends on the intended purpose of the device and its inherent risks. MDCG 2019-11 is the guidance document that addresses medical device classification, including software on page 27. Annex IV also includes SaMD classification examples based on the IMDRF framework.

Software Safety Classification

When it comes to risk evaluation, EU MDR and IVDR use the harmonized standard ISO 62304 with the following categories:

  • Class A - No risk of injury or damage to health
  • Class B - No risk of serious injury or death, but nonserious injury is possible
  • Class C - Potential risk of serious injury or death

To meet the ISO standard, the process includes a questionnaire that indicates how much rigor needs to be put into software documentation and development based on the level of risk. For European-marketed devices or software, you must also have a certificate of conformance from a notified test body for IEC 62304.


SaMD Regulation in the U.S.

Device Classification

In the U.S., software as a medical device has the same FDA device classification (Classes I, II, and III) for any type of medical device or IVD. Classification is based on the risks and the regulatory controls necessary to provide a reasonable assurance of safety and effectiveness.

Risk Categorization

FDA approaches risk categorization classification based on the level of concern similar to the classes found in ISO 62304 document but with different terminology:

  • Major - A failure or flaw could result in death or serious injury or could delay care and result in death or serious injury
  • Moderate - A failure, flaw, or delay in care could cause nonserious injury
  • Minor - Unlikely to cause injury to patient or operator (may cause inconvenience)

The level of concern indicates how much and what type of documentation is required for a regulatory submission and how much rigor your software lifecycle development process requires internally. This might include a Software Requirements Specification (SRS), Software Design Specifications, and so on.

Submission Guidance

On November 4, 2021, FDA issued the draft guidance document: "Content of Premarket Submissions For Device Software Functions."  Device software function as defined in the guidance applies to both SaMD and SiMD.  

The guidance details recommended documentation for premarket submissions in two documentation levels - basic and enhanced - based upon four risk-based factors. The purpose of the documentation level is to help identify the minimum amount of information that would support a premarket submission that includes device software functions.


Considerations for Manufacturers

Manufacturers that currently market software as a medical device or are considering developing products that fall under the definition of SaMD must consider many factors. 

Lifecycle Management

Post-market activities are the same as for any other type of medical device. Once a SaMD product has gone to market, it’s treated identically to other devices of the same class. This means that you must have a plan in place for adverse event reporting and other required post-market activities.  

Facing Challenges with Post-Market Phase

Think about how you will capture all of the necessary information for post-market activities, and create systems for incorporating that information into your documentation consistently. Not a lot of manufacturers are thinking about whether they’re capturing this information in the right way, and it’s common for companies to have their own process or grading system that doesn’t take into account notified body requirements.

Integrating Classifications into QMS and Risk Management

When developing SaMD, consider the device classification early in the process so you can integrate it into your other systems accordingly. When integrating into your QMS:

  • Start with the basic checklist of ISO 62304.
  • Create a list of all products and see where you have it in basic lifecycle processes.
  • Add a separate column to see where the basic touch points are with your QMS.

Understanding How SaMD Is Different

Manufacturers that are new to SaMD find it especially challenging to understand how it is different from regulating a traditional physical medical device. It’s important for team members in every department and at every level to know that the processes used for physical devices do not apply to software as a medical device. 

Software Risk Management 

Risk management is also different for SaMD and cannot be approached in the same way as physical devices. For example, failures have completely different consequences, and if one issue arises, it has the potential to affect all users. When executing risk controls, the level of due diligence put on high-risk items is extremely important.

AI and Machine Learning

The new wave of SaMD incorporates artificial intelligence and machine learning. Regulators are preparing for it, and manufacturers should do the same. Start by reading the FDA action plan to get a sense of where the industry is headed.  


Both manufacturers and regulators are paying more attention to cybersecurity, especially as more connected devices emerge on the market. Make sure you’re integrating cybersecurity into the development process and addressing it in risk management documentation. Some resources to reference include:


How RQM+ Helps

Whether you’re new to SaMD or simply overwhelmed with regulatory affairs, our team is here to help. We’ll work closely with your team to appropriately classify software as a medical device, identify gaps in your processes and documents, and implement solutions. With global expertise and a deep understanding of the regulatory landscape, our team can help guide your SaMD efforts from strategy to execution.

To learn more about how our team approaches technical documentation from the perspective of notified bodies, watch our MDR clinical evaluation roadmap interview with Dr. Jai Kutty.

New call-to-action

We are passionate about your success. Tell us more about your regulatory and quality needs to learn about how we can help.

Book a Consultation


To display custom copy instead of global copy in this section, please go to Show Global Content for Bottom CTA? toggle in the "Contents" tab to the left, toggle it off, save, and then REFRESH the page editor, the custom text will then show up and ready to be edited.

Turning the global content back on will be the same process, go to the toggle and toggle it back on, save and refresh!