CDex — Clinical Data Exchange

CDex (Da Vinci Clinical Data Exchange) is the FHIR IG for payer-initiated clinical data requests. When a payer needs clinical documentation from a provider — to adjudicate a claim, support a prior authorization decision, conduct a risk adjustment review, or respond to an audit — CDex defines how that request is made and how the provider responds.

The key inversion: CDex is payer-initiated, provider-responds. Most other FHIR exchange patterns are provider-initiated (the EHR sends data to a payer or queries a payer). CDex handles the reverse direction, where the payer’s system drives the data collection workflow.

CDex is part of the Da Vinci Project’s administrative burden reduction stack. It replaces the fax-and-phone documentation request process for claims adjudication and PA. For the full prior authorization workflow (CRD → DTR → PAS), see Prior Authorization Workflow. CDex handles the follow-up documentation that payers request after a claim or PA has been submitted.

CDex vs PDex: CDex (payer requests data from provider) is the reverse of PDex (Payer Data Exchange, where data flows from payer to patient or to a new payer during coverage transition). CDex is about clinical documentation for administrative purposes; PDex is about portability of claims history and coverage data for members. Both are Da Vinci IGs built on HREX, but they serve opposite data flow directions.

Exchange patterns

CDex defines three exchange patterns. Each is suited to different scenarios based on latency requirements, provider system capabilities, and the nature of the data being requested.

1. Direct query

The payer directly queries the provider’s FHIR server for specific resources:

GET [provider-base]/Observation?patient=Patient/123&category=laboratory&date=ge2024-01-01

When to use: The payer knows exactly what data it needs, the provider has a FHIR server accessible to the payer, and the data is available as discrete FHIR resources.

Constraints: The payer must be authorized to query the provider’s server (SMART Backend Services). The data must be in discrete FHIR form — not in scanned documents or unstructured notes. Not all provider systems expose a queryable FHIR endpoint to external payers.

Direct query is the simplest pattern but has the narrowest applicability in practice. Most providers don’t expose their FHIR servers to payer systems, and much clinically relevant documentation is not in discrete FHIR form.

2. Task-based exchange

The payer creates a Task on the provider’s FHIR server (or sends it via an intermediary). The Task describes what documentation is needed. The provider system processes the Task — automatically or with human review — and attaches the response.

When to use: The payer needs documentation that requires provider staff involvement, or the data needs to be reviewed before release. This is the most broadly applicable CDex pattern.

Key characteristic: Asynchronous. The payer creates the Task and polls (or subscribes) for completion. The provider may have days to respond depending on the use case and any applicable regulations.

3. Attachments (solicited and unsolicited)

Solicited attachments: The payer asks for specific documentation to support a submitted claim or PA request. The provider submits the documentation in response. This is equivalent to the legacy Additional Documentation Request (ADR) process, but via FHIR.

Unsolicited attachments: The provider proactively sends documentation with a claim or PA submission without waiting to be asked. For example, attaching lab results with a claim for a service that typically requires supporting documentation.

Both attachment patterns use a Claim or ClaimResponse as the anchor — the documentation is tied to a specific claim or PA request by reference.

Use cases

Use case	Pattern	Who requests	What is returned
Claims adjudication documentation	Solicited attachment / Task	Payer	Clinical notes, lab results, imaging reports
Prior authorization documentation	Task / Solicited attachment	Payer	DTR QuestionnaireResponse, supporting clinical records
Risk adjustment	Task	Payer (MA plan)	Problem list, diagnoses, encounter notes
Quality reporting (HEDIS)	Task / Direct query	Payer	Preventive care records, HbA1c results
Audit (RAC, OIG)	Task	Auditor	Complete encounter documentation
Coordination of benefits	Direct query / Task	Payer	Previous claims, coverage history

Claims adjudication

When a claim is submitted for a service with significant cost or clinical complexity, the payer may request medical records to validate medical necessity. CDex standardizes this: the payer sends a solicited attachment request referencing the submitted claim; the provider responds with the relevant documentation within a specified timeframe.

CMS-0057-F (for Medicare Advantage and Medicaid) and applicable state regulations set timeframes for provider response to attachment requests.

Risk adjustment

