Why CRD is the starting point for seamless prior authorization

If prior authorization delays care, it’s usually because the process started without clarity. Missed requirements, incomplete documentation, and “please provide more information” responses stall approvals before they even begin.

That’s where Coverage Requirements Discovery (CRD) comes in. Developed under the HL7 Da Vinci project, CRD is a FHIR Implementation Guide designed to give providers real-time visibility into payer rules right inside their workflow.

It’s also the first step in the bigger picture of electronic prior authorization (ePA), which is built on three core capabilities: CRD, Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS).

Together, they form an end-to-end digital loop that makes approvals faster, more transparent, and easier to integrate into provider workflows. And under CMS-0057-F, CRD is where your compliance journey for prior auth should begin.

Why CRD comes first

CRD uses CDS Hooks to surface payer-specific coverage rules in real time. That means providers don’t need to leave their EHR to guess whether a service is covered or if prior authorization is required.

Instead, when a provider schedules an appointment, signs an order, or dispatches a service, CRD can tell them:

• If the service is covered
• Whether prior authorization is needed
• What documentation will be required later in the process

This early guidance prevents wasted time, reduces resubmissions, and sets the stage for smoother Documentation Templates and Rules (DTR) and Prior Authorization Support (PAS) later on.

The hooks payers must support

To conform to the CRD Implementation Guide, it’s mandatory to implement at least the primary hooks. These are the core integration points where your CRD service must respond with a Coverage Information response — even if that answer is simply, “more details are needed.” 

Primary hooks (mandatory):   

• Appointment Book
• Orders Sign
• Order Dispatch   

CRD also defines secondary hooks that are optional. These can improve your workflow but are not required for compliance. If you support them, you may return cards or responses, but CRD clients are free to ignore responses from them. If you choose to return Coverage Information here, it must not include messages requesting clinical or administrative details prematurely.   

Secondary hooks (optional):   

• Orders Select
• Encounter Start
• Encounter Discharge   

Supporting the primary hooks ensures your CRD service can deliver actionable coverage guidance at the most critical points in a provider’s workflow — a baseline requirement for CMS-0057-F readiness. 

What payers should prepare to return 

For CRD to work effectively, payers need to configure their CRD services to return complete and actionable responses. That means deciding in advance what data elements your system requires to determine coverage, prior authorization status, or whether more information is needed. 

Typical values include: 

• Coverage status — covered | not-covered | conditional
• Prior authorization status — no-auth | auth-needed | satisfied | performpa | conditional
• Documentation needed — clinical | admin | patient | conditional
• Purpose of documentation — withpa | withclaim | withorder | retain-doc | OTH
• Additional information needed — performer | location | timeframe | contract-window | detail-code | OTH

By defining these requirements up front and ensuring your client systems prefetch the right FHIR resources, you enable your CRD service to respond completely and keep the process moving without stalls.

Enabling CRD from the client side   

The CRD Implementation Guide also defines what providers and their systems must do to enable a CRD server. That includes documenting which prefetch data items are needed and why. This documentation ensures both client (provider) and server (payer) teams understand the required data elements and their purpose in determining coverage, prior authorization status, and documentation needs. 

Once the prefetch requirements are clear, clients must translate them into scopes that are granted to the CRD server via the access token already provided in the initial hooks request. These scopes give the server permission to query for any additional FHIR resources it needs at runtime, beyond what is sent in the initial prefetch.

In practice, this means thinking through the key pieces of information the CRD server will need to give a complete, accurate response. That typically includes: 

• Patient & coverage — who the patient is and which policy applies
• Order details — what is being ordered (service, device, medication, nutrition)
• Requester/performer — who is asking and who will perform 
• Location & organization — where it will happen and under which organization or contract
• Encounter context — why and when care is happening
• Device/medication details — the exact product/code where relevant   

When these pieces come together, payers can provide providers with immediate, reliable coverage guidance, turning a historically frustrating process into one that works in real time.

The bottom line 

CRD isn’t just a box to check. It’s the starting line for electronic prior authorization. By delivering guidance at the moment of care, payers can: reduce costly rework, improve provider satisfaction with clearer, faster answers, and lay the foundation for CMS-0057-F compliance by 2026.

In short: CRD may not be the hardest step in your ePA journey, but it’s the one you can’t afford to get wrong. Every smooth prior authorization process starts here.