Da Vinci - Documentation Templates and Rules
2.1.0 - STU 2.1

Publication Build: This will be filled in by the publication tooling

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

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

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

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

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

Implementation Guide | Version(s) | Reason
--- | --- | ---
CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) | 2.0.0 | Imported by Da Vinci Prior Authorization Support (PAS) FHIR IG (and potentially others)
Da Vinci - Coverage Requirements Discovery | 2.1.0 | Makes available CRD profiles, valuesets, and codes for use as part of this IG
2.0.0 | Imported by Da Vinci Prior Authorization Support (PAS) FHIR IG (and potentially others)
Da Vinci Health Record Exchange (HRex) | 1.1.0 | Defines common conformance rules across all Da Vinci IGs, as well as additional constraints and profiles beyond U.S. Core
1.0.0 | Imported by Da Vinci - Coverage Requirements Discovery (and potentially others)
Da Vinci Prior Authorization Support (PAS) FHIR IG | 2.1.0 |
FHIR Extensions Pack | 5.1.0 | Automatically added as a dependency - all IGs depend on the HL7 Extension Pack
1.0.0 | Imported by Da Vinci - Coverage Requirements Discovery (and potentially others)
FHIR R4 package : Core | 4.0.1 | Imported by HL7 Terminology (THO) (and potentially others)
HL7 Terminology (THO) | 6.1.0 | Automatically added as a dependency - all IGs depend on HL7 Terminology
5.5.0 | Imported by US Core (and potentially others)
5.3.0 | Imported by Da Vinci - Coverage Requirements Discovery (and potentially others)
5.0.0 | Imported by Subscriptions R5 Backport (and potentially others)
Public Health Information Network Vocabulary Access and Distribution System (PHIN VADS) | 0.12.0 | Imported by US Core (and potentially others)
SMART App Launch | 2.0.0 | Imported by US Core (and potentially others)
Security for Scalable Registration, Authentication, and Authorization | 0.1.0 | Imported by Da Vinci Health Record Exchange (HRex) (and potentially others)
Structured Data Capture | 3.0.0 | Defines expecations for Questionnaires used to gather information
Subscriptions R5 Backport | 1.1.0 | Imported by Da Vinci Prior Authorization Support (PAS) FHIR IG (and potentially others)
US Core | 7.0.0 | Defines USCDI v4 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers.
6.1.0 | Defines USCDI v3 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers
3.1.1 | Defines USCDI v1 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers.
Value Set Authority Center (VSAC) | 0.7.0 | Imported by CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) (and potentially others)
0.19.0 | Imported by Da Vinci Health Record Exchange (HRex) (and potentially others)
0.18.0 | Imported by US Core (and potentially others)
0.11.0 | Imported by Da Vinci - Coverage Requirements Discovery (and potentially others)

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

- Copyright HL7. Licensed under creative commons public domain
  Show Usage
  - contactRole2: HomeOxygenTherapyStdQuestionnaire
- ISO Maintains the copyright on the country codes, and controls it's use carefully. For futher details see the ISO 3166 web page: https://www.iso.org/iso-3166-country-codes.html
  Show Usage
  - ISO 3166-1 Codes for the representation of names of countries and their subdivisions — Part 1: Country code: ActiveRole, AlternativeExpression... Show 37 more, ContainedReference, DTRBaseQuestionnaire, DTRInformationOrigins, DTRLogErrorsInputParameters, DTRMetricData, DTRNextQuestion, DTRPayerService, DTRQuestionnaireAdapt, DTRQuestionnaireAdaptSearch, DTRQuestionnaireNextQuestionnaireInputParameters, DTRQuestionnaireNextQuestionnaireOutputParameters, DTRQuestionnairePackageBundle, DTRQuestionnairePackageInputParameters, DTRQuestionnairePackageOutputParameters, DTRQuestionnaireResponse, DTRQuestionnaireResponseBundle, DTRSmartClient, DTRStdQuestionnaire, DTRSupportedPayers, DTRTempCodes, DocumentationTemplatesRules, FullDTREHR, HomeOxygenTherapyStdQuestionnaire, InformationOrigin, IntendedUse, Library/library-quick-model-definition, LightDTREHR, LogQuestionnaireErrors, MetricAction, MetricLaunchMode, MetricSource, MetricsInformationOrigins, QRcontext, Questionnaire/AdaptiveSearchExample, Questionnaire/referred-questionnaire, QuestionnairePackage and QuestionnaireResponseContext
- The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
  Show Usage
  - Unified Code for Units of Measure (UCUM): Bundle/home-o2-questionnairepackage-bundle-2, Bundle/home-o2-questionnaireresponse-bundle, Parameters/NextQuestionInputParamsExample, Parameters/NextQuestionOutputParamsExample and QuestionnaireResponse/home-o2-questionnaireresponse
- This material contains content from LOINC. LOINC is copyright © 1995-2020, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc.
  Show Usage
  - LOINC: Parameters/QuestionnairePackageInputParamsExample and ServiceRequest/ServiceRequestExample
- This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed or info@snomed.org.
  Show Usage
  - SNOMED Clinical Terms&reg; (SNOMED CT&reg;): Bundle/home-o2-questionnairepackage-bundle-2, Bundle/home-o2-questionnaireresponse-bundle... Show 6 more, Parameters/NextQuestionInputParamsExample, Parameters/NextQuestionOutputParamsExample, Parameters/QuestionnairePackageInputParamsExample, Questionnaire/referred-questionnaire, QuestionnaireResponse/home-o2-questionnaireresponse and ServiceRequest/ServiceRequestExample
- This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html
  Show Usage
  - Coverage Class Codes: Coverage/CoverageExample and Parameters/QuestionnairePackageInputParamsExample
  - LibraryType: Library/library-quick-model-definition
  - Operation Outcome Codes: DTRMetricData
  - Organization type: Coverage/CoverageExample and Parameters/QuestionnairePackageInputParamsExample
  - Practitioner role: Bundle/home-o2-questionnairepackage-bundle-2, Bundle/home-o2-questionnaireresponse-bundle, Parameters/NextQuestionInputParamsExample, Parameters/NextQuestionOutputParamsExample and QuestionnaireResponse/home-o2-questionnaireresponse
  - SubscriberPolicyholder Relationship Codes: Coverage/CoverageExample and Parameters/QuestionnairePackageInputParamsExample
  - NullFlavor: DTRMetricData and IntendedUse
  - RoleCode: HomeOxygenTherapyStdQuestionnaire