This page is part of the Documentation Templates and Rules (v2.1.0-preview: QA Preview) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 2.0.1. For a full list of available versions, 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-preview
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.

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.

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.

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.

CMS Enforcement Discretion

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.

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:

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.