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
Page standards status: Informative |
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:
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.
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:
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:
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:
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.
This Implementation Guide Fundamentally supports four different system actors that can be involved (with corresponding Capability Statements):
Light DTR EHR (for US Core 3.1.1 / US Core 6.1):
SMART on FHIR-enabled EHR that handles the form filling function of DTR, requiring the server to provide access to the specified resources to allow such an app to retrieve and edit QuestionnaireResponses and related resources.
Full DTR EHR (for US Core 3.1.1 / US Core 6.1):
EHRs that manage the form filling functions of DTR internally supporting client capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations.
SMART DTR Client (for US Core 3.1.1 / US Core 6.1): Clients support retrieving and editing QuestionnaireResponse and related resources, as well as client support for the Questionnaire Package, ValueSet Expand, and Next Question operations.
DTR Payer Service (for US Core 3.1.1 / US Core 6.1):
Payer systems that provide questionnaires to DTR clients supporting server capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations.
The graphic below shows a high-level overview of CRD and DTR (DTR is the SMART on FHIR app or equivalent native EHR app).
NOTE: | This workflow is just one example used to help illustrate the CRD and DTR APIs. It is expected that a supplemental guide will be produced moving forward to help implementers with more concrete examples. |
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):
Arrows 4 - 6 represent the workflow processing to populate the template/questionnaire (DTR):
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.
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.
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.
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:
questionnaire
Task.input reference - Communicates to the provider a URL of a data request FHIR Questionnairedata-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.