Only a few days remain before the enforcement delay that the Centers for Medicare & Medicaid Services (CMS) exercised due to COVID-19 will end and the agency will require certain payors to publish a Patient Access application programming interface (“API”) and a Provider Directory API under the requirements of the CMS Interoperability and Patient Access Final Rule. Starting on July 1, 2021, all health plans that offer Medicare Advantage, Medicaid and Children’s Health Insurance Program (CHIP) and most Qualified Health Plans offered through the Federally-facilitated Exchange will be required to make enrollee electronic health information held by the payor and the health plan’s Provider Directory (QHP Issuers on the FFEs are required to make a Provider Directory under a different CMS rule, not under this rule) available through application programming interfaces (“Open APIs”). CMS is also hopeful that when these payors see the benefit of offering easy access for their federally subsidized health care program enrollees to use and exchange their electronic protected health information, the payors will offer the same opportunity for enrollees in their commercial and Employer Sponsored plans.

The interactions between the Patient Access and Provider Directory APIs were designed to ensure that claims, encounter and certain clinical information held by payors becomes easily accessible to health plan enrollees to make it easier for them to identify which providers are in a plan’s network and to assist them in making the right care choices. However, publishing Open APIs is only one part and one step towards building the infrastructure that is needed to integrate information from multiple sources that will be able to impact both the quality and cost of health care.

Other rules, including the ONC Interoperability and Information Blocking Rules, the Hospital Transparency and Transparency in Coverage Rules, OCR’s Proposed Modifications to the HIPAA Privacy Rule and the Proposed No Surprises Act Rules also play a part in providing patients with access to a complete picture of their electronic health information and will influence the future that patient centered access plays in driving innovation, improving care, managing cost, and ensuring equitable care into the future.

While researchers have recognized the value of using claims, encounter and other health plan data in their analyses and studies for many years, individuals have rarely sought access to their own health histories through their health plan data. Payor data was considered difficult to use and consumers typically don’t find their claims histories helpful for making decisions about their future care. Through the implementation of Blue Button 2.0, CMS recognized that the longitudinal view of health plan data along with the clinical information from providers offers a complete view of a patient’s profile. Together, these data sets can inform care and benefit coordination in a way that can have a meaningful impact on both the cost and quality of care. With health care costs rising and individuals bearing responsibility for a larger portion of out-of-pocket expenses (e.g., co-pays, co-insurance and deductibles), having an integrated view of both clinical and cost information has become more important to consumers.

In addition to publishing Patient Access and Provider Directory APIs, payors are expected to develop or to engage with third parties to develop the software that will help transform health plan data that is currently hard to use and siloed, into meaningful information to enable patients, providers and payors to make the best health care choices possible. As covered entities under the Health Insurance Portability and Accountability Act (HIPAA), health plans are obligated to make an enrollee’s protected health information available to them under the HIPAA Right of Access rules.

As long as payors are developing or engaging developers directly, HIPAA would protect the electronic protected health information being collected and combined. However, Open APIs also offer the opportunity to third party developers who are not necessarily covered entities nor business associates of covered entities to offer their services directly to individuals. With the proper consent or authorization and the Patient Access API, a third party application developer acting on behalf of an individual can obtain access to that individual’s electronic protected health information and, once accessed, the HIPAA Privacy and Security Rules are no longer applicable.

Introducing third party applications that are not regulated under HIPAA as the vehicle that streamlines individuals’ access to and exchange of their electronic protected health information shifts the paradigm from covered entities deciding with whom to share protected health information to consumers making those decisions. Unless consumers know that the application they choose is not covered under HIPAA, there is the potential for them to unwittingly authorize their sensitive health information to be over-shared or to be used in ways they had not intended or anticipated. Although third-party application developers are responsible for obtaining the appropriate consent and/or authorization from individuals choosing their apps, payors may want to make sure that their enrollees are educated, informed and know what to look for from an app developer that might take advantage or hide behind convoluted language in a consent/authorization or Privacy Policy. Furthermore, to build trust with their enrollees, payors may want to collect some basic background information about the application developer that offers services to its enrollees and may be exchanging information with the payor. Some payors may offer application developers the opportunity to test their technologies and in doing so will be able to learn about the security and privacy posture of the application so that the payor can assist enrollees in choosing applications that will be beneficial to them and not put their sensitive health information at risk. Ultimately, payors should try to use this first phase of compliance with the Patient Access and Provider Directory APIs to connect and engage with enrollees and to prepare for the next step that will take place on January 1, 2022, when payors will be required to implement a payor-to-payor API to encourage more seamless information sharing between health plans at an enrollee’s request.