HL7 ROL Segment: Role

ROL names a person and the role they play relative to the patient or the event — an attending physician, an admitting nurse, a referring provider, a consulting specialist — and stamps the time span over which that assignment is in effect. It is a relationship segment: it does not carry clinical data of its own, it links a person (and optionally their role code, provider type, and contact details) to whatever segment group it follows. Multiple ROL segments can appear in one message, each describing a different person playing a different role.

Purpose

ROL answers "who is responsible, and in what capacity, and for how long". It pairs a role code (ROL-3) with a person (ROL-4), an action code (ROL-2) that says whether the assignment is being added, deleted, or updated, and a begin/end date range (ROL-5/ROL-6) for the role. Because it attaches to the segment it follows, the same ROL structure can describe a role on a patient, on a visit, or on an order.

Used in

ROL appears in messages that need to name associated practitioners and their roles: ADT (admit/discharge/transfer) for attending, admitting, referring, and consulting providers; ORM and other order messages for the ordering and acting providers; and scheduling, referral, and master-file messages. See ADT messages for the most common context. Its placement is positional — it qualifies the segment group immediately above it (for example a PID/PV1 group, or an order group).

Field-by-field reference

Source: official HL7 v2-to-FHIR IG — ROL to CareTeam ConceptMap. R = required (cardinality min ≥ 1); ROL has no strictly required fields in the base definition, though ROL-1 through ROL-4 are required in practice for the segment to mean anything. Repeat = field may repeat. Length pending authoritative v2.5.1 data.

Most-used fields

ROL-3 Role-ROL and ROL-4 Role Person are the heart of the segment: the role code plus the person who fills it. A single ADT can carry several ROL segments — one for the attending physician, one for the referring provider, one for a consulting specialist — distinguished only by ROL-3.

ROL-2 Action Code matters in update flows. When an interface streams role changes, AD adds an assignment, UP updates one, and DE removes it; receivers that ignore ROL-2 end up with stale or duplicated providers. ROL-1 Role Instance ID is what lets a later UP/DE target the right prior assignment.

ROL-5 and ROL-6 (begin/end date) pin the role to a time window, which is what distinguishes a current attending from a historical one.

Version differences (2.3 to 2.8.2)

• 2.3 / 2.3.1: ROL introduced. ROL-3 (Role-ROL) and ROL-9 (Provider Type) use the CE data type.
• 2.5 / 2.5.1: coded fields migrate from CE to CWE; the segment stabilizes at roughly 13 fields.
• 2.7+: ROL-14 Organization (XON) added; trailing fields are simply ignored by older receivers.
• Transition to PRT: v2.7 introduced the PRT (Participation) segment as a more general, role-agnostic replacement for ROL and several other role-bearing constructs. The two overlap heavily — both name a person and a role with a time span — and during the 2.7–2.8.2 era many interfaces send both, or migrate from ROL to PRT. New designs increasingly prefer PRT; ROL remains widespread in installed ADT and order feeds, so engines must handle both and reconcile duplicate participants when a message carries each.

Common mistakes

• Ignoring ROL-2 Action Code, so deletes and updates are treated as new additions and providers accumulate.
• Dropping ROL-1 Role Instance ID, leaving later updates with no way to target the right prior role.
• Assuming ROL-4 is single-valued — it repeats, and a role can name more than one person.
• Confusing the role code (ROL-3) with the provider type/specialty (ROL-9); they answer different questions.
• Treating ROL and PRT as mutually exclusive and dropping one, losing participants that only appeared in the other.
• Mis-anchoring ROL — it qualifies the segment group it follows, so placing it under the wrong group reassigns the role to the wrong patient, visit, or order.

Examples

Minimal ROL (role code and person):

ROL|1|AD|AT^Attending^HL70443|9001^SMITH^JANE^A^^^MD

Fully-populated ROL:

