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.


  1. 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 (

    1. 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.

  2. 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.

  3. 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.

  4. What might have taken hours, days, and best shower caps for long hair even months to build can now be 3D printed utilizing this know-how to create your distinctive designs quickly. Even although there are lots of 3d printing concepts for you to can} start getting things printed, 3D printing know-how is still extremely new to many. So we’re going to reply a few of the the} most typical questions on 3D printing and turning things to 3D. Now the corporate is prepping the discharge of its second-generation gadget, set to ship this April. The Metamáquina 2 includes a build volume of seven.9 x 7.9 x 6 inches -- greater than double that of its similarly named predecessor. It will run R$3,300 ($1,614) when it hits in a few months.


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

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

Using SOA to create Interoperablity between Providers

In the State of New York we have found the key to interoperability for Healthcare Information Exchange (HIE) is in building on a services oriented architecture (SOA). The preferred SHIN-NY 1.0 architecture was based on SOA in order to get the benefits of its characteristics, which are having business focused services based on open standards that provide reusability, flexibility, agility, and loose coupling (abstraction). Abstraction is also one of the foundational concepts of computer science. In HIE, we want abstraction between providers and consumers of information; such that the provider does not have to know how the consumer wants the information and the consumer does not have to know how the provider sends the information. One of our business goals is to make HIE a value-adding process for users in that it transforms between standards without losing the meaning of the content being shared. For example, what if a primary care provider (PCP) wants to send a referral patient summ