HL7 ADT_A31 Update Person Information

The person record changed, often in an MPI or enterprise identity feed.
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

SegmentNameRequiredRepeatable
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_A31 updates person information. It is close to A08, but the usual boundary is different: A31 is commonly used for MPI or person-level demographic synchronization, while A08 is commonly used for patient or encounter updates in a current episode of care.

A31 commonly appears as ADT^A31^ADT_A05. The A31 trigger says this is a person update; the ADT_A05 structure supplies the segment layout. The panel below shows ADT_A05 for that reason.

A small A31 example

MSH|^~\&|MPI|CITYHOSP|EHR|CITYHOSP|20260715113000||ADT^A31^ADT_A05|ADT310001|P|2.5.1 EVN|A31|20260715112900|||MPIUSER^Patel^Rina PID|1||778899^^^CITYHOSP^MR~NHI1234^^^NATIONAL^NI||Ngata^Mere^Ana^^Ms^^L||19910421|F|||52 Harbour Road^^Auckland^^1010^NZ^H||^PRN^CP^^64^21^4447777~^NET^Internet^mere.ngata@example.org PD1|||CITYFAMILY^City Family Practice^L PV1|1|N OBX|1|CE|LANG^Preferred language^L||mi^Maori^ISO639||||||F

What systems do with it

The sender is often an MPI, EHR master registration system, or patient-demographics supplier. Receivers use it to update an existing person record and may also add the person if the receiver does not already know them, depending on the profile. PID is the main payload; PD1, provider role segments, insurance, and OBX may carry additional person-level details.

A31 is useful when you want demographics to stay synchronized outside a single encounter. Historical backload, enterprise identity cleanup, address changes, preferred provider changes, and MPI-driven demographic corrections are common reasons it appears.

How to read the structure

The backing ADT_A05 structure looks visit-capable, but A31 often uses a pseudo PV1. IHE guidance describes a PV1 segment with patient class N when the message does not convey visit information. That prevents the receiver from turning a person update into a visit update.

The update may be sent as a full demographic snapshot rather than a narrow delta. That is safer for receivers that need to insert a patient if missing, but it means blank fields and repeats need clear rules. Is an absent phone number unchanged, unknown, or deleted? The interface agreement has to say.

Implementation traps

The first trap is confusing A31 with A08. If the change belongs to a current visit, A08 may be the right event. If the change belongs to the person identity record or MPI, A31 is often the better fit.

The second trap is not preserving identifier context. A31 updates demographics; it does not merge duplicate patients. If the problem is that two patient identifiers refer to the same person, use A40 or another agreed merge/change event rather than trying to solve it with a demographic update.

Reference notes

The HL7 v2+ patient-administration material describes A31 as an MPI/person-information update similar to A08, with A08 preferred for current-episode patient updates. IHE Patient Identity Management maps the message to ADT^A31^ADT_A05 and describes expected receiver behavior for updating or inserting the person record.