HL7 ADT Explained: What an ADT Feed Actually Does for a Nurse Call System

What is HL7 ADT?

HL7 ADT is the family of messages a hospital or aged care system sends to announce that a patient has been admitted, discharged or transferred. ADT stands for Admit, Discharge, Transfer. An "ADT feed" is a continuous stream of those messages, published by the system that owns patient movement — usually the patient administration system (PAS) or the electronic medical record (EMR) — and consumed by whichever other systems need to know who is currently in which bed.

That last phrase is the whole point. Plenty of systems in a healthcare facility are useless, or actively misleading, unless they know who is in which bed. A nurse call platform is one of them.

Why a nurse call system cares

A traditional nurse call system knows locations, not people. It knows that Bed 12A is calling. It does not know who is in Bed 12A, and it has no way of finding out except for a staff member typing a name into a panel or a spreadsheet, then remembering to change it when the patient moves.

In practice that means one of three things happens. Names are entered once and drift out of date. Names are never entered at all, and the system stays location-only. Or names are maintained diligently by a nurse who has better things to do.

An ADT feed removes the choice. Admissions, transfers and discharges arrive automatically, so the bed carries the right patient context without anyone re-keying anything — and, just as importantly, the context clears itself when the patient leaves.

The trigger events that matter

ADT messages are distinguished by a trigger event code. There are dozens in the standard; a handful do almost all the work in a nurse call context:

• A01 — Admit / visit notification. A patient has been admitted. This is what populates a bed.
• A02 — Transfer a patient. The patient has moved. Context moves with them, from the old bed to the new one.
• A03 — Discharge / end visit. The patient has left. The bed clears.
• A04 — Register a patient. Common in outpatient and emergency contexts rather than inpatient wards.
• A08 — Update patient information. Something about the patient record changed. Often a name correction, and more common than people expect.

Then there are the ones that get forgotten in scoping meetings and cause problems six months later:

• A11 — Cancel admit. The admission was entered in error.
• A12 — Cancel transfer. The move did not happen after all.
• A13 — Cancel discharge. The patient was marked as discharged and then was not.

If a receiving system handles A01, A02 and A03 but ignores the cancellations, it will eventually show a patient in a bed they were never in, or an empty bed that is occupied. Ask about the cancel messages specifically.

What is actually inside the message

HL7 version 2 messages are plain text, pipe-delimited, and organised into segments. A typical ADT message uses four:

• MSH — message header. Who sent it, who it is for, when, which message type and which HL7 version.
• EVN — event type. The trigger event and when it occurred.
• PID — patient identification. The patient identifier and name, among a great many optional fields.
• PV1 — patient visit. Visit-level detail, including the assigned patient location.

For a nurse call platform, the important field is PV1-3, the assigned patient location. It is a composite field carrying point of care, room and bed, plus facility. That is the field that ties a human being to a physical bed, and it is where most integration problems live.

The bed naming problem

Here is the failure mode that catches more projects than any protocol issue.

The PAS calls a bed one thing. The nurse call system calls it another. The PAS might send ROSE^07A^1 while the nurse call system, commissioned in 2009 by a different contractor, knows that same bed as Ward 3 / Room 7 / Bed A. Neither is wrong. They simply were never reconciled, because until now nothing needed them to agree.

Resolving that is not a technical problem so much as a clerical one, and it is real work. Someone has to walk the wards with both lists. It is worth budgeting for it explicitly rather than discovering it during commissioning, and it is the first thing we check when scoping an ADT integration.

How the feed is delivered

ADT messages are typically carried over MLLP — the Minimal Lower Layer Protocol — which wraps each message in start and end characters and sends it over a plain TCP connection. Most sites do not connect systems to each other directly. They run an integration engine such as Mirth, Rhapsody or Cloverleaf in the middle, which subscribes to the feed once and distributes it to everything that needs it, transforming as required.

That is a good arrangement for everyone. The receiving system is one more subscriber rather than one more direct connection to the PAS, and the engine gives the site a single place to see, filter and audit what is being shared.

Each message is acknowledged. The receiver returns an ACK containing an MSA segment, which either confirms the message was accepted or reports that it was rejected. Acknowledgement matters more than it sounds: it is how a site knows the feed is genuinely being consumed rather than quietly failing into a socket nobody is watching.

Share the minimum

A full ADT message can carry a great deal about a person — dates of birth, addresses, next of kin, insurance detail. A nurse call platform does not need most of it.

The right posture is to take the identifier, the display name and the location, and to ask the integration engine to strip the rest before it ever arrives. It reduces what sits on a ward system, it makes the privacy conversation with your health information team much shorter, and it costs nothing to specify up front. It is far harder to walk back once a feed is live.

Worth deciding early, too: what actually appears on a corridor screen. A name on a display in a public corridor is a different privacy question from a name on a nurse-base dashboard, and the answer usually differs by ward.

What to ask before you commit

If a vendor is proposing an ADT integration, these questions separate a considered design from an optimistic one:

• Which trigger events do you consume — and do you handle A11, A12 and A13?
• Which HL7 version, and which fields do you read from PID and PV1?
• How is bed mapping between our PAS and the nurse call system established and maintained?
• What happens if the feed stops? Does the system flag it, or keep displaying yesterday's occupancy as though nothing is wrong?
• What data can be stripped before it reaches the platform, and how long is anything retained?
• Does the integration run through our existing integration engine?

The fourth one is the one to press hardest. A stale feed is more dangerous than no feed, because a screen that is confidently wrong is trusted in a way that a blank field is not.

The other direction

ADT is inbound — context arriving at the nurse call platform. The traffic can also run the other way: call and response events published back out, so that the clinical record reflects what happened on the ward rather than living in a separate system nobody reconciles.

Done together, the two directions are what stop a nurse call platform being an island. Beds know who is in them, and response-time reporting comes from one source rather than two that disagree with each other.

We have set out how this works on our nurse call integration page, including the data flow in both directions and the other interfaces a gateway can read. If you are scoping an integration and want a straight answer about what your systems can actually expose, book a site assessment or call us on 03 7504 7011.