In healthcare, one question decides which rules apply to your AI: is it used for a medical purpose? If so, the MHRA regulates it as a medical device. Here’s what that means in 2026, cited to official sources. (dgm implements osFoundry as an independent partner. General information, not regulatory or clinical advice.)
The dividing line: medical purpose
AI or software used for a medical purpose — to diagnose, prevent, monitor, predict, treat or alleviate disease — is regulated as a medical device by the MHRA. This is “software as a medical device” (SaMD) or AI as a medical device (AIaMD), and it’s a separate, stricter regime from general AI and data-protection governance.
The practical implication: where your AI sits relative to that line changes everything.
Clinical vs non-clinical AI
| Likely a medical device | Likely NOT a medical device |
|---|---|
| Diagnostic/triage AI making clinical calls | Administrative automation |
| Treatment recommendation tools | Correspondence triage / routing |
| Risk-prediction influencing care | Knowledge retrieval for staff |
| Ambient scribing that doesn’t decide care |
So non-clinical healthcare AI (admin, retrieval, drafting) typically avoids device regulation; clinical/diagnostic AI does not. Assess each use case against the medical-purpose test.
What’s changing in 2026
The MHRA’s framework is actively evolving:
- New post-market surveillance rules came into force in June 2025;
- the “AI Airlock” regulatory sandbox completed its pilot in March 2025;
- international reliance pathways (recognising FDA/Health Canada/TGA approvals) were announced to open in H1 2026; and
- a dedicated AIaMD regulatory framework is expected in 2026.
(These dates draw on regulatory commentary — confirm against the MHRA/gov.uk before relying on them.)
The practical path
For most NHS and healthcare-provider AI projects, the fastest, lowest-risk start is non-clinical: reducing admin burden, triaging correspondence, retrieving knowledge — clear value without entering device regulation. Clinical/diagnostic AI is worthwhile but brings MHRA into scope, with conformity, post-market surveillance and clinical-safety obligations.
Where osFoundry and dgm fit
dgm builds non-clinical healthcare AI — admin, retrieval, triage support — with NHS-grade controls on osFoundry: data control (self-host in your own cloud or an EU region; it publishes US/EU/JP regions, not a UK one), audit logging, and human oversight, designed around NHS Information Governance and DTAC. We help you identify where a use case crosses into medical-device territory, so you go in with eyes open. See our NHS trusts guide for the wider NHS picture.
dgm is an independent integration partner with zero integrations so far. Medical-device compliance and clinical responsibility stay with the provider/manufacturer. To scope a compliant healthcare AI project, book a consultation with dgm. General information, not regulatory or clinical advice.