Adopting a Life Cycle Approach to Software Medical Devices: Regulatory Guidelines by Singapore HSA

whose third revision was issued by the Singapore Health Sciences Authority. The guideline is designed to cover software of all Risk Classifications, covering regulatory obligations throughout the entire product life cycle. It specifically focuses on key software-related regulatory aspects including cybersecurity and obligations for Artificial Intelligence (AI) medical devices.

The guideline will cover the following topics:

• Quality Management System (QMS) for software medical devices
• Pre-market product registration obligations
• Dealer’s licensing obligations
• Change notification
• Post-market management of software medical devices
• Cybersecurity
• Artificial Intelligence
• Quality Management System (QMS) For Software Medical Devices

All producers of medical devices, including software medical devices, are required to implement a Quality Management System (QMS) to make sure consistent manufacturing quality. For software medical devices, good software quality and engineering practices is essential to control the quality of software products. The international standard ISO 13485 – Medical Devices – Quality Management Systems – Requirements for regulatory purposes outlines the obligations for a QMS that can be adopted by organizations involved in any stage of the medical device life cycle.

Pre-Market Product Registration Requirements

Product registration applications for medical devices submitted to HSA is required to conform to the format specified in the ASEAN Common Submission Dossier Template (CSDT) guideline. This format can be adapted from the International Medical Device Regulators Forum (IMDRF) Non-in Vitro Diagnostic Medical Device Market Authorization Table of Contents (nIVD MA ToC). The mapping between the pertinent sections in the IMDRF ToC dossier and CSDT is available at .

This section offers guidance for specific sections of the CSDT dossier where there may be particular obligations for software medical devices. Following are the sections covered here:

Essential Principles for safety and performance of medical devices

• Labelling obligations
• Software versioning and traceability
• Software verification and validation
• Clinical evidence
• Risk management
• Supporting guidelines for cybersecurity
• Software Manufacturers and Distributors: Activity Controls

All producers, importers, and/or wholesalers of software medical devices is required to hold medical device licenses for their respective activities. A prerequisite for obtaining a license is the establishment and maintenance of an appropriate quality management system (QMS), which should cover the following aspects:

Ensure that the software is developed and manufactured within an appropriate and effective quality management system (e.g., ISO 13485).

Ensure traceability of the software medical device, essential for tracking and tracing the software (e.g., software version) to users (e.g., physicians or patients) in the event of a Field Safety Corrective Action (FSCA) or product defect.

Provide assurance that proper procedures are in place for postmarketing surveillance and response, including the ability to handle product recalls and implement corrective actions (e.g., bug fixes, cyber alerts, software patches) in a timely and effective manner (planning, carry outing, and reporting of corrective action), and to identify any recurring problems requiring attention.

Ensure proper maintenance and handling of device-related records and information (e.g., customer complaints, distribution records, recall data) throughout the lifecycle of the software.

Do note that for all the scenarios mentioned in the guideline, the software medical device will require product registration.

Changes to A Registered Software: Change Notification

A software medical device undergoes a number of modifications throughout its product life cycle. These modifications are typically designed to (i) correct faults, (ii) improve the software functionality and performance to meet customer demands and (iii) make sure safety and effectiveness of the device is not compromised (e.g. security patch).

For instance, significant modifications, such as Technical & Review modifications, will necessitate a more comprehensive review compared to Administrative modifications to make sure that the alteration does not compromise the safety and effectiveness of the software. As such, non-significant software modifications are required to be notified to the HSA and are referred to as Notification modifications.

Below are some common examples of modifications that would require approval from the HSA before implementation.

A Technical Notification will be required for Class C and D products, and a Notification will be required for Class B products if:

• Alters an algorithm
• Addition of new features or software applications
• Addition or removal of alarm function
• Change in the operating system
• All other modifications, including minor adjustments to rectify errors or cover cybersecurity vulnerabilities, would require a notification.
• Post-Market Management of Software Medical Devices
• This section offers an overview of some postmarketing obligations that are also relevant to software medical devices.
• Field Safety Corrective Actions (FSCA)

An FSCA may be initiated when the product owner identifies specific risks associated with the use of the medical device during postmarketing monitoring and surveillance, such as through tracking product complaints or feedback. The purpose of initiating an FSCA is typically to communicate these risks to users and to outline the measures planned to mitigate them.

Adverse Events

Reports may come from various sources including surveillance of device log sheets, complaints or feedback from the user. It is crucial to promptly investigate these reports and implement corrective and/or preventive actions in a timely manner to effectively manage risks and prevent the recurrence of adverse events.

Software with Multiple Functions

Software medical devices typically consist of various functions, some of which may not meet the criteria detailed for a medical device in the Health Products Act (HPA). These non-medical device functions may include the following:

Software function that allows storing, converting formats or transferring patient data;

Software function that is designed to provide general patient education and facilitate access to commonly reference information;

Software function that allows automation of general office operations (e.g. patient scheduling, billing and etc.) in a healthcare setting.

Cybersecurity

When designing a software medical device, it’s essential to devise a cybersecurity plan that comprises the following considerations (non-exhaustive):

1. A secure device design
2. Having proper customer security guidelineation
3. Conduct cyber risk management
4. Conduct verification and validation testing and
5. Having an on-going plan for surveillance and timely detection of emerging threats
6. Artificial Intelligence Medical Devices (AI-MD)

This section coveres specific regulatory considerations pertaining to medical devices integrating Artificial Intelligence (AI) technology from a medical device regulatory perspective.

Regulatory Requirements for AI-MD

The regulatory principles for AI-MDs are comparable to software that are regulated as medical devices However, there are distinct additional considerations, such as continuous learning capabilities, the level of human intervention, model training, retraining, etc., which demand meticulous attention and tailored approaches when covering the regulatory obligations for AI-MDs.