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

Why this matters

If you are scoping or buying a telemedicine platform, "HD video" sounds like a feature you should demand everywhere — and that instinct quietly wastes money and frustrates patients on weak networks. The useful question is not "what is the maximum quality?" but "what is the lowest quality at which this specific consult is still safe and effective?" Get that bar right and you spend bandwidth, battery, and engineering effort where it changes a clinical decision, and you stop spending it where it does not. This article is written for the founder, product manager, or clinical-IT lead who has to set those targets and then ask a vendor or engineer whether the platform actually hits them. By the end you will be able to say, for each kind of visit you run, what resolution, frame rate, and latency you need — and what should happen when the network cannot deliver it.

Latency is the one bar every consult shares

Start with the number that matters regardless of specialty. Latency is the delay between something happening in front of the patient's camera and the clinician seeing and hearing it — often called "glass-to-glass" for video and "mouth-to-ear" for audio. It is measured in milliseconds (ms, thousandths of a second). Latency is what makes a conversation feel natural or makes two people keep talking over each other.

The reference point comes from telephony, and it has held up for decades. ITU-T Recommendation G.114, the international standard for one-way transmission time, says that a one-way delay up to about 150 ms is essentially transparent — most people cannot tell it is there. From 150 to 400 ms the call is still usable, but interactivity degrades: the natural rhythm of turn-taking breaks down and people start interrupting each other. Past 400 ms the delay is unacceptable for normal conversation. For a clinical consult, where a clinician is reading hesitation, pauses, and emotional cues, the target is the low end of that range.

Where does the delay come from? It accumulates across a pipeline, and no single stage is the villain — they add up.

A six-stage chain of the one-way latency budget, drawn as two rows. The top row runs left to right: Capture, 10 ms, camera to frame; Encode, 20 ms, frame to packets; then Network, 30 to 150 ms, the big variable, outlined in light blue. A connector drops from Network and runs left, labelled the receiving side, into the second row, which also runs left to right: Jitter buffer, 20 to 60 ms, bought on purpose, outlined in light blue; Decode, 15 ms, packets to frame; Render, 15 ms, frame to screen. Below the chain is the ITU-T G.114 scale of one-way transmission time, split into three bands: a green band, 0 to 150 ms, transparent; an orange band, 150 to 400 ms, turn-taking breaks down; and a grey band, over 400 ms, unacceptable. A triangle above the orange band marks 160 ms, a typical stack. A closing note gives the arithmetic once, 10 plus 20 plus 60 plus 40 plus 15 plus 15 equals 160 ms one way, and says that dark blue is a stage you set in code while light blue marks the two that move with the network, that routing shortens the network slice and the jitter buffer is tuned rather than maximised, and that colour is the same code in all four figures Figure 1. The clinical latency budget. Each stage adds a few milliseconds; the network and the jitter buffer are the big, variable contributors. Keep the one-way total under 150 ms (ITU-T G.114) and the consult feels like being in the room.

Here is the arithmetic, walked out once. A camera takes about 10 ms to capture a frame. Encoding it into a compressed video stream adds roughly 20 ms. Sending it across the internet is the big variable — anywhere from 30 ms on a good fiber line to 150 ms or more on congested cellular or a long geographic hop. At the receiving end, a jitter buffer — a small holding area that smooths out packets arriving at uneven times — adds 20 to 60 ms on purpose, trading a little delay for steady playback. Decoding adds about 15 ms and drawing the frame on screen another 15 ms. Add a typical set of those numbers — 10 + 20 + 60 + 40 + 15 + 15 — and you land near 160 ms one way, right at the edge of the transparent range. That is why the network path and the jitter buffer get the most engineering attention: they are where the budget is won or lost.

Two practical consequences follow. First, routing matters: the closer the media server is to both participants, the smaller the network slice of the budget — which is why regional media routing is a real lever, not a luxury (we return to scaling and regions in a later article). Second, the jitter buffer is a tuning knob, not a switch: making it bigger smooths choppy audio but adds delay, so it is balanced against the conversation, not maximized. The deep mechanics of jitter buffers and audio smoothing live in our audio section; here the point is simply that this stage is part of your latency budget and must be tuned, not ignored. See the jitter buffer and NetEQ explained and packet-loss concealment for the audio engineering underneath.

Audio is more clinical than video — protect it first

A counterintuitive rule governs the rest of this article: in almost every consult, audio carries more clinical weight than video. A clinician can complete most of a history-and-symptoms conversation on clear audio with a frozen or low-resolution picture, but cannot complete any of it on crisp video with garbled sound. The patient describing chest pain, the parent reporting a child's fever, the medication review — these are audio events with a face attached, not the other way around.