Medicare Advantage plans conduct retrospective clinical reviews to validate diagnosis codes that affect their risk scores. CDex provides the mechanism for these annual chart review requests. The payer sends a Task identifying the patient and the review period; the provider responds with encounter documentation supporting the submitted diagnoses.

Prior authorization follow-up

When a PA request is pended pending additional documentation, CDex handles the follow-up. The payer sends a solicited attachment request; the provider attaches the additional clinical documentation. This is distinct from the initial PA submission via PAS — it is the back-and-forth that occurs when a synchronous PA decision cannot be made.

HREX as the foundation

CDex builds on HREX (Da Vinci Health Record Exchange), the base IG for all Da Vinci administrative exchange. HREX defines:

Authentication: SMART Backend Services for system-to-system authentication without user presence
Authorization: OAuth2 scopes for payer-initiated requests
Task profiles: Base Task profiles extended by CDex for specific request types
Coverage reference: How to link data requests to a specific member’s coverage

CDex-specific profiles extend HREX profiles. When implementing CDex, HREX conformance is a prerequisite.

Member match in CDex context: When a payer initiates a CDex request, it must identify which patient at the provider matches the payer’s member. HREX defines a $member-match operation for this: the payer sends patient demographics and coverage details, and the provider system returns a matched patient identifier. This is necessary because payers identify members by member ID while providers identify patients by MRN or other local identifiers. Without member match, the payer cannot reliably address a CDex Task to the correct patient record.

Task workflow

Task-based exchange is the core of CDex. Understanding the Task lifecycle is essential for both payer (requester) and provider (responder) implementations.

Task creation

The payer creates (or sends) a Task to the provider’s system describing what documentation is needed:

{
  "resourceType": "Task",
  "id": "cdex-task-001",
  "meta": {
    "profile": ["http://hl7.org/fhir/us/davinci-cdex/StructureDefinition/cdex-task-attachment-request"]
  },
  "status": "requested",
  "intent": "order",
  "code": {
    "coding": [
      {
        "system": "http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp",
        "code": "attachment-request-questionnaire",
        "display": "Attachment Request Questionnaire"
      }
    ]
  },
  "for": {
    "reference": "Patient/patient-001",
    "identifier": {
      "system": "http://www.acmeinsurance.com/member-id",
      "value": "MEMBER-456"
    }
  },
  "authoredOn": "2025-03-15T10:00:00Z",
  "requester": {
    "reference": "Organization/payer-acme"
  },
  "owner": {
    "reference": "Organization/provider-clinic"
  },
  "reasonCode": {
    "coding": [
      {
        "system": "http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp",
        "code": "claim",
        "display": "Claim"
      }
    ]
  },
  "reasonReference": {
    "identifier": {
      "system": "http://www.acmeinsurance.com/claim-id",
      "value": "CLM-2025-789"
    }
  },
  "input": [
    {
      "type": {
        "coding": [
          {
            "system": "http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp",
            "code": "questionnaire"
          }
        ]
      },
      "valueCanonical": "https://payer.example.org/fhir/Questionnaire/claims-attachment-01"
    }
  ]
}

input types

input describes what the payer is requesting. CDex defines several input types:

Input type code	What it requests
`questionnaire`	A specific Questionnaire URL — provider fills it out
`data-code`	A FHIR resource type and code — provider returns matching resources
`data-query`	A full FHIR query string — provider executes and returns results

questionnaire is the most prescriptive — the payer defines exactly what information is needed via a FHIR Questionnaire, similar to DTR. data-code and data-query are more flexible — the payer specifies what kind of data is needed and the provider’s system determines which resources satisfy the request.

Task status lifecycle

requested → accepted → in-progress → completed
         → rejected (provider declines the request)
         → failed (provider cannot fulfill the request)
         → on-hold (additional information needed)
         → cancelled (payer withdraws the request)

Provider systems must update Task status as processing progresses. The payer polls Task status (or subscribes via FHIR Subscriptions) to detect completion.

accepted: The provider’s system has received the Task and intends to fulfill it. in-progress: Active work has begun (e.g., staff is reviewing records). completed: The documentation is attached in Task.output. on-hold: The provider needs more information or time — a statusReason should explain why. rejected: The provider declines the request (with reason).

