CRD in Practice: What Answering 'Does This Need Auth?' Demands From Your Rules Engine

Most payer organizations can answer "does this service need prior auth?" today. The answer lives in a benefits document, a UM policy manual, or — the classic — a PDF on the provider portal listing codes that require review. What CMS-0057-F pushes toward, and what the Da Vinci CRD implementation guide specifies, is something categorically different: answering that question synchronously, for a specific member and a specific order, while a clinician is mid-workflow in their EHR. The API surface is the easy part. The hard part is that most payer rules engines were never built to answer the question at the granularity, speed, or precision the workflow requires.

Where the question arrives: six hooks, three you must answer

CRD rides on CDS Hooks: the EHR (the CRD client) calls the payer's CRD server at defined points in the clinical workflow, and the server responds with cards and system actions. The current CRD guide identifies six hooks, split into two tiers with very different conformance weight.

Primary hooks — appointment-book, order-sign, order-dispatch — are the ones a CRD server SHALL answer. At minimum, the server must return a coverage-information system action for these hooks even when the honest answer is "we need more detail to say." Order-sign fires when the clinician signs a set of draft orders, so every order in context is considered complete and fair game for comment. Order-dispatch fires later, when a performer is chosen — often by someone other than the ordering clinician — which matters because network status and site of service frequently change the authorization answer.

Secondary hooks — order-select, encounter-start, encounter-discharge — MAY return responses, and clients are free to ignore them. The guide adds a subtle constraint: coverage information returned on secondary hooks must not ask for clinical or administrative information, because that information is expected later in the process. Order-select is still worth implementing on the server side even if you return nothing: it fires early enough to let your back end pre-fetch member, benefit, and history data so the answer is already cached when order-sign arrives. The IG explicitly calls this pattern out as a way to hit the required response window.

One more client-side fact that shapes server design: CRD clients must determine the correct payer CRD server per request. Your server will only ever be asked about members you cover — but it will be asked by many different EHR implementations, with different prefetch behavior and different tolerances, which is why your discovery endpoint's declared prefetch templates deserve real engineering attention rather than copy-paste from the IG examples.

What the question actually contains

A hook invocation is not "does CPT 70553 need auth?" It is a FHIR payload: patient and user context, draft order resources (ServiceRequest, MedicationRequest, DeviceRequest, and friends), and whatever prefetch data you asked the EHR to send — coverage resources, encounter context, sometimes relevant history. The question your engine must answer is closer to: for this member, under this plan, for this procedure code at this site of service ordered by this provider, is authorization required, and if so, what documentation will be needed?

Every clause in that sentence is a lookup your rules engine has to perform in real time, and each one is a place where "we have a PA list" quietly falls apart.

Four things the rules engine must actually do

Service-code granularity. The unit of decision is the procedure code — CPT/HCPCS level, sometimes modified by diagnosis, site of service, or quantity — not the service category. A policy that says "advanced imaging requires review" is a paragraph; a rule that says this code, with this diagnosis context, at this place of service requires review is a decision your engine can execute. Most UM policy libraries are written at the paragraph level, and the translation to code-level rules is the single largest work item in a CRD program. It is content work, not integration work, and it never finishes: codes change annually and policies change quarterly.

Member-and-benefit resolution. "Does this need auth?" has no answer without "for whom?" The engine must resolve the member to a specific product, line of business, and benefit configuration — including delegate carve-outs. If radiology UM is delegated to a benefit manager, your CRD server still owns the answer; a response of "ask our delegate" is not a coverage-information system action. That means either federating the query to delegate rule sets in real time or syncing their rules into your engine, with all the freshness problems that implies.

Latency. CDS Hooks is a synchronous, in-workflow pattern. The EHR enforces a timeout, and clinicians enforce a shorter one: a card that renders after the ordering screen is closed is a card that never existed. Rules evaluation, benefit resolution, and any delegate or mainframe lookup all have to fit inside a response window measured in seconds. This is where the order-select pre-warming pattern earns its keep, and where architectures that route every question through a batch- era adjudication system go to die. Cache benefit and rules data close to the CRD server; treat anything that requires a synchronous hop to a legacy system as a design smell.

Determinism and versioning. The same question must produce the same answer at order time, at PAS submission time, and at claim time — or providers will stop trusting the cards, which defeats the entire program. That requires versioned rules with effective dates, so you can prove that the "no auth required" answer given on March 3 was correct under the rules in force on March 3 even if the policy changed on April 1. Log every hook invocation and every answer; when a claim denies for missing authorization after CRD said none was needed, that log is the difference between a fixable defect and a provider-relations fire.

Answers, not just flags: what goes back on the wire

The CRD response is richer than a boolean. The coverage-information extension annotates the order itself with whether the service is covered, whether prior authorization is required, and whether additional clinical or administrative documentation is needed — which is the handoff point to DTR and its questionnaires. Cards can carry human-readable guidance and links. The design intent is that the system action silently updates the order record while cards interrupt only when a human needs to act. Engineering teams consistently underestimate the second-order requirement here: everything you assert in a coverage-information extension becomes a commitment your downstream UM process has to honor.

CMS-0057-F frames the same obligation from the regulatory side: the Prior Authorization API must be populated with the payer's list of covered items and services (excluding drugs) that require prior authorization, and must identify all documentation required for approval. CRD is the recommended delivery mechanism for exactly those capabilities inside the ordering workflow — see the Prior Authorization API glossary entry for the full requirement set.

The PDF gap, measured honestly

Take your current PA list PDF and score it against the four demands above. Typical findings: the list is organized by service category rather than exhaustive code enumeration ("all inpatient admissions," "non-emergent advanced imaging"); it is one list for all products even though requirements differ by line of business; it carries a revision date but no machine-readable effective-dating; and it says nothing about documentation requirements beyond "clinical records may be requested." None of that is machine-answerable. Closing the gap means an inventory project — every PA-requiring policy, decomposed to codes, mapped to benefits, effective-dated, and owned by someone whose job includes keeping it current. Payers that treat this as a data-entry task staffed casually get a rules engine that confidently returns wrong answers, which is worse than the PDF.

Sequencing: CRD first is not optional

In the Da Vinci trio, CRD is the front door: it tells the provider whether auth is needed and points at documentation requirements, DTR collects that documentation, and PAS carries the request. Teams sometimes propose building PAS first because it maps neatly onto the existing 278 request flow. That sequencing works mechanically but strands the biggest burden reduction: most provider abrasion comes from not knowing whether auth is needed and what to attach, and those are precisely CRD's and DTR's jobs. Build the rules content once, and it serves CRD's real-time answers, the PA API's requirements list, and your intake validation on the 278 rail — one rules engine, three consumers.

Verify hook names, conformance language, and response profiles against the current published HL7 Da Vinci CRD implementation guide, and the API requirement set against the CMS-0057-F rule text — both evolve.