Interoperability Standards

HL7v2, FHIR R4, DICOM, IHE profiles, and API patterns -- what every healthcare ERP functional consultant must understand about data exchange between hospital...

February 2026 · 20 min

Manual area

FC Training Programme

Coverage

8 sections

Operator notes

4 implementation notes

Why Interoperability Matters

A hospital never operates in isolation. Lab analysers send results, PACS stores images, insurance portals expect claims, government registries demand notifications, and patients move between facilities. Interoperability is the ability of these disparate systems to exchange data and use it meaningfully.

As an FC, you will encounter interoperability in every implementation:

Configuring lab instrument interfaces
Mapping radiology orders to PACS/RIS
Setting up insurance e-claim submissions
Enabling ABDM health record sharing
Integrating third-party pharmacy or blood bank systems

Understanding the standards below is not optional -- it is the foundation of every integration conversation you will have.

HL7v2 -- The Legacy Workhorse

HL7 Version 2 (Health Level Seven) has been the dominant messaging standard in healthcare since the 1990s. Most lab instruments, bed-side monitors, and legacy HIS systems still speak HL7v2.

Key Concepts:

Concept	Explanation
Message	A pipe-delimited text payload (e.g., `MSH\|^~\\&\|...`)
Segment	A line starting with a 3-letter code (MSH, PID, OBR, OBX, etc.)
Trigger Event	The reason the message was sent (ADT^A01 = admission, ORM^O01 = order, ORU^R01 = result)
Encoding	Pipe `\|` separates fields, caret `^` separates components
Acknowledgement	Receiving system replies with ACK or NAK

Most Common Message Types in a Hospital:

ADT^A01 / A02 / A03 -- Admit, Transfer, Discharge
ORM^O01 -- Order message (lab, radiology)
ORU^R01 -- Observation result (lab result back to HIS)
SIU^S12 -- Scheduling information (appointment updates)
DFT^P03 -- Detailed financial transaction (charge posting)

FC Relevance: When integrating Bio Ecko with a lab analyser, you will configure HL7v2 ORM/ORU mappings. You don't write the parser -- the Integration Hub handles it -- but you must understand which fields map where.

FHIR R4 -- The Modern Standard

FHIR (Fast Healthcare Interoperability Resources) R4 is the modern REST-based standard replacing HL7v2 for new integrations. ABDM mandates FHIR R4.

Core Concepts:

Concept	Explanation
Resource	A discrete data unit (Patient, Encounter, Observation, MedicationRequest, etc.)
Bundle	A collection of Resources sent together (e.g., a discharge summary Bundle)
RESTful API	Standard CRUD: `GET /Patient/123`, `POST /Observation`, `PUT /Encounter/456`
Profiles	Constraints on a Resource for a specific use case (ABDM defines India-specific profiles)
Extensions	Custom fields added to a Resource when the base spec lacks a needed attribute
Terminology Binding	Resources reference coded systems (ICD-10, LOINC, SNOMED-CT)

FHIR vs HL7v2 Comparison:

Aspect	HL7v2	FHIR R4
Format	Pipe-delimited text	JSON or XML
Transport	TCP/MLLP	HTTPS REST
Learning Curve	High (cryptic encoding)	Moderate (standard REST)
Adoption	Legacy systems, instruments	New integrations, ABDM, mobile
Extensibility	Limited	Rich (Profiles + Extensions)
Tooling	Mirth Connect, Rhapsody	HAPI FHIR, SMART on FHIR

FC Relevance: For ABDM integration, you configure which FHIR resources Bio Ecko generates. For third-party app integrations, you may configure FHIR API access scopes.

DICOM -- The Imaging Standard

DICOM (Digital Imaging and Communications in Medicine) is the universal standard for medical images -- X-rays, CT scans, MRIs, ultrasounds.

Key Concepts:

Concept	Explanation
DICOM Object	An image file with embedded metadata (patient name, modality, body part, date)
Modality	The imaging device type: CR (X-ray), CT, MR, US, MG (mammography), etc.
PACS	Picture Archiving & Communication System -- the server that stores/retrieves DICOM images
Worklist (MWL)	Modality Worklist -- the radiology order list sent from HIS to the imaging device
DICOM Tags	Metadata fields identified by group/element numbers (e.g., 0010,0010 = Patient Name)
WADO-RS	Web Access to DICOM Objects -- REST API to fetch images from PACS

How It Works in a Hospital:

Doctor orders an X-ray in Bio Ecko
Bio Ecko sends a Modality Worklist (MWL) entry to the X-ray machine
Technician selects the patient from the worklist on the machine -- no re-typing needed
Machine acquires the image and sends the DICOM file to PACS
Radiologist views the image from PACS, writes the report in Bio Ecko
Bio Ecko links the report to the PACS study via Study Instance UID

FC Relevance: You configure the MWL mapping (which Bio Ecko fields map to which DICOM tags) and the PACS connection parameters (IP, port, AE Title). You don't handle DICOM parsing directly.

IHE Profiles -- Integration Recipes

IHE (Integrating the Healthcare Enterprise) does not create new standards. Instead, it publishes profiles -- step-by-step recipes for using HL7v2, FHIR, and DICOM together to solve specific integration problems.

Profiles Relevant to Bio Ecko:

IHE Profile	Full Name	What It Solves
PIX / PDQ	Patient Identity Cross-reference / Demographics Query	Finding a patient across multiple systems using MRN or demographics
SWF	Scheduled Workflow	Radiology order → worklist → image acquisition → result reporting
XDS.b	Cross-Enterprise Document Sharing	Sharing clinical documents (discharge summaries, reports) across facilities
PAM	Patient Administration Management	ADT messaging (admit, transfer, discharge)
LTW	Laboratory Testing Workflow	Lab order → specimen → analyser → result → validation
ATNA	Audit Trail and Node Authentication	Security logging for all health data access

FC Relevance: When a vendor says their system is "IHE SWF compliant," you know exactly what integration flow to expect. Use IHE profiles as a checklist during integration testing.

API Patterns in Bio Ecko

Bio Ecko exposes and consumes integrations via several API patterns:

Pattern	Used For	Example
Supabase Realtime	Internal live updates (bed board, queue)	Ward dashboard subscribes to admission changes
REST API (Next.js Route Handlers)	External system integration	Insurance portal posts claim status updates
HL7v2 via Integration Hub	Lab analyser, bed-side monitor	Analyser sends ORU^R01 with results
FHIR R4 via ABDM Gateway	National health record exchange	Discharge summary shared as FHIR Bundle
DICOM MWL via Radiology Bridge	Modality worklist to imaging devices	X-ray machine pulls today's orders
Webhooks (outbound)	Notifications to external systems	SMS gateway notified on appointment confirmation

FC Configuration Points:

Integration Hub: enable/disable interfaces, map fields, set retry policies
ABDM Gateway: credentials, record types, consent policies
Radiology Bridge: PACS connection, AE titles, MWL field mapping
Webhook Manager: target URLs, event triggers, authentication headers

Data Mapping -- The FC's Core Integration Skill

The most common integration task for an FC is data mapping -- deciding which field in System A corresponds to which field in System B.

Mapping Template:

Source System	Source Field	Target System	Target Field	Transform
Bio Ecko	`patients.first_name`	HL7v2	PID-5.1 (Family Name)	Direct copy
Bio Ecko	`patients.date_of_birth`	FHIR	Patient.birthDate	Format: YYYY-MM-DD
Lab Analyser	OBX-5 (Result Value)	Bio Ecko	`lab_results.result_value`	Parse numeric
PACS	Study Instance UID	Bio Ecko	`radiology_studies.study_uid`	Direct copy

Best Practices:

Always document the mapping in a spreadsheet before configuring
Include data type, length constraints, and transformation rules
Identify mandatory vs optional fields
Plan for edge cases: null values, special characters, encoding mismatches
Test with real sample data from the source system, not fabricated data

Integration Testing Checklist

Before signing off any integration during UAT:

Happy Path -- Standard message flows correctly end-to-end
Boundary Values -- Max-length patient names, special characters (accents, apostrophes), future dates
Error Handling -- What happens when the target system is down? (queue, retry, alert)
Duplicate Handling -- Same message sent twice does not create duplicate records
Encoding -- UTF-8 characters pass through correctly (Hindi, Tamil, Urdu names)
Volume -- Simulate peak-hour load (e.g., 200 lab results in 10 minutes)
Security -- TLS encryption, authentication tokens, IP whitelisting verified
Audit -- Every inbound/outbound message is logged with timestamp, status, and payload hash
Rollback -- If integration fails mid-go-live, manual workaround is documented

Notes

Info

You do not need to be a developer to understand these standards. Focus on the concepts, message types, and field mappings -- the technical plumbing is handled by the Integration Hub and ABDM Gateway.

Tip

When talking to a lab analyser vendor, ask: 'Which HL7v2 message types do you support, and can you share a sample ORU message?' This single question fast-tracks the entire integration discussion.

Warning

Never assume two systems using the same standard (e.g., both HL7v2) will integrate seamlessly. Version differences, custom Z-segments, and field-level interpretation vary widely between vendors.

Clinic tip

For small clinics without PACS, radiology images may be stored as JPEG/PDF uploads in Bio Ecko's document manager rather than via DICOM. Confirm the imaging setup during discovery.