Tip 8 in the Interoperability Tip Series
Critical Elements in an HL7 Interface Specification
These are critical elements a developer needs to create a interface that works (almost) out of the box with minimal testing. The more accurate the HL7 interface specification, the faster it’ll be implemented – and the less costly the work will be.
1. Interface name
How do you refer to your interface in your integration environment? Some organizations manage thousands of interfaces. If you’ve got 10 or 20 interfaces, no big deal. But if you’ve got thousands, devise a naming system for easy name recognition and tracking.
2. Source or destination system name and version
System versions (and even product names) change over time. Make sure you’ve got a way to track this in your spec.
3. Message types used in the interface
A message type is essentially a trigger event, such as patient admission, lab request, lab results available, new appointment, etc. How you use and implement events is completely up to you – it depends on your system and hospital workflow. Each of the HL7 v2.x reference specifications contain hundreds of trigger events. Just focus on the ones you need for your interface.
4. Message definitions including segments, fields, data types
You need a list of the segments, fields, and data types used in each message type.
5. Segment and field attributes
These are optionality, repeatability, data type associated with a field, field length, tables associated with field.
6. Z-segments
Custom segments, if a vendor or your facility uses them.
7. Data types
Apart from a list of data types, you will also need attributes and customizations.
8. HL7 tables with field and data type content
Within your HL7 interface specification, you need the real-world data or code sets that are actually implemented – such as gender, race, and lab codes – not what the standard provides. Otherwise you’ll find yourself wasting lots of time trying to figure out what’s really going on in your system, especially when data such as lab codes change over time. You can solve this problem by keeping track of the actual data and code sets used, along with where and how they’re used, and the meaning of the information.
9. Specialized interoperability challenges
Without getting all necessary information upfront, your challenges around interoperability become greater and more insurmountable. Consider lab interoperability and the example of Logical Observation Identifier Names and Codes (LOINC) codes – the LOINC dictionary contains more than 42,000 codes and some codes mean similar things. That means two systems exchanging data could refer to that data differently – leading to confusion and information-exchange problems. Read more about addressing the challenges of lab interoperability in this Clinical Innovation and Technology article: Lab Interoperability Plays Catch Up.