Essay11 min read

Designing a prescription platform

By Emmanuel Benami

For someone managing a pet’s chronic treatment, the next refill can involve much the same work as the last one. The owner contacts the clinic, sends the prescription and patient details, waits for review, and arranges collection. A treatment decision already exists, yet the owner still has to reconnect the people and information needed to act on it. This was the recurring problem behind Platform Rx.¹

Some of this repetition is administrative. Some establishes whether the next supply should proceed. An expired prescription or a discrepancy in quantity can matter even when the customer is ordering a familiar medicine. Making the experience easier requires understanding what each step contributes before deciding which steps to remove.

I think the most useful starting point is to work backward from the customer receiving the medicine. What has to be true for that delivery to be appropriate? Who can establish it? What must the software do while the answer is still unknown?

I worked through these questions when leading Platform Rx, a prescription workflow within a veterinary marketplace. Its clinics retained clinical authority and custody of the medicine; the platform coordinated the transaction. The examples here concern that model and its emphasis on existing prescriptions. Other services need to establish their own clinical roles and applicable requirements.²

Choose the part of care you are making easier

“Build online Rx” leaves too much undecided. Helping an owner obtain an established refill is a different product problem from helping them obtain a diagnosis or begin a changed treatment. Those differences determine the evidence, review, and recovery the experience needs.

We started with repeat access because owners were already asking for it, and the veterinary sellers on the marketplace wanted an online channel. The clinics had the medicine and professional capability. What was missing was a shared workflow that let the customer submit a request once and follow it through to delivery. New or changed prescriptions needed stronger verification; diagnosis and prescribing remained outside the platform’s role.³

That choice should shape the intake form. Each field needs a reason connected to the reviewer’s decision. In our flow, medicine classification determined the required evidence, including relevant patient and treatment context. Reducing form abandonment by removing a necessary field would simply move the missing-information problem to the clinic’s queue.⁴

The recurring journey also creates an opportunity to carry evidence forward. But evidence already on file and permission to fulfil a new order are separate things. A useful refill experience reduces repeated entry while still letting the reviewer establish whether the current request meets the prescription’s conditions.

Set the operating model before designing permissions

The next decision is who will perform the professional work. A platform that owns a pharmacy is taking on a different business from one that connects customers to existing dispensing clinics. Inventory, staffing, premises, and fulfilment follow from that choice. So do the roles the software has to represent.

We chose clinic-led dispensing because the sellers already held those capabilities. Operating our own pharmacy would have duplicated them at substantial cost. Adding a second platform-employed veterinarian to approve every order would also have created another queue, without evidence that the extra review improved routine decisions. Neither alternative solved the gap we had identified.⁵

In our permissions model, medicine class determined which named professional could act and which actions were permitted. Some classes required a veterinarian’s decision. Others allowed a named assistant or technician to verify and release under veterinary direction, referring doubtful cases to the veterinarian. The prescribing clinician could be entirely outside the platform.⁶

A broad “clinic administrator” permission would not express those distinctions. Product and clinical teams need to agree on the mapping between medicine class, required evidence, authorized actor, and permitted action before engineering encodes it. Shared credentials would erase the individual accountability that the model depends on.

This operating model gives up direct control over review capacity and fulfilment. A product team should accept that dependency deliberately. The clinic’s working day, staffing, and ability to resolve exceptions become part of the service the customer experiences.

Build an order that can wait

Professional review introduces a period in which the customer has expressed a clear intention to buy, but the transaction cannot yet proceed. That interval needs to exist in the product’s state model.

In Platform Rx, checkout created a pending Rx line item and held payment and fulfilment. Approval released payment and allowed clinic dispensing. Rejection cancelled the line item and reversed the hold. The decision had to change what the transaction could do, rather than exist only as a status on a review screen.⁷

There was a third outcome we initially missed. Our first clinic interface offered approve and reject. Design partners began rejecting otherwise valid requests because a field was missing. We added a request-more-information action that kept the order open and its hold intact while the customer supplied the detail.⁸

An unanswered question needs an owner, a route back to review, and a defined effect on payment and fulfilment. Otherwise, a reviewer who is not ready to decide has to improvise around an interface that insists on a final answer.

The Platform Rx order-state model, including the clarification loop and the boundary before dispensing. Source: design record, Figure 2, page 5.

Before the clinic hands over the medicine, an order can be held or cancelled. After handover, changing its status cannot retrieve the medicine. I would use that boundary to decide which checks must prevent advancement and which failures require an operational response.

The corresponding record needs to connect the submitted evidence, the person who acted, their authority, the decision, and the subsequent payment and delivery events. A team investigating a failed order should be able to reconstruct one transaction, rather than reconcile competing accounts from support messages, clinic notes, and payment records.⁷

Examine what could bypass the workflow

Even a correctly enforced approval process offers no protection to an order that never enters it.

During catalogue onboarding, a clinic uploaded a medicine under a trade name that did not map cleanly to the product and ingredient reference data. The classifier assigned the wrong route. Had a medicine requiring review been treated as an ordinary product, it could have bypassed the Rx workflow before any professional saw the request.⁹

This changed how we approached classification. Clear records could be classified automatically. Conflicting or incomplete records remained unavailable for sale in a review-required state. A named veterinary user could confirm or correct the class, give a reason, and submit it for revalidation. The original value and correction were both recorded.

The two kinds of classification error had different consequences. A false positive added review friction to an ordinary product. A false negative could remove review from a regulated one. An overall accuracy number would conceal the distinction the launch decision depended on.

A review of the control should therefore include the inputs that determine whether it runs at all. The classification corrections also gave us labelled data for improving the rules later, without making that improvement a prerequisite for launch.⁹

