Da Vinci Clinical Data Exchange (CDex)
2.1.0 - STU 2.1
Da Vinci Clinical Data Exchange (CDex)
2.1.0 - STU 2.1
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
| Page standards status: Trial-use | Maturity Level: 2 |
<Requirements xmlns="http://hl7.org/fhir">
<id value="cdex-payer"/>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml"><p class="res-header-id"><b>Generated Narrative: Requirements cdex-payer</b></p><a name="cdex-payer"> </a><a name="hccdex-payer"> </a><table class="grid"><tr><td><b><a name="CONF-012"> </a></b>CONF-012</td><td>SHALL</td><td><div><p>This <code>Task.input</code> element represents the service date or the service's starting date for the claim or prior authorization. If the attachment is for a claim, it <strong>SHALL</strong> be present and precise to the day. It is optional if the attachment is for a prior authorization.</p>
</div><p>Links: </p><ul><li>References: <a href="requesting-attachments-code.html#date-of-service-for-the-claim">requesting-attachments-code.html</a></li></ul></td></tr><tr><td><b><a name="CONF-022"> </a></b>CONF-022</td><td>SHALL</td><td><div><ol>
<li>Servers <strong>SHALL</strong> document in their Capability Statement's <code>CapabilityStatement,operation.documentation</code> element or payer-supplied documentation:</li>
</ol>
</div><p>Links: </p><ul><li>References: <a href="sending-attachments.html#large-payloads">sending-attachments.html</a></li></ul></td></tr><tr><td><b><a name="CONF-023"> </a></b>CONF-023</td><td>SHALL</td><td><div><ol>
<li>When the payload is too big, the Server <strong>SHALL</strong> use The HTTP <code>413 Content Too Large</code> client error response status code (alternate status messages "Request Entity Too Large" or "Payload Too Large").</li>
</ol>
</div><p>Links: </p><ul><li>References: <a href="sending-attachments.html#large-payloads">sending-attachments.html</a></li></ul></td></tr><tr><td><b><a name="CONF-024"> </a></b>CONF-024</td><td>SHALL</td><td><div><ol>
<li>Servers <strong>SHALL</strong> document instructions for the Client when the 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)</li>
</ol>
</div><p>Links: </p><ul><li>References: <a href="sending-attachments.html#large-payloads">sending-attachments.html</a></li></ul></td></tr><tr><td><b><a name="CONF-025"> </a></b>CONF-025</td><td>SHALL</td><td><div><ul>
<li>If the signatures fail verification when processing the [<code>$submit-attachment</code>] operation, the Data Source/Responder <strong>SHALL</strong> return an HTTP <code>400 Bad Request</code> <em>and</em> an OperationOutcome declaring that the signature was invalid.</li>
</ul>
</div><p>Links: </p><ul><li>References: <a href="sending-attachments.html#the-payer-requirements">sending-attachments.html</a></li></ul></td></tr><tr><td><b><a name="CONF-079"> </a></b>CONF-079</td><td>SHALL</td><td><div><ul>
<li>A "ServiceDate" <code>Task.input</code> element representing the date of service or starting date of the service for the claim or prior authorization. It <strong>SHALL</strong> be present if the attachment is for a claim.</li>
</ul>
</div><p>Links: </p><ul><li>References: <a href="StructureDefinition-cdex-task-attachment-request.html">StructureDefinition-cdex-task-attachment-request.html</a></li></ul></td></tr><tr><td><b><a name="CONF-098"> </a></b>CONF-098</td><td>SHALL</td><td><div><p><strong>For CDex attachment requests transactions, the Payer SHALL use the [CDex Task Attachment Request Profile] to solicit information from a Provider.</strong></p>
</div><p>Links: </p><ul><li>References: <a href="requesting-attachments-code.html#cdex-attachment-request-profile">requesting-attachments-code.html</a></li></ul></td></tr><tr><td><b><a name="CONF-099"> </a></b>CONF-099</td><td>SHALL</td><td><div><p><strong>For CDex attachment requests transactions, the Payer SHALL use the [CDex Task Attachment Request Profile] to solicit information from a Provider.</strong></p>
</div><p>Links: </p><ul><li>References: <a href="requesting-attachments-questionnaire.html#cdex-attachment-request-profile">requesting-attachments-questionnaire.html</a></li></ul></td></tr><tr><td><b><a name="CONF-003"> </a></b>CONF-003</td><td>SHOULD</td><td><div><p>|Attachment.Content|{{OK}}(DocumentReference, QuestionnaireResponse if support Requesting Attachments Using Questionnaire|{{OK}}(Servers SHOULD support other FHIR types)|</p>
</div><p>Links: </p><ul><li>References: <a href="attachments-conformance.html#submit-attachment-parameters-for-sending-attachments">attachments-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-021"> </a></b>CONF-021</td><td>SHOULD</td><td><div><ul>
<li>The Payer <strong>SHOULD</strong> return an informational OperationOutcome with the HTTP accept response if the attachments can not be associated with a <em>current</em> claim or prior authorization and are being held for association with a <em>future</em> claim or prior authorization. An OperationOutcome example is used in Scenario 1b below.</li>
</ul>
</div><p>Links: </p><ul><li>References: <a href="sending-attachments.html#technical-workflow">sending-attachments.html</a></li></ul></td></tr></table></div>
</text>
<extension
url="http://hl7.org/fhir/StructureDefinition/structuredefinition-wg">
<valueCode value="claims"/>
</extension>
<extension
url="http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm">
<valueInteger value="2">
<extension
url="http://hl7.org/fhir/StructureDefinition/structuredefinition-conformance-derivedFrom">
<valueCanonical
value="http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex"/>
</extension>
</valueInteger>
</extension>
<extension
url="http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status">
<valueCode value="trial-use">
<extension
url="http://hl7.org/fhir/StructureDefinition/structuredefinition-conformance-derivedFrom">
<valueCanonical
value="http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex"/>
</extension>
</valueCode>
</extension>
<url value="http://hl7.org/fhir/us/davinci-cdex/Requirements/cdex-payer"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:oid:2.16.840.1.113883.4.642.40.21.36.3"/>
</identifier>
<version value="2.1.0"/>
<name value="CDexPayerRequirements"/>
<title value="CDex Payer Requirements"/>
<status value="draft"/>
<date value="2026-06-10T20:32:01+00:00"/>
<publisher
value="HL7 International / Payer/Provider Information Exchange Work Group"/>
<contact>
<name
value="HL7 International / Payer/Provider Information Exchange Work Group"/>
<telecom>
<system value="url"/>
<value value="http://www.hl7.org/Special/committees/claims"/>
</telecom>
<telecom>
<system value="email"/>
<value value="pie@lists.hl7.org"/>
</telecom>
</contact>
<description
value="This [Requirements](https://hl7.org/fhir/R5/requirements.html) resource lists all the CDex Payer requirements defined in the narrative sections of this IG."/>
<jurisdiction>
<coding>
<system value="urn:iso:std:iso:3166"/>
<code value="US"/>
</coding>
</jurisdiction>
<copyright
value="Used by permission of HL7 International all rights reserved Creative Commons License"/>
<statement>
<key value="CONF-012"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="This `Task.input` element represents the service date or the service's starting date for the claim or prior authorization. If the attachment is for a claim, it **SHALL** be present and precise to the day. It is optional if the attachment is for a prior authorization."/>
<reference
value="requesting-attachments-code.html#date-of-service-for-the-claim"/>
</statement>
<statement>
<key value="CONF-022"/>
<conformance value="SHALL"/>
<requirement
value="1. Servers **SHALL** document in their Capability Statement's `CapabilityStatement,operation.documentation` element or payer-supplied documentation:"/>
<reference value="sending-attachments.html#large-payloads"/>
</statement>
<statement>
<key value="CONF-023"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="1. When the 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")."/>
<reference value="sending-attachments.html#large-payloads"/>
</statement>
<statement>
<key value="CONF-024"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="1. Servers **SHALL** document instructions for the Client when the 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)"/>
<reference value="sending-attachments.html#large-payloads"/>
</statement>
<statement>
<key value="CONF-025"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="- 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."/>
<reference value="sending-attachments.html#the-payer-requirements"/>
</statement>
<statement>
<key value="CONF-079"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="- A "ServiceDate" `Task.input` element representing the date of service or starting date of the service for the claim or prior authorization. It **SHALL** be present if the attachment is for a claim."/>
<reference value="StructureDefinition-cdex-task-attachment-request.html"/>
</statement>
<statement>
<key value="CONF-098"/>
<conformance value="SHALL"/>
<requirement
value="**For CDex attachment requests transactions, the Payer SHALL use the [CDex Task Attachment Request Profile] to solicit information from a Provider.**"/>
<reference
value="requesting-attachments-code.html#cdex-attachment-request-profile"/>
</statement>
<statement>
<key value="CONF-099"/>
<conformance value="SHALL"/>
<requirement
value="**For CDex attachment requests transactions, the Payer SHALL use the [CDex Task Attachment Request Profile] to solicit information from a Provider.**"/>
<reference
value="requesting-attachments-questionnaire.html#cdex-attachment-request-profile"/>
</statement>
<statement>
<key value="CONF-003"/>
<conformance value="SHOULD"/>
<conditionality value="true"/>
<requirement
value="|Attachment.Content|{{OK}}(DocumentReference, QuestionnaireResponse if support Requesting Attachments Using Questionnaire|{{OK}}(Servers SHOULD support other FHIR types)|"/>
<reference
value="attachments-conformance.html#submit-attachment-parameters-for-sending-attachments"/>
</statement>
<statement>
<key value="CONF-021"/>
<conformance value="SHOULD"/>
<conditionality value="true"/>
<requirement
value="- 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. An OperationOutcome example is used in Scenario 1b below."/>
<reference value="sending-attachments.html#technical-workflow"/>
</statement>
</Requirements>
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
2026-06-10
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change