The Coordinated Care Washington ABA policy revisions 2026 announcement contains two effective dates. Its February provider news says WA.CP.BH.104 changed for Apple Health on March 1 and CP.BH.105 documentation requirements changed for Apple Health and Ambetter on May 1. The news item does not describe every revised requirement. Providers should compare the live policy versions and revision histories, then apply each change by product, service date, and request state.

Build two policy layers

WA.CP.BH.104 supplies the plan's ABA clinical policy for the named Apple Health scope. CP.BH.105 supplies ABA documentation requirements for Apple Health and Ambetter. Keep the policy identifiers, titles, products, revision dates, effective dates, service-date ranges, request types, and checked dates in separate rows. One policy's effective date should not activate the other layer.

Retrieve the live policies before configuring details

The news article announces revised policies without listing every changed sentence. Use the Coordinated Care forms and resources page and the plan's current policy library to retrieve the actual version. Save the PDF or stable record, revision history, effective date, product scope, and access date. Hold any field whose value cannot be traced to the operative document.

Name one policy custodian for acquisition and version control. Preserve the official filename, policy identifier, revision, download date, checksum or controlled copy, access terms, superseded version, and responsible approver. Give clinical, authorization, documentation, and billing users the version needed for their role. Avoid pasting policy fragments into uncontrolled templates that can outlive the source.

Compare revisions field by field

For WA.CP.BH.104, compare eligibility, clinical criteria, assessment, treatment plan, goals, dosage, provider qualifications, initial and concurrent review, codes, transition, and review rights. For CP.BH.105, compare authorship, signatures, service facts, treatment activity, data, protocol modification, telehealth, billing support, and retention. Mark each field unchanged, revised, removed, added, or unresolved.

Add the source section, product, service-date boundary, owner, system field, training change, test case, and rollback step for every revised item. Unknown values stay disabled. Preserve older rules while earlier authorizations, appeals, corrections, and claims remain open. A policy alert can start the review; activation requires the actual operative text and tested implementation.

Keep Apple Health and Ambetter configurations separate

The March change is described for Apple Health, while the May documentation update reaches Apple Health and Ambetter. Verify the member's product, benefit, contract, authorization, provider network, service date, and claim route. A rule observed on an Apple Health request cannot establish the Ambetter requirement, and an Ambetter claim result cannot establish the Medicaid configuration.

Preserve clinical and documentation authority

A qualified clinician owns assessment, plan authorship, recommendation, risk decisions, and any clinical correction within scope. Documentation rules define evidence expected for the payer route. Administrative staff can surface missing or conflicting evidence. They should not rewrite the clinical record after the service or alter goals and dosage to imitate a policy criterion.

Retain the person's direct input, accessible communication, required consent and assent, caregiver perspective, health information, and service feasibility. A payer criterion can guide a coverage submission while the clinical record explains the qualified recommendation. When the payer decision differs, preserve both, deliver the notice accessibly, and route any review or appeal through the applicable product process.

Test boundary cases before release

For WA.CP.BH.104, test an Apple Health request before and after March 1, an initial and concurrent request, and an in-flight authorization. For CP.BH.105, test Apple Health and Ambetter records before and after May 1, including telehealth, protocol modification, and a corrected claim. Verify policy selection, required evidence, portal or form, receipt, decision, claim release, and historical reconstruction.

Use synthetic or properly authorized minimum-necessary information. A passing test establishes configuration behavior only. It does not establish a real member's clinical fit, authorization, coverage, or payment.

Test requests and claims as different workflows

An authorization can meet a clinical policy while a later claim fails documentation, provider, code, unit, or submission requirements. A complete note cannot create coverage, authorization, claim acceptance, adjudication, or payment. Test initial request, concurrent request, service documentation, claim release, rejection, denial, correction, appeal, and recoupment as distinct episodes with their own evidence.

A fictional two-policy audit

Soren locks 25 configurations across Apple Health and Ambetter. Nineteen identify the right product, policy layer, version, effective date, clinical owner, documentation fields, authorization route, claim test, and recheck owner. Two March rows wrongly include Ambetter, two May rows use the earlier documentation version, one row lacks a live policy copy, and one merges authorization with claim release. Completeness is 19 of 25, or 76.0%.

Use a product-and-date checklist

Verify member and product, policy identifier, live version, effective period, service date, request state, clinical criteria, documentation requirements, provider and location, authorization form, submission route, receipt, claim guide, code and unit source, correction or appeal path, family communication, and recheck date. Preserve the provider-news item as the change alert while the operative policy controls each field.

Related resources

Sources