Submitting WG/Project/Implementer Group
HL7 Da Vinci Payer Data Exchange (PDEx)
Justification and Objectives
The purpose of this Track is to enable data to be exchanged between Health Plans (Payers) via Member-authorized exchange using an OAuth 2.0 authorization.
This track will use what version of FHIR.
Clinical input requested (if any)
The Track will use US Core Resources and other profiles defined in Da Vinci Implementation Guides, such as HRex. The data will be derived from a Payer's claims and other clinical resources.
Payer representatives will likely be involved in other Da Vinci or CARIN Blue Button Tracks.
Proposed Track Lead
Mark Scrimshire, email@example.com
Track leads must be registered users on http://chat.fhir.org
Payer Representatives. At previous Connectathon this track 8-10 participants.
Orientation will be held during an upcoming PDex weekly conference call on Either August 2nd or 9th.
PDex weekly conference calls occur at Noon ET on Fridays. The Orientation section of the call will be recorded.
A webinar will be hosted on date at time to share further participation information about this track.
Source Health Plan Server - Hosting data for a departing member.
Receiving Health Plan Server - Hosting an account for a newly enrolled member.
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
Participants may use the HSPC Sandbox servers used for previous PDex connectathons as a Source or Receiving Server.
Participants wishing to test with their own systems as a source system will need to publish a FHIR API Endpoint and provide test user accounts with data that supports the Patient/$Everything operation where the profiles encapsulated in the $Everything bundle conform to the HL7 FHIR R4 US Core Profiles.
Participants wishing to test with their own systems as a receiving system will need to be able to connect to a target FHIR Server using R4 and be able to retrieve and validate HL7 FHIR R4 US Core profiles. The retrieval operation could be a Patient/$Everything operation or could make individual calls to specific R4 profiles available in the source servers Capability Statement.
Role 1 Source Server
There are three scenarios to be tested:
- IN-FLOW: Member-authorized Exchange of Patient/$Everything bundle. Member connects to old plan from new plan and authorizes an exchange directly. Previously tested in Jacksonville. This exchange also supports Member-authorized exchange with a third-party application.
- INDIRECT-FLOW: Member-authorized exchange of Patient/$Everything bundle via a request made by the Member to the New Payer. i.e. Please go and get my data from my old plan.
- ENROLLMENT-FLOW: Payer-to-Payer HIPAA Business, Treatment and Operations covered exchange of Patient/$Everything bundle. When a new Member is enrolled in a health plan the plan identifies the old health plan and requests the Member's information from the old plan without requiring an authorization by the member.
These scenarios can use the same mechanisms to perform the exchange. ie. REST-based GET to an OAuth 2.0 protected API Endpoint . The difference will be the entity requesting an OAuth2.0 token.
Present a HL7 FHIR R4 API with a capabilityStatement that supports the following profiles and operations:
- US Core Patient
- Da Vinci HRex Coverage
- US Core Encounter
- US Core Procedure
- US Core DiagnosticReport
- US Core Observation
- Da Vinci HRex MedicationDispense
The API should be protected via OAuth2.0 that complies with the SMART-on-FHIR app launch framework.
Role 2 Receiving Server
For a newly enrolled member initiate an OAuth 2.0-based connection to the member's prior payer by following the SMART-on-FHIR app launch framework.
Query the source FHIR Server for the member and retrieve their Health History using the Patient/$Everything operation.
Process the received bundle and store the information as FHIR resources in the receiving payer system as part of the newly enrolled member's health history.
Describe the different scenarios participating systems can engage in during the conenctathon. Each scenario should provide sufficient description that participants can appropriately construct their software in advance to prepare to interoperate during the connectathon.
Scenario Step 1 Receiving Server Connects to Source Server
Action: Receiving Server connects to Source Server using SMART-on-FHIR app launch framework
Precondition: Source Server has Receiving Server identified as a valid OAuth2.0 application
Success Criteria: Receiving Server can connect to Source Server and retrieve CapabilityStatement
Scenario Step 2 Source Server accepts connection from Receiving Server and enables search for a member
Action: Source Server allows connection from a Receiving Server and supports search for a member by MemberId
Precondition: Source Server has Receiving Server identified as a valid OAuth2.0 application.
Receiving Server has OAuth2.0 credentials for Source Server API Endpoint incorporated into connection workflow
Success Criteria: Receiving Server retrieves the Patient Resource for a member via a member id search
Bonus point: Source Server presents Observation resources coded from HL7 V2, 837 Claim and CCDA sources with associated Provenance Resource records as per guidance provided in PDex IG Companion Guide - Laboratory Reporting Resources.
Scenario Step 3 Receiving Server retrieves $Everything operation for Member
Action: Receiving Server requests the Patient/$Everything and retrieves all member health history as a paged bundle from the Source Server
Bonus point: Systems support the request and return of the Patient/$Everything operation as a non-paged Bulk FHIR conformant NDJson transaction.
Scenario Step 4 Receiving Server adds Patient/$Everything content to member record in the Receiving Payer's system
Action: The Receiving Server processes the records returned by the Patient/$Everything operation and adds the content to the new member's health history
Precondition: Successful completion of Patient/$Everything operation with Source Server.
Success Criteria: Member Health History from Source Server is visible with Receiving Server's Member Health History.
Bonus point: Request individual records, or categories of US Core resources from Source Server and add to Member Health History on Receiving Server
Indicate any test scripts that will be used to help verify system behavior
Test Scripts will be created using the Aegis Test Script Template and will be linked here.
Test Scripts will cover:
- Access Not Authorized - 403 error
- Member Not Found Search - 404 error
- Paged Bundle for Patient/$Everything
- Non-Paged Bundle for Patient/$Everything
- Bulk FHIR NDJson $Patient/$Everything non-paged bundle
Security and Privacy Considerations
Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate
OAuth 2.0 will be used for Authorization. Connections will follow the SMART-on-FHIR app launch framework.
A Receiving Server should be authorized to search for any member via their Member ID and retrieve the data for that member.