This article discusses how modern workflows that support interactive patient functionality and remote patient monitoring can be integrated with the legacy infrastructure prevalent in many healthcare organizations. While the legacy world is utilizing the HL7 v2 standard, modern applications require HL7 FHIR. However, it is possible to seamlessly bridge between the two worlds and accomplish the goals of modern healthcare systems without a need to rip-and-replace reliable and scalable extant infrastructure. Connected Healthcare nowadays reaches far beyond connecting systems inside a hospital or between professional care providers, it involves also connecting with the patient and a wider social community to accomplish better prevention and health outcomes.
By Heinz Joerg Schwarz[1]
I. INTRODUCTION
The meaning of “Connected Healthcare” is constantly evolving. In the late 1980s and early 1990s, when Health Level Seven (“HL7”) was launched, connected healthcare essentially meant that essential patient information could be exchanged between the patient registration system and the laboratory and radiology system. Fast forward to 2022, and we are still using primarily HL7 v2, a standard that was first published in 1988, to transact over 90 percent of healthcare data transactions among hundreds of applications in thousands of organizations worldwide. In an environment where value-based care gains momentum elevating the value of data higher and higher, connected healthcare now means not only connecting all the essential information systems inside of an organization, but beyond those organizational boundaries across different providers of healthcare and social services (Social Determinants of Health). This article will highlight how the legacy HL7 v2 infrastructure still predominant today can be utilized as the foundation for the next generation of connected healthcare, which includes remote patient monitoring for Hospital@Home programs and even a modern digital healthcare shopping experience for consumers. Essential for these modern services are HL7 Fast Healthcare Interoperability Resources (“FHIR”) translations and API orchestration that work seamlessly in conjunction with the extant legacy infrastructure. The good news is that this evolution is very doable, and disruptive and costly rip-and-replace can be avoided in most cases.
II. CONNECTING LEGACY INFRASTRUCTURE TO MEET THE DEMANDS OF TODAY
Hundreds of millions of health care data transactions are today still transacted in HL7 v2, a text based, delimited, data exchange standard developed in the 1980s and 1990s to connect laboratory and medical imaging systems to the patient registration systems of the time. The standard is relatively simple and allows transactions via file transfer relatively easily. Many organizations have scalable and reliable infrastructure in place to connect hundreds of applications using an HL7 integration engine, such as Infor’s Cloverleaf as the #1 installed solution in the U.S and internationally.
However, HL7 v2 is not appropriate for the needs of contemporary healthcare systems anymore. While the structure of HL7 messages is well defined, the payload of HL7 messages can vary from organization to organization, so when someone needs to aggregate data that originates from multiple sites, it gets tricky very quickly. Is gender coded as a binary value (0 or 1, 1 or 2, F or M), or are there even more options? This variability is not good for data analytics. HL7 v2 is also not a good standard for responsive web-services. Instead of pinging an information source for a particular piece of information, the information sending systems sends out messages that then are forwarded. A modern, responsive webservice would require that the recipients ping the source for a piece of information and then receive a response with that exact information (or a message that the information is not available). This all can be accomplished with HL7 FHIR, a modern standard first published in 2012.
III. CONNECTING HL7 FHIR WITH LEGACY SYSTEMS
Many healthcare organizations intent to build user responsive, consumer centric web interfaces that allow potential patients to interact, submit information, schedule appointments, upload data and even conduct televisits through the Internet. This set of functionalities became especially popular during the COVID-19 pandemic and is often termed “Digital Front-Door.” Patients like this type of consumer style engagement and it will remain a requirement long after the pandemic. As described before, HL7 v2 is not the best infrastructure to build this responsive consumer interaction, and the Electronic Health Record System (“EHR”) neither has all the data, nor all the functionality to provide this front-end, either. Organizations often utilize CRM systems to keep track of patients with chronic conditions, they utilize advanced medical imaging procedures, and they want to support patients at home with remote monitoring devices. All of this can be accomplished by combining the new HL7 FHIR infrastructure with the existing legacy infrastructure.
Key components to make this seamless integration possible are an API Gateway,[2] a FHIR Server,[3] and a FHIR Bridge.[4] The API Gateway is installed in a DMZ that shields outside access from the network that connects all internal systems. APIs that allow for example triaging consumers requests for appropriate follow up in chat bots, or APIs that collect Internet of things (“IOT”) data from patients are registered with the API Gateway and are isolated in isolated network environments that allow access to only limited resources. If either of these applications need information about a patient, that information request is routed as a FHIR resource request to the FHIR server, which can respond in real time – essential for applications with user interaction. The FHIR server stores all data received from the interface engine, originally formatted in HL7 v2 and translated by the FHIR Bridge into FHIR resources. A good, full featured FHIR Server will also support subscriptions, which means as soon as updated information becomes available, existing FHIR resources are updated. The FHIR server therefore has the most current data available to respond to requests from APIs interactively and in near real time. Conversely, if the API submits data, it can be persisted in the FHIR server. This is very important for APIs that collect user data, for example from patient monitoring devices. As much of the data will be noise, it requires applications with machine-learning trained algorithms to separate noise from relevant data. Once relevant data is detected, the API can push that data – but not the noise – into the EHR, where care providers can evaluate the data and take further action.
IV. REVIEWING USE CASES FOR MODERN CONNECTED HEALTHCARE
A. IOT Devices and Remote Monitoring
IOT devices that can measure a variety of biometric data have become ubiquitous and make remote patient monitoring cost effective. The challenge is to collect the data and integrate it into the existing infrastructure for professional examination and billing. A variety of companies have developed applications that evaluate the incoming data for early detection of potential problems.
One such example is Vironix.ai,[5] which uses data from inexpensive at-home devices to detect pulmonary and cardiac problems that, if left untreated, could lead to severe health escalations. Another example is Medtronic, one of the world’s largest medical device manufacturers, which launched Pacemakers[6] that can communicate with the Patient’s smart phone to transmit data – but the data needs to be moved from the phone onto the desk of a physician if it is relevant for clinical decision making, and that requires further integration.
In value-based care environments it makes sense for care providers, such as Accountable Care Organizations (“ACO”) to utilize remote monitoring to capture data from selected cohorts of patients, especially those with elevated risk, to keep them from worsening conditions that might require hospitalization. While remote monitoring is a cost-effective way to collect useful data, the patient can’t be the endpoint – the endpoint of this data should be a care provider that can evaluate the data and initiate necessary corrections if and when required.
B. Social Services Integration
It is well understood that social determinants of health (“SoDH”) such as housing, transportation, and nutrition have a large impact on health outcomes.[7] Connected Healthcare therefore also requires exchanging information with social services and consideration and mitigation of such factors.
One of these factors could be transportation, and one of the integrative actions could be to integrate APIs for transportation providers such as Uber or Lyft, so that care providers can not only schedule an appointment for a patient, but also orchestrate that the patient will be picked up at home for an appointment and brought back home after the appointment. Since these services are in certain cases reimbursable, the integration would not only provide patient address and pickup time to the transportation provider, but also collect the information necessary to file for reimbursement from the insurance carrier.
C. Interactive Payer Integration
The 21st Century Cures Act does not only require providers to share clinical data with patients and other providers: it also requires Payers to exchange data among each other and with the patient. Connected Healthcare can modernize the ancient billing process, usually many months delayed after the clinical episode and transacted in X12, with modern, interactive HL7 FHIR workflows. Rightfully termed “Burden Reduction,” a FHIR based dialogue between the provider and the payer can automate the prior authorization workflow that currently requires much manual intervention and communication both on the provider and the payer side.
In this workflow, a provider that decides a patient requires a follow-up intervention submits a prior-authorization request to a payer, customized for the requirements of the payer for the type of requested procedure. This might require supporting documentation, which can be retrieved from the FHIR Server. The payer system that responds to the pre-authorization request can then not only confirm eligibility, but also check if all required documentation is provided. If something is missing, it can request this information is real time, while the care provider is still inside the patient workflow. On the payer side, the FHIR resources can be mapped into X12, the standard mandated by HIPPA to transact medical claims. All in all, a fully FHIR enabled workflow that interacts on the provider side interactively with the existing HL7 v2 infrastructure and on the Payer side with the existing X12 infrastructure creates a much streamlined process with time and cost savings for both payers and providers.
D. Hospital@Home
Gaining popularity even prior to COVID-19, Hospital@Home concepts have gained momentum in times when Hospitals struggled to keep capacity during the pandemic. The value is that patients who can be monitored and cared for in their own home don’t occupy a hospital bed and still can receive hospital quality level care. Remote monitoring is essential in this concept, as are care providers that are able and equipped to travel to various home sites.
Hospital@Home represents a challenge for Connected Healthcare because the network infrastructure of the home is out of the control of the hospital, yet the data that flows from the home needs to end up in the same electronic medical record used inside the hospital. This can be accomplished by installing home hubs that collect and transmit data through mobile hotspots. Utilizing technologies such as the Cloverleaf Secure Courier,[8] intelligent agents that collect and encrypt the data remotely, transmit it to a central collection point on encrypted transmission lines where it can interface with the hospital integration engine, are available to enable this integration both securely and seamlessly.
It should also be mentioned that the scheduling systems and the supply chain system need to support Hospital@Home care delivery models with schedules that consider driving times and supplies that are in mobile units.
V. CONCLUSION
Connected Care is continuously evolving. From its humble beginnings, when the definition of connected care was restricted to connecting the laboratory system to the patient registration system inside a hospital, to today, when it involves collecting data from the patient and their IOT devices, exchanging data with payers in real time, providing hospital-level care at the patient’s home, and including social services and social determinants of health, both technology and use cases keep adapting to new paradigms and business models. With the increasing importance of value-based care, the focus has shifted from acute care to prevention, enabled by modern telecommunications infrastructure and IOT devices. The comforting news is that we have the technology to bridge between the legacy infrastructure built for the older Connected Healthcare paradigm and the modern infrastructure required for contemporary requirements without a costly rip-and-replace.
[1] Professor Joerg Schwarz is currently Senior Director for Healthcare Interoperability Solutions and Strategy at Infor with over 25 years of experience in the Healthcare Industry and in the interopera-bility space specifically.
[2] Infor API Gateway: https://www.infor.com/resources/cloverleaf-api-gateway.
[3] Infor FHIR Server: https://www.infor.com/resources/cloverleaf-fhir-server.
[4] Infor Cloverleaf FHIR Bridge: https://www.infor.com/resources/infor-fhir-bridge.
[5] More info on Vironix.ai can be found here: https://www.vironix.ai/.
[6] More info here: https://www.medtronic.com/us-en/mobileapps/patient-caregiver/mycarelink-heart-app-connected-heart-devices.html.
[7] Social Determinants of Health primer: https://www.kff.org/racial-equity-and-health-policy/issue-brief/beyond-health-care-the-role-of-social-determinants-in-promoting-health-and-health-equity/.
[8] More Information can be found here: https://www.infor.com/resources/infor-cloverleaf-secure-courier.
