How to build a telehealth platform, Part 1: the complete architecture

The seven layers

Strip the branding off any virtual-care company and the same stack appears. Some layers are the product; some are the medicine; the rest are plumbing that has to be right and is the same for everyone.

Layers 1 and 2: the product

The storefront decides who arrives and the patient experience decides whether they stay. Both are yours to design and both are where a brand differentiates: the quiz that qualifies someone in ninety seconds, the check-in that feels like a coach rather than a form, the status screen that answers “where is my medication” before anyone asks. Nothing regulated stops you from owning every pixel here, and the best programs do.

Two rules from layer 7 reach up into these layers. Marketing pixels cannot run on pages that handle health information — see HIPAA and your marketing stack — and informed consent has to be captured, versioned, and state-aware before anything clinical happens. Design for both from the first wireframe.

Layer 3: the clinical layer

This is the medicine, and it is the layer founders most underestimate. It is not “find some doctors.” It is a physician-owned professional entity where corporate-practice-of-medicine rules require one, a management services arrangement between that entity and your company, clinicians licensed in every state you sell into, collaborating-physician agreements for nurse practitioners where states require them, written protocols for every treatment, charting that stands up to a board, and an escalation path for red flags.

Standing this up from scratch is the eight-to-twelve-month part of a self-build, and it never stops needing attention: licenses lapse, states change modality rules, protocols need updating. Infrastructure vendors exist largely because this layer is the same for every brand and hard for each one.

Layer 4: prescribing and pharmacy

After a clinician signs, the prescription travels as an electronic message over the e-prescribing network to a pharmacy licensed to ship into the patient’s state, with controlled substances requiring EPCS-certified software and identity-proofed prescribers. The pharmacy choice depends on the medication: a compounding pharmacy for patient-specific compounded GLP-1s or peptides, an outsourcing facility for batch-made products, retail or mail-order for commercial brands. Cold-chain packaging for injectables, carrier integration, and delivery tracking round it out. Part 3 of this series covers this layer end to end.

Layers 5 and 6: labs and payments

Labs make hormone therapy, longevity, and cardiometabolic programs possible and are the same integration problem as pharmacy: order, fulfill, return results to a clinician, surface them to the patient. Payments are different — cash-pay subscriptions with dose changes, pauses, and refunds have real pricing logic that belongs to you, built on a payments provider rather than a healthcare vendor. See pricing GLP-1 subscriptions and refunds and chargebacks.

Layer 7: where the compliance lives

Compliance is not a layer you add at the end; it is properties of layers 3, 4, and 7 that have to be true at once. The medical group must be structured lawfully. Clinicians must be licensed where patients are. Each treatment must be lawful for the modality used in that state. Controlled substances must follow federal telemedicine rules and EPCS. Protected health information must sit under BAAs with access logged. Consent must be versioned. Identity must be proofed. The pharmacy must hold a license in the destination state.

The practical consequence: compliance travels with the infrastructure. If you buy layers 3 and 4 from a vendor that enforces state rules server-side, most of layer 7 comes with them, and what remains — your privacy policy, your marketing stack, your consent copy — is manageable. If you assemble those layers yourself, you own all of it. Our 50-state compliance checklist is the full list.

Build versus buy, by team

The reference architecture

On infrastructure the whole pipeline is two objects and a stream of events. A patient is created once, with the telehealth consent timestamp your app captured. An encounter — initial for a new clinical relationship, follow_up for a renewal or check-in — carries the intake your app collected to a licensed physician in the patient’s state. The physician approves or rejects; an approval produces prescriptions and a pharmacy order; every state change returns to your app as a webhook you answer with a GET.

POST /v1/oauth2/token      # client credentials → short-lived Bearer token
POST /v1/patients          # demographics, address, telehealth_consented_at, your external_id
POST /v1/encounters        # patient_id, encounter_type: initial | follow_up, intake_data

# a licensed physician in the patient's state reviews (AI has already prepared the case)

← webhook  encounter.approved    # GET /v1/encounters/{id} → prescriptions, orders[]
← webhook  order.processing      # the pharmacy has it
← webhook  order.completed       # fulfilled · days_supply starts the follow-up clock

Your product owns everything the patient sees and everything that happens on those events: the dashboard update, the message, the next check-in. Part 2 covers intake — the part of the encounter you design — and the second series in this journal covers the integration patterns in detail, starting with four ways to integrate Lithos.

Cost and timeline

Self-assembly of layers 3 through 7 commonly runs eight to twelve months and past two hundred thousand dollars before the first patient, most of it legal structure, clinician recruiting, e-prescribing certification, pharmacy contracting, and compliance work that produces no product. Building layers 1, 2, and 6 on infrastructure that already runs the rest puts first patients three to four weeks out, with clinical costs starting when patients do. The full breakdown is in what it really costs to launch and the week-by-week plan in the launch timeline.

Five mistakes to design out early

1. Treating intake as a form. It is a clinical instrument; its structure decides how fast clinicians decide. Part 2.
2. Choosing a pharmacy before choosing a routing rule. Licensure by state, medication type, and cold chain decide the pharmacy per order, not a single contract.
3. Polling for status. Clinical events happen on human time. Build on webhooks from day one.
4. Marketing pixels on health pages. The most common HIPAA failure in DTC telehealth, and the easiest to avoid at wireframe stage.
5. Assuming one state is all states. Modality rules, pharmacy licensure, and re-evaluation intervals differ; the architecture has to carry state as a first-class field.

Frequently asked questions