Coverage Requirements Discovery (CRD)

What is CRD?

Coverage Requirements Discovery (CRD) enables payers to provide real-time coverage information to providers at the point of care. When a clinician orders a service, medication, or device, CRD automatically checks coverage requirements and communicates them within the provider's workflow.

1upHealth follows the HL7 Da Vinci Coverage Requirements Discovery Implementation Guide.

Supported versions

1upHealth supports the following versions of the HL7 Da Vinci Coverage Requirements Discovery Implementation Guide:

STU 2.0.1

Key capabilities

Check if a service is covered under a patient's plan.
Determine if prior authorization is required.
Identify documentation requirements.
Suggest alternative treatments or lower-cost options.
Provide links to coverage policies.

CDS hooks overview

CRD uses Clinical Decision Support (CDS) hooks, a specification for clinical decision support at key workflow points. CDS hooks enables a provider's EHR to call external services and receive "cards" with information, suggestions, and links. Hooks are built into CDS clients, such as a provider's EHR or appointment booking application and trigger the CDS client to send a request.

How it works

Hook event: Specific action in CDS client (e.g. signing an order in an EHR).
Service invocation: EHR calls CDS service with context.
Card response: Service returns cards with guidance.
User display: EHR shows cards to clinician.

Hook types

Hook type	Specification conformance	Supported?	When does the hook trigger?	Purpose
appointment-book	Shall	Planned for support	When a member books an appointment with a provider.	Check if the appointment requires authorization.
encounter-start	May	Planned for support	When a patient encounter begins.	Checking coverage at the start of an encounter to guide decision-making for the provider.
order-select	May	Planned for support	After a provider selects an order but before signing it.	Checking coverage before entering details and signing to support efficient decision-making for the provider.
order-sign	Shall	Yes	When a provider signs an order for a medication, procedure, device, or other service.	Check coverage before the order is finalized and sent to the pharmacy, lab, etc.
order-dispatch	Shall	Planned for support	After an order is assigned to a specific performer.	Checking coverage based on the specific facility or provider assigned.
encounter-discharge	May	Planned for support	When a provider begins the discharge process for a patient.	Checking whether documentation requirements have been met and follow-up planning is complete.

CDS service discovery

Hooks trigger the CDS client to first send a request to 1up's discovery endpoint: /cds-services. The response to that request includes the type of hooks that 1upHealth supports and prefetch requirements for that CRD API request. Then the CDS client collects the required data and submits a request with the prefetch fields populated to 1up using the CRD API. 1up returns a response indicating whether or not prior authorization is required.

Endpoint: GET https://gateway.1up.health/v1/1uphealth-core-prod/crd-prod/{customerKey}/{partitionKey}/cds-services

Path parameters

Replace the {customerKey} and {partitionKey} path parameters with the appropriate values for the desired payer. Refer to Provider implementation for more details about these path parameters.

Response format: CDS Hooks Discovery. The response lists available services, supported hooks, and prefetch templates.

CDS hook requests

CDS clients POST to the service endpoint when a hook event occurs.

Endpoint and request profile

Endpoint: POST https://gateway.1up.health/v1/1uphealth-core-prod/crd-prod/{customerKey}/{partitionKey}/cds-services/{service-id}

Path parameters

Replace the {customerKey} and {partitionKey} path parameters with the appropriate values for the desired payer. Refer to Provider implementation for more details about these path parameters.

The {service-id} path parameter is the type of CDS hook. For example, order-sign.

Request profile: CRD CDSHooksRequest

Required FHIR elements

hook: Hook type (e.g., "order-sign")
hookInstance: Unique UUID for this invocation
fhirServer: CDS client's FHIR endpoint URL for queries
fhirAuthorization: Access token for FHIR queries
context: Hook-specific context data
prefetch: Pre-populated FHIR resources (optional but recommended)

CRD-specific extensions

davinci-crd.requestedVersion: Requested CRD version (e.g., ["2.2"])
davinci-crd.configuration: Configuration options

Prefetch

Including prefetch reduces latency by including commonly needed resources in the initial request, minimizing additional queries.

Typical prefetch bundle:

Patient resource
Coverage resources (active coverages for the patient)
Encounter resource
Relevant Conditions
Recent Observations

Prefetch templates: Specified in service discovery response.

Specification: CRD Prefetch Guidance

Example requests

CDS hook responses

1upHealth returns cards with coverage information. Each card contains guidance, links, or actionable suggestions.

Response specification: CRD CDSHooksResponse

FHIR resource profiles

Supported US Core profiles

1upHealth expects FHIR resources conforming to US Core profiles. Provider systems must support US Core 7.0.0 (USCDI v4).

CRD resource profiles

Use CRD-specific profiles when available for enhanced functionality:

CRD-specific profile	Spec	Example
Patient	CRD Patient Profile	Example Patient
Coverage	CRD Coverage Profile	Example Coverage
ServiceRequest	CRD ServiceRequest Profile Billing Options Extension (Includes alternative billing codes)	Example ServiceRequest
MedicationRequest	CRD MedicationRequest Profile	Example MedicationRequest
DeviceRequest	CRD DeviceRequest Profile	Example DeviceRequest
Appointment	CRD Appointment with ServiceRequest CRD Appointment without ServiceRequest	Example Appointment with order
Encounter	CRD Encounter Profile	Example Encounter
Other Resources	CRD CommunicationRequest CRD NutritionOrder CRD VisionPrescription CRD Task

See all CRD resource profiles for more detail.

CRD extensions

Extensions are additions to FHIR resources that go beyond the base FHIR specification. 1up supports several extensions related to the CRD. These extensions are not required to use the 1up CRD.

Coverage Information extension

The primary extension for conveying coverage assertions.

Extension URL: http://hl7.org/fhir/us/davinci-crd/StructureDefinition/ext-coverage-information

Specification: Coverage Information Extension

Key elements:

coverage: Reference to Coverage resource
covered: Coverage status (covered, not-covered, conditional)
pa-needed: Prior auth status (auth-needed, no-auth, satisfied, conditional)
doc-needed: Documentation type (clinical, admin, patient, conditional)
doc-purpose: Purpose of documentation (prior-auth, claim, audit)
info-needed: Additional info (performer, location, timeframe)

Billing Options extension

Specify alternative billing codes for an order.

Extension URL: http://hl7.org/fhir/us/davinci-crd/StructureDefinition/ext-billing-options

Specification: Billing Options Extension

Use case: ServiceRequest may be billed under different CPT codes depending on specifics

Example: ServiceRequest with billing options

Request Type extension

High-level categorization of the order type.

Extension URL: http://hl7.org/fhir/us/davinci-crd/StructureDefinition/ext-request-type

Specification: Request Type Extension