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.
- 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
Where you meet them
What data is exchanged
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
How Ventrecs handles it
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
Typical rollout steps
The same eight stages as every Ventrecs deployment, applied to this connection. How we deliver
- 1DiscoverConfirm with each partner which of your facility types must connect, and which messages or transactions apply.
- 2DesignAgree the message set, identifiers and code mappings, and name an owner for each interface.
- 3ConfigureSet up facilities, users, catalogues and the integration layer, with credentials held outside the clinical records.
- 4MigrateLoad the master data the exchange needs, such as facilities, clinicians and patient identifiers, and reconcile it.
- 5TestTest in the environment each partner provides, with synthetic data, including rejected and duplicate messages.
- 6TrainTrain the teams who watch the interface and fix the rejections.
- 7Go-liveCut over in phases with on-site support, and with sign-off from each partner where the operator requires it.
- 8HypercareClose monitoring in the first weeks, then hand-over to the agreed support process.
Sources
Operator and standards documents these statements rest on. Standards change, so work from the current version.
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.