Understanding Software as a Medical Device

The software has “eaten” a lot of spheres of our life since investor Marc Andreessen published his famous article nearly twelve years ago. And the healthcare industry, of course, was no exception.

Software is changing the way diseases are detected, treatments are suggested, and how patients manage their health. Far from being tied to a single medical device, the software itself is becoming a product, known as software as a medical device SaMD.

When you have a clear understanding of the various nuances of SaMD solutions and the rules that govern SaMD development, it becomes easier not only to navigate regulation but also to release these products more effectively.

Defining SaMD

The IMDRF (International Medical Device Regulators Forum), an international group of regulators that aim to harmonize regulatory requirements for medical products, including SaMDs, provides us with a clear definition of what a SaMD exactly is: “The term “Software as a Medical Device” (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.” [key definitions]

It means that:

• The software has medical usefulness.

• There is a high-level patient risk if it is defective or used wrongly.

• It can be used to notify, avert, analyze, monitor, treat or appease disease.

• It doesn’t reach its prior purpose by pharmacological, immunological, or metabolic means.

• It can deliver patient data and inform healthcare providers about options for treating, diagnosing, preventing, or mitigating disease.

Basically, there are 2 main types of medical device software: Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD). Software solutions that don’t reside in a medical device but are used for medical purposes are called SaMD. SiMD, in its turn, is as critical a component as the healthcare equipment itself.

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 the FDA approved software as a medical device:

• software that collects patient data to aid doctors in planning a linear accelerator cancer treatment;

• software that interprets personalized patient data to offer the proper medication 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 notice and analyze a stroke;

• software that collects data from various digital devices to determine users’ risk factors related to epileptic seizures.

There are numerous types of SaMD solutions already available, and many, many more are on the way. Most SaMDs are related to some kind of diagnosis, prevention, treatment, prediction, alleviation, or monitoring in the context of an illness, injury, or disability. In addition, if the medical device, running as standalone software, is involved in the control of conception or IVD and sterilization, it is also a SaMD. SaMDs can range from software that can detect cancer based on smartphone images, to a sleep app that analyses the data to form the basis of a sleep treatment plan. It’s quite impossible to create a complete list of all types of SaMDs because the digital landscape is vast. An easy trick to know whether or not medical device software can be seen as SaMD is whether or not the software is run on non-medical devices like smartphones, smartwatches, tablets, etc.

Benefits of SaMD

There are two key benefits of SaMD solutions that we’d like to share:

The Use of Data to Improve Health in Patients

SaMD solutions make it possible to collect data much easier and faster than some of the traditional health improvement methods. As these kinds of solutions are highly regulated, the quality of the data is often very high as well. As a result, SaMDs enable the health space to create patient-centered solutions that are capable of improving patient health tremendously.

The Use of Software Is Much More Versatile than Hardware-Based Solutions

SaMDs exist mostly in the cloud. This is a big win in terms of speed and versatility, not only when building these kinds of solutions, but also the updates and adaptations to said SaMD solutions. By utilizing the latest technologies, software-based medical devices are much easier to create, build and keep in the air, in contrast to traditional hardware-based health improvement solutions.

Regulation

Given the unique features of SaMD that extend beyond a traditional medical device or hardware, regulators recognized the need to converge on a common framework and principles that enable the promotion of safe innovation. The International Medical Device Regulators Forum (IMDRF) formed the SaMD Working Group (WG) to develop guidance for risk categorization, quality management, and clinical evaluation.

The Federal law (Federal Food, Drug, and Cosmetic Act, section 513) has established three classes of risk-based device classification:

• Class I (low to moderate risk): these products are the least complicated and their failure possesses little risk;

• Class II (moderate to high risk): they are more complicated than Class I, though they are also non-life sustaining;

• Class III (high risk): they are those that sustain or support life and their failure is life-threatening.

The additional aspects of regulations include:

• Design control covers seven key areas: users’ needs, design inputs, design process, design outputs, reviews, verifications, and validations. The U.S. FDA expects a firm to maintain certain documents to understand the design, development, and V&V processes.

• Cybersecurity: as an element of the software verification and risk analysis demanded by 21 CFR 820.30(g), software device makers may need to launch a cybersecurity vulnerability and administration approach, where suitable.

• Post-market: define how surveillance, analysis, and information sharing are done. Assess the device and clinical impact of vulnerabilities and exploits.

• Mobile app regulations: define to which of the 2 groups of mobile apps the software developed belongs and comply with the regulatory requirements of the group.

SaMD Regulations: EU MDR vs FDA

It is important to note that there is a difference when you are launching a SaMD into the EU or US markets. There is a clear distinction between the two markets, be it the way they are regulated. On the one hand, the EU market is regulated by the MDR (Medical Device Regulation), while on the other, the US market is regulated by the FDA (Food & Drugs Association). You might also have heard of the MDD (Medical Device Derivative), which has been replaced in the EU by the MDR.

Also, the IMDRF standards for SaMD are a harmonizing effort, as both the EU and the USA are members of this international forum. Although much more harmonized than before, it’s still very important that you deep-dive into the similarities and differences between the two if you plan on entering both markets.

FDA Draft Guidance on SaMD

In November 2021, the FDA released a draft guidance on what information should be comprised 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.

Depending on their documentation level, product developers are supposed to provide various types of documents, including:

• overview of software features;

• detailed diagrams;

• the flow of data for user interaction;

• risk management plan;

• revision history;

• list of unresolved bugs.

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, and Quality Management Systems.

SaMD Data Protection: GDPR vs HIPAA

Software as a medical device will always rely on patient data to work properly and have its desired result. And with patient data, comes data protection and data security. Both the EU and US markets have strict data protection and data security regulations in place that you will need to comply with.

In the EU, data protection is regulated by the GDPR (General Data Protection Regulation). In the US, data protection is regulated by HIPAA (Health Insurance Portability and Accountability Act). Where the GDPR regulates all the personal data of individuals living in the EU, HIPAA has a much more narrow scope, zooming in on the Protected Health Information of patients.

Final Word About SaMD Future

The future of SaMD products is exciting. The 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.

***

Building a SaMD from scratch is quite a challenge, but it doesn’t mean whatsoever that it’s not possible to do so, but it does require a highly competent and knowledgeable team, with the resources to organize a qualified healthcare software development process. How do we know? We can do it ourselves.