Skip to main content

Why Direct makes sense for Data Delivery to an EHR Hub

Who precisely are you sending that message to?


There is a little recognized problem in using legacy HL7 over VPNs to deliver data (lab results, image studies, reports, etc). The orderer is in the message regardless of whether you are trying to send to them or not. The CC list is in the message regardless as well. The attending, the primary, etc. all there but maybe not who you are routing to. Who are you routing it to?

How is this a problem?


In today's modern world of Software as a Service (SaaS), many of the EHRs get data delivery through a common gateway for many practices. If you route a message to a single practice with a locally installed EHR, then when the data source (e.g. hospital or an HIE as its proxy) sends a message to the practice, the practice endpoint and the EHR endpoint are one in the same. There is no confusion about who the message is for. When the EHR serves multiple practices is where we get the confusion. The endpoint of the practice is a spoke off of the EHR vendor hub.

Which of those spokes is the message intended to go to?


The message identifies many providers who could potentially be routed the message (ordered by, CC, attending, primary, etc.). But those may not be who this message is intended for at this endpoint. This is because some of those may be getting this message a different endpoint (they have a different EHR). Some may be getting it at this endpoint but they are still getting fax and are not ready for the structured data message.

Why is this a problem?


First off, the EHR Hub may wonder who you are routing to and may come back to ask about the additional providers that they cannot identify. That isn't a real big issue. The bigger issue is that if an HIE or HISP is in use, some providers may be getting this message by an older point to point feed and could wind up with the message twice. Some providers simply are not whom the sending facility was trying to send to (e.g. the attending has their copy in the hospital system and they are not trying to send it to their ambulatory practice connection). Lastly, there may be a business relationship and BAA chain issue if the EHR Hub sends a message to a practice that does not have a service agreement with the HIE or HISP that sent the message to them.

How do you solve the problem with Direct as it becomes the standard?


The good thing about direct is that it is a routing protocol, an email message. The content of the message may be an HL7 message, as it is with the lab results initiative (LRI). This way the concept of routing is added outside of the clinical content of the message. So Direct will eventually solve the problem across the board as we move from VPNs to Direct over the next several years. That problem being, we only want the message to go to those we intended and not send it to others even if they are in the clinical data for some other reason.

How do you solve the problem with Legacy HL7 over VPN today?


The bad thing about HL7 over VPN is that it uses content based routing within an EHR Hub. The best solution we have found is to add a specific new segment and field for routing and not rely on trying to interpret routing from the clinical message content. This can be accomplished by adding a Z-segment with a provider XCN field to the outbound message to be used by the EHR Hub. This new field is then used exclusively by the EHR Hub for content based routing and the other fields in the clinical content are not used. This resolves any issue with hub and spoke (HIE and/or EHR Hub) based routing until Direct can be introduced as the wrapper to handle the same.

How does it work?


We implement this as either the concept of a "receiving system" for some EHR hubs or as a Z-Segment approach for other EHR hubs in the HIE that I am associated with and it is yet another benefit of the SOA based abstraction that we implement as the foundation of our HIE and it serves as a stepping stone to Direct via the HIE as we are routing based on addressing for user accounts that are specified in the subscriptions (for publish-subscribe SOA pattern) rather than purely on content, even if that subscription is triggered by IDs in the content.

Comments

Post a Comment

Popular posts from this blog

eRegister and Get Rid of the Clipboard

The Real Use Case for Personal Health Records (PHR) I have been at this, HIE game, for a few years or so now. And when I go out and meet new people, I get the typical, "so, what do you do" question. Once I tell them and give a little explanation of what it means, about half of them have a follow-up question. There is only ever one follow-up question and it is always the same question "so, are you going to get rid of that clipboard of paperwork that I have to do over and over again every time I go to see a doctor". The fact that I only get one question from general consumers and it is always the same question tells me one thing. This is what matters to them. This is how they see their information making it from them to their provider today. This is what they want to eliminate by using HIE or a PHR. In essence, I see the HIE and PHR as one in the same. The HIE, in a fixed repository model, is a collection of "views" of the patient. We have a primary

Game Changing Healthcare Information Exchange

Evolving HIE Beyond just replacing the fax machine   HIE can be more of a game changer for healthcare than just being a replacement for the fax machine. The route to being a game changer is to be an enabler of care management. That care management can come from a health plan (managed care organization), an Accountable Care Organization (ACO) like a Patient Centered Medical Home or Medicaid Health Home, or from the patient/consumer as care manager for themselves or as the caretaker of another.   To do this, I think the HIE needs to serve the following customers and their use cases. These are the healthcare providers for care coordination, the care manager in the role of managing care, the care management at a program management or quality improvement level, and the care management at a financial management level.     HIE must Support Provider-Patient Coordination Use Cases   Send patient data between providers This is the primary purpose of the HIE PUSH functionality