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

Why this matters

If you are building a telemedicine product, HIPAA is not a legal footnote — it decides your architecture, your vendor list, your logging design, and your launch date. Most explanations come in two unusable flavors: legal prose written for compliance officers, and vendor checklists that skip the parts that decide lawsuits. This article is the third option: what the law actually requires, traced to the rule text, translated into product decisions. It is the anchor of our compliance block — the later articles on the 2026 Security Rule update, Business Associate Agreements, and encryption all build on the vocabulary defined here. Read it once and every auditor conversation afterwards gets shorter.

One law, one question

The Health Insurance Portability and Accountability Act — HIPAA — was signed in 1996 (Public Law 104-191). The name explains the surprise most builders feel: it was an insurance-portability law, and the privacy and security regulations grew out of one section of it. The regulations that matter to a product team live in Title 45 of the Code of Federal Regulations, Parts 160 and 164, and arrived in waves: the Privacy Rule (compliance required 2003), the Security Rule (2005), and the Breach Notification Rule (2009, under the HITECH Act). The 2013 Omnibus Rule (78 FR 5566) then extended direct liability to vendors — the change that made HIPAA a software-industry concern rather than a hospital-only one.

Before any of the three rules applies, HIPAA asks a single gating question: are you handling protected health information in a regulated role? That question has two halves — what data counts, and what role you play. Get those two right and the rest of the law unfolds in order. Get them wrong and teams either over-build (treating fitness data like hospital records) or under-build (running patient video through an analytics stack that was never allowed to see it).

PHI: the unit of risk

The data HIPAA protects is called Protected Health Information, or PHI. The definition (45 CFR §160.103) is broader than most engineers expect: any information about a person's past, present, or future health, the care they received, or the payment for that care — if it can be tied to an identifiable person and is held or transmitted by a regulated entity. The electronic form is called ePHI. There is no "medical-grade data" threshold. An appointment time plus a name is PHI. A patient's email address inside your telemedicine platform is PHI. The fact that a person is a patient of a psychiatric clinic at all is PHI, even with no diagnosis attached.

The regulation's de-identification section gives the most concrete picture of what "identifiable" means. The Safe Harbor method (45 CFR §164.514(b)(2)) lists 18 categories of identifiers that must be removed before health data stops being PHI: names; geographic units smaller than a state; all date elements except the year (birth dates, admission dates, visit dates); phone and fax numbers; email addresses; Social Security numbers; medical record numbers; health-plan beneficiary numbers; account numbers; certificate and license numbers; vehicle identifiers; device identifiers and serial numbers; URLs; IP addresses; biometric identifiers; full-face photographs; and any other unique identifying number, characteristic, or code. The alternative is Expert Determination (§164.514(b)(1)) — a statistician formally certifies that re-identification risk is very small.

Read that list again as an engineer, because three entries sink products regularly. IP addresses are identifiers. URLs are identifiers — a path like /booking/dermatology-biopsy-followup attached to a user is health information about an identified person. Device identifiers are identifiers. This is why piping raw telemetry from a telemedicine app into a consumer analytics tool is a disclosure of PHI, not "anonymous usage data". We cover the analytics trap in detail in common HIPAA mistakes.

One more boundary matters: the same data point can be PHI in one context and not in another. A heart rate in a consumer fitness app the user downloaded independently is not PHI — no covered entity is involved. The identical number, flowing through a remote-monitoring platform a clinic deployed, is PHI. The data did not change; the role of the handler did. Which brings us to the question that determines your entire compliance posture.

Covered entity or business associate — which one is your startup?

HIPAA regulates two kinds of organizations directly (definitions in 45 CFR §160.103).

A covered entity is one of three things: a healthcare provider that transmits health information electronically in connection with standard transactions (billing, eligibility checks), a health plan, or a healthcare clearinghouse. Doctors, hospitals, clinics, insurers, pharmacies — and yes, a telehealth practice that employs its own clinicians is a covered entity.

A business associate is any person or company that creates, receives, maintains, or transmits PHI on behalf of a covered entity (or on behalf of another business associate). The contract that formalizes this — the signed promise a vendor makes before it gets a key to the building — is the Business Associate Agreement (BAA). Since the 2013 Omnibus Rule, business associates are directly liable under the Security Rule, the Breach Notification Rule, and large parts of the Privacy Rule. OCR can fine a vendor without ever involving the customer.

For a product team, the mapping is usually this:

Your situation Your HIPAA role What it means
You build/operate a telemedicine platform that clinics or providers use with their patients Business associate Sign a BAA with each customer; full Security and Breach Rule obligations; Privacy Rule limits on use
You run a direct-to-consumer telehealth service that employs or contracts the clinicians Covered entity (the medical group), platform arm often its business associate The full weight of all three rules
Your consumer wellness app is chosen and used by individuals, no provider relationship Neither — HIPAA does not apply FTC rules apply instead (see below)
You subcontract for a vendor that serves clinics (e.g., you host their video infrastructure) Subcontractor business associate A BAA with the vendor above you; same direct liability

The dividing line for app developers was spelled out by the HHS Office for Civil Rights (OCR) in its health-app guidance: if a covered entity (or its business associate) hires you, pays for the app, or directs you to handle PHI, you are a business associate. If a consumer independently downloads your app and chooses to send their own data somewhere, you are generally not — even if the data came from a hospital's API at the patient's request (HHS OCR, Health App Use Scenarios & HIPAA, 2016; HHS health-apps resources). The FTC's Mobile Health App Interactive Tool walks through the same logic question by question.

"Neither" is not "unregulated". A consumer health app outside HIPAA falls under the Federal Trade Commission's Health Breach Notification Rule (16 CFR Part 318, strengthened in 2024), which now covers most health apps and carries its own breach-notification duties — plus FTC Act enforcement for deceptive privacy claims. The choice is not between regulation and freedom; it is between regulatory regimes.

Decision tree from "who uses your product and who pays" to covered entity, business associate, or FTC territory Figure 1. The role decision. Almost every telemedicine product team lands in the middle branch — business associate — and the BAA chain follows the data.

A worked example makes the chain concrete. A hospital contracts TeleCare Inc. to run video visits. TeleCare runs its service on a cloud provider and records sessions to cloud storage. The hospital is the covered entity. TeleCare is its business associate — BAA #1. The cloud provider creates, receives, and maintains ePHI on TeleCare's behalf, so it is a subcontractor business associate — BAA #2, signed between TeleCare and the cloud provider. If TeleCare also sends transcripts to a speech-to-text API, that API vendor needs BAA #3. The chain has no gaps: every hop where PHI lands on someone else's infrastructure needs its own agreement. (The full anatomy of a BAA — what is in it, who refuses to sign, what "HIPAA-eligible service" means — is its own article.)

The three rules, in the order they bite

HIPAA's regulations group into three operative rules. Each governs a different layer of your product.

Three panels summarizing the HIPAA Privacy, Security, and Breach Notification Rules with their product-team obligations Figure 2. One law, three rules. Privacy governs who may see PHI, Security governs how ePHI is protected, Breach Notification governs what happens when protection fails.

The Privacy Rule: who may see and share PHI

The Privacy Rule (45 CFR Part 164, Subpart E; compliance since 2003) is the permission system. Its default is deny: a regulated entity may not use or disclose PHI except as the rule explicitly permits or requires (§164.502). The big permission is TPO — treatment, payment, and healthcare operations (§164.506) — which is why a doctor can send a referral without a signed form. Almost everything else, including marketing and most data sales, requires the patient's written authorization (§164.508).

Two Privacy Rule concepts land directly in product backlogs.

Minimum necessary (§164.502(b)): when using or disclosing PHI, limit it to the minimum needed for the purpose. In software terms this is role-based access control, scoped API responses, and redacted exports — a support engineer debugging a video issue needs call-quality metrics, not the patient's chart. We map this to concrete access-control design in audit logging and access controls.

Patient rights: individuals have a right to access their records (§164.524, within 30 days), request amendments (§164.526), and receive an accounting of certain disclosures (§164.528). If your platform stores clinical records, "export this patient's data" is not a nice-to-have feature; it is the mechanism your covered-entity customers use to honor a federal right on a deadline.

For business associates, the Privacy Rule arrives mostly through the BAA: you may use PHI only as the agreement permits, and a use outside it is a violation even if no data ever leaks. A telemedicine vendor that uses patient session data to train a marketing model "because the data was already there" has violated the Privacy Rule with zero breaches involved.

One 2026 footnote: the 2024 amendment that added special protections for reproductive-health information was vacated nationwide by a federal court in June 2025 (Purl v. HHS, N.D. Tex.), although some Notice of Privacy Practices changes survived with a February 16, 2026 compliance date. It is a live example of why compliance content carries dates — rules move in both directions.

