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

Why this matters

Telemedicine teams rarely fail compliance on the hard problems — they fail on defaults: the logging library that captures request URLs, the analytics snippet copied from the last startup, the push notification that helpfully includes the message preview. If you are a founder, product manager, or hospital IT lead, this article gives you a concrete inspection list you can run against your build before a regulator, a plaintiff's lawyer, or a journalist runs it for you. Each mistake comes with the exact rule citation your compliance officer needs and the engineering fix your developers need, so the same page serves both conversations. The pattern beneath all ten mistakes is worth learning once: patient data flows downhill into every system you connect, unless you design the dam. For the architecture that prevents these failures wholesale rather than one by one, pair this article with the compliance-boundary pattern.

The breach you build yourself

Start with the legal frame, because it explains why innocent-looking engineering is the problem. The Health Insurance Portability and Accountability Act (HIPAA) protects health information that can be tied to an identifiable person — called protected health information, or PHI. The Privacy Rule's general rule, 45 CFR §164.502(a), says a covered entity or business associate may not use or disclose PHI except as the rule permits. Note what is missing from that sentence: intent. A disclosure does not need a hacker, a thief, or a motive to be impermissible. A URL that carries a diagnosis to an ad network is a disclosure. A recording in a bucket the public can list is a disclosure. The rule does not care that it was a default setting.

That matters because of what an impermissible disclosure triggers. Under the Breach Notification Rule (45 CFR §§164.400–414), an impermissible acquisition, access, use, or disclosure of unsecured PHI is presumed to be a reportable breach unless you can demonstrate — through a documented risk assessment — a low probability that the data was compromised. Reportable means: individual notice without unreasonable delay and no later than 60 days from discovery (§164.404), notice to HHS (§164.408, within 60 days for breaches affecting 500 or more people), and, at 500+ affected individuals in a state, notice to prominent media outlets (§164.406). The 60-day clock starts when the mistake is discovered, not when it is fixed — and the clock math is unforgiving, as we walked through in HIPAA in plain English for product teams.

Two enforcement tracks then price the mistake. The HHS Office for Civil Rights (OCR) — HIPAA's enforcement agency — applies civil monetary penalties in four culpability tiers; under the 2026 inflation-adjusted figures they run from $145 to $73,011 per violation, capped at $2,190,294 per provision per calendar year (HHS annual adjustment, effective January 28, 2026). And if your product is a direct-to-consumer wellness or telehealth app that sits outside HIPAA, the Federal Trade Commission (FTC) covers the gap with the Health Breach Notification Rule (16 CFR Part 318, final rule of May 30, 2024) and its general deception authority — the legal basis for every case in this article that names a consumer telehealth brand.

Here is the arithmetic, out loud, for one concrete scenario. Suppose a misconfigured bucket exposes 50,000 consult recordings, and OCR treats it as the lowest culpability tier — "did not know and could not reasonably have known," $145 minimum per violation:

50,000 exposed records × $145 = $7,250,000 in theoretical exposure, capped by regulation at $2,190,294 for that provision in that calendar year.

The cap sounds like relief until you notice it applies per provision per year — a bucket that also evidences a missing risk analysis and a missing business associate agreement stacks three provisions — and until you add the costs the cap does not touch: individual notification at roughly a dollar or two per letter, credit monitoring, the class action, the state attorneys general, and the enterprise deals that pause while your name is on the HHS breach portal, which the industry calls the "wall of shame" for a reason.

One more piece of the frame. The contract that lets any vendor lawfully handle PHI on your behalf is called a Business Associate Agreement (BAA) — the signed promise every contractor must make before they get a key to the building. The Privacy Rule conditions vendor disclosures on it (45 CFR §164.502(e), with the contract requirements in §164.504(e)), and the Security Rule repeats the requirement for ePHI (§164.308(b)). Six of the ten mistakes below are, at bottom, the same mistake: PHI reached a vendor that never signed. We dissected the contract itself in the BAA article; here you will watch it not exist, ten different ways.

