*** DRAFT - WORK IN PROGRESS ***

Summary

The purpose of this Coverage Requirements Discovery (CRD) and Documentation Templates and Coverage Rules (DTR) Supplemental Guide (SG) is to provide further context on the detailed representation of the clinical data and data payload in a provider-to-payer exchange. FHIR examples demonstrating representation of this guidance are provided to illustrate the points made in the guide. It is possible that some of this content will be merged into the CRD and/or DTR FHIR Implementation Guides (IG) in a future release.

Overview

Background

Documentation Templates and Rules (DTR) show how payer rules can be executed in a provider context to ensure that documentation requirements are met. DTR is a companion to Coverage Requirements Discovery (CRD), which uses Clinical Decision Support (CDS) Hooks to query payers to determine if there are documentation requirements for a proposed item, medication, procedure, or other service. When those requirements exist, a CDS Hooks Card(s) will be returned with information about the requirements. DTR leverages the ability of CDS Hooks to link to a SMART on FHIR or native EHR app (app) to launch and execute payer rules. DTR maintains the transaction state as the workflow transitions from CDS Hooks to the app. It describes the interactions between the app and the payer IT system to retrieve documentation requirements, in the form of CQL and a FHIR Questionnaire resource.

Scope and Assumptions

In Scope

An attempt will be made to address all key functionality found in the CRD and DTR IGs. As noted above this is a "work in progress" and it is expected to take some time to be fully complete.

Note: This Supplemental Guide is meant to provide best practices and recommendations for those wishing to implement CRD and DTR. Although some of the content in this Supplemental Guide might be added to the above mentioned IGs at a future date. This Supplemental Guide is not currently part of any normative standard.     

Out of Scope

Currently this SG does not address Prior Authorization Support (PAS).  

Important Terms and Technology 

  • CDS Hooks - As mentioned above CRD uses CDS Hooks. This SG will demonstrate the order-sign hook. order-sign is used when a clinician is ready to sign one or more orders for a patient, (including orders for medications, procedures, labs and other orders). This hook is among the last workflow events before an order is promoted out of a draft status. The context contains all order details, such as dose, quantity, route, etc, although the order has not yet been signed and therefore still exists in a draft status. Use this hook when your service requires all order details, and the clinician will accept recommended changes.


  • SMART on FHIR - As mentioned above is the DTR SMART on FHIR app. Note: It is possible DTR could be implemented in a native EHR or native Practice Management System app. For this SG we will focus on a SMART on FHIR based DTR app. The SMART App Launch Framework connects third-party applications to Electronic Health Record data, allowing apps to launch from inside or outside the user interface of an EHR system. The framework supports apps for use by clinicians, patients, and others via a PHR or Patient Portal or any FHIR system where a user can give permissions to launch an app. It provides a reliable, secure authorization protocol for a variety of app architectures, including apps that run on an end-user’s device as well as apps that run on a secure server. 


  • Questionnaire - As mentioned above the use of FHIR based Questionnaires is an important part of DTR in regards to the way in which questions and question responses pre-population happen. A Questionnaire is an organized collection of questions intended to solicit information from patients, providers or other individuals involved in the healthcare domain. They may be simple flat lists of questions or can be hierarchically organized in groups and sub-groups, each containing questions. The Questionnaire defines the questions to be asked, how they are ordered and grouped, any intervening instructional text and what the constraints are on the allowed answers. The results of a Questionnaire can be communicated using the QuestionnaireResponse resource.



Installing CRD and DTR 

A complete end-to-end install guide can be found here. Note: It is recommended that CRD and DTR be installed on a MacOS but it Windows is OK. Also, Documentation Requirement Lookup Service (DRLS) is just the combination of CRD and DTR. Once installed the user would be able to swap in their own app. For example an EHR vendor would be expected to use their own EHR and Authorization app instead of the test-ehr and KeyCloak app described in the install guide above.     

Identifying Provider organizations

Todo

Identifying Coverage Plans

Todo

  • No labels