This is why every quality decision in the rest of this article spends video quality to protect audio quality. When the network tightens, the picture should get smaller, slower, or pause entirely before the sound ever breaks up. It is also why an audio-only fallback — and ultimately a plain phone line — is a legitimate clinical channel, not a failure screen. US Medicare reimburses audio-only telehealth for many services (a flexibility currently extended through December 31, 2027, with audio-only behavioral health permanent), which means the phone path is both clinically and financially first-class. Reimbursement rules are jurisdictional and dated — confirm the current expiry and your payer's policy before relying on it.

The clinical "good enough" bar, by specialty

Now the central idea. Different consults look at different things, so they need different pictures. Pushing 1080p at 30 frames per second into every visit is like prescribing the same dose to every patient: occasionally right, often wasteful, sometimes wrong.

A table with five rows, one per kind of consult, and four columns: consult, picture, motion, and what must be read. A medication refill or check-in needs 360 to 480p, shown in green as the cheap end of the bar, at 15 to 24 frames per second, to read identity and the conversation. Mental and behavioural health needs 480 to 720p at 24 to 30 frames per second, to read affect: expression, eye contact, pauses. Primary and urgent care needs 720p at 24 to 30 frames per second, to read pallor, swelling, and how the patient moves. Dermatology and wound care needs 800 by 600 pixels as a minimum and 1024 by 768 upward, where a still beats a stream, to read one sharp, colour-true lesion. A tele-stroke or neuro exam needs 720 to 1080p, shown in orange as the expensive end, at a true 30 frames per second, to read gaze, symmetry, and limb drift. A panel outlined in purple below is headed Audio is not a column here and reads: in every row the sound carries more clinical weight than the picture, so spend video quality first, resolution, then frame rate, then the picture itself, and treat audio-only and a phone line as clinical channels. A closing note names the sources: ITU-T G.114 for latency, the AAD teledermatology standards for the 800 by 600 minimum and the 1024 by 768 preference, and AHA/ASA tele-stroke guidance for the 30 frames per second bar Figure 2. What each consult actually needs. The clinical job — confirm identity, read affect, inspect a lesion, watch a movement — sets the bar. Higher is not automatically better.

A medication refill or routine check-in is a conversation. The clinician needs to confirm the patient's identity and talk; 360–480p at 15–24 frames per second is plenty, and the audio is doing the work. Spending more here is pure cost.

A mental or behavioral health session needs enough resolution and a steady enough frame rate to read affect — facial expression, eye contact, micro-pauses. Roughly 480–720p at 24–30 fps is the practical bar. Smoothness matters here because affect lives in motion, not in a single sharp frame.

Primary and urgent care sits in the middle: 720p at 24–30 fps lets a clinician see general visible signs — pallor, swelling, a rash described and roughly shown, how a patient moves and breathes — even though a true close inspection often becomes a referral or a store-and-forward photo.

Dermatology and wound care flip the priority from motion to detail. Here a single sharp, color-accurate image is worth more than a smooth stream. The American Academy of Dermatology's teledermatology standards recommend a minimum capture resolution of 800×600 pixels and prefer 1024×768 or higher (about 0.8 megapixels), and modern store-and-forward setups commonly use 2–3 megapixel images with consistent lighting. For these consults the right design is often a high-resolution still or uploaded photo alongside the live video — the video establishes context and consent, the still carries the diagnostic detail. Note the trade-off: more megapixels mean larger files and slower transfer, so "more" has a practical ceiling too.

Tele-stroke and neurological exams are the demanding case, and they need both detail and motion. Assessing a stroke remotely — for example administering the NIH Stroke Scale, the standard 15-item neurological exam — depends on watching smooth movement: gaze, facial symmetry, limb drift, coordination. Studies have found remote NIHSS scoring agrees closely with bedside scoring (correlation around r = 0.97) when the video is good enough, and have also found that low-bandwidth links (early 3G) were not sufficient while higher-bandwidth connections were. The practical bar is 720–1080p at a genuine 30 fps with a stable connection, because here a dropped frame can hide a clinical sign.

The takeaway is not a fixed table to memorize but a habit: decide what the clinician must see in each consult type you support, then set the minimum that satisfies it. That is your good-enough bar.

When the network is weak: choose detail or motion

Real networks do not deliver the target consistently. When bandwidth tightens, WebRTC — the browser technology that carries the live video, short for Web Real-Time Communication — cannot keep both resolution and frame rate at the configured level. It has to give up one. The crucial design choice is which one, and WebRTC exposes it directly through a setting called degradationPreference on the video sender.

