The PRA (Practitioner Detail) segment supplies the practitioner-specific attributes that elaborate on a staff record. It is a child segment of STF: where STF identifies the person, PRA describes their professional role — the groups they practice with, their categories and specialties, license and credential numbers, hospital privileges, and the dates that bound their practice. PRA is exchanged inside MFN^M02 master file notification messages so receiving systems can maintain an accurate, credentialed view of each clinician.
Purpose
The purpose of PRA is to convey the professional and credentialing detail of a practitioner whose identity has already been established by the preceding STF segment. It records practitioner group affiliations, practitioner categories, billing eligibility, specialties, license and identifier numbers, privileges, and the dates a practitioner entered and left practice. Because PRA shares its primary key with STF-1, the receiving system can attach this detail to the correct person.
Used in
PRA is used in MFN^M02 Master File Notification messages for staff and practitioner records. It follows the STF segment within the same master file entry group and may itself be followed by one or more ORG segments describing the organizational units the practitioner is associated with.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (PRA) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| PRA-1 | Primary Key Value - PRA | ce | — | R | — | — | Primary key linking this detail to the staff record |
| PRA-2 | Practitioner Group | ce | — | O | Y | HL70358 | Practitioner group affiliations |
| PRA-3 | Practitioner Category | is | — | O | Y | HL70186 | Category of practitioner such as attending or resident |
| PRA-4 | Provider Billing | id | — | O | — | HL70187 | How the provider bills for services |
| PRA-5 | Specialty | spd | — | O | Y | — | Specialties of the practitioner |
| PRA-6 | Practitioner ID Numbers | pln | — | O | Y | — | License and credential identifier numbers |
| PRA-7 | Privileges | pip | — | O | Y | — | Privileges granted to the practitioner |
| PRA-8 | Date Entered Practice | dt | — | O | — | — | Date the practitioner entered practice |
| PRA-9 | Institution | ce | — | O | — | HL70537 | Institution where the practitioner trained or practices |
| PRA-10 | Date Left Practice | dt | — | O | — | — | Date the practitioner left practice |
| PRA-11 | Government Reimbursement Billing Eligibility | ce | — | O | Y | HL70401 | Eligibility for government reimbursement billing |
| PRA-12 | Set ID - PRA | si | — | O | — | — | Sequence number for repeated PRA segments |
Most-used fields
The fields that carry the most weight in real integrations are PRA-1, PRA-3, PRA-5, and PRA-6. PRA-1 (Primary Key Value) anchors the detail to the matching STF record and must equal STF-1. PRA-3 (Practitioner Category) classifies the practitioner's role and drives directory and scheduling logic. PRA-5 (Specialty) is the field provider directories most often display and filter on. PRA-6 (Practitioner ID Numbers) carries the license and DEA-style identifiers that credentialing and billing systems depend on. PRA-2 (Practitioner Group) is frequently used where group affiliation affects routing or reimbursement.
Version differences (2.3 to 2.8.2)
PRA appeared in HL7 v2.3 as the practitioner detail companion to STF, originally with the primary key, group, category, billing, specialty, identifier, privileges, and practice-date fields. Version 2.4 added the Government Reimbursement Billing Eligibility field (PRA-11) and the Set ID (PRA-12) to support repeating PRA segments for practitioners with multiple roles. Versions 2.5 and 2.5.1 retained the twelve-field structure documented here. Later versions through 2.8.2 left the field set essentially intact while refining table bindings and the underlying complex types (SPD, PLN, PIP); a 2.5.1 PRA therefore remains compatible with later-version parsers.
Common mistakes
The most common mistake is letting PRA-1 drift from STF-1, which orphans the practitioner detail from its person record. Another is collapsing the repeating fields — PRA-2, PRA-3, PRA-5, PRA-6, PRA-7, and PRA-11 all repeat, and practitioners frequently have multiple specialties, identifiers, and privileges. Integrators sometimes place a national provider identifier in PRA-6 when the receiving system expects it in STF-2; the two fields serve different purposes and the agreement should be explicit. Finally, sending free-text where a coded category or specialty is expected leads to records that cannot be filtered downstream.
Examples
A minimal valid PRA segment with the primary key and a single category:
PRA|1234^^^HOSP^PRN||FACPHY
A fully populated PRA segment exercising the repeating fields:
PRA|1234^^^HOSP^PRN|GRP01^Cardiology Group^L~GRP07^Cath Lab^L|FACPHY~ATND|RR|207RC0000X^Cardiology^NUCC~207RI0011X^Interventional Cardiology^NUCC|D1234567^NY^MD^20281231~DEA9876543^^DEA^20271130|ADMIT^Admitting^L~SURG^Surgical^L|20100701|UNIV01^State University Hospital^L|20300101|Y^Eligible^HL70401|1
Annotated breakdown of the key fields:
PRA|1234^^^HOSP^PRN|GRP01^Cardiology Group^L|FACPHY|RR|207RC0000X^Cardiology^NUCC|D1234567^NY^MD|ADMIT^Admitting^L
| | | | | | |
| | | | | | +--> PRA-7 Privileges
| | | | | +----------------------> PRA-6 Practitioner ID Numbers
| | | | +-----------------------------------------------> PRA-5 Specialty
| | | +--------------------------------------------------> PRA-4 Provider Billing
| | +----------------------------------------------------------> PRA-3 Practitioner Category
| +-------------------------------------------------------------------------------------> PRA-2 Practitioner Group
+----------------------------------------------------------------------------------------------------> PRA-1 Primary Key Value - PRA
In-context excerpt inside an MFN^M02 message, adding practitioner detail beneath a staff record:
MSH|^~&|HRSYS|HOSP|DIRSVC|HOSP|20260610091500||MFN^M02^MFN_M02|MSG00010|P|2.5.1
MFI|PRA^Practitioner Master File^HL70175|HOSP|UPD|20260610091500||AL
MFE|MAD|PKEY010|20260610091500|1234^^^HOSP^PRN|CM
STF|1234^^^HOSP^PRN|987654^^^NPI|SMITH^JOHN^A|P|M|19700115|A
PRA|1234^^^HOSP^PRN|GRP01^Cardiology Group^L|FACPHY|RR|207RC0000X^Cardiology^NUCC|D1234567^NY^MD^20281231|ADMIT^Admitting^L|20100701
A second in-context excerpt updating specialties and license dates for an existing practitioner:
MSH|^~&|HRSYS|HOSP|DIRSVC|HOSP|20260610094500||MFN^M02^MFN_M02|MSG00011|P|2.5.1
MFI|PRA^Practitioner Master File^HL70175|HOSP|UPD|20260610094500||AL
MFE|MUP|PKEY011|20260610094500|1234^^^HOSP^PRN|CM
STF|1234^^^HOSP^PRN|987654^^^NPI|SMITH^JOHN^A|P|||A
PRA|1234^^^HOSP^PRN||FACPHY||207RC0000X^Cardiology^NUCC~207RI0011X^Interventional Cardiology^NUCC|D1234567^NY^MD^20291231
FHIR mapping
No segment-level ConceptMap is published in the v2-to-FHIR IG for PRA. Conceptually the practitioner detail described by PRA corresponds to a FHIR PractitionerRole resource for the role, specialty, and organizational context, together with Practitioner.qualification for the license and credential numbers carried in PRA-6. Specialties map to PractitionerRole.specialty, group affiliations to PractitionerRole.organization, and practice dates to PractitionerRole.period. Because no formal segment-level ConceptMap exists, implementers define these mappings locally.
Engine considerations
Engines should validate that PRA-1 matches the STF-1 of the staff record it follows and reject or quarantine messages where they diverge. Several PRA fields repeat, so engines must expand them into arrays rather than reading only the first occurrence; this matters most for specialties and identifier numbers. When PRA-12 (Set ID) is used to send multiple PRA segments for one person, engines should order detail records by the Set ID. Complex types such as SPD, PLN, and PIP should be parsed component-by-component so that license states, expiration dates, and privilege classes survive translation.
How Vorro parses and produces PRA
Vorro parses PRA by matching PRA-1 against the staff record key established by the preceding STF, then expanding the repeating category, specialty, identifier, privilege, and reimbursement fields into normalized collections. Coded fields are resolved against the configured HL7 tables while retaining their original components, and the PLN identifier numbers are decomposed so license type, state, and expiration are individually addressable. When producing PRA, Vorro emits PRA-1 equal to STF-1, writes specialties and identifiers from the normalized credential model, and uses PRA-12 to sequence multiple role records for the same practitioner, leaving optional fields empty rather than padding them.
Related pages
- HL7 STF Segment: Staff Identification
- HL7 ORG Segment: Practitioner Organization Unit
- HL7 MFN Message: Master File Notification
