Extracting Maximum Value from Your Artifacts

Tip 25 in the Interoperability Tip SeriesExtracting maximum value from your artifacts

This is our last tip in the Interoperability Tip Series. Read the entire series here.

The fact is that the value of your interface-related artifacts increases over time. While they’re useful for development and go-live, they are essential down the road, in a year or two or more. Follow the 4 best practices for extracting maximum value from your artifacts and get the most from them.

1. Work with real-world messages.

When you’re developing deliverables such as profiles, it’s important to start with real-world messages for reasons we covered earlier on HL7 interface specifications. You will refer back to these deliverables over and over throughout the interface life cycle. If you start with placeholders or fictitious information, you’ll struggle when it comes time to troubleshoot issues.

2. Share your work. Share your artifacts.

Encourage diligence in documenting all aspects of your interface project. Consider a common scenario – the interface project wraps up and a key analyst or engineer leaves your organization. You want the new employee to be able to easily take over for the departing employee. And that means having all related documentation on hand. This practice helps in another way: by documenting what changes have been made to the interface over time, it’s much easier to quickly troubleshoot any issue. And keep an on-going to-do list, especially around gap analysis as this will help you better approach maintenance tasks. Make it easy for people to share their work and documentation. Use SharePoint, or look for collaboration functionality in the software you purchase.

3. Archive your work.

Upgrades and updates to the interface engine will happen. You don’t want to get stuck being the victim of Frozen Interface Syndrome, which occurs when you are trying to implement a new interface and need all participants to switch over at the same time but can’t get their cooperation. You also want to avoid Black Box Syndrome, when you lack full visibility into all the work that has gone into interface development handled by a third party, making it nearly impossible to upgrade, tweak, and manage the interface without spending lots of money and time. Don’t make the mistake of thinking you won’t need certain documentation in the future. In fact, you’ll probably re-use it for your next project or for an interface or system update.

4. Understand content management.

Effective documentation requires that you think beyond message structure and troubleshooting. You need to think about clinical content and how it changes over time. For example, lab orders have their own codes and these codes get updated over time. You want ready access to the most up-to-date list as needed. And you need them reflected in your HL7 tables. That means you need to plan from the start how you’ll map the code sets to the right fields and build that into your interface and the system at go-live.

Lifecycle Management Software

Check out Caristix Workgroup for a full interface lifecycle management suite (16-minute on-demand demo available).

Why Document HL7 Profiles (or Specs)? Part 2

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

Why Document Your HL7 Profiles and Specs? Part 1

Tip 23 in the Interoperability Tip Series

The last few tips have been about what to document and how to document. This one and the next explain why documenting your HL7 profiles and specs is so important.

When you document your HL7 profiles and specs, you can much more easily troubleshoot issues and tweak configuration once your interface is live. Plus, if you created electronic – i.e., machine readable – versions of your profiles, you can use them in your monitoring. For example, you could shoot a message through a profile using the Caristix Message Player to see if there’s anything anomalous, such as an extra segment or a field that is too long. Or you could run problematic messages against the test scenarios you developed during the validation phase of the interface lifecycle.

All that’s good and well but no one can use your profiles and spec unless they’re readily available. So be sure to store them in a central repository for your support team. Make the files read-only if necessary. What’s important is that anyone can quickly access them when needed.

By using the assets you built in the earlier phases of the interface lifecycle, you can quickly and proactively address issues and avoid additional costs. Plus you can keep users happy. Imagine rapidly troubleshooting an issue to avoid downtime rather than forcing clinicians to log a help desk ticket because the interface went down.

Lifecycle Management Software

Check out Caristix Workgroup for a full interface lifecycle management suite (16-minute on-demand demo available).

Document Your HL7 Profiles and SpecsUse Workgroup to do the message/profile validation. Pick a profile from the library and a set of message. Run the validation and a list of errors/warnings will be displayed (click to enlarge).

Managing Interoperability and Interfacing Assets

Tip 22 in the Interoperability Tip Series

Managing Interoperability and Interfacing Assets

In the previous tip, we talked about documenting your interfaces and workflows – especially important for HIE organizations. This tip is all about our recommendations for what to look for when you’re planning out how to organize your assets – documentation, requirements, test scenarios, and the rest.

4 Capabilities to Seek Out

  • Visualize all of your interoperability assets, from multiple interface engines to the interfaces themselves.
  • Cover the entire interface lifecycle.
  • Access a library of interfacing assets and manage assets so you can take an instant inventory.
  • And it should provide all this regardless of the interface engine you’re using

Tips for Artifact Management

