0.3.0 - Second STU ballot

This page is part of the Da Vinci Coverage Requirements Discovery (CRD) FHIR IG (v0.3.0: STU 1 Ballot 2) based on FHIR R4. The current version which supercedes this version is 1.0.0. For a full list of available versions, see the Directory of published versions

Technical Background

Da Vinci

Da Vinci is an HL7-sponsored project that brings together the U.S. EHR vendor and Payer communities 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. 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.

Systems

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

Client systems are typically Electronic Medical Record (EMR) systems but could theoretically be any system responsible for making clinical and administrative systems with respect to a patient that might be informed by information held by payer systems. (E.g. pharmacy systems, dental systems, etc.)

Payer systems (or servers) are systems that act on behalf of payer organizations to share relevant information with clients about care for patients who are covered by health insurance plans by that payer.

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

This implementation guide supports the STU3 and R4 versions of the FHIR standard. FHIR services based on STU3 are being moved into production by EMR vendors. R4 is just recently published and the goal is to ensure the implementation guide is aligned with the current direction of the FHIR standard. Initial implementations will focus on STU3.

This implementation guide also builds on the US Core Implementation Guide and implementers need to familiarize themselves with the profiles in those Implementation Guides:

US Core (2.1.0 - R4 based)
US Core (2.0.0 - STU3 based)

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

STU3 R4
Appointment
Coverage
CommunicationRequest
Device
DeviceRequest
Encounter
Location
Organization
Medication
MedicationRequest
NutritionOrder
Patient
Practitioner
PractitionerRole
ProcedureRequest
Questionnaire
ReferralRequest
SupplyRequest
Task
VisionPrescription 		Appointment
Coverage
CommunicationRequest
Device
DeviceRequest
Encounter
Location
Organization
Medication
MedicationRequest
NutritionOrder
Patient
Practitioner
PractitionerRole
Questionnaire
ServiceRequest
SupplyRequest
Task

CDS Hooks

Clinical systems will use the specification and workflows defined by CDS Hooks 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 principle 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 EMR. 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 EMR to perform such what-if scenarios is here. EMRs can use the general open source SMART app. Payers might also choose to develop their own using the open source SMART app as a base to inform their own development. This might be an appropriate option if there’s a need for additional elements to be included in certain resources to determine full coverage requirements.

Hook actions

When a server responds to a CDS hook, one of the possible actions is to allow the user to invoke a SMART App. Support for this option by payer systems is optional. Doing so allows the payer to provide a custom user interface to complete forms, navigate through decision support, review subsets of EHR and/or payer data, etc. The Da Vinci Documentation Templates and Rules implementation guide provides additional guidance and expectations on the use of CDS Hook cards to launch SMART Apps and how payer-provided SMART Apps should function.