PRT is a general-purpose participation segment: it names a participant — a person, an organization, a device, or a location — and the role that participant played for the segment immediately before it. It was introduced in v2.7 as the modern, reusable way to attach participants to almost any structure, replacing the practice of embedding provider and role fields directly inside other segments. A PRT after an OBX says who performed or verified that observation; a PRT after an OBR says who ordered or collected it. The same segment shape works everywhere, which is why it shows up across many v2.7+ messages.
Purpose
PRT attaches one participant and one role to the preceding segment. PRT-4 carries the role (ordering provider, performing organization, collecting device, and so on), and exactly one of the participant-identity fields is populated to match that role: PRT-5 for a person, PRT-8 for an organization, PRT-9 for a location, PRT-10 for a device. PRT-2 says whether this is an add, update, or delete of that participation. Because the role and identity live in a single repeatable child segment, the parent segment does not need its own provider fields.
Used in
PRT appears as a participant child of a preceding segment in ORU (after OBR/OBX), OML (after OBR/ORC/SPM), and many other v2.7+ messages — anywhere a person, organization, device, or location needs to be tied to a specific clinical or order segment. See ORU messages for the most common placement, where PRT follows OBR or OBX to name the performer of a result.
Field-by-field reference
Source: official HL7 v2-to-FHIR IG. PRT is a v2.7+ segment; the version: "2.5.1" in frontmatter is the page series version, not the version that introduced PRT. R = required (cardinality min ≥ 1). Repeat = field may repeat (cardinality max *). Length is not pinned to an authoritative v2.7+ table here, so all lengths show —.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| PRT-1 | Participation Instance ID | EI | — | O | — | — | Unique id for this participation instance; used to update or delete it later. |
| PRT-2 | Action Code | ID | — | R | — | HL70206 | AD add, UP update, DE delete, UC unchanged. |
| PRT-3 | Action Reason | CWE | — | O | — | — | Why the participation was added, changed, or removed. |
| PRT-4 | Participation (Role) | CWE | — | R | — | HL70912 | The role this participant played for the preceding segment, e.g. ordering provider, performing organization. |
| PRT-5 | Participation Person | XCN | — | O | Y | — | The participating person, when the role is a person. |
| PRT-6 | Participation Person Provider Type | CWE | — | O | — | — | Provider type/specialty of the person in PRT-5. |
| PRT-7 | Participant Organization Unit Type | CWE | — | O | — | — | Type of organization unit for PRT-8. |
| PRT-8 | Participation Organization | XON | — | O | Y | — | The participating organization, when the role is an organization. |
| PRT-9 | Participant Location | PL | — | O | Y | — | The participating location, when the role is a location. |
| PRT-10 | Participation Device | EI | — | O | Y | — | The participating device, when the role is a device. |
| PRT-11 | Participation Begin Date/Time | DTM | — | O | — | — | When the participation started. |
| PRT-12 | Participation End Date/Time | DTM | — | O | — | — | When the participation ended. |
| PRT-13 | Participation Qualitative Duration | CWE | — | O | — | — | Qualitative duration of the participation. |
| PRT-14 | Participation Address | XAD | — | O | Y | — | Address of the participant. |
| PRT-15 | Participant Telecommunication Address | XTN | — | O | Y | — | Phone/email/other contact for the participant. |
| PRT-16 | Participant Device Identifier | EI | — | O | — | — | UDI device identifier. |
| PRT-17 | Participant Device Manufacture Date | DTM | — | O | — | — | Device manufacture date. |
| PRT-18 | Participant Device Expiry Date | DTM | — | O | — | — | Device expiry date. |
| PRT-19 | Participant Device Lot Number | ST | — | O | — | — | Device lot number. |
| PRT-20 | Participant Device Serial Number | ST | — | O | — | — | Device serial number. |
| PRT-21 | Participant Device Donation Identification | EI | — | O | — | — | Donation id for the device. |
| PRT-22 | Participation Device Type | CNE | — | O | — | — | Device type. |
| PRT-23 | Preferred Method of Contact | CWE | — | O | — | — | Preferred contact method for the participant. |
| PRT-24 | Contact Identifiers | PLN | — | O | Y | — | Provider/contact identifiers, e.g. license numbers. |
PRT-16 through PRT-22 (device manufacture/expiry/lot/serial/donation/type) and PRT-23/24 appear in v2.7.1+ revisions; older v2.7 implementations may stop earlier in the list. Table assignments beyond PRT-2 (HL70206) and PRT-4 (HL70912) are user-defined or not yet pinned in the IG.
Most-used fields
PRT-4 Participation is the field that gives the segment meaning. Without it, the participant has no role and the segment is unusable; it is the code that distinguishes an ordering provider from a performing organization from a collecting device.
PRT-5 Participation Person carries the person identity (XCN — id, name, and assigning authority) and is the most common participant by far, since most PRTs name a provider tied to an order or result.
PRT-2 Action Code drives lifecycle: AD to add a participation, UP to update, DE to delete. Combined with PRT-1 Participation Instance ID, it lets a later message amend or remove a previously sent participant rather than resend the whole structure.
Version differences (2.3 to 2.8.2)
- 2.3 through 2.6: PRT does not exist. Participants and roles are embedded directly in other segments (provider fields inside OBR, ORC, PV1, and the standalone ROL segment).
- 2.7: PRT introduced as the modern, reusable participation mechanism — a single segment that can follow many parents and name a person, organization, device, or location with an explicit role in PRT-4.
- 2.7.1 / 2.8: device-detail fields (PRT-16 through PRT-22) and the contact fields (PRT-23, PRT-24) added, broadening PRT to fully describe device and contact participants.
- 2.8.2: PRT remains the standard participation segment; receivers built for 2.3 to 2.6 will not recognize it and simply ignore the unknown segment.
Common mistakes
- Populating more than one identity field (e.g. both PRT-5 and PRT-8) for a single PRT instead of choosing the one that matches PRT-4.
- Omitting PRT-4 — the role is required and the participant is meaningless without it.
- Omitting PRT-2 Action Code, which is required; defaulting to a blank action breaks update/delete handling.
- Assuming downstream systems understand PRT — pre-2.7 receivers drop it, so critical provider data sent only in PRT can be silently lost.
- Attaching PRT to the wrong parent: PRT always describes the segment immediately before it, so order matters.
Examples
Minimal valid PRT (required fields only — action code and role):
PRT|1|AD||RO^Ordering Provider^HL70912
Fully-populated PRT (a performing provider tied to a result):
PRT|1|AD||PP^Performing Provider^HL70912|9988^SMITH^ANNE^^^^MD^^NPI|CARD^Cardiology^HL70912||||||20260609131500
Annotated breakdown of the minimal example:
PRT ← segment ID
1 ← PRT-1 Participation Instance ID
AD ← PRT-2 Action Code (Add)
← PRT-3 empty (Action Reason)
RO^Ordering Provider^HL70912 ← PRT-4 Participation / role (required)
← PRT-5+ empty (no person/org/device/location detail)
In-context inside an ORU^R01 — PRT after OBR names the ordering provider for the order:
MSH|^~&|LAB|HOSP_B|EHR|HOSP_A|20260609131500||ORU^R01^ORU_R01|CTRL-7741|P|2.5.1
PID|1||778812^^^HOSP^MR||REYES^MARIA^L||19770304|F
OBR|1||ORD55120|CBC^Complete Blood Count^L
PRT|1|AD||RO^Ordering Provider^HL70912|4471^PATEL^RAVI^^^^MD^^NPI
In-context inside an ORU^R01 — PRT after OBX names the performing provider for a specific result:
OBR|1||ORD55120|CBC^Complete Blood Count^L
OBX|1|NM|718-7^Hemoglobin^LN||13.5|g/dL|13.0-17.0|N|||F
PRT|1|AD||PP^Performing Provider^HL70912|9988^SMITH^ANNE^^^^MD^^NPI
FHIR mapping
PRT has several official ConceptMaps in the v2-to-FHIR IG — one per target resource and participation role, because the same segment can describe a person, organization, device, or location. Targets include PractitionerRole (primary, for person participants), CareTeam, RelatedPerson, Device, Patient.generalPractitioner, and Observation (for location participants). ConceptMap: ConceptMap-segment-prt-to-practitionerrole (JSON).
| PRT field | FHIR target (PractitionerRole map) |
|---|---|
| PRT-2 Action Code | drives relationship activation/inactivation |
| PRT-4 Participation | PractitionerRole.code |
| PRT-5 Participation Person | PractitionerRole.practitioner |
| PRT-6 Person Provider Type | PractitionerRole.specialty |
| PRT-7 Org Unit Type / PRT-8 Organization | PractitionerRole.organization |
| PRT-9 Participant Location | PractitionerRole.location |
| PRT-11 Begin Date/Time | PractitionerRole.period.start |
| PRT-12 End Date/Time | PractitionerRole.period.end |
| PRT-14 Participation Address | PractitionerRole.practitioner (Practitioner.address) |
| PRT-15 Telecommunication Address | PractitionerRole.telecom |
| PRT-23 Preferred Method of Contact | PractitionerRole.telecom.extension |
| PRT-24 Contact Identifiers | PractitionerRole.identifier |
Which map applies depends on PRT-4 and which identity field is populated: a person routes to PractitionerRole (or CareTeam/RelatedPerson), PRT-10 device to Device, PRT-9 location to Observation, and a general-practitioner role to Patient.generalPractitioner. Not mapped in the PractitionerRole map: PRT-1, PRT-3, PRT-13, and the device-detail fields PRT-16 through PRT-22 (handled in the Device map instead).
Engine considerations
- PRT always binds to the segment immediately before it; the parser must track the current parent segment so a PRT is associated with the right OBR, OBX, ORC, or SPM.
- PRT repeats — a single OBX can carry several PRTs (performer, verifier, transcriber). Treat it as a repeating child group, not a one-off.
- Choose the FHIR map by inspecting PRT-4 and the populated identity field, not by position; the same segment shape resolves to different resources.
- Failure mode: routing PRT-only provider data to a pre-2.7 receiver loses it silently, since the receiver discards segments it does not recognize.
- Validate that exactly one identity field (PRT-5/8/9/10) is set and that it matches the role class in PRT-4.
How Vorro parses and produces PRT
Vorro associates each PRT with the parent segment it follows and exposes the role (PRT-4) plus the populated identity field as a structured participant on that parent. On the produce side, Vorro emits PRT only on channels configured for v2.7+, sets PRT-2 from the participation lifecycle (add/update/delete), stamps PRT-1 so later messages can amend the same participation, and selects the FHIR target resource from PRT-4 and the identity field when transforming to FHIR.
Related pages
- ROL — the older role segment PRT modernizes and largely supersedes.
- OBX — the observation segment a PRT frequently follows to name a performer.
- ORU messages — where PRT attaches participants to OBR and OBX.
