The medical device industry has recently ventured into creating innovative digital products that work independently of traditional hardware. These are known as Software as a Medical Device (SaMD). While they differ from conventional medical devices, SaMDs have tremendous potential to improve patient care and enhance the quality of life worldwide.
Even with their distinct nature, regulatory bodies in healthcare worldwide still categorize SaMDs as medical devices. This guide aims to demystify the complexities of SaMDs, offering valuable insights for anyone interested in developing one.
Let’s dive into this fascinating field and uncover its many opportunities.
“Software as a Medical Device is revolutionizing health care in its potency to personalize the treatment options and further enhance the outcome for patients with next-generation data analytics and Artificial Intelligence.” — Dr. Eric Topol
Table of Contents
Main Types of Medical Software
The World Health Organization notes that over 2 million types of medical devices are globally organized into 700 generic groups. They range from essential tools like stethoscopes to sophisticated MRI machines that cost millions and feature complex built-in systems. Essentially, any tool, machine, appliance, implant, petri dish reagent, or digital tools designed for medical purposes qualifies as a medical device.
- Software as a Medical Device (SaMD). This standalone software acts as an independent medical product. Software as a medical device examples include Computer-Aided Detection software, which examines MRI images to spot disease patterns.
- Software in a Medical Device (SiMD). This tool is integral to medical equipment. For instance, the software that operates MRI machines and other hospital hardware falls into this category.
- Software as a Medical Device Accessory (MDA). This type of software enhances the performance of medical devices. Examples include tools used for the remote control of medical equipment.
- General-purpose software. While not a medical product, this digital product manages data and streamlines business processes. Mobile health apps, such as EMR and EHR systems, telemedicine apps, prescription management apps, well-being apps, and other applications for doctors and patients, belong here.
SaMD presents new opportunities for healthcare providers but also poses challenges for regulatory bodies. Establishing guidelines to regulate digital medical device solutions is crucial for ensuring clinical effectiveness and safety, as well as protecting sensitive information.
Why is categorizing MDSW essential? Each category has its own set of regulations. Healthcare software providers need to classify their products to comply with these regulations. Hospital software vendors must understand the applicable guidelines and the necessary certification to bring new solutions to the Software as a Medical Device market.
What Is Software as a Medical Device?
According to the FDA, Software as a Medical Device (SaMD) stands out because it independently performs medical functions without needing extra equipment. SaMD is designed to handle medical tasks solo without relying on other software or hardware. Despite this independence, SaMD can still work with medical equipment and general-purpose digital products and even gather input from IoT devices to provide useful recommendations.
So, how can you tell SaMD apart from other software? The FDA’s Software as a Medical Device classification and clinical evaluations are extensive. Rather than delving into those complexities, let’s look at real-world applications to see SaMD in action.
Identifying the medical function in your digital product makes recognizing SaMD simple. If your mobile health app doesn’t meet the criteria set for SaMD, it won’t be regulated as such.
How Medical Device Software Works
SaMD Software as a Medical Device transforms healthcare by converting complex data into practical insights. Picture it this way: SaMD collects information from lab tests, patient symptoms, and imaging scans and then applies advanced algorithms to interpret this data. The outcome? It generates valuable insights that aid in diagnosing, treating, and managing health conditions more effectively.
Moreover, SaMD can integrate with sensors, smartphones, and other external sources to gather additional relevant data. This continuous influx of information keeps the software’s medical insights precise and up-to-date.
SaMD Examples
Let’s look at some examples of Software as a Medical Device.
Diagnosis and Treatment
Software as a medical device companies are at the forefront of transforming healthcare by analyzing intricate medical data and providing valuable insights into patient health. This technology assists healthcare providers in making well-informed decisions, leading to more effective treatment plans. From ECG analysis to breast cancer diagnosis and cognitive behavioral therapy (CBT), SaMD enhances patient outcomes and optimizes healthcare delivery. Let’s look at Software as a medical device examples in this niche.
ECG analysis software
Software designed for electrocardiogram (ECG) analysis helps diagnose heart conditions such as arrhythmia, myocardial infarction, and heart failure. It scrutinizes the heart’s electrical activity recorded in ECG signals, offering vital insights into a patient’s heart health.
Example: KardiaAI
Breast cancer diagnosis software
SaMD for breast cancer diagnosis utilizes advanced image analysis techniques to aid radiologists in detecting lesions, masses, and other abnormalities in breast tissue that might indicate cancer. This software conducts a thorough analysis of mammograms and other medical images.
Example: Koios DS
Cognitive behavioral therapy software
SaMD targeting cognitive behavioral therapy (CBT) addresses mental health issues such as depression and chronic insomnia. It provides interactive exercises and interventions, teaching patients new coping mechanisms, enhancing mood, and improving sleep quality.
Examples: Somryst, Feel Therapeutics
Pulmonary function testing software
SaMD is used for pulmonary function testing and diagnoses respiratory conditions such as asthma, bronchiolitis obliterans syndrome (BOS), and chronic obstructive pulmonary disease (COPD). This digital product delivers detailed insights into respiratory health.
Examples: ComPAS2, AI-Rad Companion (Pulmonary)
Sleep diagnostics software
Software for sleep analysis assists in diagnosing various sleep and respiratory-related disorders. Physicians can use this technology to evaluate sleep quality and efficiency, leading to more accurate diagnoses and better treatments.
Example: Sandman Elite
Monitoring and Management
Think about having a personal health assistant at your fingertips, continuously tracking your health data and sharing it with your doctor in real-time. That’s precisely what software as a medical device (SaMD) provides for monitoring and management. This technology delivers up-to-the-minute health insights, enabling more informed decision-making.
Doctors can now stay on top of things, observing early symptoms or changes in a patient’s condition and taking timely actions to prevent complications.
Continuous glucose monitoring software for diabetes
Managing diabetes has become significantly easier. Continuous glucose monitoring software evaluates data from glucose meters, providing real-time updates on blood glucose levels, trends, and patterns. This approach allows individuals with diabetes to make better-informed choices about their diet and medication.
Examples include:
Sleep apnea monitoring software
Innovative digital products now utilize microphone-enabled devices to analyze breathing patterns and detect apnea events for those suffering from sleep apnea. If breathing is interrupted, the system can alert the patient. Healthcare providers can then review detailed reports on treatment effectiveness, such as CPAP therapy.
Examples include:
Medication management software
One of the most common applications of Software as a Medical Device SaMD is in medication management. These apps assist patients in keeping track of their medication schedules while allowing healthcare providers to monitor usage and adjust prescriptions as necessary.
Examples include:
Remote patient monitoring software
Remote Patient Monitoring (RPM) software is revolutionizing healthcare. It enables providers to monitor patients’ vital signs, symptoms, and medication usage from a distance. This method means they can quickly intervene if needed, preventing complications and ensuring timely care.
Examples include:
Prevention and Wellness
Many apps are designed to foster healthier habits and enhance patient engagement. These cutting-edge tools do more than just monitor health metrics; they offer personalized insights and lifestyle recommendations, empowering users to make impactful changes.
Fitness and nutrition tracking apps
Many consumer apps are geared towards promoting a healthier lifestyle, but not all meet the criteria to be classified as Software as a Medical Device (SaMD). That said, fitness and nutrition software can be pivotal in preventing and managing conditions such as obesity, diabetes, eating disorders, and even migraines. These SaMD tools provide tailored advice and track user progress, helping individuals achieve their health objectives.
Examples include:
Smoking cessation apps
Quitting smoking is notoriously challenging, but certain apps can make the journey a bit easier. These tools track your progress, offer personalized advice, and even measure carbon monoxide levels in your breath. SaMD solutions can also share real-time data with your healthcare provider, providing them with valuable insights into your treatment response.
Examples include:
Women’s health software
Women’s health apps have made significant strides, offering personalized insights into fertility, symptom tracking, and reproductive health management. Some SaMD solutions even serve as digital contraception, offering a modern approach to birth control.
Examples include:
- Natural Cycles
- Clue Birth Control
How Do I Know if My Product Is SaMD?
When determining if your software qualifies as a SaMD, it’s essential to be familiar with the guidelines from both the FDA and the International Medical Device Regulators Forum (IMDRF). Although these organizations have largely aligned approaches, there are particular nuances you need to be aware of.
The initial step involves determining if your digital product meets the criteria for a medical device. According to the IMDRF, the software must be “intended for one or more medical purposes.” On the other hand, the FDA provides a more detailed Software as a Medical Device definition outlined in Section 201(h) of the Federal Food, Drug, and Cosmetic (FD&C) Act. This section states that a device can be anything from an instrument or machine to an implant or in vitro reagent, provided:
- It is recognized in official pharmacopeias like the National Formulary or the United States Pharmacopoeia.
- It is intended for diagnosing, treating, curing, mitigating, or preventing diseases in humans or animals.
- It impacts the body’s structure or function without depending on chemical action or metabolism.
To determine if your software qualifies as a medical device, it must meet the criteria outlined above. A key part of this process is precisely defining your product’s “intended use” and “indications for use.”
- Intended use. This definition refers to the primary function of your device—what it is designed to do.
- Indications for use. These specify the diseases or conditions your device addresses, including the target patient population and the reasons for its use.
Once you’ve clearly outlined these elements, it will be easier to determine whether your software falls under the FDA guidance Software as a Medical Device.
If you plan to market your digital product in the U.S., it’s vital to thoroughly review the FDA’s guidance on the Policy for Device Software Functions and Mobile Medical Applications. This document offers valuable insights into what the FDA classifies as a medical device and what features may fall outside its regulatory scope.
Still unsure if your software qualifies as a medical device? Contacting the FDA directly can help you gain the clarity you need.
“That is to say, given the unique nature of SaMD, regulatory frameworks shall evolve to make sure safety and efficacy are upheld while at the same time creating an environment where innovation will happen in this fast-changing field.” — Dr. Vinod Khosla
Is My Software Considered SaMD or SiMD?
You’re only at the starting line once you’ve established that your product qualifies as a medical device. The next critical step is to explore the definitions of SaMD Software as a Medical Device as outlined by the IMDRF (International Medical Device Regulators Forum) and the FDA.
According to the IMDRF, SaMD refers to a digital product that operates independently of any hardware medical device. Similarly, the FDA defines SaMD as software intended for medical use that doesn’t rely on being part of a physical device.
This distinction sharpens the understanding of what qualifies as SaMD. Software that is specifically designed to control or operate a hardware device doesn’t meet the SaMD criteria. Instead, such software falls into a different category: SiMD, or “Software in a Medical Device.”
Simply put, SiMD refers to any software that contributes to operating a hardware medical device—whether it controls the device’s mechanics or generates its user interface. Examples of SiMD include digital products that:
- Control the inflation or deflation of a blood pressure cuff
- Manage insulin delivery on an insulin pump
- Handle the closed-loop control of a pacemaker
This type of software is often known as “embedded software,” “firmware,” or “micro-code.” When you encounter these terms, remember that they refer to SiMD, not SaMD.
For software to be classified as SaMD, it must operate independently of any hardware while performing functions that qualify it as a medical device. The IMDRF’s guidelines on risk categorization add further clarity:
- SaMD is considered a medical device, which includes in-vitro diagnostic (IVD) medical devices.
- SaMD can run on general-purpose (non-medical) computing platforms.
- The phrase “without being part of” signifies that the digital product isn’t essential for a hardware medical device to perform its intended medical function.
- Software whose purpose is to drive a hardware medical device isn’t classified as SaMD.
- SaMD can be used in conjunction with other products, including medical devices.
- SaMD can interface with other medical devices, both hardware and software, as well as general-purpose digital product.
- Mobile apps under this definition are also considered SaMD.
While it’s crucial to differentiate between SaMD and SiMD, it’s equally important to understand that both types of software follow many of the same development standards, like the international IEC 62304 standard for software lifecycle processes. As a result, even if your software falls under the SiMD category, much of the guidance and standards relevant to SaMD will also apply.
Related articles:
- Medical Device IoT Security Importance
- Benefits of AI in healthcare: Key usages
- What Technologies Are Driving the Health Protection System?
- Leveraging Data Analytics: A Guide to Revolutionizing the Pharmaceutical Industry
- Transforming Healthcare Communication: Integration of HL7 Interface Engine
SaMD Regulations in the US
The FDA acknowledges that its Software as a Medical Device regulation was initially created with traditional devices in mind, which is why they’ve since rolled out specific guidance for software, especially regarding premarket submissions.
The first set of guidelines for Software as a Medical Device (SaMD) premarket submissions was published way back in 2005. If you’re thinking that’s a bit outdated, you’re spot on. That’s why, in 2021, the FDA introduced a draft for new guidance to bring things up to speed.
Here’s where it gets a bit complicated. Both the current and draft guidance outline the necessary documentation based on the intended use of your SaMD.
The 2005 guidance classifies Software as a Medical Device (SaMD) into three “levels of concern” based on the severity of potential injury due to device failure or design flaws:
- Minor. Failures or design flaws are generally not expected to cause any injury to either the patient or the operator.
- Moderate. Failures or flaws might lead to minor injuries to the patient or operator, which could result from delayed or incorrect information or actions taken by the provider.
- Major. Failures or flaws could lead to death or serious injury to the patient or provider, again potentially due to delayed or incorrect information or actions by the provider.
The Software as a Medical Device guidance specifies the documentation you must submit based on these levels of concern. It’s important to note that the “level of concern” differs from your device’s risk class.
Now, let’s shift to the draft guidance. In this version, the three levels of concern have been simplified into two categories:
- Basic Documentation
- Enhanced Documentation
As you might expect, this shift has led to some confusion. We don’t know when the draft guidance will be finalized or the final version. So, it’s best to indicate your device’s level of concern and whether it requires basic or enhanced documentation.
It might sound like extra work, but the truth is that both the draft and current guidance documents require similar types of documentation—they just organize them differently. So, the paperwork you prepare will likely be sufficient for the other.
If you’re uncertain which category your SaMD falls under in either guidance, it’s safer to lean toward submitting the documentation for the higher level.
Medical Device Software Regulations in the EU
Navigating the regulations for EU MDR Software as a Medical Device can seem overwhelming, especially since the regulatory framework closely mirrors that of traditional medical devices. Much like in the United States, you must adhere to all the EU MDR (Medical Device Regulation) requirements and EU IVDR (In Vitro Diagnostic Regulation).
One crucial distinction is the terminology; the EU doesn’t use “Software as a Medical Device.” Instead, it categorizes this type of digital product as “Medical Device Software” or MDSW.
Fortunately, the European Commission (EC) has provided a range of helpful guidance documents designed explicitly for SaMD manufacturers. Here are a few that stand out:
- MDCG 2021-24. Guidance on the classification of medical devices
- Infographic. Is your software a medical device?
- MDCG 2020-1. Guidance on Software as a Medical Device (SaMD): clinical evaluation
- MDCG 2019-16. Guidance on cybersecurity for medical devices
- MDCG 2019-11. Guidance on the qualification and classification of software
We’ll explore some of these resources in more detail later in this guide, but we strongly recommend looking at them now. These documents are precious whether you’re still determining if your software qualifies as MDSW or you’re already well into the regulatory process.
If you’ve confirmed that your software falls under the MDSW category and want to ensure you’re aligned with EU MDR compliance, you can contact Software as a Medical Device lawyer. This person will evaluate your compliance status and select the proper regulatory pathway for your medical device software.
Software Development for SaMD
Venturing into Software as a Medical Device development is like stepping into a hotbed of strong opinions.
Why? Well, much of it boils down to regulations such as the FDA’s Quality System Regulation (QSR), which were initially designed with traditional, hardware-centric medical devices in mind. These regulations expect a systematic, step-by-step product development process—what many refer to as the waterfall methodology. This linear, sequential approach, where each phase must be completed before the next one begins, has long been the industry standard and is embedded in regulations such as IEC 62304. Naturally, this creates some tension for software developers.
In contrast, each Software as a Medical Device developer today leans towards the agile methodology, a more flexible, iterative approach that allows for continuous improvement and adaptation. This shift has led to a bit of a cultural rift, especially as many new Software as a Medical Device companies don’t hail from the traditional medical device world. Consequently, there’s a common belief that agile practices and existing regulatory frameworks are at odds.
But here’s the kicker: While these regulations were drafted with a linear process in mind, adopting agile development and meeting all the required standards is possible.
Take IEC 62304, for instance. At first glance, it may seem rigid and locked into a linear mindset. However, agile methodologies can align with its requirements. Another standard, AAMI TIR 45, provides clear guidance on integrating agile practices into medical device software development.
Now that that myth is busted let’s explore the specifics of IEC 62304 and see how they relate to SaMD development.
IEC 62304 – Software Lifecycle Requirements
IEC 62304 isn’t about laying down strict rules for your product; it’s more like a helpful guide that walks you through the process. Picture it as a roadmap—when you follow it correctly, you can trust that your software will be safe and effective.
Instead of telling you exactly what your product needs to do, IEC 62304 provides a structured approach that covers the entire software lifecycle. It breaks down into five essential processes:
- Development process
- Maintenance process
- Risk management process
- Configuration management process
- Problem resolution process
Interested in what each process involves? Below you’ll find a detailed overview.
Software Development Process
Developing software under IEC 62304 is like following a well-marked roadmap, starting with careful planning and culminating in the exciting milestone of releasing your software. But before you reach that finish line, there are some critical steps you need to take, including:
- Analyzing the software requirements
- Designing the software architecture
- Implementing and verifying software units
- Integrating the software components and running integration tests
- Conducting system-wide testing
But don’t kick back just yet; releasing the digital product is only one part of the equation. IEC 62304 is a comprehensive lifecycle standard, meaning your work doesn’t stop at launch. You’ll need to stay vigilant, continuously maintaining the software and addressing any issues that might come up along the way.
Software Maintenance Process
IEC 62304 offers clear guidance on managing software maintenance, similar to how ISO 13485 and FDA 21 CFR Part 820 handle complaint management procedures.
The software maintenance process outlined in IEC 62304 can be divided into three fundamental steps:
- Crafting your software maintenance plan
- Problem analysis and identifying necessary modifications
- Executing the modifications
Pro Tip: Before starting from scratch, closely review your complaint-handling procedures. You might discover that much of the groundwork is already laid, which could help you streamline the development of your maintenance process and avoid redundant effort.
Software Risk Management Process
The software risk management process should ring a bell if you transition into IEC 62304 from medical device manufacturing. IEC 62304’s guidelines align closely with ISO 14971, the global medical device risk management benchmark.
Keep in mind that SaMD – Software as a Medical Device manufacturers adhere to the same ISO 14971 standards as other medical device makers. Feeling a bit lost on risk management? Our Definitive Guide to ISO 14971 has got you covered.
Diving into IEC 62304, you’ll notice its harmony with ISO 14971, especially in areas such as:
- Analyzing software’s role in hazardous situations
- Implementing risk control measures
- Verifying the effectiveness of those measures
- Managing risks associated with digital product changes
But don’t think risk management is just a standalone section. It’s intertwined throughout the software development process. Following IEC 62304 transforms this process into a potent tool for risk control.
Software Configuration Management Process
Think of software configuration management as the bookkeeping of your software environment. Just as accounting tracks your finances, configuration management records everything you need to rebuild your digital product from scratch. This practice is essential for maintaining traceability and ensuring smooth release management.
Under the IEC 62304 standard, effective software configuration management must include the following:
- Configuration identification
- Change control
- Configuration status accounting
Many companies use a configuration matrix to simplify this process. This helpful tool gathers all the digital product components you need to manage and tracks their release times in a single, easy-to-reference table.
Software Problem Resolution Process
The term “software problem resolution process” might give the impression that there’s a universal fix for every issue, but that’s not true. In reality, you’ll need to employ various problem-solving strategies, as different challenges will surface throughout the software’s lifecycle.
The IEC 62304 standard offers a robust framework for tackling these challenges:
- Prepare comprehensive problem reports
- Investigate the underlying causes
- Keep all relevant stakeholders informed
- Implement the change control process
- Maintain detailed records
- Analyze issues to identify patterns and trends
- Verify that the problem has been thoroughly resolved
- Review and update your documentation
As your software evolves, you may encounter fewer issues, but the ones that arise could be significantly more serious, necessitating a more rigorous approach to resolve them.
Software Validation for SaMD Development
Navigating the FDA’s Quality System Regulations can feel overwhelming, especially if your background is in software development and you’re new to the medical device industry. One of the core requirements is ensuring that any digital product used in production or within the quality system is validated for its intended use, following a clear, established protocol.
Validating software—especially software that builds others—might seem like an unexpected challenge. But it’s a critical step. Proper validation guarantees that hardware and MDSW are safe for their intended use.
So, how much validation is needed? The FDA’s guidance on software validation offers some insight: The level of effort should align with the risk associated with the software’s automated functions.
For instance, if you’re using digital products to run tests, and it doesn’t work as expected—maybe it gives a false pass or misses vital tests—you could be facing serious issues that could jeopardize patient safety. On the other hand, widely used programs like Microsoft Excel, which carry minimal risk, don’t require the same level of validation scrutiny.
Remember that all validation must be conducted according to a documented protocol, and the results must be meticulously recorded. Ultimately, while the decision to validate a software tool rests with you, you must be ready to justify that decision.
At IntelliSoft, we recognize how time-consuming software validation can be in medical device development. That’s why we handle it for you. We provide a complete validation package aligned with Computer Software Assurance and ISO/TR 80002-2:2017 standards and best practices with every major software update. In this way, you can stay focused on developing your devices, confident you’re remaining compliant.
Artificial Intelligence and Machine Learning in SaMD
Navigating the decision-making process for new submissions has become increasingly complex with the advent of artificial intelligence (AI). A key driver of this transformation is machine learning (ML), a subset of AI that has gained significant traction across various sectors.
Machine learning involves algorithms that refine their output by learning from ever-growing datasets. The more data these ML algorithms process, the more accurate their predictions and results become.
This technology offers tremendous potential for diagnostics and other medical devices but presents a significant challenge. In TGA Software as a Medical Device (SaMD), any modification to the algorithm technically alters the device itself.
So, how do you determine if these changes necessitate a new submission for your SaMD?
This area remains relatively unexplored for medical device manufacturers and regulatory authorities. However, the FDA has proposed a Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) to help navigate this process. While reviewing the full document is critical, several key points must be considered.
First, the FDA expects manufacturers to refer to the guidance document, Deciding When to Submit a 510(k) for a Software Change to an Existing Device, which we discussed earlier in this section.
Second, the FDA’s proposed framework for AI/ML modifications is based on the principle of a “predetermined change control plan.” This plan sets the boundaries for any anticipated alterations during your initial premarket submission.
This “predetermined change control plan” consists of two parts, each covering different types of modifications:
- SaMD pre-specifications (SPS). It refers to the anticipated changes a manufacturer expects in terms of “performance,” “inputs,” or modifications related to the “intended use” of AI/ML-based SaMD. The SPS outlines a “region of potential changes” around the original device specifications and labeling, charting what the manufacturer envisions the algorithm could evolve as it learns.
- Algorithm change protocol (ACP). It details the specific procedures a manufacturer will use to manage and mitigate the risks associated with the anticipated changes outlined in the SPS. The ACP provides a step-by-step guide to ensure the modification maintains the device’s safety and effectiveness. This is the “how” of the algorithm’s learning and evolution.
Under this proposed framework, the FDA suggests that modifications within the agreed parameters of the SPS and ACP would only need to be documented by the manufacturer—these are the changes you previously notified the FDA about, anticipating they could occur as the algorithm evolves.
However, if a modification goes outside these predefined boundaries and affects the device’s safety or effectiveness, a new 510(k) submission would be necessary.
I understand this is a lot to take in, so here’s a flowchart that should help clarify the process.
Conclusion
Software as a Medical Device (SaMD) extends beyond the capabilities of traditional medical devices by utilizing advanced technology and connectivity. It offers continuous monitoring of safety, effectiveness, and performance.
In the European Union, software is considered a medical device if it is “active,” meaning it requires an external power source. In the United States, the FDA classifies Software as a Medical Device if it serves one or more medical purposes independently of any hardware.
As the “Internet of Everything” permeates all aspects of our lives, the advancement of SaMD will accelerate. Companies are now at a crossroads, deciding whether to develop these groundbreaking solutions. In the end, they decide to seek guidance from a Software as a Medical Device company. This is where IntelliSoft comes into play.
Are you prepared to innovate in this space and need a development partner? Contact our experts, and let’s create something extraordinary together.
