Singapore's Ministry of Health and Health Sciences Authority published AI in Healthcare Guidelines 2.0 (AIHGle 2.0) in March 2026, updating the 2021 version. Its most distinctive feature is structural: rather than regulating AI systems by risk tier, it allocates responsibilities across three roles — developers, healthcare institutions and clinicians — and describes what each owes across the AI lifecycle.
That role-based split determines which obligations attach to you rather than to your vendor or clinical staff. For the wider picture, see AI for government health agencies. Current as of September 2026 — verify against the primary guidelines before relying on specifics.
The three roles
Developers — responsibilities concentrate on the development process, performance characterisation, documented intended use, and transparency about limitations to downstream users.
Healthcare institutions — responsible for the deployment decision, integration, staff training, and post-deployment monitoring. Institutions most often underestimate this last point: a system validated on the developer's population may perform differently on the institution's, and that responsibility sits with the institution, not the vendor.
Clinicians — responsible for appropriate use and retained clinical judgement. The clinician's accountability for the clinical decision is not transferred by the presence of an AI system. See human-in-the-loop AI in healthcare.
Why the split matters commercially: it means a vendor cannot deliver "compliance" as a product. A developer can meet its own obligations and hand over documentation that enables the institution to meet its own — but the institution's obligations remain the institution's.
Singapore versus the EU
Singapore relies on sectoral guidelines layered on existing legislation, with responsibilities allocated by role. The EU AI Act is a horizontal statute with obligations by risk tier, including conformity assessment and registration for high-risk systems. What actually converges: both expect documented intended use, risk proportionality, transparency, human oversight, and lifecycle monitoring. See the EU AI Act and healthcare AI.
Where Eclypse sits: deployment documentation covers intended use, development population and known limitations as standard deliverables — the developer artefacts an institution needs to meet its own AIHGle obligations.
The role split is the key to using these guidelines well: knowing which obligations are yours, which are your vendor's, and which stay with the clinician.
Common questions about Singapore's AI healthcare guidelines.
What is AIHGle 2.0?
Singapore's AI in Healthcare Guidelines version 2.0, published by MOH and HSA in March 2026, allocating responsibilities across developers, institutions and clinicians.
Are Singapore's AI healthcare guidelines legally binding?
The guidelines are authoritative expectations rather than statute, but sit alongside binding regimes — the PDPA, and HSA's framework where the AI is a regulated medical device.
Who is responsible for AI compliance under AIHGle 2.0?
Split across developer, institution and clinician. A vendor cannot deliver institutional compliance as a product.
How does Singapore's AI regulation compare to the EU AI Act?
Singapore uses sectoral guidelines with role-based responsibility; the EU uses a horizontal statute with risk-tiered obligations. The underlying expectations converge; the instruments differ.
Walk us through your validation requirements — we'll map them against the framework.
Book a working session
ECLYPSE
AI
Our proprietary AI orchestration platform for healthcare: one engine, a registry of reusable task modules and domain agents, and a governed knowledge base — deployed inside your walls and run by your team.