HL7 PMU Messages: Add Personnel Record

HL7 PMU messages manage the lifecycle of personnel records — clinicians, practitioners, and other staff — across systems that maintain a master file of people authorised to practise or work in a facility. A PMU message can add a new person to the directory, update their demographics or credentials, activate or deactivate their practising status, terminate their record, or grant or revoke a certificate or permission. This page explains what a PMU message represents, every trigger event the message carries, every segment the message can contain and what each one holds, and how a PMU personnel record relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What a PMU message represents

A PMU message — PMU stands for Add Personnel Record — communicates a change to the master file entry for a member of staff. The two core segments are STF and PRA. The STF segment carries the person's identifiers, name, type (physician, nurse, administrator), and contact information; it is the required anchor of every PMU message. The PRA segment is optional and carries practitioner-specific detail — primary specialty, provider IDs (such as NPI and DEA numbers), and privilege detail — applicable only when the person holds a clinical or prescribing role.

The sender is any system that owns or manages the authoritative personnel directory — typically the human-resources information system (HRIS), a credentialing platform, or the master patient index layer of the EHR. Receivers are the systems that need a current, consistent view of who is authorised to order, prescribe, treat, or administer: scheduling, EHR, pharmacy, laboratory, billing, and any access-control or directory service. PMU is the personnel-master-file equivalent of an ADT demographic event — rather than tracking a patient visit, it tracks the authorised state of a person in the organisation.

When a PMU message is sent

A PMU message is sent whenever the authoritative source for the personnel master record produces an event that affects a person's standing or data. A single person produces a sequence of PMU messages over time — added on hire, updated when their contact details change, activated or deactivated as their practising status changes, and eventually terminated — and together those messages form a complete audit trail of the person's history in the directory.

Trigger events

The PMU message type carries seven trigger events:

• PMU^B01 – Add personnel record. Sent when a new person is first registered in the master file.
• PMU^B02 – Update personnel record. Sent when demographics, identifiers, or contact data for an existing person change.
• PMU^B04 – Active practicing person. Sent to signal that a person has been activated and is currently authorised to practise.
• PMU^B05 – Deactivate practicing person. Sent to signal that a person's practising privileges have been suspended or placed on hold, without terminating the record.
• PMU^B06 – Terminate practicing person. Sent when a person's relationship with the organisation ends and their record is closed.
• PMU^B07 – Grant certificate/permission. Sent when a specific credential, certification, or system permission is granted to the person.
• PMU^B08 – Revoke certificate/permission. Sent when a previously granted certificate or permission is withdrawn.

Because PMU carries multiple trigger events, receivers must branch on the trigger code in MSH-9 — a B01 add, a B05 deactivation, and a B08 revocation each require a different downstream action even though all three share the same segment structure.

Integration topology

The diagram shows the personnel management source emitting a PMU event through the integration engine to the systems that maintain a local view of the personnel directory.

{{diagram: HRIS / credentialing system → PMU message → integration engine → EHR / scheduling / pharmacy / billing / access control}}

Typical senders: human-resources information system (HRIS), credentialing or privileging platform, EHR provider directory, or master facility directory.

Typical receivers: EHR provider directory, scheduling system, pharmacy information system, laboratory system, billing or claims platform, and access-control or directory services.

Direction: unidirectional notification from the authoritative personnel source to all downstream systems that hold a derived copy of the record.

Segments in a PMU message

The PMU_B01 and PMU_B02 message structure (shared by all trigger events in the PMU family) opens with the required MSH and EVN segments, followed by the required STF staff identification segment, and then a series of optional and repeating segments that carry practitioner-specific, affiliation, language, education, and certification detail. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

The segment structure from MSH through CER describes one person's record in full. Because the PMU message covers a single person per message, there is no outer repeating group — to update multiple practitioners, the sending system emits one PMU message per person. The canonical segment pages carry the full field-by-field detail.

Sample PMU message

Note. Constructed for illustration. Personnel identifiers, names, dates, and facility codes are fictional.

MSH|^~&|HRIS|MERCYGEN|EHR|MERCYGEN|20260604083000||PMU^B01^PMU_B01|MSG00047|P|2.5.1
EVN|B01|20260604083000
STF|PROV001^MERCYGEN|NPI123456789^UPIN^NPI~DEA987654^DEA|SMITH^JAMES^R|P|MD|19750315|M|A|20260601|GIM^General Internal Medicine^L|^^214^5551234567^WPN
PRA|PROV001^MERCYGEN|||MD|I|NPI123456789^NPI~DEA987654^DEA|IM^Internal Medicine^ABIM|20260601
AFF|1|American College of Physicians||20200101
EDU|1|University of Texas Southwestern Medical School|MD|20010515
CER|1|ABIM^American Board of Internal Medicine^L|IM^Internal Medicine^ABIM|20210601|20310601

What this sample shows

