An AI scribe is not automatically a medical device. Its regulatory status depends on what the software is intended to do, what it actually does and the claims made about it.

In Great Britain, the MHRA’s July 2026 guidance gives a particularly clear boundary. A product intended only to transcribe, summarise, structure information or draft documentation for clinician review can sit outside medical-device regulation when it does not have a medical intended purpose. Functions that introduce diagnosis, treatment recommendations, other medical-purpose outputs or certain autonomous actions can move the product into medical-device regulation.

Australia draws a similar functional distinction: transcription and translation without analysis or interpretation are not medical devices, while a digital scribe that analyses clinical information to generate a diagnosis, differential diagnosis or treatment recommendation not stated by the practitioner can meet the medical-device definition.

In the United States, the FDA applies a different statutory framework. Certain software functions are excluded from the device definition, while recommendation functions intended for healthcare professionals must satisfy all four Non-Device CDS criteria in section 520(o)(1)(E) to qualify for that exclusion.

The practical lesson across all three markets is:

Classification follows intended purpose and functionality, not the label “AI scribe.”

---

Why this question became easier to answer in 2026

The biggest clarification came from Great Britain.

On 29 July 2026, the MHRA published dedicated guidance explaining how existing medical-device law applies to ambient voice technology products. The guidance was developed in partnership with NHS England.

One point matters immediately:

The guidance does not create a new class of AI regulation.

It explains how existing UK medical-device law applies to AVT products.

The MHRA specifically says that healthcare use alone does not make software a medical device. Intended purpose remains central

That distinction matters because the same underlying AI technology can sit on opposite sides of the regulatory boundary depending on the function being provided and how the manufacturer describes its purpose.

---

The line, one function at a time

Function	Great Britain	United States	Australia
Transcription only	Generally outside device regulation where purely administrative	Generally assessed as a non-medical/administrative software function rather than CDS	Not a medical device where limited to transcription/translation without analysis
Summarising for clinician review	Can be non-device when limited to documenting what was discussed	Depends on intended function; documentation should be distinguished from CDS recommendations	Regulatory status depends on whether the function analyses or interprets for a therapeutic purpose
Drafting documentation	Can be non-device	Function-specific assessment	Can remain outside device rules where no therapeutic analysis/interpretation occurs
Clinical-code suggestion	Can be non-device where it maps information explicitly stated rather than making clinical deductions	Function-specific	Depends on whether interpretation gives the software a therapeutic purpose
Diagnosis/recommendation	Can make the product a medical device	Apply all four Non-Device CDS criteria; otherwise device regulation may apply	Medical device when analysis/interpretation produces relevant new clinical recommendations
Autonomous clinical action	Strong indicator of regulated medical functionality	Likely device functionality depending on intended use	Likely medical-device functionality depending on intended therapeutic purpose
If regulated	UK MDR classification requirements apply	Applicable FDA device classification/marketing pathway applies	ARTG inclusion required before supply

The apparent similarity should not obscure an important point:

These are three different legal frameworks.

Do not treat the MHRA rule as though the FDA or TGA simply copied it.

---

United Kingdom: the MHRA’s worked examples

The MHRA’s July guidance is particularly useful because it provides concrete AVT examples rather than discussing software only in abstract terms.

Products that can remain outside medical-device regulation

Transcript for clinician review

The MHRA describes an ambient scribe intended only to document the conversation.

The clinician reviews and can correct it.

Because the intended purpose is administrative documentation rather than diagnosis, monitoring, treatment or another medical purpose, the MHRA says this example is not a medical device.

Consultation summary

A product can summarise the encounter for later clinician review and correction without automatically becoming a medical device.

Again, the important boundary is that the software does not introduce clinical suggestions or recommendations beyond what was discussed.

Structured information

An AVT tool may also organise information from the encounter into structured fields for clinician review.

The fact that the output enters a clinical record does not by itself create a medical intended purpose.

---

Where the boundary changes

The regulatory position becomes different when the software moves from:

documenting what happened

towards:

interpreting what happened for a medical purpose.

Examples include software intended to:

