Telemedicine App Development: The Five Things Every Visit Has to Know About Itself

The short version

The video call is the easy part. What stalls a telemedicine build is that five facts about a single visit change independently of your code, and most builds store all five as booleans. Where the patient physically was. What the coverage rule said on that date. Which modality was used. Whether consent covered that modality in that state at that moment. And which vendors touched the patient data on the way through.

Get those five wrong and the app still works. It demos beautifully. What breaks is everything downstream: the claim gets denied, the clinician turns out to have been unlicensed for that visit, the audit asks for a consent record that was overwritten, and the answer to "what did we do on March 4th" is a shrug.

Here is the part nobody selling telemedicine app development says out loud. In the eleven months between September 2025 and February 2026, the rules that decide whether a US telehealth visit gets paid lapsed twice and were restored twice. Medicare's pandemic-era flexibilities expired on September 30, 2025, came back, expired again on January 30, 2026, and were restored on February 3, 2026 when the Consolidated Appropriations Act, 2026 was signed, this time with an end date of December 31, 2027. If your eligibility logic is an if statement, you did not ship a feature. You shipped a bug with a date on it.

This page is about the parts a feature list leaves out. Read it before you brief anyone.

What does a telemedicine app development company actually have to build?

Every vendor page lists the same eight things. Video consultation. Scheduling with a waiting room. Secure chat. E-prescribing. Payments. EHR integration. Patient records. Clinician dashboard.

All of it is true and none of it is the hard part. Video is a solved problem you buy. Scheduling is a calendar with rules. Chat is chat. A competent team ships that whole list.

What separates a telemedicine build that survives its first audit from one that does not is the record of the encounter, and the encounter is not a row with a video URL on it. A telehealth visit is a legal event that happened at a place, at a time, under a rule set, through a modality, with a consent behind it and a chain of vendors underneath it. Six facts. Your database has to carry all six, per visit, forever, and it has to carry the versions of them that were true then rather than the ones that are true now.

Most builds we are asked to look at carry two. They know the appointment time and they know the clinician. Location is inferred from the patient's billing address, which is where their card lives and not where they were sitting. Consent is a boolean called consented that flipped to true at signup. Modality is not stored at all, because the video service knows and nobody thought to ask it.

That gap is what turns a working product into a rebuild quote. So the rest of this page walks the five facts one at a time, and what each one looks like when it is stored properly.

Why is the patient's location the first thing your app has to store?

Because the clinician has to be licensed where the patient is, not where the clinician is.

This is the single most misunderstood rule in telemedicine, and it has not changed while everything around it did. A doctor sitting in Boston treating a patient who happens to be in Ohio that week is practising in Ohio, and needs an Ohio licence to do it. Practice is governed by the law of the place the patient is physically located during the encounter.

The compacts help with the paperwork and change nothing about the rule. The Interstate Medical Licensure Compact now covers 43 member states plus the District of Columbia and Guam, with Connecticut confirmed as a full participant on March 15, 2026 and Alaska legislated to join as the 44th. In March 2026 alone the Compact issued 3,633 physician licences. That is a faster path to holding many licences. It is not one licence that works everywhere, and the clinician stays subject to the rules of the state the patient is in.

So here is what your app has to do, and it is a product decision long before it is a code decision. At booking, and again at the start of the visit, ask the patient where they are right now. Not their address on file. Where they are, today, for this call. Then check that answer against the clinician's licence set for that date, and refuse the booking if it does not match.

Every part of that sentence is a schema requirement:

Teams get this wrong in a specific and predictable way. They store one state per clinician, they read the patient's profile address, and they run the check once at signup. It works until the first patient drives across a state line, and then it fails silently, because nothing in the software knows anything went wrong.

Why does coverage have to be a dated table instead of an if statement?

Because the coverage rules changed four times in under a year, and two of those changes were retroactive.

Here is the actual sequence, and it is worth reading slowly if you are about to hardcode anything. Medicare's pandemic-era telehealth flexibilities, which allowed the patient's home to be an originating site, removed the rural geographic restriction and covered audio-only visits, expired on September 30, 2025. They were restored when the government shutdown ended, through January 30, 2026. They lapsed again on January 31, 2026, and for three days Medicare telehealth reverted to the pre-pandemic rules, meaning the patient had to be in a designated rural area at an approved facility. On February 3, 2026 the Consolidated Appropriations Act, 2026 was signed and put the flexibilities back, this time through December 31, 2027.

