Eliminating Interoperability Hurdles in Digital Health Requires More Than FHIR-The HSB Blog 10/4/21
Our Take:
While FHIR may help improve many of healthcare’s data interoperability problems, it will not solve all of them. Getting the full value of new data sources created by the digitization of healthcare and making it interoperable requires not only looking at what is currently available and supported by the HL7 standard but what may not be as well. Healthcare payers and providers will have to be compliant with the interoperability rules but need to think holistically about their own organization and how to create a flexible technology architecture, in addition to what is provided by HL7 to ensure an organization’s specific data requirements are met. As data interactions will vary dramatically as new digital tools are incorporated into current workflows, stakeholders need to consider the best ways to use and incorporate these into the future of care, when implementing a data standard and planning for interoperability.
Key Takeaways:
According to the Pew Charitable Trusts, “approximately 40% of survey respondents said COVID made them more likely to support efforts that enable data-sharing among a patient’s providers and let people download their personal data from EHRs to apps.”
Between 2009 (when HITECH Act passed) and 2015 basic EHR adoption went from 12% to 72% for hospitals and from 22% to 54% for ambulatory EHRs.
Research done by ONC on individual’s perceptions of data privacy and security shows approximately two-thirds of respondents remain concerned about unauthorized viewing when data is shared by providers.
According to the IQVIA Digital Health Trends report, there are now over 350K health-related mobile apps, and almost 90K were created in 2020 alone, driving the need for data access and interoperability.
The Problem:
For years healthcare has been plagued by underinvestment in technology and systems that were dominated by records kept on paper and exchanged by fax. In 2009 the U.S. Congress passed the HITECH Act hoping to spur investment in technology to digitize paper-based hospital records. The HITECH Act incented hospitals and physicians to adopt electronic medical record systems (EMRs) by giving them reimbursement payments and other benefits for using EHRs which met certain standards. One of the goals of the HITECH Act was to improve the efficiency and accuracy of healthcare records while improving the exchange and portability of records. However, while the HITECH Act did successfully move the vast majority of hospitals and physician practices onto EMRs and other electronic record-keeping systems, by and large data remained largely interoperable, trapped in silos behind the walls of individual institutions, and often not shareable between EMR vendors or interoperable between systems. To help overcome these issues in 2016, the U.S. Congress passed the 21st Century Cures Act which addressed the issues of interoperability, information blocking, and patient access to records. As required to implement the 21st Century Cures Act, in March of 2020, the ONC published the information blocking rule that took effect in April of 2021.
While the ONC Final Rule created a number of legal requirements for interoperability, we feel healthcare is at a critical point where it is more important to explore the true functional requirements for interoperability. One of the core issues regarding interoperability is that interoperability is more than just implementing a standard or being able to have two systems exchange data with each other. It is beyond the technical challenges of integrating multiple vendors with different compliance needs. In addition, healthcare is also plagued by the fact that there is no single system of record for interactions with the system and even no single way to identify patients (ex: a national patient identifier). For example, interactions with hospitals and physicians are governed by clinical data generally stored in an EHR detailing clinician interactions, medications, prescriptions, lab tests, imaging, and other diagnostics. By contrast, claims data is used by payers (healthcare insurance companies) to track and pay for providers used, charges billed and discounts to those charges and prescriptions filled.In addition, there is often a third system that is used to track and reconcile financial transactions with patients, payers, and providers. Often data can be lost between systems or very difficult to exchange between systems. For example, while claims data is predominantly financial, clinical systems have to deal with structured data (ex: coding for diagnosis and testing), unstructured data (ex: physician notes in free text fields), and fields involving different storage mediums and signal processing (ex: blood tests, EKGs, etc.). While much improved from earlier in the decade, these issues remain at the heart of poor communication between providers, payers, and patients and, often in inefficient coordination of care.
The Backdrop:
As noted on its website, “founded in 1987, Health Level Seven International (HL7) is a not-for-profit, standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery, and evaluation of health services.HL7”s mission is to provide standards that empower global health data interoperability.” In addition, the Office of the National Coordinator for Health Information Technology (ONC) also provides national guidance in the US regarding data standards and expectations for improving data interoperability. The ONC and HL7, among other organizations, have worked to establish the Fast Healthcare Interoperability Resources (FHIR) standard for how to structure and format health data to provide guidance to improve the implementation of health IT solutions.
According to “A Brief History of FHIA and Its Impact on Connectivity”, “FHIR seeks to be the next-generation foundation by which electronic health records (EHRs), digital health applications, and consumers use and exchange structured healthcare data.”The FHIR standard helps developers and clinicians develop software to access and exchange data by using a shared structured format for making an Application Programming Interface (API). APIs themselves are a standard for how to exchange and access data that requires multiple parties to understand how the API works, such as what variables are available for programs that interact with the API to be able to perform operations for creating, reading, updating, and deleting data. An API can be thought of as a series of doors that can provide access for different software applications, and the standard is like a map that provides the route for how to find a specific door, and an API key is a key that allows you access to the door that you were granted access to. By using APIs HL7 is seeking to bring healthcare applications and systems closer to more typical consumer-driven applications which are plug and play between systems.
According to HHS the goal of the interoperability rule is to “support a patient’s access and control of their electronic health information [and by using APIs] patients will be empowered to more securely and easily obtain their electronic health information from their provider’s medical record for free’” As Donald Rucker, National Coordinator for Health Information Technology at ONC stated when the Final Rule was announced, “delivering interoperability actually gives patients the ability to manage their healthcare the same way they manage their finances, travel and every other component of their lives.
Implications:
Digital health has the potential to radically change the process and efficiency by which healthcare is delivered, however, one of the biggest challenges faced by these products is an inability to interact with, extract and exchange patient data within or among existing systems. Having standards, such as FHIR, create an opportunity to simplify the development and implementation of products that leverage health data as it moves into the digital age. This is particularly important
as digital health products, which can improve the ability to monitor and thus intervene with patients such as wearables and other remote patient monitoring and virtual tools, generate significant amounts of data that needs to be exchanged, analyzed, and acted upon in real-time to have maximum impact. In addition, FHIR was developed with current clinical processes and workflows in mind; this means while it may help solve the issues and data requirements of workflows and care protocols of today, it will not future-proof the organization in the creation of the healthcare delivery system of tomorrow.
Healthcare delivery systems must develop a roadmap for integration with systems that generate health data, and real-world evidence for treatment research that will be used in the future. Moreover, having an interoperability standard does not solve healthcare’s data issues outside of interoperability, such as data completeness, data integrity, managing structured and unstructured data, and data security. As healthcare slowly begins to shift data to the cloud, development and implementation times will be dramatically reduced but this will shift the burden to chief information officers (CIOs) and Chief Medical Information Officers (CMIOs) to ensure they are deploying the right architecture designed for new data models as well as the different types of data to be stored, processed, and analyzed in care going forward. While FHIR is a major step forward in easing the exchange of healthcare data, it is important to consider how FHIR does and does not fit the data requirements of your organization. Other solutions that have compatibility with FHIR API standards and have additional features and support for other forms of health data may or may not be more appropriate. As pointed out in “A Brief History of FHIR and Its Impact on Connectivity” “nothing has fundamentally changed about how EHRs implement and use standards with FHIR. Real disruptors may use FHIR, but the real change in value and hence disruption is going to come [as it addresses] ‘what problems does FHIR not solve."
Related Reading:
