A documentation-only AI scribe can fall outside medical-device regulation and still produce an error that matters to a patient. As at 10 October 2026, the relevant Great Britain distinction is the product's intended purpose and functions, not whether an inaccurate output could ever influence care. Regulatory classification and a service's practical safety assessment answer different questions.
What the July 2026 clarification actually changed
The MHRA announcement of 29 July 2026 explains the application of existing law; it did not enact a new exemption. Products intended solely for transcription, summarisation, letter drafting or clinician-reviewed coding suggestions are distinguished from functions supporting diagnosis, treatment or prevention, and automated actions such as orders placed without clinician review.
That statement should neither be broadened into "all scribes are unregulated" nor reversed into "anything affecting a record must be a medical device". The useful task is to identify what the particular software is intended to do. A clinical brand can contain several functions that require different consideration.
This article concerns the Great Britain clarification and NHS England deployment context, checked on 10 October 2026. It is an explanation for clinical teams, not a product-specific classification opinion. Uncertain classifications belong with appropriate regulatory advice and the relevant authorities.
How an administrative error can become clinically important
Consider a fictional consultation in which the patient says a previous investigation was discussed but never completed. A summary turns that into "previous investigation normal". The software has not openly proposed a diagnosis. Nevertheless, a later clinician could treat an unresolved question as settled.
The potential harm follows from the role of the record. It is not necessary for the scribe to announce a treatment decision itself. A missing qualifier, mistaken speaker or altered chronology can change the information on which a human bases a decision. This is a constructed failure mechanism, not evidence that a named product has made this error.
A different fictional example concerns appointment administration. A clinician agrees to discuss a result after checking additional information. The note instead says that the patient has already been informed. A subsequent staff member could reasonably misunderstand what remains outstanding. The safety question is therefore not only "did the system make a recommendation?" but "what will another person believe has happened?"
The GMC's record-keeping principles, in force in the version checked on 10 October 2026, apply to professional work regardless of the tool used to produce it. A polished note still needs to represent the actual encounter accurately.
Assess functions rather than assigning a verdict to a brand
A service can create a short function register before deployment. The following is a proposed structure, not a formal regulatory decision tree.
| Function | Information it transforms | Local question to test |
|---|---|---|
| Transcription | Speech into text | Are clinically important words, speakers and negatives preserved? |
| Summarisation | A conversation into a shorter account | Are uncertainty, chronology and unanswered questions retained? |
| Draft letter | Approved content into correspondence | Are recipient, purpose and action status correct? |
| Suggested code | Narrative into a proposed structured entry | Does a provisional idea remain provisional? |
| Recommendation or automated action | Clinical context into a proposed or executed next step | Has the expanded purpose received appropriate reassessment? |
A row should describe the live configuration rather than what a demonstration might eventually do. It should also identify who can enable the function. A feature that is technically available but disabled locally is different from one routinely used in patient care.
Local controls still need to work
As checked on 10 October 2026, NHS England's DCB0160 information standard concerns clinical-risk management across deployment, use, maintenance and decommissioning. The applicability assessment is distinct from simply asking whether a medical-device mark is present.
For the fictional investigation example, a meaningful control would make pending and completed actions distinguishable and test whether a reviewer catches the change. For a shared clinic workstation, it would include checking that the next patient's encounter cannot inherit the previous context. For a generated letter, it would include verifying the intended recipient and whether the document is still a draft.
These are not arguments for duplicating every manual step indefinitely. They are reasons to measure what a safe assisted workflow actually requires. A useful pilot can discover that some formats are easy to review while others create unnecessary ambiguity. The response might be a narrower template or a restricted use case, not abandonment of the whole product.
Review is a designed activity, not a disclaimer
The NHS England information-governance guidance for ambient scribes, checked on 10 October 2026, requires responsible-professional checking before outputs enter the care record. For a team implementing that expectation, "the clinician reviews it" should lead to further questions about time, context and authority.
Can the clinician inspect the information from which the statement was derived? Can they distinguish an unsupported addition from something the patient actually said? Does correction reach the final destination, or only the visible draft? What happens when review cannot be completed before the next encounter?
Those are workflow questions that a classification label cannot resolve. Equally, an absence of incidents during a small pilot does not establish that the controls are unnecessary. The pilot may not yet have encountered the conditions that challenge them.
What to do when the product starts doing more
Feature expansion deserves a repeat assessment of assumptions. A draft-only letter tool that acquires permission to send correspondence changes the point at which an error can reach someone outside the organisation. A code suggestion automatically promoted into a persistent problem list changes the consequence of an interpretation.
The NHS England AVT adoption resource, checked on 10 October 2026, links the July regulatory clarification with its deployment guidance. A practical local response is to require notification of consequential changes, identify who approves them and test an appropriate fallback before expanding permissions.
Staff should be able to describe the boundary in ordinary language: the software drafts this document; this professional checks it; this action cannot occur until the required approval. Where nobody can explain that sequence consistently, the deployment needs clarification even if its supplier documentation is extensive.
Keep clinical knowledge checking separate from deployment assurance
An AI-generated account can be faithful to a conversation whose clinical reasoning still needs review. Conversely, an evidence-based paragraph can misrepresent what happened in that consultation. These are separate checks.
For learning about the clinical question, iatroX's October 2026 product description positions Ask-iatroX as free, source-linked reference support. It does not establish what a patient said, approve an integration or decide a manufacturer's regulatory obligations. The same limitation applies to any general reference source used alongside a scribe.
The constructive position is neither "a non-device needs no safeguards" nor "regulation alone makes a tool safe". It is to match the assessment to the actual function, and then examine whether the local system preserves the information, professional judgement and corrective action on which care depends.
Frequently asked questions
Are documentation-only AI scribes medical devices in Great Britain?
The MHRA's 29 July 2026 clarification distinguishes solely documentary functions from medical-device functions under existing law. The exact intended purpose and configuration still matter.
Can a non-medical-device scribe still create a patient-safety problem?
Yes, an inaccurate account can affect subsequent decisions even without an explicit diagnostic recommendation. That possibility is a reason to assess deployment risks, not a substitute for a regulatory classification assessment.
Should a new feature trigger another assessment?
A feature that changes purpose, permissions, data flows or clinical consequences should prompt review of the relevant assumptions and controls. An earlier decision about drafting should not automatically authorise later execution.
Check the clinical evidence behind a question with Ask-iatroX →