Skip to main content

Is our HIE Effective?

In "Ryba's 16 rules of effective HIE" published in Government Health IT, I recently wrote about what I believe to be the rules that can be used to define an HIE that is reusable across all use cases. I don't get into what technical implementation it supports or even what type of healthcare information is being exchanged. However, if your HIE complies with these rules, I believe you have a "fully effective" HIE. That said, if it does not, it may or may not be adequately effective for where the world is today. The point is, these rules are what I think exchanges, public or private, should comply with, or at least should be able to comply with, from a functional perspective. How soon you will need to meet all of them will probably be determined by market forces or government mandates in your area.

While I left technology out of the rules, if you follow any of my previous writings, you know I of course believe that a services oriented architecture and enterprise service bus best applies to the rules primarily due to its inherent focus on resuability and abstraction. So, if you are building your HIE using an ESB, I think you are probably heading in the right direction.

If you haven't yet met all the rules, you probably are not alone. The rules are what I think we aspire to. They are based on mostly where we are but to a greater degree where we are going.

To answer my title question, our HIE is effective and is mostly compliant to the rules, but like all HIEs, we still have work to do. Abstraction is an area that seems to always need continual maturity for both syntactical interoperability to transform between transports and schemas and semantic interoperability to translate terminology between different vocabularies. Syntactical interoperability allows one to know what the other is saying; semantic interoperability allows them to understand what you mean. This is never-ending work since new standards emerge or version on a regular basis. The abstraction rule is where myself and my staff spend a lot of our time. We see it as a big part of the technical solution value of HIE the noun.

Comments

  1. udayacadizMarch 3, 2022 at 7:08 PM

    WynnBET, MGM National Harbor | DMC
    You are 군포 출장안마 eligible for 남양주 출장샵 a 군포 출장샵 $50 bonus. You will receive a 20% deposit 정읍 출장마사지 match on your first four deposits on your first four 양주 출장마사지 deposits.

    ReplyDelete

Post a Comment

Popular posts from this blog

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
4 comments
Read more

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
2 comments
Read more

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
7 comments
Read more