A majority of clinical applications today have the ability to interface via HL7, or as we say, they can ‘speak’ HL7. The problem is that the HL7 standard is flexible, and it is typically customized by each vendor to fit the specific needs of their application. When you need to build an interface between two independent systems, it is helpful to know where to start and what information you should gather from each vendor to begin the project.
Ask For:
HL7 Specifications – Each vendor should be able to supply an inbound and outbound HL7 specification for their application. The quality of these documents will vary greatly from vendor to vendor. These documents will allow you to do a gap analysis (see below) between the two systems.
Sample Messages – Regardless of the quality of the specifications, sample ‘production’ messages are a real representation of the messages and data format that will be exchanged. You can use this sampling of HL7 integration messages to build and test the interface, if you are using an interface engine.
Connection Details – Most HL7 interfaces transmit data over TCP/IP. That being the case, it is important to get the IP address and port information where these applications will be transmitting or receiving messages. Other considerations are VPNs or file transfer protocols. Verifying and testing the communications layer earlier in the project will prove advantageous for all parties.
Contact Information – Make sure you get the names, phone numbers, and e-mail addresses for each vendor’s contacts. These contacts will be involved with the testing and development of the interface.
Ask About:
Communication and Workflow Details – It’s important to have an understanding of how each system will handle acknowledgement (ACK and NACK) messages. Under what circumstances would a receiver connection send back a negative acknowledgement (NACK), and in this situation how should the sender respond? Should the sender resend the same message, fail the message and continue sending the next message, fail the message and suspend sending, etc. These types of workflow questions need to be addressed so that you don’t run into issues in production that could have been avoided.
Develop:
Gap Analysis – Compare the HL7 specifications from the vendors and make note of the differences. Common problems include: 1) messages sent by one system but not supported by the receiving system, or 2) message format differences. The gap analysis will help you estimate the amount of work involved in interfacing the two systems.
Test Plan – Work with your vendors to develop a test plan. The test plan needs to be complete with a list of scenarios you want to walk through prior to considering the interface ready for production. The application’s critical path is a good place to start. Scenarios may be as simple as admitting, updating, and discharging a patient, or they may be more involved and include placing orders, canceling orders, receiving results, and updating or adding addendums to reports. Also, include communication testing scenarios. What happens if the network goes down between the applications? Do they recover automatically when the network comes back up?
Go-Live Plan – Have a plan and a schedule for the go-live of the interface. Check availability for all key players. Plus, consider the need for minor modifications during the process. Can those changes be made at the time of go-live?
For an HL7 Interface definition as well as others, HL7 Resources is a great place to find additional information.
Related posts:
- HL7 Specifications Defined
- How Do I Determine if HL7 Messages Are Conformant?
- What Is an ACK?
- ACK Message – Real World Scenario
- HL7 Engine Mapping
