Coverage Requirements Discovery

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

CRD brings payer guidance into a workflow

The current CRD implementation guide describes a real-time exchange between a client system and a payer-side CRD service. The aim is to surface relevant requirements while a user creates an order, books an appointment, or completes another supported action.

Guidance can arrive earlier than a portal or telephone check, though its meaning still depends on the payer, product, member, requested service, data supplied, endpoint, guide version, and response timestamp.

The workflow uses CDS Hooks and FHIR

A CRD client invokes a supported CDS Hook at a defined workflow event and sends context plus authorized FHIR data. The payer service can use prefetched data, query permitted information, and return cards or coverage-information assertions.

Implementers must map hook, resource, code, member coverage, payer endpoint, authorization, response artifact, and user action. A successful HTTP response alone says nothing about completeness or correctness of coverage guidance.

Payer routing is a hard gate

The client needs the correct service for the patient's current coverage. Plan name, payer brand, administrator, network, and processing organization can differ.

Record the coverage identifier, endpoint-discovery source, effective date, supported hooks and resources, environment, certificate or token configuration, and last successful validation. Send no clinical data to an endpoint until identity, authorization, and purpose are verified.

CRD, DTR, and PAS have different jobs

CRD discovers coverage and documentation expectations in context. Documentation Templates and Rules, or DTR, can retrieve computable questionnaires and logic to gather needed information. Prior Authorization Support, or PAS, supports the authorization request and response exchange.

The guides are designed to work together, and implementations can support different subsets. A CRD card is not a PAS approval. A DTR questionnaire is not a clinical recommendation.

Current version and federal rule differ

The HL7 U.S. implementation-guide index lists CRD 2.2.1 as a January 2026 publication based on FHIR R4. It has trial-use status and can evolve.

CMS-0057-F requires specified impacted payers to implement a Prior Authorization API for medical items and services excluding drugs, generally beginning January 1, 2027. The CMS fact sheet identifies CRD 2.0.1, DTR 2.0.0, and PAS 2.0.1 as recommended guides, while FHIR R4.0.1 and other named standards are required. Recommendation does not make every payer implement CRD.

A fictional ABA workflow

A clinician begins an assessment-service request for one member. The EHR invokes a configured CRD service with the coded request and permitted context. The response says documentation is needed and offers a DTR launch link.

The work queue records one request, endpoint, guide version, payer assertion ID, timestamp, returned status, and human reviewer. A benefits specialist verifies the member, product, source freshness, and current payer route before release.

Across 20 test cases, 18 reach the expected payer endpoint, 16 return a response, and 14 match the preverified requirements. Report routing 18/20, response 16/18, and validated agreement 14/16 separately.

Clinical authority stays with qualified people

Software can surface a payer requirement, identify missing fields, and preserve source evidence. It should not rewrite goals, dosage, risk, medical necessity, or rationale to satisfy a card.

An appropriately qualified clinician decides clinical content. Payer and operations roles decide within their own authority. A coverage statement does not replace consent, assessment, or client preference.

Privacy and security apply to every exchange

Map which protected health information leaves the client, who receives it, why it is needed, and which agreement and authorization route applies. Use approved endpoints, least-privilege access, transport security, audit logs, incident routing, retention, and deletion controls.

Do not include an entire record because the interface permits it. Validate prefetch and query behavior against purpose-specific data needs and applicable law.

Test business meaning, not only connectivity

Create cases for covered, excluded, authorization-required, documentation-needed, ambiguous, unsupported, expired, wrong-payer, timeout, partial-data, and conflicting-response states. Lock expected results before execution.

Measure endpoint routing, response completeness, code mapping, assertion freshness, user display, safe fallback, DTR link behavior, and human resolution. Keep every due case in its denominator, including timeouts and unsupported routes.

Maintain a deployment contract for each payer route: supported hook, resource and code set, guide version, endpoint, authentication, data scope, expected response states, cache rule, timeout, escalation owner, and last validated date. Disable automated reliance when the contract expires or a response conflicts with a current controlling payer source.

Define which artifact controls each decision. Current payer documentation should govern operational requirements; the CRD response supplies time-stamped workflow evidence; the clinical record supports clinical facts; and the authorization response governs the submitted request's status. Route conflicts to a named human owner and preserve both versions without silent overwriting.