Overview
Da Vinci Coverage Requirements Discovery (CRD) is a FHIR Implementation Guide that uses CDS Hooks to surface payer coverage requirements to clinicians at the point of clinical ordering. When a clinician in an EHR selects a medication, imaging study, procedure, or other item that may have coverage implications, the CRD hook fires a call to the payer's CRD service. The payer evaluates the member's coverage and returns CDS Hooks cards indicating whether prior authorization is required, what documentation is needed, whether preferred alternatives exist, and other coverage-relevant information.
CRD is a core component of the CMS-0057-F Prior Authorization Final Rule compliance stack, alongside Documentation Templates and Rules (DTR) and Prior Authorization Support (PAS). CRD answers the "do I need PA for this?" question; DTR helps complete required documentation; PAS submits the completed PA. Together the three IGs enable end-to-end FHIR-based prior-authorization workflow.
The hook that triggers CRD is typically order-select — when the clinician picks an order before signing. CRD-aware EHRs configure the order-select hook to fire for categories of orders that are likely to have coverage implications. The response may be a card reading "Prior authorization required — launch DTR to complete documentation," or "Preferred alternative: Drug X (no PA needed)," or "No PA required — proceed with order," or similar. Clinicians can proceed, modify, or cancel the order based on the guidance.
Coverage-requirement payloads can include structured data beyond simple flags. Documentation requirements reference specific clinical data elements the payer needs; alternative-suggestion cards describe preferred drugs or procedures; clinical-criteria links point to the payer's detailed coverage policy. The structured response enables the EHR to guide clinicians through the decision rather than merely alerting them to a problem.
CMS-0057-F requires covered payers to implement CRD for all non-drug services with compliance dates beginning January 2026. Early-adopter payers have been running CRD in production for several years under voluntary participation; the mandated expansion will substantially increase coverage across covered-payer relationships.
For RCM operations, CRD's value proposition is denial prevention. Claim denials for missing PA or failed medical-necessity frequently originate because the clinician did not know PA was needed or did not complete required documentation at order time. CRD surfaces the requirement at the moment the order is placed, giving the clinician and RCM function time to handle the PA workflow before service delivery — transforming a post-claim denial into a pre-service prevention.
From a board-reporting standpoint, Da Vinci Coverage Requirements Discovery (CRD) belongs in the compliance committee's quarterly dashboard. The reporting line should include volume, exception rate, and any open remediation action; reviewers tie Da Vinci Coverage Requirements Discovery (CRD) metrics to the broader compliance program KPIs so an emerging Da Vinci Coverage Requirements Discovery (CRD) risk surfaces before it becomes a formal finding. Pairing the Da Vinci Coverage Requirements Discovery (CRD) trend with prior authorization api gives the committee a single view of whether the control environment is strengthening or drifting.
Industry benchmark
CMS-0057-F CRD compliance: January 2026 for most covered payers. Early-adopter production deployments: 10+ major payers with growing use across specialties.
Worked example
A clinician selects a high-cost specialty biologic in an EHR order module. The order-select CDS Hook fires CRD against the patient's MA plan. The payer's CRD service returns a card: "Prior authorization required. Preferred alternative available with no PA: generic equivalent Y. To proceed with selected drug, launch DTR to complete documentation." The clinician discusses alternatives with the patient and selects the generic, avoiding a PA workflow and likely future denial.
Frequently asked questions — Da Vinci Coverage Requirements Discovery (CRD)
What triggers CRD?
CDS Hooks — typically order-select — fire CRD calls to the payer's service when the clinician selects an order. The EHR configures which order types trigger hooks.
Does CRD replace payer portals?
For coverage-requirement checks, yes — CRD surfaces the information at order time rather than requiring separate portal lookups. Portals continue for exception cases and non-CRD workflows.
Who builds CRD services?
Payers build or acquire CRD services to respond to CDS Hooks calls. Many payers partner with vendor platforms (Cohere, Rhyme, Vital/Availity, Surescripts Clinical Decision Support, and others) rather than building entirely in-house.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.