Pharmacy management
Dispensing, stock and the counter as one system — batches and expiry tracked properly, the clinical record kept separately from the sale, and the day reconciling at close without anyone hunting for the difference.
Talk about scopeThree systems wearing one interface
A pharmacy counter is simultaneously a clinical record, a stock ledger and a till, and each of the three has different rules about what may be changed afterwards. A sale can be refunded and a stock count corrected, but a dispensing record is appended to rather than edited, because it is evidence of what a named person was given. Most pharmacy software is uncomfortable precisely where those three meet — and that seam, rather than the feature list, is what decides whether the system holds up in an audit or during a recall.
Expires 03/27 · received 28 Jul
Expires 09/27 · received 06 Aug
What makes this hard to build
A dispense is not a sale.
The same event is simultaneously a stock movement, a clinical record and a financial transaction, and the three have different rules about being amended. A sale can be refunded; a dispensing record cannot be quietly reversed. Deciding early that the clinical record is append-only, and that the till operates against it rather than the other way round, is the decision the rest of the system hangs off.
Stock is batches, not quantities.
Two boxes of the same medicine are not interchangeable — they have different batch numbers and different expiry dates, and only one of them is the one that was handed to a named person last Tuesday. A model that stores a single number per product cannot answer a recall, and no amount of reporting added later will recover the link that was never stored.
The counter cannot wait for the system.
Someone is standing there, often unwell, frequently with a queue behind them. Every check the software performs has to happen inside the time it takes to reach for the shelf, which rules out designs that call out to something slow at exactly the wrong moment.
Inventory that has to be right, not approximately right
Pharmacy stock differs from retail stock in ways that change the data model rather than the screens. Items expire, and the expiry belongs to the batch rather than the product. Some items are controlled and every movement of them has to be accounted for individually. Unclaimed prescriptions return to stock but not to the same state they left it in. A general inventory system handles none of this without being bent, and the bending is where the errors live.
What the counter has to handle
- part payments and mixed tenders — a single dispense may be split across cash, card and an account, and the split has to survive a refund of only part of it.
- proof of handover — who collected it, when, and on whose behalf, captured at the counter rather than reconstructed from a delivery note afterwards.
- live stock at the point of dispensing — the shelf and the screen have to agree during the transaction, not after an overnight job has run.
- returns to stock — an uncollected item goes back, but only into the states it is still valid for; some of it cannot go back at all.
- day-end reconciliation — takings, dispensed value and stock movement agreeing, with every discrepancy attributable to a recorded event and a name.
- pricing that differs by who is paying — retail, account and subsidised prices for the same item, resolved as a rule and stored with the transaction so an old receipt still explains itself.
What it has to talk to
A pharmacy system is rarely the only system in the building, and the integrations are where the schedule usually goes. These are the ones worth scoping before the estimate rather than after.
- Prescribers.Wherever prescriptions arrive electronically, that interface is the one with the least tolerance for ambiguity — a mis-parsed dose is not a data quality issue. It deserves its own validation and its own rejection path rather than being treated as an import.
- Suppliers and wholesalers.Ordering, confirmations and price files, each in whatever format the supplier already uses and will not be changing for us. This is unglamorous integration work and it is consistently the part that is under-estimated.
- Accounting.Daily takings and stock valuation have to reach the books without anyone retyping them, and in a form the accountant can reconcile against the system that produced it.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.
More platforms
Other sectors we can build for.