AI Software as a Medical Device: HSA Registration in Singapore

The short answer: risk class decides the route, and change control decides the cost

As of October 2026, AI medical device registration in Singapore follows the same risk-based framework as other medical devices under the Health Products Act 2007, with additional software- and AI-specific expectations set out in HSA guidance. If software is intended to diagnose, monitor, treat or manage a medical condition, it is generally a medical device. Class A software is exempt from product registration, while Class B, C and D software must be registered on the Singapore Medical Device Register before supply.

What makes AI different is change. Machine learning models are retrained, recalibrated and redeployed. HSA's December 2025 software guidelines and its Change Management Program (CMP) set out when an update needs a change notification and how manufacturers can obtain approval in advance for pre-specified changes.

Three developments shape the picture in 2026: the updated software guidelines, an exemption sandbox for lower-risk AI software developed and used within public healthcare, and the consolidation of health regulatory functions under HSA following legislation passed in September 2026. This article explains what each means for developers, hospitals and investors.

What changed in 2025 and 2026

Each item is listed on HSA's medical device guidance documents page, which should be checked before any submission because revisions are frequent.

Is your AI software a medical device, and which class?

HSA's digital health guidance explains that a digital health product intended for medical purposes, such as investigation, detection, diagnosis, monitoring, treatment or management of a medical condition, is generally regulated as a medical device. The intended use stated in labelling, marketing and the user interface is what counts, not the underlying technology. A general wellness app may fall outside the regime; the same model marketed to detect disease will not.

Medical devices are classified from Class A (lowest risk) to Class D (highest risk). For software, classification turns on the significance of the information provided to the healthcare decision and the seriousness of the condition. Software that drives clinical management for a critical condition will sit higher than software that informs management of a non-serious one.

Classification is the first decision in AI medical device registration in Singapore and it has direct cost consequences. Class A software medical devices are exempt from product registration but must still meet the essential principles of safety and performance. Class B, C and D software requires product registration, a registrant in Singapore and the appropriate dealer's licences. Where a local entity develops the software in Singapore, HSA's guidelines indicate a manufacturer's licence and a quality management system based on ISO 13485 are required. Our page on medical device compliance in Singapore explains licensing and registrant roles in more detail.

The process for AI medical device registration in Singapore

1. Fix the intended use. Write a precise intended use and indications statement. Everything that follows, including classification, evidence and change control, depends on it.
2. Classify the device. Apply HSA's risk classification rules and the SaMD and clinical decision support guidance. Record the reasoning, because HSA may challenge it.
3. Appoint a registrant and obtain licences. Identify the Singapore company that will hold the registration and obtain the manufacturer's, importer's or wholesaler's licences that the distribution model requires.
4. Assemble the technical dossier. Prepare the submission in the ASEAN CSDT format, including software versioning, verification and validation, clinical evaluation, risk management and cybersecurity documentation.
5. Add machine learning evidence. For machine learning-enabled devices, include the model description, the source and size of training data, inclusion and exclusion criteria, and performance on a test dataset independent of training and tuning data.
6. Decide on a change management plan. If frequent updates are expected, consider enrolling in the Change Management Program with the registration so that pre-specified changes can be approved upfront.
7. Submit and respond. File on HSA's systems, choosing the evaluation route available. Standalone software and mobile applications may use HSA's immediate registration pathway where prior approval by a recognised reference agency exists.
8. Plan post-market duties. Set up adverse event reporting, field safety corrective actions, real-world performance monitoring and complaint handling before launch.

Change management for AI models

HSA treats changes to registered software proportionately. Its software guidelines sort changes into categories with different review routes depending on the device class and the significance of the change: technical review for higher-risk devices, review or notification for Class B, and notification for administrative-level changes. Changes to the algorithm that affect performance, new inputs, new outputs or a change in clinical workflow (for example, removing specialist review of an AI output) typically require prior submission.

Continuous learning models attract additional questions. HSA asks whether the inclusion or exclusion criteria for retraining data change, whether the defined boundaries for allowable performance change, and whether the baseline performance used for comparison changes. Any of these can trigger a fresh submission. Manufacturers must also describe the learning process, how data is checked to match the original training attributes, and how performance drift is detected.

In practice, the evidence that supports a change decision should be generated by the engineering pipeline itself. Version-controlled model artefacts, dataset manifests, validation reports and a traceable link between each release and its risk assessment make it far easier to show HSA, hospital customers and investors that an update was assessed properly. Retrofitting this record after an incident is slow and rarely convincing.

Hospitals increasingly ask for the same material during procurement, so a disciplined change file pays off commercially as well as with the regulator.

The Change Management Program

The Change Management Program lets a manufacturer obtain HSA approval for pre-specified changes, such as a planned retraining with new data under a defined protocol, and then implement them under its own quality management system without a new change notification each time. To enrol, manufacturers must show compliance with ISO 13485 or MDSAP and IEC 62304. After approval, a declaration with the implementation record is due within one year, followed by annual declarations.

The public healthcare AI-SaMD sandbox

