HL7^® Reference Guide

HL7 PD1 Patient Additional Demographic

Examine the usage of every PD1 field from experience.

HL7 field reference PD1 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
PD1.1	Living Dependency	No	Yes	IS	0223
PD1.2	Living Arrangement	No	No	IS	0220
PD1.3	Patient Primary Facility	No	Yes	XON
PD1.4	Patient Primary Care Provider Name & ID No.	No	Yes	XCN
PD1.5	Student Indicator	No	No	IS	0231
PD1.6	Handicap	No	No	IS	0295
PD1.7	Living Will Code	No	No	IS	0315
PD1.8	Organ Donor Code	No	No	IS	0316
PD1.9	Separate Bill	No	No	ID	0136
PD1.10	Duplicate Patient	No	Yes	CX
PD1.11	Publicity Code	No	No	CE	0215
PD1.12	Protection Indicator	No	No	ID	0136
PD1.13	Protection Indicator Effective Date	No	No	DT
PD1.14	Place of Worship	No	Yes	XON
PD1.15	Advance Directive Code	No	Yes	CE	0435
PD1.16	Immunization Registry Status	No	No	IS	0441
PD1.17	Immunization Registry Status Effective Date	No	No	DT
PD1.18	Publicity Code Effective Date	No	No	DT
PD1.19	Military Branch	No	No	IS	0140
PD1.20	Military Rank/Grade	No	No	IS	0141
PD1.21	Military Status	No	No	IS	0142

If the PID segment is the main patient record card, PD1 is the little extra sheet that sometimes travels behind it. It carries patient demographic information that may change from time to time, or information that is a bit too policy-like, registry-like, or administrative to sit comfortably in PID.

In everyday hospital ADT feeds, PD1 is often absent. That does not make it useless. It just means the data it carries is specialised. You see PD1 more often in patient demographic queries, immunisation registry interfaces, public health feeds, and registration feeds where the receiving system cares about privacy restrictions, recall/reminder permission, registry status, primary care provider, living arrangements, advance directives, or military status.

The easiest mistake is to treat PD1 as "spare PID fields". It is not that. If the information identifies the patient, use PID. If it describes this visit, look at PV1 or PV2. If it describes a related person, look at NK1. PD1 is mostly for additional patient-level context, and quite a few of its fields are really consent, policy, or registry fields in disguise.

That example is deliberately fuller than most real messages. A normal feed may only use PD1-11, PD1-12, PD1-16, and their dates. But it shows the shape of the segment: extra patient context, privacy/publicity settings, a primary care provider, and a few administrative status fields. Open it in HL7 Soup Web and the privacy/publicity fields stand out more clearly than they do in one long ADT line.

Where PD1 actually earns its keep

The immunisation world is probably the clearest modern use case. Implementation guides commonly use PD1 to say whether the patient wants data protected, whether recall or reminder notices are allowed, and what the patient's current registry status is. Those are not just labels. They can affect whether an immunisation registry contacts a patient, hides a record, marks someone inactive, or treats the person as moved away, lost to follow-up, or permanently inactive.

Patient demographics query profiles also allow PD1 to come back with PID when the source system has extra patient-level data to return. That is a good way to think about it: PD1 is optional, but if you use it, be precise. A half-populated PD1 with unclear privacy settings can be worse than no PD1 at all, because it tempts the receiver to make assumptions about consent and contact behaviour.

This is about people or circumstances the patient depends on, or that depend on the patient. The standard table includes ideas like small children dependent, spouse dependent, medical supervision required, other, and unknown. It can repeat, which makes sense because a person may have more than one kind of dependency.

I have not seen this used heavily in ordinary ADT feeds. When it is used, it tends to be part of social care, discharge planning, community care, or insurance-style information. Be careful with it. A living dependency is not the same thing as next of kin. If you need to name the spouse, child, guardian, or contact, use NK1. PD1-1 is the coded dependency summary, not the person's contact record.

This field says something about how the patient lives: alone, with family, in an institution, with a relative, with a spouse, or unknown. It can be useful for care planning and risk assessment, especially when discharge planning or community follow-up cares whether the patient has support at home.