Telemedicine PHI boundary with ten leak paths: URLs, logs, test data, analytics, buckets, tickets, push, email, process gaps Figure 1. The failure gallery as a map. Every solid arrow is data leaving the BAA-covered boundary — an impermissible disclosure under §164.502(a) unless an agreement or authorization covers the destination. The two dashed gaps are process failures that make the arrows likely.

Family one — PHI put where it does not belong

Mistake 1. PHI in URLs and query strings

It starts innocently: the appointment deep link is /visit?patient=jane.doe&clinic=hiv-care, the results page is /results?test=hiv&outcome=positive, the calendar invite carries ?dx=F32.1 (the ICD-10 code for major depressive disorder). The application works. The demo goes well. And the URL — the one string engineers treat as an address — is now a clinical record.

The problem is replication. A URL is the most-copied string in computing: it lands in the browser history of a shared family computer, in your web server's access logs, in your content-delivery network's logs, in the Referer header sent to whatever third party hosts a font, a script, or a pixel on the next page, in the analytics payload of every tag on the page, and in the screenshot a patient attaches to a support ticket. One tap, five copies, none of them deletable on demand. OCR's online-tracking guidance (December 2022, revised March 2024) calls out exactly this vector — query strings and URL paths that reveal health conditions flowing to tracking vendors. Each copy that reaches a party without a BAA or an authorization is an impermissible disclosure under §164.502(a), and the transmission-security standard (§164.312(e)(1)) obliges you to guard ePHI in transit — TLS encrypts the URL on the wire but does nothing about the copies at either end.

The fix. Treat URLs as public. Identifiers in paths are opaque and meaningless (/visit/9f3k2x), clinical context travels in POST bodies or authenticated API responses, deep links resolve through short-lived signed tokens that map to context server-side, and Referrer-Policy: no-referrer (or at minimum same-origin) is set on every authenticated page. Add a CI check that greps route definitions for parameter names like dx, diagnosis, test, med — it is a one-hour task that closes a permanent class of leak.

Mistake 2. PHI in application logs and crash reports

Logging is where engineering virtue becomes a compliance vice. The same instinct that says "log everything, debugging will thank you" produces log lines like GET /api/messages?patient=88321 "I've been having suicidal thoughts" — because the chat service helpfully logs request bodies on error. Crash reporters are worse: a stack trace serializes whatever objects were in memory, and in a telemedicine app the objects in memory are patients. The log stream then flows to a log vendor, the crash dump to a crash-analytics service, and if either lacks a BAA you have built a continuous, automated impermissible-disclosure pipeline running at production scale.

The rules here are unglamorous but exact. Logs containing PHI are ePHI — every Security Rule safeguard applies to them: access control (§164.312(a)), audit controls (§164.312(b)), transmission security (§164.312(e)). The minimum-necessary standard (§164.502(b)) bars workforce-wide readable PHI in a debugging tool every engineer can query. And the vendor that stores the logs is a business associate that must sign (§164.502(e)).

The fix has three layers, in order of effectiveness. First, structure: log references, never payloads — user IDs, session IDs, event names, outcome codes; the rule of thumb from our audit-logging article is that a log line should let you reconstruct that something happened, with the substance fetched from the system of record by someone authorized. Second, scrubbing: a redaction middleware on the logging path that drops known-sensitive fields and pattern-matches stragglers (emails, phone numbers, MRNs) — imperfect by design, which is why it is layer two and not layer one. Third, the vendor: send logs and crash reports only to services under a signed BAA — Datadog (HIPAA-eligible services list), Splunk (HIPAA Premium environment), and Sentry (BAA on Business tier and above) all offer one as of June 2026 — and configure the SDK to strip request bodies and PII fields before transmission, because the BAA permits the vendor to hold PHI; it does not oblige you to send more than necessary.

Mistake 3. Real patient data in test and staging

Under deadline, someone copies the production database into staging "so QA matches reality." Now the realest possible PHI sits in the least protected environment you operate: shared passwords, no audit logging, debug endpoints open, third-party test tools attached, and a seat for every contractor who ever needed to reproduce a bug. HIPAA has no test-environment exception. The Security Rule applies to ePHI wherever it lives, and a staging copy multiplies your attack surface without adding a single safeguard — the opposite of the risk-management duty in §164.308(a)(1)(ii)(B).