output — attaching the documentation

When the Task is complete, the provider adds output with references to the documentation:

"output": [
  {
    "type": {
      "coding": [
        {
          "system": "http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp",
          "code": "questionnaire-response"
        }
      ]
    },
    "valueReference": {
      "reference": "QuestionnaireResponse/qr-claim-attach-001"
    }
  },
  {
    "type": {
      "coding": [
        {
          "system": "http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp",
          "code": "clinical-note"
        }
      ]
    },
    "valueReference": {
      "reference": "DocumentReference/note-encounter-2025-03-10"
    }
  }
]

Output can reference QuestionnaireResponse (for questionnaire-based requests), DocumentReference (for clinical notes, imaging reports), or discrete FHIR resources (Observation, Condition, etc.).

Polling vs subscription

The payer has two options to detect when a Task is complete:

Polling: The payer periodically GETs the Task resource to check status. Simple to implement but creates load on the provider’s server. Polling interval should be agreed upon by trading partners.

FHIR Subscriptions: The provider’s system sends a notification to the payer when the Task status changes. Lower latency than polling, but requires the payer to host a subscription notification endpoint. FHIR R4 Subscriptions use a channel (rest-hook, websocket, email); R5 improves the subscription model significantly.

In practice, polling is more widely implemented. The CDex IG supports both.

Solicited attachments

Solicited attachments are the CDex pattern for responding to a payer’s documentation request tied to a submitted claim or PA request:

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "AttachTo",
      "part": [
        {
          "name": "TrackingId",
          "valueIdentifier": {
            "system": "http://acmeinsurance.com/claim-id",
            "value": "CLM-2025-789"
          }
        },
        {
          "name": "PayerId",
          "valueIdentifier": {
            "system": "http://hl7.org/fhir/sid/us-npi",
            "value": "1234567890"
          }
        }
      ]
    },
    {
      "name": "Attachment",
      "part": [
        {
          "name": "LineItem",
          "valuePositiveInt": 1
        },
        {
          "name": "Code",
          "valueCodeableConcept": {
            "coding": [
              {
                "system": "http://loinc.org",
                "code": "11506-3",
                "display": "Progress note"
              }
            ]
          }
        },
        {
          "name": "Content",
          "resource": {
            "resourceType": "DocumentReference",
            "status": "current",
            "content": [
              {
                "attachment": {
                  "contentType": "application/pdf",
                  "data": "[base64-encoded-pdf]"
                }
              }
            ]
          }
        }
      ]
    }
  ]
}

The $submit-attachment operation posts this Parameters bundle to the payer’s CDex endpoint. TrackingId links the attachment to the original claim. LineItem specifies which line item the documentation supports.

Unsolicited attachments

Unsolicited attachments follow the same $submit-attachment operation but are sent proactively with the original claim submission or immediately after it, without a prior payer request. The TrackingId links to the claim. The provider anticipates what documentation will be needed and sends it without waiting for the payer to ask.

Unsolicited attachments reduce the likelihood of a solicited attachment request — which requires additional provider effort and delays adjudication. For services where documentation requirements are predictable (oncology, complex surgical procedures, durable medical equipment), sending attachments upfront is more efficient.

The legacy equivalent of unsolicited attachments is the X12 275 transaction (Additional Information to Support a Health Care Claim). CDex’s $submit-attachment is the FHIR replacement for X12 275 in the unsolicited direction.

Authentication: SMART Backend Services

CDex system-to-system exchange uses SMART Backend Services (also called SMART App Launch for Backend Services or B2B OAuth). This is server-to-server authentication without a human user present.

The flow:

The payer system generates an asymmetric key pair. The public key is registered with the provider’s authorization server.
When the payer needs to make a request, it creates a signed JWT (JSON Web Token) using its private key and sends it to the provider’s token endpoint.
The provider’s auth server verifies the JWT signature against the registered public key and issues an access token.
The payer uses the access token as a Bearer token in subsequent FHIR requests.

POST /token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJSUzM4NCJ9...
&scope=system/Task.write system/Patient.read system/DocumentReference.read

SMART Backend Services scopes for CDex:

