Short Description

This Da Vinci track is focused on testing the functionality of the CDex implementation guide.  It covers provider to provider and provider to payer exchanges to help facilitate continuity of care.  Testing will focus on 4 topics:
  • using Task as a mechanism to asynchronously solicit clinical information from a remote system
  • invoking an operation to submit unsolicited attachments to claims and prior authorizations
  • Use of signatures with
    • Task-based data requests
    • Direct query-based retrieval 

Long Description

This track will continue the work of several past connectathon tracks testing out the HRex and CDex implementation guides.  (CDex depends on components defined in HRex.)

NOTE: Unlike some past connectathons, this track will not incorporate the PCDE implementation guide as PCDE development work is on hold until Jan. 2022.

 The specific aspects of the IGs that will be a focus of this track include:

  • Testing the subscription/notification approach for CDex Task submissions.
  • Use of signatures with Task-based data requests
  • Using the new 'attach' operation for attaching documentation to claims and prior-authorization requests
  • Digitally signing search responses

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

Agenda

Introduction:

Demonstrations:

Track HIghlights:

Type

Test an implementation guide

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group  

Da Vinci

Track Lead(s)

Lloyd McKenzie; Eric Haas

Track Lead Email(s)

lloyd.mckenzie@accenture.com; ehaas@healthedatainc.com

Related Tracks

N/A

FHIR Version

R4

Specification(s) this track uses

http://hl7.org/fhir/us/davinci-cdex/


Artifacts of focus

https://build.fhir.org/ig/HL7/davinci-ecdx/CapabilityStatement-data-consumer-client.html

https://build.fhir.org/ig/HL7/davinci-ecdx/CapabilityStatement-data-consumer-server.html

https://build.fhir.org/ig/HL7/davinci-ecdx/CapabilityStatement-data-source-client.html

https://build.fhir.org/ig/HL7/davinci-ecdx/CapabilityStatement-data-source-server.html

Expected participants

EHR and other data source systems, as well as payer systems

Updated reference implementation

Zulip stream

https://chat.fhir.org/#narrow/stream/180805-Da-Vinci.20eCDx

Track Implementers Connection Call

Track Details

System roles:

NOTE: participants should expect to complete most of their development in advance of the track.  Depending on which portions of the track are implemented, development should likely start no later than mid-late August.

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.

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.

Attachments Client (Provider)

  • A system that has attachments that need to be associated with an existing or future claim or prior authorization request and can push this data to the payer using the CDex $submit-attachments operation.

Attachments Server (Payer)

  • A system that processes claims and/or prior authorization requests and is able to receive unsolicited attachments using  the CDex $submit-attachments operation.


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

1. Direct query

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

2. Asynchronous Document retrieval

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

3. Filtered query

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

4. Unsolicited push

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

Precondition: The Unsolicited Data Source knows the Unsolicited Data Consumer's member identifier for the patient.  An un-processed prior authorization with a known identifier exists on the Unsolicited 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)

Example Data:

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/ 


Reference implementations:

Sample Data:

Sample data is available as FHIR transaction bundles:  here   

TestScript(s):

Touchstone has loaded some FHIR test-scripts for HREX/CDEX use cases that can be found HERE.

Please reach out to Touchstone_Support@aegis.net with any questions on how to test.


Security and Privacy Considerations:

None at this time