HL7 NK1 Next of Kin / Associated Parties
HL7 field reference NK1 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 |
|---|---|---|---|---|---|
| NK1.1 | Set ID - NK1 | Yes | No | SI | |
| NK1.2 | Name | No | Yes | XPN | |
| NK1.3 | Relationship | No | No | CE | 0063 |
| NK1.4 | Address | No | Yes | XAD | |
| NK1.5 | Phone Number | No | Yes | XTN | |
| NK1.6 | Business Phone Number | No | Yes | XTN | |
| NK1.7 | Contact Role | No | No | CE | 0131 |
| NK1.8 | Start Date | No | No | DT | |
| NK1.9 | End Date | No | No | DT | |
| NK1.10 | Next of Kin / Associated Parties Job Title | No | No | ST | |
| NK1.11 | Next of Kin / Associated Parties Job Code/Class | No | No | JCC | 0327 |
| NK1.12 | Next of Kin / Associated Parties Employee Number | No | No | CX | |
| NK1.13 | Organization Name - NK1 | No | Yes | XON | |
| NK1.14 | Marital Status | No | No | CE | 0002 |
| NK1.15 | Administrative Sex | No | No | IS | 0001 |
| NK1.16 | Date/Time of Birth | No | No | TS | |
| NK1.17 | Living Dependency | No | Yes | IS | 0223 |
| NK1.18 | Ambulatory Status | No | Yes | IS | 0009 |
| NK1.19 | Citizenship | No | Yes | CE | 0171 |
| NK1.20 | Primary Language | No | No | CE | 0296 |
| NK1.21 | Living Arrangement | No | No | IS | 0220 |
| NK1.22 | Publicity Code | No | No | CE | 0215 |
| NK1.23 | Protection Indicator | No | No | ID | 0136 |
| NK1.24 | Student Indicator | No | No | IS | 0231 |
| NK1.25 | Religion | No | No | CE | 0006 |
| NK1.26 | Mother's Maiden Name | No | Yes | XPN | |
| NK1.27 | Nationality | No | No | CE | 0212 |
| NK1.28 | Ethnic Group | No | Yes | CE | 0189 |
| NK1.29 | Contact Reason | No | Yes | CE | 0222 |
| NK1.30 | Contact Person's Name | No | Yes | XPN | |
| NK1.31 | Contact Person's Telephone Number | No | Yes | XTN | |
| NK1.32 | Contact Person's Address | No | Yes | XAD | |
| NK1.33 | Next of Kin/Associated Party's Identifiers | No | Yes | CX | |
| NK1.34 | Job Status | No | No | IS | 0311 |
| NK1.35 | Race | No | Yes | CE | 0005 |
| NK1.36 | Handicap | No | No | IS | 0295 |
| NK1.37 | Contact Person Social Security Number | No | No | ST | |
| NK1.38 | Next of Kin Birth Place | No | No | ST | |
| NK1.39 | VIP Indicator | No | No | IS | 0099 |
NK1 is the segment for the people and organisations around the patient. It can carry the patient's next of kin, emergency contact, spouse, parent, guardian, employer, insurance company, agency, school, or any other associated party that the receiving system needs to know about. You see it most often in ADT-style messages, but it also appears in referrals, orders, results, account messages, and immunisation feeds whenever the patient record needs useful contact context.
It feels a little like PID, because it has names, addresses, phone numbers, demographics, identifiers, and privacy flags. The difference is that this is not the patient. That sounds obvious until someone maps NK1-2 into a patient name column, or treats the contact's date of birth as the patient's date of birth. Whenever I am mapping NK1 I keep asking the same dull but useful question: whose data is this?
The other important split is relationship versus role. NK1-3 says who this person or organisation is to the patient: spouse, father, mother, friend, guardian, employer, and so on. NK1-7 says why this person or organisation is being sent in the workflow: emergency contact, next of kin, employer, insurance company, agency, other. Those are not the same thing. A spouse can be both an emergency contact and next of kin, and the HL7 guidance is to send separate NK1 segments if the same party is playing multiple contact roles. When a real feed is confusing, HL7 Soup Web makes it quick to compare NK1-3 and NK1-7 without counting pipes by hand.
Also, NK1 is not the guarantor segment. The same person might appear in NK1 and IN1 or GT1, but the meaning is different. NK1 is about associated people and contact use. GT1 is about financial responsibility. Blurring those together is one of those little shortcuts that seems harmless right up until billing or emergency contact workflows start disagreeing.
So let's go through the NK1 fields and talk about how they tend to behave in real interfaces.
This is the sequence number for the NK1 segment. If there is one contact, it is usually 1. If the patient has three associated parties, they normally arrive as 1, 2, and 3. It is useful for preserving the order the registration system intended, and many screens will treat the first NK1 as the primary or most important contact if there is no more explicit priority field.
Do not treat it as an identifier for the contact person. It is only the position of this NK1 in this message. If a system sends a full replacement set of contacts, renumbering may be fine. If a system is sending targeted updates, changing the set IDs without a clear replacement rule can make the receiver think contacts have disappeared or changed identity. If contact identity matters, use NK1-33, not NK1-1.
The name belongs to the next of kin or associated party, not to the patient. It uses the XPN name structure, so you can carry family name, given name, other given names, prefix, suffix, degree, and name type code. A tidy value like Smith^Robert^James^^Mr^^L is much easier to map than a single free-text "Robert Smith".
If there are multiple names, repeat the field and use the name type code rather than relying on position alone. Legal name first is the safest pattern, with aliases, maiden names, display names, or local-script names as additional repeats if your interface profile supports them. Some implementation notes call out that the legal name should be first, which is a good habit even when the receiver is not strict about it.
When the associated party is an organisation rather than a person, do not force a company name into NK1-2 unless your receiver has asked for that. The organisation has its own home in NK1-13, and the named human contact inside that organisation can go in NK1-30.
This is the actual relationship to the patient. Table 0063 gives you codes such as SPO for spouse, FTH for father, MTH for mother, PAR for parent, GRD for guardian, FND for friend, EMC for emergency contact, OTH for other, and UNK for unknown. If the patient says "call my father", then FTH^Father^HL70063 is the relationship.
The easy mistake is to put the contact role here. "Emergency contact" can appear in the relationship table, but in many interfaces it is better represented in NK1-7 because emergency contact is a function, not a family relationship. If Robert is Jane's spouse and emergency contact, I would normally send SPO in NK1-3 and C in NK1-7. That tells a cleaner story than making relationship do both jobs.
This is where the associated party can be reached. It repeats because a person can have a home address, mailing address, work address, temporary address, or other contact location. Use the XAD address type where you can, and put the best or home address first if the receiver still behaves in an order-based way.
Do not copy the patient's address into this field just because the contact has the same surname. Sometimes a spouse lives with the patient, sometimes they do not. Sometimes a parent is overseas, a guardian is an organisation, or the most useful address is a workplace. Address data also has privacy weight. If the receiver only needs a phone number for an emergency contact, sending the contact's full home address may be more data than the workflow deserves.
NK1-5 is the personal contact number, and NK1-6 is the business phone number. Both use XTN, which means they can carry more than a simple phone string. Mobile phone, home phone, fax, pager, and e-mail can all be represented by using the telecommunication use code and equipment type properly. Separate repeats are your friend here: one repeat for the mobile, one for the e-mail, one for the home phone.
Older receivers often take the first repeat as the best number, so put the most useful number first when you know it. Still, do not make order do all the explaining. ^PRN^CP^^64^21^5554321 says "personal mobile" much more clearly than a formatted string with spaces and no context. The work number belongs in NK1-6, especially for employers or contacts who should only be called at work. In newer HL7 versions the telecom fields are tidied up further, but in v2.5.1 NK1-5 and NK1-6 are still the fields you will meet most often.
This is the field that gives NK1 its practical meaning. In HL7 v2.5.1 table 0131, the standard values are C Emergency Contact, E Employer, F Federal Agency, I Insurance Company, N Next-of-Kin, O Other, S State Agency, and U Unknown. Some sites extend this idea with more readable local codes for guardian, power of attorney, billing contact, school contact, or carer, but that needs to be documented clearly.
The rule I like is: relationship says who they are, role says why they are in this message. If the same person is both emergency contact and next of kin, the HL7 guidance is to send one NK1 for each role. That feels redundant at first, but it avoids the receiver having to guess whether a single NK1 with one role should also be displayed in a different contact list.
These dates describe the period during which this contact role applies. They are useful when a guardianship has a start date, an employer relationship ended, an agency contact is temporary, or a contact should stop being used after a known date.
Most everyday emergency contact feeds leave them empty, and that is fine. Just do not confuse them with date of birth. If the role ends, NK1-9 can be a clean way to say that the contact should no longer be active without deleting history from systems that keep contact records over time.
These fields sit in a slightly awkward corner of NK1 because they can describe the associated party's employment, or, when the contact role is employer, they can describe the patient's job information at that employer. That distinction should be written down in the interface specification, because the field names alone are not enough to save you.
If the associated party is a person, NK1-10 might be their job title, NK1-11 a local job code or class, and NK1-12 their employee number. If the NK1 is there because the employer is the associated party, then the employee number may be the patient's employee number at that organisation. NK1-12 is a CX identifier, so use assigning authority and identifier type where you can. EMP7788^^^ACMESCHOOL^EI is far more useful than EMP7788 floating on its own.
This is the organisation associated with the NK1. It might be the employer, insurance company, agency, school, care home, government body, or some other organisation linked to the patient. It can also be the organisation where the named contact person works.
If the organisation is the actual associated party, NK1-13 should do the heavy lifting and NK1-30 to NK1-32 can describe the human contact inside that organisation. For example, an employer NK1 might have Acme School in NK1-13 and Kelly^Mara in NK1-30. If multiple organisation names are sent, put the legal or primary name first and use the XON components rather than relying on a casual display string.
This little demographic block belongs to the associated party. That is the thing to keep saying out loud. NK1-14 is the contact's marital status, NK1-15 is the contact's administrative sex, and NK1-16 is the contact's date or time of birth. None of these should be mapped into the patient demographics unless you enjoy unpicking very confusing patient records later.
For a normal emergency contact, these fields are often blank. They can be useful in legal, guardian, related-person matching, payer, or social-care workflows where the receiver needs to identify the associated person more precisely. Even then, be careful with sensitivity and freshness. A contact's date of birth might help matching, but it is still personal information about someone who is not the patient.
These fields are not the everyday "who should we call?" fields. Living dependency can say that small children depend on this person, that a spouse is dependent, or that medical supervision is required. Ambulatory status describes the associated party's mobility or functional status. You might see this kind of information in discharge planning, home support, long-term care, or social-context workflows.
I would not populate these from casual notes or assumptions. If the receiving system uses them, it should be because care planning genuinely depends on them and the codes are maintained properly. Stale dependency and disability-related data can be more harmful than an empty field because it sounds official.
Citizenship and primary language again describe the associated party, not the patient. HL7 points implementers toward country-style codes for citizenship and language codes for primary language, and local profiles usually decide the exact code system.
Language can be genuinely useful if staff may need to speak with the contact in an emergency, or if letters and calls go through a family representative. Just be clear what "primary" means in your workflow. Preferred spoken language, written correspondence language, and interpreter need are not always the same thing.
Living arrangement describes how the associated party lives at their residential address: alone, with family, in an institution, with a relative, with a spouse only, or unknown. It is a social-context field, not a locator field. The address is still NK1-4.
Most simple ADT feeds do not need it. It becomes more interesting when the receiver is doing care planning or social support and needs to understand whether the associated party can realistically help the patient after discharge.
These two deserve more respect than they usually get. Publicity code can say whether information may be public, family only, no publicity, or something local. Protection indicator is a yes/no flag telling the receiver that access to this person's information should be restricted from users who do not have authority.
If your feed receives protection data, preserve it. Family violence, confidential admissions, celebrity patients, court orders, adoption cases, and ordinary privacy preferences can all make contact information sensitive. It is tempting to treat these flags as decorative because many messages leave them blank, but when they are populated they may be the most important fields in the segment.
This says whether the associated party is a full-time student, part-time student, or not a student. It does not describe the degree, school, year level, or course of study.
You will usually only see it when an administrative, insurance, benefit, or dependency workflow cares about student status. Outside that sort of workflow, leaving it empty is normal.
Religion is sensitive, and in NK1 it is the associated party's religion. That makes it even easier to send too much information by accident. It might matter for chaplaincy, cultural care, funeral workflows, or local administrative requirements, but most interfaces do not need it.
If it is used, use the code set the site has agreed on and do not infer it. A blank field is usually better than a guessed value. This is the kind of data where "we had a field for it" is not a good enough reason to send it.
This is the associated party's mother's maiden name, not the patient's mother's maiden name. Historically it has been used as a matching clue or identity question, but it is also sensitive and not something I like to see in broad feeds.
If a receiver really needs this for identity matching, make sure everyone understands whose mother is being described. For the patient's mother's maiden name, the PID segment has its own field. Mixing the two creates exactly the kind of demographic confusion that takes a long time to find.
Nationality and ethnic group are demographic attributes of the associated party. They are jurisdiction-specific, sensitive, and often unused. The base tables are only a starting point; local reporting rules decide what is meaningful.
Do not infer these values from name, address, language, or the patient's demographics. If a guide genuinely requires them, follow that guide. Otherwise they are usually better left out of a general contact segment.
This gives the reason this contact should be used. It is not the relationship and it is not quite the same as contact role. Think of it as a workflow hint: contact the employer if the patient cannot work, call the agency for placement questions, use this person for discharge transport, or use this contact only for billing questions.
The table is user-defined in many implementations, so local codes are normal. That also means the code set has to be documented. A reason code nobody understands is worse than a plain note, because it looks structured while carrying no shared meaning.
These fields make the most sense when NK1-13 is an organisation. The NK1 itself might represent a school, employer, insurer, agency, or care home, while NK1-30 gives the actual person to contact there. NK1-31 gives that person's phone or telecom details, and NK1-32 gives that person's address.
Try not to duplicate NK1-2, NK1-4, and NK1-5 into these fields just because they exist. If the associated party is a person, the main NK1 person fields are usually enough. If the associated party is an organisation, these later contact-person fields are how you avoid stuffing "Acme School - ask for Mara" into one messy organisation name.
This is the structured identifier list for the associated party. It can carry a local contact ID, employee number, national identifier, driver licence number, agency ID, or any other agreed identifier. Because it uses CX, you should include assigning authority and identifier type when you have them.
Use it when stable matching matters. Names, phone numbers, and addresses change, and two family members can share very similar demographics. At the same time, identifiers are sensitive, especially government identifiers. Do not send them just to make the segment look complete. Send them because the receiver has a real matching or workflow need.
Job status says whether the associated party is permanent, temporary, other, or unknown in the local table. In employer-style NK1 records, it may describe employment status relevant to the patient's employer relationship, depending on the interface agreement.
This is a rare field in general ADT feeds. If the receiver does not have a specific use for it, leave it alone rather than inventing an employment state that nobody will maintain.
Race here is the associated party's race, not the patient's race. That distinction matters, and so does the sensitivity of the field. Some US-oriented profiles may define a proper code set, while many other regions will not use this field at all.
Follow the local implementation guide and do not infer the value. For most next-of-kin and emergency contact workflows, this is not necessary data.
This field describes a disability or handicap code for the associated party. The table is user-defined, which means there is no universal meaning you can safely assume.
Use it only when the receiving workflow genuinely needs it, such as care planning, support eligibility, or a tightly defined local process. It is sensitive information, and it should not leak through broad demographic feeds by accident.
This is a very specific US-style field for the contact person's Social Security Number or similar retirement number. HL7's own guidance around NK1 identifiers points people toward NK1-33 for the associated party's identifiers, with assigning authority and identifier type, which is usually the cleaner pattern.
I would avoid this field unless a local US implementation guide explicitly requires it. SSNs are high-risk identifiers, and a next-of-kin feed is rarely the place you want to spread them around.
Birth place is a free-text birthplace for the associated party. It is not an address and it should not be used as a substitute for NK1-4. You might see it in older identity-matching workflows or very specific administrative feeds.
Because it is free text, it is weak for precise matching. If a receiver needs coded birthplace detail, the implementation guide should say exactly how to represent it.
VIP indicator is a local flag for special handling of the associated party. The code table is user-defined, so the meaning is entirely site-specific.
Be careful with it. VIP flags can affect privacy, routing, service handling, or visibility, and not every downstream system should know about them. If you send it, make sure the receiving system has a legitimate reason to receive it and knows what the local value means.