The Telehealth MVP Playbook for US Founders: State Licensure, ePrescribe, Eligibility, and the UX That Actually Works

In March 2023, a women’s health founder in Los Angeles came to us with a product that had been live for four months. $4.2M raised. A beautifully designed telehealth platform connecting patients with OB-GYNs for virtual consultations. Her NPS from patients was 71. Her provider retention was strong. Her board was happy.

Then her healthcare attorney sent a memo.

Three of her seventeen contracted providers were seeing patients in states where those providers were not licensed. The platform had no licensure verification logic, it matched patients to available providers by specialty and time slot, not by the provider’s active state licenses. A provider licensed in California and Nevada had seen patients in Arizona, Oregon, and Colorado through the platform. The platform had facilitated unlicensed medical practice in three states.

The financial exposure was significant. The reputational exposure was worse. She pulled those providers from interstate consultations immediately, refunded the affected patients, and engaged a healthcare attorney at $650/hour to assess the liability. She has not told me the final number. What she told me was that the licensure verification logic would have cost $18,000 to build correctly from the start.

Every telehealth product is, at its core, a licensure management problem wrapped in a video call. The founders who understand this build it right. The founders who think telehealth is a video call with a medical form attached pay for that misunderstanding eventually.

Eight Things Telehealth Founders Get Wrong Before They Build

• Wrong #1: “Telehealth is just a video call.”

A telehealth consultation is a medical encounter. It is subject to the same state medical practice laws, the same prescribing regulations, the same documentation requirements, and the same liability exposure as an in-person visit. The video call is the delivery mechanism. The regulated product is the medical encounter that happens through it.

• Wrong #2: “Our providers can see patients anywhere in the US.”

No. A physician is licensed to practice medicine in specific states. Seeing a patient located in a state where the physician is not licensed, even via video, is the unlicensed practice of medicine in that state, regardless of where the physician is physically located. Your platform must enforce this. Every patient-provider match must verify that the provider holds an active license in the patient’s state.

• Wrong #3: “The Interstate Medical Licensure Compact covers everyone.”

The IMLC covers 40+ states and makes it faster for physicians to obtain licenses in additional IMLC member states. It does not eliminate the licensing requirement, it streamlines the application process. A physician must still hold an active license in each IMLC member state where they see patients. PSYPACT covers psychologists across 42 states. The Counseling Compact covers licensed professional counselors. Nurse practitioners, physician assistants, and therapists have their own compact frameworks, each with different member states and different requirements.

• Wrong #4: “We’ll add ePrescribe later.”

If your clinical use case involves prescribing, and most telehealth use cases eventually do, ePrescribe is not a feature you add later. The DEA’s telemedicine prescribing rules changed significantly in 2025 following the COVID-19 public health emergency expiration. The current framework for controlled substance prescribing via telehealth requires an in-person evaluation in most circumstances unless specific exceptions apply. Build prescribing capability with the current regulatory framework in mind, not the pandemic-era rules.

• Wrong #5: “Insurance billing is a phase two problem.”

Maybe. But the decision of whether you are a cash-pay platform or a payer-billing platform is an architecture decision, not a business model decision you can defer to phase two without engineering consequences. A cash-pay telehealth platform and a payer-billing telehealth platform have fundamentally different data models, compliance requirements, and integration needs. Decide in discovery. Architect accordingly.

• Wrong #6: “HIPAA-compliant video means we just use Zoom.”

Standard Zoom does not include a HIPAA BAA. Zoom’s Healthcare plan does, but it requires specific configuration and the BAA covers only specific Zoom services. The consumer Zoom your provider is already using on their laptop is not covered. Your telehealth platform must use a video infrastructure provider that offers a HIPAA BAA and must ensure that providers use the platform-provided video interface, not their personal consumer video accounts.

• Wrong #7: “We don’t need to verify provider credentials, they provided their license number.”

A provider providing their license number is not the same as your platform verifying that the license is active, unrestricted, and valid in the patient’s state at the time of the encounter. Credential verification means querying state licensing boards, either directly via API or through a credentialing service like Medallion, Verifiable, or MD Verify, and storing the verification result with a timestamp. Self-reported license numbers are a starting point for verification, not verification itself.

• Wrong #8: “We can handle consent in the terms of service.”

Telehealth-specific informed consent is a distinct legal requirement in most US states, separate from your platform’s general terms of service. Many states require that patients explicitly consent to the telehealth modality, acknowledging that they understand they are receiving care via video rather than in person, that they have the right to refuse telehealth, and that the provider is licensed in their state. This consent must be obtained before the first encounter and documented in a way that can be retrieved if a licensing board or attorney requests it.

Is Your Telehealth Product Actually a Telehealth Product?

Before you build, define exactly what category of telehealth product you are building. The regulatory requirements, the data architecture, and the integration needs differ significantly across these categories.

• Synchronous telehealth (live video consultation):

The provider and patient interact in real time via video. This is the most common telehealth model. Requirements: HIPAA-compliant video infrastructure, real-time licensure verification, encounter documentation, ePrescribe if prescribing is in scope, consent workflow, provider scheduling and availability management.

• Asynchronous telehealth (store-and-forward):

The patient submits information, photos, questionnaire responses, medical history, and the provider reviews and responds asynchronously. Common in dermatology, ophthalmology, and certain primary care use cases. No live video required. Requirements: HIPAA-compliant file storage, structured intake forms with clinical data collection, provider review queue and response workflow, documentation of the asynchronous encounter, and, importantly, the same licensure requirements as synchronous telehealth. The provider must be licensed in the patient’s state even if they never speak to the patient in real time.

• Remote Patient Monitoring (RPM):

Covered in Guide 5. The provider monitors patient-generated health data from connected devices over time. Different reimbursement model (CPT codes 99453/99454/99457), different data architecture (time-series device data rather than encounter records), different provider workflow.

• Hybrid (synchronous + asynchronous):

Many modern telehealth products combine both models, an initial asynchronous intake followed by a synchronous video consultation for complex cases, or ongoing asynchronous monitoring between synchronous check-ins. The engineering complexity is additive. Plan for it in discovery.

• Mental health telehealth:

Carries additional regulatory considerations: 42 CFR Part 2 for substance use disorder, state-specific mental health parity laws, crisis intervention protocol requirements, and PSYPACT licensure compact for psychologists.

• Specialty telehealth:

Dermatology, cardiology, neurology, endocrinology, and other specialty telehealth products have specialty-specific workflows, documentation requirements, and in some cases specialty-specific regulatory frameworks (e.g., FDA requirements for AI-assisted diagnostic tools in dermatology or cardiology).

From a US founder call: “I spent three months scoping a telehealth platform before I realized I hadn’t decided whether it was synchronous or asynchronous. My engineer had built half of a live video infrastructure before we figured out that our dermatology use case was almost entirely asynchronous, photos and questionnaires, reviewed by dermatologists within 24 hours.

