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

Background

Page standards status: Trial-use

About the Da Vinci Project

Da Vinci is a private sector initiative that addresses the needs of the Value-Based Care Community by leveraging the HL7 FHIR platform. For more information about the Da Vinci Project, its use cases, members, and updates, see the Da Vinci Overview

What Do Payers Do with Clinical Information

Payers require clinical data from providers who order or provide services. They use this data to document prior authorization, process and audit claims, and confirm medical necessity and appropriateness. In addition, payers use clinical data to create risk profiles for members for value-based care contracts and population health adjustments. Quality reporting requirements and quality care scoring require clinical data for evaluating clinical performance and outcomes. Payers may also collect this clinical information to assist providers with care planning options.

Example Scenarios

• Payer requests attachments for a claim submission or prior authorization.
  • For example, additional documentation to support medical necessity or a coverage rule.
• Payer requests additional documentation to support a claims audit.
• Payer requests patient health record information to support their Risk Adjustment submissions to the Centers for Medicare and Medicaid Services (CMS).
• Payer requests patient health record information to support their member records.
• Payer requests additional information related to quality reporting.
• Payers request patient health record information to meet new regulatory requirements (for example, promoting patient access).

Provider to Provider Data Exchange

Providers commonly need and request information about their patients from other providers. Although this guide focuses on payer-to-provider interactions, the technical exchange is no different from a provider-to-provider interaction.

Example Scenarios

• The referred-to provider solicits additional clinical information from the referring provider to support the performance of the requested service.
• The referring provider needs the results from the referred-to provider.

What Information is Needed

A sampling of the type of information needed by Payers includes:

• Medical records - for example, a progress note or visit summary
• C-CDA documents of various types
• Medications
• Laboratory results
• Clinical Assessments for Diagnoses
• Vital Signs - for example, Blood Pressure measurements
• Narrative - such as written or transcribed clinical notes

For Security and Privacy considerations, refer to the Security and Privacy page.

Where Does CDEX Fit in the Da Vinci Project

[Da Vinci Use Cases] are interrelated, currently with five categories that have emerged: Quality Improvement, Coverage/Burden Reduction, Member Access, Process Improvement, and Clinical Data Exchange. A table that summarizes the many areas of functional overlap between this guide and other Da Vinci guides is available here. 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.
• There is a specific exchange that is not already addressed by one of the other IGs

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.

Workflow Overview

FHIR offers numerous architectural approaches for sharing data between systems. Each has pros and cons; the most appropriate one depends on the circumstances under which systems exchange data. (Review the Architectural Approach section below for more detail.) This guide focuses on three FHIR transaction approaches for requesting information:

1. Direct Query: A Payer or external Provider system directly queries the Provider system for specific data using the standard FHIR RESTful search.
2. Task Based Approach: A Payer or external Provider system requests data using the FHIR Task resource. The Provider system supplies the data. Human involvement may be needed to find/aggregate/filter/approve it.
3. [Solicited and Unsolicited Attachments] The payer system requests attachments (additional documentation) for claims or prior authorization using the FHIR Task resource. The Provider system uses a “push” based FHIR operation to submit attachments to the Payer.

Direct Query and Task-Based Workflows

Figure 3 below illustrates the exchange of clinical data between a Payer (or Provider) system and a Provider system using the Direct Query and Task-Based workflows.

Actors and Roles

• The Payer or External Provider System acts as a data consumer.
• The Provider system acts as a data source.
• A human practitioner is involved in approving/filtering the information provided.
  • A pre-existing agreement could be in place that allows data to be shared without human intervention.

Steps

1. The data consumer initiates a request for information.
2. The data source retrieves the requested data.
3. A human practitioner may review the data before sending it back to the data consumer.
4. The data is sent back to the data consumer.

Solicited and Unsolicited Attachments Workflows

This specification divides attachments for claims or prior authorization into solicited and unsolicited workflows. Both are illustrated below.

Actors and Roles

