Rhapsody Health Solutions Team

Learning to Speak the Language of Health Data Exchange

Upon starting the University of Texas Health IT program, I quickly became acquainted with two buzzwords: interoperability and connectivity. The central theme of most discourse was that patient data needs to be transferred to other providers, to labs, to insurance companies, and to essentially anyone involved in a patient’s healthcare experience.

Widespread adoption of EHRs and exchanging of patient data (structured, codified data) can result in many benefits such as more comprehensive history of a patient’s health, reduction of medical errors, and strengthening of medical research. After a few experiences with family members needing extensive treatment, I could attest firsthand that there was often a lack of cohesiveness in a patient’s overall care experience, especially when more than one doctor was involved.  

I entered the program to study health IT, moving on from a career as a high school teacher. I didn’t yet know the specifics and intricacies of how technology was being used in the various healthcare settings, but I felt that if the many entities involved in patient care could act together to form a more complete picture of an individual’s health, then I was on board.

During an internship with a Regional Extension Center, funded by the ONC, I was able to assist physicians and other healthcare professionals with implementing technology into their work. For some of the providers who had been in healthcare for a long time, utilizing an EHR in their daily routines required a bit of a learning curve; a sort of Computers 101 class ended up being the lesson plan.  For others, using the application was simple enough, albeit an undesirable hindrance to their productivity. 

One physician informed us that he would rather retire early than deal with an EHR; he professed loyalty to paper charts until the end. Some were enthusiastic about the evolution of technology in their practice and embraced it with gusto because their lives had been infused with use of computers, and they thought the benefits were clear.

Whatever the reaction, one common thread was that throughout physicians’ busy workdays of tending to patients’ health, not much thought was given to how the health information would be transferred. With Meaningful Use deadlines to meet, we worked on ensuring that patients’ smoking status was recorded, prescriptions were sent out, and cancer cases were reported to the state registry electronically.

When I used to send an email, I never pondered long on how it arrived at its destination. However, the process of sending health data to its various destinations got me interested in the transmission process. I wanted to learn more about the application layers needed to send an order and to receive a result.

Our program at the University of Texas covered a wide spectrum of topics related to health IT, from project management to medical practice business models. As I continued through the program, I found myself primarily drawn to working with the more technical aspects, such as learning about HL7 and SQL.

Upon my first introduction to HL7, it seemed simple enough. It’s the messaging standard that allows for interoperability among the healthcare applications and is the definition for how all healthcare information should be communicated. As a teacher, I was used to working with standards. We had to rigidly adhere to the TEKS standards and ensure that each lesson plan addressed a specific objective (Common Core for those of you outside of Texas). After a little more study, I soon began to see that HL7 isn’t quite as “standard” as I initially thought.

Working with HL7 seems to more closely resemble another former job of mine at a burger joint. The restaurant owners had defined their standard burger to include: mayo, mustard, tomato, onion, lettuce, and a beef patty, in that order. Unless otherwise specified, that was what the customer could count on receiving.

However, most customers needed some slight variation in their burger. Some wanted “repeating” pickles while others wanted the tomato completely removed. Customers could even have customized ingredients put on their burgers, such as kimchee or a fried egg, if the standard ingredients didn’t fit all of their needs. HL7 seems to resemble this “have it your way” model.   

Once I graduated from the Corepoint Health’s HL7 training and began working with customers, I got to see this great variety firsthand. Wes Rishel said, “When you have seen one HL7 interface, you’ve seen …one.” 

While HL7 is clearly an invaluable framework for getting the conversations between different systems started, there is such great variety between departments, institutions, and even among each EHR systems that there has to be some flexibility in the standard. Anyone with experience in filling out forms can see how uniformity issues easily exist: some forms require middle names, while others just want a middle initial; some want the area code in parentheses, others want 10 digits with no special characters.

This variety transfers over to how applications want their information. System A sends the home and cell phone in the same PID-13 field, but System B needs each number in a new instance of a repeating PID-13 field. Application X sends the attending doctor’s full name, but Application Z wants the last name and a corresponding code. Person 1 thinks “y’all” is a perfectly legitimate word, but Person 2 requires it be said as “you all.” The semantic variances among each system is easily comparable to the variances in our own language.

Once I became involved in helping make these modifications for customers, I was very focused on the specific details of HL7. Working with the standard, it’s easy to get caught up in the subcomponents and data types, the pipes and the hats.

These pieces of data need to be placed in PID-5-1 and PID-5-2, while this system needs each repeating OBX-5 field to be in a new OBX segment. It’s easy to forget that PID-5-1 contains the last name of an actual patient, and OBX-5 contains an actual lab result that could bring life or death information to that patient.

Ensuring that this information is communicated in the most efficient and effective way is an important task, and I’m glad to have entered the world of HL7. 

Related Blogs

Rhapsody Health Solutions Team

Glossary: Healthcare Interoperability Terms and Definitions

Find definitions of commonly used healthcare interoperability terms in this glossary.

Read more
Generative AI, semantic interoperability, precision medicine and other themes from HIMSS23

Evgueni Loukipoudis, Vice President of Research and Emerging Technologies

Generative AI, semantic interoperability, precision medicine, and other themes from HIMSS23

Read our key takeaways from HIMSS23, including perspectives on artificial intelligence, semantic interoperability, and patient matching.

Read more

Rhapsody Health Solutions Team

FHIR vs. HL7: We explain the key differences

This article offers a deep dive into the differences between HL7 and FHIR to help industry insiders and newcomers understand how healthcare standards have evolved over time and what’s on the horizon.

Read more