HL7 NK1 Segment: Next of Kin

The NK1 segment carries the patient's next of kin and other associated parties: family members, emergency contacts, guardians, employers, and other people or organizations related to the patient. Where PID describes the patient, NK1 describes who to call and who is connected to them. A message may contain several NK1 segments, one per contact, each numbered by its Set ID.

Purpose

NK1 records each associated party's name, relationship to the patient, contact role, addresses, and phone numbers, plus optional demographic and employment detail. It supports both individuals (a spouse, a parent, an emergency contact) and organizations (an employer or guardian agency). Repetition lets a single patient carry multiple contacts, each with its own relationship and priority.

Used in

NK1 appears in patient-context messages, most prominently ADT (registration and admit events such as A01/A04/A28 where contacts are captured), and is also carried wherever downstream systems need next-of-kin or emergency-contact detail. It always follows PID (and any PD1) for the patient it describes. See ADT.

Field-by-field reference

Source: the Vorro HL7 segment database (extracted from the official v2-to-FHIR IG). R = required (cardinality min ≥ 1). Repeat = field may repeat. Length is not carried by the FHIR source and is shown as -.

Most-used fields

• NK1-1 Set ID numbers each contact and is the only required field; it separates one associated party from the next.
• NK1-2 Name and NK1-3 Relationship are the core of the segment - who the contact is and how they relate to the patient (spouse, parent, guardian).
• NK1-3 Relationship and NK1-7 Contact Role together drive emergency-contact and next-of-kin selection downstream.
• NK1-4 Address, NK1-5 Phone Number, and NK1-6 Business Phone Number carry how to reach the contact and are what most registration systems actually populate.
• NK1-13 Organization Name is used when the associated party is an organization (employer, guardian agency) rather than a person.

Version differences (2.3 to 2.8.2)

• 2.3/2.4: NK1 carries the core name, relationship, address, and phone fields; many of the demographic fields (NK1-14 onward) are present early.
• 2.5: coded fields move from CE toward CWE; contact-person fields (NK1-30 through NK1-33) are used for organization contacts.
• 2.7+: NK1-40 Next of Kin Telecommunication Information and NK1-41 Contact Person's Telecommunication Information added as richer XTN telecom fields.
• Receivers built for 2.3 ignore the trailing fields they do not recognize.

Common mistakes

• Reading only the first NK1 when a patient has several contacts - each NK1 is a separate associated party keyed by Set ID.
• Confusing NK1-3 Relationship (kinship) with NK1-7 Contact Role (the role they serve), and collapsing both into one value.
• Assuming NK1 always describes a person - when NK1-13 is set, the associated party is an organization and NK1-30/31/32 carry its contact person.
• Treating NK1-4 as free text instead of a structured XAD and losing the address components.
• Mismatching repetition: NK1-5/NK1-6 can each repeat, so don't keep only the first phone number.

Examples

Minimal valid NK1 (Set ID, name, relationship):

NK1|1|DOE^JANE^Q|SPO

Fully-populated NK1 (spouse as emergency contact):

NK1|1|DOE^JANE^Q^^^^L|SPO|123 MAIN ST^^SPRINGFIELD^IL^62704^USA|^PRN^PH^^1^555^5550101|^WPN^PH^^1^555^5550199|EC|20200101||MANAGER|||||F|19820315

Annotated breakdown of the fully-populated example (selected fields):

NK1                              ← segment ID
1                                ← NK1-1  Set ID
DOE^JANE^Q^^^^L                  ← NK1-2  Name (family^given^middle...^type)
SPO                              ← NK1-3  Relationship (Spouse)
123 MAIN ST^^SPRINGFIELD^IL^...  ← NK1-4  Address
^PRN^PH^^1^555^5550101           ← NK1-5  Phone Number (home)
^WPN^PH^^1^555^5550199           ← NK1-6  Business Phone Number (work)
EC                               ← NK1-7  Contact Role (Emergency Contact)
20200101                         ← NK1-8  Start Date
F                                ← NK1-15 Administrative Sex
19820315                         ← NK1-16 Date/Time of Birth

