Your Dispensing Record and Your Stock Record Answer Different Questions
A recall notice lands on a Tuesday morning and asks two questions. Where is the affected batch now, and who already has it. Our product answers the first one properly — batch by batch, location by location, with quantities in, out and remaining. It cannot answer the second, because there is no patient anywhere in it, and that is a boundary we intend to keep.
The email arrives from the distributor at 08:40. One batch number, one product, immediate quarantine, contact anyone who received it. By 09:00 the superintendent needs two answers and they are not the same answer. The first is about the shelf: how much of that batch is still in the building, in which branch, in which room. The second is about people: which of them walked out of the door with it, and can they be reached.
Inventory software answers the first question. Dispensing software answers the second. A great many procurement documents put both under one heading called "pharmacy management", and that heading is where the trouble starts, because a product can be excellent at one and structurally incapable of the other.
This post says exactly which one we are, and it says it in the way that is most useful: by describing precisely how far our answer to the first question goes, and then showing you the wall it stops at.
What the stock record knows, which is more than most people expect
Stock in this product is batch-aware from receipt to issue. A batch is a record in its own right — batch and lot number, expiry date, a quality status and a recall status — and it is attached to the physical rows that say how much of it sits in which location. Every movement that touches it writes a trace event.
| What is recorded | On what | Available where |
|---|---|---|
| Batch and lot number, expiry, quality status, recall status | The batch record | Batch screens and the batch-risk report |
| Direction, quantity, event type, location, timestamp, operator | Every trace event | The traceability screens and the API |
| Which batch a given issue drew from | The check-out row | Issue history |
| Which supplier and purchase order brought it in | The batch, via its relations | The recall trace |
| Where the remainder is sitting right now, with quantities | Computed live from stock locations | The recall trace |
There is a dedicated recall function, on the web and on the API. Give it a batch and it returns the complete event history in time order, the list of locations still holding any of it with the quantity in each, and three totals: how much came in, how much went out, how much remains.
The 08:40 email, run through the recall trace
That is a real answer to the first question and it is the harder half of the operational work. Everything above is computed from stored data, not reconstructed by hand.
The trace tells you two hundred and forty units left the building. It cannot tell you one phone number.
Why the second question is a different object entirely
A dispensing record is not a stock record with an extra column bolted on. It is a record about a person, and it carries things a stock ledger has no concept of: who the medicine was for, who prescribed it, at what dose and for how long, whether it interacts with something else they take, whether they have an allergy that rules it out, whether the quantity dispensed matches the entitlement, and who is professionally answerable for the decision.
Every one of those is a clinical judgement attached to an identified individual. None is inferable from the fact that a box left a shelf.
There is no patient in this product
Stated as plainly as it can be stated, and verified by searching rather than by recollection: there is no patient, no beneficiary and no prescription anywhere in this application. Not a model, not a database table, not a column, not a service. A search across the entire codebase returns nothing.
The consequences are worth spelling out one at a time, because each of them is a question somebody will ask in an evaluation.
- A stock issue has no recipient field. A check-out records the item, the batch, the location it came from, the quantity, the cost and the person who performed the issue. There is nowhere to put who received it, because there is no such field.
- The nearest thing to a recipient is a customer, and a customer here is a commercial counterparty: a company name, contact details, an address, a currency, a credit limit and an outstanding balance. It is built for someone you invoice, which is the wrong shape for a person collecting medicine.
- Most till sales carry no counterparty at all. The customer link on a sale is optional in the schema and unattached sales are shown throughout the reports as "Walk-in". For a retail pharmacy that will be the overwhelming majority of transactions.
- The recall trace does not follow a sale outward. It gives you internal movement and the remainder. It is designed to stop at the door and it does.
- An issue can point at a project or an invoice, which covers a ward, a programme or a wholesale order. Those are destinations, not people.
This is a boundary we intend to keep
Health information about an identified person is special-category data under Kenya's Data Protection Act and its equivalents elsewhere. A product that stores it takes on consent capture, retention schedules, subject access handling and clinical governance — a serious set of obligations that has to be built deliberately, not acquired by adding a name field. We have not built that, we do not hold that data, and the honest thing is to say so rather than to add a text box and let a buyer assume the rest exists behind it.
One related point, so that nobody reads more into our compliance posture than is there. The data-subject tooling in this product is built around user accounts — the people who log in. It is not a general facility for handling requests from third parties whose data you happen to hold. If you are weighing obligations of your own here, take your own advice on them; what we can tell you with confidence is what we do and do not store.
The three situations where this actually decides something
Abstract scope statements are easy to nod along to. Here is what the boundary does in the three moments a pharmacy will meet it.
| The situation | What we answer | What has to come from elsewhere |
|---|---|---|
| A batch recall | Where every remaining unit is, in which branch and room, with quantities and a dated movement history | Which individuals received the 240 units that left |
| An inspection of controlled or high-value stock | Receipt, movement and issue of every batch, attributed to the operator, with variance history from counts | The clinical record of each supply and the professional who authorised it |
| An insurance or scheme claim | What was issued, when, from which batch, at what cost | The entitlement, the prescriber, the diagnosis, the person |
Read across the middle column and you have a fair description of what an inventory system is for. Read down the right-hand one and you have a fair description of a dispensing system. The mistake is not choosing one — it is buying one and believing the other came with it.
How the two should sit together
Most pharmacies of any size already run something for the clinical side, or are required to. The practical question is not whether to have both but how they meet, and the answer is more mundane than it sounds.
-
Let the dispensing system own the person
Who received what, on whose authority, against what entitlement. That record belongs where the clinical governance is, and it should not be duplicated into an inventory product.
-
Let the stock system own the shelf
Receipt, batch, location, movement, count, variance, issue, cost. This is where a dated and attributed trail is worth having, and it is what we do.
-
Make the batch number the join
If your dispensing system records the batch it supplied from, the two records meet at that number and a recall becomes answerable end to end. If it does not record the batch, no amount of integration will rescue that, and it is the single most valuable thing to check.
-
Decide who owns the quantity
Two systems both trying to be authoritative about how many boxes are on the shelf is the classic failure. One of them decrements stock; the other refers to it. Agree which before either is configured.
-
Write the boundary into the procurement document
If a tender asks for dispensing and inventory as one line, split it into two before anyone quotes. A vendor answering yes to both should be asked which of the two questions above they answer, in their own words.
Questions we answer
- How much of batch LOT-4471 is left, and where exactly
- When did it arrive, from which supplier, on which purchase order
- Every movement it made, dated and attributed to an operator
- Which issues drew from that specific batch
- What did it cost, and what is the value at risk
- Which batches are near expiry, and where they are sitting
- What the last count found, and what the variance was
Questions we do not answer
- Who received it
- Who prescribed it, and at what dose
- Was it clinically appropriate for that person
- Does it interact with anything else they take
- Were they entitled to that quantity under their scheme
- Which individuals do we need to phone this morning
Built and verified in the code
- Batch and lot records with expiry, quality status and recall status, attached to the physical stock rows that hold them.
- A trace event on every movement capturing item, batch, serial, warehouse, location, direction, quantity, event type, the source document, the operator and the timestamp.
- A dedicated recall trace, on the web and the API, returning the full event history for a batch, the locations still holding it with quantities, and totals in, out and remaining.
- Batch-attributed issues. A check-out records which batch it drew from, so an issue is traceable to a lot rather than only to an item.
- Supplier and purchase order provenance on the batch, so an upstream trace is available alongside the downstream one.
- An optional customer link on till sales, for the cases where you do invoice or account-track a buyer.
More we can add — each one a deliberate scoping decision
- A patient, beneficiary or prescription entity. A model, a table, the columns and the service behind them — established as a build by searching the whole application for it rather than by recalling it.
- A recipient on a stock issue. A check-out records who performed the issue, never who received the goods.
- A downstream trace to a person. The recall trace covers internal movement and the remainder; it does not follow a sale outward, and it is not intended to.
- Clinical fields: a prescriber, a dose, a frequency, a course length, an allergy, an interaction check and an entitlement.
- A consent, retention or subject-access handling for third-party individuals. Our data-subject tooling is built around the people who hold user accounts.
- A dispensing report, because there is nothing to report on. What exists is a stock issue report, and it answers a different question.
Where the line falls
- If you need to know where every unit of a batch is and how it got there, this is a strong fit and the recall trace is real, not a roadmap item.
- If you need to know who received it, you need a dispensing system, and you should buy one rather than hope this grows into one.
- If a tender asks for both, split the line. The two products co-exist well, and the batch number is where they meet.
We do not intend to build a clinical record, and we would rather say that clearly than leave it ambiguous on a roadmap. Where we will happily do work is on the join: exporting batch-level issue data in whatever shape your dispensing system can consume, so the recall question becomes answerable across the two.
Verified against the repository on 7 August 2026. That the patient entity is a build was established by searching for it across the application and its migrations, rather than by failing to recall one.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsThat closes this set. Five posts before this one drew lines in the same way — around expiry and short-dated stock, around what FEFO can and cannot enforce, around a reorder point that recalculates overnight, and around a cold-chain unit whose service calendar lives on a card taped to its door. The point of writing them was never modesty. It was that a pharmacy choosing software has to plan around what is true, and the fastest way to be useful is to make the true thing easy to find.
Send us the tender line, not the brochure
If you are writing or answering a specification that puts dispensing and inventory in one requirement, send us the wording. We will tell you which half we answer, where the join should be, and what to ask whoever is quoting for the other half.
Talk to us about a pharmacy deployment