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

Why this matters

If you are a founder, product manager, or hospital IT lead scoping a telemedicine build, "we'll use WebRTC" will appear in the first technical conversation — and it is the right call. What that sentence hides is everything around the standard: the relay servers, the firewall behavior of real clinics, the missing record button, and the point where peer-to-peer quietly becomes the wrong architecture. Those four items, not the video call itself, are where telemedicine video projects slip by months. This article is the anchor for the whole architecture block of this course: read it first, then go deeper per topic. By the end you should be able to ask a vendor or an engineering team exactly the questions that expose whether they have built clinical video before.

What WebRTC is, in plain language

A video call needs three things: capture the camera and microphone, move the audio and video to the other person with minimal delay, and do both securely. Before 2012 or so, that required installing software — a desktop app, or a browser plugin like Flash. The plugin era ended for good when Adobe retired Flash at the end of 2020 [7].

The technology that replaced it is Web Real-Time Communication, or WebRTC: a set of capabilities built into the browser itself that lets a web page capture media and stream it to another device in real time. Think of it as a phone line built into the browser tab. The page you open is the calling application; there is nothing else to install.

Two details matter for what comes later. First, WebRTC is an open standard, not a product. The browser-facing part is a W3C Recommendation — the web's formal standards body published it in January 2021 and continues to maintain it, with the current edition dated March 2025 [1]. The network protocol side is specified by the IETF, the body that standardizes internet protocols, in RFC 8825 and its companion documents [2]. Nobody licenses WebRTC to you, and nobody can take it away — which is exactly what you want under a product with a 10-year compliance lifetime.

Second, WebRTC is a component, not a platform. The standard gives you the call. It deliberately does not give you signaling (how two browsers find each other), user accounts, scheduling, recording, or any of the clinical workflow around the call. The phrase you will hear from engineers is that WebRTC is free like a puppy: the standard costs nothing, and then you feed it infrastructure for the rest of its life. A working consult also needs a signaling service, usually one or two kinds of helper servers, and — for anything beyond two participants — a media server. The anatomy of a telemedicine platform article maps where all of those live; this one focuses on the video layer itself.

For the protocol internals — how session descriptions are exchanged, how candidates are gathered, what an SFU does packet by packet — our Video Streaming section has the deep dives: start with WebRTC explained. Here we stay on the clinical application.

Why WebRTC won clinical video

Four properties, each of which maps to a clinical requirement.

1. The patient installs nothing

A telemedicine visit has a property most software does not: the user may use it exactly once, under stress, on whatever device they own. A 72-year-old patient with a new diagnosis is not a person you ask to download an app, create an account, and grant camera permissions in a settings menu. Every extra step before the consult costs show-rate: the patient who cannot get the software working becomes a no-show, a rebooked slot, and a support call.

WebRTC removes the steps. The patient taps a link in a text message or an email, the browser opens, the browser asks one question — "allow camera and microphone?" — and the visit starts. One detail founders often miss: browsers only expose camera and microphone capture to pages served over HTTPS (a rule called secure contexts), so the encrypted-web requirement is enforced by the browser before your compliance team ever asks [1]. Browser-first telehealth products — Doxy.me is the best-known example — built their entire pitch on this no-download flow, and every major video API (Twilio, Vonage, Daily, Agora, LiveKit) is WebRTC under the hood [10].

Support for the standard is effectively universal: Chrome and Firefox have shipped it since 2013, Safari since version 11 in 2017, and Edge in its modern form since 2020 [1][2]. For a patient population, that means the browser they already have is the client you support.

2. Sub-second latency, because a consult is a conversation

Latency is the delay between one person speaking and the other person hearing it. For one-way video — a webinar, a sports stream — several seconds of delay is invisible. For a conversation it is fatal: people start talking over each other, pausing awkwardly, and repeating themselves.

The standards body for telephony, the ITU, quantified this decades ago in Recommendation G.114: one-way delay up to about 150 milliseconds feels natural, and beyond 400 milliseconds is unacceptable for interactive speech [6]. Walk through what that budget means. A milliseconds budget of 150 must cover capturing the frame, compressing it, crossing the network, decompressing, and rendering:

capture + encode ≈ 20–40 ms
network transit  ≈ 30–80 ms (same continent)
jitter buffer + decode + render ≈ 30–60 ms
total            ≈ 80–180 ms one way

