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.

Diagram of the clinical latency budget: capture, encode, network, jitter buffer, decode, and render stages summed against the ITU-T G.114 thresholds 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.

Comparison table of video-quality needs by consult type, from medication refill to tele-stroke, across resolution, frame rate, audio, and clinical purpose 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.

Decision diagram: detail-focused consults set maintain-resolution, motion-focused consults set maintain-framerate 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.

Diagram of simulcast: a patient device encodes three quality layers, an SFU forwards 1080p to a desktop, 720p to a tablet, and 360p to an old phone 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.

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.

What to read next

Call to action

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/