When interoperability was introduced, the thinking was that it would simplify everything and lead to a virtual integration of disparate applications. Technology would be plug and play, seamlessly and automatically working together. However, that has proven to not be the case. Although interoperability in essence seems simple, there is a lot that can go wrong with it, and it is a far cry from integration.
I compare the interoperability situation to what you might experience trying to connect a DVD player to a TV set. You need to have the right cable or your TV might not work. You might have an HDMI cable but if you have an older TV set that will only accept video, then you would need an old RGB video cable. Then you need to make sure you’re selecting the right video input on your TV and setting up the display correctly on the DVD player, making sure the DVD player is sending the right video and the TV is interpreting that video correctly. This is actually easy to do, as simplified directions are usually provided and you typically only need one cable, but you could potentially have any one of a number of things go wrong with it.
That’s very similar to how it is with setting up an interface (even using the HL7 “standard”) to send information to an EMR. You need to make sure you have all the data the receiving EMR needs and in the right format. You also need to know how the receiving EMR’s feed is set up (as even HL7 has many variations). An EMR may only accept one particular format, therefore you have to rectify that, which, depending on the software, requires someone to make a change on either the sender’s or receiving EMR’s end.
Once the information has been sent, you need someone to validate the data that is being received on the other side and censure that the data itself is correct, is in the correct format and is in the right place. Once that’s done, you need to test the communication a number of times. You have to make sure you’re always sending the right data and that the recipient is always receiving it correctly.
As you can see, that’s not plug and play. You can’t plug in one cable and then another, hit “on” and everything works. There are a whole bunch of steps that have to happen in between, and going through that process can take some time. Even with some of the better HL7 systems, there’s set up to be done and that’s for just one HL7 feed. Now, multiply that task by the number of different EMRs and recipients and it gets very complex. You can have the same information going to two different EMRs, but it needs to be sent in two different ways. It doesn’t matter who is sending or receiving, it just matters what they’ll accept. One EMR may only accept HL7 lab messages that have discrete data while another might receive a lab message with the same results but in non-discrete data. If you have the data as discrete data, it’s going to be sent as discrete data, but if your recipient only accepts non-discrete data, the info sent will be in a format they may not be able to capture.
Even though there’s an HL7 standard, EMR vendors provide their interpretation of the standard and tell you what they accept based on what version of HL7 they have. Some people may expect to see the doctor name in field 7 in the file, while others expect it in field 8 because that’s what they chose when they set up the feed. This adds further complexity to getting an interface up and running, and then there’s all the other interfaces you have for all the other vendors you’re working with. The set up process is not always the same each time. Sometimes you’ll get lucky and the data you are sending to one vendor is going to be the same going to another vendor. Most often, you will have to change what you’re doing or add or change information.
Looking at all the various complexities involved, you can see that integration is just not possible and even interoperability is difficult to chase. You have someone receiving data one way and then having to transform it into another format so that another can receive it. By having to do that, something always gets lost in the translation.
The hope was that HL7 and the standardization of communication would make interoperability simpler and more plug and play. But, instead, it’s created a new set of complexities. Your expectation is that an HL7 implementation is not going to be an all-day affair, but it can take weeks because of all the steps and various pieces in play. How long the steps actually take depends on how many resources each side has and coming to an agreement on how much time they should spend.
As technology gets smarter, there’s the hope that more of the interoperability process will become automated. However, if something goes wrong, there’s still going to be the question of where the problem is and what measures will need to be taken to rectify it. We are all relying on technology more and more to make our jobs easier and to deliver better patient care, and in many ways it’s doing that. We just need to get it to the point where trying to makes things easier takes up less time and is more fool-proof.
