by Rahul Bhagat
Synchronous and Asynchronous Communication
There can be two types of communication between integrated systems - synchronous and asynchronous.
Synchronous communication takes place just like a conversation. It happens in real time and uses the request/response model. One system will ask a question and the other system will respond with an answer. It is like making a phone call. You pick up the phone, dial the number, and say hello. Then you wait for the other end to respond.
Asynchronous communication is more like a text message. You type and send the message and get on with whatever else you were doing. You are not waiting for the other person to respond. This is a better and more efficient way to deal with situations where having the information immediately is not necessary.
Imagine a person showing up at the registration desk of a hospital. He has been feeling a tingling sensation in his feet that keeps coming back and he would like to see a doctor. The registration clerk asks for the man’s information, including his insurance information, and creates a patient record. The next step is confirmation with the insurer before an appointment is scheduled with the doctor. This step is a perfect candidate for using synchronous communication to integrate the hospital system with the insurance company’s system. It is necessary for the hospital system to confirm insurance details before an appointment is scheduled.
Well, finally the man gets to see the doctor. It could be nothing. But the doctor notices that he is overweight. He also has high blood pressure, and there are blisters on his feet. This gets the doctor concerned and she orders a blood test for sugar level and A1C to check if the patient has diabetes.
Here the synchronous communication method to integrate the hospital system with the lab system will not work. Blood has to be drawn, labeled, and shipped to the lab. This will take time. The order can be sent electronically immediately but neither the hospital system nor the lab system will, or should, keep waiting till the test results are available. This is where asynchronous communication is used to integrate systems.
Connection
How systems are physically connected is another important topic in integration. If there are only two systems, then there is no issue. You can connect them directly - point A to point B. This is a point-to-point connection.
A point-to-point connection works fine as long as the number of systems to be connected is low. And by low, we mean two or three. Anything higher and it starts becoming a serious issue. How? Read on.
For a system to be able to send messages to every other system on the network, it has to have a connection to every other system. To connect two systems, we only need a single connection between them. With three systems (A, B, and C), we will need three connections - A to B, B to C, and C to A.
For four systems, the number of connection jumps to six. For five it is ten, six systems require fifteen connections and… ten systems require forty-five connections!
I did not have to manually count the number of connections for ten systems because there is a mathematical formula for it. Number of connections = [(n/2) * (n-1)] where n is the number of systems. No matter how much you hate them, formulas have their usefulness.
You can see how this problem seriously limits the number of systems we can have in a network.
Well, it was not the first time we faced this problem. Transportation systems faced this issue long before computers and they solved it with the help of the hub-and-spoke model.
Delta Airlines pioneered the hub-and-spoke model back in the 1950s. Their merger with Chicago and Southern Airlines meant they had to create a network that integrated many more cities. They did this by coming up with the idea of an airline hub in Atlanta. One set of planes would ferry passengers to Atlanta and another to the final destination. Today, almost all airlines operate on this model, although, there are exceptions like SouthWest Airlines, which only flies point-to-point.
The company that really turned this model into an art was FedEx. To guarantee overnight package delivery, not only between San Francisco and New York City but also between Albany and El Paso, they set up a central clearinghouse in Memphis (their hub) and implemented the hub and spoke model for overnight package delivery.
All overnight packages are flown from various destinations to Memphis where incoming packages are sorted with the help of a high-tech conveyor belt system. The sorting is done within a four-hour window according to the destination location and at 2:50 AM, the first plane leaves Memphis for its destination. For the next hour (probably longer now) a plane takes off every minute to another destination. I would love to watch this symphony of modern age. Someday, maybe.
The hub-and-spoke model solved the problem of exponentially increasing connections in computer systems by using a hub in the network. If A wanted to send a message to Z, it sent that message to the hub, which in turn passed it on to Z. This way, the number of connections was equal to the number of systems. In other words, to connect ten systems, we only needed ten connections.
Publish-Subscribe Model
Using a hub to connect systems has other advantages. One such advantage is optimization of message generation from the source system to the destination.
Consider the case where system A has to send messages to systems B and Z. One option is that system A creates two identical copies of each message and sends one to B and the other one to Z. Under a different approach, system A creates only one message and sends it to the hub. Other systems that want to receive messages from A let the hub know that.
So, when the hub receives a message from A, it checks its instructions and notes that systems B and Z want to receive messages from A. It then creates two copies of the message and sends them to both the destination systems.
This is the publish-subscribe model of message routing. It not only reduces the number of messages and traffic on the network, it also frees up sending systems (like A) from having to keep track of who wants to receive what. This becomes the job of the hub.
The hub is very important in integration. You must have come across software like eGate, BizTalk, or Rhapsody. They are a class of software products called integration engines. At their heart, these products are hubs which route messages between systems on the network.
Message Triggers
Message triggers are real-life events that trigger generation of a message by a system. There are two situations.
One, it can be a service request. This is the request/ response model we discussed in the section on synchronous communication. For example, a doctor’s office makes a service request to the lab system for an old test result. The lab system responds with a message that contains details of the old test result.
The second situation is event notification. Here a real world event triggers automatic generation of a message. For example, the lab system will generate an event-notification message when the result of a new test becomes available. Ordering systems don’t have to keep asking if the result is available.
Scope of HL7
System integration is a vast topic. HL7 only occupies a small niche in healthcare system integration and exchange of healthcare data.
Even within healthcare system integration, HL7 doesn’t set the standard for everything. If you divide it broadly, there are three standards that are required for integration: a message-transfer standard (how a message will be sent), a message-format standard (what a message will look like), and a data standard (how healthcare information will be organized in a message).
We saw in the last chapter how the Internet and TCP/IP protocol can be used to send messages between applications. HL7 does not reinvent the wheel. It leaves message-transfer standard to implementers. They can either use the Internet and TCP/IP or a dedicated network and their own custom protocol. HL7 doesn’t care.
What HL7 does care about and defines standards for, are the message-format standards and data standards.
Message Format Standard
The message-format standard defines the structure of a messa
ge so that the receiving system can make sense of its content. If the data is not organized in a standard way then the system won’t know where to look for it in the message. In that case, along with the message, the sending system will also have to send information about where to look for data and what each value means. That will be a very inefficient way of communicating.
If the same were true in our everyday life, then every speed limit sign on the highway will have to be a large descriptive board. This will be required because instead of just saying “Max 100 km/hr.”, it will have to say, “The vehicle you are operating on this stretch of the highway is not allowed to exceed the speed limit of 100 km per hour. This is against the law and if you are caught you will be penalized.”
The point is, with a standard message format, you can have a short, to-the-point message, which is understood by everyone.
By defining a standard-message format, HL7 allows clinical systems to exchange short messages without them having to grapple with explaining the meaning of each field, every time they send a message.
Data Standard
Data standards deal with how information is represented in a message. It might seem like a simple thing but real tragedies have occurred because we mixed up the measuring unit (remember Mars orbiter?). By defining a comprehensive data standard, HL7 ensures that there is no ambiguity in the information that is shared between systems.
To illustrate, let’s consider the simple example of the patient name field. A hospital system stores a patient’s name in three different fields: first name, middle name and last name. In contrast, a lab system stores the patient’s name in just one field with space between each part of the name.
These two systems cannot be integrated unless they agree on a common data standard. If the hospital sends the patient’s name as is, the lab system will need an extra layer of software to stitch the name fields together and then save it to its database. And a patient’s name is just one field. There could be thirty or forty fields in a message. Can you imagine the enormity of work involved in reconciling those fields? It would be a nightmare.
HL7 solves the problem by defining standard data format. If two systems want to integrate, then both of them will have to use the HL7 data standard for messaging. This way there will be no ambiguity with field content and there will be no need to undergo the laborious process of reconciling fields every time two systems are integrated.
4. Evolution of HL7
We live in a world of standards. As new technologies emerge, a necessary condition for their wide adoption is standardization. We notice it when there is a problem with the standard. As must be evident to anyone in a foreign country not able to plug in a laptop because the power outlet is different.
Standards emerge from different sources. A standard could be imposed by the government, as was the case with the conversion from the imperial to the metric system of measurement. Both the USA and Canada started the conversion but in the States, the government defunded the Metric Board, stalling their conversion. In Canada however, the conversion was completed and we started measuring distance in kilometers and temperature in Celsius.
Another source of standard is the industry itself. Companies at the forefront of a new technology vie for competitive advantage by promoting adoption of their technology. We have all heard about the famous videotape standards battle between Betamax and VHS. Sony’s Betamax was a superior technology but VHS became the standard because JVC was relentless in promoting it to electronics manufacturers.
A third source of standard is market forces, which leads to a de-facto standard. This was the case with TCP/IP. It became the dominant, and ultimately standard, network-communication protocol as a result of gradual adoption by universities and businesses. By the time the ISO model was developed, it was too late for a switchover. TCP/IP was already baked in.
And finally, there is the deliberate approach where experts get together with the specific intent of creating a standard. This is how the HL7 standard came into being.
Development of HL7
The story of HL7 started in 1987. An international group of experts got together to work on the problem and created a rudimentary version of what we know today as HL7. It had many gaps and was not detailed enough for practical use, but it got the ball rolling.
A dedicated, not for profit organization called Health Level Seven International was founded to manage ongoing development of the standard.
The organization is completely volunteer driven. It draws its members from healthcare providers, vendors, consultants, government groups and others who have an interest in the development of standards.
Within a couple of years of its formation, it had the first usable version of HL7 (v2.1) ready, which was released in 1990. This was followed by a revised version (v 2.2) in 1994.
Industry adoption of HL7 was not very successful initially, but the user base kept growing slowly. The turning point came in 1997 when version 2.3 was released. This version was ANSI approved which signaled to the industry that the standard was robust and mature.
ANSI approval was like a shot in the arm for HL7. Adoption accelerated and picked up further pace with the release of version 2.3.1 in 1999. This led to much broader market recognition, wider industry adoption, and eventually to the current status as the dominant industry standard for the exchange of clinical and administrative health information.
ANSI (American National Standards Institute)
ANSI is a private, not-for-profit organization in the United States, which facilitates, coordinates and oversees standards development activities. ANSI itself doesn’t develop any standard, it only defines guidelines and a process for standard development. If another organization, like HL7, follows the guidelines and process to develop its standard then it gets ANSI approval.
The ANSI process is a consensus-driven standard development process. The idea is to ensure that no single party dominates and every interested party has an opportunity to voice its opinion. It also requires standard development to be conducted in an open environment under public scrutiny.
ANSI approval is granted for five years with an additional five years extension if requested. At the end of the approval period, the standard is reviewed to determine if it should be reapproved, revised, or withdrawn.
HL7 Organizational Structure
A board of directors, composed of elected and appointed members, oversees the development of HL7 standard. The organization also has numerous technical committees and special interest groups (SIG), made entirely of volunteers. They are the ones who develop and revise the standards. Each technical committee or SIG has two or more co-chairs who manage the work within the group. Together, co-chairs from all the groups form the Technical Steering Committee, which is the clearinghouse for new and revised standards. Once the Technical Steering Committee votes and agrees to a new standard, it is sent to the board of directors, which makes the final decision on releasing the standard to general audience.
Anyone can volunteer and get involved in the development of HL7 standards. All one needs to do is become a member of HL7.org or its affiliate (if outside the USA) and then register with one of the active work groups.
Versions of HL7
Since the release of the first version of HL7 in 1987, the organization has made regular revisions of the standard.
With each new version, the standard has been improved by adding new rules, modifying existing rules, or by finding solutions to issues raised by the implementers. It has also been necessary to ensure that each new version is backward compatible. In other words, a new version is able to communicate with systems using older versions of the standard.
Backward compatibility adds a lot of legacy burden and makes it much more difficult to improve a standard. We saw what a quirky task it is with the release of Windows 8. Users of Windows operating system were used to the start button to run applications. When Windows 8 came out with a revamped user interface where instead of using the start button, users w
ere presented with tiles to run the applications, all hell broke loose. Microsoft had to quickly release version 8.1 and bring back the start button to keep its customer base happy.
Similarly, HL7 has had to ensure that with each new version, the old structure and format is not disturbed. Version 2.1 of HL7 was the first implementable version and since its release there has been eight revisions of the standard: v2.2, v2.3, v2.3.1, v2.4, v.2.5, v2.5.1, v2.6 and v2.7. Of these, HL7 v2.3 and v2.3.1 are the most widely implemented versions. They account for over three quarters of all HL7 messages.
All versions are compatible with each other. If an older-version message is sent to a system using a new version, the system will still be able to read the message. Similarly, a system compatible with an older version will be able to read a newer version message by ignoring additional features present in the message.
But there are serious problems with this approach. To maintain backward compatibility, HL7 has had to leave many attributes optional and allow a lot of room for customization. This has prompted some to even call HL7 a non-standard standard. The problem is that you cannot just send an HL7 message to any system. Every time two systems need to communicate, a unique HL7 interface has to be created with all the options and customization involved.
HL7 Version 3
To address these issues, it became necessary to break from the past and build a standard from the ground up. The result is HL7 v3.0, which was first released in 2005. The version number no longer changes with this new form of HL7, but it is revised annually. HL7 v3.0 exists alongside HL7 v2.x but they are not compatible. Incompatibility between v2.x and v3.0 means that systems implementing v3.0 interfaces will not be able to communicate with systems implementing v2.x messages. Although not impossible, it takes considerable time and effort to convert v2.x messages to v3.0 and because of that, the adoption of v3.0 is still very low.
