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 Office of the National Coordinator for Health Information Technology (ONC) – Located within the Office of the Secretary for the U.S. Department of Health and Human Services (HHS), the Office of the National Coordinator (ONC) coordinates nationwide ..., 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 Electronic Health Record (EHR), as defined in Defining Key Health Information Technology Terms (The National Alliance for Health Information Technology, April 28, 2008): An electronic record of health-related information on an individual that conform... 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 is a Standards Developing Organization accredited by the American National Standards Institute (ANSI) to author consensus-based standards representing a board view from healthcare system stakeholders. HL7 has compiled a collection of message form... 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.Tags: Healthcare Interoperability, HL7