The deeper trap is that "we'll anonymize it" usually means "we deleted the name column." HIPAA's de-identification standard (§164.514) accepts exactly two methods — Safe Harbor, which requires removing all 18 identifier categories including dates, device IDs, and full-resolution ZIP codes, and Expert Determination, which requires a documented statistical analysis. A telemedicine dataset with appointment timestamps, free-text chat, and recording references fails Safe Harbor on its face. We walked through both methods, and what survives them, in the de-identification article.

The fix. Generate synthetic data — fake patients with realistic shapes, volumes, and edge cases; tools and scripts for this are a solved problem and a one-sprint investment. Where a production-shaped dataset is unavoidable (load testing against real distributions, say), produce a properly de-identified extract under §164.514, document the method, and treat the extract pipeline as a governed system. And put it in writing: a one-line policy — production PHI never enters non-production environments — turns the next deadline shortcut into a deliberate, visible violation instead of a default.

Family two — vendors that never signed up

Mistake 4. Analytics and advertising SDKs phoning home

This is the mistake with the richest enforcement record, because it is the one whole industries made at once. The default growth stack — Google Analytics, a Meta pixel for ad attribution, a TikTok pixel, a session-replay tool — ships data to its vendor by design. Inside a telemedicine product, that data is "person X, identified by IP, device ID, and cookie, viewed the anxiety-medication page, booked a psychiatry slot, returned twice." An April 2023 Health Affairs study found third-party transfers on 98.6 percent of 3,747 US non-federal hospital websites' homepages — transfers to Alphabet on 98.5 percent and to Meta on 55.6 percent. A 2019 JAMA Network Open study of 36 top depression and smoking-cessation apps found 29 transmitting data to Facebook or Google services, with only 12 disclosing it accurately. The default is the violation, at population scale.

Regulators responded on both tracks. The FTC fined GoodRx $1.5 million (February 2023, the first Health Breach Notification Rule action) for sending medication and condition data to Facebook, Google, and Criteo; banned BetterHelp from sharing health data for advertising and ordered $7.8 million in consumer refunds (finalized July 2023) for routing intake-questionnaire answers, emails, and IPs to Facebook, Snapchat, Criteo, and Pinterest; and ordered Cerebral to pay over $7 million (April 2024) after trackers on its site and apps gave LinkedIn, Snapchat, and TikTok the names, medical and prescription histories, and insurance details of nearly 3.2 million users. In July 2023, the FTC and OCR jointly wrote to roughly 130 hospital systems and telehealth providers warning about exactly these technologies. On the HIPAA side, OCR's tracking bulletin survives with one judicial trim: in AHA v. HHS (N.D. Tex., June 20, 2024) a federal court vacated OCR's theory that an IP address plus a visit to an unauthenticated public health page is by itself PHI — but inside a logged-in telemedicine app or patient portal, where the data demonstrably belongs to a patient, the bulletin's position stands.

The vendor question is binary, the way the BAA article frames every vendor question. Google does not sign a BAA for Google Analytics — Google's own help documentation tells customers not to send HIPAA-covered data, a policy unchanged for GA4 as of June 2026. Meta does not sign one for the pixel. No BAA, no event stream: those tools may live on your public marketing site, where no patient relationship exists, and nowhere else.

The fix. Product analytics moves to a vendor that signs — Mixpanel and Amplitude both offer BAAs on qualifying plans (vendor-published status, June 2026) — or to self-hosted tooling inside your boundary. Events are designed PHI-light (event names and opaque IDs, no free text, no health-state property names), ad attribution is measured on the marketing site and severed at the authenticated door, and the platform's egress is allowlisted so a stray SDK cannot phone home from a clinical surface even if a developer adds one. The full analytics architecture — including when de-identified event streams can lawfully leave — is in analytics on health data.

Mistake 5. Recordings in an un-BAA'd bucket

