The integration engineer
The job that keeps hospitals running and nobody notices until it stops: moving clinical data between systems that were never designed to talk, without losing meaning.
In one line
An integration engineer moves clinical data between systems that were never designed to talk to each other — and does it without losing the meaning. It is the least glamorous and most load-bearing job in health IT.
What the job really is
A hospital is not one system. It's an EHR, a lab system, a radiology system, a pharmacy system, a billing system, three departmental databases someone built in 2009, and a machine in the base- ment nobody will let you turn off. Each was bought separately, from a different vendor, in a different decade. Care requires them to agree about a patient.
Nobody agrees. You make them.
The daily reality:
- HL7 v2 — still, in 2026, how most hospital systems actually talk. Pipes and carets, ADT feeds, ORU results. It is not legacy; it is load-bearing.
- FHIR — where new work goes, and where the APIs are.
- The interface engine — routing, transforming, queueing, retrying.
- Mapping — this system's
M/F/Uto that system'smale/female/unknown; this lab's local code to LOINC; this MRN to that ABHA.
The skill that separates good from adequate
Anyone can transform a field. The engineers worth hiring are the ones who ask "what happens when this is wrong?" — because it will be, and the answer decides whether someone gets hurt.
Consider a real shape of problem. An ADT feed drops for forty minutes. When it returns, do you: replay everything and risk duplicate encounters; skip the gap and leave records missing; or reconcile? Each choice has a clinical consequence. Duplicates mean a patient appears twice and their allergy list is split across both. Gaps mean the allergy never arrives at all.
That's the job. Not the mapping — the failure modes:
- Messages arriving out of order — a discharge before the admission it belongs to.
- Duplicates — the same result twice, because the sender retried.
- Silent truncation — a field longer than the target column, quietly cut. The name still looks like a name. It's just the wrong one.
- Character encoding — the reason Indian names arrive as question marks, and why nobody notices until a patient does.
- The unit that wasn't checked — the value transferred perfectly. It was mg/dL. The target expected mmol/L. See UCUM.
The last one is the whole discipline in miniature: a technically flawless transfer that lost the meaning is a failure, and it's the failure your monitoring won't catch.
Why the career is durable
Two forces protect it:
Hospitals don't rip and replace. They accrete. Every new system joins the old ones rather than retiring them, so the number of interfaces only grows. The 2009 database will outlive your tenure.
Standards multiply rather than converge. FHIR did not kill HL7 v2 — it joined it. Now you need both, plus the bridge between them. The same will be true of the next standard.
And in India specifically, the ABDM build-out is creating this role at national scale: HIP and HIU integrations, consent state machines, NRCeS-profiled bundles. That work barely existed five years ago.
Getting in
Learn HL7 v2 properly — not because it's beautiful, but because it's where the jobs are and most newcomers skip it for FHIR and are then useless on their first day. Then FHIR, then mapping, then the failure modes.
Practise on the HL7 explainer, integration engine and FHIR labs here: they run on synthetic messages, so you can break the pipeline, replay the gap, and watch what duplicates do — which is the only way anyone actually learns this. Then show it in a portfolio. An engineer who can talk fluently about how they handled an out-of-order ADT feed is hired ahead of one with a certificate and no scars.