Telehealth apps look simple from the outside: a calendar and a video call. Telehealth app development is anything but, because the regulations, the integrations and the clinical workflow all sit underneath that video call. This guide is written from the experience of building patient-facing and clinician-facing software, and it covers what a first version needs, which rules apply, and what it costs.

The five features a telehealth app must have

  1. Scheduling with provider availability and time zones. Patients book into real clinician availability, with buffers, cancellations and reminders. Time-zone handling is where most bugs live; store everything in UTC and render in the patient's zone. A real example: a clinician in Denver publishes 9 a.m. to 5 p.m. Mountain. A patient in Phoenix books in March. Arizona does not observe daylight saving time, so the gap between the two shifts by an hour overnight. An app that stored local times shows the wrong slot. Buffers of 5 to 10 minutes between visits are typical, and clinicians will ask for them by the second week.
  2. Video that works on a bad connection. Patients join from phones on cellular networks. The video layer needs adaptive bitrate, a reconnect path and a fallback to audio. You buy this layer; you do not build it. Good looks like this: a patient who drops in an elevator rejoins the same room within seconds, without the clinician resending a link. Bad looks like a dead room and a phone call to the front desk. Test on a throttled connection before launch, not after the first complaint.
  3. Intake and consent. Forms for history, medications, allergies and the consent to treat via telehealth, captured before the visit and visible to the clinician during it. Intake that takes more than 10 minutes gets abandoned. Send it with the booking confirmation and save partial progress, so a patient who stops halfway does not start again.
  4. A clinical outcome. A prescription, a referral, a follow-up or a note. A visit that ends in nothing leaves the clinician writing it up elsewhere, and the app becomes a video toy. A structured note template, usually SOAP format, that the clinician can complete in the same screen as the video is the minimum.
  5. Billing or eligibility. Either cash pay with a card on file, or insurance eligibility checks and claim generation. Decide which before design starts, because they are different products. Cash pay is a payment form and a receipt. Insurance means eligibility checks before the visit, the right place-of-service code (02 or 10 for telehealth), modifiers, and claim status tracking afterwards.

The regulations, by name

HIPAA is the one everyone knows. It applies to the covered entity (the practice) and to every business associate that touches protected health information, including your development team, the video vendor and the cloud host. Each of them signs a Business Associate Agreement (BAA). If a vendor will not sign one, they cannot be in the data path. Practical consequences for the build: encryption at rest and in transit, unique user IDs, automatic logoff, audit logs of every access to a record, and a documented risk analysis.

Those requirements reach further than most buyers expect. Error-tracking tools, analytics scripts and log aggregators all see data. A crash report that captures a patient's name puts that vendor in the data path. Either it signs a BAA or you scrub the payload before it leaves your servers. Most teams keep audit logs for six years, matching HIPAA's documentation retention period. Breach notification to affected patients is required within 60 days of discovery, so the incident process needs to exist before launch.

State telehealth and licensure rules determine whether a clinician can treat a patient in another state. The app must know the patient's location at the time of the visit and the clinician's licences, and block or route accordingly. In practice, ask the patient to confirm their current state at check-in and record the answer. A home address on file is not enough. A patient who lives in Ohio but is on holiday in Florida is in Florida for that visit. Interstate compacts such as the Interstate Medical Licensure Compact speed up multi-state licensing but do not remove the check.

The Ryan Haight Act and DEA rules govern prescribing controlled substances via telehealth. If prescriptions are in scope, the prescribing path needs an identity-proofed e-prescribing vendor and, for controlled substances, the current federal flexibilities checked at build time, because they change. Build the rule as configuration, not hard-coded logic, so a change in federal policy is a settings update rather than a release.

42 CFR Part 2 adds consent requirements if substance-use treatment records are involved. TCPA governs SMS reminders: capture consent and honour STOP. Store the timestamp, the wording the patient agreed to, and the phone number. When a complaint arrives, that record is your defense.

