Introducing: Insights into Interoperability

Getting to “Plays Well with Others” on the Health Records Report Card

Healthcare is a data-driven industry. Delivering the right care to the right patient at the right time and in the right venue is dependent on having complete, accurate, and timely access to that patient’s health records.  

This is a pretty straightforward and noncontroversial statement. However, the problem is that this “frictionless” and timely access to a patient’s longitudinal health record is generally not the reality for delivering or receiving care in our fragmented healthcare system.  And that results in a high cost—both to individual patients and to the health system as a whole. Furthermore, the costs associated with lack of timely and complete access to a patient’s relevant records are high—in the context of waste, direct errors, and unnecessary frustration (for patients and providers alike).

In response to this (long recognized issue) Congress passed the 21st Century Cures Act in 2016 which, among other things, directed the Office of the National Coordinator for Health Information Technology (ONC) and the Department of Health and Human Services (DHHS) to institute administrative rules to address data blocking (the practice of denying access to clinical data for a market advantage) and health information interoperability across stakeholders and systems. Last year the ONC and the Centers for Medicare and Medicaid Services (CMS) issued corresponding Final Rules, implementing this legislation. 

These rules were welcomed with both enthusiasm and (understandable) trepidation (….along with some selective hostility where a more interoperable framework undermines a given stakeholder’s strategic market advantage). While there is broad based consensus as to the necessity and urgency of these regulatory changes, it also comes with a lot of unanswered questions as to how to thread the needle between competing interests (privacy and security vs. accessibility, to name one morass)—and then how to implement.  As with many big and #wicked problems (and any problem in the U.S. healthcare space)—it’s complicated.  You don’t overhaul decades of market dynamics—not to mention addressing technical and operational challenges—overnight, at least not without things getting messy. 

And that brings us to the topic of our article today and the introduction of this series: Insights into Interoperability. Last month, amidst limited public attention, CMS began enforcement of two important components of CMS’s Interoperability and Patient Right of Access Final Rule. This requires that: 

• Hospitals with relevant EHR capability send (daily) Admission, Discharge, and Transfer notifications to other providers in a patient’s care network.
• Payers must utilize and support FHIR API’s to allow patients to have ready access to their medical information, and the ability to direct the disclosure of that information to other providers, members of their care team and third party applications (think of those mHealth or care management apps).  

Together, these are two significant milestones in the initiative to foster an interoperable electronic health information ecosystem across disparate stakeholders. 

Now, I threw out a few acronyms there and technical terms.  It is worth backing up a little to level set, define terms, and explain what this will (ideally) look like for patients and providers in practice

WHAT IS AN API?

API is the acronym for an Application Programming Interface, a software interface or portal that allows two applications to connect and “talk” to each other. We utilize APIs throughout our digital lives including every time we log on to a site using our Google or Facebook account (as one example).  APIs are also central to a lot of the financial operations we conduct digitally (bill pay and Paypal being two examples). 

WHAT IS FHIR?

FHIR is the acronym for Fast Healthcare Interoperability Resources and includes the standardized data formats and API standard for the exchange of electronic health records.  FHIR was developed by a non-governmental consortium (Health Level Seven International) and, in addition to standardization, is significant because it takes a discrete data field entry approach as opposed to building upon a document-centric approach which specific formatted entry fields. Using these smaller building pieces as the architecture facilitates utilization of APIs and, thus, interoperability across disparate legacy EHR systems (which were not necessarily designed with the objective of cross-system interoperability).

WHAT WILL THIS LOOK LIKE?

The intention, as noted above, is to enable greater patient access and control. This means that patients (without “special effort”) will be able to portal in to their health records with a payer (or provider) to access those records and direct how they are used – including disclosure to third parties (such as those mHealth applications) that have traditionally been outside of the formal patient care circle. Payers will also have to maintain a provider directory to facilitate the patients identification and incorporation of providers as part of their care team. 

The intent is that Covered entities (specifically payers and providers)—which have access to the biggest, most comprehensive chunk of a patients health record—will have a user-friendly portal for patient access which centralizes and harmonizes data.  The experience should be like logging in to your banking account, or your existing patient portal for a health system, except a lot more user-friendly, centralized and responsive than the latter.

While the federal government has outlined a detailed technical and conceptual framework for the push for an interoperable health information ecosystem, how we fill in the (many) blanks along the way remains to be determined. This is causing some consternation and scrambling in the Information Security and Compliance departments across states. But while we recognize that implementation is always messy, we should take comfort in the fact that while this is a new challenge to the healthcare industry, this is not uncharted technical territory. These are issues that other industries (notably the financial industry, which also has a lot on the line when it comes to protected data and operational security) have had to grapple with. In an interview with EHR Intelligence, Don Searing, VP of Solutions Architecture at HGS Colibrium, compared the introduction of patient-facing APIs to bill pay, noting: “It’s going to start off ugly.”

But that isn’t a reason to not press on—particularly if we really intend to deliver on the promise of “patient-centered care”—enabling a patient to have timely access to his or her longitudinal health record and the ability to (without extraordinary effort or friction) to direct its disposition, is an unmissable step in breaking down the too often inefficient hierarchy of care delivery.

Throughout this series we will explore the emerging issues related to implementation of ONC and CMS’s Interoperability and Patient Right of Access.  For now, we leave you with a quick run down of some recent (and pending) events.

•  The Sequoia Project (the selected contractor for ONC) released its draft of the Qualified Health Information Network Technical Agreement. This addresses the technical requirements for exchanges between Qualified Health Information Networks (including privacy and security requirements). Stakeholder comments are invited through September 17, 2021.

• Google Cloud (working in coordination with the Mayo Clinic) circulated a private preview of its upcoming data interoperability and harmonization tool, “the healthcare data engine.” Health data interoperability and harmonization is the new space and race for tech giants. (Think is it a little more productive than vanity space travel as an endeavor #WatchThisSpace).
• In the midst of all of this cybersecurity remains very much “a thing.” Last week, nearly half a million patient records were breached following a successful phishing attack at a Florida-based practice.  A recently released report estimates that the average cost of a data breach increased by 10% (to $4.24 million) in 2020.  Similarly, ransomware heists are an increasingly pervasive (and lucrative) activity for bad actors, resulting in an estimated cost of $20 billion so far this year.