Software as a medical device (SaMD) products are everywhere in the healthcare industry — and beyond! They play an important role in the way that doctors interact with patients, how patients manage their own health (like tracking their wellness on smartphone apps), and how hospitals function on a daily basis. But what exactly is SaMD? And what makes it a medical device?
Definition of SaMD
Software as a Medical Device (SaMD) is “software intended for one or more medical purposes that perform these purposes without being part of a hardware medical device,” as defined by the International Medical Device Regulators Forum (IMDRF). Before determining if it’s categorized as SaMD, first, determine if it is a medical device at all. The Food, Drug, and Cosmetic Act defines a medical device as, “an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part or accessory” that diagnoses, treats, and/or interacts with the body and is intended by the manufacturer to be used for a medical purpose. To determine if your product meets the definition of a medical device, define the intended use and indications for use of your product. Intended use is the general purpose of the device, including indications for use (the condition that the device with diagnose, treat, prevent, or cure, as well as the intended patient population).
The key definition for SaMD categorization is that the software cannot function as part of a hardware device. For example, a mobile app that works with glucose monitors compared to medical device software controlling a device like a ventilator.
Some devices carry out diagnostic or therapeutic purposes via software alone. These may be software applications used via personal computers or mobile devices. If the application’s intended use meets the definition of a medical device, it is subject to regulation as a medical device. Based on the device classification, it may require FDA authorization prior to distribution in the United States.
What Makes SaMD Unique?
In most cases, when we think about a medical device, we’re thinking about something physical. However, SaMD doesn’t have anything to do with physical objects at all; it’s purely digital! Unlike physical devices like manual stethoscopes, SaMD runs on devices like computers or smartphones.
Healthcare providers and other consumers use SaMD, but that isn’t its sole use. Software with a non-medical functionality but carrying out functions that meet the definition of a medical device (i.e. to treat or diagnose) is still considered SaMD. SaMD products can connect to a hardware medical device, but the device cannot rely on the software to perform its intended use.
Examples of SaMD
SaMD is used in healthcare, diagnostics, and therapeutics to improve patient outcomes. They are also used outside of healthcare settings, with a lot of SaMD applications used for wellness devices.
SaMD examples include:
- Computer software to view radiological images for diagnostic purposes.
- SaMD software that analyzes test results, assesses patient health, or calculates medication dosage.
- Applications to view and interpret patient monitoring data (vital signs monitoring).
- Pre-surgical planning software applications.
- Lifestyle/habit behavioral therapy applications.
Regulatory Compliance of SaMD Products
Even though software products are not physical objects, they still have to follow regulatory frameworks.
For a software-based medical device (SaMD) distributed in the United States to be cleared by the Food and Drug Administration (FDA), it must be demonstrated to be safe and effective as well as meet all FDA regulations. This means that any SaMD product on the U.S. market has been thoroughly tested and meets all patient safety and cybersecurity standards set forth by the government agency. These requirements include the protection of a patient’s digital health records. For example, SaMD software must have patient confidentiality protections.
As with any medical device, submissions must include detailed design information, test data, and more. Guidance documents provide guidance on everything that must be part of the submission, if they are needed at all (some devices do not require submission to the FDA). Of course, the regulatory pathway depends on the classification of the device.
Classification of Medical Devices
The first step of any regulatory pathway is to determine if your application is a medical device. Then, determine the class of that medical device. As a reminder, there are three classes of medical devices, depending on the risks associated with the device and their intended use.
Class I
Class I devices are low-risk to the patient. They do not support or sustain life and cannot implant into the patient. Some examples include manual stethoscopes and bandages.
Class II
Class II devices are medium-risk. They are slightly more complicated than class I devices but still not used in life-saving situations. Some examples include glucose monitors and dental implants.
Class III
Class III devices have the highest risk. They are often used as life-supporting devices and can implant into the patient. Examples include some pacemakers and ventilators.
Quality Management System
A proper quality management system (QMS) is required to design and develop the device in accordance with FDA regulations and maintain compliance once the device is distributed to market. The FDA has guidance for designing and developing software in a controlled manner. These requirements involve ensuring the designed software works for its intended use, is tested for performance and patient safety, and maintains the quality procedures needed throughout its development.
Clinical Evaluation
There are different criteria for the clinical evaluation of medical software. This evaluation is divided into three main factions.
-
- Valid Clinical Association: evaluates the connection between the SaMD output and the SaMD’s targeted clinical condition.
- Analytical Validation: ensures that the SaMD processes and outputs accurate, reliable, and precise data.
- Clinical Validation: determines if the accurate, reliable, and precise output data achieves the intended use for the target market.
Testing of Software
Like other medical devices, software must be tested for its safety and effectiveness. This verification process includes a variety of different software tests, depending on the complexity of the software.
-
- Unit Testing: verifies individual software units or components. Unit testing results are included as part of the verification documentation. This type of testing also allows developers to detect bugs in the software early enough to correct them and save costs.
- Integration Testing: verifies interfaces and data flow between integrated software units or components. It is often combined with system testing.
- System Testing: verifies completed software products by using different methods and tools to evaluate functionalities and how the software components interact as a whole. Some types of system testing are also considered validation for standalone software.
Cybersecurity Controls
SaMD is often connected to the internet in some way, so cybersecurity controls are extremely important to protect users and their information. This cybersecurity is included in the FDA’s evaluation of the device’s safety and effectiveness for its intended use. Connecting SaMD to the internet allows for more universal access, but increases the risk of security breaches. Developers must ensure that their device is designed securely and risks are mitigated through the product’s Total Product Life Cycle.
Find a Regulatory Partner for Your Device Approval
SaMD development is already complicated; don’t let the process of submitting to the FDA inhibit your device. The experts at A Wright Path can help you meet regulatory requirements so you can focus on software development. Experience a partnership that helps you gain market clearance with the quality management system and other long-term benefits to maintain your status. Schedule a consultation today!