• The Payer system acts as a data consumer.
• The Provider system acts as a data source.

Unsolicited Attachments Workflow

Figure 4 below illustrates the exchange of clinical data between a Provider system and a Payer system using the Unsolicited Attachments workflow.

Steps

1. The Provider submits the attachments and metadata for the association to the claim or prior authorization (for example, member id and claim id).
   • attachments are submitted without an explicit request as unsolicited attachments.
2. The Payer system accepts attachments. (This guide does not cover the payer's method for associating attachments to claims or prior authorizations and processing them.)

   Solicited Attachments Workflow

Figure 5 below illustrates the exchange of clinical data between a Payer system and a Provider system using the Solicited Attachments workflow.

Steps

1. For solicited attachments, the Payer initiates a request for attachments for a claim or prior authorization.
   • This can be a FHIR or non-FHIR-based transaction
2. The Provider submits the attachments and metadata (for example, member id and claim id) for the association to the claim or prior authorization.
3. The Payer system accepts attachments. (This guide does not cover the payer's method for associating attachments to claims or prior authorizations and processing them.)

Architectural Approach

All Da Vinci IGs that define CapababilityStatements setting expectations for support for specific FHIR interactions, operations, or other exchange mechanisms include this section explaining the IG's choice of exchange architecture in terms of the Approaches to Exchanging FHIR Data page documented in the FHIR version R5 specification.

Direct Query

Direct Query is the standard FHIR RESTful search and is the simplest, most adopted, and reusable approach for clinical data exchange between a Data Consumer and a Data Source.

Decision Tree

• Consumer initiates? - Yes - The CDex Data Consumer systems initiate the transaction when it needs clinical information from the CDex Data Source.
• Direct Connection? - Yes - It was presumed that CDex Data Consumer systems could connect directly with the CDex Data Source system.
• Human intervention? - No - There was no expectation the CDex Data Source would need human intervention to return the information.
• Is data pre-existing? - Yes - Generally, it was presumed the CDex Data Source has data about a patient/member.
• Return FHIR resources? - Yes - The CDex Data Source could return FHIR resources.
• Ad-hoc query? - Yes - It was presumed that CDex Data Consumer would create Ad-hoc RESTful queries to get the data from the CDex Data Source.
• Synchronous? - Yes - It was presumed that the RESTful queries are synchronous.

Task-Based Workflow

Although not as widely adopted as the FHIR RESTful approach, the Task-Based approach is a highly reusable clinical data exchange between a Data Consumer and a Data Source. See the Task Based Approach page for its benefits over Direct Query and when to use it.

Decision Tree

• Consumer initiates? - Yes - The CDex Data Consumer systems initiate the transaction when clinical information from the CDex Data Source is needed.
• Direct Connection? - Yes - It was presumed that CDex Data Consumer systems could connect directly with the CDex Data Source system to create Tasks and fetch resources.
• Human intervention? - Yes - There was an expectation the CDex Data Source may need human intervention to return the information.
• Is data pre-existing? - Yes - Generally, it was presumed the CDex Data Source has data about a patient/member.
• Return FHIR resources? - Yes - The CDex Data Source could return FHIR resources.
• Ad-hoc query? - Yes - It was presumed that CDex Data Consumer would create an Ad-hoc data request using Task.input to get the data from the CDex Data Source.
• Synchronous? - No - It was presumed that the Task-based queries are asynchronous.
• Subscription capability? - Maybe - It was presumed that the CDex Data Consumer would use polling or subscriptions to determine when the Task is completed.

Solicited and Unsolicited Attachments Workflow

Sending Attachments Using a FHIR Process Operation

The CDex Data Source (i.e., the Provider) uses the $submit-attachment operation to push clinical data to the CDex Data Consumer (i.e., the Payer) in both solicited and solicited attachment transactions. This transaction is specialized to the CDex Attachments use case and is not reusable for other clinical data exchanges.

Decision Tree

• Push? - Yes - It was presumed that the CDex Data Source would push the clinical data to the CDex Data Consumer.
• Configured by consumer? - No - It was presumed that the CDex Data Consumer would share all the clinical data for all transactions.
• Direct Connection? - Yes - It was presumed that CDex Data Source systems could connect directly with the CDex Data Consumer system.
• Data source directs consumer persistence? - No - It was presumed that the CDex Data Consumer is unaware of the existing data and would share all the clinical data for all transactions.
• Is message-like? - No - It was presumed that there is no need for explicit support for routing and that Operations are a lighter-weight solution.

Requesting Attachment using Task

Requesting Attachment using Task is a specialization of the Task-Based Workflow transaction. In contrast to the Task Based Workflow, it is not reusable for other clinical data exchanges. Additionally, the CDex Data Source (i.e., the Provider) pushes the data to the Payer-supplied endpoint using the $submit-attachment operation documented in the Sending Attachments Using a FHIR Process Operation section above.

Decision Tree

• Consumer initiates? - Yes - The CDex Data Consumer systems initiate the transaction when clinical information from the CDex Data Source is needed.
• Direct Connection? - Yes - It was presumed that CDex Data Consumer systems could connect directly with the CDex Data Source system to create Tasks and fetch resources. Human intervention? Yes - There was an expectation the CDex Data Source may need human intervention to return the information.
• Is data pre-existing? - Yes - Generally, it was presumed the CDex Data Source has data about a patient/member.
• Return FHIR resources? - Yes - The CDex Data Source could return FHIR resources.
• Ad-hoc query? - Yes - It was presumed that CDex Data Consumer would create Ad-hoc data requests using Task.input to get the data from the CDex Data Source.
• Synchronous? - No - It was presumed that the Task-based queries are asynchronous.
• Push? - Yes - It was presumed that the CDex Data Source would push the clinical data to the CDex Data Consumer when the Task is complete. See the decision tree in the Sending Attachments Using a FHIR Process Operation section above.

[Da Vinci Prior Authorization Support (PAS)]: [CDex Work Queue Value Set]: ValueSet-cdex-work-queue.html [What is Signed]: signatures.html#what-is-signed [Signatures for Task Based Requests]: task-based-approach.html#signatures [X12]: https://x12.org/ [X12 transactions]: https://x12.org/ [X12 Transaction Sets]: https://x12.org/products/transaction-sets [HEDIS]: https://en.wikipedia.org/wiki/Healthcare_Effectiveness_Data_and_Information_Set [Specification]: specification.html [$match]: http://hl7.org/fhir/R4/patient-operation-match.html [Coverage]: http://hl7.org/fhir/R4/coverage.html [FHIR RESTful Search syntax]: http://hl7.org/fhir/R4/search.html#Introduction [DocumentReference]: http://hl7.org/fhir/R4/documentreference.html [FHIR Signature]: http://hl7.org/fhir/R4/datatypes.html#signature [Bundle.signature]: http://hl7.org/fhir/R4/bundle-definitions.html#Bundle.signature [enveloped signature]: http://www.w3.org/TR/xmldsig-core/#def-SignatureEnveloped [(Verification Signature)]: http://hl7.org/fhir/R4/valueset-signature-type.html [FHIR Document]: http://hl7.org/fhir/R4/documents.html [RFC 7515]: https://tools.ietf.org/html/rfc7515 [JSON Signature rules]: http://hl7.org/fhir/R4/datatypes.html#JSON [RFC 7515: JSON Web Signature (JWS)]: https://tools.ietf.org/html/rfc7515 [Detached]: https://tools.ietf.org/html/rfc7515#appendix-F [Canonical JSON]: http://hl7.org/fhir/R4/json.html#canonical [JWS JSON Serialization]: https://datatracker.ietf.org/doc/html/rfc7515#section-3.2 [X.509 certificates]: https://www.itu.int/rec/T-REC-X.509 [RFC 7518]: https://tools.ietf.org/html/rfc7518 [RFC 7517]: https://tools.ietf.org/html/rfc7517 [RFC 8785]: https://datatracker.ietf.org/doc/rfc8785 [self-signed certificates]: https://en.wikipedia.org/wiki/Self-signed_certificate [Signed SearchSet Bundle Example]: signed-searchset-bundle-example.html [Signed Document Bundle Example]: signed-document-bundle-example.html [FHIR-36158]: https://jira.hl7.org/browse/FHIR-36158 [Solicited and Unsolicited Attachments]: solicited-unsolicited-attachments.html [Sending Attachments]: sending-attachments.html [Requesting Attachments Using Attachment Codes]: requesting-attachments-code.html [Requesting Attachments Using Questionnaires]: requesting-attachments-questionnaire.html [Using Questionnaire as Task Input]: task-based-approach.html#using-questionnaire-as-task-input [Using CDex Attachments with DaVinci PAS]: burden-reduction.html [CDex Task Attachment Request Profile]: StructureDefinition-cdex-task-attachment-request.html [LOINC attachment codes]: https://loinc.org/attachments/ [Parameters]: http://hl7.org/fhir/R4/parameters.html [CDex Patient Demographics Profile]: StructureDefinition-cdex-patient-demographics.html [CDex Claim Use Value Set]: ValueSet-cdex-claim-use.html [Prior-Auth AttachmentRequest Example]: Task-cdex-task-example20.html [Claim AttachmentRequest Example]: Task-cdex-task-example19.html [CDex Temporary Code System]: CodeSystem-cdex-temp.html [NHIN Purpose Of Use Code System]: http://hl7.org/fhir/R4/codesystem-nhin-purposeofuse.html [LOINC Document Ontology]: https://loinc.org/document-ontology/ [CDex Signature Bundle Profile]: StructureDefinition-cdex-signature-bundle.html [FHIR RESTful search]: http://hl7.org/fhir/R4/http.html#search [FHIR RESTful read]: http://hl7.org/fhir/R4/http.html#read [Change Log]: changes.html [CDex Parameters Example1]: Parameters-cdex-parameters-example1.html [CDex Parameters Example2]: Parameters-cdex-parameters-example2.html [CDex Parameters Example3]: Parameters-cdex-parameters-example3.html [CDex Parameters Example4]: Parameters-cdex-parameters-example4.html [validating profiles and resources]: http://hl7.org/fhir/R4/validation.html [ImplementationGuide]: http://hl7.org/fhir/R4/implementationguide.html [CDex ImplementationGuide Resource]: ImplementationGuide-hl7.fhir.us.davinci-cdex.html [Da Vinci DTR]: http://hl7.org/fhir/us/davinci-dtr/2.1.0-preview [Questionnaire]: http://hl7.org/fhir/R4/questionnaire.html [Smart Version 2.0.0 EHR launch flow]: https://hl7.org/fhir/smart-app-launch/app-launch.html#launch-app-ehr-launch [Using Da Vinci DTR to Complete the Questionnaire]: requesting-attachments-questionnaire.html#using-da-vinci-dtr-to-complete-the-questionnaire [Conforming to CDex Attachments]: attachments-conformance.html [Request for Additional Information]: /additionalinfo.html [SDC Questionnaire Response Profile]:http://hl7.org/fhir/uv/sdc/STU3StructureDefinition-sdc-questionnaireresponse.html [SDC Adaptive Questionnaire Response Profile]:http://hl7.org/fhir/uv/sdc/STU3StructureDefinition-sdc-questionnaireresponse-adapt.html [45 CFR 164.506 Treatment, Payment, and Health Care Operations (TPO)]: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.506 [must support]: http://hl7.org/fhir/us/davinci-hrex/STU1.1/conformance.html [DTR SMART App Launch]: requesting-attachments-questionnaire.html#dtr-smart-app-launch [Conforming to CDex Task Based Approach]: task-based-conformance.html [Signature Extension]: http://hl7.org/fhir/StructureDefinition/questionnaireresponse-signature [DTR Standard Questionnaire]: http://hl7.org/fhir/us/davinci-dtr/2.1.0-previewStructureDefinition-dtr-std-questionnaire.html [signatureRequired]: http://hl7.org/fhir/StructureDefinition/questionnaire-signatureRequired [CDex Signature Profile]: StructureDefinition-cdex-signature.html [CDex SDC QuestionnaireResponse Profile]: StructureDefinition-cdex-sdc-questionnaireresponse.html [QuestionnaireResponse]: http://hl7.org/fhir/R4/questionnaireresponse.html [Topic-Based Subscriptions Framework]: http://hl7.org/fhir/2022Sep/subscriptions.html [C-CDA on FHIR Documents]: http://www.hl7.org/fhir/us/ccda/index.html [FHIR Conformance]: http://hl7.org/fhir/R4/conformance-rules.html#conflang [Must Support]: http://hl7.org/fhir/R4/profiling.html#mustsupport [modifier elements]: http://hl7.org/fhir/R4/conformance-rules.html#isModifier [CDex PractitionerRole Profile]: StructureDefinition-cdex-practitionerrole.html [CDex Task Update]: SubscriptionTopic-cdex-task-update.html [Subscription R5 Backport Implementation Guide]: http://hl7.org/fhir/uv/subscriptions-backport/STU1.1 [SubscriptionTopic]: https://hl7.org/fhir/R4B/subscriptiontopic.html [CapabilityStatement SubscriptionTopic Canonical]: http://hl7.org/fhir/uv/subscriptions-backport/STU1.1/StructureDefinition-capabilitystatement-subscriptiontopic-canonical.html [Conformance in FHIR R4]: http://hl7.org/fhir/uv/subscriptions-backport/STU1.1/conformance.html#conformance-in-fhir-r4 [R4/B Topic-Based Subscription Profile]: http://hl7.org/fhir/uv/subscriptions-backport/STU1.1/StructureDefinition-backport-subscription.html [R4 Topic-Based Subscription Notification Bundle]: http://hl7.org/fhir/uv/subscriptions-backport/STU1.1/StructureDefinition-backport-subscription-notification-r4.html [HRex Task Status ValueSet]: http://hl7.org/fhir/us/davinci-hrex/STU1.1/ValueSet-hrex-task-status.html [Task.businessStatus]: http://hl7.org/fhir/R4/task-definitions.html#Task.businessStatus [Benefits]: task-based-approach.html#benefits [Task Inputs and Outputs]: task-based-approach.html#task-inputs-and-outputs [Purpose of Use]: task-based-approach.html#purpose-of-use [Task Reason]: task-based-approach.html#task-reason [Discovery of Identifiers]: task-based-approach.html#discovery-of-identifiers [Task State Machine]: task-based-approach.html#task-state-machine [Approaches to Exchanging FHIR Data]: https://hl7.org/fhir/R5/exchanging.html [PAS Claim Response Bundle]: /StructureDefinition-profile-pas-response-bundle.html [PAS Task]: /StructureDefinition-profile-task.html [Patient Matching]: https://hl7.org/fhir/us/identity-matching/patient-matching.html [Guidance on Identity Assurance]: https://hl7.org/fhir/us/identity-matching/guidance-on-identity-assurance.html [Interoperable Digital Identity and Patient Matching]: https://hl7.org/fhir/us/identity-matching/index.html [CQL]: https://cql.hl7.org/ [Da Vinci Use Cases]: https://confluence.hl7.org/display/DVP/Da+Vinci+Use+Cases [FHIR R4 core]: http://hl7.org/fhir/R4/fhir-spec.zip [FHIR core downloads]: http://hl7.org/fhir/R4/downloads.html [validator]: https://fhir.github.io/latest-ig-validator/org.hl7.fhir.validator.jar [instructions on how to use it]: https://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator