Page tree
Skip to end of metadata
Go to start of metadata

This page and it's subpages are focused on the ongoing efforts to continue testing Da Vinci Burden Reduction components between Connectathons. 

Multi-Participant Testing Proposal - MCG

Weekly Scrum Meetings

Quick sessions to assess testing progress and raise blocking issues.

Monday at 3:30pm ET 

Email or for the link to join. 

Zulip Chat Stream - #DaVinci Burden Reduction interoperability.


Track overview

The Da Vinci Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), Prior Auth Support (PAS) Implementation Guides (IGs) together support an integrated workflow to enable automated submission of required documentation and prior authorization from EHR and payer systems respectively. We expect the use of these IGs is likely to be mandated as part of regulation. We have had past connectathon testing of CRD, DTR, and PAS. This track will ensure that the IGs work appropriately, independently, as well as in concert.

This track will use:


Most current FHIR to X12 278 Mapping Spreadsheet: 

ReadMe Doc 2020 SEP Connectathon v1.docx 


Test Implementation Guides

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group

Clinical Decision Support / CRD / Da Vinci / CMS / MITRE 

Financial Management / DTR / Da Vinci / CMS / MITRE 

Financial Management / PAS / Da Vinci / CMS / MITRE 

Proposed Track Lead

Larry Decelles  Gary P. Gryan  

Other Contacts

Robert Dieterle Mary Kay McDaniel

Related tracks


Specification(s) this track uses




Artifacts of focus


Clinical input requested (if any)

There is little expectation of direct clinical input in this track, though ideas about types of required documentation to test and feedback around the provider experience manifested by the CRD, DTR, and PAS IGs are welcome.

Patient input requested (if any)

There is little expectation of direct clinical input in this track, though ideas about types of required documentation to test and feedback around the provider experience manifested by the CRD, DTR, and PAS IGs are welcome.

Expected participants

We expect 6-12 payer members, 1-2 EHR implementers, and 1-2 providers to participate

 Contact Name



Role (Payer, Provider, Other)


Ben Langleyblangley@mitre.orgMITREReference Implementation
Sumit Lahirisumit.lahiri@optum.comUHCPayer
Sree MallipeddiSreenivasreddy.Mallipeddi@mcg.comMCGOther
sreekanth.puram@mettles.comMettle SolutionsOther
Srinivas Velamurisvelamur@telligen.comTelligenOther

Zulip stream

CRD - CRD Zulip

DTR - DTR Zulip

PAS - PAS Zulip 

Track Orientation

Note: The below schedule is subject to change and will most likely change based on Connectathon work.

Thursday 9/10  

Approximate time (EDT)

9 AM

Pat LaRocque - CRD / DTR VM

10 AM

Interoperability / Integration / Connectivity Support

10:45 AM


11 AM

Larry Decelles - CRD / DTR update and overview, Gary Gryan - PAS update and overview 

11:30 AMPat LaRocque - source code review / file structure layout

12 Noon


1 PM

Keeyan Ghoreshi - DTR

2 PM

Pat LaRocque - CRD

2:45 PM


3 PM

Interoperability / Integration / Connectivity Support

4 PM

Meg Riley - Aegis Touchstone and testing PAS, CRD

Friday 9/11

Approximate time (EDT)

9 AM

Interoperability / Integration / Connectivity Support

10 AM

Yolanda Liu - CRD/DTR Rule Sets (CQL/Questionnaires)

11 AM


11:15 AM

Sree Mallipeddi - MCG Demo

12 Noon


1 PM

Ben Langley - Prior Authorization Automated Dispositions with CQL

2 PM

CRD/DTR/PAS - HL7 Da Vinci readout

3 PM


3:15 PM

Sreekanth Puram - Mettle Solutions Demo  

4 PM

Interoperability / Integration / Connectivity Support

Track Preparation

Before the connectathon begins please come ready with your implementations ready to go. The reference implementations can be installed by following this guide: Setting up CRD:DTR:PAS.pdf

A video tutorial to set up the entire process can be found at:

Optional Alternative Setup

Alternatively, a Virtual Machine (VM) is available for download that contains the CRD, DTR, and all of the test software (CRD Request Generator, Keycloak, Test EHR) configured and ready to run. Please contact for access.

Please note that the VM requires host machine to contain more than 8gb of RAM as the virtual machine requires that on its own.

Track details

System Roles

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

    It is expected that the provider will be able to:

  1. Invoke CRD via CDS Hooks
  2. Populate the hook request with necessary demographic, payer and requested service information or have a FHIR server that will respond to queries for the information
  3. Handle the response of the CRD CDS Hooks Cards
  4. It is expected, that they will be able to launch a SMART on FHIR application using the EHR launch sequence
  5. The SMART on FHIR app will collect information from the EHR using the template/rules returned from the payer system

    Healthcare Payer

    In this role, the payer examines the request for Documentation Templates and Rules (DTR) and responds appropriately. This could be viewed as the server part of the transaction.

    It is expected that participants in this role will:

  1. Provide a server that implements the CDS Hooks specified in the CRD IG 
  2. Provide a FHIR Questionnaire that details the information requirements for the "order-sign" scenario
  3. Provide a FHIR Library that contains CQL with rules to extract the information needed by the Questionnaire from the EHR's FHIR server


