ADT Trigger Events & Patient Workflow

How Vital uses the ADT feed

Vital ingests your full, unfiltered ADT feed. We support all event types and all

segments and fields — there is no custom, Vital-specific message subset you need to build.

What matters for your integration is understanding how the events you already send map to the patient's journey in Vital. The ADT feed is responsible for creating the visit, matching the patient, and tracking status from arrival through discharge. Specific trigger events tell Vital when to start a visit, when to update it, and when to end it.

Trigger events and what they do

The table below groups the ADT events by the workflow action they drive. Every event is processed; the ones below are the ones that move the patient through the experience.

Feed	Message type	Powers
Start the visit	`A04` Register · `A01` Admit · `A05` Pre-Admit	Creates the visit, matches/identifies the patient, sets language, and — if the patient is eligible and not opted out — sends the invite to the experience.
Keep the visit current	`A08` Update · `A02` Transfer · `A09` Departing (tracking) · `A10` Arriving (tracking) · `A06`/`A07` Class change	Updates demographics, location, care team, and visit status. Location changes also drive wait-time predictions and step tracking.
End the visit	`A03` Discharge · or admit/transfer out of an in-scope ED location	Ends the visit, records the outcome from the discharge disposition, and triggers post-visit follow-up where configured.
Corrections	`A11` Cancel admit · `A12` Cancel transfer · `A13` Cancel discharge	Reverses the corresponding action so the visit state stays accurate.
Record management	`A40`/`A41` Merge patient · `A42` Merge visit · `A43`/`A44`/`A45` Move · `A23`/`A29` Delete	Merges, moves, or removes records using the MRG segment so identity and visit history remain correct.
Deceased patient	`PID.29` / `PID.30` (with discharge disposition)	Marks the patient as deceased and suppresses further messaging.

In short: register/admit starts the visit, updates and transfers maintain it, and

discharge (or a move out of the ED) ends it.

How Vital knows when the ED visit ends

For Vital Emergency, we track the visit by filtering on location — PV1.3.1 (assigned

location) and PV1.6.1 (prior location) — against your in-scope ED department values.

This lets us end the visit as soon as the patient is admitted or transferred out of the ED, even before a formal discharge event arrives. (For Vital Inpatient, the same logic applies to the in-scope inpatient departments.)

The feeds that drive in-visit patient updates

ADT establishes and tracks the visit. The step-by-step updates a patient sees during the visit come from the other HL7v2 feeds:

Feed	Message type	Powers
Diagnostic Orders	`ORM^O01`	"Tests ordered" updates and video education
Diagnostic Results	`ORU^R01`	Patient-friendly results and imaging AI summaries
Clinical Notes	`MDM^T02` (or `ORU`)	Patient timeline updates and the discharge summary
Clinical Flowsheets	`ORU`	Triage/status signals and wait-time predictions

See Diagnostic Orders, Diagnostic Results, Clinical Notes, and Clinical Flowsheets for the minimum specs on each.

Keeping records linked across feeds

For Vital to correctly link every message to the right patient and visit, a few identifiers must be consistent across all interfaces and feeds:

Visit Number (PV1.19) — and the alternate visit ID (PV1.50) if you send one.
MRN (PID.2 / PID.3) at both the facility and enterprise level, with the identifier
type code specified.
Order ID (OBR-2) and Order Code (OBR-4.1) — consistent between Orders and Results.