Software as a Medical Device (SaMD)
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 by the International Medical Device Regulators Forum (IMDRF) Software as a Medical Device Working Group in the IMDRF SaMD WG N10 / Software as a Medical Device: Key Definitions technical document.
To be considered as a SaMD, your product or device needs to fall under the definition of a medical device first. The medical device definition as stated in the IMDRF/SaMD WG/N12FINAL:2014 / “Software as a Medical Device”: Possible Framework for Risk Categorisation and Corresponding Considerations, means any instrument, apparatus, implement, machine, appliance, implant, reagent for in-vitro use, software, material or other similar or related article, intended by the manufacturer to be used, alone or in combination, for human beings, for one or more of the specific medical purpose(s) of:
- Diagnosis, prevention, monitoring, treatment or alleviation of disease;
- Diagnosis, monitoring, treatment, alleviation of or compensation for an injury;
- Investigation, replacement, modification, or support of the anatomy or a physiological process;
- Supporting or sustaining life;
- Control of conception;
- Disinfection of medical devices;
- Providing information utilising in vitro examination of specimens derived from the human body.
and does not achieve its primary intended action by pharmacological, immunological or metabolic means, in or on the human body, but which may be assisted in its intended function by such means.
Therefore, as long as your software product meets the medical device definition, and it can perform these medical purpose(s) without being part of a hardware medical device, your software product can be considered as a SaMD.
What are some examples of Software as a Medical Device (SaMD)?
Examples of SaMD are:
- Software in-vitro diagnostic (IVD) medical device
- Software with a medical purpose that is capable of running on general-purpose (non-medical purpose) computing platforms
- Software with a medical purpose that may be used in combination (e.g., as a module) with other products, including medical devices
- Software with a medical purpose that may be interfaced with other medical devices, including hardware medical devices and other SaMD software, as well as general-purpose software
- Mobile apps that meet the definition above are considered SaMD.
What is Software as a Medical Device (SaMD) used for?
With the advancement of medical devices technology in the healthcare industry, SaMD has proven its benefits in many areas such as monitoring, screening, diagnosis, disease management and therapeutics.
For example, with the availability of clinical data globally, SaMD can aid patients in disease management by predictive analysis capabilities. These SaMD allows patients to consult their doctors and take early prevention measures to manage early-stage diseases.
Medical imaging software is another example of SaMD that is currently being widely used in the healthcare industry. These medical software include medical image analysis, processing, management and dose-tracking software. Some common use cases are software that processes images taken from Computed Tomography (CT), Medical Resonance Imaging (MRI) and X-ray scans with computer-aided detection software.
By processing these images, doctors can view images that may be reconstructed into 3D images to better analyse the human anatomical structure and confirm the diagnosis for the prevention of various diseases (E.g. detection of benign tumours in breasts that may lead to late-stage breast cancer). The healthcare industry then benefits from providing doctors assistance in their treatment and surgical plans.
How is Software as a Medical Device (SaMD) regulated?
SaMD is regulated just like any other traditional medical device, which depends on the various country’s regulatory requirements such as Singapore’s Health Sciences Authority (HSA), United State’s Food and Drug Administration (FDA) and Europe’s European Commission. Medical device regulation can be observed in almost all countries that prioritise patient safety, including SaMD.
However, regulations may differ in countries as different approaches to ensure safe and effective software are being designed, manufactured, and distributed. For example, Singapore’s Health Sciences Authority has established regulatory guidelines in a guidance document titled Regulatory Guidelines for Software Medical Devices – A Life Cycle Approach for medical device software, including SaMD.
To fulfil multiple countries’ regulatory requirements for SaMD, it is also highly recommended to comply with the ISO 13485:2016 Medical Device Quality Management Systems standard. In addition, IEC 62304:2006 Medical device software — Software life cycle processes is an international standard required by multiple countries’ regulatory requirements to market software medical devices, including SaMD.
IEC 62304 Medical device software – Software life cycle processes
The IEC 62304 standard is a proposed framework of life cycle processes for all organisations developing and maintaining medical device software. This ensures the production and maintenance of safe and effective software medical devices, including SaMD.
Software Safety Classification
IEC 62304 provides guidance on assigning safety classifications (Class A, B and C) to your medical device software, including SaMD. The safety classification is determined by applying the ISO 14971 Medical devices — Application of risk management to medical devices.
Depending on the safety classification, if your medical device software is of the highest risk (Class C), it is deemed a software system that can contribute to a hazardous situation in which unacceptable risk will result even after risk control measures are implemented. In other words, the resulting possible harm is death or severe injury.
Therefore, the higher your software safety classification is, the more requirements must be fulfilled to comply with IEC 62304. These requirements are in the form of activities as part of the software development and risk management process.
Software Development Process
The software development process consists of the following activities.
Software development planning
During this stage of development, your organisation should formulate a Software Design and Development Plan that addresses:
- the processes used in the development of the software;
- the deliverables, including the documentation as a result of the development process;
- how traceability between your software requirements;
- testing and risk control measures are being addressed;
- software configuration and change management; and
- software problem resolution process.
If your SaMD has a safety classification of B or C, additional information such as the plan for software integration and integration testing also needs to be included. This includes the deliverables, milestones and acceptance criteria for the tests.
Software requirements analysis
Documentation of your Software as a Medical Devices’ requirements is applicable for all software safety classes. The content in your organisation’s software requirements should cover and include the following:
- Functional and capability requirements;
- Software system inputs and outputs;
- Interfaces between the software system and other systems;
- Software-driven alarms, warnings, and operator messages;
- Security requirements;
- User interface requirements implemented by software;
- Data definition and database requirements;
- Requirements related to IT-network aspects;
- User maintenance requirements; and
- Regulatory requirements.
For class B and C software, risk control measures implemented must be included in the software requirements document.
Software architectural design
This process is only applicable for class B and C software where your organisation is required to develop an architecture for the interfaces of your software as a medical device that depicts the interfaces between your SaMD and other components external to your software.
Software detailed design
Only applicable for class B and C software, manufacturers have to document the sub-division of your software, including SaMD, into their respective software unit levels. For each of these units, only class C software is required for their units to be detailed down and verified.
Software unit implementation
Applicable to all software classes, manufacturers have to implement all the units. However, only class B and C medical devices are required to establish test protocols to verify each unit based on defined acceptance criteria by your organisation.
Software integration and integration testing
Only class B and C software require testing for integrating all software units.
Software system testing
During this activity, the tests for software requirements must be established for all software classes. These are also known as the tests for the complete software system. The problem resolution, re-testing after changes and evaluation of the tests, including the documentation, is also required.
Software release for utilisation at a system level
This process includes ensuring that all software verification activities mentioned in points 6 and 7 have been completed and evaluated before the software is released. Known residual anomalies have to be documented for all classes of software. Only class B and C software are required to have additional measures to evaluate these residual anomalies.
Similarly, only Class B and C software must document how the released software was created and ensure all activities and tasks are completed before the release.
Artificial Intelligence (AI) in Software as a Medical Device (SaMD) software
As the usage of artificial intelligence in medical software, including SaMD is trending thus, regulations are necessary. Various countries have begun developing guidance for ensuring patient safety in the healthcare industry.
In Singapore, the Ministry of Health has published a guidance document titled Artificial Intelligence in Healthcare Guidelines, which compliments the Regulatory Guidelines for Software Medical Devices – A Life Cycle Approach document by the Health Sciences Authority.
Medical devices that are currently considered AI medical devices by the Health Sciences Authority incorporate continuous learning capabilities.
As powerful as AI can be, it also poses a significant risk, which explains additional regulations. One other requirement is a clinical evaluation where evidence of performance testing with relevant data sets and results that validate the performance specifications must be provided.
Therefore, it is crucial to ensure that your organisation checks if the medical devices manufactured, including SaMD falls under the definition of AI medical devices as new regulations are being established for various countries.
Information Security in Software as a Medical Device (SaMD) software
Information security is another requirement for medical software devices, including SaMD software. With all the above advancements in technology mentioned, protecting patients’ data is crucial. This has led to the cyber security requirements for medical device software in various countries.
As seen in the Regulatory Guidelines for Software Medical Devices – A Life Cycle Approach, HSA has specified cyber security requirements for manufacturers to adhere to. It adopts a risk-based approach for manufacturers to identify cyber security hazards and mitigate them. Similarly, the ongoing monitoring of threats and the recovery plan is required. Adherence to the Personal Data Protection Act (PDPA) is also required.
Aside from Singapore, other countries also have regulations such as Europe’s General Data Protection Regulation (GDPR) and United States’ Health Insurance Portability and Accountability Act (HIPAA). To meet most of these requirements, it recommends complying with the ISO 27001 Information Security Management Systems standard.
This standard can be easily integrated with your existing ISO 13485 Quality Management Systems for your SaMD. To add on, the ISO 27001 standard also adopts a risk-based approach for your organisation. Also, it defines a list of reference controls that have to be adopted by your organisation if it applies.
Conclusion
Software as a medical device has been proven helpful in the healthcare industry. However, to market your SaMD software, many considerations must be taken into account in terms of regulations in various countries.
At Stendard, we believe that quality is everyone’s business because it takes a team to consistently deliver and uphold excellent standards that build confidence with customers, partners and the community.
We are a competent group of experts who can provide ISO consultancy services in Singapore and advice on using technological platforms for your company through this journey. We are committed to supporting your organisation’s certification process by equipping your team with the relevant knowledge and training to implement various standards such as ISO 13485, IEC 62304 and ISO 27001 for your SaMD software to meet multiple country’s regulations.
