MHRA Software Classification: A UK Healthtech Startup Guide

Why MHRA software classification matters more in 2026 than it did last year

If you are building software that touches a patient, a clinician or a care pathway in the UK, your MHRA software classification is the single decision that shapes your next 18 months. The draft amendment to the UK Medical Devices Regulations published on 8 May 2026 is expected to be adopted in December 2026 and come into force in June 2027, and it rewrites the classification rules for software specifically (Latham & Watkins summary). You are not classifying against the old EU MDR mapping any more, and pretending otherwise will cost you a funding round.

Most healthtech founders still ask the wrong first question. They ask what technology they are using, or which framework they should copy. The right question is what your software claims to do for a patient, because that is what MHRA will classify against.

The one non-obvious insight: your intended purpose sentence is your regulatory strategy

Here is the piece almost every seed-stage founder gets wrong. Your MHRA classification is not primarily driven by your architecture, your model type or whether you use AI. It is driven by the single sentence in your intended purpose statement that describes what the software does for a specific patient population in a specific clinical context.

Rewrite that sentence and you can move a Class IIa product to Class I, or an unregulated wellness tool to Class IIb. This is not a loophole. It is the way the MHRA classification guidance is designed to work, because risk to the patient scales with what you claim, not what you build. You should treat the intended purpose statement as a founding document, versioned alongside your pitch deck, and reviewed every time your product roadmap moves.

The practical implication: your first regulatory hire, or your first regulatory advisor, should be in the room when you write your first marketing page. Ship a homepage that overreaches and you have just reclassified yourself.

The new SaMD classification framework you will actually be assessed against

The 2026 draft amendment adopts the IMDRF SaMD risk categorisation, which combines two axes. The first is the significance of the information the software provides, ranging from informing clinical management, to driving clinical management, to diagnosing or treating. The second is the state of the healthcare situation, ranging from non-serious, to serious, to critical.

You end up with a grid. Software that drives clinical management in a critical situation is the top of the risk stack, and it will need Class III scrutiny. Software that informs clinical management in a non-serious situation sits at the bottom.

Two things founders miss. First, "drives clinical management" includes AI outputs that a clinician is expected to act on without independent verification, and this catches a lot of triage and prioritisation tools that were previously assumed to be Class I. Second, "critical" includes situations where a delayed decision leads to serious deterioration, which pulls a lot of remote monitoring tools upward.

The draft also formally introduces Predetermined Change Control Plans (PCCPs) for SaMD. If you are shipping software that changes weekly, a PCCP lets you define the modifications you anticipate up front and update the device without a fresh submission each time. If you are not planning your PCCP now, you are planning to freeze your product for 12 months at exactly the moment you should be iterating.

A three-step process to get your classification right the first time

Before you commission a formal regulatory review, run this process internally. It will save you between eight and twenty thousand pounds in consultancy time and, more importantly, will force you to write the intended purpose sentence you can actually defend.

Step one: write the intended purpose in one paragraph. Include the patient population, the clinical setting, the decision the software supports, and who acts on the output. Be specific. "Adults aged 40 to 75 in NHS primary care presenting with new atrial fibrillation, where the software flags high-risk cases for GP review within 24 hours" is a defensible sentence. "AI for cardiology" is not.

Step two: map that sentence to the IMDRF grid. Ask two questions. Does the software inform, drive, or diagnose/treat? Is the situation non-serious, serious, or critical? Write your answer down with the reasoning. If you cannot defend it in one paragraph, you have the wrong intended purpose statement, not the wrong classification.

Step three: pressure test with a clinician who works in that setting. This is where founders most often get burned. A cardiologist will tell you within five minutes whether your "informs" framing is defensible or whether clinicians will use it as "drives". Get that opinion in writing before you build.

Startup example: how getting classification right unlocked a £2.4m raise

A UK-based digital pathology startup came to us at pre-Series A, with a product they had been calling "AI-assisted diagnostic support for histopathologists". Their notified body conversation was heading toward Class IIb. They were three months from cash out.

Two things changed. First, they rewrote the intended purpose statement to make explicit that the pathologist reviews every case and the software provides a second-read prioritisation flag. Second, they narrowed the initial claim to two tissue types with existing evidence, rather than the six they had been pitching to investors.

The MHRA route shifted to Class IIa with a defined PCCP for adding tissue types. That single change, made three weeks before their term sheet closed, unlocked the raise because the lead investor could see a 14-month path to UKCA rather than a 30-month path. The product did not change. The words did.

NHS example: what a Trust actually asks for before it will pilot you

If you are selling into the NHS, your MHRA classification is the first line of the procurement conversation, not the last. NHS Trusts and ICBs are increasingly running a two-stage clinical safety and regulatory check before any pilot begins, and they now expect to see your intended purpose statement and your provisional classification before the DTAC assessment.

We recently supported a Trust in the Midlands piloting a remote monitoring tool for heart failure patients. The startup arrived with a Class I self-certification, based on their US 510(k) exempt status. The Trust's Clinical Safety Officer challenged it in the first meeting, because the software was clearly driving clinical decisions between clinic visits.

The pilot was paused for six weeks while the vendor reclassified to Class IIa and re-issued their intended purpose. That six-week pause cost the vendor a full quarter of revenue and reset their relationship with the Trust. If you are talking to NHS buyers, expect this to happen more often, not less, as CSOs get more literate on SaMD.

Failure example: the classification mistake that ended a company

A UK healthtech that raised a well-publicised £5m seed round in 2023 built a symptom-checker product they classified as Class I. Their intended purpose was written broadly, covering "self-triage guidance for common conditions", and the marketing page suggested users could rely on the output before deciding whether to seek care.

The MHRA opened correspondence in late 2024. The regulator's position was that the software drove clinical management in situations that could be serious, and belonged in Class IIa at minimum. The company had 90 days to either restrict claims or begin a full conformity assessment. They chose the assessment route and ran out of runway before completing it.

Two lessons. First, self-certification is a promise, not a shield, and the MHRA can and does challenge it. Second, if your marketing page reads more aggressively than your intended purpose, the marketing page is what regulators read. If you are self-certifying today, audit your website copy tomorrow.

What to do this quarter

Rewrite your intended purpose statement using the paragraph structure above and get it in front of a clinician who works in your target setting. If you are pre-launch, build a draft PCCP that covers the next 18 months of anticipated changes, because it will shape your entire QMS architecture. If you are post-launch and self-certified, run an internal reclassification exercise against the IMDRF grid this month, before an NHS buyer or the MHRA runs it for you.

Orbion Connect matches healthtech founders with the regulatory-literate clinicians who can pressure test your intended purpose in one paid session. See how our founders have used this to move faster through MHRA classification, or read about our approach if you want to work with us directly.