UK MHRA Issues Guidance on Ambient Voice Technology: Transcription and Summarisation Are Not Medical Devices, Diagnostic Decision-Making Is

Overview

On 29 July 2026, the UK Medicines and Healthcare products Regulatory Agency (MHRA) and NHS England jointly published guidance on ambient voice technology (AVT) products — commonly described on the market as AI clinical documentation assistants or AI scribes. The document identifies five categories of functionality that do not make a product a medical device: transcription only; summarisation only; structuring data only; suggesting clinical codes based only on terms explicitly mentioned in the conversation; and drafting discharge summaries or letter drafts. Conversely, products whose intended purpose is diagnosis, treatment or prevention, or that automatically perform an action in place of a clinician (for example, placing an order without clinician review), remain regulated as medical devices. The guidance does not change the law; it explains how the UK Medical Devices Regulations 2002 (UK MDR) apply, and it requires manufacturers to re-assess device status after every functional change.

Full Translated Source Content

A Document That Answers One Question

Ambient voice technology (AVT) has expanded rapidly over the past two years. As a clinician conducts a consultation, AI converts the conversation into text and generates a summary. The question is whether such products constitute medical devices.

On 29 July 2026, the UK MHRA provided the answer.

The MHRA published guidance on that date covering ambient voice technology-enabled products — what the market commonly calls AI documentation assistants or AI scribes. The document was written jointly by the MHRA and NHS England.

It addresses a single question: under what circumstances do these products constitute a medical device, and under what circumstances do they not.

The boundaries should be stated clearly first. This is not new legislation. It does not alter any provision of the UK Medical Devices Regulations 2002 (UK MDR). The guidance sets out how the MHRA applies the existing regulations to these products.

On the same day, NHS England published accompanying clinical use guidance.

Five Categories of Functionality That Are Not Medical Devices

The MHRA uses five examples to delineate the lower-risk zone.

• Transcription only. Converting clinician–patient dialogue into text for clinician review and amendment. The product provides no additional recommendations.
• Summarisation only. Summarising a consultation for clinician review before it is entered into the electronic health record.
• Structuring conversational information. For example, populating a problem list, medication list or order set for the clinician to confirm or reject.
• Suggesting clinical codes based on terms explicitly stated in the conversation. The product does not infer a diagnosis; it performs literal matching only.
• Drafting discharge summaries or letters for clinician amendment.

What these five categories have in common is that they touch only administrative and documentation tasks and do not produce new clinical judgements.

One further statement in the guidance is worth noting: using a product in a healthcare setting does not, in itself, make it a medical device.

Two Categories That Remain Medical Devices

If the intended purpose of a product is to support diagnosis, treatment or prevention, it is a medical device.

If a product automatically performs actions in place of a clinician — for example, placing an order without clinician review — it is likewise a medical device.

How is intended purpose determined? It is assessed from labelling and instructions for use, and also from promotional material. Descriptions on a manufacturer's website, claims made in sales demonstrations and online advertising are all taken into account.

There is a practical pitfall here. The guidance explicitly states that a disclaimer such as 'this product is not intended for diagnostic use' does not neutralise medical claims made elsewhere. A disclaimer is the lowest level of risk control; manufacturers should prioritise eliminating risk through design.

Re-assessment Is Required After Every Functional Change

The MHRA reminds manufacturers that a product that was not a device at launch will not necessarily remain outside the definition.

Once a manufacturer adds functionality or broadens the intended use, the product may fall within the definition of a medical device. The guidance is explicit: every change must be re-evaluated.

The guidance also highlights a specific technical risk. Hallucinations in large language models have a broad impact in AVT products. Manufacturers must identify and mitigate this risk in line with the product's intended purpose, and should prioritise design changes over added warnings.

Implications for Manufacturers and Clinical Organisations

For manufacturers, this is a recalibration of the regulatory baseline. Whether a product is a device directly determines its compliance pathway.

Under the classification rules set out in the MHRA standalone software guidance, active devices intended for diagnosis fall into Class IIa, while other active devices fall into Class I. Products in Class IIa and above require UKCA certification issued by an Approved Body. Classification references cited in the guidance include Rule 10 and Rule 12.

