Connecting the Dots: Technical Answers from Our WEDI Webinar (Part 2)

In September, we concluded our two-part WEDI webinar series on CMS-0057 implementation with a deep dive into the technical mechanics of integration. While Part 1 focused on foundational elements like policy management and delegated vendor coordination, Part 2 explored the practical challenges of connecting these systems: How do you handle error responses when patient data is missing? What’s the role of prefetch bundles in CRD requests? How does routing logic work when multiple vendors are involved?

These questions matter because successful implementation depends on understanding not just what the APIs do, but how they behave in real-world scenarios. The questions we received reflected this focus on operational details: technical architects and integration teams working through the specific mechanics of making these systems communicate effectively.

We’ve organized the most critical questions from Part 2 into this guide, providing detailed answers that address the connectivity challenges organizations face as they build out their electronic prior authorization infrastructure.

Understanding CRD Request Mechanics

Can you briefly talk about ‘error’ responses to a CRD request that isn’t a Yes/No/Pending? For example, if the patient can’t be found by the payer or isn’t covered by the plan information?

The Da Vinci Prior Authorization Implementation Guide incorporates the base CDS Hooks specification, which uses error code 412 when the requested prefetch information (such as a patient’s coverage) was not included in the CRD Request. The latest version of the Implementation Guide adds additional detail in the coverage-information to allow the payer to indicate “not covered” with a reason code of “no-member-found” (when the patient can’t be found) or “no-active-coverage” (when the patient is found, but does not have an active coverage).

I would like to understand the difference between CRD requests that use prefetch bundles or do not use them.

The CRD server defines the information that it requires in the prefetch as part of its discovery endpoint. The patient’s coverage resource, for example, should be included as part of the request so that the payer (and any routing intermediaries) know which Payer/Group/Plan/Member ID the request is for. (The latest version of the IG proposes making coverage a required prefetch element.) Additional prefetch data, such as a patient’s condition list, might be required by the payer. If it is, the provider’s request must include it, or the service will return HTTP 412.

Routing & Proxy Architecture

Does PA Checkpoint™ essentially act as a Networked FHIR proxy?

Yes, when a CRD, DTR, or PAS request should be handled by a delegated vendor, Itiliti Health acts as a routing service, and proxies the request to the appropriate destination based on the patient’s coverage, the requested procedure or service, and the plan’s rules. Because you need decision-making logic, PA Checkpoint™ is not just a proxy, but is also a rules engine to determine the route!

Is the flow to third party vendors easily interchangeable from Itiliti Health to the payer if the payer would like to proxy all transactions?

Yes, Itiliti Health’s prior authorization APIs can be hosted in front of or behind any other portion of your web service infrastructure, including proxies that support TLS. The intelligent routing on requests that should be routed to a delegated vendor will rely on Itiliti Health having some way to pass this requested destination to the third party.

Integration Standards & Vendor Coordination

Does Itiliti Health have a public API for delegated vendors or does each vendor require custom integration?

Like many others across the industry engaged in the development of standards for prior authorization, Itiliti Health and the delegated vendors we have worked with are following the guidance of the Da Vinci Prior Authorization Implementation Guides. The same data model, events, and security considerations apply whether a request is being served by a payer’s internal rules or the external services of a delegated vendor.

Workflow & Responsibilities

In your opinion, who holds the primary responsibility for initiating the prior authorization process, the physician requesting the service or the provider delivering the service? Additionally, how have you seen this responsibility typically handled at other organizations?

This decision is controlled by the EHR vendor and the provider. Our experience has shown that CRD can provide valuable feedback to both the ordering and performing providers. At the time of ordering, the CRD response can help inform a provider about the details of a patient’s coverage, which reduces the delay in obtaining a prior authorization (and can eliminate waiting periods for cases where no prior authorization is required). The DTR and PAS transactions may be most suitable for the administrative staff in the near future due to the probability that requiring the physician to perform those steps may be more burdensome. The specific implementation workflow for DTR and PAS will be decided by the EHR vendor or provider. For the performing provider, the Burden Reduction APIs not only enable real-time requests to the payer for a prior authorization, but also provide a reliable and consistent way for the provider to retrieve information about a previously issued prior authorization directly from the payer.

Is it correct to assume the questionnaire will be shown to the patient through the Provider EHR?

Questionnaires returned during DTR need information provided by the clinician or their administrative staff. Patient-facing questionnaires are not typically part of the prior authorization workflows supported by these APIs.

EHR Requirements & Timelines

When are EMRs required to support e-Prior Auths?

HTI-4 defines the certification requirements for EHRs as expanding to include these prior authorization APIs. The final rule took effect in October 2025, and indicates the functionality should be available on 1/1/27, just like the payer’s APIs.

From Architecture to Action

These questions from Part 2 reveal the technical precision required for successful implementation. Understanding error handling, prefetch requirements, routing logic, and certification timelines is foundational to building infrastructure that works reliably at scale.

[Download the complete Part 2 Q&A as a PDF]

If you’re navigating similar integration challenges or need clarity on how these systems connect in practice, our team is here to help.

Contact Steve McLeod at smcleod@itilitihealth.com or David Clickner at dclickner@itilitihealth.com to schedule a call with our team.