The OG (Observation Grouper) data type is the v2.7-and-later replacement for the plain ST value in OBX-4 Observation Sub-ID. It extends the historic free-text sub-identifier with four structured components — Original Sub-Identifier, Group, Sequence, and Qualifier — so a sender can express explicit parent-child relationships between OBX rows in a single result group (e.g. a battery result whose individual analytes share a parent grouping OBX).
Purpose
Before OG, OBX-4 was a plain string and senders used informal conventions (1, 1.1, 1.2, 2, 2.1, …) to imply hierarchy. Receivers had to parse the string and guess the convention. OG turns that into a structured composite: OG.2 is the group number, OG.3 is the sequence within the group, OG.4 is a free-text qualifier (commonly an analyte code or position name), and OG.1 preserves the original v2.6-and-earlier ST sub-identifier verbatim for backward compatibility. The result is a clean way to model batteries (CBC, BMP, lipid panel), multi-site measurements (left arm vs. right arm BP), and replicate analyses.
Component table
Source: Caristix HL7 v2.8.1 definition (OG). Lengths are no longer published as fixed maxima in v2.8.1 (—). OG has 4 components.
| Comp | Name | Sub-type | Length | Required | Description |
|---|---|---|---|---|---|
| OG.1 | Original Sub-Identifier | st | — | O | Pre-v2.7 free-text sub-ID retained verbatim for back-compat (e.g. 1, 1.1). |
| OG.2 | Group | nm | — | O | Group number — identifies the parent grouping; same value across all members. |
| OG.3 | Sequence | nm | — | O | Position within the group — 1 for the parent header row, 2..n for children. |
| OG.4 | Identifier | st | — | O | Free-text qualifier — typically the analyte code or sub-result label. |
Most-used components
- OG.2 Group — the integer that ties parent and children together. All OBXs in one battery share the same OG.2.
- OG.3 Sequence — distinguishes the parent header (sequence
1) from each child analyte (sequence2,3, …). - OG.4 Identifier — usually the analyte mnemonic (
GLU,NA,K) so a human reading the message can see at a glance which sub-result is which. - OG.1 Original Sub-Identifier — populated by gateways that are translating older v2.5/v2.6 messages forward; greenfield v2.7+ senders typically leave it empty.
Where it's used
OG appears in exactly one place in the v2.8.1 base standard:
- OBX-4 Observation Sub-ID — the structured grouping field. In v2.7+, OBX-4 is typed OG; in v2.6 and earlier it was typed ST.
Site profiles occasionally re-use OG in custom Z-segments that need a structured sub-grouping, but this is rare — most extensions stick with a plain ST or a coded CWE.
Version differences
- v2.1 – v2.6 — OBX-4 typed as plain ST. Hierarchy expressed by convention (
1,1.1,1.2). - v2.7 — OG introduced; OBX-4 retyped from ST to OG. OG.1 preserves the legacy ST so receivers parsing OG can still recover the original string if the upgrade was lossless.
- v2.7.1 – v2.8.1 — OG structure unchanged. Adoption is uneven — many senders continue to populate only OG.1 with their legacy convention, which is valid but loses the structural benefit.
Common mistakes
- Populating OG.1 only. Valid for backward compatibility but throws away the whole point of OG. Greenfield messages should populate OG.2 and OG.3 so receivers can build the parent-child tree without parsing strings.
- Mismatched group numbers across battery members. All members of one battery share one OG.2. Using
1,2,3for three analytes of the same panel breaks grouping. - Skipping the parent header row. Some senders emit children with sequence
2..nbut never emit the sequence1parent. Receivers that key on the parent row drop the entire group. - Free-text OG.2 or OG.3. Both are NM and must be numeric.
1A,1.1, orGroup-1are invalid. - Reusing OG.4 as the primary code. OG.4 is a free-text qualifier, not a coded observation identifier. The coded identifier belongs in OBX-3.
Examples
Minimal value — single child in group 1, qualifier GLU
^1^1^GLU
OG.1 empty, group 1, sequence 1, qualifier GLU. This is the parent (sequence 1) of group 1, labeled glucose.
Multi-component — back-compat with legacy sub-identifier preserved
1.2^1^3^K
Original v2.6 sub-identifier 1.2 retained in OG.1; structured form says group 1, sequence 3, qualifier K (potassium).
In-context excerpt — basic metabolic panel battery
OBX|1|CE|BMP^Basic Metabolic Panel^L|^1^1^|||||||F
OBX|2|NM|GLU^Glucose^LN|^1^2^GLU|95|mg/dL|70-99||||F
OBX|3|NM|NA^Sodium^LN|^1^3^NA|140|mmol/L|135-145||||F
OBX|4|NM|K^Potassium^LN|^1^4^K|4.1|mmol/L|3.5-5.0||||F
OBX|5|NM|CL^Chloride^LN|^1^5^CL|102|mmol/L|98-107||||F
Five OBX rows share group 1. OBX-1 is the parent header (sequence 1); OBX-2 through OBX-5 are the four analyte children (sequences 2 – 5). A receiver builds the tree by grouping on OG.2 and ordering on OG.3.
Common pitfall — children with no parent header
OBX|1|NM|GLU^Glucose^LN|^1^2^GLU|95|mg/dL|70-99||||F
OBX|2|NM|NA^Sodium^LN|^1^3^NA|140|mmol/L|135-145||||F
Group 1 is referenced by two children, but no OBX with sequence 1 exists. Receivers that require a parent row to anchor the group either drop both children or silently promote OBX-1 (sequence 2) to the parent.
FHIR mapping
The v2-to-FHIR Implementation Guide publishes ConceptMap-datatype-og-subidentifier-to-extension. OG does not map to a single FHIR primitive; instead it lifts into an Extension on the Observation resource that preserves the v2 sub-identifier grouping. Battery membership is also expressed natively in FHIR via Observation.hasMember from the parent to its children.
| OG component | FHIR element |
|---|---|
| OG.1 Original Sub-Identifier | Extension subidentifier (string) |
| OG.2 Group | Extension group (integer) — same value across battery members |
| OG.3 Sequence | Extension sequence (integer) |
| OG.4 Identifier | Extension qualifier (string) |
| (group membership) | Observation.hasMember references from parent to children |
Engine considerations
- Group-tree reconstruction. Engines mapping v2.7+ to FHIR should build the parent-child tree from OG.2 and OG.3, then emit
Observation.hasMemberlinks rather than relying on the legacy string convention. - Forward-translation from v2.6. When ingesting v2.6 messages and emitting v2.7+, populate OG.1 with the original ST sub-identifier and parse the convention into OG.2/OG.3 where possible. Where the convention can't be parsed, leave OG.2/OG.3 empty rather than guessing.
- Receiver tolerance. Many production receivers still treat OBX-4 as plain ST and read only the bytes up to the first
^. Senders emitting structured OG should verify the receiver consumes all four components. - Numeric components. OG.2 and OG.3 are NM, not ST. Engines must reject
1Aor1.1in these slots at parse time. - HAPI accessor. HAPI v2.8.1 exposes OG as
ca.uhn.hl7v2.model.v281.datatype.OGwith typed getters for each component; OG.1 and OG.4 areST, OG.2 and OG.3 areNM.
How Vorro parses and produces OG
Vorro's HL7 parser reads OG into a typed SubIdentifier model with explicit originalSubId, group, sequence, and qualifier slots. When ingesting v2.6 or earlier (where OBX-4 is ST), the parser stores the raw string in originalSubId and attempts a best-effort parse of the dot-convention (1.2 → group 1, sequence 2) to populate the structured fields. The parse is conservative — anything that doesn't match the convention is left as originalSubId only.
On outbound, Vorro emits OG when the route's profile is v2.7 or later. Group and sequence are populated from the canonical model's tree position; qualifier is populated from the analyte code if OBX-3 carries one. When the downstream profile is v2.6 or earlier, the engine collapses OG back to the legacy ST convention ({group}.{sequence}) and emits that string in OBX-4.
