NEW!

HL7 Segment Browser

Browse all common HL7 v2.x segments with field definitions and message type schemas. Free reference for healthcare integration analysts.

HIPAA-Compliant by Design

Your medical data never leaves your device. No PHI is transmitted to any server.

HIPAA-Friendly No PHI Transmission Local Processing
This tool contains only public HL7 standard definitions. No HL7 messages or patient data are processed.
21 segments
Segment Description Fields
AIG Appointment Information - General Resource 14
AIL Appointment Information - Location Resource 12
AIP Appointment Information - Personnel Resource 12
AL1 Allergy Information 6
DG1 Diagnosis 21
EVN Event Type 7
FT1 Financial Transaction 31
GT1 Guarantor 30
IN1 Insurance 49
MSA Message Acknowledgment 6
MSH Message Header 21
NK1 Next of Kin / Associated Parties 40
NTE Notes and Comments 4
OBR Observation Request 45
OBX Observation/Result 25
ORC Common Order 31
PID Patient Identification 39
PV1 Patient Visit 52
PV2 Patient Visit - Additional Information 30
SCH Scheduling Activity Information 27
TXA Transcription Document Header 23

Keywords

hl7 segment browserhl7 segment definitionshl7 v2 segmentshl7 field referencehl7 message typeshl7 integration referencehl7 schema browser

Need something else?

How to use

1

On the Segments tab, browse all available HL7 v2.x segment definitions sorted alphabetically.

2

Click the expand button on any segment row to reveal its full field list β€” position, name, data type, max length, required, and repeating flags.

3

Use the search box to filter segments by code or description, or use the Data Type filter to show only segments containing a specific HL7 data type.

4

On the Message Types tab, browse the 10 most common HL7 v2.x message structures and click any message type to see its required and optional segments in sequence.

5

Click any segment code in the Message Types tab to jump directly to that segment's full field definition in the Segments tab, with automatic highlighting.

Features

21 Segments with Full Field Definitions

Covers all segments used in the 10 most common HL7 v2.x message types β€” ADT, ORM, ORU, SIU, MDM, BAR, DFT β€” with field positions, data types, max lengths, and required/repeating flags.

10 Message Type Schemas

Browse ADT^A01, ORU^R01, ORM^O01, SIU^S12, and 6 more message structures showing required vs. optional segment composition in the correct sequence.

Cross-Reference Navigation

Click a segment code in any message type schema to jump directly to its full field definition in the Segments tab, with automatic scroll and highlight.

Search and Data Type Filter

Filter segments by name or code, or narrow to segments containing a specific data type (CX, XPN, CE, TS) to quickly find relevant definitions.

Export to CSV

Download the currently visible segment list as a CSV file for use in mapping documents, interface specifications, or offline reference.

Why Choose This Tool?

Zero PHI Risk β€” Pure Standard Reference

Unlike the HL7 Viewer (which parses your actual messages), this tool contains only publicly available HL7 standard segment and message type definitions. There is nothing to upload, no patient data processed, and no network requests made. Healthcare IT teams can use it freely on hospital workstations, VPN-connected devices, and locked-down corporate networks without any data governance concerns.

Cross-Referenced Message Schemas

Knowing a segment's field definitions in isolation is useful β€” but knowing which messages require it is essential for interface work. The Message Types tab shows the composition of the 10 most common HL7 v2.x message structures, and clicking any segment code jumps directly to its full field definition. This cross-referencing eliminates the constant switching between reference documents that slows down interface analysis.

Faster Than the HL7 Specification PDF

The official HL7 v2.x specification runs to thousands of pages across multiple volumes. For everyday interface work β€” writing a mapping document, debugging a missing field, or checking a field's data type β€” most engineers need the segment table for MSH, PID, or OBX, not the full specification. This browser puts those definitions one search away instead of buried in a PDF.

Consistent With Our HL7 Viewer

The segment definitions in this browser are the same ones used by the HL7 Viewer when it annotates your messages with field names, data types, and required-field validation. If you spot an unexpected annotation in the viewer, you can look up the exact definition here. This consistency makes both tools more useful together.

Understanding HL7 v2.x Message Structure: A Reference for Integration Analysts

What Is HL7 v2.x?

HL7 version 2.x (often called HL7 v2 or HL7 2.x) is the dominant standard for electronic data interchange between healthcare information systems. Despite being more than 30 years old, it continues to carry the majority of clinical message traffic in hospitals worldwide β€” patient admissions, laboratory orders and results, scheduling events, financial transactions, and clinical documentation. Most hospital interface engines (Mirth Connect, Rhapsody, Ensemble, Cloverleaf) are still primarily routing HL7 v2.x messages.

The Anatomy of an HL7 v2.x Message

An HL7 v2.x message is a pipe-delimited text file where each line is a segment. Every segment starts with a three-letter code (e.g., MSH, PID, OBX), followed by fields separated by the pipe character |. Fields are numbered by position β€” MSH.9 is the 9th field and contains the message type. Fields can contain sub-components separated by carets (^) and repetitions separated by tildes (~).

A complete HL7 v2.x message is a sequence of these segments, where each segment carries a specific category of clinical or administrative information. The MSH (Message Header) always comes first and establishes the message type, version, and routing information. Patient demographics live in PID. Visit information is in PV1. Observation results appear in OBX.

The Most Important Segments