A consult recording is the densest PHI artifact your product creates: face, voice, name, condition, prescription, all in one file. The mistake is storing it like any other media asset — in a consumer Dropbox or Google Drive tied to a founder's account, in an S3 bucket with a public-read ACL someone set during a debugging session, on an FTP server nobody inventoried. OCR's enforcement archive shows how this ends. Touchstone Medical Imaging paid $3 million (May 2019) after an FTP server allowed anonymous access to 307,839 patients' records — files were indexed by search engines and remained retrievable even after the server went dark, and notification ran 147 days behind discovery against a 60-day rule. MedEvolve, a billing business associate, paid $350,000 (2023) for an FTP server that exposed 230,572 people's data plus a missing subcontractor BAA. St. Joseph Health paid $2.14 million (October 2016) because a file server's default configuration left patient files reachable through Google searches.

The rule stack is familiar by now: impermissible disclosure (§164.502(a)) for the exposure, missing BAA (§164.502(e)) if the storage vendor never signed, encryption at rest as the addressable-but-effectively-expected safeguard (§164.312(a)(2)(iv)) — addressable meaning you implement it or document why an equivalent alternative protects the data, never meaning optional — and access controls plus audit trails (§164.312(a), (b)) for who retrieved which recording, when.

The fix. Recordings live in object storage covered by your cloud BAA (AWS, Google Cloud, and Azure all sign for their core storage services), encrypted at rest with keys you manage, in buckets that are private by policy and by organization-level control (S3 Block Public Access or its GCP/Azure equivalent, set at the account level so a developer cannot un-set it per bucket), with access through short-lived signed URLs issued by your API — never through long-lived links, which are passwords in URL form and reproduce Mistake 1. Every retrieval is logged. Retention follows a written schedule, because a recording you no longer need is risk with no offsetting value — the consent and retention rules that govern when you may record at all are in patient consent, recording, and data retention, and the encryption stack is in the encryption article.

Mistake 6. Screenshots and PHI in support tickets

Support is the leak nobody owns. A patient cannot join her appointment; the support agent asks for a screenshot; the screenshot shows her name, her clinician's name, the appointment type ("Behavioral health — intake"), and two chat messages. The ticket — now a clinical record — sits in a helpdesk that never signed a BAA, is forwarded to a contractor in another time zone, and is quoted in a Slack channel with 40 members. None of these systems is hostile. All of them are now holding PHI outside your boundary.

The rule analysis is the same binary as ever: the helpdesk vendor, the chat tool, and the screen-sharing service that touch identifiable patient data in support workflows are business associates and must sign (§164.502(e)); the minimum-necessary standard (§164.502(b)) separately requires that support staff see the narrowest slice that resolves the issue — and a free-form screenshot is rarely the narrowest slice. Cerebral's FTC complaint (April 2024) shows the adjacent failure mode: support and operations practices so loose that promotional postcards revealed users' diagnosis and treatment plainly on the card — over 6,000 patients, no envelope.

The fix. Put the helpdesk under contract or out of the data path: Zendesk signs a BAA on its Enterprise tier with the advanced-compliance add-on (vendor-published status, June 2026); several competitors have equivalents. Then shrink what support needs to see: an in-product "report a problem" flow that captures structured diagnostics (session ID, device, connection stats) instead of screenshots; automatic redaction on attachment upload; agent access to patient context through your own scoped, logged support console rather than data pasted into tickets — the impersonation-and-audit pattern from the audit-logging article. And write the one-line policy that makes violations visible: PHI does not enter ticket text; tickets carry reference IDs only.

Family three — messages that say too much

Mistake 7. Push notifications that reveal the diagnosis

A push notification renders on a lock screen — visible to whoever glances at the phone on the kitchen table, the meeting-room desk, the hospital nightstand. "Your HIV test results are ready." "Time for your lithium refill." "Therapy with Dr. Reyes in 15 minutes." Each is a disclosure to anyone within eyeshot, made by your product, by design. The infrastructure compounds it: a notification payload transits Apple's and Google's push services, and neither is BAA-covered for this purpose — Apple offers no BAA for its push service, and Firebase Cloud Messaging does not appear on Google Cloud's list of BAA-covered products, whose terms require not using non-covered services with PHI at all. The payload is a postcard: it travels through a carrier that never promised confidentiality, with the message on the outside.

