Start with the prescription
Ask the demonstrator to create a prescription from an existing patient record. The pharmacist should be able to find the issued prescription without recreating the patient or copying its contents from another screen.
Check how the pharmacy identifies the patient, displays the prescription and separates work that is ready to supply from work already completed. Use a synthetic patient so the demonstration does not expose real information.
Test the stock behind the medicine
A medicine name is not a complete inventory record. The pharmacy needs to know which batches are available, their expiry dates and quantities, and where the stock came from.
Ask to receive a delivery, then supply part of it. Review the stock movement afterward. Check how your team handles a partial delivery, limited availability and the next replenishment request.
Follow the invoice
Configured medicine prices should flow into the billing workflow. The pharmacist still needs to confirm the actual supply and quantities. Tax treatment and invoice details should come from the organisation’s agreed configuration.
Make the demonstration continue to the invoice and payment record. Then check the financial report your team uses for reconciliation. Ask separately about online payment collection; recording a payment does not itself process a bank transaction.
Agree responsibility before rollout
Decide who can create prescriptions, who can dispense, who maintains prices and who receives stock. The software should support those responsibilities rather than giving every staff member the same workspace.
If vendors get access, inspect exactly which hospital relationship, requests and delivery information they can see. A vendor who serves multiple hospitals should not receive access to another hospital’s private workspace.
Use an ordinary difficult day
A useful demonstration includes more than a perfect full-stock sale. Try an incomplete delivery, a medicine that needs replenishment and a prescription supplied in part. Inspect the record left behind each action.
These practical examples reveal the quality of the connected workflow more clearly than a long feature list. They also help you define the training and acceptance checks for your own team.