While the HL7 v2.x specification defines hundreds of segment types, a handful appear in nearly every integration scenario:

  • MSH β€” Always the first segment. Contains message type (MSH.9), control ID for deduplication (MSH.10), sending and receiving application/facility, and HL7 version.
  • PID β€” The core patient identifier segment. PID.3 contains the patient identifier list (MRN, national ID), PID.5 the patient name, and PID.7 the date of birth.
  • PV1 β€” Patient visit details: patient class (inpatient/outpatient), assigned location, attending doctor, and admission type. Critical for ADT workflows.
  • OBR β€” The order request segment in ORM and ORU messages. OBR.4 contains the universal service identifier (test code) and is the key field for mapping lab orders to your test catalog.
  • OBX β€” Individual observation or result in an ORU message. OBX.2 declares the value type (NM for numeric, ST for string, CWE for coded), OBX.3 the observation identifier, and OBX.5 the actual value.
  • EVN β€” Event type metadata for ADT messages. Contains the event type code (EVN.1) that distinguishes A01 (admit), A03 (discharge), A08 (update), and other patient movement events.

HL7 Data Types

Like DICOM's Value Representations, HL7 defines data types that govern how field values are encoded. Key data types include:

  • ST (String) β€” Plain text up to a defined max length. Used for free-text fields like notes and descriptions.
  • TS (Timestamp) β€” Date/time string in YYYYMMDDHHMMSS format. HL7 allows partial precision (YYYYMMDD for dates only).
  • CX (Extended Composite ID) β€” A structured identifier with assigning authority and identifier type code. Used for MRNs, account numbers, and national patient IDs.
  • XPN (Extended Person Name) β€” Structured name with family name, given name, middle initial, suffix, prefix, and name type code separated by carets.
  • CE/CWE (Coded Element / Coded with Exceptions) β€” A coded value with identifier, description, and coding system (ICD-10, LOINC, SNOMED). The standard way to transmit coded clinical data.
  • NM (Numeric) β€” Decimal number as a string. Used for test results, quantities, and measurements.
  • HD (Hierarchic Designator) β€” An application or facility identifier. Used in MSH.3/4/5/6 for message routing.

Message Type Structure

HL7 v2.x defines message types as combinations of a message code and event code, written as Code^Event. For example: ADT^A01 (Admit), ORM^O01 (Order), ORU^R01 (Result), SIU^S12 (New Appointment), and MDM^T02 (Document). Each message type has a defined segment grammar specifying which segments are required, which are optional, and in what order they appear. The Message Types tab in this browser shows these grammars for the 10 most common message types.

Practical Use Cases for This Browser

Interface analysts and integration engineers use this segment browser in several everyday scenarios:

  • Writing interface specifications: Reference field positions and data types when documenting mapping logic from source system fields to destination system fields.
  • Debugging missing or misplaced data: When a receiving system reports a missing value, look up the segment to confirm the expected field position and data type.
  • Understanding a new message type: Browse the ADT^A31 or DFT^P03 schema to understand what segments to expect when building a new interface.
  • Training new analysts: The combination of segment definitions and message schemas makes a self-contained HL7 v2.x primer for team onboarding.

Frequently Asked Questions

Does this tool support all HL7 v2.x versions?

The segment definitions are based on HL7 v2.5 and v2.7, which cover the vast majority of production HL7 interfaces in use today. Minor version differences may have slightly different field lists or cardinality rules, but the core segment structure is consistent across HL7 v2.3 through v2.8.

Does this tool parse or process actual HL7 messages?

No. This browser is a pure reference tool containing only public HL7 standard segment definitions. No HL7 message files are uploaded, no patient data is processed, and no PHI is involved. To parse actual HL7 messages, use the HL7 Viewer tool.

How many segments does this browser cover?

The browser includes 21 common HL7 v2.x segments covering all segments used in the 10 message type schemas: MSH, PID, PV1, OBX, OBR, NK1, EVN, ORC, NTE, MSA, AL1, DG1, IN1, GT1, PV2, SCH, TXA, FT1, AIG, AIL, and AIP.

What are the 10 message types included?

ADT^A01 (Admit), ADT^A04 (Register Outpatient), ADT^A08 (Update Patient), ADT^A31 (Update Person), ORM^O01 (Order), ORU^R01 (Observation Result), SIU^S12 (New Appointment), MDM^T02 (Document Status Change), BAR^P01 (Add Patient Account), and DFT^P03 (Post Financial Transaction).

What does 'Required' mean for a field vs. a segment?

At the segment level, Required means the segment must appear in messages of that type β€” its absence makes the message non-conformant. At the field level, Required means the field value must be populated when the segment is sent. Fields marked Repeating can appear multiple times within a single segment, separated by the tilde (~) delimiter.

What HL7 data types appear most often?

The most common data types are CX (Extended Composite ID) for identifiers like MRNs, XPN (Extended Person Name) for patient and provider names, TS (Timestamp) for dates and times, CE/CWE (Coded Element) for clinical codes like ICD and LOINC, and ST (String) for free-text content.

Can I use this to validate my HL7 interface?

You can use it as a reference to manually check field mappings and segment composition. For automated validation against schemas, use the HL7 Viewer which includes segment parsing and required-field checking against actual message content.

What is the difference between a segment and a field in HL7?

A segment is a named group of related data elements (e.g., PID for patient demographics). A field is an individual data item within that segment, identified by its position number β€” for example, PID.5 is the Patient Name field within the Patient Identification segment.

Are Z-segments (custom segments) included?

No. This browser contains only standard HL7 segment definitions. Z-segments are custom extensions defined by individual healthcare organizations or vendors and are not part of the public standard. Check your specific vendor's documentation for local Z-segment definitions.

Can I export the segment definitions?

Yes. Use the Export CSV button on the Segments tab to download the currently visible segment list with descriptions and field counts. You can filter first by data type or search query to export only the segments relevant to your project.

Learn more