In brief: Coverage Requirements Discovery is the Da Vinci guide that lets an EHR ask a payer, at the moment an order is signed, whether the service is covered, whether prior authorization is needed and what documentation the payer wants. It runs on CDS Hooks, expects an answer in about five seconds, and its key output is a coverage-information system action attached to the order. This post covers the mechanics, the six hooks, the response, the architecture that makes five seconds possible, how delegated vendors sit behind one endpoint, and how to test without an EHR partner.
Coverage Requirements Discovery is the first of the three HL7 Da Vinci guides that make up the CMS-0057-F Prior Authorization API, and the one that delivers most of the value. Its question is simple: when a clinician orders something, is it covered, does it need prior authorization, and what documentation will the payer want? Its constraint is hard: answer inside the clinician's workflow, in about five seconds, from payer systems that were built to answer in hours.
This post is the second in our series (the first, CMS-0057-F explained, covers the rule itself). Here we go through the CDS Hooks mechanics CRD is built on, the six hooks and which ones are mandatory, the exact response the payer must return, the error rules, the architecture that hits five seconds, how a plan composes delegated vendors behind one endpoint, and how to test before you meet a real EHR. Requirement identifiers such as §hook-16 are the guide's own, so anyone can check them on the CRD hooks page.
CDS Hooks in four calls
CRD does not invent an API. It uses CDS Hooks, the HL7 specification that lets an EHR call an outside service at a moment in a clinician's workflow and get back something to show or do. Everything in CRD sits on four calls.
Discovery. The EHR calls GET /cds-services on the payer's base URL and receives a list of services: the hook each one listens to, an id, a description, and prefetch templates, which are FHIR queries the EHR should run before calling so the service does not have to call back. Discovery happens once, or on a schedule, not on every order.
The hook. When the workflow event fires, the EHR posts to /cds-services/{id}. The body carries a hookInstance identifier, the hook name, a context object specific to the hook (patient, user, the draft orders as a bundle, the selected orders), the prefetched resources, and optionally a fhirAuthorization token the service could use to query the EHR's FHIR server.
The response. An array of cards, each with a summary, detail, indicator, source, optional links (which can launch a SMART app) and optional suggestions that edit the draft order, plus system actions, which the EHR applies silently. In CRD the system action is the important part.
Feedback. The EHR posts to /cds-services/{id}/feedback to say whether the user accepted or overrode a suggestion.
Two practical notes from Epic's documentation and the Medblocks CDS Hooks tutorials: use prefetch wherever you can, because a callback to the EHR's FHIR server costs seconds you do not have, and expect CORS and mutual TLS questions if your service is ever called from a browser. Epic supports patient-view, order-select and order-sign, sends draft orders as MedicationRequest, ServiceRequest or ProcedureRequest, and lets the health system configure prefetch in its own records.
This illustrative request path uses prefetched context before evaluating requirements. The response communicates what is known about coverage and documentation.
The six hooks, and the two that matter most
The CRD guide (version 2.2.1 is current; CMS names 2.1.0 for 2027) defines six hooks that cover the moments where coverage questions arise.
- appointment-book, when scheduling books a visit.
- encounter-start, when the patient is seen.
- encounter-discharge, when they leave.
- order-select, when the clinician picks an order from a list, before signing.
- order-sign, when the clinician signs the order.
- order-dispatch, when an order is routed to a performing provider.
The guide's conformance language is specific. A CRD client "SHALL support at least one of the hooks" and, if it places orders, "SHALL support the order-sign hook for the order types they support" (§hook-2, §hook-3). A CRD server "SHALL provide a service for all hooks and order resource types required of CRD clients ... unless the server has determined that the hook will not be reasonably useful" (§hook-4).
Order-sign and order-dispatch are primary. For these, "CRD Servers SHALL include a Coverage Information system action in the response ... even if the response indicates that further information is needed or that the level of detail provided is insufficient to determine coverage" (§hook-16). The other four are secondary: they "MAY return cards or system actions, but are not expected to, and CRD clients are free to ignore any cards or actions returned" (§hook-17). Clients can use configuration options to tell a server not to bother responding on hooks they will not display (§hook-18).
Each hook has a required set of profiles for the resources in its context: patient, encounter, practitioner and practitioner role, and the order types (ServiceRequest, MedicationRequest, DeviceRequest, NutritionOrder, VisionPrescription, CommunicationRequest, Appointment, Task for dispatch). Clients "SHALL ensure that data included in the hook invocation complies with the listed profiles" and servers "SHALL NOT depend on data not covered by the identified profiles" (§hook-21, §hook-22). Servers "SHALL handle unrecognized context elements by ignoring them" (§hook-23).
One hook type the base specification does not have and CRD adds: the what-if call. A clinician can test an order without placing it, to see whether it would need approval. The payer must recognize this, answer with coverage and documentation information, and make no stateful change, issuing no authorization number.
What the payer returns
The heart of a CRD response is the coverage-information extension carried on a system action, which the EHR attaches to the order. Cards are optional, and Epic's guidance to CDS Hooks developers is blunt: "Your CDS service must be fast, must avoid alert fatigue, and should improve over time." Clinicians dislike interrupting cards; the system action is what gets stored and acted on.
The coverage-information extension states whether the service is covered, whether prior authorization is needed, whether documentation is needed and of what kind, what information is missing and why, and, when the payer can decide on the spot, a satisfied prior-auth identifier that binds the later claim. It carries a coverage-assertion id that DTR treats as the primary key when a completed questionnaire updates or replaces the assertion.
Errors follow the FHIR RESTful create semantics. A 400 covers requests that are not parsable, fail FHIR or CDS Hooks validation, or name a payer the endpoint does not serve: "if a CRD server receives a call where the primary Coverage ... does not have a payer.identifier that identifies a payer that is handled by that CRD server endpoint, the server SHALL return a 400 error and SHOULD provide an OperationOutcome" (§hook-13). For internal failures the server "SHALL provide an OperationOutcome for internal issue tracking by the client system" (§hook-10), and the client may tell the user the discovery service is unavailable.
The client also has a discovery problem of its own: it "SHALL be able to determine the correct payer CRD server to use for each request" (§hook-1). Today that means per-payer configuration; PDex endpoint discovery and the national directory work are the longer-term answer.
Missing context, a successful requirements response, and a service failure are different outcomes. A failure to obtain information must not silently become a coverage decision.
Five seconds is an architecture, not a setting
The guide's implementer expectation is a response in about five seconds, ten at most, including any callback into the EHR. Payers' eligibility, benefit, network, gold-card and delegated-vendor rules live in separate legacy systems that answer in hours. The teams that make CRD work do not query those systems at request time.
Four components do the work.
- A requirement matrix. For each line of business, product, procedure code and place of service: whether prior authorization is required and which documentation is needed. Compiled nightly from a structured policy catalog, which means the medical policies have to exist as data first. That catalog is the same asset DTR needs, and building it is the largest unbudgeted item in most programs.
- An eligibility cache. Coverage effective dates, benefits and network status, refreshed from 834 enrollment and eligibility feeds, so "is it covered" is answered from memory.
- A delegate routing table. Which vendor reviews which category, so the plan knows who owns the answer and can answer for a vendor that is not yet connected.
- A coverage-assertion ledger. Every "no approval needed" answer recorded against the member, the code, the provider and the date, so the claim is honored when it arrives.
The request path is then short: hook arrives with prefetch, match the matrix and cache in memory, build the coverage-information extension, write the assertion, respond. In vendor-reported pilots presented at HL7 Da Vinci and industry sessions, "no prior auth required" came back for roughly half to 80% of requests, depending on the payer and the order mix; treat those as self-reported figures. That answer alone removes most of the phone calls and portal visits, and it needs no questionnaire content to ship. Build CRD first.
A plan with delegated vendors: one door, many reviewers
Most plans do not make all their decisions in-house. A California payer described "literally dozens of delegated providers performing that prior-auth function": imaging with one vendor, genetic testing with another, home health, DME and behavioral health elsewhere, drugs with the pharmacy benefit manager. The rule does not care. The EHR must see one CDS service.
The composition pattern below is the architecture we propose. One part of it, never forwarding the EHR's token, follows the CRD guide's privacy guidance; the rest are design choices, and CMS does not mandate how a plan integrates its delegates:
- Every vendor implements the same CRD interface internally and proves it on the Inferno kit, so the plan's facade is a router rather than a translator. A conformant external endpoint can also be served by per-vendor adapters; the cost is maintaining each one, and it is the pattern the Medblocks walkthrough warns "will become a mess."
- The plan runs a facade that exposes one
/cds-serviceslist, aggregated from the vendors' lists, and routes each hook by plan, product or code category. - Prefetch keys are namespaced per vendor (vendor1_p1, vendor1_e1) and the prefix is stripped when routing, so each vendor gets exactly the prefetch it declared.
- The EHR's
fhirAuthorizationtoken is never forwarded. The guide says access tokens "should not be forwarded to systems that are not managed by the same organization or have business associate agreements that allow centralized audit of access," and suggests "routing all requests for information through the initial endpoint system." The plan hosts its own FHIR server, resolves what it needs from the EHR, and gives vendors that. - What-if calls are answered statelessly all the way down.
For our take on the whole architecture, including the other three APIs, see the fifth post in this series; for the underlying SMART and OAuth mechanics, our Epic SMART on FHIR page covers app registration and launch.
How to test CRD before you meet a real EHR
Nothing about CRD needs a partner to start.
- The HL7 Foundry Burden Reduction bundle. One Docker configuration that runs the Da Vinci payer server (br-payer), a test EHR seeded with patients, and the crd-request-generator, a small web app that fires hooks and shows the cards. It needs a free VSAC key from a UMLS account because the rule content expands value sets at runtime.
- The Inferno CRD test kit. ONC hosts it at inferno.healthit.gov and it self-hosts with
setup.shandrun.sh. Its server suites (2.0.1 and 2.2.1 at the time of writing) exercise the documented hook set, profiles and error rules; the kit's README lists exactly which requirements it covers. - The Acentra Health sandbox. A review contractor's sandbox on synthetic data that exposes all six CRD hooks at
/priorauth/api/v1/cds-services/*-crd, with vendor, EHR and payer registration lanes. - Epic on FHIR. Epic publishes template apps under the use case "CMS Prior Auth." At the time of writing the payer-side clinician template listed read, search and update on ServiceRequest and MedicationRequest, read and search on Appointment, Coverage and Patient, and outgoing "CRD Request" and "CDS Hooks Framework." Registering it gives you a sandbox client with those scopes; running order-sign end to end still needs the CDS service configured in the sandbox, and production use needs the customer's and Epic's approval.
- A connectathon. HL7 runs a Burden Reduction track three times a year. At the July 2026 CMS connectathon, the failures were unbound SMART launch contexts, null-versus-absent hook keys and CapabilityStatement mismatches; none of them are in a test kit.
A worked example (illustrative): an MRI order at ten to five
A neurologist at a Medicare Advantage member's visit orders a lumbar spine MRI at 4:50 pm. Here is what the two systems exchange.
The EHR fires order-sign. The context carries the patient id, the ordering practitioner, and a draftOrders bundle with one ServiceRequest coded 72148. Prefetch, filled by the EHR before the call, includes the member's Coverage with the payer identifier, the Practitioner with NPI, and the Location. No callback is needed.
The CRD facade validates the payer identifier and routes to the imaging category. The requirement matrix says: this product, this code, outpatient, prior authorization required unless the ordering provider is gold-carded for advanced imaging. The eligibility cache confirms coverage is active. The provider is not gold-carded. Total elapsed time: under a second.
The response carries one system action: update the ServiceRequest with a coverage-information extension stating covered, prior authorization required, documentation required, with a link to the imaging questionnaire and a coverage-assertion id. One card, low priority, says "Prior authorization required for lumbar MRI; documentation can be completed now," with a link that launches DTR. The assertion is written to the ledger against member, code, provider and date.
The clinician clicks the link, DTR populates the form from the chart, and the request goes out through PAS before the visit ends. Had the provider been gold-carded, the same call would have returned "no prior authorization required" with a satisfied identifier. The CRD response records the prior authorization requirement for the specified context; claim payment still depends on applicable coverage, eligibility and billing conditions. Everything in this example, including the timings, is illustrative.
What the major EHRs do differently
The guide is one thing; the four EHRs that matter to a US payer's network read it slightly differently, and an evidence pack should show all of them.
- Epic documents patient-view, order-select and order-sign, sends draft orders as MedicationRequest, ServiceRequest or ProcedureRequest, and lets each health system configure prefetch. Epic announced on 17 August 2026 that real-time CRD checks were live with UnitedHealthcare, Aetna and Network Health, with more payers in testing. Its release documentation says the February 2026 build "does not follow [Da Vinci 2.1] exactly," so expect differences in context and system-action handling. Our earlier post on CDS Hooks in production covers the Epic and Oracle mechanics in more depth.
- Oracle Health documents CDS Hooks support through its developer program with its own registration flow; hook coverage and context details differ from Epic's, so verify order-sign context and prefetch behavior in its sandbox rather than assuming parity.
- MEDITECH was named in CMS's May 2026 early-adopter press release; confirm CDS Hooks availability and timing with its developer program before treating it as ready.
- athenahealth handles much prior authorization work through its own services and partners; expect the CRD conversation to involve a partner such as Availity.
The practical rule: build to the guide, verify against Epic first because it is the largest, and keep the context handling behind an adapter so the other three do not fork your facade.
If you are scoping a CRD service, or a delegated-vendor facade in front of several, we can review your hook coverage, prefetch design and version matrix against the guide before you commit to an architecture. See our prior authorization automation and CMS-0057-F interoperability suite pages, or talk to our team.
Explore the CMS-0057-F series
- CMS-0057-F Explained: Requirements and 2027 API Deadlines
- Da Vinci CRD Explained: Coverage Requirements Discovery (this article)
- Da Vinci DTR Explained: Questionnaires, CQL and Prior Authorization
- Da Vinci PAS Explained: FHIR Prior Authorization and X12 278
- CMS-0057-F Payer Architecture for Delegated Vendors
- CMS-0057-F API Testing: Inferno, Sandboxes and Evidence
Sources
- HL7 Da Vinci CRD 2.2.1 (current) and 2.1.0
- CRD hooks page
- CDS Hooks 2.0 specification
- CMS Prior Authorization API FAQs
- CMS standards and implementation guides by API (updated 14 April 2026)
- Epic: payers, providers and Epic launch real-time prior authorization checks (August 2026)
- Epic on FHIR developer documentation
- HIT Consultant on Epic CRD deployment (17 August 2026)
- Acentra Health FHIR sandbox
- Inferno Da Vinci CRD test kit (GitHub)
- HL7 Foundry
- Burden Reduction reference implementations (HL7 Confluence)
- HL7-DaVinci GitHub: br-payer, br-provider, test-ehr, crd-request-generator, dtr, CDS-Library
- Health Samurai: CMS FHIR Connectathon 2026 results
- Medblocks, CMS-0057-F Explained (Sidharth Ramesh, YouTube)
- HL7 National Directory of Healthcare Providers and Services (build)