Interfacing artifacts can grow over time. You maintain two profiles for your source and destination system. You conduct a gap analysis and your engine handles message transformation. But message transformation is part of workflow. You need test plans and test data. Keep all these artifacts together and include workflow. As you develop and implement interfaces, these can grow. In terms of managing interoperability and interfacing assets, you should keep them in a central repository.

Caristix Resources

Track assets using our Interface Asset Template. 

Consider Caristix Workgroup software when you need to share these assets across a team.View the 16-minute on-demand demo.

 

Documenting Interfaces and Workflows for HIEs

Tip 21 in the Interoperability Tip Series

Documenting Interfaces and Workflows for HIEs

This tip is especially relevant for Healthcare Information Exchanges (HIEs), regardless of whether your exchange is internal to an IDN or if it connects multiple regional stakeholders from community hospitals to physician practices.

Some interface engines let you view workflow within the engine. But what happens with external systems, such as an HIE transmitting to an internal engine, or multiple systems from different providers connecting across a region? Keeping track of workflow is a major issue in interoperability. You need a way to do this outside of the engine when documenting interfaces and workflows for HIEs and other multi-stakeholder organizations.

While you can track interfaces and workflow to some extent with spreadsheets, and can use a tool like Visio to diagram it all out, you ultimately need a tool that maps process and workflow. Such a tool lets you truly grasp your data and interfaces – not just your interface engine plumbing.

In our next tip, we’ll cover what to look for when you’re documenting and tracking your assets.

Download the HL7 Survival Guide

Download the HL7 Survival Guide

Interfacing Workflows: Start with a Spreadsheet?

Tip 20 in the Interoperability Tip Series

Interfacing workflows spreadsheetsIn our previous tip, we explained why you need to map processes and workflows. Many developers list their interfaces and workflows in a spreadsheet. You’ll find examples of what to track in the HL7 Interface Asset Template here.

While a spreadsheet provides a good start, you need to go beyond to capture the details and interconnections to capture a complete picture of your interfacing workflows. After all, in most hospital and HIE environments, you’ll be dealing with multiple workflows and systems, meaning your systems will be exchanging different sets of data. To efficiently and accurately test and manage all of this over the interface lifecycle, you need a clear mapping of workflows and processes – something that’s nearly impossible to capture in a spreadsheet.

