Menu
In the recently concluded 2021 CMS HL7® FHIR® Connectathon, our CIO, Mark Scrimshire, who is also the co-chair of the Payer Data Exchange workgroup and author of the Da Vinci Payer Data Exchange Implementation Guide (IG), shared his expert views on the Payer-to-Payer Data Exchange Implementation Guide focusing specifically on the forthcoming regulatory target of January 1, 2022. Read on to know more:
—
Mark pointed out that a critical issue in US healthcare is its siloed nature. This prevents providers and payers from accessing and interpreting important patient data, leading to decisions being made on partial information. The interoperability challenges – data standardization and easy information access – have inhibited both payers and providers in building efficient care delivery solutions and management models for the benefit of the patient. It is the aim of the Da Vinci HL7 FHIR® Project to assist payers and providers to positively impact clinical, quality, cost, and care management outcomes.
“Value Based Care Programs Drive Focus to Patient Outcomes by enabling providers to see the right data at the right time for patient-centered care… in terms of specific patient coverage, their benefits and effective care coordination. Historically, payment and coverage data were completely separated from care…”
The Da Vinci Project approach is to:
A key objective of PDex is to promote data reusability. The PDex IG is one of a suite of Da Vinci IGs that are recommended by CMS to meet the compliance requirements of the CMS Interoperability and Patient Access Rule. The enforcement deadline for this rule was July 1, 2021, and requires regulated Health Plans (Medicare Advantage, Medicaid, Children’s Health Insurance Program (CHIP) and Qualified Health Plans on the Federal Exchange) to implement a Patient Access API, covering claims, clinical and formulary information for a member, and an Open API for Provider Directory information.
The CMS Interoperability Rule also set a deadline of January 1, 2022, requiring the regulated Health Plans to enable Payer to Payer exchange of clinical data at the request of a member. This will enable any member to request their clinical data from a regulated health plan they left up to five years earlier.
PDex provides a FHIR Operation that facilitates the exchange of clinical information by health plans for members that have requested their data follow them.
While the Centers for Medicare & Medicaid Services (CMS) haven’t mandated the use of FHIR® they have provided guidance that recommends the use of a series of five FHIR IGs to comply with the interoperability and patient access rule.
Indications from CMS are that we can expect to see the use of FHIR specifications being embedded into future regulation. This will remove the optionality about how payer-to-payer data exchange is accomplished. The Interoperability Rule states that a payer can deliver the data for payer-to-payer data exchange in any format, while a receiving payer is not obliged, or required, to convert that data into FHIR® resources. However, in the Rule, there is the requirement that the data should be made available to the member upon their request.
Since Payer-to-Payer exchange is a requirement for the regulated health plans which will have already created a Patient Access API, CMS recommends using the clinical part of the Patient Access API to make the data available to other payers. This was part of the PDex approach: to use a common payload (the clinical FHIR resources) and make them available via different channels.
PDex provides an operation: member-match. This enables a payer to send a transaction that will check whether they have a unique member in common. Work is currently underway to include a consent record in the bundle as an optional element. It is a simple process to add an additional element to the transaction. The challenge is in getting consensus about the use of a consent or authorization resource. Will one covered entity accept a consent record gathered from a member by another covered entity as sufficient authorization to release member data to that entity?
Enabling member authorization in advance requires less active engagement from the member in the data exchange process. The alternative is to leverage the Patient Access API. This brings many challenges. Payers would have to register an app with many other payers. Members would need to have an active digital account with the prior health plan in order to enable a transfer of data.
Technology is not the concern: it’s all about achieving consensus to enable a consumer to instruct their health plan to obtain their data and add it to their health record.
Historically, PDex pre-dated the notice of proposed rulemaking for the interoperability and patient access rule.
The flow focused on providers and payers. The concept of a provider, seeing a new member from a health plan, gathering coverage information, collaborating with the payers and being able to decide which data to be added into their EMR – all done with the purpose of gathering a patient’s history and delivering a better experience and service to the member.
The PDex IG is not a cited in the interoperability rule. However, CMS refers to PDex and other HL7 FHIR. IGs in their guidance to plans regarding how to achieve compliance with the rule.
At the first CMS Connectathon in 2020, a group of payers got together and brainstormed on how to enable payer-to-payer exchange of data about a member.
One significant challenge is the level of adoption of digital accounts at health plans. Without a digital account, how could a digital transaction be performed that required the authentication and authorization of a member? The Member Match operation was developed to address this challenge. A plan would gather a request from the member, typically during the enrolment process, or via the member portal. This process would gather information about a member’s prior coverage. The payer would use the information to identify the other payer and find their FHIR endpoint.
The patient demographics and the coverage information in the Member-Match transaction would be used to determine a definitive, unique match for a member and return a unique member id as a part of the transaction response, together with a token that would allow the plan to query the member’s data from the PDex Clinical FHIR® APIs.
The member match operation flow is as follows:
The process is based on the expectation that the member can provide their prior coverage information. This would be the information found on a coverage card. If a member does not have that information, they would have to contact their prior plan to obtain the necessary information.
In Consumer-directed exchange today, when a member connects an app to a Payer’s environment and authorizes the sharing of their data with that third-party app, they are providing consent.
The process of sharing, of authorizing an app is a form of consent. This process was proven as part of building the CMS Blue Button 2.0 API. During an OAuth2.0 or SMART-on-FHIR authorization All of the necessary pieces of information to document a consent are available:
For Payer-to-Payer exchange when a consumer is enrolling in a new health plan, they could be asked a series of questions that obtain the prior plan details and their consent to collect their data from the prior plan. This same approach can also be used as part of the member portal to enable a member to give their authorization to gather information from another plan.
One of the design philosophies of Payer Data Exchange was to avoid creating new profiles, unless necessary. In addressing the clinical data exchange requirements PDex leverages the profiles in the US Core Implementation Guide. PDex also adds some additional profiles that are oriented towards the needs of the payer community. By utilizing existing profiles, it lowers the barriers to adoption and implementation.
The additional profiles include:
PDex also provides mapping from the profiles and the Common Payer Consumer Data Set definition in the CARIN Alliance Blue Button IG that provides claims information to various clinical resources.
Payer Data Exchange addresses the needs of payers by providing a Provenance record. The IG recognizes that payers typically receive data from multiple sources. Currently that data is not in FHIR format and therefore does not provide provenance.
If the data payers receive is maintained for the member and used in the management of their health, if that data falls within the US CDI data classifications, then payers need to make that data available to their members using the US Core clinical FHIR APIs.
Provenance in the PDex IG covers two scenarios. The profile is derived from the US Core Provenance profile. The first scenario is to enable a payer to say that they are simply the transmitter of data. Thus, if sending a bundle of information, a provenance record can provide a record of transmission. In the second scenario payers can use a Provenance record to record the source of the data and the format in which it was received. As Payer-to-Payer exchange occurs Provenance will be increasingly important to identify which data was generated by the current payer, which data was received from other sources and which data was retrieved from prior payers.
**In the subsequent series, Mark will share further insights on PDex Workflows and Reference Implementation.
