HL7 ROL Role
HL7 field reference ROL fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| ROL.1 | Role Instance ID | No | No | EI | |
| ROL.2 | Action Code | Yes | No | ID | 0287 |
| ROL.3 | Role-ROL | Yes | No | CE | 0443 |
| ROL.4 | Role Person | Yes | Yes | XCN | |
| ROL.5 | Role Begin Date/Time | No | No | TS | |
| ROL.6 | Role End Date/Time | No | No | TS | |
| ROL.7 | Role Duration | No | No | CE | |
| ROL.8 | Role Action Reason | No | No | CE | |
| ROL.9 | Provider Type | No | Yes | CE | |
| ROL.10 | Organization Unit Type | No | No | CE | 0406 |
| ROL.11 | Office/Home Address/Birthplace | No | Yes | XAD | |
| ROL.12 | Phone | No | Yes | XTN |
ROL describes a role that a person or organization plays in relation to the patient, visit, order, problem, or other context.
The standard describes ROL this way: The role segment contains the data necessary to add, update, correct, and delete from the record persons involved, as well as their functional involvement with the activity being transmitted. In general, the ROL segment is used to describe a person playing a particular role within the context of the message. In PM, for example, in the Grant Certificate/Permission message (B07), the ROL segment is used to describe the roles a person may perform pertinent to the certificate in the message. The positional location of the ROL segment in ADT and Finance messages indicates the relationship. When the segment is used following the IN3 segment, and the role-ROL value is PP or FHCP, the PP or FHCP is related to the health plan. When the segment is used following the PID segment, and the role-ROL value is PP or FHCP, the PP or FHCP is related to the person. When the segment is used following the PV2 segment, and the role-ROL value is PCP or FHCP, the PP or FHCP is related to the patient visit.
These segments describe clinical goals, problems, roles, referrals, requisitions, incidents, variances, and resource groupings that sit around the core patient/order/result traffic.
They are most useful when responsibilities, dates, identifiers, and status values are kept explicit. Otherwise they become narrative fragments that are hard to act on.
The v2.5.1 structures show ROL in ADR_A19 - Patient query, ADT_A01 - Admit/visit notification, ADT_A02 - Transfer a patient, and ADT_A03 - Discharge/end visit, and 31 other message structures. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
ROL-1 identifies the Role Instance ID for this care-plan or referral workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
ROL-2 says what action is being taken for this segment or record: add, update, delete, cancel, clear, or another profile-defined operation. It needs to agree with the message trigger and the previous state.
The generated panel links this to HL7 table 0287; many real interfaces narrow that list further, so follow the receiver's implementation guide.
ROL-3 carries Role-ROL for this care-plan or referral workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0443; many real interfaces narrow that list further, so follow the receiver's implementation guide.
ROL-4 identifies a person, provider, staff member, or contact involved in this care-plan or referral workflow. Use the structured name or provider datatype instead of flattening everything into display text.
When more than one person is sent, repeats should carry role or identifier context so the receiver can tell who did what.
ROL-5 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
ROL-6 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
For effective and end dates, make the boundary rule explicit. Receivers need to know whether the value is inclusive, exclusive, planned, actual, or merely informational.
ROL-7 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
ROL-8 says what action is being taken for this segment or record: add, update, delete, cancel, clear, or another profile-defined operation. It needs to agree with the message trigger and the previous state.
ROL-9 qualifies the care-plan or referral workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
ROL-10 qualifies the care-plan or referral workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0406. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
ROL-11 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
ROL-12 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.