2023 - 05 Da Vinci CDex: Attachments,Task-Based, and Direct Queries Between Payers and Providers

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

• This Connectathon focuses on Solicited and Unsolicited Attachments Using Loinc Attachment codes for claims and prior authorizations.  
• The Connectathon’s secondary focus is on testing Solicited Attachments Using NEW CDex functionality requesting data using Questionnaire/QuestionnaireResponse
  
  • Including Integration of CDex with standalone DTR to test 
• The Connectathon’s tertiary focus is on testing:
  
  1. Using Task as a mechanism to solicit clinical information from a remote system asynchronously
     • Including Integration of CDex with standalone DTR to test new CDex functionality requesting data using Questionnaire/QuestionnaireResponse
  2. Using Direct FHIR RESTful Query as a mechanism to solicit clinical information from a remote system synchronously
  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.)

• This Connectathon focuses on Solicited and Unsolicited Attachments Using Loinc Attachment codes for claims and prior authorizations.
  • These interactions are directly related to the 3/17/2023 DaVinci Response to the Proposed CMS Attachment Rules on 12/21/2022 :

The Da Vinci Project is not in favor of finalizing the proposed Attachments regulations as written ...
Withdrawing the Attachments NPRM would support industry efforts to comply with the Advancing
Interoperability and Improving Prior Authorization Processes NPRM (Interoperability NPRM
ii), if finalized as proposed, and broader use of existing HL7 Fast Healthcare Interoperability Resources (FHIR®)
capabilities, and permit real-world use of the clinical data exchange (CDex) standard that enables well
defined attachment information as data and/or documents across prior authorization or claims
attachments....

• The Connectathon’s secondary focus is on testing Solicited Attachments Using NEW CDex functionality requesting data using Questionnaire/QuestionnaireResponse
  
  • This new functionality allows implementers to request data using a form/questionnaire and responding with QuestionnaireResponse leveraging the DTR specification to automate filling out the Questionnaire.

• The Connectathon’s tertiary focus is on testing the rest of the  CDex implementation guide

1. 1. Using Task as a mechanism to solicit clinical information from a remote system asynchronously
   2. Using Direct FHIR RESTful Query as a mechanism to solicit clinical information from a remote system synchronously

         c. Use of FHIR Digital Signatures with all of the above transactions

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

Da Vinci Clinical Data Exchange (CDex)

Reference implementation:  

TestScript(s):

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

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.

Track Kickoff Call: April 12th at 2:00 PM ET

• Slides: May2023Connectathon_CDex.pdf
• Recording: https://zoom.us/rec/play/da35OK0kMUpuJniep6Q00symoh80Jwo7yP-ToyI_YsgW9aJ1FQEUEa2V1ekD-EHbKF8kCCSefxtGd9VK.qyp4tgUZW3coMkhD?autoplay=true&startTime=1681322760000 

Previous Participant Information Sessions:

• (Dec 2022): Information Session Recording
• (Sept 2022): Information Session Recording

1. Write an app, set up server, or create your collection to test ahead of time....

2. Background Reading:
   1. 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
3. Register for an account on Touchstone (reach out to one of the leads if you need help with this)
4. Have registered for an account to login into the RI (reach out to one of the leads if you need help with this)
5. Either

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

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

Scenario 1: Unsolicited Attachments of CCDA Documents Using LOINC Attachment Codes

See CDEX Use Case: Unsolicited Attachments of CCDA Documents Using LOINC Attachment Codes

Scenario 2: Solicited Attachments of CCDA Documents Using LOINC Attachment Codes

See CDEX Use Case: Solicited Attachments of CCDA Documents Using LOINC Attachment Codes

Scenario 3: Attachments for Home Oxygen Therapy Using Questionnaire

See CDEX Use Case:  CDEX Use Case: Attachments for Home Oxygen Therapy Using Questionnaire

POSTMAN Collection for Scenarios 1,2,3

Other Scenarios:

Direct Query Transactions

For detailed documentation see: http://hl7.org/fhir/us/davinci-cdex/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://hl7.org/fhir/us/davinci-cdex/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 week 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 and 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://hl7.org/fhir/us/davinci-cdex/signatures.html

Signer (Data Source)

• A system capable of digitally signing 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 capable of verifying digitally signing a FHIR search and documents bundles.

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