HL7 VAR Segment: Variance

VAR records a variance — a documented difference between what was planned or expected and what actually happened. It is a small, self-contained segment used in patient-care workflows: a clinical pathway step that ran late, a goal that drifted from its target, or a scheduled activity that deviated from plan. VAR does not stand alone as a message; it attaches to the entity it qualifies (a pathway, goal, role, or scheduled activity) and answers four questions: which variance instance this is, when it was documented, who documented it, and how it is classified. It was introduced around v2.5 as part of the patient-care chapter.

Purpose

VAR captures the data needed to describe a deviation that occurred when a healthcare event was documented. It identifies the variance instance, records both the documentation time and the stated time of the variance (which can differ), names the originator, assigns a classification for downstream presentation and processing, and carries a free-text description of the detail.

Used in

VAR appears in patient-care messages that report deviations against a plan: clinical-pathway messages alongside PTH, goal messages alongside GOL, and scheduling messages reporting variances against a planned activity. Usage is limited compared with envelope segments like MSH — many interfaces never carry VAR, and it is most often seen in care-plan and pathway-management feeds. See the messages index for the message families where patient-care segments appear.

Field-by-field reference

Source: HL7 v2.5.1 standard VAR definition (patient-care chapter). No segment-level ConceptMap is published in the v2-to-FHIR IG for VAR, so field data is drawn from the base standard rather than an IG map. R = required (cardinality min ≥ 1), O = optional. Repeat = field may repeat. Length and table numbers are left as — where the standard does not establish a well-known value.

Most-used fields

VAR-1 Variance Instance ID is the anchor. As an EI it gives each variance a stable, unique identifier so the same deviation can be referenced, updated, or deduplicated across messages.

VAR-5 Variance Classification is the field most systems act on. It places the variance into a category — for example a timing deviation versus a clinical-content deviation — which lets a receiving application route, filter, or display the variance without parsing the free text.

VAR-2 Documented Date/Time and VAR-3 Stated Variance Date/Time are deliberately separate: VAR-2 is when someone recorded the variance, VAR-3 is when the variance actually occurred. Conflating the two loses the gap between an event and its documentation, which matters for audit and pathway analytics.

Version differences (2.3 to 2.8.2)

• 2.3 / 2.4: VAR is not part of the standard in its current patient-care form; deviations were handled with general-purpose segments such as OBX or NTE.
• 2.5 / 2.5.1: VAR introduced as a dedicated Variance segment in the patient-care chapter, with VAR-1 through VAR-6 as defined above.
• 2.6 / 2.7: data types tighten to the modern set (TS dates expressed as DTM); field semantics are stable.
• 2.8.x: VAR carries forward essentially unchanged. Receivers built for earlier versions simply ignore VAR if they do not model it.

Common mistakes

• Treating VAR-2 (Documented Date/Time) and VAR-3 (Stated Variance Date/Time) as interchangeable, collapsing the documentation lag.
• Emitting VAR without a populated VAR-1, leaving the variance with no stable identifier for correlation or updates.
• Stuffing categorical meaning into the free-text VAR-6 instead of coding it in VAR-5, so receivers cannot filter or route on it.
• Sending VAR detached from the entity it qualifies (the PTH/GOL/ROL or scheduled activity), so the receiver cannot tell what the variance is about.

Examples

Minimal valid VAR (identifier only):

VAR|VARIN-0001

Fully-populated VAR:

VAR|VARIN-0001^^VORRO^EI|20260609131500|20260609090000|9988^CARTER^LISA^^^^^^VORRO^^^^XX|TIMING^Timing deviation^VORROVAR|Pathway step started 4.5 hours later than scheduled

Annotated breakdown of the fully-populated example:

VAR                                  ← segment ID
VARIN-0001^^VORRO^EI                 ← VAR-1 Variance Instance ID (EI)
20260609131500                       ← VAR-2 Documented Date/Time
20260609090000                       ← VAR-3 Stated Variance Date/Time
9988^CARTER^LISA^...                 ← VAR-4 Variance Originator (XCN)
TIMING^Timing deviation^VORROVAR     ← VAR-5 Variance Classification (CWE)
Pathway step started 4.5 hours late  ← VAR-6 Variance Description

In-context within a clinical-pathway excerpt (VAR qualifying a PTH step):

PID|1||557788^^^HOSP^MR||DOE^JANE^A||19751012|F
PTH|ADD|CHF-PATH-01^Heart Failure Pathway^VORROPATH|PATHINST-7741|20260608080000
VAR|VARIN-0001^^VORRO^EI|20260609131500|20260609090000|9988^CARTER^LISA|TIMING^Timing deviation^VORROVAR|Step started 4.5 hours later than scheduled

In-context within a goal excerpt (VAR qualifying a GOL goal):

PID|1||557788^^^HOSP^MR||DOE^JANE^A||19751012|F
GOL|AD|20260601080000|GOAL-3310^Reduce fluid overload^VORROGOAL|GOALINST-5521
VAR|VARIN-0002^^VORRO^EI|20260609140000|20260607000000|9988^CARTER^LISA|CLINICAL^Clinical deviation^VORROVAR|Weight target not met by review date

FHIR mapping

Target: Not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR IG for VAR — the IG's segment maps cover the common message segments (OBX, PV1, DG1, IN1, and so on) but do not include VAR.

In practice, variance content is reflected in FHIR ad hoc rather than through an official segment map. Implementers typically surface it as an Observation about the related plan, as Provenance (for VAR-4 originator and the VAR-2 documentation timestamp), or as an extension on the related Goal or CarePlan resource that the variance qualifies. Because there is no published mapping, treat any VAR-to-FHIR transform as site-specific and document it explicitly.

Engine considerations

• VAR is always subordinate to the entity it qualifies. Parse it in the context of the preceding PTH, GOL, ROL, or scheduled-activity group, not as a free-standing segment.
• Preserve both VAR-2 and VAR-3 distinctly; a transform that maps only one date silently discards the documentation-lag signal.
• Treat VAR-5 as the routable signal and VAR-6 as display-only. Filtering rules should key off the coded VAR-5 value, not substring matches in VAR-6.
• VAR-4 and VAR-6 repeat. Engines that assume single-valued fields will truncate multi-originator or multi-line variance records.
• Because few interfaces emit VAR, downstream systems may not model it. Confirm the receiver consumes VAR before relying on it; otherwise it may be dropped on ingest.

How Vorro parses and produces VAR

Vorro parses VAR within the patient-care group of its parent entity, binding each variance to the PTH, GOL, or scheduled activity it follows by their instance identifiers. It reads VAR-1 as the variance key for correlation and dedup, and keeps VAR-2 and VAR-3 as separate timestamps so documentation lag survives the transform. On the produce side, Vorro stamps a unique VAR-1, codes VAR-5 against the configured variance-classification table so receivers can route on it, and leaves VAR-to-FHIR mapping to channel-specific configuration since the v2-to-FHIR IG publishes no segment map for VAR.

Related pages

• PTH — the pathway segment a variance most often qualifies.
• GOL — the goal segment against which goal variances are reported.
• OBX — the observation segment used for deviations before VAR existed and still used alongside it.

Sources

• HL7 Version 2.5.1 product brief
• HL7 v2-to-FHIR IG — segment maps index (no VAR entry)
• VAR segment definition, HL7 v2.5.1 </content>

</invoke>