The REL segment was introduced in HL7 v2.7 to give senders a first-class, machine-readable way to declare that one piece of clinical information relates to another. Before REL, integration engines inferred relationships from segment grouping or proprietary OBX-linked observations; REL replaces that inference with an explicit, typed, directional link between a source instance and a target instance, together with metadata about who is asserting the relationship, how certain they are, and when the assertion applies.
This page documents the segment as it appears in HL7 v2.8.1.
Purpose
REL exists to carry a single, typed relationship instance between two other information instances already present in (or referenced by) the message. Each REL row answers four questions: what kind of relationship (REL-2), what is the source (REL-4), what is the target (REL-5), and who says so (REL-6 through REL-10). Optional fields refine the assertion with date range, negation, certainty, priority, and separability.
Typical uses include:
- Linking an OBX observation result to the OBR order that produced it when the linkage is not implicit in segment grouping.
- Recording that two problems are causally related (one is a manifestation of the other).
- Asserting that one medication order supersedes another.
- Declaring that two documents are versions of the same logical record.
Used in
REL appears wherever a message needs to carry clinical relationships that are not implicit in the segment hierarchy. Most commonly it appears in observation result messages such as the ORU message, but it is also used in care record and clinical document messages whenever a sender needs to relate two information instances explicitly.
Field-by-field reference
Source: HAPI HL7v2 v2.8.1 javadocs (REL.html). Length is shown as — because v2.8.1 deprecated fixed maximum lengths in favour of conformance-profile constraints. Required and Table # are taken from the HL7 v2 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| REL-1 | Set ID - REL | si | — | R | — | — | Sequence number within the message |
| REL-2 | Relationship Type | cwe | — | R | — | — | Coded type of the relationship asserted |
| REL-3 | This Relationship Instance Identifier | ei | — | R | — | — | Unique identifier of this relationship row |
| REL-4 | Source Information Instance Identifier | ei | — | R | — | — | Identifier of the source information instance |
| REL-5 | Target Information Instance Identifier | ei | — | R | — | — | Identifier of the target information instance |
| REL-6 | Asserting Entity Instance ID | ei | — | O | — | — | Identifier of the asserting entity instance |
| REL-7 | Asserting Person | xcn | — | O | — | — | Person making the relationship assertion |
| REL-8 | Asserting Organization | xon | — | O | — | — | Organization making the assertion |
| REL-9 | Assertor Address | xad | — | O | — | — | Address of the asserting party |
| REL-10 | Assertor Contact | xtn | — | O | — | — | Contact telecom of the asserting party |
| REL-11 | Assertion Date Range | dr | — | O | — | — | Date range over which the assertion holds |
| REL-12 | Negation Indicator | id | — | O | — | — | Whether the relationship is being negated |
| REL-13 | Certainty of Relationship | cwe | — | O | — | — | Coded certainty level of the assertion |
| REL-14 | Priority No | nm | — | O | — | — | Numeric priority of this relationship |
| REL-15 | Priority Sequence No | nm | — | O | — | — | Preference order for consideration |
| REL-16 | Separability Indicator | id | — | O | — | — | Whether items can be split apart |
Most-used fields
In day-to-day integration work, the five identifying fields carry almost all of the meaning:
- REL-2 Relationship Type says what the link is (e.g. "manifestation of", "supersedes", "is-component-of"). Without it the row is uninterpretable.
- REL-3 This Relationship Instance Identifier lets downstream systems acknowledge, update, or retract the relationship later.
- REL-4 Source Information Instance Identifier and REL-5 Target Information Instance Identifier are the two endpoints. Direction matters: most relationship vocabularies are asymmetric.
- REL-13 Certainty of Relationship is heavily used by decision support, which weights the assertion by stated confidence.
REL-12 Negation Indicator is small but consequential: a REL row with REL-12 set to Y asserts that the relationship does not hold, which is not the same as omitting the row.
Version differences (2.6 -> 2.7 -> 2.8.2)
- v2.6 and earlier: No REL segment. Relationships between observations were expressed via OBX-4 sub-IDs, the optional OBX linkage fields, or proprietary Z-segments.
- v2.7: REL introduced with the full 16-field structure shown above. The semantics of source/target identifiers and the assertion metadata block were finalised here.
- v2.7.1 / v2.8 / v2.8.1: No structural changes; vocabulary refinements only. v2.8.1 (this page) retains the v2.7 layout.
- v2.8.2: Continues to carry REL unchanged structurally; minor table updates for Relationship Type and Certainty vocabularies.
Common mistakes
- Putting an OBX-set-id in REL-4/REL-5. REL-4 and REL-5 are EI (Entity Identifier) values that must dereference globally, not local sequence numbers from within the message.
- Omitting REL-3. Some senders treat REL as stateless and skip the instance identifier. Without REL-3 the receiver cannot retract or update the assertion later.
- Confusing absence with negation. Not sending a REL row means "no assertion"; sending one with REL-12 =
Ymeans "this relationship is explicitly denied". They are not the same. - Symmetry assumptions. Relationship Type codes are directional. Reversing source and target changes the meaning even if the type code is symmetric in everyday English.
- Using REL where OBX-linkage would suffice. For straightforward "this result belongs to that order" cases, segment grouping already conveys the link; adding REL is noise.
Examples
Minimal REL
REL|1|MFST^manifestation-of^HL7|REL-001^Vorro^L||OBS-7781^Vorro^L|OBS-7780^Vorro^L
Fully-populated REL
REL|1|MFST^manifestation-of^HL7|REL-2026-0001^Vorro^L|OBS-7781^Vorro^L|OBS-7780^Vorro^L|ENT-44^Vorro^L|99812^Reyes^Marta^L^^^MD|1003^Riverbend Cardiology^^^^^XX^^^1003|123 Mill St^^Riverbend^OR^97001^USA|^WPN^PH^^^555^5550144|20260610100000^20260620100000|N|DEF^definite^HL7|1|1|N
Annotated breakdown
REL Segment ID
|1 REL-1 Set ID
|MFST^manifestation-of^HL7 REL-2 Relationship Type (CWE)
|REL-2026-0001^Vorro^L REL-3 This Relationship Instance Identifier (EI)
|OBS-7781^Vorro^L REL-4 Source Information Instance Identifier (EI)
|OBS-7780^Vorro^L REL-5 Target Information Instance Identifier (EI)
|ENT-44^Vorro^L REL-6 Asserting Entity Instance ID (EI)
|99812^Reyes^Marta^L^^^MD REL-7 Asserting Person (XCN)
|1003^Riverbend Cardiology... REL-8 Asserting Organization (XON)
|123 Mill St^^Riverbend... REL-9 Assertor Address (XAD)
|^WPN^PH^^^555^5550144 REL-10 Assertor Contact (XTN)
|20260610100000^20260620... REL-11 Assertion Date Range (DR)
|N REL-12 Negation Indicator
|DEF^definite^HL7 REL-13 Certainty of Relationship (CWE)
|1 REL-14 Priority No
|1 REL-15 Priority Sequence No
|N REL-16 Separability Indicator
In-context excerpt: REL inside an ORU result linking observations
MSH|^~&|LIS|RIVERBEND|EMR|RIVERBEND|20260612091500||ORU^R01^ORU_R01|MSG-77810|P|2.8.1
PID|1||MRN-554120^^^Riverbend^MR||Okafor^Adaeze||19780214|F
OBR|1|ORD-9912^Vorro|ACC-44210^LIS|24331-1^Lipid panel^LN|||20260612090000
OBX|1|NM|13457-7^LDL^LN||162|mg/dL|<100|H|||F|||20260612090000
OBX|2|NM|2085-9^HDL^LN||38|mg/dL|>40|L|||F|||20260612090000
REL|1|RELATED^related-to^HL7|REL-77810-1^Vorro^L|OBS-1162^Vorro^L|OBS-1163^Vorro^L||||||||PROB^probable^HL7
In-context excerpt: REL relating two problems
MSH|^~&|EMR|RIVERBEND|REGISTRY|STATE|20260612101200||ORU^R01^ORU_R01|MSG-77811|P|2.8.1
PID|1||MRN-554120^^^Riverbend^MR||Okafor^Adaeze||19780214|F
OBR|1|PRB-1^Vorro|PRB-1^EMR|11450-4^Problem list^LN
OBX|1|CWE|55607006^Problem^SCT||38341003^Hypertensive disorder^SCT|||||||F
OBX|2|CWE|55607006^Problem^SCT||90708001^Diabetic kidney disease^SCT|||||||F
REL|1|CAUS^caused-by^HL7|REL-77811-1^Vorro^L|OBS-1166^Vorro^L|OBS-1165^Vorro^L||||||||DEF^definite^HL7
FHIR mapping
The v2-to-FHIR Implementation Guide does not publish a segment-level ConceptMap for REL. Conceptually REL aligns most closely with the FHIR Linkage resource, which records typed relationships between two or more resources, or with the relationship element on the specific clinical resource at one end of the link (for example Condition.evidence, Observation.derivedFrom, or MedicationRequest.priorPrescription).
Implementations that need a deterministic mapping typically:
- Resolve REL-4 and REL-5 EI values to FHIR resource references.
- Choose between
Linkage(when both endpoints are first-class resources) and an inline relationship element (when the source resource already has a suitable field). - Carry REL-13 Certainty as a
codeextension and REL-12 Negation as a boolean modifier extension.
Engine considerations
- Encoding: REL uses
^only as a component separator within EI, CWE, XCN, XON, XAD, XTN and DR; the field separator inside the segment is the message's MSH-1 character. - Validation: Strict profiles will reject REL rows missing REL-2 through REL-5; lenient profiles accept REL-1 alone but the row is then useless.
- Ordering: Multiple REL rows are independent and may be reordered without changing meaning provided each row carries its own REL-3 identifier.
- Acknowledgement: REL-3 is the only handle a receiver has for later updates; engines should preserve it verbatim through any transformations.
How Vorro parses and produces REL
Vorro's HL7 parser builds REL into a typed RelationshipAssertion object whose source and target are resolved against the message's EI registry at parse time. REL-2 Relationship Type and REL-13 Certainty of Relationship are normalised against configurable code-system tables, so downstream rules can switch on primary values rather than per-sender strings. REL-12 Negation Indicator is surfaced as a Boolean; rows with negation are still emitted to downstream targets so consumers can record explicit denials.
When producing REL, Vorro assigns REL-3 from a deterministic UUID-derived namespace so re-sent messages carry stable instance identifiers, which lets receivers replay or retract assertions without duplicates. REL rows whose source or target identifier cannot be resolved are quarantined rather than silently dropped.