The Security Rule: how ePHI must be protected

The Security Rule (45 CFR Part 164, Subpart C; compliance since 2005) covers electronic PHI only, and it is the rule your architecture answers to. It organizes safeguards into three families: administrative (§164.308 — risk analysis, workforce training, access management, incident procedures), physical (§164.310 — facilities, workstations, device and media controls), and technical (§164.312). The technical safeguards read like a checklist of system design topics, verbatim from the rule: access control with unique user identification and emergency access; audit controls that record and examine activity in systems containing ePHI; integrity protections against improper alteration or destruction; person-or-entity authentication; and transmission security for ePHI moving over a network.

The rule's most misunderstood word is "addressable". Each safeguard standard carries implementation specifications marked Required or Addressable (§164.306(d)). Addressable does not mean optional: it means you must assess whether the specification is reasonable and appropriate for your environment, implement it if it is, and document the analysis and the equivalent measure you adopted if it is not. Encryption of ePHI is — today — addressable (§164.312(a)(2)(iv), §164.312(e)(2)(ii)). No serious telemedicine product treats that as permission to skip encryption; the documented-justification path exists for edge cases like a legacy lab device, not for your production database. The practical 2026 posture: encrypt in transit and at rest, everywhere, and spend your "addressable" arguments on nothing.

The single most enforced sentence in the Security Rule is the risk analysis requirement (§164.308(a)(1)(ii)(A)): conduct an accurate and thorough assessment of the risks to ePHI's confidentiality, integrity, and availability. OCR launched a dedicated Risk Analysis Initiative in late 2024, and by April 2026 it had completed 13 enforcement actions under it — the recurring pattern is a ransomware incident followed by the discovery that the organization never documented a risk analysis at all (HHS OCR, April 23, 2026 announcements). If you keep one compliance artifact current, make it this one.

Two properties of the Security Rule surprise builders, and both are features. First, it is technology-neutral by design (§164.306(b), the "flexibility of approach"): the rule scales its expectations to your size, complexity, and risk profile, and it never names a cipher, a protocol, or a product. Second, it is therefore stable: §164.312 has not changed since 2013 while the technology underneath it turned over several times. The proposed update published January 6, 2025 (90 FR 898) would end part of that era — it proposes making encryption, multi-factor authentication, asset inventories, and annual audits explicitly mandatory, and removing the required/addressable distinction. As of this writing (June 2026) it remains a proposed rule: the comment period closed March 7, 2025, more than 4,000 comments came in, and no final rule has been published. Build to the proposal anyway; every item in it is already standard security practice. The full change set and its video-product implications are in our 2026 Security Rule article.

The Breach Notification Rule: when protection fails

The Breach Notification Rule (45 CFR §§164.400–414; in force since 2009) defines a breach as the acquisition, access, use, or disclosure of unsecured PHI in a manner not permitted by the Privacy Rule, which compromises its security or privacy (§164.402). Two clarifications do a lot of work. "Unsecured" means not rendered unusable to unauthorized persons per HHS guidance — in practice, encrypted-at-rest data whose key did not leak is secured, and its loss is not a reportable breach. This is the regulatory reason encryption is the cheapest insurance in healthcare software. Second, an impermissible disclosure is presumed to be a breach unless you can demonstrate — through a documented four-factor risk assessment — a low probability that the PHI was compromised.

Then the clocks start, and they are exact:

  • Individuals: notify without unreasonable delay, and no later than 60 calendar days after discovery (§164.404(b)).
  • HHS: for breaches affecting 500 or more people, notify contemporaneously with the individual notices; for fewer than 500, log and report within 60 days after the calendar year ends (§164.408).
  • Media: breaches affecting more than 500 residents of one state or jurisdiction also require notice to prominent media outlets (§164.406).
  • Business associate → covered entity: a business associate must notify the affected covered entity without unreasonable delay, no later than 60 days after discovery (§164.410) — and BAAs routinely tighten this to 5–10 days by contract, because the covered entity's own 60-day clock starts running and it needs time to act.

Walk the arithmetic once, because "60 days" feels longer than it is. Say your on-call engineer finds an exposed recordings bucket on March 3, 2026 — discovery day. March has 31 days, so 28 of them remain after March 3. Sixty days minus those 28 leaves 32; April provides 30 more, leaving 2; the deadline lands on May 2, 2026. Inside that window you must run the investigation, complete the four-factor assessment, identify every affected individual, draft notices containing the required content, and mail them. Teams that meet the deadline are the ones whose incident-response runbook existed before the incident.

