2022 - 09 Da Vinci Clinical Documentation Exchange (CDex), Including Support for Attachments

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

• 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

TBD

lloyd.mckenzie@accenture.com

dayd@bcbsil.com

christol.green@elevancehealth.com

Reference implementation:

• Payer: https://sandbox.logicahealth.org/DaVinciCDexPayer
• Provider: https://sandbox.logicahealth.org/DaVinciCDexProvider
• For access to the reference implementation sandboxes above, email Viet Ngyen for access at viet@hl7.org

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 EHR/HIT

Payer systems such as Payers/Intermediaries/Payment Processors

Participant Information Session

Learn more about the tracks being offered, how to prepare your sandbox system for a weekend of testing, and where to connect with your track leads to get the most out of the event.

Info Session Recording

---

Kickoff & coordination call: Sept. 7, 2pm eastern

Dial in: https://hl7-org.zoom.us/j/91511198854?pwd=RElmU1FjaWtBbU9obSs4NXpkK04vdz09

Kickoff Slides:

Call Recording: https://hl7-org.zoom.us/rec/share/9fhDGOJDQNbYzex2iQgnLaLhSDyhqVs5eEKIn73m4phaTmlax6-59CyqVtLZfO-T.GWXwdqqCWoDUTK6c 

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.

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

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:

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