Da Vinci - Coverage Requirements Discovery, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.1.0-preview built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-crd/ and changes regularly. See the Directory of published versions

Technical Background

Page standards status: Informative

Da Vinci

Da Vinci is an HL7-sponsored project that brings together the U.S. payer, providers, and technology suppliers (including CRD client vendors) to help payers and providers to positively impact clinical, quality, cost, and care management outcomes using FHIR-related technologies. The project organizes meetings (face-to-face and conference calls), as well as connectathons, to find ways to leverage FHIR technologies to support and integrate value-based care (VBC) data exchange across communities. Da Vinci identifies value-based care use cases of interest to its members and to the broader community.

The process that Da Vinci has adopted includes:

1. identifying business, clinical, technical, and testing requirements
2. developing and balloting a FHIR based implementation guide (IG)
3. developing a reference implementation (RI) that is used to demonstrate that the concepts in the IG are possible to implement
4. piloting the standard
5. supporting the production use of the IG to enable exchange of data to support interoperability for value-based care

Additional information about Da Vinci, its members, the use cases, and the implementation guides being developed can all be found on the HL7 website. Meeting minutes and other materials can be found on the Da Vinci Confluence page.

Da Vinci Burden Reduction

This implementation guide is part of a set of interrelated implementation guides that are focused on reducing clinician and payer burden. The Da Vinci ‘Burden Reduction’ implementation guides are:

1. ​Coverage Requirements Discovery (CRD) which provides decision support to providers at the time they’re ordering diagnostics, specifying treatments, making referrals, scheduling appointments, etc.
2. Documentation Templates and Rules (DTR) which allows providers to download ‘smart’ questionnaires, rules (e.g. CQL), and provides a SMART on FHIR app or EHR app that executes them to gather information relevant to a performed or planned service. Execution of the questionnaires and rules may also be performed by an application that is part of the provider’s EHR.
3. Prior Authorization Support (PAS) allows provider systems to send (and payer systems to receive) prior authorization requests using FHIR, while still meeting regulatory mandates to have X12 278 used, where required, to transport the prior authorization, potentially simplifying processing for either or both exchange partners.
4. Clinical Data Exchange (CDex) supports the launch of DTR to gather documentation through the CDex Task Data Request Profile, which provides the questionnaire Task.input reference to Communicate to the provider a URL of a data request FHIR Questionnaire, and the ‘data-request-questionnaire’ Task.code which indicates the provider system uses DTR to complete the Questionnaire referenced in the questionnaire input parameter.

The general flow of activity across all three IGs can be seen in the following diagram:

<?xml version=”1.0” encoding=”us-ascii” standalone=”no”?>

The guides overlap in the following ways:

• CRD can indicate whether prior authorization is or is not required and whether there are or are not ‘special documentation requirements’ related to the planned service. The CDS Hook system actions can indicate that additional clinical and/or administrative information needs to be captured, allowing the EHR to prompt the appropriate user(s) to launch the DTR process to guide the user(s) in capturing the relevant information.
• The need for DTR is indicated in an extension created by a CRD system action. DTR allows the capture of information needed to support prior authorization requests and that can be included as part of such requests in PAS.
• PAS can be used to submit a prior authorization based on a requirement identified by CRD and include information requested by the payer in the form for a QuestionnaireResponse Bundle. The QuestionnaireResponse Bundle is included in the PAS request bundle and referenced by the PA profile on the claim as .supportingInformation. The entire PAS bundle passed to the payer includes the QuestionnaireResponse Bundle.

All three implementation guides should be used together to perform business functions related to prior authorization. However, the first two IGs also offer functionality that’s unrelated to prior authorization. The guides can function independently in several ways:

• CRD can provide information unrelated to prior authorization and ‘special documentation’. For example, providing an estimate of patient cost, suggesting appropriate use criteria, identifying duplicate therapies, etc.
• DTR might be invoked directly by a clinician to validate documentation regarding an item or service that meets a responsible payer’s requirements.
• Information gathered by DTR will normally be used for submission via PAS to support a prior authorization request. However, the Questionnaire Response and its associated references may be exchanged, using other methods, with a performing provider, payer, or other entity to supply medical necessity documentation.
• PAS can be used for prior authorization submissions even if the requirement is not identified by CRD and the supporting documentation is exchanged via another method.

The greatest benefit to clinical workflow and reduction of manual intervention is achieved by implementing all three IGs at the same time. However, implementers can choose to roll out these three implementation guides in whatever order or combination best meets their business objectives.

Systems

The CRD implementation guide defines the responsibilities of the two types of systems involved in a CRD solution:

CRD Clients are typically systems that healthcare providers use at the point of care including electronic medical records systems, pharmacy systems, and other provider and administrative systems used for ordering, documenting, and executing patient-related services. Users of these systems have a need for coverage requirements information to support care planning.

