Primary and Urgent Care Telemedicine

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

If you are building a virtual urgent care or on-demand primary care product, you are entering the most crowded, most price-sensitive corner of telehealth — and the one where a safety failure is most likely. This article is for the founder, product manager, or clinical lead who needs to understand the moving parts before scoping a build: how the patient flows through the system, where the clinical safety rails go, which regulatory dials change yearly, and why the whole thing lives or dies on cost per consult. Get the triage and the routing right and you have a genuinely useful, defensible product. Get them wrong and you have a liability machine that prints antibiotics.

What "primary and urgent care telemedicine" actually means

Three words in that phrase do a lot of work, so let us define them in plain language before going further.

Urgent care is the band of medicine between a primary care appointment and the emergency room: conditions that need attention today but are not life-threatening. A sore throat, a suspected urinary tract infection, pink eye, a minor rash, a sprained ankle, a medication that ran out. In a physical clinic these are walk-ins. On a telemedicine platform they become the on-demand visit — the patient opens an app, describes the problem, and is connected to whichever clinician is free.

Primary care is the ongoing relationship: your regular doctor, who manages chronic conditions, orders screening, and knows your history. Delivered over video, much of routine primary care — a blood-pressure check-in, a refill, a lab-result review — works well. The line between the two blurs in practice, which is why this article treats them together: both are high-volume, mostly low-acuity, mostly scheduled-or-instant short visits, and both share the same compliance and safety spine.

What unites them, and separates them from the rest of this section's specialty playbooks, is volume at low acuity. A behavioral-health platform (covered in mental and behavioral health telemedicine) runs long, scheduled, deeply sensitive sessions. A tele-stroke platform runs rare, ultra-high-stakes, millisecond-sensitive consults. Urgent care runs the opposite: many short visits, most of them routine, a few of them hiding something serious. The whole product design follows from that one fact.

The on-demand patient flow, end to end

The core of the product is a queue. A patient arrives with a problem, waits a short time, sees a clinician, and leaves with an outcome. Everything else is built around making that loop fast, safe, and cheap.

Figure 1. The on-demand urgent care loop. Triage sits before the queue on purpose — it is cheaper and safer to route a patient correctly before a clinician's time is spent.

Walk through it as the patient experiences it.

Intake and triage. The patient describes the problem, usually by answering structured questions before any clinician is involved. This is the most important screen in the product. A good intake flow does three jobs at once: it collects the clinical information the clinician will need, it captures the patient's current physical location (which determines which laws apply — more on that below), and it screens for danger. The contract that lets your vendors handle this patient data, called a Business Associate Agreement (BAA), must already be signed with every system in the path; intake data is Protected Health Information (PHI) — any health data tied to an identifiable person — from the first keystroke. We cover the data layer in depth in HIPAA for telemedicine product teams.

The queue and waiting room. Low-acuity telehealth lives and dies on wait time. The waiting room is not a loading spinner — it is a managed queue with position, estimated wait, a tech check, and a way to reach the patient if the connection drops. We treat queue design as its own discipline in the telemedicine waiting room: queueing, triage, and provider readiness.

The consult. The visit itself is short — often five to ten minutes — and frequently does not need pristine 1080p video. A clinician examining a rash needs a clear still image more than smooth motion; a clinician discussing a refill barely needs video at all. Build for graceful degradation to a lower resolution or audio-only when the network is poor, because your patients are on home Wi-Fi and cellular, not a hospital backbone. See connection reliability: reconnection, network changes, and graceful degradation.

The outcome. Every visit ends in one of four places: self-care advice, an electronic prescription, a referral to in-person care (a lab, an imaging center, a clinic), or an escalation to emergency services. The product's job is to make the right one of those happen quickly and to document why.

Triage and escalation: the safety rail that defines the product

Here is the uncomfortable truth of low-acuity, high-volume telemedicine: most patients are fine, which trains everyone — patients, clinicians, and the system — to assume the next one is fine too. The rare patient with chest pain that is actually a heart attack, or a headache that is actually a stroke, is the one your design exists to catch.

A triage protocol is the set of rules that screens every patient for severity and routes them to the right level of care before, during, and after the visit. Its purpose is to prevent the system from underestimating how sick someone is. During screening, the platform and the clinician look for red flags — warning signs that the patient needs a higher level of care now. Classic examples include difficulty breathing, chest pain, a low oxygen reading, uncontrolled bleeding, new confusion or slurred speech, or a sudden severe headache. When a red flag appears, the correct action is not a video visit — it is a fast, documented handoff to in-person or emergency care.

Figure 2. The triage and escalation decision tree. The escalation branch must exist and be logged before the first patient ever connects — it is not a feature you add later.

Three design rules follow from this.

First, screen before the queue, not only in the visit. Catching a red flag at intake saves a clinician's time and gets a sick patient moving sooner. The structured intake questions should hard-stop a patient reporting stroke or heart-attack symptoms and direct them to call emergency services immediately, with that event logged.

