Friday, July 6, 2012

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.