Da Vinci Clinical Data Exchange (CDex)
2.0.0-preview - CI Build United States of America flag

Da Vinci Clinical Data Exchange (CDex), published by HL7 International - Patient Care Work Group. This is not an authorized publication; it is the continuous build for version 2.0.0-preview). This version is based on the current content of https://github.com/HL7/davinci-ecdx/ and changes regularly. See the Directory of published versions

Artifacts Summary

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Behavior: Capability Statements

The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.

Data Consumer Client CapabilityStatement

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Consumer in Client mode when requesting clinical data from the Data Source during clinical data exchange. The capabilities include one or more of the following interactions:

  1. Requesting Clinical Data using a FHIR RESTful query
  2. Requesting Attachments
  3. POSTing a Task resource representing a request for clinical data
  4. POSTing a Subscription resource
  5. Polling a Task resource
Data Consumer Server CapabilityStatement

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Consumer in Server mode when responding to a Data Source or one of its proxies during clinical data exchange. The capabilities include one or more of the following interactions:

  1. Responding to a query for authorization information represented by a CommunicationRequest or ServiceRequest
  2. Responding to the $submit-attachment operation.
Data Source Client CapabilityStatement

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Source in Client mode during clinical data exchange with a Data Consumer. The capabilities include one or more of the following interactions:

  1. Post the $submit-attachment operation to a Data Consumer endpoint.
  2. Query for Authorization information represented by a CommunicationRequest or ServiceRequest.
  3. Post a subscription notification to a Data Consumer endpoint updating the status of a task.
Data Source Server CapabilityStatement

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Source in Server mode when responding to a Data Consumer during clinical data exchange. The capabilities include one or more of the following interactions:

  1. Responding to a FHIR RestFul Query for Clinical Data
  2. Responding to a POST of a Task resource representing a request for clinical data
  3. Responding to a POST of a Subscription resource
  4. Responding to polling of a Task resource

Behavior: Operation Definitions

These are custom operations that can be supported by and/or invoked by systems conforming to this implementation guide

Submit Attachment Operation

This operation is used to submit attachments (additional documentation) for claims or prior authorization. The $submit-attachm,ent operation accepts the clinical/administrative attachments and the necessary information needed to associate them to the claim or prior authorization and returns a transaction layer HTTP response. The operation may be invoked before, at the same time as, or after the claim or pre-authorization has been supplied to the Payer. This operation can be used by any HTTP endpoint, not just FHIR RESTful servers.

The input parameters are:

  1. One or more attachments as FHIR Resources
    • Optionally, one or more unique line item numbers associated with the attachment
    • Optionally, the code, free text, or search string for information that was requested
  2. Data elements for the association to the claim/prior authorization
    • A unique identifier that ties the attachment(s) back to the claim or prior authorization. (referred to as the “re-association tracking control numbers”)*
    • What are the attachments for:
      • Claims
      • Prior Authorizations
    • Optionally, a unique payer identifier
    • A unique organization/location identifier (e.g., Type 2 NPI) and/or unique provider identifier (e.g., Type 1 NPI)
    • A unique Patient member identifier
    • A Date of Service
    • A Flag indicating whether the operation is the last attachment submission for the claim or prior authorization.

There are no output parameters.

Structures: Resource Profiles

These define constraints on FHIR resources for systems conforming to this implementation guide

CDex Patient Demographics Profile

This Profile is defined to be contained within the CDex Task Attachment Request Profile or CDex Task Data Request Profile. It is referenced when additional patient demographic data is communicated for a clinical data request (for example, to verify patient identity for HIPAA compliance regulations). It constrains the following elements to be mandatory (min=1):

  • A default resource ID of “patient”
  • A member ID identifier slice
  • A patient’s name

and the following element to be must support (min=0):

  • A patient account number identifier slice
  • A date of birth
CDex Signature Bundle Profile

This Bundle profile enforces the various elements of signature documented in the CDex guide. It adds the following mandatory (min=1) constraints:

  • A Bundle.signature element representing the enveloped signature
  • A Bundle.signature.type fixed to ASTM Standard, E1762-95(2013) code = “1.2.840.10065.1.12.1.5” (Verification Signature)
  • A Bundle.signature.who for the organization or practitioner who signed the Bundle which is either:
    1. a reference to US-Core Practitioner, PractitionerRole or Organization or
    2. an NPI or Tax ID and name of the organization or practitioner
  • A Bundle.signature.data representing base64 encoded JWS-Signature

