You are not buying six tools. You are buying one patient context and a workforce that runs on it.
OneDose is an AI care workforce for medication: six agents that answer inbound calls, recover lapsed refills, assemble and chase prior authorizations, structure prescriptions arriving as faxes or images, and run structured follow-up on every discharge. All six read and write against one shared patient context and one audit log, so the integration and the security review happen once rather than once per capability.
Which is the whole argument: the second agent costs a fraction of the first, and the fourth costs almost nothing.
What does an AI care workforce actually change?
Medication is upstream of numbers a hospital or a pharmacy group already reports — the calls that go unanswered, the refills that lapse, the authorizations that hold a bed, the discharges nobody has capacity to follow up. Almost none of those are filed against medication in anyone’s accounts. Medication is filed as a cost line.
Below is what each agent changes, what has to be true for it to be worth anything, and where it does not apply. The last part is not modesty — a benefits page with no stated limits is an advertisement, and the limits are the part worth reading if you are deciding whether to take the meeting.
Every call answered, on the first ring
The line rings out at the busiest hour of the day, because the busiest hour of the day is also the hour nobody can reach the phone. The caller wanted to confirm an appointment, move one rather than miss it, or ask whether a prescription was ready.
None of those calls are recorded anywhere, which is the part worth sitting with. A call that was never answered leaves no trace in any system — so the volume, the reasons and the abandonment are invisible to the people responsible for them.
The voice agent answers immediately, identifies itself as an AI, verifies the caller, and resolves the routine calls — hours, pickup status, refill requests, directions, whether a prescription is ready.
Clinical questions route to a person on site with the conversation attached, so the patient is not asked to start again. A caller who asks for a human gets one; an agent that resisted handing over would destroy the trust the channel depends on.
And what callers actually asked becomes data for the first time. For most organisations, that report does not currently exist anywhere.
That your callers are trying to do things an agent can finish. If most of your inbound volume is complex clinical conversation, the agent resolves almost nothing and hands over almost everything — you would be buying a very good switchboard. Ask us to look at a week of your call reasons before you decide, and we will tell you if that is what we see.
The refill that would have walked
A refill is not a delayed sale. For a patient on a long-term medication it is a monthly relationship, and the one that lapses usually lapses quietly — nobody declined anything, nobody complained, the request simply never got made.
The reasons divide cleanly and almost nobody captures them: the patient stopped because of a side-effect, stopped because of cost, was confused about the instructions, or never collected it in the first place. Those are four different problems with four different fixes, and an unfilled prescription looks identical in all four cases.
The refill agent validates and queues refill requests so a pharmacist reviews exceptions rather than working a list.
The adherence agent notices the refill that was due and was not collected, contacts the patient, and records the reason it did not happen — which is what turns an absence into something you can act on.
And the voice agent means the refill call that comes in gets answered rather than abandoned, which is the cheapest of all of these to fix.
That you dispense the fill. A health system whose prescriptions all leave for a retail chain by design gets the contact benefit and not the revenue one, and the honest version of this block for that reader is a shorter one.
Follow-up on every discharge, not the top decile
The intervention is not controversial. Contact the patient, ask structured questions, notice the answer that matters, escalate it. It is understood well enough to be in every guideline.
What stops it is arithmetic. Several hundred discharges a week, several contacts each, made by the most expensive people in the building — so it gets rationed to the highest-risk cohort, and the highest-risk cohort was already getting attention.
The patient who stopped an anticoagulant on day four because it made them feel strange is not in that cohort. That patient is the reason the gap exists.
Structured contact runs on every discharge — Day 1, Day 7, Day 14, Day 30 — checking medication, side-effects and recovery. Coverage stops being a function of how many clinicians are free to dial.
Every check-in asks the same questions in the same order, so one patient's Day-7 answer is comparable to their Day-30 answer and to everybody else's. Free-text call notes are not.
What reaches a clinician is an escalation with the whole conversation attached, rather than a queue of numbers to call.
That you want the coverage, and have somewhere for the escalations to land. This produces more signal than the current process does, and an organisation with no capacity to receive it will experience that as noise. The deployment question worth asking first is who works the escalation queue.
Clinical time spent on clinical work
A pharmacist trained for years to make decisions about medication, and a substantial share of the day goes to answering the phone, deciphering a fax, retyping a script, and chasing a payer.
A nurse or a coordinator has a panel larger than the number of people they can meaningfully contact, and closes the gap by triaging the list: work the top, hope the rest are fine.
None of that work is optional and none of it is clinical. It is the tax on the clinical work, it scales with volume rather than with complexity, and it is the first thing that expands to fill a day.
The routine contact happens without a clinician placing it — the scheduled check-in, the medication confirmation, the second and third attempt to reach somebody.
Prescriptions arriving as faxes or images come in structured, with uncertain fields flagged against the source image, so a pharmacist reviews a flag instead of retyping a document.
Everything that escalates arrives with the history attached, so the time goes on the decision rather than on reassembling the situation.
That the intent is fewer routine calls placed by clinicians rather than fewer clinicians. Deployed as a headcount reduction this tends to fail on its own terms: the escalations still need somewhere to land, and the organisations that get the most out of it are the ones that moved the time rather than removed it.
The order that never entered the system
A verbal order taken during a round. A fax from an outside prescriber. A photographed script. A discharge summary that arrives as a PDF with its table structure gone.
Somebody retypes it. Retyping is where a wrong strength enters a system that will then propagate it faithfully through every downstream check — and every one of those checks will pass, because they are all checking the record against itself.
This is one of the two ends of the medication process that the automation category has never addressed, and it is the one that happens before any of the safety technology switches on.
Orders arriving outside the ordering system are structured into drug, strength, dose, route, frequency and prescriber.
Anything the agent cannot read with confidence is flagged against the source image rather than resolved to the most probable value. On a milligram count, the most probable value is wrong often enough to matter.
What a pharmacist receives is a clean record with the uncertainty marked, which is a different job from reading a fax.
That a meaningful share of your orders actually arrive outside the ordering system. A hospital with genuinely universal electronic ordering does not have this problem and should not be sold this block — though it is worth counting rather than assuming, because verbal orders and outside faxes are usually undercounted by the people closest to them.
Length of stay, where medication is the blocker
The discharge clears clinically on the morning round and the patient physically leaves in the late afternoon. Part of that gap is medication: an authorization that has not come back, a discharge prescription that has not been written up, a query nobody has been able to reach the pharmacy to ask.
None of it is a clinical delay, and none of it is recorded as one. It is recorded as a bed-day.
The authorization runs and is chased without a person driving it, and its status is visible to the ward rather than only to the pharmacy.
The discharge prescription is structured where it arrives instead of queueing behind a transcription step.
The routine questions that would otherwise be a phone call to a pharmacy that cannot pick up get answered.
That medication is genuinely one of your top discharge blockers, and that you are capacity-constrained enough for a released bed-day to be worth something. Above high occupancy, a freed bed is filled the same day by the queue in your emergency department. Well below it, the honest argument is turnover and case mix rather than capacity — and anyone selling you occupancy from a medication system without asking which of those you are is selling you your own marketing department's job.
Why the second agent costs a fraction of the first
The competitive threat to a hospital or a pharmacy group is not one vendor. It is buying six point solutions over four years, each with its own integration, its own security review, its own data agreement and its own view of the patient that disagrees quietly with the other five.
OneDose is built the other way round. There is one patient context and one audit log, and every agent reads and writes against it. The integration happens once. What arrives after that is a capability rather than a project.
That is why the agents are a workforce rather than six tools with a shared logo — and it is the part of this you can verify in a thirty-minute demo rather than taking on trust.
It remembers; it does not learn
PharmaEye is shared context and retrieval. It does not train on patient data — not per-tenant, not across customers. Every agent reads one record rather than building its own model of your patient, which is a materially different question at a security review and a materially different answer.
One audit log, not six
Every agent action is recorded and attributable in one place. When a regulator, a governance committee or your own quality team asks what the intervention actually consisted of, the answer is a query rather than a reconciliation across systems.
The next capability is a decision, not a procurement
Because context is shared, adding an agent does not re-open the integration, the security review or the data agreement. The cost curve of the second, third and fourth capability is the argument — and it is the one thing a competitor cannot match by shipping a better version of any single agent.
It runs inside the estate you already have
OneDose is built to read and write against the systems already in place rather than to replace them. Integration depth varies by system and by region, and this site does not publish a matrix asserting depth nobody has confirmed. Ask what is live for your estate and you will get it in writing before committing to anything.
What would this be worth on your numbers?
This calculator contains no OneDose figure. Every improvement assumption on it is one you set, and each of them opens at zero — so the page shows no benefit at all until you choose one.
That is deliberate. OneDose does not publish an outcome percentage it cannot attribute to a named deployment, and a vendor number you have no way to check is worth less to you than your own arithmetic anyway. So this hands over the model instead of the conclusion.
The work arriving every month
Four numbers you already have. Leave anything blank that you do not track — a gap here is itself worth noticing, because it is usually the number nobody owns.
Per month, across the lines you are responsible for
Per month, however they arrive
Per month, submitted or chased
Per month, all of them — not the high-risk cohort
Your assumptions
all start at zeroThese three sliders are the only place a benefit enters this calculation, and they are yours to set. OneDose publishes no outcome figure it cannot attribute to a named deployment, so rather than asking you to accept ours, this asks what yours would have to be for a conversation to be worth having.
What the last few tools cost you to connect
This is the number the context layer argument is actually about, and it is one most organisations know and resent. Count only the integration and review effort — not the licence.
Clinical or operational systems you connected
Integration, security review and data agreement, in your currency
The OneDose claim about this number is architectural rather than numerical: the agents share one patient context and one audit log, so the integration and the security review happen once and each additional capability is a decision rather than a repeat of the work above. That is verifiable in a demo. It is not a percentage, and we are not going to present it as one.
And the loop the agents run on
Everything above is the medication process outside the walls, or at the edges of them — the order that arrived as a fax, the call nobody could answer, the thirty days after the patient went home.
Inside the walls there is a well-understood process with six stages: the order, pharmacist verification, preparation and packaging, dispensing to the point of care, barcode-verified administration, and documentation back to the record. Hospital automation has addressed those six for years and generally addresses them well.
OneDose counts a seventh — after discharge — because that is where the loop measurably reopens. Nothing confirms the patient collected the medication, understood it, started it, tolerated it or continued it. Every guarantee the first six provide stops at the door, and the agents above are what runs after it.
OneDose also builds the hardware that closes the middle of that loop physically: a dose packing machine that barcodes each package against the order it was packed from, and an IP dispensing machine that releases patient-specific doses against the active order. Those are a capital project rather than a subscription, and they are the right conversation once the agents are running — not before.
What OneDose does not do, at any stage: clinical verification, and the clinical decision at an override. A pharmacist verifies the order and a nurse makes the call at the bedside. OneDose structures, queues, prepares and records. A vendor offering to automate that judgement has built a regulated device and a liability rather than a medication system.
Who in your organisation does this land on?
Three people read this page differently, and the useful thing to know is that two of them are looking at the same mechanism from opposite ends.
The CTO or CIO reads the context layer
This is an architecture decision before it is a clinical one. What it touches, where the data sits, what the security review covers, and whether the next capability re-opens all of it. Ask us what is live for your estate and what the integration actually consists of — you will get it in writing before committing to anything.
The COO reads the authorization and discharge blocks
Authorization delay and follow-up coverage are bed-days and readmission exposure respectively, measured in the units an operations report already uses.
The pharmacy director reads the calls, refills and intake blocks
The same discharge prescription the COO sees as a bed-day is a fill that either happens in your pharmacy or walks. Those are one mechanism with two budget holders, which is usually how this gets two internal sponsors rather than one.
Frequently asked
- What are OneDose care agents?
- OneDose care agents are six AI agents that run the non-clinical work in a medication process: a voice agent that answers inbound calls, a refill agent that validates and queues refill requests, a claims and prior-authorization agent, an intake agent that structures prescriptions arriving as faxes or images, a follow-up agent that runs structured post-discharge contact, and an adherence agent that tracks whether medication was collected and continued. They share one patient context and one audit log, and they escalate anything requiring clinical judgement to a clinician.
- What is a universal context layer for healthcare AI?
- A universal context layer is shared patient context and retrieval that every AI agent reads and writes against, instead of each tool integrating separately and holding its own partial view of the patient. In OneDose it is called PharmaEye. The practical consequence is that the integration and security review happen once rather than once per capability, so adding a second or third agent does not repeat the work that made the first one expensive.
- Does OneDose train AI models on our patient data?
- No. PharmaEye is shared context and retrieval — it remembers a patient record so every agent reads the same one. It does not train models on patient data, per-tenant or across customers. That distinction matters at a security review, because training on protected health data is a use-limitation question under a business associate agreement and shared retrieval is not.
- Do AI agents make clinical decisions about patients?
- Not in OneDose. The agents collect, structure, contact and escalate. They do not diagnose, they do not decide whether a prescription is correct, and they do not close a case a clinician has not seen. Clinical questions, low-confidence answers and any sign of deterioration route to a person with the full context attached. The division is a design constraint rather than a configuration setting, because it is the constraint that makes the rest deployable in a hospital.
- Do patients know they are speaking to an AI?
- Yes, at the start of every call. Passing an AI agent off as a human is a trust problem and, in a growing number of jurisdictions, a legal one. A patient who asks to speak to a person gets one, with the conversation so far attached so the human does not start from zero.
- What ROI should we expect from OneDose?
- OneDose does not publish an outcome percentage it cannot attribute to a named deployment, so there is no figure to quote here honestly. What can be evaluated before any commitment is the arithmetic on your own numbers: how much inbound contact goes unanswered today, how many refills lapse without a recorded reason, how long authorizations take, and how many discharges get no structured follow-up. That is a conversation with your numbers rather than ours, and it is the honest version of this discussion.
- Do we have to buy the dispensing hardware to use the agents?
- No. The care agents and the context layer run as software against the systems a hospital or pharmacy group already has, and they are deployed without the machines in several markets. The IP dispensing machine and dose packing machine close the middle of the inpatient medication loop physically and are a separate, later decision — a capital project rather than a subscription.
- How is this different from buying separate AI tools for each task?
- Separate tools each carry their own integration, security review, data agreement and partial view of the patient, so the fourth one costs about what the first one did and the five before it disagree about the same patient. OneDose agents share one patient context and one audit log, so the integration happens once and each additional capability is a decision rather than a procurement. That cost curve is the architectural argument, and it is verifiable in a demo rather than dependent on a published figure.