Da Vinci - Coverage Requirements Discovery
1.1.0-ballot - STU 1.1 US

This page is part of the Da Vinci Coverage Requirements Discovery (CRD) FHIR IG (v1.1.0-ballot: STU 1.1 Ballot 1) 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. payer, providers, and technology suppliers (including EHR 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. identify business, clinical, technical, and testing requirements,
  2. develop and ballot a FHIR based implementation guide (IG),
  3. develop a reference implementation (RI) that is used to demonstrate that the concepts in the IG are possible to implement,
  4. pilot the standard
  5. support 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 partner.

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

Clinical SystemPayerProviderEHREHR repositoryHooks ServiceSMART appPrior AuthconverterRules repositoryPrior AuthprocessorCoverage Requirements Discovery (CRD)For "what if" scenariosEHR is played by SMART appCreate order/referral/etc.Is there anything provider should know?Retrieve patient dataRetrieve Hooks Service rulesYes, e.g.:No coverage requirements; orSeelinkto opioid guidelines; orThat lab test was already run, results are here:... ; orThere are documents to fill outClickhereto launch SMART appDocumentation, Templates & Rules (DTR)Click 'launch' on SMART App cardLaunch SMART appRetrieve Questionnaire/CQL rulesRetrieve data to populate QuestionnaireResponse/execute CQLUser verifies data & QuestionnaireResponseStore completed QuestionnaireResponse/other infoPrior Authorization Support (PAS)"Request prior auth"FHIR prior auth request(with completed form(s) from DTR process)"X12 (+FHIR) prior auth requestwith completed form(s)"X12 prior auth responseFHIR prior auth responseDisplay prior auth response

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 cards returned by CRD can include a link to a DTR SMART application that will then guide the clinician in capturing the relevant information
  • DTR can be triggered by a CRD hook. It allows captures of information needed to support prior authorization requests and that can be included as part of the request
  • PAS can be used to submit a prior authorization based on a requirement identified by CRD and using information gathered by DTR

All three implementation guides can be used together and intersect in that they 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.
  • CRD can identify a need for prior authorization and/or special documentation but, instead of linking to a DTR solution, might simply point to a website or other documentation with guidance on the appropriate forms to complete
  • DTR might be invoked directly by a clinician who either knows or is informed by means other than CRD about the requirement to gather additional documentation
  • Information gathered by DTR might be used for direct submission of prior authorizations to support X12 278 transactions or using alternative submission means (e.g. fax, mail) if supported/required by the relevant payer
  • PAS can be used for prior authorization submissions where the need to submit a prior authorization was identified without CRD (either known in advance or identified by other means) and/or the supplemental information to be provided was identified and gathered outside of or in addition to DTR.

As such, implementers can choose to roll out these three implementation guides in whatever order or combination best meets their business objectives - though obviously coordinating with their communication partners so that there are other systems to interoperate with will also be important.

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 clinical 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 Services (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 Service will provide coverage information related to one or possibly more insurance plans.

Users

The human users of CRD will all be on the CRD Client side, as CRD Services must be fully automated with no human intervention. The humans who benefit from the decision support provided by payer services will be many and varied. They will include clinicians who might adjust therapies or even make decisions about whether to pursue a therapy at all based on information from a payer (e.g. projected patient expense, whether a therapy is covered, whether there is a contraindication detected based on information known to the payer but previously unknown to the clinician). However, they will also include non-clinical staff - those making appointments, those managing dispatching of referrals to available providers, and those handling back-end collection of documentation that was inappropriate/inefficient for the clinician to gather at the time of the encounter. As such, CRD encompasses a broad spectrum of decision support that isn’t exclusively ‘clinical’.

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 R4 version of the FHIR standard and builds on the US Core Implementation Guide and implementers need to familiarize themselves with the profiles in that guide. It 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

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

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 EHR systems could connect directly either with the payer or with a payer-provided service
  • Consumer initiates? - Yes - the clinical system needing decision support would trigger the support, because only the clinical 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 was a good fit for the workflow we needed. There was no need to define custom operations or messages to meet our use-cases

Impact on payer processes

Information passed to the CRD service will typically contain clinical terminologies, might not contain billing terminologies, and will certainly not include billing modifier codes or similar information typically included in prior authorization requests. CRD services will need to support these clinical terminologies or map them to internally used billing terminologies when determining decision support results - such as whether a therapy is covered or requires prior authorization. In some cases, mappings may not be fully deterministic and may impact the ability respond with useful decision support. Services will also need to consider that the mapping they perform between clinical terminologies and billing codes may be different than the bill coding process performed by the client system when claims are eventually submitted. This may mean that assertions about coverage or prior authorization requirements will need to be expressed conditionally. E.g. “Provided this service is billed as X, Y or Z, then prior authorization is not needed”.