In addition, the following mandatory (min=1) element is inherited from the base standard:

  • Bundle.signature.when - system timestamp when the signature was created
CDex Task Attachment Request Profile

This Task based profile is used by Payers to request additional documentation for claims or prior authorizations. It constrains the Task resource to minimal necessary data elements needed to request attachments and is compliant with HIPAA Attachment rules for CMS and an alternative to the X12n 277 and 278 response transactions.

It constrains the following elements to be mandatory (min=1):

  • A contained Patient Resource defined by the CDex Patient Demographics Profile and communicating additional patient demographic data elements.
  • A Task.identifier element representing the payers tracking identifier (referred to as the “re-association tracking control numbers”)
  • A Task.status with a required binding to HRex Task Status ValueSet (this element is a mandatory Task element)
  • A Task.intent fixed to “order” (this element is a mandatory Task element)
  • A Task.code fixed to “attachment-request” to communicate that the Payer is requesting attachments for a claim or prior-authorization and is expecting they will be submitted using the $submit-attachment operation to the endpoint provided in the “payer-url” input parameter.
  • A Task.requester.identifier element representing the Payer ID
  • A Task.owner.identifier element representing the Provider ID
  • A Task.for.reference element fixed to “#string” - a reference the contained Patient Resource
  • A Task.reasonCode to communicate whether the attachments are for a Claim or Prior Authorization
  • A Task.reasonReference.reference referencing the Claim or Prior Authorization ID (business Identifier)
  • A Task.input element to communicate to the provider what attachments are needed using LOINC attachment codes
    • An extension representing line item numbers in the Claim or Prior Authorization
  • A Task.input element representing the Payer endpoint URL to communicate to the provider to submit the attachments using the $submit-attachment operation
  • A Task.input element representing the date of service or starting date of the service for the claim or prior authorization

and the following elements to be must support [min=0]:

  • A Task.Restriction.period element representing the due date for submitting the attachments
  • A Task.statusReason.text to communicate the reason for the status (e.g., if it is rejected or failed)
  • A Task.input element representing a flag to indicate whether the requested data requires a signature

and the following elements to be optional:

  • A Task.input element representing a flag to indicate whether the requested data can be sent in multiple submissions
CDex Task Data Request Profile

This Task profile is based upon the Da Vinci HRex Task Data Request. It adds the following must support constraints for CDex:

  • A Task.identifier element representing the unique data request identifier
  • A Task.for.reference.identifier element representing a patient business identifier like a Member ID
  • A Task.requester.reference.identifier element representing the Payer business identifier
  • A Task.owner.reference.identifier element representing the Provider business identifier
  • A Task.reasonReference.reference.identifier for the claim, pre-auth or coverage business identifier
  • For the “code” Task.input element, an extensible LOINC® Document types value set to communicate the specific information being requested
  • A Task.input element representing a flag to indicate whether the requested data requires a signature

In addition, the following optional constraint:

  • A meta.tag element representing work-queue hints.
  • A Task.input element representing the purpose of use for the requested data using an extensible CDex Purpose of Use Value Set

Terminology: Value Sets

These define sets of codes used by systems conforming to this implementation guide

CDex Purpose of Use Value Set

The set of purpose of use codes for the requested data (the output of the task). This code set is composed of FHIR core Purpose of Use security labels and additional codes defined by this Guide.

CDex Claim Use Value Set

The purpose of a Claim resource and the reason for attachments. It includes the codes “preauthorization” and “claim”.

CDex Identifier Types Value Set

Identifiers type for providers and organizations limited to NPI or US Tax id.

CDex Work Queue Value Set

The set work queue tags that the provider may use in their workflow to process requests. This code set is composed of codes defined by this Guide.

Terminology: Code Systems

These define new code systems used by systems conforming to this implementation guide

CDex Temporary Code System

Codes temporarily defined as part of the CDex implementation guide. These will eventually migrate into an officially maintained terminology (likely HL7’s UTG code systems).

Example: Example Instances

These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like

CDEX Document with Digital Signature Example

Digital signature example showing how it is used to sign a FHIR Document. The CDEX use case would be the target resource in response to a Task-based request where a digital signature was required. If no signature was required, the response would typically be in the form of an individual resource.

CDEX Document with Electronic Signature Example

Electronic signature example showing how an image file can be used to sign a document Bundle. The CDEX use case would be the target resource in response to a Task-based request where an electronic signature was required. If no signature was required, the response would typically be in the form of an individual resource.

CDex Parameters Example1

