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

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

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

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

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

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

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”

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

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

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

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

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

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

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?