The January 2027 API deadline is close enough that organizations should be testing real workflows, not simply reviewing technical plans.
By Vanessa Couch-Laguana, Head of RCM, LunaBill
On January 1, 2027, impacted payers must implement several application programming interface requirements under the CMS Interoperability and Prior Authorization Final Rule. The Prior Authorization API must make coverage and documentation requirements available and support a request and response for covered medical items and services. It must also communicate whether a request was approved, denied with a specific reason, or requires more information. Drug prior authorizations are excluded from these requirements.
For providers, October marks a practical 90-day readiness window. The question is no longer whether a payer or vendor has a technical plan. Revenue Cycle leaders need to know whether the transaction works inside the actual operational workflow.
Test the transaction from beginning to end
A successful connection is only the first step. Testing should begin with the ordered service, confirm whether authorization is required, identify the payer’s documentation requirements, submit the request, receive the decision, and place the result in the correct work queue and patient record.
Use real scenarios that include requests for more information, denials, changes in service, coverage changes, and cases that need a revised authorization. These exceptions reveal whether the workflow has a clear owner or simply moves the problem from one system to another.
Prepare for a mixed environment
The API requirements apply to specified Medicare Advantage, Medicaid, CHIP, and Federally Facilitated Exchange payers. They do not cover every payer, product, or drug authorization. Provider adoption will also vary. The 2025 CAQH Index found that implementation remained uneven, with many organizations still working through technology integration, resource limitations, and workflow design.
Teams should expect APIs, portals, faxes, and payer calls to coexist. A readiness plan must define which channel applies to each payer and service, along with the fallback when the electronic path fails.
Use automation to manage the gaps
Automation can determine the expected channel, monitor for a response, retrieve status from a portal, supplement follow-up with a payer call, and return the result to the work queue. It can also flag requests that are approaching the date of service or the payer’s decision deadline.
Human review should begin when the request involves clinical judgment, conflicting payer information, a changed service, a new coverage determination, or an adverse decision. The handoff should include the submitted information, payer response, timestamps, and prior follow-up so the reviewer can act without starting over.
Use October to establish a baseline
Before January, leaders should measure current authorization volume, turnaround time, manual touches, calls, portal checks, requests for additional information, denials, and missed service dates. That baseline will show whether the new workflow actually reduces administrative work or merely changes how it enters the organization.
A good readiness review produces clear answers: which payers are ready, which workflows have been tested, who owns each exception, and how the organization will continue operating when the electronic response is incomplete.
