HL7 ADT_A28 (Add Person Information) | Integration Soup HL7 Reference Guide

HL7 ADT_A28 Add Person Information

A person or patient identity record is being created, not an encounter.

HL7 message structure ADT_A05 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SFT	Software Segment	No	Yes
EVN	Event Type	Yes	No
PID	Patient Identification	Yes	No
PD1	Patient Additional Demographic	No	No
ROL	Role	No	Yes
NK1	Next of Kin / Associated Parties	No	Yes
PV1	Patient Visit	Yes	No
PV2	Patient Visit - Additional Information	No	No
ROL	Role	No	Yes
DB1	Disability	No	Yes
OBX	Observation/Result	No	Yes
AL1	Patient Allergy Information	No	Yes
DG1	Diagnosis	No	Yes
DRG	Diagnosis Related Group	No	No
ADT_A05.PROCEDURE	Procedure group	No	Yes
PR1	Procedures	Yes	No
ROL	Role	No	Yes
GT1	Guarantor	No	Yes
ADT_A05.INSURANCE	Insurance group	No	Yes
IN1	Insurance	Yes	No
IN2	Insurance Additional Information	No	No
IN3	Insurance Additional Information, Certification	No	Yes
ROL	Role	No	Yes
ACC	Accident	No	No
UB1	UB82	No	No
UB2	UB92 Data	No	No

ADT_A28 is used to add person information, often in a master patient index, enterprise patient identity feed, or patient-demographics synchronization interface. It says "create this person/patient identity record" rather than "this patient has arrived for this visit."

A28 commonly uses ADT^A28^ADT_A05. That means the event is A28, while the backing structure is ADT_A05. The structure panel below shows ADT_A05 because that is the local v2.5.1 structure shared by A05, A14, A28, and A31.

A small A28 example

MSH|^~\&|MPI|CITYHOSP|EHR|CITYHOSP|20260715100000||ADT^A28^ADT_A05|ADT280001|P|2.5.1 EVN|A28|20260715100000|||MPIUSER^Patel^Rina PID|1||778899^^^CITYHOSP^MR~NHI1234^^^NATIONAL^NI||Ngata^Mere^Ana^^Ms^^L||19910421|F|||44 Harbour Road^^Auckland^^1010^NZ^H||^PRN^CP^^64^21^4441234 PD1|||CITYFAMILY^City Family Practice^L PV1|1|N

What systems do with it

The sender is usually an MPI, registration master, identity-management system, or EHR. Receivers use PID to add a person/patient identity record, PD1 for extra patient-level demographics, and optional ROL or provider-related data when the profile supports it.

In IHE Patient Identity Management, A28 is the create-patient/person feed. The receiver is expected to add the new patient record and acknowledge success or error. It is often paired with A31 for later updates and A40 for merges.

How to read the structure

The ADT_A05 structure includes many visit and billing-capable segments, but A28 profiles often treat PV1 as a pseudo-visit segment. In IHE-style feeds, PV1-2 may be the only required visit field, with a patient class such as N for not applicable. That tells the receiver this is identity data, not an active encounter.

Optional OBX segments may carry permanent observations in some profiles, and insurance or provider segments may be used when the identity feed owns that data. Keep the boundary clear: if the receiver is an MPI, visit-specific facts should not leak in just because the structure has room.

Implementation traps

The big trap is treating A28 like A04. A04 creates or starts a visit. A28 creates a person identity record. If the receiver opens an encounter from an A28, it may create visits that never existed.

The second trap is sending a thin identifier-only message to a receiver that expects a complete identity snapshot. For a new patient feed, PID should carry enough demographics and assigning-authority detail for the receiver to create a safe, matchable record.

Reference notes

HL7 v2.5.1 table 0354 maps A28 to the ADT_A05 message structure, and IHE Patient Identity Management describes ADT^A28^ADT_A05 as communicating the demographics of a new patient plus related information. Oracle's IHE mapping also lists A28 with ADT_A05 for create-patient workflows.