Behavioral health EHR evaluation for ASAM Fourth Edition compliance

It’s the specific set of criteria that test whether a platform’s clinical documentation, billing logic, and review workflows can be structured around the six ASAM dimensions and level-of-care system — or whether ASAM is handled as a form layered on top of a general encounter template built for primary care or general mental health, not SUD treatment specifically.

That distinction matters because ASAM isn’t a documentation preference — it’s the framework payers and state Medicaid programs use to determine whether a claim gets paid. A platform that handles scheduling, billing, and general clinical notes well can still leave a program exposed if it has no structured way to link a Dimension 5 finding to a residential placement, or to flag that a concurrent review deadline for a Level 3.7 patient is three days out.

If your organization is also running a general behavioral health EHR evaluation, blueBriX’s 10 questions to ask every behavioral health EHR vendor before you sign covers the foundational ground. The questions below are specific to programs delivering ASAM-governed SUD care, and specific to which member of your committee should be asking them.

Fourth Edition adoption has been rolling rather than uniform, and it moved again since most vendor comparisons in this space were written. Kentucky and Illinois adopted the Fourth Edition for Medicaid SUD services effective July 1, 2025 ^[2][3]. Louisiana followed on its own timeline: the transition took effect January 1, 2026, for beneficiaries 18 and older, with the state updating its Specialized Behavioral Health Services fee schedule to reflect the changed rates and services, and full provider compliance required by July 1, 2026 ^[4]. Colorado and Oregon have set July 2027 adoption dates; Washington has set January 2028 ^[5] [6].

Commercial payers moved earlier and independently of any state timeline — Optum applied the Fourth Edition to commercial plans starting in November 2023, and HCSC Blue Cross Blue Shield plans across five states followed on January 1, 2025 ^{[7] [8]}.

For a behavioral health organization’s buying committee, the practical effect is that you’re very likely already documenting to multiple editions depending on payer, and that split isn’t resolving on a fixed date. Your Compliance/Quality lead needs to know this before your IT/Integration lead signs off on any platform’s data model.

A multi-payer SUD program is very likely documenting to two ASAM editions at the same time, right now.

Bring all eight to every vendor conversation — but assign ownership so nothing gets waved through because it wasn’t the reader’s job to catch it.

1. Are all six ASAM dimensions captured as structured, discrete fields — not free text inside a general assessment note?
   Owner: Compliance/Quality Owner
   Why it matters: If Dimension 6 (person-centered considerations) lives as a paragraph inside a narrative note rather than a structured field, the platform can’t surface it separately in a prior authorization package or flag when it’s missing.
   Red flag: The system captures ASAM data only as unstructured narrative text, with no way to isolate or report on an individual dimension. If the fields underneath a customizable form are not structured at the dimension level, this data cannot be pulled, reported, and flagged independently. A vendor who can’t show that distinction, regardless of how flexible their form builder is, hasn’t answered the question.
2. Can the platform tie the documented dimensional profile directly to the ASAM level and billing code being submitted?
   Owner: Revenue/Finance Owner
   Why it matters: H0015 (IOP, per diem) or S9480 (mental health IOP), H0035 (PHP, Medicaid) or S0201 (PHP, commercial), H0018/H0019 (residential, short/long-term), and H0017 (residential, 30 days or fewer) each map to specific ASAM levels. ^[9]. If the clinical documentation and the billing code selection live in separate systems, the connection that justifies the claim exists only in a biller’s judgment.
   Red flag: Code selection is a manual dropdown disconnected from the clinical assessment just completed.
3. Does the platform enforce concurrent review cadence by level of care, not as a single generic reminder?
   Owner: Revenue/Finance Owner, with Compliance/Quality Owner sign-off
   Why it matters: Review timing varies meaningfully by level — roughly every 3 to 5 days for medically managed withdrawal, every 5 to 7 days for PHP, every 5 to 10 sessions for IOP. A platform sending the same generic “review due” alert regardless of level will either fire too often to be useful or miss the tighter windows entirely.
   Red flag: The vendor can’t demonstrate a level-specific review schedule without custom configuration work.
4. Can a patient move between levels of care — residential to IOP, PHP to outpatient — without losing documentation or billing continuity?
   Owner: Compliance/Quality Owner
   Why it matters: Step-downs need to be documented with the same rigor as admissions: which dimensions stabilized, what changed in the recovery environment, what the ongoing monitoring plan is. If a transition requires re-enrolling the patient as a new record, that continuity breaks exactly where payers look hardest.
   Red flag: A “transition” in the demo is really a discharge and a new intake.
