Why electronic prior authorization won’t be fixed by an API alone
Standards are converging ahead of 2027, but success will depend on whether orders, appointments, clinical data and staff responsibilities work together in actual care settings.
Prior authorization remains one of healthcare’s most consequential administrative controls, intended to balance timely access to care with clinical and financial oversight. But implementing an API that complies with new federal requirements does not guarantee that clinicians, administrative staff or patients will experience a process that works better.
An application programming interface can carry a request from one system to another. It cannot determine whether the organization has the right information at the right point in its workflow, whether a clinician should be interrupted during order entry or whether an authorization team will still need to open a payer portal to finish the job. That is the distinction the industry has to keep in view as electronic prior authorization moves from standards development toward production use.
The CMS rule requires specified impacted payers to implement FHIR-based Prior Authorization APIs generally beginning January 1, 2027, with exact compliance dates varying by payer type. Some related operational requirements, including decision timeframes and public reporting of prior authorization metrics, began in 2026. Separately, the Medicare Promoting Interoperability Program’s Electronic Prior Authorization measure will be an optional bonus measure for eligible hospitals and critical access hospitals in calendar year 2027 and becomes mandatory beginning with the 2028 EHR reporting period.
Those timelines are creating necessary momentum, but a compliance date and a usable workflow are not the same thing. If electronic prior authorization is going to reduce burden and help patients move from a clinical decision to the next step in care more quickly, the industry has to test the complete workflow rather than only the transaction.
Standards alignment gives the industry a clearer target
For several years, organizations implementing electronic prior authorization faced a version-alignment problem. EHR developers, payers and provider organizations could make reasonable implementation decisions at different moments and still end up building against different releases of the same Da Vinci implementation guides. That made conformance testing harder and created uncertainty about which combination of specifications would become the durable national target.
The technical target is now clearer. In the FY2027 IPPS final rule, federal health IT policy adopted updated versions of three Da Vinci implementation guides effective October 1, 2026: CRD 2.2.1 for Coverage Requirements Discovery, DTR 2.2.0 for Documentation Templates and Rules, and PAS 2.2.1 for Prior Authorization Support. ONC also approved those versions through the 2026 Standards Version Advancement Process, allowing certified health IT developers to move to them ahead of broader certification transitions.
The three guides support different parts of the process. CRD allows the provider system to discover coverage requirements associated with a proposed service; DTR enables payer documentation requirements to be expressed in a computable, context-specific form so the provider can supply the needed information; and PAS supports submission of the authorization request and the payer response. Together they provide a more coherent path from discovering that authorization is needed to assembling documentation and receiving a decision.
That alignment matters because it gives payers, developers and providers a common reference point for development, certification, testing and deployment. It does not mean the specifications are finished: the current CRD, DTR and PAS implementation guides remain standards for trial use, and their own documentation anticipates continued refinement through implementation feedback, Connectathons and early production experience.
A specification can define how systems exchange information, but it cannot settle every operational question. Once the technical versions align, the hardest work shifts toward deciding when a workflow should fire, who is responsible for responding, what information is actually available at that moment and how exceptions are handled without recreating manual burden.
The hardest problem may begin before the request
Electronic prior authorization is often described as a clean sequence: a clinician places an order, the EHR determines whether authorization is required, the necessary documentation is collected and the payer returns a decision. Actual care delivery is not always that orderly, because the information required for one step may not exist until a later step has already occurred.
In our work, we have encountered a basic timing problem. A payer may need the servicing organization, performing clinician, location or appointment date before it can determine whether a service requires authorization or before it can render a complete decision. The provider organization, however, may not choose the servicing site or book the appointment until it knows whether the service will be authorized.
A person working in a portal can sometimes bridge that gap through local knowledge and judgment. Staff may know where a patient is likely to receive an MRI, which facility normally performs a procedure or which clinician is likely to take responsibility. An automated workflow can act only on information the system actually has. If the required data are created by scheduling, but scheduling is waiting on authorization, automation can expose the circular dependency without resolving it.
There is a second question that is just as important: who should handle the interruption? MEDITECH manager of interoperability development Jason Vogt has been deeply involved in this work through the HL7 Da Vinci community and, in interviews for this series, has heard a consistent concern from EHR developers and provider organizations that clinicians do not necessarily want prior authorization prompts, coverage alternatives and documentation requests interrupting every ordering workflow.
That does not mean the information lacks value. In some specialty settings, completing documentation while the patient and clinician are together may produce the fastest decision; in an emergency department, during rounds or in another time-sensitive environment, forcing the same interaction could slow care and contribute to alert fatigue. Some organizations will want clinicians to complete portions of the process, while others will rely on centralized authorization teams or hybrid workflows.
The standards therefore need enough flexibility for organizations to place work where it can actually be completed. If every electronic prior authorization step is simply pushed into the clinician’s order-entry experience, the industry risks recreating payer-portal burden inside the EHR rather than eliminating it.
Transaction testing is not workflow testing
Connectathons and technical conformance testing have helped payers and health technology developers determine whether systems can send and receive the expected transactions. That work is essential, but a successful test message still does not tell us whether a health system can place the order, identify the correct coverage, collect the payer’s required information, route follow-up questions to the right person, receive a useful response and move the patient to the next care step without manual re-entry.
Vogt summarized the near-term need during our conversation as a willingness to “pause and react” to what organizations experience when products begin going live. That is an important distinction: implementation feedback should not be treated as evidence that the standards failed; it is part of the process of discovering where technically valid exchange collides with real scheduling, staffing and care-delivery constraints.
The industry would benefit from more reusable synthetic testing scenarios built around a consistent set of representative services, coverage situations, documentation requirements and payer responses. If each payer-provider testing relationship begins by negotiating different examples and expected results, teams can spend more time preparing the test than evaluating whether the workflow functions.
Measurement should follow the full authorization funnel rather than stop at the API response. Leaders need to know how many orders were evaluated for prior authorization, how many actually required it, how many received an electronic decision and how many still fell back to a payer portal, fax, phone call or manual questionnaire. They also need to know where the process stopped, what information was missing and how long the patient waited before the next care step could be scheduled.
Those measures reveal whether automation is removing work or merely moving it from one team to another. They also give standards developers, payers and EHR vendors more useful evidence about which implementation patterns work, where exceptions occur and which parts of future releases deserve the most attention.
Development calendars must reflect deployment reality
The industry also has to account for a practical difference between payer and EHR release models. A payer may deploy an API through a relatively centralized environment, while an EHR developer has to build and test the capability and then distribute or enable it across many customer environments. Provider organizations still need time to receive the update, configure local rules, test workflows, train staff and decide how responsibilities will be divided.
As Vogt observed during our conversation, a payer planning to make a production capability available shortly before a regulatory deadline may reasonably believe it is on schedule. The EHR developer and provider organizations waiting to conduct end-to-end testing against that capability may see the same timeline as too short to validate local workflows before the deadline arrives.
That is why the distinction between the payer requirements and the provider-side measure matters. The FY2027 rule makes Electronic Prior Authorization an optional bonus measure for eligible hospitals and critical access hospitals in 2027 and mandatory beginning in 2028. That additional runway should be treated as implementation time rather than waiting time, particularly for organizations that need multiple software upgrades, payer connections and workflow redesigns before they can attest successfully.
The goal is a learning system
One encouraging development is that CMS is explicitly organizing work around those implementation problems. Its acceleration initiative brought 29 early-adopter organizations—including health systems, EHR developers, physician practices, networks and digital health companies—into a cross-sector effort alongside major payers to address workflow, technical and operational barriers before the 2027 requirements take effect.
For me, that is the real opportunity. The initiative can create a feedback loop among the organizations developing standards, the payers implementing APIs, the technology companies integrating those capabilities and the staff responsible for using them in daily care. That moves testing beyond whether an endpoint responds and toward whether the patient receives a usable decision at the right time.
The industry should not wait for a perfect future specification before beginning. The better path is to align around the current standards, test them in production-like workflows, measure where manual work remains and use that evidence to improve the next release. Because CRD, DTR and PAS remain trial-use standards, the feedback from real implementations is not a detour from standards development; it is part of how those standards mature.
An API is an essential part of electronic prior authorization, but it is only the connection. Success will be visible when clinicians can order appropriate care without unnecessary interruption, authorization teams can work without navigating multiple disconnected payer portals and patients can move from a clinical decision to a scheduled service without avoidable uncertainty. The deadline can create motion, but the workflow will determine whether that motion becomes meaningful change.
Mike Cordeiro is Senior Director of Interoperability Market and Product Strategy at MEDITECH, where he focuses on interoperability products and services intended to improve patient and caregiver access to health information.