Clinical Data Exchange (CDex)
Unsolicited exchange of clinical data - FHIR resources, C-CDA documents, PDFs and more - proactively sent from providers to payer systems.
Overview
The Clinical Data Exchange (CDex) API is a FHIR-based interoperability API that enables an unsolicited data-exchange flow, where a provider proactively sends relevant clinical data to payer systems without a prior explicit request, based on a known business or clinical need.
It enables the exchange of a wide range of clinical data formats, including FHIR resources and Bundles, C-CDA documents, PDFs, and other file types.
To enable efficient exchange of large clinical documents, the CDex API supports a PreSigned URL-based attachment workflow. Clients obtain a secure, time-limited PreSigned URL to upload documents and then reference the uploaded content during CDex submission. This approach improves performance, reduces payload size, and provides a secure and scalable mechanism for exchanging large clinical attachments.
New to the CDex API? The CDex API user guide (PDF) opens in a new tab explains how unsolicited attachments are sent, using the pre-signed URL mechanism.
User Guide
Capability Statement
Developers can access the Acentra Health FHIR server capabilities for the CDex 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 CDex 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.Operations
The CDex API supports the following operations.
Profiles
The CDex API supports the following profiles.
Request Headers
All requests for CDex API profiles require the following headers:
| Header | Value |
|---|---|
| content-type | application/json |
| accept | application/json |
| authorization | Bearer {access_token} |
Sample Responses & Data
Synthetic test data is provided for PAS API. The identifiers provided to submit PAS requests can be used to obtain a PA tracking ID, which can then be used for CDex interactions. No separate test data is provided for CDex.
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 |