January 1, 2027, is more than another compliance date. It marks a major change in how certain payers must exchange prior authorization information electronically. For organizations running Epic, the question is whether the technology will work when payer APIs become available, and whether the surrounding workflow will work with it.
Under the CMS Interoperability and Prior Authorization Final Rule, CMS-0057-F, impacted payers must implement and maintain a Prior Authorization API beginning January 1, 2027. The obligation falls primarily on payers, but providers can’t treat it as somebody else’s deadline. CMS is urging providers to work with their EHR vendors now, understand API capabilities, assess upgrade needs, and prepare teams for electronic prior authorization.
What Changes on January 1, 2027?
CMS-0057-F applies to Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid and CHIP managed care entities, and Qualified Health Plan issuers on Federally-facilitated Exchanges. It includes three new FHIR-based APIs (Provider Access, Payer-to-Payer, and Prior Authorization) and expands the existing Patient Access API.
For prior authorization, a transaction must communicate whether a request is approved, denied, or needs more information, and a denial must include a specific reason. These requirements cover medical items and services, not drugs. CMS has separately proposed drug-related requirements, which shouldn’t be confused with the finalized 2027 requirements.
Operational changes have already started. Many payers have been subject to maximum decision timeframes since 2026: 72 hours for expedited requests and 7 calendar days for standard ones. Technology readiness and operational readiness are now converging.
The pressure is real. CMS estimates its broader policies could save about $15 billion over 10 years. The AMA’s 2025 Prior Authorization Physician Survey found physicians and their teams handle an average of 40 prior authorizations per physician each week, consuming roughly 13 hours. Poorly designed digital workflows can easily preserve that burden in a new format.
Why Should Epic Prepare Early?
It’s tempting to assume the payer owns the deadline and you can wait for their connection. The CMS Electronic Prior Authorization guidance advises the opposite: talk to your EHR vendor about timelines, API integration, electronic prior authorization functionality, upgrades, testing, training, and payer pilots.
A payer can make an API available while a provider remains operationally unprepared to use it. Success requires Epic configuration, FHIR/API connectivity, payer readiness, authorization rules, clinical documentation, user workflow, exception handling, testing, and governance to come together. Miss one, and a technically successful interface may still create manual work.
The Workflow Is Bigger Than an API
Epic publicly supports HL7 FHIR APIs (see Epic’s public FHIR technical documentation), and CMS recommends the Da Vinci implementation guides for prior authorization: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS). The CMS API standards and implementation-guide guidance lays out which standards apply. But standards don’t automatically create a good workflow.
A clinician orders a service. Someone must determine whether authorization is required, gather the right clinical information, submit the request, and route the response to the right place. If more information is needed, someone must know what to do next. If the request is denied, the reason must reach a team that can act. If approved, the status must stay visible downstream. That isn’t one API call. It’s an end-to-end process.
Seven Areas Epic Should Validate Now
Current-state workflow
Start with how work happens today, not the future-state API. Document who determines whether authorization is needed, how documentation is gathered, which portals, faxes, or clearinghouses are involved, who handles additional-information requests and denials, and how scheduling learns the outcome. Existing manual workarounds won’t disappear just because an API connection exists.
Epic and API readiness
“Epic supports FHIR” isn’t a readiness assessment. Confirm which electronic prior authorization capabilities exist in your current environment, whether you need an upgrade or configuration change, which standards each payer will use, how authentication will work, where payer requirements will appear in the workflow, how responses return, and how API failures will be detected and routed.
Payer-by-payer readiness
The deadline is national, but implementation happens payer by payer. Build a readiness matrix tracking each player’s rule applicability, technical contact, API availability, standards, test environment, workflow scope, documentation and response behavior, exception process, production date, internal owner, and status (not started, validating, testing, ready, or blocked). This turns a vague discussion into an actionable record.
Documentation readiness
Digitizing a transaction won’t fix incomplete or hard-to-find information. Review what documentation is commonly required, where each data element originates, whether it’s structured, who completes it, whether the workflow can flag gaps before submission, and whether the same information is entered repeatedly. The goal is to reduce rework before the request reaches the payer, not just move today’s form online.
Exceptions, not just the happy path
A test that ends in an approval proves little. Test scenarios such as authorization not required, denial, requests for more documentation, missing or changed coverage data, duplicate submissions, payer timeouts, API outages, authentication failures, mismatched service information, expiration, and cancellations. Your Epic workflow needs an operational response to approvals, denials, and additional-information requests alike. A valid message in the wrong queue is still a failure.
Ownership before go-live
Prior authorization crosses IT, Epic analysts, clinical teams, patient access, revenue cycle, compliance, and payer relations. Define responsibility across the whole lifecycle (requirements, build, payer coordination, testing, training, monitoring, incident management, optimization) with a simple RACI so nobody assumes another group owns the exception. Virtelligence’s Epic consulting services can help with implementation, optimization, and integration planning.
Success measures
“The interface is live” measures deployment, not improvement. Baseline what you can: percent submitted electronically, manual portal and fax volume, incomplete request rate, additional-information requests, turnaround time, denial rate and reasons, resubmissions, exception volume, API error rate, scheduling delays, and staff touches per request. Start with measures you can capture consistently and add more over time.
Common Readiness Mistakes
- Treating 2027 as an integration-team project: Authorization touches documentation, scheduling, access, utilization management, and revenue cycle.
- Waiting for every payer to publish details: Workflow mapping, governance, documentation analysis, Epic assessment, and test planning can start now.
- Assuming every manual step disappears: Some payers will transition differently and some cases will still need review. Aim to reduce avoidable manual work while building a controlled path for legitimate exceptions.
- Testing only connectivity: A successful API response doesn’t prove the right person got the right information at the right time.
- Ignoring denials: CMS requires a specific denial reason, but that’s only useful if your workflow routes it to a team that can act. A 2026 HHS Office of Inspector General review found the Medicare Advantage organizations studied denied 12% of skilled nursing facility admission requests in June 2024, and 95% of appealed denials were overturned. That’s a specific context and shouldn’t be generalized, but it shows why denial follow-up deserves careful design.
Build a Cross-Functional Readiness Plan
Organize the work into five workstreams:
- Strategy and governance: define scope, executive ownership, and priority payers and workflows.
- Epic workflow and integration: assess configuration, validate FHIR/API capabilities, define response routing, and review security and monitoring. Don’t assume every capability is configured or production-ready. For broader healthcare integration and interoperability planning, Virtelligence can help.
- Payer coordination: build the payer matrix, identify testing partners, agree on test scenarios, and track blockers.
- Operational readiness: map roles, redesign handoffs, train users, and define downtime and exception processes.
- Testing and performance: build end-to-end and negative test cases, baseline metrics, and optimize using early findings.
A practical timeline: now, establish the baseline (governance, workflow mapping, Epic readiness, payer inventory). Next, move to external validation (payer outreach, test access, workflow design). Before production, test operations as well as transactions, including denials, error handling, training, and monitoring. After activation, measure adoption, exceptions, response times, and bottlenecks. October 2026 is late enough that discovery should move quickly.
What Leaders Should Do Next
Ask five questions:
- Do we understand our Epic prior authorization workflow end to end?
- Have we confirmed the Epic and integration capabilities our electronic workflow requires?
- Do we know the readiness status of our major payers?
- Have we tested denials, missing documentation, additional-information requests, and technical failures?
- Does every part of the future-state process have a named owner?
If any answer is unclear, there’s work to do before January. Virtelligence provides Epic implementation and optimization, integration and interoperability, healthcare IT advisory services, and project management to help organizations assess their environment and move toward a controlled implementation plan.
Conclusion
CMS-0057-F sets a clear January 1, 2027 requirement for payers, while CMS is already urging providers to prepare their EHR environments and workflows. For Epic organizations, the technical connection is only one part of the project. The best-positioned organizations will know how authorization works today, what Epic changes are needed, which payers are ready, where documentation comes from, how exceptions are routed, who owns each step, and how improvement will be measured.
Successful electronic prior authorization isn’t just about making systems exchange data. It’s about turning that exchange into a workflow people can actually use.
Frequently Asked Questions
What is the CMS prior authorization API deadline?
Under CMS-0057-F, impacted payers generally must implement and maintain the Prior Authorization API beginning January 1, 2027.
Does it apply directly to hospitals and health systems?
It primarily applies to payers, but providers must prepare because they’ll interact with payer APIs through EHR and administrative workflows.
Does it include prescription drugs?
No. The finalized requirements cover medical items and services. CMS issued separate proposed rulemaking in 2026 on drug prior authorization.
What standards are involved?
HL7 FHIR, with CMS recommending the Da Vinci CRD, DTR, and PAS implementation guides.
Does Epic support FHIR APIs?
Yes, but configuration, workflow, licensing, and production readiness must be validated for each organization’s environment.