2020-05 Da Vinci CRD/DTR/PAS

Important CRD / DTR / PAS Track events

Zulip (chat with us during the Connectathon)

CRD - CRD Zulip

DTR - DTR Zulip

PAS - PAS Zulip 

Submitting WG / Project / Implementer Group

Clinical Decision Support / CRD / MITRE 

Financial Management / DTR / MITRE 

Financial Management / PAS / MITRE 

Justification and Objectives

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: FHIR R4 

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.

Related tracks

None

Track Leads

Larry Decelles  Gary P. Gryan  

Other Contacts

Robert Dieterle Mary Kay McDaniel

Expected participants

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

Track Orientation

2020-05 Zoom Info for Each Track

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:

End Points

Scenarios

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

Scenarios

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

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 point: None

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 point: None

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 point: Process 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 point: None

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 point: Use 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 point: None

TestScript(s)

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    

Videos (post Connectathon)

Day 1.01 Larry leads discussion about the main concepts behind DTR IG and CRD IG.mp4Day 1.02 Discussion with Signa, Evercore about standing up their own parallel version of CRD and DTR.mp4Day 2.03 Discussion of vsac.nlm.nih.gov.mp4Day 2.04 Demo of VSAC value sets in MITRE’s reference implementation.mp4Day 2.05 Discussion of VSAC authoring, use, governance, CQL.mp4Day 2.06 History of DaVinci, CRD, DTR, PAS.mp4Day 2.07 Discussions on PAS and workflow.mp4.zip

Day 2.08 Discussion (multiple topics).mp4

Day 2.09 Mettle demo.mp4

Day 2.10 MITRE demo.mp4