Da Vinci Clinical Data Exchange (CDex)
2.1.0 - STU2
Da Vinci Clinical Data Exchange (CDex)
2.1.0 - STU2
Da Vinci Clinical Data Exchange (CDex), published by HL7 International / Payer/Provider Information Exchange Work Group. This guide is not an authorized publication; it is the continuous build for version 2.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-ecdx/ and changes regularly. See the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
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:
|
| 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:
|
| 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:
|
| 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:
|
Profiles Associated with CDex Attachments Transactions
| CDex Task Attachment Request Profile |
Payers use this Task based profile to request additional documentation ("attachments") for claims or prior authorizations. It constrains the Task resource to minimal necessary data elements needed to request attachments and respond in a way that is compatible with existing X12 277 RFAI and 278 response transactions to allow for association and requests for (typically PDF and CCDA) documents using LOINC and X12 standard codes. It also supports requests for more detailed missing data using Questionnaire, CQL, and QuestionnaireResponse, as supported by Da Vinci DTR. It constrains the following elements to be mandatory (min=1):
It constrains the following elements to be must support (min=0):
It defines the following optional elements:
* Either a "AttachmentsNeeded" or a "QuestionnairesNeeded" |
| CDex PractitionerRole Profile |
This Profile is defined as a contained resource within the CDex Task Attachment Request Profile. It is referenced by
At least a practitioner identifier or organization identifier SHALL be present. |
| CDex Patient Demographics Profile |
This Profile is defined as a contained resource 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 (such as verifying patient identity for HIPAA compliance regulations). It constrains the following elements to be mandatory (min=1):
and the following element to be must support (min=0):
|
| CDex Parameters Submit Attachment Profile |
The Parameters profile for Da Vinci Submit Attachment Operation |
Operations Associated with CDex Attachments Transactions
| Submit Attachment Operation |
Providers use this operation to submit solicited and unsolicited attachments or additional information for claims or prior authorization. The $submit-attachment operation accepts the clinical/administrative attachments and the information required to associate them with the claim or prior authorization and returns an HTTP response. For unsolicited attachments, the Provider invokes this operation before, concurrently, or after the claim or pre-authorization transaction. For solicited attachments, the Provider invokes it when responding to a Payer request for attachments or additional information. Any HTTP endpoint can use $submit-attachment, not just FHIR RESTful server endpoints. Implementers of CDex's Unsolicited Attachments SHOULD support the Endpoint Discovery Strategy defined in the Da Vinci HRex specification to allow discovery of the endpoint for this operation. For Solicited Attachments, the $submit-attachment endpoint is supplied in the CDex Task Attachment Request Profile The input parameters are:
There are no output parameters. |
ValueSets Associated with CDex Attachments Transactions
| CDex Claim Use Value Set |
The purpose of a Claim resource and the reason for attachments. It includes the codes "preauthorization" and "claim". |
| CDex LOINC Attachment Codes Value Set |
This value set includes LOINC terms that can be sent by a payer as part of an HL7 attachment request for additional information. It has been curated by the HL7 Payer/Provider Information Exchange (PIE) Work Group. More information about using LOINC in HIPAA attachments and the source of this value set can be found at LOINC Attahments. |
| CDex PWK01 Attachment Report Type Code Value Set |
In addition to using LOINC attachment codes, a payer may request for additional information from the provider to support a prior authorization request using X12's PWK01 Attachment Report Type Code. Note that the PWK01 codes will not be published in due to X12 IP restrictions. |
Examples Associated with CDex Attachments Transactions
| 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 20 |
Prior-Auth Attachment Request Example: Prior Authorization Attachment Request with a POU of "coverage authorization" sent by payer to a provider requesting a signed History and physical (H&P) note. |
| CDex Task Example 22 |
Request Additional Data using a Questionnaire: Prior Authorization Attachment Request with a POU of "coverage authorization" sent by payer to a provider requesting a data request questionnaire be completed. |
| CDex Task Example 23 |
Request Additional Data using an Adaptive Questionnaire: Prior Authorization Attachment Request with a POU of "coverage authorization" sent by payer to a provider requesting an adaptive questionnaire be completed. |
| CDex Task Example 24 |
Completed Request for Additional Data using a Questionnaire: Completed Task for CDex Task Example 22. This example has a status of "completed" and a "lastModified" date of 6/17/2022. The "reasonCode" is "request additional data" and the "output" is a QuestionnaireResponse. |
| CDex Task Example 25 |
Completed Request for Additional Data Using an Adaptive Questionnaire: Completed Task for CDex Task Example 23. This example has a status of "completed" and a "lastModified" date of 6/17/2022. The "reasonCode" is "request additional data" and the "output" is a QuestionnaireResponse. |
| CDex Task Example 28 |
Request Additional Data Requiring a Verification Signature Using a Questionnaire: Prior Authorization Attachment Request with a POU of "coverage authorization" and Signature required sent by payer to a provider requesting a data request questionnaire be completed and signed. |
| CDex Task Example 29 |
Completed Request for Additional Data Requiring a Verification Signature Using a Questionnaire: Completed Prior Authorization Attachment Request (CDex Task Example 28) with a status of "completed" and output referencing the digitally signed QuestionnaireResponse. |
| CDex Parameters Example 1 |
CCDA Attachment Example: Parameters Resource example showing how it is used to submit attachments using the |
| CDex Parameters Example 2 |
Signed FHIR Document Attachment Example: Parameters Resource example showing how it is used to submit attachments using the |
| CDex Parameters Example 3 |
PDF Attachment Example: Parameters Resource example showing how it is used to submit attachments using the |
| CDex Parameters Example 4 |
Laboratory Results Attachment Example: Parameters Resource example showing how it is used to submit multiple attachments using the |
| CDex Parameters Example 5 |
Completed QuestionnaireResponse Attachment Example: Parameters Resource example showing how it is used to submit a solicited attachment using the |
Profiles Associated with CDex Task Based Approach Transactions
| CDex Task Data Request Profile |
This Task profile is used to solicit information from a system. The Data Consumer uses it when direct query transactions are not an option, and the transaction may require human intervention. It represents both the data request and the returned "data request". Data requests are supplied as codes, free-text, or FHIR Restful queries. It can also support requests for more detailed missing data using Questionnaire, CQL, and QuestionnaireResponse as supported by Da Vinci DTR. It constrains the following elements to be mandatory (min=1):
It constrains following elements to be must support (min=0):
It defines the following elements to be optional:
It prohibits the following elements (max=0):
* Either a "query", "code", or "questionnaire" |
ValueSets Associated with CDex Task Based Approach Transactions
| 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. |
| CDex Data Request Task Code Value Set |
Codes used to identify the type of data request. It includes the codes “data-request-query”, “data-request-code”, and “data-request-questionnaire”. |
Examples Associated with CDex Task Based Approach Transactions
| 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 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 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. |
| 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 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 26 |
Data Request Using a Questionnaire: Task to seek reason for home oxygen therapy using the CDex Profile questionnaire input. This example illustrates the use of Questionnaire to request data from a data source |
| CDex Task Example 27 |
Completed Data Request Using a Questionnaire: Completed Task for CDex Task Example 26. This example has a status of "completed" and a "lastModified" date of 6/19/2022. The "output" is a QuestionnaireResponse.Task to seek reason for home oxygen therapy. |
| CDex Task Example 30 |
Data Request Requiring a Verification Signature Using Questionnaire: Task to seek reason for home oxygen therapy using the CDex Profile questionnaire input. This example illustrates the use of Questionnaire to request data from a data source and requires a digitally signed QuestionnaireResponse. |
| CDex Task Example 31 |
Completed Data Request Requiring a Verification Signature Using Questionnaire: Completed Task (CDex Task Example 30) with a status of "completed" and output referencing the digitally signed QuestionnaireResponse. |
Examples Associated with CDex Direct Query (FHIR RESTful search) Approach Transactions
| Direct Query for Patient's Active Conditions |
Bundle example used in direct query transactions scenario 1 and in task based transactions - for example, scenario 1a. |
| Direct Query Response Including Provenance |
Bundle example used in the direct query scenario that includes the corresponding Provenance records. Payer Seeks Insured Person/Patient Active Conditions from Provider to support a claims audit. |
| Direct Query for Patient's Progress Notes |
Bundle example used in direct query scenario 3. Payer Seeks Insured Person/Patient Progress Notes from Provider to support a claim submission. |
| Direct Query for Patient's HbA1c Test Results |
Bundle example used in direct query scenario 2. Payer Seeks Insured Person/Patient HbA1c Test Results from Provider |
Questionnaire profiles used in both CDex Attachments and Task Based Approach Transactions
| CDex SDC QuestionnaireResponse Profile |
This profile is derived from the US Core QuestionnaireResponse Profile profile and enforces the various elements of signature documented in the CDex guide to represent an enveloped signature. It adds the following constraints:
|
Questionnaire examples used in both CDex Attachments and Task Based Approach Transactions
| CDex Questionnaire Example1 |
This example is a simple data request Questionnaire used in the Task Based and Attachments transactions. It is adapted from the Da Vinci DTR IG. |
| CDex QuestionnaireResponse Example1 |
This Questionnaire Response example demonstrates the response to a CDEX Data Query or Attachments that uses a Questionnaire to request the data. It is adapted from the Da Vinci DTR IG. |
| CDex QuestionnaireResponse Example2 |
This Questionnaire Response example demonstrates the response to a CDEX Data Query or Attachments that uses a Questionnaire to request the data. The Questionnaire is an adaptive questionnaire and the resulting QuestionnaireResponse contains the generated Questionnaire instance. This example is adapted from the Da Vinci DTR IG. For more information about adaptive questionnaires in FHIR see the SDC Implementation Guide. |
Profiles Associated with CDex Signatures
| CDex Signature Profile |
This Signature DataType profile enforces the various elements of signature documented in the CDex guide. It adds the following mandatory (min=1) constraints:
In addition, the following mandatory (min=1) element is inherited from the base standard:
|
| CDex Signature Bundle Profile |
This Bundle profile enforces the various elements of signature documented in the CDex guide to represent an enveloped signature. It adds the following mandatory (min=1) constraint:
|
ValueSets Associated with CDex Signatures
| CDex Identifier Types Value Set |
Identifier types for providers and organizations. It includes the codes “TAX” and “NPI”. |
Examples Associated with CDex Signatures (Several examples are in Task Based and Attachments Examples groupings as well)
| 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 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 Questionnaire Example2 |
This example is a simple data request Questionnaire used in the Task Based and Attachments transactions. It indicates that a verification signature is needed when completing the QuestionnaireResponse. It is adapted from the Da Vinci DTR IG. |
| CDex QuestionnaireResponse Example3 |
This Questionnaire Response example demonstrates the response to a CDEX Data Query or Attachments that uses a Questionnaire to request the data when an electronic verification signature is required. It is adapted from the Da Vinci DTR IG. The electronic signature is an image file in the QuestionnaireResponse signature extension. This example is adapted from the Da Vinci DTR IG. |
| CDex QuestionnaireResponse Example4 |
This Questionnaire Response example demonstrates the response to a CDEX Data Query or Attachments that uses a Questionnaire to request the data and an electronic digital Verification signature is required. It is adapted from the Da Vinci DTR IG. The digital signature is a JSON FHIR Signature in the QuestionnaireResponse signature extension. This example is adapted from the Da Vinci DTR IG. |
ValueSets and CodeSystems used in both CDex Attachments and Task Based Approach Transactions
| CDex Purpose of Use Value Set |
The set of purpose of use (POU) codes for requesting data. This code set is composed of FHIR core Purpose of Use security labels and additional codes defined by this 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). |
These examples are used in the inline example scenarios throughout the guide. They are listed here so the implementation guide's publication tooling can validate them against the CDex profile definitions. Since they are used to illustrate "over-the-wire" transactions, the rendered narrative and id elements are often absent.
IG © 2024+ HL7 International / Payer/Provider Information Exchange Work Group. Package hl7.fhir.us.davinci-cdex#2.1.0 based on FHIR 4.0.1. Generated 2024-11-18
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change