This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Consumer (often a Payer) in Client mode when requesting clinical data from the Data Source (often an EHR) during a clinical data exchange. This includes the following interactions:

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

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Consumer (often a Payer) in Server mode when responding to a Data Source (often an EHR) or one of its proxies during a clinical data exchange. This includes the following interactions:

1. Responding to a query for authorization information represented by a CommunicationRequest or ServiceRequest
2. Responding to subscription notification posted to it endpoint updating the status of a task
3. Responding to $submit-attachment operation.

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Source (often an EHR) in Client mode during a clinical data exchange with a Data Consumer. This includes the following interactions:

1. POSTing the $submit-attachment operation to exchange clinical data using a FHIR based Attachments transaction.
2. Query for Authorization information represented by a CommunicationRequest or ServiceRequest.
3. Posting a subscription notification to a Data Consumer endpoint updating the status of a Task.

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Source (often an EHR) in Server mode when responding to a Data Consumer (often a Payer) during a clinical data exchange. This includes 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

This operation is used to submit attachments (aditional information) for Claims or Prior Authorization. This operation accepts the clinical/administrative attachments and the necessary information needed to re-associate them to the claim or prior authorization, and returns a transaction layer HTTP response. 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
2. Data elements for reassociation to the Claim/Prior Authorization
   • What is the documentation for:
     • Claim
     • Prior Authorization
   • A unique claim/prior authorization identifier (referred to as the “re-association tracking control numbers”)*
   • Optionally, one or more unique claim line item identifiers
   • A unique organization/location identifier (e.g., NPI)
   • A unique provider identifier (e.g., NPI)
   • A unique Patient member identifier
   • Date of Service

There are no output parameters.

This Task profile is based upon the Da Vinci Hrex Task Data Request. It adds the following additional constraints for CDEX:

• A ‘meta.tag’ element representing work-queue hints.
• A Task.input element slice representing the types of documents to be returned using the extensible LOINC® Document types value set.
• A Task.input element slice representing a flag to indicate whether the requested data requires a signature.
• A Task.input element slice representing the purpose of use for the requested data using an extensible 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 FHIR core Purpose of Use security labels and additional codes defined by this Guide.

The set of codes is used in the $submit-attachment operation for identifying the reason for attachments

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

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).

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 an digital signature was required. If no signature was required, the response would typically be in the form of an individual resource.

Electronic signature example showing how a image file can be use 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.

Completed Task to seek a patient active conditions with a reference to a formal authorization.

Task to seek a patient active conditions with a reference to a formal authorization.

Completed Task to seek a patient active conditions using free text for the input.

Task to seek a patient active conditions using free text for the input.

Completed Task to seek a patient active conditions using a contained resource for the output data.

Completed Task to seek a patient active conditions.

Task to seek a patient active conditions.

Completed Task to seek a patient active conditions and their provenance using free text for the input.

Completed Task to seek a patient active conditions their provenance.

Task to seek a patient active conditions using Task.input signature parameter to indicate a signature is required.

Completed Task to seek a signed patient active conditions.

Task to seek a patient’s HbA1c test results with a failed status.

Task to seek a patient’s HbA1c test results.

Completed Task to seek a patient’s latest history and physical exam notes using a contained resource for the output data.

Task to seek a patient’s latest history and physical exam notes.

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

Parameters Resource example showing how it is used when the $submit-attachment operation is invoked. It represents the collection of named parameters including the “attachment” (additional information) and data to re-associate the attachmenet to a claim or prior authorization.