In February 2026, HSA published its response to consultation on exempting AI-SaMD developed by selected public healthcare entities for use in public healthcare from manufacturer licensing and product registration. HSA describes it as an "AI-SaMD sandbox" and a first step towards broader AI adoption.

The safeguards are specific. Only Class A and Class B AI-SaMD intended to diagnose or drive clinical management of non-critical conditions qualify. A public healthcare clinician at consultant level or higher must oversee design, validation and output. The Chairman of the Medical Board or the chief executive of the institution or cluster must endorse deployment, HSA must be notified before patient use, patients must be told when the software is used in their care, and developers must make yearly ISO 13485 self-attestations. Adverse effects must still be reported, and breaches can attract fines of up to S$20,000, imprisonment of up to 12 months, or both.

The sandbox does not extend to private hospitals or commercial developers. HSA has said it will consider widening the scope after evaluating outcomes. For private-sector developers, the practical relevance is twofold: public sector partners may build tools in-house rather than buy them, and a commercial partner that later takes over a sandbox product will need full registration.

Beyond HSA: data, AI governance and the integrated regulator

Registration is only one layer. AI developers also deal with personal data obligations under the PDPA, healthcare data rules, and the AI in Healthcare Guidelines (AIHGle 2.0) developed jointly by MOH and HSA, which set expectations for developers, deployers and users on accountability, transparency and deployment risk. Hospital customers will expect evidence of all of these alongside AI medical device registration in Singapore.

The consolidation of regulatory functions under HSA, which begins with the transfer of MOH regulatory functions from November 2026, aims to give industry a single point of contact across product regulation, healthcare services and research. HSA's announcement on the Bill notes that technologies such as AI may span several regulatory domains. Developers selling to licensed healthcare providers should expect more coordinated questions about how a product fits into clinical services, not only whether it is registered.

See our pages on health data governance and AI governance in Singapore, and our article on the Health Information Act and NEHR.

Cross-border strategy: overseas approvals and regional roll-out

Many AI developers arrive in Singapore with an approval elsewhere. A prior approval from a recognised reference regulator can shorten AI medical device registration in Singapore through HSA's immediate pathway for standalone software, but only if the product, version and intended use match what the reference agency approved. A model retrained for Asian populations, or a new output added for the Singapore launch, may no longer be the same device.

The reverse also applies. Companies that obtain AI medical device registration in Singapore first often use the Singapore dossier, prepared in the ASEAN CSDT format, as a base for filings elsewhere in Southeast Asia. Requirements and timelines differ market by market, and change-control approvals rarely travel automatically, so a single global change protocol needs local mapping.

Data flows add another layer. Training and validation data may be collected in one country, processed in a second and hosted in a third. Contracts with hospitals and cloud providers should address cross-border transfer rules under the PDPA and the laws of the source country. TRW & Co coordinates these workstreams across our network, including Bangladesh, the UAE and China, working with local counsel where foreign law applies.

An illustrative scenario

This scenario is illustrative only and does not describe any real client or matter.

A start-up develops an AI tool that flags suspected diabetic retinopathy from retinal images for review by an ophthalmologist. It initially describes the product as "decision support", but its marketing claims improved detection rates. Advisers conclude that the product is a medical device and, given the clinical significance of its output, falls in a class requiring registration.

The company appoints a Singapore registrant, prepares a CSDT dossier with validation results on an independent test set drawn from multiple sites, and files a CMP alongside registration describing quarterly retraining within defined performance boundaries. When it later wants to add a new output grading disease severity, that change falls outside the approved protocol and is filed as a change notification.

Risks and common mistakes

What to do next

• Write and freeze an intended use statement before planning AI medical device registration in Singapore.
• Run a documented classification against HSA's SaMD and clinical decision support guidance.
• Confirm the Singapore registrant and dealer's licences for your distribution model.
• Build the machine learning evidence pack: data provenance, independent test results and drift monitoring.
• Decide whether a Change Management Program will save time over the product's life.
• Map PDPA, cybersecurity and AIHGle 2.0 expectations into hospital contracts.

TRW & Co advises developers, healthcare providers and investors on AI medical device registration in Singapore, from classification and registrant structures to licensing terms with hospitals. See our healthcare regulation and telemedicine and digital health pages, or contact us to discuss your product.

Frequently asked questions

Sources and official materials

1. HSA: Digital health — When digital health products are medical devices; pathways
2. HSA: Guidance documents for medical devices — Current software, classification and change notification guidance
3. HSA GL-04-R4: Regulatory Guidelines for Software Medical Devices (December 2025) — Machine learning, continuous learning and change notification
4. HSA GN-37: Change Management Program for SaMD — Pre-specified changes and CMP eligibility
5. HSA: Response to consultation on AI-SaMD exemption — Public healthcare AI-SaMD sandbox safeguards
6. HSA: Health Sciences Authority (Amendment) and Other Matters Bill — Consolidation of health regulatory functions

General information only, current as at 20 October 2026. It is not legal advice and does not create a lawyer–client relationship. Singapore law and regulatory practice change; check current official sources and take advice on the facts of your matter.