2 Addressing the Interpretive Elements of the Standard HL7 is NOT a plug and play standard, nor was it intended to beThe use of various data elements and the recognition of trigger events varies greatly by siteMany 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 fieldsIdentify 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 EnginesInterface Engines are useful tools for formatting messages and routing them between messaging partnersInterface Engine use can require special training and infrastructuresInterface Engines can become the means to degrade the reusability of HL7 messages to virtual point to point interfaces through message customizationInterface 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 growthe robustness required of your interfacewhether the interface is real time or batchyour ability to support an Interface Engineif 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 challengeMany individuals may take part in the flow of information without knowing the entire process or even where they fit in the processManagers 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 systemTalk to the people that actually handle the data, not only their managersBe 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 complianceFew HL7 implementations are successful without the direct assistance of vendor expertiseVendors should be able to demonstrate that their system meets your requirementsApplications 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 processtake the time to talk to other organizations that have implemented the same release of the interfacearrange for demonstrations of the application interface based on your data and trigger event requirements
10 Project RisksImplementing an Interface between two stable applications is the ideal environment - between two new applications is the riskiestInterface projects always have dependencies that are outside of the project team’s controlApplications 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 requiredIdentify your dependencies as early as possible both within your project and to those you depend on - increase your contingency on these itemsTry 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 ownerMaintenance and support of shared data elements can be complexThe 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 systemsThe IT department should avoid taking ownership over any data elements - the Interface is the medium over which information travels, not an evaluator of that informationEach client department should have its own Interface configuration expert for their system
14 QuestionsDescribe 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?
Your consent to our cookies if you continue to use this website.