ROL|RID-0007|UP|CP^Consulting Provider^HL70443|9002^PATEL^ANIL^^^^MD~9003^OKORO^CHIDI^^^^MD|20260609080000|20260609170000||SCH^Scheduled^L|207RC0000X^Cardiology^NUCC|||^^^^^1^555^5550100|ICU^101^A^HOSP_A|ORG-12^Cardiology Associates

Annotated breakdown of the minimal example:

ROL                       ← segment ID
1                         ← ROL-1  Role Instance ID
AD                        ← ROL-2  Action Code (Add)
AT^Attending^HL70443      ← ROL-3  Role-ROL (role code)
9001^SMITH^JANE^A^^^MD    ← ROL-4  Role Person (id^family^given^middle^^^degree)

In-context inside an ADT^A01 (admit) — ROL follows the PV1 group and names the attending and the referring provider:

MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120000||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|20260609120000
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
PV1|1|I|ICU^101^A|||||||MED
ROL|1|AD|AT^Attending^HL70443|9001^SMITH^JANE^A^^^MD|20260609120000
ROL|2|AD|RP^Referring Provider^HL70443|8800^NGUYEN^LE^^^^MD

In-context inside an ORM^O01 (order) — ROL names the ordering provider for the order group:

MSH|^~&|CPOE|HOSP_A|LAB|HOSP_B|20260609131500||ORM^O01^ORM_O01|CTRL-7741|P|2.5.1
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
ORC|NW|ORD123|||||^^^20260609131500
ROL|1|AD|OP^Ordering Provider^HL70443|9001^SMITH^JANE^A^^^MD
OBR|1||ORD123|CBC^Complete Blood Count^L

FHIR mapping

Target resources: CareTeam (primary mapped resource), with ROL also feeding PractitionerRole, Encounter (participant), Patient (general practitioner), and RelatedPerson through context-specific maps in the IG. Official ConceptMap: ConceptMap-segment-rol-to-careteam (JSON).

Not mapped in the CareTeam map: ROL-1 (Role Instance ID), ROL-2 (Action Code — drives the create/update/delete decision rather than mapping to an element), ROL-11 (address), and ROL-13 (Person's Location). When the target is PractitionerRole instead of CareTeam, ROL-3/ROL-9 inform PractitionerRole.code/.specialty and ROL-4 the referenced Practitioner.

Engine considerations

• Anchor correctly: ROL qualifies the segment group it follows. Track the current group context during parsing so a ROL lands on the right patient, visit, or order.
• Honor ROL-2: map AD/UP/DE to create/update/delete on the downstream participant rather than blindly appending. Use ROL-1 to find the prior instance for UP/DE.
• Handle repetition: ROL-4, ROL-9, ROL-11, and ROL-12 repeat; iterate the repetition character rather than reading a single occurrence.
• Reconcile with PRT: when a message carries both ROL and PRT for the same participant, dedupe so the same provider is not created twice in the FHIR output.
• Failure mode: dropping ROL-1/ROL-2 turns an update stream into an append-only one and silently grows the provider list.

How Vorro parses and produces ROL

Vorro binds each ROL to the segment group it follows, so the role attaches to the correct patient, visit, or order. It reads ROL-2 Action Code and ROL-1 Role Instance ID to apply adds, updates, and deletes against the existing participant set rather than appending blindly, and it expands the repeating ROL-4/ROL-9 occurrences into distinct participants. On the produce side, Vorro maps internal role assignments to ROL-3/ROL-4 with the correct begin/end window, and can emit PRT instead of (or alongside) ROL per channel configuration when a downstream system expects the newer segment.

Related pages

• PRT — the newer Participation segment that overlaps with and increasingly replaces ROL.
• PV1 — the visit segment whose group ROL most often qualifies with attending and admitting providers.
• ADT messages — the most common home for ROL.

Sources

• HL7 v2-to-FHIR IG — segment maps index
• HL7 v2-to-FHIR IG — ROL to CareTeam ConceptMap
• HL7 Version 2.5.1 product brief