What is Software as a Medical Device (SaMD)?

Medical devices are a big business covering a wide range of modalities and applications. To ensure the safety of these devices, the Food and Drug Administration (FDA) publishes guidelines and regulations that assess the safety and efficacy of new devices that go to market.

In an August 2016 publication, the FDA released a draft guidance document which details its current thinking on one of the fastest growing trends in medical devices: Software as a Medical Device, or SaMD.

This article highlights the most crucial aspects of this document from the standpoint of medical device manufacturers. The new guidance on SaMD clarifies how existing regulations can be applied to software medical devices, including a newly proposed categorization framework. This draft guidance should be seen as an update for earlier guidance documents that accounts for new trends and concerns in the SaMD industry.

Free Download: Click here to learn which factors influence how a SaMD is classified.

Scope and Definition of SaMD

Let’s first ensure we understand what a SaMD is, and how this term distinguishes medical device software applications from other types of medical devices.

The definition of SaMD given in the draft guidance published by the FDA was pulled from a document entitled “Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations”.

This report was released by the International Medical Device Regulators Forum (IMDRF) in 2014, in hopes of establishing a categorization method for SaMD that accounts for the risks associated with implementing SaMD in various clinical contexts, along with appropriate considerations for SaMD during its lifecycle (requirements, design, development, testing, maintenance, and use).

I want to be totally clear on this part: the IMDRF created this report to inform the future of SaMD regulation worldwide, and the recent report by the FDA means that enhanced regulatory requirements are in the pipeline.

The FDA currently defines medical devices as:

“any apparatus, appliance, software, material, or other article intended by the manufacturer to be used for human beings for the purpose of:

• Diagnosis, prevention, monitoring, treatment, or alleviation of disease;
• Diagnosis, monitoring, treatment, alleviation, or compensation for an injury or handicap;
• Investigation, replacement, or modification of the anatomy or of a physiological process;
• Control of conception; and which does not achieve its principal intended action in or on the human body by pharmacological, immunological, or metabolic means, but which may be assisted in its function by such means

Software medical devices take on a narrower definition that the FDA has adapted from the 2014 IMDRF report, where SaMD is defined as: “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device”.

The important distinction here is that the software doesn’t meet the definition of SaMD if its intended purpose is to power a hardware medical device. It may interface with other physical devices, but a SaMD must run on general computing platforms (or mobile devices), and may be used in combination with other medical devices.

Some examples of SaMD devices are:

• Software intended to diagnose a condition using an accelerometer in a digital camera
• Software that allows MRI and other types of medical imaging to be viewed on regular mobile devices
• Software that performs image processing in to detect cancer
• Treatment planning applications that supply information
• Software that regulates an installed medical device, like a pacemaker
• BMI and body fat calculators, and heart rate monitors

Understanding Categorization of Software Medical Devices

The main reason for the latest publications on SaMDs by both the FDA and IMDRF is to bridge regulatory gaps that have resulted from the proliferation of app development and smartphone usage.

In the last decade, while the FDA struggled to address reliability and safety compliance issues with the software embedded in medical devices, thousands of standalone health and medical applications appeared which seemed to fall under no existing regulations.

The FDA’s draft guidance document describes the need for clinical evaluations of all SaMD applications, describing the same as a process activity that is conducted during a product’s lifecycle as part of the quality management system. Developers who code software for medical applications will be expected to assess and analyze clinical data and verify its safety, effectiveness, and performance.

Accordingly, the categories for software medical devices distinguish software applications across two key dimensions:

• Significance of Information – Devices that are used directly in the treatment or diagnosis of patient illnesses are expected to obtain higher standards of clinical evidence, including obtaining both scientific and analytical validity, as well as assessing clinical performance. Applications that drive, or merely inform clinical management are associated with less stringent validation requirements.
• State of Disease – When a SaMD is used as an intervention for critical disease, it must be tested more rigorously than if its intended use is in detecting non-serious illnesses.

Accordingly, the FDA designates four separate categories for SaMD, each with its own characteristics and unique requirements for clinical evaluation:

Consider the safety requirements for an application that regulates an installed pacemaker (critical function) versus those of a visual recognition app that’s used in the home to diagnose skin conditions (non-serious).

In the first case, the software is involved in the application of critical ongoing therapy to a human being, and a device failure could potentially trigger a life-threatening situation. For the second case, however, the targeted diseases are non-serious and the information provided is meant to help inform a patient, not to provide a diagnosis or treatment plan.

You can view the full validity requirements for each category of SaMD here.

Free Download: Click here to learn which factors influence how a SaMD is classified.

Summary

When the FDA releases new draft guidance for software development, we essentially get an inside look into how the agency thinks about SaMD and how their expectations will be applied to SaMD companies in future audits.

Indeed, the FDA document indicates that requirements management, design, development, verification and validation, deployment, maintenance, and decommissioning should all be aspects of an effective SaMD QMS - and therefore would be assessed in an FDA audit.