Da Vinci - Documentation Templates and Rules
2.1.0 - STU 2.1 United States of America flag

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

Burden Reduction

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) 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:

Clinical SystemPayerProviderEHREHR repositoryHooks ServiceDTR clientPrior AuthconverterRules repositoryPrior AuthprocessorCoverage Requirements Discovery (CRD)For "what if" scenariosEHR is played by DTR clientCreate or updateorder / referral / etc.Is there anything provider should know?Retrieve member coverage and rulesRetrieve patient dataPre-emptive prior authorization?No / Yes(with auth number):Cards, system actions:"Be aware that:"No coverage requirements; orPrior auth is needed, here it is; and/orSeelinkto opioid guidelines; and/orThat lab test was already run, results are here:... ; and/orThere are documents to fill outClickhereto launch DTRDocumentation, Templates & Rules (DTR)Launch DTRLaunch DTR (app or internal)Get Questionnaire package(Questionnaires,ValueSets, Libraries)Retrieve data to populateQuestionnaireResponse / execute CQLGet next-questionGrant prior auth?No /Yes(w/ number)Updated Questionnairew/ new question(s)User completes & verifies QuestionnaireResponseStore completed QuestionnaireResponsePrior Authorization Support (PAS)"Request prior auth"alt[FHIR Direct]FHIR prior auth request(with completed form(s) from DTR process)FHIR prior auth response[FHIR w/ X12 conversion]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 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.)