Under the hood
It isn’t a shopping cart. It’s a regulated, multi-party medical pipeline.
What a patient experiences as six 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
Six patient steps. A dozen regulated hand-offs.
Each step is a hand-off between a different system, partner, and regulator. 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.
See a doctor
A telemedicine visit with a licensed provider.
Behind it
Routed to a provider licensed in the patient’s state.
Prescribed
If appropriate, the doctor writes a prescription.
Behind it
E-prescription routed to a partner pharmacy in the patient’s 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 over months.
Behind it
The whole cycle re-runs for every refill — nothing can be dropped.
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.
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.
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; controlled-substance e-prescribing (EPCS) runs under DEA and state rules; cards are tokenized client-side so card data never touches us — SAQ-A scope, not full PCI-DSS. (unconfirmed claim — pending verification: PCI scope (SAQ-A), WORM audit log & PAN-handling wording — confirm with counsel before launch)
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 API and MCP.
We built, operate, and audit the hard part. Your agents drive it with a few calls.