Ask early
“Your prescription is being prepared. Part 1 of 2 is available. Receive available items now, or wait for one delivery?” Show an agreed response cutoff.
Patient app is the destinationAccessible website access alongside an optional app.
Accountable pharmacy decisionsSupply, release, policy and clinical review remain authorised work.
Professional screen mockupsFictional screens for review; no live accounts or patient records.
Make the proposal tangible
See how the screens could work.
Select a perspective, then explore individual concepts. These are discussion mockups, not connected apps.
For patients and carers
Review repeat requests, history, arrival updates and collection. Tell us where a phone, paper or staff-assisted option is needed.
Illustrative product screen
Names, references, counts, charges and times are fictional examples. A perspective changes the presentation, not access permissions.
9:41PDS · Concept
Get the timing right
One prescription. Sometimes two parts.
Explain split supply early enough for a useful patient reply—without turning a preference into an automatic pharmacy or route decision.
Confirm the plan
Apply a valid standing preference and agreed default. No response is not automatically consent to hold or deliver. Check supply, urgency and delivery policy.
Track each part
Identify physical packages as part 1 of 2 or part 2 of 2, linked to the prescription. Check loaded packages against the authorised round.
Coordinate a change
If already loaded, staff review a hold request. Acknowledge it, update through an agreed interface and confirm with the driver before treating the stop as removed.
Partners and shared addresses
Offer one journey for consenting household members where practical. Group travel while keeping separate identities, permissions, package counts, policies and outcomes. One response cannot silently alter another person’s prescription.
Unexpected delays and route changes
Show revised ETA, current route version and acknowledgement state. Pharmacy-approved changes reconcile with the route system; a patient reply never silently erases a stop.
Use “Your prescription is being prepared” in patient messages. Use “package” when the physical bag or split handover needs to be distinguished.
The whole pharmacy experience
Useful at the counter and at home.
Request and track
Request receipt, pharmacy acknowledgement and progress. Prescribing and dispensing depend on approved processes and available interfaces.
Know what was handed over
Verified app records of prescriptions, parts, dates and times, with controlled access to suitable handover evidence. Imported history depends on authorised sources.
Arrive ready
Ready-to-collect message, reference or supported QR/NFC tap, and nominated-carer workflow. A staff-assisted alternative remains.
Prepare for the door
On My Way, estimated arrival, known charges and permitted responses. The recorded handover, not a notification, determines completion.
A familiar front door
Services, bookings, approved advice, patient account and help in one browser experience, reflecting the same authorised app information.
Useful extras, clear prices
Suitable pharmacy products and co-delivery. Assess stock, picking, payments, returns and margin before claiming purchases fund the round.
What to build, and when
From review to a working pilot.
Suggested priorities for discussion. This presentation does not declare software implemented or change the approved application architecture.
| Destination | Proposed scope | Evidence to progress |
|---|---|---|
| Core patient experience | Pharmacy identity; secure patient/carer access; repeat acknowledgement; preparation/status; prescription and handover history; collection; help and suggestion box; accessible layouts. | Patient and staff review; agreed identity/release rules and data sources. |
| Bounded delivery pilot | Driver role; before-round checklist; parts and household grouping; early wait/deliver choice; ETA/replies; authorised photos; delays and route reconciliation. | Confirmed route interfaces, versioned changes, permissions and fictional scenario tests. |
| Optional income features | Shop, suitable co-delivery, transparent charges and accounting. | Net contribution after operating costs and staff workload. |
| Voice accessibility | Read status aloud, spoken choices and repeat assistance, confirmation before important actions, text/touch fallback. | Willing-user testing, privacy in shared spaces and misunderstood-speech handling. |
| Multi-pharmacy rollout | Shared core with branch-specific identity, services and policy. Server-enforced separation of patient records and staff/driver permissions. | Successful pilot and repeatable onboarding/support. |
Voice control is a future accessibility goal. Large controls, plain language and assistive-technology support belong in the core design.
Patients, carers, drivers and pharmacy
Share an idea.
What would make this useful to you? A patients’ suggestion box is part of the proposed app; this page prepares an email draft.
How an idea becomes work
Listen → review → decide → test.
Record role, screen, benefit and importance. Jon reviews product needs; the pharmacist reviews clinical/release implications; the architect reviews system changes when required.
Accepted ideas become traceable requirements and tasks. Return the decision, test result and resolution to contributors. Feedback does not automatically alter approved architecture.
- What would reduce uncertainty?
- Which step should be simpler?
- What do you need without a smartphone?
- Would spoken choices or status reading help?
Pharmacy commerce · proposed next stage
A pharmacy shop, loyalty and delivery credit.
Propose nopCommerce as the commerce foundation, with a store for each pharmacy, shared product capabilities and pharmacy-specific branding and rules. Patient clinical records remain in their authorised system.
Top up once. See every agreed charge.
A patient could add prepaid delivery credit through an approved payment provider. A supported QR scan or NFC tap could identify the authorised transaction and confirm the pharmacy’s agreed delivery amount.
- Show amount, current balance and a clear receipt.
- Record one deduction per authorised delivery; repeated taps must not charge twice.
- Define top-up, refund and insufficient-credit handling before the pilot.
- Keep shop loyalty rewards and delivery credit balances distinct.
- Explain any conversion between rewards and credit explicitly; no automatic clinical or delivery entitlement.
This is a proposed account and ledger flow, not a live payment facility. A QR code or NFC token alone does not authorise an arbitrary fee.
9:41Credit · Concept
Mossley PharmacyFictional wallet
Delivery credit
Balance before delivery: £5.00Top-up receipt DEMO-T01 · Confirmed example
Agreed delivery charge: £1.00Delivery DEMO-D04
QR/NFC confirmation reference DEMO-C04
QR/NFC confirmation reference DEMO-C04
Balance after one deduction: £4.00Receipt DEMO-R04
A repeated tap returns the same receipt.
A repeated tap returns the same receipt.
Shop rewards: 120 demo pointsSeparate from credit. Redemption rules to be agreed.
Illustrative calculation only. No payment or deduction occurs here.
Automatic delivery-credit deduction: Where the patient has agreed and pharmacy policy permits, the authorised delivery-confirmed event can deduct the agreed amount automatically and issue a receipt. QR/NFC may support identification or confirmation; it must not trigger an additional deduction for the same delivery. Holds, failed attempts, waivers and split supplies follow explicit charging rules. Show insufficient-credit handling before activation; no balance or charge is processed by this mockup.
Longer-term delivery economics
An electric-vehicle partnership to assess.
Explore an eco partnership supplying vehicles and a small team taking carefully chosen marketplace or evening takeaway deliveries. Pharmacy service remains the priority. Extra income is a hypothesis, not a break-even promise.
- Model finance/lease, insurance, charging, depreciation and maintenance.
- Include paid time, dead mileage, platform fees, storage and segregation.
- Test demand, hours and operational fit; measure net contribution and pharmacy reliability.
This weekend’s review
Choose the first useful journey.
Review the screens, choose the core app and identify one bounded pilot. Discuss route access and the patient app with the appropriate stakeholders.
PharmDel collaboration proposal