← The Health AI Brief
Loading summary
Transcript1 lines
- [00:01]
A
So let's say that you want to use an AI scribe for your health service. Is it a medical device? It's long been slightly ambiguous. Clinicians use these tools in various ways. Knowing when exactly an AI scribe is a medical device and when it's not is important. Well, in the uk, the MHRA has just offered some very helpful clarity. They've provided specific examples of when something is a device and when it's not. It's incredibly helpful for developers, users and procurers. So listen on if you want to be fully clued up. So let's first consider the administrative side. The pathway is simple. If the software strictly stays within documentation supports, it's not classed as a medical device. The MHRA outlines several clear cut functions that fall into this safe zone. Consider literal transcription. The system records the clinical encounter word for word. It acts as a passive digital mirror, so there's no regulatory hurdles existing. Next, if it then summarises that transcript, the software drafts a clinical summary to be copied into the electronic healthcare record. Importantly, this requires clinician review and editing. It's a draft, not the final decision, and therefore not a medical device in the MHRA's definition. Then we look at formatting and data structuring. The tool places information from the transcript into standard formats, like a clinic letter. Note, it checks for missing data. It doesn't make clinical recommendations, it's just clean bookkeeping. But what about if the AI scribe then suggests some clinical coding? So suggesting snomed or billing codes is a common functionality. If the tool matches those codes to words explicitly spoken during a visit, then it's not considered a medical device because it doesn't infer or deduce. It simply maps explicit references of a term. Finally, drafting letters generating a draft referral letter based on the exact spoken conversation is permitted. The clinician still needs to review and edit the document. It's a workflow accelerator rather than acting autonomously. So that covers the functionality, which the MHRA deems doesn't constitute a medical device. But what tasks do make a medical device? So insight generation is a key trigger. If the software proposes potential diagnoses, then it's a medical device. If it suggests treatment plans or follow up tests not explicitly discussed within a consultation, then it crosses the line. The tool is now actively guiding clinical care. Autonomous actions also trigger regulation, so saving transcripts directly to an electronic healthcare record without prior human review is a clinical action. Sending referrals automatically is another. The safety net has been removed until it becomes a medical device. Marketing claims are also deemed to be Very important. So two suppliers might sell identical software. One markets it as an administrative time saver. The other claims that it guides diagnosis or improves clinical outcomes. The second product is a medical device. The physical code might be identical, but the legal reality is completely different. Also, disclaimers aren't enough. Placing a tiny warning saying not for diagnostic use doesn't bypass the law. The actual features and interface dictate the classification. But it's important to note that generative AI is highly plastic. It changes constantly. A clinic might buy a simple administrative scribe today. It's unregulated and cheap at this early stage. But then the vendor might push an over the air update and the tool suddenly starts suggesting treatment advice, which would transfer its classification into being a medical device. The system's overnight transformed into an unregulated medical device. This creates important compliance gaps. It requires an immediate new regulatory assessment. If this were to occur, although developers are likely to be wise to this and not push these sorts of updates without very clear notification, digital leads need to monitor these updates closely. But then there's the issue of liability. This is a point that many organisations may miss. If a tool is not a medical device and it's purely felt to be administrative software, then the MHRA doesn't regulate it. This sounds convenient, but it also means that the safety responsibility sits entirely with those deploying the tools. The NHS trusts, the GP practice. The individual clinician holds all the legal liability if things go wrong, and things can definitely still go wrong. Large language models are very prone to confabulation or confidently filling the gaps. They might invent a normal heart rate. That was never mentioned. This is why human in the loop is mandatory. Clinicians will need to actively review and edit every draft, anything that's inaccurate that's entered into a patient's records, even if it might be harmless in the immediate future. Down the line, other people might base decisions upon that inaccurate information. And so the clinician who entered that information into the electronic healthcare records is themselves responsible and liable. It's important also to note that medical device status is only one hurdle. You still must clear the demanding pathway of local information governance. It's a separate legal layer. Think of a secure physical drain pipe. While the MHRA checks if the pipe itself is safe, your local trust or practice needs to negotiate who controls the valves and where the patient data actually flows. That means signing formal data processing agreements with the data controller. You also need to complete a robust data protection impact assessment to map how voice recordings are stored. This is deemed personally identifiable information, so really careful safeguards need to be in place. Where are the voice recordings stored, how long for, how are they processed and when are they ultimately deleted? Without these contracts, even a compliance administrative tool remains completely unusable in a clinical environment. So don't skip that step. Just because something is or isn't a medical device isn't the only factor to consider. So this MHRA guidance is a very helpful step forward. It removes some of the fog of ambiguity surrounding ambient voice technologies. It's clear that administrative factors in scribing is not deemed to constitute a medical device, but it also draws a clear red line around clinical decision support and autonomous actions, keeping patient safety at the centre. This clarity helps developers build with confidence and allows healthcare managers to deploy safely. It's a pragmatic and balanced framework. It's not completely without risk though, and so the things that we've discussed should also be very front of mind when considering these things.