Second, give the clinician a one-tap escalation path. When a clinician decides mid-visit that the patient needs the emergency department, the product should make the handoff frictionless: surface the patient's confirmed location, provide local emergency numbers, generate a visit summary, and record the decision. A handoff that depends on the clinician remembering a phone number is a handoff that fails under load.

Third, log every branch. Whether the outcome is self-care, a prescription, a referral, or a 911 escalation, the reasoning is part of the medical record. In a vertical built on speed, the audit trail is what proves the speed did not come at the cost of safety.

The common mistake: the antibiotic problem

The most documented failure mode in direct-to-consumer urgent care telehealth is over-prescribing antibiotics. The research is blunt about it. One widely cited study found antibiotics were prescribed at 52% of direct-to-consumer telemedicine visits, compared with 42% of in-person urgent care visits and 31% of primary care visits, and that prescribing matched clinical guidelines less often over telehealth (59% guideline-concordant) than in urgent care (67%) or primary care (78%).¹ The pattern has a simple cause: a two-minute visit, a patient who wants a prescription, and a clinician with no relationship and no easy way to say "wait and see" produces a prescription.

This is a product problem, not only a clinician problem. Build antibiotic stewardship — the practice of prescribing antibiotics only when guidelines support them — into the workflow: decision support at the point of prescribing, guideline prompts for the common respiratory complaints, watchful-waiting scripts the clinician can send instead of a prescription, and prescribing analytics that flag outlier patterns. A network that did exactly this cut antibiotic prescribing for respiratory conditions from 48% to 33%.² Stewardship is both a safety feature and, increasingly, a contractual expectation from the payers and health systems you sell to.

The rules that change every year — build them as configuration

This is the part founders most often underestimate. Three separate bodies of law shape what an urgent care telemedicine product can do, and all three change on a yearly or sub-yearly cadence. If you hard-code them, every change is a code release. Build them as configuration and a change is a settings edit.

Figure 3. The three dials that move on their own clocks. The dates inside the boxes change; the structure does not. Model each as a rule the product reads, not a constant in the code.

Reimbursement: dated and jurisdictional

Whether and how a telehealth visit gets paid for depends on the payer, the patient's location, and the calendar year. For Medicare, a long list of pandemic-era flexibilities — letting patients receive telehealth at home, removing the rule that they be in a rural area, and allowing audio-only visits — has been extended repeatedly rather than made permanent. As of this writing, the latest extension, enacted in the Consolidated Appropriations Act, 2026, carries most of those non-behavioral flexibilities through December 31, 2027.³⁴ Audio-only non-behavioral telehealth is covered through the same date.³

Two things matter for your build. First, cite the year and re-check it: these dates have moved several times and lapsed briefly in early 2026 before being restored.⁴ Second, Medicare is only one payer — commercial plans and state Medicaid programs each set their own telehealth coverage and "parity" rules, which vary by state. Treat coverage logic as data your billing system reads, not a fixed assumption. We unpack the payment mechanics in reimbursement and the rules that shape the product and payments, insurance, and claims.

Prescribing: the Ryan Haight clock

Most urgent care prescriptions are ordinary, non-controlled medications, sent electronically to the patient's pharmacy. That path is well-established; see e-prescribing and EPCS.

Controlled substances are different. The Ryan Haight Act of 2008 generally requires a clinician to conduct an in-person medical evaluation before prescribing a controlled substance over the internet.⁵ Since 2020 the Drug Enforcement Administration (DEA) has waived that in-person requirement through a series of temporary extensions. The current one — the Fourth Temporary Extension, published December 31, 2025 — keeps remote prescribing of controlled substances available through December 31, 2026 while the DEA finalizes a permanent rule.⁶ For an urgent care product, this means the in-person gate for controlled substances is a dated switch you may need to flip — so build it as a rule, not an assumption.

Licensing: care happens where the patient sits

The single most important compliance fact in cross-state telemedicine is this: a clinician is generally practicing medicine in the state where the patient is physically located at the time of the visit, and must hold a license (or a recognized privilege) for that state. This is why your intake must capture the patient's current location every time, not once at signup. A patient who created an account in Texas and opens the app from a hotel in New York is a New York visit.

Getting licensed in many states used to be slow and manual. The Interstate Medical Licensure Compact (IMLC) is an expedited pathway that lets qualifying physicians obtain licenses in multiple member states faster — though it is a faster route to separate state licenses, not a single national license. As of early 2026 it covers a large majority of states, with a few notable holdouts that still require direct application.⁷ For your product, the takeaway is architectural: scheduling and clinician-matching must know each clinician's licensed states and each patient's current state, and only ever offer a legal match. The deeper treatment of licensing and prescribing rules lives in state and specialty rules: licensing and prescribing.

Synchronous, asynchronous, and the cheapest safe path

Not every urgent care problem needs a live video visit. Synchronous care is real-time — a video or phone call. Asynchronous care, also called store-and-forward, lets the patient submit a description, photos, or answers, and a clinician reviews and responds later without both being online at once.

