Testing HL7 v2 PD1: The Fields Your System Actually Needs to Handle
PD1 shows up in ADT messages as the segment that didn't fit in PID — primary care provider, whether the patient can be listed in the hospital directory, whether their record is flagged for extra privacy, and where they stand with the state immunization registry. It's short, optional in most implementations, and routinely skipped in test data even though every field on it drives a different downstream workflow.
PD1 is the Patient Additional Demographic segment in HL7 v2. It carries supplementary information that doesn't live in PID — the patient's primary facility and primary care provider, student and publicity flags, a privacy protection indicator, and immunization registry status. It appears in ADT messages and is read by directory services, care-coordination systems, and public health reporting feeds, not by core patient matching.
The fields that actually matter in practice
Example
A synthetic PD1 segment showing a primary facility, an assigned primary care provider, a publicity code, an active protection flag, and an immunization registry status. All names and identifiers are fabricated.
Where this trips people up
Because PD1 is optional in most implementation guides and rarely touches core clinical logic, test data generators frequently drop it from ADT messages entirely — which means the directory-listing, care-team-routing, and privacy-flag logic that reads PD1-11, PD1-4, and PD1-12 never gets exercised until a real VIP patient's chart shows up unprotected in a public directory query. The protection indicator in particular deserves its own test lane: it's a single character with outsized consequences, and a generator that only ever emits "N" (or leaves it blank) gives false confidence that restricted-record handling works.