Skip to Content

HL7 FHIR integration for hospitals, laboratories and exchanges

HL7 v2 and FHIR R4 are the two standards a hospital meets when it connects to laboratories, radiology, pharmacy, payers and national exchanges. This is how they differ, where each is used in the region, and how Ventrecs scopes an interface.

What HL7 and FHIR are

HL7 version 2 describes how one healthcare system tells another that something happened: a patient was admitted, a test was ordered, a result is ready. A message is plain text made of segments, and the usual transport is MLLP, which has no security of its own, so it normally runs inside a VPN or wrapped in TLS.

FHIR comes from the same organisation but describes health data as resources, such as a Patient or a Claim, with a web API. Neither makes the other obsolete. The practical question for a hospital is which standard each partner publishes, and how to connect to all of them without building a separate system for each.

At a glance
HL7 v2
Delimited text messages: ADT, ORM, ORU, MDM, RDE, VXU. Usually carried over MLLP inside a VPN or TLS.
FHIR R4
Resources such as Patient, Encounter, Observation and Claim, as JSON or XML over HTTPS.
Used in the region
NPHIES in Saudi Arabia (FHIR R4.0.1), NABIDH in Dubai (HL7 v2.5) and Malaffi in Abu Dhabi (HL7-capable EMR)
Approach
One internal model, translated at the edge for each partner
HL7 and FHIR

Where you meet them

Laboratory analyzers, middleware, radiology and pharmacy systems, which mostly speak HL7 v2.
National and regional exchanges: NPHIES uses FHIR R4.0.1, NABIDH describes HL7 v2.5 and C-CDA, and Malaffi asks for an HL7-capable EMR sending ADT in real time.
Payers and applications that expect resources instead of messages, alongside v2 partners in the same hospital.
HL7 and FHIR

What data is exchanged

Patient identity and encountersADT messages in HL7 v2; Patient and Encounter resources in FHIR.
Orders and resultsORM and ORU messages in HL7 v2; ServiceRequest, Observation and DiagnosticReport in FHIR.
Prescriptions and documentsRDE and MDM messages in HL7 v2, as published by the partner.
Claims and eligibilityA FHIR Claim export and payer eligibility connectors over FHIR R4 or a generic REST interface.
HL7 and FHIR

What makes an interface work

A written specification

The standards are flexible, and flexibility is where problems come from.

  • Message types, fields and sample messages that hold no real patient data
  • A code-set mapping reviewed by the clinical owner of each code
  • The partner's own guide, profiles and CapabilityStatement as the source of truth

Acknowledgements and delivery

The sender must read the answer.

  • HL7 v2 acknowledgements: AA, AE and AR, or CA, CE and CR in enhanced mode
  • FHIR responses and polling where the programme defers them
  • Retries that do not create duplicates

Operations

Most failures are silent.

  • Monitoring that alerts a named person when messages queue, fail or stop
  • A named owner when the partner changes its specification
  • A downtime procedure and a way to resend
HL7 and FHIR

How Ventrecs handles it

Clinical system and transport kept apartThe hospital system records events as part of the patient record. HL7 v2 and other transports run in a separate integration layer.
FHIR R4-shaped resourcesPatient, Encounter, ServiceRequest, Observation, laboratory Observation and DiagnosticReport, and ImagingStudy are produced from a durable outbox for an approved integration service.
Scoped per projectMessage types, mappings, owners and the test plan are agreed with you and the partner, and tested in the partner's environment.
Durable outboxMessages leave through an outbox with retry, a transaction log and a reconciliation queue, so a deferred, rejected or missing response is a visible state with an owner.
How the connection is delivered

Each HL7 v2 or FHIR interface is built for your instruments and partners: scoped per project, tested in the partner's environment and signed off before go-live. Ventrecs produces FHIR R4-shaped resources, and each partner's profiles, value sets and test cases are added and tested per project.

Messages are carried by Ventrecs Connect. See how an integration is delivered, from scoping to monitoring. Ventrecs Connect · The integration lifecycle

HL7 and FHIR

Typical rollout steps

The same eight stages as every Ventrecs deployment, applied to this connection. How we deliver

  1. 1
    DiscoverConfirm with each partner which of your facility types must connect, and which messages or transactions apply.
  2. 2
    DesignAgree the message set, identifiers and code mappings, and name an owner for each interface.
  3. 3
    ConfigureSet up facilities, users, catalogues and the integration layer, with credentials held outside the clinical records.
  4. 4
    MigrateLoad the master data the exchange needs, such as facilities, clinicians and patient identifiers, and reconcile it.
  5. 5
    TestTest in the environment each partner provides, with synthetic data, including rejected and duplicate messages.
  6. 6
    TrainTrain the teams who watch the interface and fix the rejections.
  7. 7
    Go-liveCut over in phases with on-site support, and with sign-off from each partner where the operator requires it.
  8. 8
    HypercareClose monitoring in the first weeks, then hand-over to the agreed support process.
HL7 and FHIR

Sources

Operator and standards documents these statements rest on. Standards change, so work from the current version.

HL7 and FHIR

Questions we are asked

Should we use HL7 v2 or FHIR?

Use whichever each partner publishes. Keep one internal model and translate at the edge, with one mapping and one owner per partner.

What is MLLP?

The minimal lower layer protocol: a simple wrapper that tells the receiver where each HL7 v2 message starts and stops on a TCP connection. It has no security of its own.

Does Ventrecs support FHIR R4?

Yes. Ventrecs produces FHIR R4-shaped resources for an integration service, and each partner's profiles are added and tested per project.

Can Ventrecs connect to my analyzer or exchange?

Yes. We build each interface as a project: scoped with you and the partner, tested in the partner's environment, and signed off before go-live.

Talk to us about your setup

Tell us about your facility and current systems. We will reply within one working day.