Understanding Health Information Exchange
This guide introduces the concepts behind Health Information Exchange (HIE) to help developers understand the "why" before diving into the "how." By the end, you should see where APIs fit in and why standardization is the cornerstone of interoperability.
The Patient Care Journey
To truly understand and appreciate why HIE exists, we start the patient's story when they seek healthcare services in a healthcare system.
- Patient Visit: The patient arrives at a healthcare facility seeking medical services. They register if they are a new patient creating a new patient file or if a returning patient their file is retrieved.
- Triage: Vital signs are recorded—height, weight, blood pressure, and other basic measures.
- Consultation (initial): The doctor reviews the patient’s medical history (if any), records symptoms, and may order lab tests. Billing for services often begins here.
- Lab: The lab order is shared with the lab technician. Tests are carried out and a lab report is created with the results of the lab tests. This is shared with the doctor.
- Consultation (Follow-up): Using lab results, the doctor analyses the results and created a treatment plan for the patient. This may include a prescription for the medicine to be given to the patient.
- Pharmacy: Using the prescription from the doctor, a pharmacist dispenses the medications and billing is completed.
This flow seems simple and clear when all the outlined service points in the patient's care journey is contained in a single facility. But there are other scenarios that are not that simple:
- A patient may be referred to an external lab for the lab tests if a facility can't do them in-house.
- They may need medication from a community pharmacy or even a commercial pharmacy if the healthcare facility doesn't have the medication .
- They may switch hospitals entirely and start using a different healthcare facility.
Suddenly, continuity of care depends on how well information flows across different systems. And that’s where problems begin.
The Limits of Standalone EMRs
Electronic Medical Records (EMRs) replaced paper files, they made things much better. No clutter of files, or having to physically transport files. Information could be shared easily and there was improved record keeping as well. So they mostly solved storage. However what happened when this information needed to be shared with other systems? THe problem of sharing came up:
- Inside one facility, EMRs work fine. They had well defined workflows and easily referred to the health and medical products in the same way. And given it was just a single system accessing the same data store, data was easy to retrieve across different service points.
- Across facilities, there was a big problem: EMRs speak different "languages."
One hospital may record “Panadol”, another “Paracetamol”, and yet another “Acetaminophen”. Without a shared standard, these systems could share information but equally as important as just sharing the information was understanding the information.
So the question developers need to ask is:
What is the standard way of exchanging health information so that it is universally understood?
Health Information Exchange (HIE)
HIE was created to solve this. Think of it as a national framework, infrastructure, and rulebook that enables secure, authorized, and interoperable health data exchange.
Instead of each system building dozens of one-off connections, HIE provides a Shared Health Record (SHR)—a single source of truth that different systems can access, update, and trust.
The goal is simple:
Make sure the right health information is available to the right person at the right time.
Example Scenario
- A patient registers, consults, and is referred to an external lab.
- Facility A shares orders and observations with the lab via the HIE.
- The lab completes tests and returns results in a standardized format.
- Later, the same patient visits Facility B. With consent, Facility B retrieves the patient’s history from the SHR, no repeated tests, no missing context.
The Building Blocks of HIE
Behind the scenes, HIE runs on several core services and registries. These are what developers will integrate and interact with.
1. Master Patient Index (MPI) / Client Registry
- The single source of truth for patient identity.
- It stores demographic data and identifiers, such as the Client Registry ID (CR_ID) which is the unique identifier of every patient.
- It makes sure that a patient in one system remains consistent throughout different systems and their data is retrievable as well.
2. Facility Registry (FR)
- This is the authoritative list of healthcare facilities in the country.
- Each facility has a unique facility registry identifier (FR_ID) which is the facility's unique identifier throughout multiple system.
- This registry stores key metadata for the facility: type (hospital, clinic, pharmacy), location, licensing status, and services offered.
- Ensures that healthcare services, referrals and claims are tied only to valid facilities.
- Also just like the client registry it ensures a consistent way of identifying a facility across multiple systems
3. Health Worker Registry (HWR)
- The official record of licensed healthcare worker.
- Each healthcare worker has a unique health worker ID.
- It captures roles, credentials, and scope of practice (doctor, pharmacist, nurse, etc.).
- It powers authorization checks—only licensed workers can create or access certain records.
- It also consistently identifies the healthcare worker across different healthcare systems.
4. Terminology Service (TS)
- This is the translator of the HIE ecosystem.
- It provides standard codes for medicines, diagnoses, procedures, and labs (e.g., ICD-11, LOINC, national drug codes).
- Maps local terms (“Panadol”) to standardized codes (“Paracetamol 500mg tablet”).
- Ensures that every system "speaks the same language."
5. Shared Health Record (SHR)
- The central repository of longitudinal patient data.
- It aggregates and normalizes records from EMRs, labs, pharmacies, and other systems.
- It also provides a full patient history across facilities and care settings.
- However one of its main work is it acts as the hub for analytics, continuity of care, and clinical decision support.
- It enforces consent rules—patients must authorize access to their data.
6. Consent Management
- This governs who can access what, when, and for what purpose.
- Patients can authorize or restrict access to their data.
- It helps enforce privacy and compliance with data protection laws.
7. Audit & Logging
- Tracks every create, read, update, or delete action.
- Creates an immutable log of who accessed what, when, and why.
- Ensures accountability, compliance, and trust.
Why This Matters to Developers
If you’re building applications that interact with HIE APIs, here’s what you need to keep in mind:
- Identity is federated. Patients, providers, and facilities must always be referenced by their registry IDs.
- Data is coded. Free text (“malaria”) is not used, it mainly uses coded values (e.g., ICD-11 code).
- Consent is mandatory. Every API call involving patient data checks against consent rules.
- Audit is automatic. All API interactions will be logged and traceable.
- Standards are non-negotiable. Interoperability relies on FHIR and controlled vocabularies.
Bringing It All Together
HIE is more than just a data-sharing mechanism, it helps building an infrastructure for continuity of care.