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 |
{
"resourceType" : "Requirements",
"id" : "cdex-data-source",
"text" : {
"status" : "generated",
"div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p class=\"res-header-id\"><b>Generated Narrative: Requirements cdex-data-source</b></p><a name=\"cdex-data-source\"> </a><a name=\"hccdex-data-source\"> </a><table class=\"grid\"><tr><td><b><a name=\"CONF-007\"> </a></b>CONF-007</td><td>SHALL</td><td><div><ul>\n<li>CDex Data Source servers <strong>SHALL</strong> support resolving logical identifiers for the Patient resource.</li>\n</ul>\n</div><p>Links: </p><ul><li>References: <a href=\"direct-query.html#discovery-of-patient-fhir-ids\">direct-query.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-010\"> </a></b>CONF-010</td><td>SHALL</td><td><div><p>use a [FHIR RESTful search] instead of [FHIR RESTful 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. If the Data Consumer attempts to fetch a resource with a read and a signature is required, the Data Source/Responder <strong>SHALL</strong> return an HTTP <code>400 Bad Request</code> <em>and</em> an OperationOutcome describing the business rule error. The following HTTP response and OperationOutcome illustrate this</p>\n</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>SHALL</td><td><div><p>The [Da Vinci] 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 [HL7 Da Vinci Guiding Principles] for exchanging patient health information.</p>\n</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>SHALL</td><td><div><p>This implementation guide inherits all of the mandatory requirements and recommendations defined in the [HRex Security and Privacy] specification. Implementers <strong>SHALL</strong> read and adhere to the guidance for the following topics:</p>\n</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>SHALL</td><td><div><ol>\n<li>User scopes <strong>SHALL</strong> be used as defined in [SMART App Launch] to restrict access to the relevant patients for a given Data Consumer. 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.</li>\n</ol>\n</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>SHALL</td><td><div><ol>\n<li>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.</li>\n</ol>\n</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>SHALL</td><td><div><p>communicate the POU for the requested data for each Task using codes from the [CDex Purpose of Use Value Set] in the POU <code>Task.input</code> element. The Data Consumer and Data Source <strong>SHALL</strong> use it to communicate the POU for the requested data when trading partner agreements require the POU to be exchanged.</span><!-- new-content --></p>\n</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-059\"> </a></b>CONF-059</td><td>SHALL</td><td><div><p>Figure 8 below illustrates a "typical" state machine for CDex Task. The Data Consumer creates the Task with a status of "requested". The Data Source updates the status of the Task as appropriate. The Data Source <strong>SHALL</strong> support <em>all</em> the statuses in the [HRex Task Status ValueSet]. The Data Source</p>\n</div><p>Links: </p><ul><li>References: <a href=\"task-based-approach.html#task-state-machine\">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-064\"> </a></b>CONF-064</td><td>SHALL</td><td><div><p>Da Vinci CDex Data Sources who choose to support Subscription <strong>SHALL</strong> comply with the [Subscription R5 Backport Implementation Guide] and the Da Vinci Health Record Exchange (HRex) <a href=\"https://build.fhir.org/ig/HL7/davinci-ehrx/task.html#subscription\">Subscription requirements</a> for subscribing to Task updates. These implementation guides "pre-adopt" the FHIR R5 topic-based subscription approach in R4 implementations since most U.S. EHR vendors have agreed to support it.</p>\n</div><p>Links: </p><ul><li>References: <a href=\"task-based-approach.html#subscription\">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-065\"> </a></b>CONF-065</td><td>SHALL</td><td><div><ul>\n<li>The Data Source <strong>SHALL</strong> support the HRex Task Subscription Topic and</li>\n</ul>\n</div><p>Links: </p><ul><li>References: <a href=\"task-based-approach.html#hrex-task-subscription-topic\">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-067\"> </a></b>CONF-067</td><td>SHALL</td><td><div><ul>\n<li>The Data Source <strong>SHALL</strong> support discovery of the CDex Task Update Subscription Topic canonical URL</li>\n</ul>\n</div><p>Links: </p><ul><li>References: <a href=\"task-based-approach.html#discovery\">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-080\"> </a></b>CONF-080</td><td>SHALL</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. Servers <strong>SHALL</strong> support at least one of them, and when supporting a Coverage profile</p>\n</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-081\"> </a></b>CONF-081</td><td>SHALL</td><td><div><p>support at least one of them, and when supporting a Coverage profile, <strong>SHALL</strong> support the Coverage Profile based on the US Core version as follows:</p>\n</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>SHALL</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>\n</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>SHALL</td><td><div><p>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 <em>mustSupport</em> flag and <strong>SHALL</strong> be interpreted as follows:</p>\n</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>SHALL</td><td><div><p>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 <em>mustSupport</em> flag and <strong>SHALL</strong> be interpreted as follows:</p>\n</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>SHALL</td><td><div><p>element is <em>required</em> and the Task Source <strong>SHALL</strong> populating the data element with value unless:</p>\n</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>SHALL</td><td><div><p>element is <em>required</em> and the Task Source <strong>SHALL</strong> populating the data element with value unless:</p>\n</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>SHALL</td><td><div><p>Source <strong>SHALL</strong> use that extension to communicate the reason for missing data.</p>\n</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>SHALL</td><td><div><p>Source <strong>SHALL</strong> use that extension to communicate the reason for missing data.</p>\n</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>SHALL</td><td><div><ul>\n<li>If 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. 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</li>\n</ul>\n</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>SHALL</td><td><div><ul>\n<li>If 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. 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</li>\n</ul>\n</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>SHALL</td><td><div><ul>\n<li>The Task Consumer <strong>SHALL</strong> be capable of processing Task instances</li>\n</ul>\n</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>SHALL</td><td><div><ul>\n<li>The Task Consumer <strong>SHALL</strong> be capable of processing Task instances</li>\n</ul>\n</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-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>\n</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>SHOULD</td><td><div><p>Systems may 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 <strong>SHOULD</strong> define what they support in their local capability statement in one or more of the following ways:</p>\n</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>SHOULD</td><td><div><p>|Attachment.Code||{{OK}}(It SHOULD be present when submitting unsolicited attachments)|</p>\n</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-006\"> </a></b>CONF-006</td><td>SHOULD</td><td><div><ul>\n<li>CDex Data Source servers <strong>SHOULD</strong> support the patient match operation and declare it in their CapabilityStatement.</li>\n</ul>\n</div><p>Links: </p><ul><li>References: <a href=\"direct-query.html#discovery-of-patient-fhir-ids\">direct-query.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-008\"> </a></b>CONF-008</td><td>SHOULD</td><td><div><p>To the extent that the Data Source keeps a record of the provenance of the data, the FHIR Provenance Resource can be requested as documented on US Core's [Basic Provenance] page. When returning provenance, they <strong>SHOULD</strong> use the [HRex Provenance Profile]. The following example illustrates this transaction.</p>\n</div><p>Links: </p><ul><li>References: <a href=\"direct-query.html#provenance\">direct-query.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-056\"> </a></b>CONF-056</td><td>SHOULD</td><td><div><p>The Da Vinci Burden Reduction Implementation Guides (IGs), [Da Vinci Coverage Requirements Discovery (CRD)], [Da Vinci Documentation Templates and Rules (DTR)], and [Da Vinci Prior Authorization Support (PAS)], support an integrated workflow to enable automated submission of required documentation and prior authorization from EHR and payer systems respectively. Although the PAS guide leverages CDex, implementers <strong>SHOULD</strong> follow the Burden Reduction IGs to request additional information for prior authorization. See [Using CDex Attachments with DaVinci PAS] page for more details.</p>\n</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-068\"> </a></b>CONF-068</td><td>SHOULD</td><td><div><ul>\n<li>The Data Source <strong>SHOULD</strong> support discovery using the CapabilityStatement SubscriptionTopic Canonical extension and</li>\n</ul>\n</div><p>Links: </p><ul><li>References: <a href=\"task-based-approach.html#discovery\">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-078\"> </a></b>CONF-078</td><td>SHOULD</td><td><div><p>CDex Task-based transactions have many optional capabilities. Systems may choose some or all of these capabilities and implement any combination. Refer to the CDex [CapabilityStatements] resources for conformance expectations for the various actors and roles. In contrast to the expectations in the CDex CapabilityStatements, Systems <strong>SHOULD</strong> define what they support in their local capability statement in one or more of the following ways:</p>\n</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-084\"> </a></b>CONF-084</td><td>SHOULD</td><td><div><ul>\n<li>if multiple documents need to be signed, systems <strong>SHOULD</strong> minimize the number of interactions required by the user</li>\n</ul>\n</div><p>Links: </p><ul><li>References: <a href=\"sending-attachments.html\">sending-attachments.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-085\"> </a></b>CONF-085</td><td>SHOULD</td><td><div><ul>\n<li>if multiple documents need to be signed, systems <strong>SHOULD</strong> minimize the number of interactions required by the user</li>\n</ul>\n</div><p>Links: </p><ul><li>References: <a href=\"task-based-approach.html\">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-004\"> </a></b>CONF-004</td><td>SHOULD-NOT</td><td><div><ul>\n<li>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.</li>\n</ul>\n</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>SHOULD-NOT</td><td><div><p>data - and receivers <strong>SHOULD NOT</strong> 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 <em>mustSupport</em>.</p>\n</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>SHOULD-NOT</td><td><div><p>data - and receivers <strong>SHOULD NOT</strong> 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 <em>mustSupport</em>.</p>\n</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>MAY</td><td><div><p><span class="bg-success" markdown="1">CDex Task-based queries enable Data Consumers to dynamically define POUs when requesting data. Data Consumer and Data Source <strong>MAY</strong> communicate the POU for the requested data for each Task using codes from the [CDex Purpose of Use Value Set] in the POU <code>Task.input</code> element. The Data Consumer and Data Source</p>\n</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-060\"> </a></b>CONF-060</td><td>MAY</td><td><div><p>support <em>all</em> the statuses in the [HRex Task Status ValueSet]. The Data Source <strong>MAY</strong> support additional transitions, including transitions from terminal states (e.g., back to "in-progress" from "failed" or "completed"). The Data Source</p>\n</div><p>Links: </p><ul><li>References: <a href=\"task-based-approach.html#task-state-machine\">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-061\"> </a></b>CONF-061</td><td>MAY</td><td><div><p>support additional transitions, including transitions from terminal states (e.g., back to "in-progress" from "failed" or "completed"). The Data Source <strong>MAY</strong> use [<code>Task.businessStatus</code>] to track intermediate business statuses for their specific implementation</p>\n</div><p>Links: </p><ul><li>References: <a href=\"task-based-approach.html#task-state-machine\">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-066\"> </a></b>CONF-066</td><td>MAY</td><td><div><p>support the HRex Task Subscription Topic and <strong>MAY</strong> support other subscription topics</p>\n</div><p>Links: </p><ul><li>References: <a href=\"task-based-approach.html#hrex-task-subscription-topic\">task-based-approach.html</a></li></ul></td></tr><tr><td><b><a name=\"CONF-069\"> </a></b>CONF-069</td><td>MAY</td><td><div><p>support discovery using the CapabilityStatement SubscriptionTopic Canonical extension and <strong>MAY</strong> support discovery by some other method</p>\n</div><p>Links: </p><ul><li>References: <a href=\"task-based-approach.html#discovery\">task-based-approach.html</a></li></ul></td></tr></table></div>"
},
"extension" : [
{
"url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-wg",
"valueCode" : "claims"
},
{
"url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
"valueInteger" : 2,
"_valueInteger" : {
"extension" : [
{
"url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-conformance-derivedFrom",
"valueCanonical" : "http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex"
}
]
}
},
{
"url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
"valueCode" : "trial-use",
"_valueCode" : {
"extension" : [
{
"url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-conformance-derivedFrom",
"valueCanonical" : "http://hl7.org/fhir/us/davinci-cdex/ImplementationGuide/hl7.fhir.us.davinci-cdex"
}
]
}
}
],
"url" : "http://hl7.org/fhir/us/davinci-cdex/Requirements/cdex-data-source",
"identifier" : [
{
"system" : "urn:ietf:rfc:3986",
"value" : "urn:oid:2.16.840.1.113883.4.642.40.21.36.2"
}
],
"version" : "2.1.0",
"name" : "CDexDataSourceRequirements",
"title" : "CDex Data Source Requirements",
"status" : "draft",
"date" : "2026-06-10T20:32:01+00:00",
"publisher" : "HL7 International / Payer/Provider Information Exchange Work Group",
"contact" : [
{
"name" : "HL7 International / Payer/Provider Information Exchange Work Group",
"telecom" : [
{
"system" : "url",
"value" : "http://www.hl7.org/Special/committees/claims"
},
{
"system" : "email",
"value" : "pie@lists.hl7.org"
}
]
}
],
"description" : "This [Requirements](https://hl7.org/fhir/R5/requirements.html) resource lists all the CDex Data Source requirements defined in the narrative sections of this IG.",
"jurisdiction" : [
{
"coding" : [
{
"system" : "urn:iso:std:iso:3166",
"code" : "US"
}
]
}
],
"copyright" : "Used by permission of HL7 International all rights reserved Creative Commons License",
"statement" : [
{
"key" : "CONF-007",
"conformance" : [
"SHALL"
],
"requirement" : "- CDex Data Source servers **SHALL** support resolving logical identifiers for the Patient resource.",
"reference" : [
"direct-query.html#discovery-of-patient-fhir-ids"
]
},
{
"key" : "CONF-010",
"conformance" : [
"SHALL"
],
"conditionality" : true,
"requirement" : "use a [FHIR RESTful search] instead of [FHIR RESTful 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. If the Data Consumer attempts to fetch a resource with a read and a signature is required, the Data Source/Responder **SHALL** return an HTTP `400 Bad Request` *and* an OperationOutcome describing the business rule error. The following HTTP response and OperationOutcome illustrate this",
"reference" : [
"direct-query.html#data-sourceresponder-requirements"
]
},
{
"key" : "CONF-011",
"conformance" : [
"SHALL"
],
"requirement" : "The [Da Vinci] 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] for exchanging patient health information.",
"reference" : [
"index.html#about-this-guide"
]
},
{
"key" : "CONF-014",
"conformance" : [
"SHALL"
],
"requirement" : "This implementation guide inherits all of the mandatory requirements and recommendations defined in the [HRex Security and Privacy] specification. Implementers **SHALL** read and adhere to the guidance for the following topics:",
"reference" : [
"security.html#da-vinci-hrex-security-and-privacy-requirements"
]
},
{
"key" : "CONF-015",
"conformance" : [
"SHALL"
],
"requirement" : "1. User scopes **SHALL** be used as defined in [SMART App Launch] to restrict access to the relevant patients for a given Data Consumer. 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" : [
"security.html#general-considerations"
]
},
{
"key" : "CONF-016",
"conformance" : [
"SHALL"
],
"requirement" : "1. Audit mechanisms **SHALL** be in place so that exchange mechanisms *with or without human intervention* can be subject to review/oversight.",
"reference" : [
"security.html#general-considerations"
]
},
{
"key" : "CONF-018",
"conformance" : [
"SHALL"
],
"conditionality" : true,
"requirement" : "communicate the POU for the requested data for each Task using codes from the [CDex Purpose of Use Value Set] in the POU `Task.input` element. The Data Consumer and Data Source **SHALL** use it to communicate the POU for the requested data when trading partner agreements require the POU to be exchanged.</span><!-- new-content -->",
"reference" : [
"security.html#purpose-of-use"
]
},
{
"key" : "CONF-059",
"conformance" : [
"SHALL"
],
"requirement" : "Figure 8 below illustrates a \"typical\" state machine for CDex Task. The Data Consumer creates the Task with a status of \"requested\". The Data Source updates the status of the Task as appropriate. The Data Source **SHALL** support *all* the statuses in the [HRex Task Status ValueSet]. The Data Source",
"reference" : [
"task-based-approach.html#task-state-machine"
]
},
{
"key" : "CONF-064",
"conformance" : [
"SHALL"
],
"requirement" : "Da Vinci CDex Data Sources who choose to support Subscription **SHALL** comply with the [Subscription R5 Backport Implementation Guide] and the Da Vinci Health Record Exchange (HRex) [Subscription requirements](https://build.fhir.org/ig/HL7/davinci-ehrx/task.html#subscription) for subscribing to Task updates. These implementation guides \"pre-adopt\" the FHIR R5 topic-based subscription approach in R4 implementations since most U.S. EHR vendors have agreed to support it.",
"reference" : [
"task-based-approach.html#subscription"
]
},
{
"key" : "CONF-065",
"conformance" : [
"SHALL"
],
"requirement" : "- The Data Source **SHALL** support the HRex Task Subscription Topic and",
"reference" : [
"task-based-approach.html#hrex-task-subscription-topic"
]
},
{
"key" : "CONF-067",
"conformance" : [
"SHALL"
],
"requirement" : "- The Data Source **SHALL** support discovery of the CDex Task Update Subscription Topic canonical URL",
"reference" : [
"task-based-approach.html#discovery"
]
},
{
"key" : "CONF-080",
"conformance" : [
"SHALL"
],
"conditionality" : true,
"requirement" : "*The `Task.reasonReference` `DocumentReference.author` is a *Must Support* element with four target profile and three Coverage profiles. Servers **SHALL** support at least one of them, and when supporting a Coverage profile",
"reference" : [
"StructureDefinition-cdex-task-data-request.html"
]
},
{
"key" : "CONF-081",
"conformance" : [
"SHALL"
],
"conditionality" : true,
"requirement" : "support at least one of them, and when supporting a Coverage profile, **SHALL** support the Coverage Profile based on the US Core version as follows:",
"reference" : [
"StructureDefinition-cdex-task-data-request.html"
]
},
{
"key" : "CONF-083",
"conformance" : [
"SHALL"
],
"requirement" : "do not define the detailed POU, and the implementer **SHALL** supply an additional, alternate code. The resource fragment below shows their use:",
"reference" : [
"ValueSet-cdex-POU.html"
]
},
{
"key" : "CONF-086",
"conformance" : [
"SHALL"
],
"requirement" : "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:",
"reference" : [
"attachments-conformance.html"
]
},
{
"key" : "CONF-087",
"conformance" : [
"SHALL"
],
"requirement" : "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:",
"reference" : [
"task-based-conformance.html"
]
},
{
"key" : "CONF-088",
"conformance" : [
"SHALL"
],
"conditionality" : true,
"requirement" : "element is *required* and the Task Source **SHALL** populating the data element with value unless:",
"reference" : [
"attachments-conformance.html"
]
},
{
"key" : "CONF-089",
"conformance" : [
"SHALL"
],
"conditionality" : true,
"requirement" : "element is *required* and the Task Source **SHALL** populating the data element with value unless:",
"reference" : [
"task-based-conformance.html"
]
},
{
"key" : "CONF-090",
"conformance" : [
"SHALL"
],
"requirement" : "Source **SHALL** use that extension to communicate the reason for missing data.",
"reference" : [
"attachments-conformance.html"
]
},
{
"key" : "CONF-091",
"conformance" : [
"SHALL"
],
"requirement" : "Source **SHALL** use that extension to communicate the reason for missing data.",
"reference" : [
"task-based-conformance.html"
]
},
{
"key" : "CONF-092",
"conformance" : [
"SHALL"
],
"conditionality" : true,
"requirement" : "- 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",
"reference" : [
"attachments-conformance.html"
]
},
{
"key" : "CONF-093",
"conformance" : [
"SHALL"
],
"conditionality" : true,
"requirement" : "- 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",
"reference" : [
"task-based-conformance.html"
]
},
{
"key" : "CONF-094",
"conformance" : [
"SHALL"
],
"requirement" : "- The Task Consumer **SHALL** be capable of processing Task instances",
"reference" : [
"attachments-conformance.html"
]
},
{
"key" : "CONF-095",
"conformance" : [
"SHALL"
],
"requirement" : "- The Task Consumer **SHALL** be capable of processing Task instances",
"reference" : [
"task-based-conformance.html"
]
},
{
"extension" : [
{
"url" : "http://hl7.org/fhir/tools/StructureDefinition/requirements-statementshallnot",
"valueBoolean" : true
}
],
"key" : "CONF-005",
"conditionality" : true,
"requirement" : "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" : [
"background.html#where-does-cdex-fit-in-the-da-vinci-project"
]
},
{
"key" : "CONF-001",
"conformance" : [
"SHOULD"
],
"requirement" : "Systems may 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:",
"reference" : [
"attachments-conformance.html#introduction"
]
},
{
"key" : "CONF-002",
"conformance" : [
"SHOULD"
],
"conditionality" : true,
"requirement" : "|Attachment.Code||{{OK}}(It SHOULD be present when submitting unsolicited attachments)|",
"reference" : [
"attachments-conformance.html#submit-attachment-parameters-for-sending-attachments"
]
},
{
"key" : "CONF-006",
"conformance" : [
"SHOULD"
],
"requirement" : "- CDex Data Source servers **SHOULD** support the patient match operation and declare it in their CapabilityStatement.",
"reference" : [
"direct-query.html#discovery-of-patient-fhir-ids"
]
},
{
"key" : "CONF-008",
"conformance" : [
"SHOULD"
],
"conditionality" : true,
"requirement" : "To the extent that the Data Source keeps a record of the provenance of the data, the FHIR Provenance Resource can be requested as documented on US Core's [Basic Provenance] page. When returning provenance, they **SHOULD** use the [HRex Provenance Profile]. The following example illustrates this transaction.",
"reference" : [
"direct-query.html#provenance"
]
},
{
"key" : "CONF-056",
"conformance" : [
"SHOULD"
],
"requirement" : "The Da Vinci Burden Reduction Implementation Guides (IGs), [Da Vinci Coverage Requirements Discovery (CRD)], [Da Vinci Documentation Templates and Rules (DTR)], and [Da Vinci Prior Authorization Support (PAS)], support an integrated workflow to enable automated submission of required documentation and prior authorization from EHR and payer systems respectively. Although the PAS guide leverages CDex, implementers **SHOULD** follow the Burden Reduction IGs to request additional information for prior authorization. See [Using CDex Attachments with DaVinci PAS] page for more details.",
"reference" : [
"solicited-unsolicited-attachments.html"
]
},
{
"key" : "CONF-068",
"conformance" : [
"SHOULD"
],
"requirement" : "- The Data Source **SHOULD** support discovery using the CapabilityStatement SubscriptionTopic Canonical extension and",
"reference" : [
"task-based-approach.html#discovery"
]
},
{
"key" : "CONF-078",
"conformance" : [
"SHOULD"
],
"requirement" : "CDex Task-based transactions have many optional capabilities. Systems may choose some or all of these capabilities and implement any combination. Refer to the CDex [CapabilityStatements] resources for conformance expectations for the various actors and roles. In contrast to the expectations in the CDex CapabilityStatements, Systems **SHOULD** define what they support in their local capability statement in one or more of the following ways:",
"reference" : [
"task-based-conformance.html#introduction"
]
},
{
"key" : "CONF-084",
"conformance" : [
"SHOULD"
],
"conditionality" : true,
"requirement" : "- if multiple documents need to be signed, systems **SHOULD** minimize the number of interactions required by the user",
"reference" : [
"sending-attachments.html"
]
},
{
"key" : "CONF-085",
"conformance" : [
"SHOULD"
],
"conditionality" : true,
"requirement" : "- if multiple documents need to be signed, systems **SHOULD** minimize the number of interactions required by the user",
"reference" : [
"task-based-approach.html"
]
},
{
"key" : "CONF-004",
"conformance" : [
"SHOULD-NOT"
],
"conditionality" : true,
"requirement" : "- 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" : [
"background.html#where-does-cdex-fit-in-the-da-vinci-project"
]
},
{
"key" : "CONF-096",
"conformance" : [
"SHOULD-NOT"
],
"conditionality" : true,
"requirement" : "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*.",
"reference" : [
"attachments-conformance.html"
]
},
{
"key" : "CONF-097",
"conformance" : [
"SHOULD-NOT"
],
"conditionality" : true,
"requirement" : "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*.",
"reference" : [
"task-based-conformance.html"
]
},
{
"key" : "CONF-017",
"conformance" : [
"MAY"
],
"conditionality" : true,
"requirement" : "<span class=\"bg-success\" markdown=\"1\">CDex Task-based queries enable Data Consumers to dynamically define POUs when requesting data. 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] in the POU `Task.input` element. The Data Consumer and Data Source",
"reference" : [
"security.html#purpose-of-use"
]
},
{
"key" : "CONF-060",
"conformance" : [
"MAY"
],
"requirement" : "support *all* the statuses in the [HRex Task Status ValueSet]. The Data Source **MAY** support additional transitions, including transitions from terminal states (e.g., back to \"in-progress\" from \"failed\" or \"completed\"). The Data Source",
"reference" : [
"task-based-approach.html#task-state-machine"
]
},
{
"key" : "CONF-061",
"conformance" : [
"MAY"
],
"requirement" : "support additional transitions, including transitions from terminal states (e.g., back to \"in-progress\" from \"failed\" or \"completed\"). The Data Source **MAY** use [`Task.businessStatus`] to track intermediate business statuses for their specific implementation",
"reference" : [
"task-based-approach.html#task-state-machine"
]
},
{
"key" : "CONF-066",
"conformance" : [
"MAY"
],
"requirement" : "support the HRex Task Subscription Topic and **MAY** support other subscription topics",
"reference" : [
"task-based-approach.html#hrex-task-subscription-topic"
]
},
{
"key" : "CONF-069",
"conformance" : [
"MAY"
],
"requirement" : "support discovery using the CapabilityStatement SubscriptionTopic Canonical extension and **MAY** support discovery by some other method",
"reference" : [
"task-based-approach.html#discovery"
]
}
]
}
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