2023 - 01 Da Vinci Clinical Documentation Exchange/Attachments (CDex)

This Da Vinci track is focused on testing the functionality of the CDex implementation guide (CDex).

• The Connectathon’s primary focus is on testing the Requesting and Submitting attachments for claims and prior authorizations
• NEW Integration of CDex with standalone DTR to test new CDex functionality requesting data using Questionnaire/QuestionnaireResponse
• The Connectathon’s secondary focus is on testing:
  1. Using Direct FHIR RESTful Query as a mechanism to synchronously solicit clinical information from a remote system
  2. Using Task as a mechanism to asynchronously solicit clinical information from a remote system
  3. Use of FHIR digital signatures with above

This track will continue the work of several past connectathon tracks testing out CDex. CDex depends on components defined in the Da Vinci HRex Implementation Guide.)

• The Connectathon’s primary focus is on testing the Requesting and Submitting attachments for claims and prior authorizations

• NEWTesting new functionality to request data using a form/questionnaire and responding with a QuestionnaireResponse leverage the DTR specification to fill out the Questionnaire ( see our notes here)
• 

• The Connectathon’s secondary focus is on testing:

1. 1. Using Direct FHIR RESTful Query as a mechanism to synchronously solicit clinical information from a remote system
   2. Using Task as a mechanism to asynchronously solicit clinical information from a remote system
2. 
3.  
   1. Use of FHIR digital signatures with above

Attendees are requested to identify in advance which of these aspects of the track they plan to be prepared to test

Break-outs TBD

Eric Haas

mailto:ehaas@healthedatainc.com

NOTE WE ARE USING THE CI BUILD VERSION: http://build.fhir.org/ig/HL7/davinci-ecdx/

Reference implementation:  

• Endpoints:
  • Data Consumer/Payer: https://api.logicahealth.org/DaVinciCDexPayer (e.g., for Fetching a Claim)
  • Data Consumer/Payer submit attachment endpoint is  https://cdex-commreq.davinci.hl7.org/$submit-attachment
  • Data Source/Provider: https://api.logicahealth.org/DaVinciCDexProvider (e.g., for POSTing  a Task) 

How to navigate the RI

TestScript(s):

Touchstone CDEX testscripts: Please reach out to Touchstone_Support@aegis.net with any questions on how to test.

Data source systems such as EHR/HIT

Payer systems such as Payers/Intermediaries/Payment Processors

Track Kickoff Call

December 14th from 2:00 - 3:00 PM ET (during standing weekly CDex call)

Recording: https://hl7-org.zoom.us/rec/share/L7RzUw3AxG2ooFZPPP6uYpt34UipmqK-bzrdLeHxOJmnCNc2UeIiy_iF8NJslSo0.m5UjpAnrJm5NhDcJ?startTime=1671044689000

Previous Participant Information Sessions (Sept 2022): Information Session Recording

1. Read: CDex IG
2.  For Attachments in addition to 1 
   1. A basic understanding of the Attachments workflow
   2. HREX Approaches to Exchanging FHIR esp Requesting exchange using Task
   3. FHIR Task resource,
   4. FHIR Operations,
3. For using Questionnaire/QuestionnaireResponse to request data in addition to 1 and 2:
   1. DTR IG exp  Launch Outside of CRD
   2. FHIR Structured Data Capture
      
4. For Direct Query in addition to 1
   1. read FHIR RESTful Queries

   2. US Core

5. For Task Based Query in addition to 1
   1. HREX Approaches to Exchanging FHIR esp Requesting exchange using Task
   2. FHIR Task resource,
   3. Subscriptions Backport IG
6.  Signatures:
   1. FHIR Signatures and the Signature datatype
   2. Basic understanding of JWS
   3. l SHC Protocol  is also helpful 

1. Register for an account on Touchstone (reach out to one of the leads if you need help with this)
2. Have registered for an account to login into the RI (reach out to one of the leads if you need help with this)
3. Either
   1. Technical editing environment capable of creating instance examples and submitting directly to a server 
   2. Development environment with code that supports at least one of the track scenarios

