Under the hood
It isn’t a shopping cart. It’s a regulated, multi-party medical pipeline.
What a patient experiences as a few simple steps is, underneath, a chain of hand-offs between doctors, pharmacies, payment processors, and regulators. We’ve already built, operated, and audited every one — and we expose it to your agents as a few API and MCP calls. That’s the build-vs-buy question in one sentence: you don’t want to own this.
The domain we’re engineering for
Eight steps the patient sees. A dozen hand-offs they don’t.
Every card below is a hand-off between a different system, partner, and regulator — and a place the journey can break. We’ve mapped every one.
Qualify
A patient answers a medical intake to see if they’re eligible.
Behind it
Clinical eligibility rules, per medication and per state.
Pay
They check out for their therapy or subscription.
Behind it
Tokenized payments through each client’s own merchant — we hold no card data.
Verify identity
The patient confirms who they are before the visit.
Behind it
Third-party ID verification — a legal gate for a real prescription.
See a doctor
A telemedicine visit with a licensed provider.
Behind it
Routed to a provider licensed in the patient’s state.
Labs
select RxSome therapies require bloodwork before the doctor prescribes.
Behind it
A lab order and results gate the prescription — only for medications that need it.
Prescribed
If appropriate, the doctor writes a prescription.
Behind it
E-prescription routed to a partner pharmacy — with prescribing rules enforced per medication and per state.
Delivered
Medication is dispensed and shipped to the patient.
Behind it
Fulfillment pharmacy, dispense status, and shipment tracking.
Follow-up & titrate
Follow-up visits adjust the dose up or down over months.
Behind it
The whole cycle re-runs for every refill — nothing can be dropped.
Each follow-up re-enters at the doctor visit (Step 04) — the cycle repeats for the life of the therapy.
Why it’s hard
Every step is a hand-off between systems, partners, and regulators. Lose one and you lose a patient — or a license. The architecture exists to make that impossible.
The order saga
The whole journey, collapsed into one durable function.
A single durable workflow drives every order — its state is persisted after each step and survives worker crashes and deploys.
ChargePayment
RouteProvider
ScheduleVisit
Await visit
RecordRx
SubmitERx
Await shipment
Await follow-up
On unrecoverable failure, a plain try/catch unwinds the whole workflow.
RefundPayment
reverse the charge
CancelOrder
release the reservation
NotifyPatient
explain & offer next steps
Durable state
Automatic retries
Idempotency keys
Durable timers
Net effect
The patient journey is a single durable function — it cannot lose state, double-charge, double-prescribe, or strand a patient mid-flow. You don’t operate any of it: your agents start the journey with one call, and the platform guarantees the rest.
Clinical authority, sealed
Dose changes are clinical decisions, not funnel logic. On Purple Label, titration is authorized by the treating clinician and recorded as a clinical event on the patient's timeline — marketing can shape the journey, but it can never write the dose. Elsewhere in this market, funnel builders can route a patient into a titration schedule from a quiz answer. We consider that a compliance defect, not a feature.
The journey, as a read model
Every order exposes a versioned status —RECEIVED → VISIT_SCHEDULED → RX_WRITTEN → SHIPPED → REFILL_DUE — as API reads and webhook events, so your storefront and your agents always know exactly where a patient is.
The event backbone
Database-per-service. The event log is the source of truth.
Each service owns its data and publishes domain events. The ordered event stream — not any one database — is authoritative.
Producers — each owns its database, publishes domain events
Eligibility
Order & subscription
Payments
Clinical
PHI · stricter auth
Pharmacy
Tenant & onboarding
Partner adapters
Event bus
System of recordOrdered domain events · at-least-once delivery · idempotent consumers · dead-letter queues.
Consumers
Saga orchestrator
Audit & event store
Analytics & CQRS
Notifications
Loose coupling
One source of truth
Audit for free
Decision rationale
Why this stack — optimized for correctness and compliance.
Every choice is made to keep the patient journey correct, the data isolated, and the partners swappable. A glimpse of the reasoning, not the full blueprint.
Cloud & runtime
Managed, BAA-covered cloud
Stateful workers run the saga; serverless data scales idle tenants toward zero cost.
Identity
Org-per-tenant identity
Each tenant is an organization; each agent gets its own revocable machine client; entitlements change at runtime without re-issuing tokens.
Data
DB-per-service + transactional outbox
“Change state and emit event” is atomic in one local transaction — no distributed transactions. The event log is authoritative; read models rebuild by replay.
Orchestration
Durable saga + choreography
The workflow survives restarts; activities auto-retry; idempotency keys give at-most-once charges and prescriptions; compensation is a try/catch.
Messaging
Managed event bus
Schema registry and archive/replay built in; one queue and dead-letter queue per consumer; idempotent consumers keyed on a processed-event table.
Catalog
One catalog, many brands
Offerings, pricing, and programs are data bound to your brand — not thousands of SKUs cloned per storefront. Change a program once; every surface that consumes it updates.
Multi-tenancy
Row-level security
The database enforces isolation, not app code — a missing clause can’t leak another tenant’s data. Every tenant runs on the same audited floor; Enterprise can move to a dedicated silo with its own encryption keys and data residency. Same model, more sovereignty.
Partners
Routing + anti-corruption adapters
Rules pick the partner by state, therapy, and cost; each adapter normalizes one partner to our model, so swapping a pharmacy, processor, or network never ripples into core.
Compliance
PHI-segregated, PCI-minimized
PHI is field-encrypted; an append-only audit log is compliance evidence by construction; and cards are tokenized client-side, so card data never touches our servers.
Delivery
Contract-first
Generated stubs and mocks let agents build against a contract before the service exists; contract tests catch breaking changes; semver’d events avoid lockstep deploys.
And you get all of it
The whole pipeline — as an API today, MCP connectors at launch.
We built, operate, and audit the hard part. Your agents drive it with a few calls.