It should not be used as a sloppy address field. The address belongs in PID-11. Living arrangement says the pattern of living, not where the house is. If your receiver is trying to infer social support from a street address, the interface is already drifting into guesswork.

This is the patient's primary facility or practice. In FHIR mapping work, this roughly lines up with the organisation side of the patient's general practitioner or care provider relationship. In practical terms, it may be the GP clinic, primary care practice, usual health centre, school clinic, or registry facility associated with the patient.

Use this when the facility itself matters. If you are sending the individual doctor, nurse practitioner, or provider, PD1-4 is the better place. If both are known, send both, but do not pretend the clinic and the clinician are the same thing just because both happen to be "primary care".

This is the person side of the primary care relationship. It uses XCN, so it can carry an identifier, family name, given name, assigning authority, and identifier type. A useful value looks like a provider identity, not just a display name.

The main trap is provider matching. If you send only "Smith", the receiving system cannot reliably know which Smith you meant. Use a provider identifier where you can, and agree the assigning authority. Also think about whether you are sending the current primary care provider, the historical provider at the time of registration, or the provider associated with this specific message. Those are not always the same.

This says whether the patient is a full-time student, part-time student, or not a student. You may see similar student fields in insurance, guarantor, and next-of-kin segments too, because student status can affect coverage, eligibility, or administrative handling.

In patient demographics, only send it if someone actually uses it. Student status changes, and stale student data is worse than empty student data. If the value drives school-based immunisation, public health reporting, or insurance coverage, make sure the source and update process are understood.

This is an older field name, and modern implementations often avoid it or constrain it carefully. The local reference data does not carry common values for table 0295, which is a hint that you should not invent your own casual codes without a profile telling you what to do.

If the goal is accessibility, disability support, or accommodation needs, many modern systems will prefer more explicit clinical, social, or care-plan structures rather than this one short field. If you do use it, keep the vocabulary agreed and be aware that this is sensitive information, not a harmless demographic flag.

This says whether the patient has a living will, whether documentation is on file, or whether information was provided. It is small, but it points to a very serious real-world question: does the organisation know the patient's wishes if they cannot speak for themselves?

Do not treat it as the full advance directive. This field is a signal, not the document. If the patient has an actual advance directive document, care teams need to know where it is, whether it is current, and how it should be honoured. PD1-7 helps flag that story, but it does not replace the document-management process.

This is another status-style field. It can say the patient is a documented donor, is not a donor, leaves the decision to relatives or a specific person, or that the status is unknown. Like living will, it is simple in HL7 and complicated in real life.

Use it only where the receiving system has a real use for it and knows the legal/local meaning of the value. Organ donation preferences and donor registrations vary by jurisdiction. A code that is safe in one region may not be enough in another.

This is a yes/no field that says whether a separate bill is expected. In practice, it is a patient-level administrative hint, not a replacement for IN1, GT1, account, or charge data.

I would be cautious with it. If the billing workflow truly depends on separate billing, make sure the downstream accounting system knows exactly what this flag means. A single yes/no patient demographic field is too thin to carry a whole billing arrangement by itself.

This field can carry identifiers for duplicate patient records. It is a useful warning that the system has seen possible duplicate identities, but it is not the same as a formal merge transaction.

If you are actually merging patient records, use the proper ADT merge/change event and the merge-related structures expected by the receiver. PD1-10 is more of a "there is a duplicate patient identifier associated with this patient" field. Do not rely on it to perform record merges silently.

This is one of the important modern PD1 fields. The base table includes values like family only, no publicity, other, and unknown. In immunisation guides, this often becomes the field that controls whether the patient may receive reminder or recall notices, or how the registry is allowed to contact or publicise information about the patient.

Do not guess what "publicity" means from the word alone. In one feed it may mean no reminder letters. In another it may mean do not release patient information except to family. In a registry feed it may be tied to consent policy. This is a field where the implementation guide is king. If it affects contact, privacy, or disclosure, document the business rule in plain language.

This yes/no field says whether the patient's information should be protected. In immunisation messaging it is commonly paired with PD1-11 and PD1-16. A protected record may need to be hidden, masked, excluded from ordinary reminder activity, or handled under special access rules depending on the registry or receiving system.

