A08 and A31 both carry updated demographics: a new address, a corrected date of birth, a new phone number. The difference is what the update is attached to.
| ADT^A08 | ADT^A31 | |
|---|---|---|
| HL7 name | Update patient information | Update person information |
| Scope | A patient in the context of a visit (encounter) | A person, independent of any visit |
| Typical sender | Registration and ADT systems | Master patient index (MPI), or registration when no visit is involved |
| PV1 segment | Describes the visit being updated | Present because the structure requires it, but often sent with PV1-2 = N (not applicable) |
| Message structure | ADT_A01 | ADT_A05 up to v2.8.2; HL7's current table lists ADT_A28 |
| Paired "add" event | A04 register or A01 admit | A28 add person information |
ADT^A08: update patient information
A08 is the catch-all update for a patient and their current visit. It's sent when something changes and no more specific event applies: a new insurance plan, a corrected name, a different attending physician. In most feeds it's the highest-volume ADT event.
Because it uses the same structure as an admission (ADT_A01), an A08 carries a full PV1 segment, and receivers are expected to apply the update to that visit, identified by the visit number in PV1-19 or the account number in PID-18.
ADT^A31: update person information
A31 updates a person, regardless of any visit. It's typical of master patient index systems, which hold one record per person and push demographic changes to everything downstream. An A31 shouldn't change any encounter, and receivers shouldn't create one from it.
The message structure still requires a PV1 segment, so senders usually include a placeholder visit with patient class N (not applicable, from table 0004):
MSH|^~\&|MPI|MERCY GENERAL|DATAHUB|MERCY|20261101090000||ADT^A31^ADT_A05|MPI0042|P|2.5.1
EVN|A31|20261101090000
PID|1||MRN100234^^^MERCY^MR||SAMPLE^JANE^Q||19800101|F|||200 NEW ST^^SPRINGFIELD^IL^62704^USA
PV1|1|NThe same split for new records: A04 vs A28
The "add" events follow the same pattern. A04 (register a patient) creates a visit, such as an outpatient or emergency registration. A28 (add person information) adds a person to an MPI or another system without any visit.
What goes wrong
- Phantom encounters. A receiver that treats every ADT message as a visit creates an empty encounter for each A31 or A28.
- Missed demographic updates. A receiver that only listens for A08 never hears about address changes made in the MPI, which arrive as A31.
- Everything sent as A08. Some senders use A08 for every change, including person-level ones, with a stale or empty PV1. Receivers then update the wrong visit, or no visit at all.
- Visit-level fields in A31. Values in PV1 of an A31, such as a location or attending doctor, are usually leftovers and shouldn't overwrite real visit data.
Practical checklist
- Find out which events the sender actually uses. Profile a day of traffic and count messages by event type; don't rely on the specification alone.
- Decide the receiver's rules: A08 updates the patient and the visit in
PV1-19; A31 updates the person only. - Check PV1 in A31s. If
PV1-2isn'tN, find out whether the sender means anything by it. - Write it in the interface specification, including what happens when an A08 arrives for a visit the receiver doesn't know.
PipeHat's feed profile shows the event mix of a feed at a glance, plus how often each field is filled for each event type, for example whether PV1-19 is ever sent with an A31.