The PMU^B01 in MSH-9 marks an add personnel record event. EVN confirms the event type B01 and records the time the event occurred. The STF segment identifies the practitioner: the internal identifier PROV001 and external identifiers NPI 123456789 and DEA 987654 in STF-2, the name SMITH^JAMES^R in STF-3, the staff type P (physician) in STF-4, and active status A in STF-7 with an effective date of 20260601. The PRA segment carries the practitioner's specialty Internal Medicine (IM) and lists the same NPI and DEA identifiers in PRA-6 along with ABIM board certification in PRA-7. The AFF segment records membership in the American College of Physicians, EDU records the MD degree, and CER records the ABIM Internal Medicine board certification with its expiry date.

Working with PMU messages

Branch on the trigger event, not just the segment content

Unlike message types with a single trigger event, PMU carries seven distinct ones, and the downstream action depends entirely on the trigger code in MSH-9. A B01 add creates a new record; a B05 deactivation suspends privileges without closing the record; a B08 revocation withdraws a specific credential. Build a trigger-event router as the first step in any PMU handler, and confirm the full list of trigger events your integration partner sends — some implementations emit only B01 and B02 and handle status changes through master file notifications instead.

STF is the anchor; PRA is conditional

Every PMU message carries STF. The PRA segment is present only when the record describes a licensed practitioner. Non-clinical staff — administrators, technicians, coders — will have an STF with no following PRA. Parse STF unconditionally and look for PRA conditionally based on the staff type in STF-4.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key. Personnel feeds are replayed after outages, and applying a replayed B01 add a second time risks creating a duplicate provider record. Match incoming records on the stable personnel identifier in STF-2 before deciding whether to insert or update, and treat a repeated control id as a no-op when the record already exists with the same data.

Credential and permission events carry the affected CER

For PMU^B07 grant and PMU^B08 revoke events, the CER segment identifies the specific credential being affected. Surface the certificate type, issuing authority, and effective dates from CER rather than inferring the credential from the person's existing record — a practitioner may hold multiple credentials, and only one is being granted or revoked.

Vendor variance. Some sending systems populate only STF and omit PRA even for physicians, relying on the staff type code in STF-4 to imply clinical status. Others repeat the full complement of AFF, EDU, and CER segments on every update regardless of whether those sections changed. Confirm a partner's field and segment usage against their interface specification rather than assuming the base standard.

FHIR equivalent

A PMU personnel record corresponds conceptually to the FHIR Practitioner resource for the person's identity and credentials, and to the FHIR PractitionerRole resource for their role, specialty, and organisational affiliation. For a messaging exchange, a MessageHeader at the head of a Bundle would accompany these resources.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for PMU and no ConceptMap for the STF or PRA segments. A FHIR Practitioner and PractitionerRole representation produced from a PMU message is therefore mapped manually, taking the identifier list and name from STF, the specialty and provider IDs from PRA, affiliations from AFF, and credentials from CER.

Common pitfalls

Pitfall. Treating all PMU messages as adds. Ignoring the trigger event and always inserting a new record on every PMU duplicates existing practitioners in the provider directory. Route on the trigger event in MSH-9 and match incoming records on the identifier in STF-2 before deciding to insert or update.

Pitfall. Omitting the deactivation and termination events. Systems that handle only B01 and B02 miss B05 deactivations and B06 terminations, leaving deactivated practitioners with active access in downstream systems. Subscribe to all relevant trigger events from the source.

Pitfall. Assuming PRA is always present for physicians. Some senders populate STF-4 with the staff type but do not include a PRA segment even for prescribers. Parse STF unconditionally and treat PRA as optional; derive clinical status from STF-4 when PRA is absent.

Pitfall. Ignoring CER effective and expiry dates. Credential expiry in CER-7 is the definitive indicator of whether a certification is currently valid. Storing only the credential type without the expiry date causes downstream systems to display lapsed credentials as current.

How Vorro handles PMU messages

Vorro ingests the PMU feed over MLLP or another transport, deduplicates on MSH-10, and routes each personnel event to every subscribed destination in the format that system expects — provider directory, scheduling, pharmacy, billing, and access control. Vorro reads the person's identity and status from STF, clinical detail from PRA when present, and credentials from CER, and branches processing on the trigger event in MSH-9 so that an add, an update, a deactivation, and a revocation each follow the correct downstream path. Where a FHIR destination is configured, Vorro maps the record to Practitioner and PractitionerRole resources — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

Related messages

• MFN — the master file notification message, which handles general master file additions and updates across multiple file types including staff.
• ADT — the admit/discharge/transfer message, which tracks patient encounters and references provider identifiers established through PMU.
• MFK — the master file acknowledgement, which a receiving system returns to confirm receipt and processing of a master file update including PMU events.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for PMU
• HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for STF or PRA
• HL7 Messaging Standard Version 2.5.1 product brief