42 CFR Part 2 Final Rule: EHR Consent, Labels & APIs (2026)

42 CFR Part 2 is the federal rule that protects substance use disorder (SUD) treatment records, and for engineers it comes down to three jobs: know which records came from a Part 2 program, check a valid consent before each use or disclosure, and send the consent scope and a notice with every disclosure. The 2024 final rule made Part 2 closer to HIPAA, and compliance became mandatory on February 16, 2026. It did not remove these three jobs. In October 2026, ONC also published a rule that drops the two certification tests for security tags at the end of 2026, so your product cannot count on the EHR to do this work.

This guide is for CTOs, architects and engineers who build software that touches SUD data: EHRs and add-ons for addiction treatment programs, health information exchanges, care coordination and value-based care platforms, AI scribes, telehealth, billing and analytics. It explains the rule in build terms, then shows the data model, the HL7 and FHIR codes, the consent engine, API filtering, audit, the edge cases, testing and how to migrate old records. Every rule point cites the section of 42 CFR Part 2 it comes from, checked against the current eCFR text on November 9, 2026. Where something is our engineering judgment and not rule text, we say so. This is not legal advice, and your counsel decides how the rule applies to your organization.

If you need a team to design or build this, see our behavioral health EHR integration services. For the vendor side, our behavioral health EHR API guide compares what ten EHRs let you read and write.

What is 42 CFR Part 2, in one paragraph?

42 CFR Part 2 is a federal regulation that limits how SUD treatment records from federally assisted programs can be used and shared. It exists so that people seek treatment without fear that their records will be used against them. It is stricter than HIPAA in three ways that matter to software: a patient's consent is needed even for treatment, payment and health care operations; the records may not be used in legal proceedings against the patient without consent or a court order; and each disclosure made with consent carries a notice and the consent scope. The current text is at eCFR, Title 42, Part 2, last amended September 17, 2024.

Key dates engineers need

We searched the Federal Register on November 9, 2026 for any document that amends 42 CFR Part 2 since January 2024. The only result was the 2024 final rule. One part of that rule is still on hold: the patient's right to an accounting of disclosures under 2.25. The preamble pauses its effective and compliance dates until HHS revises the matching HIPAA accounting rule at 45 CFR 164.528, which has not happened. The eCFR text shows 2.25 with no note, which is why many articles say the right is already live.

Does Part 2 apply to your product?

Part 2 applies to records that identify a patient as having an SUD and that a Part 2 program created or received. It also applies to anyone who receives those records with consent or under an exception, called a "lawful holder". So there are three ways your software can be in scope.

1. You are, or you build for, a Part 2 program. A "program" holds itself out as providing SUD diagnosis, treatment or referral for treatment, and provides it (2.11). In a general hospital, only an identified SUD unit, or staff whose main job is SUD care, counts. The program becomes a "Part 2 program" when it is federally assisted (2.12(b)), which includes being a Medicare provider, holding a DEA registration to dispense SUD medications, getting any federal funding, or being tax-exempt. Most US SUD treatment programs meet at least one of these.
2. You receive Part 2 records. A primary care clinic, health plan, HIE, care coordination platform or analytics vendor that receives records from a Part 2 program with consent becomes a lawful holder (2.11). The rules travel with the records.
3. You process records for a Part 2 program as a vendor. A billing company, cloud EHR, lab or data processor that serves a program signs a qualified service organization agreement (QSOA), a contract in which the vendor agrees to be bound by Part 2 (2.11). For a program that is also a HIPAA covered entity, a business associate agreement covers this role for records that are also protected health information.

What Part 2 does not cover