5. Can the system track which ASAM edition applies per payer and per program, given uneven adoption?
   Owner: IT/Integration Gatekeeper, with Revenue/Finance Owner input on payer mix
   Why it matters: With Kentucky, Illinois, and Louisiana on the Fourth Edition for Medicaid, Colorado and Oregon on 2027 timelines, Washington on 2028, and commercial payers years ahead of most states, a multi-payer program is very likely documenting to both editions simultaneously.
   Red flag: The vendor treats this as a one-time settings toggle rather than a per-payer, per-program capability.
6. Does the platform distinguish Level 3.1 recovery-residence/IOP pairings, and Level 4 Psych from general acute Level 4, as their own configurations?
   Owner: Compliance/Quality Owner
   Why it matters: Both are Fourth Edition-specific structural changes with their own billing and staffing implications. A platform still running Third Edition level definitions under the hood will misclassify both.
   Red flag: The vendor is unfamiliar with either distinction when you raise it.
7. Are discharge planning and recovery support service linkage built into the workflow, not just the discharge summary template?
   Owner: Compliance/Quality Owner
   Why it matters: The Fourth Edition’s chronic care model expects recovery support service linkage and remission monitoring as part of appropriate care, not a formality assembled on the last day of a stay.
   Red flag: Discharge planning fields exist but aren’t populated until discharge day, with no earlier prompts.
8. Does the platform’s data architecture support 42 CFR Part 2’s single-consent model and record-level segregation for SUD records — and does it support CARF-aligned reporting if that matters to your payer contracts?
   Owner: Compliance/Quality Owner, with IT/Integration Gatekeeper on architecture
   Why it matters: Part 2 is a behavioral-health-specific consent and disclosure framework that a general medical EHR RFP has no reason to test. CARF is separately the only ASAM-approved certification body for residential levels 3.1, 3.5, and 3.7, and some major payers weight it in contracting decisions.
   Red flag: The vendor answers “we’re HIPAA compliant” without addressing Part 2 specifically, or hasn’t heard of CARF in this context.

This is an assessment of whether ASAM can exist as a first-class concept within the platform’s data model — dimensions, levels, transitions, and edition status represented as structured, connected data — regardless of whether that data model is delivered through a fixed, built-in ASAM module or a configurable one. The distinction that matters isn’t forms versus no forms, or configurable versus fixed; platforms built either way can get this right, and platforms built either way can get it wrong. What separates them is whether the fields captured through intake, referral, treatment planning, and billing are actually connected to each other as structured data, or whether they’re separate forms that happen to sit in the same interface. Two platforms can look identical in a demo — the same six-dimension intake screen, the same level-of-care picker — while one ties that data to referral routing, billing code selection, and review cadence automatically, and the other requires staff to carry the connection themselves. The distinction becomes evident six months after go-live, when concurrent review denials, data integrity issues, and audit findings expose how deeply ASAM is actually wired into the platform, rather than just displayed by it.

Your existing prior authorization workflow is a useful stress test here: whatever process handles authorization today is exactly what will absorb the gap if a new platform can’t answer these eight questions.

blueBriX is built specifically for behavioral health, with SUD workflows supported as a core use case rather than layered onto a general-purpose EHR. Its approach is configuration-driven rather than a fixed ASAM module:

• ASAM-aligned assessment and treatment workflows: ASAM score assignment, referral routing, and treatment planning are configured through blueBriX’s program management engine, referral engine, and treatment plan builder. For SUD programs, these components can be configured into an end-to-end ASAM-aligned workflow with minimal setup. Each level of care can be modeled as its own program, with enrollment criteria, care-team structure, authorization requirements, and billing strategy defined at the program level.
• Level-of-care transitions: Transitions between levels of care can be tracked through blueBriX’s care coordination capabilities. Because treatment plans can be linked to the specific program and subprogram in which a patient is enrolled, clinical documentation can carry forward across transitions rather than requiring a new treatment record.
• Part 2 and data segmentation: blueBriX is FHIR R5-native. For 42 CFR Part 2, SUD records can be partitioned at the program level through the platform’s access-control layer (ACL, RBAC, and ABAC). This enables SUD information to be governed separately from general clinical records and subject to Part 2’s authorization requirements before disclosure, rather than relying on general HIPAA permissions alone.
• Human-in-the-loop AI: blueBriX’s AI orchestration layer is designed around clinician oversight. AI can identify gaps such as incomplete dimensional documentation or an approaching concurrent-review deadline, but it does not independently make or commit clinical decisions. The clinician retains decision authority over every entry in the record.