It has three values. maintain-resolution tells the encoder to keep the picture sharp and let the frame rate drop — you get crisp but jerky video. maintain-framerate keeps motion smooth and lets the resolution fall — you get fluid but softer video. balanced (the default) trades both. The wrong default can quietly hurt a clinical decision.

A decision drawn top to bottom. A bar across the top asks: the network tightens, what must the clinician see? Two arrows drop from it into two lanes. The left lane, Fine detail, gives the setting maintain-resolution, which keeps the picture sharp and lets the frame rate fall, so the video is crisp but jerky; it is for dermatology, a wound, an eye. The right lane, Movement, gives the setting maintain-framerate, which keeps motion smooth and lets the resolution fall, so the video is fluid but softer; it is for affect, a tremor, gait, stroke. Below the lanes, a panel outlined in orange is headed balanced is the default and reads: it is a reasonable generic setting and the wrong answer at both ends of this picture, so set it per consult type, or let the clinician switch mid-call. A panel outlined in purple below that is headed The ladder never spends audio and reads: lower the resolution or the frame rate, drop a video layer, pause video to audio-only, then fall back to a phone line, because the sound is the last thing to go. A closing note says the setting goes on the sender, through getParameters, degradationPreference and setParameters: one line of code, decided per clinical task rather than once for the product Figure 3. Degradation is a clinical choice. If the clinician is inspecting fine detail, keep resolution; if they are watching movement, keep frame rate. Match the setting to what the doctor must see.

The mapping is clinical. If the consult is about fine detail — a dermatology lesion, a wound, an eye — set maintain-resolution: a sharp still that updates slowly beats a smooth blur. If the consult is about movement — a mental-health session reading affect, a tremor, a gait or stroke assessment — set maintain-framerate: smooth motion beats a sharp freeze. Building one global default and never revisiting it is the common mistake; the better products set this per consult type, or even let the clinician toggle "I need to look closely" mid-call.

Here is the setting in practice, with pc as an established RTCPeerConnection:

// Keep detail for a dermatology consult: sharp picture, accept a lower frame rate.
const sender = pc.getSenders().find((s) => s.track && s.track.kind === "video");
const params = sender.getParameters();
params.degradationPreference = "maintain-resolution"; // or "maintain-framerate" for motion
await sender.setParameters(params);

Through all of this, audio stays protected. The degradation ladder for a clinical call spends video quality in order — lower resolution or frame rate, then drop extra video layers, then pause video to audio-only, then fall back to a phone line — and never sacrifices the sound. We cover that fallback chain in depth in the connection-reliability article; the link to quality is that graceful degradation is how you defend the good-enough bar when the network will not cooperate.

One stream, many devices: simulcast and SVC

A real consult rarely has two matched devices. The patient is on an old phone over cellular; the clinician is on a wired desktop; a remote specialist joins on a tablet. If the platform sent one single quality to everyone, it would be forced down to whatever the weakest device and network could handle — the desktop clinician would get the old phone's blurry stream.

Two techniques solve this, and both rely on a Selective Forwarding Unit (SFU) — the media server that receives each participant's video and forwards the right version to each recipient rather than mixing everything together. Simulcast has the sender encode its video at several quality levels at once — for example 1080p, 720p, and 360p — and send all of them to the SFU, which then forwards the layer each viewer can handle. Scalable Video Coding (SVC) achieves a similar result inside a single layered stream the server can peel back. Either way, no one is forced to the weakest link, and the server avoids the cost and latency of transcoding (decoding and re-encoding) every stream.

A funnel drawn top to bottom. At the top, a box reads: the patient's device, one camera, encodes three layers at once. An arrow drops from it, labelled with the three layers, 1080p at 2.5 Mbps, 720p at 1.2 Mbps and 360p at 0.6 Mbps, into a wide box outlined in light blue: the Selective Forwarding Unit, which forwards the layer each viewer can take and never transcodes. Three arrows drop from it into three cards: a wired desktop gets 1080p, the high layer; a tablet on Wi-Fi gets 720p, the middle layer; and an old phone on cellular, outlined in light blue as the weak link, gets 360p, the low layer. A panel outlined in orange below is headed Without simulcast or SVC and reads: one quality goes to everyone, and it is the one the weakest device and network can take, so the wired clinician gets the old phone's picture. A closing note gives the question for a vendor: in a call with a high-end and a low-end device, does each get the best quality it can handle, or does everyone drop to the weakest? If it is the latter, the platform has neither simulcast nor SVC Figure 4. Simulcast in a mixed-device consult. The patient sends three layers; the SFU gives the desktop the high layer, the tablet a medium layer, and the old phone the low layer — no transcoding, no lowest-common-denominator.

