Health Information Exchange of HIE is the most commonly heard abbreviation in healthcare. There are a lot of invaluable information about the same that is available in the internet, journals, textbooks and other sources. This blog is a humble attempt by Harish Sakala and S.Karthik at exploring some of the common terminologies and process in HIE

1. Introduction

Health Information Exchange or HIE as the name itself indicates refers to the exchange of health information. The health information can be information related to a patient’s current condition, or prescription or any diagnostics tests. The HIE can happen between any of the following,

Point to Point

o Provider to Practitioner

o Provider to Diagnostic Laboratories

o Provider to Radiology Service providers

Provider to Patient
Provider to Immunization Registries

The following are some of the areas where HIE is used,

Referral Management
Order laboratory tests and receive results
E-prescription

Following are the some of the HIE networks including:

Physicians
Hospitals
Regional Health Information Organizations
State Government Agencies|
Others as Healthcare evolves (i.e., ACOs., etc)

HIE will help providers in emergency treatment, improved care, informed decision making and minimization of errors involved in manual methods of information exchange. The below is a high level depiction of the various methodologies that are used in HIE

Source: HIMSS Florida HIE Lessons Learnt

This the Low level flow methodologies that are used in HIE

As the above picture indicates, the following are the different methods of exchanging health information that are in vogue,

Fax and Paper
Point to Point
Enterprise wide HIE
HL7

o TCP / IP

o XML and web services

NHIN Direct
NHIN Connect
VPN
Proprietary Solutions

While most of the HIE are pull in nature there are a number of instances like the following which are push in nature,

E-prescription to a pharmacy
Laboratory test results from a laboratory to a EMR / PM system
ADT (Admission Discharge Transfer) event

2. Architectural Approaches in HIE

The following are the different architectural approaches involved in implementing a HIE,

Federated Architecture
Centralized Architecture
Hybrid Architecture

Federated Architecture: A federated HIE is a collection of local repositories that are remotely located. The patient’s data is located at the provider level. The requesting application queries the patient’s data. The HIE’s patient registry will locate the information, authenticate the requestor and verify if it is authorized to receive that information. The patient registry or Record Locator Services (RLS) uses a combination of unique patient identifiers such name, social security number, to locate a patient record. On successful verification, the source system will respond with a “Yes” response if the record is available.

If the user chooses to view the record the same is displayed in a in a predetermined format like PDF. It is to be noted here that the recipient has got a read only access and cannot save the record that he is viewing. It is not saved in the cache also.

If a user is querying a lab result the system will search for that particular order or result and display the same. If the user is querying for patient medical history or demographics information, the system will search all possible locations in that network where the information is available and display links to it.

Centralized Architecture: In a centralized architecture the patient’s medical records are stored in a centralized location. The record is constantly updated through interfaces from connecting applications usually on a daily basis. In this model the HIE is responsible for ensuring information security and authenticating the systems that share data. Though the data in a centralized location is a summation of data from multiple systems there is a logical separation between data from different systems.

Source: Stratis Health HIE Technology Document

The Master Patient Index (MPI) is the algorithm that is used to match patients that are being queried.

Hybrid Model: The Hybrid model is a via media between Federated (decentralized) Centralized model. This model ensures that the complete patient information is available in real time where publishers post data and consumers have access it. In this model a Record Locator Service (RLS), MPI and Healthcare provider directory are used. The system aggregates different medical information for the same patient into a single record which can be queried and directly imported into the destination system.

HIE ‘s can also be classified on the basis of number of entities that are involved in HIE as

Type 1
Type 2
Type 3
Type 4
Type 5

i. Type One HIE : Type 1 HIE is designed for a single hospital or a hospital exchange that wants to seamlessly provide hospital specific data to its providers in one common view. Traditionally, the data is viewed within the HIE. Data is not transferable into a provider’s specific EHR product as discrete data.

ii. Type Two HIE: Type 2 HIE facilitates data sharing between different practices utilizing the same EHR product. Through a specific vendor’s data exchange protocols, specific patient data can be exchanged between multiple provider organizations. A Type Two HIE can also receive data from hospitals and laboratory facilities. Traditionally, a Type Two HIE does not exchange data with other EHR vendor products. An HIE at this Type can provide PHR capability, but only among practices using the same EHR product. A Type Two HIE is usually governed by one hospital organization, or by a smaller local provider community.

iii. Type Three HIE: Type 3 HIE provides data sharing between different practices who are utilizing a short list of different EHR products. The Type Three HIE is traditionally distributed by an EHR vendor claiming it can connect other EHR vendors with its product. The Type Three HIE exchanges data using one specific vendor’s data exchange protocols. An HIE at this Type is generally built from the ground–up, and utilizes multiple point-to-point interfaces.

Type Three HIE can receive data from hospitals and laboratory facilities and provide PHR capability, but once again, only with other organizations using the same EHR product.

iv. Type Four HIE: Type 4 HIE has the ability to exchange discrete patient data (following CCD methodology) between multiple practices with selected EHR products, hospitals, radiology centers and laboratory facilities, even if they are on separate Healthcare products.

iv.The Type Four HIE provides a community MPI and a community patient portal for patient communications with each care provider. The data is able to be transmitted seamlessly into each provider’s EHR as discrete data.

The Type Four HIE also provides e-prescribing capabilities for those providers that have not embraced EHR technology. An HIE at this Type is often governed by a community of competing hospitals and provider organizations throughout a region.

v. Type Five HIEs: Type 5 HIE have the ability to exchange discrete patient data (following HITSP C32 version 2.5 or higher CCD record format) between multiple practices with different EHR products and with hospitals, radiology centers and laboratory facilities, even if they are on separate vendor systems.

Type Five HIE provides a community MPI and a community patient portal for patient communications with each care provider. The data is able to be transmitted seamlessly into each provider’s EHR as discrete data.

The HIE should possess a community Patient Health Record (PHR) capability, designed to provide each patient with a centralized location for demographics and clinical history.

The Type Five HIE also provides e-prescribing applications, for those providers that have not embraced EHR technologies, and offers extensive disease management and outcomes measurement data capture and reporting.

Type Five HIEs are governed by a community of competing hospitals and provider organizations throughout a region. The goal of a Type Five HIE is to improve the quality of healthcare in the community while reducing costs via patient data coordination.