• suggest a diagnosis;
• recommend treatment;
• calculate probabilities intended to influence diagnosis;
• take clinically meaningful actions without the required human review;
• perform functions presented or marketed as diagnostic.

The MHRA also makes clear that intended purpose is determined partly through labelling, instructions and promotional material.

That means:

Marketing can alter the regulatory analysis even when the underlying software appears similar.

---

A disclaimer does not override a medical claim

A particularly useful part of the MHRA guidance concerns disclaimers.

A manufacturer cannot simply state:

“This product is not for diagnosis.”

and assume that settles classification if the surrounding product, website, advertising or instructions communicate a diagnostic purpose.

The MHRA explicitly says general disclaimers are not sufficient where medical claims are made or implied elsewhere.

For founders, this means regulatory scoping involves more than reviewing code.

Review:

product → interface → intended-use statement → sales deck → website → advertising

as one system.

---

If the UK product is a device, how might it be classified?

AVT software qualifying as a medical device is treated as an active device under the current UK MDR framework.

MHRA guidance highlights two particularly relevant rules.

Rule 12

Other active devices are generally Class I.

Rule 10

An active device intended for diagnosis can become Class IIa where it enables direct diagnosis.

MHRA guidance explains that this can include software supplying decisive information used to make a diagnosis.

That distinction matters commercially because Class IIa involves third-party conformity assessment, whereas ordinary Class I devices generally follow a different conformity route.

Classification still needs to be assessed against the particular intended purpose.

---

The NHS layer applies separately from device classification

This is one of the most important parts of the article.

A product being outside medical-device regulation does not mean that every NHS assurance requirement disappears.

NHS England updated its ambient-scribing guidance on 29 July 2026 to align with the MHRA guidance. The NHS guidance explicitly says organisations remain responsible for safe and appropriate AVT deployment.

It also emphasises issues including:

• clinician review of outputs;
• training;
• privacy and consent;
• information quality;
• automation bias;
• incident reporting;
• performance monitoring;
• clinical governance;
• change management;
• interoperability;
• cybersecurity;
• regulatory compliance.

Depending on the deployment, other NHS assurance obligations can therefore remain relevant, including DCB0129, DCB0160, DTAC and DSPT.

Device status answers one question.

It does not answer the entire NHS deployment question.

---

The AVT Supplier Registry has now reached 29 suppliers

This is one of the changes since the previous draft.

NHS England’s live Ambient Voice Technology Self-Certified Supplier Registry now lists 29 suppliers.

Applications reopened on 3 February 2026 and remain open.

Importantly, NHS England says the registry exists to support local procurement and assurance.

The final assurance and decision-making responsibility remains with the local NHS organisation.

So inclusion on the registry should not be interpreted as:

NHS England has approved this product as clinically safe for every deployment.

Local evaluation still matters.

---

HSSIB is now investigating AVT patient safety

The Health Services Safety Investigations Body notified a national investigation on 6 August 2026 into the use of Ambient Voice Technology in hospitals.

The investigation focuses on acute adult secondary-care settings and will examine:

• how AVT has contributed, or could contribute, to patient harm;
• patient-safety risks associated with AVT;
• how accountability for AVT safety is understood locally and nationally.

HSSIB says adoption is accelerating while the safety implications are not yet fully understood. It also notes that existing discussion has focused heavily on efficiency while routes for recognising and reporting AI-related safety incidents remain immature.

The investigation report is expected in summer 2027.

This is worth monitoring because it could materially influence future NHS implementation guidance even without changing medical-device classification itself.

---

The wider UK medical-device framework is also moving

The AVT guidance describes the current regulatory framework.

But that framework is undergoing reform.

In May 2026, the MHRA published the draft Medical Devices (Amendment) Regulations 2026, covering proposed changes including international reliance, device identification and stronger alignment between device claims and intended purpose.

Those remain proposed reforms rather than a replacement for the current AVT classification rules.

A newer development came on 1 September 2026, when the Government tabled amendments to the Health Bill relating to MHRA regulatory reform, information sharing and powers supporting a possible future medical-device licensing regime.