Now look forward, because the cliff edges are already on the calendar:

An app that treats "telehealth is covered" as a constant is wrong on at least four dates in this list, and wrong differently depending on the specialty. That is not a compliance detail. That is your revenue.

What it looks like built properly is a policy table with effective dates, queried by the date of service:

policy_rule
  payer            medicare | medicaid_<state> | commercial_<plan>
  service_category behavioral | pt_ot_slp | general_medical | ...
  modality         video | audio_only | store_and_forward | rpm
  origin_rule      any_location | rural_facility_only | ...
  effective_from   date
  effective_to     date | null
  source           the citation, so an auditor can check it

Then eligibility is a lookup against the date of the encounter, not today's date, and the resolved rule is written into the encounter record. Three properties fall out of that design and all three matter.

You can answer "was this visit billable when it happened" two years later without a lawyer. You can reprocess a period retroactively when a rule is restored after a lapse, which is exactly what happened in October 2025 and again in February 2026, by re-running the lookup rather than re-deploying. And you can add a payer without touching application code, which matters more than it sounds, because commercial plans and state Medicaid programs each carry their own version of every rule above.

We have argued this exact case before in a different setting, where a system's business rules were welded into the code and every policy change turned into a release. The fix there was the same shape as the fix here. Data that changes goes in a table, with dates on it, and the code reads the table.

Does the modality change what your app has to record?

Yes, and it is the fact most often thrown away.

Audio-only is not a degraded video call. It is a separate modality with its own coverage rule, its own consent expectations in several states, and its own billing codes. Under the current federal position, audio-only Medicare telehealth is permitted through December 31, 2027, and permanently for behavioral health. Which means the difference between a visit that gets paid and one that does not can be whether the patient's camera worked.

That sounds like a trivial thing to log until you look at how most builds handle it. The video vendor knows the call fell back to audio. The application does not, because nobody wired the callback. So the encounter record says "video", the claim says video, and the note in the chart says the patient's connection was poor. Three sources, two of them wrong.

The volumes here are not marginal. Fair Health's tracker put telehealth at 5.51% of medical claim lines in the first quarter of 2026, up from 5.01% in the fourth quarter of 2025, with 18.4% of commercially insured patients filing at least one telehealth claim in that quarter, up from 17.3%. And the mix is lopsided in a way that shapes what you build: 52.1% of patients with a telehealth claim had one for a mental health condition. Telemedicine, in practice, is mostly behavioral health, which is also the one category with permanent coverage from home. If you are choosing which flow to make excellent first, that is your answer.

So the encounter record carries the modality that actually happened, captured from the session itself rather than from the appointment type. It carries a fallback event if the call downgraded mid-visit, with the timestamp. And the consent check re-runs when the modality changes, which is the next fact.

Why is consent not a checkbox on the patient record?

Because consent in telehealth is scoped to a state, a modality, a provider and a moment, and a boolean carries none of those.

The rules genuinely differ by state, and the differences are the kind that break a one-size data model. California requires the provider to obtain consent once before the initial delivery of telehealth services, verbal or written, documented in the medical record. New York expects consent to be documented before each telehealth encounter. Alaska's Medicaid programme wants consent to the telehealth modality obtained before services are rendered and the receipt of it documented in the member's file. Texas requires written consent and adds specific language requirements for mental health services. Across nearly all jurisdictions, consent has to be secured before or at the start of the encounter and documented in the record, and it covers audio-only, store-and-forward and remote monitoring, not just video.

Some states re-trigger consent at each new episode of care. Some re-trigger it when the modality changes. A patient who consented to a video visit in California and then takes an audio-only follow-up call while visiting New York has, depending on how you read three different rule sets, either valid consent or none.

The data model that survives this is an append-only consent ledger:

consent_record
  patient_id
  provider_or_practice_id
  jurisdiction        the patient's state at the time
  modality            video | audio_only | store_and_forward | rpm
  consent_text_version  which exact wording was shown
  captured_at         timestamp
  captured_by         staff member, or "patient_self_service"
  method              written | verbal
  response            the affirmative answer as recorded

Never updated. Only appended. The encounter then references the consent record that was valid for it, and the audit question "show me the consent for this visit" has a single row as its answer, including the exact wording the patient saw, which is the part teams forget to version and the part an auditor asks for first.

If you only take one schema change from this page, take this one. It is cheap to build on day one and expensive to reconstruct later, because the information you need was never captured.