CCDA Attachment Example: Parameters Resource example showing how it is used to submit attachments using the $submit-attachment operation. It contains a CCDA attachment and the necessary information needed to associate them to the claim.

CDex Parameters Example 2

Signed FHIR Document Attachment Example: Parameters Resource example showing how it is used to submit attachments using the $submit-attachment operation. It contains a Signed FHIR Document attachment and the necessary information needed to associate it to a prior authorization.

CDex Parameters Example 3

PDF Attachment Example: Parameters Resource example showing how it is used to submit attachments using the $submit-attachment operation. It contains a PDF attachment and the necessary information needed to associate them to the claim.

CDex Parameters Example 4

Laboratory Results Attachment Example: Parameters Resource example showing how it is used to submit multiple attachments using the $submit-attachment operation. It contains 3 Hemoglobin A1c results as attachments and the necessary information needed to associate them to the claim.

CDEX SearchSet Bundle with Digital Signature Example

Digital signature example showing how it is used to sign a search set Bundle. The CDEX use case would be a response to a Direct Query where a digital signature was required.

CDex Task Example 1

Query String Request for Condition: Task to seek a patient’s active conditions using the CDex Profile query input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 10

Coded Request for A1C Results: Task to seek a patient’s HbA1c test results using the CDex Profile query input. This example illustrates the use of FHIR resource references to the various actors.

Cdex Task Example 11

Query String Request for Condition with Authorization: In this provider to provider request, a Task is used to request a patient active conditions using the CDex Profile query input. A reference to a formal authorization is provided. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 12

Completed Query String Request for Condition with Authorization: In this completed provider to provider request, a Task is used to request a patient active conditions using the CDex Profile query input. A reference to a formal authorization is provided. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 13

Free Text Request for Condition with Provenance: Task to seek a patient active conditions and its provenance using free text in the CDex Profile code input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 14

Completed Free Text Request for Condition with Provenance: Completed Task to seek a patient active conditions and its provenance using free text in the CDex Profile code input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 15

Query String Request for Condition with Provenance: Task to seek a patient active conditions and its provenance using query string in the CDex Profile query input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 16

Completed Query String Request for Condition with Provenance: Completed Task to seek a patient active conditions their provenance using the CDex Profile query input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 17

Query String Request for Signed Condition Data: Task to seek a patient active conditions using the CDex Profile query input and using the signature input to indicate a signature is required. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 18

Completed Query String Request for Signed Condition Data: Completed Task to seek a signed patient active conditions. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 19

Claim Attachment Request Example: Claim Attachment Request sent by payer to a provider requesting a signed Progress note (H&P) note

Cdex Task Example 2

Completed Query String Request for Condition: Completed Task to seek a patient active conditions using the CDex Profile query input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 20

Prior-Auth Attachment Request Example: Prior Authorization Attachment Request sent by payer to a provider requesting a signed History and physical (H&P) note

Cdex Task Example 21

Coded Request for Surgical Operation Note: Task to seek a patient’s latest operative notes using the CDex Profile code input. This example illustrates the use of FHIR resource references to the various actors.

Cdex Task Example 3

Completed Query String Request for Condition with Contained Output: Completed Task to seek a patient active conditions using the CDex Profile query input and using a contained resource for the output data. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 4

Free Text Request for Condition: Task to seek a patient active conditions using free text in the CDex Profile code input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 5

Completed Free Text Request for Condition: Completed Task to seek a patient active conditions using free text for the input in the CDex Profile code input. This example illustrates the use of business identifiers (instead of pointing to a FHIR resource) to references the various actors.

Cdex Task Example 6

Coded Request for Progress note: Task to seek a patient’s latest Progress notes using the CDex Profile code input. This example illustrates the use of FHIR resource references to the various actors.

Cdex Task Example 7

Completed Coded Request for Progress note - PDF: Completed Task to seek a patient’s latest Progress notes using the CDex Profile code input. This example illustrates the use of FHIR resource references to the various actors. The output data is a contained DocumentReference with an inline base64 encoded PDF document.

Cdex Task Example 8

Completed Coded RequestOperative note -CCDA: Completed Task to seek a patient’s Operative notes using the CDex Profile code input. This example illustrates the use of FHIR resource references to the various actors. The output data is a contained DocumentReference with an inline base64 encoded CCDA document.

Cdex Task Example 9

Failed Coded Request for A1C Results: Task to seek a patient’s HbA1c test results using the CDex Profile query input with a failed status. This example illustrates the use of FHIR resource references to the various actors.