• SUD notes made by a provider who is not a Part 2 program. A primary care doctor who records an opioid use disorder diagnosis from their own visit does not create a Part 2 record (2.12(d)(2)(ii)). The rule's own example says emergency room staff who refer an overdose patient are not covered, unless SUD care is their main job or the ER promotes itself as an SUD provider (2.12(e)(1)).
• Information a patient or program tells a non-Part 2 provider orally. If a non-Part 2 provider writes down what it was told for treatment, with consent, that note does not become a Part 2 record just because it was written down (2.11, "records").
• Tobacco and caffeine. The rule's definition of SUD leaves them out (2.11). Nicotine dependence codes are outside Part 2.
• Veterans Affairs care. A different law, 38 U.S.C. 7332, covers VA records (2.12(c)).

The most important point for engineers: the program decides, not the code

The same diagnosis code can be a Part 2 record in one system and an ordinary record in another. An ICD-10 code F11.20 (opioid dependence) from an opioid treatment program is a Part 2 record. The same code entered by a family doctor after a routine visit is not. So a list of SUD codes can find candidate records, but it cannot decide which ones are protected. Your data model has to record where each piece of data came from. We return to this in the data model section, because it is the decision most teams get wrong.

What changed in the 2024 final rule

The 2024 final rule carried out section 3221 of the CARES Act, which told HHS to bring Part 2 closer to HIPAA. These are the changes that affect software.

What did not change

Several common summaries say "Part 2 now just follows HIPAA". That is wrong in ways that break software. Under HIPAA, a covered entity needs no patient consent to share records for treatment. Under Part 2, it still needs one, even if that one consent now covers all future TPO uses. The legal-proceedings ban still follows the record to anyone who holds it. Each disclosure made with consent still carries a notice and the consent scope. SUD counseling notes need their own consent. And a Part 2 program still cannot disclose records to a recipient who is not a HIPAA entity just because HIPAA would allow it.

The five rules your software has to enforce

Almost every Part 2 requirement that touches code falls under one of five rules. We use these five as the backbone of the design that follows.

Consent: what a valid Part 2 consent must contain

A Part 2 consent can be on paper or electronic, and electronic signatures are allowed unless other law forbids them (2.31(a)). It must contain ten elements. Your consent capture screen and your consent data model both need a field for each one, because an incomplete consent is invalid (2.31(c)).

When the recipient is a covered entity or business associate receiving records for TPO, the consent must also say the records may be redisclosed under HIPAA, except for proceedings against the patient (2.31(a)(4)(iii)). If the program fundraises, the consent must state the right to opt out (2.31(a)(5)).

Four consent types your engine must tell apart

• Single TPO consent. Covers treatment, payment and health care operations for future uses until revoked (2.33(a)(2)). This is the consent most integrations rely on.
• Specific consent. Named recipients and purposes outside TPO, for example a disclosure to an employer program or a family member.
• Intermediary consent. Names an intermediary, such as an HIE or research network that is not a HIPAA entity, plus either named members or a general designation limited to members who treat the patient (2.31(a)(4)(ii)).
• SUD counseling notes consent. Covers counseling notes only, and may only be combined with another counseling notes consent (2.31(b)). A separate consent for use in legal proceedings cannot be combined with anything else (2.31(d)).

When a consent is invalid

The rule lists four cases (2.31(c)): it has expired; on its face it substantially fails to meet the required elements; the discloser knows it was revoked; or the discloser knows, or with reasonable diligence would know, that a material part is false. Your engine can check the first three automatically. The fourth needs a way for staff to flag a consent as disputed and stop it from being used.

Redisclosure: what travels with every disclosure

Each disclosure made with a patient's consent must include one of two notice statements (2.32(a)). The short version is one sentence: "42 CFR part 2 prohibits unauthorized use or disclosure of these records." The long version is printed in the rule. Each disclosure must also include a copy of the consent or a clear explanation of its scope (2.32(b)). That second part is easy to miss. The boilerplate notice is not enough on its own; the recipient has to be able to tell what the patient agreed to.

What the recipient may do next depends on who it is.