The fix is an architecture, not a setting, and it is mercifully simple. The push payload carries nothing clinical — a generic title ("You have a new message"), an opaque reference, a badge count. On tap, the app wakes, authenticates, and fetches the actual content over TLS from your BAA-covered backend, rendering it only inside the authenticated screen. Where platforms support it, use silent or data-only pushes that trigger a fetch with no visible preview at all, and let patients choose notification verbosity in settings — some will trade privacy for glanceability, but that is their authorization to give, not your default to set. The same logic extends to the notification category: a push from "HIV Care Clinic" leaks through the app name itself, which is a product-naming decision worth making deliberately for sensitive verticals.

Mistake 8. Email and SMS reminders that overshare

The appointment-reminder email that says "Psychiatry follow-up, Thursday 3 pm, Dr. Chen" has disclosed a mental-health relationship to whoever reads over a shoulder, shares the inbox, or operates the mail server. SMS is plaintext on the carrier network. Neither channel is inside your boundary, and unlike push you cannot architect the rendering — the content is the message. HHS treats unencrypted email and SMS with patients as permissible if the patient is warned of the risk and still prefers the channel — a preference you must capture, honor, and be able to show — while the minimum-necessary instinct says the reminder needs only "You have an appointment Thursday at 3 pm — sign in for details."

The fix. Default templates carry zero clinical context: no specialty, no clinician name in sensitive verticals, no test names, no medication names — a time, a generic practice name, a link into the authenticated app (an opaque link: Mistake 1 applies to email URLs too). Channel preferences and the risk acknowledgment are captured at onboarding as part of the consent flow described in roles, identity, and consent, and the messaging vendor — Twilio and its peers sign BAAs for eligible services — is under contract, which covers the vendor's handling but still does not encrypt the last hop to the handset. Contract plus content discipline together close the channel; either alone does not.

Family four — the process you skipped

Mistake 9. No risk analysis anyone can show an auditor

Every technical mistake above becomes an enforcement multiplier through one administrative failure: the missing risk analysis. The Security Rule's first required implementation specification (§164.308(a)(1)(ii)(A)) demands an accurate, thorough assessment of risks to all ePHI you hold — and it is the single most-cited gap in OCR's resolution agreements. OCR thought the failure common enough to launch a dedicated Risk Analysis Initiative in October 2024; its enforcement actions under the initiative have accumulated steadily since, with settlements from $10,000 to $350,000 and corrective-action plans that outlast the fines by years. Touchstone, MedEvolve, and the ransomware settlements all carry the same finding, because the investigation script is stable: breach happens, OCR asks for the risk analysis, there is none, and the case stops being about the breach.

The product insight is that a risk analysis is not paperwork about engineering — done properly, it is the document where the ten mistakes in this article get found before production. A telemedicine-shaped risk analysis walks the PHI flow end to end (the walk we do in the platform-anatomy article): every system that touches PHI, including the log pipeline, the crash reporter, the staging environment, the helpdesk, and the push path — exactly the systems teams forget — with a likelihood-and-impact ranking and a dated remediation plan. NIST SP 800-66 Rev. 2 (February 2024) is the federal how-to. The proposed 2026 Security Rule update (NPRM of January 6, 2025, RIN 0945-AA22; still a proposed rule as of 2026-06-11) would sharpen this further — a written asset inventory and network map, annual compliance audits, and removal of the addressable/required distinction — so a risk analysis built properly today is also the cheapest preparation for the rule that is coming.

The fix. Build the asset inventory and data-flow map first (the 2.10 boundary diagram is the visual form), run the risk analysis against it, date it, and re-run on a schedule and on every architectural change. Keep the remediation log — OCR's 2026 posture expects evidence that identified risks were acted on, not merely listed.

Mistake 10. Access that outlives the employee

