HL7 EVN Event Type
HL7 field reference EVN fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
EVN is the event segment. You mostly meet it near the top of ADT messages, just after the MSH, where it gives extra information about the trigger event. If MSH-9 says "this is an ADT A02 transfer", EVN helps explain when that transfer was entered, why it happened, who triggered it, when it really occurred, and which facility it belongs to.
This segment is small, but it is very easy to read the dates casually and get the wrong timeline. MSH-7 is when the message was created. EVN-2 is when the event was recorded in the system. EVN-6 is when the event actually happened. Those can all be the same minute in a tidy demo message. In real hospitals, they can be different, and that difference is usually the whole point. When you inspect an ADT example in HL7 Soup Web, comparing those timestamps side by side is one of the quickest ways to spot a bad event story.
One other trap is EVN-1. Older messages often sent the event type code here, such as A04. In v2.5.1, the real trigger event should be taken from MSH-9.2, and EVN-1 is there for backward compatibility. If MSH says one event and EVN says another, do not shrug and pick your favorite. That is an interface defect that can change what the receiving system does.
So let's go through each of the EVN fields and talk about how they tend to behave in real interfaces.
This field is the historical place for the trigger event code. You may still see EVN|A04 in older ADT feeds, and if your receiver expects it then you may need to support it. But in modern v2.5.1-style messaging, MSH-9.2 is the better place to read the event type.
The practical rule is simple: if EVN-1 is populated, it should agree with MSH-9.2. An ADT^A02 message with EVN-1=A03 is not a charming bit of local flavor. It is a contradiction. I would rather log it loudly than quietly turn a transfer into a discharge.
Recorded time is when the event was entered into the system. Most systems will default it to the current system time, but the standard expects that it can be overridden. That matters when an event is entered after the fact.
Do not treat this as the same thing as MSH-7. MSH-7 is when the message was created. EVN-2 is when the user or source system recorded the event. If a transfer happened at 10:15, was keyed at 10:30, and the message left at 10:31, EVN-2 should be 10:30 and MSH-7 should be 10:31. Small difference, big meaning.
Planned time is for something expected to happen, not something that already happened. You see the idea around pre-admits, pending transfers, pending discharges, leave of absence returns, and other future-looking ADT workflows.
In many interfaces this field is empty, and that is fine. If the message also has PV2 expected admit, discharge, or leave dates, those may be the better homes for the plan. Use EVN-3 only when the receiving system has agreed that this is the planned event time it should pay attention to.
The reason code says why the event happened. The base table gives broad values such as patient request, physician or health practitioner order, census management, other, and unknown. Many real sites extend this locally because the useful reasons are often operational.
Keep the reason separate from the event. A03 says the patient was discharged. EVN-4 may say whether that happened because of a practitioner order, patient request, census management, or some local reason. It is not a diagnosis, not a discharge disposition, and not a place to bury a paragraph of explanation.
The operator is the person responsible for triggering the event. That might be a registrar, ward clerk, nurse, bed manager, interface user, or another authenticated user. It is not automatically the attending doctor, admitting doctor, or ordering provider.
Use XCN properly if you populate it. A staff ID with a name and assigning authority is much more useful than a bare display name. In audit-heavy workflows, EVN-5 can answer "who did this?" long after everyone has forgotten which workstation was used.
This is the time the event actually happened. For a transfer, it can be the time the patient was actually transferred. For a discharge, it can be the time the patient actually left or the discharge event took effect, depending on the local workflow.
Cancellation messages make this especially important. On a cancel transfer, this field should point at the time of the event being cancelled, not merely the time someone clicked cancel. If EVN-6 is blank, receivers often fall back to EVN-2 or message receive time, but that is a compromise. If your workflow cares about the true event timeline, send EVN-6.
Facility sounds like it should be obvious, right up until an enterprise interface engine, MPI, or regional hub starts rebroadcasting messages for several hospitals. MSH-4 tells you the sending facility. EVN-7 can tell you the actual facility where the event occurred.
This is useful when the system sending the message is not the same place where the patient was registered, transferred, discharged, or updated. In multi-facility setups, keep this value if you receive it. It can be the difference between "the central system sent the message" and "the event happened at City Hospital."