CMS Interoperability and Patient Access Final Rule

The CMS’s Interoperability and Patient Access final rule has been built with the vision of putting patients first, giving them access to their health information when they need it most and in a way, they can best use it. The new policies as part of the Patient Access Rule have been aligned on these lines promoting the healthcare industry towards greater interoperability.

Following is the snapshot of the policies released as part of the Patient Access Final Rule:

Patient Access API

CMS regulated Payers are required to provide patients access to their data such as claims, encounters, and clinical information through 3rd Party Applications of their choice by implementing a secure HL7 FHIR® (Release 4.0.1) API endpoint. Therefore a Member will be able to access their health information through secure FHIR based API connecting third-party applications. Following is a summary of the requirements spelled out in the rule with respect to the Patient Access API:

Following is an example of an implementation workflow for the Patient Access API:

An example use case is the Consumer accessing their claims data electronically from the payer. The workflow begins with the Consumer placing a request to access their health data example their Explanation of Benefit (EOB) record via a third-party application. Upon successfully validating their credentials, the payer responds by sending EOB FHIR Resource through a secure FHIR based API to their party application.

Provider Directory API

CMS regulated Payers are required to maintain and publish provider directory data through APIs with the latest updates. Payers must make provider directories available through a standard-based API that is accessible on a public-facing digital endpoint on the payer’s website.

This provider data was until now made available in the payer portal but now has to be published via the API. Since this data is already being made available in the payer portal, the impact on the payer will be to map the existing data to FHIR resources and share this via the API. The Provider Directory data will include a list of In-Network Providers.

Provider Directory FHIR server does not maintain any records that can be associated with a consumer. Therefore, the Provider Directory API does not require third-party applications to send consumer identifying information and therefore will not require any authentication.

Following is a summary of the requirements spelled out in the rule with respect to the Provider Directory API:

Following is an example of an implementation workflow for the Provider Directory API:

The above figure depicts the workflow for publishing the provider directory data to the end-users (Patient/Member or Providers) through an FHIR endpoint. A third-party application uses the API published by the payer to provide the data to the end-users. The Patient/Members and Providers can query the payer on data such as Provider organizations, In-Network Providers, Insurance plan coverage details, and so on, which are available as FHIR Profiles.

Payer to Payer Data Exchange API

As per the CMS Patient Access Rule, Payers will be required to exchange clinical data as outlined by the United States Core Data for Interoperability (USCDI) format at the Member’s request. CMS requires the previous health plans to share up to 5 years of historical patient data to the new/current plan of the Member resulting in the creation of the Member's Longitudinal health record as they move across Payers.

As per CMS, this would likely be an extension of the technology mandated for the Patient Access API and thus the Patient Access API can be repurposed to comply with this data exchange rule.

However, in the CMS Interoperability and Patient Access final rule, CMS did not specify a mechanism for the payer-to-payer data exchange. Rather, CMS required impacted payers to receive data in whatever format it was sent and send data in the form and format it was received, which complicates implementation by requiring payers to accept data in different formats.

Due to the lack of technical specifications for the payer-to-payer data exchange requirement, there are challenges in implementing the same. Therefore, CMS is currently exercising enforcement discretion to delay the payer-to-payer data exchange requirement until future rulemaking is finalized.

Federal- State data exchanges for dually eligible individuals

The Patient Access final Rule updates the requirements for states to exchange data for individuals who are dually eligible for Medicare and Medicaid. This will include state Buy-In files and MMA files. As per the rule, the data exchanges which had a frequency of monthly will be changed to daily.

Buy-In Files: As per the rule, state-CMS buy-in files (State payment of Medicare Premiums are referred to as Buy-In files) which were being exchanged on a weekly/monthly basis will now have to be exchanged daily.

MMA files: States generally exchange files with CMS that identify current and prospective dually eligible individuals and are referred to as Medicare Modernization Act (MMA) files. These data which used to be exchanged at a monthly frequency will now, as per the Patient Access Rule, have to be exchanged daily with CMS.

As per CMS, moving the data exchange frequency to daily will serve to expedite the enrolment status changes, reduce the payment inaccuracies as well as improve customer experience.

With the CMS introducing mandates centered around promoting interoperability, the healthcare industry now stands at a transition from the stage of data siloed into disparate systems into a stage of seamless flow of data. The upcoming major milestones can potentially be the finalization of the regulations pertaining to the Payer-to-Payer data exchange that will serve to further advance the interoperability journey.