Wednesday, January 20, 2010

Troubleshooting HL7 Integration (Hard Code vs Integration Platforms)

As healthcare organizations such as hospitals and clinics are under more pressure to effectively manage and use their IT applications, much of this pressure is offset to those IT vendors tasked with supplying healthcare organizations with their IT applications.

With the introduction of National Electronic Patient Records (such as the AORTA system in the Netherlands) it turns out that IT suppliers often have little more than a few months to get their IT applications fully converted to the HL7 standard. So what are the options for IT vendors looking to adapt their applications quickly and cost-efficiently to the HL7 protocol? First let's look at the conventional hard-coding approach to integration:
Challenge 1: Become an HL7 Expert
First off, to manually adapt your healthcare application to the HL7 protocol you need to swat up and become fully versatile in all the bits and bytes of the HL7 protocol. This includes becoming familiar with all the various formats; from where you insert your healthcare patient's ID, to every field you need to pass or retrieve.
Challenge 2: Build a New Application Layer
Once these formats are fully understood, IT vendors then have to create a whole new layer to their existing healthcare applications. This layer must read and then extract the application data in the HL7 format, or vice versa. It would then have to embed that information into the existing application. Just incorporating the HL7 lingo into an existing application is by itself an IT project of significant magnitude.
Challenge 3: Future Maintenance
Every time the IT vendor updates, changes or modernizes their healthcare application, they also have to update and maintain the new HL7 layer. In an average appliation's life cycle, maintenance can use around 70% of the IT team's total work hours - this becomes a significant undertaking which of course entails greater costs to the vendor.
Challenge 4: Multiple HL7 Versions!
Also to consider are the various versions of the HL7 protocol - so ideally you would want to be as loosely coupled with the HL7 specifications - to allow for simple integration and organizational changes (whether its from the HL7 side or from the application end).
Integration Platforms such as the iBOLT integration suite can offer a number of advantages compared to hard coding:
Metadata engine - The iBOLT suite contains pre-compiled business logic that enables IT vendors and developers to bypass challenges 1 and 2. There's no need to learn the full HL7 format before you start, and no need to manually build and then maintain a seperate HL7 layer on top of the original application.
Graphical Studio and Wizards that enable IT teams to intuitively view and design their integration linkages. This makes the entire project easier to build and therefore easier to adapt to future demands (answering challenge 3). It also helps ensure that the entire project is loosely coupled - so the IT vendor can easily and cost-efficiently adapt to new HL7 standards (answering challenge 4) as and when they roll out.