WebRTC is engineered for exactly this: glass-to-glass delay typically lands under 500 milliseconds and often under 200 on decent networks. Streaming protocols built for one-to-many delivery sit in a different league entirely — standard HLS runs 6–30 seconds behind live, and even its low-latency variant runs 2–5 seconds [2]. A clinician cannot conduct an exam over a 6-second delay; they cannot even say "does it hurt when I press here?" and watch the reaction. This is why no serious telemedicine product runs consults over a streaming protocol, and why the protocol choice is not actually a choice.

Latency ladder from WebRTC's sub-second delay to HLS's 6–30 seconds, with the conversation threshold marked Figure 1. The latency ladder. A live consult must stay inside the conversational band defined by ITU-T G.114; only real-time protocols like WebRTC do.

Where the clinical bar sits per specialty — and when dermatology or tele-stroke needs more than "good enough" — is covered in latency, quality, and the clinical bar.

3. Encryption is mandatory — but encryption is not compliance

WebRTC has no unencrypted mode. The standard requires that all media be carried over SRTP, the secure variant of the real-time transport protocol, with encryption keys negotiated through DTLS — a TLS-style handshake performed directly between the endpoints (RFC 8827; the underlying mechanisms are RFC 3711 and RFC 5763/5764) [3]. In plain terms: the audio and video are encrypted from one end of each network hop to the other, and an implementation that skipped this would not be WebRTC and would not interoperate with any browser.

That is a real head start on the HIPAA Security Rule, the part of US health-data law that dictates technical safeguards for electronic patient data. Protected Health Information, or PHI — any health data tied to an identifiable person — triggers the rule the moment it crosses the wire, and a video of a patient's face discussing symptoms is PHI. The Security Rule's transmission-security standard (45 CFR §164.312(e)(1)) asks for exactly the guard WebRTC ships by default [4].

It is also where teams overreach. Encryption in transit is one safeguard out of five in §164.312; the others — access control, audit controls, integrity, and person-or-entity authentication — live entirely in the application you build around WebRTC [4]. And no protocol can sign a contract: every vendor whose servers touch PHI on your behalf needs a signed Business Associate Agreement (BAA) — the written promise health-data law requires before a contractor may handle patient data — regardless of how well the bytes were encrypted in flight. Since the COVID-era enforcement discretion ended on August 9, 2023, "we used an encrypted video tool" without a BAA is simply a violation [5].

§164.312 safeguard What WebRTC gives you What you must build or buy
Transmission security DTLS-SRTP encrypted media, TLS signaling — mandatory in the standard Certificate management; TLS on every API and webhook around the call
Access control Nothing Unique user IDs, session authorization, automatic logoff
Audit controls Nothing Who joined, when, from where — logged and reviewable
Integrity Packet-level integrity via SRTP Tamper-evident records, recording integrity
Authentication Nothing Identity verification for patient and provider

Table 1. WebRTC covers one row well. The other four are your product. The full mapping is in HIPAA for telemedicine product teams and encryption in transit, at rest, end to end.

One regulatory note worth tracking: the proposed update to the Security Rule (published January 6, 2025) would make encryption in transit and at rest explicitly mandatory rather than "addressable." As of 2026-06-11 it remains a proposed rule, not final law [4]. WebRTC-based architectures already clear the in-transit half by construction.

4. It is the ecosystem, not just the protocol

Standards win on network effects. Because WebRTC is the browser's only real-time media API, every video API vendor builds on it, every SFU (the media-server type most telemedicine platforms use) speaks it, and every WebRTC engineer you hire transfers across stacks. The practical consequence for a buyer: choosing WebRTC does not lock you to a vendor. A platform built on a managed video API can later migrate to an open-source media server — mediasoup, Janus, LiveKit — without changing what runs in the patient's browser. That migration story is the subject of choosing the video layer: build vs buy, and it is a real option precisely because the standard underneath is shared. Vendor churn is also real — Twilio announced the end-of-life of its Video API in 2023 and reversed the decision in October 2024 [10] — and an open standard is your insurance policy against it.

How a consult actually connects

It helps to see the moving parts once, end to end, before we get to what breaks. When patient and provider click "join": the browsers exchange connection offers through your signaling server (an HTTPS/WebSocket service you run — this is where authorization happens); each browser gathers candidate network paths with the help of a STUN server, which simply tells a device what its public address looks like from outside; the ICE procedure (RFC 8445) tries those paths in pairs until one works, falling back to a TURN relay if none do; a DTLS handshake establishes keys; and encrypted media starts to flow [2][3]. On a good network the whole sequence takes one to three seconds — which is also why the pre-call tech check belongs in the waiting room, not at the moment the clinician joins.

Connection sequence of a WebRTC telemedicine visit: signaling over HTTPS, ICE with STUN and TURN, DTLS-SRTP media Figure 2. The first seconds of a consult. Signaling finds the other side, ICE finds a network path, DTLS establishes keys, then encrypted media flows — directly if possible, through a TURN relay if not.

That is the why. Now the four places where clinical reality bites.

Gotcha 1 — TURN: the relay you forgot to budget

Most home and clinic networks sit behind NAT — network address translation, the router feature that lets many devices share one public address. Two devices behind NATs often cannot reach each other directly; it is like two people trying to mail letters using only apartment numbers, with no building address. STUN solves the easy cases by telling each device its public-facing address. The hard cases — strict NATs, symmetric NATs, networks that block the direct path — need TURN: a relay server with a public address that forwards the media between the two parties. TURN is the post-office forwarding address the call falls back to when no direct route exists (the current protocol specification is RFC 8656) [2].

Three facts about TURN drive real budgets.

First, you cannot ship without it. Industry measurements have been stable for years: expect somewhere between 5% and 20% of sessions to be unable to connect directly, varying with geography, carrier, and network strictness [9]. A telemedicine service that deploys without TURN simply fails for that slice of patients — and the slice is biased toward exactly the networks healthcare cares about: hospitals, clinics, corporate guest Wi-Fi, and cellular carrier-grade NAT.

Second, relayed media is metered media. A TURN server forwards every packet of a call, both directions, for the relayed party. The arithmetic, out loud. A typical 720p consult stream runs about 1.5 Mbps each way. A 20-minute consult moves, per direction:

1.5 Mbps × 60 s × 20 min = 1,800 megabits ≈ 225 MB
both directions through the relay ≈ 450 MB per relayed consult

Now scale it. Say your platform runs 10,000 consults a month and 15% relay:

10,000 × 15% = 1,500 relayed consults
1,500 × 0.45 GB ≈ 675 GB of relayed traffic per month

On a managed TURN service at list price — Twilio's Network Traversal Service charges $0.40/GB for US-located relays (June 2026 list; Asia-Pacific regions run $0.60–0.80/GB) — that is 675 × $0.40 ≈ $270 per month [8]. Modest. But the same fleet on a locked-down enterprise estate, where relay rates of 60–70% are routinely observed, turns into 3,150 GB and $1,260 per month — for the relay alone, before a single media-server or recording dollar. Prices vary an order of magnitude across providers (Cloudflare's TURN service lists $0.05/GB with the first 1,000 GB free, June 2026 [8]), and self-hosting the open-source coturn server on a cloud VM with bundled egress is often cheaper still at volume — at the cost of operating it yourself. The point of the arithmetic is not the specific dollars; it is that relay percentage × minutes × bitrate is a line item you can and should forecast during the cost model stage, not discover on the first invoice.

Third, TURN sits inside your compliance boundary. A TURN relay forwards packets that are already DTLS-SRTP encrypted, and it does not hold the keys — so one school of thought treats it like a dumb pipe. The conservative reading, which this course recommends and the compliance architecture pattern explains in detail, is to treat any server in the media path as inside the PHI boundary: use a TURN provider that signs a BAA, or self-host TURN inside your own covered environment. Common mistake: copying a free public TURN/STUN credential set from a tutorial into production. You have just routed patient consultations through an unknown third party's server with no contract, no BAA, and no uptime promise — and because the failure is invisible when the direct path works, it surfaces months later, on exactly the patients with the worst networks.

Gotcha 2 — Hospital and clinic networks are built to stop you

The demo works at the office. Then the pilot starts at a hospital, and 40% of provider-side calls fail or arrive with relay-grade latency. Nothing is broken; the hospital network is doing its job.

Clinical networks are among the most restrictive environments WebRTC encounters. The pattern, observed across deployments: UDP — the fast, connectionless transport WebRTC prefers for media — is blocked outright except for named services; outbound traffic must pass a proxy or deep-packet inspection; and only TCP ports 80 and 443 (web browsing) are reliably open [9]. Home networks add their own obstacles: hotel and dorm Wi-Fi, cellular carrier-grade NAT, ISP-supplied routers with aggressive defaults.

