Blog

Why Document HL7 Profiles (or Specs)? Part 2

By margo.ellis@caristix.com | Published: August 27th, 2014

Tip 24 in the Interoperability Tip Series

Read Part 1 here

In our previous tip we asked: why document HL7 profiles and specs. In beginning to answer that question, we explained that profile documentation is critical for troubleshooting and maintenance.

Another benefit to documenting profiles is that it streamlines processes when you are performing a system upgrade. Let’s say you’re changing or upgrading your pharmacy system – that change affects the interface of any other system that communicates with the pharmacy system. Imagine ten different systems connect to your pharmacy system – you’d need to tweak those ten interfaces.

But you’re smart and you already documented the pharmacy system and the other systems through the use of profiles/specifications. That means all you need to do is create a new profile for the new/changed pharmacy system. Then when you redo the associated 10 interfaces, you will perform a new gap analysis, but the hard scoping work (those specs) will already be done.

Many people are using the canonical model as an intermediate layer to make this work easier in cases such as the example described above. For this, all pharmacy interfaces would be converted to an intermediate model (a profile) so that each system is loosely coupled. If one system changes, it’s easy to adapt the system so that the message is transformed to the canonical model.

Document your HL7 profiles and specs

Once your interfaces are in place, you want to monitor them to ensure they’re supporting your processes as designed. The value of monitoring is that it empowers you to be proactive in troubleshooting issues. You can set up thresholds and then be alerted to potential issues. For example, you could say that only a certain number of messages should pass through the system for a certain process and if that number is exceed, you get alerted.

Many interface engines include monitoring capabilities but some are limited to that particular engine. If that’s all that you have at your disposal, take advantage of it. But if you have the option and your environment includes multiple interface engines, look for vendor-agnostic solutions that cover the entire integration environment. That’s the easiest way to get a global overview of your environment.

Just remember – when you’re sharing data across your infrastructure, sometimes an HL7 message is the problem. But the network or a specific system could also be the problem. For example, perhaps a nurse is not seeing orders in the pharmacy system. This may be because the network is down. Or it could be an issue with the ADT system or with the medication admin system. Or one HL7 message could be holding up the queue. You want to be able to quickly eliminate the HL7 message as the issue. Just remember that ideally your monitoring should link back to your test cases and interface specifications.

Lifecycle Management Software

Check out Caristix Workgroup for a full interface lifecycle management suite (16-minute on-demand demo available). Workgroup helps by providing a way to document the canonical model (profile), each system model (profile) and transformation needed (click to enlarge).

Document your HL7 profiles and spec