What to Build for UK Pharmacies and Medicine Delivery

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: Owner or COO of an independent UK pharmacy group or medicine delivery business with 3–20 branches, losing margin to dispensing errors, manual EPS token reconciliation, and a delivery operation still run on WhatsApp and spreadsheets

If you run a 3–20 branch UK pharmacy group, the highest-ROI software to commission first is not a patient app. It is an internal reconciliation layer that matches your NHSBSA payment schedule against your dispensed item records and flags Drug Tariff underclaims. Build that, then a delivery tracking and proof-of-delivery system, then a repeat prescription engine. In that order. Everything else — loyalty, consultations booking, a branded patient portal — can wait or be bought off the shelf.

The reason to be this specific: every pharmacy software vendor in the UK pitches a full platform, and most owners end up paying for modules that solve the wrong problem. The money is leaking from three places you already know about but have not quantified. Let us quantify them.

Where the margin actually goes

Three operational problems account for most of the preventable losses in an independent UK pharmacy group. None of them are glamorous.

1. EPS reconciliation done in a spreadsheet

In 2024/25, 1.13 billion prescription items were dispensed via the Electronic Prescription Service — 97% of all items dispensed in England, according to NHSBSA data reported by The Pharmaceutical Journal. With community pharmacy numbers down to 11,098 — the lowest since 2015/16 — the average surviving pharmacy now dispenses around 104,000 items a year, per The Pharmacist. A 10-branch group is handling over a million items annually.

Every one of those items generates a line in the NHSBSA payment schedule. Every schedule needs to be matched back against what your PMR (Patient Medication Record) system says you dispensed, and the difference reconciled against the Drug Tariff — the monthly document that sets reimbursement rates, including Category M prices, broken bulk, and out-of-pocket expenses. In most independent groups this is done monthly by one person in a spreadsheet. They catch the obvious discrepancies. They miss the long tail: items reimbursed below tariff, missed broken bulk claims, uncollected fees for appliances and specials, endorsements that were stripped on submission.

From working with pharmacy operators, the pattern we see is that spreadsheet-based reconciliation typically recovers 60–80% of what a systematic line-level match would recover. The gap — often 3–7% of monthly NHS revenue — is pure margin, because the dispensing cost is already sunk.

2. Delivery run on WhatsApp

Medicine delivery has become a core service for most groups, not a side offering. The UK e-pharmacy market was valued at USD 3.08 billion in 2024 and is forecast to reach USD 4.06 billion by 2030, per TechSci Research. But at the independent group level, most delivery operations run on a WhatsApp group, a printed manifest, and a driver's memory. There is no live tracking, no digital proof of delivery, no exception workflow when a patient is not home, no audit trail when a controlled drug delivery is disputed.

The costs are hidden but real: returned items that get redispensed, CD compliance risk, patient complaints that escalate because you cannot prove what happened, driver time wasted on failed drops, and the labour cost of a dispenser phoning round to find out where a bag went.

3. No repeat prescription engine

Repeat prescriptions account for roughly 77% of all NHS prescription items, per a BMC Family Practice study, and two-thirds of England's prescription volume is estimated to be repeats for long-term conditions. Digital repeat requests via the NHS App rose more than 45% between 2023 and 2024, reaching 3.1 million requests per month, per the Royal College of Pharmacy.

If a patient on a 28-day repeat lapses by a week, you have lost that dispensing fee and — if they switch nominated pharmacy — the lifetime value of that patient. Most independent groups have no system that tells them which patients are due, which are overdue, and which have silently moved to a distance-selling pharmacy.

Underneath all three sits a dispensing safety problem that the digitisation effort should help with, not make worse. Avoidable medication errors cost the NHS £98.5 million annually and contribute to 1,708 deaths in England each year, per a BMJ Quality & Safety study, with dispensing errors making up 36.7% of primary care errors per the University of York rapid evidence synthesis. Any system you build has to reduce cognitive load for your dispensers, not add to it.

What to build, in order

Build 1: EPS reconciliation and Drug Tariff audit layer

What it is: An internal tool that ingests three data sources — your NHSBSA monthly payment schedule (FP34C), your PMR system's dispensed items export, and the current Drug Tariff — and matches them line by line. It flags every item where reimbursement is below expected tariff, every missing endorsement, every broken bulk opportunity missed, every appliance fee not claimed.

