SaMD, or Software as a Medical Device, is not just another mobile app. It is a new category of medical device that has particular regulatory considerations and is at the forefront of some of the most innovative new healthcare technology.
According to the International Medical Device Regulators Forum (IMDRF), Software as a Medical Device 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.” So if the software is running in a medical device then it isn’t SaMD (it would be traditional “SiMD”) and if the software doesn’t have a medical purpose (diagnostic or therapeutic) then it’s just plain software. SaMD can be software in the cloud, software on a mobile device, or software on a PC, or a combination of all three; it’s not any one software technology that makes it distinctive but its use.
Benefits and Applications
Many innovative healthcare technologies today are being developed as software-only products. Companies are leveraging the availability of powerful, general purpose computing platforms, such as cloud and smartphones, and highly interconnected systems to rapidly develop new SaMD products.
Many SaMD products are diagnostic: intended to assist a physician in making a diagnosis (for example, powerful data analytics applied to physiological measurements like a patient’s EKG or to medical images like a chest x-ray). Other SaMD products are therapeutic: for example, in assisting patients with managing chronic diseases like diabetes or neurological disorders and offering treatment in a way that is customized to the patient’s specific needs.
SaMD products can be designed from the start to interface with other software systems, which enables them to collect and aggregate large data sets quickly. By contrast, most traditional hardware medical devices are difficult or impossible to interface with. Combining data analytics with an interface operating on hand-held mobile devices, these SaMD products can bring tremendous analytical power and data into the hands of clinicians (and patients).
Because SaMD products have no hardware, a new product development team does not have to deal with the enormous costs of developing a new manufacturing line and establishing a robust supply chain. Development resources can be focused instead on software feature design, software testing, and clinical evaluations leading to more rapid innovation. But with this rapid innovation comes new challenges.
Challenges
Developing an SaMD product sounds much easier than a hardware medical device but SaMD products have their own characteristic challenges. Here are the key ones.
Frequent software updates
A company cannot just release an SaMD and consider it finished until the next version comes out next year. Without the limitations of hardware manufacturing, SaMD products are expected to be updated frequently with additional features and enhancements. And because they involve interfaces and third party software (libraries, OS, etc.), they have to be updated regularly just to maintain interoperability. This means the company has to be able to manage design changes efficiently and rigorously at a rapid pace, including quickly and securely pushing out updates to all of the customers. Most established medical device companies have a quality system that was built around hardware products which will struggle to keep pace with SaMD changes.
Security and privacy
Any connected medical device needs security protections. SaMD by their very nature are connected and so security considerations loom large, both during development and after launch. If an SaMD product involves patient data then additional privacy protections will be needed to ensure confidentiality. This translates to a company which needs to be organized for continuous product monitoring and ready to respond rapidly to any security or privacy issues that arise during the product’s lifetime.
Evolving regulations
Many SaMD involve machine learning or artificial intelligence algorithms (ML/AI). Medical software that learns and evolves doesn’t fit readily into traditional regulatory frameworks. The FDA has recognized this and is developing new regulations and guidance. Currently, that means companies need to carefully study FDA draft documentation and presentations (and ask lots of questions during an FDA pre-sub mtg) to understand what’s needed for regulatory approval and ongoing compliance.
Integrating two worlds
There’s one more key challenge that isn’t a matter of technology or quality system procedures–it’s the challenge of integrating two very different worlds. Many SaMD products are developed by teams consisting of a mix of people with a medical device background and people coming from an unregulated software background. These two groups can have very different ways of developing and maintaining software. Those with a medical device background will understand how to work within a quality system and navigate through regulatory constraints. Those from an unregulated software background will understand how to manage very complex products and rapidly and efficiently update the released software. Taking the time early in a project to integrate and align team members from these two very different backgrounds can make the difference between getting the best of both worlds and getting frequent conflict and misunderstandings.
How Much Documentation Is Needed?
The level of control of SaMD products and therefore the amount of documentation depends on their intended use and the risks associated with it. In general, you need to consider whether the output of the SaMD is being used to treat or diagnose, whether it will drive clinical management or just inform it, and what is the seriousness of the patient’s disease. For example, here are three types of SaMD in increasing order of risk (lowest to highest) from the IMDRF risk categorization guidance:
- SaMD that sends ECG rate, walking speed, heart rate, elapsed distance, and location for an exercise-based cardiac rehabilitation patient to a server for monitoring by a qualified professional;
- SaMD that analyzes heart rate data intended for a clinician as an aid in diagnosis of arrhythmia;
- SaMD that performs diagnostic image analysis for making treatment decisions in patients with acute stroke, i.e., where fast and accurate differentiation between ischemic and hemorrhagic stroke is crucial to choose early initialization of brain-saving intravenous thrombolytic therapy or interventional revascularization.
Even though SaMD products have no hardware, there are still plenty of medical regulations that still apply. For more information see FDA Software Guidances and the IEC 62304 Software Standard.
Additional Resources
Orthogonal Software – SaMD – a good summary article on SaMD and its benefits
What Is SaMD? – a quick guide to SaMD by Galen Data
FDA home page for SaMD – a good place to find the latest information from FDA on SaMD regulation
How to Do SaMD Development Correctly – a video presentation with lots of practical advice by the very knowledgeable Christian Kaestner
IMDRF Guidance
The IMDRF produced a set of 4 guidance documents which together lay out a framework for management of SaMD (and which are referenced by the FDA):
- SaMD – Application of QMS (2015) – Basic considerations for a quality system to support SaMD products
- SaMD – Framework for Risk Categorization (2014) – A new way of considering risks associated with SaMD products (category I / II / III / IV)
- SaMD – Key Definitions (2013) – A glossary of SaMD terminology
- SaMD – Clinical Evaluation (2017) – Key concepts in demonstrating the clinical effectiveness of an SaMD product