Short Description

Continue the testing of the Implementation Guides, as well as Reference and vendor Implementations for electronic Prior Authorization Da Vinci (CRD + DTR + PAS) IGs

Long Description

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.

Each of the use cases (IGs) represented in the Burden Reduction track has four specific areas in which everyone is encouraged to test.  Focus for these areas has been determined as beneficial for the advancement of the designs through directed testing.  They are...

CRD:

DTR:

PAS:


Type

Test Implementation Guides (IG) and Reference Implementations (RI)

Track Lead(s)

Specification Information

CRD - https://build.fhir.org/ig/HL7/davinci-crd 
DTR - http://build.fhir.org/ig/HL7/davinci-dtr 
PAS - http://build.fhir.org/ig/HL7/davinci-pas 

Reference Implementations

CRD - https://crd.davinci.hl7.org  
DTR - https://dtr.davinci.hl7.org   
PAS - https://prior-auth.davinci.hl7.org    

Call for participants

EHR vendors, Providers, payers, and other HIT related vendors

Zulip streams

CRD - https://chat.fhir.org/#narrow/stream/180803-Da-Vinci.20CRD/topic/Connectathons
DTR - https://chat.fhir.org/#narrow/stream/197320-Da-Vinci.20DTR/topic/Connectathons
PAS - https://chat.fhir.org/#narrow/stream/208874-Da-Vinci.20PAS/topic/Connectathons

Track Kick-Off Call

Track Pre-requisites