Why first: It pays for itself inside the first reconciliation cycle. The ROI is measurable in pounds recovered, not in soft metrics like "patient satisfaction". You can run it alongside your existing process without disrupting operations.

What changes when it exists: Your monthly reconciliation shifts from "check a sample" to "review the exceptions queue". The person doing it goes from a week of spreadsheet work to a day of judgment calls. You start submitting cleaner claims because the tool shows you which endorsements your team is forgetting.

What it does not do: It will not fix problems upstream in your PMR. If your dispensers are not endorsing correctly at the point of dispense, the tool tells you after the fact, not before. You still need the PMR workflow to be right.

What shapes the build: The complexity is mostly in the data ingestion and the Drug Tariff logic, not the UI. Key decisions: which PMR system(s) you use (Pharmacy Manager, ProScript Connect, Titan, RxWeb all export differently), how many branches share one NHSBSA account vs separate accounts, whether you want branch-level drill-down or group-level summary, and whether you want the tool to auto-generate correction submissions or just flag them for a human.

Build 2: Delivery operations — dispatch, tracking, proof of delivery

What it is: A driver app plus a dispatcher console. Driver app: today's manifest, route in order, barcode scan to confirm each bag loaded, patient signature or photo proof of delivery, CD-specific workflow (ID check, signature, witness field). Dispatcher console: live map, exception queue, SMS to patients with ETA windows, reassignment when a driver is delayed.

Why second: It removes a compliance risk you currently carry informally, it cuts failed-delivery labour, and it gives you the audit trail you need when a patient or an inspector asks what happened to a specific item.

What changes: Driver productivity goes up because the route is sequenced. Failed deliveries drop because patients get an ETA SMS. CD disputes become resolvable in 30 seconds instead of 30 minutes. The person who used to field "where is my bag" calls spends that time on clinical services.

What it does not do: It does not turn you into a same-day delivery operation competing with Pharmacy2U. If that is your ambition, this is the foundation, not the finished product. It also will not fix a route that is badly designed — you need enough delivery density per postcode for route optimisation to matter.

What shapes the build: Volume per branch, whether drivers are employed or subcontracted, whether you deliver CDs, whether you need temperature-controlled logging for fridge lines, how you want to handle payment on delivery, and whether you want patients to self-schedule via an SMS link or you push ETAs only.

Build 3: Repeat prescription engine

What it is: A patient-facing request channel (SMS, web, or lightweight app — not necessarily a full branded app) plus an internal engine that tracks expected reorder dates, flags overdue patients, auto-generates reorder requests to GP surgeries where the patient has consented, and manages the nomination capture conversation.

Why third: Repeats are 77% of volume. Losing a repeat patient to a distance-selling competitor is losing an annuity, not a transaction. Pharmacy2U's own reporting notes that 17% of patients experienced health problems because medication was not ready — that is both a patient safety issue and a churn risk for the pharmacy that caused it.

What changes: You see who is due before they lapse. You can proactively contact patients whose GP has not yet issued the next script. You stop losing repeats to competitors who are simply more organised about reminders.

What it does not do: It cannot force a GP surgery to turn around a repeat request faster. The bottleneck is often at the surgery, not at you. The tool should make that visible so you can have the conversation with the PCN.

What shapes the build: Whether you integrate directly with GP systems (EMIS, SystmOne) via approved APIs or stay at the patient-facing layer, how you handle nominated vs non-nominated patients, whether you want to offer MDS (monitored dosage system) scheduling, and whether consent capture is built into the flow.

What is not worth building yet

A few things we would push back on if you asked us to build them first:

• A full branded patient app. Most independents do not have the install base to justify it. A mobile web portal with SMS triggers covers 90% of the use cases at a fraction of the maintenance burden.
• AI symptom checkers or triage. Regulatory overhead is significant and the MHRA scrutiny on anything that looks like SaMD (Software as a Medical Device) is not trivial. Build the operational layer first.
• Loyalty points. NHS dispensing is not a loyalty-driven purchase. Spend the effort on being reliably in stock and delivering on time.
• A replacement PMR. Do not try to displace Pharmacy Manager or ProScript. Build around them.

Sequencing and what drives the budget

