Singapore HSA ‘Regulatory Guidelines for Software Medical Devices – A lifecycle approach’ Draft

Singapore HSA ‘Regulatory Guidelines for Software Medical Devices – A lifecycle approach’ Draft for Software Developer and Software in Singapore.


The Health Sciences Authority (HSA)'s Medical Devices Branch (MDB) has released a draft document for consultation by 31 January 2020:

'Regulatory Guidelines for Software Medical Devices – A lifecycle approach’

This document intends to provide clarity on the regulatory requirements for software medical devices during its entire lifecycle. The document is intended for stakeholders who are involved in software medical device development and /or supplying such devices in Singapore. It is important to note that these guidelines reflect HSA’s current thinking and practice, and should not be misconstrued as a new regulatory control on software medical devices.

This document applies to software with intended use that falls under the definition of a medical device as stipulated in the Health Products Act (HPA). This includes software supplied in the following forms:

Overall, the following topics will be covered in this document:

  1. Quality Management System (QMS) for software medical devices

  2. Pre-market product registration requirements

  3. Dealer’s licensing requirements

  4. Change notification

  5. Post-market management of software medical devices

  6. Cybersecurity

  7. Artificial Intelligence

1. Quality Management System (QMS) for software medical devices

All manufacturers of medical devices, including software medical devices should have a QMS in place to ensure manufacturing quality and consistency such as the ISO 13485.

2. Pre-market product registration requirements

a. Essential Principles for Safety and Performance of Medical device

The developer of a medical device can refer to HSA’s guidance document GN-16: Guidance on Essential Principles for Safety and Performance of Medical Devices.

b. Labelling requirements

c. Software versioning and Traceability

The software version information that represents all software changes/iteration (e.g. graphic interface, functionality, bug fixes) has to be submitted. This does not include Software version numbering that is solely for testing or internal use only (e.g. checking in of source code).

d. Design Verification & Validation

Reference to International Standards such as IEC 62304: Medical device software – Software life cycle processes is encouraged to demonstrate conformity to the essential requirements. The need for specific validation to address significant differences between the two software versions has to be considered, if the software version in validation report is different from the software version for product registration.

e. Clinical Evidence

The clinical evaluation process establishes that there is a valid clinical association between the software output and the specified clinical condition according to the product owner’s intended use.

The level of clinical evidence required depends on the significance of the information generated by the software medical device (to treat or diagnose, drive clinical management or inform clinical management) and the state of healthcare situation or condition. Literature review, Post-market experience are a basic requirements for all software type and clinical studies requirement is only required for software to treat or diagnose purpose. Where the software is assigned a novel intended purpose or is intended for use in new target populations, clinical studies should be carried out to support such use. After the software medical device has been deployed in the market, clinical data should be collected for continuous monitoring of the real-world clinical performance and post-market risk management.

3. Dealer’s licensing requirements


The software changes are typically meant to (i) correct faults, (ii) improve the software functionality and performance to meet customer demands and (iii) ensure safety and effectiveness of the device is not compromised (e.g. security patch). Change notification submission based on risk approach including Technical change and Notification change. Notification changes may be bundled together in one application (within a maximum of 6 months from the initiation of the change) or submitted together with other upcoming Review/Technical changes for the registered software. Do note that such bundled Notification changes are not allowed for AE/FSCA related changes and for changes to AI medical devices. CHANGES TO A REGISTERED AI-MD also described in the document.


Companies involved in distributing software medical devices in Singapore (manufacturers, importers, wholesalers and registrants) are required to comply with their post-market duties and obligations which includes reporting of device defects or malfunctions, recalls, Field Safety Corrective Actions and serious injuries or death associated with use of the device.

6. Cybersecurity


Other relevant legislation and guidelines applicable to the development and deployment of AI-MD in healthcare should be complied with:

· Personal Data Protection Act

· Human Biomedical Research Act

· Private Hospitals and Medical Clinics Act

There are specific AI-MD additional considerations such as continuous learning capabilities, level of human intervention, training of models, retraining etc

Recent Posts