This page is part of the Documentation Templates and Rules (v1.0.0: STU 1) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Underlying Technologies

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 member and the community as a whole.

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:

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 a number of 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 particular business objectives - though obviously coordinating with their communication partners so that there are other systems to interoperate with will also be important.

FHIR

This IG uses terminology, notations and design principles that are specific to FHIR. 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 the following prior to reading the rest of this IG.

• 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 IG leverages and builds on the US Core IG defined by HL7 for sharing human EHR data in the US. Implementers need to familiarize themselves with the profiles in US Core.

This IG supports the R4 version of the FHIR standard.

FHIR Version
FHIR R4 US Core

Implementers should also familiarize themselves with the FHIR resources used within this IG.

Resources
Questionnaire
QuestionnaireResponse
Task

US Core

Clinical systems SHALL use the specification defined by US Core in exchanging information with payers. Implementers should be familiar with this specification.

Clinical Decision Support Hooks

Clinical systems and payer systems SHALL use the specification and workflows defined by Clinical Decision Support (CDS) Hooks to initiate CRD. Implementers should be familiar with this specification.

Coverage Requirements Discovery

Clinical systems SHOULD use the specification and workflows defined by Coverage Requirements Discovery (CRD) to initiate DTR functionality with payers, where it is appropriate. Implementers should be familiar with this specification.

SMART on FHIR

Client systems conformant to this IG SHALL also serve as a SMART on FHIR client. This is to allow DTR functionality to be invoked outside of regular EHR clinical workflows using a SMART on FHIR app to provide a consistent way of evaluating payer rules and documentation requirements across EHR implementations. As such client implementers will also need to be familiar with the SMART on FHIR specification. Payer implementers only need to be familiar with the SMART on FHIR specification if they plan to develop SMART apps for launch by CDS Hooks or other purposes.

Structured Data Capture

Clinical systems SHALL use the specification and workflows defined by Structured Data Capture (SDC) to initiate DTR functionality with the payers. Implementers should be familiar with this specification.

Clinical Quality Language

Payer systems SHALL use the specification and workflows defined by Clinical Quality Language CQL to facilitate DTR functionality within clinical systems. Implementers should be familiar with this specification. Older versions of CQL such as STU 2 can be used provided they work with FHIR R4.

Must Support

This IG does NOT mark any elements with the Must Support flag in its own profiles.

This IG also references the US Core IG. Da Vinci DTR implementations SHALL conform to the US Core IG Must Support Guidance where US Core IG resources are used.