Timeline of the 60-day breach notification clock from discovery March 3, 2026 to May 2, with parallel BA and HHS clocks Figure 3. The 60-day clock, drawn to scale. The contractual BA→CE notice (often 5–10 days) and the ≥500 HHS/media notices run inside the same window.

What HIPAA does NOT say

Half of HIPAA fluency is knowing what is not in the law. Five things product teams routinely assume are there, and are not:

It names no technology. No AES-256, no TLS version, no password length, no cloud-vs-on-prem stance. The Security Rule defines outcomes (confidentiality, integrity, availability) and lets the risk analysis choose mechanisms. The often-quoted specifics come from NIST guidance (SP 800-66r2 maps the Security Rule to controls), which is excellent engineering input but not regulatory text.

There is no certification. Neither HHS nor anyone else certifies products as "HIPAA compliant". A vendor can be eligible to support your compliance (it signs a BAA, its service has the right controls), and third-party attestations like HITRUST or SOC 2 are useful evidence — but a "HIPAA Certified™" badge has no legal meaning. Compliance is a property of your organization, its documentation, and its running configuration, assessed continuously, never a sticker earned once.

It does not cover all health data. The handler's role decides, as we saw — millions of health-app users are protected by FTC rules, not HIPAA. And separate, stricter federal regimes exist for specific data: substance-use-disorder treatment records carry their own confidentiality statute (42 CFR Part 2), which matters the moment your platform serves behavioral health (covered in state and specialty rules).

It is a floor, not a ceiling. HIPAA preempts contrary state law only when the state law is less protective (45 CFR Part 160, Subpart B). States stack stricter requirements on top — California's CMIA, Texas's HB 300 with its own training and breach rules, Washington's My Health My Data Act reaching non-HIPAA health data. A US-wide telemedicine product complies with HIPAA plus the strictest applicable state layer.

Patients cannot sue under it. HIPAA has no private right of action; enforcement belongs to OCR and state attorneys general. That is no comfort: plaintiffs' lawyers sue over the same incidents under state privacy and negligence law, with HIPAA cited as the standard of care. The regulator is not the only adversary a breach creates.

What ignoring it costs in 2026

Civil penalties are tiered by culpability and adjusted for inflation annually. The amounts effective January 28, 2026 (HHS Annual Civil Monetary Penalties Inflation Adjustment, Federal Register):

Tier Culpability Per violation (2026) Annual cap, per provision (2026)
1 No knowledge, reasonable diligence $145 – $73,011 $2,190,294
2 Reasonable cause, not willful neglect $1,461 – $73,011 $2,190,294
3 Willful neglect, corrected within 30 days $14,602 – $73,011 $2,190,294
4 Willful neglect, not corrected $73,011 – $2,190,294 $2,190,294

Two notes keep the table honest. OCR has, since a 2019 notice of enforcement discretion, applied lower annual caps for tiers 1–3 as a matter of policy — but the regulation's cap is what you see above, and "each violation" can be counted per affected record or per day of noncompliance, which is how settlements reach seven figures fast. Separately, criminal penalties (42 U.S.C. §1320d-6, enforced by the DOJ) reach $250,000 and ten years' imprisonment for obtaining or disclosing PHI under false pretenses or for commercial gain — aimed at individuals, including employees snooping on records.

The enforcement reality in 2026 is less about record fines and more about volume and predictability: ransomware investigations and the Risk Analysis Initiative produced four settlements on a single April day in 2026, most with six-figure-or-below amounts plus multi-year corrective action plans whose monitoring burden often exceeds the fine. The pattern OCR keeps publishing is the same: breach happens → investigation finds no risk analysis, no BAA, or unencrypted data → settlement. None of those three findings is expensive to prevent; all are expensive to explain.

Where telemedicine video meets HIPAA

Everything above applies to any health software. Video adds its own pressure points, which is why this section of Fora Soft Learn exists — and why telemedicine video is harder than a normal video call.

The COVID-era leniency is over. From March 2020 to May 2023, OCR exercised enforcement discretion allowing good-faith telehealth over consumer tools like FaceTime. That notification ended with the public health emergency on May 11, 2023, and its transition period expired August 9, 2023. Since then, full HIPAA compliance applies to remote care — including the BAA for whatever carries the video.