We rebuilt. It cost us eight weeks and $40,000. The question ‘synchronous, asynchronous, or hybrid?’ is the first question you answer in discovery, not the third month of build.”, Seed-stage specialty telehealth founder, Chicago.

The State Licensure Problem, And the Three Ways Founders Solve It

State licensure is the most underestimated engineering problem in telehealth. Here is the full picture.

The legal reality:

Medical practice is regulated at the state level in the United States. A physician, nurse practitioner, physician assistant, therapist, or any other licensed healthcare provider is licensed to practice in specific states. Practicing medicine, including via telehealth, in a state where the provider is not licensed is the unlicensed practice of medicine, a criminal offense in most states.

The patient’s location at the time of the encounter determines which state’s medical practice laws apply, not the provider’s location, not the platform’s headquarters. A provider in Texas seeing a patient in New York via video is practicing medicine in New York and must hold a New York license.

The engineering requirement:

Your platform must enforce licensure compliance at every patient-provider match. This means:

1. Every provider’s active licenses are stored in your system, state, license type, license number, expiration date.
2. Every patient’s location at the time of encounter is captured, not their billing address, their physical location at the time of the visit.
3. The patient-provider matching logic only surfaces providers who hold an active, unrestricted license in the patient’s state.
4. The license data is not self-reported and static, it is verified against primary sources and updated on a regular cadence.

The three approaches telehealth founders use:

Approach 1: Cash-pay, single-state, limited provider network Launch in one state with a small, fully credentialed provider network. Every provider holds a license in that state. No interstate matching logic needed in v1. Expand to additional states as the provider network grows and licenses are obtained. This is the right approach for pre-seed and early Seed founders who want to validate the clinical model before scaling the licensing complexity.

Engineering implication: simple state filter on provider matching. Credential verification for the single launch state. Fast to build, easy to maintain. The right v1 architecture for most early-stage telehealth startups.

Approach 2: Compact-based multi-state coverage Use provider licensing compacts to enable interstate coverage from launch. The IMLC allows physicians who hold a license in their principal state of practice to obtain licenses in other IMLC member states (40+) through an expedited process. PSYPACT allows licensed psychologists to see patients in 42 member states under a single authorization. The Counseling Compact, the Nurse Licensure Compact (NLC for RNs), and others cover additional provider types.

Engineering implication: the provider record stores each active compact authorization as a distinct license entry. The patient-provider matching logic checks compact membership for the patient’s state. You still need verification logic, compact membership does not eliminate the licensing requirement, it streamlines obtaining licenses in compact member states.

Approach 3: National coverage via credentialing service integration For platforms targeting national coverage from launch, integrate a credentialing service, Medallion, Verifiable, MD Verify, or Nursys for nurses, that performs primary source verification of provider credentials across all US states and provides ongoing monitoring for license status changes, disciplinary actions, and expirations.

Engineering implication: API integration with the credentialing service, webhook handling for real-time license status updates, automated suspension of interstate encounters when a provider’s license in a given state lapses or is restricted. The most robust approach. Also the most expensive, credentialing services charge per provider per state per verification, with ongoing monitoring fees.

EB Index 2026: Across 32 telehealth products we have shipped for US founders since 2020, 19 launched with Approach 1 (single-state), 9 launched with Approach 2 (compact-based), and 4 launched with Approach 3 (national credentialing service). The 4 that launched with Approach 3 had the most complex builds and the highest pre-launch cost. They also had the fastest time to $1M ARR after launch, because national coverage was a selling point their competitors couldn’t match.

Red flag: Any telehealth product that matches patients to providers without a licensure verification step, even in a beta or “soft launch”, is facilitating potential unlicensed medical practice from Day 1. There is no beta exception to medical practice law. Build the licensure verification before you onboard your first real patient.

Compliance trap: Provider licenses expire. A provider who was licensed in 12 states when they onboarded may be licensed in only 9 states six months later if they let some licenses lapse.

Your system must track license expiration dates and alert, or automatically suspend, interstate encounters when a license expires. A static credential verification at onboarding is not sufficient. You need ongoing monitoring.

The 14-Question Telehealth Readiness Audit

Before your engineering team writes a line of code, work through these fourteen questions. Each one is an architecture decision or a compliance decision that is cheaper to make explicitly in discovery than to discover implicitly post-launch.

1. Is your product synchronous, asynchronous, or hybrid? This determines your video infrastructure needs, your data architecture, your provider workflow design, and your encounter documentation model.
2. Which provider types will practice on your platform? Physicians, nurse practitioners, physician assistants, therapists, psychologists, dietitians, pharmacists? Each provider type has its own licensing framework, its own prescribing authority, and its own compact structure. The engineering requirements differ by provider type.
3. Which states will you launch in, and do your providers hold active licenses in those states? Map your planned launch geography against your provider network’s actual license coverage. The gap between these two is your pre-launch licensing work.
4. Which licensing compact(s) apply to your provider types and patient states? IMLC, PSYPACT, Counseling Compact, NLC, APRN Compact, which ones are relevant for your provider types and your target geography? Which of your target states are members?
5. Will your platform facilitate prescribing? If yes, what categories of medications? Controlled substances or non-controlled substances only? The regulatory framework for telehealth prescribing of controlled substances under the DEA’s current rules (post-PHE expiration) is materially different from the pandemic-era flexibility. Get a healthcare regulatory attorney’s guidance on prescribing scope before you architect the ePrescribe integration.
6. Will you bill insurance or operate cash-pay? This is not a business model question you can defer. It is an architecture decision. Cash-pay and payer-billing require different data models, different compliance postures (payer billing adds HIPAA transaction standards, claim formats, and remittance processing requirements), and different provider workflow designs.
7. If billing insurance, which payers, and what are their telehealth-specific reimbursement policies? Telehealth reimbursement varies by payer and by state. Medicare’s telehealth coverage rules changed multiple times post-COVID. Medicaid telehealth coverage varies state by state. Commercial payer telehealth coverage depends on the specific plan. Payer policy research is a pre-build deliverable, not a post-launch discovery.
8. How will you verify patient identity before a telehealth encounter? Most state telehealth laws require patient identity verification before the first encounter. Some require it before every encounter. Options range from self-attestation (lowest friction, highest regulatory risk) to document verification with a service like Persona or Jumio (higher friction, stronger compliance posture).
9. How will you obtain and document telehealth-specific informed consent? Which states require explicit telehealth consent (most of them)? What does the consent document need to include? How will you store the signed consent in a way that can be retrieved for a licensing board inquiry five years from now?
10. How will you handle clinical emergencies during a telehealth encounter? A patient experiences a medical emergency during a video call. What does the provider do? What does the platform do? A clinical emergency protocol is a required element of a telehealth platform, it must be designed before the first encounter, not improvised during one.
11. How will you handle prescriptions for patients in states with specific telehealth prescribing restrictions? Some states have telehealth-specific prescribing restrictions that go beyond the federal DEA framework. Texas, for example, has specific requirements for the patient-physician relationship in a telehealth context that affect prescribing authority.
12. What is your encounter documentation model? Every telehealth encounter must be documented in a clinical note. Where does the note live, in your platform’s database, in the provider’s EHR, or in both? Who owns the clinical record, the platform or the provider? What is the retention period? (HIPAA minimum: 6 years. Many states require longer for medical records.)
13. What is your provider onboarding and credentialing workflow? How does a new provider join your platform? What documents are collected? How are credentials verified? Who approves a provider for clinical practice on the platform? How long does onboarding take? This workflow is a product feature, not a manual process, it must be designed and built.
14. What are your quality assurance and complaint resolution processes? State medical boards and malpractice insurers will ask these questions. A telehealth platform with no documented quality assurance process, no patient complaint resolution workflow, and no mechanism for reviewing clinical concerns is a regulatory and liability exposure.

