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

Documentation Templates and Rules Implementation Guide Home Page

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

Introduction

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.

CMS Enforcement Discretion

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.

Expected Systems

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.

ExpectedSystems

 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. 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.


Boundaries and Relationships

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.

Content and Organization

The IG is organized into the following sections:

  • Use Cases and Overview Provides examples of how this specification can be used by provider and payer organizations.
  • Technical Background Describes the underlying technologies this specification builds upon that readers should be familiar with before reading the rest of the IG.
  • ePA Coordinators Provides information regarding the interactions necessary to participate in an ePA workflow.
  • Formal Specification Provides the technical conformance details for the specification.
  • Privacy, Security, and Safety Describes guidance and conformance expectations around privacy and security this IG relies on.
  • DTR Metrics Provides guidance on capturing formal metrics to help evaluate and potentially benchmark DTR implementations.
  • Artifacts Introduces and provides links to the FHIR profiles, operations, extensions, as well as examples.
  • Credits Identifies the individuals and organizations involved in developing this IG.
  • Change History Documents the changes that have been made to this IG in its different releases and pointers to the discussion that drove those changes.

Dependencies

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:

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:

  • DTR leverages profiles and capabilities defined in the Structured Data Capture (SDC) implementation guide to define the forms used to gather information, how they're displayed, flow control logic, and mechanisms to automatically populate answers. It also describes how to support Adaptive Forms. The general capabilities of the SDC guide are further constrained in DTR to reflect the capabilities that payers can count on EHRs and/or DTR smart applications to have for managing forms - and thus the constraints that need to be adhered to by payers when defining the questionnaires to be used.

    Within the SDC Questionnaires, the logic that handles population and occasionally the flow control of forms is written using Clinical Quality Language (CQL). This is a language specifically designed to encode decision support logic. It can operate against data structures independent of their syntax (e.g., XML or JSON). It is heavily used throughout the FHIR decision support community.

  • In turn, DTR relies on the various EHR FHIR interfaces that comply with the US Core implementation guide 6.1 and 3.1.1 releases. These interfaces allow the CQL embedded in Questionnaires to retrieve data from the EHR to help populate answers and/or to guide what questions are necessary.

  • Because the DTR functionality is expected, at least in the early stages, to be performed by SMART on FHIR systems, this implementation guide also provides explicit guidance around the use of SMART launch to manage DTR functionality.


Intellectual Property Considerations

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.