The PID segment, short for Patient Identification, tells every receiving system who a message is about. It appears in almost every HL7 v2 message, from ADT and orders to results and scheduling. When PID is incomplete or inconsistent, results file to the wrong patient, duplicates multiply and merges become painful. This reference covers every PID field, how identifiers work and how to support accurate patient matching. For ADT-specific usage, see our HL7 ADT message catalog and our HL7 message types guide. Fighting duplicate patients? Request a free HL7 interface review.
What the PID Segment Does
PID carries the demographic and identifying information receivers use to find or create the correct patient record. Because patient identity affects every downstream workflow, PID deserves more attention than most segments in interface design, testing and ongoing monitoring.
Present in most message types
PID appears in ADT, ORM, ORU, SIU, MDM, DFT and many other messages. Each receiving system uses it to locate the patient before processing the rest of the message. Consistent PID content across message types prevents the same patient appearing differently in different feeds.
Identifiers versus demographics
PID combines identifiers, such as medical record numbers, with demographics, such as name, birth date and address. Identifiers should drive matching wherever possible. Demographics support matching when identifiers are missing and help staff confirm identity during manual review. Document matching rules clearly.
Relationship to PV1 and other segments
PID identifies the patient, while PV1 describes the visit or encounter. Related segments such as PD1, NK1 and IN1 add care team, next of kin and insurance details. Together they give receivers the context needed to file data correctly. Validate them together.
Why PID errors are costly
Wrong or missing identity data can attach results to the wrong patient, a serious safety risk. It also creates duplicate records that require manual merges. Investing in PID validation and monitoring saves far more effort than cleaning up identity errors later.
PID Field Reference (HL7 v2.5.1)
The table below lists PID fields as defined in HL7 v2.5.1. Optionality uses standard codes: R for required, O for optional, C for conditional and B for retained for backward compatibility. Many partners require more fields than the base standard, particularly for matching.
| Seq | Field name | Data type | Opt | Notes |
| PID-1 | Set ID – PID | SI | O | Sequence number |
| PID-2 | Patient ID | CX | B | Use PID-3 instead |
| PID-3 | Patient Identifier List | CX | R | MRN and other identifiers, repeating |
| PID-4 | Alternate Patient ID – PID | CX | B | Use PID-3 instead |
| PID-5 | Patient Name | XPN | R | Family name, given name and more |
| PID-6 | Mother’s Maiden Name | XPN | O | Supports matching |
| PID-7 | Date/Time of Birth | TS | O | Key matching attribute |
| PID-8 | Administrative Sex | IS | O | Values from HL7 table 0001 |
| PID-9 | Patient Alias | XPN | B | Use repeating PID-5 instead |
| PID-10 | Race | CE | O | Coded race values |
| PID-11 | Patient Address | XAD | O | Repeating addresses |
| PID-12 | County Code | IS | B | Use PID-11 county component |
| PID-13 | Phone Number – Home | XTN | O | Home and personal contacts |
| PID-14 | Phone Number – Business | XTN | O | Work contacts |
| PID-15 | Primary Language | CE | O | Preferred language |
| PID-16 | Marital Status | CE | O | Coded marital status |
| PID-17 | Religion | CE | O | Coded religion |
| PID-18 | Patient Account Number | CX | O | Billing account, often visit-level |
| PID-19 | SSN Number – Patient | ST | B | Retained for compatibility |
| PID-20 | Driver’s License Number | DLN | B | Retained for compatibility |
| PID-21 | Mother’s Identifier | CX | O | Links newborns to mothers |
| PID-22 | Ethnic Group | CE | O | Coded ethnicity |
| PID-23 | Birth Place | ST | O | Place of birth |
| PID-24 | Multiple Birth Indicator | ID | O | Y or N |
| PID-25 | Birth Order | NM | O | Order in a multiple birth |
| PID-26 | Citizenship | CE | O | Citizenship |
| PID-27 | Veterans Military Status | CE | O | Military status |
| PID-28 | Nationality | CE | B | Retained for compatibility |
| PID-29 | Patient Death Date and Time | TS | O | Date and time of death |
| PID-30 | Patient Death Indicator | ID | O | Y or N |
| PID-31 | Identity Unknown Indicator | ID | O | For unidentified patients |
| PID-32 | Identity Reliability Code | IS | O | Reliability of identity data |
| PID-33 | Last Update Date/Time | TS | O | When demographics last changed |
| PID-34 | Last Update Facility | HD | O | Facility that last updated |
| PID-35 | Species Code | CE | C | Veterinary use |
| PID-36 | Breed Code | CE | C | Veterinary use |
| PID-37 | Strain | ST | O | Veterinary use |
| PID-38 | Production Class Code | CE | O | Veterinary use |
| PID-39 | Tribal Citizenship | CWE | O | Tribal citizenship |
Patient Identifiers in PID-3
PID-3 is the most important field in the segment. It repeats, allowing several identifiers for the same patient, each with its own type and assigning authority. Handling PID-3 correctly is the foundation of reliable patient matching across systems.
The CX data type
Each PID-3 repetition uses the CX data type, which includes the identifier, an assigning authority and an identifier type code. The assigning authority tells receivers which system issued the number, preventing confusion between identical numbers from different organizations. Validate every component carefully.
Identifier type codes
Identifier type codes describe what each identifier represents, such as MR for medical record number. Using type codes consistently lets receivers select the right identifier for matching. Agree on expected codes with every partner and validate them in testing. Document them in specifications.
Multiple identifiers per patient
Patients often carry several identifiers, such as an enterprise ID, a facility MRN and an external system ID. Send all relevant identifiers in PID-3 repetitions. Receivers can then match on the identifier they trust while preserving the others for cross-referencing.
Enterprise and master patient indexes
Organizations with several facilities often use an enterprise master patient index to link records. PID-3 then carries the enterprise ID alongside local MRNs. Our master patient index services help organizations design and maintain these identity systems. Plan identifier strategy before connecting new facilities.
Example PID Segment
The sample below shows a patient with an MRN, name, birth date, sex, address and home phone. Values are fictional and shown in standard pipe-delimited format so teams can validate parsing, field positions and component handling during testing.
PID|1||MRN123456^^^HOSP^MR||Doe^Jane^Marie||19850214|F|||123 Main St^^Springfield^IL^62701^USA||^PRN^PH^^^217^5551234
Reading the identifiers
PID-1 is the set ID. PID-2 is empty, as recommended. PID-3 holds MRN123456 with assigning authority HOSP and identifier type MR. Receivers use these components together to locate the patient in the correct system. Missing any component weakens matching accuracy significantly.
Reading the demographics
PID-5 holds the name as family, given and middle names. PID-7 is the birth date, PID-8 the administrative sex, PID-11 the address with street, city, state, postal code and country, and PID-13 the home phone number. Validate each component during testing.
Empty fields and repeats
Empty fields keep later fields in position through consecutive pipes. Repeating fields such as PID-3 or PID-11 use the tilde character to separate repetitions. Parsers must handle both correctly to avoid shifting values into the wrong fields. Test parsers with repeating fields.
Implementation Tips for Reliable Matching
Most PID problems involve missing assigning authorities, inconsistent name formats and poor handling of updates and merges. These tips reflect issues we see repeatedly when building ADT, order and result interfaces for hospitals, clinics and digital health platforms.
Always include assigning authorities
Identifiers without assigning authorities are ambiguous, especially across organizations. Require them in PID-3, and reject or flag messages without them. This simple rule prevents many matching errors when several systems use overlapping numbering schemes. Document required assigning authorities in every partner specification.
Normalize names and dates
Names arrive with different capitalization, punctuation and component usage. Normalize names consistently before matching, and validate birth date formats. Consistent normalization improves automated matching and reduces records sent to manual review queues. Apply the same normalization rules across every interface you manage.
Handle demographic updates
Patient details change through ADT updates, such as A08 messages. Receivers must update stored demographics rather than create new records. Track update timestamps, and apply changes carefully so older messages do not overwrite newer information. Log every update for audit purposes.
Plan for merges
When duplicate records are merged, ADT merge messages tell receivers which identifiers to combine. Our guide to HL7 ADT patient merge handling explains how to process merges without losing data or breaking links. Test merge scenarios with every partner before go-live, because merge errors are hard to reverse.
How Taction Helps With Patient Identity in HL7
Taction has delivered 200+ healthcare projects, including ADT, order and result interfaces and patient identity solutions. We help organizations map PID accurately, enforce identifier rules and reduce duplicates across connected systems.
Free HL7 interface review
Share sample messages and partner specifications. We review PID usage, identifiers, assigning authorities and update handling, then flag matching risks and fixes. You get clear recommendations. Request your free review. We also flag quick fixes you can apply immediately to reduce duplicate records.
ADT and interface development
We build ADT and other HL7 interfaces through engines such as Mirth Connect, with validation and monitoring. Explore our HL7 integration services for how we keep patient identity consistent across feeds. Every interface includes alerting, so identity errors are caught before they reach clinical workflows.
Identity and MPI solutions
We design matching rules, enterprise identifiers and merge workflows that keep patient records accurate. Our engineers combine interface validation with identity management, reducing duplicates and the manual effort required to resolve them. We also build dashboards that show duplicate rates and merge activity across connected systems over time.
HL7 engineers on demand
Need experienced interface engineers? Hire HL7 integration engineers who understand patient identity, ADT workflows and engine development. They join your team quickly and document every interface thoroughly. Engagements scale with your roadmap, from a single ADT feed to support across many facilities, partners and connected clinical systems.
Frequently Asked Questions
These answers cover common questions about the HL7 PID segment. Because implementation guides and partners often add rules beyond the base standard, always confirm requirements with the specifications for your specific interface.
What does PID stand for in HL7?
PID stands for Patient Identification. It carries identifiers and demographics that receiving systems use to find or create the correct patient record. PID appears in most HL7 v2 messages, including ADT, orders, results and scheduling messages. Accuracy here protects patient safety.
Which PID fields are required?
In HL7 v2.5.1, PID-3 Patient Identifier List and PID-5 Patient Name are required. Many partners also require birth date, sex and address for matching, so check each specification and validate these fields before messages reach production systems. Partners often require much more.
What is the difference between PID-2 and PID-3?
PID-2 Patient ID is retained only for backward compatibility. PID-3 Patient Identifier List is the correct field for identifiers in current versions, supporting multiple repetitions with assigning authorities and identifier type codes. New interfaces should always populate PID-3 and leave PID-2 empty.
What goes in PID-18?
PID-18 Patient Account Number usually carries the billing account, often tied to a specific visit or encounter. It differs from the medical record number in PID-3. Confirm how each partner uses PID-18, because practices vary widely. Document its usage clearly.
How do I prevent duplicate patients?
Include assigning authorities in PID-3, normalize names and dates, handle demographic updates correctly and process merges properly. Combining these practices with an enterprise master patient index significantly reduces duplicate records across connected systems. Monitor duplicate rates regularly over time. Small fixes help.