The territorial scope must be stated clearly. These rules cover Great Britain — England, Wales and Scotland. Northern Ireland continues to apply the EU MDR (2017/745) under the Windsor Framework.

For clinical organisations, the MHRA requires NHS boards to confirm four things: clinical oversight, local governance, staff training and procurement processes. They must also be able to identify changes in regulatory status arising from changes in product functionality.

Clinicians must still review AI-generated transcripts, summaries and other outputs. This responsibility is unchanged by the guidance.

Sources and Scope of Verification

• UK Medicines and Healthcare products Regulatory Agency (MHRA) news release, 'MHRA clarifies regulatory status of ambient voice technologies used in the NHS', published 29 July 2026: https://www.gov.uk/government/news/mhra-clarifies-regulatory-status-of-ambient-voice-technologies-used-in-the-nhs
• MHRA guidance, 'Ambient voice technology-enabled products': https://www.gov.uk/government/publications/ambient-voice-technology-enabled-products/ambient-voice-technology-enabled-products
• MHRA guidance PDF, 'Guidance on Ambient Voice Technology-Enabled Products': https://assets.publishing.service.gov.uk/media/6a68daaff23ff62c51c1a7a3/MHRA_Guidance_on_Ambient_Voice_Technology-Enabled_Products.pdf
• NHS England, 'Guidance on the use of AI-enabled ambient scribing products in health and care settings': https://www.england.nhs.uk/long-read/guidance-on-the-use-of-ai-enabled-ambient-scribing-products-in-health-and-care-settings/

Verification scope and access date: the above MHRA news release, guidance page and guidance PDF (including Section 4 on determining device qualification, Section 5 on qualification examples, and the classification references to Rule 10 and Rule 12) and the accompanying NHS England guidance page were accessed and verified on 28 September 2026. Article reference numbers for UK MDR 2002 and EU MDR 2017/745 cited in the guidance are subject to the official texts.

Scope statement: this article is an interpretation of publicly available regulatory information and does not constitute a conclusion or commitment regarding any specific product, company or registration application. Whether a specific product qualifies as a medical device must be determined case by case on the basis of its intended purpose as stated in labelling, instructions for use and promotional material, and in accordance with the official texts and any subsequent updates.

AIMEILI Regulatory Interpretation and Business Impact

What This Means for Medical Device Companies

For international registration of AI medical devices and software medical devices, regulators generally focus not only on the description of product functions but also on algorithm intended use, risk control, data provenance, performance validation, cybersecurity, the software lifecycle, clinical evaluation, and post-market continuous learning and version change management.

Classification, evidentiary requirements and change-management obligations for AI and software medical devices are not fully aligned across jurisdictions. Companies cannot prepare submissions using only the documentation framework designed for traditional hardware devices.

Which Documents Should Be Prioritised

We recommend prioritising the following materials: software description; algorithm intended use; inputs and outputs; target population; training and validation data descriptions; performance validation reports; risk management; software lifecycle documentation; cybersecurity documentation; clinical evaluation documentation; labelling and instructions for use; version management records; and the post-market surveillance plan.

Where a product involves diagnosis, treatment recommendations, life support, automated decision-making or other high-risk scenarios, the depth of evidence and the clinical validation requirements should be assessed with additional caution.

Common Risks

Recurring issues include: an overly broad description of algorithm intended use; unclear boundaries between training data and validation data; absence of a control strategy for software version changes; insufficient cybersecurity documentation; clinical evidence that does not match the claims made; and inconsistent classification conclusions across jurisdictions.

AIMEILI View

This guidance has a direct impact on companies developing AI medical software: changing one sentence in the product definition can alter compliance costs by an order of magnitude.

Consider the difference. A product judged to be a medical device must go through the full sequence of qualification, classification, technical documentation and post-market surveillance. A product judged to be a non-device is subject only to ordinary rules on data, privacy and procurement. Class IIa and above additionally require Approved Body certification.

The first thing a company should do is break its product down to the functional level. Within the same application, a transcription module may not be a device, but as soon as 'inferring a diagnosis from the conversation' or 'automatically amending medical orders' is added, the boundary has been crossed.

