The decisions between checkout and care

A patient completes an order and starts thinking about when the medicine will arrive. A reviewer opens the same request and notices something that needs clarification. The dispensing team sees stock on the shelf, while customer support sees a person asking why an apparently completed purchase has stopped moving. Each has a reasonable understanding of their part of the work. The platform has to make those understandings agree before anyone takes the next consequential step.

I think this is the central design problem in a prescription platform. A successful checkout establishes an intention to purchase. The system still needs to connect that intention to evidence, an authorized decision, the correct financial outcome, and a permitted handover. A mistake in those connections can allow one person’s perfectly ordinary action to defeat another person’s safeguard.

Platform Rx makes that dependency visible through an interactive workflow. The healthcare example below generalizes its underlying rules into a fictional patient journey, with illustrative dollar amounts. It follows one mixed order through the people responsible for it, then examines what the browser demonstration leaves for a deployed service to solve.

A useful gate preserves a condition the next person is entitled to rely on, while giving the person who encounters it a workable route forward.

The patient’s journey: submitting a request that can be resolved

Consider a patient ordering four items together. For this example, the service has established different handling requirements for each:

These are handling rules for the example. Before using such a model in practice, the service needs to establish which products enter each route, what evidence is required, and which professionals may act. Calling someone a reviewer, assistant, or administrator cannot create an authority their actual role does not carry.¹

From the patient’s perspective, the immediate task is supplying enough information for the request to be considered. The packet includes the prescription, prescriber details, treatment context, and declared medications, conditions, and allergies. In the prototype, the most demanding item determines the required completeness of the shared packet. Completing the fields permits submission and creates a held order; it does not determine whether supply is appropriate.²

This distinction should shape the interface. A file received successfully and a prescription accepted by a professional deserve different messages. The first confirms that information reached the service. The second records a judgment about what that information supports. Confusing them could lead a patient to believe the review is over while the person who must perform it has not yet begun.

The patient’s journey also needs a useful account of waiting. I would make the next responsibility visible: the service is reviewing the request, it needs an answer from the patient, or an authorized clinician must resolve a concern. A question should be specific enough to answer, and the order should remain available while the answer is obtained. Otherwise, the patient may have to start again simply because the service did not represent an unresolved question.

The reviewer’s journey: knowing when to decide and when to stop

The reviewer can confirm the nutrition product and examine the repeat prescription within their permitted scope. The remaining medicine requires the designated clinician. These distinctions should appear in the available actions, but they must also govern the action when it is attempted. In the prototype, the reducer checks the order’s stage, whether the item still awaits a decision, and the actor’s authority before accepting an approval or rejection.³

Suppose the reviewer confirms the nutrition product, then needs the patient to clarify the current dose before continuing.

Requesting more information pauses the whole order and retains the full $1,499 hold. The existing confirmation survives the pause.

When the patient replies, the question closes and the order returns to review; no outstanding item is automatically approved. The reply is recorded in the audit history, leaving the reviewer to assess what it means.⁴

There is an important design choice here. The reviewer is allowed to express uncertainty without forcing the patient into rejection or allowing the order to advance prematurely. The pause changes what everyone else may do, so the person preparing the delivery cannot interpret one approved line as permission to dispatch it.

A different uncertainty may require another professional rather than another answer from the patient. The reviewer can refer the repeat prescription with a reason and an optional note. That item remains pending, but its decision now belongs to the clinician’s authority level. The reviewer can continue eligible work on other items; they cannot reclaim the referred decision by switching back to their original view.⁵

Try the referral and inspect those changes together: the queue, the available decision controls, the unchanged payment hold, and the recorded reason. The useful feature is the transfer of responsibility. A message that merely asks someone else to look, while leaving the original approval route open, would permit the concern to be bypassed.

The clinician’s journey: resolving the concern without approving the whole basket

The clinician should arrive at the evidence and the question that prompted referral. A declared medication is information supplied for review. A possible interaction is a concern raised by a person. The prototype does not infer clinical relationships between medicines, and a recorded referral reason should not appear as a diagnosis or an automated finding.⁵

