The FAC (Facility) segment describes a physical facility as master-file data: its identifier, type, address, and the people responsible for it. It is used where systems exchange descriptions of facilities themselves rather than encounters or patients, so that every participant agrees on what a facility is, where it is, and who to contact about it.
FAC groups together the facility's own contact details and the contact and signature-authority people associated with it, making it a compact record of organizational and location information suitable for master-file synchronization.
Purpose
The FAC segment carries facility master data: a facility identifier, a facility type, one or more addresses, telecommunication numbers, and the contact person and signature authority responsible for the facility. It lets a master-file feed describe a facility in enough detail for a receiving system to register or update it.
FAC is used when facility-level reference data must be kept in sync between systems, distinct from patient or encounter messages.
Used in
FAC (Facility) carries facility master data in master-file and registration contexts. See MFN master file messages.
- Master-file notification (MFN) flows describe facilities so receivers can maintain a consistent facility directory.
- FAC pairs naturally with LOC and ORG segments that describe locations and organizations in the same master-file context.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (FAC.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 |
|---|---|---|---|---|---|---|---|
| FAC-1 | Facility ID-FAC | ei | — | O | — | — | Unique identifier of the facility |
| FAC-2 | Facility Type | id | — | O | — | — | Type or category of the facility |
| FAC-3 | Facility Address | xad | — | O | Y | — | Physical or mailing address of facility |
| FAC-4 | Facility Telecommunication | xtn | — | O | — | — | Main facility phone or contact number |
| FAC-5 | Contact Person | xcn | — | O | Y | — | Person to contact about the facility |
| FAC-6 | Contact Title | st | — | O | Y | — | Job title of the contact person |
| FAC-7 | Contact Address | xad | — | O | Y | — | Address of the contact person |
| FAC-8 | Contact Telecommunication | xtn | — | O | Y | — | Phone or number for the contact person |
| FAC-9 | Signature Authority | xcn | — | O | Y | — | Person authorized to sign for facility |
| FAC-10 | Signature Authority Title | st | — | O | — | — | Title of the signature authority |
| FAC-11 | Signature Authority Address | xad | — | O | Y | — | Address of the signature authority |
| FAC-12 | Signature Authority Telecommunication | xtn | — | O | — | — | Number for the signature authority |
Most-used fields
- FAC-1 Facility ID-FAC: the entity identifier that uniquely names the facility and ties updates to the correct record.
- FAC-2 Facility Type: the category code that lets receivers classify the facility (for example hospital, clinic, or laboratory).
- FAC-3 Facility Address: the repeating address field, often holding both a physical and a mailing address.
- FAC-4 Facility Telecommunication: the primary number used to reach the facility.
- FAC-5 Contact Person: the named individual a receiver can reach for facility questions, typically paired with FAC-6 and FAC-8.
Version differences (2.3 to 2.8.2)
- 2.3: FAC is defined within the master-file material with its identifier, type, address, and contact and signature-authority fields.
- 2.3.1 to 2.4: Layout is stable; the XAD, XCN, and XTN data types gain components that FAC inherits.
- 2.5 and 2.5.1: FAC carries the twelve fields documented here, with FAC-1 typed as EI and the contact and signature blocks fully present.
- 2.6 to 2.8.2: The segment shape is retained while underlying complex types are refined; verify component-level expectations against the negotiated version.
Because FAC leans heavily on XAD, XCN, and XTN, most cross-version variation shows up inside those data types rather than in the FAC field list itself.
Common mistakes
- Leaving FAC-1 empty, which makes it impossible for the receiver to match the facility to an existing master-file record.
- Confusing the facility's own contact (FAC-4, FAC-5) with the signature authority block (FAC-9 through FAC-12); they describe different roles.
- Collapsing multiple FAC-3 addresses into one repetition and losing the distinction between physical and mailing addresses.
- Sending FAC outside a master-file context as if it were an encounter segment.
- Assuming FAC-2 is free text; it is a coded type value and should match the receiver's expected categories.
Examples
Minimal FAC with an identifier and type:
FAC|FAC0098^^^VORRO_FAC|H
Fully populated FAC:
FAC|FAC0098^^^VORRO_FAC|H|275 Harbor Blvd^^Lakeside^OR^97001^USA^M~12 Dock Rd^^Lakeside^OR^97001^USA^C|^WPN^PH^^1^503^5550100|10293^Vance^Iris^^^Dr^MD^^VORRO_FAC|Facility Administrator|31 Pine Ct^^Lakeside^OR^97001^USA|^WPN^PH^^1^503^5550101|55810^Hale^Marcus^^^Dr^MD^^VORRO_FAC|Chief Medical Officer|31 Pine Ct^^Lakeside^OR^97001^USA|^WPN^PH^^1^503^5550102
Annotated breakdown:
FAC-1 FAC0098^^^VORRO_FAC Facility entity identifier
FAC-2 H Facility type code (hospital)
FAC-3 275 Harbor Blvd...~12 Dock Rd Two addresses: mailing then campus
FAC-4 ^WPN^PH^...5550100 Main facility phone
FAC-5 10293^Vance^Iris^... Contact person (with assigning authority)
FAC-6 Facility Administrator Contact person title
FAC-7 31 Pine Ct^^Lakeside... Contact person address
FAC-8 ^WPN^PH^...5550101 Contact person phone
FAC-9 55810^Hale^Marcus^... Signature authority person
FAC-10 Chief Medical Officer Signature authority title
FAC-11 31 Pine Ct^^Lakeside... Signature authority address
FAC-12 ^WPN^PH^...5550102 Signature authority phone
In-context excerpt within a master-file (MFN) facility update:
MSH|^~&|MFSYS|VORRO|EHR|HOSP_B|20260610091500||MFN^M01^MFN_M01|MFN00077|P|2.5.1
MFI|FAC^Facility Master^HL70175|VORRO|UPD|20260610091500||AL
MFE|MUP|VORRO0098|20260610091500|FAC0098^^^VORRO_FAC|CE
FAC|FAC0098^^^VORRO_FAC|H|275 Harbor Blvd^^Lakeside^OR^97001^USA^M|^WPN^PH^^1^503^5550100|10293^Vance^Iris^^^Dr^MD|Facility Administrator
A second in-context excerpt pairing FAC with location detail:
MFE|MAD|VORRO0099|20260610091500|FAC0099^^^VORRO_FAC|CE
FAC|FAC0099^^^VORRO_FAC|C|9 Lakeshore Way^^Lakeside^OR^97001^USA^M|^WPN^PH^^1^503^5550133|10477^Brooks^Dana^^^Dr^MD|Clinic Manager|9 Lakeshore Way^^Lakeside^OR^97001^USA|^WPN^PH^^1^503^5550134
LOC|LAK-CLINIC^^VORRO_LOC|Lakeside Outpatient Clinic|C
FHIR mapping
- Source: FAC
- Target: Not mapped at the segment level.
- Notes: No segment-level ConceptMap is published in the v2-to-FHIR IG for FAC. Conceptually FAC describes a facility and maps toward an Organization or Location resource rather than to a single standalone resource.
In a FHIR integration, FAC-1 and FAC-2 inform the Organization or Location identity and type, FAC-3 and FAC-4 supply address and telecom, and the contact and signature-authority people map onto contact roles attached to the chosen resource.
Engine considerations
- Treat FAC as master-file data and route it through facility-directory logic, not encounter processing.
- Preserve all FAC-3 repetitions so address purpose codes survive the transform.
- Keep the FAC-1 assigning-authority component intact for reliable record matching.
- Distinguish the contact block (FAC-5 to FAC-8) from the signature-authority block (FAC-9 to FAC-12) when mapping people.
- Validate FAC-2 against the agreed facility-type values before producing the segment.
How Vorro parses and produces FAC
- On inbound master-file messages, Vorro keys FAC records on FAC-1 and upserts the facility directory based on the surrounding MFE action code.
- Repeating addresses and people fields are normalized into lists so no repetition is dropped.
- On outbound messages, Vorro writes FAC-1 first, then emits only populated optional fields to keep segments lean.
- Contact and signature-authority roles are modeled separately so they map cleanly onto downstream contact structures.
- Facility-type and address-purpose codes are validated against configured tables prior to production.