HIPAA-Compliant Video Infrastructure, The Decision That Defines Your Stack

The video infrastructure decision is the most visible architecture decision in a telehealth product. It is also the one most founders make based on the wrong criteria, familiarity and price, rather than the right criteriHIPAA BAA coverage, reliability, clinical workflow fit, and scalability economics.

The non-negotiable requirement: Your video infrastructure provider must offer a HIPAA BAA and that BAA must cover the specific services you use for clinical encounters. A BAA that covers the provider’s general API but excludes recorded sessions is insufficient if you record encounters.

The options in 2026 and what we actually think about each:

• Daily.co

Our most common recommendation for early-stage telehealth products. BAA available on the Scale plan. Strong HIPAA posture, well-documented. Excellent React and React Native SDKs, fast to integrate. Room-based model maps cleanly to the appointment-based telehealth workflow. The waiting room concept is built in. Recording available with BAA. Pricing: starts at $0.00099/participant-minute for video, scales with volume. For a platform doing 500 telehealth visits per month at an average of 20 minutes per visit, that is approximately $9.90/month in infrastructure, before you add recording, transcription, or AI features.

Honest limitation: Daily.co’s maximum room size (for group telehealth) caps at lower participant counts than enterprise video infrastructure. For individual or small-group telehealth, this is not a constraint. For platforms doing large virtual care groups or community health sessions, evaluate participant limits carefully.

• Twilio Video

BAA available under the Twilio HIPAA BAA (enterprise agreement required). More flexible than Daily.co for complex multi-participant workflows. Slightly more engineering effort to implement, you build more of the room management logic yourself. Strong for platforms where the video workflow is deeply embedded in a custom clinical interface.

Honest limitation: Twilio Video’s roadmap has been subject to changes. Confirm current development trajectory and support commitment before a long-term architecture decision.

• Vonage Video (formerly OpenTok)

BAA available under enterprise agreement. Mature platform, strong broadcast capabilities for one-to-many telehealth scenarios (provider speaking to a group of patients). Solid for platforms where group sessions or virtual health education events are core to the product.

• Amazon Chime SDK

Covered under the AWS BAA for HIPAA-eligible services. Strong choice for products already deeply integrated into the AWS ecosystem, AWS Bedrock for clinical AI, Amazon Transcribe Medical for session transcription. The video infrastructure and the AI layer share the same BAA and the same compliance posture.

Honest limitation: More engineering effort than Daily.co or Twilio to implement basic telehealth video workflow. The Chime SDK gives you primitives, you build the product.

• Zoom for Healthcare (Zoom’s HIPAA-specific plan)

BAA available under the Zoom for Healthcare plan specifically. The standard Zoom Business plan does not include the HIPAA BAA. If you are considering Zoom, you must use the Healthcare plan and configure it correctly per Zoom’s HIPAA guidance. Providers who use their personal Zoom accounts for telehealth sessions facilitated by your platform, even if the appointment is booked through your platform, are not covered by your platform’s BAA.

Honest recommendation: Zoom for Healthcare is a reasonable choice for provider-facing scheduling and communication workflows. For a telehealth product where the video interface is embedded in your patient-facing app, Daily.co or Amazon Chime SDK give you more control over the patient experience.

What we’d cut: For a HIPAA-ready Lean Telehealth App with a budget under $150K, we default to Daily.co. Fast to integrate, clear BAA, reasonable pricing at early stage volume, and the waiting room and recording features cover 90% of what an early-stage telehealth product needs. The remaining 10%, custom AI transcription, complex group session management, deep EHR video embedding, we evaluate when we actually need it, not at the architecture decision stage.

From a US founder call: “I spent six weeks evaluating video infrastructure. Daily.co, Twilio, Vonage, Amazon Chime, Zoom Healthcare. I talked to eight engineers. I read every BAA. You know what the right answer was? Daily.co, which was the first thing Mayank’s team recommended in Week 1. The evaluation cost me six weeks I did not have. The decision was already clear.”, Series A telehealth founder, Boston.

The Telehealth Data Architecture, What You Store, What You Don’t

A telehealth platform touches more ePHI data types than most healthcare products. Every data type is a compliance decision. Here is the complete map.

• Patient demographic data

Name, date of birth, address, phone, email, insurance ID. All PHI under the 18 HIPAA identifiers. Stored in the patient profile. Encrypted at rest. Access: patient (self), care coordinator, billing, provider (treating only).

• Patient location at time of encounter

The patient’s physical state at the time of each telehealth encounter, not their home address, their actual location. Required for licensure enforcement. Stored per encounter, not per patient profile. If a patient sees a provider while traveling, their location for that encounter is the state they were in when the call happened, which may differ from their home state.

• Provider credential data

License numbers, license states, expiration dates, verification timestamps, compact membership, NPI number, DEA registration number (if prescribing), board certifications, malpractice insurance. Not ePHI, provider data, but highly sensitive and central to your licensure compliance posture.

• Appointment and scheduling data

Appointment time, provider, patient, appointment type, status (scheduled, completed, cancelled, no-show), duration. PHI because it contains information about a patient receiving healthcare. Stored in the scheduling module. Encrypted. Audit logged.

• Encounter documentation (clinical notes)

The clinical note documenting the telehealth encounter, chief complaint, history, assessment, plan, diagnoses (ICD-10 codes), prescriptions issued. This is the most sensitive ePHI in your system. Access: treating provider (read/write), supervising provider where applicable, patient (read, under HIPAA right of access), billing (diagnosis codes and CPT codes only, not full narrative notes).

Retention: HIPAA minimum 6 years. State medical record retention laws vary, California requires 10 years from the date of service for adult patients. Build your retention policy around the most restrictive requirement that applies to your patient population.

• Session recordings (if applicable)

Audio and/or video recordings of telehealth encounters are ePHI. Most telehealth platforms do not record sessions by default, recording introduces significant ePHI storage, consent, and retention complexity.