For engineers this means the recipient's type is a field your disclosure engine reads. Sending a "no redisclosure" label on every record to every recipient is safe, but since 2024 it can over-restrict a hospital or health plan that is allowed to redisclose under HIPAA. Choosing the label per recipient is a policy decision for the sending organization, and we suggest your counsel approve the table your engine uses.

"No segmentation required": what it really means

This is the most misread line in the 2024 rule. The text says that a Part 2 program, covered entity or business associate that receives records under a single TPO consent "is not required to segregate or segment such records" (2.12(d)(2)(i)(C)). That is the full scope. It does not ban segmentation. It does not cover recipients outside that group, or records received under a specific consent or an exception. The definition of "records" in 2.11 still says a non-Part 2 provider "may" segregate records it receives.

Our engineering reading, which is not rule text: you do not have to store Part 2 data in a separate database, but you still have to know which data is Part 2 data. Five other duties depend on it:

• The legal-proceedings ban applies to Part 2 records wherever they sit (2.12(d)(1)).
• The 2.32 notice goes with consent-based disclosures of Part 2 records.
• SUD counseling notes need their own consent (2.31(b)).
• A patient who revokes consent stops future disclosures of Part 2 records (2.31(a)(6)).
• An agreed restriction under 2.26 has to stop the specific records it covers.

So the practical answer is "tag, do not wall off". Keep the data together if that suits your product, and label each item so the rules can still find it.

The data model: provenance first, labels second

A Part 2 design starts with one question for every data item: did it come from a Part 2 program? Labels and filters follow from the answer. We recommend four objects.

The flag on the source program is a fact that a person confirms, not one your software guesses. A name match or a diagnosis code can suggest that an organization is a Part 2 program. A compliance owner on your side or the customer's side has to confirm it before your engine relies on it.

Why code lists are not enough

Value sets of SUD codes, such as ICD-10-CM F10 to F19 without F17 and medications like buprenorphine, methadone and naltrexone, are useful in two places. They help find records that might be Part 2 records during a migration, and they help catch SUD data that arrives from a Part 2 program without labels. They cannot decide coverage on their own, because the same code is a Part 2 record from one source and not from another. A system that labels every F11 code as Part 2 over-restricts primary care data. A system that labels nothing without a code misses Part 2 billing records, appointment lists and emails, which are records too (2.11).

HL7 and FHIR security labels for Part 2

HL7 publishes the codes you need. We checked each one in the current HL7 terminology files (terminology.hl7.org, release 7.5.0) on November 9, 2026. All are active.

Three traps we found while checking. ALC and DRG are not SUD labels: in v3-ActCode, ALC means "alternative level of care" and DRG means "drug interaction alert". There is no code called REDISCLOSE. And the old ETH and PSY codes in the v3-Confidentiality system are deprecated; use the v3-ActCode versions. The HL7 definition of 42CFRPart2CD still cites the 2017 consent elements, so use the rule text, not that definition, for your consent form.

A labeled FHIR resource

FHIR puts labels in meta.security on any resource. This illustrative example uses synthetic data. It labels an opioid use disorder condition from a Part 2 program as restricted, SUD-sensitive and covered by Part 2.

