42 CFR Part 2 protects substance-use disorder treatment records more strictly than HIPAA does, and the practical consequence for software is that consent has to be modelled as data rather than assumed as a policy. Where HIPAA permits disclosure for treatment, payment and operations without specific patient authorization, Part 2 generally requires consent naming who receives the information and for what purpose, and it restricts what the recipient may then do with it. That means a system holding Part 2 records needs to capture consent with that specificity, enforce it at the point of disclosure, attach a redisclosure notice, and prove after the fact what was released to whom under which consent. It also means the threshold question matters: Part 2 applies to federally assisted substance-use programs, not to every mention of substance use in a general medical record, so determining whether you are in scope is the first design decision rather than an afterthought.
What Is 42 CFR Part 2?
42 CFR Part 2 is the federal regulation protecting the confidentiality of substance-use disorder treatment records, and it predates HIPAA by decades, written at a time when the stigma and legal exposure attached to addiction treatment records were even more acute than they are now. It imposes a confidentiality standard genuinely stricter than HIPAA’s, with consent and redisclosure rules that don’t map cleanly onto ordinary healthcare data-sharing assumptions.
Does It Apply to You?
This is the scoping question that has to come first, and it’s the one most content skips past. Part 2 applies specifically to federally assisted programs that hold themselves out as providing substance-use disorder diagnosis, treatment or referral — not to every clinical record that happens to mention substance use. A general medical practice’s EHR that occasionally documents a patient’s alcohol use isn’t automatically in scope. A dedicated SUD treatment program receiving any form of federal assistance almost certainly is. Determine this before designing anything, because it changes the entire architecture, not just a compliance checklist item at the end.
How It Differs From HIPAA
| HIPAA | 42 CFR Part 2 | |
|---|---|---|
| Disclosure for treatment/payment/operations | Permitted without specific authorization | Generally requires specific consent |
| Consent specificity | General authorization sufficient | Must name recipient and purpose |
| Redisclosure | Governed by the same rule | Restricted; requires a redisclosure notice |
| Penalties | Civil and criminal | Now aligned with HIPAA’s penalty structure (2024 rule) |
Consent as a Data Model
This is the software reframe that carries the rest of the post: Part 2 consent isn’t a signed form filed away and forgotten — it’s a data structure your system has to enforce at the point of every disclosure. At minimum, that means capturing who the patient authorized to receive the information, for what specific purpose, and for how long that authorization stays valid. A system that captures consent as an unstructured document rather than structured, enforceable data can’t actually gate disclosures against it — it can only document that a consent exists somewhere, which isn’t the same thing as enforcing it.
Segmentation and Redisclosure
I go into the deeper engineering problem this creates — distinguishing Part 2-protected data from ordinary HIPAA-governed content within the same record — in the behavioral health EHR integration requirements post, including the real, current gap in EHR certification for granular data segmentation. That post is the engineering companion to this one; this post covers the regulatory requirement, that one covers building for it.
Audit and Proof
Beyond capturing consent, the system has to be able to reconstruct, after the fact, exactly what was disclosed, to whom, under which specific consent, and when. That’s a real audit-logging requirement specific to Part 2 disclosures, not just general HIPAA-style access logging — the reconstruction has to tie each disclosure back to the consent that authorized it.
The 2024 Alignment With HIPAA
Verify the current effective and compliance dates directly, since this has genuinely changed: a 2024 final rule better aligned Part 2 with HIPAA, effective April 16, 2024, with a compliance deadline of February 16, 2026 — meaning it is now fully in effect. The alignment allows a single patient consent to cover future treatment, payment and operations disclosures rather than requiring separate consent for each one, permits HIPAA covered entities and business associates receiving records under that consent to redisclose them under standard HIPAA rules, created a new narrower protection for an SUD clinician’s own private session notes analogous to HIPAA’s psychotherapy notes, and aligned enforcement — civil and criminal penalties — with HIPAA’s structure. Software built against the pre-2024 Part 2 regime is now working from an outdated model.
A Requirements Checklist
- Confirmed whether the program is actually in scope as a federally assisted SUD program
- Consent captured as structured, enforceable data — recipient and purpose, not a blanket authorization
- Redisclosure notices attached to any Part 2 data leaving the system
- Audit logging that ties every disclosure back to its authorizing consent
- Segmentation architecture that distinguishes Part 2 data from ordinary HIPAA-governed content
Next Steps
This is not legal advice — it describes the technical and regulatory requirements and cites the current rule, but consent design specifically should involve counsel given the stakes of getting it wrong. If you’re building or extending software that touches SUD treatment records, talk to our team about building the consent and segmentation architecture correctly from the start.