Da Vinci - Documentation Templates and Rules, published by HL7 International / Clinical Decision Support. This guide is not an authorized publication; it is the continuous build for version 2.1.0-preview built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-dtr/ and changes regularly. See the Directory of published versions

Use Cases and Overview

Page standards status: Informative

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 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 partners.
4. Clinical Data Exchange (CDex) supports the launch of DTR to gather documentation through the CDex Task Data Request Profile, which provides the questionnaire Task.input reference to Communicate to the provider a URL of a data request FHIR Questionnaire, and the ‘data-request-questionnaire’ Task.code which indicates the provider system uses DTR to complete the Questionnaire referenced in the questionnaire input parameter.

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

<?xml version=”1.0” encoding=”us-ascii” standalone=”no”?>

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 system actions can indicate that additional clinical and/or administrative information needs to be captured, allowing the EHR to prompt the appropriate user(s) to launch the DTR process to guide the user(s) in capturing the relevant information.
• The need for DTR is indicated in an extension created by a CRD system action. DTR allows the capture of information needed to support prior authorization requests and that can be included as part of such requests in PAS.
• PAS can be used to submit a prior authorization based on a requirement identified by CRD and include information requested by the payer in the form for a QuestionnaireResponse Bundle. The QuestionnaireResponse Bundle is included in the PAS request bundle and referenced by the PA profile on the claim as .supportingInformation. The entire PAS bundle passed to the payer includes the QuestionnaireResponse Bundle.

All three implementation guides should be used together to 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.
• DTR might be invoked directly by a clinician to validate documentation regarding an item or service that meets a responsible payer’s requirements.
• Information gathered by DTR will normally be used for submission via PAS to support a prior authorization request. However, the Questionnaire Response and its associated references may be exchanged, using other methods, with a performing provider, payer, or other entity to supply medical necessity documentation.
• PAS can be used for prior authorization submissions even if the requirement is not identified by CRD and the supporting documentation is exchanged via another method.

The greatest benefit to clinical workflow and reduction of manual intervention is achieved by implementing all three IGs at the same time. However, implementers can choose to roll out these three implementation guides in whatever order or combination best meets their business objectives.

System Actors

This Implementation Guide Fundamentally supports four different system actors that can be involved (with corresponding Capability Statements):

• DTR Payer Service (for US Core 3.1.1 / US Core 6.1): Responds to operations requesting Questionnaire packages, and (optionally) helps in the processing of adaptive questionnaires.

• DTR SMART Client (for US Core 3.1.1 / US Core 6.1): SMART on FHIR applications that take context from an EHR, retrieve questionnaires and rule sets from a DTR Payer server, render the Questionnaires and capture data, and store the results on payer and/or EHR systems

• Full DTR EHR (for US Core 3.1.1 / US Core 6.1): EHR systems which manage DTR data capture and execution directly and also allow the rules to access other data and store final documentation results

• Light DTR EHR (for US Core 3.1.1 / US Core 6.1):
  EHR systems which leverage a SMART app to manage data capture and rules execution, but which must be able to launch the SMART app, respond to app queries, and store the final documentation results.

CRD and DTR Workflow

The graphic below shows a high-level overview of CRD and DTR (DTR is the SMART on FHIR app or equivalent native EHR app).

As an example, a clinician might order, “Home Oxygen Therapy”:

• Arrows 1 - 4 represent the workflow processing to determine if there are documentation and/or prior authorization requirements (CRD):

  • The EHR would allow for the ordering of a DME (Durable Medical Equipment) device “Home Oxygen Therapy” (arrow 1).
  • The EHR would then compose a CDS Hook call containing or referencing FHIR resources to be used when calling the CDS Service (CRD) (arrow 2).
  • CRD then, optionally, retrieves additional information from a repository to help determine if there are documentation and/or prior authorization requirements for a requested device, service, or medication. The repository API and repository are shown in the Payer box. (repository API arrow and arrow 3).
  • In this scenario a response is sent back to the EHR/clinician in the form of a CDS system action (arrow 4), annotating a FHIR resource with an extension indicating there are documentation requirements.
    
    

