Implementing CMS-0057: Expert Answers to Your Top Questions

Last December, we partnered with WEDI to host a webinar featuring a large BUCA plan’s journey to CMS-0057 compliance. The session drew an engaged audience of health plan leaders, technical teams, and compliance professionals, all navigating the complexities of electronic prior authorization implementation.

The questions that came through the Zoom chat were exceptional. They revealed the real challenges organizations face as they move from theory to implementation: How do you handle bulk policies? What happens with delegated vendors? How much automation is actually achievable? These aren’t surface-level concerns; they’re the technical and operational questions that determine whether an implementation succeeds or stalls.

We’ve compiled the most insightful questions and our detailed responses into a comprehensive guide. Whether you’re in early planning stages or active implementation, these answers provide practical clarity on the path forward.

Understanding the Da Vinci Standards

What do CRD, DTR, PAS, and TEFCA mean?

Coverage Requirements Discovery (CRD) is the transaction format for provider systems to send a request to find out if a procedure requires prior authorization. Documentation Templates and Rules (DTR) is the transaction format for providers to receive a list of questions to answer and documents to send to get a prior authorization approved. Prior Authorization Support (PAS) is the transaction format for providers to send a prior authorization and receive the response from the payer.

TEFCA is the Trusted Exchange Framework and Common Agreement, a nationwide framework for information sharing created by the U.S. Department of Health & Human Services to remove barriers for sharing health records electronically among healthcare providers, patients, public health agencies, and payers. TEFCA establishes the standards these participants should use for communication by referencing Standard Operating Procedures and Implementation Guides. To support prior authorization workflows, TEFCA references the Da Vinci Burden Reduction IGs: CRD, DTR, PAS, and Clinical Data Exchange (CDex).

For payers, CMS-0057 requires support for electronic prior authorization using X12 and/or FHIR, and recommends the Da Vinci specifications. For providers, these APIs are also strongly encouraged by CMS, and support for these APIs is a requirement for Certified Electronic Health Record Software under HTI-2.

Does this approach provide the Utilization Management (UM) criteria at the point of care?

Yes. The intent of the Da Vinci Burden Reduction APIs is to allow the provider and their staff to receive immediate feedback about the criteria for procedures that may require prior authorization. Some criteria are managed within the payer’s UM system, while others are managed by delegated vendors. Delegated vendors have also begun to support the CRD/DTR/PAS transactions, using the same set of standards. This allows payers to host a single set of endpoints for providers to connect to.

With Itiliti Health’s PA Checkpoint™, payers have a single hub to manage the business logic of which procedures require prior authorization and which systems manage those policies. This means providers only need to connect their APIs once, and are no longer required to navigate a myriad of different web portals.

Policy Management & Digitization

What did the digitizing of policy look like? Are you speaking of entering information into a comprehensive policy management system or some preparatory interim step?

Yes, these policies are ingested by Itiliti Health as a comprehensive policy management system. The first step is to consolidate the policies across the payer organization’s systems into a single place. No matter the format (word documents, web pages, PDFs), these policies can be imported into Itiliti Health. After importing these documents, the policies are automatically broken down into their key components, preserving the original text, and organized to support long-term policy management.

Then, Itiliti Health helps users standardize the language used in policy requirements, algorithmically parsing the business logic from words into a computable structure. This process is deterministic and transparent, and we strongly believe that Generative AI should not be used during the creation of digital policies. Large Language Models are much better suited for the task of parsing unstructured data such as clinical notes submitted by a provider. Our Clinical Decision Assistant can help staff identify evidence of matching criteria.

How does your tool parse out bulk policies? Our policy and restrictions are arranged in a bulk PDF based on a line of business.

Itiliti Health can import policies from plain text, CSV, DOC/DOCX, PDF, or HTML/XML. When parsing policies, they are broken down into their component parts to make long-term maintenance easier for your staff. The parsing function in our systems is extremely flexible and easily configurable. If several policies share the same block of text, you can update that module and publish new versions of all the impacted policies simultaneously, instead of having to make the change in many different places.

Technical Implementation

What FHIR servers are you recommending to implement with Itiliti?

Itiliti Health functionality is compatible with all major FHIR servers, including cloud-native FHIR functionality provided by AWS and Azure. In our experience, many payers have already chosen FHIR servers that allow them to meet existing regulatory obligations such as Patient Access and Payer-to-Payer data exchange. Reach out to us for more details about the platforms used in our existing implementations.

Is the platform for this process all on the FHIR platform?

The inputs, outputs, and created artifacts are mostly represented by FHIR resources. However, FHIR alone cannot sufficiently describe the complex business logic driven by plan, policy, provider, and place-of-service. Our application code is implemented in AWS, and our application programming interfaces include both FHIR and customer-specific functionalities. For example, the custom tooling necessary to import your existing policies or communicate with your existing UM system would go beyond basic FHIR capabilities.

How does Itiliti Health identify whether a prior authorization service is inpatient or outpatient based on the information received from the provider’s EHR? This classification is critical for determining if a PA is required as part of the CRD workflow.

When the provider places the order, they may identify the location, category, and service. This information is transmitted as part of the CRD Request that their EHR submits to the payer. As an example, “ServiceRequest.Location.Type = 22232009 (Hospital)” could indicate to the payer that the procedure should be performed at the hospital instead of a surgical center. Additionally, the provider can simultaneously propose an admission with a matching expected start date alongside the procedure when a patient needs a longer recovery time. This allows the payer to authorize both the procedure and the admission within the same Prior Authorization Submission.