CRD Servers (or servers) are systems that act on behalf of payer organizations to share information with healthcare providers about rules and requirements related to healthcare products and services covered by a patient’s payer. A CRD Server will provide coverage information related to one or possibly more insurance plans.

Users

The ‘CDS’ in ‘CDS Hooks’ stands for ‘Clinical Decision Support’. However, the mechanism actually supports a variety of types of decision support and the responsible HL7 work group has confirmed that conveying guidance that isn’t strictly clinical, and providing guidance to non-clinical users (receptionists, back-end schedulers, etc.) is appropriate. Because all decision support provided by a CRD Server is fully automated, there will be no human intervention on the payer side. If an automated system doesn’t have enough information to provide guidance without human input, then no guidance will be provided.

Underlying Technologies

This guide is based on the HL7 FHIR standard, as well as the CDS Hooks and SMART on FHIR specifications, which build additional capabilities on top of FHIR. This architecture is intended to maximize the number of provider systems that conform to this guide, as well as to allow for easy growth and extensibility of system capabilities in the future.

Implementers of this specification therefore need to understand some basic information about these referenced specifications.

FHIR

This implementation guide uses terminology, notations and design principles that are specific to FHIR. Before reading this implementation guide, it’s important to be familiar with some of the basic principles of FHIR as well as general guidance on how to read FHIR specifications. Readers who are unfamiliar with FHIR are encouraged to read (or at least skim) the following prior to reading the rest of this implementation guide.

• FHIR Overview
• Developer’s Introduction (or Clinical Introduction)
• FHIR Data Types
• Using Codes
• References Between Resources
• How to Read Resource & Profile Definitions
• Base Resource

This implementation guide supports the R4 version of the FHIR standard and builds on the US Core 3.1 (USCDI 1) and 6.1 (USCDI 3) implementation guides and implementers need to familiarize themselves with the profiles in those guides. In most cases, the profiles in this IG conform with both releases of US Core. Where that is not possible (specifically in the case of Encounter), separate profiles have been created for use by CRD clients that support USCDI 1 vs. those that support USCDI 3. Clients SHALL support one of the two profiles (and versions of US Core). CRD Servers SHALL be able to handle both.

This IG also draws on content from the Davinci Health Record Exchange (HRex) and Structured Data Capture (SDC) implementation guides.

Implementers should also familiarize themselves with the FHIR resources used within the guide:

Appointment ClaimResponse Coverage CommunicationRequest Device DeviceRequest Encounter Location Organization Medication MedicationRequest NutritionOrder Patient Practitioner PractitionerRole Questionnaire ServiceRequest Task VisionPrescription

CDS Hooks

Provider systems will use the specification and workflows defined by CDS Hooks 2.0 to initiate Coverage Requirements Discovery with the payers. Implementers must be familiar with all aspects of this specification.

SMART on FHIR

SMART on FHIR is expected to be used in two principal ways:

Ad-hoc Coverage Requirements Discovery

CDS Hooks provides a mechanism for payers to advise clinicians on coverage requirements as part of their regular workflow - when ordering medications, making referrals, scheduling appointments, discharging patients, etc. However, sometimes clinicians may be interested in learning about coverage requirements without going through the workflow steps within their CRD client. I.e. they don’t want to actually create a referral, they just want to ask the question “what would the requirements be if I wanted to create a referral?

Discussion of how a SMART on FHIR app can be used to trigger CDS Hooks from within an CRD client to perform such what-if scenarios can be found here.

Architectural Approach

The approach taken to meet the requirements of the Coverage Requirements Discovery use-case was selected after evaluating the various interoperability choices provided by FHIR. Specifically, the project team evaluated the possible architectural approaches as described in the HRex specification’s Approaches to Exchanging FHIR Data guide. The following bullets describe the path choices driven by use-case requirements:

• Direct Connection? - Yes - it was presumed that CRD client systems could connect directly either with the payer or with a payer-provided service.
• Consumer initiates? - Yes - the provider system needing decision support would trigger the support, because only the provider system would know when support was needed.
• Human intervention? - No - there was no expectation that a human would need to be involved on the data source (payer) side to determine what guidance should be provided back. The requirement was for real-time guidance, which meant any guidance provided had to be automatic.
• Is data pre-existing? - No - in decision support, we’re generating context-specific guidance that didn’t previously exist, even if some of the resources pointed to might have been pre-existing.
• CDS-hooks? - Yes - CDS hooks were a good fit for the workflow we needed. There was no need to define custom operations or messages to meet our use-cases.

NOTE: Because of the sensitivity around disclosure of clinical information to payer-controlled systems during the clinical workflow process, this IG imposes a number of safeguards around the use of the selected CDS Hooks technology to help ensure that providers and their systems have an appropriate degree of control over disclosure and that information can’t be used in inappropriate ways.