The Telehealth Tech Stack, Mapped: Every Layer From Click to Doorstep

What are the nine layers of the business?

Before any software gets evaluated, a telehealth company has to be assembled, and the assembly has a repeatable shape. Nine layers, in the rough order founders meet them: the entity and legal structure (in corporate-practice-of-medicine states, a clinician-owned professional entity plus a management company; our MSO guide maps it), the clinician supply (an operated medical group, a network vendor, or your own hires; our clinician-network guide explains the models and our clinician network directory profiles 21 vendors), the software (the eight-layer stack the rest of this page walks), and the pharmacy relationship (the 503A/503B chassis question and the counterparties; our compounding guide and pharmacy directory cover both).

Then the layers that turn it from a clinic into a business: payments (high-risk underwriting and subscription mechanics; the payments guide), labs and diagnostics where care lines need them (ordering rails, at-home kit platforms, phlebotomy networks; our labs-layer guide walks how the four pieces assemble and what they cost, and the labs directory maps 21 vendors with the layer's remarkable rename churn dated), the compliance function (certification, claims discipline, state rules; the LegitScript pillar and the compliance cluster), the marketing machine (certification-gated ads, owned audience, content; the advertising guide), and operations (the org you actually need at each stage and the numbers it should watch; the org-charts guide and the KPI reference).

Two honest observations from mapping this category all year. First, the expensive layers are rentable now: clinicians, pharmacy, software, and much of compliance can be assembled from vendors or arrive together on an operated platform, which is why the entity, audience, and operating discipline are where founders actually differentiate. Second, every layer has a vendor category, but the seams between layers do not: whoever holds the seams (you, an assembled vendor set, or one operated platform) holds the launch timeline. That is the same seam lesson the software stack below teaches, one level up.

• 1. Entity & legal: the CPOM-aware structure, built per state (MSO guide)
• 2. Clinicians: employed, network, or operated medical group (clinician-network guide + directory)
• 3. Software: the eight-layer stack below
• 4. Pharmacy: 503A/503B chassis + counterparties (compounding guide + pharmacy directory)
• 5. Payments: high-risk underwriting + subscription mechanics (payments guide)
• 6. Labs: ordering rails, at-home kits, phlebotomy (labs-layer guide + directory)
• 7. Compliance: certification, claims, state rules (LegitScript pillar)
• 8. Marketing: certification-gated ads + owned audience (advertising guide)
• 9. Operations: the org and the numbers (org-charts guide + KPI reference)

The nine layers are the diligence checklist for any 'launch a telehealth business' pitch, ours included: make every vendor and every plan name which layers it covers, which it leaves you, and who holds the seams between them.

Layers one and two: what do the storefront and intake do?

The storefront is the layer founders overestimate, because it looks like e-commerce: product pages, a cart, a checkout. The healthcare differences are structural, not cosmetic: required disclosures on every selling surface, claims discipline in the copy, and the handoff into a clinical flow instead of a fulfillment queue. Standard e-commerce platforms can host the front (a Shopify storefront over a telehealth backend is a real pattern), but the moment prescription products enter, the payment and clinical layers below stop being optional.

The intake engine is the layer founders underestimate, and it's the heart of the machine. A real one is a clinical instrument: branching medical questionnaires per condition, disqualification logic that stops unsafe cases before checkout, state-aware routing (the per-state modality and prescribing rules our state guide covers, encoded as software), identity verification, consent capture, and photo upload where the protocol needs it. It's also where conversion lives, so it's simultaneously a medical document and a funnel, and both disciplines have to sign off on every question. Building one well per condition is weeks of clinical-plus-product work; EmbedCare's runs 160+ conditions on one engine, which is the kind of accumulation a from-scratch build is racing against.

The intake engine is where medicine, law, and conversion meet in the same form fields. It's the single highest-leverage build-or-buy decision in the stack.

Layers three and four: where do records and prescriptions live?

Behind intake sits the clinical record: the EHR or EHR-like system where clinicians review cases, document encounters, message patients, and where the legal medical record lives. Telehealth programs need less than a hospital EHR and different things than most of them offer: asynchronous review queues, protocol templates per care line, state-license-aware task assignment, and audit trails. Teams choose between healthcare-API platforms, lightweight EHRs, and purpose-built internal tools; what's non-negotiable is that the record is real, retained per state rules, and produced on demand when a board or reviewer asks.

Prescription rails are their own layer because e-prescribing is a regulated network, not an API call you improvise: prescriptions travel over certified eRx networks to pharmacies, with additional requirements (like EPCS, electronic prescribing of controlled substances) if your care lines touch controlled medications. In practice teams integrate an eRx-capable EHR or a prescribing API rather than certifying anything themselves; the diligence question is whether the rails reach the pharmacies you actually use, which is where the next layer begins.

Layer five: how does pharmacy routing work?

This is the layer generic software maps miss entirely, and for compounded-medication programs it's the moat. Each order must route to a pharmacy that is licensed for the patient's state, stocks or compounds that formulation, and can meet the ship date; the router has to handle license coverage, catalog availability, cold-chain requirements, backorders, and transfers when a pharmacy drops a state. Under it sits the actual pharmacy relationship layer: the 503A/503B chassis question, testing documentation, and integration quality, which our compounding guide covers as its own diligence subject.

Programs that treat fulfillment as 'the pharmacy's problem' end up with support tickets as their routing layer. Programs that win treat delivery like the product: order status flowing back into patient comms, refill timing driving the retention engine, and a network of integrated pharmacies so no single pharmacy outage pauses the brand.

Layers six and seven: how do payments and messaging work?

Healthcare billing is a specialty, not a plugin: the high-risk merchant classification and certification-gated underwriting we cover in the payments guide, plus subscription mechanics tuned for medicine (dose-based pricing, pauses for clinical holds, proration) and the revenue-defense machinery (network card updaters, decline-aware retries, dunning, chargeback responses with clinical context). Bolting a generic subscription library onto a telehealth catalog works right up until the first underwriting review or the first involuntary-churn month.

Patient communications is the retention engine wearing a compliance vest: onboarding sequences, refill reminders, clinician-message notifications, winbacks. Two constraints separate it from normal lifecycle marketing: consent (telemarketing and texting rules are enforced, and health context raises the stakes) and content discipline (a refill reminder can acknowledge care exists; an ad pixel can't see it, which is the boundary the pixels guide maps). The teams that get this layer right treat message content as regulated copy, not growth-team freestyle.

Layer eight: what holds the compliance layer together?

The last layer isn't a product; it's a property of all the others: BAAs with every vendor that touches patient data, access controls and audit logs, consent-gated analytics on marketing surfaces and none behind intake, state rules encoded in routing, claims discipline in every rendered sentence, and the paper trail (the state matrix, the licensure records, the pharmacy credentials) that certification and underwriting reviews ask for. Compliance retrofitted after launch costs multiples of compliance designed in; the scanner exists because the website slice of this layer is checkable in a minute.

And then the glue: the eight layers exchange state constantly (intake outcomes gate checkout, prescriptions gate fulfillment, delivery events drive comms, refunds touch the clinical record), and integration seams are where patient experience actually breaks. When you evaluate any platform, ask to see the seams: what happens to the subscription when a clinician declines, to the shipment when a card fails, to the record when a patient cancels. Demos show layers; seams show engineering.

Nobody's differentiation is having eight layers; everyone eventually has them. Differentiation is how well the seams hold when a card declines, a pharmacy drops a state, and a clinician says no, all in the same order.

Do you build, assemble, or run on an operated platform?

Three honest paths. Building from scratch buys maximum control and costs the most time: teams that have done it commonly describe a year or more of engineering before feature parity with day one of an assembled stack, and the clinical-content accumulation (protocols, intake logic per condition) is the part that resists shortcuts. Assembling from healthcare APIs and vendors is faster and shifts the work to integration and vendor management: you own the seams, and the seams are the hard part. Running on an operated platform trades some configurability for speed and inherited compliance: the layers and seams arrive already built and already certified-adjacent, and your team spends on brand and audience instead.

The right answer tracks what your company is actually for. If the software is the company (a novel care model, a technology thesis), build or assemble. If the brand and audience are the company and telehealth is the engine, operating the stack yourself is overhead wearing a strategy costume; that's the case EmbedCare exists for, with every layer above run as one platform under your brand. Whichever path, use this map in diligence: make any vendor or plan show you all eight layers and name which ones are yours to operate.