....And obviously write an app, set up server, or create your collection to test ahead of time....

System roles:

NOTE: participants should expect to complete most of their development in advance of the track.  START TODAY...

Requesting and Sending Attachments

For detailed documentation see: http://build.fhir.org/ig/HL7/davinci-ecdx/attachments.html

Data Consumer (Payer)

• A system that processes claims and/or prior authorization requests and is able to:
  • receive unsolicited and solicited attachments using the CDex $submit-attachments operation.
  • send requests for attachments using the CDex Task Attachment Request Profile.
  • associate unsolicited and unsolicited attachments. to a claim or preauthorization

Data Source (Provider)

• A system that has attachments that need to be associated with an existing or future claim or prior authorization request and can:
  • receive and process requests for attachments using the CDex Task Attachment Request Profile.
  • push this data to payer unsolicited and solicited attachments using the CDex $submit-attachments operation

Example Transaction

Unsolicited Attachments

Action: Data Source invokes the '$submit-attachment' operation on the  Data Consumer to attach a document to an existing Claim Response.  The Data Consumer returns a success code

Precondition: Data Source knows the Data Consumer's member identifier for the patient.  An un-processed prior authorization with a known tracking id and pre-auth identifier exists on the Data Consumer's system

Success Criteria: The submitted attachment is associated with the pre-existing prior authorization on the  Data Consumer's system.

Bonus point(s):

• • Try sending multiple attachments at once
  • Try sending attachments to a claim rather than a prior authorization
  • Try sending attachments to a prior authorization that is already processed or otherwise not 
  • Try sending the attachment prior to the prior authorization having been submitted, then send the prior authorization after the fact (via PAS)

Solicited Attachments

Action: Provider creates a claim and sends it to the Payer. The Payer reviews the claim and responds with a request for a Progress Note using the CDex Attachment Request Profile.

Action: Data Source receives the attachment request, collects the documentation, and returns them using the [$submit-attachment] operation, posting it to the endpoint supplied in the request.

Precondition: The  Data Source knows the Data Consumer's member identifier for the patient.  An claim or prior authorization with a known identifier exists on the Data Consumer's system

Success Criteria: The submitted attachment is associated with the pre-existing prior authorization on the Unsolicited Data Consumer's system.

Bonus point(s):

• • Try sending multiple attachments at once
  • Try sending attachments to a claim rather than a prior authorization
  • Try sending attachments to a prior authorization that is already processed or otherwise not 
  • Try sending the attachment prior to the prior authorization having been submitted, then send the prior authorization after the fact (via PAS)

Requesting and Sending Questionnaire/QuestionnaireResponse using the CDEX Attachment Workflow

1. Payer requests data with a  input parameter in the CDex Task Request Profile that points to a url of a Questionnaire
   • This associated with a  Task.code
   • The Questionnaire may or may not be standardized- i.e., it can ask anything
   • The Task can only contain one Questionnaire, no mixing codes, search queries, etc with Questionnaires
2. EHR Launch DTR and gives access to the Task
   • Trigger for the Data Source to launch DTR is the url to a Questionnaire and the Task.code
   • Task lives on Data Source
3. DTR app loads and answer questionnaire (See DTR especially Launch outside of CRD)
4. DTR Return QuestionnaireResponse link as a Task.output parameter and updates the Task as “completed”
5. Data Source (Provider) returns QuestionnaireResponse to Data Consumer (Payer) as a $submit-attachment parameter

Direct Query Transactions

For detailed documentation see: http://build.fhir.org/ig/HL7/davinci-ecdx/direct-query.html

Direct Query Server (Provider)

• A system that has (or might have) information about a patient/member and which can respond to  FHIR RESTful queries synchronously.

Direct Query Client (Payer or Provider)

• A system that needs information about a patient/member and which can solicit that information using standard FHIR RESTful queries.

