A field guide for integrating LIS platforms with hospital systems using HL7 v2 and FHIR while preserving traceability and operational safety.
Hospital integration is heterogeneous by design. A typical lab network we work with has analyzers from four vendors (Roche, Sysmex, Abbott, Mindray), some speaking HL7 v2.5 over MLLP, some still emitting CSV over RS-232, an HIS that exposes a partial FHIR R4 API for orders but expects HL7 v2 ORU for results, and a billing system that lives in Excel until something breaks.
This guide is the field-tested integration pattern from a clinical lab network deployment where analyzer onboarding dropped from 6–10 weeks to 4 days and the ISO 15189 non-conformity around result traceability was closed.
The topology that works
The integration broker (we use Mirth Connect for greenfield, Rhapsody if the customer already has it) is the only thing that speaks HL7 v2 and serial protocols. The LIS core only speaks JSON over an internal contract. This separation is non-negotiable — mixing HL7 parsing into business logic is how you get bugs that take three weeks to find.
HL7 v2 — the parts that matter
Despite being a 1990s standard, HL7 v2 is what 95% of analyzers and HIS systems still speak. Three message types cover most of the work:
- **ORM^O01** — order from HIS to LIS ("run this test on this sample").
- **OUL^R22** or **ORU^R01** — result from analyzer/LIS back to HIS.
- **ADT^A08** — patient demographic updates.
The traps are in the OBX segments — different analyzers encode units differently ("mg/dL" vs. "mg/dl" vs. "mg per dL"), reference ranges are sometimes in OBX-7 and sometimes in a custom Z-segment, and patient identifiers split across PID-3 repetitions in ways that vary by HIS vendor. The broker must normalize aggressively before the LIS sees the message.
FHIR — where to use it
FHIR R4 is excellent for outbound APIs to modern consumers (patient apps, public health reporting, regional health information exchanges). It is a poor fit for analyzer integration — no analyzer speaks FHIR natively, and writing a translator in both directions doubles the surface area.
Our rule: HL7 v2 inside the hospital, FHIR at the perimeter. The LIS exposes ServiceRequest, Observation, DiagnosticReport, and Patient resources over a FHIR API for external consumers; internal flows stay on HL7.
The four controls that prevent incidents
- **Message idempotency.** Every inbound message gets a deterministic ID (MSH-10 + sending facility + control segment hash). Duplicate IDs are de-duped at the broker, never reach the LIS. Without this, an analyzer reboot during a result burst produces duplicate results.
- **Patient identity reconciliation.** When PID-3 doesn't match a known patient, the message goes to a reconciliation queue, not the LIS. A clinical user resolves it within an SLA (we use 15 minutes for stat orders, 4 hours for routine).
- **Timestamp normalization.** Analyzers report local time without timezone. We attach the analyzer's configured timezone at broker ingress and convert to UTC before storage. This single change eliminated 80% of "why is this result dated tomorrow" tickets.
- **Exception queue with clinical escalation.** Any message that fails validation goes to a queue visible to lab supervisors, with a counter on the dashboard. Silent failures are how you fail an audit.
Operational discipline
We run a weekly "integration health" review with: message volume per interface, error rate, queue depth, p95 latency. Anything trending wrong gets an owner that week. This is unglamorous and indispensable.
Closing
Hospital integration is not a one-time project. It's an operational practice. Get the broker pattern right, normalize aggressively at the edge, expose FHIR only outward, and run the weekly health review religiously — that's the recipe.
