subject: Plug And Play In Hl7 For Healthcare Solutions [print this page] HL7 plays a very important role in todays healthcare domains. HL7 solutions help healthcare industries to overcome the challenges that they usually face and also support all clinical as well as administrative electronic data exchange. This article shows how today IT industry commonly uses notion of plug and play. The idea for using this notion is to allow a software component to plug into one or more existing systems and play instantly or immediately.
HL7 plug and play in a health interfacing context suggests that an application that conforms to the standards of HL7 should be able to finish the installation into an existing environment of customer and also should inter operate faultlessly with other applications that exists.
Sad but this is not very true. Expectation from plug and play is fostered by everyday experiences considering other tools which we commonly use are increasingly plug and play. Examples of which are given below:
Mobile Phones( plug in a SIMM card and battery and then play on the phone by making calls)
USB memory key (plugs into the USB port on your desktop/PC and play by copying files to and from the memory key
Desktop or PC applications such as Virus scanning software (plug into your PC by a simple installation and immediately play by scanning for viruses and synchronizes with virus signature files with the help of a server on the other side of the world
Two HL7 standard based applications usually developed in HL7 solutions or HL7 software development are not plug and play might include reasons like:
When during HL7 software development vendors would implement various versions of HL7. Backwards compatibility is the general goal of most standards of HL7 that are used currently so the difference between versions of HL7 is the reason for causing problems.
Different interpretations and ambiguity in the standards of HL7 by the vendors also result into incompatibilities between implementations.
During the stage of HL7 software development, the design of a particular application means that due to certain application architecture requirements effect the interface of HL7.
Customer needs are not met exactly to HL7. Examples of them are given below:
The standard HL7 messages for which do not exist and application events for them
Particular application that uses data items cares is not explicitly captured in a particular HL7 segment
A method for which addition of additional data items are added to existing messages of HL7
Use of HL7 Z segments - data items in use in a particular application that care not explicitly captured in a particular HL7 segment
Well various approaches can be used to mitigate interface compatibility issues despite non-existence of silver bullet of HL7 interface plug and play and it includes:
Planning as well as testing of HL7 for identifying issues and to ensure their resolution.
To mask differences between application interfaces use of an interface engine can be done
Expecting for a big change in interface standards like the V3 or Open HER which can magically solve compatibility issues often caused in interface.
