Da Vinci - Coverage Requirements Discovery
2.2.0-snapshot - STU 2.2 Peer Review

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.2.0-snapshot 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

## Reading this IG

Page standards status: Informative | Highlight text changes?

### 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 is 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 and additional IG reading guidance
- Base Resource

This implementation guide supports the R4 version of the FHIR standard and builds on the US Core 3.1 (USCDI v1), 6.1 (USCDI v3) and 7.0 (USCDI v4) implementation guides and implementers need to familiarize themselves with the profiles in those guides. The profiles in this IG conform with all three releases of US Core.

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:

Resource | Relevance
--- | ---
ActorDefinition | Used to help identify the entities that are subject to conformance expectations (pre-adopted from R5)
Appointment | One of the resources that can trigger payer decision support
Binary | Used to represent example instances of CDS Hooks JSON structures
Bundle | Used when delivering collections of resources in a CDS Hooks call, also used for queries
CapabilityStatement | Used to define conformance expectations for this guide
CodeSystem | Used to define custom codes specific to this guide
ConceptMap | Used to map location codes between terminologies
Coverage | Used to identify the member and the relevant insurance coverage to a payer
CommunicationRequest | One of the resources that can trigger payer decision support
Device | Supporting information for device requests
DeviceRequest | One of the resources that can trigger payer decision support
Encounter | Oner of the resources that can trigger payer decision support, and also provides context for other resources
Location | Supporting information for encounters and request resources
Organization | Used when identifying providers in Encounters, Tasks, and all requests
Medication | Supporting information for medication requests
MedicationRequest | One of the resources that can trigger payer decision support
NutritionOrder | One of the resources that can trigger payer decision support
Patient | Demographic information relevant to all requests
Practitioner | Used when identifying providers in Encounters, Tasks, and all requests
PractitionerRole | Used when identifying providers in Encounters, Tasks, and all requests
Questionnaire | Used to support the capture of additional information not covered by DTR
Requirements | Provides a computable listing of the text-based conformance expectations of the guide (pre-adopted from R5)
ServiceRequest | One of the resources that can trigger payer decision support
StructureDefinition | Used when profiling resources, defining extensions, and defining profiles and extensions on CDS Hooks models
Task | Used to manage dispatching orders to performing providers or locations
ValueSet | Used to define collections of codes used by CRD profiles
VisionPrescription | One of the resources that can trigger payer decision support

#### 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. In this case, they do not want to actually create a referral, they just want to ask the question "what would the requirements or recommendations be if I wanted to create a referral?

Such recommendations might be from decision support (such as ImmunizationRecommendation or a CarePlan with an intent of 'proposed') or from standard protocols (e.g. "this patient is due for a pap smear"). In such cases, the EHR can support automated generation of 'draft' requests (such as MedicationRequest or ServiceRequest) based on the decision support or protocol resources and use them when invoking CRD. Alternatively, the EHR might support launching a SMART on FHIR app that would capture the key information needed to drive a CRD response.

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.

##### Apps for Decision Support

Payers may recommend the launch of SMART apps that are relevant to the activity the user is performing. For example, an app might help guide order creation for specialized patient needs, help evaluate alternative therapies, determine whether complementary therapy is necessary/appropriate, etc. These might have clinical or administrative purposes. Recommendations for such apps would be returned by the SMART app response type.

### Architectural Approach

The approach taken to meet the requirements of the CRD 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. 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 are generating context-specific guidance that did not 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 cannot be used in inappropriate ways.