other Submitting WG /Project / Implementer Group
Justification and Objectives
The goal of the Documentation Templates and Rules (DTR) reference implementation track is to show how it supports the DTR Implementation Guide (IG). Which is to specify how payer rules can be executed in a provider context to ensure that documentation requirements are met. The DTR IG is a companion to the Coverage Requirements Discovery (CRD) IG, which uses CDS Hooks to query payers to determine if there are documentation requirements for a proposed medication, procedure or other service. When those requirements exist, CDS Hooks Cards will be returned with information about the requirements. The DTR IG leverages the ability of CDS Hooks to link to a SMART on FHIR app to launch and execute payer rules. The DTR IG specifies how to maintain the transaction state as the workflow transitions from CDS Hooks to a SMART on FHIR app. It also describes the interactions between the SMART on FHIR app and the Payer IT system to retrieve documentation requirements, in the form of CQL and a FHIR Questionnaire resource. The primary objective will be to show the Reference Implementation (RI) does what the DTR IG claims
This track will use the STU3 version of FHIR.
Proposed Track Leads
CMS/CPI (via The MITRE Corporation), Rush University Medical Center, and MCG Health
Webinars will be hosted on Wednesday's from 11am - 12:00pm EDT on 4/17 and 4/24 to share further participation information about this track. Visit the HL7.org Conference Call page for the dial-in information.
Healthcare Provider / EHR
In this role, a provider wishes to discover the documentation requirements for home oxygen therapy as well as have a template pre-populated to satisfy Prior Auth requirements.
It is expected that the provider will be able to:
- Invoke CRD via CDS Hooks
- Populate the hook request with the necessary demographic, payer and requested service information or have a FHIR server that will respond to queries for the information
- Handle the response of the CRD CDS Hooks Cards
- It is expected, that they will be able to launch a SMART on FHIR application using the EHR launch sequence
- The SMART on FHIR app will collect information from the EHR using the template/rules returned from the payer system
In this role, the payer examines the request for Prior Auth, Documentation and Templates / Rules and responds appropriately. This could be viewed as the server part of the transaction.
It is expected that participants in this role will:
- Provide a server that implements the CDS Hooks specified in the CRD IG and the DTR IG
- Provide a FHIR Questionnaire that details the information requirements for the order review scenario
- Provide a FHIR Library that contains CQL with rules to extract the information needed by the Questionnaire from the EHR's FHIR server
Dara is a 64-year-old on Medicare FFS with long standing COPD who has had slowly and progressively worsening shortness of breath with activity. In the office her room air saturation after a 5-minute walk is 84%. She has additional evaluation that reveals no new findings. Dr. Good (Healthcare Provider) wants to initiate home oxygen therapy for Dara.
Using an application, Dr. Good performs a CRD query against the Healthcare Payer and is informed that specific testing and documentation is required to substantiate the need for home oxygen therapy.
Dr. Good is presented with a card with a link to a SMART app that contains a template that was pre-populated with EHR data with the help of the templates and rules from the Healthcare Payer.
Step 1 - Hook Request (CRD)
Action: Healthcare Provider executes order-review CDS Hook, sending the request to the Healthcare Payer which includes a CRD DeviceRequest resource and prefetches related resources
Precondition: Healthcare Payer has a prefetch template that requests the Patient, Encounter referenced in the hook context as well as the Coverage referenced by MedicationRequest.insurance
Success Criteria: Healthcare Payer receives a valid CDS Hook order-review request with all information needed to satisfy the request
Bonus point: Healthcare Provider supplies OAuth token
Step 2 - Fetch Relevant Data (CRD)
Action: Healthcare Payer issues FHIR GET requests to retrieve relevant Patient, Encounter, MedicationRequest, Coverage and other related resources
Success Criteria: Healthcare Payer obtains all information necessary to resolve the CDS Hook request made in Step 1
Bonus point: Healthcare Payer uses the OAuth token supplied in Step 1 and the Healthcare Provider requires OAuth for all requests
Step 3 - Return Cards (CRD)
Action: Healthcare Payer returns CDS Hooks Cards with documentation requirements. At least one Card has a link to the DTR app.
Success Criteria: Healthcare Provider system displays the cards
Bonus point: Healthcare Payer requests form completion and the Provider displays the form to complete
Step 4 – Open SMART on FHIR App (DTR)
Action: Healthcare Provider clicks a link within the returned Card, launching the DTR (SMART on FHIR App)
Precondition: Healthcare Payer has a Questionnaire / CQL Library that the DTR (SMART on FHIR App) can use to extract information requirements. The Healthcare Provider can launch a DTR (SMART on FHIR App) using the EHR launch sequence.
Success Criteria: The DTR (SMART on FHIR app) shows information collected from the patient chart and prompts a user for any information that is missing.
Bonus point: The Healthcare Payer secures their services with OAuth and the DTR (SMART on FHIR App) fetches the Questionnaire / CQL with a token for authorization.
Step 5 – Completion of the data collection SMART on FHIR App (DTR) (Stretch Goal)
Action: The provider completes the interaction with the DTR (SMART on FHIR App). The data from the dialogue is stored as a bundle in the provider EHR and also sent back to the Payer.
Precondition: Data in the SMART on FHIR (SoF) UI can be stored as a combination of FHIR resources (including DocumentReferences)
Success Criteria: The bundle is written in the EHR and can be queried. The bundle is successfully sent and written to the Payer’s data store. A record of the transaction is stored in both systems for later auditing.
Bonus point: DocumentReference resource contains a PDF with the results of DTR execution (for EHRs that can't handle structured data)
(Da Vinci CRD Use Case TestScripts from previous Connectathon used for initial development.)
The supporting TestScripts and corresponding fixtures have been committed to the FHIR documents Github repository at:
Security and Privacy Considerations
None, other than what exists in the CRD and DTR IGs