Here’s what you should capture when documenting your interfaces and workflows:

  • Interface names
  • Systems that are linked
  • Connection information (IP address, credentials, port, connection type, location (location may be by unit or by data center)
  • Security: SSL, VPN, firewalls, and any required certificates.
  • Trigger events: List all trigger events and note which ones are used by which systems based on your spec.
  • Connection types: could include database, web service, TCP, HTTP, file, FTP.

Note: here’s why it may make sense to note the data center location. Let’s say you run systems out of two data centers for redundancy, one in Skokie, IL and the other in Hyde Park, IL. If your Skokie, IL data center experiences failures, but your Hyde Park data center is still operating, you’ll know it makes sense to start your troubleshooting in Skokie.

Consider one workflow in which data entered through an interface is first pushed to a database, then to an external system through a web service, and finally to archives or an enterprise warehouse. Without a diagram of this workflow, it’s difficult – if not impossible – to track the data flow. Four months after deploying your interface, you may find that no data has been pushed to the archives.

 Get the Interface Asset Template

Why You Need to Map Processes and Workflows

Tip 19 in the Interoperability Tip Series

dOCUMENT FILEThroughout the Interoperability Tip Series, we’ve stressed the need to complement the message structure and and content details from HL7 profiles with good process and workflow maps for future interfacing asset management. Earlier in the Interoperability Tip Series, Tip 4 emphasized the importance of mapping out the message process and workflow from the very beginning to kick off the planning of an interoperability project.

If you’ve documented your systems and taken the time to map processes and workflows,  it’ll be easier to connect the next system because you won’t need to start from scratch. Workflows also impact your test plan. For instance, all your destination systems might require different inputs from a single source system. As part of your scoping and requirements planning, you’ll need to understand the workflow – for instance, who does what: a physician, a nurse, or a pharmacist? Capturing workflow is also critical for network monitoring down the road so, for example, your IT team will know right away when a system goes down what workflows and processes are affected.

Lifecycle Management Software

Check out Caristix Workgroup for a full interface lifecycle management suite (16-minute on-demand demo available).

HL7 Messages – Don’t Fall into the Beginner’s Trap

Tip 18 in the Interoperability Series

What’s The Big Deal?HL7 messages - beginner's trap

If you’re just getting your feet wet with clinical and medical applications, you might think: “What’s the big deal? I’ll just hit Google for some sample HL7 messages and get started that way.” 

Don’t do that! If you do, you’ll get some basic structures right – like pipes and carets. But you won’t have any information about the interface you’re trying to build: the message types it uses, the segments and fields, positions, optionality. Yet developers need the information in messages in order to build a solid set of requirements for the actual interface. That’s why real-world messages are the best option.

For instance, let’s say that you’re interfacing with a lab system. The lab is often the area with the largest number of custom data values. After all, how you treat a lab order and lab results varies by hospital and by vendor. To develop a viable interface, you need to work with realistic messages.

At the same time, many hospitals employ email security measures that block the sending of any emails containing HL7-formatted content – even if it is de-identified. So whatever you find on the Internet is likely to be so generic that it will be practically useless.

Lifecycle Management Software

Check out Caristix Workgroup for a full interface lifecycle management suite (16-minute on-demand demo available). Get started on the right foot and avoid the beginner’s trap. 

Creating HL7 Test Messages? Consider De-identification

Tip 17 in the Interoperability Tip Series

HL7 Data for Testing

De-identification-HL7-messagesIn last week’s tip on HL7 test reporting, we suggested that you use production data for your testing. That said, you obviously can’t use real production data. You need to find a way to remove protected health information (PHI).

That’s where a technique known as de-identification can help. You keep the clinical workflow in the messages, but you remove patient identifiers and replace them with fake values. You can also replace them with off-the-wall fake values for edge cases.

And remember – even employer information can contain PHI. For instance, if two of your patients work for say, a 5-person law firm, it would be pretty easy to search publicly available information sources and re-identify them. You must remove their employer names – or insert replacement names – if you want to use this data safely. (For more on de-identification, check out this blog post.

Here’s what to keep in mind when you de-identify your production data:

  • Satisfy HIPAA. Remove the 18 identifiers designated by HIPAA as protected health information (PHI).
  • Maintain message flow. If “John Doe” in your production data becomes “Michael Smith” in your test messages, ensure that Michael Smith in your A01 admission message is the same Michael Smith upon discharge.
  • De-identify data in z-segments and unstructured notes. PHI can hide there.
  • Message volume. Aim for at least a week’s worth of messages and ideally a few months’ worth.
  • Traceability. Record which data was de-identified and which fields and data types were transformed.

Without the right message samples and test messages, you’ll run into the issues we discussed in previous tips, namely lack of updated vocabulary and potential for downtime if messages contain unexpected values.

Remember, these messages are how you test the data format and confirm that you’re not introducing errors. For example, you don’t want to find out after go-live that your interface doesn’t recognize a last name with an apostrophe.

De-Identification Software

Caristix provides de-identification software for HL7 messages. Check out Caristix Workgroup for a full interface lifecycle management suite (16-minute on-demand demo available), and Cloak, the standalone de-identification application. You can also download a Cloak trial to give it a spin.

HL7 Test Reporting

Tip 16 in the Interoperability Tip Series

The past few tips have covered HL7 testing and test automation. This one covers what you should do with HL7 test reporting.

Creating Test Reports    

Caristix Test Module

As part of the testing process, you’ll want to run reports. The reports should document the following: 

  • The number of times the test was run, as well as test duration – if you’re sending messages, this helps you understand performance.
  • Test results, including positive validations and failures.
  • The messages that were used; note the data source (SQL queries pulling from a database, an HL7 message feed, a batch file).
  • Summary of test scenarios that were run.

Just as you need sample messages elsewhere in the interfacing lifecycle (for instance, scoping), you need them for testing, too.

As a reminder, sample messages give you custom formats, structure, and data values.

For example, imagine you’re interfacing the lab information system and the ADT. You’ll want to look at the issues that were highlighted during the gap analysis. Your test messages need to cover your use cases and the following:

  • Events that are exchanged
  • Code sets/vocabulary and varying field lengths
  • Optional segments and fields, especially varying optionality  

Go with Production Data

Now about the sources of your messages: we’re going to come right out and say it – you need production data. Here’s why: Once you have the right message samples and test messages, you need to make sure you have a sufficient volume of quality test data. And your production data accurately reflects the data you work with day in and day out, both in data type and format as well as volume. And that means you’ll be able to accurately test for load and performance, and avoid message workflow problems that can bring down interfaces.

In our next tip, we’ll explain how you can de-identify production data to use safely in your test system.

The Caristix 3.1 release focuses on test automation. These new features add a lot of power to the Caristix platform. To get started on using them, check out our new test automation tutorial series.