Critically, the MHRA says:

These amendments do not create immediate changes to current medical-device regulation.

So the July AVT guidance remains the relevant current classification reference while the wider reform programme develops.

---

United States: use the four CDS criteria

The US framework should not be described as a direct equivalent of the MHRA AVT guidance.

The FDA’s current Clinical Decision Support Software guidance was updated in January 2026 and reissued on 29 January 2026.

Section 520(o)(1)(E) of the FD&C Act excludes certain CDS software functions from the definition of device when all four statutory criteria are satisfied.

In simplified terms, the software must:

1. not acquire, process or analyse specified medical images or signals;
2. display, analyse or print medical information about a patient or other medical information;
3. support or provide recommendations to a healthcare professional;
4. enable the healthcare professional to independently review the basis of those recommendations so that they do not rely primarily on the software.

The fourth criterion matters particularly for AI.

A model that provides a clinical recommendation without giving the clinician sufficient information to independently evaluate its basis may fail the Non-Device CDS criteria.

That does not mean every AI-generated suggestion automatically becomes a medical device.

It means the exact function needs to be tested against the statutory criteria.

---

Do pure documentation functions need FDA clearance?

Do not start with:

“It uses AI.”

Start with:

“What software function is being provided?”

The FDA framework distinguishes software functions that meet the statutory device definition from software functions excluded from it.

A documentation function should therefore be assessed separately from a clinical-recommendation function.

If the product adds diagnosis, prediction, treatment or other clinical decision-support capabilities, the regulatory analysis can change even though the underlying interface still looks like a “scribe.”

---

Australia: intended purpose remains the dividing line

Australia now has particularly direct guidance for digital scribes.

The TGA states that digital scribes intended only to transcribe and translate clinical conversations into written records without analysis or interpretation are not considered medical devices.

However, if the software analyses or interprets the clinical conversation — for example by generating:

• a diagnosis;
• a differential diagnosis;
• a treatment recommendation

that was not explicitly stated by the healthcare practitioner, it can meet the definition of a medical device under section 41BD of the Therapeutic Goods Act 1989.

Where a digital scribe meets that definition, TGA guidance says it must meet the relevant regulatory requirements and be included in the Australian Register of Therapeutic Goods before supply.

---

Feature creep matters in Australia

The TGA specifically warns developers to reassess products as functionality changes.

A product may begin as:

conversation → transcript

and remain outside device regulation.

Later it becomes:

conversation → transcript → AI diagnostic suggestion

That new functionality can alter the intended purpose and therefore the regulatory status.

This is why regulatory classification should exist inside release governance, not only inside the initial product specification.

---

Using an external LLM does not remove manufacturer responsibility

Another important TGA point is that developers using third-party AI models still need to assess their own obligations.

The TGA’s current AI/software guidance says developers of AI-enabled medical-device software can meet the legal definition of the manufacturer or sponsor depending on their role.

So:

“We use somebody else’s foundation model” is not itself a regulatory exemption.

The regulatory analysis follows the product placed on the market and its intended purpose.

---

What this means if you run a clinic

Ask whether the software introduces information that was not stated.
That is one of the most useful questions for distinguishing documentation from clinical interpretation.

Ask what happens before information enters the record.
Clinician review is an important part of the workflows described by regulators and NHS England.

Read the marketing claims.
A product website promising diagnostic or treatment support can matter to intended-purpose analysis.

Check the relevant register where appropriate.
For Australian medical devices, check ARTG status. For NHS AVT procurement, understand what inclusion on the Supplier Registry does — and does not — mean.

Review each new feature.
Classification can change after release.

---

What this means if you are building an AI scribe

Before finalising the intended purpose, answer these questions:

• Does any feature create clinical information that was not present in the underlying encounter?
• Does the software infer from implicit information?
• Does it suggest diagnosis, prognosis or treatment?
• Can the output trigger clinical action without meaningful human review?
• Can the clinician understand and challenge the basis of a recommendation?
• What claims appear on the website, sales deck and product interface?
• Are you relying on a disclaimer despite making medical claims elsewhere?
• What happens when new functionality is introduced?
• Which jurisdiction is the product entering?
• Do deployment requirements apply even if the feature is not a medical device?