In the walkthrough, the clinician reviews and approves the referred repeat prescription. The nutrition product and refill are now decided, but the final medicine remains pending, so the entire $1,499 stays held. The patient sees one transaction; the reviewer sees separate decisions that must not acquire more scope than their authors intended.

Now have the clinician reject the final $610 medicine with a reason. This completes the outstanding decisions. The rejected amount reverses, the remaining $889 releases, and nothing remains held. The care product, nutrition product, and approved refill proceed together. A single order-level flag saying “approved” would conceal which medicine must be excluded; a flag saying “rejected” would conceal that the rest can proceed.⁶

The order in which decisions arrive also matters. Rejecting that medicine earlier reverses $610 while leaving $889 held until the remaining reviews finish. Approving it instead as the final decision releases the full $1,499. If every item requiring review is rejected, the prototype ends the order and reverses the entire hold, including the ordinary care item.⁶

These outcomes expose a product trade-off. The prototype preserves one dispatch per order, so a slow decision can delay items already cleared. I would examine that consequence before adopting the same arrangement for a healthcare service. Supporting separate deliveries would require separate release conditions, customer expectations, and financial reconciliation; the decision cannot safely be made by letting a packing team improvise around the hold.

The dispensing journey: crossing from information into physical custody

The dispensing team needs to know exactly which items may leave, who authorized them, and whether the order remains eligible for handover. In the prototype, dispensing becomes available only after payment release and only to an actor with the permitted dispensing role.

An operations user can subsequently confirm delivery without receiving authority to make clinical decisions.⁷

Before completing the reviews, attempt to record dispensing. The guard refuses the action, the transaction remains unchanged, and one blocked audit record explains the refusal. An authorized person trying to act too early should encounter a different explanation from a person whose role cannot perform the action at all. Both restrictions matter, but resolving them requires different next steps.

That boundary becomes harder once physical custody changes. The prototype permits ordinary cancellation before dispensing and refuses it afterward. This is a lifecycle rule for the demonstration. In a deployed service, a discovery after handover would need a defined incident, contact, and recovery process appropriate to the problem. Changing a status in the database cannot retrieve medicine already delivered.⁷

I would also require the final handover check to refer to the current approved contents. A change in quantity, medicine, or material evidence after review should trigger examination of whether the existing decision still applies. Otherwise, a team could carry a valid approval forward onto a different transaction. Version-bound approval and revalidation would be additional controls; the current prototype does not implement that change-management path.⁸

The operations journey: explaining an outcome and detecting a failure

Imagine the patient asks why one medicine is missing and why the final amount is lower. Support needs an account that connects the refusal to the financial change and the retained contents. Asking the clinician to reconstruct the event from memory would leave the answer dependent on who happens to be available.

In the prototype, one pure reducer owns order state and audit writes. Given the same state and action, it produces the same result, including the relevant records. Its initial orders are also built by replaying actions through the rules. This gives the owner and review surfaces a common source of transaction state, and it makes the consequences of a proposed action testable without relying on a particular screen.⁹

The final $610 rejection is especially revealing. One interaction produces four audit records: the rejection, the partial hold reversal, completion of the order’s decisions, and payment release. The records identify the actor, authority, simulated time, action, before-and-after order stage, payment status, and relevant note. The final state is $610 reversed and $889 released; the intermediate records explain how it was reached.⁶

Blocked commands have a different trace. The reducer preserves the order and appends a refusal with its reason. A disabled interface button, however, sends no command and creates no record. To inspect an unauthorized attempt itself, the lab needs an explicit guard-test action that reaches the reducer. Counting every disabled control as a prevented attempt would manufacture activity that never occurred.³

For a deployed service, I would use this history to investigate recurring patterns. Repeated requests for the same missing detail may suggest an intake problem. Repeated early-dispensing attempts may reveal a confusing handoff, a training issue, or attempted circumvention. The event establishes what was attempted; establishing why requires investigation. Monitoring should route a consequential pattern to someone with responsibility to respond.¹⁰

The same attention belongs on orders that stop producing events. A correctly blocked order can remain unresolved because the patient cannot answer, the clinician has not seen the referral, or nobody owns the next step. I would make those queues visible to operations and agree how to contact the patient, escalate the delay, or close the request appropriately. A timeout should never silently convert an unanswered question into permission to dispense.

