Drug Diversion Monitoring Software Problems: The 7 That Hide Real Cases, and How to Avoid Them

Why does the build turn into a data warehouse project?

The reasoning that leads here is sound at every step, which is what makes it dangerous. Diversion detection depends on joining automated dispensing cabinet transactions to administrations to waste to inventory, so the team concludes that the join is the product and starts by building it comprehensively. Every facility, every cabinet vendor, every drug, every unit. Pharmacy informatics enjoys this work because it is tractable. Compliance waits.

What is specific to this category is that the value does not arrive proportionally with coverage. A diversion programme that can analyse two high risk drug classes on ward workflow at one hospital, and open a case on what it finds, is materially useful. The same programme with complete coverage and no case management is a reporting exercise. The people who fund this at executive level are funding investigations, not a schema.

The sequencing that works is deliberately narrow. One facility, the two drug classes with the highest diversion risk in your estate, ward workflow only, and case management from day one so the committee has somewhere to work while the analytics mature. Add cabinet vendors, facilities and anaesthesia as later phases with their own budget. A programme that has closed three real cases has political capital to expand. A programme that has ingested everything and found nothing has an awkward budget meeting.

What goes wrong with identity resolution across systems?

This is the data problem that quietly decides whether the whole system works, and it is consistently underestimated.

A clinician appears in the cabinet as a badge identifier or a cabinet-local user account, in the electronic health record as a network account, in the scheduling system as an employee number, in human resources (HR) as a payroll identifier, and on a licence as a state issued number. None of them match. Names are worse than useless as a key, because units carry two people with the same surname, married names change mid-year, and a preferred name in one system differs from the legal name in another.

The failure mode is specific and severe. Get the join slightly wrong and a diverting clinician's removals split across two identities, so neither profile looks unusual and the pattern disappears. Get it wrong the other way and two people's activity merges into one, producing a statistical outlier who has done nothing, which is the fastest way to destroy a programme's credibility with nursing leadership.

The fix is to build identity resolution as a named component with its own review process, not as a lookup inside the ingestion job. Every mapping between a source identifier and a person carries a confidence and a provenance. Unresolved identifiers become a monitored queue rather than being dropped. And any clinician whose profile is about to be surfaced in an alert has their identity mapping verified before a human sees the name. Leavers and agency staff deserve particular attention, because a person who worked three shifts through an agency may exist in the cabinet and nowhere else.

Why do the cabinet and record feeds break after launch?

Both feeds work at go live and both degrade, in ways that are easy to miss because the output still looks plausible.

On the cabinet side, the break is semantic rather than technical. Vendors use the same words for different things, particularly around overrides, discrepancies, waste and returns, and a firmware or configuration change at one facility can alter what a transaction type means without altering the export format. Your normalisation layer keeps parsing happily and the numbers shift underneath it. Comparing a facility on one vendor against a facility on another then produces a difference that is an artefact of the export rather than a finding.

On the record side, the break is workflow change. A unit adopts a new documentation practice, or a build change moves where waste is recorded, and the administrations stop matching removals for that unit. The system reports a rising unmatched rate, which is exactly right, but only if somebody is watching it.

The controls that hold: treat the unmatched removal rate per unit as a monitored operational metric with an owner and a threshold, because it is both a data quality signal and a genuine diversion signal and you cannot tell which without looking. Validate transaction type counts per facility per week against expected ranges so a semantic change shows up as a step. And require the developer to document, per vendor, exactly which source field maps to which internal concept, so when the numbers move somebody can check rather than guess.

What happens when the case file is not built to survive a hearing?

This is the gap that does the most damage, because it surfaces at the worst possible moment.

Detection is the part everyone designs. What determines whether a programme survives is what happens after an alert: a named investigator opens a case, gathers the underlying transactions, speaks to a manager, brings in human resources and legal at the right point, and reaches a disposition that either exonerates a clinician without damaging a career or leads to a report to a licensing board and potentially to the Drug Enforcement Administration. Controlled substance recordkeeping obligations under the Controlled Substances Act sit on the registrant, so the file has real consequence.