{
  "resourceType": "Condition",
  "id": "example-sud-condition",
  "meta": {
    "security": [
      { "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "code": "R" },
      { "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "SUD" },
      { "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "42CFRPart2" }
    ]
  },
  "clinicalStatus": { "coding": [{
    "system": "http://terminology.hl7.org/CodeSystem/condition-clinical", "code": "active" }] },
  "code": { "coding": [{
    "system": "http://hl7.org/fhir/sid/icd-10-cm", "code": "F11.20",
    "display": "Opioid dependence, uncomplicated" }] },
  "subject": { "reference": "Patient/example-synthetic-patient" },
  "recordedDate": "2026-10-01"
}

Add a refrain such as NORDSCLCD only when you send to a recipient that may not redisclose, as described in the redisclosure section. FHIR's standard _security search parameter finds labeled resources, for example GET /Condition?patient=123&_security=http://terminology.hl7.org/CodeSystem/v3-ActCode|42CFRPart2. One FHIR detail catches teams out: on update, servers merge new labels with existing ones by default, so removing a label needs a deliberate step and an audit entry.

Labels inside a resource

The HL7 FHIR Data Segmentation for Privacy implementation guide (DS4P, version 1.0.0, trial use, April 2023) adds inline labels for parts of a resource. A resource with inline labels must also carry the PROCESSINLINELABEL code in meta.security, so a receiver knows to scan the whole resource. The guide also asks for a "high water mark": the resource-level label carries the highest confidentiality inside it, so a client that ignores inline labels still protects the data. Our advice is to avoid inline labels unless you control both ends. Most receivers we see read only resource-level labels.

Labels in C-CDA and HL7 v2

In a C-CDA document, the document-level label is ClinicalDocument/confidentialityCode, and section and entry labels use the DS4P templates named in 45 CFR 170.205(o)(1). In HL7 v2, the ARV (access restrictions) segment carries restriction codes from table 0717, which now includes 42CFRPart2 and 42CFRPart2CD, while the table's original codes are deprecated. Check your v2 partner's version before you rely on ARV, because older interfaces do not send or read it.

The consent model in FHIR

A FHIR Consent resource can hold a Part 2 consent. This illustrative R4 example, with synthetic data, records a single TPO consent. It permits treatment, payment and operations for records labeled 42CFRPart2, and includes a nested deny for use in proceedings against the patient, because that use needs its own separate consent (2.31(d)).

{
  "resourceType": "Consent",
  "id": "example-part2-tpo-consent",
  "status": "active",
  "scope": { "coding": [{
    "system": "http://terminology.hl7.org/CodeSystem/consentscope", "code": "patient-privacy" }] },
  "category": [{ "coding": [{
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "42CFRPart2CD" }] }],
  "patient": { "reference": "Patient/example-synthetic-patient" },
  "dateTime": "2026-10-01",
  "organization": [{ "reference": "Organization/example-part2-program" }],
  "sourceReference": { "reference": "DocumentReference/example-signed-consent-pdf" },
  "policyRule": { "coding": [{
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "42CFRPart2" }] },
  "provision": {
    "type": "permit",
    "period": { "start": "2026-10-01" },
    "purpose": [
      { "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason", "code": "TREAT" },
      { "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason", "code": "HPAYMT" },
      { "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason", "code": "HOPERAT" }
    ],
    "securityLabel": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "42CFRPart2" }],
    "provision": [{
      "type": "deny",
      "purpose": [{ "system": "https://example.org/purpose",
        "code": "legal-proceeding-against-patient" }]
    }]
  }
}

Three notes on this example. The deny purpose uses an invented example.org code, because we found no HL7 purpose-of-use code for "proceeding against the patient"; define one in your own code system. Neither FHIR R4 nor R5 has a "revoked" status, so the common practice is to set the status to inactive and end the provision period on the revocation date, and to keep the written revocation as a document. And FHIR R5 renames several fields (patient becomes subject, policyRule becomes regulatoryBasis, and the base decision moves to a top-level decision), so check which version your partners use.

Keep the signed form as the source of truth. The FHIR resource is how your engine reads the consent quickly. The signed document is what you send as "a copy of the consent" under 2.32(b) and what you show if anyone asks.

The consent engine: how a disclosure decision works

Every read, export, message or API response that might contain Part 2 data passes through one decision. We call the component that makes it the consent engine. It answers one question: may this recipient receive this data for this purpose now?

1. Find the Part 2 data in the response. Use the labels and provenance on each item. If nothing is labeled 42CFRPart2, the Part 2 checks do not apply, though your HIPAA rules still do.
2. Identify the recipient and its type. A HIPAA covered entity, a business associate, a Part 2 program, an intermediary, a QSO or another party. The type changes what the recipient may do next.
3. Read the purpose of use. Treatment, payment, operations, emergency treatment, research, audit or the patient's own request. Refuse any request that has no purpose.
4. Check for a legal-proceedings use. If the purpose is a proceeding against the patient, stop. Only a subpart E court order or a specific legal-proceedings consent allows it, and both go to a person, not to the engine.
5. Look for an exception. A bona fide medical emergency (2.51), research (2.52), audit or evaluation (2.53), de-identified public health data (2.54), or a QSO doing its contracted work (2.12(c)(4)).
6. Find a valid consent. Active, not expired, not revoked, not flagged as disputed, covering this recipient or its class, this purpose and this data.
7. Check restrictions and counseling notes. Remove items covered by an agreed 2.26 restriction, and remove SUD counseling notes unless a counseling notes consent covers them.
8. Build the release. Include only the minimum needed (2.13(a)), attach the 2.32 notice and the consent copy or scope, and add labels the recipient can read.
9. Log it. Write an audit entry for every decision: allowed, partly allowed or refused, with the consent or exception used.

Each step either passes, removes items, or refuses. A partial release is the most common result in practice: the recipient gets the general record without the Part 2 items, plus a statement that some records were withheld. Whether to tell the recipient that records were withheld is a design choice your counsel should approve. Under 2.13(c), a facility publicly known as SUD-only may not even confirm that a person is a patient, so a refusal must not give that away.

API filtering: what your FHIR and HL7 interfaces must do

The consent engine is only useful if every way out of your system goes through it. List them first. Most products have more than the team remembers.

SMART on FHIR and purpose of use

SMART App Launch version 2 has granular scopes, such as limiting an app to lab Observations, but it defines no purpose-of-use claim and nothing about security labels in scopes. So the purpose has to come from somewhere else: the app's registration, a signed agreement for that app, or an extension in your token that you define. We suggest you record the purpose per app at registration, require it for any app that may receive Part 2 data, and default every other app to receiving no labeled data.

Where to put the filter

Put it as close to the way out as you can, in one shared component that every interface calls. Teams that add a filter to each interface separately end up with seven slightly different filters. A single privacy gateway in front of the FHIR server, the interface engine and the export jobs is easier to test and to explain to an auditor. The trade-off is speed: per-item consent checks on a large bulk export are slow, so cache consent decisions per patient, recipient and purpose, and clear the cache on every consent change.

SUD counseling notes and psychotherapy notes

The 2024 rule created "SUD counseling notes": notes by an SUD or mental health professional in a Part 2 program that document or analyze a counseling session and are kept separate from the rest of the record (2.11). The definition copies HIPAA's definition of psychotherapy notes at 45 CFR 164.501. Both exclude the same things: medication, session start and stop times, how the session was done, test results, and summaries of diagnosis, functional status, treatment plan, symptoms, prognosis and progress.

Any use or disclosure of counseling notes needs a separate consent, with a few narrow exceptions, such as the note's author using it for treatment or supervised training (2.31(b)). Treatment, payment, enrollment or eligibility cannot depend on the patient signing it.

For software, the key word is "separate". A note only counts as a counseling note if it is kept apart from the general record. If a counselor types analysis into the ordinary progress note, it is part of the record under the ordinary rules. So:

• Give counseling notes their own note type and their own storage or access path, not just a checkbox on a progress note.
• Keep them out of every general feed, export, summary and search index by default.
• For an AI scribe, write the draft into the progress note structure the program uses, and never into the counseling notes area, unless the program designs that workflow with counsel. Leave the final sign-off to the clinician.
• Label counseling notes with a higher confidentiality, such as V, if your policy asks for it.

A note could in theory be both a Part 2 counseling note and a HIPAA psychotherapy note, when the program is also a covered entity. We did not find clear guidance on how the two consent rules combine in that case. Treat it as a question for counsel and design for the stricter rule.

Patient rights your product must support

Exceptions: when you may disclose without consent

Part 2 allows a short list of disclosures without the patient's consent. Each one has conditions your engine and your staff must check.

• Medical emergency (2.51). To medical staff for a bona fide emergency when consent cannot be obtained. The program must record at once who received the records, who disclosed them, the date and time, and the nature of the emergency. Build an emergency release with those fields required, and send an alert to the privacy officer.
• Research (2.52). Under HIPAA authorization or waiver, or the Common Rule or FDA rules. Researchers are bound by Part 2 and may publish only de-identified data.
• Audit and evaluation (2.53). For funders, regulators, payers and quality bodies, under a written agreement on limits.
• Public health (2.54). Only de-identified data, to the HIPAA standard.
• Qualified service organizations (2.12(c)(4)). A QSO doing its contracted work for the program is not making a disclosure under the rule.
• Court orders (subpart E, 2.61 to 2.68). Only an order that meets subpart E, and never on a subpoena alone. Route these to a person.

Two common mistakes: reporting to a prescription drug monitoring program is not a no-consent exception, because 2.36 requires consent first; and the "safe harbor" in 2.3(b) protects only investigative agencies that show reasonable diligence, not vendors or providers.

Audit: what to log for every disclosure

Several rules need a record of disclosures: the emergency record in 2.51, the intermediary list in 2.24, the paused accounting in 2.25 and HIPAA-style breach and complaint handling under 2.16 and 2.4. One audit design can serve all of them. Log every decision the consent engine makes, including refusals.

In FHIR, an AuditEvent resource fits this well. This illustrative example, with synthetic data, records a treatment disclosure and links the consent it relied on.

{
  "resourceType": "AuditEvent",
  "type": { "system": "http://dicom.nema.org/resources/ontology/DCM",
            "code": "110106", "display": "Export" },
  "action": "R",
  "recorded": "2026-11-09T10:15:00Z",
  "outcome": "0",
  "purposeOfEvent": [{ "coding": [{
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason", "code": "TREAT" }] }],
  "agent": [
    { "who": { "reference": "Organization/example-part2-program" }, "requestor": false },
    { "who": { "reference": "Organization/example-receiving-clinic" }, "requestor": true }
  ],
  "source": { "observer": { "reference": "Device/example-privacy-gateway" } },
  "entity": [
    { "what": { "reference": "Patient/example-synthetic-patient" } },
    { "what": { "reference": "Condition/example-sud-condition" },
      "securityLabel": [{
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "42CFRPart2" }] },
    { "what": { "reference": "Consent/example-part2-tpo-consent" },
      "description": "Consent this disclosure relied on" }
  ]
}

Keep audit records for at least as long as any report could ask for them. The 2.24 list and the 2.25 accounting both look back 3 years, and HIPAA requires six years for certain documentation. Your counsel sets the final period.

Security and breach

Part 2 programs and lawful holders need written security policies for paper and electronic records: how records are created, received, kept, sent, accessed and destroyed, and how media is cleaned (2.16(a)). The HIPAA breach notification rule now applies to breaches of unsecured Part 2 records (2.16(b)), with the same notices and timelines as HIPAA. Penalties follow HIPAA's civil and criminal penalties (2.3(a)), and HHS uses HIPAA's enforcement process (2.3(c)).

The engineering list is the one you know from HIPAA, with a few Part 2 additions:

• Encrypt Part 2 data in transit and at rest, so that a lost device or file is not "unsecured" under the breach rule.
• Give support and engineering staff no default access to Part 2 data, and log every exception.
• Keep note text, consent forms and diagnoses out of application logs, error reports and analytics tools.
• Check every vendor in the path. QSOAs and business associate agreements must cover cloud hosting, messaging, email, AI and support tools.
• Test de-identification against the HIPAA standard before any data leaves for analytics or public health.

Community discussion in the Health Tech Nerds group, which we reviewed in anonymized form, raised two vendor problems again and again. Some cloud and messaging vendors did not know what a QSOA was, and at least one SMS provider was described as unwilling to support Part 2 use. Check this before you choose a vendor, not after.

ONC certification, TEFCA and HIEs: what you can and cannot rely on

The security tag criteria are going away

Two ONC certification criteria tested security tags: 170.315(b)(7) for sending a summary of care with tags at the document, section and entry level, and 170.315(b)(8) for receiving one and keeping the tags. They were never part of the Base EHR definition, so CMS programs never required them. ONC's HTI-5 final rule, published October 28, 2026 (91 FR 67916), removes both from December 28, 2026. ONC gave low certification uptake as a reason, and noted that different systems label and enforce sensitive data differently. Most comments opposed the removal. ONC said it may address consent and segmentation in future rulemaking, and pointed to its LEAP consent projects.

For engineers this has two effects. You cannot assume an EHR can send or keep Part 2 tags just because it is certified. And from 2027 there is no certification test that a vendor can point to. Ask each EHR and HIE partner directly what they send, what they keep, and what they ignore.

TEFCA and national networks

We searched the TEFCA Common Agreement version 2.0, the Exchange Purposes standard operating procedure version 5.0 (effective February 15, 2026) and the Treatment SOP version 1.2 on November 9, 2026. None of them mentions 42 CFR Part 2. The draft QHIN Technical Framework 2.1 describes a general way to attach consent policies to a request, and a responder may refuse a request it cannot process without one. That is generic, not Part 2 specific, and it is a draft. So, as of today, there is no published TEFCA rule that a network must support Part 2 consent. Part 2 still applies through the law. Treat national network queries as a route that needs your own filter, and check again when TEFCA publishes new versions.

HIEs and intermediaries

Since 2024, an intermediary is someone other than a Part 2 program, covered entity or business associate that receives records under a general designation to pass on to members who treat the patient (2.11). An HIE that is a business associate of its members is not an intermediary under this definition. One that is not a HIPAA entity may be. If you are an intermediary, you owe the patient a list of who received their records in the past 3 years within 30 days of a written request (2.24). Design that report from day one.

A few state HIEs publish their own Part 2 programs. Contexture (serving Colorado and Arizona) and Kentucky's KHIE publish Part 2 consent material, according to their own sites. Most EHR vendors we checked publish no public Part 2 documentation at all. Netsmart and ICANotes publish some; for Epic, Oracle Health, Qualifacts, Valant, Healthie, TherapyNotes, SimplePractice, athenahealth and eClinicalWorks we found no public statement on how their APIs label or filter Part 2 data. That means we found no public source, not that the feature is missing. Ask each vendor.

Edge cases that break Part 2 designs

Migrating records you already hold

Most teams start with years of data that has no labels. The migration has to find the Part 2 data without labeling everything, and it needs people to confirm the hard calls.

1. List every source. Every organization, unit and feed you have ever received data from, with dates.
2. Classify each source. A compliance owner confirms which sources are, or were, Part 2 programs, and from what date. This is a human decision, recorded with a name and date.
3. Label by source. Apply 42CFRPart2 labels to every item that came from a confirmed Part 2 source, whatever its code.
4. Search by code for stragglers. Run SUD code and medication searches across unlabeled data to find items that might have come from a Part 2 program through a route nobody listed. Send these to a review queue. Do not label them automatically.
5. Link consents. Match existing consent forms to patients and record their elements. Many old consents predate the 2024 rule. Your counsel decides whether they still cover current uses.
6. Find counseling notes. Identify notes kept separately as counseling notes and move them to the separate note type.
7. Turn on filtering in a dry run. Run the consent engine in "log only" mode for a few weeks. Compare what it would have blocked with what actually went out.
8. Switch to enforcement, one route at a time. Start with the riskiest route, usually bulk exports, and keep the dry-run comparison for the rest.

Keep a check query for each step, with its expected result, so anyone can rerun it. For example: "every item from a confirmed Part 2 source has a 42CFRPart2 label" should return zero exceptions after step 3.

How to test a Part 2 implementation

Part 2 bugs are silent. A missing filter does not throw an error; it sends a record. So the tests have to prove what does not happen, as well as what does. Use synthetic patients only.

Run these tests on every release, not once. A new interface, a new report or a new AI feature is the usual way Part 2 data starts leaking.

Where Part 2 engineering is needed: 8 use cases

A build plan: phases and what each delivers

The size of the work depends on how many ways data leaves your system. These phases are the order we recommend. The time each takes depends on your interfaces and on how fast your compliance owners confirm sources, so we do not give a single number here.

Common mistakes we see

• Labeling data by diagnosis code alone, which both over-restricts and misses records.
• Reading "no segmentation required" as "no tagging required".
• Sending the 2.32 notice without the consent copy or scope.
• Adding a "no redisclosure" label for every recipient, which blocks hospitals and plans that may redisclose under HIPAA.
• Filtering the FHIR API but not the bulk export, the HL7 feeds or the reports.
• Treating SUD counseling notes as a checkbox on a progress note.
• Assuming an EHR handles Part 2 because it is certified.
• Logging note text while debugging.
• Answering legal requests from a support queue.
• Choosing cloud, SMS or AI vendors before checking they will sign a QSOA or business associate agreement.

Where Nirmitee fits

We design and build the engineering side of 42 CFR Part 2 for healthcare software teams: the data flow map, the data model and labels, the consent engine and gateway, migration of existing records and the test suite. We work with your counsel and privacy officer, who own the legal decisions. We do not give legal advice.

What a Part 2 gap check gives you

This is the fixed-scope first step we offer. You get a written answer to "where can Part 2 data leave our system today, and what do we need to build to control it".

It starts with a 30-minute call, where we confirm the scope and agree a fixed price and delivery date before any work begins. You keep everything we send, whether or not you work with us afterwards. Book a call to scope your Part 2 gap check.

Sources

• eCFR, 42 CFR Part 2, current text (last amended September 17, 2024), read November 9, 2026.
• Federal Register, "Confidentiality of Substance Use Disorder (SUD) Patient Records", final rule, 89 FR 12472, February 16, 2024, including the preamble on 2.25 and segmentation.
• Federal Register search for documents amending 42 CFR Part 2 since January 1, 2024, run November 9, 2026.
• HHS Office for Civil Rights, "Office for Civil Rights Announces Civil Enforcement Program for Confidentiality of Substance Use Disorder Patient Records", February 13, 2026 (hhs.gov), read November 9, 2026.
• 45 CFR 164.501, definition of psychotherapy notes, and 45 CFR 164.514(b), de-identification (eCFR).
• ONC HTI-5 final rule, 91 FR 67916, October 28, 2026, section on security tags, and 45 CFR 170.315(b)(7), (b)(8) and 170.205(o)(1) (eCFR).
• HL7 terminology release 7.5.0 (terminology.hl7.org): v3-ActCode, v3-Confidentiality, v3-ActReason and v2 table 0717, read November 9, 2026.
• HL7 FHIR Data Segmentation for Privacy implementation guide 1.0.0; FHIR R4 and R5 Consent, security labels and search pages; SMART App Launch version 2 scopes.
• TEFCA Common Agreement 2.0, Exchange Purposes SOP 5.0, Treatment SOP 1.2 and draft QHIN Technical Framework 2.1 (rce.sequoiaproject.org), searched November 9, 2026.
• Public Part 2 pages of Netsmart, ICANotes, Contexture and KHIE, and practitioner discussion in the Health Tech Nerds community, 2022 to 2026, anonymized.