The Cerebral complaint contains one detail every engineering leader should pin above their desk: from May to December 2021, former employees retained access to patient medical records — for seven months after leaving. No exotic attack, just offboarding that nobody owned. The same failure wears other costumes: the shared clinic-front-desk login that survives every staff change because changing it is annoying; the contractor's API key from a 2024 integration project, still valid; the agency analyst with production database access "temporarily" since the migration. The Security Rule addresses all of them directly — workforce-clearance and termination procedures (§164.308(a)(3)), access authorization and review (§164.308(a)(4)), unique user identification as a required specification (§164.312(a)(2)(i)) — and the proposed 2026 update would tighten the screw to a 24-hour notification duty between entities when workforce access changes.

The fix is the access-lifecycle loop from the audit-logging article: provisioning tied to the HR system so termination revokes same-day and automatically; unique identities everywhere, with shared logins eliminated as a matter of policy and of build (devices get device identities, not human ones); quarterly access recertification where every role and every standing credential is re-confirmed by an owner; and audit alerts on dormant-account activity, because the log that nobody reviews is Memorial Healthcare's $5.5 million lesson (February 2017) — twelve months of unreviewed access by a former affiliate's credentials.

The default stack, rebuilt

The table below is the shortest version of this article: the tools a team reaches for by default, whether a BAA is available, and what belongs in a telemedicine build instead. Vendor BAA status is plan-dependent and changes — figures are vendor-published status as of June 2026; re-verify at contract time.

Default tool BAA available? The mistake it enables What to do in a telemedicine build
Google Analytics 4 No (Google: do not send HIPAA data) #4 — clinical events to an ad platform Public marketing pages only; BAA'd product analytics inside the app
Meta / TikTok pixel No #4 — patient identity to ad networks Marketing site only; sever at the authenticated door
Mixpanel / Amplitude Yes (qualifying plans) — PHI-light event design; opaque IDs; BAA signed before the SDK ships
Firebase Cloud Messaging / APNs No (not BAA-covered) #7 — diagnoses on lock screens Generic payloads; data-only push; content fetched from BAA'd backend
Sentry Yes (Business tier+) #2 — PHI in crash dumps BAA + SDK configured to strip bodies and PII
Datadog / Splunk Yes (eligible services / HIPAA environment) #2 — PHI in log lines BAA + reference-only logging + scrubbing middleware
Consumer Dropbox / Google Drive No (consumer tiers) #5 — recordings in personal clouds Cloud-BAA object storage, private by org policy, signed-URL access
AWS S3 / GCS / Azure Blob Yes (under cloud BAA) #5 if misconfigured Block-public-access at org level; KMS encryption; access logging
Zendesk Yes (Enterprise + compliance add-on) #6 — PHI in tickets BAA + redaction + reference-ID-only ticket policy
Twilio (SMS/voice, eligible services) Yes #8 — clinical content in SMS BAA + zero-clinical-content templates + captured channel consent

Table 1. The default startup stack, audited. "BAA available" is necessary, never sufficient — a signed BAA does not fix PHI-heavy event design, public buckets, or chatty notification templates.

And one explicit callout for the meta-mistake beneath the table — the confusion this section's style guide bans us from ever blurring: "encrypted" is not "compliant." Every vendor in the table encrypts in transit. Encryption answers eavesdropping; it does not answer authorization — whether the recipient is lawfully allowed to hold the data at all. A pixel over TLS is an encrypted violation. Test data on an encrypted laptop in a contractor's home is an encrypted violation. The BAA question and the encryption question are separate gates, and a telemedicine build passes both or neither.

Telemedicine URL with diagnosis parameters fanning out into five stored copies, with the opaque-identifier fix beneath Figure 2. One URL, five copies. The address string replicates into systems you do not control — which is why the fix is making the string meaningless, not guarding the copies.

Push notification revealing test results versus a generic one with content fetched inside the authenticated app Figure 3. The push-notification pattern. FCM and APNs are not BAA-covered carriers — the payload is a postcard, so the postcard carries nothing.

