Healthcare is the most exciting frontier in applied AI — and the easiest place for a founder to build something brilliant that can never legally launch. The difference between those outcomes usually comes down to one concept understood early: Software as a Medical Device (SaMD).
A note before we begin: this article is an orientation, not legal or regulatory advice. Rules evolve, and classification is case-specific — treat this as the map, then verify the territory with a regulatory professional and official MHRA guidance.
The question that decides everything
UK regulation, overseen by the MHRA (Medicines and Healthcare products Regulatory Agency), hinges on intended purpose. The core question is disarmingly simple:
Does your software's output inform or influence a decision about diagnosis, treatment, or patient management?
If yes — even indirectly, even "just as a suggestion the doctor can ignore" — you are likely in medical-device territory, with everything that implies: classification, quality management, clinical evidence, registration, post-market surveillance.
What counts as SaMD — and what doesn't
Notice the pattern: the left column touches logistics; the right column touches clinical judgement. The same underlying AI technology can sit in either column — what moves it is the claim you make and the decision it feeds.
Risk classes in plain English
Devices are classified by potential harm — from Class I (low risk) up through IIa, IIb and III (highest). The higher the class, the heavier the evidence and oversight. Two intuitions carry you far:
Consequence: what happens if your software is wrong? An incorrect gym-plan suggestion and an incorrect sepsis alert live in different universes.
Autonomy: does a clinician independently verify the output, or does your system drive action directly? The less human checking, the higher the scrutiny.
Most diagnostic-support AI lands in Class IIa or above — meaning a notified/approved body reviews your evidence before you can affix the UKCA mark and sell.
Habits that cost pennies now, fortunes later
Even at prototype stage — before hiring consultants — disciplined teams build habits that make eventual certification dramatically cheaper:
Document decisions. Why this model, this dataset, this threshold? A running decision log becomes the backbone of your technical file.
Version everything. Data, models, prompts, evaluation sets. "Which version produced this output?" must always have an answer.
Measure like a regulator. Track sensitivity, specificity, and failure modes on a held-out set from day one. Also learn the NHS's DTAC (Digital Technology Assessment Criteria) early if the NHS is your market — procurement will ask.
Design the human in. Decide explicitly what the clinician sees, verifies, and can override. "Human-in-the-loop" is an architecture, not a slogan.
UK vs FDA — the founder's view
Both regimes ask the same fundamental questions — is it safe, does it work, can you prove it — but the paperwork and pathways differ. The strategic takeaway for an early-stage team: build one rigorous evidence base (clear intended use, documented development, honest performance data) and you'll be able to walk through either door. Teams that "do regulation later" end up rebuilding their product's paper trail from archaeology.
Healthcare AI rewards patience. The founders who treat regulation as product design — not as an obstacle after product design — are the ones whose products actually reach patients.
Is your software likely a medical device?
A quick orientation — not legal advice, but the right first questions.
Answer both to see where you likely stand ☝️
Building clinical AI and unsure where you stand?
We build healthcare AI with regulatory awareness from the first line of code. Describe your product — we'll flag the questions you need answered.
Book a free discovery call ✦