What is telehealth app development, and who needs a custom app?
Telehealth app development is building the software a practice uses to see patients remotely: a patient-facing app or web experience, a clinician workspace, and the integrations that connect video, scheduling, prescribing and records. A custom app makes sense when your visit flow, brand or integrations differ from what off-the-shelf tools allow.
Many practices never need custom software. A solo therapist can run video sessions through an EHR's built-in telehealth module or a BAA-backed video service and be perfectly well served. Custom telehealth app development starts to pay off in a few recognizable situations: a group sees patients across several states and needs clinician routing by license; a startup's care model (asynchronous visits, monitoring plus video, group sessions) does not match a generic platform; a practice wants its own branded app in the stores for retention; or the EHR's module forces clinicians through too many clicks.
The honest first step is to write down your visit lifecycle from the patient's point of view: find the practice, check eligibility, book, complete intake and consent, wait, meet, get a prescription or referral, receive a summary, pay, follow up. Then mark which steps already work with your current tools. The unmarked steps are the real scope, and they are often smaller than people expect.
Custom telehealth app development vs white-label platforms
Buy a white-label platform when speed matters most and your workflow is standard; build custom when the workflow is your differentiator or the platform's per-provider fees and limits will hurt as you grow. A hybrid, where a custom app sits on rented video and eRx services, is the most common answer.
Nobody sensible builds video streaming, pharmacy networks or certified prescribing from scratch for one practice. What custom telehealth app development actually means is owning the experience layer: the screens, the scheduling logic, the rules about who can see whom, and the data model, while renting the heavy infrastructure from vendors who specialize in it and will sign a business associate agreement with you.
- Choose white-label if you need visits running within weeks and can live with its screens
- Choose custom if you route patients by state license, run a novel care model or need deep EHR workflow
- Choose hybrid if you want your own brand and data model but not your own video or pharmacy stack
- Revisit the decision at scale: per-provider subscriptions grow with headcount; custom running costs grow with usage
We are happy to tell you when a platform is the better choice. If you decide to build, the same thinking behind our MVP development work applies: launch the smallest visit flow that real patients can use, then add features from what clinicians ask for.
Which vendors need a BAA in a telehealth app?
Any vendor that creates, receives, stores or transmits protected health information on your practice's behalf generally needs a business associate agreement: typically video, cloud hosting and database, messaging and SMS, email, file storage, e-prescribing, and any support or crash-reporting tool that could capture PHI. Your counsel makes the final call for each one.
During the pandemic, HHS relaxed enforcement so providers could use everyday video apps. That period is over. A Federal Register notice from April 2023 confirmed that the HHS Office for Civil Rights notifications of enforcement discretion would expire with the public health emergency on May 11, 2023, with a 90-day transition for telehealth. A telehealth app built today should assume the ordinary HIPAA rules apply.
In practice, vendor choice is where most telehealth app development projects either stay tidy or become risky. The obvious vendors (video, hosting) are usually handled. The quiet ones cause trouble: a crash-reporting SDK that captures screen text, an analytics SDK logging screen names like “Anxiety intake”, push notifications that print the provider's specialty on a lock screen, or a support chat widget that patients type symptoms into. We produce a vendor map listing every SDK and service in the app, whether it can see PHI, and whether it needs to sit under a BAA your practice signs. Anything that cannot be covered is removed or configured so it never receives PHI. We are developers, not lawyers, and we never describe our own work as “HIPAA-compliant”; the compliance decision is yours, made with your counsel.
Video visits in telehealth app development: SDKs, waiting rooms and weak signals
Build video visits on a HIPAA-eligible real-time video SDK or API rather than a consumer meeting app, and spend most of the design effort on the moments before and after the call: device checks, the waiting room, reconnects and the handoff to a summary.
Patients join from old phones, parking lots and rural connections. The video feature has to cope. We add a pre-visit check for camera, microphone and bandwidth; a virtual waiting room where the patient sees a clear status (“Dr. Rivera is finishing another visit”); automatic reconnect if the network drops; an audio-only fallback where your clinical policies allow it; and a visible way to call the practice if everything fails.
Multi-party visits
Interpreters, caregivers or a second clinician can be invited to a single visit with their own time-limited link.
Screen share and files
Clinicians can share images or care plans; uploads from patients land in BAA-covered storage, never in chat logs on a third-party server.
Recording
Off by default. If your practice wants recordings, we treat them as PHI with retention rules your policy sets.
Accessibility
Captions where the SDK supports them, large tap targets, screen reader labels and a text chat for patients who cannot use audio.
Scheduling and the visit lifecycle in a telehealth app
Telehealth scheduling has to handle three clocks at once: the clinician's time zone, the patient's time zone and the practice's rules. Get that wrong and patients miss visits; get it right and no-shows drop simply because reminders arrive at sensible times.
We model the visit as a set of states: requested, booked, intake complete, checked in, waiting, in visit, completed, documented, billed, and cancelled or no-show. Each state has an owner and triggers. When a patient books, the app confirms in their local time and sends reminders through a messaging vendor covered by your BAA, with wording that avoids clinical detail (“You have an appointment tomorrow at 3:30 pm” rather than the service name). Check-in opens a set time before the visit, so the clinician sees who is ready.
Provider availability often lives in the EHR already. Where the EHR exposes appointment slots through its API, we read and write there so staff keep one calendar. Where it does not, we build scheduling in the telehealth platform and give staff a daily export or a simple sync. Cancellation windows, buffer time between visits, new-patient vs follow-up durations and waitlists are settings your admin team controls, not code changes. For practices whose front desk still runs on phone calls, an AI voice agent can take booking requests into the same calendar.
How does state licensure affect telehealth app development?
In general a clinician needs to be licensed where the patient is located at the time of the visit, so a telehealth app should capture the patient's current state before each visit and only offer clinicians licensed there. The rules and exceptions vary by state and profession, so your counsel sets the policy and the app enforces it.
This is one of the clearest places where custom telehealth app development beats a generic tool. We store each clinician's license states and expiry dates, ask the patient to confirm their location at booking and again at check-in, and filter availability accordingly. If a patient travels, the check-in step catches it and routes them to rescheduling or a licensed colleague. Admins get an alert well before a license expires, so the schedule does not silently offer an unlicensed slot.
Multistate practices often ask about compacts. According to the Interstate Medical Licensure Compact Commission, the IMLC is a voluntary, expedited pathway for qualified physicians to obtain separate licenses in participating states, not a single national license. So from the app's point of view nothing changes: each state license is still a separate record. Other professions such as nursing, psychology and counseling have their own compacts and rules. We build the rules engine; we do not interpret the law, and a healthcare attorney should approve the routing policy before launch.
Can a telehealth app include e-prescribing?
Yes, but through a certified e-prescribing vendor embedded in the clinician workflow, not built in-house. The vendor connects to pharmacy networks and, for controlled substances, carries the audit or certification burden federal rules require.
Electronic prescribing of controlled substances is tightly regulated. Under 21 CFR 1311.300, an EPCS application needs a third-party audit or a DEA-approved certification before it may be used, repeated when functionality changes or every two years, whichever comes first. The same part of the regulations sets two-factor authentication and identity-proofing requirements for prescribers. That is why a practice-built app should hand prescribing off to a vendor that already holds the certification.
Remote prescribing policy is also in flux. The DEA and HHS issued a fourth temporary extension of the COVID-era telemedicine flexibilities for prescribing controlled medications, running through December 31, 2026. Whatever the permanent rules become, your clinicians and counsel decide what may be prescribed after a video-only visit; the app records the visit type and supports those rules. In a typical build, the clinician opens the eRx vendor's embedded screen from the visit, the patient's demographics and pharmacy prefill, and the prescription status returns to the visit record.
EHR integration choices for telehealth app development
There are three realistic levels: a SMART on FHIR app launched from inside the EHR, a background FHIR integration that syncs patients, appointments and documents, or a lighter workflow where visit summaries are exported and filed by staff. Which one you get depends on what your EHR vendor exposes and approves.
Certified EHRs in the US must offer a standardized patient and population API. ONC's test method for the (g)(10) criterion names HL7 FHIR Release 4.0.1, the US Core implementation guide and the SMART App Launch framework, including patient access for standalone apps and clinician access for EHR launch. That is a useful baseline for read access. Writing data back (notes, appointments, orders) is where EHRs differ most, and it usually needs the vendor's own APIs, app-marketplace registration and sometimes fees.
Our advice is to start read-first. Launch the telehealth app from the EHR with SMART, read demographics and appointments, and write the visit summary back as a document if the vendor allows it. Deeper write-back comes later once the workflow is proven. We have no special partnership with any EHR vendor, so their approval timelines are outside our control, and we flag them early in the plan.
Patient onboarding: identity, consent, insurance and intake
Good onboarding gets a new patient from download to a booked visit in a few minutes while collecting only what the practice needs: identity, contact details, location, consent to telehealth, insurance or payment, and a short clinical intake.
Onboarding is where telehealth apps lose people. We break it into small screens, save progress so an interrupted signup resumes, and ask for insurance card photos only when a visit type needs them. Consent forms your practice supplies (telehealth consent, privacy practices, financial policy) are shown in readable text with a timestamped acceptance stored against the patient record. Identity verification can be as simple as a date of birth and phone check or, where your model requires it, an identity-verification vendor under a suitable agreement.
- Account creation with passkeys or strong passwords plus multi-factor authentication
- Current state of residence and a location confirmation for each visit
- Consent forms your practice provides, versioned so re-consent can be triggered
- Insurance details or card-on-file through a payment vendor, never stored in the app
- Short intake questionnaires built from your templates, with conditional questions
- Guardian or proxy access for minors and dependents, if your policies allow it
How much does telehealth app development cost?
With our team, a telehealth patient app for Android and iOS starts at US$600, a provider dashboard or full platform starts at US$900, and a supporting public website starts at US$150. Vendor fees for video, messaging, hosting and prescribing are billed to your practice separately.
Quotes for telehealth app development vary widely across the market, and the reasons are easy to list. Integrations drive cost most: a SMART on FHIR read-only launch is a very different job from full appointment and note write-back. Next come the number of roles (patient, clinician, front desk, supervisor, admin), multi-state license routing, asynchronous visit types, group sessions, payments and insurance capture, and the amount of design polish your brand needs.
Running costs matter as much as the build. Video is usually billed per participant-minute, SMS per message, and eRx per prescriber, and all of them need plan tiers that include a BAA. We put estimated usage-based costs in the quote so you can compare a custom build against per-provider platform fees over two or three years. Our cost to outsource app development page explains the offshore side of that comparison.
How long does it take to build a telehealth app?
A first patient app with booking, intake and video visits typically takes 6–10 weeks; a platform with a provider dashboard, admin console and EHR or eRx integration takes 6–12 weeks for the first version, with vendor approvals often setting the real end date.
The build itself is predictable. What stretches telehealth timelines is outside code: signing BAAs with each vendor, getting EHR marketplace or API access approved, eRx vendor onboarding and prescriber identity proofing, App Store review for health apps, and your counsel's review of consent language and license routing rules. We start those threads in the first week so they run in parallel with design and development.
A typical plan: week 1, visit lifecycle map, vendor list and BAA checklist; weeks 2–3, clickable prototype tested with two clinicians and a few patients; weeks 3–7, patient app and provider dashboard built against sandbox vendors with synthetic data; weeks 6–9, integrations, security testing and accessibility checks; then a pilot with a small group of clinicians before opening to all patients. Store submission runs in the last two weeks, and you need your own Apple Developer account (99 USD per year, per Apple) and Google Play developer account (a one-time US$25 fee, per Google) ready by then.
Security architecture for telehealth app development
A telehealth app should encrypt data in transit and at rest, give every user a unique login with multi-factor authentication, grant access by role, log every view and change of PHI, time out idle sessions, and keep PHI out of places it tends to leak: notifications, logs, analytics and device storage.
We run the backend in your practice's own cloud account, on services covered by the provider's BAA, with the database encrypted and private networking between components. On the phone, tokens sit in the platform's secure storage, screenshots can be blocked on sensitive screens, cached data is minimized and cleared at logout, and a remote sign-out option exists for lost devices. Push notifications carry no clinical detail.
Audit logs record who accessed which patient, when and from where, and they are written somewhere ordinary staff accounts cannot edit. Before launch we run a dependency scan, basic penetration testing of the API against the common web risks, and a review of every third-party SDK against the vendor map. If your organization requires an independent penetration test or security questionnaire, we support the testers and fix what they find. Throughout, our team works only with synthetic data; production PHI stays with your staff.
Flutter, React Native or web for a telehealth app?
Use Flutter or React Native for a patient app on both stores from one codebase, and a web app for clinicians who work from desktops. Offer a browser-based join link as well, because some patients will never install an app for a single visit.
Both cross-platform frameworks have mature support in the major video SDKs, so the choice usually comes down to your team. If your engineers already write React, React Native keeps skills shared with the provider dashboard. If you are starting fresh and want very consistent UI on older Android phones, Flutter is a strong option. Our Flutter and React Native pages go deeper.
A native app earns its place for returning patients: push reminders, stored insurance details, secure messages and quicker joins. A browser link earns its place for one-off visits and for relatives joining a call. We build both from shared backend APIs. The provider dashboard is a web app because clinicians work at desks with the EHR open beside it, and an app that forces them onto a phone would slow them down.
Choosing a telehealth app development partner: questions and red flags
Pick a partner who can show you a vendor and data-flow map before quoting, explains which parts they will rent rather than build, and never needs real patient data to develop. Be cautious of anyone who promises a “HIPAA-certified app”; there is no government certification by that name.
Questions to ask any telehealth app development team: Which video SDK do you recommend and does its BAA cover our use? How will the app know which state the patient is in? How is e-prescribing handled for controlled substances? What does our EHR allow, and what will you do if write-back is not approved? What leaves the phone in push notifications, analytics and crash reports? Who owns the store accounts and cloud account? How do we get security fixes after launch?
- Red flag: the developer's own cloud account hosts your PHI
- Red flag: an analytics or advertising SDK is included “for marketing” without a PHI review
- Red flag: e-prescribing is described as a quick custom feature
- Red flag: no plan for license expiry, patient travel or state routing
- Good sign: a pilot with a few clinicians before full launch
Working with a telehealth app development team in India from the US
Your clinicians and staff talk to us in US Eastern mornings, which are evenings in India, and review new builds the next day. West Coast practices usually pick one early call a week and handle the rest in writing.
Because we work from India and have no US office or entity, the setup is deliberate. Your practice creates the cloud, video, messaging and store accounts, signs the BAAs with those vendors, and invites us with limited roles. We develop against sandbox environments and synthetic patients, so our team never needs production PHI; once live, production access stays with your staff and any support access is decided by your compliance lead. Quotes and invoices are in USD, paid by bank wire, Wise or PayPal, and nothing is billed before your written approval.
The first two weeks look like this: a kickoff call to walk through your visit lifecycle; a vendor and BAA checklist your compliance lead can work from; a written list of license-routing and consent rules for counsel to approve; and a clickable prototype that two of your clinicians try on their own phones. By the end of week two you know exactly which screens, integrations and vendors are in scope, and the build plan has dates. Details such as NDAs and IP assignment go into the written quote and our terms.
Worked example: a two-state behavioral health group (hypothetical)
Say a behavioral health group with twelve therapists in Colorado and New Mexico wants its own app. Some therapists hold licenses in both states, most in one. The group uses a cloud EHR with a FHIR API and wants weekly video sessions, secure messaging and intake questionnaires. This is an illustration of how scope might be shaped, not a past client.
The plan starts with a vendor map: a HIPAA-eligible video SDK, the group's own cloud account for the backend, a messaging vendor for reminders, and the EHR. Each gets a BAA the group signs directly. Therapists' license states go into the admin console, and patients confirm their location at booking and check-in; a patient who says they are in Arizona that day is asked to reschedule, in line with the policy the group's counsel approves.
The patient app covers onboarding, intake, booking, the waiting room and sessions, and the provider dashboard shows each therapist's day and a notes template. Phase one reads demographics and appointments from the EHR with SMART on FHIR and files a visit summary back as a document. No prescribing is included, since the group refers medication management elsewhere. Scope like this sits in the patient app plan from US$600 plus the platform plan from US$900, with vendor usage billed to the group.
Telehealth app development launch checklist
Run through these checks with your clinical lead, compliance officer and development team before the first real patient joins a visit.
- BAAs signed with every vendor on the vendor map that can touch PHI
- License-routing and consent rules approved by your counsel and configured in the admin console
- Push notifications, SMS and email wording checked for clinical detail
- Crash reporting and analytics confirmed PHI-free
- Video tested on an older Android phone, an iPhone and a weak connection
- Audit logs reviewed: every view of a test patient appears
- Accessibility checked with screen readers and large text settings
- Store listings, privacy labels and support contacts completed in your own developer accounts
- Pilot group of clinicians trained and a rollback plan written down
Your telehealth landing pages need the same care for accessibility; the accessibility remediation page explains how we audit and fix public sites against WCAG.