What AI actually does well in a pharmacy right now
Five applications are mature enough to deploy, and every one of them is administrative rather than clinical.
Drafting communications. Patient emails, service descriptions, letters and responses, produced quickly and checked by a person. The output is a first draft rather than a send, which is the correct relationship.
Summarising and extracting from documents. Pulling the relevant lines from a long letter, a supplier document or a guideline. Useful precisely because the human still reads the source when it matters.
Transcription and note structuring. Turning a spoken consultation into structured text for a clinician to review and correct, which is addressed in its own section below because it carries conditions.
First-pass sorting. Routing correspondence, categorising enquiries, flagging what looks urgent for a person to confirm.
Forecasting and analysis. Stock movement, demand patterns, identifying which lines behave unusually.
What those share is that a human sees the output before it does anything, the failure mode is inconvenience rather than harm, and the benefit is measurable in hours. That combination is why they are the sensible place to start and why almost nobody markets them, since they are considerably less exciting than the alternative.
The line between admin AI and clinical AI
Buyers evaluate AI on capability, and capability is not what determines the regulatory position or the risk. A tool which drafts a patient email and a tool which suggests whether a patient is suitable for treatment may use identical technology, and they sit on opposite sides of a line that matters enormously. The distinguishing factor is intended purpose, meaning what the manufacturer states the software is for. Software intended for a medical purpose, including informing or supporting a clinical decision, can fall within the medical devices regime as Software as a Medical Device, and AI within that scope is regulated as AI as a Medical Device according to its intended use and risk class. Administrative software generally sits outside. The consequence for a pharmacy buyer is direct and easy to act on. Before evaluating whether a tool is any good, ask what its stated intended purpose is and whether it is registered as a medical device, because a vendor describing clinical benefits whilst claiming their product is not a medical device is describing either a carefully bounded product or a regulatory problem, and you need to know which.
When does AI software become a medical device?
The determination turns on intended purpose and the risk that follows from it, rather than on the technology used. Three practical readings help.
Marketing can create the intended purpose. A product positioned as helping identify suitable patients has been given a medical purpose by its own description, whatever its documentation says, and vendors are not always careful about the distinction between what their software does and what their website implies.
Supporting a decision counts. Software does not need to make a decision to fall within scope. Informing or supporting one can be sufficient, which catches a great deal of what is sold as decision support.
Whether the clinician can see the basis matters. Regulators internationally have focused on whether a healthcare professional can understand the basis of a recommendation well enough to exercise independent judgement on it. A tool which shows its working sits differently from one which produces a conclusion from an opaque process, and that distinction is worth raising with any vendor.
None of this is a reason to avoid clinical AI. It is a reason to establish the position in writing before deployment rather than after, and to expect a serious vendor to have the answer ready.
What the MHRA is doing in 2026
The framework is moving, and a pharmacy buying now is buying into a position which will change.
The MHRA has run its Software and AI as a Medical Device Change Programme since 2023, and the government's Life Sciences Sector Plan indicated a new regulatory framework for AI in medical devices during 2026. New post-market surveillance regulations came into force in June 2025, imposing stricter obligations on manufacturers including surveillance plans and, for some risk classes, periodic safety reports. A pre-market statutory instrument covering conformity assessment, classification and international reliance routes has been expected to come into force during 2026, with predetermined change control plans among the mechanisms addressed, which matters for AI because it concerns how a model may be updated after approval without fresh assessment.
Alongside the regulations, the MHRA has operated the AI Airlock, a regulatory sandbox whose second phase ran into 2026 and which is intended to produce guidance from real cases rather than in the abstract. A National Commission into the Regulation of AI in Healthcare has separately sought evidence, including on ambient voice technologies used to summarise consultations.
Two practical conclusions follow for a buyer. Treat any vendor's regulatory statement as current rather than permanent, and ask what happens to their position when the framework changes. And treat this section as dated, because it will be, which is a reason to check the MHRA's own pages rather than rely on an article.
How to check a vendor's claims yourself
This is the misconception the whole verification exercise turns on, and vendors trade on it. The MHRA states the position on its own database in terms which leave no room, namely that registration of medical devices with the MHRA does not represent any form of accreditation, certification, approval or endorsement, and that it is not permitted to make any claim to that effect or to use MHRA logos in marketing, on packaging or in documentation. Registration means the manufacturer has taken legal responsibility for the device and told the regulator it exists. It does not mean the MHRA has assessed the software, tested it, or expressed any view about whether it works. A vendor describing their product as MHRA approved, MHRA accredited or MHRA endorsed is making a claim they are expressly not permitted to make, and that is a more useful signal about the company than anything on their capability slide. What a serious vendor will say instead is that their product is a UKCA or CE marked medical device of a stated class, registered with the MHRA, with a named conformity assessment route, and they will hand you the certificate.
Two public sources let a pharmacy check most claims in under fifteen minutes.
The Public Access Registration Database at pard.mhra.gov.uk, which lists registered manufacturers and registered device types. Its limitations matter as much as its contents. It is searchable by manufacturer name and by device type nomenclature rather than by product name, and full device details and model numbers are not included, so it confirms that a manufacturer has registered devices of a given type rather than that the specific product in front of you is that device. Use it to establish that the company exists in the register and that the device type matches what is being sold, then ask the vendor to close the gap with their certificate.
The Ambient Voice Technology self-certified supplier registry, published by NHS England, for anyone being sold an AI scribe. The important word is self-certified, meaning suppliers attest to meeting NHS England's expectations rather than being assessed against them, and a listing therefore indicates that a supplier has made a set of statements rather than that anyone has verified them. It remains worth checking, because a supplier absent from it when the tool is squarely within scope is worth asking about.
Three documents to request directly, since neither register substitutes for them. The statement of intended purpose, which is the document that determines the regulatory position and which every device manufacturer holds. The UKCA or CE certificate with the class and the notified or approved body named, noting that CE marking continues to be accepted on the Great Britain market during the transition to UKCA. And the clinical safety documentation under DCB0129, which the manufacturer produces and which forms an input to your own assessment as the DCB0160 article explains.
A vendor who provides all three without hesitation has been through this before. One who offers a case study instead has answered a different question.
AI consultation recording and note-taking
Ambient tools which record a consultation and produce a structured note are among the more mature applications and the ones a pharmacy is most likely to be offered. They also raise three questions which are not about the technology.
Has the patient been told and agreed? Recording a consultation is processing special category data, and it needs a lawful basis and a genuine choice rather than a notice on a wall. A patient who declines should still get the consultation.
Does the clinician review and correct before it enters the record? An unreviewed summary is the software's account of the consultation rather than the clinician's, and it will be read years later as though the clinician wrote it. The review step is what makes it a clinical note, per the standard set out in the patient notes guide.
Where does the audio go, and for how long? Whether it leaves your systems, whether it leaves the UK, how long it is retained, and whether the recording or only the transcript is kept. Each is a processing question requiring a written arrangement.
Handled properly these tools genuinely help, since the alternative is a clinician typing during a consultation instead of listening. Handled carelessly they produce a record nobody wrote and a recording nobody can account for.
Is your patient data being used to train the model?
This is the question most worth asking and the one least often asked, and it should be answered in writing before any trial, not after.
Four parts to it. Is our data used to train or improve models, and does that include what staff type in as well as what they upload? Can it be excluded contractually, and is that the default or an option? Where does processing happen, including any subprocessors and any transfer outside the UK? And what is retained, for how long, and can it be deleted on request?
The reason this matters more in pharmacy than in most sectors is that the data in question is health data about identifiable people, which requires a proper processing arrangement and sits under the same obligations examined in the security baseline. A vendor who answers these readily has thought about their obligations. One who answers vaguely, or who points to a general privacy policy, has answered a different question.
Who is responsible when the AI is wrong
The pharmacist or prescriber, in every case that matters, and no product changes that.
What changes is the shape of the risk. Two failure modes are specific to this technology and worth designing against. Automation bias, being the tendency to accept a plausible suggestion because it is confident and fast, which is the same mechanism as alert fatigue running in the opposite direction. And plausible error, since these systems fail by producing something that reads correctly rather than something obviously wrong, which defeats the visual check that catches most other software errors.
Three arrangements address it. Keep AI output visibly marked as AI output until a human has accepted it, so nobody mistakes a draft for a record. Ensure the person reviewing has the source available rather than only the summary, because a review against a summary confirms the summary. And treat deployment as a change requiring the clinical risk assessment described in the DCB0160 article, since introducing a tool into a clinical workflow is precisely what that standard exists for.
What is being oversold
Four claims worth pressing.
Autonomous clinical triage. Anything positioned as deciding who is suitable is describing a medical purpose, and should come with a regulatory position rather than a case study.
Interaction and safety checking as an AI feature. Established clinical decision support relies on maintained, referenced datasets. A generative system producing similar-looking output is not the same thing, and the difference only becomes apparent on the case where it matters.
Fully automated patient communication. Sending unreviewed generated text to patients about their treatment removes the check at the point where it protects most.
Accuracy figures without context. A percentage means nothing without knowing the task, the dataset, who evaluated it and what the failures were. Ask what the errors looked like rather than how many there were.
Where to start if you want to try something
With something administrative, bounded and measurable, for four reasons which apply regardless of how the technology develops.
Pick a task where a human already checks the output, so the safety net exists before the tool arrives. Choose one you can measure, in hours or in turnaround, so the trial produces an answer rather than an impression. Run it for a defined period with a defined decision point. And settle the data question first, because it is much harder to unpick after a trial than before one.
Drafting patient communications and summarising incoming documents both fit that description well. Clinical suitability does not, and a pharmacy whose first AI deployment is clinical has chosen the hardest possible starting point.
Eight questions to ask any AI vendor
What is the stated intended purpose of this software, and is it registered as a medical device? If not, what specifically keeps it outside that scope? What happens when it is wrong, and what does a wrong output look like? How does a user see the basis of a suggestion rather than only the suggestion? What data leaves our systems, where does it go, and is any of it used for training? What clinical safety documentation exists, and will you share it? What does this not do well, in your own words? And what is your position if the regulatory framework changes during our contract?
The seventh question remains the most informative in any technology purchase, and it is the one this publisher would expect to be asked in turn.
Key takeaways
- The mature applications in UK pharmacy are administrative rather than clinical, comprising drafting, summarising, transcription, sorting and forecasting, where a human sees the output first and the failure mode is inconvenience.
- Intended purpose rather than capability determines the regulatory position, and software intended to inform or support a clinical decision can fall within the medical devices regime as AI as a Medical Device.
- Ask for the stated intended purpose and medical device status before evaluating whether a tool is any good, since a vendor claiming clinical benefit and no device status needs to explain which it is.
- There is no MHRA accreditation or approval of software, since registration is a legal declaration by the manufacturer rather than an assessment, and any vendor claiming otherwise is making a claim they are not permitted to make.
- Check the Public Access Registration Database and, for scribes, the NHS England self-certified AVT registry, then ask directly for the intended purpose statement, the UKCA or CE certificate and the DCB0129 documentation.
- The MHRA framework is actively changing through 2026, so treat any vendor's regulatory statement as current rather than permanent and check the regulator's own pages.
- Ambient consultation recording needs patient agreement, clinician review before the summary enters the record, and a clear answer on where the audio goes and for how long.
- Settle the training data question in writing before any trial, covering whether your data trains models, whether it can be excluded, where processing happens and what is retained.
- Accountability stays with the pharmacist, and the specific risks are automation bias and plausible error, so mark AI output until accepted, review against the source, and treat deployment as a clinical risk assessment.
FAQs
Useful first, clever second.
We will tell you plainly which parts of Dataforge PMR use AI, what they are for, and where a human still decides. If a vendor cannot draw that line for you, including this one, that is the answer to the question you were asking.
See Dataforge PMR