Setting Up Prescription Uploads for Online Medicine Delivery — A Chemist's Guide

The single biggest friction in online medicine delivery is the prescription. Customers fumble to take a clear photo of a crumpled hospital slip, the pharmacist has to verify it without the doctor in the room, and the schedule flags need clearing before the runner can move. Most pharmacies handle this on WhatsApp — a workflow that breaks the moment volume crosses 20 orders a day. Here is what a clean prescription upload setup looks like, and the small decisions that decide whether 80% of prescriptions clear on first review or only 40%.

The customer-side flow

At checkout, the customer should encounter the prescription upload beforethey enter the address — not after they tap "Place Order". The earlier you ask, the less likely they are to abandon the order trying to find the prescription. Three accept modes work well:

• Photo from camera. The most common path. The UI should auto-crop and de-skew if possible; otherwise pharmacists are reading prescriptions sideways at 30° angles.
• PDF from gallery. Hospital-app exports (Apollo, Aster, KIMS) come as PDFs. Accept up to ~5 MB and render the first page server-side as a preview.
• Forward from WhatsApp. Less common, but a deep link that pre-fills the customer's order with an image they shared in WhatsApp earlier removes the "take another photo" step.

Hard-cap the file size at 8 MB. Reject obviously-tampered images (a server-side EXIF check that flags edited images can save the pharmacist a manual review). Don't accept screen recordings.

Image-quality rules — auto-reject the unreadable ones

Two rules at upload time will eliminate 60% of the bad prescriptions before a pharmacist ever sees them:

1. Resolution gate.Reject anything under 800 pixels on the long side. The customer gets a friendly re-upload prompt: "The image is too small for a pharmacist to read — please retake from closer."
2. Blur gate. A simple Laplacian-variance score on the server flags blurry images and bounces them back to the customer with the same prompt.

Don't reject for missing fields (doctor signature, date, clinic stamp). Customers don't control those — the pharmacist does the call on whether the prescription is adequate.

The pharmacist-review screen

Three actions, one screen:

• Approve. The dispensing pharmacist verifies patient, drug list, doctor name, validity. Tap Approve and the schedule flags clear automatically; the order moves to dispensing.
• Approve with adjustments.The customer ordered 30 tablets, the prescription says 20. Reduce the quantity, log the reason ("Prescription says 20, customer requested 30"), the system regenerates the price. The customer gets a one-tap confirmation: accept the adjustment or cancel. Both options take ~5 seconds.
• Reject.Picker drops a logged reason ("Prescription expired", "Drug not on prescription", "Image illegible", etc.). The customer sees a friendly rejection with the reason; the order is logged for the dispensing register.

The screen should also show the dispensing pharmacist's name + Pharmacy Council registration number so the audit trail is complete without a separate register lookup.

What to flag automatically

The system, not the pharmacist, should highlight:

• Schedule H/H1/X items in the cart. A coloured banner per line: green for OTC, amber for Schedule H, red for H1/X.
• Quantity > 30 days' supply. Most retail prescriptions are 7–30 days; a 90-day order should prompt confirmation that the prescription explicitly allows long-term dispensing.
• Customer-name mismatch.If the prescription patient name doesn't match the registered customer, prompt for confirmation ("ordering for a family member" is a common case but worth recording).
• Repeat orders within 7 days. Possible duplicate dispensing — flag for the pharmacist to confirm.

Handling repeat customers — the trust ladder

For chronic-illness customers (diabetes, hypertension, thyroid) who reorder the same prescription monthly, repeat prescription review is genuine friction. The compliant shortcut:

1. On the first dispensing, the pharmacist marks the prescription as repeat-eligible with an explicit validity (e.g. 6 months from issue date).
2. During that window, the customer reorders without uploading again. The console reuses the same prescription file and re-flags only if the cart changes.
3. When the validity expires, the system automatically asks for a fresh prescription on the next reorder.

This is fully compliant under the Drugs and Cosmetics Rules (which permit dispensing against a valid prescription, not re-uploading on every dispensing) and dramatically reduces repeat-order friction.

The reject conversation

Rejected prescriptions are where most pharmacies lose customers permanently. Two rules:

• Be specific about the reason."Image unreadable" is fine; "Doctor name not visible — please retake including the top of the prescription" is much better. The customer reuploads instead of giving up.
• Send the reject via WhatsApp + email + in-app. Customers don't check the app once they've closed it. WhatsApp has 95%+ open rates within 30 minutes.

Audit trail — what to retain

• The original prescription file, immutable, in cloud storage.
• The pharmacist who reviewed (ID + reg. number) and the timestamp.
• The action taken (approve / approve-with-adjustment / reject) and any free-form note.
• The cart at the time of approval, so a quantity adjustment is reconstructible.

Retention period: 2 years for Schedule H, 3 years for H1, 2 years for X (with the prescription scan attached).

Putting it together

A proper upload-and-review setup is the difference between running a regulated pharmacy delivery operation and running a WhatsApp group with extra steps. Get the upload-time gates right (resolution, blur, size), the review screen tight (three actions, ~5 second decisions), the schedule flags automatic, and the repeat-order ladder built in — and a pharmacist can clear 100+ orders a day without the audit trail ever falling apart. See the Deelo Shops pharmacy workflow →