Example Transaction

Action: Synchronous Data Consumer executes a RESTful search the Synchronous Data Source's system that will return the patient's active medication orders

Precondition: The Synchronous Data Consumer knows the Synchronous Data Source's patient identifier for the patient/member in question (see step 1)

Success Criteria: Synchronous Data Consumer Payer has all of the active medication orders for the patient/member

Bonus point(s):

• • Request data for a patient the Synchronous Data Consumer doesn't have a right to see (e.g. payer asking for patient data when there is no coverage relationship) and the Synchronous Data Source returns an error
  • Asynchronous Data Source digitally signs the returned search bundle and the Synchronous Data Consumer validates the signature
  • Try some of the other queries listed here

Task Based Transactions

For detailed documentation see: http://build.fhir.org/ig/HL7/davinci-ecdx/task-based-approach.html

Task Based Request Server (Provider)

• A system that has (or might have) information about a patient/member and which can respond to asynchronous queries using CDEX Task based approach potentially involving human intervention.

Task Based Request Client (Payer or Provider)

• A system that needs information about a patient/member and which can solicit that information using the asynchronous CDEX Task based approach.

Example Transaction

Knee Surgery

Action: Asynchronous Data Consumer creates a Task on the Asynchronous Data Source's system soliciting a patient's knee surgery report and then polls for updates to the Task.  When the Task is complete, the Data Consumer reads the document referenced via the Task.output

Precondition: The Asynchronous Data Consumer knows the Asynchronous Data Source's patient identifier and (if needed) coverage identifier for the patient in question (see step 1)

Success Criteria: Asynchronous Data Consumer has a copy of the requested document

Bonus point(s):

• • Rather than polling, the Asynchronous Data Consumer creates a subscription on the Asynchronous Data Source that monitors the Task for updates
  • The Asynchronous Data Source updates the status to indicate progress prior to completion
  • The Asynchronous Data Source refuses the request
  • The Asynchronous Data Consumer cancels the task before it is complete

Advanced preparation is required for implementing the Subscriptions R5 backport as a new feature. Allow for at least 1 weeks prior to the start of the connectathon for preliminary testing.  Support will be available virtually on http://chat.fhir.org. 

Medication List

Action: Asynchronous Data Consumer creates a Task on the Asynchronous Data Source's system soliciting the execution of a query that will return the patient's active medication orders then polls for updates to the Task.  When the Task is complete, the Asynchronous Data Consumer reads the search response Bundle referenced via the Task.output

Precondition: The Asynchronous Data Consumer knows the Asynchronous Data Source's patient identifier and (if needed) coverage identifier for the member in question (see step 1)

Success Criteria: Asynchronous Data Consumer Payer has all of the active medication orders for the member

Bonus point(s):

• • Rather than polling, the Asynchronous Data Consumer creates a subscription on the Asynchronous Data Source that monitors the Task for updates
  • The Asynchronous Data Source updates the Task with "in progress" status information before it is marked as complete
  • The Asynchronous Data Source refuses the request
  • The Asynchronous Data Source requests that the query response be packaged in a signed document
  • The Asynchronous Data Consumer cancels the task before it is complete
  • Try some of the other queries listed here

Signatures

For detailed documentation see: http://build.fhir.org/ig/HL7/davinci-ecdx/signatures.html

Singer (Data Source)

• A system that is capable of digitally signing a FHIR search bundles (for direct queries) and/or creating and digitally signing document bundles (for task-based queries and attachments).

Verifier (Data Consumer)

• A system that is capable of verifying digitally signing a FHIR search and documents bundles.

Example Data: ( This is stale and needs to be updated)

See the  Example Data  and example scenarios for each type of exchange in the implementation guide

Example FlowCharts:

source https://hackmd.io/o_JtpJtdRjqsO25TlNhMhw?both

to view full size charts copy/paste the text between the triple backtics to https://flowchart.js.org/ 

Security and Privacy Considerations:

None at this time