"Zoom is HIPAA compliant" is the wrong sentence. A video platform can be HIPAA-eligible: the vendor signs a BAA on specific plans and the service is configurable to the Security Rule's expectations. Compliance then depends on the BAA being signed, the right plan being purchased, and the configuration being done. Encrypted ≠ compliant; available ≠ configured. The same logic applies to every component in a telemedicine stack:

Stack component Example vendors (2026) BAA available? Note
Cloud infrastructure AWS, Google Cloud, Microsoft Azure Yes Only services the vendor designates as HIPAA-eligible, used per its reference architecture
Video API / CPaaS Vonage, Daily, Zoom (healthcare plans) Yes BAA on specific plans/products only — confirm yours is covered in writing
Open-source SFU, self-hosted mediasoup, Janus, LiveKit (self-hosted) N/A — no vendor handles PHI The compliance burden shifts entirely to your infrastructure and team
Consumer analytics Google Analytics No Must never receive PHI — including IPs and URLs tied to patients
Email / marketing Typical consumer-tier email tools Usually no Appointment reminders containing PHI need a BAA-covered channel
AI / transcription APIs Varies widely Varies Treat "no BAA" as "cannot touch consult audio"; verify per product and plan

BAA availability changes by vendor, product, and plan — verify directly with the vendor, in writing, before PHI flows. For the build-vs-buy decision behind this table, see choosing the video layer.

