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 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
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:
identify business, clinical, technical and testing requirements.
develop and ballot a FHIR based implementation guide (IG).
develop a reference implementation (RI) that is used to demonstrate that the concepts in the IG are possible to implement.
pilot the standard.
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:
Coverage Requirements Discovery (CRD) which provides decision support to providers at the time they're ordering diagnostics, specifying treatments, making referrals, scheduling appointments, etc.
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.
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.
Clinical Data Exchange (CDex) documents launching DTR to gather additional information ("attachments"). The portion of CDex that is relevant to Burden Reduction is the use of the PAS Task profile. The PAS Task Profile uses the launching of DTR to communicate to the provider a URL of a data request FHIR Questionnaire. The Task.code indicates to the provider system to use DTR to complete the Questionnaire, and the URL of the Questionnaire "package" is communicated in Task.input.
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 required and whether there are '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 of 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 four implementation guides should be used together to perform business functions related to prior authorization. CMS Interoperability and Prior Authorization Final Rule CMS-0057-F recommends (and CMS may in the future require) that payers implement the functionality defined in the CRD, DTR, and PAS guides within their APIs. However, all IGs other than PAS also offer functionality that is 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 documentation of medical necessity.
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.
HRex can be used to solicit information unrelated to prior authorization.
The greatest benefit to clinical workflow and reduction of manual intervention is achieved by implementing all four IGs at the same time. However, implementers can choose to roll out these implementation guides in whatever order or combination best meets their business objectives. (Note that regulations may set expectations for when certain implementation guides must be used.)
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).
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):
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 or designated staff member 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 or designated staff member 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.
It is determined that documentation and/or prior authorization is required for coverage.
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.
The DTR SMART App (or equivalent native EHR app) fetches CQL (rules) and a FHIR Questionnaire from the payer server.
The engine then extracts as many answers as it can from the EHR to pre-populate a FHIR QuestionnaireResponse with FHIR-based EHR data.
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.
The DTR app/EHR function then writes the FHIR QuestionnaireResponse back to the EHR server.
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.
NOTE:
|
Propose a change