The engineering journey: preserving the rules beyond the screen

The browser model makes the workflow inspectable. A service handling real prescriptions would have to preserve its conditions when requests arrive from different devices, credentials change, integrations fail, or someone tries to circumvent the interface. That work extends beyond the prototype’s client-side checks.

The first requirement is reliable identity and authorization. I would derive the acting identity from the authenticated session, verify permission for the particular patient, organization, order, and action, and enforce that check on the server. A support employee permitted to inspect delivery progress should not inherit permission to read every clinical detail or approve supply. OWASP’s authorization guidance emphasizes these per-request checks and the distinction between authentication and permission to act.¹¹

The next requirement is preserving decisions as the world changes. Two people may open the same pending request and act on different information. A service needs a way to detect that a decision was submitted against an older version, present the intervening change, and prevent a stale command from overwriting the accepted outcome. I would make the relevant version part of the decision contract and recheck the conditions at execution. The single-session reducer demonstrates sequential rules; it does not solve distributed concurrency.⁸

Payments create another boundary. The prototype moves directly from the last required decision to a released payment state. A real integration would need to distinguish eligibility to release funds, a request sent to the payment provider, and confirmation of its outcome. If a response is lost, retrying must not produce another charge. Idempotency keys can help a provider recognize repeated requests for the same operation; the order still needs a way to reconcile the result before asserting that payment succeeded.¹²

A related problem arises when saving the decision and notifying another service are separate writes. A crash between them could leave fulfilment unaware of an accepted decision, or leave another component acting on a change that was never committed. One possible design is a transactional outbox: save the state change and an outgoing event together, then deliver that event through a retryable process. Consumers still need to handle duplicate delivery. This is an extension to evaluate, rather than a property supplied by the in-memory reducer.¹³

The audit record needs protection as well. I would separate access to clinical evidence from access to operational history, retain references instead of copying sensitive documents into general logs, and protect stored records against unauthorized alteration. Recording who read or changed sensitive information matters alongside recording who approved the order. The prototype’s session audit is inspectable, but it has neither durable storage nor those access controls.¹⁴

These additions protect different relationships. Identity binds an action to a person; authorization limits its scope; version checks bind it to the information considered; payment reconciliation establishes the financial effect; and audit makes the accepted or refused transition available for investigation. A complete record can still describe a mistaken clinical decision. The service must therefore preserve professional review and its own quality controls alongside the transaction safeguards.

Where I would try to break the design

I would begin testing before the patient’s request reaches a reviewer. Classification determines whether the review process runs at all. In the prototype, products arrive with fixed handling classes. For a real catalogue, I would test an ambiguous listing, a conflicting product description, and a correction that changes the required route. My default for an unresolved classification would be to withhold the item from the transaction until an authorized person resolves it. This proposed catalogue control is outside the current demo.¹

Within the existing workflow, the most instructive tests combine journeys. Approve one item, ask for more information, and try to dispense while waiting. Return with an answer and check that the earlier approval survives without approving anything else. Refer the refill, then check that the original review role cannot decide it. Reject the final medicine and reconcile both the money and the four audit records before confirming the retained delivery.¹⁵

I would repeat the financial test with the decisions arriving in another order. The intermediate holds should reflect which items have already been rejected, while the final retained amount should agree. I would also repeat a completed action and attempt cancellation after handover. The important result is what remains unchanged, what is recorded, and which person can legitimately resolve the next step.

The synchronized companion should let the reader follow all of this as one transaction. The patient sees a question and a hold; the reviewer sees an unresolved item and their authority; the clinician sees a referral; operations sees the retained contents and financial outcome. Switching perspective should reveal another part of the same history. Scrolling can advance the authored walkthrough, while explicit experiments keep their own state until the reader chooses to return.

The opportunity is a service in which patients spend less effort coordinating the people responsible for their care, and those people can act without reconstructing what happened elsewhere. I would judge the design by whether each handoff preserves the information and authority the next person needs, including when the right outcome is to pause, refuse an item, or investigate a failure. Those are part of the service people should be able to trust.

Explore the repository · Read the companion essay: Designing a prescription platform

Source notes