Scope	Purpose
`system/Task.write`	Create and update Tasks
`system/Task.read`	Read Task status
`system/Patient.read`	Read patient demographics
`system/DocumentReference.read`	Read clinical notes
`system/Observation.read`	Read clinical observations

The payer’s access is scoped — it can only read the resources it is authorized to access. The provider’s authorization server enforces scope boundaries.

CDex vs DTR for PA documentation

Both CDex and DTR collect clinical documentation from providers using FHIR Questionnaires. The difference is timing and initiation:

	DTR	CDex
When	During ordering workflow (before PA submission)	After claim/PA submission (follow-up)
Initiated by	EHR triggers DTR launch from CRD card	Payer sends Task or attachment request
Integration point	Embedded in ordering workflow	External request to provider system
Response destination	QuestionnaireResponse → PAS submission	QuestionnaireResponse → Task output or $submit-attachment

Use DTR to gather documentation before PA submission. Use CDex when the payer needs additional documentation after a claim or PA has been submitted.

Implementation considerations

Determine which patterns your trading partners support. Not all payers implement all CDex patterns. Some implement Task-based exchange; some implement only the $submit-attachment operation. Confirm which patterns your specific payer partners support before designing your provider-side implementation.

Task delivery: push vs hosted. There are two ways a payer sends a Task to a provider:

Push: The payer POSTs the Task directly to the provider’s FHIR server. Requires the provider to expose a Task endpoint accessible to payers.
Hosted: An intermediary hosts the Task; the provider polls the intermediary for pending Tasks. More practical for providers who can’t expose FHIR endpoints to external systems.

Most implementations use an intermediary (clearinghouse or CDex-capable health information network).

Status response timeframes matter. Regulatory and contractual timeframes apply to documentation response. For Medicare Advantage, providers typically have 30 days to respond to retrospective documentation requests. For claims adjudication attachments, the payer’s ADR process sets the timeframe. Provider systems that don’t surface CDex Task requests to staff in a timely way will miss response windows.

Binary vs structured output. Providers can respond to CDex requests with either structured FHIR resources (Observation, Condition, DocumentReference with FHIR content) or binary attachments (PDF, TIFF, HL7 CDA). Structured responses are preferred — they are machine-readable and support automated processing. Binary PDFs require manual review by payer staff and do not support automated adjudication.

Common mistakes

Not surfacing Task requests to clinical staff. CDex Tasks received by a provider system need to reach the staff who can fulfill them. A Task that sits unnoticed in a FHIR server queue is indistinguishable from one that was never received. Workflow integration — routing incoming Tasks to the appropriate inbox or work queue — is as important as the FHIR mechanics.

Responding with PDFs when structured data is available. Sending a PDF scan of a chart when the underlying data is available as FHIR resources forces the payer into manual review. Payers that support automated CDex processing cannot process binary attachments automatically. When discrete data is available, return discrete FHIR resources.

Conflating CDex with DTR. Both collect clinical documentation using Questionnaires, but they operate at different points in the workflow and serve different purposes. DTR is integrated into the EHR ordering workflow and feeds PA submission. CDex is an external payer request after submission. Implementing one does not substitute for the other.

Not scoping SMART Backend Services tokens correctly. Overly broad scopes on payer access tokens create a privacy and security risk. The payer should only have access to the patient records it has a legitimate reason to access. Token scope should be patient-specific and resource-type-specific, not system/*.read.

Ignoring on-hold status. When a provider’s system sets Task status to on-hold, it should include a statusReason explaining why. Payers that don’t monitor on-hold Tasks may wait indefinitely for a response that won’t come without additional action.

CDex — Clinical Data Exchange

CDex — Clinical Data Exchange

Exchange patterns

1. Direct query

2. Task-based exchange

3. Attachments (solicited and unsolicited)

Use cases

Claims adjudication

Risk adjustment

Prior authorization follow-up

HREX as the foundation

Task workflow

Task creation

input types

Task status lifecycle

output — attaching the documentation

Polling vs subscription

Solicited attachments

Unsolicited attachments

Authentication: SMART Backend Services

CDex vs DTR for PA documentation

Implementation considerations

Common mistakes

See also