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

Submitting WG/Project/Implementer Group

Financial Management

Justification and Objectives

The Da Vinci Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) and Prior Authorization Support (PAS) together support an integrated workflow to enable automated submission of prior authorizations from EHR systems.  We expect the use of these IGs are likely to be mandated as part of regulation.  While we have had past connectathon testing of both CRD and DTR, both specifications have been updated and neither have been tested end-to-end with the new PAS implementation guide.  This track will ensure that all three 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 prior authorizations to test and feedback around the provider experience manifested by the CRD and DTR IGs is welcome

Related tracks

2019-09 Da Vinci Payer Data Exchange

Proposed Track Lead

Gary Gryan (ggryan@mitre.org)

Expected participants

We expect 10-15 payer members and 1-2 EHR implementers to participate

Track Orientation

A webinar will be hosted on TBD to share further participation information about this track.

See Zulip for Connectathon live updates - https://chat.fhir.org/#narrow/stream/208874-Da-Vinci.20PAS

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 Prior Auth requirements.

It is expected that the provider will be able to:

  1. Invoke CRD via CDS Hooks
  2. 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
  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 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:

  1. Provide a server that implements the CDS Hooks specified in the CRD IG and the DTR IG 
  2. Provide a FHIR Questionnaire that details the information requirements for the order review 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

    Healthcare Payer Intermediary

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:

  1. Provide a server that implements the CDS Hooks specified in the CRD IG and the DTR IG 
  2. Provide a FHIR Questionnaire that details the information requirements for the order review 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.  Finally it involves the submission of the resulting information as a prior authorization request in compliance with the PAS IG.

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. 

After completing the information, their EHR submits a prior authorization request with the needed data and receives back an authorization


NOTE: This scenario contains numerous steps.  Ideally connectathon partipants 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 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-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, MedicationRequest, 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 Cards with documentation requirements. At least one Card has a link to the DTR 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 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)

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 and QuestionnaireResponses)

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 pointDocumentReference resource contains a PDF with the results of DTR execution (for EHRs that can't handle structured data)

see http://build.fhir.org/ig/HL7/davinci-dtr/specification__behaviors__persisting_results.html


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

Success Criteria: As determined by participants

                          Bonus pointNone


TestScript(s)

TBD

Security and Privacy Considerations

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

  • No labels