Electronic Health Reporter

By Jörg Schwarz, director of strategy and solutions, Infor Interoperability

The COVID-19 pandemic has served as an innovation catalyst for many healthcare delivery organizations. Within a short period of time, health systems had to find ways to perform tasks they previously did not execute, such as scheduling thousands of vaccination appointments online with people that are not regular patients and delivering healthcare visits between patients and doctors electronically.

Let’s pause for a moment and acknowledge what a great achievement this burst of innovation and implementation was in an industry that chronically underfunds IT and rolls-out projects over years, not months.

However, this accelerated innovation can also present a problem – there is no going back. Patients expect online services. Patients want to book appointments like they book services for their car or food delivery: online. Patients want the option to have phone or video visits instead of waiting weeks for face-to-face visits. There is a myriad of options for new applications that promise remote patient monitoring or improved diagnostics, workflows, etc. How can a CIO in Healthcare possibly cater to all the demands for innovation when they must shell out the majority of their budget to maintain a behemoth EHR Mega suite from one of the three main vendors in the U.S. at the same time?

Fortunately, there are interoperability standards that enable just this – connecting new applications that augment the functionality of core systems and let information flow between all of them. HL7 v2 was designed for this and has been around since the 1990s. It was developed along with other EDI standards, such as X11, in an age when files where exchanges in batches or real-time when a connection was available – in other words, before the Internet age. While HL7 v2 is focused on transacting clinical data, X11 was developed to transact claims.

Much has changed in the world since the 1990s, and HL7 v2 is still the reliable de-facto standard that our healthcare system and interoperability across providers runs on in 2021. But it is not a great standard in the age of web services and mobile applications. To ensure interoperability flourishes in today’s digital age, we now have HL7 FHIR (Fast Healthcare Interoperability Resources). Many of the new and promising applications that allow innovative functions and workflows are based on FHIR. The introduction of FHIR creates the following set of questions for a CIO at a healthcare delivery organization that is considering his or her innovation agenda:

1. Do I have to replace my HL7 v2 infrastructure with HL7 FHIR infrastructure?
2. Can HL7 v2 and HL7 FHIR co-exist?
3. Should I connect all my FHIR APIs directly to the EHR?
4. How can I guarantee reliable 24*7 SLA for healthcare delivery and still run innovative programs in parallel?
5. How can I get more control of my innovation agenda, instead of relying on my main EHR vendor exclusively?

Let’s discuss these valid questions and concerns one-by-one in more detail.

Do I have to replace my HL7 v2 infrastructure with HL7 FHIR infrastructure?

The answer to this question is, at this moment, clearly NO. Based on our experience, we assume that the average hospital transacts about 2-3 million HL7 v2 messages per day – which equates to a total volume of 15B transactions per day, which is a conservative estimate for the United States alone. A vast majority of this volume will be Admission, Discharge, and Transfer (ADT) messages.

ADT messages, while basic and fundamental, carry out important functions. Numerous state Medicaid agencies have sanctioned and even funded statewide networks that share ADT messages from hospitals to primary care providers, MCOs and ACOs, such as Minnesota, Florida, Tennessee and most recently Illinois. Not only are these ADT notification networks not going away, as of May 2021, it is now mandatory for hospitals nationwide to share admission information to primary care doctors as per the 21^st Century Cures Act. Admission or discharge information to regular care providers ensures a seamless transition of care and post discharge follow-up. This function can be carried out very well using HL7 v2, so there is no need to rip and replace this vast infrastructure with FHIR. At the same time, it means HL7 v2 is here to stay until it makes sense to switch completely to a webservices-based infrastructure.

Can HL7 v2 and HL7 FHIR co-exist?

Yes, absolutely. While we have a proven and capable infrastructure to transact high volumes of HL7 v2 messages, as the previous example of ADT type messages demonstrates, we also need more sophisticated workflows driven by FHIR. For example, the 21^st Century Cures Act mandates  FHIR-enabled prior authorization workflows, which would be impossible to implement in HL7 v2 by 2022.

Prior authorization is a good example of the power of FHIR workflows. Today, prior authorization can be time consuming and frustrating for providers. Depending on the condition and suggested procedure, as well as the specific payer, providers need to submit different documents and data elements to a payer to get treatment authorization, a pre-requisite for later billing the payer for the actual procedure.

