The NPU (Bed Status Update) segment reports the current status of a specific bed within patient-administration workflows. It is a deliberately small segment: it names a bed location and states whether that bed is occupied, available, contaminated, or otherwise unavailable.
NPU lets bed-management and census systems stay synchronized with the facility's real-time occupancy without sending a full patient record. It describes the bed, not the patient, which is what makes it useful for housekeeping, admitting, and capacity dashboards.
Purpose
The NPU segment communicates a bed status change: it identifies the bed by location and reports its status. It is used to keep downstream systems aware of which beds are usable, so admitting and bed-management functions can place patients correctly.
NPU is about the operational state of a physical bed, distinct from any encounter or patient association.
Used in
NPU (Bed Status Update) reports bed status in patient-administration messages. See ADT messages.
- Bed-status-update events carry NPU so census and bed-management systems learn when a bed changes state.
- NPU complements PV1 and LOC, which describe patient visits and locations, by reporting the standalone status of a bed.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (NPU.html). Length is shown as —; Required and Table # come from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| NPU-1 | Bed Location | pl | — | R | — | — | Bed being reported, as a location |
| NPU-2 | Bed Status | is | — | O | — | HL70116 | Operational status of the bed |
Most-used fields
- NPU-1 Bed Location: the required field that identifies exactly which bed the update concerns, expressed as a full point-of-care location.
- NPU-2 Bed Status: the coded status value (for example occupied, unoccupied, or contaminated) that the message exists to deliver.
Because NPU has only two fields, both are essentially the message: one names the bed, the other reports its state.
Version differences (2.3 to 2.8.2)
- 2.3: NPU is defined in the patient-administration chapter with NPU-1 Bed Location and NPU-2 Bed Status.
- 2.3.1 to 2.4: The two-field layout is unchanged; the PL data type underlying NPU-1 gains components.
- 2.5 and 2.5.1: NPU carries the two fields documented here, with NPU-2 typed as IS against the bed-status table.
- 2.6 to 2.8.2: The segment remains a compact two-field structure; refinements occur inside the PL data type and the associated status table rather than in the NPU field list.
The stability of NPU across versions makes it one of the simpler segments to support, though PL component differences still warrant version-aware parsing.
Common mistakes
- Leaving NPU-1 Bed Location empty: it is required, and without it the status update has no subject.
- Sending a bed status without the full PL location, so the receiver cannot resolve which bed changed.
- Using a free-text status in NPU-2 instead of a value from the bed-status table.
- Treating NPU as a patient event; it describes a bed, and attaching patient identity to it confuses the model.
- Assuming NPU repeats within a single update; report one bed per NPU instance.
Examples
Minimal NPU with just the required bed location:
NPU|HOSP_B^3W^312^A
Fully populated NPU:
NPU|HOSP_B^3W^312^A^^N^^^Three West^^312^A|O
Annotated breakdown:
NPU-1 HOSP_B^3W^312^A^^N^^^Three West^^312^A Bed location (facility, ward, room, bed)
NPU-2 O Bed status = occupied
In-context excerpt within a bed-status-update message:
MSH|^~&|BEDMGR|HOSP_B|CENSUS|HOSP_B|20260610142200||ADT^A15^ADT_A15|MSG00512|P|2.5.1
EVN|A15|20260610142200
NPU|HOSP_B^3W^312^A^^N^^^Three West^^312^A|U
A second in-context excerpt reporting a freshly vacated bed alongside the visit context:
EVN|A15|20260610150000
NPU|HOSP_B^3W^312^A^^N^^^Three West^^312^A|C
PV1|1|I|HOSP_B^3W^312^A^^N||||||MED
FHIR mapping
- Source: NPU
- Target: Not mapped at the segment level.
- Notes: No segment-level ConceptMap is published in the v2-to-FHIR IG for NPU. Conceptually NPU reports the operational status of a bed and maps toward Location operational status rather than to a standalone resource.
In a FHIR integration, NPU-1 resolves to a Location representing the bed, and NPU-2 informs that Location's operational status, rather than creating a new resource per update.
Engine considerations
- Require NPU-1 before accepting the segment, since the bed location is mandatory.
- Resolve the full PL in NPU-1 to a known bed; partial locations should be flagged.
- Map NPU-2 against the configured bed-status table and reject unknown codes early.
- Keep NPU processing on the bed-management path, separate from patient-merge or encounter logic.
- Expect one bed per NPU; process multiple beds as multiple segments or messages.
How Vorro parses and produces NPU
- On inbound messages, Vorro reads NPU-1 as a structured location and resolves it against the facility's bed directory.
- NPU-2 is validated against the bed-status table and normalized to the receiver's expected status vocabulary.
- On outbound messages, Vorro always writes a complete NPU-1 location and only adds NPU-2 when a status value is available.
- Bed-status updates are routed to census and bed-management subscribers without being confused for patient events.
- Unknown or partial bed locations are surfaced as validation errors rather than silently passed through.
