Telemedicine App Development: The 2026 Engineering Guide (Architecture, Compliance, Cost)

Reviewed September 2026. Regulatory dates checked against official sources.

Telemedicine app development is the work of designing, building and operating software that lets clinicians deliver care remotely: live video visits, secure messaging, asynchronous (store-and-forward) review, e-prescribing and remote monitoring. A production telemedicine app also has to meet HIPAA, prescribing and state licensure rules and exchange data with the EHR.

This guide is written for the people who have to ship and run the product: founders of virtual care companies, product leads at provider groups and CTOs at digital health startups. It covers the architecture layer by layer, the US rules as they stand in September 2026 (with dates and sources), how EHR integration works with Epic, Oracle Health, athenahealth and eClinicalWorks, what drives cost, and where telehealth projects usually fail.

What a telemedicine app is, and the four product types

"Telehealth" is the broader term for remote health services, including education and administrative use. "Telemedicine" usually means remote clinical care between a licensed clinician and a patient. In practice, buyers and regulators use the words interchangeably, and so does this guide.

Almost every telemedicine product falls into one of four types, and the type decides most of your architecture:

Many products combine types, such as live video plus async check-ins for behavioral health. Decide the primary type first, because it sets what the MVP must include and which regulations bite hardest.

Reference architecture: the 13 building blocks of a telemedicine platform

A telemedicine app is a set of services that share identity, scheduling and a clinical record. Below are the building blocks found in almost every production platform, with the decisions that matter for each.

1. Patient app (mobile and web)

The patient app handles registration, identity verification, intake forms, consent, booking, the visit itself, follow-up messages and payments. Two decisions shape it:

• Native, cross-platform or web-first. Video quality and background behavior (incoming call notifications, reconnecting after a phone call interrupts the visit) are better in native or React Native / Flutter apps. A web app with no install lowers friction for one-off visits and is often enough for provider-extension telehealth, where patients join from an email or SMS link.
• Low-bandwidth fallbacks. Build audio-only fallback into the visit screen from day one. Medicare allows audio-only for many services through the end of 2027 (see compliance below), and a large share of visits will hit poor connections.

Accessibility is a requirement, not polish. HHS now requires recipients of HHS funding to meet WCAG 2.1 Level AA for web content and mobile apps (details in the compliance section).

2. Clinician workspace

This is where most of the product value lives and where most MVPs are too thin. Clinicians need a queue of today's visits, patient context (history, meds, allergies, prior notes), the video pane, a notes panel, order and prescription entry, and a one-click way to close the visit. If the clinician works inside an EHR all day, the better pattern is to launch the telehealth workspace from the EHR with SMART on FHIR so they never retype a patient's name.

3. Scheduling and provider matching

Scheduling in telemedicine has rules generic calendar tools do not handle:

• State licensure matching. A clinician can only see a patient located in a state where the clinician is licensed (or otherwise authorized). The patient's location at the time of the visit is what counts, so capture and confirm it at check-in, not only at signup.
• Payer and credentialing matching. If you bill insurance, the clinician must be credentialed with the patient's plan.
• Visit types and durations, buffers, time zones and on-demand queues versus booked slots.

4. Virtual waiting room

The waiting room is a small state machine: scheduled, checked in, device test passed, waiting, admitted, in visit, wrapped up, no-show. Each transition is an event that other services react to (notify the clinician, start the no-show timer, release the slot). Build the device check (camera, microphone, bandwidth) into this step. It prevents a large share of "I can't hear you" minutes.

5. Video layer

Real-time video in telehealth runs on WebRTC, the open standard supported natively in modern browsers and mobile platforms. You have three options:

