2027 Readiness Review: A Self-Audit Checklist for the API Deadline

Six months out from a regulatory deadline, the most useful thing a compliance lead can do is stop reading status reports and start demanding evidence. Status reports are green until they aren't; evidence is either on the table or it isn't. This article is a self-audit for the January 1, 2027 obligations under CMS-0057-F — organized the way an auditor would organize it, obligation by obligation, with the specific artifacts worth demanding in mid-2026 while there is still time to act on what you find.

Two framing notes before the checklist. First, scope: confirm which of your legal entities and products are impacted payers at all, and under which variant — Medicare Advantage, Medicaid managed care, CHIP, and QHP issuers on the FFEs carry meaningfully different obligations (QHPs, for instance, attach by plan year and escaped the 2026 decision-timeframe requirement). Walk each entity against the payer-type breakdowns — /cms-0057/medicare-advantage/, /cms-0057/medicaid-managed-care/, /cms-0057/chip/, /cms-0057/qhp/ — and write the entity-by-entity scoping down; it is the first thing a regulator will ask for and the thing most programs have never actually documented. Second, posture: "the vendor says we're on track" is not an audit answer for any line item below. Demos, data, and signatures are.

Obligation 1: the Prior Authorization API

The Prior Authorization API must let a provider determine whether an item or service requires prior auth, discover documentation requirements, submit the request, and receive the decision electronically. CMS recommends — does not mandate — the HL7 Da Vinci CRD, DTR, and PAS implementation guides, which is where the market has converged. Evidence to demand now:

• A live demo against production-shaped data. Not slideware: a request for a service your plan actually manages, flowing to a decision, with the denial path showing a specific reason. If the demo only shows approvals, ask why.
• The requirements-discovery content plan. The API's answer to "is auth required, and what documentation?" is only as good as the coded rules behind it. Who owns keeping that rule content synchronized with your UM policy, and what is the update SLA after a policy change?
• The dual-rail decision, in writing. The X12 278 remains the adopted HIPAA standard; HHS's enforcement discretion means a partner may transact entirely in FHIR but cannot be required to. Your intake architecture must run both rails — see why you need both — and the audit question is whether both produce one canonical request record with one clock.
• Trading-partner testing roster. Which EHRs, clearinghouses, and provider systems have committed test windows before January? An API nobody has tested against is compliance theater.

Obligation 2: Patient Access API — the PA-data enhancement

The Patient Access API you already operate must add prior authorization data — status and related information, excluding drugs — by January 1, 2027. Deceptively small; the data work is not. Evidence to demand:

• A data-completeness measure, not an assertion. What percentage of currently active authorizations — across your UM platform, delegated UMOs, and any carve-out vendors — can be rendered through the API today with correct status, dates, and services? If delegate authorizations are missing, your API will show members a partial truth, and delegates are where this always breaks — see delegation oversight after CMS-0057.
• Status-vocabulary mapping. The pended/approved/partially-approved/ denied lifecycle in your UM system must map deterministically to what the API serves. Demand the mapping table and who signed off on it.
• A member-experience walkthrough. Pull a real (test) member's PA history through a third-party app the way a member would. Does what the app shows match what the denial letter said? Mismatches here become complaints, then market-conduct questions.
• Usage-metrics continuity. Annual reporting of Patient Access API usage metrics to CMS began in 2026 — confirm the pipeline that produced this year's numbers survives the PA-data enhancement rather than being rebuilt around it.

Obligation 3: the Provider Access API

The Provider Access API must share claims and encounter data (excluding provider remittances and enrollee cost-sharing), USCDI data classes, and prior authorization information (excluding drugs) with in-network providers who have a treatment relationship — subject to attribution and patient opt-out. The hard parts are not FHIR; they are the two workflows around it:

• The attribution mechanism, demonstrated. How does your system establish that provider X has a treatment relationship with member Y, and what stops an in-network provider from reading members they don't treat? Ask to see a negative test — a request that is correctly refused. The design space is covered in who sees what under Provider Access.
• The opt-out flow, end to end. Where does a member exercise it, how fast does it propagate to the API, and where is the evidence it was honored? An opt-out that takes effect "at the next batch load" is a finding waiting for a date.
• Bulk-access readiness. Provider organizations will want their attributed panels, not one member at a time. Confirm the implementation and its performance envelope against your largest provider group's panel size.

Obligation 4: the Payer-to-Payer API

The Payer-to-Payer API exchanges the same data classes — claims and encounters (with the same exclusions), USCDI, and PA information excluding drugs — when members change payers or hold concurrent coverage, with a five-year lookback from the data request, opt-in patient permission, and a quarterly cadence for concurrent coverage. This is the API most dependent on business process, which is why it audits worst. Evidence to demand:

• The consent capture point. Opt-in permission has to be collected somewhere real — enrollment is the natural moment. Who asks, where is the answer stored, and how does the API check it per request? The operational detail is in consent, cadence, and enrollment data.
• Both directions tested. You are simultaneously a requesting payer (new members arriving) and a responding payer (members leaving). Demand a demonstration of each, including the five-year lookback boundary behaving correctly at its edges.
• Prior-payer identification workflow. To request data you must know the previous payer and reach their endpoint. What does enrollment capture today, and what happens when it captured nothing?
• Inbound-data governance. When another payer's authorization history arrives, does it inform your UM decisions (the rule's intent) or land in a table nobody queries? A written policy either way — this is exactly the kind of decision to document, per the closing section.

Re-verify the 2026 obligations while you're in there

A readiness review that looks only forward misses the obligations already generating exposure. Three re-verifications worth an afternoon each: pull a sample of Q2 expedited and standard determinations and check actual receipt-to-decision times against the 72-hour and 7-calendar-day clocks (and stricter state rules where they apply — the strictest-rule problem doesn't pause for API work); read ten actual denial notices for reason-specificity a provider could act on; and confirm the March 2026 public metrics report reconciles to source systems well enough that you could defend its definitions — the definitional traps are still there for the 2027 report.

Document the decisions, not just the deliverables

Every program makes judgment calls: which entities you scoped in, how you interpreted attribution, what "prior authorization information" includes for your product mix, which IGs you adopted and which you deferred, what your enforcement-discretion posture is on the 278. For each, keep a dated decision record — the question, the options, the rationale, the approver, and the rule-text or FAQ citation you relied on. When guidance later shifts or an examiner reads your implementation differently, the record is the difference between "reasonable interpretation, documented at the time" and improvising an explanation two years after the fact. Auditors forgive judgment calls; they do not forgive the absence of evidence that anyone made them.

Verify each obligation against the CMS-0057-F rule text (89 FR 8758), the CMS fact sheet and current FAQs, and — for the enforcement discretion — the February 2024 HHS National Standards Group letter.