Measure the outcome and the capacity it consumes

An approval rate is an especially poor headline measure for this product. It can improve because requests are better prepared, but it can also reward more permissive decisions. It says nothing about whether the customer received the medicine.

We used Monthly Compliant Rx Orders. An order counted when delivery was complete and the required evidence, approval, permitted dispensing action, and payment-release event existed. Submissions and approvals remained useful diagnostic measures, but neither could stand in for the completed outcome.¹⁰

That definition also makes it easier to locate the next product problem. Incomplete evidence points toward intake or clarification. Slow decisions point toward the review process and its capacity. Approval followed by failed payment release points toward transaction control. Late or incorrect delivery points toward fulfilment. Each measure should help the team decide where to intervene.

A digital acquisition channel can generate work faster than a clinic can review it. If demand outruns that capacity, a successful campaign can lengthen the wait for everyone. Automated refills can produce the same problem. We deferred them while monitoring decision time and workload per approver.¹¹

For this model, I would treat review capacity as part of the product’s supply. A medicine being in stock is insufficient when there is no authorized person available to complete the request within the promised service window. Expansion decisions need to account for both.

Launch a complete transaction at limited scale

The dependency between these parts changes how I would scope a first release. A small catalogue and a few participating clinics can limit exposure while preserving the complete journey. Omitting a required approval or the record of who gave it leaves the journey incomplete at any scale.

We used manual onboarding and prescription review, and deferred automated extraction and deep integration with clinic systems. Those choices cost time and effort, but the order could still be completed through the required process. They let us test the operating model before investing in its more expensive conveniences.¹²

The pilot needed to test two different things. Engineering tried to advance orders without the evidence, permissions, or records they required. Clinics tested whether real staff could use the workflow. In one engineering test, a prescription without a dosage was returned for clarification, an unauthorized approval attempt was refused, and the assigned veterinarian could complete the decision. Any path ending in premature fulfilment, unauthorized approval, or a missing decision record blocked launch.¹³

The release decision also needs a response to failure. We set stop conditions in advance, including pausing new Rx intake for an affected clinic or medicine class when a gate was breached. That made the response part of the operating agreement before growth created pressure to keep accepting orders.¹⁴

Our six-week pilot was followed by expansion in waves, after targets held for four consecutive weeks without a gate breach. The first 90 days produced about 800 compliant deliveries, with 90% of decisions recorded within 18 hours and roughly 96% of approved orders due for delivery meeting the two-day promise from approval, in the approved medicine, strength, and quantity. No incidents or guardrail breaches were recorded in that period. These results supported expansion of the workflow we had tested; they did not measure better clinical outcomes or establish performance at substantially greater scale.¹⁵

One capability I would bring forward is specialist operations. General seller support did not initially have the clinical vocabulary the service required. We added clinical runbooks and direct veterinary escalation. A product that pauses correctly still needs someone capable of resolving the reason for the pause.¹⁶

What this makes possible

There is a promising ambition in making repeat access progressively easier. Information can travel with the customer’s request, uncertainty can reach the right person, and a resolved question need not be asked again without a reason. Over time, that could free more of the clinic’s effort for the decisions that genuinely require its attention.

I would build toward that future by watching where people still have to reconstruct context or coordinate the next step themselves. The owner should be able to tell whether the clinic is reviewing the request, what information is missing, and when the approved medicine will arrive. They should not have to understand how the clinic’s approvals, payment system, and delivery operation fit together just to obtain the next refill.

Source notes

This essay draws on the author’s Platform Rx product and system-design record, August 2026. The examples and reported results come from that account. Recommendations and broader implications are the author’s interpretation of the case, not a jurisdiction-independent clinical or legal specification.

Design record, page 1, “Problem statement.” Back to reference 1
Design record, page 1, “Solution” and footnote 2. Back to reference 2
Design record, page 7, “User Segmentation and Initial Focus”; pages 6–7, “Ecosystem Players and Product Rationale.” Back to reference 3
Design record, page 2, Rx intake and class-based routing; page 8, “Convenience vs evidence sufficiency.” The discussion of evidence reuse also draws on Figure 3, page 5, and the prescription-reuse guardrail on page 3. Back to reference 4
Design record, page 4, “Operating-Model and Solution Choice.” Back to reference 5
Design record, page 2, class-based authorization; page 6, prescribing and dispensing roles; page 9, credential-misuse risk. Back to reference 6
Design record, page 2, transaction controls and audit; Figure 2, page 5. Back to reference 7 Back to reference 7-2
Design record, page 2, design-partner testing and the request-more-information change. Back to reference 8
Design record, page 9, “From Pilot Evidence to a V1 Control.” The comparison of error consequences is documented there; the implication for evaluating aggregate accuracy is the author’s reasoning. Back to reference 9 Back to reference 9-2
Design record, page 1, “What success looked like” and footnote 3; page 3, metric hierarchy and rejected North Star candidates. Back to reference 10
Design record, page 3, decision-time and review-burden measures; page 8, automated-refill deferral; page 9, customer-growth versus review-capacity trade-off. Back to reference 11
Design record, page 2, V1 scope; page 8, deferred capabilities and breadth-versus-launch-confidence trade-off. Back to reference 12
Design record, page 2, engineering validation and design-partner testing. Back to reference 13
Design record, page 3, hard guardrails and predefined responses. Back to reference 14
Design record, page 2, “Delivery, Results, and Retrospective”; page 1, footnote 4, defines the two-day on-time-and-in-full delivery measure from approval. The reported measures concern transaction performance, not comparative clinical efficacy. Back to reference 15
Design record, page 2, specialist veterinary operations and retrospective. Back to reference 16