This imposes a burden on providers that the Cures Act seeks to reduce by automating the process as much as possible. The DaVinci workgroup within HL7 FHIR is working on pre-defined workflows that will allow providers to submit the right documentation based on the condition and payer requirements. This is facilitated through a web services dialogue between the provider system and the payer system in near real time and could even prompt questions to the provider that could be answered in real-time.

As a result, prior authorization will be streamlined and billing will be improved, so it is hard to imagine that providers won’t jump at the first opportunity to implement this as soon as the Cures Act makes it mandatory for payers to support this workflow. That means both payers and providers will have to invest resources to build, test, and support the infrastructure supporting this FHIR workflow over the next 12 months while our daily business of processing 15 billion HL7 v2 transactions per day keeps going on.

Should I connect all my FHIR APIs directly to the EHR?

This question is as old as interoperability, and the answer always has been and remains a clear NO. The reason HL7 was created in the first place was to allow a repeatable way to connect specialty systems for laboratories, medical imaging, medical devices, and ancillary systems from the kitchen to supplies management to the electronic medical record (EMR) and electronic resource planning (ERP) systems. This was accomplished by specialized interface engines that would handle all the translations and disintermediate the core clinical system from the ancillary system.

Interface engines have been proven very scalable and useful to replay a single ADT message from the EHR to all the connected systems, inside and outside the organization, that need data from the ADTs for their own purposes, such as a PACS system, that needs patient demographics and a Medical Record Number (MRN) from the ADT to synchronize its output with the EMR.

The same concept of disintermediation will remain true in the age of FHIR. There will be a multitude of web services from inside and outside the hospital that will request FHIR resources. For example, a smart CT system will request the BMI of a patient to calculate the exact dosage of a contrast agent, or a monitoring device with generate loads of data by constantly monitoring vital signs of a patient. Instead of exposing the core system directly to all these data resource read and write requests, FHIR resources can be staged in a FHIR server and loaded from/to the core system at a steady rate without interfering with the core mission of the EMR at the point of care.

Since many web services might also cross organizational boundaries, it is much more secure to isolate the EMR inside the firewall and instead have the interface engine handle API webservice calls from outside the firewall through a secure API Gateway. In conclusion, disintermediating FHIR traffic from the EMR through a smart and secure interface engine is more scalable and secure than trying to connect all web services directly to the core EMR.

How can I guarantee reliable 24*7 SLA for healthcare delivery and still run innovative programs in parallel?

The answer to this question builds upon the previous answer – by disintermediating the core production system for any peripheral workflows through a smart and secure interface engine. When the EMR is disintermediated in such a way, 24*7 operations with high availability SLA can be guaranteed and innovative programs can be explored in parallel. This will require an interface engine that supports both HL7 v2 and FHIR and can translate between the two formats seamlessly.

If an innovative program for patient monitoring, for example, requires some data from the existing system (such as demographics, lab results, medication history), this data can be extracted in HL7 v2 or FHIR format and persisted in a FHIR server. The data received from the monitoring program can also be persisted in HL7 FHIR format in the FHIR Server, and the EHR is updated in pre-defined intervals or when certain anomalies occur. HL7 FHIR also supports subscriptions, so whenever a trigger event happens in the HL7 FHIR data on the FHIR Server, subscribing systems – including the EMR – can be automatically updated. This setup allows a very versatile configuration for a variety of use cases and prevents overloading the EMR with unnecessary data that would convolute the medical record and make it harder for care providers to perform their routine activities.

How can I get more control of my innovation agenda, instead of relying on my main EHR vendor exclusively?

The conclusion of all prior points is that while HL7 v2 is here to stay for a while, HL7 FHIR opens many new opportunities for innovation that will support modern ways to improve value-based care delivery. Many analysts agree there will be various aspects to this innovation in the form of device vendors, AI/ML based algorithms and applications, care management programs, risk stratification tools, and gap-in-care detectors.

It would be a mistake to rely on a single vendor to provide all this innovation in the form of an EHR mega suite. Instead, CIOs can utilize the power of interoperability with both HL7 v2 and FHIR to build a secure and scalable infrastructure by disintermediating their core EMR with a capable interface engine and FHIR infrastructure that allows securely transacting their day-to-day business while also supporting new innovative programs with great flexibility.

This requires a smart interface engine that can translate seamlessly between HL7 v2 and FHIR and persist FHIR resources, so that the core EMR can keep optimized for 24*7 care delivery, yet critical data can be used for fully integrated modern care programs across the care continuum.