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
Official URL: http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr | Version: 2.1.0-preview | |||
IG Standards status: Trial-use | Maturity Level: 2 | Computable Name: DocumentationTemplatesRules |
When creating orders, booking appointments, admitting patients, etc. there is often an expectation that certain types of documentation are captured that will subsequently be used for payer processing. This might be information needed for determining prior authorization (or even whether prior authorization is necessary), for inclusion as part of a claims submission, or even for retention as documentation of 'medical necessity' in the event of a future audit. Each payer has rules for what documentation is necessary and in what form it needs to exist. Failure to capture appropriate documentation or represent it in the correct manner can delay the processing of authorization requests and claims, result in denial of requests, or result in other penalties or hardships for both the provider and their patients.
The Da Vinci Documentation Templates and Rules (DTR) implementation guide provides a mechanism for payers to express their documentation requirements computably in a way that allows clinicians and other EHR users to navigate and quickly specify the needed information in a context-specific way. The guide allows rules to be written in a way that supports automatically extracting existing EHR information for review/confirmation and adjusting the information prompted for based on what data is already known or entered, minimizing impact on provider time, while expediting subsequent payer interactions.
DTR leverages FHIR Questionnaires combined with embedded CQL logic and associated value sets to retrieve existing information, prompt for additional relevant information, and manage the logic process of determining which questions need to be answered (and what answer choices are relevant). The function of rendering these Questionnaires and capturing the information in patient-specific QuestionnaireResponses can occur either through SMART on FHIR applications or through functionality embedded directly into the EHR.
This Implementation Guide has expectations defined for four types of systems 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.
NOTE: | The term Electronic Health Record (EHR) is used in this IG and can be considered equivalent to Electronic Medical Record (EMR) or a Practice Management System (PMS) for the purposes of the contained content. |
This IG is a companion to the Da Vinci Coverage Requirements Discovery (CRD), Prior Authorization Support (PAS), and Clinical Data Exchange (CDex) IGs. CRD allows a provider to be alerted that DTR is relevant for a particular order/appointment/etc. and optionally allows that provider to directly launch DTR (either as a SMART application or embedded EHR functionality), or hand off to back office staff for additional processing. PAS allows the information returned by DTR to be packaged as part of a FHIR-based prior authorization request. DTR functions in the 'middle' of these two IGs to capture the needed documentation. CDex allows a payer to solicit additional information from a clinical system in a variety of circumstances. One of the mechanisms it supports is asking for a user to fill out a particular form, or an unspecified set of forms associated with a tracking id. DTR provides the mechanism to allow the user to fill out such forms.
While designed to work with these other IGs, DTR can be implemented stand-alone. Further details on the relationships between these three implementation guides can be found here.
A fourth Da Vinci IG that is relevant to DTR is the Health Record Exchange (HRex) implementation guide, which defines a number of shared profiles and other shared content used across Da Vincie IGs - including this one.
On Feb 28, 2024, the Office of Burden Reduction and Health Informatics (OBRHI) National Standards Group (NSG) announced an enforcement discretion that they would not enforce the requirement to use the X12 278 for prior authorization if the covered entities were using the FHIR-based Prior Authorization API as described in the CMS Interoperability and Prior Authorization final rule (CMS-0057-F). This allows the payer to return a prior authorization number for use in the X12 837 in coverage extension of the CRD and DTR IGs or as part of the 'all FHIR' exchange of the Prior Authorization Response Bundle in the PAS IG.
For DTR, this specifically means that satisfied-pa-id
in the Coverage Information extension can be used as an X12 prior authorization number.
The IG is organized into the following sections:
This guide is based on the FHIR R4 specification that is mandated for use in the U.S. as well as the Clinical Quality Language (CQL) N1 release specification. It also leverages the SMART on FHIR specification for non-native DTR Apps.
This IG supports both USCDI v1 (US-Core 3.1.1) and USCDI v3 (US-Core 6.1.0), but the expectation is that in the near future DTR will be updated to include support for USCDI v4 (US-Core 7.0.0) which will bring minimal impact through the reliance on the Coverage Requirements Discover (CRD) dependencies.
In addition, this guide also relies on a number of parent implementation guides:
IG | Package | FHIR | Comment |
---|---|---|---|
Da Vinci - Documentation Templates and Rules | hl7.fhir.us.davinci-dtr#2.1.0-preview | R4 | |
HL7 Terminology (THO) | hl7.terminology.r4#6.0.2 | R4 | Automatically added as a dependency - all IGs depend on HL7 Terminology |
FHIR Extensions Pack | hl7.fhir.uv.extensions.r4#5.1.0 | R4 | Automatically added as a dependency - all IGs depend on the HL7 Extension Pack |
US Core (Reuse Wrapper) | hl7.fhir.us.core.v311#3.1.1 | R4 | |
US Core Implementation Guide | hl7.fhir.us.core#6.1.0 | R4 | |
US Core (Reuse Wrapper) | hl7.fhir.us.core.v700#7.0.0 | R4 | |
Structured Data Capture | hl7.fhir.uv.sdc#3.0.0 | R4 | |
Da Vinci Health Record Exchange (HRex) | hl7.fhir.us.davinci-hrex#1.1.0-ballot | R4 | |
Da Vinci - Coverage Requirements Discovery | hl7.fhir.us.davinci-crd#2.1.0-preview | R4 |
This implementation guide defines additional constraints and usage expectations above and beyond the information found in these base specifications. This guide also depends on several non-Da Vinci specifications:
This implementation guide and the underlying FHIR specification are licensed as public domain under the FHIR license. The license page also describes rules for the use of the FHIR name and logo.
This publication includes IP covered under the following statements.