Common mistake — the un-BAA'd side channel. The classic telemedicine violation is not the video call; it is the periphery. Session recordings copied to a storage bucket nobody listed in the risk analysis. Crash reports that include the consult URL. A support screenshot with a patient's name, pasted into a ticketing tool with no BAA. Push notifications that put a diagnosis on a lock screen. An analytics SDK initialized before consent, dutifully shipping IP + page path — both identifiers — to a server that was never allowed to see them. (OCR's tracking-technology bulletin says exactly this; a 2024 court ruling trimmed its reach on unauthenticated pages, but for logged-in patient surfaces the engineering rule stands.) Every one of these is invisible in a feature demo and obvious in an audit. Design the PHI boundary first — decide which systems are allowed to hold PHI, put a BAA and encryption on each, and route everything else around it.

Compliance-boundary diagram: BAA-covered systems inside the PHI boundary, consumer analytics and marketing tools outside Figure 4. The PHI boundary. Everything inside holds PHI under a BAA with encryption and audit logging; everything outside gets de-identified or synthetic data only.

That boundary diagram is the seed of the full pattern — network segmentation, key management, logging architecture — which we develop in the compliance architecture pattern, and which the anatomy of a telemedicine platform shows in context.

So what do you actually have to do?

Strip the three rules to a product team's to-do list and it is shorter than the legal page count suggests:

  1. Classify yourself — covered entity, business associate, or neither. Everything keys off this (use Figure 1; when in doubt, counsel).
  2. Map the PHI — every system, vendor, log, and backup where PHI can land. The map is the input to the risk analysis.
  3. Run and document the risk analysis (§164.308(a)(1)(ii)(A)) — the artifact OCR asks for first, and the one most enforcement targets lack.
  4. Close the BAA chain — a signed agreement on every hop where a third party creates, receives, maintains, or transmits PHI. No BAA, no PHI: replace the vendor or de-identify the flow.
  5. Implement the safeguards — encryption in transit and at rest, unique identities, MFA, role-based access, audit logging, integrity controls, session timeouts. Today this is "addressable done properly"; under the proposed update it becomes explicit.
  6. Honor the Privacy Rule surface — minimum-necessary access design, patient data export within 30 days, authorization flows for anything beyond TPO, and consent and recording rules for video.
  7. Pre-write the breach playbook — discovery → four-factor assessment → notifications, with the 60-day clock and your contractual BA notice deadline marked. Test it like you test failover.
  8. Train and document — policies, workforce training, sanction policy, six-year documentation retention (§164.316). If it is not written down, it did not happen, as far as an auditor is concerned.

Print-ready version: Download the HIPAA product-team cheat sheet — the three rules, the role test, the 2026 penalty table, and the eight steps on one page. The deeper, audit-oriented version of this list — with evidence checklists per safeguard — is the HIPAA readiness checklist.

Where Fora Soft fits in

Fora Soft has built video software since 2005 — telemedicine platforms among 239+ shipped projects — and HIPAA's requirements are design inputs we engineer for from the first architecture diagram, not a retrofit. In practice that means we scope the PHI boundary with you before choosing vendors, design the BAA chain alongside the system diagram, and build the risk-analysis evidence (encryption posture, access control, audit logging) as part of delivery rather than as a post-launch scramble. Our teams have implemented compliant video consults, session recording with consent flows, and EHR-adjacent integrations for telemedicine products serving US patients. If your product touches PHI, the cheapest moment to get the boundary right is before the first sprint.

What to read next

Building a telemedicine product that has to pass a HIPAA review? Talk to our telemedicine team about HIPAA compliance, see our case studies, or download the HIPAA product-team cheat sheet.

Call to action

References

  1. 45 CFR §160.103 — Definitions: protected health information, covered entity, business associate. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103 (Tier 1)
  2. 45 CFR §164.312 — Security Rule technical safeguards (access control, audit controls, integrity, authentication, transmission security; encryption "addressable" as of June 2026). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 (Tier 1; read in full for this article)
  3. 45 CFR §164.308(a)(1)(ii)(A) — the risk-analysis requirement; §164.306(b) — flexibility of approach; §164.306(d) — required vs addressable; §164.316 — documentation, six-year retention. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C (Tier 1)
  4. 45 CFR §§164.500–534 (Privacy Rule): §164.502 uses and disclosures & minimum necessary; §164.506 TPO; §164.508 authorizations; §164.524 right of access (30 days). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E (Tier 1)
  5. 45 CFR §§164.400–414 (Breach Notification Rule): §164.402 definitions; §164.404(b) 60-day individual notice; §164.406 media; §164.408 HHS; §164.410 business-associate notice. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D (Tier 1)
  6. 45 CFR §164.514(b) — de-identification: Safe Harbor's 18 identifiers and Expert Determination. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514 (Tier 1)
  7. HHS OCR, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information — Notice of Proposed Rulemaking, 90 FR 898 (January 6, 2025); comment period closed March 7, 2025; no final rule 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, Federal Register (effective January 28, 2026) — 2026 HIPAA penalty tiers ($145–$73,011 per violation; $2,190,294 cap). https://www.federalregister.gov/documents/2026/01/28/2026-01688/annual-civil-monetary-penalties-inflation-adjustment (Tier 1)
  9. Omnibus Final Rule, 78 FR 5566 (January 25, 2013) — direct liability of business associates; subcontractor BAAs. https://www.federalregister.gov/documents/2013/01/25/2013-01073/ (Tier 1)
  10. HHS OCR, Notification of Enforcement Discretion for Telehealth Remote Communications — expired with the PHE (May 11, 2023); transition period ended August 9, 2023. https://www.hhs.gov/hipaa/for-professionals/special-topics/emergency-preparedness/notification-enforcement-discretion-telehealth/index.html (Tier 2)
  11. HHS OCR, Health App Use Scenarios & HIPAA (2016) and Resources for Mobile Health Apps Developers — when an app developer is a business associate. https://www.hhs.gov/hipaa/for-professionals/special-topics/health-apps/index.html (Tier 2)
  12. FTC, Mobile Health App Interactive Tool and Health Breach Notification Rule, 16 CFR Part 318 (as amended 2024) — the regime for non-HIPAA health apps. https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool (Tier 1/2)
  13. HHS OCR press releases, April 23, 2026 — four ransomware settlements; Risk Analysis Initiative at 13 completed investigations. https://www.hhs.gov/press-room/ocr-settles-four-ransomware-investigations.html (Tier 2)
  14. Purl v. HHS, No. 2:24-cv-00228-Z (N.D. Tex., June 18, 2025) — nationwide vacatur of the 2024 reproductive-health privacy amendments; surviving NPP provisions with 2026-02-16 compliance date. Summary: https://www.hhs.gov/hipaa/for-professionals/special-topics/reproductive-health/index.html (Tier 1 court order / Tier 2 summary)
  15. NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (2024) — control mappings referenced for "what good looks like". https://csrc.nist.gov/pubs/sp/800/66/r2/final (Tier 1)
  16. 42 U.S.C. §1320d-6 — criminal penalties for wrongful obtaining/disclosure of PHI. https://www.govinfo.gov/link/uscode/42/1320d-6 (Tier 1)

Where vendor guides disagreed with the rule text — most often by presenting 2026 Security Rule NPRM items (mandatory encryption, MFA) as already-final law, or by quoting pre-2026 penalty figures — this article follows the controlling sources: the current CFR text and the January 2026 Federal Register adjustment, with the NPRM clearly labeled as proposed.