This page is part of the Da Vinci Coverage Requirements Discovery (CRD) FHIR IG (v2.1.0: STU 2.1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Reading this IG

Page standards status: Informative

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 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. CRD clients SHALL support at least one of the three profiles (and versions of US Core). CRD servers SHALL be able to handle all three.

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
Appointment	One of the resources that can trigger payer decision support
Binary	Used to represent example instances of CDS Hook JSON structions
Bundle	Used when delivering collections of resources in a CDS Hook 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 capture of additional information when not using DTR
ServiceRequest	One of the resources that can trigger payer decision support
StructureDefinition	Used when profiling resource, defining extensions, and defining profiles and extensions on CDS Hook models
Task
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 don't 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 ype.

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'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.