Interoperability

Breaking the “Islands of Care”

A major bottleneck is that healthcare systems often work in silos. To bridge these gaps, we must understand the Levels of Interoperability (as defined by HIMSS):

• Level 1: Foundational: Establishing basic data exchange (e.g., lab results sent to an EHR).
• Level 2: Structural: Ensuring syntactic data formatting (e.g., HL7 message structures) so data is in a readable format.
• Level 3: Semantic: Preserving meaning during exchange. Standards like SNOMED CT ensure that “CVA” in one system is understood as “Stroke” in another.
• Level 4: Organizational: Encompassing the policies, processes, and governance that enable coordinated care across different legal and social entities.

---

Institutional Sentiment: The Integration Barrier

Identifying the “why” behind the silos is as critical as the “how” of the standards. During the session, workshop participants were asked to rank the most significant hurdles in their daily operations.

Figure: Audience Poll Result: Participants rank the lack of common standards and high manual mapping effort as the primary barriers to HIS-Lab integration.

The Standards Paradox (HL7 v3 vs v2.7)

Interoperability is often hampered by Versioning Conflict. While national missions advocate for modern standards (FHIR), many legacy hospital systems (LIS/RIS) still run on HL7 v2.x.

• Data Integrity Risk: Forcing a match between HL7 v3 (XML) and HL7 v2.7 (Pipe-delimited) can lead to “semantic slippage,” where critical clinical flags or lab nuances are lost during translation.

• The Middleware Requirement: Successful HIE implementation requires robust Intermediate Mapping Layers that can handle these versioning mismatches without data loss.

• The Intent Problem: Interoperability is often more of an “intent” problem than a technical one. A major cultural shift required is moving from institutional competition to a spirit of Collaboration.

---

The 7 Core Care Contexts

ABDM defines 7 primary care contexts that represent the most common clinical interactions requiring data exchange:

• OPD Consultation: For standard outpatient visits.
• IPD Admission: For inpatient stays and procedures.
• Diagnostic Test: For lab and imaging results.
• Prescription: For digital medication orders.
• Immunization: For vaccination events.
• Wellness/Health Record: For wearable and telemetry data.
• Pharmacy Invoice: For proof of medication purchase.

Each context is backed by standardized FHIR resource types ensuring semantic interoperability across the ecosystem.

Mandatory FHIR R4: The Integration Baseline

For any HIS or EMR to interact with the national HIE, it must undergo a specific type of integration.

• Strict Compliance: ABDM, in collaboration with NRCeS, has mandated HL7 FHIR R4 as the only acceptable standard for data exchange.
• Resource Definition: Whether it’s a vaccine certificate or a pharmacy invoice, every HI type is modeled as a FHIR resource (e.g., Patient, Observation, DiagnosticReport), ensuring that data is self-describing and semantically rich.
• CCD (v1.0): For Continuity of Care Documents.

OPD Success vs. The CDA Challenge

India has seen massive success in digitizing Out-patient (OPD) registration and summaries. However, the next frontier is the Clinical Document Architecture (CDA):

• OPD (Snapshot): Success is driven by simple, structured summaries.
• Inpatient (Narrative): Complex inpatient care requires a more robust CDA/CCR (Continuity of Care Record) framework to capture the longitudinal depth of a patient’s stay, which remains a significant implementation hurdle for most hospitals.