An Evidence-to-State architecture for reliable AI in Retail Pharmacy

[Puneet Arora]

The Problem - A true event can still be a wrong context:​

Imagine a retail prescription that hits a prior-authorization reject at 9:01 AM. At 9:20, the PA gets submitted. At 11:42, a pharmacist talks to the PBM and learns that the case is still under clinical review. While inventory is available and no action is required from patient. The next useful workflow action would be to simply monitor the payer decision.

Each one of those facts can be accurate. Yet an AI assistant that sees only the original reject, can still make the wrong recommendation. It might tell pharmacist to resubmit the claim, ask the patient to call the insurer, or prioritize outreach that is no longer meaningful. Here the failure is not necessarily bad data event. It is a failure to reconstruct the current operational state from a sequence of otherwise valid observations, i.e. the lack of clarity to AI in building relationship among those events.

This clarity matters in retail pharmacy, because a prescription is not a single transaction. It progresses through multiple operational stages, including prescribing, review, adjudication, prior authorization, inventory, fulfillment, communication, and exception handling.

Some of the information needed to understand the stages is captured live in structured systems as transactions and workflow events . But the other information that can materially change the prescriptions operational state may arrive through fax, or a payer portal message, or a phone call, or a prescriber response, or the information provided by the patient at the counter.

These inputs do not necessarily arrive in sequence, and many of them change asynchronously. As a result, no single transaction or system record can always be assumed to represent the prescription’s complete current operational state.

The missing layer - a Current prescription context:​

I am using the term Pharmacy Operational Context Gap for the difference between distributed operational information and the resolved, current, traceable prescription state that a workflow or AI consumer actually needs. The proposed solution is a derived operational projection; a Current Prescription Context.

For a prescription, that projection should be able to answer a small set of practical questions for example:

• What is true now?
• What is blocking progression?
• What remains unresolved?
• Which external party or internal role is pending?
• What evidence supports the interpretation?
• How fresh is that interpretation?
• What action is allowed or required next?

The key design choice I propose is to make that result explicit and resolved in upper architecture layer, before reasoning interaction with AI starts. Instead of asking every copilot, workflow engine, or agent to independently infer state from raw transactions, events and notes, the platform resolves operational context once and exposes it as a versioned contract.

Prescription	Active
Claim	Rejected, PA Required
Coverage	Active plan on file
Prior authorization	Submitted, Payer review pending
Inventory	Available
Safety / Compliance	No unresolved hold found identified in currently available evidence
Patient action	None Currently Required
External dependency	Payer Determination
Next workflow step	Monitor PA / Recheck status
Last meaningful change	PBM Status confirmed 11:42 AM
Context version	44
Supporting Evidence	Claim response + Pa record + Pharmacist/PBM interaction

     Table1: An example of Current Prescription Context. It is a versioned projection, not a new source-of-truth system.

Some of the ideas exist in event-based systems, temporal models, workflow engines, and context layers for AI. The point is not to rename those patterns or claims.

Having personally witnessed the problem in pharmacy domain for years, my point is simply that “pharmacy-specific problem is integrating them across the actual evidence that drives a prescription journey, including transactions, documents, and human interactions, while preserving the semantics needed to resolve current state safely and reliably.”

The solution architecture – evidence first, state second:​

“Building operation-context architecture into stateful pharmacy workflows”

A practical architecture has five parts:

1. Operational Sources
2. Capture and Correlation
3. A Context Engine
4. A Current context projection
5. Downstream consumers

Policy, authority, and human reviews remain across the architecture.

Operational Sources:​

Operational sources are the systems and interactions that produce evidences about the prescription journey. For example, e-prescriptions, claim responses, prior-authorization status, inventory and workflow events, documents, payer portal messages, and structured outcomes from staff interactions.

Capture and Correlation:​

Capture and correlation attach incoming observations into evidence of correct operational entities, for example: auto searching the correct patient, prescription, claim, coverage episode, authorization, or task.

Correlation may find direct references, reliable business identifiers, or bounded probabilistic matching during search. If the match is ambiguous, the architecture should record the ambiguity and route it for review and not silently converting a guess into prescription state without evidence.

Context Engine:​

The Context Engine then resolves evidence over time. Build relationships among evidences. This is tricky, especially when workflows events arrive out of order. For example, A payer response can be received after a recent phone conversation. A fax can correct an earlier prescription. A patient can present new insurance while an old-plan claim is still unresolved. “This is why the model needs both occurred/effective time and recorded/received time, plus explicit correction and supersession relationships.”

Current Context Projection:​

The output of the Context Engine is a version of Current Prescription Context. This is the read model that downstream systems consume. It is not source-of-truth database. It is just a versioned, derived snapshot of the prescription across the operational domains. A useful projection can answer, “what is true now”, “what is blocking the prescription processing”, “which dependency is external” , “what changed ‘most’ recently”, and which evidence supports this context resolution. If evidence conflicts, that conflict will itself appear in the projection and not hide behind a single status value.