The recurring pattern is:

Regulatory classification is a product-scoping decision.

It becomes much cheaper to address when intended purpose, workflow and feature boundaries are settled before architecture and marketing claims are locked.

---

Frequently asked questions

Is an AI scribe a medical device?

Not automatically. Regulatory status depends on intended purpose and functionality. In Great Britain, the MHRA says AVT products limited to administrative documentation such as transcription and certain summaries for clinician review can fall outside medical-device regulation. Functions providing diagnosis, treatment recommendations or other medical-purpose outputs can change that position. Australia follows a similar intended-purpose approach, while the US applies its own statutory software and CDS framework.

Does an AI scribe need MHRA registration?

Only if it falls within the relevant medical-device regulatory requirements. NHS England’s current AVT guidance aligns with the MHRA’s July 2026 classification guidance rather than treating every ambient scribe as a medical device.

Does the MHRA’s July 2026 guidance change the law?

No. It explains how existing Great Britain medical-device legislation applies to AVT products.

Can an AI summary remain outside UK medical-device regulation?

Yes, depending on its intended purpose and functionality. The MHRA provides an example of a consultation summary produced for clinician review and correction that is not a medical device because it does not provide clinical suggestions beyond the encounter.

Can a disclaimer keep an AI scribe outside medical-device regulation?

Not by itself. The MHRA says a general non-diagnostic disclaimer cannot override medical claims made or implied elsewhere in the product’s labelling or promotional material.

Can marketing claims affect classification?

Yes. Intended purpose is informed by claims made in instructions, labelling and promotional material, including websites and advertisements.

Does an AI scribe need FDA clearance in the US?

Not simply because it is called an AI scribe. The FDA assesses the particular software function. Certain CDS functions can be excluded from the device definition when all four criteria under section 520(o)(1)(E) are satisfied; functions that remain devices follow the applicable FDA regulatory pathway.

Does the TGA regulate AI scribes in Australia?

Some. The TGA says transcription or translation without analysis or interpretation is not a medical device. A product that analyses information and generates a diagnosis, differential diagnosis or treatment recommendation not stated by the practitioner may be a medical device and require ARTG inclusion.

If our scribe is not a medical device, do NHS assurance requirements disappear?

No. Medical-device status is only one part of NHS deployment. Clinical safety, information governance, cybersecurity, interoperability, procurement and local governance obligations may still be relevant depending on the product and deployment. NHS organisations remain responsible for ensuring AVT is deployed safely and appropriately.

How many suppliers are currently on the NHS AVT Supplier Registry?

Twenty-nine, as of 25 September 2026. NHS England says applications remain open and that local NHS organisations retain assurance and decision-making responsibility.

Is AVT safety being formally investigated?

Yes. HSSIB launched an investigation in August 2026 into AVT use in hospitals, focusing on patient harm, safety risks and accountability. Its report is expected in summer 2027.

Are UK medical-device rules changing again?

Reform is underway, but there has been no immediate replacement of the current AVT classification framework. Draft pre-market regulations were published in May 2026, and further Health Bill amendments were tabled in September. The MHRA states that the September proposals do not immediately change current medical-device regulation.

---

About the author

Kamna Singh Thakur is CEO and Founder of KastHunt Consulting LLP, an AI-native healthcare technology firm serving clinics, healthtech founders and health systems across the UK, US and Australia. She has spent nine years in healthcare technology across business development, account management and digital transformation, and grew up in a clinical household — her mother, Leela Verma, spent 40 years in frontline nursing, medicine and behavioural health, including NHS service.

She writes about clinical AI governance, healthcare product delivery, and what actually survives deployment in a real clinical environment.

Questions or corrections: info@kasthunt.com

---

Related reading

• Claude in Clinical Documentation: What the Evidence Shows
• Which Open Medical AI Models Can You Deploy in a Clinic?
• What Healthcare Architecture and Database Diagrams Need to Show

---