Explore how PDS could provide the patient and pharmacy experience while PharmDel continues to own its delivery platform. Begin with the smallest agreed interface: access to the day’s optimised route.
Illustrative screens using fictional route and patient references. No API calls, real locations or live updates occur here.
“Grab the route” starts the discussion, but patient holds, shared journeys and delays require clear ownership and reconciliation.
| Interface proposal | Minimum useful information | Boundary to agree |
|---|---|---|
| Authorised route snapshot | Pharmacy/driver scope, route ID/version, stable stop/job references, sequence, approved navigation point, package count, relevant windows/policy flags. | Read-only starting scope. Confirm access, refresh, expiry, location necessity and permitted use. |
| Delivery events | Approved dispatch, status, delay and outcome events with time, source and stable references. | Patient notifications must be based on authorised data. An ETA is an estimate, not handover evidence. |
| Hold or combine request | Patient intent linked to their own prescription/parts. Pharmacy approval, request ID and expected route version. | Optional separate write/event channel. Reject stale/conflicting changes; return acknowledgement. A read export does not grant mutation access. |
| Reconciliation | Versioned refresh, applied/rejected result and unresolved changes visible to staff/driver. | Repeat requests must not duplicate actions. Avoid silent divergence between overlay and source round. |
| Handover evidence | Authorised outcome reference and suitable photo/evidence access if supported. | Agree evidence owner, storage, retention and viewer permissions; a photo alone cannot relax policy. |
The patient asks for one combined handover. The app records intent and acknowledges receipt, not approval.
Staff check urgency, policy and part readiness. Other household members’ deliveries remain separate.
Through an agreed change mechanism, check the current version, acknowledge the decision and refresh the round.
Review when safely stopped. Preserve custody/return tracking for the loaded part; update affected ETAs.
Read-only scoped route, reminders and notes. PharmDel remains the driver’s delivery platform. Minimal interface requirement first.
Launch patient-response or assistance views from an existing driver flow if the platform supports and approves it. Identity boundaries need explicit agreement.
Restricted driver login, checklist and live replies. Requires enough agreed route/status interoperability to avoid duplicated operational authority.
Let patients request repeats, understand split supply, prepare for arrival and view verified history. Voice/status reading is a future accessibility goal alongside touch and text.
Collection can use an authorised reference or QR/NFC and nominated-carer checks, with a staff-assisted fallback. The focus remains reliable customer delivery and collection.
Round locations, references and notes can identify people. A live pilot needs agreed roles, access scopes, retention and data-sharing arrangements. Avoid broad clinical access merely for navigation.
Distinguish measured, calculated, estimated and demo metrics. No savings or break-even claim is presented as proven.
Propose nopCommerce multi-store for pharmacy shops, with pharmacy-specific loyalty rules. Prepaid delivery credit would be a separate ledger from shop reward points.
Use a confirmed payment result, show the balance and issue a receipt. Define refunds and insufficient-credit handling.
Identify the authorised delivery transaction and confirm the agreed amount. Repeated scans/taps return the same result without another deduction.
Agree whether and how charge/receipt status is exchanged. A route interface does not imply payment capabilities; drivers do not invent charges or waivers.
What interfaces exist, which option fits PharmDel, and what would a bounded fictional proof need to show?
Agree route access, identity, events, change ownership and evidence. Ask the team about realistic availability and effort.
Specify one route snapshot and one hold/reconciliation scenario, with failures and stale versions. Demonstrate against a stub first.
Agree participants, safety/data arrangements, baseline measures and support. Proceed only after evidence and partner approval.
Tell us which boundary, interface or driver experience would be practical.
A previously reported driver workflow for PharmDel discussion. Confirm the current app version and exact steps with the driver before turning it into a requirement.
For some house-name destinations, Google Maps finds an unrelated place. After grouping prescriptions to the same address, the driver reports that Apple Maps is no longer offered. The workaround is to cancel grouping, open an order, choose Apple Maps manually, locate the address and group the items again to complete the handover.
Could a grouped stop retain the chosen map provider, address context and delivery state? Check whether the issue is navigation data, a platform option or the grouped-stop workflow. Preserve each recipient’s packages and handover policy independently.
Useful evidence: app version, fictional reproduction steps, screenshots without patient information, frequency and effect on the round.