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-data-consumer"/>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml"><p class="res-header-id"><b>Generated Narrative: Requirements cdex-data-consumer</b></p><a name="cdex-data-consumer"> </a><a name="hccdex-data-consumer"> </a><table class="grid"><tr><td><b><a name="CONF-009"> </a></b>CONF-009</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>When signatures are required, the Data Consumer <strong>SHALL</strong> use a <a href="http://hl7.org/fhir/R4/http.html#search">FHIR RESTful search</a> instead of <a href="http://hl7.org/fhir/R4/http.html#read">FHIR RESTful read</a>. There is no CDex support for signatures on a FHIR RESTful read because it fetches a single instance of a resource instead of a Bundle.</p>
</div><p>Links: </p><ul><li>References: <a href="direct-query.html#data-sourceresponder-requirements">direct-query.html</a></li></ul></td></tr><tr><td><b><a name="CONF-011"> </a></b>CONF-011</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>The <a href="http://www.hl7.org/about/davinci/index.cfm?ref=common">Da Vinci</a> initiative supports this implementation guide. Da Vinci is a private effort to accelerate the adoption of Health Level Seven International Fast Healthcare Interoperability Resources (HL7® FHIR®) as the standard to support and integrate value-based care (VBC) data exchange across communities. This guide and implementers of it <strong>SHALL</strong> adhere to the <a href="https://confluence.hl7.org/display/DVP/Da+Vinci+Clinical+Advisory+Council+Members?preview=/66940155/66942916/Guiding%20Principles%20for%20Da%20Vinci%20Implementation%20Guides.pdf">HL7 Da Vinci Guiding Principles</a> for exchanging patient health information.</p>
</div><p>Links: </p><ul><li>References: <a href="index.html#about-this-guide">index.html</a></li></ul></td></tr><tr><td><b><a name="CONF-014"> </a></b>CONF-014</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>Implementers <strong>SHALL</strong> read and adhere to the guidance for the following topics in the <a href="http://hl7.org/fhir/us/davinci-hrex/1.2.0/security.html">HRex Security and Privacy</a>:<sup>[][CONF-014]</sup></p>
<ul>
<li>Da Vinci's Guiding Principles</li>
<li>Statutes, Regulations</li>
<li>Clinical Safety Guidelines</li>
<li>FHIR Security and Implementation Guidance</li>
<li>Security/Privacy-Related Technologies, Including Explicit Consent and Security - Labels</li>
<li>Exchange Security</li>
<li>Additionally Protected Information</li>
<li>Security Contexts for Da Vinci IGs</li>
</ul>
</div><p>Links: </p><ul><li>References: <a href="security.html#da-vinci-hrex-security-and-privacy-requirements">security.html</a></li></ul></td></tr><tr><td><b><a name="CONF-015"> </a></b>CONF-015</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>User scopes <strong>SHALL</strong> be used as defined in <a href="http://www.hl7.org/fhir/smart-app-launch/">SMART App Launch</a> to restrict access to the relevant patients for a given Data Consumer.</p>
</div><p>Links: </p><ul><li>References: <a href="security.html#general-considerations">security.html</a></li></ul></td></tr><tr><td><b><a name="CONF-016"> </a></b>CONF-016</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>Audit mechanisms <strong>SHALL</strong> be in place so that exchange mechanisms <em>with or without human intervention</em> can be subject to review/oversight.</p>
</div><p>Links: </p><ul><li>References: <a href="security.html#general-considerations">security.html</a></li></ul></td></tr><tr><td><b><a name="CONF-018"> </a></b>CONF-018</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>The Data Consumer and Data Source <strong>SHALL</strong> use it [codes from the CDex Purpose of Use Value Set in the POU Task.input element.] to communicate the POU for the requested data when trading partner agreements require the POU to be exchanged.</p>
</div><p>Links: </p><ul><li>References: <a href="security.html#purpose-of-use">security.html</a></li></ul></td></tr><tr><td><b><a name="CONF-022"> </a></b>CONF-022</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>[For managing large payloads in the $submit-attachment operation,] Servers <strong>SHALL</strong> document in their Capability Statement's <code>CapabilityStatement.operation.documentation</code> element or payer-supplied documentation:</p>
<ol>
<li>The payload endpoint size limits (e.g. 100MB )</li>
<li>Whether they support the $submit-attachment's <code>Final</code> input parameter</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><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>When the [$submit-attachment] 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").</p>
</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><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>Servers <strong>SHALL</strong> 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)</p>
</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><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>If the signatures fail verification when processing the <a href="OperationDefinition-submit-attachment.html"><code>$submit-attachment</code></a> 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.</p>
</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-057"> </a></b>CONF-057</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>For CDex Task-based transactions, the <a href="StructureDefinition-cdex-task-data-request.html">CDex Task Data Request Profile</a> <strong>SHALL</strong> be used by the Data Consumer to solicit information from a system.</p>
</div><p>Links: </p><ul><li>References: <a href="task-based-approach.html#the-task-resource">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name="CONF-058"> </a></b>CONF-058</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>When known, <code>Task.reasonCode</code> or <code>Task.reasonReference</code> <strong>SHALL</strong> reference the object that directly leads to the task - a particular claim, for example.</p>
</div><p>Links: </p><ul><li>References: <a href="task-based-approach.html#task-reason">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name="CONF-082"> </a></b>CONF-082</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>The <code>Task.reasonReference</code> <code>DocumentReference.author</code> is a <em>Must Support</em> element with four target profile and three Coverage profiles….Clients <strong>SHALL</strong> support all four profiles.</p>
</div><p>Links: </p><ul><li>References: <a href="StructureDefinition-cdex-task-data-request.html">StructureDefinition-cdex-task-data-request.html</a></li></ul></td></tr><tr><td><b><a name="CONF-083"> </a></b>CONF-083</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>do not define the detailed POU, and the implementer <strong>SHALL</strong> supply an additional, alternate code. The resource fragment below shows their use:</p>
</div><p>Links: </p><ul><li>References: <a href="ValueSet-cdex-POU.html">ValueSet-cdex-POU.html</a></li></ul></td></tr><tr><td><b><a name="CONF-086"> </a></b>CONF-086</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p><a href="http://hl7.org/fhir/R4/profiling.html#mustsupport">Must Support</a> elements are marked with the <em>mustSupport</em> flag and <strong>SHALL</strong> be interpreted [by the Task Source and Task Consumer] as follows in CONF-088, CONF-090, CONF-092, CONF-094, CONF-096.</p>
</div><p>Links: </p><ul><li>References: <a href="attachments-conformance.html">attachments-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-087"> </a></b>CONF-087</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p><a href="http://hl7.org/fhir/R4/profiling.html#mustsupport">Must Support</a> elements are marked with the <em>mustSupport</em> flag and <strong>SHALL</strong> be interpreted [by the Task Source and Task Consumer] as follows in CONF-089, CONF-091, CONF-093, CONF-095, CONF-097.</p>
</div><p>Links: </p><ul><li>References: <a href="task-based-conformance.html">task-based-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-088"> </a></b>CONF-088</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>[for <a href="http://hl7.org/fhir/R4/profiling.html#mustsupport">Must Support</a> elements are marked with the <em>mustSupport</em> flag and ] the minimum cardinality of an element is greater than 0, the
element is <em>required</em> and the Task Source <strong>SHALL</strong> populatie the data element with a value unless {CONF-091].</p>
</div><p>Links: </p><ul><li>References: <a href="attachments-conformance.html">attachments-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-089"> </a></b>CONF-089</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>[for <a href="http://hl7.org/fhir/R4/profiling.html#mustsupport">Must Support</a> elements are marked with the <em>mustSupport</em> flag and ] the minimum cardinality of an element is greater than 0, the
element is <em>required</em> and the Task Source <strong>SHALL</strong> populatie the data element with a value unless {CONF-091].</p>
</div><p>Links: </p><ul><li>References: <a href="task-based-conformance.html">task-based-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-090"> </a></b>CONF-090</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>[For <a href="http://hl7.org/fhir/R4/profiling.html#mustsupport">Must Support</a> elements are marked with the <em>mustSupport</em> flag and ] the minimum cardinality of an element is greater than 0, the
element is <em>required</em> unless the profile references a dataAbsentReason (DAR) extension, then the Task Source <strong>SHALL</strong> use that extension to communicate the reason for missing data.</p>
</div><p>Links: </p><ul><li>References: <a href="attachments-conformance.html">attachments-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-091"> </a></b>CONF-091</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>[For <a href="http://hl7.org/fhir/R4/profiling.html#mustsupport">Must Support</a> elements are marked with the <em>mustSupport</em> flag and ] the minimum cardinality of an element is greater than 0, the
element is <em>required</em> unless the profile references a dataAbsentReason (DAR) extension, then the Task Source <strong>SHALL</strong> use that extension to communicate the reason for missing data.</p>
</div><p>Links: </p><ul><li>References: <a href="task-based-conformance.html">task-based-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-092"> </a></b>CONF-092</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>[For <a href="http://hl7.org/fhir/R4/profiling.html#mustsupport">Must Support</a> elements marked with the <em>mustSupport</em> flag and ] the minimum cardinality of an element is equal to 0, the Task Source <strong>SHALL</strong> be capable of populating the data element when sharing Task compliant with a CDex profile.</p>
</div><p>Links: </p><ul><li>References: <a href="attachments-conformance.html">attachments-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-093"> </a></b>CONF-093</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>[For <a href="http://hl7.org/fhir/R4/profiling.html#mustsupport">Must Support</a> elements marked with the <em>mustSupport</em> flag and ] the minimum cardinality of an element is equal to 0, the Task Source <strong>SHALL</strong> be capable of populating the data element when sharing Task compliant with a CDex profile.</p>
</div><p>Links: </p><ul><li>References: <a href="task-based-conformance.html">task-based-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-094"> </a></b>CONF-094</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>[ For <a href="http://hl7.org/fhir/R4/profiling.html#mustsupport">Must Support</a> elements are marked with the <em>mustSupport</em> flag , the] ... Task Consumer <strong>SHALL</strong> be capable of processing Task instances containing the data elements without generating an error or causing
the application to fail.</p>
</div><p>Links: </p><ul><li>References: <a href="attachments-conformance.html">attachments-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-095"> </a></b>CONF-095</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>[ For <a href="http://hl7.org/fhir/R4/profiling.html#mustsupport">Must Support</a> elements are marked with the <em>mustSupport</em> flag , the] ... Task Consumer <strong>SHALL</strong> be capable of processing Task instances containing the data elements without generating an error or causing
the application to fail.</p>
</div><p>Links: </p><ul><li>References: <a href="task-based-conformance.html">task-based-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-098"> </a></b>CONF-098</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>For CDex attachment requests transactions, the Payer SHALL use the <a href="StructureDefinition-cdex-task-attachment-request.html">CDex Task Attachment Request Profile</a> to solicit information from a Provider.</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-005"> </a></b>CONF-005</td><td>SHALL NOT</td><td><div><p>The use of CDex <strong>SHALL NOT</strong> be considered compliant with any use case specific IG where CDex is not explicitly required as part of the supported exchanges.</p>
</div><p>Links: </p><ul><li>References: <a href="background.html#where-does-cdex-fit-in-the-da-vinci-project">background.html</a></li></ul></td></tr><tr><td><b><a name="CONF-001"> </a></b>CONF-001</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHOULD">SHOULD</a></td><td><div><p>Systems ...<strong>SHOULD</strong> define what they support in their local capability statement in one or more of the following ways:</p>
<ol>
<li>(Preferred) Formally derived implementable profile from <a href="StructureDefinition-cdex-task-attachment-request.html">CDex Task Attachment Request Profile</a></li>
<li>Document their systems' capabilities for requesting attachments in <code>CapabilityStatement.rest.resource.documentation</code> for the Task resource.</li>
<li>(Preferred) Formal <a href="http://hl7.org/fhir/R4/operationdefinition.html">OperationDefinition</a> derived from <a href="OperationDefinition-submit-attachment.html"><code>$submit-attachment</code></a></li>
<li>Document their systems' capabilities for submitting attachments in <code>CapabilityStatement.rest.documentation</code></li>
</ol>
</div><p>Links: </p><ul><li>References: <a href="attachments-conformance.html#introduction">attachments-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-002"> </a></b>CONF-002</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHOULD">SHOULD</a></td><td><div><p>When submitting unsolicited attachments [using the $submit-attachment operation], the [Data Source/]Provider <strong>SHOULD</strong> populate <code>Attachment.Code</code>[parameter].</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-003"> </a></b>CONF-003</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHOULD">SHOULD</a></td><td><div><p>[When submitting unsolicited attachments using the $submit-attachment operation] Servers <strong>SHOULD</strong> support <code>Attachment.Content</code> types beyond [the required types, ] <code>DocumentReference</code> and <code>QuestionnaireResponse</code>.</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><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHOULD">SHOULD</a></td><td><div><p>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.</p>
</div><p>Links: </p><ul><li>References: <a href="sending-attachments.html#technical-workflow">sending-attachments.html</a></li></ul></td></tr><tr><td><b><a name="CONF-056"> </a></b>CONF-056</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHOULD">SHOULD</a></td><td><div><p>Although the PAS guide leverages CDex, implementers <strong>SHOULD</strong> follow the Burden Reduction IGs to request additional information for prior authorization.</p>
</div><p>Links: </p><ul><li>References: <a href="solicited-unsolicited-attachments.html">solicited-unsolicited-attachments.html</a></li></ul></td></tr><tr><td><b><a name="CONF-062"> </a></b>CONF-062</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHOULD">SHOULD</a></td><td><div><p>Data Consumers <strong>SHOULD</strong> … [poll for Task updates] in an automated/background manner after 1 minute to return automated responses and no more than every 5 minutes for the first 30 minutes and no more frequently than once every hour after that.</p>
</div><p>Links: </p><ul><li>References: <a href="task-based-approach.html#polling">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name="CONF-078"> </a></b>CONF-078</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHOULD">SHOULD</a></td><td><div><p>Systems <strong>SHOULD</strong> define what they support in their local capability statement in one or more of the following ways:</p>
<ol>
<li>(Preferred) Formally derived implementable profile from [CDex Task Data Request Profile]
(StructureDefinition-cdex-task-data-request.html)</li>
<li>Document their systems' capabilities for requesting attachments in <code>CapabilityStatement.rest.resource.documentation</code> for the Task resource.</li>
<li>(Preferred) Formal <a href="http://hl7.org/fhir/R4/operationdefinition.html">OperationDefinition</a> derived from <a href="OperationDefinition-submit-attachment.html"><code>$submit-attachment</code></a></li>
<li>Document their systems' capabilities for submitting attachments in <code>CapabilityStatement.rest.documentation</code></li>
</ol>
</div><p>Links: </p><ul><li>References: <a href="task-based-conformance.html#introduction">task-based-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-004"> </a></b>CONF-004</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHOULD-NOT">SHOULD-NOT</a></td><td><div><p>CDex is not intended to supersede other Da Vinci guides, which focus on a particular use case and define how to share clinical information. However, CDex may be used to request clinical data from a provider when an alternative is needed to cover some aspects of an exchange. For example, suppose the provider's data release process does not allow the automatic request for information specified in a use case specific IG. In that case, CDex provides an asynchronous process that allows manual review before releasing the information. However, implementers <strong>SHOULD NOT</strong> use this transaction when there is a requirement for real-time response to facilitate patient care.</p>
</div><p>Links: </p><ul><li>References: <a href="background.html#where-does-cdex-fit-in-the-da-vinci-project">background.html</a></li></ul></td></tr><tr><td><b><a name="CONF-096"> </a></b>CONF-096</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHOULD-NOT">SHOULD-NOT</a></td><td><div><p>[Data Consumers] ...<strong>SHOULD NOT</strong> reject instances that contain unexpected data elements if those elements are not <a href="http://hl7.org/fhir/R4/conformance-rules.html#isModifier">modifier elements</a>.</p>
</div><p>Links: </p><ul><li>References: <a href="attachments-conformance.html">attachments-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-097"> </a></b>CONF-097</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHOULD-NOT">SHOULD-NOT</a></td><td><div><p>[Data Consumers] ...<strong>SHOULD NOT</strong> reject instances that contain unexpected data elements if those elements are not <a href="http://hl7.org/fhir/R4/conformance-rules.html#isModifier">modifier elements</a>.</p>
</div><p>Links: </p><ul><li>References: <a href="task-based-conformance.html">task-based-conformance.html</a></li></ul></td></tr><tr><td><b><a name="CONF-017"> </a></b>CONF-017</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-MAY">MAY</a></td><td><div><p>Data Consumer and Data Source <strong>MAY</strong> communicate the POU for the requested data for each Task using codes from the <a href="ValueSet-cdex-POU.html">CDex Purpose of Use Value Set</a> in the POU <code>Task.input</code> element.</p>
</div><p>Links: </p><ul><li>References: <a href="security.html#purpose-of-use">security.html</a></li></ul></td></tr><tr><td><b><a name="CONF-019"> </a></b>CONF-019</td><td><a href="http://hl7.org/fhir/uv/xver-r5.r4/0.1.0/CodeSystem-conformance-expectation.html#conformance-expectation-SHALL">SHALL</a></td><td><div><p>Organizational user access scopes are typically pre-negotiated and documented via business agreements. Data Sources <strong>SHALL</strong> translate these agreements into the appropriate SMART App Launch scopes.</p>
</div><p>Links: </p><ul><li>References: <a href="security.html#general-considerations">security.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-data-consumer"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:oid:2.16.840.1.113883.4.642.40.21.36.1"/>
</identifier>
<version value="2.1.0"/>
<name value="CDexDataConsumerRequirements"/>
<title value="CDex Data Consumer Requirements"/>
<status value="draft"/>
<date value="2026-07-09T22:52:27+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 Data Consumer 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-009"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="When signatures are required, the Data Consumer **SHALL** use a [FHIR RESTful search](http://hl7.org/fhir/R4/http.html#search) instead of [FHIR RESTful read](http://hl7.org/fhir/R4/http.html#read). There is no CDex support for signatures on a FHIR RESTful read because it fetches a single instance of a resource instead of a Bundle."/>
<reference value="direct-query.html#data-sourceresponder-requirements"/>
</statement>
<statement>
<key value="CONF-011"/>
<conformance value="SHALL"/>
<requirement
value="The [Da Vinci](http://www.hl7.org/about/davinci/index.cfm?ref=common) initiative supports this implementation guide. Da Vinci is a private effort to accelerate the adoption of Health Level Seven International Fast Healthcare Interoperability Resources (HL7® FHIR®) as the standard to support and integrate value-based care (VBC) data exchange across communities. This guide and implementers of it **SHALL** adhere to the [HL7 Da Vinci Guiding Principles](https://confluence.hl7.org/display/DVP/Da+Vinci+Clinical+Advisory+Council+Members?preview=/66940155/66942916/Guiding%20Principles%20for%20Da%20Vinci%20Implementation%20Guides.pdf) for exchanging patient health information."/>
<reference value="index.html#about-this-guide"/>
</statement>
<statement>
<key value="CONF-014"/>
<conformance value="SHALL"/>
<requirement
value="Implementers **SHALL** read and adhere to the guidance for the following topics in the [HRex Security and Privacy](http://hl7.org/fhir/us/davinci-hrex/1.2.0/security.html):<sup>[][CONF-014]</sup>
- Da Vinci's Guiding Principles
- Statutes, Regulations
- Clinical Safety Guidelines
- FHIR Security and Implementation Guidance
- Security/Privacy-Related Technologies, Including Explicit Consent and Security - Labels
- Exchange Security
- Additionally Protected Information
- Security Contexts for Da Vinci IGs"/>
<reference
value="security.html#da-vinci-hrex-security-and-privacy-requirements"/>
</statement>
<statement>
<key value="CONF-015"/>
<conformance value="SHALL"/>
<requirement
value="User scopes **SHALL** be used as defined in [SMART App Launch](http://www.hl7.org/fhir/smart-app-launch/) to restrict access to the relevant patients for a given Data Consumer."/>
<reference value="security.html#general-considerations"/>
</statement>
<statement>
<key value="CONF-016"/>
<conformance value="SHALL"/>
<requirement
value="Audit mechanisms **SHALL** be in place so that exchange mechanisms *with or without human intervention* can be subject to review/oversight."/>
<reference value="security.html#general-considerations"/>
</statement>
<statement>
<key value="CONF-018"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="The Data Consumer and Data Source **SHALL** use it [codes from the CDex Purpose of Use Value Set in the POU Task.input element.] to communicate the POU for the requested data when trading partner agreements require the POU to be exchanged."/>
<reference value="security.html#purpose-of-use"/>
</statement>
<statement>
<key value="CONF-022"/>
<conformance value="SHALL"/>
<requirement
value="[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"/>
<reference value="sending-attachments.html#large-payloads"/>
</statement>
<statement>
<key value="CONF-023"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="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")."/>
<reference value="sending-attachments.html#large-payloads"/>
</statement>
<statement>
<key value="CONF-024"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="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)"/>
<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`](OperationDefinition-submit-attachment.html) 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-057"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="For CDex Task-based transactions, the [CDex Task Data Request Profile](StructureDefinition-cdex-task-data-request.html) **SHALL** be used by the Data Consumer to solicit information from a system."/>
<reference value="task-based-approach.html#the-task-resource"/>
</statement>
<statement>
<key value="CONF-058"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="When known, `Task.reasonCode` or `Task.reasonReference` **SHALL** reference the object that directly leads to the task - a particular claim, for example."/>
<reference value="task-based-approach.html#task-reason"/>
</statement>
<statement>
<key value="CONF-082"/>
<conformance value="SHALL"/>
<requirement
value="The `Task.reasonReference` `DocumentReference.author` is a *Must Support* element with four target profile and three Coverage profiles….Clients **SHALL** support all four profiles."/>
<reference value="StructureDefinition-cdex-task-data-request.html"/>
</statement>
<statement>
<key value="CONF-083"/>
<conformance value="SHALL"/>
<requirement
value="do not define the detailed POU, and the implementer **SHALL** supply an additional, alternate code. The resource fragment below shows their use:"/>
<reference value="ValueSet-cdex-POU.html"/>
</statement>
<statement>
<key value="CONF-086"/>
<conformance value="SHALL"/>
<requirement
value="[Must Support](http://hl7.org/fhir/R4/profiling.html#mustsupport) 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."/>
<reference value="attachments-conformance.html"/>
</statement>
<statement>
<key value="CONF-087"/>
<conformance value="SHALL"/>
<requirement
value="[Must Support](http://hl7.org/fhir/R4/profiling.html#mustsupport) elements are marked with the *mustSupport* flag and **SHALL** be interpreted [by the Task Source and Task Consumer] as follows in CONF-089, CONF-091, CONF-093, CONF-095, CONF-097."/>
<reference value="task-based-conformance.html"/>
</statement>
<statement>
<key value="CONF-088"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="[for [Must Support](http://hl7.org/fhir/R4/profiling.html#mustsupport) 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]."/>
<reference value="attachments-conformance.html"/>
</statement>
<statement>
<key value="CONF-089"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="[for [Must Support](http://hl7.org/fhir/R4/profiling.html#mustsupport) 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]."/>
<reference value="task-based-conformance.html"/>
</statement>
<statement>
<key value="CONF-090"/>
<conformance value="SHALL"/>
<requirement
value="[For [Must Support](http://hl7.org/fhir/R4/profiling.html#mustsupport) 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."/>
<reference value="attachments-conformance.html"/>
</statement>
<statement>
<key value="CONF-091"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="[For [Must Support](http://hl7.org/fhir/R4/profiling.html#mustsupport) 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."/>
<reference value="task-based-conformance.html"/>
</statement>
<statement>
<key value="CONF-092"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="[For [Must Support](http://hl7.org/fhir/R4/profiling.html#mustsupport) 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."/>
<reference value="attachments-conformance.html"/>
</statement>
<statement>
<key value="CONF-093"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="[For [Must Support](http://hl7.org/fhir/R4/profiling.html#mustsupport) 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."/>
<reference value="task-based-conformance.html"/>
</statement>
<statement>
<key value="CONF-094"/>
<conformance value="SHALL"/>
<requirement
value="[ For [Must Support](http://hl7.org/fhir/R4/profiling.html#mustsupport) 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."/>
<reference value="attachments-conformance.html"/>
</statement>
<statement>
<key value="CONF-095"/>
<conformance value="SHALL"/>
<requirement
value="[ For [Must Support](http://hl7.org/fhir/R4/profiling.html#mustsupport) 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."/>
<reference value="task-based-conformance.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](StructureDefinition-cdex-task-attachment-request.html) to solicit information from a Provider."/>
<reference
value="requesting-attachments-code.html#cdex-attachment-request-profile"/>
</statement>
<statement>
<extension
url="http://hl7.org/fhir/tools/StructureDefinition/requirements-statementshallnot">
<valueBoolean value="true"/>
</extension>
<key value="CONF-005"/>
<conditionality value="true"/>
<requirement
value="The use of CDex **SHALL NOT** be considered compliant with any use case specific IG where CDex is not explicitly required as part of the supported exchanges."/>
<reference
value="background.html#where-does-cdex-fit-in-the-da-vinci-project"/>
</statement>
<statement>
<key value="CONF-001"/>
<conformance value="SHOULD"/>
<requirement
value="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](StructureDefinition-cdex-task-attachment-request.html)
2. Document their systems' capabilities for requesting attachments in `CapabilityStatement.rest.resource.documentation` for the Task resource.
3. (Preferred) Formal [OperationDefinition](http://hl7.org/fhir/R4/operationdefinition.html) derived from [`$submit-attachment`](OperationDefinition-submit-attachment.html)
4. Document their systems' capabilities for submitting attachments in `CapabilityStatement.rest.documentation`"/>
<reference value="attachments-conformance.html#introduction"/>
</statement>
<statement>
<key value="CONF-002"/>
<conformance value="SHOULD"/>
<conditionality value="true"/>
<requirement
value="When submitting unsolicited attachments [using the $submit-attachment operation], the [Data Source/]Provider **SHOULD** populate `Attachment.Code`[parameter]."/>
<reference
value="attachments-conformance.html#submit-attachment-parameters-for-sending-attachments"/>
</statement>
<statement>
<key value="CONF-003"/>
<conformance value="SHOULD"/>
<conditionality value="true"/>
<requirement
value="[When submitting unsolicited attachments using the $submit-attachment operation] Servers **SHOULD** support `Attachment.Content` types beyond [the required types, ] `DocumentReference` and `QuestionnaireResponse`."/>
<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."/>
<reference value="sending-attachments.html#technical-workflow"/>
</statement>
<statement>
<key value="CONF-056"/>
<conformance value="SHOULD"/>
<requirement
value=" Although the PAS guide leverages CDex, implementers **SHOULD** follow the Burden Reduction IGs to request additional information for prior authorization."/>
<reference value="solicited-unsolicited-attachments.html"/>
</statement>
<statement>
<key value="CONF-062"/>
<conformance value="SHOULD"/>
<requirement
value="Data Consumers **SHOULD** … [poll for Task updates] in an automated/background manner after 1 minute to return automated responses and no more than every 5 minutes for the first 30 minutes and no more frequently than once every hour after that."/>
<reference value="task-based-approach.html#polling"/>
</statement>
<statement>
<key value="CONF-078"/>
<conformance value="SHOULD"/>
<requirement
value="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 Data Request Profile]
(StructureDefinition-cdex-task-data-request.html)
1. Document their systems' capabilities for requesting attachments in `CapabilityStatement.rest.resource.documentation` for the Task resource.
2. (Preferred) Formal [OperationDefinition](http://hl7.org/fhir/R4/operationdefinition.html) derived from [`$submit-attachment`](OperationDefinition-submit-attachment.html)
3. Document their systems' capabilities for submitting attachments in `CapabilityStatement.rest.documentation`"/>
<reference value="task-based-conformance.html#introduction"/>
</statement>
<statement>
<key value="CONF-004"/>
<conformance value="SHOULD-NOT"/>
<conditionality value="true"/>
<requirement
value="CDex is not intended to supersede other Da Vinci guides, which focus on a particular use case and define how to share clinical information. However, CDex may be used to request clinical data from a provider when an alternative is needed to cover some aspects of an exchange. For example, suppose the provider's data release process does not allow the automatic request for information specified in a use case specific IG. In that case, CDex provides an asynchronous process that allows manual review before releasing the information. However, implementers **SHOULD NOT** use this transaction when there is a requirement for real-time response to facilitate patient care."/>
<reference
value="background.html#where-does-cdex-fit-in-the-da-vinci-project"/>
</statement>
<statement>
<key value="CONF-096"/>
<conformance value="SHOULD-NOT"/>
<conditionality value="true"/>
<requirement
value="[Data Consumers] ...**SHOULD NOT** reject instances that contain unexpected data elements if those elements are not [modifier elements](http://hl7.org/fhir/R4/conformance-rules.html#isModifier)."/>
<reference value="attachments-conformance.html"/>
</statement>
<statement>
<key value="CONF-097"/>
<conformance value="SHOULD-NOT"/>
<conditionality value="true"/>
<requirement
value="[Data Consumers] ...**SHOULD NOT** reject instances that contain unexpected data elements if those elements are not [modifier elements](http://hl7.org/fhir/R4/conformance-rules.html#isModifier)."/>
<reference value="task-based-conformance.html"/>
</statement>
<statement>
<key value="CONF-017"/>
<conformance value="MAY"/>
<conditionality value="true"/>
<requirement
value="Data Consumer and Data Source **MAY** communicate the POU for the requested data for each Task using codes from the [CDex Purpose of Use Value Set](ValueSet-cdex-POU.html) in the POU `Task.input` element. "/>
<reference value="security.html#purpose-of-use"/>
</statement>
<statement>
<key value="CONF-019"/>
<conformance value="SHALL"/>
<requirement
value="Organizational user access scopes are typically pre-negotiated and documented via business agreements. Data Sources **SHALL** translate these agreements into the appropriate SMART App Launch scopes."/>
<reference value="security.html#general-considerations"/>
</statement>
</Requirements>