Da Vinci Clinical Data Exchange (CDex)
2.1.0 - STU 2.1 United States of America flag

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

Conforming to CDex Attachments

Page standards status: Trial-use

Introduction

CDex attachments are intended to be compatible with the X12n transactions and designed to work for both solicited and unsolicited claims and prior authorization. Refer to the CDex CapabilityStatements resources for conformance expectations for the various actors and roles. The tables below show:

  • The CDex Attachments interaction for each role and the conformance resource and terminology that makes it unique to help clarify the different use cases.
  • The optional and required capabilities for CDex Attachments transactions.
  • The optional and required $submit-attachment Parameters

Systems might choose some or all of these capabilities and implement any combination of unsolicited or solicited attachments for prior authorization, claims, or both. Therefore, in contrast to the expectations in the CDex CapabilityStatements, they SHOULD define what they support in their local capability statement in one or more of the following ways:§

  1. (Preferred) Formally derived implementable profile from CDex Task Attachment Request Profile
  2. Document their systems' capabilities for requesting attachments in CapabilityStatement.rest.resource.documentation for the Task resource.
  3. (Preferred) Formal OperationDefinition derived from $submit-attachment
  4. Document their systems' capabilities for submitting attachments in CapabilityStatement.rest.documentation

Provider Conformance

Provider in Role of Data Source Server

Data Source Server Unsolicited Claims Solicited Claims Unsolicited Prior Authorization Solicited Prior Authorization
CDex Task Attachment Request Profile ✘ ✔ ✘ ✔
Task.reasonCode Terminology - claim - preauthorization

Provider in Role of Data Source Client

Data Source Client Unsolicited Claims Solicited Claims Unsolicited Prior Authorization Solicited Prior Authorization
Submit Attachment Operation ✔ ✔ ✔ ✔
AttachTo parameter Terminology claim claim preauthorization preauthorization

Payer Conformance

Payer Data Consumer Server Role

Data Consumer Client Unsolicited Claims Solicited Claims Unsolicited Prior Authorization Solicited Prior Authorization
Submit Attachment Operation ✔ ✔ ✔ ✔
AttachTo parameter Terminology claim claim preauthorization preauthorization

Payer Data Consumer Client Role

Data Consumer Server Unsolicited Claims Solicited Claims Unsolicited Prior Authorization Solicited Prior Authorization
CDex Task Attachment Request Profile ✘ ✔ ✘ ✔
Task.reasonCode Terminology - claim - preauthorization

✔: Conformance resource used in the transaction ✘: Conformance resource not used in the transaction

Capabilities for Requesting Attachments

Capability Must Support* Optional
Requesting Attachments Using Attachment Codes ✔  
Requesting Attachments Using Questionnaire   ✔
Signatures ✔  
Representing The Purpose Of Use (POU) For The Requested Data   ✔
Ability to submit attachments data in multiple submissions   ✔

* See the next section

CDex Must Support Definition

The CDex Profile elements consist of Mandatory, Must Support, and Optional elements. Elements that are neither Mandatory or Must Support are Optional. Mandatory elements are elements with a minimum cardinality greater than 0. Must Support elements are marked with the mustSupport flag and SHALL be interpreted as follows: §

Task Source
Data Source server where the Task is stored and updated, or Data Consumer client that POST the Task to Data Source server.
Task Consumer
Data Consumer client receiving a Task from the Data Source server due to a FHIR interaction.
  • If the minimum cardinality of an element is greater than 0, the element is required and the Task Source SHALL populate the data element with a value unless:§
    • The profile references a dataAbsentReason (DAR) extension, then the Task Source SHALL use that extension to communicate the reason for missing data.§
  • If the minimum cardinality of an element is equal to 0, the Task Source SHALL be capable of populating the data element when sharing Task compliant with a CDex profile.§ Although the system needs to demonstrate it is capable of populating and sharing of the element, it is acceptable to omit the element if the system doesn't have values in a particular instance. A system that is incapable of ever sharing the element would be non-conformant.
  • The Task Consumer SHALL be capable of processing Task instances containing the data elements without generating an error or causing the application to fail.§

