What health plans need to know to comply with the FHIR®-based patient access API mandate

“Patients must have complete transparency into the cost and outcomes of their care.”

-The Office of the National Coordinator for Health Information Technology (ONC),
U.S. Department of Health and Human Services

21st Century Cures Act: Data transparency & access supporting empowered & engaged patients

Under the 21st Century Cures Act, as part of ongoing efforts to drive improved quality and efficiency of patient care, healthcare 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 healthcare industry’s broader push toward enabling patients to play a larger role in their health and healthcare – 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 healthcare 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 healthcare 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. Healthcare 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 healthcare continuum, patients will never be able to access a complete, comprehensive 360° view of their health and healthcare. CMS’ Patient Access API mandate is attempting to help bridge this gap.

The data generated in the healthcare 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. 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 healthcare 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 healthcare 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 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 healthcare-related requirements of the Patient Access API mandates will be the key to a successful partnership. Make sure you’re asking these questions as your researching and weighing your options:

1. 1. How familiar/ experienced are you managing healthcare data, possibly originating from disparate sources across the enterprise, and clinical data specifically? Has the vendor ever worked with healthcare 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

At the same time 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 healthcare industry. While the path ahead may be long, the journey toward enabling greater interoperability and connectivity across the healthcare system and empowering patients to be active stewards of their health and health care is essential.

Built upon decades of experience managing healthcare data, deep technology and FHIR®-based expertise, and broad interoperability and connectivity across the industry, Inovalon offers a secure, scalable FHIR®-based API solution enabling health plans to achieve full compliance with the mandates in the Interoperability final rule.

Contact us today to schedule a meeting with one of our FHIR® experts.

Inovalon and design® and Inovalon® are trademarks of Inovalon, Inc.