The integrations you cannot avoid

  • Video: a HIPAA-eligible vendor with a signed BAA. Twilio Video, Daily, Vonage and Zoom for Healthcare are the usual candidates. Pricing is typically per participant minute. Model it at expected volume, not at pilot volume.
  • EHR: the practice's record system, usually via FHIR APIs for Epic, athenahealth, eClinicalWorks or similar. This is the slowest integration to get approved and the one that moves the timeline most. Scope it narrowly for version one: pull demographics and medications, push the visit note. Bidirectional scheduling sync can wait.
  • E-prescribing: Surescripts-certified vendors such as DrFirst or DoseSpot. Clinician onboarding with these vendors includes their own identity proofing, which takes days per clinician. Plan for it in the launch schedule.
  • Eligibility and claims: a clearinghouse API if insurance is in scope. Real-time eligibility responses vary by payer. Some return in seconds, some are incomplete, and the app needs a manual-review path for both.
  • Identity: patient identity proofing for prescribing and an identity provider for clinician single sign-on. Practices with more than a handful of clinicians will expect SSO from day one.
  • Messaging: SMS and email with consent records. Reminder messages should say "You have an appointment tomorrow at 2 p.m." and nothing about why. The reason for the visit is protected health information.

Order matters. Start the EHR application and the e-prescribing contract in week one, because both have external waiting periods. Video and messaging can be wired in later; they take days, not weeks.

Telehealth app development timeline and cost

A first version with cash-pay billing, bought video, intake, scheduling and a basic clinical note takes four to five months and costs $120,000 to $180,000 at typical 2026 US agency rates. Add EHR integration and insurance eligibility and you are at six to seven months and $220,000 to $300,000, with the EHR vendor's sandbox approval on the critical path. First-year maintenance, including compliance updates, runs 15 to 20 percent of the build cost. These are ranges, not quotes.

A typical breakdown of the four-to-five-month version:

  • Weeks 1 to 3: discovery, risk analysis, vendor selection and BAA signatures.
  • Weeks 3 to 6: clinical workflow mapping and design, tested with at least two working clinicians.
  • Weeks 6 to 17: build, in two-week increments with a working demo at the end of each.
  • Weeks 17 to 20: security testing, an external penetration test, and a pilot with one clinic.

Budget separately for running costs: video minutes, SMS, e-prescribing seats and cloud hosting. An external penetration test typically costs $10,000 to $25,000 and is worth repeating yearly. Practices and their insurers increasingly ask for the report.

Three mistakes first-time buyers make

  1. Building the video layer. It feels like the core, so teams want to own it. It is the most commoditised part of the product and the hardest to run well. Custom WebRTC means owning TURN servers, codec quirks across browsers, and every reconnect bug. That is months of work to match what a vendor sells per minute. Spend the budget on the clinical workflow instead, which is where products actually differ.
  2. Leaving the EHR integration to the end. Vendor approval for a sandbox can take eight weeks. Start the application the week the project is signed. A team that applies in month three often finishes the rest of the app and then waits. Those idle weeks still cost money if the team is retained.
  3. Treating consent as a checkbox. Consent to treat, consent to message, consent to share records and consent for a minor are different records with different retention rules. A single "I agree" box cannot be revoked in part. When a patient opts out of SMS but still wants visits, the data model has to separate the two. Retrofitting that after launch means migrating every existing consent record.

Two questions to ask any agency

Which BAAs have you signed, and can we see your subprocessor list? An agency that has built in healthcare has a list ready and a standard BAA of its own. A weak answer is "we'll sign whatever you send us" with no list of the tools their developers use. Their source control, ticketing system and error tracker all matter if real patient data could ever reach them.

Show me the audit log from a previous build. Not a description. The actual table design and a sample query answering “who viewed this patient's record last month?” A good answer shows who, what, when, from where, and which record. It shows that reads are logged, not just edits, and that the log cannot be altered by application users. A bad answer points to the web server's access logs.

If you are planning a telehealth product, tell us about it. An engineer who has built in healthcare will reply with a written scope that names the vendors, the BAAs and the integration order.

Frequently asked questions

Can we use a consumer video tool to start?

Only with a HIPAA-eligible plan and a signed BAA. The free tiers of most consumer tools do not qualify.

Do we need a native app, or is web enough?

Patients are fine on a responsive web app for scheduled visits. Clinicians who need push notifications and camera control all day usually justify a native app in version two.

What about data residency?

HIPAA does not require US-only hosting, but most practices' policies do. Choose a US region and say so in the risk analysis.

Is there an official HIPAA certification for an app?

No. HHS does not certify software. Third-party attestations such as SOC 2 or HITRUST show that controls exist and are tested, and larger practices often ask for one. Compliance itself rests on the risk analysis, the BAAs and how the system is actually run.

How much does telehealth app development cost?

Typically $120,000 to $180,000 for a cash-pay first version, and $220,000 to $300,000 with EHR integration and insurance eligibility. Add 15 to 20 percent of the build cost per year for maintenance, plus vendor running costs.