The first five chapters of this Survival Guide have helped you think strategically about your interfacing project. Now we’re going to dive into the nitty-gritty of what you need in an interface specification and/or HL7 profile (note: we use the terms specification, conformance profile, and profile interchangeably in this chapter).
An HL7 interface specification should list:
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.
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
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 (i.e., what we outline in this chapter), 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.
Spec = Interface Requirements
Combine the elements above with any necessary clinical or workflow constraints. This becomes your specification or profile, which is the key interface artifact you need as you can use this document to compile and validate requirements. Make sure internal customers and vendors see this. And ask tough questions (including the ones we supplied in chapters 4 and 5) as you review this spec so you can pin down the right answers for your environment.
Leverage your interface specifications (and other interfacing artifacts) to generate your interface code. In most cases, the spec is delivered as a Word document so look for tools that will help you connect the spec directly to your interface engine.
How to Develop an HL7 Conformance Profile
To build a profile, you have several options.
Messaging Workbench available via HL7 International (look for a file name that includes “MWB release”) is open-source software designed to build conformance profiles. But keep in mind, with Messaging Workbench you need to build out individual profiles for each message type. If you define 10 message types for an interface, you’ll be building 10 separate profiles. You’ll also have to read through messages to get the information you need.
You can also develop templates in Excel or Word and then populate them manually. Or you can take advantage of functionality in Caristix software that automatically creates profiles from HL7 messages. In our world, a profile corresponds to the spec for a source or destination system, with however many message types you need.
Regardless of how you develop a profile, you need to do it. The problem is that there’s no industry-standard template available. That’s why we’ve developed this HL7 profile template kit and made it available to you for download. With it, you can avoid the time and effort to set one up, and make sure you clearly and concisely communicate what your integration environment expects in terms of data exchange. Feel free to download the template and tweak it to suit your needs.
Why You Need a Conformance Profile
- Gets analysts, developers, internal customers, vendors, and consultants on the same page
- Helps identify risks before interface development
- Eliminates time spent determining requirements, testing, and on trial and error during go-live
- Makes it possible to easily generate your HL7 interface specification, gap analysis report, and test and validation plan
The Dangers of a Missing Interface Specification
Without an interface spec customized to your requirements, you’ll be stuck implementing a generic interface. If your organization is like most, your clinical resources are already stretched thin – and the last thing you can afford is to dedicate those resources to testing. But that’s what you’ll find yourself doing if you go with a generic spec. After all, your interface will likely be buggy when it goes live because your true requirements weren’t gathered up-front. As a result, you’ll find yourself bogged down with extensive troubleshooting after go-live, especially when you run into issues with clinical workflows because the interface doesn’t work as expected and clinicians report a lack of data, orders, lab results, and/or medication as a result.
Don’t take any chances – create those profiles. Get started with our HL7 Profile Kit.
Your Feedback Welcome
We’ll be publishing chapters from the HL7 Survival Guide over the upcoming weeks and months. See a topic that needs more detail? Have a different perspective on interfacing and interoperability? Tell us in the comments!
Read More in the HL7 Survival Guide
Chapter 1: How to Integrate and Exchange Healthcare Data
Chapter 2: Pros and Cons of Interfacing Capabilities
Chapter 3: The Heart of the Matter: Data Formats, Workflows, and Meaning
Chapter 4: How to Work with Vendors and Developing Your EHR Strategy
Chapter 5: Vendors, Consultants, and HL7 Interface Specifications
Chapter 6: Interfacing Artifacts: HL7 Conformance Profiles or Interface Specifications
Chapter 7: Interfacing Artifacts: Gap Analysis
Chapter 8: Interfacing Artifacts: Test Scenarios and Test Systems
Chapter 9: Interfacing Artifacts: Message Samples and Test Messages
Chapter 10: Process and Workflow
Chapter 11: Maintenance, Troubleshooting, and Monitoring
Chapter 12: Definitions
Chapter 13: Contributors and Resources