1. Common HL7 Interface Implementation Issues
Merlin Griscowsky
Managing Partner - Tekmerion Consulting

2. Addressing the Interpretive Elements of the Standard
HL7 is NOT a plug and play standard, nor was it intended to be
The use of various data elements and the recognition of trigger events varies greatly by site
Many data elements in HL7 are left to the implementing site to define and some trigger events can be implemented in multiple ways without violating the standard
“This field contains site-specific values that identify the Refer to user-defined table ... for suggested values.”
A09 and A10 trigger events can signify three different scenarios. Only one needs to be supported for adherence

3. Addressing the Interpretive Elements of the Standard
Strategies:
Meet directly with clients to understand how they use data elements. Don’t rely on database field names to map to HL7 fields
Identify the trigger events in your organization that HL7 must support and then ensure applications handle them appropriately. Don’t “force” your business onto the application

4. Interface Engines
Interface Engines are useful tools for formatting messages and routing them between messaging partners
Interface Engine use can require special training and infrastructures
Interface Engines can become the means to degrade the reusability of HL7 messages to virtual point to point interfaces through message customization
Interface Engines require maintenance and support

5. Interface Engines Strategies:
evaluate your environment before deciding to use an Interface Engine. Look at:
the number of applications being interfaced and how likely that is to grow
the robustness required of your interface
whether the interface is real time or batch
your ability to support an Interface Engine
if using an Interface Engine, consider defining and enforcing a set of organizational HL7 message standards

6. Replacing Human “Interface Engines”
When replacing non-electronic data flows with an HL7 interface, incorporating all of the value-add functions performed on the data is a challenge
Many individuals may take part in the flow of information without knowing the entire process or even where they fit in the process
Managers usually think they know the process, but they often don’t

7. Replacing Human “Interface Engines”
Strategies:
Ensure analysis has taken place that traces the flow of information from its source system through all its paths to the receiving system
Talk to the people that actually handle the data, not only their managers
Be persistent in your analysis, people often don’t report things they feel are “obvious”

8. Vendor Capabilities and Experience
Every software vendor in Healthcare has a product that is HL7 compliant, even though there is no formal means of measuring compliance
Few HL7 implementations are successful without the direct assistance of vendor expertise
Vendors should be able to demonstrate that their system meets your requirements
Applications should be designed for maximum flexibility and configuration, with custom data manipulation possible

9. Vendor Capabilities and Experience
Strategies:
request written HL7 specifications as part of the RFI/RFP or system evaluation process
take the time to talk to other organizations that have implemented the same release of the interface
arrange for demonstrations of the application interface based on your data and trigger event requirements

10. Project Risks
Implementing an Interface between two stable applications is the ideal environment - between two new applications is the riskiest
Interface projects always have dependencies that are outside of the project team’s control
Applications don’t always behave the same through an HL7 interface as they do through a User interface

11. Project Risks Strategies:
Test against business requirements, not just system capabilities, and don’t underestimate the time that will be required
Identify your dependencies as early as possible both within your project and to those you depend on - increase your contingency on these items
Try to ensure applications are functioning independently as required by the organization before interfacing them

12. Who Owns This Thing? HL7 Interfaces have no front-end users
HL7 Interfaces, especially those between multiple applications, have no clear owner
Maintenance and support of shared data elements can be complex
The IT department can often be left with responsibility it should not have for components of the Interface

13. Who Owns This Thing? Strategies:
Identify systems that “create” data elements as the owners of those elements - responsible for ensuring they are maintained between all systems
The IT department should avoid taking ownership over any data elements - the Interface is the medium over which information travels, not an evaluator of that information
Each client department should have its own Interface configuration expert for their system

14. Questions
Describe the HL7 interface you have implemented or are considering implementing:
What interpretive elements need to be defined?
What business processes need to be better understood?
Will you need an Interface Engine, and why?
Do you know how capable your vendor is?
What external dependencies does your Interface project have?
Who will support the data elements once the Interface is complete?