1. Managed video API that signs a HIPAA BAA. Options that currently offer BAAs include Twilio Video (Twilio announced an end of life in 2023, then reversed it and kept Video as a standalone product), Vonage Video API (BAAs for enterprise accounts), Zoom Video SDK, Daily (HIPAA through a healthcare add-on) and the Amazon Chime SDK, which is on AWS's list of HIPAA-eligible services under the AWS BAA.
2. Self-hosted open-source media server (for example Jitsi, mediasoup or LiveKit) on your own HIPAA-eligible cloud account. More control and lower per-minute cost at scale, but you now operate SFUs, TURN servers and capacity planning.
3. Embedded third-party telehealth product (the vendor's UI inside yours). Fastest, least control.

Whichever you pick, confirm the BAA covers the specific features you use (recording, transcription, PSTN dial-in), because vendors often scope BAAs by service. Also plan for TURN relays: patients on hospital guest Wi-Fi and corporate networks will fail peer connections without them. For the full media, signaling and data design, see our production WebRTC and FHIR architecture for HIPAA telehealth.

6. Asynchronous care (store-and-forward)

Async flows let patients submit structured questionnaires, photos, videos or documents for later review. The engineering work is in the protocol engine: a versioned set of questions, branching logic, contraindication rules and required fields that a clinical lead signs off on. Store the protocol version with each submission so you can show exactly what the patient was asked. Images need secure upload, EXIF stripping, size normalization and viewer tools for zoom and comparison.

7. Secure messaging

Patient-clinician messaging needs delivery receipts, attachments, routing to care teams (not only individuals), response-time SLAs and a clear path from message to billable encounter where applicable. Push notifications and SMS should carry no PHI: "You have a new message from your care team" with a deep link that requires login.

8. E-prescribing

E-prescribing in the US runs through the Surescripts network, usually via a certified e-prescribing vendor that your app integrates with, rather than a direct connection. Controlled substances add a separate layer: electronic prescriptions for controlled substances (EPCS) must meet DEA rules in 21 CFR Part 1311, including identity proofing of the prescriber, two-factor authentication at the moment each controlled-substance prescription is signed, and audited software. Whether a controlled substance can be prescribed after a telemedicine-only visit is a separate question covered in the compliance section.

9. Payments, eligibility and billing

Cash-pay products need payment, refund and receipt workflows. Insurance-billed products need X12 270/271 eligibility, 837 claims, 835 remittance and payer-specific billing rules. Store the source and time of every eligibility response, because the patient’s final responsibility is set when the claim adjudicates.

10. EHR integration

For provider-extension telehealth, this is the most important block. The modern pattern is SMART on FHIR for launch and read access, FHIR APIs or HL7v2 for writing back notes and results, and an integration engine for everything that is not yet on FHIR. The EHR integration section below goes vendor by vendor.

11. Remote patient monitoring (RPM) devices

RPM ingestion takes readings from cellular or Bluetooth devices (blood pressure cuffs, glucometers, scales, pulse oximeters), usually via a device vendor's cloud API. Normalize readings into FHIR Observations, run threshold rules, route alerts to a care-team queue and track days of data and minutes of interaction per patient per month, because Medicare RPM billing depends on both. Our remote patient monitoring software services page covers this stack in more depth.

12. Clinical notes and AI scribe

Visit notes need templates by visit type, structured fields that map to billing, signing and addenda. Ambient AI scribes that listen to the visit and draft the note are now common. Treat them as a PHI processor: they need a BAA, patient notice or consent according to your state's recording rules, a clinician review step before signing, and a retention policy for audio that is separate from the note itself.

13. Analytics and operations

Track visit volume, no-show rate, time to first available slot, time in waiting room, call quality (packet loss, reconnects, audio-only fallbacks), prescription turnaround and patient-reported outcomes. Send de-identified or minimum-necessary data to your warehouse, and keep PHI out of product analytics tools that will not sign a BAA. The FTC has already acted on this: GoodRx (February 2023, the first Health Breach Notification Rule case) and online therapy company BetterHelp ($7.8 million, finalized July 2023) were both penalized for sharing health data with advertising platforms.

Features: what belongs in the MVP and what waits for version 2

The fastest way to blow a telemedicine budget is to build every feature in the competitor's app before a single clinician has used yours. The table below is the split we recommend for a first release that real patients and clinicians can use safely, followed by the features that should wait until usage data justifies them.

Two MVP rules that save months:

• Pick one state set and one visit type. Launching in the states where your clinicians are already licensed, with one well-defined visit type, removes most of the licensure and protocol work from version 1.
• Pick one EHR, or none. If you are a provider group on a single EHR, integrate with that one. If you are a DTC startup, run your own lightweight clinical record first and add EHR connectivity when a partner requires it.

Build vs buy vs white-label: choosing the right path

There is no universally right answer here. The right answer depends on whether telehealth is your product or a channel for care you already deliver.

A hybrid is common and usually smart: custom patient and clinician experiences on top of bought infrastructure. For example, a custom React Native patient app and clinician workspace, a managed video API under a BAA, a certified e-prescribing vendor, and a FHIR server for the clinical record. You own the parts that differentiate you and rent the parts that are commodity.

If you are weighing these options for a real project, our team offers telemedicine app development services that cover custom builds, hybrids and integration of bought platforms into existing EHR workflows.

US compliance for telemedicine apps in 2026: what changed and what still applies

Telehealth rules moved a lot between 2020 and 2026. Several pandemic-era flexibilities have been extended again, some have been made permanent, and some are about to change. Everything below was checked against official or primary sources in September 2026. Regulations change, so re-verify dates before you launch.

HIPAA: safeguards, vendor roles and applicable BAAs

During the COVID-19 public health emergency, HHS Office for Civil Rights (OCR) said it would not penalize providers for using non-compliant consumer video tools in good faith. That enforcement discretion expired at 11:59 pm on May 11, 2023, followed by a 90-day transition that ended on August 9, 2023. Since then, the full HIPAA Privacy, Security and Breach Notification Rules apply to telehealth.

In practice that means:

• Identify business associates and execute the required BAAs. Review whether each service creates, receives, maintains or transmits PHI on a covered entity’s behalf. HHS distinguishes business associates from transmission-only conduits; review the actual service and feature scope rather than applying one rule to every vendor. See HHS telehealth vendor guidance.
• A risk analysis is required under the Security Rule, and it should specifically cover the telehealth platform.
• Breach notification: affected individuals must be notified without unreasonable delay and no later than 60 days after discovery, with HHS and media notice for larger breaches.

The January 2025 HIPAA Security Rule proposal would make encryption, multi-factor authentication, a technology asset inventory and a yearly compliance audit explicit requirements. It is still a proposal, and building those controls now is the pragmatic choice: enterprise security reviews already ask for them.

Health apps outside HIPAA: the FTC Health Breach Notification Rule

Not every telemedicine product is a HIPAA covered entity or business associate. A direct-to-consumer wellness or symptom app that is not providing care on behalf of a covered entity may sit outside HIPAA, but not outside regulation. The FTC's amended Health Breach Notification Rule, in effect since July 29, 2024, explicitly covers health apps and connected devices. Under the rule, a "breach" includes an unauthorized disclosure, such as sharing health data with an advertising platform without authorization, not only a hack. Notices to individuals are due without unreasonable delay and within 60 days, and for breaches affecting 500 or more people the FTC must be notified at the same time. The FTC's compliance guide is the best starting point.

Prescribing controlled substances by telemedicine (DEA and the Ryan Haight Act)

The Ryan Haight Online Pharmacy Consumer Protection Act of 2008 generally requires an in-person medical evaluation before a controlled substance is prescribed over the internet. Since 2020 the DEA has waived that requirement through a series of temporary flexibilities.

Current temporary framework: DEA and HHS extended the telemedicine flexibilities through December 31, 2026. Practitioners can prescribe after a telemedicine encounter when they meet the rule’s audio-video conditions (or its specific audio-only exception), the legitimate-medical-purpose requirement and applicable federal and state law. See the fourth temporary extension.

Before a prescribing release: your clinical and legal owners sign off the prescribing policy against current DEA rules, registration requirements and state law. Build to final rules, not to proposals or news reports about pending rules.

Engineering implication: version prescribing policies and their effective dates, capture patient location and the required encounter evidence, and retain the applicable prescriber credentials. Treat each policy change as a release: some are configuration, others need new workflow, data and tests.

Medicare telehealth coverage in 2026 and 2027

Congress extended the main Medicare telehealth flexibilities in the Consolidated Appropriations Act, 2026 (H.R. 7148), signed February 3, 2026 as Public Law 119-75. Per Telehealth.HHS.gov, through December 31, 2027:

• Patients can receive non-behavioral telehealth at home, with no geographic restriction on the originating site.
• All eligible Medicare practitioners can furnish telehealth.
• Audio-only is allowed for non-behavioral services when the patient cannot or will not use video.
• FQHCs and rural health clinics can act as distant site providers.
• The in-person visit requirement for Medicare behavioral and mental telehealth is not enforced.

The CY 2026 Medicare Physician Fee Schedule final rule, effective January 1, 2026, also made several telehealth changes permanent (CCHP summary):

• The review process for the Medicare Telehealth Services List was simplified, and the "provisional" versus "permanent" labels were removed.
• Frequency limits on telehealth subsequent inpatient visits, subsequent nursing facility visits and critical care consultations were permanently removed.
• Direct supervision through real-time audio and video (not audio-only) was made permanent for most services, excluding those with 010 or 090 global surgery periods.
• CMS noted that a separate Medicare enrollment is required for each state where a practitioner furnishes services and that it defers to state licensure rules.

Remote patient monitoring codes in 2026

Remote patient monitoring (RPM, including CPT 99453, 99454, 99457 and 99458) and remote therapeutic monitoring (RTM) have different service definitions, device requirements and time measures; the CMS RPM overview sets out the basics. The platform should store source transmission dates, eligible staff activity and supporting records for every billed month, so your billing team can map each claim to the current code descriptors, payer rules and permitted code combinations.

State licensure and the Interstate Medical Licensure Compact

Licensure is state law. A clinician generally must be licensed in the state where the patient is physically located during the visit. The Interstate Medical Licensure Compact (IMLC) offers physicians an expedited path to additional state licenses in more than 40 member states, but it does not create a single national license: the physician still holds a separate license in each state. Nurse practitioners, psychologists, counselors and other professions have their own compacts with different membership. Your scheduling and routing logic needs a licensure table per clinician (state, license number, type, expiry) and must block visits that do not match.

E-prescribing of controlled substances (EPCS)

Beyond DEA's technical rules in 21 CFR Part 1311, CMS runs an EPCS program for Medicare Part D: for measurement year 2026, prescribers must electronically prescribe at least 70% of qualifying Schedule II to V Part D prescriptions, with exemptions for prescribers issuing 100 or fewer such prescriptions. Many states have their own EPCS mandates on top. The practical choice for most telemedicine teams is to integrate a vendor that is already certified for EPCS rather than get their own software audited.

Accessibility: WCAG 2.1 AA is now a written HHS requirement

HHS’s Section 504 rule adopts WCAG 2.1 Level AA for covered web content and mobile applications of recipients of HHS financial assistance, with specified exceptions. The May 2026 amendment sets May 11, 2027 for recipients with at least 15 employees and May 10, 2028 for smaller recipients. Build to WCAG 2.1 AA from the first design sprint, with keyboard, screen-reader, text-resizing, contrast and live-captioning checks in every release. Language assistance for patients with limited English proficiency is a separate obligation to plan for.

Interoperability rules that affect EHR-integrated telehealth

The ASTP/ONC HTI-1 final rule made USCDI v3 the baseline data set for certified health IT from January 1, 2026 and adopted SMART App Launch 2.0 for the standardized API criterion. Certified EHRs therefore expose a predictable set of FHIR resources and a standard OAuth 2.0 launch, which is what makes vendor-neutral telehealth apps practical.

Sources: DEA temporary rule, HHS Section 504 extension and HHS Medicare payment policies.

EHR integration for telemedicine: Epic, Oracle Health, athenahealth and eClinicalWorks

For any telehealth product sold to providers, EHR integration decides adoption. Clinicians will not keep two charts, and health system IT teams will not approve an app that creates one. Here is how integration works in practice.

The three integration patterns

1. SMART on FHIR launch (EHR launch). The clinician clicks a button inside the EHR. The EHR opens your app and passes a launch context (patient, encounter, user) through an OAuth 2.0 flow defined by the SMART App Launch framework. Your app then reads FHIR resources (Patient, Encounter, Condition, MedicationRequest, AllergyIntolerance, Observation) with the scopes it was granted. This is the best clinician experience: one click, right patient, no retyping.
2. Standalone launch and patient access. The patient signs in to your app with their portal credentials, and your app reads their record through the same SMART and FHIR APIs. Useful for intake and for pulling medication lists before the visit.
3. Backend and HL7v2 integration. For writing data back (visit notes, scheduling updates, charges) many EHRs still rely on HL7v2 messages (SIU for scheduling, MDM for documents, DFT for charges, ORU for results) or vendor-specific APIs. An integration engine such as Mirth Connect sits in the middle, translating between your FHIR data model and each EHR's interfaces.

Most real deployments use all three: SMART launch for the clinician, FHIR reads for context, and HL7v2 or vendor APIs for write-back.

Epic

Epic exposes FHIR R4 APIs and SMART on FHIR launch through its developer resources at fhir.epic.com, with a public sandbox for testing. Getting into production at a specific health system means registering your app, working through Epic's app distribution process and, crucially, getting that health system's Epic team to configure and approve the launch in their own build. Write-back of notes typically needs extra work beyond the read APIs. Our practical walkthrough of how to integrate with Epic covers app registration, sandbox testing and the approval steps in detail.

Oracle Health (Cerner)

Oracle Health Millennium supports FHIR R4 and SMART on FHIR, with a developer program and sandbox for app registration and testing. Scopes, resource coverage and write support differ from Epic, so do not assume an Epic-tested app works unchanged. Test each resource you rely on against the Oracle Health sandbox and then against the customer's domain.

athenahealth

athenahealth offers both certified FHIR APIs and a broad set of proprietary REST APIs, plus a marketplace for partner apps. Its proprietary APIs are often the practical route for scheduling and appointment write-back, which matters for telehealth because the appointment lives in athenaOne.

eClinicalWorks

eClinicalWorks provides certified FHIR APIs for patient data access and works with third-party apps through its partner processes. Many eClinicalWorks practices also exchange data through HL7v2 interfaces, so plan for both.

What makes EHR-integrated telehealth hard

• Every health system's build is different. Two Epic customers can have different visit types, note templates and security settings. Budget for per-site configuration and testing, not only per-vendor work.
• Write-back is harder than read. Reading a medication list is standard. Filing a signed note to the right encounter, with the right document type, in the right department, is where projects stall.
• Security review comes first. Expect a vendor security questionnaire, evidence of controls, a BAA and sometimes a penetration test report before any production credentials are issued.

For inspectable engineering work, review Nirmitee’s open-source headless EHR and our EHR and EMR integration services. Latest published result for the headless EHR, run June 11, 2026: ONC (g)(10) Inferno test kit, SMART STU2 standalone patient launch: 47 of 47 tests passing.

Security engineering for telehealth

HIPAA's Security Rule tells you what to protect. The controls below are how telehealth platforms actually do it.

Identity and access

• MFA for every staff and clinician account, and step-up authentication for sensitive actions (EPCS signing already requires it under DEA rules).
• Role-based access control with least privilege: a scheduler does not need clinical notes; a billing user does not need video recordings.
• Break-glass access with mandatory reason capture and review.
• For patients, strong password rules or passwordless login, device binding for mobile, and account recovery that cannot be used to take over someone else's record.

Encryption

• In transit: TLS 1.2 or higher everywhere. WebRTC media is encrypted with DTLS-SRTP by design. If you use an SFU (most group-video vendors do), media is decrypted at the server unless you add end-to-end encryption, so the SFU operator must be under a BAA.
• At rest: encrypt databases, object storage, backups and search indexes with managed keys, and document key access, rotation and recovery. Encryption at rest is an “addressable” safeguard under the current Security Rule, which means assessed and documented, not optional; enterprise security reviews expect it as standard.

Audit logging

Log who accessed which patient record, when, from where and what they did, including reads, not only writes. Log video session events (joined, left, recording started, recording stopped), prescription events and exports. Store audit logs in append-only or write-once storage, separate from application data, and retain them in line with your retention policy (HIPAA requires Security Rule documentation to be kept for six years under 45 CFR 164.316). Make the logs searchable so compliance staff can answer "who looked at this patient" in minutes.

Session recording policy

Decide recording policy before you build the feature:

• Default off. Most telehealth visits are not recorded, and recordings create a large, sensitive data set that must be secured, retained and produced on request.
• If you record, get consent in line with state law (several states require all-party consent to record), show a visible indicator during recording, store recordings encrypted with restricted access, and set automatic deletion after the retention period.
• AI scribes create audio or transcripts even when you do not "record" the visit. Treat that audio under the same policy and delete it once the note is signed, unless you have a documented reason to keep it.

Application and infrastructure security

• Host on a HIPAA-eligible cloud account covered by a BAA, and use only services on the provider's HIPAA-eligible list.
• Keep PHI out of logs, error trackers, push notifications, URLs and analytics events.
• Run dependency scanning, static analysis and an external penetration test before launch and at least annually.
• Build incident response runbooks that cover both HIPAA breach notification and, for non-HIPAA products, the FTC Health Breach Notification Rule.

Nirmitee’s operating company, Elintex Technologies Pvt Ltd, holds ISO 27001:2022 certification, and Nirmitee signs BAAs where applicable.

How to build a telemedicine app: the step-by-step process

1. Define the care model before the software. Which conditions, which clinicians, which states, synchronous or async, cash or insurance. Write the clinical workflow on one page with your medical director. Software follows the care model, not the other way round.
2. Map the regulatory surface. Based on the care model: HIPAA or FTC HBNR, controlled substances or not, Medicare or commercial payers, which state licenses, which accessibility obligations. This list becomes acceptance criteria.
3. Choose build, buy or hybrid for each component. Map the data and vendor roles, confirm applicable BAAs and service terms, and verify the selected configuration before real patient data enters the system.
4. Design the domain model and integration boundary together. FHIR resources give you a clean exchange model for patients, encounters and observations. Choose internal storage around the product’s requirements and define transformations explicitly, because each EHR still adds its own integration work.
5. Prototype the two critical journeys (patient booking to visit, clinician queue to signed note) and test them with real clinicians and patients, including older patients on phones.
6. Build the MVP in short iterations, with security controls (MFA, audit logging, encryption) in the first sprint, not the last.
7. Integrate one EHR, one e-prescribing vendor and one payment or eligibility path. Each integration gets its own test plan against the vendor sandbox.
8. Test like a clinic. Load-test video at peak concurrency, test on poor networks, run accessibility audits against WCAG 2.1 AA, and complete a penetration test.
9. Pilot with a small group of clinicians for several weeks. Measure time in waiting room, call quality, no-shows, documentation time and clinician satisfaction.
10. Launch, then run it as a clinical service. Monitoring, on-call support during clinic hours, incident response and a release process that does not break clinics mid-day.

Telemedicine app development timeline by phase

For context, Relia Software publishes 3 to 5 months for a simple MVP and 8 to 12+ months for an enterprise platform (checked September 26, 2026). The phases below typically overlap, and we size each one to your scope and EHR access timeline.

The phase most teams underestimate is not development. It is the EHR customer's own approval and configuration process, which runs on the health system's calendar. Start it during discovery.

Telemedicine app development cost: drivers and published ranges

A single number for telemedicine app development cost is misleading, because two apps with the same screens can differ several times over in cost depending on integrations and compliance. Here is what the most-read guides publish, and what actually moves the number.

Published industry ranges

Ranges checked September 2026; scope definitions differ by source. Nirmitee estimates after a short discovery, with third-party fees listed separately.

The cost drivers that matter

• Number and depth of EHR integrations. Read-only SMART launch into one EHR is a modest line item. Bidirectional integration with scheduling and note write-back across several EHRs is often the largest single cost.
• Controlled-substance prescribing. EPCS, PDMP checks and configurable prescribing rules add vendor fees and engineering.
• Insurance billing. Eligibility, claims and payer rules add a whole subsystem compared with cash-pay.
• Number of platforms. Native iOS, native Android and web cost more than one cross-platform codebase plus web.
• Async protocol count. Each clinical protocol needs clinical authoring, logic, testing and sign-off.
• RPM. Device integrations, alerting and billing-grade time tracking.
• Video approach. Managed APIs cost per participant-minute; self-hosted costs engineering and operations time.
• Compliance evidence. Penetration tests, accessibility audits and documentation for enterprise security reviews.
• Run costs after launch. Hosting, video minutes, SMS, e-prescribing fees, support and ongoing maintenance, plus regulatory updates such as the DEA special registration rule.

Common failure modes in telemedicine projects

1. Treating video as the product. Video is a commodity you can rent. The product is the workflow around it: intake, routing, documentation, prescribing and follow-up.
2. Ignoring the clinician. If the clinician workspace adds clicks to a visit, clinicians will stop using it. Measure documentation time from the pilot onwards.
3. Missing vendor-role review. A business associate handling PHI without the required BAA is a compliance issue. Inventory analytics, messaging, support and AI services, and verify actual roles, contracts and permitted features.
4. Tracking pixels on logged-in pages. The FTC's GoodRx and BetterHelp cases are the reference points. Keep ad tech off any page that reveals health information.
5. Hard-coding policy. Version approved rules and effective dates. Keep a review and release process for changes that require new evidence, workflow or vendor support.
6. No licensure checks at the moment of the visit. Patients travel. Confirm location at check-in.
7. Underestimating EHR approvals. The code can be ready months before the health system's approval, build and go-live window.
8. No plan for bad networks. Without TURN relays, audio-only fallback and reconnect logic, a meaningful share of visits will fail.
9. Accessibility as an afterthought. Retrofitting WCAG 2.1 AA into a finished app is far more expensive than designing for it.
10. No operational ownership. A telemedicine platform is a clinical service and needs monitoring, clinic-hours support and careful releases.

Release checklist: prove the visit can recover

Use synthetic patients and test accounts. Record the expected result, responsible reviewer and evidence for each scenario before approving the pilot.

Build your telemedicine platform with a team that knows the integrations

Define the care model first, select infrastructure with the required contracts and safeguards, and invest in the clinician workflow and EHR integration. Record policy owners and test regulatory changes before releasing them.

Nirmitee builds telehealth platforms for US virtual care companies and provider groups through its custom healthcare software development practice, with deep experience in SMART on FHIR, HL7v2 and Mirth Connect. Our healthcare interoperability team connects telemedicine apps to Epic, Oracle Health, athenahealth and eClinicalWorks. If you are planning a telemedicine app, talk to our team.

Sources

Regulatory and pricing references reviewed September 26, 2026.

1. DEA and HHS, Fourth Temporary Extension of COVID-19 Telemedicine Flexibilities for Prescription of Controlled Medications, Federal Register, Dec 31, 2025: View source
2. DEA press release, DEA Extends Telemedicine Flexibilities, Dec 31, 2025: View source
3. Telehealth.HHS.gov, Medicare payment policies: View source
4. CMS, CY 2026 Physician Fee Schedule final rule, Federal Register, Nov 5, 2025: View source
5. HHS OCR, Expiration of COVID-19 PHE HIPAA Notifications of Enforcement Discretion, Apr 11, 2023: View source
6. HHS, Breach Notification Rule: View source
7. HHS, HIPAA Security Rule NPRM, Federal Register, Jan 6, 2025: View source
8. eCFR, 45 CFR Part 164 Subpart C (Security Rule): View source
9. FTC, Health Breach Notification Rule, Federal Register, May 30, 2024: View source
10. FTC, Complying with FTC's Health Breach Notification Rule: View source
11. FTC, GoodRx enforcement action, Feb 2023: View source
12. FTC, BetterHelp final order, Jul 2023: View source
13. eCFR, 21 CFR Part 1311 (EPCS): View source
14. CMS, EPCS Program: View source
15. Interstate Medical Licensure Compact Commission: View source
16. HHS OCR, Extension of Compliance Dates, Section 504 web and mobile accessibility, Federal Register, May 11, 2026: View source
17. ASTP/ONC, HTI-1 Final Rule: View source
18. Twilio, Twilio Video Will Remain a Standalone Product: View source
19. Vonage, Does Vonage Video API provide HIPAA BAAs: View source
20. Zoom, HIPAA-ready: View source
21. Daily, HIPAA guide: View source
22. AWS, HIPAA Eligible Services Reference: View source
23. Epic on FHIR: View source
24. Published development estimates: Aalpha and Relia Software; accessed September 26, 2026.