Ten-row matrix of common HIPAA mistakes with the engineering fix and rule citation for each Figure 4. The whole gallery on one card — the visual twin of the downloadable audit checklist.

Where Fora Soft fits in

Fora Soft has built video software since 2005 — telemedicine platforms among 239+ shipped projects across video conferencing, streaming, surveillance, e-learning, and OTT — and the compliance-first habit this article preaches is how our healthcare builds start: the PHI flow map and vendor-BAA audit come before the first sprint, not after the first incident. In practice that means the checks in this article are baked into architecture — opaque-identifier URL schemes, reference-only logging with scrubbing middleware, BAA-verified vendor stacks, push and reminder templates that disclose nothing, and access provisioning wired to offboarding from day one. When a client arrives with an existing build, the audit below is the first deliverable: ten mistakes, checked against the codebase, with a remediation plan an auditor can read.

What to read next

If you want the basics-level view of healthcare app compliance before this deep dive, start with our compliance guide for healthcare apps.

Call to action

References

  1. 45 CFR §164.502 — Uses and disclosures of protected health information: general rules (a); minimum necessary (b); disclosures to business associates (e). eCFR, read 2026-06-11. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502 Tier 1.
  2. 45 CFR §164.312 — Security Rule technical safeguards: access control (a) incl. unique user identification (a)(2)(i) and encryption at rest (a)(2)(iv); audit controls (b); transmission security (e). eCFR, read 2026-06-11. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 Tier 1.
  3. 45 CFR §164.308 — Administrative safeguards: risk analysis (a)(1)(ii)(A), risk management (a)(1)(ii)(B), workforce security and termination (a)(3), access management (a)(4), BAA requirement (b). eCFR, read 2026-06-11. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308 Tier 1.
  4. 45 CFR §§164.400–414 — Breach Notification Rule: presumption of breach and risk assessment (§164.402); 60-day individual notice (§164.404); media notice (§164.406); HHS notice (§164.408). eCFR, read 2026-06-11. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D Tier 1.
  5. 45 CFR §164.514 — De-identification: Safe Harbor (b)(2) and Expert Determination (b)(1); §164.504(e) — business associate contract requirements. eCFR, read 2026-06-11. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514 Tier 1.
  6. HHS OCR — Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates (bulletin, December 2022, revised March 2024) — partially vacated as to unauthenticated public pages by AHA v. HHS, No. 4:23-cv-01110 (N.D. Tex., June 20, 2024); HHS withdrew its appeal September 2024. Status checked 2026-06-11. https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html Tier 1, with judicial limitation noted.
  7. HHS — HIPAA Security Rule NPRM, 90 FR 898 (January 6, 2025), RIN 0945-AA22 — proposed asset inventory/network map, MFA, annual audits, removal of addressable distinction, 24-hour access-change notification. Status: proposed as of 2026-06-11. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information Tier 1.
  8. HHS — Annual Civil Monetary Penalties Inflation Adjustment (effective January 28, 2026): $145–$73,011 per violation, $2,190,294 per-provision annual cap. https://www.federalregister.gov/documents/2026/01/28/2026-01688/annual-civil-monetary-penalties-inflation-adjustment Tier 1.
  9. FTC — Health Breach Notification Rule, Final Rule, 89 FR 47028 (May 30, 2024), 16 CFR Part 318. https://www.federalregister.gov/documents/2024/05/30/2024-10855/health-breach-notification-rule Tier 1.
  10. FTC enforcement: GoodRx, $1.5M civil penalty, first HBNR action (February 2023); BetterHelp, $7.8M consumer refunds and ad-use ban (final order July 2023); Cerebral, $7M+ proposed order (April 15, 2024 — ~3.2M consumers; trackers to LinkedIn, Snapchat, TikTok; diagnosis-revealing postcards to 6,000+ patients; former-employee access May–December 2021). Read 2026-06-11. https://www.ftc.gov/news-events/news/press-releases/2024/04/proposed-ftc-order-will-prohibit-telehealth-firm-cerebral-using-or-disclosing-sensitive-data · https://www.ftc.gov/news-events/news/press-releases/2023/07/ftc-gives-final-approval-order-banning-betterhelp-sharing-sensitive-health-data-advertising Tier 2.
  11. FTC & HHS OCR — joint letter to ~130 hospital systems and telehealth providers on tracking technologies (July 2023). https://www.ftc.gov/news-events/news/press-releases/2023/07/ftc-hhs-warn-hospital-systems-telehealth-providers-about-privacy-security-risks-online-tracking Tier 2.
  12. HHS OCR resolution agreements: Raleigh Orthopaedic Clinic, $750,000 (2016 — X-rays of 17,300 patients to a vendor with no BAA); Center for Children's Digestive Health, $31,000 (2017 — record-storage vendor, no BAA); Advanced Care Hospitalists, $500,000 (December 2018 — billing vendor, no BAA, no risk analysis); Touchstone Medical Imaging, $3,000,000 (May 2019 — anonymous-access FTP server, 307,839 individuals, search-engine indexing, 147-day-late notice); St. Joseph Health, $2,140,500 (October 2016 — default server settings exposed files to internet searches); MedEvolve, $350,000 (2023 — exposed FTP server, 230,572 individuals); Memorial Healthcare System, $5.5M (February 2017 — unreviewed access by former-affiliate credentials). https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/index.html Tier 2.
  13. HHS OCR — Risk Analysis Initiative (launched October 2024; ongoing enforcement actions citing §164.308(a)(1)(ii)(A), settlements $10,000–$350,000 range as of mid-2026). https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/index.html Tier 2 — counts to be re-verified at publication.
  14. NIST SP 800-66 Rev. 2 — Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (February 2024). https://csrc.nist.gov/pubs/sp/800/66/r2/final Tier 1.
  15. Friedman, A.B., et al. — "Widespread Third-Party Tracking on Hospital Websites…" Health Affairs 42(4), April 2023 — 98.6% of 3,747 hospital homepages with ≥1 third-party transfer; Alphabet 98.5%, Meta 55.6%. https://pmc.ncbi.nlm.nih.gov/articles/PMC11145977/ Tier 5.
  16. Huckvale, K., Torous, J., Larsen, M.E. — "Assessment of the Data Sharing and Privacy Practices of Smartphone Apps for Depression and Smoking Cessation." JAMA Network Open 2(4), 2019 — 29/36 apps transmitted data to Facebook or Google; 12/29 disclosed accurately. https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2730782 Tier 5.
  17. Google — Google Analytics and HIPAA (no BAA; do not send HIPAA-covered data — policy checked 2026-06-11); Google Cloud — HIPAA compliance covered-products terms (non-covered products, including Firebase Cloud Messaging, must not be used with PHI). https://support.google.com/analytics/answer/13297105 · https://cloud.google.com/security/compliance/hipaa Tier 4.
  18. Vendor BAA policies (plan-dependent; vendor-published status June 2026): Sentry (Business tier+); Zendesk (Enterprise + Advanced Data Privacy and Protection add-on); Datadog (HIPAA-eligible services); Mixpanel; Twilio (eligible services). https://sentry.zendesk.com/hc/en-us/articles/23858023552283 · https://support.zendesk.com/hc/en-us/articles/4408820063898 · https://www.datadoghq.com/legal/hipaa-eligible-services/ · https://mixpanel.com/legal/mixpanel-hipaa/ Tier 4.
  19. The HIPAA Journal / Compliancy Group — telehealth-violation listicles (competitor reference only; commonly blur "encrypted" with "compliant" and omit the per-vendor BAA analysis — overridden by rule text per §164.502(e)). https://www.hipaajournal.com/hipaa-guidelines-on-telemedicine/ Tier 7.

Where lower-tier sources disagreed with rule text, the rule won: "Zoom/our stack is HIPAA compliant" claims are reframed as configuration-plus-BAA states, never product properties; "encryption makes you compliant" is contradicted by §164.502(a)/(e), which govern authorization regardless of transport security; and the vacated portion of the OCR tracking bulletin is described with its judicial limitation rather than as live rule everywhere.