CRD (Coverage Requirements Discovery)

One-sentence definition: CRD (Coverage Requirements Discovery) is a Da Vinci FHIR Implementation Guide that enables health insurance payers to embed real-time coverage guidance directly into a clinician’s EHR ordering workflow using CDS Hooks, answering — before the order is signed — whether the service is covered, whether prior authorization is required, and what documentation must be collected.

Full Definition

Prior authorization friction often begins with a simple information gap: the clinician doesn’t know at the point of ordering whether a service needs PA. The result is orders that trigger PA requirements no one anticipated, fax exchanges that happen after the clinical decision has already been made, and delays that could have been avoided entirely. CRD closes that gap by making payer coverage guidance available inside the EHR at the moment of ordering.

CRD is the first component in the three-IG Da Vinci prior authorization stack, published by HL7. It defines a real-time query interface between a provider’s EHR (acting as the CDS Hooks client) and the payer’s coverage rules engine (acting as the CDS Hooks server). When a clinician selects or signs an order, the EHR automatically invokes the payer’s CRD service with the patient’s coverage information and the order in progress. The payer evaluates that request and returns guidance cards rendered within the ordering UI — with no separate workflow step required.

CRD responses cover a defined set of guidance types: confirming that a service is covered, identifying that prior authorization is required and linking to the documentation requirements, confirming that no PA is required, suggesting covered alternatives to an uncovered service, and signalling that DTR — the documentation collection step — should be launched. The clinician sees this guidance before committing the order, when it is still actionable.

The term “CRD” refers both to the IG itself and, informally, to the payer-hosted CDS Hooks service that implements it. A payer that has “implemented CRD” has published a CDS Hooks endpoint conforming to the IG.

For the complete workflow, implementation requirements, CDS Hooks integration details, and CMS-0057-F compliance context, see Prior Authorization Workflow.

Context and Usage

Where This Term Appears

• Da Vinci IG documentation and HL7 project materials
• EHR vendor certification and payer integration documentation
• CMS-0057-F implementation planning discussions (CRD is best practice under the rule, though not individually mandated)
• Provider–payer integration contracts specifying which Da Vinci IGs a payer has deployed
• Clinical informatics and health IT conference presentations on electronic prior authorization

Common Usage Examples

In conversation: “We integrated CRD last quarter — our PA work queue dropped by 30% because clinicians can see before ordering whether something needs auth.”

In technical contexts: “The CRD server is returning a DTR-launch card for this drug class, so the EHR needs to surface the SMART app launch option.”

In documentation: “Payers subject to CMS-0057-F are not required to implement CRD, but HL7 recommends it as the upstream step that makes PAS submissions more complete.”

Relationship to Other Terms

CRD is always discussed in the context of the other two Da Vinci PA IGs:

• DTR — Documentation Templates and Rules; CRD identifies that PA is needed and can signal that DTR should be launched to collect the required documentation
• PAS — Prior Authorization Support; PAS is the submission step that follows after CRD and DTR; PAS is the only component individually mandated by CMS-0057-F
• CDS Hooks — the real-time clinical decision support protocol that CRD is built on; CRD is an application of CDS Hooks to payer coverage rules
• Prior Authorization — the business process CRD addresses; CRD is not a substitute for PA but the mechanism that surfaces PA requirements early in the clinical workflow

CRD is distinct from the older eligibility check (CoverageEligibilityRequest/Response), which confirms that a patient has coverage but does not return PA requirements or order-specific guidance.

Common Misconceptions

“CRD replaces prior authorization.” CRD surfaces PA requirements earlier — it does not eliminate PA or substitute for the PA submission. A CRD response saying “PA required” still requires a PAS submission to obtain the authorization number.

“CRD is mandated by CMS-0057-F.” CMS-0057-F mandates an electronic PA API (the PAS layer). CRD is part of the Da Vinci best-practice stack and strongly recommended, but not individually required by the rule. Payers can satisfy CMS-0057-F without implementing CRD.

---

Last reviewed: February 16, 2026 Definition authority: HL7 International Content status: Canonical reference