Medication App Accepts a Cancelled Prescription
A hospital ward uses 32 Android tablets for medication administration. A nurse scans the patient's wristband, then the drug's barcode; the app checks the prescription and records the administration time. Tablets sync with the eMAR server over Wi-Fi. The hospital's survey shows 6 dead spots across the ward, and tablet batteries last about 7 hours under load against a 12-hour shift. Last Tuesday a nurse administered 5 mg of morphine to a patient whose prescription had been stopped two hours earlier. The investigation shows the tablet had been offline for 41 minutes and had queued the scan; on reconnection it uploaded the record but had not pulled the cancellation. The app showed a green tick at the moment of scanning. The hospital has 6 wards and wants the same system on all of them by March.
1. Separate the causes of the morphine incident into technical, procedural and interface factors, and identify which one you would fix first.
Read the worked answer
Technical: the sync was one-way and queued. The tablet pushed the record on reconnect but did not pull the cancellation, so it validated against a 41-minute-old cache. Worse, nothing on the server rejected the queued record on arrival; a correct design would have refused it because the prescription was no longer active. The sync model is a write-only queue, and that is the defect.
Procedural: there was no rule for offline working, and no way for the nurse to know that being offline mattered. With 6 dead spots and 7 hours of battery against a 12-hour shift, offline use is normal, not exceptional, so a procedure must exist.
Interface: a single green tick said success without saying 'as at 14:02' or 'offline, not verified'. The system communicated certainty it did not have, and the nurse had no reason to doubt it.
Fix first: server-side validation on sync, because it prevents the error independently of human behaviour. Then the interface, then the procedure, but all three are needed. A better banner does not stop a stale authorisation being accepted.
Also treat the battery as a contributing cause: a device that dies at hour 7 pushes staff onto shared tablets and paper notes, another route to the same error.
2. Design an offline and synchronisation policy for the app, distinguishing operations that may be queued from those that must be online.
Read the worked answer
Classify by risk, not convenience.
May be cached and read offline: patient identity (name, wristband number, ward, allergies) refreshed at shift start with a version stamp; drug reference data, which changes rarely; the list of due administrations, shown with an explicit last-updated time.
May be queued offline: recording that a dose was given, with device time and cached prescription version. This records an event that will happen anyway; blocking it only sends the record to paper.
Must be server-validated immediately: authorisation to administer, especially for high-risk or controlled drugs. If the server cannot confirm the prescription is active, the app must not show success; it blocks and requires a call or a connected device.
Sync rules:
- Pull before push on reconnect; the server is authoritative.
- Send the cached version with each queued record. If the prescription changed since, the server rejects it and raises a reconciliation task for the pharmacist; it never silently accepts.
- Show sync state permanently: last successful sync and number of queued records.
- Offline beyond a threshold (say 15 minutes) downgrades to read-only except recording, with every later action marked unverified.
Test by cutting Wi-Fi for 45 minutes during a simulated round and confirming a cancelled prescription is refused on reconnection.
3. The trust wants the same system on all 6 wards by March. What would you require before agreeing, and how would you evaluate the redesigned confirmation screen?
Read the worked answer
Before roll-out:
- The sync fix demonstrated, not described: a test where a prescription is cancelled while a device is offline and the device refuses the record on reconnect. One ward, one month, with the error log reviewed.
- Battery and connectivity solved per ward. Seven hours against a 12-hour shift with 6 dead spots needs a charging routine and either more access points or a rule that high-risk drugs require a connected device. Repeat the Wi-Fi survey per ward; a different layout has different dead spots.
- A fallback: the paper record must remain available and staff trained to use it, because the system has already failed once.
Evaluating the confirmation screen:
- Replace the single tick with explicit text: patient name and wristband number, drug, dose, route, time, and either 'verified as at HH:MM' or 'offline, not verified'.
- For high-risk drugs, require a second confirmation naming drug and dose.
- Measure rather than ask: simulated rounds with planted errors, counting wrong-patient and wrong-drug acceptance rate, time per round, and override rate. A screen that fires constantly and is always overridden is worse than none; if overrides are high, simplify.
- Compare against the paper baseline and retest after two weeks, once novelty has worn off.