Who is holding the patient data, and did every one of them sign a BAA?

This is where telemedicine builds carry risk they do not know about, and the reason is a rule that expired three years ago and is still misremembered.

During the public health emergency, the Office for Civil Rights said it would not impose penalties for good-faith telehealth delivered over non-public-facing consumer tools. That discretion ended. The emergency expired on May 11, 2023, OCR gave a 90-day transition, and at 11:59pm on August 9, 2023 the telehealth notification stopped being a basis for withholding penalties. Full HIPAA obligations have applied to telehealth ever since. Penalties for the lowest tier, unknowing violations, run from roughly 127 dollars to roughly 60,973 dollars per violation, adjusted annually.

The practical consequence for a build is a chain, not a checkbox. Trace one visit and list every party that touches protected health information on the way:

Each one is a business associate and each one needs a signed business associate agreement. Two of that list catch teams out consistently. Analytics and crash SDKs get added in an afternoon and quietly ship screen names, patient identifiers and sometimes the contents of a form field to a vendor who has signed nothing. And the AI layer, which is the newest and the fastest-moving, where the question is not only whether there is a business associate agreement but whether the provider trains on your data and where inference physically runs. We wrote separately about building AI features inside a HIPAA boundary, because the answer changes depending on which of those two things you need.

The design rule we apply is simple to state and takes discipline to hold. Keep the number of parties touching protected health information as small as the product allows, and know the list by name. A telemedicine app with four business associates and four signed agreements is in better shape than one with eleven and a spreadsheet that was last updated at launch.

Which part of a telemedicine stack is most likely to move under you?

The video layer, and the last three years are a useful lesson in why you should not weld yourself to it.

Twilio announced end of life for Programmable Video, originally set for December 5, 2024. After customer pushback it extended that by two years to December 5, 2026, pointing customers at the Zoom Video SDK as an alternative. Then it reversed the decision, and Programmable Video remains a standalone product with continued investment.

Read that sequence as an engineering brief rather than as gossip about one vendor. Over roughly two years, the video layer under a large number of healthcare products was scheduled for deletion, rescheduled, and then reinstated. Teams that had wrapped video behind their own interface spent a meeting on it. Teams that had scattered vendor SDK calls through their appointment code, their recording pipeline and their React components spent a quarter planning a migration they ultimately did not need.

So the video vendor sits behind an adapter with your own interface in front of it: start a session, join a session, record, stop, retrieve the artefact, report quality. Session identifiers are yours, not theirs. Recordings land in your storage, under your retention policy, not in a vendor bucket whose lifecycle you do not control. This is the same adapter argument we make for EHR integration, where FHIR, HL7v2 and CDA each need their own translation layer and the application above should not be able to tell which one it is talking to. The reasoning is identical. The parts of a healthcare system most likely to change are the ones you did not write.

Can your app prescribe, and what does that mean in code?

Only if you have decided, explicitly, which of three prescribing situations you are in, because they carry different requirements and different expiry dates.

Non-controlled prescribing over telehealth is ordinary practice in every state, subject to the same standard of care as an in-person visit, and it needs e-prescribing integration and a drug database rather than a special permission.

Controlled substances are the live question. Under the Ryan Haight Online Pharmacy Consumer Protection Act of 2008, a practitioner may prescribe controlled substances remotely only after at least one in-person medical evaluation, with limited exceptions. The flexibilities introduced in March 2020 suspended that requirement, and they have been extended four times. The fourth temporary rule was issued on December 31, 2025 and runs through December 31, 2026, allowing Schedule II to V prescribing via telemedicine without a prior in-person visit for the whole of this year. A permanent framework, including a proposed Special Registration for Telemedicine, is still pending.

That date is now under four months away, and this is the third dated rule on this page. Which is the argument for the policy table all over again. A build that hardcodes "controlled substances allowed via telehealth" has an expiry it does not know about, and a build that hardcodes the opposite is refusing legal prescriptions today.

Substance use disorder treatment adds a further layer, because those records fall under 42 CFR Part 2 as well as HIPAA, with stricter consent and disclosure rules. If your product touches addiction medicine, that is a distinct access-control problem and not a variation on the general one.

Why do the app stores reject telemedicine apps?

Because both stores treat health as a regulated category, and both check who submitted the app before they look at what it does.

