Medical Prior Auth Compliance Engineering.
A payer’s implementation playbook for the federal medical prior authorization mandate. CMS-0057-F (Interoperability and Prior Authorization Final Rule, in force) and the medical-PA components of CMS-0062-P (Drug PA Proposed Rule, March 2026). FHIR PA APIs, the 7-day standard / 72-hour expedited windows, public reporting, the no-auto-deny architectural commitment — and what production compliance looks like.
CMS-0057-F is the federal Interoperability and Prior Authorization Final Rule (89 FR 8758, January 17, 2024). It mandates that affected payers — Medicare Advantage organizations, state Medicaid (FFS and MCO), CHIP (FFS and MCE), and QHP issuers on Federally-facilitated Exchanges — support four FHIR-based APIs (Prior Authorization, Patient Access, Provider Access, Payer-to-Payer), meet decision timeframes of 72 hours expedited and 7 calendar days standard, provide specific clinical denial reasons, and publish annual PA performance metrics starting March 31, 2026. CMS-0062-P (March 2026) extends the framework to drug PA and aligns QHP FFE timeframes effective October 1, 2027.
What CMS-0057-F requires today — and what CMS-0062-P will require next.
CMS-0057-F is in force. The Interoperability and Prior Authorization Final Rule (89 FR 8758, published January 17, 2024) is the operational floor for prior authorization at every affected payer in the United States. PA decision timeframes — 72 hours expedited, 7 calendar days standard — have been in effect since January 1, 2026. The first public PA performance metrics are due March 31, 2026, with annual reporting thereafter. The FHIR Prior Authorization API mandate takes effect January 1, 2027 for Medicare Advantage and Medicaid/CHIP Fee-for-Service.
CMS-0062-P extends the framework. The Drug PA Proposed Rule (issued March 2026, comment period open through mid-2026) introduces medical-PA-relevant provisions that affected payers must plan for now: QHP issuers on FFEs come into timeframe alignment (October 1, 2027); medical benefit drugs enter the FHIR Prior Authorization API (October 1, 2027); FHIR adoption under HIPAA Administrative Simplification elevates from discretionary alternative to required standard (24 months post-effective for covered entities). The CHIP-specific accommodations and small-plan extensions in CMS-0062-P expand the regulatory perimeter.
The architectural floor is no-auto-deny. Across CMS-0057-F, the CMS MA Final Rule, the WISeR Innovation Model, and state AI laws (Colorado SB24-205, California SB 1120), a consistent commitment has emerged: AI may auto-affirm; AI may not auto-deny. Every clinical non-affirmation must route to a licensed human reviewer with full evidence pre-assembled. This commitment cannot be retrofitted — it has to be wired into the substrate.
Production proof exists. Genzeon Platforms operates the only commercial AI Participant inside a CMS Innovation Center model in production today — the CMS WISeR Innovation Model, MAC JL (New Jersey), live since January 1, 2026. 15,000+ Medicare prior authorization cases processed in Q1 2026, at 100% three-day TAT compliance, with zero auto-denials issued. The deployment demonstrates the operational floor CMS-0057-F now sets for the broader payer ecosystem — running on a patent-protected substrate covered by twelve filed USPTO applications.
Note: this whitepaper covers medical prior authorization — non-drug PA under CMS-0057-F and the medical-PA components of CMS-0062-P. Pharmacy benefit drug PA (NCPDP SCRIPT ePA, Formulary & Benefit, Real-Time Prescription Benefit) is covered in a forthcoming companion whitepaper on Rx Prior Authorization.
The audience for this whitepaper is the leadership at affected payers responsible for delivering compliance: Chief Medical Officers, Chief Compliance Officers, VPs of Utilization Management, and the architecture and engineering leaders who will own the FHIR PA API build. The argument is operational: read it and the architectural choices required to engineer comprehensive medical PA compliance become explicit, with the regulatory citations behind each requirement.
The combined master timeline: 2026 through 2028.
The medical PA compliance timeline spans both CMS-0057-F (in force, the operational baseline) and CMS-0062-P (proposed, with proposed dates pending finalization). The combined view is the operational planning surface for affected payers. Pharmacy benefit drug PA dates are shown in this table for completeness but are out of scope for the body of this whitepaper.
| Date | Rule | Milestone |
|---|---|---|
| January 1, 2026 | 0057-F | Non-drug PA timeframes take effect: 72 hours expedited, 7 calendar days standard (reduced from 14) |
| January 1, 2026 | 0057-F | PA performance metric collection begins (CY 2025 data closes) |
| January 1, 2026 | 0057-F | Specific clinical denial reason requirement in effect (generic form language insufficient) |
| March 31, 2026 | 0057-F | First public non-drug PA metrics due (CY 2025) — recurring annually |
| ~Mid-2026 | 0062-P | Comment period closes; public comments under review |
| January 1, 2027 | 0057-F | FHIR PA API compliance deadline: Medicare Advantage organizations and Medicaid/CHIP Fee-for-Service programs |
| 2027 rating periods on/after Jan 1 | 0057-F | Medicaid managed care, CHIP managed care, QHP FFE FHIR APIs operational |
| March 31, 2027 | 0057-F | First API usage metrics due (Patient Access API only, CY 2026 data) |
| October 1, 2027 | 0062-P | QHP FFE non-drug PA timeframe alignment effective (7d standard / 72h expedited) |
| October 1, 2027 | 0062-P | Medical benefit drugs enter the FHIR Prior Authorization API |
| October 1, 2027 | 0062-P | Drug denial reason requirement (specific clinical reasons, not generic) |
| October 1, 2027 | 0062-P | Drug PA timeframes effective |
| October 1, 2027 | 0062-P | Updates to four APIs to surface drug-specific fields (status, dates, denial reason, dosage, documentation) |
| Pharmacy benefit, NCPDP track | 0062-P | NCPDP SCRIPT ePA mandate, F&B, RTPB — covered in forthcoming Rx PA whitepaper |
| 24 months post-effective | 0062-P | HIPAA FHIR adoption for PA — covered entities (X12 278 replacement track) |
| 36 months post-effective | 0062-P | HIPAA FHIR adoption — small health plans |
| 2028 (for CY 2027) | 0062-P | First drug PA metric reports; first expanded API usage metric reports |
The timeline matters as planning surface, not just compliance checklist. The January 1, 2027 FHIR PA API deadline is approximately seven months out from this whitepaper’s publication date. Most affected payers who have not started their FHIR PA API build are now in a compressed engineering window. The October 1, 2027 CMS-0062-P date adds a second wave of changes — QHP FFE alignment, medical-benefit drugs in the PA API, expanded API field requirements — that should be factored into the same FHIR PA API build rather than treated as a separate project.
The March 31 reporting gate is recurring. CY 2025 metrics were due March 31, 2026; CY 2026 metrics are due March 31, 2027; CY 2027 metrics are due March 31, 2028 with the first drug PA metrics layering in. Affected payers should treat the reporting pipeline as a first-class operational system, not a quarterly export, because the metrics it produces are publicly comparable and consumed by regulators, providers, and members.
Who’s impacted — and what CMS-0062-P expands.
CMS-0057-F established six payer categories within the federal medical PA framework. CMS-0062-P does not add new categories, but it expands the regulatory reach within several of them — particularly QHP FFE and CHIP — in ways that affected payers need to factor into 2026–2027 planning.
Medicare Advantage organizations
The primary target of CMS-0057-F. All MA organizations are subject to non-drug PA timeframes (in force), FHIR PA API (Jan 1, 2027), public reporting (recurring), and the no-auto-deny constraints carried forward from the CMS MA Final Rule. CMS-0062-P adds drug PA timeframes and the medical-benefit-drug FHIR PA API extension (Oct 1, 2027).
State Medicaid Fee-for-Service programs
Subject to non-drug PA timeframes, FHIR PA API (Jan 1, 2027), and public reporting. State Medicaid agencies have a 0062-P-specific extension option available through the annual Advance Planning Document process, which may extend the FHIR PA API compliance date for medical benefit drugs.
Medicaid managed care plans
Subject to non-drug PA timeframes (in force), FHIR PA API by 2027 rating periods on/after January 1, and public reporting. The rating-period alignment creates a per-plan effective date that varies by state but converges on calendar-year boundaries.
CHIP Fee-for-Service programs
Same compliance profile as Medicaid FFS under CMS-0057-F. CMS-0062-P adds CHIP-specific accommodations including the extension option through annual Advance Planning Documents. CMS-0062-P expands the rule’s reach within CHIP by clarifying drug PA, public reporting, and API field requirements for state CHIP agencies that previously operated under a less-defined federal floor.
CHIP managed care entities
Subject to FHIR PA API by 2027 rating periods. CMS-0062-P confirms that the medical PA framework applies to CHIP managed care entities on the same timing as Medicaid managed care, closing what was previously an ambiguous edge of CMS-0057-F.
QHP issuers on FFEs
Subject to FHIR PA API by 2027 rating periods on/after January 1. CMS-0062-P brings QHP FFE issuers into non-drug PA timeframe alignment with MA and Medicaid effective October 1, 2027 — 7-day standard, 72-hour expedited. This is a material change for QHP FFE issuers who previously operated under varying state-by-state timeframes. Engineering and operations should factor this date into the same FHIR build as the API mandate.
What this scope structure tells affected payers: the federal medical PA framework is consolidating. CMS-0057-F drew the perimeter; CMS-0062-P is closing the residual variation within it. CHIP and QHP FFE were the categories with the most variability under 0057-F; 0062-P removes that variability. A payer building one FHIR PA API system that targets the CMS-0057-F floor will be well-positioned to handle the 0062-P additions without architectural rework — provided the substrate was built to accommodate per-payer-type rule packs from the start, rather than coded against one payer type with assumptions baked into the application logic.
What CMS-0057-F mandates payers expose.
CMS-0057-F requires affected payers to support four FHIR-based APIs. Each carries specific implementation guides under the HL7 Da Vinci Project. CMS-0062-P adds drug-specific fields to all four, effective October 1, 2027.
-
Prior Authorization API — the CRD + DTR + PAS workflow.
The headline requirement. A FHIR-based workflow combining three Da Vinci implementation guides:
Da Vinci CRD— Coverage Requirements Discovery. The provider’s system queries the payer at the point of order to determine whether PA is required.Da Vinci DTR— Documentation Templates and Rules. The payer returns a FHIR Questionnaire matched to the relevant coverage policy; the provider’s system completes it with patient-specific data.Da Vinci PAS— Prior Authorization Support. The completed bundle (Patient + Coverage + ServiceRequest + DocumentReference + QuestionnaireResponse) is submitted via FHIR PAS for adjudication. The X12 278 response payload is preserved within the FHIR response.
Compliance date for MA and Medicaid/CHIP FFS: January 1, 2027. CMS-0062-P expands the PA API scope to include medical benefit drugs effective October 1, 2027.
-
Patient Access API — longitudinal patient data.
The Patient Access API surfaces USCDI v3 clinical data, claims, encounters, and (under 0057-F) PA information excluding drugs. Drugs covered under a medical benefit enter scope under CMS-0062-P (October 1, 2027). CMS-0057-F required Patient Access API by January 1, 2027; first API usage metrics on Patient Access were due March 31, 2027 for CY 2026 data.
-
Provider Access API — bulk and individual provider access.
Allows in-network providers with an active treatment relationship to retrieve patient data via FHIR Bulk Data Access. Patient opt-out required (the patient must be able to opt out of having their data made available via this API). Same January 1, 2027 / 2027 rating-period compliance pattern as the PA API.
-
Payer-to-Payer API — plan transition continuity.
When a patient changes plans, the prior payer must make up to five years of historical clinical data, claims, encounters, and PA information available to the new payer via FHIR — quarterly for concurrent coverage, episodically on plan switch. Under CMS-0057-F, denied PAs and cost-sharing data are excluded from the Payer-to-Payer transfer. CMS-0062-P adds drug PA information to the Payer-to-Payer scope.
All four APIs share technical standards: HL7 FHIR R4 (mandatory under 45 CFR 170.215), USCDI v3 (mandatory under 45 CFR 170.213), SMART App Launch 2.0.0, FHIR Bulk Data Access v1.0.0, and OpenID Connect Core 1.0 errata. The Da Vinci implementation guides (CRD, DTR, PAS, PDex, CARIN Blue Button, Plan-Net) are recommended under CMS-0057-F but not mandated as named standards in regulation — CMS-0062-P proposes elevating several of these to mandated HIPAA standards.
X12 enforcement discretion is changing. The HHS National Standards Group memo of February 28, 2024 established enforcement discretion for the HIPAA-mandated X12 278 standard when entities use FHIR-based PA APIs. CMS-0062-P proposes elevating FHIR to a HIPAA-mandated standard alongside X12 278 — eliminating the discretion and making FHIR a required administrative standard. Covered entities have 24 months post-effective to adopt; small health plans have 36 months. Payers building their FHIR PA API today should treat this as a forward-looking certainty, not an option.
What this looks like in production. The Healthcare Brain runs the FHIR Prior Authorization API in CMS Medicare today — specifically, the Da Vinci PAS, CRD, and DTR Implementation Guides on HL7 FHIR R4, with HIP One (the Reasoning Lobe) executing the coverage policy evaluation and the determination logic behind the API surface. Genzeon Platforms’ Healthcare Forward Deployed Engineers deploy the Healthcare Brain into payer environments and configure the four-API stack against the customer’s specific MA, Medicaid, CHIP, or QHP FFE compliance profile. The FHIR PA API is not a separate product; it is a CMS-0057-F-compliant surface that the Healthcare Brain exposes on top of the underlying agentic substrate.
72 hours expedited. 7 days standard. Specific reasons required.
CMS-0057-F’s most operationally significant provision is the decision-timeframe compression and the specific-reason requirement. These are in force today, applied to every affected payer for every non-drug PA decision.
Standard decisions: 7 calendar days. Reduced from the 14 calendar day baseline that most affected payers operated under previously. This is wall-clock time, not business days. A standard PA submitted Friday afternoon is due Friday of the following week.
Expedited decisions: 72 hours. For PA requests where waiting could seriously jeopardize the enrollee’s life, health, or ability to regain maximum function, the determination is due in 72 hours from receipt. Many affected payers previously operated on 24-hour or 48-hour expedited timeframes that exceeded the federal floor; CMS-0057-F set the floor at 72 hours but did not prohibit faster.
Specific clinical denial reasons. Generic form language (“does not meet medical necessity criteria,” “additional documentation required”) is no longer sufficient. The denial communication must identify the specific clinical criteria that were not met, reference the source policy, and (where applicable) describe what documentation would change the determination. The requirement is in effect since January 1, 2026.
What this means architecturally. A PA system that cannot trace its determination back to the specific clinical criteria that were evaluated, with per-criterion confidence and source-policy citation, cannot produce a CMS-0057-F-compliant denial notice. This is why the substrate matters: the audit trail has to be wired into the determination response, not retrofit as a separate explanation pipeline. A determination response that arrives without its citation chain is operationally incomplete under CMS-0057-F.
The March 31 gate, recurring annually.
CMS-0057-F’s public reporting requirement converts the rule from a compliance obligation into a reputational mechanism. Once a payer’s PA performance is published, it is comparable, measurable, and visible to providers, regulators, and members.
The first non-drug PA performance metrics were due March 31, 2026 for CY 2025 data. The reporting is annual and recurring. CMS-0062-P proposes adding drug PA metrics and expanded API usage metrics starting in 2028 for CY 2027 data, plus Patient Access API, Provider Access API, and Payer-to-Payer API usage metrics.
Required non-drug PA metrics under CMS-0057-F include percentage of PA requests approved at each stage, percentage denied at each stage, average and median time to decision, approval rate after appeal, denial rate after appeal, and breakdowns by service category. The metric specifications are detailed in 89 FR 8758.
Operational implication. Affected payers should treat the reporting pipeline as a first-class system, not a quarterly export job. The metrics consumed by the reporting need to be sourced from the same audit ledger that drives the per-determination citation chain. A payer with a clean substrate has a single source of truth for both the per-determination defensibility and the aggregate reporting. A payer with a fragmented audit stack will be reconciling reporting outputs against operational logs every quarter, with regulatory risk on any reconciliation gap.
AI can affirm. Humans — supported by AI — decide non-affirmation.
Across CMS-0057-F, the CMS MA Final Rule, the WISeR Innovation Model, and state AI laws, a consistent commitment has emerged: AI may auto-affirm; AI may not auto-deny. Every clinical non-affirmation must route to a licensed human reviewer with full evidence pre-assembled. This is the most consequential architectural decision in a CMS-0057-F-compliant PA system.
The regulatory basis. The CMS MA Final Rule (Calendar Year 2024 Medicare Advantage and Part D Final Rule) clarified that AI alone cannot be the basis for an adverse determination on a Medicare Advantage coverage decision. The clinician of record must make the final determination on coverage and medical necessity. The CMS WISeR Innovation Model carries the same prohibition forward into the federal innovation pilot context. Colorado SB24-205 requires algorithmic decision systems used in consumer-facing decisions, including health coverage, to operate with human review. California SB 1120 establishes that AI cannot be the final word on health coverage determinations.
What the commitment does architecturally. Every clinical agent’s output is one of three classes: affirm (with auto-affirmation permitted under confidence thresholds), partial-affirm (some service lines affirmed, others routed to clinical review), or non-affirm (always routed to a licensed human clinical reviewer). The reviewer’s role is not to rubber-stamp the agent; it is to make the determination, with the agent providing the evidence package, the unmet criteria, the source policy citation, and the confidence breakdown.
What it does not do. The commitment does not eliminate AI from the determination loop. It does not require humans to make every determination from scratch. It does not slow throughput — affirmations are still automated at machine speed. It does not reduce the auto-affirmation rate — the affirmation pathway is independent of the non-affirmation pathway. What it does is structurally enforce the clinical-trust loop: when a patient is denied coverage, the reason is grounded in a human clinical judgment, with the AI providing the evidence and the citation, not the verdict.
Why architectural enforcement matters. A policy that says “humans review denials” is breakable under operational pressure. An architecture that prevents the system from issuing a denial without a human signature is not. The substrate has to enforce the constraint at the schema level: the determination response cannot serialize as a denial without a non-empty reviewer_attestation field. The CI pipeline tests this on every pull request. The audit trail proves it on every case.
The no-auto-deny enforcement is a filed patent claim. The mechanism by which the substrate structurally prevents adverse determinations from being serialized without an attested human reviewer signature — the schema-level enforcement, the dependency-injection audit, the CI gate — is covered under the service-oriented agent architecture portfolio (PA8-Core) and the horizontal pre-screening portfolio (PA-GATE), both filed with USPTO in March 2026. Policy-enforced no-auto-deny and architecturally-enforced no-auto-deny are not equivalent compliance postures, and they are not equivalently defensible at audit. The IP layer reflects that distinction.
What the proposed rule changes for medical PA.
CMS-0062-P is best known for its drug PA provisions, but it carries several medical-PA-relevant changes that affected payers need to plan for now. This section covers the medical components only; pharmacy benefit drug PA (NCPDP track) is the subject of a forthcoming companion whitepaper.
(1) QHP FFE timeframe alignment. CMS-0062-P proposes bringing Qualified Health Plan issuers on Federally-facilitated Exchanges into alignment with the MA / Medicaid medical PA timeframes: 7 calendar days standard, 72 hours expedited, effective October 1, 2027. This is a material change for QHP FFE issuers who currently operate under varying state-by-state timeframes. The architectural implication is straightforward: the substrate needs to accept QHP FFE as a payer-type axis distinct from generic commercial, with its own decision-timeframe configuration, its own rule-pack inheritance, and its own reporting profile. Payers building the FHIR PA API today should add QHP-FFE-aware rule packs to the same engineering sprint.
(2) Medical benefit drugs enter the FHIR PA API. Effective October 1, 2027, medical benefit drugs — the drugs administered in the clinical setting and billed under the medical benefit, distinct from pharmacy benefit drugs administered through dispensing pharmacies — come into scope of the FHIR Prior Authorization API. The Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support workflow that applies to non-drug services now applies to medical benefit drugs. The Patient Access, Provider Access, and Payer-to-Payer APIs must surface medical benefit drug PA fields: status, approval/denial date, authorization end date, approved drug and dosage, denial reason, and structured documentation.
(3) HIPAA FHIR adoption for PA. CMS-0062-P proposes elevating FHIR-based PA workflows from a discretionary alternative to a HIPAA-mandated standard. The current X12 enforcement discretion (HHS NSG, February 28, 2024) phases out. The compliance timeline is 24 months post-effective for covered entities and 36 months post-effective for small health plans. Affected payers building the FHIR PA API for CMS-0057-F compliance are positioned to absorb this change without an additional system; payers using FHIR only as a CMS-0057-F compliance veneer over an X12 278 core will need architectural rework.
(4) Updates to the four APIs — drug fields. All four CMS-0057-F APIs (PA, Patient Access, Provider Access, Payer-to-Payer) gain drug-specific field requirements effective October 1, 2027 for medical benefit drugs flowing through the PA API track. The field requirements include PA status, approval/denial date, authorization end date, approved drug(s) including dosage, denial reason, and structured clinical and administrative documentation. Payers extending their PA API to medical benefit drugs need to ensure the surrounding APIs surface these fields consistently.
(5) Public reporting expansion. CMS-0062-P proposes adding drug-specific PA metrics to the recurring reporting pipeline starting in 2028 for CY 2027 data, plus expanded API usage metrics covering Patient Access, Provider Access, and Payer-to-Payer (the CMS-0057-F reporting required Patient Access API usage metrics first, due March 31, 2027 for CY 2026 data). The reporting infrastructure is additive; payers with a clean audit ledger feeding their CMS-0057-F reports can absorb the 0062-P additions without a separate pipeline.
What CMS-0062-P does not change for medical PA. The decision timeframes for MA, Medicaid, and CHIP remain at 7 days standard / 72 hours expedited. The no-auto-deny architectural commitment carried forward from the CMS MA Final Rule and the WISeR Innovation Model continues to apply. The four FHIR APIs remain the operational structure. The public reporting cadence (March 31 recurring) remains.
What CMS-0057-F-compliant PA looks like in production.
Most regulatory analyses are paper exercises. CMS-0057-F has a live production proof: the CMS WISeR Innovation Model, where Genzeon Platforms operates the AI Participant role for MAC JL (New Jersey) under federal three-day TAT, with the no-auto-deny commitment architecturally enforced.
The CMS WISeR Innovation Model — Wasteful and Inappropriate Service Reduction — is a CMS Center for Medicare & Medicaid Innovation (CMMI) program operating across six MAC jurisdictions since January 1, 2026. Genzeon Platforms is the AI Participant for MAC JL (New Jersey), partnered with Novitas Solutions as the Medicare Administrative Contractor. The model imposes constraints that match the CMS-0057-F operational floor: three-day TAT for standard determinations, mandatory human-in-the-loop on every non-affirmation, audit-grade traceability, public reporting readiness.
The numbers translate to the CMS-0057-F compliance floor as follows. 15,000+ Medicare PA cases in Q1 2026 demonstrates the substrate’s production capacity under federal regulatory observation. 100% compliance with the three-day TAT means every case completed inside the federal window, well inside the CMS-0057-F 7-day standard and 72-hour expedited windows. Zero auto-denials demonstrates the no-auto-deny architectural commitment held in production, under volume, under regulatory observation. <3 minute median agent decision latency on the auto-affirm path means PA turnaround orders of magnitude inside the federal windows, with the audit lineage that CMS-0057-F’s public reporting now requires.
The full case study covering the first 90 days of WISeR operations — volume, distribution by service category, operational lessons — is published at /research/case-studies/wiser. The substrate that runs WISeR is the same Healthcare Brain architecture documented in the companion whitepaper at /research/whitepapers/healthcare-brain-substrate — a patent-protected substrate covered by twelve filed USPTO applications with approximately 346 claims locked at priority dates, including the specific architectural mechanisms that enabled the WISeR production outcomes described above.
Build, buy, or coexist.
Affected payers have three implementation paths to CMS-0057-F and CMS-0062-P medical PA compliance. The choice depends on internal engineering capacity, existing UM vendor commitments, and the strategic value of in-house ownership.
Path A: Build in-house. Stand up an internal FHIR PA API team, author the rule packs, build the audit ledger, design the human-in-the-loop pathway. The investment is substantial — typically 18–30 months from a standing start to production for a mid-market plan — and the ongoing operational burden is significant. Best fit for very large plans with existing FHIR engineering capacity, a mature internal medical-policy operation, and strategic value in owning the substrate. One caveat: several core architectural patterns — agentic substrate coordination, atomic criteria decomposition, cross-context inference, deterministic gate decisioning, no-auto-deny architectural enforcement, multi-channel submission orchestration — are covered by filed patent claims under USPTO Customer #226167. An in-house build addressing comparable architectural ground should plan for IP review as part of the engineering scope.
Path B: Buy a full-platform compliance solution. License a substrate that handles the four APIs, the determination engine, the audit ledger, the human-in-the-loop pathway, and the public reporting pipeline as a single integrated system. Best fit for payers without existing FHIR engineering investment, or for payers who want to move quickly to a CMS-0057-F-compliant posture without diverting engineering capacity from competitive priorities. The Healthcare Brain is one such substrate; others exist in the market. Customers licensing the Healthcare Brain receive the architectural substrate and the underlying IP rights to operate it as part of the same engagement — the substrate and the patent portfolio are inseparable in the licensing relationship.
Path C: Coexist with existing UM partners. The most common path for payers with existing investments in UM vendors. Already running Cohere Health, Humata Health, eviCore, or Optum on parts of the utilization-management stack? The Healthcare Brain (or a comparable substrate) can sit in front of the existing workflow at the administrative pre-screening layer — eligibility verification (270/271), submission completeness checks, duplicate detection, document classification, coding accuracy checks — routing the cleanly-prepared cases through the existing criteria engine. Genzeon Platforms’ Healthcare Forward Deployed Engineers handle the integration work: wiring the Healthcare Brain substrate to both the FHIR PA API surface and the customer’s existing UM engine, calibrating the pre-screening rules to the customer’s clinical and operational KPIs, and operating the coexistence pattern customer-side. The substrate extends the stack rather than replacing it. The medical-necessity layer continues to run through the customer’s licensed criteria sets (MCG, InterQual, or the payer’s own coverage policies) under existing licensing agreements.
The coexistence path is often the right answer for payers who have invested significantly in an existing UM vendor but need to close gaps on CMS-0057-F-mandated capabilities — the FHIR PA API surface, the audit ledger, the public reporting pipeline, or the no-auto-deny architectural enforcement. The substrate provides those capabilities without disrupting the underlying medical-necessity engine the customer has been operating against.
The pharmacy benefit track: a forthcoming whitepaper.
CMS-0062-P’s pharmacy benefit drug PA provisions — NCPDP SCRIPT ePA, Formulary & Benefit (F&B) standards, Real-Time Prescription Benefit (RTPB) — are a substantial subject area deliberately excluded from the body of this whitepaper to keep the medical PA argument coherent. The pharmacy track has its own architecture, its own implementation guides, its own operational characteristics, and its own buyer audience (PBMs, pharmacy directors, formulary management leads).
For payers planning their CMS-0062-P response holistically, the operational truth is that medical PA and pharmacy benefit drug PA share a common substrate architecturally. The Healthcare Brain runs both: medical benefit drugs and non-drug services flow through the FHIR Prior Authorization API; pharmacy benefit drugs flow through NCPDP SCRIPT ePA. The same agentic substrate, audit ledger, rule-pack engine, and human-in-the-loop pathway serve both tracks. The forthcoming Rx whitepaper will document the substrate’s pharmacy benefit handling in detail; the architectural foundation is described in the companion whitepaper at /research/whitepapers/healthcare-brain-substrate.
Common questions on CMS-0057-F and CMS-0062-P medical PA.
How does CMS-0062-P extend CMS-0057-F for medical prior auth?
CMS-0062-P (Drug PA Proposed Rule, March 2026) extends CMS-0057-F in several medical-PA-relevant ways. QHP issuers on FFEs come into alignment with MA and Medicaid decision timeframes (7 days standard, 72 hours expedited) effective October 1, 2027. Medical benefit drugs are brought into the scope of the FHIR Prior Authorization API. Updates to the four APIs add drug-specific fields. FHIR is being elevated from a discretionary alternative to a HIPAA-mandated standard for PA (replacing the X12 278 enforcement discretion currently in effect). Pharmacy benefit drug PA components (NCPDP SCRIPT ePA, F&B, RTPB) are out of scope for this whitepaper and will be covered in a forthcoming dedicated Rx PA whitepaper.
Who is impacted by CMS-0057-F and the medical PA provisions of CMS-0062-P?
Six payer categories: Medicare Advantage organizations; state Medicaid Fee-for-Service programs; Medicaid managed care plans; state Children’s Health Insurance Program (CHIP) Fee-for-Service programs; CHIP managed care entities; and Qualified Health Plan (QHP) issuers on Federally-facilitated Exchanges. CMS-0062-P expands the regulatory reach by adding CHIP-specific accommodations and aligning QHP FFE non-drug PA timeframes with the MA / Medicaid floor.
What is the no-auto-deny architectural commitment?
The architectural commitment that AI never issues a clinical adverse determination unilaterally. Auto-affirmation is permitted; auto-denial is not. Every clinical non-affirmation routes to a licensed human clinical reviewer with full evidence pre-assembled. The commitment satisfies the CMS WISeR Innovation Model’s explicit prohibition on AI-only adverse determinations, the CMS MA Final Rule’s parallel prohibition for Medicare Advantage, and state AI laws (Colorado SB24-205, California SB 1120). It is architecturally enforced in the Healthcare Brain, not policy-enforced, and cannot be configured around.
What public reporting does CMS-0057-F require?
Affected payers must publish prior authorization performance metrics annually, beginning March 31, 2026 for CY 2025 non-drug PA. Required metrics include approval rate, denial rate, time-to-decision distributions, and appeal outcomes. CMS-0062-P proposes adding drug-specific PA metrics starting in 2028 for CY 2027 reporting, plus expanded API usage metrics. The public reporting is what converts CMS-0057-F from a compliance obligation into a reputational mechanism: payer performance is comparable, measurable, and visible to providers, regulators, and members.
What does production CMS-0057-F compliance look like?
Genzeon Platforms operates the only commercial AI Participant in a CMS Innovation Center model in production today, under the CMS WISeR program. Live since January 1, 2026 in MAC JL (New Jersey) with Novitas Solutions. Q1 2026 processed over 15,000 Medicare prior authorization cases at 100% compliance with the federal three-day turnaround standard. Sub-three-minute median decision latency on the auto-affirm path. Zero auto-denials issued. 42% clinical reviewer productivity gain. Every non-affirmation routed to a licensed human reviewer with full evidence pre-assembled. This is what the operational floor CMS-0057-F now sets for the broader payer ecosystem looks like in production.
What IP protection covers the Healthcare Brain substrate?
Twelve patents filed under USPTO Customer Number 226167, with approximately 346 claims locked at priority dates. All claims are assigned to Genzeon Corporation. The portfolio protects the architectural pattern itself (three-tier agentic coordination), the specific mechanisms inside it (atomic criteria decomposition, cross-context inference, dual verification gate, no-auto-deny enforcement, deterministic gate decisioning), and the supporting infrastructure (multi-channel submission orchestration, ambient agent integration, distributed threshold cryptography). The Agentic Knowledge Pack Specification (AKPS) is released as an open standard; the proprietary Pack Engine that executes it is patent-protected. Customers licensing the Healthcare Brain receive both the substrate and the IP rights to operate it. A payer planning an in-house build addressing comparable architectural ground should plan for IP review.
What if we already have a UM vendor like Cohere, Humata, eviCore, or Optum?
The Healthcare Brain (or any comparable substrate) can sit in front of an existing UM workflow at the administrative pre-screening layer — eligibility verification (270/271), submission completeness checks, duplicate detection, document classification, coding accuracy checks — routing the cleanly-prepared cases through the existing criteria engine. The substrate extends the stack rather than replacing it. The medical-necessity layer continues to run through the customer’s licensed criteria sets (MCG, InterQual, or the payer’s own coverage policies) under existing licensing agreements. Integration with proprietary criteria sets is available where the customer holds an active license and the criteria publisher has authorized programmatic use.
How fast can a payer reach CMS-0057-F compliance with a substrate-based approach?
For payers building in-house from a standing start, the typical timeline is 18–30 months to a production-grade FHIR PA API surface, audit ledger, and human-in-the-loop pathway. For payers licensing a substrate (whether the Healthcare Brain or a comparable solution), commercial deployments outside federal regulatory contexts typically reach production in 12–16 weeks for cloud-native deployments and somewhat longer for sovereign on-premises. Genzeon Platforms went from CMS WISeR contract award to live Medicare prior authorization production in approximately six months, with full federal regulatory oversight in place.
When does CMS-0057-F take effect?
CMS-0057-F became effective in stages. January 1, 2026: PA decision timeframes (72 hours expedited, 7 calendar days standard), specific clinical denial reasons, and metric collection in force. March 31, 2026: first public non-drug PA performance metrics due for CY 2025 (recurring annually). January 1, 2027: FHIR Prior Authorization API compliance deadline for Medicare Advantage and Medicaid/CHIP Fee-for-Service. 2027 rating periods on/after January 1: Medicaid managed care, CHIP managed care, and QHP FFE FHIR APIs operational. March 31, 2027: first Patient Access API usage metrics due for CY 2026.
What are the CMS-0057-F PA decision timeframes?
CMS-0057-F sets two PA decision timeframes for affected payers. Expedited: 72 hours (3 calendar days) from receipt for PA requests where waiting could seriously jeopardize the enrollee’s life, health, or ability to regain maximum function. Standard: 7 calendar days (reduced from the prior 14-day baseline) for routine PA requests. Both timeframes are wall-clock time, not business days. The timeframes have been in effect since January 1, 2026. CMS-0062-P aligns QHP FFE issuers to the same timeframes effective October 1, 2027.
Is FHIR mandatory under CMS-0057-F?
Effectively yes. CMS-0057-F requires affected payers to support four FHIR-based APIs (Prior Authorization, Patient Access, Provider Access, Payer-to-Payer) using HL7 FHIR R4 as the mandatory technical standard under 45 CFR 170.215. The HHS National Standards Group memo of February 28, 2024 established enforcement discretion for the legacy X12 278 standard when entities use FHIR-based PA APIs. CMS-0062-P proposes elevating FHIR to a HIPAA-mandated administrative standard, with 24-month and 36-month adoption timelines for covered entities and small health plans respectively.
Are any payers exempt from CMS-0057-F?
The major non-impacted categories are Medicare Fee-for-Service (administered directly by CMS via MACs), commercial fully-insured plans not on FFEs, and self-insured ERISA plans. The CMS-0057-F regulatory perimeter is: Medicare Advantage organizations, state Medicaid Fee-for-Service, Medicaid managed care, CHIP Fee-for-Service, CHIP managed care entities, and QHP issuers on Federally-facilitated Exchanges. CMS-0062-P does not change this perimeter directly but adds CHIP-specific accommodations and brings QHP FFE issuers fully into PA timeframe alignment.
What PA metrics must payers publish under CMS-0057-F?
Affected payers must publish prior authorization performance metrics annually, recurring. The first non-drug PA metrics were due March 31, 2026 for CY 2025. Required metrics include: percentage of PA requests approved, percentage denied, average and median time to decision, approval rate after appeal, denial rate after appeal, and breakdowns by service category. CMS-0062-P proposes adding drug-specific PA metrics starting in 2028 for CY 2027, plus expanded API usage metrics covering Patient Access, Provider Access, and Payer-to-Payer.
What is the difference between CMS-0057-F and CMS-0062-P?
CMS-0057-F is a final rule (89 FR 8758, published January 17, 2024). It is the operational baseline for medical (non-drug) prior authorization. CMS-0062-P is a proposed rule issued in March 2026, extending CMS-0057-F to cover drug prior authorization plus several medical-PA-relevant provisions. The medical-PA components of CMS-0062-P include QHP FFE timeframe alignment, medical-benefit drugs entering the FHIR PA API, FHIR adoption under HIPAA, and updates to the four APIs for drug fields. The pharmacy-benefit drug PA components (NCPDP SCRIPT ePA, F&B, RTPB) are out of scope for this whitepaper.
When is the FHIR Prior Authorization API mandatory under CMS-0057-F?
The FHIR Prior Authorization API mandate takes effect January 1, 2027 for Medicare Advantage organizations and Medicaid/CHIP Fee-for-Service programs. For Medicaid managed care plans, CHIP managed care entities, and QHP issuers on FFEs, the deadline is 2027 rating periods on or after January 1 — meaning per-plan effective dates that vary by state but converge on calendar-year boundaries. Affected payers should plan their FHIR PA API build to land production-ready by the earliest applicable date for their category.
Does the X12 278 enforcement discretion still apply?
Yes, for now. The HHS National Standards Group memo of February 28, 2024 established enforcement discretion for the HIPAA-mandated X12 278 standard when entities use FHIR-based PA APIs. This means payers using FHIR for PA submission do not face HIPAA enforcement action for not supporting X12 278 in parallel. CMS-0062-P proposes changing this by elevating FHIR to a HIPAA-mandated standard, eliminating the discretion structure. The timeline is 24 months post-effective for covered entities, 36 months for small health plans. Payers building today should treat FHIR-as-mandated as the forward-looking certainty.
What is the penalty for CMS-0057-F non-compliance?
CMS-0057-F non-compliance creates several distinct exposure surfaces. Direct regulatory action: CMS may apply civil monetary penalties, contract sanctions for Medicare Advantage organizations, and contract terminations in severe cases. Reputational exposure: the public reporting requirement converts non-compliance into a publicly visible metric, comparable across payers, consumed by regulators, providers, and members. Operational exposure: non-compliant PA processes that delay determinations beyond the 7-day standard or 72-hour expedited window expose payers to provider and member complaints, state insurance commissioner attention, and litigation risk. CMS is expected to publish specific enforcement guidance as the public reporting cycle matures.
Citations.
- CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). Federal Register, Vol. 89, No. 27, p. 8758, January 17, 2024.
89 FR 8758. Published at federalregister.gov. - CMS Interoperability Standards and Prior Authorization for Drugs Proposed Rule (CMS-0062-P). Issued by CMS, March 2026. Comment period open through mid-2026.
- HHS National Standards Group Memo on X12 278 Enforcement Discretion. February 28, 2024. Establishes enforcement discretion when entities use FHIR-based PA APIs.
- CMS WISeR Innovation Model. Wasteful and Inappropriate Service Reduction Model. CMS Center for Medicare & Medicaid Innovation (CMMI). Operational since January 1, 2026 across six MAC jurisdictions. See CMS Innovation Center.
- CMS MA Final Rule (CY 2024 Medicare Advantage and Part D Final Rule). Federal Register, Vol. 88, No. 73, April 12, 2023. Establishes that AI alone cannot be the basis for an adverse determination on Medicare Advantage coverage decisions.
- HL7 FHIR R4 Specification. Health Level Seven International. R4 release. hl7.org/fhir/R4. Mandated under 45 CFR 170.215.
- USCDI v3. United States Core Data for Interoperability, Version 3. Office of the National Coordinator for Health Information Technology. Mandated under 45 CFR 170.213.
- HL7 Da Vinci Project Implementation Guides: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), Prior Authorization Support (PAS), Patient Data Exchange (PDex), CARIN Blue Button, Plan-Net.
- X12 N HIPAA Standards. X12 270/271 (Eligibility and Benefit Inquiry and Response), X12 278 (Health Care Services Review Information). HIPAA Administrative Simplification.
- Colorado SB24-205. Consumer Protections for Artificial Intelligence. Effective 2026.
- California SB 1120. Health Care Coverage: Utilization Review. Establishes that AI cannot be the final word on coverage determinations.
- Genzeon Platforms WISeR Case Study. The First 90 Days on the Record. Published at genzeon.one/research/case-studies/wiser.
- Genzeon Platforms Healthcare Brain Substrate Whitepaper. The Architecture Powering Production Healthcare AI. Published at genzeon.one/research/whitepapers/healthcare-brain-substrate.
Read the production proof.
The CMS WISeR Innovation Model is the operational test of the architecture this whitepaper describes. The case study covers the first 90 days — volume, distribution by service category, and operational lessons.
Read the WISeR case study →Talk to the payer team.
A 30–45 minute conversation with the senior compliance and engineering leads running CMS-0057-F-compliant PA in production. Bring a regulatory scenario, a build-vs-buy question, or a pilot shape you want to test.
Schedule a conversation →