A guide to organized health care arrangements, affiliated covered entities, and hybrid entities, and what changes in your privacy program when your organization is not a single, simple covered entity.
Think of a hospital and the independent physicians who hold staff privileges there. Patients walk in and reasonably assume they are dealing with one connected system of care, even though legally the hospital and the physician group are separate entities. HIPAA has a specific mechanism for exactly this situation: an organized health care arrangement, or OHCA, which lets covered entities that patients perceive as connected share PHI more freely than unrelated covered entities normally could.
The definition lives at 45 CFR 160.103. It covers a few different fact patterns, but the one you will run into most is a clinically integrated care setting: participants who hold themselves out to the public as part of a joint arrangement and who engage in shared activities like utilization review, quality assessment, or payer contracting.
What an OHCA actually allows: Under 45 CFR 164.506(c)(5), a covered entity in an OHCA may disclose PHI to the other participants for any health care operations activity of the arrangement. That is broader than the ordinary health care operations rule, which otherwise requires both entities to have had a relationship with the patient before sharing information for operations purposes. Inside a properly documented OHCA, that condition relaxes for arrangement-related operations.
OHCA participants are also permitted, though not required, to issue a single joint Notice of Privacy Practices under 45 CFR 164.520(d). Once one participant delivers that notice to a patient, every other participant covered by it has satisfied its own notice obligation to that patient.
What an OHCA does not do is merge the participants into one covered entity for every purpose. Each one stays independently responsible for its own training, its own BAAs, its own breach response. The permission is specifically about sharing PHI for the arrangement's operations. It does not authorize disclosures outside that purpose, and it does not relieve anyone of their own administrative obligations under 45 CFR 164.530.
Why this comes up in practice: Hospital medical staff arrangements are the most common OHCA you will see in the field. If your organization is a hospital with a credentialed but independently employed medical staff, and nobody has formally evaluated whether you are actually operating as an OHCA, that is worth resolving. Sharing quality data, peer review information, or operations data with affiliated physicians without a documented OHCA basis means you may be relying on a permission you have not actually established.
An affiliated covered entity solves a different problem than an OHCA. Where an OHCA connects entities that work together clinically, an affiliated covered entity designation connects entities that share common ownership or control, whether or not they work together clinically at all.
The basis is 45 CFR 164.105(b): legally separate covered entities under common ownership or control may designate themselves as a single covered entity for Privacy Rule purposes. This is the structure a health system with multiple separately incorporated subsidiaries reaches for: a parent health system, several hospital subsidiaries, and a separately incorporated physician group, all under common corporate control.
Once the designation is made, the affiliated entities are treated as one covered entity for Privacy Rule purposes, and PHI can move between members the same way information moves freely within a single legal entity. For an organization whose corporate structure does not match how the business actually functions day to day, that is a real operational simplification.
It comes at a cost, though, and the cost is easy to overlook.
Joint and several liability: Under 45 CFR 160.402(b)(2), a covered entity that is a member of an affiliated covered entity is jointly and severally liable for a civil money penalty arising from a violation by the affiliated arrangement, unless it is established that a specific other member was responsible. Designate your entities as a single affiliated covered entity, and their compliance exposure is now linked. A serious violation at one member can create liability for all of them.
Combined safeguard obligations: If the affiliated covered entity combines the functions of a health plan, provider, and clearinghouse, it has to ensure compliance with the applicable safeguard provisions across that combination, specifically the Security Rule organizational requirement at 45 CFR 164.308(a)(4)(ii)(A) and the business associate contract provisions at 45 CFR 164.504(g). The affiliated structure does not exempt the combined entity from sorting out how those requirements apply across what may be a genuinely complex internal structure.
The designation itself has to be documented in writing or electronically under 45 CFR 164.105(c), and that documentation has to be retained for six years from its creation date or the date it was last in effect, whichever is later. This is not a one-time filing. If your affiliated structure changes through a divestiture or acquisition, the documentation needs to be updated to reflect the current arrangement.
Why this comes up in practice: Health systems that grew through acquisition are the most common candidates here. If your organization includes multiple legally distinct entities under one corporate umbrella, and PHI moves between them as if they were one organization, it is worth confirming whether an affiliated covered entity designation has actually been made and documented. Operating as though it exists, without the written record the rule requires, leaves you exposed in exactly the scenario the documentation requirement was built to prevent.
A hybrid entity addresses a third situation entirely: an organization whose primary business is not health care, but which performs some functions that meet the definition of a covered entity. Think of a corporation outside the health care industry that runs an on-site employee health clinic conducting standard electronic transactions, or an insurance carrier selling both health insurance and unrelated lines like property and casualty coverage. Both are the textbook examples HHS uses, and the basis for the designation is 45 CFR 164.105(a).
A hybrid entity has to designate which parts of the organization perform covered functions and identify those parts as one or more health care components. The designation has to include any internal unit that would itself meet the definition of a covered entity or business associate if it were a separate legal entity. You cannot designate a narrower health care component than your actual covered activities justify just to shrink your compliance footprint.
Once designated, HIPAA applies only to the health care component, not the entire organization. Inside that component, "covered entity" in the regulation means the component specifically, and PHI means information created or received by or on behalf of it. The rest of the organization sits outside HIPAA's reach for that activity.
The boundary is the hard part: PHI cannot move freely between the health care component and the rest of the organization. A disclosure from the component to a non-health care part of the same legal entity is treated under the Privacy Rule the same way a disclosure to an outside third party would be, and it needs its own permission, like an authorization or a permitted health care operations use. This is the single most common compliance failure in hybrid entity structures: treating internal sharing as automatically fine because it never technically leaves the company.
The covered entity, meaning the parent organization, stays responsible for making sure its designated health care component actually complies with the applicable requirements. Designating a component does not create a separate, self-governing unit. The organization as a whole is on the hook for making sure the boundary the designation creates is respected operationally, not just on paper.
Why this comes up in practice: Employer-sponsored on-site health clinics are the clearest example you will see. If your organization runs a clinic, a wellness program with clinical elements, or an employee assistance program that creates clinical records, and the rest of the company is not otherwise in health care, you may be operating a hybrid entity whether or not it has been formally designated. The absence of a clear designation does not mean HIPAA does not apply to the clinical component. It just means the boundary between what is covered and what is not has never actually been drawn, and that is its own risk.
These three structures solve different problems and are not mutually exclusive. A large health system can simultaneously be an affiliated covered entity at the corporate level, participate in one or more OHCAs at the clinical level with independent physicians, and contain a hybrid entity if one of its affiliated members also runs a non-health care line of business.
Points toward this if your organization functions as a connected system of care with entities you do not legally own.
Points toward this if your organization includes multiple legally separate entities under common ownership that you would want to treat as one for compliance purposes.
Points toward this if health care is a small part of a larger, non-health care organization.
| Structure | Solves | Core Mechanism | Regulatory Basis |
|---|---|---|---|
| Organized Health Care Arrangement | Clinically connected but separately owned providers need to share PHI for joint operations | Permits PHI sharing for OHCA operations; allows a joint Notice of Privacy Practices | 45 CFR 160.103; 164.506(c)(5); 164.520(d) |
| Affiliated Covered Entity | Commonly owned, legally separate entities want to operate as one covered entity | Self-designation as a single covered entity; PHI moves freely among members | 45 CFR 164.105(b); 160.402(b)(2) |
| Hybrid Entity | An organization whose primary business is not health care performs some covered functions | Designates a health care component; HIPAA applies only within that component | 45 CFR 164.105(a) |
Whichever designation applies, or if you determine deliberately that none does, write the analysis down. A memo describing your organization's structure, the designation you are adopting or declining, the regulatory basis, and the date of the decision is exactly the kind of record that shows a deliberate, informed compliance posture instead of an accidental one. Retain it the same way you retain other compliance documentation: six years from creation, or from when it was last in effect.
Mergers, acquisitions, divestitures, new joint ventures, and new subsidiaries should all trigger a fresh look at whether your existing designations still describe your organization accurately. A designation that was accurate three reorganizations ago, and never updated since, is a liability waiting to surface during an investigation, not a settled fact you can lean on.
This is advanced territory by nature. Unlike most of what 101 covers, getting these designations wrong usually does not produce an obvious daily symptom. The risk shows up later, during a complaint investigation or an acquisition's due diligence, when someone asks exactly how your organization is structured for HIPAA purposes and the honest answer is that no one formally worked it out. If your structure is genuinely complex, bringing in legal counsel to confirm the analysis is a reasonable, common step, not a sign you are not equipped for the role.
Next up: Section 2 moves from organizational structure to one of the categories of records that carries the strictest disclosure rules in the entire field: behavioral health and substance use disorder treatment records, including a full treatment of the 2024 final rule governing 42 CFR Part 2.
Section 2: Behavioral Health →A full treatment of psychotherapy notes and the 2024 final rule governing 42 CFR Part 2, including what changed, what stayed the same, and how the two frameworks now interact with each other and with HIPAA.
101 mentioned that psychotherapy notes require authorization with narrow exceptions. Here is the complete picture of what that actually means.
The definition matters as much as the rule. Under 45 CFR 164.501, psychotherapy notes are notes a mental health professional records while documenting or analyzing a private counseling session, or a group, joint, or family session, and keeps separate from the rest of the patient's medical record. The definition specifically excludes several things that might intuitively seem related: medication prescription and monitoring, session start and stop times, treatment modalities and frequency, results of clinical tests, and any summary of diagnosis, functional status, treatment plan, symptoms, prognosis, or progress. If a clinician's notes contain any of those, that content is not protected as psychotherapy notes even if it lives in the same file.
Why the separation requirement matters operationally: A therapist's clinical progress notes that live inside the regular medical record, readable by anyone with ordinary record access, are not psychotherapy notes under this definition no matter how sensitive they are. The heightened protection only attaches to notes the clinician has deliberately kept apart. So your EHR configuration is not incidental here. If the system does not actually support keeping these notes separate and access-restricted, the legal protection has nothing to attach to.
The authorization requirement comes close to absolute. Under 45 CFR 164.508(a)(2), a covered entity needs authorization for any use or disclosure of psychotherapy notes, full stop, with a short and specific list of exceptions. Ordinary PHI works the other way: broad permitted categories like treatment, payment, and operations, with authorization as the exception. Psychotherapy notes flip that structure entirely.
| Permitted Without Authorization | Regulatory Basis |
|---|---|
| Use by the clinician who originated the notes, for that patient's own treatment | 45 CFR 164.508(a)(2)(i)(A) |
| Use or disclosure for the covered entity's own mental health training programs, where students or trainees learn under supervision | 45 CFR 164.508(a)(2)(i)(B) |
| Use or disclosure by the covered entity to defend itself in a legal action brought by the individual | 45 CFR 164.508(a)(2)(i)(C) |
| A disclosure required by the individual's own access right to other records, or required by HHS oversight of the covered entity | 45 CFR 164.502(a)(2)(ii) |
| Disclosures required by law | 45 CFR 164.512(a), referenced at 164.508(a)(2)(ii) |
| Health oversight activities specifically directed at the originator of the notes | 45 CFR 164.512(d), referenced at 164.508(a)(2)(ii) |
| Disclosures to coroners and medical examiners | 45 CFR 164.512(g)(1), referenced at 164.508(a)(2)(ii) |
| Disclosures to avert a serious and imminent threat to health or safety | 45 CFR 164.512(j)(1)(i), referenced at 164.508(a)(2)(ii) |
Notice what is missing: ordinary treatment, payment, and health care operations disclosures to anyone other than the originator. If another provider treating the same patient wants the psychotherapy notes, even for active care coordination, that requires the patient's authorization. People used to the much more permissive TPO standard governing the rest of the medical record are usually surprised by this.
Patients also do not have a right under the Privacy Rule to access their own psychotherapy notes, an explicit exception at 45 CFR 164.524(a)(1)(i). A provider can choose to share them directly as a matter of clinical judgment, but a patient cannot compel it through a formal access request the way they can with the rest of their record. The same exception applies if a parent requests a minor's psychotherapy notes as the child's personal representative.
The practical takeaway for your policies: Your Patient Rights Policy and your Right of Access Form need to explicitly carve out psychotherapy notes as a defined exception, and your EHR access controls need to actually enforce the separation the definition assumes exists. A policy that says the right thing on paper while the underlying system lets any clinician pull up a colleague's psychotherapy notes alongside the rest of the chart is not actually compliant, no matter what the document says.
Substance use disorder treatment records run on an entirely separate federal framework, with its own statute and its own history, and until recently very little structural overlap with HIPAA. A 2024 final rule changed that substantially, and as of February 16, 2026, full compliance with the new rule is required.
Part 2, codified at 42 CFR Part 2 and authorized by 42 U.S.C. 290dd-2, predates HIPAA by more than two decades. It was built around a specific concern: that people would avoid treatment for substance use disorders if they feared their records could reach an employer, a court, or law enforcement. Per 42 CFR 2.12, Part 2 applies to records of patients enrolled in a federally assisted SUD treatment program, where the records document SUD diagnosis, treatment, or referral for treatment. Confirming whether your organization, or a specific service line within it, is actually a Part 2 program is the necessary first step before any of this analysis applies.
The rule itself: Published in the Federal Register at 89 FR 12472 on February 16, 2024. Effective April 16, 2024. Implements section 3221 of the CARES Act, which directed HHS to align significant parts of Part 2 with HIPAA and HITECH. Every Part 2 program, and every HIPAA covered entity or business associate that handles Part 2 records, is now operating under the new requirements rather than the transitional ones.
The single biggest operational change is TPO consent. Historically, Part 2 had no general treatment, payment, and health care operations exception at all, the largest practical gap from HIPAA, and a real source of care coordination friction. Under the 2024 rule, a patient can sign one written consent covering all future TPO uses and disclosures of their Part 2 records.
A patient who signs a TPO consent has authorized all future TPO uses and disclosures of their Part 2 records, without a fresh consent for each one. When a HIPAA covered entity or business associate receives Part 2 records under a TPO consent, that recipient can redisclose the records the way HIPAA generally permits, rather than being bound by Part 2's traditional, much stricter redisclosure limits.
The exception that survives everything else: There is one purpose the TPO consent and the general redisclosure permission do not reach: using the records or related testimony in civil, criminal, administrative, or legislative proceedings against the patient. That still requires either the patient's specific consent for that purpose or a qualifying court order accompanied by a subpoena or similar legal mandate. A compliance team that treats a TPO consent as a blanket permission covering every conceivable use, litigation included, has misread the rule in a way that creates real exposure.
SUD counseling notes ride separately, no matter what else is on file. Even with a fully executed TPO consent, they cannot be disclosed on the strength of that consent. They need their own specific consent, the same way psychotherapy notes need their own authorization regardless of what other permissions exist.
Part 2's version of a Business Associate Agreement is the QSOA, required between a Part 2 program and any organization providing services that involve access to Part 2 records. If your organization is both a Part 2 program and a HIPAA covered entity, a vendor that qualifies as a business associate under HIPAA generally needs a QSOA as well. Auditing your vendor agreements for QSOA coverage, not just BAA coverage, is an easy step to miss if your Business Associate Inventory was built without Part 2 in mind.
Part 4 of 4Despite the alignment the 2024 rule created, psychotherapy notes under HIPAA and SUD records under Part 2 remain two separate legal frameworks, and conflating them is a real risk.
| Psychotherapy Notes (HIPAA) | SUD Records (42 CFR Part 2) | |
|---|---|---|
| Governing framework | 45 CFR 164.508(a)(2) | 42 CFR Part 2, as revised by the 2024 final rule |
| Default rule | Authorization required, narrow named exceptions | Consent required, broader since 2024 via TPO consent |
| TPO disclosures to other providers | Still requires authorization | Permitted under a TPO consent since 2024 |
| Right of patient access | No right of access | Generally accessible; SUD counseling notes carry their own narrower protection |
| Use against the patient in legal proceedings | Governed by general HIPAA rules and the legal-defense exception | Specifically restricted regardless of TPO consent; requires separate consent or qualifying court order |
| Penalty structure | HIPAA civil and criminal enforcement | Aligned with HIPAA enforcement since 2024 |
A patient can fall into both categories at once. Someone in SUD treatment who is also receiving psychotherapy has records that may be subject to both frameworks simultaneously, and the more protective standard generally controls when they conflict.
State law has not gone anywhere. 101 covered the principle that state law can be more protective than HIPAA, and that applies with particular force here. A number of states impose consent and disclosure requirements for both mental health and SUD records that go beyond even the newly aligned federal Part 2 framework. The 2024 alignment narrowed the gap between HIPAA and Part 2. It did nothing to narrow the gap between either framework and a stricter state law. Confirm your state's specific requirements before assuming the federal baseline is the only standard you need to meet.
If your organization has any behavioral health or SUD treatment component, three things follow directly from this section: confirm whether you are operating a Part 2 program and document that determination, update your Patient Notice, consent forms, and BAA inventory to reflect the 2024 rule's content requirements and QSOA distinction, and make sure your EHR configuration actually enforces the separation that both psychotherapy notes and SUD counseling notes require.
Next up: Section 3 moves into territory 101 did not cover at all: how AI tools and vendors intersect with your privacy obligations, including when an AI vendor becomes a business associate and where consumer health technology falls outside HIPAA's reach entirely.
Section 3: AI & Vendors →The rules here were largely written for a world that did not have generative AI in it. The gaps that creates are where the real exposure lives.
The test has not changed just because the technology is new. A vendor is a business associate when it creates, receives, maintains, or transmits PHI on behalf of a covered entity to perform a function or service for that entity. An AI scribe that listens to a patient encounter and drafts a note meets that test immediately. So does a chatbot that triages patient messages, a coding assistant that reads clinical documentation to suggest billing codes, or a model that flags high-risk patients from claims data.
Where this gets harder is the conduit question. The Privacy Rule has always carved out a narrow exception for entities that merely transmit information without accessing it in any meaningful way, the classic example being a telecommunications carrier or the postal service. OCR's own guidance has been clear for over a decade that this exception does not extend to a vendor that stores or processes the information, even temporarily. An AI tool that has to ingest a transcript or a clinical note to generate output is not a conduit.
The practical failure mode in 2026: It is not a covered entity knowingly skipping a BAA. It is staff signing up for a general-purpose AI tool, the kind built for drafting emails or summarizing meetings, and using it to clean up a clinical note because it is faster than typing. That tool was never built to handle PHI and almost certainly has no BAA on file with your organization. Putting a patient's information into it is an impermissible disclosure under 45 CFR 164.502(e), regardless of how careful the employee thought they were being. This is the single most common AI-related gap solo practitioners and small practices report, and it usually traces back to a tool nobody in compliance ever evaluated because nobody in compliance knew it existed.
101 covered the basic rule that a business associate agreement is required before PHI moves to a vendor. What it did not get into is what happens underneath that vendor, and for AI tools, underneath is often where the actual data sits.
Most AI products in health care are not built entirely in-house. An AI scribe company frequently licenses a foundation model from a separate provider to actually generate the clinical note, which means that foundation model provider may receive, process, or temporarily store the same PHI your BAA covers, just one layer removed from you.
The contract obligation flows downhill: Under 45 CFR 164.502(e)(1)(ii), a business associate that wants to disclose PHI to its own subcontractor has to obtain satisfactory assurances that the subcontractor will safeguard the information appropriately, documented in a written agreement. The implementation specifications at 164.504(e)(5) make clear that the same substantive contract requirements running between you and your business associate apply all the way down the chain. The Security Rule imposes the parallel requirement at 164.308(b)(2) and 164.308(b)(4) for electronic PHI specifically.
You are not a party to that downstream contract, and you generally do not need to be. But you are still entitled to ask your vendor a direct question before you sign: who else touches this data, and do you have a written agreement with them that flows down the same obligations you are agreeing to with me? A vendor that cannot answer that, or that treats it as an unusual ask, is telling you something about how seriously it has thought through its own compliance obligations. This is also where breach notification timelines get genuinely complicated, since a breach at a subcontractor three layers down still has to work its way back up to you within the same 60-day framework that governs your own notification to affected individuals.
Part 3 of 5A lot of AI vendor pitches lean on the claim that the data used to train or improve their model has been de-identified, meant to signal that HIPAA's restrictions do not apply. That claim is only true if the de-identification actually meets one of the two methods the Privacy Rule recognizes.
45 CFR 164.514(b)(1). Requires a qualified statistician or similarly trained person to apply accepted analytic methods and formally conclude the risk of re-identification is very small, documented.
45 CFR 164.514(b)(2). Requires removing all eighteen specified categories of identifiers, not just name and Social Security number, but exact dates tied to an individual, geographic subdivisions smaller than a state, and any other unique identifying number or characteristic.
Free-text clinical notes, exactly what an AI scribe or summarization tool handles constantly, are notoriously hard to de-identify under either method, because narrative text tends to embed exact dates, rare diagnoses, employer names, or other details a person wrote in the normal course of documenting care. If a vendor's idea of de-identification is stripping a name field from a structured database and calling the rest of the record safe, that satisfies neither recognized method, and the information is still PHI no matter what label the vendor puts on it internally.
Before you accept a vendor's de-identification claim as a reason a BAA is not needed, ask which of the two methods was used and ask to see the documentation. If the answer is vague, treat the data as identified and require the BAA.
Most of what AI introduces into a compliance program is a privacy and security question, but one piece sits in a different part of the regulatory structure entirely. The 2024 final rule implementing Section 1557 of the Affordable Care Act, at 45 CFR 92.210, prohibits covered entities from discriminating on the basis of race, color, national origin, sex, age, or disability through the use of what the rule calls patient care decision support tools, a deliberately broad category covering AI and machine learning tools used in clinical decision-making alongside older rule-based clinical algorithms. Covered entities have an affirmative obligation to make reasonable efforts to identify where they use these tools and to mitigate the risk that a tool's outputs systematically disadvantage patients based on a protected characteristic.
This is worth flagging separately because it is easy to assume that vetting an AI tool for HIPAA, meaning the BAA is signed and the security review is done, means the tool has been fully vetted. Section 1557 asks a different question: whether the tool's outputs themselves treat patients fairly, and that question does not go away just because the privacy and security side of the relationship is buttoned up. A diagnostic support tool can have a flawless BAA and still create 1557 exposure if it was trained on a population that does not reflect the patients it is now being used on.
A fitness tracker, a period-tracking app, a direct-to-consumer mental wellness app: none of these are covered entities, and none become business associates simply because a patient happens to use one alongside getting care from you. HIPAA's reach stops at the relationship between a covered entity, its business associates, and their subcontractors. A consumer downloading an app on their own, with no involvement from your practice, is in a relationship HIPAA does not govern.
That does not mean the information is unprotected. The Federal Trade Commission's Health Breach Notification Rule, substantially updated in 2024, requires vendors of personal health records and related entities not covered by HIPAA to notify affected individuals, the FTC, and in some cases the media following a breach of unsecured identifiable health information, on a timeline that mirrors HIPAA's own sixty-day standard. The FTC has already brought enforcement actions under this rule against companies including GoodRx and Easy Healthcare for sharing user health data with advertising platforms without proper disclosure.
Where this becomes your problem, rather than just a patient education point, is the moment your practice gets involved in the recommendation or integration. If a provider tells a patient to download a specific app to track symptoms between visits, you have not necessarily created a business associate relationship with the app. But if your practice has a direct technical integration, an API connection, or a data-sharing partnership where the app vendor performs a function for you rather than for the patient independently, that arrangement needs the same business associate analysis as any other vendor relationship. The label "consumer app" on the App Store does not settle the question. The function it performs, and who it performs that function for, does.
Next up: Section 4 moves into territory 101 named and moved past, because a first introduction to HIPAA does not have room to walk through every branch of a six-part rule. Research disclosures, court orders versus subpoenas, and the six law enforcement pathways, in full.
Section 4: Disclosure Pathways →At some point a request lands on your desk that does not fit neatly into treatment, payment, or health care operations. You need to know which provision applies, and exactly what it requires, before any information leaves your building.
The Privacy Rule lets a covered entity disclose PHI for research without authorization in three distinct situations, and they get confused with each other constantly.
What the board has to find for a waiver: That the use or disclosure involves no more than minimal risk to privacy, based at minimum on an adequate plan to protect identifiers from improper use, an adequate plan to destroy identifiers at the earliest point consistent with conducting the research, and written assurances the information will not be reused or redisclosed except as the rule permits. That the research could not practicably be conducted without the waiver. And that it could not practicably be conducted without access to the specific PHI requested. The documentation has to identify the board, the date of approval, and a description of the PHI for which access was approved.
What this means for you in practice: When a researcher or outside investigator hands you an IRB approval letter and asks for chart access, your job is not to take the board's approval at face value because it has a letterhead. Confirm the documentation actually contains the required elements, and confirm the disclosure you are about to make matches the scope of what was approved. A board approving a waiver for de-identified aggregate counts does not authorize you to hand over a spreadsheet of identifiable records, even if it is the same underlying study.
This is the single most common complex disclosure request a privacy officer handles, and the whole analysis turns on one question: is this request accompanied by an order signed by a judge or administrative tribunal, or is it a subpoena, discovery request, or other lawful process standing on its own?
45 CFR 164.512(e)(1)(i). Lets you disclose immediately, but only the PHI the order expressly authorizes, nothing broader. A court order does the legal work of authorization for you.
45 CFR 164.512(e)(1)(ii). Does not let you disclose on the subpoena alone. You need satisfactory assurance of notice to the individual, or a qualified protective order, before you disclose.
A well-drafted subpoena from an attorney who knows what they are doing will often include the satisfactory assurance language directly in the document, so you do not need to chase down separate paperwork. A bare subpoena with none of that is not a green light. Object, ask for the missing assurance, or push the requesting party toward a protective order, and do not disclose until one of those is actually in hand.
A note on a provision with a turbulent recent history: In 2024, HHS added a requirement that certain requests touching reproductive health care needed a signed attestation before disclosure. A federal court vacated that requirement nationwide in June 2025, and it is not currently in effect. If a request you are handling involves reproductive health information, the ordinary analysis above, court order, subpoena, or one of the law enforcement pathways below, governs it the same way it would any other request. That said, several states have their own reproductive health privacy laws that go further than HIPAA, so it is worth checking your state's requirements specifically rather than assuming the federal baseline is the whole picture. This is one to keep an eye on, since federal reproductive health privacy rules have been a genuinely moving target over the past couple of years.
164.512(f) is not a single rule. It is six separate, narrow permissions, and a request that does not fit cleanly into one of them is not authorized just because the person asking wears a badge.
The practical takeaway: An officer showing up and asking for a patient's records is not, by itself, a basis for disclosure under any of these six pathways unless the specific facts match one precisely. A request connected to an ongoing investigation, with no court order and no fit under the other five pathways, generally has to be redirected back through the legal process pathway. And the minimum necessary standard still applies to every one of these pathways except where disclosure is required by law.
What ties research disclosures, judicial proceedings, and law enforcement requests together is the same discipline: identify exactly which provision authorizes the disclosure, confirm every condition that provision actually requires has been met and documented, and resist the pull to treat an official-looking request, a board approval letter, a subpoena, a badge, as self-authorizing. None of these requests are self-authorizing on their own. That is the whole reason the provisions exist.
Next up: Section 5 covers the part of the Privacy Rule that trips up otherwise well-run programs more often than almost anything else in HIPAA, marketing, fundraising, and the sale of PHI.
Section 5: Marketing & Sale of PHI →The everyday activities these rules govern look completely normal from inside a marketing or development department. The Privacy Rule does not ban them. It just requires you to know which bucket a given communication falls into.
The Privacy Rule defines marketing, at 45 CFR 164.501, as making a communication about a product or service that encourages the recipient to purchase or use it. Read on its own, that definition would sweep in almost everything a covered entity legitimately tells a patient. The rule carves three specific categories back out, and getting those carve-outs right is most of what this section is about.
The first covers communications about treatment, case management, care coordination, and recommending alternative treatments or providers. The second is the refill reminder exception. Both carve-outs come with a condition that determines everything: they only keep a communication outside the marketing definition if the covered entity is not receiving financial remuneration for making it, with one narrow exception for refill reminders, where remuneration is allowed as long as it is reasonably related to the actual cost of making the communication.
This is where the line actually sits. A clinic that tells a patient about a new physical therapy program it offers is engaged in treatment communication, fully outside the marketing definition, because there is no third party paying for that message. A clinic that gets paid by a device manufacturer to send patients information promoting that manufacturer's product is doing something categorically different, even if the message itself reads identically to an ordinary treatment recommendation. Financial remuneration is what converts an otherwise-exempt communication into marketing requiring authorization under 164.508(a)(3), and that authorization has to affirmatively disclose that remuneration is involved.
The most common failure pattern is not a covered entity knowingly running undisclosed pharma marketing through patient channels. It is a marketing or business development team setting up a sponsorship, co-branding, or revenue-share arrangement with a vendor, treating it as a straightforward business deal, and never looping in the privacy office to ask whether patient communications connected to that arrangement now require authorization. If your organization has any sponsorship, referral fee, or co-marketing relationship with an outside company, and patient communications are part of it, that is a privacy question before it is a contracts question.
Fundraising sits in a more permissive spot than marketing, but it is permissive within a specific, limited scope, not a blank check. Under 45 CFR 164.514(f), a covered entity may use or disclose a defined set of PHI, to a business associate or an institutionally related foundation, for the purpose of raising funds for its own benefit, without a 164.508 authorization.
What is in the carve-out: Demographic information (name, address, other contact details, age, gender, date of birth), dates of health care provided, department of service information like cardiology or oncology, treating physician, outcome information, and health insurance status.
What is not: Clinical detail, diagnosis specifics, treatment notes, or anything beyond that defined list. A development office targeting fundraising appeals by a patient's actual diagnosis is operating outside what this provision permits.
The part of this provision that actually gets enforced is the opt-out mechanism. Your Notice of Privacy Practices has to disclose the right to opt out, every fundraising communication has to include a clear and conspicuous opportunity to do so, and once someone opts out you have to make reasonable efforts to honor that election going forward, including across your business associates and any institutionally related foundation working on your behalf. An opt-out registered with the hospital has to actually stop fundraising mail from the affiliated foundation too.
One narrow but important wrinkle: if your organization creates or maintains records subject to 42 CFR Part 2, you cannot use those records for fundraising at all until the individual has first been given a clear and conspicuous opportunity to opt out, a higher bar than the general fundraising rule.
The HITECH-era sale prohibition at 45 CFR 164.502(a)(5)(ii) is written more broadly than the word "sale" typically implies in plain English. The rule defines a sale of PHI as any disclosure where the covered entity or business associate directly or indirectly receives remuneration from or on behalf of the recipient in exchange for that information. This is not limited to bulk data sales to data brokers. A one-off arrangement where a single vendor pays you for access to a subset of patient records can trigger the same prohibition as a large-scale data licensing deal.
Once a disclosure meets that definition, it is prohibited unless the patient has signed an authorization under 164.508(a)(4) that specifically states the disclosure will result in remuneration, or unless it falls within a defined set of exceptions.
The exceptions: Public health disclosures, research disclosures where the only payment is a reasonable cost-based fee to prepare and transmit the information, treatment and payment purposes, a sale or merger of the covered entity along with related due diligence, payments to a business associate or subcontractor for performing services under the agreement, disclosures required by law, and providing individuals with access to their own records or an accounting of disclosures.
The practical discipline this requires is asking the remuneration question on every data-sharing arrangement before it goes live, not just the obvious ones. The label your business development team puts on the deal does not control the analysis. The actual flow of money or value in exchange for PHI does.
Marketing, fundraising, and the sale of PHI sit on a spectrum from most restrictive to least, but the underlying discipline is identical across all three. Trace where money is actually moving, identify whether it is moving in exchange for the PHI itself or for some other permitted activity, and match the disclosure to the specific provision that actually authorizes it.
Next up: Section 6 closes out this series by looking at what changes when your organization operates across state lines, and how a privacy officer's role itself evolves once the basics are no longer the hard part.
Section 6: Multi-State Governance →What changes once your program has the fundamentals solid and starts operating at a scale where HIPAA is no longer the only rule in the room.
101 likely told you, correctly, that HIPAA sets a federal floor and states can go further. What it probably did not walk through is how to actually determine, for a specific state law provision, whether you follow it or follow HIPAA instead. That determination is not a single yes-or-no question about an entire state code. It is a provision-by-provision comparison, governed by two defined terms at 45 CFR 160.202 and 160.203.
Contrary, and the exception that saves it: A state law is contrary to HIPAA if it would be impossible to comply with both at once, or if it stands as an obstacle to the purposes of HIPAA's administrative simplification provisions. If a state law is contrary, HIPAA generally preempts it, with one major exception: if the contrary state law is also more stringent, meaning it provides greater privacy protections or greater individual rights than the federal standard, the state law survives anyway.
HHS has been explicit that this is not a holistic judgment about which body of law is better overall. You compare a specific HIPAA provision to a specific state provision, term by term, and the more rigorous one controls for that issue. Your organization could be following HIPAA's standard on one provision and a state's standard on the very next one in the same chart.
The operational version of this is a preemption matrix: a working document that tracks, state by state and topic by topic, where your state's law diverges from HIPAA and which one governs. The places this matters most in practice are minor consent and parental access rules, mental health and substance use record handling on top of what 42 CFR Part 2 already requires, breach notification timing and content, and record retention periods.
Telehealth does not introduce a separate privacy framework. It takes the preemption analysis above and multiplies it by every state where your patients are physically located at the moment of the encounter, not just the state where your organization is headquartered or licensed. A practice based in one state treating patients across five others is potentially managing five different sets of more-stringent state privacy provisions layered on top of HIPAA, five different state breach notification statutes running on different timelines, and in some cases five different state-specific consent requirements for telehealth specifically.
A breach affecting telehealth patients in multiple states does not get one notification analysis. It gets one per affected state, run in parallel, because a state's own breach notification law can impose obligations, content requirements, or shorter deadlines that HIPAA does not preempt just because the same incident also triggers HIPAA's federal notification requirement. Building a single combined breach response checklist that already accounts for your top operating states is the practical payoff of doing the preemption matrix work in the first place.
Part 3 of 4The Information Blocking Rule, at 45 CFR Part 171, comes from the 21st Century Cures Act and is administered by ASTP/ONC, not HHS's Office for Civil Rights, with its own enforcement track and its own penalty structure.
The rule prohibits an "actor," defined to include health care providers, health IT developers of certified health IT, and health information networks or exchanges, from engaging in a practice that is likely to interfere with the access, exchange, or use of electronic health information, unless the practice fits one of the recognized exceptions. As of the most recent update in December 2024, there are nine of these.
The privacy exception matters most for a privacy officer specifically, because it is built to interact directly with HIPAA rather than override it. It does not give you blanket cover to decline an EHI request just because the information is PHI. The refusal has to fit one of the exception's own defined sub-conditions: a legal precondition for disclosure that has not yet been satisfied, a denial consistent with the specific grounds HIPAA itself recognizes under 164.524(a)(1) and (2), or a documented, non-discriminatory honoring of an individual's own request not to share their information. Under the Information Blocking Rule, "HIPAA might apply" is not, by itself, a permitted reason to withhold electronic health information.
The failure mode this rule is designed to catch is exactly the instinct many compliance programs have built over twenty years of HIPAA training: when in doubt, do not share the information. A privacy officer who has spent years training staff to default toward caution now has to also train staff that unjustified caution, with respect to electronic health information specifically, carries its own federal exposure.
Everything in this series, from organizational structures in Section 1 through information blocking just now, points toward the same shift in what the role actually is once the fundamentals are handled. A privacy officer managing a single, simple covered entity is mostly answering one question: does this specific use or disclosure comply with the Privacy Rule. A privacy officer operating at the scale this section describes is doing something broader: coordinating compliance across organizational boundaries, where no single document or determination settles the question and the job becomes keeping multiple, overlapping frameworks correctly mapped against each other in real time.
The clearest emerging version of this is standing up a formal AI governance function, separate from but coordinated with the privacy program. A mature program increasingly needs a cross-functional body, often a governance committee with representation from privacy, security, clinical leadership, and legal, that owns the intake process for any new AI tool before it touches a single patient record.
That is also, fittingly, where Privacy Officer 101 ends and where this series has been building the whole time. The first guide gave you the rules. This one has been about the judgment required when the rules overlap, conflict, or simply have not caught up yet: the actual work of a privacy officer once the basics stop being the hard part.
You have finished the series. If your organization's structure, behavioral health program, vendor relationships, or multi-state footprint surfaced a gap while reading, that gap is exactly the kind of thing worth documenting and addressing deliberately, the same discipline this whole series has been building toward.