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





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

Track Lead(s)

Specification Information

CRD - 
DTR - 
PAS - 

Reference Implementations

CRD -  
DTR -   
PAS -    

Call for participants

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

Zulip streams


Track Kick-Off Call

Track Pre-requisites

Knowledge of 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. 


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




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.


Point of Contact 

Clinical Scenario

CDS EndpointDTR App






Test Data

CQL Execution




PAS Subscriptions

PAS Additional documentation request




  • 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



Botolinum Toxin (Botox)

More from

YesYesYes/YesYesYesCQL engine

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


Kyle Johnsen


Colonoscopy, Endoscopy

No (Acting as CRD Client)NoNoNoCan prep data in or in dev environmentNone

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

Brian Poteet

Artem Sopin (

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

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


Peni Moxim

Anup Manhasaria

Radiation Oncology for Prostate CancerYesNoYesNoMaybeNoneNoNoNoReady to test with EHR and ready to test with other participants 
CRD ClientCan launch any DTR App

We have native functionality in the platform

Ready to test All scenarios as Provider

Michael Gould

Michael Gould 


Smile Digital Health

David Chisholm

Tom Kakanowski 

Brenin Rhodes

Rob Reynolds 

SMART Launch DTRYes, NoYesYesCQL Engine


Dan Newingham

YesYes, NoYesYesJavascriptYes

Testing in progress with Epic sandbox

Ranjan Saxena

Chidubem Okam

MRI - no authorization  needed. 

Chest CT (Prior authorization needed) 

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

Cosmetic Surgery (Not Covered)



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)






Epic/Evernorth POC









Epic/Smile DTR Launch

(Sleep Study)


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)
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: - coverage profile needs a clear member number in identifier - dtr launch needs examples - need detailed examples that span CRD/DTR/PAS


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


    LOINC code

    LOINC Description

    Free text associated with it in the PWK

    08 - Plan of Treatment


    Plan of care note


    M1 - Medical Record Attachment


    History and physical note


    M1 - Medical Record Attachment


    Diagnostic imaging study


    M1 - Medical Record Attachment


    Medical records


    M1 - Medical Record Attachment


    Medical records


    M1 - Medical Record Attachment


    Medical records


    M1 - Medical Record Attachment


    Medical records


    PN - Physical Therapy Notes


    Physical therapy Records total Encounter


    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.