Knowledge of US Core (https://www.hl7.org/fhir/us/core/)

Technologies leveraged by the Burden Reduction use cases, such as the FHIR R5 Subscriptions Backport, CDS Hooks, and SMART on FHIR 

See underlying technologies/background page of Burden Reduction constituent Implementation Guides: 

ConMan Information

Testing Scenario:

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 System Actions (CRD)

Action:  Healthcare Payer returns System Actions from CDS Hooks with documentation requirements. At least one Card has a link to the DTR app (SMART App) and/or System Action to process.

Precondition:  none

Success Criteria:  Healthcare Provider system displays the cards and/or process System Action(s)

          • 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 via Subscription (PAS)

Action:  The EHR posts subscription to receive status update 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


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

Participants

If your organization intends to bring technology to this connectathon, please add yourself to this list and comment on each component. If your artifacts are available publicly, please add a URL. Otherwise, participants will contact the organizational POC for this information.


Organization

Point of Contact 

Clinical Scenario

CDS EndpointDTR App

Questionnaire

Resource 

CQL

Script

FHIR

Test Data

CQL Execution

Approach

PAS

App

PAS Subscriptions

PAS Additional documentation request


Maturity

Organization

Name

  • Name,
  • email,
  • Confluence user (@)

e.g. CPAP, Knee surgery, MRI Immunologic drug

(Note if you are working with other participant(s) on specific scenario and/or exchanges)

Do you have a CDS endpoint to use with CRDDo you have a DTR App?Do you have a Questionnaire resource? Is it adaptive?Do you have a CQL script for the scenario?Do you have test patients in a sharable FHIR bundleHow is your CQL executed? Javascript, CQL Engine, other?Do you have a PAS App?Support subscriptions conformant with Subscriptions R5 Backport IG?Able to request additional documentation leveraging CDex to launch DTR?

0. Building components for scenario

  1. All components built and being tested internally.
  2. Components and successfully tested - via Logica sandbox or other environment.
  3. Ready to test with other participants.
  4. Ready to test with EHR. 

Mettle Solutions LLC

Sreekanth Puram 

Home Health

Blepharoplasty

Rhinoplasty

Botolinum Toxin (Botox)

More from https://github.com/Medical-Mettles/medical-necessity/tree/master/coverage_determinations

YesYesYes/YesYesYesCQL engine


Ready to test with EHR and ready to test with other participants

Epic

Kyle Johnsen

kjohnsen@epic.com

MRI

Colonoscopy, Endoscopy

No (Acting as CRD Client)NoNoNoCan prep data in https://fhir.epic.com/Documentation?docId=testpatients or in dev environmentNone


Can test generic SMART on FHIR launch with others. Don't have support for DTR functionality like writing a QuestionnaireResponse.
Edifecs

Brian Poteet


Artem Sopin (artem.sopin@edifecs.com)

CodeX-related: BRCA testing, Chemo for Breast Cancer , Chemo for Colorectal Cancer (Docetaxel & Carboplatin)


Total Knee Arthroplasty

Endoscopy Screening

Home O2 Therapy (per ref implementation)


CRD and PAS submit/update

YesYesYesYesSome test data, but not sure how much will be sharable by the eventCQL EngineYes, but not externally exposed yetNoYes, but, in SoF app flows onlyCan do limited SMART launch and CDS hooks/CRD testing
Palmetto GBA

Kevin Prince 

Kevin.Prince@bcbssc.com

Multiple Topics (Outpatient Prior Auth)NoNoYes/NoYesYesCQL EngineYesNot Yet  (Hopefully!)
We've tested with MCG in a Logica environment, and we're hoping to test with other participants.
MCGRajesh Godavarthi Knee MRI and a few othersYesYesYesYesYesCQL Engine



Evernorth

Peni Moxim

peni.moxim@evernorth.com

Anup Manhasaria

Radiation Oncology for Prostate CancerYesNoYesNoMaybeNoneNoNoNoReady to test with EHR and ready to test with other participants 
Nucuralvishnu@nucural.com 
CRD ClientCan launch any DTR App

Yes
We have native functionality in the platform

Ready to test All scenarios as Provider
ZeOmega

Michael Gould

mgould@zeomega.com

Michael Gould 


Yes








Smile Digital Health

David Chisholm 

David.chisholm@smilcdr.com

Tom Kakanowski 

Brenin Rhodes
brenin.rhodes@smilecdr

Rob Reynolds 



SMART Launch DTRYes, NoYesYesCQL Engine



ZS

Dan Newingham 

dan.newingham@zs.com

seth.smeltz@zs.com



YesYes, NoYesYesJavascriptYes

Testing in progress with Epic sandbox
Humana 

Ranjan Saxena

rsaxena7@humana.com

Chidubem Okam

cokam@humana.com


MRI - no authorization  needed. 

Chest CT (Prior authorization needed) 

Lipid Panel (No Response / payer system action not needed) 

Cosmetic Surgery (Not Covered)


Yes 


Yes



Testing in progress with Epic.

Testing Scenario Roles:

Scenario/Name/Use caseProvider/EMR SystemPayer CRD clientCRD CDS systemDTR Operation system
(DTR API) Questionnaire

DTR App system

PAS Bundle creatorPAS IntermediaryPAS Payer

Prostate cancer radiation therapy for Codex

Aria (Varian)

CignaMettlesN/AEvernorth/Evicore

Mettles

N/A

N/A

N/A

Epic/Evernorth POC

EpicCigna

Epic

Evernorth/Evicore

N/A

N/A

N/A

N/A

N/A

Epic/Smile DTR Launch

(Sleep Study)

EpicSmileN/AN/ASmileSmileN/AN/AN/A

Epic/Smile/Palmetto DTR Launch

(Outpatient PA Req)

EpicPalmetto GBAN/AN/APalmettoSmileN/AN/AN/A
Palmetto / MCG (PAS Subscriptions)LogicaPalmettoN/AN/APalmettoMCGMCGN/APalmetto
Epic/Humana EpicHumanaEpicHumanaN/AN/AN/AN/AN/A
Epic/Edifecs (Oncology)EpicTest PayerEpicEdifecs Prior AuthEdifecs Prior Auth (SoF)Edifecs Prior Auth (SoF)Edifecs Prior Auth (SoF)Edifecs Prior Auth (SoF)Edifecs Prior Auth (SoF)
Epic/MCG CRD (Knee MRI)EpicMCGEpicMCGN/AN/AN/AN/AN/A
Prostate cancer radiation therapy POCNucural CignaNucuralEvernorth/EvicoreEvernorth/EvicoreMettlesNucuralN/AN/A

Extra Test- Smile/Edifecs DTR flow

Edifecs provided Questionnaire, CQL, and patient bundle

Smile posted to Smile repo in lieu of a Provider

Successfully called $populate on persisted patient data

2 Questionnaires were tested

Errors introduced on purpose, to explore Operation Outcomes


Epic Connectathon Summary-

Through the various tests we did there was a lot of time working through authorization issues (in particular OAuth2 vs how CDS hooks requires a signed JWT), and various bugs that had to be resolved on both sides, but overall had a lot of sucessful testing.

The issues we ran into that should get changes in the IGs are:

https://jira.hl7.org/browse/FHIR-41219 - coverage profile needs a clear member number in identifier

https://jira.hl7.org/browse/FHIR-41222 - dtr launch needs examples

https://jira.hl7.org/browse/FHIR-41223 - need detailed examples that span CRD/DTR/PAS



2 Comments

  1. March 8, 2023 Notes

    Kyle Johnsen (please correct any errors) - Epic is planning to attend and is currently focused on the CRD and will try to support DTR App launch via

    1. Generic SMART on FHIR app launch
      1. Participants can set up a developer account at fhir.epic.com for self-service testing. Information needed to register your app is on the site
      2. Participants are encouraged to do initial testing via the developer site
    2. Launch from Epic Dev environment - Provide information from 1a and 1b to Kyle once successful testing is completed in Epic testing sanbox
    3. System Action - plan to prototype

    Participants - Please fill out the table above, even if your participation at the Connectathon is tentative. We will use this to help with planning and coordination.


  2. The Colonoscopy/Endoscopy scenario I'm considering comes from grabbing a messy scenario from our existing 278/275 integration. Would need to figure out a way to CQL-ify it, but that looks like:

    Auth Request

    CPT 45378 - Colonoscopy

    CPT 45380 - Endoscopy


    The document request comes as a mix of PWK, LOINC, and free text:

    PWK

    LOINC code

    LOINC Description

    Free text associated with it in the PWK

    08 - Plan of Treatment

    18776-5

    Plan of care note

    VERIFICATION THAT THERE IS NO LASER INVOLVED IN REQUESTS FOR VARICOSE VE

    M1 - Medical Record Attachment

    34117-2

    History and physical note

    PATIENT HISTORY

    M1 - Medical Record Attachment

    18748-4

    Diagnostic imaging study

    REPORTS FROM X-RAY,MRIS OR CT SCAN,PET SCAN,AND OTHER LABORATORY/IMAGING

    M1 - Medical Record Attachment

    11503-0

    Medical records

    MD OFFICE NOTES AND EXAM FINDINGS RELATIVE TO THIS REQUEST

    M1 - Medical Record Attachment

    11503-0

    Medical records

    ANY INFORMATION YOU FEEL WOULD SUPPORT THIS REQUEST

    M1 - Medical Record Attachment

    11503-0

    Medical records

    PREVIOUSLY TRIED TREATMENTS AND MEDICATIONS

    M1 - Medical Record Attachment

    11503-0

    Medical records

    DOCUMENTATION OF MEDICAL NECESSITY FOR REQUEST OF OVERNIGHT STAY

    PN - Physical Therapy Notes

    11515-4

    Physical therapy Records total Encounter

    PHYSICAL THERAPY EVALUATION


    Submitting attachments

    End users aren't sure what they're looking for exactly. It's just anything that looks like it tells the health plan why they need this service. That is most often going to the most recent note, labs, meds and sometimes imaging.