Behavioral health organizations that also operate as Medicaid managed care entities may face payer-level requirements, depending on their regulatory classification and state contracts. Phase 1 is already in force, and API requirements begin January 1, 2027. Traditional clinical EHRs typically weren't designed to carry either.
API requirements begin January 1, 2027, with exact compliance dates varying by payer type. For Medicaid and CHIP managed care, they apply to rating periods beginning on or after January 1, 2027.
Effective January 1, 2026. 72 hours expedited and 7 calendar days standard for covered non-drug items and services, plus a specific reason for every denial.
Posted on payer websites. Initial reports, covering calendar year 2025, were due March 31, 2026. Reporting repeats annually.
A separate, non-public annual report that began in 2026. Channels differ by payer type: Medicaid managed care plans report to their states.
January 1, 2027 (Da Vinci CRD, DTR, PAS recommended)
January 1, 2027 (Da Vinci PDex recommended)
January 1, 2027 (Da Vinci PDex recommended)
Some behavioral health organizations operate both as clinical service providers and as Medicaid managed care entities. Depending on their regulatory classification and state contracts, these organizations may be subject to CMS-0057-F requirements.
Organizations should confirm whether they qualify as impacted payers under the rule and determine which operational, reporting, and interoperability requirements apply to their programs.
Organization types that may be impacted, depending on classification and contract
CMS has not announced a delay of the 2027 API requirements. The only enforcement discretion CMS lists for the rule lets HIPAA covered entities use an all-FHIR Prior Authorization API without the X12 278 transaction. It is not a delay.
The FY 2027 IPPS final rule adopted updated health IT standards, including Da Vinci CRD 2.2.1, DTR 2.2.0, and PAS 2.2.1. Organizations preparing for CMS-0057-F should review these updates alongside the rule's required standards and recommended implementation guides to determine their impact on API development and compliance planning.
Proposed, not final. CMS-0062-P, released April 10, 2026, would extend electronic PA, shorter timeframes, and public reporting to drugs. Comments closed June 15. If finalized, it would build on the same API infrastructure CMS-0057-F requires.
For hospitals and CAHs, the FY 2027 IPPS final rule made the Electronic Prior Authorization measure an optional bonus in CY 2027 and required beginning in CY 2028. For MIPS clinicians, CMS has proposed the same approach, but that change is not yet final. Provider-based plans can feel pressure from both sides of the transaction.
Status reflects official CMS and HHS information as of October 19, 2026. Finalized requirements and proposed rules are labeled separately. Requirements vary by payer type and state contract.
Phase 1 has been in force since January 2026. Phase 2 adds three new FHIR APIs and expanded requirements for the existing Patient Access API, beginning January 1, 2027, with exact compliance dates varying by payer type.
Decision timeframes apply to covered non-drug items and services for applicable impacted payers, subject to payer-specific exceptions. QHP issuers on the FFEs are excluded from the timeframe requirements.
If your organization is an impacted payer and your PA workflow is manual or EHR-only, gaps can surface in your required metrics.
CMS does not require payer API certification under these interoperability rules. Impacted payers are responsible for implementing, testing, monitoring, and maintaining APIs that meet applicable regulatory requirements.
Traditional behavioral health EHRs are built primarily to document and bill care from the provider side. CMS-0057-F asks impacted payers to make decisions, measure them, and expose payer data through standardized APIs. Some EHRs support FHIR, but payer-side APIs typically sit outside clinical system design and roadmaps.
FHIR support within an EHR does not necessarily establish compliance with CMS-0057-F's payer-side requirements.
| Requirement | Typical EHR coverage | Why |
|---|---|---|
| Clinical operations (not regulated by CMS-0057-F) | ||
| Clinical documentation, treatment plans, progress notes | Covered | Core EHR purpose |
| Scheduling and provider-side billing | Covered | Core EHR purpose |
| Phase 1: in force now | ||
| 7-day and 72-hour decision clocks for covered non-drug items and services | Often partial | Typically built around appointments and tasks rather than regulatory turnaround timers with escalation |
| Specific denial reason for every adverse determination | Often partial | Typically capture clinical rationale rather than structured payer denial reasons and notices |
| Public PA metrics reporting | Not typically native | Requires payer-side approval, denial, appeal, and turnaround data by service category |
| Phase 2: beginning January 1, 2027 (dates vary by payer type) | ||
| Prior Authorization API (payer side) | Not typically native | EHR workflows are typically built to submit requests, not to receive, decide, and answer them as a payer |
| Patient Access API with PA data | Not typically native | Requires member-facing claims, encounter, and PA decision data |
| Provider Access API | Not typically native | Requires payer attribution and cross-provider claims history |
| Payer-to-Payer API | Not typically native | Requires sending opted-in members' payer data, within a five-year date-of-service window, to another plan |
Coverage reflects typical behavioral health EHR design, not a universal limitation. Individual systems vary, and some functions may be met through additional payer systems or integrations. Confirm with your vendor using the questions below.
Each API requirement involves functionality that depends on payer-side data and infrastructure typically outside the scope of traditional clinical EHRs.
Members already access their claims, encounter data, and clinical information through apps they authorize. Beginning in 2027, payers must add prior authorization information, excluding drugs.
EHR gap: Traditional BH EHRs store provider-side clinical data. Serving member-facing payer data, such as claims and PA decisions, through a payer API endpoint is not typically native to them.
In-network providers with a treatment relationship can access a member's claims, encounter data, clinical data, and certain prior authorization information, excluding drugs. Patients can opt out of this sharing.
EHR gap: Traditional BH EHRs manage a provider's view of its own patients. Payer-side attribution, PA status, and cross-provider claims history are not typically native to them.
When a member who has opted in moves to a new plan, the prior payer makes available claims, encounter data, clinical data, and certain prior authorization information, excluding drugs, with dates of service within five years of the request.
EHR gap: Exchanging structured payer claims and authorization history with another payer may require additional payer systems, integrations, and consent and 42 CFR Part 2 controls that traditional EHRs don't typically provide.
The rule requires an API that identifies covered items and services requiring prior authorization and their documentation requirements, and supports electronic requests and responses: approvals with the date or circumstance under which the authorization ends, denials with a specific reason, or requests for more information. It gives providers an electronic alternative to fax and portal workflows.
EHR gap: EHR PA workflows typically sit on the provider side. A payer-side endpoint that applies coverage rules and returns structured decisions is a separate capability.
CMS-0057-F APIs serve claims, eligibility, attribution, and PA decision data. Those records typically live in payer systems rather than clinical charts.
Traditional EHRs are typically built to send authorization requests. The rule requires impacted payers to receive, decide, time, and report on them.
Sharing payer data with members, providers, and other plans requires consent handling and 42 CFR Part 2 controls designed for exchange, not internal care.
These questions help separate general FHIR support from payer-side CMS-0057-F capability.
Talk with the InfoMC team about your obligations under your state contract and where your current systems may fall short.
Complete the form or email us at info@infomc.com.