If you record: explicit patient consent required before recording begins (distinct from the general telehealth consent), BAA confirmation for your recording storage provider, encryption at rest, clear retention and deletion policy (most platforms retain for 30–90 days and then auto-delete unless the recording is clinically indicated), and audit log for every access to a recording.

Honest recommendation: Do not record sessions in your MVP unless recording is core to your clinical model (e.g., an AI clinical scribe that requires the audio for transcription). Recording adds engineering complexity, compliance exposure, and storage cost that most early-stage telehealth products do not need.

• Session transcripts (AI-generated)

If you use AI transcription, Amazon Transcribe Medical, Nuance DAX, or a similar service, the transcript is ePHI and requires BAA coverage for the transcription service, encrypted storage, and clear retention and deletion policy. Transcripts that are used only to generate a clinical note (not retained themselves) have a smaller compliance footprint than transcripts retained as a permanent record.

• Prescription data

Prescription details, medication, dosage, frequency, prescriber, patient, date, pharmacy, are ePHI. If you integrate ePrescribe, the prescription data flows through your ePrescribe integration partner (Surescripts, DrFirst, or DoseSpot, all offer HIPAA BAAs). The prescription record in your system is ePHI and must be treated accordingly.

• Billing and claims data

If billing payers: diagnosis codes (ICD-10), procedure codes (CPT/HCPCS), claim status, remittance data, explanation of benefits. All PHI. HIPAA transaction standards (X12 837 for claims, 835 for remittances, 270/271 for eligibility) apply if you are submitting claims electronically, which you are.

• Chat and messaging data

In-platform messaging between patients and providers, whether pre-appointment intake questions, post-visit follow-up messages, or secure messaging, is ePHI if it contains health information. HIPAA-compliant messaging (not standard SMS, not standard email, not consumer chat platforms without BAA) is required for any in-platform communication that contains ePHI.

What we’d cut: For a HIPAA-ready Lean Telehealth MVP, we recommend starting with: patient profile, appointment scheduling, video encounter, and post-encounter clinical note. That is the minimum viable clinical workflow. Add ePrescribe in sprint 2. Add insurance billing in sprint 3. Add AI transcription and SOAP note generation in sprint 4. Each addition expands the ePHI surface area, add them deliberately, not all at once.

ePrescribe Integration, The Feature Founders Underestimate Most

Prescribing is in scope for most telehealth platforms eventually. Almost every founder underestimates how complex it is to implement correctly in 2026.

The regulatory context as of 2026:

The COVID-19 public health emergency ended in May 2023. During the PHE, the DEA granted broad flexibilities allowing providers to prescribe controlled substances via telehealth without a prior in-person evaluation. Those flexibilities expired. The DEA has issued new telemedicine prescribing rules under 21 CFR Part 1306, the framework is more permissive than pre-pandemic rules but more restrictive than PHE-era rules.

The current framework (as of 2026, confirm current status with a healthcare regulatory attorney before building):

• Non-controlled substances: Can generally be prescribed via telehealth without a prior in-person evaluation, subject to state-specific requirements and the standard of care.
• Controlled substances (Schedule III–V): Under the DEA’s telemedicine prescribing framework, certain Schedule III–V substances (including buprenorphine for opioid use disorder) can be prescribed via telehealth under specific conditions without a prior in-person evaluation.
• Schedule II controlled substances: Generally still require an in-person evaluation before telehealth prescribing, with limited exceptions.
• State law: State prescribing laws apply on top of federal DEA requirements. Some states have more restrictive telehealth prescribing rules than the federal framework. Your prescribing logic must account for both federal and state requirements.

Before you build ePrescribe integration, know exactly which medication categories your platform will support and get a regulatory attorney’s confirmation of the current federal and state requirements for each category. This is a $3,000–$8,000 legal investment that prevents a regulatory action that could cost 1,000× more.

The ePrescribe integration options:

• Surescripts The largest ePrescribing network in the US, covering 95%+ of US pharmacies. Most EHR systems connect to pharmacies via Surescripts. If you want prescriptions sent directly to any pharmacy in the US, Surescripts is the network. However: Surescripts does not offer a direct API for standalone telehealth platforms, you access Surescripts through a certified ePrescribing vendor.
• DrFirst A certified Surescripts partner offering an ePrescribing API for telehealth and healthcare technology platforms. BAA available. EPCS (Electronic Prescribing for Controlled Substances) capability including identity proofing for prescribers. Our most common recommendation for telehealth platforms that need full ePrescribing including controlled substances.

Integration complexity: moderate to high. EPCS requires prescriber identity proofing (two-factor authentication plus identity verification meeting DEA requirements under 21 CFR §1311). The integration timeline for DrFirst with EPCS is 8–14 weeks depending on credentialing and testing requirements.

• DoseSpot A more developer-friendly ePrescribing API than DrFirst, with a white-label prescribing UI that embeds in your product. BAA available. EPCS support available. Faster time-to-integration than DrFirst for products where the white-label UI is acceptable.

Integration complexity: lower than DrFirst. Timeline: 4–8 weeks. Our recommendation for Seed-stage telehealth products that need ePrescribe quickly and where the prescribing workflow does not require deep custom UI integration.

What the ePrescribe integration actually involves:

1. Prescriber credentialing and enrollment: Every provider who will prescribe through your platform must be enrolled in the ePrescribing network (Surescripts via your integration partner). Enrollment requires NPI verification, DEA registration number (for controlled substances), and state license verification. This is a per-provider process and takes 1–3 weeks per provider.
2. EPCS identity proofing: For controlled substance prescribing, each prescriber must complete identity proofing, a one-time process that verifies their identity and enrolls them for two-factor authentication on each controlled substance prescription. This process is mandated by DEA under 21 CFR §1311.
3. Formulary and drug database: Your ePrescribing interface needs access to a drug database, RxNorm for drug identification, a formulary service for insurance-appropriate drug selection, drug interaction checking, allergy checking. DrFirst and DoseSpot include drug database access in their API. This is not something you build yourself.
4. Pharmacy directory: Patients select a preferred pharmacy for prescription fulfillment. Your integration partner provides the pharmacy directory query capability.
5. Prescription transmission and status tracking: Prescriptions transmitted electronically to the pharmacy via the Surescripts network. Status updates (received by pharmacy, dispensed, rejected) returned via webhook. Your platform tracks prescription status and surfaces it to the prescriber and patient.
6. Renewal and refill management: Pharmacy-initiated refill requests routed to the prescriber through your platform. This is a separate workflow from new prescriptions and must be designed and built.

EB Index 2026: Across 32 telehealth products we have shipped, 18 included ePrescribe integration. The median time from ePrescribe integration kick-off to first live prescription was 10 weeks. The longest was 22 weeks, a platform that needed EPCS, had not completed prescriber enrollment before build started, and discovered a state-specific prescribing restriction in month two. Start prescriber enrollment the day you decide to include ePrescribe in scope. Do not wait until the integration is built.

