10.1 Health IT Interoperability: HL7, FHIR & Health Information Exchanges (HIE)

Health IT Interoperability: HL7, FHIR & Health Information Exchanges (HIE)

In modern healthcare, interoperability represents the ability of different information systems, devices, and software applications to access, exchange, integrate, and cooperatively use data in a coordinated manner across organizational boundaries. The Assistant Secretary for Technology Policy / Office of the National Coordinator for Health Information Technology (ASTP/ONC) and the 21st Century Cures Act mandate robust interoperability to eliminate information blocking, lower healthcare costs, and improve patient safety.

Interoperability is evaluated across four distinct levels:

1. Foundational (Level 1): Enables basic data exchange from one system to another without requiring the receiving system to interpret the data.
2. Structural / Syntactic (Level 2): Defines the structure, format, and syntax of data exchange (e.g., HL7 v2 messages or XML document schemas) so that message fields can be consistently parsed.
3. Semantic (Level 3): Encodes clinical data using standardized healthcare terminologies (SNOMED-CT for clinical concepts, LOINC for laboratory observations, RxNorm for medications, and ICD-10-CM for diagnoses). This guarantees that both the sending and receiving EHR systems interpret the clinical meaning identically.
4. Organizational (Level 4): Encompasses governance, legal agreements, policy frameworks, and social considerations that facilitate trust and seamless cross-institutional data workflows.

---

Health Level Seven (HL7) Version 2 Standards

Developed in the late 1980s, HL7 Version 2 (HL7 v2) remains the workhorse of internal hospital interfaces. HL7 v2 is a flexible, transaction-oriented standard that utilizes pipe-delimited (|) ASCII text strings to transmit clinical and administrative events between hospital information systems (e.g., ADT, EHR, LIS, RIS, and billing systems).

Message Structure & Common Segments

HL7 v2 messages consist of sequential segments, each separated by a carriage return. Segments begin with a three-character header followed by fields separated by vertical pipes (|), component separators (^), and sub-component separators (&).

• MSH (Message Header): Defines the message type, sending/receiving applications, timestamp, and control ID.
• PID (Patient Identification): Contains demographic details including patient ID, name, date of birth, sex, address, and SSN.
• PV1 (Patient Visit): Captures visit-specific attributes like patient class (inpatient/outpatient), assigned location (room/bed), attending physician, and admission date.
• ORR / ORM (Order Entry): Handles clinical order requests sent to ancillary systems.
• OBR (Observation Request): Identifies specific lab tests or diagnostic imaging procedures ordered by a clinician.
• OBX (Observation Result): Transmits individual result findings (e.g., glucose numerical values or radiologist textual impressions).

Core Message Types & Trigger Events

HL7 v2 operates on real-time event triggers:

• ADT (Admission, Discharge, Transfer): Tracks patient movement. Common trigger events include ADT^A01 (Patient Admit), ADT^A04 (Patient Register), and ADT^A08 (Patient Information Update).
• ORM (Order Message): Transmits new orders (ORM^O01) from the EHR to laboratory or radiology systems.
• ORU (Unsolicited Observation Result): Transmits completed diagnostic results (ORU^R01) back from laboratory or radiology systems to the EHR.

---

HL7 Version 3 & Consolidated Clinical Document Architecture (C-CDA)

To overcome HL7 v2's lack of strict semantic enforcement, HL7 introduced Version 3 based on a formal Reference Information Model (RIM). The most widely adopted v3 implementation is the Consolidated Clinical Document Architecture (C-CDA).

C-CDA is an XML-based document standard used to exchange complete clinical summaries across disparate health systems. The most common C-CDA document type is the Continuity of Care Document (CCD), mandated for transition-of-care summaries. C-CDA documents feature a dual structure:

• Human-Readable Header & Narrative: Formatted in standard HTML, allowing clinicians to view patient summary sections directly in any standard browser without specialized software parsing.
• Machine-Readable Structured Body: Formatted in XML with mandatory vocabulary coding (LOINC, SNOMED-CT, RxNorm), enabling receiving EHRs to parse discrete data points directly into patient chart tables.

---

HL7 FHIR (Fast Healthcare Interoperability Resources)

HL7 FHIR (Fast Healthcare Interoperability Resources) represents the modern generation of health IT interoperability. Designed specifically for web environment flexibility, FHIR combines the best features of HL7 v2 and C-CDA with modern web standards, including RESTful HTTP architecture, JSON (and XML) data formatting, and OAuth 2.0 security protocols.

Core FHIR Concepts

• Resources: Building blocks of FHIR representing discrete clinical or administrative entities (e.g., Patient, Practitioner, Observation, Condition, MedicationRequest, Encounter). Each resource has a unique URL endpoint.
• RESTful APIs: Applications interact with FHIR resources using standard HTTP verbs: GET (read), POST (create), PUT (update), and DELETE (remove).
• SMART-on-FHIR: A standardized framework allowing third-party applications (mobile apps, clinical decision support tools) to run securely inside any compliant EHR without custom integration coding.
• Bulk Data Access: Enables population-level queries to export large datasets for quality reporting and clinical analytics.

---

Health Information Exchanges (HIE)

A Health Information Exchange (HIE) facilitates the secure mobilization of healthcare information across organizations within a region, state, or nationwide network. HIE infrastructure operates across three primary exchange models:

---

Master Patient Index (MPI) & Enterprise Master Patient Index (EMPI)

In distributed HIE networks and multi-hospital enterprises, patients often possess different local Medical Record Numbers (MRNs) at each facility. An Enterprise Master Patient Index (EMPI) maintains a cross-organizational registry that links local patient identifiers to a single global unique identifier (GUID).

Patient Matching Algorithms

1. Deterministic Matching: Compares exact character matches across static, unique identifiers (e.g., Social Security Number, exact First/Last Name, and Date of Birth). While deterministic matching yields high precision (virtually zero false positives), it suffers from low recall when records contain typos, transposed digits, or missing SSNs.
2. Probabilistic Matching: Uses statistical weighting models (such as the Fellegi-Sunter methodology) to evaluate multiple demographic attributes (Name, DOB, Gender, Address, Phone Number). Points are assigned based on field similarity, accommodating spelling variations, maiden name changes, and minor typographical errors.

Critical Patient Indexing Errors

• Duplicate Record: Creating a new, redundant chart for an existing patient due to matching failure, splitting their clinical history.
• Overlay Record: Incorrectly merging Patient B's incoming clinical data into Patient A's existing electronic chart due to flawed matching logic—a catastrophic patient safety event.