HL7 MFN_M05 (Patient Location Master File) | Integration Soup HL7 Reference Guide

HL7 MFN_M05 Patient Location Master File

The reference feed for wards, rooms, beds, departments, and the metadata around them.

HL7 message structure MFN_M05 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SFT	Software Segment	No	Yes
MFI	Master File Identification	Yes	No
MFN_M05.MF_LOCATION	Mf Location group	Yes	Yes
MFE	Master File Entry	Yes	No
LOC	Location Identification	Yes	No
LCH	Location Characteristic	No	Yes
LRL	Location Relationship	No	Yes
MFN_M05.MF_LOC_DEPT	Mf Loc Dept group	Yes	Yes
LDP	Location Department	Yes	No
LCH	Location Characteristic	No	Yes
LCC	Location Charge Code	No	Yes

MFN_M05 publishes the patient location master file. This is the catalog behind the places that show up later in PV1-3 Assigned Patient Location, transfer messages, scheduling, census views, bed boards, and billing rules.

It is not an admission, discharge, or transfer message. An ADT_A02 says a patient moved. MFN_M05 says the location itself exists, how it is described, how it relates to other locations, which departments use it, and sometimes how it is charged.

A small MFN M05 example

MSH|^~\&|ADTADMIN|CITYHOSP|EHR|CITYHOSP|20260722101000||MFN^M05^MFN_M05|MFN050001|P|2.5.1 MFI|LOC^Patient location master^HL70175|ADTADMIN^CITYHOSP|UPD|20260722101000|20260722110000|AL MFE|MAD|MFN050001|20260722110000|WARD1^101^1^CITYHOSP|PL LOC|WARD1^101^1^CITYHOSP|Ward 1 Room 101 Bed 1|B|City Hospital LCH|WARD1^101^1^CITYHOSP|A||PRIVATE^Private room^L|Y^Yes^HL70136 LRL|WARD1^101^1^CITYHOSP|A||PARTOF^Part of^L|City Hospital|WARD1^101^^CITYHOSP LDP|WARD1^101^1^CITYHOSP|CARD^Cardiology^L|MED|CARD^Cardiology^L|I~O|A|20260722 LCC|WARD1^101^1^CITYHOSP|CARD^Cardiology^L|PRIVATE^Private room^L|ROOMDAILY^Daily room charge^L

What workflow it represents

The sender is usually ADT administration, facilities, a bed-management application, or an enterprise location master. Receivers use the feed to validate locations, populate picklists, drive census displays, route orders, support encounter transfers, and map local locations to downstream systems.

Clean location reference data makes later ADT traffic calmer. A transfer to a location code nobody has loaded can break routing, create manual work queues, or leave a bed-board view looking wrong even when the ADT event itself is well formed.

How to read the structure

MSH, MFI, and MFE do the usual master-file work: message identity, file identity, and record identity.

LOC is the required location record. LCH adds location characteristics, and LRL describes relationships to other locations or organizations.

The nested MF_LOC_DEPT group is required in the local v2.5.1 structure. LDP ties the location to a department or service. LCH can appear again under LDP for department-specific characteristics, and LCC can attach charge codes to that location/department combination.

Implementation traps

The biggest trap is mixing physical identity with current use. LOC describes the location itself, not which patient is there today. Current occupancy belongs in ADT and bed-management workflows.

Another trap is losing hierarchy. A receiver may need to know that a bed belongs to a room, the room belongs to a nursing unit, and the nursing unit rolls up to a facility. If the feed only sends display labels, downstream routing and reporting become guesswork.

Pay attention to where LCH appears. A characteristic directly after LOC applies to the location generally; a characteristic after LDP can be department-specific. That distinction matters when one physical room is used differently by different services.

Reference notes

HL7 v2+ describes MFN_M05 as the patient location master-file event and notes that MFI-1 should identify the LOC master file. Its structure places required LOC detail after MFE, followed by optional location characteristics and relationships, then required department detail.