• Arrows 4 - 6 represent the workflow processing to populate the template/questionnaire (DTR):

  • User launches DTR based on the indication provided by CRD.
  • DTR will retrieve the appropriate Questionnaire(s) and rule(s) from the repository via a repository API.
  • The clinician would launch the SMART app/DTR (or equivalent native EHR app) which pre-populates one or more FHIR based Questionnaire(s) with data from the EHR.
  • In the event data is known to be available but does not exist in the EHR the clinician could attest to the data in question.
  • The clinician populates the fields that were not populated with data from the EHR and possibly adjusts pre-populated elements. When the documentation is complete (or partially complete) the clinician would save the QuestionnaireResponse. DTR writes the FHIR based QuestionnaireResponse to the EHR. At this point the QuestionnaireResponse could also be sent to any ancillary service.
  • In the event the QuestionnaireResponse was incomplete, DTR could be launched at a future time with a context of the in-progress QuestionnaireResponse or associated order/resource and the process continued.

EHR System

The completion of documentation for ordered items or services is required by payers for prior authorization, claims submission, to support downstream providers in managing claims processes, to document medical necessity and/or for other coverage-related requirements. This information gathering is done in conjunction with the Electronic Health Record (EHR) system, ideally automatically extracting information from the EHR and eliminating the need for the end user to search for and/or transcribe information that already exists.

If information required to complete the Questionnaire is not available to the DTR solution from the EHR in a computably discoverable way, then the application will prompt the provider to enter the missing information.

Relation to Coverage Requirements Discovery (CRD)

The Coverage Requirements Discovery (CRD) service portion of the Burden Reduction workflow is responsible for verifying with the payer whether the product or service being ordered, or for which an appointment or encounter is being created is covered, requires documentation, and/or needs prior authorization. In most cases, the CRD service will return a system action annotating the relevant order/appointment/etc. with an extension containing the payer’s assessment and noting any documentation needs – potentially including specific Questionnaires and even partially populated draft QuestionnaireResponses that can be used in gathering that data. While CRD may verify that documentation and/or prior authorization is required, it does not manage completion of documentation, prior authorization, or validation of rules. The ‘doc-needed’ coverage-information extension component in CRD communicates the need to launch DTR – including the most appropriate type of user to launch it.

The DTR process is responsible for accessing Questionnaire resources and rules (CQL), then pre-populating the questionnaire with EHR data and finally checking if the combination of pre-populated and manually-entered data satisfies requirements.

Home Oxygen Therapy Ordering - DTR Workflow Details

This example shows an overview of how the DTR SMART App (or equivalent native EHR app) fits into a workflow when ordering Home Oxygen Therapy.

1. It is determined that documentation and/or prior authorization is required for coverage.
2. The DTR SMART App (or equivalent native EHR app) is launched from the EHR based on the need being flagged by a CDS system action.
3. The DTR SMART App (or equivalent native EHR app) fetches CQL (rules) and a FHIR Questionnaire from the payer server.
4. The engine then extracts as many answers as it can from the EHR to pre-populate a FHIR QuestionnaireResponse with FHIR-based EHR data.
5. If there is missing information, the user can manually provide it to fully populate the QuestionnaireResponse. If the QuestionnaireResponse is fully populated, the Questionnaire is not shown to the user unless specifically requested, in which case the user can review and potentially update pre-populated answers.
6. The DTR app/EHR function then writes the FHIR QuestionnaireResponse back to the EHR server.

Relation to Clinical Data Exchange (CDex)

DTR can be invoked for purposes other than specific Burden Reduction use-cases, specifically the guidance provided within the Clinical Data Exchange (CDex) Implementation Guide. CDex specifies the use of DTR to request attachments using questionnaires.

CDex supports the launch of DTR to gather documentation through the CDex Task Data Request Profile, which provides these necessary properties:

• The questionnaire Task.input reference - Communicates to the provider a URL of a data request FHIR Questionnaire
• The data-request-questionnaire Task.code - Indicates the provider system uses DTR to complete the Questionnaire referenced in the questionnaire input parameter.
  
  

See the Task Input sequence here.