We covered many details about interfacing architecture and data exchange in Chapter 2. All that said, your main challenges are not with the plumbing, or with the methods used to transport or route data. In fact, interface and integration engines handle this quite well.
Interface Engines Don’t Address The Real Issue
The real issue is with data formats, workflows, and meaning – and interface and integration engines don’t address these problems. It’s quite common for two or more departments (and by extension, the systems they use) within the same hospital or IDN to use different definitions and data structures to indicate the same information, such as “temporary patient.”
Consider another example. A physician adds a note “NA” (i.e., Not Applicable) to a patient’s chart indicating that information was never gathered about allergies to medications. Later on, another physician looks at the patient file, interprets the NA code as “No Allergies,” and orders an antibiotic drug. The patient dies from an allergic reaction. While this is an extreme case, it’s well within the realm of possibilities. This is why meaning – the semantics of data – is everything.
Here’s another scenario. A physician submits a pharmacy order for a pain relief medication not recognized by the system receiving the order. The order is dropped and the patient endures more pain for longer until the situation can be remedied.
Even the definition of a procedure can vary from one physician or clinician to the next. If a physician requests a complete blood workup on a patient but the lab technician omits some tests because she doesn’t consider them to be part of the order, the doctor will wonder when she will be receiving results for the outstanding tests. When they never show up, she’ll be forced to follow up with the lab, wasting valuable time for her and her patient.
Or consider something as simple as date-time data. If you don’t specify AM and PM in your scheduling application, you’re going to be constantly wasting time rescheduling appointments set for 8:30 at night when you mean 8:30 in the morning, for example. The same holds true when you don’t account for time zones, such as data in one system set for MST and the other set for CST.
Data and Information Challenges
The real challenge is at the information level. What information is needed by whom, when, and in what format? Once you have these answers, you need to validate that information being transferred is using the same semantics.
|
|
Issue |
Example |
Data structure |
The HL7® standard specifies a data structure based on trigger events, segments, fields, and data types. The recommended structure must account for complex clinical workflows and data representations. |
There might be a gap based on the maximum length of data elements. A field in one hospital system specifies a maximum length of 50 characters. The same field in the system under implementation is set at maximum length of 20. |
Data tables |
HL7® provides a recommended set of data values. These can be modified. |
HL7® v2.6 “suggests” six different values for patient gender. |
Data semantics |
Good data semantics implies that the meaning or intent of the data is exchanged accurately – not simply the data value itself. It’s essential for HL7® interfaces to convey their interpretation of the HL7® standard in use. |
Patient identification is the classic example. It is important to determine which fields are in use. Possibilities include: PID-2 Patient ID, PID-3 Patient Identification List, PID-18 Patient Account Number, PV1-19 Visit Number, or a combination thereof. |
Z-segments |
Z-segments are custom message segments. They are used when an application must convey information outside the scope of the HL7® standard. Development teams also resort to Z-segments to work around technical limitations. |
By definition, all Z-segments result in gaps. If Z-segments aren’t mapped accurately, critical information can be lost. |
The bottom line is that it’s critical to understand the data, the source systems involved, and how each system handles data semantics. Here are some tips and questions to help you get at this information.
6 Questions to Help Your Team Understand Healthcare Data
1. Understand the message/interface specification provided by your vendor. “We are HL7 2.4” is not enough. Ask the vendor to provide details about messages, segments, fields, the need for z-segments, etc. Also find out how they handle data semantics. In other words, what does the data mean? What is it used for? By extension, understand workflow-related information, event timing, vocabulary definitions, and who will use the information and how. The examples we listed above (lab results, two meanings of NA) speak to this.
2. Understand the type of message that will be generated based on the event (e.g., a patient admission, patient visit, cancelling a transfer, sending a partial lab result). Understand what data is provided with the event, including the various code sets. Watch this video for a 4-minute overview of an HL7® message:
https://blog.interfaceware.com/understanding-hl7-messages/
3. How do the code sets and content evolve over time, and who handles the updates and how?
4. Where does the data go? Is there a need to protect sensitive data?
5. How does the new system manage errors? What happens to messages that aren’t understood by the destination system? What happens to rejected messages? We all agree that in a perfect world no piece of information and no messages would be dropped, but the reality is it that it can and will happen. How would users and the overall workflow be impacted in such a situation? How can you mitigate the risk?
6. How do you handle workflow changes? If it’s a matter of adapting the interface, how is this handled, how much time does it take, what does it cost, and who pays? You want to avoid 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. Worse yet is Interface 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.
Answers to these questions will help you understand the source and target systems. This is important for new product implementations (like EHRs and EMRs). Once you’ve nailed down these details, you need to pinpoint the gaps with the receiving system(s) so you can bridge them with an interface.
Here are some questions you’ll need to ask of the vendor and your internal teams about the receiving system(s).
5 Questions for HIT Vendors and Internal Interfacing Teams
1. Map out the message process or workflow. For instance, if your interface transfers data from a remote application via FTP, what is the flow? Do messages start in one application, get routed to an engine, then another engine, and then finally reach the destination system?
2. Map out the business impacts of the interface. If you make changes to a patient charge interface, what is the business impact? What if you choose not to implement the interface? For example, will it result in more manual data entry for a clinician?
3. What information does the destination system need? Where in the message structure is the information found?
4. Is the vocabulary used in the destination system different from that used in the source system?
5. Is all of this information documented? If not, how will the vendor keep you updated on changes? This is an especially important question to ask vendors, since they simply won’t be as responsive two years down the road as they were during implementation and go-live.
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