NOTE: mustSupport indicates what Da Vinci CDex conformant systems are expected to be able to handle. Systems are free to include additional data - and receivers SHOULD NOT reject instances that contain unexpected data elements if those elements are not modifier elements.§ However, Task Sources cannot rely on Task Consumers to store, process, or do anything other than ignore data that is not marked as mustSupport.

The rules above are consistent with, and additional to, the general Da Vinci-wide Must Support expectations defined in HRex. For a detailed discussion of how to interpret Must Support for primitive, complex, and choice elements, references, and slices in this guide — see the US Core Must Support rules.  For content profiled in other guides, see the Must Support rules in those guides.

$submit-attachment Parameters for Sending Attachments

Parameter Required Optional
TrackingId ✔  
AttachTo ✔(see above)  
PayerId   ✔
OrganizationId ✔  
ProviderId ✔  
MemberId ✔  
ServiceDate ✔(claims) ✔(prior authorization)
Attachment.LineItem   ✔
Attachment.Code   ✔(It SHOULD be present when submitting unsolicited attachments§)
Attachment.Content ✔(DocumentReference, QuestionnaireResponse when requesting attachments using Questionnaire) ✔(Servers SHOULD support other FHIR types§)
Attachment.Final   ✔

CDex Attachments Requirements

This section lists all narrative conformance statements in the Attachments section of this IG. The tables offer a concise summary for implementers to identify essential requirements and support evaluation and testing. The data is also available as CSV and Excel files, as well as in CDex Requirements Resources.

Payer (Data Consumer) Requirements

Key Context Conformance Requirement
CONF-022 large payloads SHALL

[For managing large payloads in the $submit-attachment operation,] Servers SHALL document in their Capability Statement's CapabilityStatement.operation.documentation element or payer-supplied documentation:

  1. The payload endpoint size limits (e.g. 100MB )
  2. Whether they support the $submit-attachment's Final input parameter
CONF-023 large payloads SHALL

When the [$submit-attachment] payload is too big, the Server SHALL use The HTTP 413 Content Too Large client error response status code (alternate status messages "Request Entity Too Large" or "Payload Too Large").
CONF-024 large payloads SHALL

Servers SHALL document instructions for the Client when the [$submit-attachment] payload is (or is anticipated to be) too big. (for example, send a URL + authorization information, offload to external storage, split multiple files into multiple operations)
CONF-025 the payer requirements SHALL

If the signatures fail verification when processing the $submit-attachment operation, the Data Source/Responder SHALL return an HTTP 400 Bad Request and an OperationOutcome declaring that the signature was invalid.
CONF-086 attachments-conformance.html SHALL

Must Support elements are marked with the mustSupport flag and SHALL be interpreted [by the Task Source and Task Consumer] as follows in CONF-088, CONF-090, CONF-092, CONF-094, CONF-096.
CONF-088 attachments-conformance.html SHALL

[for Must Support elements are marked with the mustSupport flag and ] the minimum cardinality of an element is greater than 0, the element is required and the Task Source SHALL populatie the data element with a value unless {CONF-091].
CONF-090 attachments-conformance.html SHALL

[For Must Support elements are marked with the mustSupport flag and ] the minimum cardinality of an element is greater than 0, the element is required unless the profile references a dataAbsentReason (DAR) extension, then the Task Source SHALL use that extension to communicate the reason for missing data.
CONF-092 attachments-conformance.html SHALL

[For Must Support elements marked with the mustSupport flag and ] the minimum cardinality of an element is equal to 0, the Task Source SHALL be capable of populating the data element when sharing Task compliant with a CDex profile.
CONF-094 attachments-conformance.html SHALL

[ For Must Support elements are marked with the mustSupport flag , the] … Task Consumer SHALL be capable of processing Task instances containing the data elements without generating an error or causing the application to fail.
CONF-098 cdex attachment request profile SHALL

For CDex attachment requests transactions, the Payer SHALL use the CDex Task Attachment Request Profile to solicit information from a Provider.
CONF-001 introduction SHOULD

