Health plans have 12 months before they must have a FHIR®-Based Patient Access API built, running and easily accessible to consumers.

Under the 21st Century Cures Act, as part of ongoing efforts to drive improved quality and efficiency of patient care, health care organizations within the United States are required to support increasing interoperability and access to patient-level data. The date for compliance with this new rule is July 2021. While a federal mandate, this decree is well aligned with the health care industry’s broader push toward enabling patients to play a larger role in their health and health care – and the general principles around why it is essential to do so. The final CMS/ONC interoperability rule released in March implements  certain provisions of the Act, with concrete details and deadlines for health plans around their role in initiatives from enabling patient health data access to plan-to-plan data sharing and more.

A key aspect of the Act pertains to supporting consumers’ access to their own patient-level data and the requirement of all health plans to support application programming interface (API) access to the data in real-time. The final rule mandates that all Medicare Advantage, Medicaid, CHIP and ACA plans provide a Patient Access API, accessible using third-party applications, by July 2021. As touted by ONC, “Over the next two years, patients will be increasingly able to choose apps to assemble and read their records,” allowing them to better understand their care options including expected health outcomes, possible treatments and comparing costs.

For health plans, the destination is clear, but the path may be less so. Health plans have 12 months before they must have a FHIR®-Based Patient Access API built, running and easily accessible to consumers. With a CMS-estimated price tag of more than $1.5 million for initial build and implementation – not to mention ongoing maintenance and operating costs – health plans need to quickly determine how they will comply. The journey begins with weighing the advantages and disadvantages of developing an in-house FHIR®-Based Patient Access API versus finding the right partner-hosted solution.

What is patient access and why does it matter?

The concept that providing individuals access to their own health care information is important for driving greater levels of patient engagement and satisfaction – and ultimately, better health outcomes – is not a novel one. Patients play an important role when they serve as part of their own care coordination team, from helping to ensure safety and accuracy to managing the complexities of their treatment plan. Individual patients are the only ones who have first-hand experience with their health and their care encounters, and when given access to their own health data, play an important role in assuring data accuracy and closing information gaps that may exist between different providers.

The prevalence and use of online “patient portals” has grown under CMS/ONC meaningful use requirements, and most health care consumers have generally viewed these online portals as useful and beneficial. They have not been without their challenges, however, with their inability to provide much more than a limited view of a patient’s broader care journey presenting a major flaw. Health care data is growing at an immense rate, and without a way to connect the massive volumes of currently siloed data sitting with individual organizations and systems across the health care continuum, patients will never be able to access a complete, comprehensive 360° view of their health and health care. CMS’ Patient Access API mandate is attempting to help bridge this gap.

The data generated in the health care industry increases by 48 percent every year. The amount produced in 2020 alone could exceed 2.3 zettabytes, or 2.3 trillion gigabytes. That’s the amount of data it would take to watch 262 million years straight of HD movies.

Determining your Patient Access API strategy

With the July 2021, Patient Access API deadline just a year away, the first decision that health plans must make is whether they want to invest time and resources to develop and maintain their own FHIR®-Based Patient Access API in house or work with a third-party partner for a solution. An in-house solution requires a range of considerations:

  1. The timeline is short, and the costs are ongoing. The FHIR®-Based Patient Access API must be set up and tested in just 12 months from now, and CMS has estimated that cost for setting up a Patient Access API will be upwards of $1.5 million, which doesn’t consider ongoing maintenance costs. Health plans looking to develop their own API solution must ensure they are prepared to build, test, refine, and implement the full API within the next 12 months, as well as have a longer-term strategy in place that covers ongoing maintenance and operations – including the need for in-house software engineers, security engineers, and data mapping tools and engineers.  
  2. FHIR®-based API expertise is non-negotiable. HL7 FHIR® has rapidly risen the data standard popularity ranks as the standard for joining siloed systems and exchanging health care information electronically. Per the final rule, health plans will need to build an API that enables their members’ claims and clinical data to be delivered as FHIR® resources after being mapped to the Common Payer Consumer Data Set (CPCDS) and United States Core Data for Interoperability (USCDI) elements. Health plans opting to build their own solution will need a FHIR® expert in house to guide API development to FHIR® standards. 
  3. You need proficiency in application authentication and consumer validation. The rule mandates that a consumer’s request for data can come from any third-party application. Health plans will need the ability to authenticate the application and validate the user of the application, something that requires a deep level of technical expertise and skill. Not only will health plans need to be able to validate their members, they will need the capability to validate consented requests from health care providers.
  4. An enterprise-wide approach is required to address multiple lines of business. Just as no two patients or no two health plans are the same, the same applies to the various types of health insurance products covered under the final rule. Health plans need a well-honed strategy in place that supports their ability to expose their MA, ACA, Medicaid, and CHIP member’s claims and clinical data in CPCDS and USCDI format as a FHIR® resource. A “one-size fits all” approach won’t cut it.

