HL7 PID Patient Identification
HL7 field reference PID fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| PID.1 | Set ID - PID | No | No | SI | |
| PID.2 | Patient ID | No | No | CX | 0061 |
| PID.3 | Patient Identifier List | Yes | Yes | CX | 0061 |
| PID.4 | Alternate Patient ID - PID | No | Yes | CX | |
| PID.5 | Patient Name | Yes | Yes | XPN | |
| PID.6 | Mother's Maiden Name | No | Yes | XPN | |
| PID.7 | Date/Time of Birth | No | No | TS | |
| PID.8 | Administrative Sex | No | No | IS | 0001 |
| PID.9 | Patient Alias | No | Yes | XPN | |
| PID.10 | Race | No | Yes | CE | 0005 |
| PID.11 | Patient Address | No | Yes | XAD | |
| PID.12 | County Code | No | No | IS | 0289 |
| PID.13 | Phone Number - Home | No | Yes | XTN | |
| PID.14 | Phone Number - Business | No | Yes | XTN | |
| PID.15 | Primary Language | No | No | CE | 0296 |
| PID.16 | Marital Status | No | No | CE | 0002 |
| PID.17 | Religion | No | No | CE | 0006 |
| PID.18 | Patient Account Number | No | No | CX | 0061 |
| PID.19 | SSN Number - Patient | No | No | ST | |
| PID.20 | Driver's License Number - Patient | No | No | DLN | |
| PID.21 | Mother's Identifier | No | Yes | CX | |
| PID.22 | Ethnic Group | No | Yes | CE | 0189 |
| PID.23 | Birth Place | No | No | ST | |
| PID.24 | Multiple Birth Indicator | No | No | ID | 0136 |
| PID.25 | Birth Order | No | No | NM | |
| PID.26 | Citizenship | No | Yes | CE | 0171 |
| PID.27 | Veterans Military Status | No | No | CE | 0172 |
| PID.28 | Nationality | No | No | CE | 0212 |
| PID.29 | Patient Death Date and Time | No | No | TS | |
| PID.30 | Patient Death Indicator | No | No | ID | 0136 |
| PID.31 | Identity Unknown Indicator | No | No | ID | 0136 |
| PID.32 | Identity Reliability Code | No | Yes | IS | 0445 |
| PID.33 | Last Update Date/Time | No | No | TS | |
| PID.34 | Last Update Facility | No | No | HD | |
| PID.35 | Species Code | No | No | CE | 0446 |
| PID.36 | Breed Code | No | No | CE | 0447 |
| PID.37 | Strain | No | No | ST | |
| PID.38 | Production Class Code | No | No | CE | 0429 |
| PID.39 | Tribal Citizenship | No | Yes | CWE | 0171 |
If the MSH tells us where the message came from, the PID tells us who the message is about. It is the main patient identification segment, and it carries the identifiers and demographics that other systems use to find the right person. Get this segment wrong and the rest of the message can be perfectly formatted while still being perfectly useless.
The PID segment is mostly about information that should not change very often: identifiers, names, date of birth, sex, address, phone numbers, and a few important demographic details. It is not really about the visit, the appointment, or the order. Those live elsewhere. The PID is the patient record card that travels with the message.
When the extra patient-level detail is more about privacy settings, publicity or reminder permissions, registry status, primary care provider, living arrangement, military status, or advance directives, have a look at PD1. Those things can feel like patient demographics, but they are often a better fit in the patient additional demographic segment than in PID.
As with most HL7 work, optional does not mean unimportant, and available does not mean sensible. Some fields are required by the base standard, some are required by local implementation guides, and some are best left alone unless both systems have agreed exactly what they mean. The cleanest PID segment is usually not the one with the most data in it. It is the one with the identifiers you trust, the demographics the receiver needs, and no mysterious extras that will be misread later.
So let's go through each of the PID fields and talk about how they tend to behave in the real world.
This field is just the sequence number for the PID segment. In the normal messages most of us work with there is one patient, one PID, and this value is simply 1. If a message structure allows multiple PID segments, then the first is 1, the second is 2, and so on.
It is not a patient number and it is not something you should use for matching. I have seen interfaces where this is left empty and nobody cares, and others where a profile insists that it must be 1. If your receiver has rules for it, follow them. Otherwise keep it boring. In HL7 Soup Web, PID-1 is a good teaching field precisely because you can show it beside PID-3 and make the difference between "row number" and "patient identifier" obvious.
These are the fields that cause the most long-term pain when they are treated casually. PID-2 is the old Patient ID field, PID-3 is the Patient Identifier List, and PID-4 is the old alternate identifier field. In modern HL7 v2 work, PID-3 is the field you should normally be using. PID-2 and PID-4 are mostly there for older systems and backward compatibility. If you are building a new interface and someone says "put the MRN in PID-2", that is worth a friendly pause and a proper conversation.
PID-3 repeats, which is exactly what we need because patients often have more than one identifier. A hospital MRN, national health number, enterprise master patient index ID, billing number, birth registry number, and temporary emergency identifier can all exist at the same time. Each repeat should carry the ID in component 1, the assigning authority in component 4, and preferably the identifier type in component 5. For example, 123456^^^CITYHOSP^MR is much more useful than just 123456. Without the assigning authority, the receiver has to guess which numbering kingdom that value came from, and guessing is not an integration strategy.
Use PID-4 only if you are dealing with a system that explicitly needs it. The better pattern is to put all patient identifiers in PID-3 as repetitions and let the assigning authority and identifier type explain them. When patient identifiers change or merge, look at the MRG segment and the relevant ADT merge/change events rather than trying to smuggle old identifiers into random PID fields. If you are mapping identifiers in Integration Soup, keep the assigning authority and identifier type with the ID; stripping them off is how two perfectly valid numbers become one support ticket.
PID-5 is the patient's name, and it is required because humans still need to look at messages and decide whether they make sense. The usual XPN layout is family name, given name, second and further given names or initials, suffix, prefix, degree, and then name type code. So Smith^Jane^Anne^^Ms^^L says a lot more than a free-text "Jane Anne Smith".
The best habit here is to send the legal or primary name first, and use the Name Type Code when you have more than one name. A patient can have a legal name, preferred name, maiden name, alias, or name represented in another character set. Repeating PID-5 is the right way to do that. Do not rely on the order alone to say what the name means, because order-based meaning is exactly the sort of thing that survives until one system upgrade quietly ruins everyone's week.
Try not to flatten names into one component unless the receiver genuinely cannot handle XPN. Keep family names in the family-name component and given names in the given-name component. Names with spaces, prefixes, hyphens, apostrophes, or cultural naming conventions should be carried as the source system records them, not "cleaned up" into something that is easier for a database column from 1998.
This field carries the family name under which the patient's mother was born. Historically it has been used as an extra matching clue when patients have similar names and dates of birth. That can be useful, especially in older patient administration systems, but it is also personal information and should not be thrown around just because the field exists.
If you do use it, send the maiden family name as a name, not the mother's current full identity. If the receiver wants a link to the mother's patient record, that belongs in PID-21. Mixing the two makes both fields less useful.
This is one of the big patient matching fields. In most adult patient messages it is sent as a date only, in the usual HL7 timestamp style: 19800314. For newborns, the time of birth may matter, especially when there are twins or when mother and baby records are being linked.
The important rule is not to invent precision. If you only know the year, do not pretend you know the day. HL7 timestamps can represent partial precision, but not every receiving system handles that gracefully, so this is one to agree in the interface specification. Also be careful with timezone assumptions when a time is included. A date of birth should be stable, but a badly converted midnight birth time can still become yesterday in another system.
PID-8 is called Administrative Sex, and that word "administrative" is doing a lot of work. In older messages it is often just M, F, O, or U. Some versions and regions allow additional values, and local guides may constrain the list further.
Do not assume this field is a complete model of sex, gender identity, sex assigned at birth, clinical sex for lab calculations, or anything else more subtle than the administrative value the sending system holds. Modern implementations increasingly treat those concepts separately, often through profile-specific fields or OBX observations. PID-8 is still widely used and often required, but it needs a clearly agreed meaning between the systems.
PID-9 is a legacy place for alternate patient names. The modern preference is to repeat PID-5 and use the Name Type Code to explain whether a name is legal, alias, maiden, preferred, display, or something else supported by your profile.
If an older receiver only reads PID-9, then you may have to populate it. Just be aware that you are doing that for compatibility rather than good design. If you control both sides of the interface, put the alternate names in PID-5 and leave PID-9 alone.
Race is one of those fields where the base HL7 table is only the beginning of the discussion. In many countries it is not used at all. In the US, public health and registry guides often define very specific race code sets and may require one or more repetitions. Some guides use CDC Race and Ethnicity codes, some constrain HL7 Table 0005, and some add local "asked but unknown" or "preferred not to say" style values.
The good practice is simple: follow the implementation guide and do not infer the value. Race should be self-reported or taken from an authoritative registration source, not guessed from name, language, appearance, or address. If the receiver needs a coded value, send the coding system along with the code and text. A naked code with no coding system is another small ambiguity that grows up into a support ticket.
PID-11 is a repeating address field using the XAD data type. The common pattern is street address, other designation, city, state or province, postal code, country, and address type. For example, 12 High Street^^Auckland^^1010^NZ^H is a home address. If you have a mailing address and a physical address, send repeats and use the address type rather than cramming them together.
Addresses are surprisingly good at exposing assumptions. Some systems expect a state, some countries do not use one. Some systems want country codes, others leave them blank because everyone was local when the interface was written. My preference is to send country when you have it, keep address lines in their own components, and avoid normalising away details that the source system deliberately captured.
PID-12 is an older county or parish field. In newer thinking, county belongs inside the XAD address structure, because it is part of an address rather than a free-floating patient property. A lot of messages leave PID-12 empty.
Use it when a public health, reporting, or regional guide tells you to use it, and use the code set that guide expects. In the US that may be a FIPS-style county value. Outside that sort of defined use, I would rather put the address in PID-11 properly and avoid duplicating the county in two places.
PID-13 is personal contact information, and PID-14 is business contact information. The name says phone number, but the XTN data type can also carry email. Use the telecommunication use code and equipment type so the receiver knows what it is looking at. For example, a mobile phone might look like ^PRN^CP^^64^21^5551234, while an email address might look like ^NET^Internet^jane.smith@example.org.
Older systems often treat the first repetition as the primary phone number, so put the best number first if you know one. Still, do not depend only on order. A repeat with a clear use code and equipment type is much easier to map than a pile of formatted strings. If you have both a phone number and an email address, send them as separate repetitions.
Phone formatting is a local agreement issue. Some receivers prefer the old formatted telephone number component, some prefer country code, area code, and local number, and newer systems may like the unformatted telephone number component. Pick one deliberately with the receiver. If you send 021 555 1234 to a system expecting country and area components, it may store it, but it probably will not understand it.
This field carries the patient's primary language. HL7 recommends ISO 639 style language values, so you might see something like eng^English^ISO639. Many local profiles are more specific about the coding system and allowed values.
Be clear about what "primary" means. It might mean preferred spoken language, preferred written language, language for care discussions, or language for patient correspondence. If interpreter needs matter, do not assume PID-15 alone is enough. Some guides carry interpreter requirements elsewhere.
Marital status is usually registration or billing data. It can matter for administration, next-of-kin workflows, and some reporting, but it is not normally a core integration field unless the receiver asks for it.
If you send it, send a coded value that the receiver understands. Do not map every local relationship state into "single" just to keep the field populated. A bad demographic value can be worse than an empty one because it looks more certain than it really is.
Religion is sensitive information. It can be genuinely useful for chaplaincy, patient services, dietary workflows, or cultural care, but it should not be sent everywhere by default. A lab result interface probably does not need it.
When the field is used, local codes are common. Make sure the patient has actually provided the information and that the receiver has a legitimate use for it. If you do not know it, leaving the field empty is normally better than inventing "unknown" unless the implementation guide tells you to code that explicitly.
This is the account number used by accounting or billing. It is not the same thing as the patient identifier, and it is not necessarily the same thing as the visit number. A patient can have many accounts over time, and an account may be tied to a particular episode or billing context.
Use PID-18 when the receiver needs to post charges, connect billing records, or match to an account-driven workflow. If you are trying to identify the person, use PID-3. If you are trying to identify the visit, look at PV1-19. Keeping those three concepts separate makes interfaces much easier to reason about.
PID-19 is another backward-compatibility field. In places where a Social Security Number or similar national identifier is used, the modern pattern is usually to send that identifier as one of the PID-3 repetitions, with the proper assigning authority and identifier type. That keeps all patient identifiers in the same structure.
There is also the obvious privacy issue. Do not send SSNs or national identifiers unless the receiving system truly needs them and the interface agreement allows it. If a receiver asks for partial SSNs, masked values, or last-four values, document that clearly because those are no longer the same thing as a real identifier.
This field can carry the patient's driver's licence number, issuing jurisdiction, and expiration date. Some older systems use it for identity verification, especially in registration workflows. It should not be treated as a primary patient identifier unless you are integrating with a system that has explicitly chosen to work that way.
Like SSN, this is sensitive and usually unnecessary for clinical messaging. If you need a government-issued identifier, consider whether it belongs in PID-3 with an assigning authority and type code. If a legacy receiver demands PID-20, populate it carefully and do not let it leak into feeds that do not need it.
PID-21 is mainly useful for newborn and maternity workflows. It links the patient to the mother's identifier, usually a patient ID or account number. It repeats because the mother may have more than one relevant identifier, just like the baby does.
Do not confuse this with mother's maiden name in PID-6. PID-6 is a name used as a demographic clue. PID-21 is an identifier used to link records. For newborn interfaces, that distinction matters.
Ethnicity is similar to race in that the correct values are normally defined by a local or national guide. In US public health messages, PID-22 is often used for Hispanic or Latino origin and related CDC Race and Ethnicity values. In other countries it may be unused, prohibited, or defined very differently.
Do not swap race and ethnicity just because one field is empty. They answer different questions in the guides that care about them. If the patient declined to answer, use the code your guide provides for that situation, or leave it empty if that is what the guide says.
Birth place is usually a free-text description of where the patient was born. It can be useful in birth registration, some identity matching workflows, and a few specialist public health feeds.
Because it is free text, it is not a great field for precise matching. "Auckland", "Auckland Hospital", and "Auckland City Hospital" might all mean the same thing to a person and three different things to a computer. If a precise coded birthplace is required, your implementation guide should say how to carry it.
PID-24 says whether the patient was part of a multiple birth. PID-25 gives the birth order. These are mostly quiet fields until you are dealing with newborns, and then they suddenly become very helpful.
If PID-24 is Y, PID-25 can distinguish the first-born twin from the second-born twin. If PID-24 is N, birth order should normally be empty. Do not use birth order as a general child number in a family. It is about this delivery, not the family tree.
PID-26 carries citizenship, and it repeats because a person can have more than one citizenship. ISO 3166 country codes are commonly recommended when country citizenship is the thing being sent.
This is administrative and sometimes sensitive. It may matter for eligibility, reporting, or regional workflows. If the receiving system does not need it, it is usually better left out.
This field is for military or veteran status. It is very jurisdiction-specific and often irrelevant outside systems that provide veteran services or need that status for reporting and eligibility.
Use the values required by the receiving organisation. Do not try to map a complicated service history into this field unless the interface guide tells you exactly how.
Nationality is a field that is easy to misunderstand. It is not the same as citizenship, race, or ethnicity, and in later HL7 thinking it is largely a backward-compatibility field. Many interfaces leave it empty.
If you need country citizenship, use PID-26. If you need race or ethnicity, use PID-10 or PID-22. If a legacy profile asks for nationality, document the local meaning very clearly.
PID-30 says whether the patient is deceased, and PID-29 gives the date and time of death. If you send Y in PID-30 and you know the date, send PID-29 as well. If you do not know the date, agree with the receiver whether a partial date, empty date, or later correction is expected.
Be careful with these fields. Accidentally marking a patient as deceased is not a cute data-quality issue. It can stop care, letters, billing, portals, and a surprising number of downstream workflows. Only set the death indicator from a source that is allowed to make that statement.
PID-31 tells the receiver whether the patient's identity is unknown. This is useful in emergency departments, trauma workflows, newborn workflows, and anywhere a temporary identity may be created before the real patient record is known.
PID-32 is more detailed. It can flag that pieces of the identity are unreliable, such as a generated date of birth, unknown name, or questionable social security number. These fields are there to prevent bad matching decisions. If the identity is temporary or suspect, say so, then send an update later when the identity is resolved.
PID-33 is the last update date and time for the patient identifying and demographic data. PID-34 is the facility that made that update. These are not the same as MSH-7, which is only the message timestamp.
These fields are most useful around enterprise master patient indexes and demographic synchronisation. A receiver may decide not to overwrite trusted newer demographics with older information from a less trusted source. If your interface relies on that logic, populate these fields consistently or leave the decision to some other agreed rule.
From HL7 v2.4 onward, PID can also describe non-human subjects. PID-35 carries species or taxonomic classification, PID-36 carries breed, PID-37 carries strain, and PID-38 carries production class. Human healthcare messages normally leave these empty.
These fields matter in veterinary, laboratory, agricultural, and research-style workflows. If PID-35 is empty, a human is generally assumed. If you are not doing non-human messaging, that is probably all you need to know.
PID-39 carries tribal citizenship or membership, and it repeats because a person may belong to more than one tribe. In the United States, HL7 points implementers toward the Bureau of Indian Affairs Tribal Identity List, but local guides may define their own table.
This is another field where the interface agreement matters more than the base table. It is sensitive identity information, so only send it where it is collected appropriately and needed by the receiving workflow.