Given the prevalence of software-driven solutions in modern times, it is not surprising that the healthcare industry has been impacted by this trend!
The definition of Software as a Medical Device (SaMD) is "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device" as per IMDRF.
Simply, a medical software solution that perform one or more medical functions without need of hardware devices.
Some examples of SaMD:
- Software that performs image post-processing and analysis to help detect tumors
- Software that collects and analyzes data, then uses an algorithm to develop a treatment plan for a specific condition or illness.
- Software that collects data from multiple sources and allows healthcare professionals to view the data in real time from a remote location.
Examples, which are not SaMD i.e. do not have a direct medical purpose or embedded in a hardware devices:
- Software that is embedded to a syringe pump (Hardware)
- Fitness apps
- Wellness software
Now, why do we need separation as SaMD as we already have 'medical device' and 'in-vitro' stringent and standard regulations in place?
Here are some of the reasons:
- Software for medical devices may act differently when installed on various hardware platforms.
- It is frequently up to the user of the medical device software to apply a manufacturer-made update.
- Due to its non-physical character (key distinction), medical device software has the potential to be extensively distributed and copied, frequently without the manufacturer's knowledge or consent.
Okay, then how to approach SaMD as part of regulatory is concerned?
FDA's regulatory framework:
In general, FDA expects the below from the manufacturer:
- must comply with the FDA's Quality System Regulation (QSR), which sets requirements for the design, development, manufacture and maintenance of SaMD in a manner that ensures patient safety and device performance.
- QSR requires to implement a quality management system that covers all aspects of the device life cycle, from design and development to post-market surveillance and risk management."
- must comply with FDA regulations, including notification of device changes, consideration of safety considerations and current reporting requirements.
Overall, The FDA has developed a regulatory framework for SaMD that prioritizes patient safety while also fostering innovation and development within the industry.
Likewise, EU MDR has also similar kind of regulations (classifies into different risk categories and requires pre-market review for higher-risk devices) in place for SaMD.
We know that any software is dynamic in nature. Changes to the software will usually either fix bugs, fix security vulnerabilities, provide new features or improve performances and usability.
However, not all the changes to the software to be notified to the regulatory body. Only the 'significant changes' that could affect the safety or effectiveness of the device should be notified.
Do you think that the regulatory body slows down the release of updated software to the market in the name of reviews or validation? Comment your thoughts on this?
0 Comments