CMS has provided links to a large array of resources, including specific implementation guides, to support health plans in meeting the Patient Access API requirement. While their use is not required, CMS indicates that it will “provide information payers can use to meet the requirements of the policies being finalized in [the Interoperability and Patient Access final rule] without having to develop an approach independently, saving time and resources.”

Top 3 questions to ask a potential Patient Access API partner

There are several additional considerations for health plans that determine whether working with a third-party partner to implement their Patient Access API is the right strategy for them. Overall, identifying a third party that can address both the technical and health care-related requirements of the Patient Access API mandates will be the key to a successful partnership. Make sure you’re asking these questions as you’re researching and weighing your options:

  1. How familiar/experienced are you in managing health care data, possibly originating from disparate sources across the enterprise, and clinical data specifically? Has the vendor ever worked with health care data in the past or are they primarily equipped to take on the technical aspects of creating the Patient Access API? Do they know what CPCDS or USCDI elements are and can they map data to either format?
  2. How do you ensure data integrity and security? Is the vendor HITRUST certified? What is their approach to ensuring proper storage of personal health information (PHI)? Do they have the capability to validate data quality? Can they authenticate a third-party application and validate the users, also taking into consideration state-by-state laws around patient consent?
  3. Is your solution scalable? The Patient Access API mandate is neither the beginning nor the end of the federal government’s efforts to drive interoperability, connectivity, and data-sharing within the industry. There are several additional policies outlined in the final rule that will require use of a FHIR®-based API. Is the vendor developing a one-off solution or building a suite of scalable solutions that will enable a health plan to broaden their data sharing capabilities in a simple, streamlined way?

The path ahead is long, but achievable with the right strategy

While health plans must have their FHIR®-Based Patient Access API up and running, they must also have implemented a Provider Directory API, enabling provider directory information to be made publicly available via a standards-based API. Payer-to-payer data sharing is yet another policy specified in CMS’ final rule, requiring payers to exchange certain patient clinical data at the patient’s request. These regulatory initiatives are only part of a much broader technology transformation that is now well underway in the health care industry. While the path ahead may be long, the journey toward enabling greater interoperability and connectivity across the health care system and empowering patients to be active stewards of their health and health care is essential.

 

About the author

Mr. Archibong serves as associate vice president of innovation at Inovalon, where he oversees the development and implementation of Inovalon’s interoperability solutions. 

As a health care IT executive with over 18 years of experience in the technology field, Mr. Archibong has also held several executive roles for large health care provider systems over the last 10 years. He began his career with Johnson & Johnson (J&J) where he successfully streamlined IT project execution and resource management across all 250 J&J operating companies globally.

He transitioned into health care when he was tapped to join Cooper University Health Care, Camden, NJ as their director of enterprise applications. He successfully led the system-wide implementation and adoption of the Epic Electronic Health Record (EHR) for the health system, a 635-bed academic hospital, Level 1 trauma center, and 630 employed physicians. Mr. Archibong subsequently led both the hospital and providers to successfully attest to Meaningful Use Stages 1 through 3, earning over $10 million in CMS incentives for the health system. Under his leadership the health system achieved Stage 6 on the HIMSS Analytics EMR Adoption model.  

He then joined Anne Arundel Medical Center (AAMC) in Annapolis, MD as its executive director and associate chief information officer (ACIO). There he led several technology advancements for the health system, including the launch of a new Enterprise Resource Planning (ERP) system, a Picture Archiving and Communication System (PACS), and deployment of Epic EHR across all their Ambulatory clinics. AAMC was recognized as one of the nations Most Connected hospitals by U.S. News and World Report, as well as a HealthCare's Most Wired Hospital in 2015 and 2016 during his tenure as ACIO.

Prior to joining Inovalon, Henry was the vice president and site executive for University of Maryland Capital Region Health in Prince Georges County, MD.