For a narrow set of well-defined, low-risk complaints — a classic urinary tract infection, a medication refill, a simple rash with a clear photo — an asynchronous "e-visit" can be safe, satisfying, and dramatically cheaper, because it removes the most expensive ingredient: a clinician's synchronous, undivided time. Research has found asynchronous management equivalent to live video for several well-controlled conditions.⁸ The design pattern that wins is a hybrid: route the simplest, clearly-scoped complaints to an asynchronous path with tight clinical guardrails, and reserve live video for everything that needs examination, conversation, or judgment. The triage layer is what decides which path a patient takes — another reason it is the heart of the product.

Keep the three modes distinct in your data model and your compliance analysis, because they carry different documentation, consent, and latency requirements. Blurring them is a common source of both clinical and compliance error.

The economics: why scale is the whole game

Urgent care telemedicine is a volume business with thin margins per visit, so the unit economics decide everything. Walk the numbers out loud.

A cash-pay virtual urgent care visit in the United States typically prices somewhere in the $40–$100 range, with a median around $82.⁹ Compare that to roughly $150–$280 for a bricks-and-mortar urgent care visit and an average uninsured emergency-room visit of about $2,715 in 2025.⁹ The patient value proposition is obvious: for a non-emergency complaint, the virtual visit is a fraction of the alternatives. But that same low price means the platform earns little per visit, so the only way the model works is throughput.

Figure 4. The price gap that drives demand, and the utilization lever that decides whether the platform survives it. Lower price per visit only works if provider time stays busy and handle times stay short.

Three levers move the unit economics, and the product team owns all three.

Provider utilization. A clinician paid for an hour who sees two patients costs twice as much per visit as one who sees four. The queue, the matching engine, and the intake-before-consult design exist largely to keep clinicians busy with prepared patients. Idle provider time is the largest controllable cost in the model.

Handle time. Shorter visits mean more visits per hour — but cutting time is exactly what creates the antibiotic and missed-red-flag risks above. The resolution is not shorter visits; it is moving work out of the synchronous visit: structured intake that arrives with the patient, decision support that speeds the clinician without rushing them, and asynchronous handling of the simplest cases.

The asynchronous discount. Every complaint safely resolved asynchronously is a complaint that did not consume a clinician's live, undivided time. A hybrid model that moves even a modest share of volume to e-visits meaningfully lowers blended cost per consult.

Do the arithmetic for your own plan before you build. If your fully-loaded clinician cost is $120 per hour and the average synchronous visit takes 12 minutes, that is five visits per hour and roughly $24 of clinician cost per visit before any platform, payment-processing, or compliance overhead. Push the visit to 15 minutes and the same hour yields four visits at $30 each — a 25% jump in the largest line item. These are illustrative numbers; run them with your real costs. The full model is in the telemedicine cost model.

A reference architecture, briefly

The urgent care build is the general telemedicine platform — covered in full in the anatomy of a telemedicine platform — tuned for throughput. The pieces that matter most here:

A structured intake and triage engine in front of the queue, doing clinical screening, location capture, and red-flag detection. A real-time queue and matching service that pairs the next ready patient with an available, appropriately-licensed clinician. A media layer built for graceful degradation, not maximum fidelity, because your patients are on consumer networks. A rules layer that reads reimbursement, prescribing, and licensing as configuration so a regulatory change is a settings edit. And the HIPAA-compliant data spine — BAAs, encryption in transit and at rest under the HIPAA Security Rule (45 CFR §164.312), audit logging, and access controls — wrapping all of it. Remember the rule from across this section: encrypted is necessary but not sufficient; without a signed BAA covering every vendor that can see PHI, an encrypted system can still be a violation.

Where Fora Soft fits in

Fora Soft has built real-time video, conferencing, and telemedicine software since 2005, across 239+ shipped projects. For a primary or urgent care product, the requirement we lead with is safety-under-scale: a triage-first intake, a managed waiting-room queue, and graceful media degradation for consumer networks, all wrapped in the HIPAA data controls — BAAs, encryption, audit logging — that the vertical demands. We build the regulatory dials (reimbursement, prescribing, licensing) as configuration so your team can keep pace with rules that move every year, and we wire the EHR, pharmacy, and payment integrations the model needs. The video is the easy part; the safe, compliant, scalable system around it is the work.

The handbook

Fora Soft Video Engineering Handbook

We wrote a seven-volume, 9,000-page series that works through the whole video stack — encoding, delivery, audio, and AI — so the team building a high-volume consult knows what sits under it. Volume 7 is closest to this article: real-time pipelines, cost per stream-hour, compliance, and the vertical playbooks that decide what a regulated product can ship. Volume 3 covers the delivery every low-acuity visit leans on — WebRTC, player recovery, the economics of streaming — and volume 1 the encoding behind the still image a clinician reads a rash from. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies