The Anatomy of a Telemedicine Platform, End to End

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

Why this matters

If you are scoping a telemedicine product, the most expensive mistakes happen before any code is written: a subsystem nobody budgeted for, a vendor that quietly sees patient data without a contract that covers it, or a feature list copied from a marketing page with no idea what each feature costs to operate. This article gives founders, product managers, and hospital IT leads the one-page mental model: what the parts are, how the data flows between them, and where the compliance obligations attach. It builds on what telemedicine, telehealth, and digital health mean, why clinical video is harder than a normal video call, and the three modalities and their architectures. Read it once and every later article in the course — HIPAA, video architecture, integrations, AI — will slot into a place on this map.

The map at a glance

The picture below is the whole article in one diagram. A patient enters through an app, proves who they are, books a slot, waits in a queue, talks to a clinician over live video, the visit produces records, the records flow to the chart and the claim, and the platform watches itself the entire time. Around all of it sits the compliance boundary — the line inside which every component must be covered by the right contracts and controls.

Figure 1. The anatomy of a telemedicine platform. Ten subsystems, the data that moves between them, and the compliance and audit layer wrapping everything. Keep this map; the whole course refers back to it.

Three annotations repeat across the map, and they are the three questions to ask about any component a vendor or an engineer proposes:

A Business Associate Agreement, for readers new to the term, is the contract that lets a vendor handle patient data on your behalf — the contractor's signed promise before they get a key to the building. The BAA article covers it in depth; on this map, treat "BAA required" as a property of every arrow that carries PHI to a third party.

Now walk the map, subsystem by subsystem.

1. The front doors: patient and provider apps

Everything starts with two applications that are nothing alike. The patient app is built for someone who may be elderly, anxious, on a cheap phone, and using it once a quarter: large targets, few steps, nothing to install if possible. The provider app is built for a clinician who lives in it eight hours a day: dense schedule views, charting beside video, keyboard-friendly workflows.

The typical technology is a web app (often a Progressive Web App) for patients — because a browser-based visit removes the app-store install step that loses real patients — plus native or cross-platform mobile apps where device features like Bluetooth vitals or push notifications demand them. Providers usually get a desktop web app, increasingly embedded inside the EHR they already use. Accessibility is not optional polish: the technical standard to design against is WCAG 2.1 Level AA, the conformance level federal accessibility rules reference — the accessibility article covers the 2026–2028 compliance dates now in force for public entities.

The classic failure mode is building one app for two jobs — a patient-grade interface that wastes a clinician's day, or a clinician-grade interface that loses patients at the first screen. The second failure is platform spread: every patient device, browser, and OS version you support is a permanent test-matrix cost.

Where PHI lives: on the device. Cached visit history, chat threads, push notifications, screenshots. The most common leak at this hop is the push notification itself — "Your psychiatry appointment is confirmed" on a lock screen is a disclosure. Notifications should say no more than "You have a new message."

2. Identity and consent: who is in the room, and did they agree

Before any clinical conversation, the platform must answer two questions with confidence: is this patient who they claim to be, and is this provider licensed to treat them? The federal vocabulary for "how sure are you" comes from NIST Special Publication 800-63, which grades identity proofing as IAL (how the account was verified) and authentication strength as AAL (how the session is verified) [7]. A telemedicine platform typically proofs patients lightly at signup, steps up for high-risk services, and holds providers to a higher bar — credential checks against licensing boards, plus multi-factor authentication (MFA).

Consent is the second half of the subsystem, and in healthcare it is a recorded artifact, not a checkbox. Consent to treat via telehealth, consent to record (where recording exists), and state-specific disclosures all need versioned text, a timestamp, and the identity of the person who agreed — stored where an auditor can find them years later. The roles, identity, and consent article walks through the full cast — caregivers, interpreters, supervising physicians — and the authentication deep-dive covers the mechanics.

Typical technology: an identity provider speaking OpenID Connect or SAML, MFA, and a consent service with versioned documents. The classic failure mode is treating consent as UI copy — unversioned, unlogged, and unprovable the day a dispute arrives. HIPAA's Security Rule names the requirement directly: person or entity authentication is a standard at 45 CFR §164.312(d) [1].

Where PHI lives: the identity store itself is PHI-adjacent (a patient's presence in a psychiatry app is health information), and consent records are PHI outright.

3. Scheduling and reminders: the subsystem that pays for itself

Scheduling looks like commodity software until you load it with clinical constraints: provider licensure by state (a clinician licensed in Texas cannot take the California patient the slot-picker just offered), visit types with different durations, interpreter availability, and buffer rules between visits. The scheduler is also where reminders live — and reminders are the single highest-return feature on the map, because a missed visit is lost clinical time, and no-show reduction is measured revenue.

Typical technology: a booking service with a rules engine, calendar sync to the provider's world (often through the EHR's scheduling module rather than beside it), and SMS/email/push reminders. The classic failure mode is the reminder that leaks: an SMS reading "Reminder: your HIV clinic appointment tomorrow" is a PHI disclosure to anyone who glances at the phone — and SMS is not an encrypted channel. Reminders carry time and a join link, nothing clinical.

Where PHI lives: appointment records are PHI — the pairing of an identified person with a named specialty is health information even before the visit happens. The reminder gateway (an SMS vendor, for instance) sees that pairing too, which is why messaging vendors that touch appointment content sit inside the BAA list, not outside it.

4. The waiting room: the queue with clinical semantics

The virtual waiting room is the buffer between "patient is ready" and "provider is ready." For scheduled visits it is a check-in step: verify identity, confirm consent, run a device-and-network pre-flight (camera, microphone, bandwidth) so problems surface before the clinician joins. For on-demand urgent care it is a real queue with triage: intake questions sort patients by acuity and route them to the right clinician licensed in the right state.

Typical technology: a queue service with state (waiting, ready, in-visit, abandoned), presence signaling, and the pre-flight test — usually a short loopback call that measures the connection before it matters. The waiting-room article covers queueing math and provider-readiness patterns.

The classic failure mode is silence: a patient who waits with no feedback abandons, and an abandoned urgent-care visit can be a clinical event, not a UX metric. Show position, show estimated wait, and re-run the device check while the patient waits — the cheapest moment to fix a broken microphone is before the visit.

Where PHI lives: intake answers are PHI of the most sensitive kind — symptoms, medications, reason for visit — collected before any clinician is in the room. The queue record itself (who waited, for what service, how long) is PHI too, and it feeds the audit log.

5. The real-time video core: the heart, and the hardest part

The live visit runs on WebRTC, the real-time media standard built into every modern browser — the reason a patient can join a video visit from a link with nothing to install. Around WebRTC sit three server roles. Signaling is the control plane that sets the call up. TURN is the relay a connection falls back to when hospital and home networks block a direct path — the post-office forwarding address for media packets. And once more than two people join (a caregiver, an interpreter), media flows through an SFU — a Selective Forwarding Unit, the switchboard that receives each participant's stream and forwards it to the others.

This course deliberately does not re-derive the protocol internals — the WebRTC explainer and the SFU/MCU topology article in our Video Streaming section own that layer. What matters on this map is the clinical framing: the latency budget is conversational — ITU-T Recommendation G.114 advises keeping one-way audio delay under 150 milliseconds, with 400 ms as the planning ceiling [4] — and reliability outranks fidelity, because a dropped clinical call is an adverse event. Encryption is not optional at this hop even mechanically: WebRTC media is encrypted in transit with SRTP keyed over DTLS (the DTLS-SRTP scheme, IETF RFC 5763/5764) [8].

Figure 2. The real-time core. Signaling sets the call up; media flows patient → TURN → SFU → provider, encrypted with DTLS-SRTP at every hop, inside a conversational latency budget.

The build-vs-buy decision lands here harder than anywhere else: assemble your own media layer from open-source SFUs (mediasoup, Janus, LiveKit) or buy the layer as an API from a CPaaS — a Communications Platform as a Service. For a clinical product the vendor table has one extra column that decides everything:

The classic failure mode at this hop is shipping the happy path: no TURN capacity, no reconnection logic, no degradation plan for the patient on a weak cellular link. The second failure is contractual — building on a video API without the BAA paperwork, which makes the architecture non-compliant regardless of its encryption. The build-vs-buy article prices the decision; the reference architecture assembles it.

Where PHI lives: in transit. A live consultation is PHI on the wire — encrypted end-to-hop by DTLS-SRTP — and, if you record, PHI at rest the moment it touches a disk. Media servers (SFU, TURN) and their operators are inside the boundary: a CPaaS that relays identifiable patient video is a business associate, BAA and all.

6. In-call clinical tools: the visit is more than video

A consultation needs more than two faces. In-call chat carries links and clarifications; file share moves a photo of a rash or a PDF of lab results; screen share lets a clinician walk a patient through an X-ray; annotation draws on it; and vitals integration streams a blood-pressure reading into the visit live. Each tool is a small feature with a large data consequence, because everything shared in a clinical call is PHI.

Typical technology: WebRTC data channels or a messaging service for chat, object storage for files, and device APIs (Bluetooth LE on mobile) for vitals. e-Prescribing usually surfaces here as a workflow — the clinician prescribes during or right after the visit — but it is technically an integration, so the standards live in section 8.

The classic failure mode: each tool quietly creates a new PHI store nobody inventories. Chat transcripts land in a third-party messaging backend; shared files land in a default-configured bucket; annotations land in a screenshot service. The visit was secure; its by-products were not. The in-call tools article inventories each tool's data path.

Where PHI lives: every artifact — messages, files, shared images, vitals readings — is PHI at rest, each in its own store, each needing encryption, access control, retention rules, and BAA coverage for any vendor in the path.

7. Recording and documentation: what the visit leaves behind

When the call ends, the product's real output begins: the record. Three artifacts matter. The recording (where used) is the raw audio/video of the session. The transcript is its text. The clinical note is the structured summary that enters the chart — increasingly drafted by an ambient AI scribe that listens to the visit and proposes documentation for the clinician to approve. The scribe's model engineering belongs to our AI section's scribe playbook; its clinical wiring and compliance — consent, BAA with the model vendor, where transcripts live — is this course's ambient documentation article.

Recording is a deliberate decision, not a default. It creates the platform's largest PHI object and a two-party-consent question that varies by state — the recording article covers when to record and when not to. If you do record, the arithmetic is worth seeing once:

A 20-minute visit recorded at 1.5 Mbps: 1.5 Mbps ÷ 8 = 0.1875 MB per second. 0.1875 MB/s × 1,200 s = 225 MB per visit. At 1,000 recorded visits a month, that is ~225 GB of new PHI at rest every month — encrypted, access-controlled, retained for as long as your state's medical-record rules require, and deletable on schedule.

Typical technology: SFU-side recording into encrypted object storage, a speech-to-text service for transcripts, and the EHR as the system of record for the note. The classic failure mode is the un-BAA'd bucket: recordings parked in a storage account or transcription API outside the BAA list — encrypted, perhaps, but non-compliant. Remember the rule from the table above: "encrypted" is not "compliant."

Where PHI lives: everywhere in this subsystem. Recording store, transcript store, note drafts, and the scribe vendor's pipeline are all PHI at rest.

8. EHR integration: where the visit meets the chart

A telemedicine visit that does not reach the patient's chart creates a dangerous thing: a second, parallel medical record. The Electronic Health Record (EHR) — Epic, Oracle Health, athenahealth, and peers — is the system of record, and the integration subsystem moves data both ways: pull the patient's history and medications before the visit, push the note, orders, and visit metadata after it.

The technology has standardized hard over the last decade. HL7 FHIR — Fast Healthcare Interoperability Resources, the modern API standard for health data — is the lingua franca; certified US health IT now ships FHIR R4 APIs with the US Core profiles, and as of January 1, 2026 the federal certification baseline data set is USCDI v3 [5]. SMART on FHIR adds the OAuth-based app-launch layer that lets your product live inside the EHR. Legacy HL7 v2 interfaces still carry plenty of scheduling and results traffic. The FHIR article covers the stack; the Epic/Oracle/athenahealth article covers the vendor programs.

Market shape matters for planning: KLAS's 2026 report puts Epic at 43.7% of US acute-care hospitals (56.9% of beds), with Oracle Health second at 21.9% [6]. If your buyers are hospitals, "integrates with Epic" is half the sales conversation; if your buyers are independent clinics, the long tail of EHRs argues for an aggregator. The integration decision guide prices direct vs aggregator vs iframe.

The classic failure mode is underestimating the calendar: EHR developer-program onboarding, sandbox access, security review, and per-site go-lives run months, not sprints. The second failure is treating the EHR as a mirror — syncing everything both ways until conflicts corrupt trust in the chart. Decide what the EHR owns (the record) and what you own (the visit).

Where PHI lives: by definition — everything crossing this boundary is PHI, governed by the EHR vendor's program terms, the covered entity's policies, and the interoperability rules.

9. e-Prescribing, labs, and billing: the visit becomes orders and money

Three integration families turn the visit into action outside the platform.

e-Prescribing. Prescriptions travel from the EHR or your prescribing module to the pharmacy over the NCPDP SCRIPT standard through networks like Surescripts. The standards calendar is concrete: CMS has adopted SCRIPT v2023011, with a transition window that ends January 1, 2028, when the older 2017071 version expires for Medicare Part D e-prescribing [10]. Controlled substances add EPCS — Electronic Prescriptions for Controlled Substances — with DEA's identity-proofing and two-factor requirements, and the remote-prescribing rules under the Ryan Haight Act: DEA and HHS's Fourth Temporary Extension keeps the telemedicine prescribing flexibilities in force through December 31, 2026, while permanent rules are finalized [11]. Date-watch this hop: the e-prescribing article tracks it.

Labs. Orders out, results in — classically HL7 v2 feeds, increasingly FHIR. The product question is workflow: a result that arrives after the visit needs a review queue and a patient-notification path, or it becomes the result nobody saw. The labs article is the short deep-dive.

Billing and claims. A reimbursable visit must prove it was reimbursable: the right CPT code, the right modifiers (audio-only Medicare visits, for instance, carry modifier 93 to attest video capability existed), the right place-of-service codes, and documentation that supports them — then out as an X12 837 claim, back as an 835 remittance, under the HIPAA transaction standards of 45 CFR Part 162 [3]. Eligibility checks and patient payments (card processing for self-pay and copays) sit beside the claim path. The classic failure mode is architectural: billing rules change yearly — the current Medicare telehealth flexibilities run through December 31, 2027 under the Consolidated Appropriations Act, 2026 [2] — so codes and rules belong in configuration, not in code. The reimbursement article and the payments article own this territory.

Where PHI lives: prescriptions, orders, results, and claims are all PHI — and they flow to outside parties (pharmacy networks, labs, clearinghouses) whose coverage is part of your compliance story.

10. Analytics and observability: watching the platform without watching the patient

Two different jobs share this subsystem. Observability watches the system: call quality metrics, connection success rates, error budgets — the operational dashboard that tells you the platform is healthy. Product analytics watches usage: funnels, retention, feature adoption. In healthcare the second job has a hard constraint: usage data tied to an identifiable person in a clinical context is PHI, and shipping it to a generic analytics tool without a BAA is one of the most common violations in telemedicine builds.

The regulatory state is precise here. HHS OCR's bulletin on online tracking technologies took the strictest reading — a federal court vacated its broadest claim (the "proscribed combination" covering unauthenticated pages) in June 2024, and OCR dropped its appeal — but the part that matters to a telemedicine product stands untouched: trackers on authenticated pages, inside portals and apps where users are known patients, handle PHI and require a BAA or authorization [12]. Practically: no third-party tracking pixels inside the logged-in product, ever; analytics vendors either sign a BAA or receive only de-identified data. The de-identification and analytics article builds the compliant pipeline.

Typical technology: an event pipeline with a PHI filter at the front, a BAA-covered or self-hosted analytics store, and standard observability tooling (which sees infrastructure, not patients — keep it that way by scrubbing identifiers from logs). The classic failure mode is the default SDK: a mobile analytics or crash-reporting kit that phones home with device IDs, screen names ("PsychiatryVisitScreen"), and IP addresses from inside a health app.

Where PHI lives: anywhere an event joins an identity to a clinical signal. The discipline is to decide, per event, whether it is PHI, de-identified, or infrastructure — and route it accordingly.

The wrapper: the compliance and audit layer

Nothing above is compliant by itself. HIPAA's Security Rule attaches its technical safeguards to the whole map at once — 45 CFR §164.312 names five standards, and each lands on specific subsystems [1]:

One vocabulary note, because it changes how teams read the rule: "addressable" does not mean optional — it means you implement it or document why an alternative is reasonable. And the direction of travel is toward removing that flexibility: HHS's proposed Security Rule update (NPRM published January 6, 2025) would make encryption and MFA effectively mandatory, add asset inventories and annual audits, and tighten business-associate oversight. As of June 2026 it remains a proposed rule — OCR received more than 4,700 comments and has not issued a final rule — so build to it as the likely future without citing it as current law [13]. The 2026 Security Rule article tracks the rulemaking; the compliance architecture pattern turns the wrapper into a reference design.

The wrapper also has a clock. The Breach Notification Rule requires notifying affected individuals without unreasonable delay and no later than 60 days after a breach is discovered (45 CFR §164.404) [14]. And the stakes are measured annually: healthcare has been the costliest industry for data breaches for 14 consecutive years; the 2025 average was $7.42 million per breach, with healthcare breaches taking 279 days on average to identify and contain [15].

Reading the map as a PHI inventory

Here is the exercise that makes the map operational. Take one ordinary 20-minute visit and count where its PHI persists:

1 appointment record (scheduling) + 1 intake/queue record (waiting room) + 1 chat-and-files thread (in-call tools) + 1 recording (225 MB, if recorded) + 1 transcript + 1 clinical note (EHR) + 1 claim file (billing) = 7 persistent PHI stores from a single visit — plus transient PHI in flight through signaling, TURN/SFU, and integration APIs, plus audit-log entries recording every access.

Seven stores means seven encryption-at-rest answers, seven access-control lists, seven retention schedules, and a BAA for every vendor operating any of them. That count — not the feature list — is what an auditor, a security reviewer, and the HIPAA readiness checklist will walk through. Run the same exercise on your own architecture with the worksheet below before someone else runs it for you.

Figure 3. One visit, seven persistent PHI stores. Transient paths (dashed) carry PHI in flight; every solid store needs encryption, access control, retention rules, and BAA coverage.

From map to feature list: scoping an MVP

Marketing pages sell features; architecture pays for them. Every "must-have telemedicine app feature" on a vendor listicle is a node or an arrow on this map, and pricing a feature means pricing the subsystems it touches:

A defensible MVP for a scheduled-visit product is usually subsystems 1–5 plus documentation (7), with billing manual and EHR integration deferred — that is a real product a clinic can run. An on-demand urgent-care MVP cannot defer the queue and triage; a DTC product can rarely defer payments. What nothing can defer is the wrapper: identity, encryption, audit logging, and BAAs are MVP-day-one, because retrofitting compliance costs more than building inside it — the cost model puts numbers on both paths.

The common mistake, in one paragraph. Teams scope the boxes and forget the arrows. The visible features — video, chat, booking — demo well in week six. The arrows — EHR sync that survives conflicts, claims that pass clearinghouse validation, reminders that don't leak diagnoses, recordings that land in BAA-covered storage with retention timers — are where telemedicine builds actually spend their budget, and where the common HIPAA mistakes live. If your estimate prices the boxes, double it for the arrows.

Figure 4. The integration ring. Each spoke is a standard, a counterparty, and a compliance question: FHIR R4/US Core to the EHR, NCPDP SCRIPT to pharmacy, HL7 v2/FHIR to labs, X12 837/835 to payers, OIDC/SAML to identity.

How big is this market, really

One number keeps the whole map in proportion: telehealth accounts for roughly 5% of US commercial medical claim lines through 2025 (FAIR Health's monthly tracker has it oscillating between 4.8% and 5.1%) [16]. That is far below the pandemic spike and far above the pre-2020 baseline — a stable, structural slice of care delivery. The platforms that hold that slice are the ones that treat the map above as one product: the visit, the record, the claim, and the compliance wrapper, engineered together.

Where Fora Soft fits in

Fora Soft has been building video software since 2005 — telemedicine platforms among 239+ shipped projects across video conferencing, streaming, surveillance, e-learning, and OTT. In telemedicine engagements we own exactly this map: the WebRTC core with TURN/SFU capacity planned for clinical reliability, the PHI inventory with encryption and audit logging designed in from the first sprint, and the integration ring — EHR, e-prescribing, billing — scoped against the real standards calendar rather than optimistic assumptions. Compliance-first means we start from the requirement (which data is PHI, which vendors need BAAs, what the audit log must prove) and then make the product fast and pleasant inside that boundary.

What to read next

• HIPAA in plain English for product teams — the rules behind the wrapper.
• WebRTC for telemedicine — the video core's clinical gotchas.
• The telemedicine cost model — what this map costs to build and run.

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your telemedicine platform architecture plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Platform Anatomy PHI Worksheet — One-page worksheet to inventory PHI, BAA coverage, and audit logging across the ten subsystems of a telemedicine platform.

References

1. 45 CFR §164.312 — Security Rule, Technical Safeguards. eCFR (current as of 2026-06-02). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 — Tier 1. Access control, audit controls, integrity, person/entity authentication, transmission security; required vs addressable specifications.
2. Telehealth policy updates — HHS / telehealth.hhs.gov (updated 2026). https://telehealth.hhs.gov/providers/telehealth-policy/telehealth-policy-updates — Tier 1. CAA 2026 extension of Medicare telehealth flexibilities through 2027-12-31; behavioral telehealth permanent.
3. 45 CFR Part 162 — HIPAA Administrative Requirements (transaction standards: X12 837/835). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162 — Tier 1.
4. ITU-T Recommendation G.114 (05/2003) — One-way transmission time. https://www.itu.int/rec/T-REC-G.114 — Tier 1. ≤150 ms one-way delay guidance; 400 ms planning ceiling.
5. HTI-1 Final Rule; USCDI v3 as certification baseline from 2026-01-01 — ASTP/ONC. https://healthit.gov/regulations/hti-rules/hti-1-final-rule/ — Tier 1. FHIR R4 / US Core; USCDI version timeline.
6. KLAS Research 2026 US Acute Care EHR Market Share (May 2026), as reported by HealthSystemCIO / HIT Consultant. https://healthsystemcio.com/2026/05/14/acute-care-ehr-market-share-2026/ — Tier 5. Epic 43.7% of hospitals, 56.9% of beds; Oracle Health 21.9% / 20.4%.
7. NIST SP 800-63 (Digital Identity Guidelines) — IAL/AAL framework. https://pages.nist.gov/800-63-3/ — Tier 1.
8. IETF RFC 5763 / RFC 5764 — DTLS-SRTP framework and protection profile (with RFC 3711, SRTP). https://datatracker.ietf.org/doc/html/rfc5764 — Tier 1. WebRTC media encryption in transit.
9. Vendor HIPAA/BAA documentation: Twilio HIPAA eligibility (twilio.com/en-us/hipaa); Vonage Video API HIPAA; Daily HIPAA plans — Tier 4. BAA availability claims; verify product eligibility lists and plan tiers at contract time.
10. CMS — E-Prescribing Standards; Final Rule adopting NCPDP SCRIPT v2023011 (89 FR, 2024-06-17): transition ends 2028-01-01 (v2017071 expires). https://www.cms.gov/medicare/regulations-guidance/electronic-prescribing — Tier 1.
11. DEA/HHS — Fourth Temporary Extension of COVID-19 Telemedicine Flexibilities for Prescription of Controlled Medications, 90 FR (2025-12-31); effective through 2026-12-31. https://www.federalregister.gov/documents/2025/12/31/2025-24123/ — Tier 1.
12. HHS OCR — Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates (as revised; "proscribed combination" vacated by N.D. Tex., 2024-06-20; appeal withdrawn). https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html — Tier 1 (with court ruling noted). Authenticated-page trackers handle PHI and require BAA/authorization.
13. HHS OCR — HIPAA Security Rule NPRM (90 FR 898, published 2025-01-06; comments closed 2025-03-07; >4,700 comments; no final rule as of 2026-06). https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html — Tier 1. Proposed: mandatory encryption, MFA, asset inventory, annual audits.
14. 45 CFR §164.404 — Breach Notification Rule: notice to individuals without unreasonable delay, ≤60 days from discovery. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D/section-164.404 — Tier 1.
15. IBM — Cost of a Data Breach Report 2025. https://www.ibm.com/reports/data-breach — Tier 5. Healthcare costliest industry 14 years running; $7.42M average (2025); 279 days to identify and contain.
16. FAIR Health — Monthly Telehealth Regional Tracker (2025 data). https://www.fairhealth.org/fh-trackers/telehealth — Tier 5. Telehealth ~4.8–5.1% of commercial medical claim lines through 2025.