The order matters because Build 1 produces cash that funds Builds 2 and 3. If the reconciliation tool recovers even the low end of what a systematic process typically finds, a mid-sized group has a self-funding digitisation programme within one or two quarters.

On what a build like this takes: we will not quote a number, because the shape of the work depends on specifics we would need to scope. The variables that move the number most are:

• How many PMR systems your group uses, and whether they expose a clean export or need scraping
• Whether your NHSBSA submissions are consolidated or per-branch
• For delivery: number of branches, drivers, daily drops, and whether CDs are in scope
• For repeats: whether you want GP-system integration or stay patient-facing
• Hosting and data residency — UK-only hosting is non-negotiable for NHS data and that constrains some choices
• Whether you need IG Toolkit / DSPT alignment baked into the build from day one (you do, if you touch patient-identifiable data)

A one-branch pilot of the reconciliation tool, with a single PMR and no GP integration, is a very different piece of work from a 15-branch rollout with three PMRs and full delivery and repeats modules. To turn the range into a real number, the conversation needs to cover PMR mix, branch count, delivery volume, and whether you want to own the IP outright or operate on a shared model. That is the scoping conversation, not a blog post.

One note on compliance: anything touching patient data needs DSPT (Data Security and Protection Toolkit) alignment, and controlled drug workflows have their own legal requirements under the Misuse of Drugs Regulations. A pharmacy lawyer and your Information Governance lead should sign off the data flows before build starts. We can design to the standard; we are not a substitute for legal review.

How CodeNicely can help

We built HealthPotli, an e-pharmacy platform with AI drug interaction checking, which gave us direct experience with the data model problems specific to pharmacy: SKU-level dispensing records, interaction logic that has to be defensible, and the operational reality of a delivery fleet. The reconciliation and repeat-prescription work for a UK group is a different regulatory environment but the same underlying problem shape — reconciling what was dispensed against what should have been reimbursed, and keeping patients on their therapy without manual chasing.

If you want to see how we approach embedding this kind of operational layer into an existing business without ripping out the PMR you already run on, that is the conversation to have. We work with full IP transfer and no vendor lock-in, which matters when the system you commission is going to handle NHS payment data.

The short version

Build the EPS reconciliation layer first. It is unglamorous, it is internal-facing, and it recovers money your current process is missing. Use that recovered margin to fund the delivery operations build, which de-risks your CD compliance and cuts failed drops. Then build the repeat prescription engine to stop losing long-term patients to distance sellers. Do not start with a branded app, do not try to replace your PMR, and do not build anything AI-flavoured until the operational layer is solid.

Frequently Asked Questions

How long does a pharmacy EPS reconciliation tool take to build and start recovering money?

The timeline depends mostly on how clean your PMR data export is and how many branches share one NHSBSA account. A single-PMR pilot for one branch is a much shorter piece of work than a multi-PMR rollout across a group. What turns the range into a real timeline is: which PMR(s) you run, how your NHSBSA submissions are structured, and whether you want the first version to just flag discrepancies or also auto-generate corrections.

Do I need to replace my PMR system (Pharmacy Manager, ProScript, Titan, RxWeb) to digitise?

No, and we would actively advise against it as a first move. The PMRs are good at what they do and switching them is operationally painful. The high-ROI work is building a reconciliation, delivery, and repeat-management layer around your existing PMR, using its exports as input.

Is a patient-facing medicine delivery app worth building for an independent group?

Usually not as the first build. A mobile web portal plus SMS covers most of what patients need (request a repeat, book a delivery slot, get an ETA) without the install-base problem a native app creates. If you do go native later, the data model from your delivery and repeats systems becomes the backbone — which is why those are built first.

What are the compliance requirements for pharmacy software in the UK?

At minimum: DSPT alignment for anything handling patient-identifiable data, GPhC standards for anything used in the dispensing workflow, Misuse of Drugs Regulations for CD workflows, and MHRA scrutiny if any component meets the Software as a Medical Device threshold. Your IG lead and a pharmacy lawyer should review the specific data flows — a blog post is not a substitute for that review.

Can one tool handle both NHS and private prescription reconciliation?Yes, and it should. Private scripts have their own margin structure and are often reconciled even less rigorously than NHS claims. Building the engine to handle both from the start is a small marginal effort and closes a leakage source most groups have never measured.