Da Vinci Coverage Requirements Discovery (CRD) can be wired into the provider workflow two ways. The CDS Hooks pattern fires a service call at a specific decision point inside the EHR (order-sign, appointment-book, medication-prescribe). The direct REST pattern exposes the CRD endpoint as a FHIR REST service the EHR can call when it chooses. Both are conformant under the Da Vinci IG. The choice has operational consequences that show up months into deployment, not on day one. This comparison lays out where each pattern wins for more on healthcare regulatory tech decision-making.
What CDS Hooks Actually Is
CDS Hooks is an HL7 specification for embedding clinical decision support into EHR workflows at well-defined trigger points. The EHR calls out to a CDS service URL when a clinician hits a hook (order-sign, order-select, appointment-book, etc.), passes context, and renders any returned cards inline. For CRD, the hook tells the payer service "this provider is about to order this procedure" and the response says whether PA is required, what documentation is needed, and what the next step is.
The pattern fits the human workflow well. The clinician sees coverage information inline, before submitting the order, without leaving the EHR.
What Direct REST Looks Like
The direct REST pattern exposes CRD as a regular FHIR REST endpoint the EHR queries when it wants coverage information. The call is initiated by the EHR rather than triggered by a workflow hook, and the response carries the same data as the CDS Hook card would, just in raw FHIR Bundle form.
The pattern fits programmatic workflows well. Batch eligibility checks, scheduled order review, and prior-auth pre-checks at clinical intake can all consume the REST endpoint without depending on a clinician hitting a hook.
Where CDS Hooks Wins
CDS Hooks wins on clinician adoption. The information arrives at the moment of decision, inside the EHR the clinician is already using. Provider adoption of PA pre-checks is the single biggest variable in whether CRD reduces denial rates, and CDS Hooks is the integration pattern with the strongest track record.
CDS Hooks also wins on EHR vendor cooperation. The major EHRs (Epic, Cerner, athenahealth) ship CDS Hooks support out of the box. Wiring up CRD as a hook does not require a custom integration build for each provider.
Where Direct REST Wins
Direct REST wins on flexibility and back-office use cases. A revenue cycle team running batch eligibility verification ahead of a clinic day does not need to be inside the EHR; the REST endpoint can be queried programmatically. A care management team pre-checking PA for a referred specialty does not have a hook context to fire from.
Direct REST also wins on operational debugging. Hook context is opaque from the payer side; if a hook fires and nothing happens, the payer cannot easily distinguish between "EHR did not receive the response", "clinician dismissed the card", and "card was not rendered". A REST call leaves a clean log on both ends.
The Hybrid Pattern Most Payers Actually Run
In practice, most payers running CRD in production in 2026 implement both patterns. CDS Hooks handles the clinician-facing workflow. Direct REST handles back-office, batch, and care-management use cases. The two share the same CQL rule set and FHIR data layer underneath; the difference is the entry point.
This hybrid is not extra work if the underlying CRD service was designed with both in mind. A clean implementation factors the rule evaluation logic out of the transport layer, so CDS Hooks and direct REST are thin adapters over the same engine.
How to Decide for Your Plan
The decision usually comes down to provider mix and back-office workflow. Plans with concentrated provider networks running on EHRs with mature CDS Hooks support (Epic, Cerner) get the most leverage from CDS Hooks. Plans with diffuse provider networks across many smaller EHR systems and heavy back-office PA workflow get more from direct REST.
For the engine layer underneath both patterns, the Top 5 CQL Engines for Medical Necessity Decisions in Prior Auth covers what is actually running the rules. For the full PAS submission path that follows the CRD decision, the Top 5 Da Vinci PAS implementation tools covers the submission side.