The SaMD definition statement should include a clear and robust statement about intended use, including the following:

The term “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.

SaMD is software that carries out one or more medical tasks. If it might be incorporated with a piece of hardware, the software performs a medical function.

The international medical device regulators Forum (IMDRF) defines SaMD as “software that may operate on general-purpose (non-medical) computing platforms, may be combined with other products, including medical devices, and may interface with other medical devices or other general-purpose hardware or software that provide input to SaMD.”

Software that turns the magnets in an MRI or animates an X-ray control panel are examples of software that is necessary for hardware operation but is exempt from SaMD. Software that only organizes data, retrieves data, or speeds up operations is also insufficient.

Classification of IMDRF Regulation on SaMD

The following are necessary principles required in the categorization approach of SaMDs. 

• An accurate SaMD definition is a prerequisite for the categorization of the device.
• The importance of the information provided by the SaMD to the healthcare decision and the situation or condition are combined to determine the categories.
• The four classifications (I, II, III, and IV) are based on the severity of the impact on the patient or public health, where accurate information provided by the SaMD to treat or diagnose, guide or inform clinical management is essential to prevent death, long-term disability, or other severe deterioration of health, mitigating public health.
• The impact level is at its maximum in Category IV and lowest in Category I.
• According to the details provided in the SaMD definition statement, a manufacturer’s SaMD is classified in the highest category when it can be employed in various healthcare settings or conditions.
• The classification of SaMD should be correctly re-evaluated when a manufacturer modifies SaMD during the lifecycle that causes the definition statement to change. The information in the revised (new) SaMD definition statement is used to categorize the SaMD.
• Even when a SaMD is interfaced with other SaMDs, other hardware medical devices, or employed as a module in a more complex system, it falls under the category specified in its SaMD defining statement.

The above table represents the risk categorization of IMDRF regulation for SaMD based on the significance of the information provided by SaMD to healthcare decisions and the state of the healthcare decision.

Identifying risks and putting safeguards in place that assure acceptable risks are necessary for creating safe SaMD. It is well acknowledged that testing software is insufficient to establish operational safety.

As a result, it is acknowledged that confidence should be included in the software to guarantee its security.

The IEC 62304 standard governs the lifecycle development of medical device software. The standard highlights three key safety concepts that are pertinent to SaMD, defines basic testing requirements, and proposes a risk-based decision methodology: 

• Risk management. 
• Quality management. 
• Methodical and systematic systems engineering according to best industry practices.

Combining these concepts helps IMDRF regulation on SaMD manufacturers follow a clearly structured and consistently repeatable decision-making process to promote safety for SaMD. 

Design and Development

A quality-assured approach to software development should consider the selection and implementation of system design and development methods that: 

• Incorporate a structured development using models, methods, architecture and techniques appropriate for the development language(s) and the device’s intended use,
• Cover the various stages of the software lifecycle using IEC 62304 as a reference standard for software development. Software Engineering Body of Knowledge (SWEBOK)  and Systems Engineering Body of Knowledge (SEBoK) must be used as reference books for software engineering and
• The design and development process must be documented systematically (using appropriate tools.)

Post Market Surveillance

SaMD manufacturers should continuously monitor customer complaints to maintain the safety level because software hazards can never be eradicated.

Customer feedback must be gathered as part of the monitoring process, for instance, through enquiries, grievances, market research, focus groups, service, etc. SaMD and other software have inherent characteristics that effectively comprehend and record user experiences.

The use these feedback mechanisms by IMDRF regulation on SaMD makers is advised to comprehend failure modes and conduct analysis to address safety concerns.

Additionally, it is recommended that SaMD manufacturers expand their monitoring to detect system or software errors automatically, i.e., identify and fix an error before a failure happens.

Quality Management System

Medical device QMS principles allow the measurement of activities depending on  

• The type of medical device.  
• Risk of the product to patients.  
• Size of the organization.  
• Technology or automation is used to manufacture.  
• And other factors are determined by the manufacturer to control quality and maintain the safe and effective performance of the medical device. 

SaMD, a software-only product, is manufactured primarily using automated software development tools to assist development lifecycle activities.

In some circumstances, these computerized processes could take the role of deliberate or discrete acts generally present in creating physical items (such as transferring design to production).

To control the quality of SaMD, however, it is still necessary to adhere to the QMS principles that give the lifecycle processes and activities structure and support.

An effective QMS for IMDRF regulation on SaMD have to include the following principles:  

• An organizational structure ensures SaMD’s safety, efficacy, and performance by providing leadership, accountability, and governance with enough resources. 
• A set of SaMD lifecycle support processes that are scalable to the organization’s size and applied consistently across all realizations and use processes  
• A set of realizations and use processes that are scalable for the type of SaMD and the organization’s size takes into account essential elements required for assuring the safety, effectiveness, and performance of IMDRF regulation on SaMD. 

FAQs

What are some of the examples of SaMD?

·         Applications for viewing MRI, Ultrasound, or X-Ray examinations images
·         Software for detecting cancer using image processing
·         Software using AI for analysis of test reports and detection of pathologies
·         Software that analyses data from other devices for assessing the patient health and calculating the risks
·         Applications that calculate the dosage of the patient using the data of patient health

How do I know if my application is classified as SaMD?

Classification of software as a medical device can be tricky. However, it is imperative first to know if the software falls under the definition of SaMD. One should consider the following to classify any software as a medical device:
·         If the software can perform or take part in the treatment processes
·         It can be launched on hardware devices such as smartphones, computers, tablets, smartwatches
·         If the software is not intended to manage a hardware medical device and is a standalone medical product
·         It can be used with hardware medical devices and integrated into the ecosystem of devices
If the above is invalid, the software does not fall under a medical device, and medical device regulations need not be followed.

Disclaimer: Regulations/legislations are subjected to changes from time to time and the author claims no responsibility for the accuracy of information.