The vocabulary of hospital integration.

HL7 v2 is the pipe-delimited messaging standard that carries most clinical data between hospital systems.

A message is a series of segments, one per line, each identified by a three-character code such as MSH, PID, or OBX. Segments contain fields separated by pipes, which in turn contain components separated by carets. Despite FHIR's growth, HL7 v2 still carries the overwhelming majority of real hospital interface traffic, and versions from 2.1 through 2.8 remain in production simultaneously.

FHIR is a REST-based interoperability standard that models clinical concepts as addressable resources such as Patient, Observation, and Encounter.

R4 is the version most widely deployed in production and the one referenced by US regulation. A FHIR server advertises what it supports through a CapabilityStatement, which is the practical starting point when assessing whether an integration will work.

DICOM is the standard for medical imaging, covering both the image format and the network protocol used to move studies between modalities and archives.

Each object carries extensive metadata alongside pixel data. A modality worklist (MWL) query lets an imaging device fetch its scheduled procedures, which is why worklist failures surface immediately as technologists typing patient details by hand.

X12 is the EDI standard used for US healthcare administrative transactions, including claims, remittance, and eligibility.

The transaction sets most often seen are 837 (claim submission), 835 (remittance advice), 270/271 (eligibility inquiry and response), and 276/277 (claim status). Envelopes are structured as ISA and GS headers wrapping one or more ST transaction sets.

NCPDP is the standard governing retail pharmacy transactions, including prescription claims and eligibility.

It is distinct from X12 and is used for the pharmacy benefit path rather than the medical benefit path, which is why pharmacy claims often travel a completely separate interface route from medical claims.

MLLP (Minimal Lower Layer Protocol) is the framing protocol used to send HL7 v2 messages over a raw TCP connection.

It wraps each message in start and end block characters so the receiver knows where one message ends and the next begins. MLLP has no built-in authentication or encryption, which is why it is normally confined to internal networks or tunnelled.

ADT (Admit, Discharge, Transfer) messages communicate patient demographics and movement, and are the backbone feed of most hospitals.

Event types such as A01 (admit), A03 (discharge), A08 (update), and A40 (merge) drive downstream registration in nearly every connected system. When ADT breaks, everything else breaks shortly afterwards.

ORU messages carry observation results — most commonly laboratory results — from a producing system to the ordering or receiving system.

Results are structured as OBR (order) segments each followed by one or more OBX (observation) segments. A dropped ORU is a result a clinician never sees.

DFT (Detail Financial Transaction) messages carry billable charges from clinical systems into billing.

Because charges travel as interface messages, a silently failing DFT feed produces unbilled revenue that is rarely traced back to the integration layer. Counting DFT messages at both ends is the fastest way to detect it.

An interface engine is the middleware that routes, transforms, and delivers messages between clinical systems.

It typically owns connection handling, message transformation, queuing, and retry. Because it sits between every system, its configuration is the single most accurate description of how a hospital's data actually flows — and it is usually the least documented.

An interface estate is the complete set of live interfaces in an organisation, together with what each one connects and what depends on it.

Estates commonly run from dozens to several hundred interfaces. The practical problem is not building one interface but knowing what the other two hundred will do when you change a field.

A Z-segment is a custom, site-defined HL7 segment beginning with the letter Z, used for data the standard does not define.

Z-segments are legitimate and extremely common, but they are undocumented by definition — no published specification describes their contents, so their meaning lives only in local knowledge and in the interface configuration itself.

A conformance profile constrains a broad standard into the specific subset an organisation actually requires.

Standards like HL7 v2 and FHIR permit far more than any single deployment uses. A profile records which segments, fields, and value sets are mandatory locally, turning 'valid HL7' into 'valid here'.

An MRN (Medical Record Number) is the identifier a facility assigns to a patient within its own systems.

MRNs are local, not universal. Multi-facility organisations routinely carry several identifiers for one person, which is why identifier mapping in PID-3 is a frequent source of interface defects and duplicate records.

Alert on silence is monitoring that fires when an expected feed stops producing traffic, rather than when it produces an error.

Conventional monitoring watches for failures. The more dangerous failure mode is a feed that simply goes quiet: queues drain, dashboards stay green, and nothing alarms until someone downstream notices missing data hours or days later.

A dead-letter queue holds messages that could not be delivered after exhausting their retry policy, so they can be inspected and resent rather than lost.

Its depth is one of the few honest health metrics for an interface: a growing dead-letter queue means real clinical or financial data is not arriving.

A shadow run executes a proposed interface alongside the existing one on the same live traffic while delivering nothing, so the two outputs can be compared before cutover.

The output is a divergence report: what the new route would have sent versus what the current one actually sent, with any difference located to the exact field. It converts a migration from a scheduled risk into an observation with a number at the end.

A deployment gate is an automated check that decides whether an interface change is allowed to reach production, based on recorded evidence.

A useful gate distinguishes a genuine failure from an inability to evaluate. Returning INDETERMINATE when evidence is missing — rather than defaulting to pass — is what keeps an untested change from shipping.