Behavioral Health EHR + Billing Integration: A Compliance Field Guide
The behavioral health orgs that get cited in audits aren't the ones with bad EHRs, they are the ones whose EHR-to-billing integration creates audit gaps that show up only in 42 CFR Part 2 inspections.
Updated for 2026, Every behavioral-health integration we audit now includes an AI-summarization or AI-coding hop, and most of them are off-BAA. Pair this guide with our HIPAA AI architecture reference implementation and telehealth compliance architecture for HIPAA and state prescribing before assuming the EHR vendor's BAA covers the AI layer. The integration surface is the compliance surface When a multi-site behavioral health provider, a community mental-health center, or a substance-use treatment network calls us in, the conversation almost always opens with a version of the same sentence: "Our EHR vendor told us they're fully HIPAA-compliant and Part-2-aware." We hear it from CIOs who recently signed Netsmart, from CCOs evaluating Qualifacts, from COOs in the middle of a Valant migration. It is almost never wrong. It is almost always beside the point. The EHR vendor's compliance posture covers the EHR. The Office of Civil Rights and the SAMHSA Part 2 inspector do not stop at the EHR. They follow the data, to the clearinghouse that submits the claim, to the prior-authorization portal the case manager uses, to the lab that processes a urine drug screen, to the HIE feed that pushes a discharge summary to a physical-health partner. At every one of those boundaries, a consent decision was made, or, more commonly, was assumed away, and at every one of those boundaries the audit has a question to ask. We have read more than forty Part 2 and HIPAA assessment reports against behavioral health providers in the last two years. The pattern is consistent. The orgs that get cited are not the ones that picked the wrong EHR. They are the ones that picked a credible EHR with the right BAA, scoped their compliance program to that EHR, and then watched PHI travel through five integrations that the program never looked at. The integration with the clearinghouse retains diagnoses on a system the EHR vendor doesn't control. The integration with the eligibility-check service caches member data for ninety days. The lab interface logs the full HL7 message body to a non-BAA observability stack. None of those gaps are EHR gaps. All of them are findings. The integration surface is the compliance surface because the integration surface is where consent posture either survives or dies. Inside the EHR, a Part-2 patient's chart carries a flag that gates redisclosure. Outside the EHR, in the 837P claim, in the 270/271 eligibility round-trip, in the C-CDA summary, that flag is either preserved by deliberate engineering or quietly stripped by default integration behavior. Most behavioral health orgs we audit have not asked the question. The audit will ask it for them. This field guide is for the CIO, CCO, or COO at a 50-to-500-employee behavioral health organization who is responsible for the answer. It walks through what 42 CFR Part 2 actually requires after the 2024 amendments, the six failure modes we see most often in BH integrations, where the major EHR platforms stand on Part-2 awareness, what the billing-clearinghouse contract has to say, where AI fits and where it does not, and the 21-day diagnostic we run with clients on the Pass-Audits engagement. The close is three actions any BH CIO can take this month, paired with the EHR-to-Billing Integration Compliance Map for download. 42 CFR Part 2 in plain English, for a CIO Part 2 is the federal rule that governs records of patients treated for substance-use disorders by federally-assisted programs. It sits beside HIPAA, not inside it. For a CIO who is fluent in HIPAA, the most useful framing is: Part 2 is HIPAA with a tighter consent rule, a narrower redisclosure rule, and a specific audit-trail expectation that HIPAA on its own does not require. Three things matter for the architecture decisions a CIO has to make. First, the consent rule. Under HIPAA, treatment, payment, and operations (TPO) generally do not require patient authorization for PHI to move between covered entities. Under Part 2, even routine TPO disclosures of substance-use treatment records have historically required specific written patient consent. The 2024 amendments aligned Part 2 with HIPAA in a meaningful way: a single patient consent can now cover all future TPO disclosures, rather than requiring a fresh consent for each one. Architecturally it changes very little. The org still has to capture the consent, attach it to the right record, propagate the consent state to every downstream system that touches the record, and demonstrate at audit that every disclosure either had an active consent or fell into a narrow exception (medical emergency, court order, audit/evaluation, qualified service organization). The consent token has to travel. It usually doesn't. Second, the redisclosure rule. A Part 2 record that leaves the program carries a prohibition on redisclosure with it. The recipient cannot pass it along absent its own patient consent or an exception. The mechanism is the redisclosure notice, a specific statement that has to accompany the record. The 2024 amendments simplified the standardized notice language, but the obligation is unchanged. If the EHR sends a C-CDA to a primary-care partner via an HIE and the C-CDA does not carry the notice, the disclosure is non-compliant on its face. We have read dozens of HIE feed configurations from BH providers; about half strip the notice somewhere in the pipeline because the interface engine flattens metadata it doesn't recognize. Third, the two-disclosure standard for the audit trail. Part 2 requires the program to keep a record of disclosures sufficient to support the patient's right to know who has received their record. In practice, the audit will pick two disclosures at random from the prior twelve months and ask the program to produce: who initiated the disclosure, what consent or exception authorized it, what specifically was disclosed, who received it, and what redisclosure notice accompanied it. The program that can produce that record in under an hour passes. The program that needs three days to reconstruct it from EHR audit logs, clearinghouse reports, and HIE delivery receipts has, functionally, failed, even if the underlying disclosure was lawful. The 2024 amendments also strengthened patient rights, introduced Part-2-specific breach notification aligned to HIPAA's, and clarified that violations can now carry HIPAA-equivalent civil penalties under the HITECH Act framework. The financial stakes are no longer hypothetical. A Part 2 finding used to feel like a corrective-action plan. After the amendments, it feels like a HIPAA settlement. For the architecture, three implications follow. The consent state must be a first-class data element in every system that handles substance-use records, not a flag inside the EHR alone. The redisclosure notice must travel on every outbound channel, not selectively. And the disclosure-accounting log must be queryable across the EHR, the clearinghouse, the HIE feed, and the lab interface, not reconstructable only after a regulator asks. None of those are EHR-vendor decisions. All of them are integration decisions. The six failure modes Securem sees in behavioral health Across the BH engagements we have run, six failure modes recur. Each is sanitized below from real findings. None of them sit inside the EHR. All of them sit at an integration boundary the org's compliance program had not scoped. Failure mode 1: PHI in clearinghouse logs and SFTP archives. A multi-state outpatient SUD provider routed claims through a national clearinghouse under a standard BAA. The clearinghouse retained 837P submission files in an SFTP archive for seven years, including F-series ICD-10 codes. The provider had a BAA with the clearinghouse and assumed that closed the loop. The audit asked who at the clearinghouse could access the SFTP archive, and the clearinghouse could not produce a role-based access list that distinguished BH claims from physical-health claims. The finding was a Part 2 redisclosure violation through inadequate access controls at the business associate. Remediation took six months and required a contract renegotiation. Failure mode 2: Prior-authorization integration leaking diagnoses. A community mental-health center used a third-party prior-auth automation tool that sat between the EHR and several payer portals. The tool pulled ICD-10 codes, CPT codes, and clinical notes from the EHR via API and posted them to the payer. The tool's own operational logs, for retry, debugging, and SLA reporting, captured the full payload. The vendor's BAA covered the tool's primary database. It did not enumerate the operational logs as a covered system. PHI sat in a non-BAA-covered log store for the lifetime of the vendor's debug retention. The fix was vendor-side; the finding was provider-side. Failure mode 3: Clinical-document exchange that doesn't honor consent. A behavioral health hospital participated in a regional HIE for care coordination. The HIE feed pushed C-CDA discharge summaries to any participating provider that requested them. The EHR's outbound feed honored a Part-2-consent flag on the patient record, but only at the patient level, not the encounter level. A patient who had consented to share a 2022 outpatient therapy episode also had a 2023 detox admission that was never separately consented. The C-CDA aggregated both. The HIE distributed both. The audit caught it on an accounting-of-disclosures request. Failure mode 4: Lab integration with insufficient minimum-necessary. A SUD provider's EHR was integrated with a national reference lab for urine drug screens. The HL7 ORM message included the full demographic block, the ordering clinician, and, because the EHR template defaulted to "send all relevant clinical context", the active problem list, including non-substance-use diagnoses. The lab needed the order, the identifier, the specimen, and a small subset of history. It did not need the full problem list. The integration violated minimum-necessary on every order. Failure mode 5: Telehealth recording retention. During the post-2020 telehealth expansion, several BH providers adopted video platforms that recorded sessions by default. Some recordings landed in a cloud bucket with 90-day retention; others landed in the EHR media module under indefinite retention. The provider had no consistent policy. When the audit asked for the disclosure-accounting log of session recordings, the provider could produce it for the EHR-stored recordings and not the bucket-stored ones, which were also accessible to IT without role-based gating distinguishing BH from non-BH content. The finding was on access controls and disclosure accounting; the underlying issue was unscoped recording retention. Failure mode 6: Integration vendor with no Part-2-aware BAA. The meta-failure behind the others. The org's BAA template was written for HIPAA. It addressed PHI handling, breach notification, sub-processor flow-down, and audit rights. It did not address Part-2-specific obligations: redisclosure prohibition acknowledgment, consent-state propagation, Part-2-specific breach reporting, qualified-service-organization status where applicable. Several integration vendors had executed the BAA truthfully and were not architected for Part 2. At audit, the regulator asked for the Part-2 addendum on the clearinghouse BAA. There wasn't one. The finding was a business-associate-management deficiency under HIPAA and a Part-2 redisclosure failure simultaneously. The pattern across all six: the EHR was not the problem. The integration was the problem. In each case, the EHR's BAA was real and its internal controls were defensible. In each case, the audit finding sat one boundary outside the EHR, at the clearinghouse, the prior-auth tool, the HIE, the lab, the video platform, or the BAA template itself. In each case, the compliance program had been scoped to the EHR and the engineering team that built the integrations did not have Part-2 experience. EHR matrix: who does Part 2 well Behavioral health EHR is a fragmented market. Six platforms cover most of the mid-market: Netsmart (myAvatar, myEvolv, CareManager), Qualifacts (CareLogic, Credible, InSync), Sigmund (AURA), Valant, TheraNest, and SimplePractice. They serve overlapping but distinct segments, Netsmart and Qualifacts dominate large multi-site community-mental-health and SUD networks, Sigmund concentrates in residential and inpatient SUD, Valant serves mid-size outpatient psychiatry, and TheraNest and SimplePractice dominate small-group and solo-practice telehealth-first practices. We score them below on four dimensions that determine integration-era compliance posture, not clinical workflow fit. The scoring reflects what we have seen across engagements as of late 2025; vendors update quarterly, and our internal version of this matrix is refreshed against each new engagement. | EHR | Part 2 awareness in core product | Integration audit logging | Consent management granularity | Clearinghouse / billing posture | |---|---|---|---|---| | Netsmart (myAvatar / CareManager) | Strong, Part 2 was a foundational design constraint; encounter-level consent supported | Strong on internal modules; weaker visibility on third-party HIE feeds unless explicitly configured | Patient + encounter level; supports 2024-amendment single-consent model | Native clearinghouse (Netsmart Claims) is BAA-covered and Part-2-aware; third-party clearinghouses require separate diligence | | Qualifacts (CareLogic / Credible) | Strong, both CareLogic and Credible were built for community BH and SUD | Good, audit logs exposed for integration paths; HL7 and API logs queryable | Patient + encounter level; consent templates configurable per program | Multiple clearinghouse partners; provider must verify Part-2 addendum on the chosen partner's BAA | | Sigmund (AURA) | Strong, heavily concentrated in residential SUD; Part 2 is core | Adequate, integration-layer logging requires customer configuration | Patient + encounter level; supports program-by-program consent models | Tight integration with a small number of clearinghouses; relationship-driven, generally Part-2-aware | | Valant | Moderate, built for outpatient psychiatry, not SUD-first; Part 2 supported but not foundational | Adequate for in-product audit; integration logs vary by integration | Patient-level; encounter-level requires workaround | Standard clearinghouse partners; provider must verify Part-2 addendum | | TheraNest | Light, designed for small group practices; HIPAA-focused, Part 2 capabilities are minimal | Limited, audit logs sufficient for HIPAA, thin for Part-2 disclosure accounting | Patient-level only; not architected for the Part-2 redisclosure model | Native billing module; clearinghouse posture appropriate for small practice, not for SUD-program scale | | SimplePractice | Light, telehealth-first solo and small-group practices; HIPAA-focused | Limited, operational logs, not audit-grade for Part 2 | Patient-level only | Native billing; thin Part-2 posture | Two practical observations. First: EHR fit for Part 2 tracks closely with the EHR's historical customer base. Netsmart, Qualifacts, and Sigmund were built for organizations where Part 2 is a daily operational fact. Valant, TheraNest, and SimplePractice were built for clinicians where Part 2 is a sometimes-applies overlay. None of these vendors is doing Part 2 wrong. They are positioned for different buyers, and the buyer that is wrong about which segment they sit in will discover it in the audit. Second: even the strongest EHRs on this list cannot, on their own, close the integration surface. Netsmart's encounter-level consent is excellent inside the EHR. The C-CDA generator either honors that consent on outbound feeds or it does not, depending on configuration. The clearinghouse retention either matches the EHR's or it does not. The compliance program either looks at the boundary or it does not. The matrix above is a starting point, not a finish line. Billing integration as audit surface For most BH providers in the US mid-market, the revenue cycle passes through one or two clearinghouses, Change Healthcare/Optum, Availity, Waystar, Inovalon, and a handful of regional players cover most of the segment. The clearinghouse is the single highest-volume PHI integration in the organization. Every 837P submission, every 277CA acknowledgment, every 835 remittance carries the patient identifier, the diagnosis (often F-series ICD-10), the rendering provider, the service location, and the dates of service. For a Part-2-covered program, every one of those records is a substance-use treatment record on the wire. The clearinghouse contract has to do four specific things. Most off-the-shelf clearinghouse BAAs do two. The other two are where the gap sits. One: explicit acknowledgment that the records contain Part-2-protected information. The standard HIPAA BAA treats PHI as a single category. A Part-2-aware addendum names substance-use records as a covered subcategory and binds the clearinghouse to the redisclosure prohibition. Without this, the clearinghouse's sub-processors are operating under HIPAA's redisclosure-permissive model, not Part 2's restrictive model. Two: enumerated retention and access controls for Part-2 records. The addendum should specify retention duration, the role-based access controls that govern who at the clearinghouse can read those records, and the logging that supports a disclosure-accounting request. "We follow HIPAA-compliant practices" is not enough. Three: redisclosure notice handling. The 837P has no native field for the Part-2 redisclosure notice. The addendum should specify how the notice is conveyed, typically through the clearinghouse's acknowledgment of Part-2 status across the relationship rather than per-claim, and bind the clearinghouse to honor it on any onward transmission. Four: a disclosure-accounting cooperation clause. When the provider receives an accounting-of-disclosures request from a patient, the clearinghouse must be contractually obligated to produce, within a defined SLA, the record of which payers received which claims over the prior six years. Most clearinghouse standard BAAs do not include this clause. Clearinghouses that serve the BH market know how to execute a Part-2 addendum. They have done it for other clients. The provider has to ask. The 1-page addendum that closes the most common gap is the most leveraged document a BH CIO can put on the desk this quarter, one email to the clearinghouse account team to get it drafted, and it forecloses the most common Part-2 finding we see at audit. The Integration Compliance Map paired with this guide includes a template and a negotiation checklist. AI in behavioral health: the substance-use specialness Behavioral health is the segment where AI runs into Part 2 the hardest, and where the architecture choices that work for physical health do not transfer cleanly. The constraints are not theoretical. They are operational. The consent posture is the issue. Under HIPAA, an AI scribe drafting a progress note from a session transcript is operating inside the TPO frame, generally fine. Under Part 2, the same workflow on a substance-use session has more questions to answer. Did the patient consent to AI processing of the record specifically? Does the consent template cover the AI vendor as a recipient under the 2024 single-consent model? Does the AI vendor's logging, prompt, completion, retrieval context, sit on Part-2-aware infrastructure or only HIPAA-compliant infrastructure? Can the AI workflow produce a disclosure-accounting record that names the patient, the recipient, and the basis for the disclosure? We have looked at the Part-2 posture of the major AI scribe vendors over the last year. The picture is uneven. Vendors that have invested in BH have extended their BAA template to include Part-2 acknowledgment, logging that supports disclosure accounting, and clinician-side consent capture flows. Vendors that have not are operating under their HIPAA template and assuming TPO covers the use case. For BH workflows specifically, the second posture is not durable. The practical guidance we give BH clients: AI works well today in administrative workflows and works poorly in clinical workflows without specific guardrails. Where it works: prior-authorization letter drafting; billing-code suggestion (advisory, never final submitter); documentation cleanup from clinician dictation, with a Part-2-aware vendor; policy generation, board-document prep, and regulatory-evidence drafting from non-PHI inputs. Where it does not work yet: clinical decision support that runs autonomously without prescriber co-sign; risk stratification where the input includes Part-2 records distributed to a model vendor whose BAA does not explicitly cover Part 2; AI summarization that pushes substance-use records into a downstream system that has not been independently scoped. The framework from our HIPAA AI Architecture reference, pick the architecture before the model, applies in BH with one tightening. In BH, Architecture D (PHI never leaves the trust boundary; only de-identified or non-PHI representations cross to the model) is more often the right starting answer than in physical health. The de-identification has to be defensible, Safe Harbor or Expert Determination, documented, but once it is, the workflow ships safely while the org figures out the Part-2-specific BAA conversation with its preferred AI vendor. Where the Diagnostic fits When a behavioral health provider engages us on the Diagnostic for the Pass-Audits engagement, we run a 21-day audit against the EHR-to-billing integration surface. The audit produces a written report that the CIO hands to the board, the CCO hands to the auditor, or the leadership team hands to a new clearinghouse partner during procurement. The structure is below; we publish it here because it is more useful as a reference than as a sales pitch, and because most of it can be done internally if the org has the bandwidth to run it. Days 1–4: Scope and inventory. We document every system that touches a Part-2 record. The EHR. The clearinghouse. The eligibility-check service. The prior-auth tool. The HIE feed. The lab interface. The telehealth platform. The collections vendor. For each: data classification, integration mechanism (HL7, API, SFTP, portal), BAA status, Part-2 addendum status, disclosure-accounting capability. Output: a single architecture diagram of the PHI flow, plus a master inventory. Days 5–9: BAA chain audit. We pull every BAA for every system on the inventory. We check for: HIPAA scope, Part-2 addendum, breach notification SLA, sub-processor flow-down with Part-2 acknowledgment, audit rights, and disclosure-accounting cooperation. Output: a BAA gap register, every component on the chain that does not have a Part-2-adequate BAA. Days 10–14: Consent and redisclosure walkthrough. We trace the consent state from EHR through every outbound boundary. Does the C-CDA carry the redisclosure notice. Does the 837P route through a clearinghouse with a Part-2 addendum. Does the prior-auth tool log substance-use codes onto an enumerated covered system. Does the HIE feed strip metadata. We run the two-disclosure standard: pick two random disclosures from the prior twelve months and reconstruct who, what, when, why, and notice. Output: consent-and-redisclosure matrix. Days 15–18: Failure-mode walk-through and remediation prioritization. We run the six failure modes from section three plus four secondary patterns we track internally. Each gap is ranked by audit-finding likelihood × cost-to-remediate. Output: prioritized remediation plan with owner, effort, and timeline. Days 19–21: Report and walkthrough. We deliver a 25-to-40-page written report. The CIO hands it to the board. The CCO hands it to the auditor. We run a 60-minute walkthrough with the leadership team and provide a 30-day clarifying-question window. The report stands on its own, it does not require us to act on it. Three actions any BH CIO can take this month, regardless of whether they engage us: 1. Inventory every Part-2 record path and which BAAs cover it. Pull the integration list from IT, the vendor list from procurement, and the workflow list from clinical operations. Map each integration to its BAA and check whether a Part-2 addendum exists. Most orgs we work with cannot do this exercise in a single afternoon, that is the first finding. 2. Send the 1-page Part-2 addendum to the clearinghouse this month. Pick the clearinghouse that handles the highest BH claim volume. Send the addendum template (in the Integration Compliance Map paired with this guide). Get it executed. This single document closes the most common Part-2 audit finding we see in the field. 3. Run the two-disclosure test internally. Pick two random disclosures from the prior twelve months, one from the EHR, one from the billing/clearinghouse path, and try to reconstruct the full disclosure-accounting record in under an hour. If you cannot, the gap is at the integration logging surface, not the EHR. Fix the logging on the highest-volume integration first. Three actions, ninety days, no engagement required. If the inventory or the BAA chain or the disclosure-accounting reconstruction surfaces gaps the org cannot close internally, or if the integration surface is large enough that getting it wrong is expensive, that is where the Diagnostic comes in. Three weeks, fixed price, written report you keep regardless. More on the engagement model at Pass Audits, the segment context at Behavioral Health, the Part-2 framework at HIPAA + Behavioral Health, and the regulator background at SAMHSA / Part 2. The EHR-to-Billing Integration Compliance Map paired with this guide gives you a worksheet for inventorying every Part-2 record path, a side-by-side BAA scorecard for the major BH EHRs and clearinghouses, and a template for the 1-page Part-2 addendum. Use it on every integration review. Use it on every clearinghouse procurement. Update it whenever a new integration ships, and we will keep doing the same on our side.