If you are working in the Health Care industry you may have already heard about the HL7 standards or HL7 messages. If you are still not familiar with them, here is a list of things that you may need to know.
The HL7 standards were created to facilitate the electronic interchange of clinical data. The HL7 International organization is the one behind the definitions and is one of the biggest IT organizations in the world. This organization is in charge of the definition of many health care industry standards. A few of them include:
- HL7 Version 2.x Messaging Standard – an interoperability specification for health and medical transactions
- HL7 Version 3 Messaging Standard – an interoperability specification for health and medical transactions
- CDA (Clinical Document Architecture) – an exchange model for clinical documents, based on HL7 Version 3
- CCD (Continuity of Care Document) – a US specification for the exchange of medical summaries, based on CDA.
- SPL (Structured Product Labeling) – the published information that accompanies a medicine, based on HL7 Version 3
In this post I will focus on the HL7 Messaging Standard. In particular in Version 2 and why it is important.
Let’s take a quick look at the HL7 Standard
The last statistics from 2012 shows that 73% of hospitals in the U.S. were participating in data interchange with one or more Health Information Organizations and 48% of them had a basic Electronic Health Record.
58% of the hospitals were already electronically exchanging data with their providers. This represents a 48% of increase from 2008 statistics.
One of the biggest challenges to increasing hospital participating in data interchange efforts is that many hospitals already have their legacy systems with a non-standard definition of their EHR (Electronic Health Record), in other words they don’t share HL7 messages. Replacing systems in these cases is a significant project, which often takes considerable money and effort. Fortunately most of the middleware solutions currently available, like Microsoft BizTalk or IBM WebSphere, bring out of the box HL7 messages definitions. The only need from the legacy system is some interface to expose the messages in any format, making the translation to HL7 in the middleware, and exposing it to the other stakeholders, always preserving the security, consistency and ensuring the right message is delivered to the right receiver.
Why a middleware solution is the best approach for HL7 Messages?
Because HL7 messages can be very complex to understand, create or process from scratch. Building a custom solution to parse them can be challenging. For example, the BizTalk HL7 Accelerator already contains the HL7 message definitions, and the middleware gives the capability to transform those message to XML or map them to any other type of message your system is able to receive (XML, database entries, Web Service SOAP or REST messages, queues, and others). We have seen that a middleware approach to healthcare systems integration typically reduces development time by up to 70%.
Apart from the dramatic reduction in time and effort required to complete your integrations, healthcare enterprises can also take advantage of other capabilities of the middleware. Other capabilities include: business rules engines, message routing definitions based on their content, built in security, batching and de-batching and message monitoring among other features.
Interoperability of your systems is crucial to decrease your administrative costs, so implementing a middleware solution using tools like the Microsoft BizTalk HL7 Accelerator or the IBM WebSphere Message Broker Connectivity Pack for Healthcare, which have proved to require less effort with shorter times to spin up, will result in a long term ROI increases for your business.
Contact Art2link to learn in more detail how you achieve the highest possible levels of interoperability in the fastest time, for the lowest possible costs.
For mor information about HL7 click here – For more information about Healthcare click here.