For a non-technical decision-maker, the practical question to ask a vendor is simple: "In a call with a high-end and a low-end device, does each get the best quality it can handle, or does everyone drop to the weakest?" If the answer is the latter, the platform is not using simulcast or SVC, and your mixed-device consults — which is most of them — will look worse than they should. The protocol internals of simulcast and SVC belong to our video-streaming section; see simulcast, SVC, and the SFU and WebRTC bandwidth estimation for how the layers and the bandwidth math actually work. This article's point is the clinical one: matching quality to each device is how you hold the good-enough bar for everyone in the room.

A worked example: the cost of "always 1080p"

Numbers make the trade-off concrete. Suppose a 1080p stream needs about 2.5 Mbps and a 480p stream about 0.6 Mbps. A telehealth service running 1,000 medication-refill consults a day, each averaging 12 minutes, that insists on 1080p is moving roughly 2.5 Mbps × 12 min for every call — far more data than the visit needs, on patient devices that are often on metered cellular plans and aging batteries. Drop those talk-only visits to 480p and you cut the video data per call by roughly three-quarters, with no loss to a consult whose clinical content was the conversation. Now spend that saved budget where it matters: the dermatology and tele-stroke visits that genuinely need the high layer get it without contention. Quality is a budget you allocate by clinical task — not a slider you push to maximum and forget.

Common mistakes

Demanding "HD everywhere." Treating maximum resolution as a universal requirement wastes bandwidth and battery on consults whose clinical value is the audio, and crowds out the few visits that truly need fidelity.

Leaving degradationPreference on the default. balanced is fine as a generic default and wrong for a dermatology or a stroke consult. Not setting it per clinical task means the network, not the clinician, decides whether you keep detail or motion.

Forgetting audio is the priority. Building a quality ladder that degrades audio alongside video — or with no audio-only and phone fallback — sacrifices the most clinical part of the call first.

Ignoring the mixed-device reality. Testing only on matched office machines and shipping without simulcast/SVC, so real calls between a high-end and a low-end device collapse to the weakest stream.

Measuring latency on the demo network. Quoting the office-Wi-Fi delay number. Real latency on a patient's cellular or rural DSL link is what determines whether the conversation feels natural — measure there.

↓ Free download: Telemedicine Video-Quality Spec SheetOne page to set the bar before you build: the conversation latency budget and the 150 ms line it has to stay under, quality targets by specialty from a refill call to a tele-stroke exam, the degradationPreference and simulcast settings that hold those targets on a real network, and the tests to run on a patient's connection rather than the office Wi-Fi.

Where Fora Soft fits in

The requirement is a consult that is good enough for its clinical purpose on a real patient's network; the capability is knowing where that bar sits and engineering to it. Fora Soft has built real-time video on WebRTC since the technology was new, across telemedicine, video conferencing, e-learning, and streaming, where the difference between "looks fine in a demo" and "works for a wound exam over rural cellular" is exactly this layer. We set latency budgets, map degradationPreference and simulcast layers to each clinical context, protect audio through every degradation step, and verify the picture against the specialty before launch — so quality is spent where it changes a clinical decision and conserved where it does not. That engineering is the core of our telemedicine video development, and the call layer itself comes from our WebRTC development experts, who tune simulcast and bandwidth for weak networks.

Video Encoding: A Complete Guide to Video Compression - book coverVideo Streaming: From ABR and CDNs to Players, WebRTC, DRM, and the Economics of Streaming - book coverAudio for Video: From Jitter Buffers and Lip Sync to Atmos, Quality Metrics, and Neural Codecs - book cover

The handbook

Fora Soft Video Engineering Handbook

We wrote the seven volumes that cover the whole video stack, pixel to production — compression, delivery, sound and AI, across 9,000+ pages. Three of them sit closest to the bar this article sets: the delivery volume works through WebRTC, simulcast and SVC layers and the bandwidth estimation that decides which layer a viewer gets; the jitter-buffer volume covers the receiving half of the latency budget and the sound you protect on the way down the ladder; and the encoding volume explains what a resolution and a frame rate actually cost, so a 480p refill call and a 1080p stroke exam are priced rather than guessed. Read the series and you can design, price and build a telemedicine platform whose quality targets come from the clinic rather than from a spec sheet. Written by Nikolay Sapunov, CEO at Fora Soft.

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

What is the good-enough bar for the consults you actually run?

