Page tree
Skip to end of metadata
Go to start of metadata

Track overview

Short Description

This Da Vinci track is focused on the U.S. Payer/EHR use-case of exchanging clinical data from provider to provider, provider to payer and a specific payer-to-payer scenario of ensuring continuity of care when a patient transitions between payers.  The track will cover patient identify resolution, requesting data with or without an expectation of human intervention, requesting information across multiple patients, and generating "care transition" documents when supporting cross-payer care continuity.

Long Description

This track will continue the work of several past connectathon tracks testing out the CDex and PCDE implementation guides.  This is being run as a combined track because the exchange mechanism being used for PCDE is one of the exchange mechanisms also proposed for use with PCDE (and is a change from the mechanism that went to ballot).  As well, both implementation guides will be leveraging the patient identity resolution process documented in the new release of the HRex IG.  The specific aspects of the IGs that will be a focus of this track include:

  • Continuing to validate the member identify verification ($member-match) process tested in the PDex track at the last connectathon (which will be formally documented in the new version of the HRex IG that goes to ballot prior to the connectathon).  This process will include the changes/clarifications identified during the past connectathon.
  • Testing the Task-based exchange mechanism for both provider to practitioner exchange (CDex) and provider to provider exchange (PCDE), including monitoring status and exception scenarios (refusals, cancellations)
  • Testing the ability of payers to produce and consume coverage transition of care documents.
  • Reviewing and/or testing the recommendations noted in the PCDE Supplemental Guide. The PCDE Supplemental Guide complements the IG with guidelines and recommendations on the representation of the clinical content in a PCDE bundle.

Type

  • Test an Implementation Guide

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

  • Financial Management Work Group

Proposed Track Lead(s)

Related tracks

The following tracks will all also make use of the HRex "patient identity resolution" process:

These tracks may also have an interest in the Task-based approach to soliciting the exchange of clinical information

FHIR Version

  • FHIR R4

Specification(s) this track uses

Artifacts of focus

EHR input requested (if any)

  • Does the Task-based exchange mechanism work effectively within EHRs?

Payer input requested (if any)

  • Does the member identification process meet needs of current payer environments?
  • Are the member PCDE bundle active treatment examples created for the Connectathon clinically valid and sufficient for continuity of coverage in a member transition between health plans? 

Clinical input requested (if any)

  • Are the member PCDE bundle active treatment examples created for the Connectathon clinically valid and sufficient for continuity of coverage in a member transition between health plans? 

Patient input requested (if any)

  • Patients will benefit from the specifications under test, but there are no specific questions for patients/care-givers

Expected participants

  • MITRE - 2 participants
  • Mettles Solutions - 1-2 participants (question)
  • Anthem - 1 participant
  • Humana - 1 participant
  • Interoperion - 1 participant
  • Cerner - 1 participant
  • Feel free to add your name (smile)

Zulip stream

Track Orientation

  • PCDE Track Orientation: 8/21/20, 2p ET
  • Orientation Presentation Recording 

Track agenda

  • Thursday
    • 9:00 ET -  PCDE Overview Presentation
    • 10:00 ET - HRex/CDex Overview Presentation
    • 16:00 ET - Track touch-point - Progress so far, open issues, objectives for tomorrow, 
  • Friday
    • 15:00 ET - Track Highlight / Report-out - go to Whova Track High

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.

Data Source Payer

  • A system that has (or might have) information about a member.  In PCDE, this is the 'old' health plan from whom coverage is being transferred.

Data Consumer Payer

  • A system that needs information about a member (and needs to determine how the member is identified in the target system). In PCDE, this is the 'new' health plan requesting the member information from the old health plan.

Scenarios

Background

The PCDE exchange is based on the following clinical scenario which has been used for the past two FHIR connectathons for reference implementations.  This data will also be available for query using CDex.  (Systems are welcome to try additional data scenarios as well.)

Persona: Joe P. Smith is a 65 yo white male with end stage COPD and OSA.

Coverage Transition: Commercial to Medicare Advantage Plan

