Do DTC telehealth brands need an EHR? EHR vs. clinical infrastructure
"Which EHR should we use?" is one of the most common questions from founders launching care programs. It usually means: where do the charts live, who is the legal record-keeper, and what do clinicians work in? An EHR is one answer — and for most DTC programs, the wrong-shaped one.
Photograph via UnsplashAn EHR is a clinician-facing charting and billing system built for clinic workflows: appointments, encounters, claims. A DTC telehealth program runs an e-commerce-shaped loop — intake, async review, prescription, fulfillment, subscription refills — and needs a clinical system of record that speaks that shape: API-first, event-driven, integrated with pharmacy and payments. What matters legally is that a compliant medical record exists (complete, retained, exportable, under BAA), not that it lives in a product labeled EHR. Buy a traditional EHR when you bill insurance at scale, need e-ordering integrations only EHRs have, or employ clinicians who live in one all day; otherwise use infrastructure whose record is built in.
What an EHR is actually for
Electronic health record systems grew up inside clinics and hospitals: scheduling, room-based encounters, problem lists, and above all billing — CPT-coded claims through clearinghouses to payers. They are superb at being the clinician’s all-day workspace and the compliance ledger for insurance medicine. Every design decision assumes an appointment at its center.
What a DTC program actually runs
A DTC program is a loop, not a calendar: a patient converts on your site, completes intake, a clinician reviews async, an eRx routes to a pharmacy, a box ships, and a subscription drives monthly check-ins and refills. The unit of work is an event, not an appointment; the integrations that matter are pharmacy, labs, identity, and payments; and the patient experience lives in your product, not a portal. See inside a compounded GLP-1 order.
Side by side
| Traditional EHR | Clinical infrastructure | |
|---|---|---|
| Built around | Appointments and charts | Events and pipelines |
| Primary user | Clinicians and billers | Your product, plus a clinician review queue |
| Billing | Claims-native | Cash-pay-native; superbills from the record |
| Pharmacy | eRx to retail | Routed bench incl. compounding, with tracking back |
| Refill cycle | Manual re-encounter | Subscription-driven check-in → decision → order |
| Your front-end | Their portal | Your app, via API and webhooks |
| The record | The product | A by-product of the pipeline, exportable |
Whichever you choose, the record must stand alone
Strip the labels away and the legal requirement is identical in both models: every encounter documented — who evaluated, what was reviewed, what was decided and why; every prescription linked to the encounter that justified it; consent versions attached; records retained for the state’s mandated period, often seven to ten years and longer for minors; and the whole thing producible per patient when a board, a patient, or a court asks. An audit trail showing who accessed and changed what rounds it out.
That is the checklist to run against any vendor demo, EHR or infrastructure: ask to see one patient’s complete record exported, then ask what happens to it if you leave. A system that generates the record as a by-product of the pipeline passes the same test a chart-first system does — and the test, not the product category, is what your medical group is accountable for.
The questions that decide it
- Where does revenue come from? Cash-pay subscriptions → infrastructure. In-network claims at volume → an EHR (or both, split by line of business).
- Where do patients live? Your app and checkout → infrastructure. A portal you did not build is a portal you cannot optimize; see white-label telehealth.
- What do clinicians need? A review queue with the intake, history, and a decision to make — or a full charting environment? Most DTC clinical work is the former.
- Can you get the records out? Whichever model: API export, in the contract, tested. This is the switching cost; see how to switch.
Frequently asked questions
Is an EHR legally required to run a telehealth business?
No law requires software labeled "EHR." Laws require adequate medical records: complete documentation of each encounter, retained for state-mandated periods, available to patients and boards, protected under HIPAA. Any system that produces and retains that record compliantly satisfies the requirement.
What is the difference between an EHR and telehealth infrastructure?
An EHR is a workspace for clinicians and billers: charts, schedules, claims (see revenue cycle). Telehealth infrastructure is a pipeline for programs: intake, clinician review, eRx, pharmacy routing, refills, webhooks — with the medical record generated as a by-product of the pipeline. The first optimizes documentation; the second optimizes the patient loop.
When does a DTC brand actually need a traditional EHR?
When insurance billing is core (claims, eligibility, prior auth at volume), when you need integrations that only live in EHR ecosystems, or when you employ a large clinician staff whose whole day happens inside charting software. Hybrid models exist: infrastructure for the DTC loop, an EHR where payer workflows demand it.
Who owns the medical records in an infrastructure model?
The medical group is the legal custodian; the infrastructure stores records under BAA; your contract should guarantee export via API. Ask for export rights in writing regardless of which model you choose — it is the switching-cost question.
The telehealth tech stack in 2026: what you build vs. what you rent
Eight layers, a build/rent verdict for each, and where the engineering time actually goes.
Read the guide
The best white-label telehealth platforms in 2026: an honest comparison
Nine vendors sorted by model and fit — done-for-you operators, enterprise networks, developer platforms, and API infrastructure — with our bias disclosed.
Read the guide
Telehealth platform pricing in 2026: the four models and what they hide
Per-visit, platform-plus-usage, revenue share, and PMPM — how vendors charge, what the headline excludes, and how to model true cost at three volumes.
Read the guideFrom first call to first patient, in weeks.
A 15-minute intro call, sandbox credentials the same day, go-live in 3–4 weeks — new launches and existing patient bases alike.