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,” accord to the International Medical Device Regulators Forum. In other words, SaMD is a stand-alone computer program to resolve specific tasks in the healthcare industry. SaMDs facilitate healthcare providers’ work because they are easy to use, cost-effective, and mobile. The core value of SaMDs is their quick and accurate data processing and real-time feedback.
However, it is important to clearly distinguish the terms “Software AS a Medical Device (SaMD)” and “Software IN Medical Device (SiMD)”. SaMD can work independently on general-purpose computing platforms, while SiMD aims to drive medical hardware work.
The International Medical Device Regulators Forum mentioned above defines SaMD as follows:
- SaMD works on non-medical purpose platforms,
- can achieve its intended medical purpose independently,
- Is not aimed to boost medical hardware,
- May be used as a module for medical devices or other products, and
- Can be a mobile application.
Because medical software can be applied to a variety of purposes, formulating a clear definition can be a burden. Such concepts as classification, regulatory oversight, intended use, and operation instructions influence the wording of a final product definition.
Software as a Medical Device Definition Statement and Categorization
SaMD categorization relies on the actual definition of medical software. The International Medical Device Regulators Forum guides us on how to formulate a SaMD definition statement:
- The intended purpose of software (treat or diagnose, drive, or inform clinical management),
- The severity of the situation or condition SaMD is intended for (critical, serious, non-serious),
- A description of critical features of SaMD.
Based on the definition statement above, SaMD can be assigned to one of four (I, II, III, IV) categories. Each category has a different impact on patients’ health and the healthcare industry as a whole, ranging from the lowest impact in category I to the highest impact in category IV, as shown in the table below.
State of Healthcare Situation or Condition |
Intended Use |
||
Treat or |
Drive Clinical |
Inform Clinical |
|
Critical |
IV |
III |
II |
Serious |
III |
II |
I |
Non-serious |
II |
I |
I |
Examples of Software as a Medical Device
SaMD requires general-purpose digital devices (e.g., tablets, smartphones, laptops) to perform its operations. If the software directly manipulates a medical device, it cannot be considered SaMD. To better understand the difference between SaMD and SiMD, let’s compare some software examples in the next table.
Software as a Medical Device |
Software in Medical Device |
Image processing and image interpretation software |
Software that manipulates medical device hardware (e.g., a part of medical imaging hardware) |
Medical data interpretation software |
Software that uses medical data but without medical purpose (e.g., a database) |
Software that uses microphones, speakers, and wearables to control and transmit vital parameters |
General purpose software (e.g., encryption software for data transmission) |
Software for medical devices differentiation can be blurry! For example, EHRs/EMRs (Electronic Health Records/Electronic Medical Records) that store patient health information do not fall under the FDA regulations and are considered neither SaMD nor SiMD.
Regulatory Framework for Software as a Medical Device
Medical device software has already become a significant part of today’s healthcare system. SaMDs are deployed on numerous platforms, integrated with databases, and perform complex healthcare tasks. They are used by healthcare providers and patients alike, which of course brings new challenges:
- Software may behave unexpectedly on different platforms.
- Often the (potentially unexperienced) end-user has to install the software.
- Software can be copied and distributed illegally.
Considering these issues and SaMD flexibility in software development and frequent updates, this requires a specific regulatory framework to ensure its safety and effectiveness. The resulting framework includes several regulatory documents and standards that provide SaMD categorization, risk management for the development process, and updates. These documents include:
- IMDRF Categorization Framework that provides SaMD categorization based on the device impact on patients (I, II, III, IV categories).
- IEC 62304 Standard that regulates the life cycle development of medical devices.
- Digital Health Software Precertification Program that streamlines regulatory oversight of SaMD.
SaMD can provide real value for some healthcare goals and be part of the larger clinical workflow. However, if an issue or modification occurs at any stage of the development process including design, functionality, usage, and implementation, it can impact the workflow, mislead the end-user, and cause a potential danger to patients’ health and well-being.
Outlook
SaMD technology is steadily becoming more accessible and advanced. It integrates well with many healthcare digital platforms, and has a significant impact on medical research, healthcare services, and personalized medicine as a stand-alone solution.
Such software solutions provide a high level of connectivity with devices, letting healthcare providers process critical data quickly to generate valuable insights concerning patients’ health and the healthcare industry as a whole.