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
Official URL: http://hl7.org/fhir/us/davinci-dtr/ImplementationGuide/hl7.fhir.us.davinci-dtr | Version: 2.1.0 | |||
IG Standards status: Trial-use | Maturity Level: 2 | Computable Name: DocumentationTemplatesRules |
This specification is currently published as a Standard for Trial Use (STU). Feedback is welcome and may be submitted through the FHIR change tracker for this specification.
Individuals interested in participating in Documentation Templates and Rules, or other HL7 Da Vinci projects, can find information about Da Vinci here.
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 whether prior authorization is even 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 and/or 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.
One of the options available with DTR is to interact dynamically with the payer to formulate the questions being asked of the user, and potentially providing additional information back from the payer system - including coverage information via the Coverage Information extension.
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.
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/7.0):
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/7.0):
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:
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:
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 Implementation Guide and can be considered equivalent to Electronic Medical Record (EMR) or a Practice Management System (PMS) for the purposes of the contained content. The term EHR includes in its scope any certified HIT that performs the described burden reduction exchanges and/or processing as part of its capabilities. |
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.
NOTE: | CMS 0057-F sets out functionality requirements for prior authorization and recommends implementation of all 3 guides by covered systems to provide such functionality. There is an expectation that future versions of these implementation guides would become mandatory in future regulations. |
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.
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.
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 | R4 | |
HL7 Terminology (THO) | hl7.terminology.r4#6.1.0 | 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 Implementation Guide | hl7.fhir.us.core#7.0.0 | R4 | Defines USCDI v4 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers. |
US Core (Reuse Wrapper) | hl7.fhir.us.core.v610#6.1.0 | R4 | Defines USCDI v3 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers |
US Core (Reuse Wrapper) | hl7.fhir.us.core.v311#3.1.1 | R4 | Defines USCDI v1 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers. |
Structured Data Capture | hl7.fhir.uv.sdc#3.0.0 | R4 | Defines expecations for Questionnaires used to gather information |
Da Vinci Health Record Exchange (HRex) | hl7.fhir.us.davinci-hrex#1.1.0 | R4 | Defines common conformance rules across all Da Vinci IGs, as well as additional constraints and profiles beyond U.S. Core |
Da Vinci - Coverage Requirements Discovery | hl7.fhir.us.davinci-crd#2.1.0 | R4 | Makes available CRD profiles, valuesets, and codes for use as part of this IG |
Da Vinci Prior Authorization Support (PAS) FHIR IG | hl7.fhir.us.davinci-pas#2.1.0 | 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.