Unlike many other standard protocols, HL7 is not really plug-and-play. For historical reasons, each vendor implements HL7 messages in slightly different ways. As a result, if you design your HL7 interface yourself, you will have to modify the HL7 parser and the application for each new installation.
The following table explains why HL7 is not plug-and-play:
| Reason | Description |
|---|---|
| Missing Fields | Some vendors tend to omit fields in the message instead of leaving them empty. This will change the number of every subsequent field from the start of the message. |
| Same Data in Different Fields | The same information may be located in other fields - and even in different segments - in various HL7 implementations. |
| Same Data in Different Formats | The same data may be provided in different formats. For example, timestamp information should appear as 19991231100000.000, but some vendors divide the date and time into different sub-fields: 19991231^100000.000. This is only one example of the possible mis-formats. |
| Different Versions | The existence of a number of different versions allows data exchange only between applications that support the same version of HL7. |
| Missing Values (including mandatory fields) | Although the standard requires only a limited set of values to be present (95 percent of the fields are optional), some vendors omit even those with required values. |
| Invalid Segment Grammar | There is a lack of adherence to the segment grammar that is required by the standard. Some expected segments may be missing, while other unexpected segments may appear. |
In this environment, it is important to be equipped with tools that deal with the diversity of HL7 implementations, standards and versions.