In this series, I am exploring how Redox can fill the gap between things one would think should be possible and what actually is possible. In the first post, I covered how Redox is overcoming current limitations with bulk FHIR. This time, I’ll be discussing our capabilities to translate between HL7® v2 and HL7® FHIR®—a reoccurring challenge for many of our customers. Let’s dive in.
What does HL7 v2 do?
For those who aren’t in the weeds of healthcare integration, HL7 v2 is the most widely adopted standard for communicating data between healthcare organizations. HL7 v2, a data standard governed by HL7 International, is most commonly employed for event-driven data feeds to communicate updates about events as they happen such as a patient discharge or a new lab result. Most frequently, all of this magic happens over a VPN between organizations. Can you hear that? It’s 1997 calling, and it wants its tech back.
I talk with a lot of prospective customers who come from other parts of the tech world but are new to healthcare, and they often express shock at how relevant such an old standard remains in this field. This shock is generally followed by the expectation that FHIR has negated the need to understand and implement HL7 v2.
If you follow health tech at all, you know that FHIR is the latest “it girl” of healthcare integration. As such, Redox has devoted significant R&D resources to building out our FHIR capabilities over the last several years, and a growing percentage of our new implementations invoke EHR FHIR APIs in some fashion.
But, the reality on the ground is that HL7 v2 is still chugging along: 95% of U.S. healthcare organizations use it. There are many reasons for this, including:
- HL7 v2 includes capabilities that are not yet widely adopted by FHIR (this is the primary focus of the rest of this post).
- Healthcare organizations generally prefer to minimize risk and work with technologies (like VPNs) that are tried and true.
- Continuing the status quo is easier than changing course, especially when there is no legal or regulatory reason to do so.
The current state of replacing HL7 v2 with FHIR
If you’re going to replace HL7 v2, you have to be able to account for all of the existing capabilities that it drives.
FHIR does define a model for event-driven data flows with its subscription resource, allowing one to subscribe (pub/sub) to notifications of changes of various data types (called resources in FHIR parlance). However, the subscription resource has yet to be implemented by any major EHR vendors, and I’m not aware of any upcoming regulations that will force them to do so. Given that, it’s fair to assume that HL7 v2 is going to be around for a while.
However, modern technology shops want everything in FHIR. Stop the madness of pipes and carets, they say!* The desire to avoid the tech debt of antiquated standards is completely understandable, and Redox is here to help.
*This is a reference to the fact that HL7 v2 makes judicious use of the pipe (|) and caret (^) delimiters
Achieving FHIR subscriptions, now
Over the last several years, we’ve adapted our value proposition of “code up to Redox once and be ready to exchange data to any EHR” from our proprietary Data Model API to our FHIR API. Redox Nexus and Redox Nova can help here by translating HL7 v2 to FHIR—as well as the inverse—to make up for gaps in current EHR capabilities. We have a large library of pre-built configurations that account for most of the expected translation. We can also create custom configurations when needed to account for organization-specific differences, such as custom data fields or unique message structures that don’t conform to the published HL7 v2 standards.
Let’s look at an example. Say an application needs to know when patients are admitted to a certain hospital unit; this prompts a case manager to be assigned to the admission. At some point during the admission, the case manager writes a note that needs to be written to the patient’s chart. Looking at Redox’s 270 implementations underway now, it’s most likely that the healthcare organization will want to perform these data flows using HL7 v2.
With Redox Nexus, applications connect to our FHIR APIs for both parts of this workflow. As admission notifications come out of the EHRs as HL7 v2 ADT A01 messages, Redox transforms them into bundles of FHIR resources (at least three and likely more, depending on the exact message contents) that we post to the desired endpoint. When it’s time to write a note back to the EHR, the application will post a FHIR bundle message to Redox; we transform it into an HL7 v2 MDM T02 message and send it into the EHR.
Redox’s translation capabilities extend beyond just HL7 v2: we can perform the workflow above (and many more) with systems that use other methods, such as EHR proprietary APIs or even SFTP file transfer with the same FHIR-based experience for the application. To learn more about our capabilities, check out our plain-English FHIR API actions or list of HL7 v2 message types that we can currently translate.
Lastly, if you’re looking to convert large amounts of legacy data from HL7 v2, C-CDA, X12, or other formats to FHIR, Redox Nova can do this with additional levels of transparency and control, allowing for highly scalable movement of data into our partner cloud vendors including Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and Databricks.
I’d love your feedback on this post. You can send your questions and comments to [email protected]. I’ll be back soon with Part 3 of this series, which will focus on getting value from Carequality as a digital health vendor.
If you’d like to learn more about our HL7v2 to FHIR capabilities, check out these resources:
HL7® is a registered trademark of Health Level Seven International. The use of this trademark does not constitute an endorsement by HL7.
FHIR® is a registered trademark of Health Level Seven (HL7) and is used with the permission of HL7. Use of this trademark does not constitute an endorsement of products/services by HL7®.