Systems …SHOULD define what they support in their local capability statement in one or more of the following ways:

  1. (Preferred) Formally derived implementable profile from CDex Task Attachment Request Profile
  2. Document their systems' capabilities for requesting attachments in CapabilityStatement.rest.resource.documentation for the Task resource.
  3. (Preferred) Formal OperationDefinition derived from $submit-attachment
  4. Document their systems' capabilities for submitting attachments in CapabilityStatement.rest.documentation
CONF-002 submit attachment parameters for sending attachments SHOULD

When submitting unsolicited attachments [using the $submit-attachment operation], the [Data Source/]Provider SHOULD populate Attachment.Code[parameter].
CONF-003 submit attachment parameters for sending attachments SHOULD

[When submitting unsolicited attachments using the $submit-attachment operation] Servers SHOULD support Attachment.Content types beyond [the required types, ] DocumentReference and QuestionnaireResponse.
CONF-021 technical workflow SHOULD

The Payer SHOULD return an informational OperationOutcome with the HTTP accept response if the attachments can not be associated with a current claim or prior authorization and are being held for association with a future claim or prior authorization.
CONF-056 solicited-unsolicited-attachments.html SHOULD

Although the PAS guide leverages CDex, implementers SHOULD follow the Burden Reduction IGs to request additional information for prior authorization.
CONF-096 attachments-conformance.html SHOULD-NOT

[Data Consumers] …SHOULD NOT reject instances that contain unexpected data elements if those elements are not modifier elements.

Provider (Data Source) Requirements

Key Context Conformance Requirement
CONF-086 attachments-conformance.html SHALL

Must Support elements are marked with the mustSupport flag and SHALL be interpreted [by the Task Source and Task Consumer] as follows in CONF-088, CONF-090, CONF-092, CONF-094, CONF-096.
CONF-088 attachments-conformance.html SHALL

[for Must Support elements are marked with the mustSupport flag and ] the minimum cardinality of an element is greater than 0, the element is required and the Task Source SHALL populatie the data element with a value unless {CONF-091].
CONF-090 attachments-conformance.html SHALL

[For Must Support elements are marked with the mustSupport flag and ] the minimum cardinality of an element is greater than 0, the element is required unless the profile references a dataAbsentReason (DAR) extension, then the Task Source SHALL use that extension to communicate the reason for missing data.
CONF-092 attachments-conformance.html SHALL

[For Must Support elements marked with the mustSupport flag and ] the minimum cardinality of an element is equal to 0, the Task Source SHALL be capable of populating the data element when sharing Task compliant with a CDex profile.
CONF-094 attachments-conformance.html SHALL

[ For Must Support elements are marked with the mustSupport flag , the] … Task Consumer SHALL be capable of processing Task instances containing the data elements without generating an error or causing the application to fail.
CONF-001 introduction SHOULD

Systems …SHOULD define what they support in their local capability statement in one or more of the following ways:

  1. (Preferred) Formally derived implementable profile from CDex Task Attachment Request Profile
  2. Document their systems' capabilities for requesting attachments in CapabilityStatement.rest.resource.documentation for the Task resource.
  3. (Preferred) Formal OperationDefinition derived from $submit-attachment
  4. Document their systems' capabilities for submitting attachments in CapabilityStatement.rest.documentation
CONF-002 submit attachment parameters for sending attachments SHOULD

When submitting unsolicited attachments [using the $submit-attachment operation], the [Data Source/]Provider SHOULD populate Attachment.Code[parameter].
CONF-056 solicited-unsolicited-attachments.html SHOULD

Although the PAS guide leverages CDex, implementers SHOULD follow the Burden Reduction IGs to request additional information for prior authorization.
CONF-084 provider requirements SHOULD

if multiple documents need to be signed, systems SHOULD minimize the number of interactions required by the user
CONF-096 attachments-conformance.html SHOULD-NOT

[Data Consumers] …SHOULD NOT reject instances that contain unexpected data elements if those elements are not modifier elements.