|
| 1 | +# Coverage Requirements Discovery (CRD) |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +The Aidbox Coverage Requirements Discovery (CRD) implementation enables real-time communication between EHR systems and payers to determine documentation and prior authorization requirements at the point of care. Built on the [HL7 Da Vinci Coverage Requirements Discovery Implementation Guide](https://hl7.org/fhir/us/davinci-crd/), it helps providers understand payer requirements before ordering services. |
| 6 | + |
| 7 | +When combined with Documentation Templates and Rules (DTR) and [Prior Authorization Support (PAS)](../prior-authorization-support-pas-api.md), CRD ensures that providers are informed of coverage requirements early in the workflow, reducing claim denials and improving the authorization process. |
| 8 | + |
| 9 | +## CDS Hooks |
| 10 | + |
| 11 | +The core of the CRD Implementation Guide is built on [CDS Hooks](https://cds-hooks.hl7.org/STU2/) — an HL7 standard that enables clinical decision support to be invoked from within a clinician's workflow. All hooks in the CMS-0057-F Aidbox module follow the same processing workflow: |
| 12 | + |
| 13 | +1. **Receive Hook Request** — The EHR system sends a CDS Hooks request (e.g., `order-sign`, `order-select`) containing context data (patientId, encounterId, draftOrders etc.) and prefetch resources. |
| 14 | + |
| 15 | +2. **Validate Request Structure** — The request is validated against the CDS Hooks schema to ensure all required fields are present and correctly formatted. |
| 16 | + |
| 17 | +3. **Validate FHIR Resources** — All FHIR resources from `draftOrders` and `prefetch` are validated together using Aidbox validation. This includes resolving all references within each resource. |
| 18 | + |
| 19 | +4. **Fetch Missing Resources** — If validation fails due to missing referenced resources, the module automatically fetches them from the `fhirServer` URL provided in the hook request using the `fhirAuthorization` token. This resolution continues recursively until all references are resolved. |
| 20 | + |
| 21 | +5. **Persist Resources** — All validated resources are persisted to Aidbox using a transaction bundle for audit and future reference. |
| 22 | + |
| 23 | +6. **Enrich and Proxy** — The request is enriched with resolved prefetch data and proxied to the configured decision-making service, which analyzes the clinical data and returns CDS Cards with coverage requirements, documentation needs, or prior authorization information. |
| 24 | + |
| 25 | +## Decision Making Service |
| 26 | + |
| 27 | +The CMS-0057-F Aidbox module (`healthsamurai/cms-0057:edge`) proxies validated CDS Hooks requests to an external decision-making service. To configure the decision service URL, set the following environment variable: |
| 28 | + |
| 29 | +``` |
| 30 | +CDS_DECISION_SERVICE_URL=https://your-decision-service.example.com |
| 31 | +``` |
| 32 | + |
| 33 | +For a complete setup example, see [Run Aidbox + CMS App locally](../getting-started/run-aidbox-+-cms-app-locally.md). |
| 34 | + |
| 35 | +It is the responsibility of the decision-making service to analyze the clinical data and build a valid CDS Hooks response containing appropriate Cards with coverage requirements, prior authorization information, or links to SMART apps for additional documentation gathering. |
| 36 | + |
| 37 | +{% content-ref url="cds-hooks-api.md" %} |
| 38 | +[CDS Hooks API](cds-hooks-api.md) |
| 39 | +{% endcontent-ref %} |
0 commit comments