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

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.

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.

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

This operation is used to submit attachments (additional documentation) for claims or prior authorization. This 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., NPI)
   • A unique provider identifier (e.g., 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.

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

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

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

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

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.