The engineering answer is a graceful ladder of fallbacks, and your platform must implement all of it: try direct UDP; fall back to TURN over UDP; then TURN over TCP; and finally TURN over TLS on port 443 — media wrapped to look like ordinary secure web traffic, which traverses almost everything (TURN's TCP and TLS modes are part of RFC 8656) [2]. Each step down the ladder adds latency and jitter sensitivity, which is why it is a fallback ladder and not a default. The deployment-side answer is just as important: for fixed clinical sites, work with hospital IT before go-live to allowlist your TURN and media-server addresses, request UDP exceptions for them, and put quality-of-service rules on consult traffic. A pre-call network test in the waiting room — run while the patient still has time to switch from clinic Wi-Fi to cellular — converts hard failures into recoverable ones; connection reliability covers the full playbook, and the protocol mechanics live in the Streaming section's ICE, STUN and TURN deep dive.

Hospital firewall traversal: direct UDP blocked, TURN over UDP blocked, TURN over TLS on port 443 succeeds Figure 3. The fallback ladder on a locked-down clinical network. Each step trades latency for reachability; TLS on 443 is the path of last resort that almost always works.

Common mistake: testing the pilot only on the engineering team's office network and the founder's home fiber. The populations a telemedicine product serves — rural patients (roughly a third of rural Americans lack broadband adequate for video visits [11]), elderly patients on old devices, clinicians inside hospital firewalls — are precisely the networks your office does not have. Test on hostile networks first; the good ones will take care of themselves.

Gotcha 3 — The recording problem: WebRTC has no record button

In consumer video, recording is a feature. In telemedicine it is an architectural fork, and WebRTC deliberately does not make the choice for you: the standard defines how two endpoints exchange encrypted media, and nothing else. There is no server in the loop by default, hence nothing in the middle to press record.

You have three options, each with a compliance shadow. Record client-side in the browser (the MediaRecorder API) and upload — fragile on exactly the low-end devices and networks telemedicine serves, and the recording exists unencrypted-at-rest on the patient's or provider's device until handled. Record server-side by routing the call through a media server (an SFU) that writes streams to storage — the production-grade answer, and the moment you do it, that server and that storage are squarely inside the PHI boundary: BAA-covered, encrypted at rest, access-controlled, audit-logged. Or use a managed video API's recording feature — the same server-side architecture, wearing a vendor badge, with the BAA question delegated to the contract.

Note what the server-side answer quietly changed: the call is no longer peer-to-peer, even for a 1:1 consult. That has knock-on effects — the media server's region affects latency and data-residency, and a true end-to-end-encryption posture (where even your own servers cannot read media) directly conflicts with server-side recording, a tension the E2EE article takes apart. Recording also drags in the legal layer — consent that varies by state, retention schedules, who may replay — which belongs to patient consent, recording, and data retention, and the full recording architecture is its own article in this block. The point for an anchor article is the planning one: "do we record?" is not a feature toggle to defer — it decides your topology, your vendor shortlist, and a slice of your compliance surface, so answer it in week one.

Gotcha 4 — P2P stops at two: the third participant changes the architecture

Peer-to-peer is WebRTC's superpower for a 1:1 consult: lowest latency, no media server to run, media that never touches your infrastructure. Then someone clinically unremarkable happens: an interpreter joins. Or an adult child joins a parent's visit from another city, or a supervising physician drops in on a resident's consult, or group therapy needs eight participants. Multi-party is not an edge case in telemedicine; it is Tuesday.

Without a media server, multi-party means full mesh: every participant encodes and uploads a separate copy of their video to every other participant. The upstream arithmetic kills it. At 1.5 Mbps per stream:

2 parties: 1 × 1.5 = 1.5 Mbps up per person   — fine
3 parties: 2 × 1.5 = 3.0 Mbps up per person   — strains home uplinks
4 parties: 3 × 1.5 = 4.5 Mbps up per person   — exceeds many; phones throttle, fans spin

Many residential connections offer 5–10 Mbps upstream on a good day, and each extra encode burns CPU and battery on the cheapest device in the call — which in telemedicine is the patient's. The standard answer is an SFU, a selective forwarding unit: each participant uploads one stream to the server, and the server forwards copies to everyone else. Upstream stays flat at one stream regardless of party size; the cost moves to server bandwidth, which you can buy. The P2P, SFU, MCU topology article maps which topology fits which clinical session type, and multi-party and multi-role consults covers the roles, permissions, and interpreter channels on top.

Mesh versus SFU topology: per-participant upstream grows with each mesh peer but stays flat through an SFU Figure 4. Why the third participant forces a media server. Mesh multiplies every participant's upload; an SFU holds it flat at one stream.

There is a second, less obvious reason production telemedicine platforms route even 1:1 calls through an SFU: visibility and control. A pure P2P call gives your operations team almost nothing — no server-side quality metrics, no recording point, no way to apply regional routing. Routing through an SFU gives you call-quality telemetry to act on (and to feed audit logging), a recording point when consent allows, and one consistent architecture for 1:1 and multi-party instead of two divergent code paths. The trade is server cost and a few tens of milliseconds. Most teams that have shipped clinical video at scale take that trade, and the reference architecture at the end of this block assumes it.

WebRTC against the alternatives

The comparison founders actually need is not "WebRTC vs some other RTC stack" — for browser-based real-time video there is no other browser-native stack — but WebRTC against the adjacent technologies that keep getting proposed in scoping meetings.

Criterion WebRTC SIP softphone / VoIP apps HLS / LL-HLS streaming PSTN telephone
Typical latency < 0.5 s < 0.5 s 6–30 s / 2–5 s < 0.5 s (audio only)
Runs in a browser, no install Yes Rarely (plugins/apps) Yes (playback only) n/a
Two-way conversation Yes Yes No — one-to-many Yes, audio only
Media encryption Mandatory (DTLS-SRTP) Optional (SRTP exists, deployment varies) Transport-level (HTTPS) None end-to-end
NAT/firewall story ICE + STUN/TURN built in Varies per vendor; often painful None needed (plain HTTPS) n/a
Recording Build it (server-side via SFU) Vendor feature Inherent (it is files) Carrier/vendor feature
Clinical fit Live consults — the default Legacy contact-center integrations Webinars, education, one-to-many broadcasts Fallback when video fails; phone-only patients

Table 2. The adjacent technologies and where each one belongs. The clinical consult itself has one defensible answer.

The last row matters: the alternatives are not competitors, they are complements. A complete telemedicine platform often ships WebRTC for consults, HLS for a one-to-many education stream, and PSTN dial-in as the last-resort fallback — because the patient whose network defeats even TURN-over-TLS still deserves their appointment, and because synchronous video is only one of three telemedicine modalities anyway. Telehealth demand is concentrated where conversation quality matters most: in 2025 data, behavioral health accounted for around 44% of telehealth-delivered visits among traditional Medicare beneficiaries against roughly 9% for primary care [12] — and a therapy session is nothing but conversation, which is the latency argument made clinical.

What this means for your build

Pull the four gotchas together and a scoping picture emerges. The WebRTC standard costs you nothing and solves the hardest problem — real-time encrypted media in any browser. Everything around it is your project: a signaling service with real authorization, STUN/TURN with a BAA or self-hosted, an SFU once you record or seat three people, the fallback ladder for hostile networks, and the audit-and-consent layer HIPAA expects. None of it is exotic; all of it is work that belongs in the estimate. As a rule of thumb from our own scoping practice: the visible video call is roughly a fifth of a telemedicine platform's engineering effort, and the four gotchas above predict most of the rest of the video layer's share. Whether you assemble it from a managed video API or build on open-source media servers is the next decision — build vs buy — and the cost model article turns it into numbers.

To make the gotchas actionable, we condensed them into a one-page pre-flight: fifteen checks across TURN budgeting, hostile-network testing, the recording decision, topology, and the compliance boundary. Download the WebRTC telemedicine pre-flight checklist and run it against your architecture before the first sprint.

Where Fora Soft fits in

Fora Soft has built real-time video products since 2005 — video conferencing, streaming, surveillance, e-learning, and telemedicine — and WebRTC has been our daily tool since it shipped in browsers. In telemedicine specifically, the requirement comes first: we design the consult flow around the HIPAA boundary (BAA-covered TURN and media servers, audit logging, consent-aware recording) and then make it survive real networks — hospital firewalls, rural broadband, elderly patients' devices. That ordering — compliance first, then reliability, then features — is what this section of Learn teaches, because it is what we do on projects. If you are scoping a telemedicine platform and want the gotchas priced before they become surprises, talk to our telemedicine team.

What to read next

Talk to our telemedicine team — get your telemedicine architecture reviewed by engineers who have shipped compliant clinical video: telemedicine app development.

See our case studies — telemedicine and real-time video products we have built: our work in telemedicine.

Download the WebRTC telemedicine pre-flight checklist — fifteen checks before your first sprint: get the PDF.

Call to action

References

  1. W3C — WebRTC: Real-Time Communication in Browsers, W3C Recommendation (first published 2021-01-26; current edition 2025-03-13), https://www.w3.org/TR/webrtc/ — browser API standard; secure-context requirement for media capture. Tier 1.
  2. IETF — RFC 8825 Overview: Real-Time Protocols for Browser-Based Applications (2021); RFC 8445 ICE (2018); RFC 8656 TURN (2020, incl. TCP/TLS transports); RFC 8831 WebRTC Data Channels (2021), https://www.rfc-editor.org/ — protocol suite, NAT traversal, relay fallback. Tier 1.
  3. IETF — RFC 8827 WebRTC Security Architecture (2021); RFC 3711 SRTP (2004); RFC 5763/5764 DTLS-SRTP (2010) — mandatory encrypted media; no unencrypted mode in WebRTC. Tier 1.
  4. eCFR / HHS — 45 CFR §164.312 Technical safeguards (access control, audit controls, integrity, authentication, transmission security), https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312; HHS — HIPAA Security Rule To Strengthen the Cybersecurity of ePHI (NPRM), 90 FR 898, 2025-01-06, RIN 0945-AA22 — still proposed, not final, as of 2026-06-11. Tier 1.
  5. HHS Office for Civil Rights — Notification of Enforcement Discretion for Telehealth Remote Communications, https://www.hhs.gov/hipaa/for-professionals/special-topics/emergency-preparedness/notification-enforcement-discretion-telehealth/index.html — discretion ended 2023-05-11; transition ended 2023-08-09. Tier 1.
  6. ITU-T — Recommendation G.114 One-way transmission time (05/2003) — ≤150 ms one-way preferred for conversation; >400 ms unacceptable. Tier 1.
  7. Adobe — Adobe Flash Player End of Life announcement (EOL 2020-12-31), https://www.adobe.com/products/flashplayer/end-of-life.html — the end of the plugin era. Tier 4.
  8. Twilio — Network Traversal Service Pricing, https://www.twilio.com/en-us/stun-turn/pricing — TURN $0.400/GB (US/Germany), $0.600/GB (Singapore/India/Japan), $0.800/GB (Australia/Brazil), checked 2026-06-11; Cloudflare — Realtime TURN pricing, https://developers.cloudflare.com/realtime/sfu/pricing/ — $0.05/GB egress, first 1,000 GB/month free, checked 2026-06-11 via docs summary. List prices; re-verify at publication. Tier 4.
  9. BlogGeek.me (Tsahi Levent-Levi) — WebRTC TURN: Why you NEED it and when you DON'T need it, https://bloggeek.me/webrtc-turn/ — 5–20% of sessions require TURN; TURN-over-TCP/TLS shares; restrictive-network behavior. Industry measurement, not a standard. Tier 6.
  10. Twilio — Twilio Video product changelog (EOL announced 2023-12; reversal published 2024-10-21), https://www.twilio.com/en-us/changelog — CPaaS churn risk; WebRTC as the common substrate of CPaaS video APIs. Tier 4.
  11. AMA — Why so many patients still can't connect to doctors via telehealth, https://www.ama-assn.org/practice-management/digital-health/why-so-many-patients-still-can-t-connect-doctors-telehealth — ~33% of rural Americans lack broadband adequate for video visits. Tier 5.
  12. Medical Economics — Medicare telehealth boom hasn't driven more visits, study finds (2025), https://www.medicaleconomics.com/view/medicare-telehealth-boom-hasn-t-driven-more-visits-study-finds — telehealth ≈44% of behavioral-health visits vs ≈9% of primary-care visits among traditional Medicare beneficiaries. Tier 5.

Where lower-tier sources disagreed with rule or standard text, the rule wins in this article: vendor and listicle claims that WebRTC is "HIPAA compliant" were replaced with the precise framing (encryption is mandatory per RFC 8827; compliance additionally requires the §164.312 safeguards and BAAs per 45 CFR §164.308(b)); and blogs describing the 2025 Security Rule NPRM as final were overridden by the Federal Register record (still proposed as of 2026-06-11).