As trends in healthcare move towards making data malleable, interoperability is the new buzzword. Healthcare interoperability, in its most basic form, refers to the ability for clinical systems to aggregate, normalize, and truly harmonize various data sources for some sort of consumption down the line.
With this said, standards have become a large part of the healthcare conversation. HL7 was introduced to transmit large volumes of of pre-defined data to be shared across multiple applications. The protocol selected to make this happen was a traditional file transfer or a TCP/IP socket in both a real-time and batched fashion.
As the standard was created by clinical interface specialists, the first production ready version, HL7 V2, was built to address the needs of real-world clinical practices. The group decided to take an 80/20 approach, meaning that they only defined 80% of the framework and left 20% to be customized by whoever would use it. This gave users and vendors a place to reflect on unique business and workflow rules. HL7 needed to be vague initially because they had to get more people on board with using the standard. The more flexible the standard, the easier it would be to adopt.
As more vendors adopted the HL7 standards the value to clinicians and technologist grew. In 1998, HL7 found their tipping point when enough vendors were onboarded that it actually became advantageous to use. Since, several more V2 releases have occurred. Which HL7 V2 release a person is using is not especially important because HL7 V2 should be backwards compatible with older versions of 2.X. The practical solution created wide spread adoption for HL7. However, because of HL7’s goal of application uniqueness it created significant challenges across the continuum of care.
You may be thinking that it feels a little counter intuitive to say that a standard is customizable, and that’s part of the problem with HL7. There are common HL7 codes that are sent through a system that most all healthcare should recognize such as, ADT (admission, discharge, transfer). The problem arises when a particular message cannot hold all of the data required to be transmitted. For example, if a message can hold 75 data elements but but an EKG required 200 data elements the rest of that data would probably be jammed into a Z segment. That data would then need to be parsed, mapped, and normalized to be useful, requiring an impressive amount of development and design time.
On top of that, HL7 standards and codes that are sent out are often not adhered to. It is common to see EHRs and hospitals use their own sets of defined code, which can cause HL7 transmissions to require research and look up before they can be made useful.
Even though the V2 version became widely adopted and more refined, as adoption grew users became frustrated because it required a significant amount of customization in order to fully realize the goal of interoperability. Additionally, even with all of the necessary leg work, the message structure still tended to be complex, flat, and delimited. The organization determined that they would need to take the learnings from HL7 V2 and work toward another version; HL7 V3 is born.
It is important to recognize that HL7 V2 was created by a clinical interface specialist and V3 was created by mostly medical informaticists. With this, the initial focus for each version is unique. HL7 V3 provides more of a true standard and less of a customizable framework with application roles that are defined, fewer message options, and less expensive options to build and maintain mid to long term interfaces. Because of potential legacy issues, it is not backwards compatible, meaning it will not work with V2. This may cause HL7 V3’s adoption to be more expensive and time consuming because of restarting customizations, retraining and retooling this version of HL7 and the fact that applications will have to support V2 and V3 for the foreseeable future.
The HL7 standard is not a perfect solution, but it has the underpinnings the healthcare industry requires. To fill the gaps, technologist have sought to develop a newer standard that incorporates the best of HL7, while solving concerns that have cropped up throughout its lifecycle. The new standard is termed FHIR. FHIR is an acronym for Fast Healthcare Interoperability Resources. It was built to improve security at an HTTP(s) layer and offers a more strongly defined model with easier customization.
FHIR is based on REST which makes it easier to implement and use for organizations and developers. Since it is easier to implement and use compared to HL7, it translates into a cost savings and greater ROI from the service itself versus something like HL7 which might need more customization.
Now, as a quick but important note, this isn't the case today -- FHIR is still early on and read only, meaning that HL7 is still mostly a necessary evil so we can't make that claim yet. Though one of the goals of the spec is to reduce barrier of entry to the healthcare digital ecosystem (HL7 speakers), and FHIR hopes to solve that with an easier, more streamlined REST interface.The future of FHIR is expected to be an evolving one because of the nature of it being open source. This is important because the only way FHIR will continue to remain useful is if it is adaptable as trends and standards evolve. Most iterations are expected to be published every 18-24 months or less. The growth of FHIR is exciting and we are interested to see where it goes next. As this standard evolves, so will CloudMine. Make sure you stay ahead by subscribing to our blog.