Review Payer Data Exchange and Interaction with US Core v3.1.0+
The CMS Interoperability and Patient Access Rule requires payers to release data going back to January 1, 2016. The work of the PayerData Exchange (PDex) Work Group is helping to coordinate payer activity in response to the clinical and encounter data requirement by leveraging US Core resources with some additions from PDex.
With the dramatic increase in the number of FHIR API endpoints and the number of apps wanting access to these APIs we face a challenge in managing the issuing of credentials. We need to find a better way that leverages the power we have when we act as a community with a common purpose. Fortunately the ONC's FHIR At Scale Taskforce (FAST) have been addressing this next generation problem. The UDAP protocol was first referenced from PDex in the Da Vinci Health Record Exchange (HRex) IG. It provides a method that allows simpler registration of trusted apps.
The purpose of this event is three-fold:
- Address Payer questions about the implementation of the clinical and encounter data requirements in the CMS Patient Access API
- Inform Consumer Application Developers about the use cases for the use of US Core resources.
- Explain the Unified Data Access Protocol (UDAP) and the benefits it offers for Payers, Developers and Consumers.
The outcomes desired from this event include:
- Gather feedback on the PDex IG (Current Build)
- Raise awareness amongst Consumer App developers about use of US Core
- Inform developers about the additional items PDex requires over and above the US Core resource set
Real world testing of the Da Vinci Payer Data Exchange IG focused on the Consumer-Directed Exchange scenarios will take place as part of this event.
Intro Deck: PDexPatientAccessAPIEvent.pptx
- Test the Patient API access elements of the PDex Implementation Guide
Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group
Financial Management WG
The target audience for PDex falls into two groups:
- Payers who are implementing the clinical and encounter information parts of the CMS Patient API
- Developers who are building consumer applications that will request data from payer FHIR APIs
- FHIR R4
Specification(s) this track uses
Artifacts of focus
- Payer-Provenance: How should a payer express Provenance for data that they have received via a non-FHIR channel?
Clinical input requested (if any)
US Core provides a resource for ImplantableDevice. Payers may have information about other devices without UDIs that need to be shared. The Device profile is meant for that purpose.
Patient input requested (if any)
Learn which records are most important
- Consumer App Developers
PDex Work Group Call: August 7, 2020 at Noon ET.
The session will be recorded.
Role 1 Sandbox API Server
Role 2 Sandbox API Client
Scenario: Sandbox user retrieves clinical data (US-Core profiles + MedicationDispense resources) from the Sandbox server using the Client
Action: Sandbox user receives the access and refresh tokens from the Sandbox server and calls the clinical resource endpoints
Precondition: Sandbox user is logged into the Client
Success Criteria: The client retrieves the user's clinical records and renders them on the UI
Bonus point #1: On expiration of the access token, the app uses the refresh token to get new access and refresh tokens
Bonus point #2: The Server exposes search criteria (link) for selecting the clinical resources and the client uses search parameters to select and retrieve the those resources.