The common failure is a system that produces an excellent alert and hands you a report. The case then lives in a shared drive folder, an email thread and a spreadsheet on the compliance officer's laptop, and that becomes your evidence file.

The second failure is subtler and more damaging. The case links to a live query rather than capturing the data. Source systems correct and purge records as a matter of routine, so eighteen months later the query returns a different set of rows than the investigator saw, and opposing counsel has an easy afternoon.

What to build instead: evidence snapshotted into the case at the moment of capture, an immutable activity log of every action taken, structured interview records, a disposition taxonomy that records exonerations as clearly as substantiated findings, and a permission model for cases that is entirely separate from the analytics users. Analytics needs broad visibility across clinicians to compute peer statistics. Case access needs to be restricted to named investigators and logged. Building both on one undifferentiated permission model is the mistake that gets a programme shut down by legal after its first sensitive case.

Should you build custom or configure what you already own?

Plenty of hospitals reading this should buy, and it is worth being specific about who.

If you are a single hospital on one cabinet vendor with one electronic health record instance and mainstream ward and perioperative workflow, buy. Bluesight and Invistics do this competently and their models have been tuned across many hospitals, and a build would be reproducing work already done well. If your primary gap is identity and access rather than medication analytics, Imprivata is the more relevant investment. And if Omnicell supplies your cabinets, take their analytics seriously for the cabinet side even though it cannot see the rest of your estate.

There is also a staffing answer that beats software. A single community hospital with no dedicated diversion specialist should hire one before commissioning anything, because a competent specialist with vendor analytics finds more than an excellent platform with nobody to work it.

The build case starts when the estate itself is the problem. Several facilities on different cabinet vendors, more than one record instance after acquisitions, an anaesthesia department that packaged models misrepresent, or a specialty setting such as behavioural health, oncology infusion or a surgery centre network where ward assumptions do not hold. It also starts when your programme has matured past detection into investigation volume, because at that point the case file is your real product and analytics vendors do not build a defensible one. The strongest argument is one that rarely reaches a business case: the model only improves if case outcomes feed back into it, and case outcomes are the most confidential data you hold.

How do hidden costs get into the quote?

Five items are routinely missing from estimates in this category.

Cabinet vendor count. Each additional vendor is a separate transaction export with its own semantics, and it is ongoing maintenance rather than a one-off adapter.

Anaesthesia integration, which is the single largest scope item and is frequently described in a quote as a phase rather than priced. Modelling the anaesthetic case as the unit of analysis, with drawn, administered, wasted and returned normalised for case type and duration, is a project in its own right.

Paper documentation on any unit. A unit still recording waste on paper is either a permanent blind spot or a capture project, and the quote should say which. Blind spots matter here more than in most categories, because they are precisely where a person who has been diverting for a while ends up working.

Identity resolution, which is often assumed rather than scoped and is genuinely hard when badge identifiers, network accounts, employee numbers and licence numbers do not line up.

And running cost. Budget 15 to 20 per cent of build cost per year, weighted toward feed maintenance and model tuning, because cabinet firmware, record builds and documentation practice all change under you.

What separates a build that works from one that fails here?

Four things, and the first is about capacity rather than code.

Design the output for the investigative hours you actually have. If your specialist has ten hours a week, the system's job is to produce the highest value ten hours of work, not a complete list of anomalies. That means a combined risk score, suppression of signals a previous case already explained, and dispositions feeding back so an exonerated pattern stops resurfacing monthly. A programme whose alert list outgrows its team is treated as background noise within a quarter, and it does not recover.

Second, matching has to be a tunable model with an explicit unmatched population, not a fixed time window. Nurses pull for two patients at once and chart forty minutes later. A rule that assumes otherwise produces confident nonsense.

Third, peer groups come from your assignment and scheduling data rather than from a static unit code. If the peer group is wrong, every ratio computed against it inherits the error, and no amount of statistical sophistication downstream repairs it.

Fourth, measure the programme on time from first anomalous signal to case opening, not on alert volume. Alert volume is a number a system can inflate on demand. Time to case is the number that reflects whether anything is actually being investigated, and it is the one an executive sponsor should be shown every month.