Compliance trap: EPCS (Electronic Prescribing for Controlled Substances) requires that each controlled substance prescription be signed with a two-factor authentication step, something the prescriber knows (password) plus something they have (authenticator app or hardware token). The two-factor requirement is mandated by DEA under 21 CFR §1311.120. A telehealth platform that allows controlled substance prescriptions without EPCS-compliant two-factor authentication is in violation of federal DEA regulations from the first controlled substance prescription transmitted.

Insurance Eligibility and Claims, When You Decide to Bill Payers

Many telehealth founders launch cash-pay and add insurance billing later. This is a legitimate sequencing choice, cash-pay is faster to build and faster to validate. But when you add insurance billing, you are adding a significant engineering and compliance layer. Here is what it actually involves.

Eligibility verification (270/271 HIPAA transaction):

Before a telehealth encounter, you need to verify that the patient’s insurance covers telehealth services, that the provider is in-network for that patient’s plan, and what the patient’s cost-sharing obligation is (deductible, copay, coinsurance). This is done via a 270/271 HIPAA eligibility transaction, an electronic query to the payer’s eligibility system.

Integration options: Change Healthcare (now part of Optum), Availity, Waystar, or a clearinghouse API like Eligibility.io or PokitDok (now part of Change Healthcare). The clearinghouse handles the HIPAA transaction formatting and payer connectivity so your platform sends a structured query and receives a structured response without building EDI (Electronic Data Interchange) capability internally.

Real-time eligibility in the telehealth workflow:

For a telehealth platform, eligibility verification is ideally performed at appointment booking (to surface coverage information to the patient before the visit) and again at check-in (to catch coverage changes). Building a real-time eligibility check at booking that surfaces patient cost-sharing information reduces no-shows and billing disputes. It also requires the clearinghouse API integration, which has its own HIPAA transaction compliance requirements.

Claims submission (837P HIPAA transaction):

After a completed telehealth encounter, a professional claim (837P) is submitted to the payer for reimbursement. The claim includes: patient demographics, insurance information, provider NPI, place of service code (02 for telehealth), date of service, diagnosis codes (ICD-10), procedure codes (CPT), and modifiers (95 for live video telehealth, GT for Medicare telehealth, modifier requirements vary by payer).

Telehealth-specific billing nuances: the place of service code for telehealth (02) is different from in-person (11 for office). CMS and many commercial payers have specific modifier requirements for telehealth claims. Some payers still require telehealth claims to be submitted with the in-person place of service code depending on the state and plan type. Your billing logic must handle payer-specific variations.

Remittance processing (835 HIPAA transaction):

The payer’s response to a claim, payment, denial, or request for additional information, comes back as an 835 remittance advice. Your platform must process these remittances, update claim status, identify denials (and the reason codes), and trigger a workflow for denied claim follow-up or appeal.

The billing architecture decision: Build it or buy it. Options:

• Build with clearinghouse API: Connect to a clearinghouse (Change Healthcare, Availity, Waystar) directly. You manage the HIPAA transaction logic, the claim formatting, and the remittance processing. Maximum control, maximum engineering complexity. Not recommended for early-stage telehealth unless billing is the core product differentiator.
• Billing service / RCM partner: Engage a revenue cycle management service, Kareo, Collectly, Waystar, or a specialty telehealth RCM firm, that handles claim submission, follow-up, and remittance processing on your behalf. Your platform sends encounter data; the RCM service handles billing. Lower engineering complexity, revenue share or per-claim fee to the RCM partner.
• Practice management system integration: If your providers already use a practice management system (Athenahealth, Kareo, Practice Fusion), integrate your telehealth platform with their existing billing workflow rather than building a parallel billing system. The encounter data flows from your telehealth platform to their practice management system for billing. The clinical records stay in your platform. This is often the fastest path for telehealth platforms serving established provider practices.

From a US founder call: “We launched cash-pay. It was the right call, we validated the model in three months and raised our Seed on the cash-pay traction. When we added insurance billing eight months later, we discovered that our encounter data model was missing three fields required for claims submission, the rendering provider NPI was stored separately from the supervising provider NPI, and our diagnosis code storage was a free-text field instead of a structured ICD-10 code field.

The data migration and schema change cost us six weeks. If I had known I was going to add insurance billing in month nine, I would have designed those fields correctly from the start.”, Seed-stage primary care telehealth founder, NYC.

The Telehealth UX Playbook, What Actually Works for Patients and Providers

Telehealth has the highest dropout rate of any healthcare product category at every stage of the funnel: booking to visit, visit start to visit completion, and first visit to return visit. The UI/UX decisions that drive these rates are well-understood, and consistently underimplemented.

Patient-side UX, what kills conversion:

• Pre-visit technical failure: The patient joins the waiting room. The video doesn’t work. The microphone doesn’t work. The browser doesn’t support WebRTC. This is the single highest-impact conversion killer in telehealth. Before every scheduled visit, run an automated pre-visit technical check, camera, microphone, browser compatibility, internet connection speed, and surface any issues to the patient with clear resolution steps at least 15 minutes before the visit. Not during the visit. Before.
• Intake form abandonment: Long, generic intake forms presented as a wall of questions before booking or before the visit cause abandonment. Design intake for progressive disclosure, collect the minimum required for booking at booking time, collect the clinical intake asynchronously in the 24 hours before the visit, not in a single session. Never present a form that takes more than 3 minutes to complete without a save-and-continue option.
• Consent workflow friction: Telehealth-specific informed consent is required. It is also a conversion friction point. Design the consent workflow to be clear, scannable, and completable in under 2 minutes. Use plain language, not legal copy, for the consent document itself, with a link to the full legal text. Signature via click or typed name is legally sufficient in most states for telehealth consent (confirm with your healthcare attorney).
• No-show prevention: Telehealth no-show rates average 15–25% without intervention. The interventions that work: SMS reminder 24 hours before (with a one-tap reschedule link), SMS reminder 1 hour before, and a waiting room notification when the provider is ready. Automate all three. The pre-visit technical check is also a no-show prevention mechanism, patients who discover and resolve a technical issue before the visit show up at 2–3× the rate of patients who discover the issue during the visit.

Provider-side UX, what kills retention:

