Part one of this series described a few factors that are motivating health organizations to join or create an HIE, factors that include Meaningful Use, ACO preparation and cost savings.
This post 
will provide an overview of the three common public HIE architecture types: centralized, federated and hybrid models. I’ll also discuss a diagram of the architecture commonly used in private larger healthcare organizations have built to effectively share patient data between member hospitals, labs and their referring physicians.
First, a quick snapshot that displays an example of how data might flow within the three types of public HIEs, starting at the local level (Centralized), moving to the state level (Federated) and ending at the national level (Hybrid), or NwHIN (Nationwide Health Information Network).
Centralized Model
Centralized HIEs have a single Clinical Data Repository (CDR) that is maintained by the HIE authority, which are usually governed by representatives from each member hospital. The centralized architecture can be utilized on a regional basis, for example, by hospital systems located in the same metro area.
Each member hospital electronically transmits agreed upon patient health information to the CDR, where it is securely stored and continually updated via interfaces that are connected directly to each hospital’s patient data repository, or health information system (HIS). Through these interfaces, patient data flows to the central authority, updating the appropriate records, and also back to each member hospital when the data is requested, which is usually done upon patient admit using a pre-defined unique set of patient identifiers, including social security number or last name.
The most interoperable HIE architecture, the centralized model costs the most to set up and maintain because it requires a large upfront investment in technology in the form of servers, which need to be monitored and stored in a secure, separate location. Additionally, each organization must have a fully functional EHR and utilize CCD documents.
Federated Model
A Federated HIE model consists of a collection of clinical data repositories which are located remotely. In this example, Centralized HIEs agree to provide the overreaching state or central authority with their unique patient identifier information, which is stored in the state-wide HIE’s patient registry, or record locator service. In a Federated HIE (as opposed to Centralized HIEs) patient data is not stored in a centralized, accessible location. Patient information continues to be stored locally, with the Regional Central Authority in this example.
To retrieve patient data, member organizations send query messages to the HIE’s patient registry. The patient registry contains a “virtual roadmap” of where patient health records are located, searchable by a combination of unique patient identifiers such as a combination of identifiers including name, social security number, and others.
When a record is located in the registry, the state central authority transmits the record’s physical location back to the requesting organization. The requesting organization then must request the patient information from the facility where it is located. The facility storing the information can transmit the data to the requesting organization via secure e-mail, secure web services, or through a VPN connection.
The Federated HIE model is considered less interoperable than the Centralized HIE because it does not allow a simple exchange of information between facilities’ EHR systems. The requirement that a central record locator service is needed to keep track of numerous duplicate health records at multiple remote locations increases the complexity of locating a patient’s complete health history available and determining which information is the most up to date.
Hybrid HIEs
This national HIE architecture type could represent a combination of the seven HIEs that are participating in the EHR/HIE Interoperability Workgroup, a federally backed initiative to develop and test the standards and processes needed to create a national exchange of health information. In addition, the Nationwide Health Information Network, typically referred to as NwHIN, is working to lay the foundation for our national health system.
In this example Hybrid Architecture model, participating Federated HIE pilots (located in New York, California, Colorado, Maryland, Massachusetts, New Jersey, New York, and Oregon) request data similar to regional HIEs in the federated model, but, the location of records across states would be performed at a national level. In this example, a national authority, such as the NwHIN, is storing a limited amount of information at the national level possibly for population health reasons. This example assumes that all participating state HIEs are structured using the Federated model.
Private HIE Architecture
Several hospital systems across the country have created a private HIE system that includes internal databases and referring physicians. Many ACO structures are supported with private HIEs. Most likely a private HIE will utilize the Centralized HIE model since there is a single, private governing organization. A private HIE is a good way for health systems to create internal interoperability that will allow them to easily connect to HIEs, state databases and, later, the NwHIN.
Of course that brings us back the question of “Why?” And for a possible answer to that question, I’ll point you back to Part 1 of this HIE series: Health Information Exchange: What’s the Motivation?
Topics in this HIE series include:
Part 1: Health Information Exchange: What’s the Motivation?
Part 2: Architecture Types
Part 3: Despite Momentum, HIE Sustainability a Concern
Part 4: The Building Blocks of HIEs: A Glossary of Terms
Part 5: HIE Communication Methods
Part 6: HIE Physician and Patient Portals
Additional Resources
Round Table on HIE Connectivity: Real Experiences with Health Information Exchanges
EHR/HIE Interoperability Workgroup Releases Technical Specifications
