When Data Standards Fail to Standardize Exchange: A Close Look at the Unique Challenges in Today’s Healthcare Data Standards

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), which is responsible for many of the core internet standards and has no formal paid membership model required to participate. HL7, on the other hand, is a membership organization that requires health systems, software vendors, and other stakeholders to pay significant membership fees to participate in the feedback process and to vote on changes to the standard.


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. HL7 standards, however, are often architected to have a strong amount of variance due to the evolution of the HL7 organization, which in turn create even larger variance in implementation.  

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.


Deployment to healthcare organizations requires a significant amount of work, typically including 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. 3 might represent Caucasian at one health system and Pacific Islander at another. 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, 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.

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.

KMWorld Covers
for qualified subscribers
Subscribe Now Current Issue Past Issues