HL7 EVN Segment: Event Type

EVN records which trigger event fired and when. It immediately follows MSH in event-driven messages and answers two questions the rest of the message depends on: what happened, and when it was recorded. In modern HL7 v2 the "what" lives in the MSH-9 trigger event — EVN-1 once carried the same code but is now deprecated — while EVN-2 carries the recorded timestamp that anchors the event in time. EVN is small but central to ADT: it is the segment that turns a message into a dated, attributable event.

Purpose

EVN states the event that drove the message and the time it was recorded, and optionally why it happened, who recorded it, when it actually occurred, and at which facility. The trigger event itself is authoritatively carried in MSH-9; EVN-2 supplies the recorded date/time that the receiver uses for ordering and audit.

Used in

EVN appears in every ADT message — admits, discharges, transfers, updates, merges, and cancellations all carry it right after MSH. It is also used by a handful of other event-driven messages (for example BAR account events) that need to stamp the triggering event. See ADT messages for the event catalog; every ADT page opens with MSH followed by EVN.

Field-by-field reference

Source: official HL7 v2-to-FHIR IG. R = required (cardinality min ≥ 1). Repeat = field may repeat. Length pending authoritative v2.5.1 data.

Most-used fields

EVN-2 Recorded Date/Time is the field that matters most — it is the only required field and the timestamp receivers use to order and audit the event. It is distinct from MSH-7 (when the message was created) and from EVN-6 (when the event actually occurred).

EVN-1 Event Type Code is the historical anchor. It carried the trigger event (A01, A03, …) before MSH-9 became the source of truth. It is deprecated but still emitted by many systems, and it should agree with the MSH-9 trigger event.

EVN-4 Event Reason Code explains why the event fired — useful for downstream filtering and analytics. EVN-6 Event Occurred captures the real-world event time when it lags the recorded time.

Version differences (2.3 to 2.8.2)

• 2.3: EVN-1 Event Type Code marked deprecated. The trigger event is now driven by MSH-9; EVN-1 is retained only for backward compatibility, and EVN-2 becomes the meaningful required field.
• 2.3+: EVN-5 (Operator ID), EVN-6 (Event Occurred), and EVN-7 (Event Facility) are present, giving who/when/where context beyond the recorded time.
• 2.4 onward: date/time fields standardize on the DTM/TS long form with optional fractional seconds and timezone offset.
• 2.5 / 2.5.1: field set is stable at EVN-1 through EVN-7. Receivers built for 2.3 simply ignore trailing fields they don't know.
• 2.7 / 2.8.2: EVN-1 remains deprecated; no new fields. Engines should continue to treat MSH-9 as the trigger-event source and not rely on EVN-1.

Common mistakes

• Treating EVN-1 as the source of the trigger event instead of MSH-9 — and shipping an EVN-1 that disagrees with MSH-9.
• Omitting EVN-2, the one required field, or confusing it with MSH-7 (message create time) or EVN-6 (event occurred time).
• Assuming EVN follows every message — it belongs to ADT and other event-driven messages, not to ORU/ORM result and order flows.
• Hard-coding a timezone into EVN-2 instead of carrying the offset that the source system reports.

Examples

Minimal valid EVN (required field only):

EVN||20260609120000

Fully-populated EVN:

EVN|A01|20260609120000.000-0500|20260609090000|01^Patient request^HL70062|9988^SMITH^PAT^^^^^^HOSP^^^^XX|20260609115500|ICU^^HOSP_A

Annotated breakdown of the fully-populated example:

EVN                         ← segment ID
A01                         ← EVN-1  Event Type Code (deprecated; mirrors MSH-9)
20260609120000.000-0500     ← EVN-2  Recorded Date/Time (required)
20260609090000              ← EVN-3  Date/Time Planned Event
01^Patient request^HL70062  ← EVN-4  Event Reason Code
9988^SMITH^PAT^...^XX        ← EVN-5  Operator ID (who recorded the event)
20260609115500              ← EVN-6  Event Occurred
ICU^^HOSP_A                 ← EVN-7  Event Facility

In-context inside an ADT^A01 (admit):

MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120000||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|20260609120000
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
PV1|1|I|ICU^101^A|||||||MED

In-context inside an ADT^A03 (discharge):

MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609173000||ADT^A03^ADT_A03|MSG00042|P|2.5.1
EVN|A03|20260609173000|||01^Patient request^HL70062|20260609170000
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
PV1|1|I|ICU^101^A|||||||MED|||||||||||||||||||||||||20260601090000|20260609170000

FHIR mapping

Target resource: Provenance. Official ConceptMap: ConceptMap-segment-evn-to-provenance (JSON).

Not mapped: EVN-3 Date/Time Planned Event has no FHIR target in the IG ConceptMap.

Engine considerations

• Treat MSH-9 as the source of the trigger event. If EVN-1 is present, validate it against MSH-9 rather than trusting it on its own.
• EVN-2 is required: reject or flag messages that omit it, and preserve its timezone offset for accurate audit ordering.
• Distinguish three timestamps — MSH-7 (message created), EVN-2 (event recorded), EVN-6 (event occurred) — and map each to the correct downstream field instead of collapsing them.
• Failure mode: an EVN-1 that contradicts MSH-9 can split routing or analytics logic depending on which field a rule reads. Pin rules to MSH-9.

How Vorro parses and produces EVN

Vorro reads the trigger event from MSH-9 and uses EVN-1, when present, only as a consistency check, flagging any mismatch. On parse it captures EVN-2 as the authoritative recorded time, preserving the timezone offset, and keeps EVN-6 separate as the event-occurred time. On the produce side, Vorro stamps EVN-2 from the source event's recorded timestamp, mirrors the MSH-9 trigger event into EVN-1 for backward compatibility, and populates EVN-4 through EVN-7 from the channel's field map when the source provides reason, operator, occurrence, and facility.

Related pages

• MSH — the header whose MSH-9 trigger event EVN mirrors.
• PID — the patient identification segment that follows EVN in ADT.
• ADT messages — where EVN stamps each admit, discharge, and transfer event.

Sources

• HL7 v2-to-FHIR IG — segment maps index
• HL7 v2-to-FHIR IG — EVN to Provenance ConceptMap
• HL7 Version 2.5.1 product brief