Common HL7 Interface Implementation Issues

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?