Reference·PD1 Segment·PD1-3
HL7 v2 Reference

HL7 v2 PD1-3 (Patient Primary Facility): Format, Values, and Testing Notes

Jul 28, 2026 · 4 min read
PD1-4 →

PD1-3 answers a question that MSH can't: not who sent this particular message, but which facility the patient actually considers home base for care. Mix the two up in test data and referral-routing logic never gets a real workout.

Quick answer

PD1-3 is the Patient Primary Facility field, a composite value naming the organization (and optionally an identifier) that the patient is primarily affiliated with for care. It's independent of the sending facility recorded in the message header, and it's most often read by systems deciding where to route referrals or care summaries.

What this field contains

Component 1
Organization name — the free-text or coded name of the primary facility, e.g. SYNTHIB COMMUNITY CLINIC
Component 3
Organization identifier — an internal or assigning-authority ID for that facility, used when systems need more than a name match
Common case
Matches sending facility — when a patient is being treated at their home facility, PD1-3 often mirrors the facility in MSH-4
Divergent case
Differs from sending facility — common for network transfers, referrals, or multi-site health systems where the encounter facility isn't the patient's usual one

Example

Synthetic example Generated by Synthibase
PD1|||SYNTHIB COMMUNITY CLINIC^^12345|4521^WELLS^SARAH^^^DR|||||||01^ONE PER PATIENT^SYNTHIBLOCAL|Y|20260101|||A|20260115

PD1-3 (SYNTHIB COMMUNITY CLINIC^^12345) names the patient's primary facility, independent of whichever facility generated this message.

Where this trips people up

It's common for test fixtures to hardcode PD1-3 to whatever facility is sending the message, since in a single-site test environment the two happen to be identical. That habit means multi-facility routing logic — the code that has to notice a patient's primary facility differs from the encounter facility and act accordingly — stays untested until a real cross-site referral surfaces the gap, usually as a care summary sent to the wrong location.

Testing HL7 v2 PD1: The Fields Your System Actually Needs to Handle
How to Build a Synthetic Patient Registry for Healthcare Testing
HL7 ADT Messages: A01 through A08 Explained
Test cross-facility routing with realistic data
Synthibase can generate patients whose primary facility differs from the encounter facility, so your referral and care-summary routing logic gets exercised beyond the single-site happy path.
Start free trial →
This page is written independently by Synthibase for testing and informational purposes. It is not an official publication of HL7 International or X12/Washington Publishing Company, and is not a substitute for reviewing the official standard or your trading partner's companion guide. See our Terms of Service for full legal terms.