HL7 v2 EVN Segment Guide: Fields, Format, and Testing Gotchas
EVN looks like the simplest segment in an ADT message, right up until a test run fails because two systems disagree on when an event actually happened.
EVN (Event Type) rides at the top of ADT and similar trigger-event messages and answers one question: what happened, and when did it get recorded. It carries the event code, a recorded timestamp, an optional reason code, who or what triggered the update, and a separate timestamp for when the event actually occurred in the real world (as opposed to when the message was built). Test suites care about EVN because its timestamps are a common source of off-by-one and timezone bugs, and because EVN-1 is often redundant with MSH-9 in modern interfaces.
The fields that actually matter in practice
Example
A synthetic admit event: recorded at 07:30 but flagged as having occurred at 07:25, five minutes earlier, with operator 8842 tagged as the trigger.
Where this trips people up
The most common bug we see in synthetic ADT test suites is teams treating EVN-2 and EVN-6 as interchangeable. They are not: EVN-2 is when the message was recorded, EVN-6 is when the event happened in reality, and interfaces that backfill or replay events (like a late-entered admission) can have a meaningful gap between the two. If your test data generator always sets them equal, you will never exercise the code path that handles a delayed or corrected timestamp, which is exactly the kind of edge case that surfaces in production during a system cutover.