order-sign Scenario

This scenario follows the constraints on the order-sign CDS Hook as described in the CRD IG. As well the Questionnaire / QuestionnaireResponse constraints in the DTR IG

Lara is a 65-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 Lara.

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. 

NOTE: This scenario contains numerous steps. Ideally connectathon participants will get to a point where they can perform all of the steps. However, participating with an intention to focus on only a few steps (ideally those covered by a specific implementation guide) is still useful.

Step 1 - Hook Request (CRD)

Action: Healthcare Provider executes "order-sign" CDS Hook, sending the request to the Healthcare Payer which includes a CRD DeviceRequest resource and prefetched related resources

Precondition: Healthcare Payer has a prefetch template that requests the Patient and Encounter referenced in the hook context as well as the Coverage referenced by

Success Criteria: Healthcare Payer receives a valid CDS Hook "order-sign" 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, DeviceRequest, Coverage, and other related resources

Precondition: none

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 Card(s) with documentation requirements. At least one Card has a link to the DTR app (SMART App).

Precondition: none

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 DTR using the EHR launch sequence.

Success Criteria: DTR 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 DTR fetches the Questionnaire/CQL with a token for authorization.

Step 5 – Completion of the data collection SMART on FHIR App (DTR)

Action: The provider completes the interaction with DTR by populating all required fields that were not pre-populated by DTR. The data from the dialogue is stored as a bundle in the provider's EHR.

Precondition: Data in the DTR UI can be stored as a combination of FHIR resources (QuestionnaireResponse and DocumentReference)

Success Criteria: A DocumentReference bundle is written to the provider's EHR and can be queried. 

Bonus point: None

Step 6 – Submission of Prior Authorization (PAS)

Action: The EHR generates a prior authorization request bundle that complies with the PAS profile and includes "supportingInfo" references to all resources created by the SMART on FHIR app in Step 5 and invokes the $submit operation on the intermediary

Precondition: Agreement on what terminologies will be used for elements in the PAS prior authorization request bundle

Success Criteria: The intermediary receives and initiates processing of the prior authorization Bundle

                          Bonus pointNone

Step 7 – Prior Authorization Request conversion (PAS)

Action: The intermediary converts the prior authorization Bundle to an X12 278 message with un-submitted 275 messages for all 'supporting Info' data as well as an overall 275 containing the FHIR Bundle as a binary.  All messages are then sent to the 

Precondition: Mapping information is available to the intermediary

Success Criteria: The intermediary receives and initiates processing of the prior authorization Bundle

Bonus pointNone

Step 8 – Prior Authorization conversion (PAS)

Action: The Payer processes the X12 278 and any 275s (that were converted from FHIR data) and generates an appropriate 278 response and sends it to the intermediary

Precondition: None

Success Criteria: A valid 278 response is created

Bonus pointProcess using some of the information present in the FHIR Bundle (that was passed as a 275 Binary) directly

Step 9 – Prior Authorization Response conversion and delivery (PAS)

Action: The intermediary receives the 278 response and generates a valid FHIR prior authorization response Bundle that complies with the PAS implementation guide and synchronously returns it to the EHR application

Precondition: None

Success Criteria: A valid prior authorization response Bundle has been delivered to the EHR 

Bonus pointNone

Step 10 – Prior Authorization status check/polling (PAS)

Action: The EHR queries the intermediary for the current status of a prior authorization response.  The Intermediary converts the query to a 278i which it invokes on the Payer.  It then converts the 278i response into a Prior Authorization Response Bundle and delivers it to the EHR.

Precondition: The prior authorization response contains at least one 'pended' item

Success Criteria: The EHR receives a current copy of the prior authorization response

Bonus pointUse subscription to notify the EHR when content is available for query

Step 11 – Prior Authorization Revision (PAS)

Action: The EHR submits an update to a previously submitted prior authorization request to an Intermediary.  The Intermediary converts the revision to a 278 and/or 275s and passes those to the Payer, then converts the response and passes a converted response back to the EHR

Precondition: A prior authorization has previously been submitted

Success Criteria: The payer has an amended prior authorization request and the EHR has at least a preliminary response to the amended request

Bonus point: Try revising some items, cancelling others and adding new ones

Step 12 – Go for a drink

Action: Celebrate making a huge difference for patient experience and health system efficiency.  (If you get this far, you've more than earned it!)

Precondition: Hotel bar or other appropriate venue is available Safely at home 

Success Criteria: As determined by participants you

Bonus pointNone


Touchstone Tests are found at: See CRD test scripts under CDS Hooks 

Please create a Touchstone user account (free) associated with the Da Vinci organization if you have not already. In order to run your systems through the test scripts.

Security and Privacy Considerations

TLS and OAuth will be required as defined in the CRD, DTR, and PAS IGs

Access to Value Sets

Please see Larry Decelles regarding value set use in DTR    


  • No labels