Software as a medical device: Definition, examples, and regulatory trends
Software has “eaten” many industries ever since investor Marc Andreessen penned his famous column ten years ago. And the healthcare industry is no exception.
Software is transforming the way technicians detect diseases, how doctors suggest treatments, and how patients manage their health. Far from acting as a support or being tied to a single medical device, software itself is now becoming a product, known as software as a medical device (SaMD).
SaMD provides more effective ways of delivering healthcare at scale. And the U.S. Food and Drug Administration (FDA) is accelerating its work on new recommendations on premarket submissions for medical device software functions that will provide more clarity on how companies should plan, develop, and deploy SaMD and software in a medical device (SiMD) products.
When you have a firm grasp of the various nuances of SaMD solutions and the regulations that govern SaMD development, it becomes easier to not only navigate regulation, but also how to launch and market those products more efficiently.
What is software as a medical device?
The International Medical Device Regulators Forum (IMDRF), which consists of medical device regulators from around the world including the FDA, defines SaMD as any software used for medical purposes that isn't part of the hardware itself.
In other words, SaMD doesn’t need to be part of another device to achieve its intended medical purpose. It can be an in vitro diagnostic (IVD) medical device, a medical mobile app or a desktop software, just to name a few examples. And the software can be run on smartphones, tablets, laptops, or other electronic devices at most user’s fingertips. Since SaMD doesn’t need a specific medical device to function, it can interface with various medical devices to carry out medical functions, ranging from diagnosis and prevention to the monitoring and treatment of diseases and physiological conditions.
SaMD takes in various data inputs, like lab results, patient symptoms, or imaging data, and processes them using various types of algorithms. The software then produces outputs that are used for various medical purposes, including for helping users in diagnosing, treating, and managing their health issues.
SaMD basic programming model, SOURCE: FDA
SaMD can also use sensors, smartphones, and external sources to collect relevant data that’s pushed into the software algorithm.
Software as a medical device examples
The FDA has provided clarification on which products should be considered SaMD and which shouldn’t. Software developers whose products are considered SaMD must seek relevant regulatory approvals. Though this list is far from exhaustive, here are several examples of what the FDA considers SaMD products:
- Software that collects patient data to assist doctors in planning a linear accelerator cancer treatment
- Software that analyzes personalized patient data to suggest the proper drug dose
- Software that uses imaging data to track the size of a mole and decide the risk of melanoma cancer
- Software that analyzes magnetic resonance imaging (MRI) data to detect and diagnose a stroke
- Software that collects data from various digital devices to determine users’ risk factors related to epileptic seizures
Not every software product used in hospitals or medical settings is a SaMD. Here are examples of products the FDA doesn’t consider SaMD:
- Software that manages an infusion pump’s motors and pumping operations
- Software that controls an implantable pacemaker
- Software that encrypts medical device data for transmission
- Software for patient registration, video and voice calling, and scheduling visits
- Software that monitors the performance of medical devices for servicing purposes
Artificial intelligence/machine learning-based SaMD products
Software developers also use machine learning (ML), a type of artificial intelligence (AI), to create ever more sophisticated SaMD products. ML spots patterns in data and adapts accordingly. In theory, ML-based products become more valuable over time as they gather and analyze more data. For example, a smart sensor device that predicts the chance of its user having a heart attack becomes more accurate at predicting outcomes the more data it gathers.
The interest in ML-based SaMD products is growing more each day. According to a January 2021 article in The Lancet Digital Health, there are 222 AI-based medical devices approved in the U.S. as wel l as 240 devices in the EU.
Benefits of software as a medical device
SaMD products offer a number of benefits to patients, physicians, and software developers. Some of these benefits are:
- Patients can play a more active role in managing their health. For instance, patients with asthma can use smart sensor data to identify and avoid triggers of flare-ups.
- Powerful SaMD tools could even outperform trained clinicians in making medical diagnoses and earlier detection of certain diseases. For example, an AI model built by researchers from Google Health and Imperial College London has proven to be more accurate than doctors in identifying breast cancer from mammograms.
- SaMD products make it easy for software developers to iterate a product and drive innovation. Developers can gather data and solicit user feedback quickly, which shortens the feedback loop and time to market.
Challenges of software as a medical device
SaMD products are also posing various challenges to its developers, regulators, and users. Some of these challenges include:
- Developers might need more time than usual to get products built. Patient safety and regulatory considerations add new complexities to the existing product development methodologies.
- Regulators have to walk a fine line between ensuring patient safety and supporting innovation. Too many strict regulations might disincentivize companies from investing in new products, but authorities also can’t compromise patient safety.
- Cybersecurity vulnerabilities pose a risk to users and developers of SaMD products. Attackers may breach products, steal sensitive data, and affect the functionality of software.
How does the FDA regulate SaMD?
Regulating SaMD has proven to be a challenge for the FDA. One reason is the agency is used to reviewing medical devices that remain unchanged by their manufacturers once on the market. A stent cleared by the FDA, for instance, is implanted into the patient and won’t be changing any of its features once placed.
But SaMD works in a different way. Software developers can make continuous changes to their products, whether it’s security updates, new features, or product evolutions. Should each of these changes first be approved by the FDA? The agency can take up to eight months to approve medical devices, depending on whether developers submit a 510(k) application, self-register, or submit a Premarket Approval (PMA) application.
The FDA is aware that delays in approving products can negatively impact patients and producers. In its Digital Health Innovation Action Plan, the FDA says lengthy approval of updates for SaMD products may prevent patients from accessing critically important technologies.
Then there’s also the issue of many SaMD developers not being experienced in dealing with the FDA. Studies show that it takes 3 to 7 years to bring a medical device to market. Inexperienced developers may struggle with getting their products approved and shipped on time, ending up discouraged and abandoning their work on SaMD products. Products that present moderate- to high-risk levels to patient health may involve an especially rigorous evaluation process.
Lastly, SaMD products can continually gather medical data, such as medical images, lab results, heart rate, body temperature, and more. As such, these products and patients’ data need to be well protected against potential cybersecurity breaches. In 2021, for instance, over 40 million patient records have been exposed in online attacks in the U.S. alone. SaMD products and development processes should also comply with HIPAA standards. Failure to do so may enable attackers to leak sensitive information and have health providers deal with substantial fines and even prison sentences.
FDA draft guidance on software as a medical device
In November 2021, the FDA released draft guidance on what information should be included in premarket submissions for SaMD and SiMD products. The agency concluded gathering feedback on this guidance in February 2022. The final guidance is supposed to be delivered within a year of the end of the comment period and will replace Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices issued by FDA in May 2005.
The draft sets out a risk-based approach to the documentation level, which can be basic or enhanced. The FDA will classify products into four categories. Level I and Level II category products, like a stress monitoring app that provides no diagnosis, are those with the lowest impact on patient safety or public health and require basic documentation. Developers of Level III and IV products, such as a software product that monitors and analyzes heart rate and blood pressure data in intensive care units, whose failure can lead to death or serious injury to patients or others, will need to provide enhanced documentation for their premarket submissions. Enhanced documentation is also needed if products are intended to be used to test for transfusion-transmitted infections in blood donations or to determine donor and recipient compatibility.
IMDRF Framework for Risk Categorization of Software as a Medical Device, SOURCE: IMDRF
Depending on their documentation level, product developers are supposed to provide various types of documents, including:
- Overview of software features
- Detailed diagrams
- Flow of data for user interaction
- Risk management plan
- Revision history
- List of unresolved bugs
The FDA has also provided an example of how applicants can clarify their software architecture in premarket submissions.
An example of a software architecture diagram chart FDA would want to see in premarket submissions, SOURCE: FDA
The proposed regulatory framework is a major step forward in how the FDA thinks about SaMD and SiMD products. But product developers can consult other resources when preparing their premarket submissions. IMDRF, for instance, has released various resources on key definitions, risk categorization framework, Quality Management Systems, and the clinical evaluation of SaMD products.
The FDA is considering regulation of AI/ML-focused medical devices
In April 2019, the FDA released a discussion paper that describes potential approaches to premarket review for AI/ML-driven SaMD products. The agency wants to improve its current approach that requires multiple software changes to undergo a premarket review.
The framework proposed in the discussion paper is based on the principle of a “predetermined change control plan.” Companies will have to describe aspects of a product that may be changed through algorithmic learning as well as how the algorithm is to learn while remaining safe for use.
Under this framework, the FDA would expect developers to monitor their SaMD products in real-time. The agency would also require them to provide periodic updates on the changes that were implemented based on the approved specifications and protocols.
FDA received feedback on its discussion paper from SaMD product developers. As a result, the agency has developed a five-part action plan to improve its work in regulating AI/ML-based SaMD products in 2022 and beyond. The plan involves the following steps:
- Update the proposed framework on regulating AI/ML-based SaMD products
- Encourage tech communities to harmonize Good Machine Learning Practice (GMLP) principles
- Promote transparency in how companies label and market AI/ML-based SaMD products
- Support efforts to develop methods for identifying and removing algorithm bias
- Provide more clarity on how SaMD developers should monitor real-world performance of their products
Good Machine Learning Practice principles for AI/ML-based SaMD products
The FDA, UK’s Medicines and Healthcare products Regulatory Agency (MHRA), and Health Canada have identified 10 principles that can guide the development of GMLP. These principles are:
- Products are to be developed by a multidisciplinary team
- Product teams follow good software development practices
- Study participants and datasets should be representative of the target patient population
- Product teams will select and keep training data sets independent of test sets
- Companies will use the best available methods to develop a reference dataset
- Developers design the product that supports users in achieving the intended goal
- When relevant, the focus is placed on the performance of the human-AI team
- Developers test the product in clinically relevant conditions
- Users are given clear information on the product’s intended use
- Product teams will monitor deployed products for performance and risks
While these principles aren’t an official regulation SaMD developers must follow, adhering to these FDA-endorsed best practices will make it easier to get regulatory approvals for medical products.
Staying on top of regulatory changes
The future of SaMD products is exciting. Software has the power to improve the diagnosis and treatment of various diseases and enable patients to better manage their own health. And the data these products gather can lead to faster innovation and improved algorithms.
But the push for innovation shouldn’t come at the expense of patient safety and clinical efficacy. The FDA is stepping up its efforts to ensure this doesn’t happen. The agency has released various draft guidance documents and best practices that will be further discussed in 2022 and eventually turned into regulations. Staying on top of these developments is vital for SaMD companies. Well-informed entrepreneurs can get their products cleared by the FDA faster and better plan future innovative projects.
Although it might seem challenging to navigate FDA regulations on SaMD products, having a sophisticated quality management system (QMS) in place makes things easier. A QMS helps companies not only manage documentation but also connect various project components and better predict the impact of software changes. Qualio has helped many companies in achieving these objectives. We’ve built the first web-based quality management system (eQMS) platform that enables you to manage quality and compliance within a single system.
We can also help you assess the performance of your own QMS. Take our free self-assessment test and check how your quality processes compare to industry best practices.
Just starting or early on in your quality journey? Get helpful tips and fascinating insights from experts straight to your inbox.