E-prescription software development: printouts pharmacists can verify by QR scan

Why e-prescription software development starts at the pharmacy counter

Picture a pharmacy counter at 9:40 p.m. A man hands over a printed prescription. The duration reads 5 days, but the 5 is darker than the other digits, and the clinic closed at eight. Good e-prescription software development starts at that counter.

The pharmacist has two bad options: turn away a patient who may be genuine, or dispense on trust.

In England, almost every prescription travels over a national network, so the pharmacist checks the system, not the paper. In markets without one, such as Pakistan, the paper is the system.

Our engineers built e-prescription software for clinics in Pakistan as a custom software project, part of our healthcare product work. The goal: a legible, formula-accurate prescription a pharmacist can verify, with no new hardware. Here is how.

Why PDFs, phone calls and “verified” badges fall short

Teams usually reach for one of four shortcuts. Each one fixes a problem and creates another.

Prescription verification by QR code with minimal patient data

A bearer token works like a cloakroom ticket: whoever holds it can collect the coat. So it must be impossible to guess, and the coat behind it should be small.

Each prescription gets a token made of two random UUIDs joined together, roughly 244 bits of randomness. The server rejects tokens under 24 characters and any duplicate.

The part to get right is the projection: the short, fixed list of fields the public page may return. The public query copies only that list and never follows links to records holding phone numbers or national ID numbers.

A QR is only as trustworthy as the address it opens. A forger can print a code that points at a lookalike site, so the pharmacist must check the domain. A pharmacy-side scanner app or a signed payload closes that gap.

Share the link, not the patient

Our first share flow sent patient text with the link. Some apps merge them into one message, which can break the link and leak patient details into a chat. Now only the link and a generic title go out.

Three ways to make a QR verifiable

• Opaque token, server lookup (what we built): choose it when pharmacies are online. Small QR, private and revocable record.
• Signed payload in the QR: choose it when checks must work offline. The code is dense, and anyone can read it.
• Token plus shared dispensing record: choose it when double filling is the main risk. Every pharmacy must join one system.

Freeze each prescription at issue, then print it in English or Urdu

A snapshot is a photocopy taken at the moment of issue. If a doctor later edits their profile, last month’s prescriptions still show what the pharmacist saw.

At issue time we copy the doctor’s name and registration number, and the patient’s name and age, into the prescription row. The insert and its audit event share one database transaction, so a prescription never exists without its audit entry.

Store meaning, render language

We never store the sentence “1 tablet, morning and night, 5 days, after food”. We store its parts: quantity, form, times of day, duration, route, food instruction and an as-needed flag.

One function turns those parts into English or right-to-left Urdu. It exists because of a bug: an early print view forced Urdu while the screen and verify page showed English. Now the language is chosen once, stored on the prescription, and every surface calls that function.

Store what the doctor meant, and render it for whoever is reading.

• A4: about 190mm of content width. Print uses a letterhead layout that leaves room for the doctor’s own stationery.
• 80mm thermal: receipt-printer width, so a clinic can use hardware it may already own.
• 58mm thermal: the narrow roll, where the QR shrinks but never disappears.

Our rule: if something does not fit, fix the layout rather than drop the doctor’s identity, dosage, signature area or QR. Our thermal prints do not fully meet it yet (see below).

Drug name search and drug database integration without an API

Verification only matters if doctors use the app, and doctors give up on search that cannot find what they typed. A clinical informatics paper cites an estimate that nearly 20% of initial order searches do not end in the intended order.

Finding a medicine from a mid-word fragment

Doctors type whatever fragment they remember, so “zith” has to find azithromycin. Our search engine only matches the start of a word. So we also store each brand, generic and alias word with its first letters peeled off, one at a time, down to three letters.

Azithromycin is also stored as zithromycin, ithromycin and so on. Now “zith” matches the start of a stored word, for a few hundred bytes per medicine.

A weekly sync from a registry with no API

The national drug registry is a search website, with no API and no download. The regulator calls it an “expanded provisional list”, warns of possible “errors or omissions”, and says it “cannot be used as a reference for any purpose”. So we import new rows as inactive.

A high-water mark is a bookmark: everything numbered above it is new. Domestic, export (“-Ex”) and dotted numbers form overlapping series, so each series keeps its own bookmark.

Junk rows were the subtle trap. In the registry snapshot we harvested, real registration numbers ran to about 136,700 across 132,293 products. But 28 rows sat above 200,000: data-entry errors, some 12 or 13 digits long. One could push the bookmark past every real registration, silencing the sync forever without an error.

So any number above 1,000,000 counts as junk, and a dotted number such as 118815.00000.0000 is read only to the first dot. The bookmark advances only over records actually imported.

It is still a heuristic. A junk number under a million would still move the bookmark, and an out-of-order or re-registered number below it is missed. A periodic full harvest is the backstop.

What held up, and what we would harden next

The app is an MVP built for a pilot, so we will not quote adoption numbers. Here is what held up.

• The inactive-by-default gate worked, almost too well. Our first catalog import (10,186 rows) landed inactive, so search returned nothing until an operator chose to activate it in bulk. That was an operator decision, not a clinical review. Plan review and activation as a release step, so pressure cannot bypass the gate.
• A definition of done for medical changes. Stored data, ownership, audit, print and safety wording must agree before release, much like our UAT release evidence.

And here is what is thin.

• The verify page does not show credential status. A pharmacist sees the registration number as entered at provisioning, not as checked. We would label it “not yet verified” there too.
• Thermal prints rely on the QR for the doctor’s identity. Letterhead print omits the doctor header, fine on stationery but not on a receipt roll. We would print name and registration number on 80mm and 58mm.
• A backfill touches issued records. We wrote a repair that strips “not specified” placeholder strengths from issued prescriptions. It is cosmetic but writes no audit event, and every repair to an issued record should.
• Tokens are generated in the browser. The server checks length and uniqueness, but we would generate them server-side so no buggy client can mint a weak one.
• There is no dispensed status or revoke button yet. A scan proves a prescription is genuine, not unused, and revocation exists only in the data model.

An e-prescription software checklist you can use tomorrow

Run your design against this list before the first pilot doctor signs in.

If you are planning e-prescribing for clinics or pharmacies without a national network, book a free 30-minute discovery call. We will help you pick a verification model, find a source for your drug catalog and decide what stays out of the pilot.