Within healthcare, there’s a single organization that sets the standards for most clinical data. HL7 was created in 1987 to provide a framework and standards for the exchange and retrieval of electronic health information. Today, the organization has more than 1,600 members from over 50 countries, including healthcare providers, government officials, payers, vendors, and others with a vested interest in the healthcare industry.
The process to create a new HL7® standard and move that standard into the hands of developers and ultimately into live software is long and complex. Various health systems have adopted different versions and types of standards, and even within the same version, there is significant variation in implementation. These realities present numerous challenges for software companies and health systems trying to stay in sync with one another.
It’s worth noting that HL7 has also introduced FHIR® (Fast Healthcare Interoperability Resources), a standard with a more modern communication structure that is currently in a trial use stage. FHIR has similar problems to HL7 in that the content communicated using FHIR is still highly variable and specific to each health system. I’ve written this article with both FHIR and HL7 standards in mind.
In this post, we’ll take a look at the process of creating an HL7 standard, the unique challenges of taking that standard from authorship to deployment and use, and the ways that Redox tames the complexity. First, let’s start with digging into the process of creating and implementing HL7 standards.
HL7 standards: From ideation to clinical use
In brief, the process from standard ideation to implementation and use unfolds as follows:
- Authorship: HL7 collects feedback and input from healthcare organizations, software vendors, and other stakeholders to create the standard itself, which is effectively an academic set of specifications for how clinical data is transferred between applications.
- Implementation: Software vendors such as electronic health record (EHR) providers implement those standards in their software.
- Deployment: The EHR updates are deployed to the healthcare organizations using those EHRs.
- Configuration: The systems need to be configured, whether by an in-house IT team, EHR team, or external support.
- Use: Two parties exchange information using the standard, such as through an interaction with a new application or a connection to an existing external vendor.
Unique challenges in HL7 standards
Written step-by-step the process seems simple enough, but when we look deeper, the process contains details and challenges that are unique to healthcare standards.
In general, most standards organizations are broadly open, as is the case with the Internet Engineering Task Force (IETF). The IETF is responsible for many of the core internet standards and has no formal paid membership model required to participate. The organization is run by volunteers and is funded by meeting fees, sponsorships, and by its parent organization, the Internet Society. HL7, on the other hand, is a membership organization. The organization requires health systems, software vendors, and other stakeholders to pay significant membership fees to participate in the feedback process outlined in Step One and to vote on changes to the standard.
Furthermore, outside of healthcare, most standards are implemented completely — that is to say, 100% — or not at all. That binary provides simplicity by reducing the number of decision points. With HL7, however, there is a large amount of variance between how vendors implement HL7 standards in Step Two above.
HL7 standards themselves are often architected to have a strong amount of variance due to the evolution of the HL7 organization. That variance is shaped by HL7’s initial pre-World Wide Web use as a standard for exchange between different vendors within the same data center administered by the same IT staff at a health system. HL7 wasn’t originally designed for the Internet; it was made for data exchange within the four walls of the data center in a hospital’s basement. Given its original intent, maintaining compatibility to exchange information between health systems wasn’t a high priority.
Step Three, deployment to healthcare organizations, requires a significant amount of work. Deployment often requires a specific IT project along with the requisite funding, IT staff time, and technology infrastructure to support a new standard. Each implementation is highly customized for the healthcare organization, and deployment requires technology teams to be on-premise.
For example, the patient’s race is typically represented as an abbreviation or just a number that is unique to that health system. At one health system, 3 might represent Caucasian while at another health system it represents Pacific Islander. While this lack of consistency is business as usual for the healthcare industry, it’s not how the process works in many other industries.
When the Bluetooth Special Interests Group authors a new specification, for instance, vendors such as Apple and Bose implement the standard in their devices and that’s it — there’s no additional configuration needed to move from vendor implementation stage to using the standards. (Headphones owners might need to occasionally update the software on their phones or other devices, but the update runs automatically and requires no implementation or configuration decisions.)
Additionally, different organizations have different priorities for how up-to-date they keep their systems, and the overall landscape becomes fragmented in terms of both the version adopted and health system-specific configurations.
In Stage Four, the frequency of health system-specific configuration of HL7 standards presents interesting challenges to application developers. Each health system will have implemented a customized set of specifications, and vendors seeking to work with those health systems traditionally need to adhere to each custom setup.
Solving common HL7 challenges
If the process sounds ripe with potential for complications and costly software updates, it is. Both health systems and healthcare technology vendors have to manage this complexity in order to stay current (or current enough) and to maintain interoperability between health systems and healthcare technology solutions. Redox can help solve some of these challenges and remove much of the time and cost burdens involved. Looking at the process step-by-step, here’s how:
Step one: Authorship
HL7 standards are often not based on actual practical use cases but rather the input of subject matter experts considering all possibilities and all angles. This means that often the standard itself tries to do too many things and covers use cases that are not pragmatic. For example, HL7 FHIR (DSTU3) was built to support veterinary use cases in addition to human clinical cases, and there’s a “Patient.animal.breed” field in the specifications. In rare cases, this can be useful, as was the case for an Alaskan hospital lab that needed to process sled dog specimens. Most of the time, however, there’s no need to represent animal patients in the data model.
Instead of including all of these obscure use cases HL7 members developed speculatively, Redox uses input from its customers to develop a single data structure that represents the practical use cases and applications that are commonly in use across the market today. This data structure is, quite literally, our product. Unlike HL7, our business longevity and success depends on keeping this data structure consistent and usable for our customers.
We also collaborate with industry leaders to determine practical implementations of a consistent standard in emerging and future areas as well. For example, the field of precision medicine (using patients’ genomes to craft personalized treatment plans) is an important emerging area in healthcare. HL7 and incumbent EHR vendors are not keeping up with quickly evolving spaces like precision medicine, so we work with the people driving innovation to see where we need to be going, and how quickly, to be able to support them. To pull in a sports metaphor, we’re looking at where the puck is going when developing our data model instead of where the puck is now.
Step two: Implementation
While there can be significant variation between implementations of different EHRs and even between the same EHR vendor in use at different health systems, Redox offers a standardized and normalized data set and data model that allows those variances to be abstracted.
For example, in the Redox data model, we standardize the Patient’s Race field to the U.S. Census Bureau’s defined list of races to provide consistent data, even when health systems may send a number representing a race (e.g. “3” for Caucasian) or a custom abbreviation. We abstract away from the different standard versions in use at health systems to provide a uniform, modern API experience for application developers.
We also smooth out the variance in data flow. Some EHRs require external systems to query for information like Appointments while other EHRs push that information to external vendors. Redox allows the application developer to set whether they prefer to make queries or receive push notifications, independent of how the health system exposes that data.
Step three: Deployment
Redox offers support for any implementation at any health system. If they have HL7 v2, FHIR, their own API, or even FTP of some custom flat file, we are able to support that and normalize that to our data model.
We are also able to transition in step with the health system as it inevitably changes its infrastructure without forcing the application developers to do any additional engineering. This means that as FHIR becomes more popular and HL7 v2 begins to wane in some areas (though it will never go away completely), Redox allows an application developer to design once without worrying about what’s going on at the health system under the hood.
Step four: Configuration
Redox also offers a great deal of value in connecting applications to the standards that have been implemented. For example, Breg, a manufacturer of orthopedic braces, has used Redox to connect to over 40 health systems across 10 different EHRs. More specifically, Breg’s Vision Cloud Connect web and iOS application connects with EHRs to pull patient information and document device dispensation, placement, and billing. One Breg employee did the development and provides minimal ongoing integration support. Without Redox, we estimate that maintaining this level of complex interoperability would require about 8 to 10 full-time employees.
In conclusion
My hope is that this deep dive into the HL7 standards process has provided insights and ideas for what each phase of standard adoption will entail. If you’re considering Redox or looking for a way to streamline the process, our platform is a seamless and efficient way for healthcare organizations and applications to connect with one another. We have a number of applications who have gone live in a one-week project as opposed to the current state of three to six months that our customers report experiencing before Redox.
If you’re interested in getting started with Redox, or want to learn more, contact us here.
Stay in the know! Subscribe to our newsletter.
HL7® and FHIR® are registered trademarks of HL7 and are used with the permission of HL7.