Downstream consumers:​

Downstream consumers include pharmacy management systems (PMS), pharmacist work queues, alerts, operational dashboards, rule engines, integration workflows, AI assistants/agents. The important point is each consumer starts from the same resolved context instead of independently replaying claims, reading notes, or guessing which event is newest. Each consumer can perform different jobs or execute actions according to their define policy while sharing the same interpretation of current state context.

Authoritative changes flow back through the appropriate workflow or source-system APIs, create new evidence, and cause the Context Engine to resolve a new version.

In summary, the Context Engine resolves evidence; the projection publishes the result; consumers decide or act only within their permitted scope. When context changes, the projection receives a new version. A consumer that began work from an older version can detect that its assumptions are stale and re-read the current context before committing an action.

It also makes it easier and clearer to triage and debug issues, because teams can ask whether the problem came from source evidence, state resolution, or the consumer’s decision logic and stop treating every AI error as a model problem.

Four design rules make the context trustworthy:​

Evidence does not directly overwrite state​

• All source events remain part of history without becoming the current state.
• Evidence may be accepted, superseded, conflicting, ambiguous, or historical.
• State changes only after the resolver applies approved domain rules or an authorized human decision.

Keeping operational domains separate​

• Prescription, claim, coverage, prior authorization, inventory/fulfillment, safety/compliance, and task state should be distinct.
• If a patient presents new insurance, which changes coverage evidence, then it must not rewrite history and make an unapproved claim look as though it was submitted against the new plan.

Persist provenance and conflicts​

• Consumers usually need the latest resolved view, not the entire history.
• The platform should still retain the underlying evidence, source, actor, channel, timing, and corrections.
• If conflict is unresolved, the conflict itself belongs in the current context.

Versioning the projections​

• If an AI recommendation was generated from context version 43 and the prescription moves to version 44 before the action is committed, it should be rejected or re-evaluated.

This makes the context version a very simple but powerful stale-action control.

Design implications beyond the core pipeline:​

Why an event bus is not enough​

• It is easy to reduce this design to an event-streaming problem by putting every pharmacy event on a bus, storing an immutable log, and letting consumers materialize whatever views they need.
• Those techniques are useful, but they do not answer the domain question by themselves. A claim response, a payer phone call, a patient statement, and a faxed correction have different semantics. They can also disagree.
• The event log tells you what the system observed. But the context projection tells you what the platform currently believes is operationally true, how it reached that belief, and what uncertainty remains.
• In a regulated workflow, consumers should be able to move from the current projection back to the supporting evidence without asking the AI model to invent that lineage after the fact.

Human interactions are operational evidence​

• One of the easiest architecture mistakes is to design the transactional path carefully and then treat phone calls, walk-in conversations, or faxed documents as unstructured side channels. In pharmacy, those side channels often explain why the workflow is in its current state.
• It is hard to capture information from unstructured channels, but the architecture still should not require pharmacists to fill out another large form after every phone interaction, a fax delivery, or in-store patient conversation . This is not constructive.
• We can use workflow-derived capture where normal actions express the outcome. For known cases, it can be recorded as a structured disposition may be enough. Dictation, telephony transcription, or document intelligence can propose candidate evidence, as long as machine extraction should not automatically become authority.

State is not authority​

• A context engine can conclude that a prescription is blocked by a payer determination. That does not authorize an AI system to take any action it wants.
• State resolution answers what is happening; policy and authority answer what is allowed.
• It might be useful to consider three AI operating modes.
  • A read-only system can summarize blockers or prioritize work.
  • An assistive system can extract candidate facts, draft communication, or recommend a next step.
  • An acting system can execute an administrative task only when the permitted scope, authentication, validation, escalation path, audit trail, and recovery behavior are explicitly defined.

From architecture to adoption:​

The practical adoption path​

• Before adding more AI to a pharmacy workflow, make the current operational state explicit.
• I would not start by giving an AI agent write access to pharmacy workflows. I would start by making current state measurable.
  • Run the Context Engine in shadow mode and compare its snapshot with expert-reviewed pharmacy cases.
  • Automate only defined administrative tasks with context-version checks, explicit authorization, validation, escalation, and rollback.
  • Moving to autonomy only after context correctness and operational benefit are measured, not because the model became more capable.
• Then put policy and human authority around any action that follows.

A Practical Takeaway:​

Proposed architecture does not make AI "safe." But it creates a much better contract between operational systems and AI in regulated pharmacy workflows.

Afterall, a life (human or pet) is seeking pharmacy help behind the scene, and it is our responsibility to serve them with care and safety.


Disclaimer: The views expressed here are my own and are based on general industry observations and my experience. The examples are illustrative and do not represent any specific employer, pharmacy system, organization, or patient.

- απ