Software As A Medical Device (SaMD) Regulatory Considerations

Introduction: What is SaMD?

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." Software clearly needs hardware to run on, but in this case that hardware is general purpose platforms, such as a PC, mobile device or server. The software can process the output (ex: radiology images) from a medical device as long as it is not part of the device (i.e. necessary to achieve the device's intended purpose). SaMD cannot drive a medical device - that software is considered part of the device. But it can interface with the device.

Some examples of SaMD devices include:
  • Software used to diagnose a condition using a digital camera.
  • Software that analyzes a patient’s medical history and diagnostics data to determine the correct drug dosage (ex: input from a blood glucose meter to determine insulin dose).
  • Software that collects data from multiple wearable health sensors and identifies higher-level conditions such as tachycardia or respiratory infections.
  • Software that performs image processing to detect cancer.
  • Software that can anticipate an occurrence of an asthma episode.


Key Regulatory Requirements:

Overall, the regulatory requirements for a SaMD follow the same requirements as a traditional medical device, but without the electro-mechanical part, and a few SaMD specifics. The sections below summarize the key elements of the SaMD submission.

Definition Statement and Risk Categorization

The definition statement is where you, the manufacturer, state the intended Medical Purpose of your SaMD. Is it to Treat or Diagnose? Is it driving clinical management or informing clinical management. What is the significance of the information the SaMD provides to a healthcare decision? What is the state of the situation/condition? Critical? Serious? Non-serious?

From this information the risk is categorized into four levels, with category IV being highest impact, and I being lowest.  The chart below describes how how these categories are established:

This categorization establishes the risks associated with the SaMD and the scrutiny of the design controls and clinical evaluation in the submission.

Risk Management

The risk management process follows ISO 14971 with the software specifics defined in IEC 62304. As for all software for medical devices, identification of software that could contribute to a hazardous situation must be analyzed. What would a bug in the critical part of the software potentially cause? Could the software be misused in a way that would be dangerous? What would be the consequences of unexpected behavior of 3rd party libraries (SOUP)? These are the types of questions the analysis should be asking to determine the risks. Risk control measures can be applied to reduce the risk, and proof of verification of these measures needs to be provided.


Cybersecurity is a big part of the SaMD risk management because of the connectivity generally provided, and the general purpose nature of the platforms on which they run. The FDA has a comprehensive draft (at time of writing) premarket guidance for the "recommendations" of the agency around the Cybersecurity. It has been our experience that these are requirements, and indeed a major focus of the FDA in submissions. With the number of hospitals getting attacked, it is no wonder that the FDA wants to make sure the devices are not vectors of attacks, and SaMD is no exception. Cybersecurity threat modeling and risk analysis, as well as thorough descriptions the design controls used to address the risks is required.

Cloud software cybersecurity can and should be certified for any vendor used. SOC2, HiTrust, or ISO 27001 certification ensures the cloud security design and processes are in place to safeguard information.

Application of a Quality Management System

For medical devices, quality management system requirements are generally pretty clear to manufacturers. But with the introduction of SaMD and its closeness to general non-regulated health apps, it sometimes gets lost to the SaMD provider that the Quality Management Principals must be applied. IEC 13485 provides the regulatory requirements of medical device quality management systems, and its implications to the organization and lifecycle processes must be followed. ISO 13485 certification of your software provider ensures that indeed the principals and controls are in place.

Clinical Evaluation:

Clinical Evaluation includes the proposed association between a SaMD output and a Clinical Condition. What evidence, research, literature, data analysis and clinical trials support the assertions? This is followed up by the proof of performance, showing the accuracy, reliability and precision of the results, along with the clinical validation displaying that the output data achieves the intended purpose in the context of clinical care.

Evidence demonstrating a clinical association, with analytical and clinical validation must be provided. We have seen startups swayed by claims by providers (ex: blood pressure measurements using a mobile video camera), but without supporting data proving the claim, it will not get through the regulators.

SaMD often provides a pathway for post-market continuous improvements leveraging real-work performance data. Changes in the clinical evaluation or definition may necessitate a new 510k.

Artificial Intelligence/Machine Learning (AI/ML)

Regulators are grappling with AI/ML. To ensure patient safety, typically only "locked" algorithms have been accepted - learning stops before final test and production. But the regulators do recognize that adaptive/continual learning when post-market is incredibly powerful and has the ability to be transformative. A total product lifecycle (TPLC) approach is being considered by the FDA. After publishing a framework for review, they recently drafted an Action Plan to address Artificial Intelligence and Machine Learning. They plan to update their proposed framework and issue guidance on Predetermined Change Control - How the machine learning algorithm will change through learning while remaining safe and effective. Harmonization of Good Machine Learning Practice (GMLP) will be encouraged describing the set of best practices. Regulatory science efforts to develop methodologies for improvements that can identify and eliminate bias will be supported. And overall a Patient-centered approach will be necessitated. Stay tuned.

Need help on this topic?
Contact Us
Frances Cohen

Frances Cohen is President of Promenade Software Inc., a leading software services firm specializing in medical device and safety-critical system software. Frances has more than 20 years of experience leading software teams for medical device software. Starting with heart defibrillators for Cardiac Science  and following with  Source Scientific LLC and BIT Analytical Instruments Inc., Frances has overseen dozens of projects through development and the FDA, including IDEs, 510(k)s, and PMAs.  

Frances has a B.S. in computer engineering from the Technion, Israel Institute of Technology.

linkedin logo
16 Technology Drive, Suite 100
Irvine, CA. 92618, U.S.A.
linkedin logo
twitter logo
facebook logo
linkedin logo
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Promenade Software, Inc. specializes in software development for medical devices and other safety-critical applications.
Promenade is ISO 13485 and CyberMed • Cloud is SOC2 Type II certified.

American Systems registrarSOC2 Type 2 Logo