The second task is to clean up promotional messaging. The guidance is clear that a disclaimer cannot offset medical claims. Website copy, sales presentations, demonstration videos and paid advertising must all be reviewed together. A single suggestion of diagnosis or treatment renders all preceding 'documentation only' statements ineffective.

The third task is to embed change assessment into procedures. Every time a product adds a function, changes model or expands its use scenario, device qualification must be re-assessed and the conclusion retained on file. The usual cost of not doing so is retrospective remediation plus market withdrawal.

The fourth point is not to overlook hallucination risk. The guidance treats large language model hallucinations as a risk to be managed in accordance with the intended purpose. Manufacturers should mitigate it at the design stage rather than adding disclaimers afterwards.

For teams that already hold certificates in China or the EU and are now targeting the UK market, there is an additional interface to note. Great Britain uses UKCA, while Northern Ireland continues to use CE marking. The software classification rules under the two frameworks are not identical, and registration dossiers and labelling cannot simply be carried across.

The applicable boundaries should be noted as well. These are UK rules covering Great Britain; they do not cover Northern Ireland, and they do not mean that Saudi Arabia, Brazil, Southeast Asia or other markets apply the same position. Companies should assess each target market individually rather than applying a single guidance document globally.

Our recommendation is a three-step approach. First, produce a product function list and mark each item as to whether it constitutes a medical purpose. Second, determine the registration pathway and evidence requirements for each on the basis of that conclusion. Third, embed change assessment into internal approval. Only after these three steps should multi-market expansion be considered, so that the sequence is not reversed.

One final point on timing. Software functions in this category iterate on a monthly cycle, and regulatory positions are also evolving. Defining the product and the evidence strategy once, clearly, is far less effort than re-aligning the interpretation every quarter. For teams that already have UK customers or channel partners, this point should be confirmed before contracts are signed. If the regulatory position is aligned in advance, subsequent development schedules and registration plans will not need to be rebuilt.

In one sentence: define the product first, then define the pathway — the order cannot be reversed.

It is also worth noting that the examples in the guidance state that a product which merely organises conversational content into structured data, or only suggests clinical codes based on terms explicitly appearing in the conversation, is likewise not a medical device. The decisive factor is always the intended purpose — not which model is used, and not which department it is deployed in.

FAQ

What is the most difficult aspect of international registration for AI medical devices?

The most difficult aspects are usually risk classification, algorithm evidence, clinical evaluation, the software lifecycle and post-market change management, rather than the completion of application forms.

Can AI medical devices be filed using ordinary software documentation?

Simply applying an ordinary software documentation framework is not advisable. The first step is to confirm whether the product qualifies as Software as a Medical Device (SaMD), whether it has AI-assisted decision-making attributes, and whether it affects diagnosis or treatment; the registration dossier should then be designed accordingly.

Editorial Review and Applicable Scope

Prepared by: AIMEILI Regulatory Editorial Team. Professional review: AIMEILI Medical Device International Registration Project Team. Source principle: priority is given to official regulatory agencies, international organisations, standards bodies and publicly available regulatory texts; industry media and project experience are used only as supporting references. Applicable scope: this article is intended for preliminary understanding, document preparation and project planning. It does not replace the formal requirements of the regulatory authority in the target country, testing conclusions or legal advice.

Related Reading

• EU MDCG 2026-5 clarifies UDI assignment responsibility: under a distributor's own brand, the UDI-DI must still be held under the manufacturer's name
• Three amendments to the UK Health Bill introduced in Parliament: powers reserved for a medical device licensing regime
• Australia proposes to publish medical device review information; consultation window closes on 2 October
• CMDE Notices: NMPA Party Leadership Group communicates and studies important instructions
• 31 August 2026: NMPA Center for Medical Device Evaluation opens public consultation on the Draft Technical Review Points for Clinical Trials of Implantable Brain-Computer Interface Systems (Electronic Device Cursor Interaction Control Function)
• 19 August 2026: FDA issues an early warning on issues with the NOxBOX nitric oxide delivery system

Need to Assess Your Registration Pathway?

Please provide the product name, intended purpose, target countries and available documentation. AIMEILI can assist in determining the registration pathway, identifying documentation gaps and assessing compliance risks. Contact AIMEILI to discuss your project.