In the previous chapter, we covered what you need to know when testing your interface. While the right test tool is helpful, you need to feed it the right message samples and test messages. After all, messages impact the entire interfacing lifecycle.
So what makes messages “right”? Namely, you need message samples and test messages that reflect your environment: your ADT message flow, your specific lab codes, and your case mix – whatever information your interface is intended to share.
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 LIS and 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.
It All Starts with De-identification
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 these blog posts.
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 log, ensure that Michael Smith in your A01 admission message is the same Michael Smith upon discharge.
- De-identify data in z-segments. PHI can hide in z-segments.
- Log 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 the last chapter, 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.
Don’t Fall into the 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.
Consider that you’re interfacing with a lab system. The lab is often the area of a hospital 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.
Your Feedback Welcome
We’ll be publishing chapters from the HL7® Survival Guide over the upcoming weeks and months. See a topic that needs more detail? Have a different perspective on interfacing and interoperability? Tell us in the comments!
Read More in the HL7® Survival Guide
Introduction
Chapter 1: How to Integrate and Exchange Healthcare Data
Chapter 2: Pros and Cons of Interfacing Capabilities
Chapter 3: The Heart of the Matter: Data Formats, Workflows, and Meaning
Chapter 4: How to Work with Vendors and Developing Your EHR Strategy
Chapter 5: Vendors, Consultants, and HL7® Interface Specifications
Chapter 6: Interfacing Artifacts: HL7® Conformance Profiles or Interface Specifications
Chapter 7: Interfacing Artifacts: Gap Analysis
Chapter 8: Interfacing Artifacts: Test Scenarios and Test Systems
Chapter 9: Interfacing Artifacts: Message Samples and Test Messages
Chapter 10: Process and Workflow
Chapter 11: Maintenance, Troubleshooting, and Monitoring
Chapter 12: Definitions
Chapter 13: Contributors and Resources