Send us the visit types you support, the devices and networks your patients really use, and the platform or CPaaS you are on, and we will come back with four things: a one-way latency budget for your routing, stage by stage, and where it lands against the 150 ms line; the resolution and frame-rate target for each visit type, with the degradationPreference that defends it when the network tightens; whether your video layer does simulcast or SVC today, and what a mixed high-end and low-end call actually looks like if it does not; and the degradation ladder down to audio-only and a phone line, so the sound is the last thing to go. We have been building video software since 2005, telemedicine platforms among 250+ shipped products.

Book a 30-min call →WhatsApp →Email us →

See our case studies

Case study

CirrusMed

A HIPAA-compliant browser platform we built from scratch for a subscription practice, now 20+ physicians licensed across 48+ US states, running unlimited video visits for members. Every one of those visits happens on a patient's own home or cellular connection, which is where a good-enough bar is either set deliberately or discovered the hard way.

Case study

WorldCast Live

One of the first platforms to hold 0.4–0.5 s latency at 10,000 simultaneous viewers, on a WebRTC and Kurento architecture we built, with 1.5 Gb/s for true HD, five audio channels and quality that steps down on a weak connection. The same budget arithmetic as this article, run at a scale where every stage has to be measured.

Case study

TransLinguist

A mediasoup-based interpreting platform with 75+ languages and 30,000+ certified interpreters that won the NHS national framework covering trusts, councils, schools and police forces. Interpretation is the case where the sound is the whole clinical payload, and the SFU decides what each device in the room receives.

References

  1. ITU-T Recommendation G.114 — One-way transmission time (≤150 ms preferred / transparent; 150–400 ms acceptable with degradation; >400 ms unacceptable). International Telecommunication Union, 05/2003. Tier 1 (standard). https://www.itu.int/rec/T-REC-G.114-200305-I/en
  2. WebRTC: Real-Time Communication in Browsers — W3C Recommendation (degradationPreference, simulcast/encodings, RTCRtpSender.setParameters). W3C, 2025 edition, checked 2026-06-14. Tier 1 (standard). https://www.w3.org/TR/webrtc/
  3. 45 CFR §164.306 — HIPAA Security Rule, general requirements (confidentiality, integrity, and availability of ePHI — the basis for reliability/quality as an availability control). eCFR / HHS. Current as of 2026-06-14. Tier 1. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.306
  4. Telehealth policy updates — Telehealth.HHS.gov (Medicare audio-only flexibility extended through 2027; audio-only behavioral health permanent). HHS/HRSA, last updated 2026-02-05, checked 2026-06-14. Tier 2. https://telehealth.hhs.gov/providers/telehealth-policy/telehealth-policy-updates
  5. CY2026 Medicare Physician Fee Schedule Final Rule (telehealth services list and audio-only provisions). CMS, Federal Register, 2025-11-05. Tier 1. https://www.federalregister.gov/documents/2025/11/05/2025-19787/medicare-and-medicaid-programs-cy-2026-payment-policies-under-the-physician-fee-schedule-and-other
  6. AAD Teledermatology Standards / Position Statement (minimum capture resolution 800×600; preferred ≥1024×768; image quality and lighting guidance). American Academy of Dermatology, checked 2026-06-14. Tier 2 (institutional). https://www.aad.org/member/practice/telederm/standards
  7. Telemedicine Quality and Outcomes in Stroke — AHA/ASA Scientific Statement (video quality and bandwidth for reliable remote neurological assessment). American Heart Association / American Stroke Association, Stroke, 2017. Tier 5 (peer-reviewed/institutional). https://www.ahajournals.org/doi/10.1161/str.0000000000000114
  8. Role for telemedicine in acute stroke: feasibility and reliability of remote administration of the NIH Stroke Scale (remote vs bedside NIHSS correlation ≈ r 0.97). Stroke, 1999 (PubMed 10512919). Tier 5. https://pubmed.ncbi.nlm.nih.gov/10512919/
  9. RTCRtpSender.setParameters() / RTCRtpSendParameters.degradationPreference — MDN Web Docs (values: maintain-framerate, maintain-resolution, balanced). Mozilla, checked 2026-06-14. Tier 6 (orientation). https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpSender/setParameters
  10. Simulcast — BlogGeek.me / WebRTC Glossary (one sender encodes multiple layers; the SFU forwards the right one; no transcoding). Tsahi Levent-Levi, checked 2026-06-14. Tier 6 (orientation). https://bloggeek.me/webrtcglossary/simulcast/
  11. The effect of decreasing digital image resolution on teledermatology diagnosis (diagnostic adequacy at modest resolutions for many store-and-forward consults). Telemedicine Journal, 2000 (PubMed 10908453). Tier 5. https://pubmed.ncbi.nlm.nih.gov/10908453/