• Documentation burden: The most common provider complaint about telehealth platforms is documentation time, the time required to write the clinical note after each encounter. AI-assisted documentation (ambient clinical documentation, SOAP note generation from transcript, structured template pre-population) reduces provider documentation time by 40–60% in products we have shipped. For any telehealth platform targeting provider retention, AI-assisted documentation is not a nice-to-have feature. It is a retention feature.
• Schedule management friction: Providers who manage their own schedules on your platform need a scheduling interface that is fast, mobile-friendly, and integrates with their existing calendar. A provider who has to log into a separate system to manage their telehealth availability will not maintain their availability accurately. Calendar sync (Google Calendar, Outlook Calendar, Apple Calendar) with two-way availability sync is a table stakes feature for any telehealth platform with provider-managed scheduling.
• Payment and earnings visibility: Providers who are paid per encounter or per time block, the majority of telehealth platform models, need clear, real-time visibility into their earnings, their encounter count, and their payment timeline. A provider dashboard with earnings history, pending payments, and payment schedule reduces provider support tickets by 60–70% in our experience and is a meaningful retention driver.
• The waiting room experience: The waiting room is the moment of highest anxiety in the telehealth experience for both patients and providers. Design it as a confidence-building experience, not a blank holding screen. For patients: confirm they are in the right place, show the provider’s photo and name, display the scheduled time, show a connection status indicator, and give them something to do (complete any remaining intake, review their chief complaint, test their audio/video). For providers: show the queue, surface the patient’s intake summary, give them a one-click join button. The waiting room is a product feature. Design it like one.

From a US founder call: “We launched with a generic video waiting room, a spinner and ‘Your provider will be with you shortly.’ Our first-visit completion rate was 71%. We added the pre-visit technical check, the patient intake summary in the waiting room, and the provider join notification. Three months later, first-visit completion was 89%. The UX changes cost us four weeks of engineering. The conversion improvement was worth more than anything else we shipped that quarter.”, Series A mental health telehealth founder, SF Bay Area.

What we’d cut: For a HIPAA-ready Lean Telehealth MVP, the minimum viable UX is: patient booking flow, pre-visit intake form (5–7 questions maximum), pre-visit technical check, HIPAA-compliant waiting room, video encounter, and post-encounter clinical note template. Provider scheduling management and AI-assisted documentation are sprint 2. Insurance eligibility and billing are sprint 3. Build the core clinical encounter first. Add the workflow optimization layer once you have clinical validation.

The Real Cost Stack for a Telehealth MVP in 2026

Engineering (what you pay us):

• HIPAA-ready Lean Telehealth MVP (synchronous video, cash-pay, single-state): $90K–$145K / 12–16 weeks
• Full Telehealth MVP (synchronous + async, ePrescribe, multi-state licensure): $160K–$240K / 16–22 weeks
• AI development ready MVP (ambient documentation, SOAP note generation, multi-state): $180K–$280K / 18–24 weeks
• Dedicated pod post-MVP: $24K–$38K/month

Compliance infrastructure (what you pay, not us):

• SOC 2 Type II audit: $45K–$95K
• SOC 2 compliance tooling (Vanta, Drata): $12K–$36K/year
• Penetration testing: $8K–$22K
• Credentialing service (Medallion, Verifiable): $15K–$40K/year depending on provider network size

Video infrastructure (ongoing):

• Daily.co at 500 visits/month × 20 min avg: approximately $10/month
• Daily.co at 5,000 visits/month × 20 min avg: approximately $100/month
• Recording storage adds approximately $0.0015/GB/month
• Amazon Transcribe Medical for AI transcription: $0.0086/second of audio, approximately $10.32/hour of clinical audio transcribed

ePrescribe integration (one-time + ongoing):

• DrFirst integration: $25K–$45K engineering, $12K–$30K/year licensing depending on prescription volume
• DoseSpot integration: $15K–$28K engineering, $8K–$20K/year licensing
• Prescriber enrollment and EPCS identity proofing: 1–3 weeks per prescriber, $50–$200/prescriber depending on the credentialing service

Legal:

• Healthcare attorney for telehealth consent documents, state-specific review: $5K–$15K
• Malpractice coverage guidance (tail coverage for telehealth): $2K–$6K in legal fees; malpractice insurance premium is a separate P&L line
• State medical practice law review for your target launch states: $3K–$8K

Credentialing and licensure (ongoing operational cost):

• Primary source verification per provider per state: $30–$100 depending on state and credentialing service
• Ongoing license monitoring per provider: $50–$150/provider/year
• Compact enrollment (IMLC, PSYPACT): varies by compact and state; typically $200–$700 per state license obtained

EB Index 2026: The median total first-year cost for a US telehealth MVP, engineering, compliance, video infrastructure, ePrescribe, legal, and credentialing, was $334,000. The median engineering line item was $162,000. The largest single non-engineering cost was credentialing and licensure operations at $48,000 for the first year, for a platform with 35 providers across 8 states.

Compliance trap: Malpractice insurance for telehealth encounters is not automatically included in a provider’s standard malpractice policy. Many malpractice policies were written before telehealth was widespread and contain exclusions or ambiguities about telehealth coverage.

Every provider on your platform should confirm with their malpractice insurer that their policy covers telehealth encounters in every state where they will see patients. This is a provider responsibility, not a platform responsibility, but it is a platform risk if a malpractice claim arises from an encounter and the provider discovers their coverage does not apply.

The 13-Week Telehealth MVP Sprint

• Week 1: Discovery and Compliance Scoping Synchronous vs. asynchronous decision finalized. Provider type inventory. State launch geography confirmed. ePHI data classification map produced. BAA vendor list completed. Licensure approach selected (single-state, compact, or credentialing service). ePrescribe scope decision (in v1 or v2). Billing model confirmed (cash-pay or payer-billing and timeline). Telehealth consent document drafted (by healthcare attorney, not by engineering).
• Week 2: BAA Execution and Architecture Design BAA signed. Cloud infrastructure architecture designed (HIPAA-eligible services only). Video infrastructure vendor selected and BAA confirmed. Audit log architecture designed. Access control model, provider, patient, care coordinator, billing, admin, designed and documented. Licensure enforcement logic designed.
• Week 3: Infrastructure Provisioning HIPAA-eligible cloud infrastructure provisioned. Encryption at rest enabled. TLS 1.2+ enforced. VPC, private subnets, security groups configured. CloudTrail enabled. Audit log service deployed. CI/CD pipeline with SAST live. Video infrastructure SDK integrated into development environment.
• Week 4: HIPAA Risk Assessment and Provider Onboarding Flow HIPAA risk assessment v1 drafted. Provider onboarding workflow built, credential collection, primary source verification integration (or manual verification workflow for single-state MVP), license storage, provider profile creation.
• Weeks 5–6: Patient Booking Flow and Pre-Visit Experience Patient registration with identity verification. Appointment booking with licensure enforcement (patient state → provider license check). Telehealth consent collection and storage. Pre-visit intake form. Pre-visit technical check (camera, microphone, browser, connection).
• Week 7: Video Encounter and Waiting Room HIPAA-compliant waiting room (patient and provider views). Video encounter with audio/video controls, screen share if required, in-encounter chat. Session end workflow. Post-encounter survey (optional but high-value for quality assurance).
• Week 8: Clinical Documentation Post-encounter clinical note template. Provider note creation workflow. Structured data capture (diagnosis codes, CPT codes, prescriptions if in scope). Note storage with appropriate access controls. Patient record view (HIPAA right of access).
• Week 9: Provider Dashboard and Schedule Management Provider availability management. Calendar sync (Google Calendar, Outlook). Encounter history. Earnings dashboard (cash-pay). Patient queue management.
• Week 10: ePrescribe Integration (if in scope for v1) DrFirst or DoseSpot integration. Drug database integration. Pharmacy directory. Prescriber enrollment and EPCS setup (1–3 weeks for prescriber enrollment, this should have started in Week 2, not Week 10). Prescription transmission and status tracking.
• Week 11: Internal QA and Compliance Review Full test suite for HIPAA requirements (session timeout, access control, audit log, encryption). Licensure enforcement test cases. ePrescribe test cases. HIPAA risk assessment updated to as-built. Data flow diagrams produced.
• Week 12: Penetration Testing Third-party pen test. Critical and high findings remediated. Pen test report archived.
• Week 13: SOC 2 Readiness, UAT, and Handover SOC 2 compliance platform connected. Policies written. UAT with real providers and test patients. Handover pack delivered. Launch.

AI-Native Telehealth in 2026

The AI features that are materially improving telehealth products in 2026:

• Ambient clinical documentation

The provider enables ambient listening at the start of the telehealth encounter. The session audio is transcribed in real time (Amazon Transcribe Medical, Nuance DAX, or a custom pipeline on AWS Bedrock). At the end of the encounter, the transcript is processed by an LLM to generate a structured SOAP note, Subjective, Objective, Assessment, Plan, pre-populated in the provider’s note template. The provider reviews, edits, and signs.

Time savings: 8–12 minutes per encounter in provider documentation time. At 20 encounters per day, that is 160–240 minutes of provider time recovered daily, the equivalent of 4–6 additional encounters per day.

HIPAA requirements: The session audio is ePHI. Transcription service requires BAA (Amazon Transcribe Medical is covered under the AWS BAA). The transcript is ePHI. The generated note is ePHI. Every step of the pipeline, audio capture, transcription, LLM processing, note storage, requires BAA coverage and encrypted storage.

Patient consent: Patients must consent to ambient recording separately from the general telehealth consent. The consent must explain that AI is used to assist with documentation. Most state-specific telehealth consent frameworks do not yet address AI documentation explicitly, your healthcare attorney should draft the AI documentation consent language.

• Intelligent intake and pre-visit preparation

An LLM-powered intake flow that adapts its questions based on the patient’s chief complaint, asking follow-up questions for specific symptoms, surfacing relevant history, and generating a structured intake summary for the provider before the encounter. Reduces encounter time and surfaces clinically relevant information the provider might not have asked about.

HIPAA requirements: The intake responses are ePHI. If an LLM processes the intake responses (to generate the summary or to adapt the question flow), the LLM call requires BAA coverage.

• Post-visit care plan and patient instructions

An LLM that generates patient-facing care plan instructions, medication instructions, lifestyle recommendations, follow-up timing, based on the clinical note, in plain language appropriate for the patient’s health literacy level. The provider reviews and sends.

This is a high-value feature for patient engagement and care plan adherence. It is also a high-risk feature if the LLM hallucinates a medication instruction or a follow-up timing recommendation. Every patient instruction generated by AI must be reviewed and approved by the provider before it is sent. No auto-send. Ever.

From a US founder call: “We added ambient documentation in sprint 2. Our NPS from providers went from 34 to 67 in two months. One provider told me it was the first time in fifteen years of practice that she finished her day with all her notes done. That feature, ambient documentation, is the single highest-ROI thing we have built. Build it early.”, Series A primary care telehealth founder, RTP.

Post-Launch: Credentialing, Payer Contracting, and Multi-State Expansion

• Credentialing for payer contracts

If you add insurance billing post-launch, every provider on your platform must be credentialed with each payer they will bill. Credentialing, the payer’s process of verifying provider credentials, malpractice coverage, and practice information, takes 60–120 days per payer per provider. It is slow, manual, and cannot be accelerated significantly. Start it as soon as you decide to pursue payer contracts, not when the billing integration is ready.

Credentialing services (CAQH ProView, Medallion, Verifiable) streamline the provider data collection process. They do not accelerate the payer’s internal review process.

• Payer contracting

Being credentialed with a payer is not the same as being contracted with them. Credentialing is the qualification process. Contracting is the commercial negotiation, reimbursement rates, covered services, telehealth-specific contract terms. For a new telehealth platform, payer contracting at commercial rates requires either a large enough provider network to have negotiating leverage or a payer relationship developed through a group practice, hospital system, or employer health plan channel.

For early-stage telehealth platforms pursuing insurance billing: Medicare (PECOS enrollment, straightforward process) and Medicaid (state-by-state, varies significantly) are often faster paths to payer revenue than commercial payer contracting.

• Multi-state expansion

Each new state you expand into adds: provider licensure requirements (new state license or compact authorization), state-specific telehealth consent requirements (many states have their own telehealth consent statute), potential state-specific prescribing restrictions, and potential state-specific Medicaid telehealth coverage requirements.

Build your state expansion as a configuration, not a codebase change. A well-architected telehealth platform has state-specific rules (consent requirements, prescribing restrictions, Medicaid coverage rules) stored as configuration data, not hardcoded in application logic. Adding a new state is a configuration update, not a sprint.

EB Index 2026: The median time from telehealth platform launch to first payer contract signed was 7.2 months. The median time from payer contract signed to first payer-reimbursed claim paid was 3.1 months additional. Total median time from launch to first payer revenue: 10.3 months. Plan your cash runway accordingly if payer revenue is in your financial model.

When an Indian Engineering Partner Is Wrong for Your Telehealth Build

An Indian product engineering partner is the wrong call for your telehealth product if: your product requires real-time clinical decision-making at the engineering level, where architecture decisions need a clinician in the room at 9 AM EST five days a week and you are not willing to fund the US-overlap staffing model.

If your telehealth product requires FedRAMP or CJIS compliance from Day 1, certain federal health programs fall into this category and require US-person handling of data.

If your founding team’s working style is synchronous and spontaneous, you need to be able to call your engineering team at 2 PM EST for an unscheduled 30-minute architecture review, and you are not willing to structure your collaboration around a defined overlap window.

If your telehealth platform’s clinical model is so novel and domain-specific that the provider workflow design requires daily, in-depth clinical domain expertise from the engineering team, a level of clinical immersion that requires US-based clinical consultants embedded in the engineering process, not available as occasional consultants.

These are honest constraints. Most US telehealth founders do not face all of them. If you face any of them, I will tell you on the first call.

The Telehealth MVP Scorecard

Score each row 0 (absent), 1 (partial), or 2 (fully present). Maximum score: 70.

#	Criterion	Weight	Your Score
1	Licensure enforcement logic in patient-provider matching	2×	/4
2	Primary source license verification (not just self-reported)	2×	/4
3	License expiration monitoring and automated alerts	2×	/4
4	Patient location captured at encounter level (not just billing address)	2×	/4
5	HIPAA-compliant video infrastructure with signed BAA	2×	/4
6	Telehealth-specific informed consent collected and stored	2×	/4
7	Pre-visit technical check (camera, mic, browser, connection)	1×	/2
8	ePHI data classification map produced in discovery	2×	/4
9	BAA coverage confirmed for every sub-processor touching ePHI	2×	/4
10	Immutable audit log for every ePHI access event	2×	/4
11	HIPAA risk assessment completed before go-live	2×	/4
12	Third-party penetration test completed before go-live	2×	/4
13	EPCS-compliant ePrescribe integration (if controlled substances in scope)	2×	/4
14	Prescriber enrollment completed before first prescription	1×	/2
15	Clinical emergency protocol designed and documented	1×	/2
16	No-show prevention workflow (reminders, pre-visit check)	1×	/2
17	Provider scheduling with calendar sync	1×	/2
18	Post-encounter clinical note with structured data (ICD-10, CPT)	1×	/2
19	SOC 2 readiness built into architecture from Day 1	1×	/2
20	State-specific rules stored as configuration (not hardcoded)	2×	/4
21	Malpractice insurance coverage confirmed for telehealth per provider	1×	/2
22	42 CFR Part 2 awareness (if any SUD-adjacent use cases)	1×	/2
23	Provider credential data with verification timestamp stored	1×	/2
24	IP assignment on creation in MSA	1×	/2
25	MSA governed by US law	1×	/2

Score interpretation:

• 55–70: Strong telehealth compliance posture, ready for enterprise payer conversations
• 40–54: Proceed with identified gaps remediated, focus on 2× items first
• Under 40: Significant regulatory and compliance exposure, do not go live with real patients until gaps are closed

Conclusion

Telehealth is not a video call with a medical form attached. It is a licensed medical practice delivered through technology, and every word of that sentence matters for how you build the product.

The licensure enforcement logic, the HIPAA-compliant video infrastructure, the ePrescribe integration with EPCS, the telehealth-specific consent workflow, the pre-visit technical check, the clinical emergency protocol, none of these are optional features you add when you have time. They are the product. They are what makes the difference between a telehealth platform that scales and one that creates liability faster than it creates revenue.

The founders I have worked with who built this right the first time have one thing in common: they treated the regulatory layer as a design constraint, not a legal problem to hand off. Their engineers knew why they were building the licensure enforcement logic. Their designers knew why the consent workflow mattered. Their product managers knew why the pre-visit technical check was non-negotiable.

If you want 30 minutes to talk through your telehealth product, what states you are launching in, what your provider network looks like, what your ePrescribe scope is, and what the right architecture is for where you are today, book a call with me or Aditi. No slides. No pitch. Just the product conversation.

 

Mayank Pratap Singh is the co-founder and CEO of EngineerBabu, a CMMI Level 5, Google AI Accelerator 2024 alumni product engineering studio based in Indore, India. EngineerBabu has shipped 1,200+ products since 2014, including 32+ telehealth products for US healthcare founders. Book a product audit at engineerbabu.com/discovery.

FAQ

• Can a provider see patients in any US state via telehealth?

No. A provider must hold an active license in the patient’s state at the time of the encounter. The patient’s physical location at the time of the telehealth visit determines which state’s medical practice laws apply, not the provider’s location or the platform’s headquarters. Your platform must enforce licensure compliance at every patient-provider match.

• What is the IMLC and does it eliminate state licensing requirements?

The Interstate Medical Licensure Compact is a multi-state agreement that allows physicians who hold a license in their principal state of practice to obtain licenses in other IMLC member states (40+ as of 2026) through an expedited process. It streamlines the application process but does not eliminate the licensing requirement. A physician must still hold an active license in each state where they see patients via telehealth.

• Can telehealth providers prescribe controlled substances without an in-person visit?

Under the DEA’s current telemedicine prescribing framework (post-COVID-19 PHE), certain Schedule III–V controlled substances can be prescribed via telehealth under specific conditions. Schedule II controlled substances generally still require a prior in-person evaluation with limited exceptions. State laws add additional requirements on top of federal DEA rules. Get a healthcare regulatory attorney’s guidance on prescribing scope before building ePrescribe.

• What video platform should I use for a HIPAA-compliant telehealth product?

The most common choice for early-stage telehealth products is Daily.co (BAA available on Scale plan) for its developer-friendly SDK, built-in waiting room, and clear HIPAA posture. Amazon Chime SDK is strong for AWS-native products. Twilio Video and Vonage Video are solid alternatives. Standard Zoom does not include a HIPAA BAA, the Zoom for Healthcare plan specifically is required, with correct configuration.

• What is EPCS and is it required for telehealth prescribing?

EPCS (Electronic Prescribing for Controlled Substances) is the DEA-mandated system for prescribing Schedule II–V controlled substances electronically. It requires two-factor authentication for each controlled substance prescription, with the prescriber enrolled and identity-proofed per DEA requirements under 21 CFR §1311. If your telehealth platform facilitates controlled substance prescribing, EPCS is required, it is not optional.

• How do I handle a medical emergency during a telehealth encounter?

Every telehealth platform must have a documented clinical emergency protocol before the first patient encounter. The protocol typically includes: the provider instructs the patient to call 911 and provides the patient’s address to emergency services, the provider documents the emergency in the encounter record, the platform has a mechanism for the provider to alert a supervisor or care coordinator, and the encounter is documented as an emergency visit in the billing record. Design and document this protocol before you go live.

• Do telehealth platforms need malpractice insurance?

The platform itself typically does not carry malpractice insurance, malpractice coverage is per provider, not per platform. However, your platform may carry general liability and technology errors and omissions coverage. Every provider on your platform should confirm with their malpractice insurer that their policy covers telehealth encounters in every state where they will see patients. This is a provider responsibility, make it part of your provider onboarding checklist.

• What is telehealth-specific informed consent and is it required?

Most US states require that patients explicitly consent to the telehealth modality before their first telehealth encounter, acknowledging they understand they are receiving care via video, that they have the right to refuse telehealth, and that their provider is licensed in their state. This consent is distinct from your platform’s general terms of service. It must be obtained before the first encounter and stored in a retrievable format. Consent requirements vary by state, have a healthcare attorney draft your consent document and review it against the specific requirements of each state where you operate.

• How long does telehealth credentialing take?

Provider credentialing for payer contracts takes 60–120 days per payer per provider. Primary source verification for platform onboarding (verifying a provider’s license is active and unrestricted) takes 1–5 business days depending on the state and the credentialing service used. EPCS identity proofing for controlled substance prescribing takes 1–3 weeks per prescriber. Start every credentialing workflow as early as possible, none of these processes can be significantly accelerated.