Coverage Requirements Discovery (CRD)
Real-time coverage requirement discovery at the point of care — exposing payer coverage rules to EHR systems while treatment decisions are made.
Overview
The Coverage Requirements Discovery (CRD) API is a FHIR®-based interoperability API that enables payers to expose coverage requirement information to EHR systems in real time while treatment decisions are being made.
This allows clinicians and administrative staff to determine whether a service is covered, identify if prior authorization is required, and determine what documentation must be submitted. CRD aligns with HL7® FHIR®, Da Vinci IGs, the SMART on FHIR security framework, and CMS interoperability regulations.
New to the CRD API? The CRD API user guide (PDF) opens in a new tab explains how CDS Hooks are processed and how coverage requirements come back to the EHR.
User Guide
Capability Statement
Developers can access the Acentra Health FHIR server capabilities for the CRD API using the CapabilityStatement endpoint:
View JSONThe CapabilityStatement describes the supported profiles, interactions, and authorization and token endpoints.
API Access Setup
Clients can retrieve SMART configuration details by invoking the SMART configuration endpoint at /.well-known/smart-configuration, appended to the FHIR Base URL.
Getting an Access Token
The CRD API uses SMART Backend Services (system-to-system) authorization. Authenticate with a signed JWT client_assertion, signed with the private key that matches the public key you registered. No secret is sent over the wire. Request the token with the client_credentials grant.
| Header | Value |
|---|---|
| content-type | application/x-www-form-urlencoded |
| accept | application/json |
| Parameter | Value |
|---|---|
| grant_type | client_credentials |
| scope | {scopes} (space-separated; only scopes approved for your registration) |
| client_assertion_type | urn:ietf:params:oauth:client-assertion-type:jwt-bearer |
| client_assertion | {signed_jwt} |
| Claim | Value |
|---|---|
| iss | {client_id} |
| sub | {client_id} |
| aud | https://sb.fhir.mhbapp.com/sof/oauth2/token |
| iat | Issue time (current time, in seconds since epoch) |
| exp | Expiry; keep it short, for example 5 minutes after iat |
| jti | Unique ID. Each assertion can be used once; a repeated jti is rejected. |
access_token as the Bearer token on API requests. The sandbox also accepts client_id with client_secret for quick testing, but client_assertion is the recommended method.CDS Hooks
The CRD API supports the following CDS Hooks services.
Profiles
The CRD API supports the following profiles.
Request Headers
All requests for CRD API profiles require the following headers:
| Header | Value |
|---|---|
| content-type | application/json |
| accept | application/json |
| authorization | Bearer {access_token} |
Sample Responses & Data
Important Information for EHR Systems
| Topic | Reference |
|---|---|
| Privacy, Security and HIPAA | healthit.gov - Privacy, Security and HIPAA |
| ONC Model Privacy Notice | healthit.gov - Model Privacy Notice |