Nguyen Manh Thang
Chief Executive Officer, AgileTech Vietnam
- Published
- Read time
- 15 min
In short
Pharmacy software is a regulated workflow engine built around a single event, the dispense, which ties together a prescription, a licensed pharmacist, a specific batch of stock with an expiry date, a patient record and a payment. Four requirements follow that ordinary retail software does not have: inventory that is batch-aware because recalls execute by batch, records that are append-only because an auditor must see what was believed at the time, a dispensing path measured in seconds because it runs hundreds of times a day, and operation that survives losing the internet because a pharmacy that cannot dispense is an emergency. Get those four right and the screens are straightforward. Get any of them wrong and no amount of interface polish rescues the product.
A pharmacy looks like a shop, so pharmacy software gets specified like shop software. That is the mistake the whole category is built on. What actually happens at the counter is a regulated clinical transaction: a prescription is validated against a patient, a licensed professional takes responsibility for it, a specific batch of a specific product leaves a specific shelf, and a record is created that somebody may need to reconstruct in detail several years from now.
Every unusual requirement in this article follows from that one sentence. Batch-level inventory exists because recalls are issued by batch. Append-only records exist because auditors ask what you believed at the time, not what you believe now. The obsession with seconds exists because the dispense happens hundreds of times a day and every second is multiplied by that. Offline operation exists because the alternative is a queue of patients who cannot get medicine.
This guide covers what a complete system contains, why compliance shapes the data model rather than the feature list, the integrations that decide whether pharmacists adopt it, and the buy-versus-build question honestly. It draws on our healthcare software work, where these systems sit alongside clinical platforms.
Key takeaways
- Pharmacy stock is not fungible. The same product exists as many batches with different expiry dates, and dispensing, recalls and write-offs all operate on batches rather than products.
- Dispensing and stock records are append-only. A correction is a new compensating entry, never an edit, because the auditor needs to see what was believed at the time.
- The dispensing path is the product. It runs hundreds of times per day, so seconds and keystrokes on that one path matter more than every other screen combined.
- Design for connectivity loss from the start. A local-first architecture with sync is the safe default, because a pharmacy that cannot dispense during an outage is a regulatory and commercial emergency.
- Integration certification calendars, not your sprint plan, usually set the go-live date. Start that paperwork in week one.
- Scanning at goods receipt and again at dispense is the cheapest safety feature available. Design every stock-touching screen around the scanner rather than retrofitting it.
- Measure success in seconds per dispense, expiry write-offs and reconciliation time. Those are the numbers the owner already tracks, and moving them is what the software is for.
Why a point of sale with a medicines catalog does not work
It is worth being precise about the difference, because the assumption that pharmacy is a retail vertical is what produces unusable systems. A retail point of sale models a product, a price, a quantity on hand, and a transaction. Every one of those four models is insufficient here.
A product is insufficient because the dispensable unit is a batch. Two boxes of the same medicine with different expiry dates are different things operationally: one is dispensed first, one may be subject to a recall the other is not, and one becomes a write-off next month. A quantity on hand is insufficient for the same reason, since the meaningful question is not how many you have but how many you have that are usable and for how long.
A transaction is insufficient because the record has to carry clinical and regulatory context: which prescription authorized this, which licensed professional verified it, which patient received it, and what was known about their other medications at that moment. And a price is insufficient because the same item may be paid for by cash, by insurance, by a subsidy scheme, or by a combination, each with different rules and different reporting.
None of this means retail concepts are absent. A pharmacy does sell shampoo, and that part genuinely is retail. The failure mode is treating the regulated half as a configuration of the retail half instead of the reverse.
The same concept, modeled for retail and modeled for a pharmacy
| Concept | In retail software | In pharmacy software |
|---|---|---|
| Stock unit | A product with a quantity | A batch with a quantity, an expiry date and a supplier lot reference |
| Picking rule | Any unit will do | Ordinarily first to expire, first out, with the selection recorded |
| Correction | Edit or void the transaction | A new compensating entry; the original record is never altered |
| Who served the customer | Useful for commission | A licensed identity that is part of the legal record of the dispense |
| Product recall | Rare, handled manually | A routine operation executed by batch across dispensed and held stock |
| Customer | Optional loyalty record | A patient record with allergies and current medications, carrying health data obligations |
| Payment | Cash or card | Cash, card, insurance claim or subsidy scheme, often split across one basket |
Each row is a place where a general retail system requires either a workaround or a customization deep enough that it becomes a different product. The cumulative effect is why pharmacy software is its own category.
What a complete system contains
Whether the target is a single dispensary, a retail chain or a hospital pharmacy, the same core modules appear. What changes is the center of gravity. A chain lives in inventory and replenishment, because the operational problem is distributing stock across branches. A hospital pharmacy lives in prescriptions and ward supply, because the operational problem is getting the right medicine to the right bed. A single independent lives in the dispensing path itself.
- Prescription processing. Capture from paper, an electronic network or a portal; validation against the patient record; verification by a licensed pharmacist; and dispensing with explicit batch selection. This is the safety-critical path and deserves more design attention than everything else combined.
- Inventory with batch and expiry control. Receipt against supplier lots, batch-aware stock levels, expiry visibility well before the date, and the ability to quarantine or recall by batch across both held and dispensed stock.
- Point of sale and claims. Cash, card, insurance and subsidy handling in one basket, with prescription items and ordinary retail items following their different tax and reporting rules.
- Patient records and medication history. Allergies, current medications and the interaction-checking hooks that turn a stock database into a clinical safety tool.
- Procurement and supplier management. Purchase orders, goods receipt captured against batches at the point of scanning, and reorder logic driven by measured consumption rather than by a static minimum.
- Reporting and the audit trail. Controlled substance registers, dispensing logs, complete stock movement history and the regulatory returns your market requires, all reconstructable for a single event years later.
Where the design effort actually goes
An illustrative allocation from our own engagements rather than an industry figure. The point of the shape is that the module with the fewest screens absorbs the most design attention, because it is the one that runs hundreds of times a day.
Batch and expiry control is the requirement that reshapes everything
If there is one requirement to get right before any other, it is this one, because it is the hardest to add later. Batch awareness is not a field on a product record. It changes what the stock table is: the unit of inventory becomes a batch, with its own quantity, expiry date, supplier lot reference and status, and the product becomes a grouping above it.
That change propagates outwards further than teams expect. Receiving stock means recording batches, which means the goods-in screen has to be built around a scanner. Dispensing means selecting a batch, ordinarily the earliest to expire, and recording which one was selected. Stock valuation has to account for batches approaching expiry differently from batches with two years left. Replenishment has to know that a hundred units expiring in three weeks are not really a hundred units.
And recalls, which are routine rather than exceptional, execute by batch in both directions. Held stock in the affected batch must be quarantined immediately. Dispensed stock from that batch must be identifiable so that patients can be contacted. A system that cannot answer "who received anything from lot X" is not merely inconvenient during a recall, it leaves the pharmacy unable to meet an obligation under time pressure.
The commercial argument is easier than the safety one and lands better with owners. Expiry write-offs are money that was purchased and then thrown away, and they are almost entirely preventable with visibility far enough in advance to move or return stock. Most pharmacies know their write-off figure and dislike it, which makes it the single most persuasive number available when justifying a system.
Batch and expiry acceptance criteria
- Receipt captures the batchGoods-in records the supplier lot reference and expiry date per batch, entered by scanning rather than typing, because typed dates are wrong often enough to matter.
- Dispensing selects a batchThe dispense record names the specific batch supplied, defaulting to the earliest expiry, with an override that requires a reason.
- Expiry is visible in advanceA working view of stock approaching expiry with enough lead time to return or transfer it, rather than a report that confirms the loss afterwards.
- Quarantine is a real stateA batch can be blocked from dispensing immediately, in one action, without deleting it or adjusting quantities to hide it.
- Recall works forwardsGiven a lot reference, the system lists every remaining unit in stock across all locations and blocks it.
- Recall works backwardsGiven a lot reference, the system lists every dispense made from it, with enough detail to contact the patients involved.
- Write-offs are recorded, not adjusted awayExpired stock leaves inventory through an explicit write-off with a reason and a value, so the monthly figure is measurable and improvable.
Use this as the acceptance test for the inventory module, whether you are building or evaluating. Items five and six are the ones commercial products most often fail, and they are the ones a recall depends on.
Compliance shapes the data model, not the feature list
Pharmacy is among the most regulated retail environments anywhere, and the specifics vary by market: controlled substance registers, pharmacist licensing verification, prescription retention periods, and in many markets serialization or track-and-trace obligations for medicines. The important structural point is that these cannot be added as features on top of a working system, because they constrain the schema.
Three consequences follow directly. The first is immutability. Dispensing and stock movement records are append-only, and a correction is a new compensating entry rather than an edit, because an auditor is asking what was believed at the time and an edited record cannot answer that. The second is identity. Every clinically significant action records which licensed individual performed it, which means real authentication and genuine role separation between pharmacist, technician and cashier rather than a shared login and a dropdown.
The third is retention, and it is the one that catches teams out. Prescription and medical records carry mandated retention periods that override an ordinary deletion request, so your privacy workflow and your regulatory workflow have to be designed together rather than sequentially. A system whose erasure path deletes a dispensing record has created a compliance failure while satisfying a privacy request, and discovering that conflict during a real request is a bad way to learn it.
Patient medication data is health data, with everything that implies for encryption at rest and in transit, access logging, and breach notification obligations. If the system serves markets under regimes of that kind, those requirements belong in the architecture review at the start, not in a legal review at the end. This is standard practice in our hospital platform work and applies identically to a dispensary.
Audit trail design that survives an inspection
Do this
- Append-only movement ledgerEvery stock and dispensing change is a new immutable row. Current state is derived from the ledger, so the ledger cannot disagree with reality.
- Compensating correctionsA mistake creates a reversal entry plus a corrected entry, both timestamped and attributed, so the sequence of belief is visible.
- Licensed identity per actionThe individual professional is recorded, not the terminal or the shift, which is what makes accountability meaningful.
- Reconstructable single eventsGiven one dispense, the system reproduces the prescription, the verifier, the batch, the patient context and the payment as they stood at that moment.
Not this
- A mutable state table plus a log fileCurrent state is edited in place and a log records that something changed. The log cannot reproduce the prior state, so it proves almost nothing.
- Editable transactions with a history tabThe record shows what it says now and a list of edits. Under questioning, nobody can state what the pharmacist actually saw at the time.
- Shared terminal accountsA counter login used by several people. The trail identifies a computer, and every regulated action becomes unattributable.
- Deletion satisfying a privacy requestAn erasure path that removes a dispensing record trades a privacy obligation for a regulatory breach, usually without anyone noticing until an inspection.
Everything in the right column produces a system that appears to have an audit trail and cannot reconstruct a specific event under questioning, which is the only test that matters.
The integrations decide adoption, and their calendars decide your date
A pharmacy sits inside an ecosystem of prescribers, insurers, suppliers and national health infrastructure. Software that makes a pharmacist retype what another system already knows will be resented into disuse regardless of how well it is built, because the counter is busy and every retyped field is a queue getting longer. The integration list is therefore a first-class requirements exercise rather than a later phase.
The usual set is predictable: electronic prescription networks or hospital clinical system interfaces, insurance and subsidy claim submission, supplier ordering through electronic data interchange or a portal, a national drug database for product and interaction data, and an accounting export. Each of these has its own onboarding or certification process, and each of those processes has a calendar that belongs to somebody else.
This is the scheduling fact that surprises first-time buyers. The certification calendar, not the engineering estimate, commonly sets the go-live date. A build that is technically finished in month four and waits until month seven for a claims integration approval has not been delivered late by the development team, but it has been delivered late. The mitigation is unglamorous: start the paperwork in week one, before anyone has written code, and treat each approval as a tracked dependency with an owner.
Barcode workflow deserves separate mention because it is the highest-value safety feature per unit of effort in the entire system. Scanning at goods receipt captures batches accurately. Scanning at dispense catches wrong-product and wrong-batch errors at the counter, before they reach a patient. Both require the screens to be designed around a scanner from the beginning, since retrofitting scanning into an interface designed for clicking never produces the same flow.
The integration surface, and who controls the timeline
| Integration | What it removes | Who controls the timeline |
|---|---|---|
| Electronic prescriptions | Manual capture, transcription errors, and the queue that comes with both | The network operator, through a certification process |
| Insurance and subsidy claims | Separate claim entry, and the reconciliation work that follows it | The insurer or scheme, often with scheduled onboarding windows |
| Supplier ordering | Rekeying orders and mismatches between what was ordered and received | The supplier, usually the most flexible party on this list |
| National drug database | Maintaining product and interaction data by hand, which decays immediately | The data provider, typically a license rather than a certification |
| Accounting export | Month-end double entry and the reconciliation gap it produces | Us, in most cases |
| Label and scanner hardware | Handwritten labels and typed batch references | Us, though procurement lead times are real |
The third column is the one to read carefully during planning. Every row where the answer is not "us" is a dependency that can move your launch date, and they are frequently sequential rather than parallel.
The pharmacy cannot stop because the internet did
This requirement separates pharmacy software from most business applications, and it is regularly missed during specification because it is invisible when everything works. A pharmacy that cannot dispense is not inconvenienced, it is in an emergency: there are patients in front of the counter who need medicine, some of them urgently, and there is no acceptable version of asking them to come back tomorrow.
The design consequence is that the dispensing path must function without connectivity. In practice that means a local-first architecture: the dispensing application holds the data it needs to operate, writes locally and durably, and synchronizes when a connection is available. This is meaningfully harder than a conventional client that talks to a server, because it introduces reconciliation, conflict handling and a versioning story for reference data such as the drug catalog.
The scope of offline operation should be decided explicitly rather than emerging. Dispensing an existing prescription against local stock can work offline. Submitting an insurance claim cannot, and needs to queue with a clear indication to the user that it is pending. Retrieving a new electronic prescription that has never reached the device cannot work either. Writing that table down during design, and showing the state honestly in the interface, is the difference between degraded operation that staff trust and a system whose behavior during an outage is a mystery.
One further detail matters for a chain. When several branches operate offline and reconcile later, stock movements can conflict, and the conflict resolution rules have to be defined by the business rather than by whichever write arrives last. That is a policy question disguised as a technical one, and it belongs in the requirements.
What works offline, and what has to queue
| Works offline | Queues for later | Blocked until online | |
|---|---|---|---|
| Dispense against local stockthe critical path | Yes | No | No |
| Cash and card paymentcard depends on the terminal | Partial | No | No |
| Insurance claim submission | No | Yes | No |
| Retrieve a new electronic prescription | No | No | Yes |
| Goods receipt and batch capture | Yes | Yes | No |
| Interaction check against local datacatalog version matters | Partial | No | No |
| Inter-branch stock transfer | No | Yes | No |
| Regulatory reporting | No | Yes | No |
Decide this table during design and show it honestly in the interface. Staff tolerate a clearly labeled pending state; what they cannot work with is an action that appears to have succeeded and silently did not.
When to buy, when to build, and how to phase it either way
Commercial pharmacy systems exist and they serve standard single-store retail well. Recommending a build in that situation would be dishonest: the requirements are largely settled, the shelf products encode years of regulatory detail per market, and rebuilding that from scratch buys very little. The honest cases for a custom build are narrower and identifiable.
They are, broadly, four. A chain whose replenishment or pricing logic is genuinely distinctive and is a competitive advantage rather than an accident. A hospital pharmacy with ward supply workflows that retail products do not model at all. A market whose regulatory specifics the available products handle poorly, which happens more often than vendors admit. And a situation where the available products are aging desktop suites and the modernization gap itself is the business case, which is the most common of the four in practice.
If a build is justified, phasing is what de-risks it, and the order is consistent. Inventory and point of sale first, because they can go live independently and immediately produce value. The prescription workflow second, once the stock model it depends on is proven in real use. Integrations third, with their paperwork started in week one regardless. And a parallel-running pilot in one location before any wider rollout, because running the old and new systems side by side for a few weeks is the only honest acceptance test that exists for this category.
Whichever route you take, insist on an exit. Your dispensing history, stock ledger and patient records should be exportable in a documented format on demand. Pharmacies outlive software by decades, and a data hostage situation in a regulated industry is expensive in a way that is difficult to explain to anyone who has not been in one. That judgement call is a conversation about your specific market, and it is one our custom software team has regularly.
Should you buy a system or build one?
What is genuinely unusual about your operation?
-
Nothing, it is a standard retail dispensary
Buy, and spend the budget on training and process
The requirements are settled and the available products encode years of market-specific regulatory detail. A custom build would spend a large sum reproducing that, and the operational gain would be close to zero.
-
The available products in our market are aging and poorly supported
Consider a build, with the modernization as the case
This is the most common genuine reason. Where the shelf options are desktop-era suites with no realistic path to modern workflows, the gap itself justifies the investment, and the requirements are well understood enough to scope confidently.
-
We are a chain with distinctive replenishment or pricing logic
Build the distinctive part, buy or integrate the rest
The advantage lives in a specific subsystem, so build that and connect it to proven components elsewhere. Rebuilding dispensing to obtain custom replenishment is paying for the wrong thing.
-
We are a hospital pharmacy with ward supply workflows
Build, or extend a clinical platform
Retail products do not model ward supply, unit dose distribution or the relationship with prescribing on a ward. This is a genuinely different workflow and the retail category does not contain it.
Work through these in order and stop at the first that matches your situation. Most single independent pharmacies stop at the first branch, and that is the correct answer rather than a disappointing one.
A phasing that de-risks go-live
-
ObservationWeeks 1 to 2
A week behind the counter watching real dispensing, timing the current path, and cataloguing every workaround staff have invented. Integration paperwork started in parallel.
Done when A measured baseline for seconds per dispense and reconciliation time, plus every certification application submitted.
-
Inventory and point of saleWeeks 3 to 10
Batch-aware stock, scanner-first goods receipt, expiry visibility, retail and prescription payment handling, the append-only movement ledger.
Done when Live in one pharmacy for ordinary retail and stock control, with the recall queries answerable on real data.
-
Dispensing workflowWeeks 9 to 15
Prescription capture, validation, pharmacist verification, batch selection, the offline path, and relentless iteration on the number of keystrokes.
Done when The dispensing path is faster than the baseline measured in week one, verified by timing rather than by opinion.
-
IntegrationsWeeks 12 to 20
Electronic prescriptions, claims, supplier ordering and the drug database, each behind whatever approval its owner requires.
Done when Each integration passing its own certification, with the queueing behavior tested by disconnecting the network deliberately.
-
Parallel pilotWeeks 19 to 23
One location running old and new together, with reconciliation between them every day and a written list of every divergence found.
Done when A clean reconciliation over consecutive weeks, and the pharmacist asking to stop using the old system.
Indicative spans for a single-pharmacy build with a small team, not a quotation. The exit criteria are the load-bearing part: a phase that ends without meeting its criterion has moved risk forward rather than retiring it.
Frequently asked questions
Can we use a general retail point of sale for a pharmacy?
For the retail half of the shop, yes. For dispensing, generally no, and the reason is the inventory model rather than the feature list. Retail systems treat stock as a product with a quantity, while a pharmacy needs a batch with an expiry date and a supplier lot reference, because that is the unit that recalls, write-offs and picking rules operate on. Adding a batch field to a transaction is not the same as being batch-aware, and the difference becomes visible the first time somebody asks who received stock from a recalled lot.
How long does a pharmacy system take to build?
A single-pharmacy system covering batch-aware inventory, point of sale and a solid dispensing workflow is a few months of focused work for a small team, and the phasing matters more than the total. What extends the calendar is rarely the code: integration certification processes belong to other organizations and run on their schedules, so a build that is technically complete can still wait weeks for a claims approval. Chain features and institutional integrations each add phases of comparable size to the original build.
What does "append-only" mean in practice for staff?
It means a mistake is corrected rather than erased. Instead of editing a dispense record, the system creates a reversal and then a corrected entry, both attributed and timestamped. Staff see a normal correction workflow, and the difference is invisible day to day. It becomes visible during an inspection, when the question is what the pharmacist actually saw at the time of dispensing, and only an append-only ledger can answer that.
Do we really need offline operation?
For the dispensing path, in almost every case yes. A pharmacy that cannot dispense during an internet outage has patients waiting for medicine and no acceptable alternative to offer them, which makes it a commercial and sometimes clinical emergency rather than an inconvenience. What you do not need is for everything to work offline. Claims can queue, new electronic prescriptions genuinely cannot arrive, and the honest approach is to define which operations degrade how, and to show that state clearly rather than letting an action appear to succeed when it has not.
When is a custom build actually justified over a commercial product?
Four situations, in our experience. A chain whose replenishment or pricing logic is a genuine competitive advantage. A hospital pharmacy with ward supply workflows that retail products do not model. A market whose regulatory specifics the available products handle poorly. And the most common one, a market where the available options are aging desktop suites with no realistic modernization path. A standard single independent dispensary is usually better served by buying, and any supplier unwilling to say so should be treated with caution.
How should we measure whether the system worked?
With operational numbers the owner already tracks, measured before the project starts. Seconds per dispense, because it multiplies by hundreds of transactions a day. Expiry write-off value per month, because it is direct cash and highly responsive to expiry visibility. End-of-day reconciliation time, because it is staff hours. Stockouts per month. Features shipped is not a measure of anything, and a project that cannot state its baseline cannot demonstrate improvement.
What happens to our data if we change systems later?
That depends entirely on what you insisted on at the start, which is why it belongs in the contract rather than in a later conversation. Ask for a documented export of the dispensing history, the stock ledger and patient records, available on demand rather than as a paid professional services engagement. Pharmacies outlive software by decades, and in a regulated industry the inability to extract your own records is not only a commercial problem but a compliance one.
If you are digitizing a dispensary, a chain or a hospital pharmacy and want the audit trail designed in rather than patched on afterwards, talk to AgileTech, a software engineering partner in Vietnam that builds regulated healthcare systems.