Former Coverage Info:

  • Payor Organization: MARYLAND CAPITAL INSURANCE COMPANY
  • Subscriber: Patient
  • PolicyHolder: Patient
  • Relationship of subscriber to policyholder: Self
  • Coverage Class: Plan, id: CLASSPLAN01

Specific clinical details as well as an example of the PCDE bundle describing the persona is available here.

1. Member id confirmation

Action: Data Consumer Payer invokes the $member-match operation on the Data Source Payer

Precondition: The Data Consumer has demographic and card information about a member that exists on the Data Source Payer's system

Success Criteria: Data Source Payer receives a response and has Patient and Coverage references they can use when performing subsequent queries or operations

Bonus point(s):

  • Perform a member match using just demographic information (no card information)
  • Perform a match that results in no matches
  • Perform a match that results in multiple matches

2. PCDE retrieval

Action: Data Consumer Payer creates a Task on the Data Source Payer's system soliciting a transition of coverage document 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 Data Consumer knows the Data Source's patient identifier and coverage identifier for the member in question (see step 1)

Success Criteria: Data Consumer Payer has a completed coverage transition document for the specified member

Bonus point(s):

  • Rather than polling, the Data Consumer creates a subscription on the Data Source that monitors the Task for updates
  • The Data Source updates the Task with "in progress" status information before it is marked as complete
  • The Data Source refuses the request
  • The Data Consumer cancels the task before it is complete
  • Retrieve transition of coverage documents for patients with other types of conditions and active treatments

3. Document retrieval

Action: Data Consumer Payer creates a Task on the Data Source Payer'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 Data Consumer knows the Data Source's patient identifier and coverage identifier for the member in question (see step 1)

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

Bonus point(s):

  • Rather than polling, the Data Consumer creates a subscription on the Data Source that monitors the Task for updates
  • The Data Source refuses the request
  • The Data Consumer cancels the task before it is complete

Reference implementation:

4. Filtered query

Action: Data Consumer Payer creates a Task on the Data Source Payer'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 Data Consumer reads the search response Bundle referenced via the Task.output

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

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

Bonus point(s):

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

TestScript(s)

Touchstone has loaded some FHIR testscripts for HREX/CDEX/PCDE 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


Track Summary

Participants and observers representing payers and implementers from 7 organizations: Anthem, Cerner, Gevity, Humana, Interoperion, Mettles, and MITRE.

CDex:

Successes:

  • Presented a CDex Walkthrough that highlighted the new Task-based approach to sharing as well as a demo of the revised reference implementation, which supported the new Task-based approach
  • Updated the reference implementation to included clearer documentation/better alignment with new Task-based approach
  • Were able to test the new approach between one payer and one EHR
  • Identified a bit of clean-up to the HRex Task profile
  • Good discussion on the use of Subscription and created some examples for what subscription might look like

Challenges:

  • Limited attendees made broader discussion about subscription harder – will take back to the broader group

Future Work:

  • Questions to explore with respect to Subscription:
    • Should we include subscription in CDex release 1?
      • seems that the R4 mechanism is 'ready enough'
    • rest-hook or websocket
      • presume email & messaging are off the table
    • Full resource vs. identifier vs. either (presume ping is off the table)
      • With full resource, include outputs in bundle? If so, what?

PCDE:

Successes:

  • Presented a PCDE Walkthrough with a client demo that can be tested by payer subject matter experts to review PCDE content.
  • Implemented and tested new Task resource changes.
  • Participant review and pressure-test of the IG with a PCDE Bundle example, resulting in identifying two JIRA issues:
  1. Missing reference from PCDEBundle profile to PCDEComposition
  2. Adding invariant to improve conformance of ActiveTreatment sections within a PCDEComposition
  • Fixed PCDE Bundle example which incorrectly had multiple treatments under one ActiveTreatment.

Challenges:

  • PCDE IG still loose on how to best represent clinical data within a PCDE CarePlan
    • needs more active payer feedback on the PCDE Supplemental Guide to vet recommendations.

Future Work:

  • PCDE Testing Subscription/Notification use case over Polling Tasks
  • Support for embedded X12/EDI transactions to represent a prior authorization as an alternative to referencing the PAS IG
  • No labels