HL7 v2 utility

HL7 Message Diff & Comparison Tool

Compare two HL7 v2 messages and find meaningful changes by segment, field, repetition, component, and subcomponent.

Privacy reminder. Do not paste real patient data, credentials, secrets, production identifiers, or confidential messages. Use synthetic/test HL7 only.

Comparison

Paste two HL7 messages

The comparison runs locally in your browser. Repeating segments such as OBX, AL1, DG1, NK1, IN1, and NTE are matched using useful identifiers where available instead of line position alone.

Original message

Baseline or before version.

Updated message

Changed or after version.

Comparison options

Ignore MSH.7 timestamp Ignore MSH.10 control ID Ignore trailing empty fields Ignore whitespace differences Case-sensitive comparison Compare decoded HL7 escapes Show unchanged values

Additional ignored fields

Separate field paths with commas or spaces.

A differences-only report will appear here.

FAQ

HL7 comparison questions

How are repeating segments matched?

The tool uses identifiers appropriate to common segments, such as the observation identifier for OBX, allergen for AL1, diagnosis code for DG1, and order numbers for ORC and OBR. It falls back to occurrence order when no reliable identifier is present.

Why are MSH.7 and MSH.10 ignored by default?

Message timestamps and control IDs commonly change between otherwise equivalent messages. You can include them by clearing the options.

Is this a certified HL7 validator?

No. It is a practical comparison utility for development, testing, troubleshooting, and documentation.

Can I paste real patient data?

No. Use synthetic, anonymised, or test data only.

Practical guide

Compare HL7 messages without losing field context

The diff tool is intended for mapping regression tests, environment comparisons, interface upgrades, and investigating why one message is accepted while another fails. It breaks changes down by segment and HL7 field location rather than presenting only a character-level text diff.

Recommended workflow

Choose messages representing the same event or test scenario.
Confirm both messages use compatible delimiter definitions from MSH.
Review MSH differences first, especially message type, control ID, processing ID, version, and acknowledgement settings.
Inspect changed clinical or administrative fields by segment, repetition, component, and subcomponent.
Decide which differences are expected dynamic values and which indicate mapping or configuration drift.

High-value comparisons

Before and after a transformer or mapping change.
A production-like synthetic sample versus the vendor's accepted test sample.
Messages generated by two versions of an interface.
An accepted message versus one that produced an AE, AR, CE, or CR acknowledgement.
Payloads from two sites where local code or identifier configuration differs.

Worked example

A small location change can alter routing

Message A: PV1-3 = WARD1^ROOM2^BED3^FACILITY-A
Message B: PV1-3 = WARD1^ROOM2^BED3^FACILITY-B

Only PV1-3.4, the facility component, changed. A text diff may make this look minor, but a downstream route could use the facility to choose a destination, document template, ward mapping, or tenant. Field-level context helps reviewers assess operational impact.

The same principle applies to identifier assigning authorities, code systems, observation units, and provider namespaces: a component change can matter more than a visibly larger free-text change.

Avoiding noisy comparisons

Stabilise dynamic values where possible

Timestamps, IDs, and repetitions

MSH-7 timestamps, MSH-10 control IDs, visit numbers, order numbers, and generated identifiers commonly differ on every run. Repeating OBX, AL1, DG1, or NTE segments may also be reordered or inserted, shifting later positions.

Use fixed synthetic values in regression fixtures when the purpose is to verify a mapping rather than generation behaviour. Then reintroduce dynamic values as separate tests.

Limitations

The tool cannot determine whether two different codes are clinically or operationally equivalent.
Segment matching becomes less certain when repeated segments lack stable identifiers.
It does not execute a message profile or receiving-system validation rules.
Whitespace and line-ending normalization can hide transport-level differences; use the MLLP inspector when framing is relevant.

Authorship and review

Practical guidance backed by integration experience

Maintained and technically reviewed by Health Data Tools, drawing on more than 15 years of healthcare integration experience across HL7, FHIR, CDA, APIs, PKI, and clinical integration systems.

Technically reviewed: 21 July 2026

Official references

Standards and further reading

These references support the technical context. Local implementation guides, vendor profiles, and receiving-system rules still take precedence for a specific interface.