2022-05 Da Vinci Clinical Documentation Exchange (CDex)

Agenda

Wednesday

10am: Touch point, test data coordination

11am Challenges & Best practices in managing FHIR API endpoints

12pm: Attachments Request Discussion

2pm: Wrap up

3pm: Report out

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:

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

Sample Data:

Sample data as FHIR transaction bundles available here:

TestScript(s):

Touchstone has loaded some FHIR testscripts 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