Skip to main content

The Well Architected HIE and Direct Push


In "The Dangers of Too Much Ambition in Health Information Exchange" published in ihealthbeat, Micky Tripathi recently wrote about "over-architecting" HIEs. Mickey is correct that HIEs should not try to boil the ocean. However, the final point of Mickey’s article seems to be “Start with PUSH” because it is high value to physicians and low risk. It is true that PUSH is high value to physicians and that it is the primary thing they are willing to pay for. But, this alone will not make an HIE sustainable because physicians and hospitals won’t pay enough for it. On the other hand, Governments and Health Plans have been willing to make longer term investments into the data warehouse that supports PULL of a patient centric record. So to some degree, HIEs have to follow the money. This isn’t such a bad thing as for example the money for New York HEAL grants was to establish a strong foundational architecture for HIE. If regions followed the State architecture, they implemented a flexible horizontal capability for HIE based on services oriented architecture (SOA) and an enterprise service bus (ESB) rather than simply a vertical HIE application. This is critical because HEAL funded organizations that strictly adhered to SOA should be able to provide PUSH as a service between hospitals and physicians at a faction of the cost of those organizations setting up private HIEs. This is the value of reuse and this is what we are doing today. Overall, I agree with Micky; start with one or two use cases but build a foundation for reuse for all use cases. If your HIE is “well-architected”, it will take more time to create abstraction between data providers for either PUSH or PULL, but the value of reuse and abstraction is what leads to lower costs and greater sustainability for both models together as one.

A “well architected”, not over-architected, not under-architected, solution to me is one that uses a common information model (CIM) to provide a message-based, canonical view of the information being passed from source to destination in PUSH rather than passing what came in as is or doing individual source to destination transforms. This allows standardization of data structures among disparate systems, speeding deployment, and reducing the cost of integration by significantly reducing the number transformations that need to be built and maintained. It also gives the abstraction, or loose coupling, between source and destination so that their individual system changes do not affect each other and they don’t get frozen to their business partner. By using the same CIM for the PULL model, we also have reuse of the adapters built to load data into the exchange, cutting the number of adapters to be built and maintained in half yet again. All of this reuse and abstraction results in sustainability for public HIEs by creating an economy of scale that private HIEs cannot reach because they don’t have the reuse between PUSH and PULL that the larger state or regional HIE can create. This includes the reuse to implement Direct as a transport for push the same as any other protocol.

I propose an HIE should start with PUSH or PULL based on where the financing is coming from but either way the HIE needs to have enough time and funding to build the strong foundation required to do both rather than jumping in with a PUSH platform that won’t meet the need for sustainability, which requires both. I also propose that ACOs should be looking for a state or regional HIEs as an alternative to building a private HIE for Direct Push, as a “well-architected” public HIE should offer lower cost of operation. Some of the failed HIEs after all did start with PUSH but they couldn’t get sustainable because there isn’t enough revenue or cost-justification just around PUSH. As a side note, state and regional HIEs should not be implementing PUSH and PULL as two different systems as this will not yield the same level of reuse as the “well-architected” solution.



Comments

  1. UnknownJuly 9, 2012 at 1:27 PM

    I like your tought about a common information model. But I would take it even at a simpler level, by suggesting that one should start with a common metadata model. That is much simpler, and sufficient in order to bring PUSH and PULL together so that one can start with either one as you suggest. On this I receommend the white paper developped by EHRA on the same theme: Supporting a Robust Health Information Exchange Strategy with a Pragmatic Transport Framework (http://www.himssehra.org/docs/20110629_EHRA_TransportFramework_Final%20.pdf)

    ReplyDelete
    Replies
    1. Joel RybaJuly 9, 2012 at 2:17 PM

      Thanks for the comments. I believe your concept of Direct push including metadata mapped to a common model is great. My prior experience includes implementing both, a common schema that works as the middleman in the exchange as well as having that schema or any other exchange schemas mapped to a common model. That experience was with NIEM for criminal justice exchanges. NIEM is a good example for where we need to go with healthcare exchanges.

      Delete
  2. ChrisFebruary 11, 2013 at 10:39 AM

    Couldn't agree more. I see too many implementations "massaging" the source messages instead of mapping to a common model leading to harsh coupling and fragile implementations.

    ReplyDelete
  3. AnonymousNovember 14, 2022 at 1:41 AM

    The subsequent step of the process is straightforward too - simply selected a username and password and enter them into the indicated boxes. Make certain your chosen password is one you could 카지노 bear in mind easily and cannot be guessed by someone wanting to interrupt into your account. Needs to evaluation the safety of your connection before proceeding.

    ReplyDelete

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

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 provi...
3 comments
Read more

"Version the Verb" is more efficient with "HIE the Noun"

What happens when you version the standards for P2P exchange? One of the key value propositions of "HIE the noun", for example an Enterprise Service Bus (ESB) based regional patient-centric exchange, is that it abstracts between data providers and data consumers. Thus, if a new standard comes along, some can implement it and some can hold off. The HIE provides the abstraction between the two. There is no tight-coupling between trading partners. In the "we will all do the same thing peer to peer" model, doesn't it break when something new comes along? Otherwise, every P2P end-point needs to support every standard that emerges as they emerge and until everyone has it implemented, the world is frozen. That sounds an awful lot like where HIT is with ICD10 right now. Most systems seem to have tightly coupled to the ICD9 codes rather than having an abstraction in their system between internal coding and the outward facing standard codes, now they have trouble upg...
Post a Comment
Read more