This is not decoration. A protection indicator can represent a privacy restriction, safety concern, confidentiality flag, or local legal requirement. If the receiving system cannot honour it, that should be raised as an interface issue. Do not send a protection flag and then rely on a human to notice it later.

This gives the date the protection setting became effective. It is easy to skip, but it can matter when a patient opts in or out, a guardian changes their choice, or a registry needs to know when the privacy rule started.

Use the date of the decision or effective policy change, not simply the date the message was sent. If you only send today's date because the interface ran today, you may overwrite useful history with processing noise.

This identifies an organisation associated with the patient's place of worship or congregation. It uses XON, so it is an organisation-style value rather than a free-text pastoral note. In FHIR mapping work, it lines up with a patient congregation-style extension.

Many interfaces will leave this empty. Where it is used, it may support pastoral care, chaplaincy, community support, or cultural/spiritual needs. Be thoughtful with consent and privacy. Religious affiliation and congregation information can be sensitive, and not every downstream system needs it.

This is the broader advance directive field. The v2.5.1 table is small, with values such as DNR and no directive, but real-world advance directives can include living wills, health care proxies, medical orders, and local legal documents. The field is useful as a flag, not as the whole story.

If a patient has a DNR or other directive, the receiving system needs to know what workflow follows. Is there a signed document? Is it verified? Is it current? Who is allowed to view it? PD1-15 can say "there is an advance directive concept here", but it does not carry all the document and clinical governance around it.

This is another key modern PD1 field. The table includes active, inactive, moved or gone elsewhere, lost to follow-up, permanently inactive, other, and unknown. Immunisation registries use this to decide how to treat the patient record for participation, follow-up, and forecasting.

The practical trap is treating inactive as one thing. Lost to follow-up, moved elsewhere, and permanently inactive are different operational states. If the registry profile gives those values, use the right one. A permanently inactive record may not be reactivated automatically, while a moved record may behave differently again.

This gives the date the registry status took effect. If a patient moved away in March but the update message is sent in June, March is usually the clinically and operationally meaningful date.

It is also useful for reconciliation. Registries receive late updates, corrections, and re-sent messages. Effective dates help the receiver decide whether a status update is new information or an old fact arriving again.

This is the companion date for PD1-11. If the patient or guardian changes recall/reminder permission or publicity preference, this date says when that preference became effective.

When privacy and contact preferences are involved, dates matter. Do not just send the message date unless that really is the effective date. A patient may have opted out last week, and a delayed interface file should not make that look like it happened today.

This field records the military branch, using codes such as Army, Navy, Air Force, Coast Guard, Marines, and some non-military uniformed services depending on the table. You may see it in military, veteran, occupational health, payer, or benefits-related interfaces.

Most ordinary hospital feeds will leave it empty. If you use it, make sure it is relevant to the receiving workflow and not just a leftover from a registration screen. Military affiliation can affect eligibility and care coordination in some settings, but it should still be treated as meaningful demographic data.

This is the rank or grade, such as enlisted, officer, or warrant officer ranges. Like PD1-19, it is specialised. It is more likely to be useful in military or veteran systems than in a general patient feed.

Do not send a local free-text rank in here unless the receiver has agreed how to parse it. If all the receiver needs is veteran status, rank may be unnecessary. If rank matters for a benefits workflow, get the code system right.

This says whether the patient is active duty, retired, or deceased according to the military status table. Again, this is not a general patient death indicator. Patient death information belongs in PID-29 and PID-30.

The field is best understood as military-service status, not patient vital status. If someone maps PD1-21 directly to "is this patient deceased", they will eventually make a bad decision from a field that was never meant to answer that question.

What about newer PD1 fields?

Later HL7 references add fields after PD1-21. PD1-22 is Advance Directive Last Verified Date, which is a genuinely useful addition because advance directives are not "set once and forget forever" information. A DNR or living will flag is much safer when you know when it was last checked.

HL7 v2.9 reference data also includes PD1-23 Retirement Date. That is a specialised demographic/employment-style detail. This page follows the v2.5.1 field list used in our local tutorial data, so the formal table below stops at PD1-21, but it is worth knowing those later fields exist if you are reading a newer implementation guide.