In-context inside an ADT^A01 (admit, one NK1 after PID):

MSH|^~&|REG|MERCYGEN|EHR|MERCYGEN|20260609120000||ADT^A01^ADT_A01|MSG001|P|2.5.1
EVN|A01|20260609120000
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
NK1|1|DOE^JANE^Q|SPO|123 MAIN ST^^SPRINGFIELD^IL^62704^USA|^PRN^PH^^1^555^5550101||EC
PV1|1|I|3WEST^301^A||||1234^SMITH^JANE^A^^^MD|||MED

In-context inside an ADT^A04 (register, two NK1s after PID):

MSH|^~&|REG|MERCYGEN|EHR|MERCYGEN|20260609130000||ADT^A04^ADT_A01|MSG014|P|2.5.1
EVN|A04|20260609130000
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
NK1|1|DOE^JANE^Q|SPO|123 MAIN ST^^SPRINGFIELD^IL^62704^USA|^PRN^PH^^1^555^5550101||EC
NK1|2|DOE^MARY^A|MTH||^PRN^PH^^1^555^5550150||N
PV1|1|O|CLINIC^^^MERCYGEN

FHIR mapping

Primary target resource: RelatedPerson. The same NK1 also maps to the embedded Patient.contact backbone element so the contact is represented inside the Patient as well. Official ConceptMaps: RelatedPerson, Patient.

Key RelatedPerson mappings:

Patient.contact mappings (same person inside the Patient resource): NK1-2 → contact.name; NK1-3 → contact.relationship[1]; NK1-4 → contact.address; NK1-5 → contact.telecom[1]; NK1-6 → contact.telecom[2] (use work); NK1-7 → contact.relationship[2]; NK1-8/9 → contact.period.start/end; NK1-13 → contact.organization (Organization); NK1-15 → contact.gender; NK1-30/31/32 → the Organization's contact.name/telecom/address; NK1-40/41 → contact.telecom[3]/[4].

Fields without a published target: NK1-1 (Set ID, structural only), NK1-10/11 (job title and job code), NK1-14 (marital status), NK1-17 through NK1-19, NK1-21 through NK1-29 (most living-arrangement, publicity, religion, and demographic detail), NK1-34/35/36, NK1-38 (birth place), and NK1-39 (VIP indicator) are not mapped to RelatedPerson or Patient.contact in the published ConceptMaps.

Engine considerations

• Required in practice: only NK1-1 Set ID is standard-required, but real interfaces also expect NK1-2 (name) and NK1-3 (relationship) for any usable contact.
• Iterate over every NK1 segment in the message, keying by NK1-1, rather than reading only the first.
• Parse NK1-4/NK1-32 as structured XAD and NK1-2/NK1-30 as XPN so address and name components survive.
• Preserve repetitions of NK1-5/NK1-6 and the telecom fields as arrays - a contact can have several numbers.
• Branch on NK1-13: when present, treat the party as an organization and pull its contact person from NK1-30/31/32.

How Vorro parses and produces NK1

Vorro emits one RelatedPerson per NK1, linked back to the patient, mapping NK1-2 to name, NK1-3/NK1-7 to the two relationship slots, and address/phone fields to address and the typed telecom array per the official ConceptMap. The same contact is mirrored into Patient.contact so consumers that read the Patient resource still see next-of-kin detail. Organization parties (NK1-13 set) are produced as a referenced Organization with its contact person taken from NK1-30/31/32, and repeating name, address, and phone fields are preserved as arrays.

Related pages

• PID - the patient the next of kin belongs to.
• ROL - role segment for related providers and parties.
• ADT messages - where NK1 captures contacts during registration and admit.

Sources

• HL7 v2-to-FHIR IG - segment maps index
• HL7 v2-to-FHIR IG - NK1 to RelatedPerson ConceptMap
• HL7 v2-to-FHIR IG - NK1 to Patient ConceptMap
• HL7 Version 2.5.1 product brief