Apple's guideline 1.4.1 requires apps that claim to diagnose or treat health conditions to show documentation of the relevant regulatory clearance, and apps that connect to external medical hardware to provide documentation of clearance for that hardware plus evidence the app uses it as described. Separately, guideline 5.1.1(ix) lists healthcare among the highly regulated fields where the app should be submitted by the legal entity providing the service and not by an individual developer. A founder's personal developer account fails that check regardless of code quality.

Google Play now requires every published app to complete the Health apps declaration in Play Console, including apps in closed and open testing, and existing health apps had until January 28, 2026 to migrate to a verified Organization Account. From January 2026 the store also added a Medical Device labelling flow and tighter justification requirements for Health Connect data access.

None of this is difficult. All of it takes calendar time you have not budgeted, which is why it belongs in week one of the plan rather than the week before launch. Enrol as an organisation. Complete the declaration. Have the regulatory documentation ready if the product makes any claim that could be read as diagnosis or treatment, and get a straight answer from your clinical lead about whether it does, because "it just shows the patient their readings" and "it tells the patient what their readings mean" sit on opposite sides of that line.

Who does not need most of this?

A fair amount of what you just read does not apply to you, and any telemedicine app development company that tells you otherwise is selling scope.

Cash-pay wellness with no diagnosis and no prescription carries no billing rules to model, because there is no payer. Licensure and consent still apply if a licensed clinician is delivering care. The coverage table does not.

Products outside the United States inherit an entirely different rule set. Medicare, the DEA, HIPAA and state licensure are US constructs. The five facts still need storing, because the UK, the EU, the UAE and India each have their own version of licensure scope, consent, data protection and prescribing authority. The citations change. The schema does not.

Software sold to a provider organisation that carries its own compliance may be a business associate rather than a covered entity, which changes what you owe from "hold the whole programme" to "hold the agreement and the technical safeguards". Smaller obligation, not zero.

A scheduling or intake layer that never carries clinical content may sit outside most of this. That is rarer than it sounds, because intake forms tend to collect symptoms, and symptoms are protected health information.

If you are in one of those four, build the encounter model properly anyway and skip the rest. The encounter model is what you cannot retrofit.

When is a rebuild honestly the right answer?

Three cases, and outside them we would rather fix what exists.

One. The encounter has no identity. Visits are rows joined from an appointments table, a video vendor's dashboard and a chat log, with no single record that says what happened, where, through what, under what consent. You cannot add that by writing a migration, because the historical data to fill it was never captured. New model going forward, old data preserved read-only and clearly marked as incomplete.

Two. Protected health information is spread across systems nobody has mapped. If it takes a week to answer "which vendors hold patient data", the answer is not a document. It is an architecture problem, and the fix is consolidation, which is a rebuild of the data layer even when the application above it survives.

Three. Clinical logic is welded into the interface. Eligibility rules, consent rules and prescribing rules living inside React components mean every regulatory change is a front-end release and every audit question is a code read. That is the case for extracting a rules layer, which is a real rewrite of the middle and is worth doing once.

Everything else we have seen is repairable in place. A missing consent ledger is an addition. A hardcoded coverage rule becomes a table. A vendor SDK gets an adapter. A missing business associate agreement is a procurement task. Those are weeks, not quarters, and we will say so rather than quote the bigger number. That preference is not specific to healthcare, and we have written about how often a rewrite gets quoted when slices would do.

What should you ask a telemedicine app development company before you sign?

Six questions. The answers tell you more than any portfolio.

How does Geminate Solutions run a telemedicine engagement?

We start with a written read of what exists, before any quote.

A senior engineer reads your data model, your booking flow, your consent capture, your vendor list and your store configuration against the five facts on this page, then says in writing which ones your build already carries, which are missing, and whether anything in the code justifies a rebuild rather than an addition. If the honest answer is that you need four weeks of schema work and not a new product, the read says that.

What we bring to the build itself is healthcare software development with the integration work already behind us, FHIR and HL7v2 adapters we have shipped rather than read about, and the same engineering discipline that holds our multi-tenant EdTech platform at 250,000 daily users. Load is load. A consultation queue at peak hour behaves like a submission queue at a deadline, and we have built both.

What we will not do is claim to certify your HIPAA compliance. That depends on your organisation's own policies and a third-party audit, and no development partner can sign it off for you. What a partner can do is build the system so the audit is a formality instead of a six-month scramble, and the five facts above are most of the difference between those two outcomes.