2023 - 01 Da Vinci Burden Reduction (BR) Track

Our Goal is to test CRD/DTR/PAS interoperability with as many interested parties as possible. e.g. EHR vendors, Providers, Payers, and others. The Da Vinci Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Auth Support (PAS) Implementation Guides (IGs) together support an integrated workflow to enable automated submission of required documentation and/or prior authorization from EHR and payer systems respectively. 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.

There will be three specific areas which will be given additional focus beyond prior Connectathon track efforts:

1.  The ability to support a robust CRD interaction by including CDS Hooks implementations returning multiple Cards where appropriate.  
2.  Testing usability and interchange ease for CQL/CQL Libraries within the expected DTR workflows.
3.  The support for subscriptions within the PAS workflow, leveraging latest Subscriptions R5 Backport version (CI Build) which supports R4 compatibility

Jeff Brown (jeff.brown@lantanagroup.com) 

Friday December 16, 2022  (3:00 pm Eastern)

Webmeeting Info:  https://hl7-org.zoom.us/j/99425780016?pwd=Mlgxa2dIYVpEWHVDTGtIZTQwbTNRZz09 
Phone: +1 770-657-9273, Participant Code: 536832

Call Recording: https://hl7-org.zoom.us/rec/share/EqCqM_TJ7luYv5clmBsrSSkBrjnXSfvLftss0I5mTn5A5Cd18p42AxNVyXY25CKA.5Elp23qiM9p7SzGM?startTime=1671221098000

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:

• • • • Invoke CRD via CDS Hooks
      • 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
      • 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

• • 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:

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

Note: If needed participants should install the Reference Implementations (RI) in advance as this process can be time consuming. See Track Preparation for details. 

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

Security and Privacy Considerations:

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

Results

TBD