Workflow & Provider Experience

Did you involve providers in the provider portal and FHIR API rollout to encourage adoption? If so, how?

The provider portal was already in place for the plan we’ve referenced, and through the Itiliti Health initiative, the provider portal experience was enhanced. This means that the service is woven into an existing workflow. Providers using the web portal experienced a seamless transition into the faster, more capable user experience powered by Itiliti Health. The look-and-feel remained the same, but they can now experience an immediate authorization when their patient clearly meets the authorization criteria.

The web experience is powered by the exact same APIs that providers may also use from their EHR. Even the payer’s call center staff get the benefit of consistent, accurate responses from a centrally managed policy system. By coordinating with high-volume organizations, we can demonstrate the improvements to their workflow and immediately kick off adoption of the EHR’s native Prior Authorization APIs once their software vendor has provided the new capabilities.

It sounds like there are two primary intake channels: Itiliti’s provider portal or an EHR that has adopted FHIR APIs. Is one of these two channels seen as preferable or optimal? If so, which?

Integrating with the payer portals that providers are using today is a way to “meet them where they are” and provide immediate value on both sides of the prior authorization workflow. However, the best experience is made possible by native EHR integrations, where data from the patient’s chart can be automatically used to satisfy the qualification criteria for a prior authorization. A primary goal of burden reduction is to reduce the duplicate entry of previously documented clinical data.

Does this mean that providers see the response from the payer?

During the CRD step, providers can see whether a prior authorization is needed, and can be shown real-time feedback that impacts ordering decisions. For example, if a specific treatment alternative is covered by the patient’s policy, that’s something the provider needs to see. Most documentation requirements (including the questionnaires and attachments specified by DTR) are asynchronous tasks that can wait until after the encounter, and can be routed to both clinical and administrative staff to ease the burden on the ordering provider.

The provider does see the response from the payer in the channel they used to submit an authorization and also in the channels that are used by payers today. For instance, for a prior authorization submitted via EHR and FHIR, the provider will receive the response within the EHR and receive a letter in the mail, similar to the existing workflow.

Scalability & Managing Complexity

Is this large plan planning to use these APIs for all plans, including commercial, or focused on the Medicare Advantage and government plans?

Itiliti Health supports all lines of business, and this plan will apply the Prior Authorization APIs to all lines of business.

What about payers who manage multiple plans and delegated vendors?

Itiliti Health gives you a single place to manage policies across plans, provider networks, and delegated vendors. This way, providers only submit data to one set of endpoints. No more portal-itis.

What happens if a provider logs in later and gets a different answer? Could there be a mismatch between when they checked and when they submitted the claim?

Policies published in Itiliti Health are given an effective date, which we compare to the expected date of a procedure when the clinician places the order. When payers create or amend rules, they finalize those changes with an effective date at least 45 days into the future. The response about whether authorization is needed is given for the date the procedure is planned.

Also, the answer is accompanied by a Traceability ID that links the data in the request to the policy that answered it. If the patient’s scheduled date is altered, the clinician or their staff can electronically re-check coverage requirements.

Automation Potential & Data Limitations

Is Prior Authorization Support (PAS) only used during the final step?

Typically, PAS submissions are the last step of the workflow, when a provider or their staff have filled out the required questionnaires and attached the necessary documents. It’s also possible to shortcut to a Prior Authorization if all the necessary data is already present in the EHR. In this case, the CRD step can return an instant Prior Authorization Number (in FHIR, the PA is “satisfied”), and the patient can be scheduled for their procedure before they leave the clinic. Behind the scenes, Itiliti Health checks the criteria in the policy against the data available in the prefetch bundle, and can request that authorization directly from the Utilization Management system before sending it back to the provider’s EHR.

Many policies can’t be resolved with the available discrete data in the EHR. Does this mean that PAs can’t be fully automated?

It is true that many policies can’t be resolved with the available discrete data in the EHR, but there are provider tools that use AI to fill out questionnaires which then are fully automated in the PA decision. Even when a prior authorization is not fully automated, there are several ways that these APIs immediately begin to reduce the burden on both providers and payers.

In our experience, real-time feedback eliminates more than half of all prior authorization submissions, where today many practices submit PAs “just to be safe”. Of the remaining half, automation is possible for 50-70% of electronic submissions. As payers improve the language and criteria of their policies to better align with data in the EHR, even more of these submissions can be automated. On the provider side, the more discrete data that’s available in a patient’s chart, the more likely the payer will be able to algorithmically qualify the patient.

Our clients also see immediate value in using a baseline set of questionnaires that gather the routine data that apply broadly across policies. From there, it’s a gradual process to refine and update questionnaires to improve the likelihood of getting an exact answer from the patient’s data.

Is it sufficient to return a policy, or are questionnaires required for regulatory compliance?

Your compliance team can answer specifically for your organization’s requirements, but the high-level expectations described by CMS-0057 include faster turnaround times than is possible with current practice, even if you publish all your policies online. Our tools can help you build questionnaires that meet the basic data gathering requirements that support manual review, and in the long term, help you gradually adopt fully computable policies that are driven by EHR data wherever possible. It is required that the provider be able to submit a prior authorization within the PAS.

Ready to Discuss Your Implementation?

These questions reveal the depth of planning required for successful CMS-0057 implementation. Every organization faces unique challenges based on their existing infrastructure, policy complexity, and lines of business. If you’re working through similar questions about your own implementation timeline, we’re here to help.