This page is part of the Da Vinci Clinical Documentation Exchange (v0.2.0: STU1 Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.1.0. For a full list of available versions, see the Directory of published versions

Background

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 want to create a complete clinical record of their members to improve care coordination and provide optimum medical care. For example with this information they can reduce redundant care, shift to a more proactive and timely care, and make better informed and more accurate medical treatment and care planning recommendations. Payers may use this clinical record to give providers information that may assist in care coordination.

Payers also require clinical data from the provider ordering or providing services to document prior authorization, claims processing, audit submitted claims, to confirm medical necessity and appropriateness. Clinical data is also used by Payers to create complete, accurate risk profiles for members for value-based care contracts and population health adjustments. Quality reporting requirements and quality care scoring all require clinical data. Importantly, this data helps to reduce preventable medical errors. Payers review member information to identify gaps in care. They work with providers and hunt down information showing the gap in care has been closed. Improving HEDIS measure scores has a positive impact on revenue for payers and reimbursements for providers.

The payer’s health record needs to be attributed based on the actual contributing provider. In other words, the record needs to be attributed to the individual that made the assertion. If an Electronic Health Information Exchange (HIE) retains that information in a non-repudiable manner, then it would be acceptable for a payer’s health record to be based on an aggregation created by an HIE. However, not all HIEs do this (and not for all records). Where attribution is not present or non-repudiable, then HIE content is not acceptable for most payer use-cases.

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’s 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

Any request should be limited to information necessary and when information is shared for one or more specific purposes of use, the recipient is expected to use the information only for those purposes of use or as allowed by existing federal and state statutes and regulations including HIPAA restrictions on access to information for payment. Audit mechanisms need to be in place so that exchange mechanisms with or without human intervention can be subject to review/oversight. For more about patient privacy, Review the guidance in the Security and Privacy section in the Da Vinci Health Record Exchange (HRex) Implementation Guide.

Where Does CDEX Fit in the Da Vinci Project?

There are over a dozen use cases and corresponding Implementation guides being developed by the Da Vinci Project. Figure 1 illustrates how the Clinical Data Exchange (CDex) use case fits in the family of Da Vinci Use Cases/Implementation Guides. CDex is not intended to supplant existing standards that already define how to share clinical information. This guide provide technical guidance to support the exchange of clinical data generated by providers to be shared with payers (or other providers) in situations where there are not other implemented standards to manage that process. For example, the Data Exchange For Quality Measures (DEQM) Implementation Guide provides a standard method of reporting Quality Measures. CDex can be used when:

1. The measure is not yet implementable using DEQM
2. A Provider has not implemented DEQM
3. Additional information is required for audit of the Quality Measure.

Example Scenarios

• Some payers create a complete clinical record for each of their members to facilitate data exchange with providers. Payers use this clinical record to give providers the adequate information to execute care coordination decisions.

• Clinical information gathered from providers to support the HEDIS/Stars quality program.

• Payers need information that helps them meet new regulatory requirements that promote patient access and exchange of information.

• A Durable Medical Equipment supplier submits a claim for a wheelchair. The Payer reviews the claim and assesses that the documentation submitted by the Provider is insufficient to support medical necessity or Payer coverage rules.

• Payers need to provide CMS with Risk Adjustment submissions annually.

• Allow a referred-to provider to solicit additional clinical information through a payer to support performing the requested service

Workflow Overview

See the Specification page for a detailed description of the technical workflow and API guidance.

Figure 2 below illustrates the general workflow for the exchange of clinical data between a Payer system and a Provider system.

Actors and Roles

• The Payer system (Payer) acts in the role of a data consumer
• The Provider system (Provider) acts in the role of a data source
• A human practitioner 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 Payer system initiates a request for clinical information
2. The Provider system retrieves the the requested data.
3. The data may be review by the provider prior to sending back to the Payer system
4. The data is sent back to the Payer system

Provider to Provider

This project scope includes exchanges of clinical information between provider and other providers. However, this use case has not been sufficiently explored and tested to provide guidance in this version of the guide.

---