Electronic prior authorization can help a care team discover requirements, assemble information and send a request to a payer. Connecting those steps does not, by itself, mean a request has been approved. Under CMS’s US rule, the API response can be an approval, a denial with a reason, or a request for more information. CMS response requirements
An October interview with Epic’s value-based-care lead makes the workflow easier to picture. It also illustrates why a software standard, a live connection and a faster patient journey need different evidence.
Three labels describe different jobs
The interview discusses the Da Vinci workflow commonly described using Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support. Their abbreviations are CRD, DTR and PAS. They concern different parts of preparing and exchanging a request, rather than three separate approvals of care. Original Epic interview
| Workflow stage | The question it helps address |
|---|---|
| Requirements discovery | Does this proposed service need prior authorization, and what requirements apply? |
| Documentation | What information needs to accompany the request? |
| Request and response | How is the request submitted and the payer’s response returned? |
A useful electronic process can reduce the need to re-enter information or switch channels. That is an intended workflow benefit; it is not evidence that every payer has implemented the same functions or that every request will receive an immediate decision.
The rule and the implementation guides are different layers
CMS-0057-F requires defined groups of payers to provide API functions. Its summary describes a Prior Authorization API able to identify documentation requirements and support requests and responses, alongside other API policies for patient, provider and payer data access. CMS final-rule fact sheet
The same fact sheet separates required standards from recommended implementation guides. CRD, DTR and PAS appear in the recommended-guide list. Treating those three labels as the complete list of mandated API categories would conflate a workflow approach with the broader rule’s requirements.
This article does not assess a particular technical implementation against the standards. CMS’s published summary supplies the policy distinction; the interview supplies an attributed explanation of how the workflow is being used.
A deadline does not describe every payer or every policy
CMS says API development and enhancement requirements generally begin in 2027, while certain operational requirements began in 2026. Exact compliance dates vary by payer type. Its defined scope includes Medicare Advantage organisations, specified Medicaid and CHIP arrangements, and qualified health-plan issuers on federally facilitated exchanges; it is not a statement about every insurance product. Scope and timelines
The cited final rule also distinguishes medical items and services from drug prior authorizations. A later proposed policy should not be silently folded into that final-rule description. The current CMS FAQ explicitly identifies CMS-0062-P as a proposal when discussing possible reporting updates. Current FAQ
For a service team, these are reasons to identify the payer, policy and relevant date before interpreting a vendor’s broad “ready for 2027” statement. They are not a compliance determination for an individual organisation.
Missing information can appear after the clinical order
In the interview, Epic’s Ryan Bohochik describes a practical difficulty: the information available when a clinician places an order may differ from what becomes known during scheduling. A point-of-care requirements check may therefore not settle every later question.
He also describes different levels of payer readiness and reports early-adopter experiences of fewer administrative touches and fewer disrupted appointments. Those observations are attributed vendor accounts, without a common study population or comparator establishing a universal benefit. Implementation experience
Our insurance-verification explainer addresses a neighbouring task: checking insurance information does not answer every question about a particular service. Here, the distinction is between knowing the requirements, submitting adequate information and receiving the payer’s decision. Following those stages makes an implementation claim more specific; its effect on waiting, approvals and care still needs to be measured.