Select Page

    4.1.1  HIE the noun

    Some background context for understanding the HIE market was already explored in section 4. Health Information Exchanges. Let’s cover a few ways to categorize the entity we call an HIE. First and most importantly, they can be classified according to funding source.

    Public HIEs

    These are paid for by taxpayer money, most of which was distributed by the HITECH Act in 2009 to create regional and state-level HIEs. Today that wellspring has nearly dried up and self-sustainability has become the main problem for public HIEs. Concerns about cooperating with competition and data ownership have consistently made stakeholders unwilling to pay for public HIE services. There is a somewhat dated dashboard on the HealthIT.gov website that provides high-level details on public HIE efforts. [1]

    There has also been lots of press given to a national-level HIE effort called the “Nationwide Health Information Network” (or NwHIN). Here is what you need to know about NwHIN: It’s not an actual network or HIE but rather a set of policies. Even the HealthIT.gov website defines it as “a set of standards, services, and policies that enable secure health information exchange over the Internet.” [2]

    Private HIEs

    These are sponsored by a commercial entity (usually a hospital system) to help direct business from peripheral clinics and affiliated providers to themselves. The argument for private HIEs being the future of the HIE market has previously been laid out in section 2.3. Health Information Exchanges. Organizations looking to create tight clinical networks to better coordinate care and keep costs low will need to create private HIEs. As Obamacare changes the payment models, private HIEs will increasingly serve as the operating system for the surviving large hospitals and IDNs.

    Another useful way to classify HIEs is according to their data storage architecture.

    Centralized

    In this architectural approach, all HIE participants send the previously-agreed-upon data to a common central store (called the “Clinical Data Repository”, or CDR) which is created and maintained by the HIE. This approach yields better performance (i.e. faster query-response times), but is expensive because extensive infrastructure investment and data agreements are needed upfront.

    More importantly, the centralized model requires strong coordination and political alignment to truly succeed. Which is why this architecture is almost always seen in case of private HIEs owned by a single entity with complete operational authority.

    Federated

    Also known as the “Decentralized” or “Distributed” model, it has no single central CDR. Instead, HIE data is stored in a collection of repositories that participating organizations own and maintain locally. In a strictly federated model every request for patient data is passed along to every participating data source. As you can imagine, that only works as long as the volume of requests and the number of nodes being pinged remains low.

    Having patient records across multiple remote locations means duplication and constant confusion about which information is most up-to-date. To its credit, the federated approach doesn’t have a single point of failure and is politically more feasible because participating independent (and often competing) organizations can retain physical control of data physically (a pointless concern that plagues many healthcare executives).

    Hybrid

    This approach uses a centralized virtual index of which patient’s data is stored where, using an indexing service called RLS (Record Locator Service). In effect, this takes the best of both centralized and federated approaches to store some data centrally while using an RLS to get to the rest. As the geographical reach of an HIE gets larger, a hybrid approach becomes inevitable.

     

    4.1.2. Functional Layers of an HIE

     

    Below is a high-level list of what an ideal HIE should do. Each translates to a conceptual layer in the HIE architecture and is detailed in the sections that follow.

    1. An HIE needs to accept incoming data, validate it, normalize it, and then store or pass it along to destination. The mechanics of all that are in the “Data Layer.”
    2. Systems that receive HIE data have their own context and specifications for consuming that information. The HIE functionality that deals with that repackaging is in the “Transformation Layer.”
    3. The ability to present HIE data to end users comes from the “Presentation Layer.” This is what produces the Longitudinal Patient Record (LPR) I described previously.
    4. An ideal HIE follows service-oriented architecture (SOA) principles to create a “Services Layer” that enables conversations between numerous IT systems and creates functionality that can be reused across networks.
    5. It’s logical for an HIE to generate reports and insights on the troves of data it holds and processes. Those features are enabled in the “Analytics Layer.”

    Note that this layered-view framework doesn’t leave a clean room for placing usual large IT system features like backup and recovery, and  user management. Hence those are omitted intentionally. Also, the caveat from section 3.1.1 on the volatility of EHRs applies here as well: It is futile to claim a complete feature list because the functional definition of an HIE keeps evolving as vendors do their best to adapt to changing market needs.


    [1] ONC. State HIE Program Measures Dashboard. Accessed April 25, 2016.
    [2] ONC Nationwide Health Information Network (NwHIN). Accessed April 25, 2016.