The Demo site for our new HL7 Version 2+ (plus) Standard
visit the hl7 website

Draft Website - For Review Purposes Only

Patient Administration

Chapter Chair/Editor:

Alexander de León

Kaiser Permanente

Chapter Editor:

Riki Merrick

Vernetzt, LLC

International Liaison:

Irma Jongeneel de Haas

HL7 The Netherlands, VZVZ

Sponsoring Committee:

Patient Administration

List Server:

pafm@lists.hl7.org



PURPOSE

The Patient Administration transaction set provides for the transmission of new or updated demographic and visit information about patients. Since virtually any system attached to the network requires information about patients, the Patient Administration transaction set is one of the most commonly used.

Generally, information is entered into a Patient Administration system and passed to the nursing, ancillary and financial systems either in the form of an unsolicited update or a response to a record-oriented query.

This chapter defines the transactions that occur at the seventh level, that is, the abstract messages. The examples included in this chapter were constructed using the HL7 Encoding Rules.

Trigger Events and Message Definitions

ADT/ACK - Admit/Visit Notification (Event A01)

An A01 event is intended to be used for "Admitted" patients only. An A01 event is sent as a result of a patient undergoing the admission process which assigns the patient to a bed. It signals the beginning of a patient's stay in a healthcare facility. Normally, this information is entered in the primary Patient Administration system and broadcast to the nursing units and ancillary systems. It includes short stay and "Adam Everyman" (e.g., patient name is unknown) admissions. For example, an A01 event can be used to notify: the pharmacy system that a patient has been admitted and may be legitimately prescribed drugs; the nursing system that the patient has been admitted and needs a care plan prepared; the finance system of the start of the billing period; the dietary system that a new patient has been installed and requires dietary services; the laboratory, pathology, and radiology systems that a patient has been admitted and is entitled to receive services; the clinical repository that an admission has taken place for the EMR (electronic medical record).

When an account's start and end dates span a period greater than any particular visit, the P01 (add patient account) event should be used to transmit the opening of an account. The A01 event can notify systems of the creation of an account as well as notify them of a patient's arrival in the healthcare facility. In order to create a new account without notifying of patient's arrival, use the P01 event.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT – Participation Information Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin and end date of the provider, use the –PRT-11 - Begin Date/Time and the –PRT-12 - End Date/Time in the PRT segment, with the applicable PRT-4 – Role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A01^ADT_A01: ADT Message
HL7 MessageStructure Table - ADT_A01
Segment Cardinality Must Implement Status
ADT_A01
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
AUTHORIZATION 0..* additional
AUT 1..1 Yes additional
PRT 0..* additional
REFERRAL 0..* additional
RF1 1..1 Yes additional
PRT 0..* additional
ACC 0..1 additional
UB1 0..1 additional
UB2 0..1 additional
PDA 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A01^ADT_A01

Send Application Ack: ACK^A01^ACK

Enhanced Mode Acknowledgement Choreography for ADT^A01^ADT_A01

When the MSH-15 value of an ADT^A01^ADT_A01 message is AL or ER or SU, an ACK^A01^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A01^ADT_A01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A01^ADT_A01 message is AL or ER or SU, an ACK^A01^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A01^ADT_A01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A01^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A01^ACK
NE, AL, ER, SU (none)

ADT/ACK - Transfer a Patient (Event A02)

An A02 event is issued as a result of the patient changing his or her assigned physical location.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition. If the transfer function of your Patient Administration system allows demographics to change at the same time as the transfer (for example an address change), we recommend (but do not require) sending two messages (an A02 followed by an A08). This A02 event can be used with admitted and non-admitted patients.

The new patient location should appear in PV1-3 - Assigned Patient Location while the old patient location should appear in PV1-6 - Prior Patient Location. For example, an A02 event can be used to notify: laboratory, radiology, pathology that the patient has changed location and test results should be redirected; pharmacy that drugs should be redirected for the patient; dietary that the meals should be delivered to a different location; the clinical repository that a transfer has taken place for the Electronic Medical Record.

If the patient is going to a temporary location (such as the O/R, X-RAY, LIMBO, the HALLWAY) it is recommended that the A09 (patient departing-tracking) and A10 (patient arriving-tracking) events be used instead of A02. It is recommended that A02 be used only for a real change in the census bed in the Patient Administration system.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT – Participation Information Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin- and end-date of the provider, use the –PRT-11 - Begin Date/Time and the –PRT-12 - End Date/Time in the PRT segment, with the applicable PRT-4 – Role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A02^ADT_A02: ADT Message
HL7 MessageStructure Table - ADT_A02
Segment Cardinality Must Implement Status
ADT_A02
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
PDA 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A02^ADT_A02

Send Application Ack: ADT^A02^ADT_A02

Enhanced Mode Acknowledgement Choreography for ADT^A02^ADT_A02

When the MSH-15 value of an ADT^A02^ADT_A02 message is AL or ER or SU, an ACK^A02^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A02^ADT_A02 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A02^ADT_A02 message is AL or ER or SU, an ACK^A02^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A02^ADT_A02 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A02^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A02^ACK
NE, AL, ER, SU (none)

ADT/ACK - Discharge/End Visit (Event A03)

An A03 event signals the end of a patient's stay in a healthcare facility. It signals that the patient's status has changed to "discharged" and that a discharge date has been recorded. The patient is no longer in the facility. The patient's location prior to discharge should be entered in PV1-3 - Assigned Patient Location.

An A03 event can be sent to notify: the pharmacy that the patient's stay has ended and that entitlement to drugs has changed accordingly; the nursing system that the patient has been discharged and that the care plan can be completed; the extended care or home health system that the patient has been discharged and that the new extended care or home health admission assessment can be scheduled; the finance system that the patient billing period has ended; and/or the clinical repository that discharge has taken place for the EMR.

For non-admitted patients, an A03 event signals the end of a patient's visit to a healthcare facility. It could be used to signal the end of a visit for a one-time or recurring outpatient who is not assigned to a bed. It could also be used to signal the end of a visit to the Emergency Room. PV1-45 - Discharge Date/Time can be used for the visit end date/time.

When an account's start and end dates span a period greater than any particular visit, the P06 (end account) event should be used to transmit information about the closing of an account. To indicate that a patient has expired, use an A03 event with the PID-29 - Patient Death Date and Time and PID-30 - Patient Death Indicator filled in.

The fields included when this message is sent should be the fields pertinent to communicate this event. The optional allergy, next-of-kin, insurance and guarantor fields should be sent when required to support advanced notification for pending extended care or home health admission requirements (such as scheduling of a nursing assessment in preparation for completion of the extended care plan). When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT - Participation Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin date and end date of the provider, use the –PRT-11 - Begin Date/Time and the –PRT-12 - End Date/Time in the PRT segment, with the applicable PRT-4 – Role of Particpation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A03^ADT_A03: ADT Message
HL7 MessageStructure Table - ADT_A03
Segment Cardinality Must Implement Status
ADT_A03
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
AUTHORIZATION 0..* additional
AUT 1..1 Yes additional
PRT 0..* additional
REFERRAL 0..* additional
RF1 1..1 Yes additional
PRT 0..* additional
ACC 0..1 additional
PDA 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A03^ADT_A03

Send Application Ack: ADT^A03^ADT_A03

Enhanced Mode Acknowledgement Choreography for ADT^A03^ADT_A03

When the MSH-15 value of an ADT^A03^ADT_A03 message is AL or ER or SU, an ACK^A03^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A03^ADT_A03 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A03^ADT_A03 message is AL or ER or SU, an ACK^A03^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A03^ADT_A03 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A03^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A03^ACK
NE, AL, ER, SU (none)

ADT/ACK - Register a Patient (Event A04)

An A04 event signals that the patient has arrived or checked in as a one-time, or recurring outpatient, and is not assigned to a bed. One example might be its use to signal the beginning of a visit to the Emergency Room (= Casualty, etc.).

Note: Some systems refer to these events as outpatient registrations or emergency admissions. PV1-44 - Admit Date/Time is used for the visit start date/time.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT - Participation Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRTsegment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin- and end-date of the provider, use the –PRT-11 - Begin Date/Time and the –PRT-12 - End Date/Time in the PRT segment, with the applicable PRT-4 – role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A04^ADT_A01: ADT Message
HL7 MessageStructure Table - ADT_A01
Segment Cardinality Must Implement Status
ADT_A01
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
AUTHORIZATION 0..* additional
AUT 1..1 Yes additional
PRT 0..* additional
REFERRAL 0..* additional
RF1 1..1 Yes additional
PRT 0..* additional
ACC 0..1 additional
UB1 0..1 additional
UB2 0..1 additional
PDA 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A04^ADT_A01

Send Application Ack: ADT^A04^ADT_A01

Enhanced Mode Acknowledgement Choreography for ADT^A04^ADT_A01

When the MSH-15 value of an ADT^A04^ADT_A01 message is AL or ER or SU, an ACK^A04^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A04^ADT_A01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A04^ADT_A01 message is AL or ER or SU, an ACK^A04^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A04^ADT_A01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A04^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A04^ACK
NE, AL, ER, SU (none)

ADT/ACK - Pre-Admit a Patient (Event A05)

An A05 event is sent when a patient undergoes the pre-admission process. During this process, episode-related data is collected in preparation for a patient's visit or stay in a healthcare facility. For example, a pre-admit may be performed prior to inpatient or outpatient surgery so that lab tests can be performed prior to the surgery. This event can also be used to pre-register a non-admitted patient.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT - Participation Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Visit level providers (corresponding to the PV1 data) are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin- and end-date of the provider, use the –PRT-11 - Begin Date/Time and the –PRT-12 - End Date/Time in the PRT segment, with the applicable PRT-4 – Role of Participation. Refer to Chapter 15 for the definition of the PRT segment.

ADT^A05^ADT_A05: ADT Message
HL7 MessageStructure Table - ADT_A05
Segment Cardinality Must Implement Status
ADT_A05
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
AUTHORIZATION 0..* additional
AUT 1..1 Yes additional
PRT 0..* additional
REFERRAL 0..* additional
RF1 1..1 Yes additional
PRT 0..* additional
ACC 0..1 additional
UB1 0..1 additional
UB2 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A05^ADT_A05

Send Application Ack: ADT^A05^ADT_A05

Enhanced Mode Acknowledgement Choreography for ADT^A05^ADT_A05

When the MSH-15 value of an ADT^A05^ADT_A05 message is AL or ER or SU, an ACK^A05^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A05^ADT_A05 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A05^ADT_A05 message is AL or ER or SU, an ACK^A05^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A05^ADT_A05 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A05^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A05^ACK
NE, AL, ER, SU (none)

ADT/ACK - Change an Outpatient to an Inpatient (Event A06)

An A06 event is sent when a patient who was present for a non-admitted visit is being admitted after an evaluation of the seriousness of the patient's condition. This event changes a patient's status from non-admitted to admitted. The new patient location should appear in PV1-3 - Assigned Patient Location, while the old patient location (if different) should appear in PV1-6 - Prior Patient Location. The new patient class should appear in PV1-2 - Patient Class.

It will be left to implementation negotiation to determine whether disparate systems merely change the patient class, or close and open a new account. The current active account number should appear in field PID-18 - Patient Account Number; the prior account number can be included optionally in MRG-3 - Prior Patient Account Number. This arrangement is not intended to be a type of merge. The MRG segment is used here only for MRG-3 - Prior Patient Account Number. PV1-19 - Visit Number may also be changed during this event.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT – Participation Information Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Visit level providers (corresponding to the PV1 data) are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin- and end-date of the provider, use the PRT-11 –Begin Date/Time and the PRT-12 –End Date/Time in the PRT segment, with the applicable PRT-4 – role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A06^ADT_A06: ADT Message
HL7 MessageStructure Table - ADT_A06
Segment Cardinality Must Implement Status
ADT_A06
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
MRG 0..1 additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 1..1 Yes additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
ACC 0..1 additional
UB1 0..1 additional
UB2 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A06^ADT_A06

Send Application Ack: ADT^A06^ADT_A06

Enhanced Mode Acknowledgement Choreography for ADT^A06^ADT_A06

When the MSH-15 value of an ADT^A06^ADT_A06 message is AL or ER or SU, an ACK^A06^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A06^ADT_A06 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A06^ADT_A06 message is AL or ER or SU, an ACK^A06^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A06^ADT_A06 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A06^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A06^ACK
NE, AL, ER, SU (none)

ADT/ACK - Change an Inpatient to an Outpatient (Event A07)

An A07 event is sent when a patient who was admitted changes his/her status to "no longer admitted" but is still being seen for this episode of care. This event changes a patient from an "admitted" to a "non-admitted" status. The new patient location should appear in PV1-3 - Assigned Patient Location, while the old patient location (if different) should appear in PV1-6 - Prior Patient Location.

It will be left to implementation negotiation to determine whether disparate systems merely change the patient class, or close and open a new account. The current active account number should appear in field PID-18 - Patient Account Number; the prior account number can be included optionally in MRG-3 - Prior Patient Account Number. This arrangement is not intended to be a type of merge. The MRG segment is used here only for MRG-3 - Prior Patient Account Number. PV1-19 - Visit Number may also be changed during this event.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT – Participation Information Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin and end date of the provider, use the –PRT-11 - Begin Date/Time and the –PRT-12 - End Date/Time in the PRT segment, with the applicable PRT-4 – Role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A07^ADT_A06: ADT Message
HL7 MessageStructure Table - ADT_A06
Segment Cardinality Must Implement Status
ADT_A06
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
MRG 0..1 additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 1..1 Yes additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
ACC 0..1 additional
UB1 0..1 additional
UB2 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A07^ADT_A06

Send Application Ack: ADT^A07^ADT_A06

Enhanced Mode Acknowledgement Choreography for ADT^A07^ADT_A06

When the MSH-15 value of an ADT^A07^ADT_A06 message is AL or ER or SU, an ACK^A07^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A07^ADT_A06 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A07^ADT_A06 message is AL or ER or SU, an ACK^A07^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A07^ADT_A06 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A07^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A07^ACK
NE, AL, ER, SU (none)

ADT/ACK - Update Patient Information (Event A08)

This trigger event is used when any patient information has changed but when no other trigger event has occurred. For example, an A08 event can be used to notify the receiving systems of a change of address or a name change. We strongly recommend that the A08 transaction be used to update fields that are not updated by any of the other trigger events. If there are specific trigger events for this update, these trigger events should be used. For example, if a patient's address and location are to be changed, then an A08 is used to change the patient address and the appropriate patient location trigger event is used to change the patient location. The A08 event can include information specific to an episode of care, but it can also be used for demographic information only.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT – Participation Information Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin- and end-date of the provider, use the PRT-11 – Begin Date/Time and the –PRT-12 - End Date/Time in the PRT, with the applicable PRT-4 – role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A08^ADT_A01: ADT Message
HL7 MessageStructure Table - ADT_A01
Segment Cardinality Must Implement Status
ADT_A01
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
AUTHORIZATION 0..* additional
AUT 1..1 Yes additional
PRT 0..* additional
REFERRAL 0..* additional
RF1 1..1 Yes additional
PRT 0..* additional
ACC 0..1 additional
UB1 0..1 additional
UB2 0..1 additional
PDA 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A08^ADT_A01

Send Application Ack: ADT^A08^ADT_A01

Enhanced Mode Acknowledgement Choreography for ADT^A08^ADT_A01

When the MSH-15 value of an ADT^A08^ADT_A01 message is AL or ER or SU, an ACK^A08^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A08^ADT_A01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A08^ADT_A01 message is AL or ER or SU, an ACK^A08^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A08^ADT_A01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A08^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A08^ACK
NE, AL, ER, SU (none)

ADT/ACK - Patient Departing - Tracking (Event A09)

The A09 and A10 - patient arriving-tracking events are used when there is a change in a patient's physical location (inpatient or outpatient) and when this is NOT a change in the official census bed location, as in the case of an outpatient setting. There are three situations that qualify as non-census location changes: (a) patient tracking, (b) the patient is in transit between locations for some time, (c) a notification of temporary location change.

Patient tracking: This can be used when the nursing application sends a "transfer" before the Patient Administration (or official census) system issues an A02 (transfer a patient) event. If the patient has left for a non-temporary location and is not in transit, then the PV1-3 - Assigned Patient Location must contain the new patient location, while PV1-6 - Prior Patient Location must contain the old patient location.

In transit: The patient's location during the time between an A09 and an A10 (patient arriving - tracking) is defined as "in transit." The A09 event is sent when a patient departs from one area of the healthcare facility for the purpose of arriving at another area, but without leaving the healthcare institution. This event is used when there is a time span during which the patient is neither at his/her old location nor at his/her new location. This process can take some time if a patient is being sent to another area in a multi-campus or multi-facility environment. The combination of an A09 and an A10 would serve the same purpose as an A02 (transfer a patient) event, except that it accounts for a gap in time required for transport between facilities. If the patient will be in transit during the time between the A09 (patient departing - tracking) event and the A10 (patient arriving - tracking) event, then PV1-42 - Pending Location is used for the new location, and PV1-11 - Temporary Location and PV1-43 - Prior Temporary Location would not be used. PV1-6 - Prior Patient Location should be used for the old location.

Temporary location: An A09 can also be used when the patient is being sent to a temporary location (such as the O/R, X-RAY, LIMBO, or HALLWAY). The patient may or may not return to the same assigned location after occupying the temporary location. If the patient is going to a temporary location (such as the O/R, X-RAY, LIMBO, or HALLWAY), then PV1-11 - Temporary Location is used to indicate the new temporary location. If the patient is moving from one temporary location to another, then PV1-43 - Prior Temporary Location may also be used. PV1-6 - Prior Patient Location and PV1-11 - Temporary Location should be used when the patient is moving from a permanent location to a temporary location.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

Attention: The DG1 segment was retained for backward compatibility only as of v2.4 and was withdrawn and removed from this message structure as of v2.7.

ADT^A09^ADT_A09: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A09^ADT_A09

Send Application Ack: ADT^A09^ADT_A09

Enhanced Mode Acknowledgement Choreography for ADT^A09^ADT_A09

When the MSH-15 value of an ADT^A09^ADT_A09 message is AL or ER or SU, an ACK^A09^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A09^ADT_A09 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A09^ADT_A09 message is AL or ER or SU, an ACK^A09^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A09^ADT_A09 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A09^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A09^ACK
NE, AL, ER, SU (none)

ADT/ACK - Patient Arriving - Tracking (Event A10)

The A10 event is sent when a patient arrives at a new location in the healthcare facility (inpatient or outpatient). The A09 - patient departing-tracking and A10 events are used when there is a change in a patient's physical location and when this is NOT a change in the official census bed location, as in the case of an outpatient setting. There are three varieties of these non-census location changes involving three different kinds of notification: (a) an unofficial notification of location change prior to the official notification of patient tracking, (b) the patient is in transit between locations for some time, (c) a notification of a temporary location change.

Patient tracking: If the patient is now at a non-temporary location and is not in transit, then PV1-3 - Assigned Patient Location must contain the new patient location and PV1-6 - Prior Patient Location can contain the old patient location.

In transit: This is used when there is some period of time between when the patient leaves his/her old location and when he/she arrives at the new assigned location. If the patient was in transit during the time between the A09 (patient departing-tracking) event and the A10 (patient arriving-tracking) event, then PV1-3 - Assigned Patient Location is used for the new location and PV1-6 - Prior Patient Location should be used for the old location. PV1-11 - Temporary Location and PV1-43 - Prior Temporary Location are not used.

Temporary location: An A10 event can also be used when the patient is being transferred from a temporary location (X-RAY, O/R, LIMBO, or HALLWAY) to the new assigned location. If the patient is arriving at a temporary location (such as the O/R, X-RAY, LIMBO, or HALLWAY), then PV1-11 - Temporary Location would be used to indicate the new temporary location. If the patient is moving from one temporary location to another, then PV1-43 - Prior Temporary Location may also be used. If the patient is arriving at a permanent location from a temporary location, PV1-3 - Assigned Patient Location should be used for the new location, and PV1-43 - Prior Temporary Location should be used for the old location.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

Attention: The DG1 segment was retained for backward compatibility only as of v2.4 and was withdrawn and removed from this message structure as of v2.7.

ADT^A10^ADT_A09: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A10^ADT_A09

Send Application Ack: ADT^A10^ADT_A09

Enhanced Mode Acknowledgement Choreography for ADT^A10^ADT_A09

When the MSH-15 value of an ADT^A10^ADT_A09 message is AL or ER or SU, an ACK^A10^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A10^ADT_A09 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A10^ADT_A09 message is AL or ER or SU, an ACK^A10^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A10^ADT_A09 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A10^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A10^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Admit / Visit Notification (Event A11)

For "admitted" patients, the A11 event is sent when an A01 (admit/visit notification) event is cancelled, either because of an erroneous entry of the A01 event, or because of a decision not to admit the patient after all.

For "non-admitted" patients, the A11 event is sent when an A04 (register a patient) event is cancelled, either because of an erroneous entry of the A04 event, or because of a decision not to check the patient in for the visit after all. To cancel an A05 (pre-admit a patient) event, use the A38 (cancel pre-admit), which was new for Version 2.3 of this Standard.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

Attention: The DG1 segment was retained for backward compatibility only as of v2.4 and was withdrawn and removed from this message structure as of v2.7.

ADT^A11^ADT_A09: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A11^ADT_A09

Send Application Ack: ADT^A11^ADT_A09

Enhanced Mode Acknowledgement Choreography for ADT^A11^ADT_A09

When the MSH-15 value of an ADT^A11^ADT_A09 message is AL or ER or SU, an ACK^A11^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A11^ADT_A09 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A11^ADT_A09 message is AL or ER or SU, an ACK^A11^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A11^ADT_A09 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A11^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A11^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Transfer (Event A12)

The A12 event is sent when an A02 (transfer a patient) event is cancelled, either because of erroneous entry of the A02 event or because of a decision not to transfer the patient after all. PV1-3 - Assigned Patient Location must show the location of the patient prior to the original transfer.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) even be used in addition.

Attention: The DG1 segment was retained for backward compatibility only as of v2.4 and was withdrawn and removed from this message structure as of v2.7.

ADT^A12^ADT_A12: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A12^ADT_A12

Send Application Ack: ADT^A12^ADT_A12

Enhanced Mode Acknowledgement Choreography for ADT^A12^ADT_A12

When the MSH-15 value of an ADT^A12^ADT_A12 message is AL or ER or SU, an ACK^A12^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A12^ADT_A12 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A12^ADT_A12 message is AL or ER or SU, an ACK^A12^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A12^ADT_A12 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A12^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A12^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Discharge / End Visit (Event A13)

The A13 event is sent when an A03 (discharge/end visit) event is cancelled, either because of erroneous entry of the A03 event or because of a decision not to discharge or end the visit of the patient after all. PV1-3 - Assigned Patient Location should reflect the location of the patient after the cancellation has been processed.

Note: This location may be different from the patient's location prior to the erroneous discharge. Prior Location could be used to show the location of the patient prior to the erroneous discharge.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

The PRT - Participation Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin- and end-date of the provider, use the –PRT-11 - Begin Date/Time and the –PRT-12 - End Date/Time in the ROL, with the applicable PRT-4 – Role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A13^ADT_A01: ADT Message
HL7 MessageStructure Table - ADT_A01
Segment Cardinality Must Implement Status
ADT_A01
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
AUTHORIZATION 0..* additional
AUT 1..1 Yes additional
PRT 0..* additional
REFERRAL 0..* additional
RF1 1..1 Yes additional
PRT 0..* additional
ACC 0..1 additional
UB1 0..1 additional
UB2 0..1 additional
PDA 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A13^ADT_A01

Send Application Ack: ADT^A13^ADT_A01

Enhanced Mode Acknowledgement Choreography for ADT^A13^ADT_A01

When the MSH-15 value of an ADT^A13^ADT_A01 message is AL or ER or SU, an ACK^A13^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A13^ADT_A01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A13^ADT_A01 message is AL or ER or SU, an ACK^A13^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A13^ADT_A01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A13^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A13^ACK
NE, AL, ER, SU (none)

ADT/ACK - Pending Admit (Event A14)

An A14 event notifies other systems of a planned admission, when there is a reservation or when patient admission is to occur imminently. The A14 event is similar to a pre-admit, but without the implication that an account should be opened for the purposes of tests prior to admission. It is used when advanced notification of an admit is required in order to prepare for the patient's arrival.

The PRT - Participation Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin- and end-date of the provider, use the –PRT-11 - Begin Date/Time and the –PRT-12 - End Date/Time in the PRT, with the applicable PRT-4 – Role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A14^ADT_A05: ADT Message
HL7 MessageStructure Table - ADT_A05
Segment Cardinality Must Implement Status
ADT_A05
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
AUTHORIZATION 0..* additional
AUT 1..1 Yes additional
PRT 0..* additional
REFERRAL 0..* additional
RF1 1..1 Yes additional
PRT 0..* additional
ACC 0..1 additional
UB1 0..1 additional
UB2 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A14^ADT_A05

Send Application Ack: ADT^A14^ADT_A05

Enhanced Mode Acknowledgement Choreography for ADT^A14^ADT_A05

When the MSH-15 value of an ADT^A14^ADT_A05 message is AL or ER or SU, an ACK^A14^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A14^ADT_A05 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A14^ADT_A05 message is AL or ER or SU, an ACK^A14^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A14^ADT_A05 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A14^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A14^ACK
NE, AL, ER, SU (none)

ADT/ACK - Pending Transfer (Event A15)

An A15 event notifies other systems of a plan to transfer a patient to a new location when the patient has not yet left the old location. It is used when advanced notification of a transfer is required in order to prepare for the patient's location change. For example, this transaction could be sent so that staff will be on hand to move the patient or so that dietary services can route the next meal to the new location.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT - Participation Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin- and end-date of the provider, use the PRT-11 - Begin Date/Time and the PRT-12 - End Date/Time in the PRT segment, with the applicable PRT-4 – Role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

Attention: The DG1 segment was retained in this message for backward compatibility only as of v2.4 and was withdrawn and removed from this message structure as of v2.7.

ADT^A15^ADT_A15: ADT Message
HL7 MessageStructure Table - ADT_A15
Segment Cardinality Must Implement Status
ADT_A15
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 1..* Yes additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A15^ADT_A15

Send Application Ack: ADT^A15^ADT_A15

Enhanced Mode Acknowledgement Choreography for ADT^A15^ADT_A15

When the MSH-15 value of an ADT^A15^ADT_A15 message is AL or ER or SU, an ACK^A15^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A15^ADT_A15 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A15^ADT_A15 message is AL or ER or SU, an ACK^A15^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A15^ADT_A15 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A15^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A15^ACK
NE, AL, ER, SU (none)

ADT/ACK - Pending Discharge (Event A16)

An A16 event notifies other systems of a plan to discharge a patient when the patient has not yet left the healthcare facility. It is used when advanced notification of a discharge is required in order to prepare for the patient's change in location. For example, it is used to notify the pharmacy of the possible need for discharge drugs or to notify psychotherapy of the possible need for post-discharge appointments or to notify the extended care or home health system that the patient will be discharged and that the new extended care and home health admission assessment can be scheduled.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT – Participation Information Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin- and end-date of the provider, use the PRT-11 - Begin Date/Time and the PRT-12 - End Date/Time in the PRT, with the applicable PRT-4 – Role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A16^ADT_A16: ADT Message
HL7 MessageStructure Table - ADT_A16
Segment Cardinality Must Implement Status
ADT_A16
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
AUTHORIZATION 0..* additional
AUT 1..1 Yes additional
PRT 0..* additional
REFERRAL 0..* additional
RF1 1..1 Yes additional
PRT 0..* additional
ACC 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A16^ADT_A16

Send Application Ack: ADT^A16^ADT_A16

Enhanced Mode Acknowledgement Choreography for ADT^A16^ADT_A16

When the MSH-15 value of an ADT^A16^ADT_A16 message is AL or ER or SU, an ACK^A16^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A16^ADT_A16 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A16^ADT_A16 message is AL or ER or SU, an ACK^A16^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A16^ADT_A16 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A16^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A16^ACK
NE, AL, ER, SU (none)

ADT/ACK - Swap Patients (Event A17)

The A17 is used when it is decided that two patients will exchange beds. The patient ID and visit data are repeated for the two patients changing places. See section 3.5.1, "Swapping a patient," for a discussion of issues related to implementing this trigger event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

ADT^A17^ADT_A17: ADT Message
HL7 MessageStructure Table - ADT_A17
Segment Cardinality Must Implement Status
ADT_A17
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION_RESULT_1 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION_RESULT_2 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A17^ADT_A17

Send Application Ack: ADT^A17^ADT_A17

Enhanced Mode Acknowledgement Choreography for ADT^A17^ADT_A17

When the MSH-15 value of an ADT^A17^ADT_A17 message is AL or ER or SU, an ACK^A17^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A17^ADT_A17 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A17^ADT_A17 message is AL or ER or SU, an ACK^A17^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A17^ADT_A17 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A17^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A17^ACK
NE, AL, ER, SU (none)

ADT/ACK - Merge Patient Information (Event A18)

The Original Mode Query was maintained for backward compatibility as of v2.3.1 and was withdrawn as of v2.7. The reader is referred to sections 3.3.40 – (event A40 - merge patient-patient identifier list), 3.3.41 (event A41 - merge account-patient account number) and 3.3.42 (event A42 - merge visit-visit number) for the current query/response message structure.

See section 3.5.2, "Merging patient/person information," for a discussion of issues related to implementing patient merge events.

QRY/ADR - Patient Query (Event A19)

The Original Mode Query was maintained for backward compatibility as of v2.4 and was withdrawn as of v2.7. The reader is referred to chapter 5, section 5.4, for the current query/response message structure.

ADT/ACK - Bed Status Update (Event A20)

Certain nursing/census applications need to be able to update the Patient Administration system's bed status. The following is the associated record layout:

ADT^A20^ADT_A20: ADT Message
HL7 MessageStructure Table - ADT_A20
Segment Cardinality Must Implement Status
ADT_A20
MSH 1..1 Yes additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
NPU 1..1 Yes additional

Original Mode Acknowledgement Choreography for ADT^A20^ADT_A20

Send Application Ack: ADT^A20^ADT_A20

Enhanced Mode Acknowledgement Choreography for ADT^A20^ADT_A20

When the MSH-15 value of an ADT^A20^ADT_A20 message is AL or ER or SU, an ACK^A20^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A20^ADT_A20 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A20^ADT_A20 message is AL or ER or SU, an ACK^A20^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A20^ADT_A20 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A20^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A20^ACK
NE, AL, ER, SU (none)

ADT/ACK - Patient Goes on a Leave of Absence (Event A21)

An A21 event is sent to notify systems that an admitted patient has left the healthcare institution temporarily. It is used for systems in which a bed is still assigned to the patient, and it puts the current admitted patient activities on hold. For example, it is used to notify dietary services and laboratory systems when the patient goes home for the weekend.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

As there is no specific field for the LOA start date/time, it is recommended field EVN-6 - Event Occurred contain the date/time the patient actually left. PV2-47 - Expected LOA Return Date/Time is used to communicate the date/time the patient is expected to return from LOA.

ADT^A21^ADT_A21: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A21^ADT_A21

Send Application Ack: ADT^A21^ADT_A21

Enhanced Mode Acknowledgement Choreography for ADT^A21^ADT_A21

When the MSH-15 value of an ADT^A21^ADT_A21 message is AL or ER or SU, an ACK^A21^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A21^ADT_A21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A21^ADT_A21 message is AL or ER or SU, an ACK^A21^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A21^ADT_A21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A21^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A21^ACK
NE, AL, ER, SU (none)

ADT/ACK - Patient Returns From a Leave of Absence (Event A22)

An A22 event is sent to notify systems that an admitted patient has returned to the healthcare institution after a temporary "leave of absence." It is used for systems in which a bed is still assigned to the patient, and it takes their current admitted patient activities off of "hold" status. For example, it is used to notify dietary services and laboratory systems when the patient returns from a weekend trip to his/her home.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

As there is no specific field for the LOA start date/time, it is recommended that field EVN-6 - Event Occurred contain the date/time the patient actually returned from LOA. PV2-47 - Expected LOA Return Date/Time is used to communicate the date/time the patient was expected to return from LOA.

ADT^A22^ADT_A21: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A22^ADT_A21

Send Application Ack: ADT^A22^ADT_A21

Enhanced Mode Acknowledgement Choreography for ADT^A22^ADT_A21

When the MSH-15 value of an ADT^A22^ADT_A21 message is AL or ER or SU, an ACK^A22^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A22^ADT_A21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A22^ADT_A21 message is AL or ER or SU, an ACK^A22^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A22^ADT_A21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A22^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A22^ACK
NE, AL, ER, SU (none)

ADT/ACK - Delete a Patient Record (Event A23)

The A23 event is used to delete visit or episode-specific information from the patient record. For example, it is used to remove old data from a database that cannot hold all historical patient visit data. When an event was entered erroneously, use one of the cancel transactions. This event can be used to purge account-level data while retaining the person in the database.

ADT^A23^ADT_A21: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A23^ADT_A21

Send Application Ack: ADT^A23^ADT_A21

Enhanced Mode Acknowledgement Choreography for ADT^A23^ADT_A21

When the MSH-15 value of an ADT^A23^ADT_A21 message is AL or ER or SU, an ACK^A23^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A23^ADT_A21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A23^ADT_A21 message is AL or ER or SU, an ACK^A23^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A23^ADT_A21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A23^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A23^ACK
NE, AL, ER, SU (none)

ADT/ACK - Link Patient Information (Event A24)

The A24 event is used when the first PID segment needs to be linked to the second PID segment and when both patient identifiers identify the same patient. Linking two or more patients does not require the actual merging of patient information; following a link event, the affected patient data records should remain distinct. For example, this event could be used in a hospital network environment in which there are multiple campuses and in which records need to be linked. For example, hospital A, hospital B, and hospital C would each keep their own records on a patient, but an A24 link event would be sent to a corporate-wide MPI to enable the coupling of ID information with the corporate ID number. It is used for corporate data repositories, etc. This event is not meant to link mothers and babies since a field exists (PID-21 - Mother's Identifier) for that purpose. See section 3.5.3, "Patient record links," for a discussion of issues related to implementing patient link messages and MPI issues.

This event can also be used to link two patient identifiers when a patient changes from inpatient to outpatient, or vice versa. This event can also be used to link two visits of the same patient.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

ADT^A24^ADT_A24: ADT Message
HL7 MessageStructure Table - ADT_A24
Segment Cardinality Must Implement Status
ADT_A24
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 0..1 additional
DB1 0..* additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 0..1 additional
DB1 0..* additional

Original Mode Acknowledgement Choreography for ADT^A24^ADT_A24

Send Application Ack: ADT^A24^ADT_A24

Enhanced Mode Acknowledgement Choreography for ADT^A24^ADT_A24

When the MSH-15 value of an ADT^A24^ADT_A24 message is AL or ER or SU, an ACK^A24^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A24^ADT_A24 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A24^ADT_A24 message is AL or ER or SU, an ACK^A24^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A24^ADT_A24 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A24^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A24^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Pending Discharge (Event A25)

The A25 event is sent when an A16 (pending discharge) event is cancelled, either because of erroneous entry of the A16 event or because of a decision not to discharge the patient after all.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

ADT^A25^ADT_A21: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A25^ADT_A21

Send Application Ack: ADT^A25^ADT_A21

Enhanced Mode Acknowledgement Choreography for ADT^A25^ADT_A21

When the MSH-15 value of an ADT^A25^ADT_A21 message is AL or ER or SU, an ACK^A25^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A25^ADT_A21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A25^ADT_A21 message is AL or ER or SU, an ACK^A25^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A25^ADT_A21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A25^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A25^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Pending Transfer (Event A26)

The A26 event is sent when an A15 (pending transfer) event is cancelled, either because of erroneous entry of the A15 event or because of a decision not to transfer the patient after all.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

ADT^A26^ADT_A21: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A26^ADT_A21

Send Application Ack: ADT^A26^ADT_A21

Enhanced Mode Acknowledgement Choreography for ADT^A26^ADT_A21

When the MSH-15 value of an ADT^A26^ADT_A21 message is AL or ER or SU, an ACK^A26^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A26^ADT_A21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A26^ADT_A21 message is AL or ER or SU, an ACK^A26^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A26^ADT_A21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A26^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A26^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Pending Admit (Event A27)

The A27 event is sent when an A14 (pending admit) event is cancelled, either because of erroneous entry of the A14 event or because of a decision not to admit the patient after all.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

ADT^A27^ADT_A21: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A27^ADT_A21

Send Application Ack: ADT^A27^ADT_A21

Enhanced Mode Acknowledgement Choreography for ADT^A27^ADT_A21

When the MSH-15 value of an ADT^A27^ADT_A21 message is AL or ER or SU, an ACK^A27^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A27^ADT_A21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A27^ADT_A21 message is AL or ER or SU, an ACK^A27^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A27^ADT_A21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A27^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A27^ACK
NE, AL, ER, SU (none)

ADT/ACK - Add Person or Patient Information (Event A28)

The purpose of this and the three following messages was to allow sites with multiple systems and respective master patient databases to communicate activity related to a person regardless of whether that person is currently a patient on each system. Each system has an interest in the database activity of the others in order to maintain data integrity across an institution. Though they are defined within the ADT message set, these messages differ in that they are not patient-specific. To a certain registry, the person may be a person of interest, a potential future patient, or a potential guarantor. For example, these events can be used to maintain an MPI (master patient index), a cancer registry, members of a managed care plan, an HIV database, etc.

These events should not replace the use of the A01 (admit/visit notification), A03 (discharge/end visit), A04 (register a patient), A08 (update patient information), etc., events. They are not intended to be used for notification of real-time Patient Administration events. These events are primarily for demographic data, but optional historical non-demographic data may be sent as well.

The person whose data is being sent should be identified in the PID segment using the PID-3 - Patient Identifier List, even when the person is not a patient and may be a potential guarantor. An A28 establishes person identifiers, e.g., social security number, guarantor identifier, or other unique identifiers, and contains a person identifier in the PID-3 - Patient Identifier List. The person involved may or may not have active or inactive cases associated with them. When field names and descriptions say "patient," we must translate that to "person" for these transactions. In this manner, "person information" about a guarantor can be sent independently of the guarantor's relation to any patient.

For example, a site with separate inpatient, outpatient and medical records systems may require that each system maintain concurrent person information. Prior to an admit, the new person is added to the master database of the inpatient system, resulting in the broadcast of a message. The outpatient system receives the message and adds the person to its database with the possibility that the person may someday become a patient in its system. The medical records system receives the message and adds the person to its database with the possibility that it will track inpatient, outpatient, or clinical data for that person. The clinical repository database or MPI receives the message to keep all potential patients and guarantors in its database.

The A28 event can be used to send everything that is known about a person. For example, it can be sent to an ICU unit (in addition to the A02 (transfer a patient) event) when a patient is transferred to the ICU unit in order to backload all demographic information for the patient into the ICU system. An A28 (add person information) or A31 (update person information) can also be used for backloading MPI information for the person, or for backloading person and historical information.

In addition to adding a person to a database, the delete, update, and merge messages work in a similar manner to maintain concurrent person information. It is left up to site-specific negotiations to decide how much data must be transmitted or re-transmitted when a person becomes a patient.

To maintain backward compatibility with previous releases, the PV1 segment is required. However, a "pseudo-optional" PV1 can be achieved by valuing PV1-2 - Patient Class to N - not applicable.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT – Participation Information Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin and end date of the provider, use the PRT-11 - Begin Date/Time and the PRT-12 - End Date/Time in the PRT, with the applicable PRT-4 – Role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A28^ADT_A05: ADT Message
HL7 MessageStructure Table - ADT_A05
Segment Cardinality Must Implement Status
ADT_A05
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
AUTHORIZATION 0..* additional
AUT 1..1 Yes additional
PRT 0..* additional
REFERRAL 0..* additional
RF1 1..1 Yes additional
PRT 0..* additional
ACC 0..1 additional
UB1 0..1 additional
UB2 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A28^ADT_A05

Send Application Ack: ADT^A28^ADT_A05

Enhanced Mode Acknowledgement Choreography for ADT^A28^ADT_A05

When the MSH-15 value of an ADT^A28^ADT_A05 message is AL or ER or SU, an ACK^A28^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A28^ADT_A05 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A28^ADT_A05 message is AL or ER or SU, an ACK^A28^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A28^ADT_A05 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A28^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A28^ACK
NE, AL, ER, SU (none)

ADT/ACK - Delete Person Information (Event A29)

An A29 event can be used to delete all demographic information related to a given person. This event "undoes" an A28 (add person information) event. The information from the A28 event is deleted. This event is used, for example, when adding the information was performed in error, or when another record already exists for the person, or when one wants to purge the person from the database. When this event occurs, all visit and account level data for this person is also purged.

To maintain backward compatibility with previous releases, the PV1 segment is required. However, a "pseudo-optional" PV1 can be achieved by valuing PV1-2 - Patient Class to N - not applicable.

ADT^A29^ADT_A21: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A29^ADT_A21

Send Application Ack: ADT^A29^ADT_A21

Enhanced Mode Acknowledgement Choreography for ADT^A29^ADT_A21

When the MSH-15 value of an ADT^A29^ADT_A21 message is AL or ER or SU, an ACK^A29^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A29^ADT_A21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A29^ADT_A21 message is AL or ER or SU, an ACK^A29^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A29^ADT_A21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A29^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A29^ACK
NE, AL, ER, SU (none)

ADT/ACK - Merge Person Information (Event A30)

Attention: The Merge Person Information event was maintained for backward compatibility only as of v2.3.1 and withdrawn as of v2.7. From V 2.3.1 onwards, the reader is referred to the A40 (merge patient-patient identifier list) event to be used to merge patient information for a current episode.

ADT/ACK - Update Person Information (Event A31)

An A31 event can be used to update person information on an MPI. It is similar to an A08 (update patient information) event, but an A08 (update patient information) event should be used to update patient information for a current episode. An A28 (add person information) or A31 can also be used for backloading MPI information for the person, or for backloading person and historical information.

To maintain backward compatibility with previous releases, the PV1 segment is required. However, a "pseudo-optional" PV1 can be achieved by valuing PV1-2 - Patient Class to N - not applicable.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT – Participation Information Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin and end date of the provider, use the PRT-11 - Begin Date/Time and the PRT-12 - End Date/Time in the PRT segment, with the applicable PRT-4 – Role of Participation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A31^ADT_A05: ADT Message
HL7 MessageStructure Table - ADT_A05
Segment Cardinality Must Implement Status
ADT_A05
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
OH1 0..* additional
OH2 0..* additional
OH3 0..1 additional
OH4 0..* additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
NEXT_OF_KIN 0..* additional
NK1 1..1 Yes additional
OH2 0..* additional
OH3 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
AL1 0..* additional
IAM 0..* additional
DG1 0..* additional
DRG 0..1 additional
PROCEDURE 0..* additional
PR1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
GT1 0..* additional
INSURANCE 0..* additional
IN1 1..1 Yes additional
IN2 0..1 additional
IN3 0..* additional
ROL 0..* B
PRT 0..* additional
AUTHORIZATION 0..* additional
AUT 1..1 Yes additional
PRT 0..* additional
REFERRAL 0..* additional
RF1 1..1 Yes additional
PRT 0..* additional
ACC 0..1 additional
UB1 0..1 additional
UB2 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A31^ADT_A05

Send Application Ack: ADT^A31^ADT_A05

Enhanced Mode Acknowledgement Choreography for ADT^A31^ADT_A05

When the MSH-15 value of an ADT^A31^ADT_A05 message is AL or ER or SU, an ACK^A31^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A31^ADT_A05 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A31^ADT_A05 message is AL or ER or SU, an ACK^A31^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A31^ADT_A05 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A31^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A31^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Patient Arriving - Tracking (Event A32)

The A32 event is sent when an A10 (patient arriving-tracking) event is cancelled, either because of erroneous entry of the A10 event or because of a decision not to receive the patient after all.

If the patient was in a non-temporary location, then the PV1-3 - Assigned Patient Location may contain (if known) the original patient location prior to the erroneous A10 (patient arriving-tracking) event. If the patient was in a temporary location, then PV1-11 - Temporary Location may contain (if known) the original patient location prior to the erroneous A10 (patient arriving-tracking) event.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

ADT^A32^ADT_A21: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A32^ADT_A21

Send Application Ack: ADT^A32^ADT_A21

Enhanced Mode Acknowledgement Choreography for ADT^A32^ADT_A21

When the MSH-15 value of an ADT^A32^ADT_A21 message is AL or ER or SU, an ACK^A32^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A32^ADT_A21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A32^ADT_A21 message is AL or ER or SU, an ACK^A32^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A32^ADT_A21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A32^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A32^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Patient Departing - Tracking (Event A33)

The A33 event is sent when an A09 (patient departing-tracking) event is cancelled, either because of erroneous entry of the A09 event or because of a decision not to send the patient after all.

If the patient was in a non-temporary location, then PV1-3 - Assigned Patient location must contain the original patient location prior to the erroneous A09 (patient departing-tracking) event. If the patient was in a temporary location, then PV1-11 - Temporary Location must contain the original patient location prior to the erroneous A09 (patient departing-tracking) event.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

ADT^A33^ADT_A21: ADT Message
HL7 MessageStructure Table - ADT_A09
Segment Cardinality Must Implement Status
ADT_A09
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A33^ADT_A21

Send Application Ack: ADT^A33^ADT_A21

Enhanced Mode Acknowledgement Choreography for ADT^A33^ADT_A21

When the MSH-15 value of an ADT^A33^ADT_A21 message is AL or ER or SU, an ACK^A33^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A33^ADT_A21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A33^ADT_A21 message is AL or ER or SU, an ACK^A33^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A33^ADT_A21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A33^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A33^ACK
NE, AL, ER, SU (none)

ADT/ACK - Merge Patient Information - Patient ID Only (Event A34)

Attention: The Merge Patient Information – Patient ID Only (A34) event was maintained for backward compatibility only as of v2.3.1 and withdrawn as of v2.7. From V 2.3.1 onwards, the reader is referred to the A40 (Merge Patient-Patient Identifier List) event.

ADT/ACK - Merge Patient Information - Account Number Only (Event A35)

Attention: The Merge Patient Information – Account Number Only (A35) event was maintained for backward compatibility only as of v2.3.1 and withdrawn as of v2.7. From V 2.3.1 onwards, the reader is referred to the A41 (Merge Patient - Patient Account Number) event.

ADT/ACK - Merge Patient Information - Patient ID & Account Number (Event A36)

Attention: The Merge Patient Information – Patient ID & Account Number (A36) event was maintained for backward compatibility only as of v2.3.1 and withdrawn as of v2.7. From V 2.3.1 onwards, the reader is referred to the A40 (Merge Patient-Patient Identifier List) event and the A41 (merge patient - patient account number) event.     

ADT/ACK - Unlink Patient Information (Event A37)

The A37 event unlinks two patient identifiers.

ADT^A37^ADT_A15
HL7 MessageStructure Table - ADT_A15
Segment Cardinality Must Implement Status
ADT_A15
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 0..* additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ROL 0..* B
PRT 1..* Yes additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A37^ADT_A15

Send Application Ack: ADT^A37^ADT_A15

Enhanced Mode Acknowledgement Choreography for ADT^A37^ADT_A15

When the MSH-15 value of an ADT^A37^ADT_A15 message is AL or ER or SU, an ACK^A37^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A37^ADT_A15 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A37^ADT_A15 message is AL or ER or SU, an ACK^A37^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A37^ADT_A15 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A37^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A37^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Pre-Admit (Event A38)

The A38 event is sent when an A05 (pre-admit a patient) event is cancelled, either because of erroneous entry of the A05 event or because of a decision not to pre-admit the patient after all.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other fields change, it is recommended that the A08 (update patient information) event be used in addition.

st

ADT^A38^ADT_A38: ADT Message
HL7 MessageStructure Table - ADT_A38
Segment Cardinality Must Implement Status
ADT_A38
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
DB1 0..* additional
OBSERVATION 0..* additional
OBX 1..1 Yes additional
PRT 0..* additional
DG1 0..* additional
DRG 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A38^ADT_A38

Send Application Ack: ADT^A38^ADT_A38

Enhanced Mode Acknowledgement Choreography for ADT^A38^ADT_A38

When the MSH-15 value of an ADT^A38^ADT_A38 message is AL or ER or SU, an ACK^A38^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A38^ADT_A38 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A38^ADT_A38 message is AL or ER or SU, an ACK^A38^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A38^ADT_A38 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A38^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A38^ACK
NE, AL, ER, SU (none)

ADT/ACK - Merge Person - Patient ID (Event A39)

Attention: The Merge Person – Patient ID (A39) event was maintained for backward compatibility only as of v2.3.1 and withdrawn as of v2.7. From V 2.3.1 onwards, the reader is referred to the A41 (Merge Patient - Patient Account Number) event.

ADT/ACK - Merge Patient - Patient Identifier List (Event A40)

A merge has been done at the patient identifier list level. That is, two PID-3 - Patient Identifier List identifiers have been merged into one.

An A40 event is used to signal a merge of records for a patient that was incorrectly filed under two different identifiers. The "incorrect source identifier" identified in the MRG segment (MRG-1 - Prior Patient Identifier List) is to be merged with the required "correct target identifier" of the same "identifier type code" component identified in the PID segment (PID-3 - Patient Identifier List). The "incorrect source identifier" would then logically never be referenced in future transactions. It is noted that some systems may still physically keep this "incorrect identifier" for audit trail purposes or other reasons associated with database index implementation requirements.

The identifiers involved in identifying the patients may or may not have accounts, which may or may not have visits. An A40 (merge patient-patient identifier list) event is intended for merging patient records without merging other subordinate identifiers. Any other subordinate identifiers that were previously associated with the "incorrect source identifier" are now associated with the "correct target identifier." Specification of these other subordinate identifiers is not required.

This event and the message syntax do, however, allow for the specification of any other "new subordinate identifiers" (in addition to the PID-3 - Patient Identifier List identifier). For those environments that may require changes to these other subordinate identifiers because of the A40 (merge patient-patient identifier list) event, it is required that the old and new identifiers be a "tightly coupled" pair.

See sections 3.5.2, "Merging patient/person information," and 3.5.2.1.2, "Merge," for a discussion of issues related to the implementation of merge messages.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other fields change, it is recommended that the A31 (update person information) event be used for person level updates and A08 (update patient information) event for patient level updates.

ADT^A40^ADT_A39: ADT Message
HL7 MessageStructure Table - ADT_A39
Segment Cardinality Must Implement Status
ADT_A39
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PATIENT 1..* Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
MRG 1..1 Yes additional
PV1 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A40^ADT_A39

Send Application Ack: ADT^A40^ADT_A39

Enhanced Mode Acknowledgement Choreography for ADT^A40^ADT_A39

When the MSH-15 value of an ADT^A40^ADT_A39 message is AL or ER or SU, an ACK^A40^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A40^ADT_A39 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A40^ADT_A39 message is AL or ER or SU, an ACK^A40^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A40^ADT_A39 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A40^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A40^ACK
NE, AL, ER, SU (none)

ADT/ACK - Merge Account - Patient Account Number (Event A41)

A merge has been done at the account identifier level. That is, two PID-18 - Patient Account Number identifiers have been merged into one.

An A41 event is used to signal a merge of records for an account that was incorrectly filed under two different account numbers. The "incorrect source patient account number" identified in the MRG segment (MRG-3 - Prior Patient Account Number) is to be merged with the "correct target patient account number" identified in the PID segment (PID-18 - Patient Account Number). The "incorrect source patient account number" would then logically never be referenced in future transactions. It is noted that some systems may still physically keep this "incorrect identifier" for audit trail purposes or other reasons associated with database index implementation requirements.

The patient account numbers involved may or may not have visits. An A41 (merge account-patient account number) is intended for merging account records without merging other subordinate identifiers. Any other subordinate identifiers that were previously associated with the "incorrect source account number" are now associated with the required "correct target account number." Specification of these other subordinate identifiers is not required.

This event and the message syntax do, however, allow for the specification of any other "new subordinate identifiers" (in addition to the PID-18 - Patient Account Number identifier). For those environments that may require changes to these other subordinate identifiers because of this A41 (merge account-patient account number) event, it is required that the old and new identifiers be a "tightly coupled" pair.

Each superior identifier associated with this account identifier level should have the same value in both the PID and MRG segments.

See sections 3.5.2, "Merging patient/person information," and 3.5.2.1.2, "Merge," for a discussion of issues related to the implementation of merge messages.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other fields change, it is recommended that the A08 (update patient information) event be used in addition

ADT^A41^ADT_A39: ADT Message
HL7 MessageStructure Table - ADT_A39
Segment Cardinality Must Implement Status
ADT_A39
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PATIENT 1..* Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
MRG 1..1 Yes additional
PV1 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A41^ADT_A39

Send Application Ack: ADT^A41^ADT_A39

Enhanced Mode Acknowledgement Choreography for ADT^A41^ADT_A39

When the MSH-15 value of an ADT^A41^ADT_A39 message is AL or ER or SU, an ACK^A41^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A41^ADT_A39 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A41^ADT_A39 message is AL or ER or SU, an ACK^A41^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A41^ADT_A39 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A41^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A41^ACK
NE, AL, ER, SU (none)

ADT/ACK - Merge Visit - Visit Number (Event A42)

A merge has been done at the visit identifier level. That is, two PV1-19 - Visit Number identifiers have been merged into one.

An A42 event is used to signal a merge of records for a visit that was incorrectly filed under two different visit numbers. The "incorrect source visit number" identified in the MRG segment (MRG-5 - Prior Visit Number) is to be merged with the required "correct target visit number" identified in the PV1 segment (PV1-19 - Visit Number). The "incorrect source visit number" would then logically never be referenced in future transactions. It is noted that some systems may still physically keep this "incorrect identifier" for audit trail purposes or other reasons associated with database index implementation requirements.

An A42 (merge visit-visit number) event is intended for merging visit records without merging other identifiers. Any other identifiers that were previously associated with the "incorrect source visit number" are now associated with the "correct target visit number."

Each superior identifier associated with this visit identifier level should have the same value in the PID and MRG segments, or the MRG and PV1 segments, as appropriate.

See sections 3.5.2, "Merging patient/person information," and 3.5.2.1.2, "Merge," for a discussion of issues related to the implementation of merge messages.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other fields change, it is recommended that the A08 (update patient information) event be used in addition

ADT^A42^ADT_A39: ADT Message
HL7 MessageStructure Table - ADT_A39
Segment Cardinality Must Implement Status
ADT_A39
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PATIENT 1..* Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
MRG 1..1 Yes additional
PV1 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A42^ADT_A39

Send Application Ack: ADT^A42^ADT_A39

Enhanced Mode Acknowledgement Choreography for ADT^A42^ADT_A39

When the MSH-15 value of an ADT^A42^ADT_A39 message is AL or ER or SU, an ACK^A42^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A42^ADT_A39 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A42^ADT_A39 message is AL or ER or SU, an ACK^A42^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A42^ADT_A39 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A42^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A42^ACK
NE, AL, ER, SU (none)

ADT/ACK - Move Patient Information - Patient Identifier List (Event A43)

A move has been done at the patient identifier list level. Identifier to be moved in the PID-3 - Patient Identifier List and MRG-1 - Prior Patient Identifier List will have the same value. The "from" (incorrect source patient ID) and "to" (correct target patient ID) identifiers have different values. See A43 examples in section 5. The identifiers involved in identifying the patient to be moved (MRG-1 - Prior Patient Identifier List) may or may not have accounts, which may or may not have visits. In any case, all subordinate data sets associated with the identifier in MRG-1 - Prior Patient Identifier List are moved along with the identifier, from the "incorrect source patient ID" to the "correct target patient ID."

No identifiers subordinate to the identifier (account number, visit number, alternate visit ID) are valued in this message. Specification of these other subordinate identifiers is not required.

This event and the message syntax do, however, allow for the specification of a "new identifier" (PID-3 - Patient Identifier List), which may be application and/or implementation specific and therefore require site negotiation.

See sections 3.5.2, "Merging patient/person information," and 3.5.2.1.3, "Move," for a discussion of issues related to the implementation of move messages.

The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message. However, all PID data associated with the "correct target identifier" (PID-3 - Patient Identifier List) are treated as updated information.

ADT^A43^ADT_A43: ADT Message
HL7 MessageStructure Table - ADT_A43
Segment Cardinality Must Implement Status
ADT_A43
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PATIENT 1..* Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
MRG 1..1 Yes additional

Original Mode Acknowledgement Choreography for ADT^A43^ADT_A43

Send Application Ack: ADT^A43^ADT_A43

Enhanced Mode Acknowledgement Choreography for ADT^A43^ADT_A43

When the MSH-15 value of an ADT^A43^ADT_A43 message is AL or ER or SU, an ACK^A43^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A43^ADT_A43 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A43^ADT_A43 message is AL or ER or SU, an ACK^A43^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A43^ADT_A43 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A43^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A43^ACK
NE, AL, ER, SU (none)

ADT/ACK - Move Account Information - Patient Account Number (Event A44)

A move has been done at the account identifier level. That is, a PID-18 - Patient Account Number associated with one PID-3 - Patient Identifier List has been moved to another patient identifier list.

An A44 event is used to signal a move of records identified by the MRG-3 - Prior Patient Account Number from the "incorrect source patient identifier list" identified in the MRG segment (MRG-1 - Prior Patient Identifier List) to the "correct target patient identifier list" identified in the PID segment (PID-3 - Patient Identifier List).

The account number involved in identifying the account to be moved (MRG-3 - Prior Patient Account Number) may or may not have visits. In any case, all subordinate data sets associated with the account number in MRG-3 - Prior Patient Account Number are moved along with the account number, from the "incorrect source" ID (MRG-1 - Prior Patient Identifier List) to the "correct target" ID (PID-3 - Patient Identifier List).

No identifiers subordinate to the account number (visit number, alternate visit ID) are valued in this message.

This event and the message syntax do, however, allow for the specification of a "new identifier" (PID-18 - Patient Account Number), which may be application and/or implementation-specific and therefore require site negotiation.

All of the identifiers superior to the account number should be valued in both the MRG segment and the PID segment. In this message, the PID-3 - Patient Identifier List is superior to the account number.

See sections 3.5.2, "Merging patient/person information," and 3.5.2.1.3, "Move," for a discussion of issues related to the implementation of move messages.

The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message. However, all PID data associated with the "account number" are treated as updated information.

ADT^A44^ADT_A44: ADT Message
HL7 MessageStructure Table - ADT_A44
Segment Cardinality Must Implement Status
ADT_A44
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PATIENT 1..* Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
ARV 0..* B
MRG 1..1 Yes additional

Original Mode Acknowledgement Choreography for ADT^A44^ADT_A44

Send Application Ack: ADT^A44^ADT_A44

Enhanced Mode Acknowledgement Choreography for ADT^A44^ADT_A44

When the MSH-15 value of an ADT^A44^ADT_A44 message is AL or ER or SU, an ACK^A44^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A44^ADT_A44 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A44^ADT_A44 message is AL or ER or SU, an ACK^A44^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A44^ADT_A44 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A44^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A44^ACK
NE, AL, ER, SU (none)

ADT/ACK - Move Visit Information - Visit Number (Event A45)

A move has been done at the visit identifier level. That is, a PV1-19 - Visit Number or PV1-50 - Alternate Visit ID associated with one account identifier (PID-18 - Patient Account Number) has been moved to another account identifier.

An A45 event is used to signal a move of records identified by the MRG-5 - Prior Visit Number or the MRG-6 - Prior Alternate Visit ID from the "incorrect source account identifier" identified in the MRG segment (MRG-3 - Prior Patient Account Number) to the "correct target account identifier" identified in the PID segment (PID-18 - Patient Account Number).

This event and the message syntax do allow for the specification of "new identifiers" (PV1-19 - Visit Number, or PV1-50 - Alternate Visit ID), which may be application and/or implementation-specific and therefore require site negotiation.

All of the identifiers superior to the visit number or alternate visit ID should be valued in both the MRG segment and the PID segments. In this message, the account number and PID-3 - Patient Identifier List are superior to the visit number and alternate visit ID.

See sections 3.5.2, "Merging patient/person information," and 3.5.2.1.3, "Move," for a discussion of issues related to the implementation of move messages. The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message. However, all PID data associated with the "correct target visit ID" are treated as updated information.

ADT^A45^ADT_A45: ADT Message
HL7 MessageStructure Table - ADT_A45
Segment Cardinality Must Implement Status
ADT_A45
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
MERGE_INFO 1..* Yes additional
MRG 1..1 Yes additional
PV1 1..1 Yes additional

Original Mode Acknowledgement Choreography for ADT^A45^ADT_A45

Send Application Ack: ADT^A45^ADT_A45

Enhanced Mode Acknowledgement Choreography for ADT^A45^ADT_A45

When the MSH-15 value of an ADT^A45^ADT_A45 message is AL or ER or SU, an ACK^A45^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A45^ADT_A45 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A45^ADT_A45 message is AL or ER or SU, an ACK^A45^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A45^ADT_A45 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A45^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A45^ACK
NE, AL, ER, SU (none)

ADT/ACK - Change Patient ID (Event A46)

Attention: The Change Patient ID(A46) event was maintained for backward compatibility only as of v2.3.1 and withdrawn as of v2.7. From V 2.3.1 onwards, the reader is referred to the A47 (Change patient Identifier List) event..

ADT/ACK - Change Patient Identifier List (Event A47)

A change has been done at the patient identifier list level. That is, a single PID-3 - patient identifier list value has been found to be incorrect and has been changed.

An A47 event is used to signal a change of an incorrectly assigned PID-3 - Patient Identifier List value. The "incorrect source identifier" value is stored in the MRG segment (MRG-1 - Prior Patient Identifier List) and is to be changed to the "correct target patient ID" value stored in the PID segment (PID-3 - Patient Identifier List).

The identifier involved in identifying the patient may or may not have accounts, which may or may not have visits. An A47 (change patient identifier list) event is intended for changing the value of the patient identifier list without affecting other subordinate identifiers. Any other subordinate identifiers that were previously associated with the "incorrect source identifier" are now associated with the "correct target identifier." Specification of these other subordinate identifiers is not required.

This event and the message syntax do, however, allow for the specification of "new subordinate identifiers" (in addition to the PID-3 - Patient Identifier List identifier). For those environments that may require changes to these other subordinate identifiers because of this A47 (change patient identifier list) event, it is required that the old and new identifiers be a "tightly coupled" pair.

See sections 3.5.2, "Merging patient/person information," and 3.5.2.1.4, "Change identifier," for a discussion of issues related to the implementation of change messages.

The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A31 (update patient information) event be used in conjunction with this message.

ADT^A47^ADT_A44: ADT Message
HL7 MessageStructure Table - ADT_A44
Segment Cardinality Must Implement Status
ADT_A44
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PATIENT 1..* Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
ARV 0..* B
MRG 1..1 Yes additional

Original Mode Acknowledgement Choreography for ADT^A47^ADT_A44

Send Application Ack: ADT^A47^ADT_A44

Enhanced Mode Acknowledgement Choreography for ADT^A47^ADT_A44

When the MSH-15 value of an ADT^A47^ADT_A44 message is AL or ER or SU, an ACK^A47^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A47^ADT_A44 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A47^ADT_A44 message is AL or ER or SU, an ACK^A47^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A47^ADT_A44 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A47^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A47^ACK
NE, AL, ER, SU (none)

ADT/ACK - Change Alternate Patient ID (Event A48)

Attention: The Change Alternate Patient ID (A48) event was maintained for backward compatibility only as of v2.3.1 and withdrawn as of v2.7. From V 2.3.1 onwards, the reader is referred to the A37 (Change patient Identifier List) event.

ADT/ACK - Change Patient Account Number (Event A49)

A change has been done at the account identifier level. That is, a PID-18 - patient account number has been found to be incorrect and has been changed.

An A49 event is used to signal a change of an incorrectly assigned account number value. The "incorrect source account number" value is stored in the MRG segment (MRG-3 - Prior Patient Account Number) and is to be changed to the "correct target account number" value stored in the PID segment (PID-18 - Patient Account Number).

The patient account identifier involved in identifying the account may or may not have visits. An A49 (change patient account number) event is intended for changing the value of the account identifier without affecting other subordinate identifiers. Any other subordinate identifiers that were previously associated with the "incorrect source account number" are now associated with the "correct target account number". Specification of these other subordinate identifiers is not required.

This event and the message syntax do, however, allow for the specification of "new subordinate identifiers" (in addition to the PID-18 - Patient Account Number Identifier). For those environments that may require changes to these other subordinate identifiers because of this A49 (change patient account number) event, it is required that the old and new identifiers be a "tightly coupled" pair.

Each superior identifier associated with this account identifier level, i.e. the PID-3/MRG-1 should have the same value in both the PID and MRG segments.

See sections 3.5.2, "Merging patient/person information," and 3.5.2.1.4, "Change identifier," for a discussion of issues related to the implementation of change messages.

The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message.

ADT^A49^ADT_A43: ADT Message
HL7 MessageStructure Table - ADT_A43
Segment Cardinality Must Implement Status
ADT_A43
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PATIENT 1..* Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
MRG 1..1 Yes additional

Original Mode Acknowledgement Choreography for ADT^A49^ADT_A43

Send Application Ack: ADT^A49^ADT_A43

Enhanced Mode Acknowledgement Choreography for ADT^A49^ADT_A43

When the MSH-15 value of an ADT^A49^ADT_A43 message is AL or ER or SU, an ACK^A49^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A49^ADT_A43 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A49^ADT_A43 message is AL or ER or SU, an ACK^A49^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A49^ADT_A43 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A49^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A49^ACK
NE, AL, ER, SU (none)

ADT/ACK - Change Visit Number (Event A50)

A change has been done at the visit identifier level. That is, a PV1-19 - Visit Number has been found to be incorrect and has been changed.

An A50 event is used to signal a change of an incorrectly assigned visit number value. The "incorrect source visit number" value is stored in the MRG segment (MRG-5 - Prior Visit Number) and is to be changed to the "correct target visit number" value stored in the PV1 segment (PV1-19 - Visit Number).

Each superior identifier associated with this visit number identifier level, i.e. PID-3/MRG-1 and PID-18/MRG-3 should have the same value in both the PID and MRG segments.

See sections 3.5.2, "Merging patient/person information," and 3.5.2.1.4, "Change identifier," for a discussion of issues related to the implementation of change messages.

The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message.

ADT^A50^ADT_A50: ADT Message
HL7 MessageStructure Table - ADT_A50
Segment Cardinality Must Implement Status
ADT_A50
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
MRG 1..1 Yes additional
PV1 1..1 Yes additional

Original Mode Acknowledgement Choreography for ADT^A50^ADT_A50

Send Application Ack: ADT^A50^ADT_A50

Enhanced Mode Acknowledgement Choreography for ADT^A50^ADT_A50

When the MSH-15 value of an ADT^A50^ADT_A50 message is AL or ER or SU, an ACK^A50^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A50^ADT_A50 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A50^ADT_A50 message is AL or ER or SU, an ACK^A50^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A50^ADT_A50 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A50^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A50^ACK
NE, AL, ER, SU (none)

ADT/ACK - Change Alternate Visit ID (Event A51)

A change has been done at the alternate visit identifier level. That is, a PV1-50 - Alternate Visit ID has been found to be incorrect and has been changed.

An A51 event is used to signal a change of an incorrectly assigned alternate visit ID value. The "incorrect source alternate visit ID" value is stored in the MRG segment (MRG-6 - Prior Alternate Visit ID) and is to be changed to the "correct target alternate visit ID" value stored in the PV1 segment (PV1-50 - Alternate Visit ID).

Each superior identifier associated with this alternate visit identifier level, i.e. PID-3/MRG-1 and PID-18/MRG-3 should have the same value in both the PID and MRG segments.

See sections 3.5.2, "Merging patient/person information," and 3.5.2.1.4, "Change identifier," for a discussion of issues related to the implementation of change messages.

The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message.

ADT^A51^ADT_A50: ADT Message
HL7 MessageStructure Table - ADT_A50
Segment Cardinality Must Implement Status
ADT_A50
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
MRG 1..1 Yes additional
PV1 1..1 Yes additional

Original Mode Acknowledgement Choreography for ADT^A51^ADT_A50

Send Application Ack: ADT^A51^ADT_A50

Enhanced Mode Acknowledgement Choreography for ADT^A51^ADT_A50

When the MSH-15 value of an ADT^A51^ADT_A50 message is AL or ER or SU, an ACK^A51^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A51^ADT_A50 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A51^ADT_A50 message is AL or ER or SU, an ACK^A51^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A51^ADT_A50 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A51^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A51^ACK
NE, AL, ER, SU (none)

ADT/ACK- Cancel Leave of Absence for a Patient (Event A52)

The A52 event is sent when an A21 (patient goes on "leave of absence") event is cancelled, either because of erroneous entry of the A21 event or because of a decision not to put the patient on "leave of absence" after all.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

As there is no specific field for the cancel LOA date/time, it is recommended field EVN-6 - Event Occurred contain the date/time the LOA was actually cancelled (but not necessarily recorded).

ADT^A52^ADT_A52: ADT Message
HL7 MessageStructure Table - ADT_A52
Segment Cardinality Must Implement Status
ADT_A52
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A52^ADT_A52

Send Application Ack: ADT^A52^ADT_A52

Enhanced Mode Acknowledgement Choreography for ADT^A52^ADT_A52

When the MSH-15 value of an ADT^A52^ADT_A52 message is AL or ER or SU, an ACK^A52^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A52^ADT_A52 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A52^ADT_A52 message is AL or ER or SU, an ACK^A52^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A52^ADT_A52 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A52^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A52^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Patient Returns from a Leave of Absence (Event A53)

The A53 event is sent when an A22 (patient returns from "leave of absence") event is cancelled, either because of erroneous entry of the A22 event or because of a decision not to return the patient from "leave of absence" after all.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

As there is no specific field for the cancel LOA date/time, it is recommended that field EVN-6 - Event Occurred contain the date/time the return from LOA was actually cancelled (but not necessarily recorded).

PV2-47 - Expected LOA Return Date/Time is used to communicate the date/time the patient is expected to return from LOA.

ADT^A53^ADT_A52: ADT Message
HL7 MessageStructure Table - ADT_A52
Segment Cardinality Must Implement Status
ADT_A52
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A53^ADT_A52

Send Application Ack: ADT^A53^ADT_A52

Enhanced Mode Acknowledgement Choreography for ADT^A53^ADT_A52

When the MSH-15 value of an ADT^A53^ADT_A52 message is AL or ER or SU, an ACK^A53^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A53^ADT_A52 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A53^ADT_A52 message is AL or ER or SU, an ACK^A53^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A53^ADT_A52 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A53^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A53^ACK
NE, AL, ER, SU (none)

ADT/ACK - Change Attending Doctor (Event A54)

An A54 event is issued as a result of a change in the attending doctor responsible for the treatment of a patient.

When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

The new attending doctor of the patient should appear in the PV1-7 - Attending Doctor. For example, an A54 event can be used to notify the billing system that doctors' fees should be billed to the new doctor starting from the timestamp in the message.

The ROL - Role Segment was used in this message to communicate providers not specified elsewhere. As of v2.9, this has been deprecated in preference to the PRT segment as a more robust and flexible method of conveying participation. Hereafter, instructions for the PRT segment should apply, using the PRT segment. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments.

To communicate the begin and end date of the attending, referring, or admitting doctor, use the PRT-11 - Begin Date/Time and the PRT-12 - End Date/time in the PRT segment, with the applicable PRT-4 – Role of Participation. Refer to Chapter 7 for the definition of the PRT segment. Use "UP" in PRT-2 - Action Code.

ADT^A54^ADT_A54: ADT Message
HL7 MessageStructure Table - ADT_A54
Segment Cardinality Must Implement Status
ADT_A54
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
ROL 0..* B
PRT 0..* additional
PV1 1..1 Yes additional
PV2 0..1 additional
ROL 0..* B
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A54^ADT_A54

Send Application Ack: ADT^A54^ADT_A54

Enhanced Mode Acknowledgement Choreography for ADT^A54^ADT_A54

When the MSH-15 value of an ADT^A54^ADT_A54 message is AL or ER or SU, an ACK^A54^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A54^ADT_A54 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A54^ADT_A54 message is AL or ER or SU, an ACK^A54^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A54^ADT_A54 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A54^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A54^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Change Attending Doctor (Event A55)

The A55 event is sent when an A54 (change attending doctor) event is cancelled, either because of erroneous entry of the A54 event or because of a decision not to change the attending doctor after all. PV1-7 - Attending Doctor must contain the patient's doctor prior to the change of attending doctor.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

ADT^A55^ADT_A54: ADT Message
HL7 MessageStructure Table - ADT_A54
Segment Cardinality Must Implement Status
ADT_A54
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
ROL 0..* B
PRT 0..* additional
PV1 1..1 Yes additional
PV2 0..1 additional
ROL 0..* B
PRT 0..* additional

Original Mode Acknowledgement Choreography for ADT^A55^ADT_A54

Send Application Ack: ADT^A55^ADT_A54

Enhanced Mode Acknowledgement Choreography for ADT^A55^ADT_A54

When the MSH-15 value of an ADT^A55^ADT_A54 message is AL or ER or SU, an ACK^A55^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A55^ADT_A54 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A55^ADT_A54 message is AL or ER or SU, an ACK^A55^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A55^ADT_A54 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A55^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A55^ACK
NE, AL, ER, SU (none)

QBP/RSP - Get Person Demographics (QBP) and Response (RSP) (Events Q21 and K21)

This query/response is designed for interaction between a client system and an MPI (Master Person Index). The query consists of an identifier for a person, and the response of the demographics for that person.

Query Statement ID:

Q21

Query Type:

Query

Query Name:

Q21 Get Person Demographics

Query Trigger:

QBP^Q21^QBP_Q21

Query Mode:

Response Trigger:

RSP^K21^RSP_K21

Query Characteristics

Purpose:

Returns demographics information for a specified person


Field Seq.

Field Name

Key/

Search

Sort

LEN

TYPE

Opt

Rep

Match Op

TBL

Segment Field Name

LOINC or HL7 Code/Domain

ElementName

1

PersonIdentifier

S

Y

250

CX

R

N

PID-3

Patient Identifier List

2

WhatDomainsReturned

CX

O

Y

PID-3

Patient Identifier List


Input Parameter

Comp. Name

DT

Description

PersonIdentifier ()

CX

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (IS)> ^ < assigning facility (HD)

The combination of values for PersonIdentifier.ID, and PersonIdentifier.AssigningAuthority, are intended to identify a person uniquely. The PersonIdentifier.IDTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system.

Example: ...|112234^^^GOOD HEALTH HOSPITAL|...

Only one PID.3 may be specified, only 1 segment pattern will be returned.

PersonIdentifier.

ID

PID.3.1must be valued.

PersonIdentifier

Assigning Authority

PID.3.4 must be valued.

PersonIdentifier

Identifier type code

WhatDomainsReturned

CX

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (IS)> ^ < assigning facility (HD)

This parameter restricts the set of domains for which identifiers are returned in PID-3. If this is not specified, then identifiers for all known domains shall be returned. It does not restrict the search for the person.

Example: ...|^^^GOOD HEALTH HOSPITAL~^^^SOUTH LAB|...

Only the following components should be valued.

WhatDomainsReturned

Assigning Authority

PID.3.4 must be valued.

WhatDomainsReturned

Identifier type code



Following is an example of a Q21/K21 query/response pair of messages. First is the query:

MSH|^~VALUEamp;|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q21^QBP_Q21|1|D|2.5

QPD|Q21^Get Person Demographics^HL7nnn|111069|112234^^^GOOD HEALTH HOSPITAL|^^^ GOOD HEALTH HOSPITAL~^^^SOUTH LAB|

RCP|I|

This query is asking for demographics for the person identified by the identifier 112234 from the assigning authority GOOD HEALTH HOSPITAL. With the demographics, we want identifiers returned for the person from the assigning authorities GOOD HEALTH HOSPITAL and SOUTH LAB. Here is a sample response:

MSH|^~VALUEamp;|HOSPMPI|HOSP|CLINREG|WESTCLIN|199912121135-0600||RSP^K21^RSP_K21|1|D|2.5|

MSA|AA|8699|

QAK|111069|OK|Q21^Get Person Demographics^HL7nnn|1|

QPD|Q21^Get Person Demographics^HL7nnn|111069|112234^^^GOOD HEALTH HOSPITAL|^^^ GOOD HEALTH HOSPITAL~^^^SOUTH LAB|

PID|||112234^^^GOOD HEALTH HOSPITAL~98223^^^SOUTH LAB||Everyman^Adam||19600614|M||C|2101 Webster # 106^^Oakland^CA^94612|

QRI|100|

QBP^Q21^QBP_Q21: Query By Parameter
HL7 MessageStructure Table - QBP_Q21
Segment Cardinality Must Implement Status
QBP_Q21

Original Mode Acknowledgement Choreography for QBP^Q21^QBP_Q21

Send Application Ack: RSP^K21^RSP_K21

Enhanced Mode Acknowledgement Choreography for QBP^Q21^QBP_Q21

When the MSH-15 value of a QBP^Q21^QBP_Q21 message is AL or ER or SU, an ACK^Q21^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^Q21^QBP_Q21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^Q21^QBP_Q21 message is AL or ER or SU, a RSP^K21^RSP_K21 message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^Q21^QBP_Q21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^Q21^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: RSP^K21^RSP_K21
NE, AL, ER, SU (none)

RSP^K21^RSP_K21: Segment Pattern Response
HL7 MessageStructure Table - RSP_K21
Segment Cardinality Must Implement Status
RSP_K21
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
MSA 1..1 Yes additional
ERR 0..1 additional
QAK 1..1 Yes additional
QPD 1..1 Yes additional
QUERY_RESPONSE 0..1 additional
PID 1..1 Yes additional
PD1 0..1 additional
ARV 0..* B
NK1 0..* additional
QRI 1..1 Yes additional
DSC 0..1 additional

Original Mode Acknowledgement Choreography for RSP^K21^RSP_K21

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RSP^K21^RSP_K21

When the MSH-15 value of a RSP^K21^RSP_K21 message is AL or ER or SU, an ACK^K21^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a RSP^K21^RSP_K21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RSP^K21^RSP_K21 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RSP^K21^RSP_K21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^K21^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

QBP/RSP - Find Candidates (QBP) and Response (RSP) (Events Q22 and K22)

This query/response is designed for interaction between a client system and an MPI (Master Person Index). The query consists of a set of demographics for a person, and the response is the list of candidates considered by the MPI to match that set.

Each returned person, specified by a PID segment, can also have an optional QRI - Query Response Instance segment containing information about the quality of the match.

Query Statement ID:

Q22

Query Type:

Query

Query Name:

Q22 Find Candidates

Query Trigger:

QBP^Q22^QBP_Q21

Query Mode:

Response Trigger:

RSP^K22^RSP_K22

Query Characteristics

Purpose:

Returns list of candidates matching demographic data specified by the input parameters.


Field Seq.

Field Name

Key/

Search

Sort

LEN

TYPE

Opt

Rep

Match Op

TBL

Segment Field Name

LOINC or HL7 Code/Domain

ElementName

1

DemographicsFields

QIP

R

Y

2

SearchConfidenceThreshold

NM

O

N

3

AlgorithmName

ST

O

N

4

AlgorithmVersion

ST

O

N

5

AlgorithmDescription

ST

O

N

6

WhatDomainsReturned

CX

O

Y

PID-3

Patient Identifier List


Input Parameter

Comp. Name

DT

Description

DemographicsFields

QIP

Components: <segment field name (ST)> ^ <value1 (ST) & value2 (ST) & value3 (ST...>

Components may be any fields in the PID or PD1. If subcomponents of fields need to be specified, each subcomponent should be listed separately.

Example: ...|@PID.5.1^EVERYMAN~@PID.5.2^ADAM~@PID.8^M|...

SearchConfidenceThreshold

NM

Indicates the minimum match confidence for candidates to be returned for the query. The value instructs the queried system to return no records (PID segments) for persons whose "match weight" on the lookup was lower than the user-defined value.

Example: |80|

AlgorithmName

ST

Identifies the specific algorithm the queried system should use.

Example: |MATCHWARE|

AlgorithmVersion

ST

Identifies the specific algorithm version the queried system should use.

Example: |1.2|

AlgorithmDescription

ST

Description of the algorithm the queried system should use.

WhatDomainsReturned

CX

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (IS)> ^ < assigning facility (HD)

This parameter restricts the set of domains for which identifiers are returned in PID-3. If this is not specified, then identifiers for all known domains shall be returned. It does not restrict the search for persons.

Example: ...|^^^GOOD HEALTH HOSPITAL~^^^SOUTH LAB|...

Only the following components should be valued.

WhatDomainsReturned

Assigning Authority

PID.3.4 must be valued.

WhatDomainsReturned

Identifier type code



Following is an example of a Q22/K22 query/response pair of messages. First is the query:

MSH|^~VALUEamp;|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q22^QBP_Q21|1|D|2.5

QPD|Q22^Find Candidates^HL7nnn|111069|@PID.5.1^EVERYMAN~@PID.5.2^ADAM~ @PID.8^M|80|MATCHWARE|1.2||^^^GOOD HEALTH HOSPITAL~^^^SOUTH LAB|

RCP|I|20^RD

This query is asking for a list of persons matching the name ADAM EVERYMAN with the gender Male. Candidates with a match level above 80 using the algorithm Matchware version 1.2 should be returned. The returned records should include identifiers for both the assigning authorities GOOD HEALTH HOSPITAL and SOUTH LAB. The RCP segment specifies that the number of matches should be limited to 20. Here is a sample response:

MSH|^~VALUEamp;|HOSPMPI|HOSP|CLINREG|WESTCLIN|200712121135-0600||RSP^K22^RSP_K22|1|D|2.5.1|

MSA|AA|8699|

QAK|111069|OK|Q22^Find Candidates^HL7nnnn|3|

QPD|Q22^Find Candidates^HL7nnn|111069|@PID.5.1^EVERYMAN~ @PID.5.2^ADAM~@PID.8^M|80|MATCHWARE|1.2||^^^GOOD HEALTH HOSPITAL~^^^SOUTH LAB|

PID|||66785^^^GOOD HEALTH HOSPITAL~99999^^^SOUTH LAB||Everyman^Adam||19630423|M||C|C^^Madison^WI^99999|

QRI|95||MATCHWARE 1.2|

PID|||87443^^^GOOD HEALTH HOSPITAL~651189^^^SOUTH LAB||Everyman^Adam||19470606|M||C|555-555-2004^^Madison^WI^99999|

QRI|90||MATCHWARE 1.2|

PID|||43266^^^GOOD HEALTH HOSPITAL~81209^^^SOUTH LAB||Everyman^Adam||19901210|M||C|4444 Home Street^^Lodi^WI^99999|

QRI|85||MATCHWARE 1.2|

Three candidates were returned. Notice the 3 at the end of the QAK segment signifying the number of matches. Each has a PID and QRI segment, and the QRI segment in each case gives a confidence factor for each of the candidates

QBP^Q22^QBP_Q21: Query By Parameter
HL7 MessageStructure Table - QBP_Q21
Segment Cardinality Must Implement Status
QBP_Q21

Original Mode Acknowledgement Choreography for QBP^Q22^QBP_Q21

Send Application Ack: RSP^K22^RSP_K22

Enhanced Mode Acknowledgement Choreography for QBP^Q22^QBP_Q21

When the MSH-15 value of a QBP^Q22^QBP_Q21 message is AL or ER or SU, an ACK^Q22^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^Q22^QBP_Q21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^Q22^QBP_Q21 message is AL or ER or SU, a RSP^K22^RSP_K22 message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^Q22^QBP_Q21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^Q22^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: RSP^K22^RSP_K22
NE, AL, ER, SU (none)

RSP^K22^RSP_K22: Segment Pattern Response
HL7 MessageStructure Table - RSP_K22
Segment Cardinality Must Implement Status
RSP_K22
MSH 1..1 Yes additional
SFT 0..* additional
UAC 0..1 additional
MSA 1..1 Yes additional
ERR 0..1 additional
QAK 1..1 Yes additional
QPD 1..1 Yes additional
QUERY_RESPONSE 0..* additional
PID 1..1 Yes additional
PD1 0..1 additional
NK1 0..* additional
QRI 0..1 additional
DSC 0..1 additional

Original Mode Acknowledgement Choreography for RSP^K22^RSP_K22

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RSP^K22^RSP_K22

When the MSH-15 value of a RSP^K22^RSP_K22 message is AL or ER or SU, an ACK^K22^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a RSP^K22^RSP_K22 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RSP^K22^RSP_K22 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RSP^K22^RSP_K22 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^K22^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

QBP/RSP - Get Corresponding Identifiers (QBP) and Response (RSP) (Events Q23 and K23)

This query/response is designed for interaction between a client system and an MPI (Master Person Index). The query consists of an identifier for a person, and the response is a list of identifiers for that person from the domains specified.

Query Statement ID:

Q23

Query Type:

Query

Query Name:

Q23 Get Corresponding Identifiers

Query Trigger:

QBP^Q23^QBP_Q21

Query Mode:

Response Trigger:

RSP^K23^RSP_K23

Query Characteristics

Purpose:

Returns list of identifiers from the specified domains, given an identifier from a given domain.


Field Seq.

Field Name

Key/

Search

Sort

LEN

TYPE

Opt

Rep

Match Op

TBL

Segment Field Name

LOINC or HL7 Code/Domain

Element Name

1

PersonIdentifier

S

Y

20

CX

R

N

PID-3

Patient Identifier List

2

WhatDomainsReturned

CX

O

Y

PID-3

Patient Identifier List


Input Parameter

Comp. Name

DT

Description

PersonIdentifier

CX

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (IS)> ^ < assigning facility (HD)

The combination of values for PersonIdentifier.ID, and PersonIdentifier.AssigningAuthority, are intended to identify a person uniquely. The PersonIdentifier.IDTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system.

Example: ...|112234^^^GOOD HEALTH HOSPITAL|...

Only one PID.3 may be specified, only 1 segment pattern will be returned.

PersonIdentifier

ID

PID.3.1must be valued.

PersonIdentifier

Assigning Authority

PID.3.4 must be valued.

PersonIdentifier

Identifier type code

WhatDomainsReturned

CX

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (IS)> ^ < assigning facility (HD)

This parameter restricts the set of domains for which identifiers are returned in PID-3. If this is not specified, then identifiers for all known domains shall be returned. It does not restrict the search for the person.

Example: |^^^GOOD HEALTH HOSPITAL~^^^SOUTH LAB|

Only the following components should be valued.

WhatDomainsReturned

Assigning Authority

PID.3.4 must be valued.

WhatDomainsReturned.

Identifier type code



Following is an example of a Q23/K23 query/response pair of messages. First is the query:

MSH|^~VALUEamp;|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q23^QBP_Q21|1|D|2.5

QPD|Q23^Get Corresponding IDs^HL7nnnn|111069|112234^^^GOOD HEALTH HOSPITAL|^^^WEST CLINIC~^^^SOUTH LAB|

RCP||I|

This query is asking for identifiers from WEST CLINIC and SOUTH LAB for the person identified with the identifier 112234 from the assigning authority GOOD HEALTH HOSPITAL. Here is a sample response:

MSH|^~VALUEamp;|HOSPMPI|HOSP|CLINREG|WESTCLIN|199912121135-0600||RSP^K23^RSP_K23|1|D|2.5|

MSA|AA|8699|

QAK|111069|OK|Q23^Get Corresponding IDs^HL7nnnn|1|

QPD|Q23^Get Corresponding IDs^HL7nnn|111069|112234^^^GOOD HEALTH HOSPITAL|^^^WEST CLINIC~^^^SOUTH LAB|

PID|||56321A^^^WEST CLINIC~66532^^^SOUTH LAB||EVERYMAN^ADAM||19630423|M||C|N2378 South Street^^Madison^WI^53711|

Note: that the identifiers returned do not include the GOOD HEALTH HOSPITAL identifier, as it was not specified in the list of WhatDomainsReturned.

QBP^Q23^QBP_Q21: Query By Parameter
HL7 MessageStructure Table - QBP_Q21
Segment Cardinality Must Implement Status
QBP_Q21

Original Mode Acknowledgement Choreography for QBP^Q23^QBP_Q21

Send Application Ack: RSP^K23^RSP_K23

Enhanced Mode Acknowledgement Choreography for QBP^Q23^QBP_Q21

When the MSH-15 value of a QBP^Q23^QBP_Q21 message is AL or ER or SU, an ACK^Q23^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^Q23^QBP_Q21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^Q23^QBP_Q21 message is AL or ER or SU, a RSP^K23^RSP_K23 message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^Q23^QBP_Q21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^Q23^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: RSP^K23^RSP_K23
NE, AL, ER, SU (none)

RSP^K23^RSP_K23: Segment Pattern Response
HL7 MessageStructure Table - RSP_K23
Segment Cardinality Must Implement Status
RSP_K23
MSH 1..1 Yes additional
SFT 0..* additional
UAC 0..1 additional
MSA 1..1 Yes additional
ERR 0..1 additional
QAK 1..1 Yes additional
QPD 1..1 Yes additional
QUERY_RESPONSE 0..1 additional
PID 1..1 Yes additional
DSC 0..1 additional

Original Mode Acknowledgement Choreography for RSP^K23^RSP_K23

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RSP^K23^RSP_K23

When the MSH-15 value of a RSP^K23^RSP_K23 message is AL or ER or SU, an ACK^K23^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a RSP^K23^RSP_K23 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RSP^K23^RSP_K23 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RSP^K23^RSP_K23 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^K23^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

QBP/RSP - Allocate Identifiers (QBP) and Response (RSP) (Events Q24 and K24)

This query/response is designed for interaction between a client system and an MPI (Master Person Index). The query consists of domains in which identifiers should be allocated. The response is new identifiers in those domains.

This event is not meant to cause the creation of a new person record, or to bind identifiers to a particular person record. The events A28 - Add person information and A24 - Link patient information should be used for that purpose. This event is meant to simply reserve the use of identifiers.

Query Statement ID:

Q24

Query Type:

Query

Query Name:

Allocate Identifiers

Query Trigger:

QBP^Q24^QBP_Q21

Query Mode:

Response Trigger:

RSP^K24^RSP_K23

Query Characteristics

Purpose:

Request that an MPI allocate an identifier for a given domain.


Field Seq.

Field Name

Key/

Search

Sort

LEN

TYPE

Opt

Rep

Match Op

TBL

Segment Field Name

LOINC or HL7 Code/Domain

Element Name

1

DomainToAllocateIn

CX

R

Y

PID-3

Patient Identifier



Input Parameter

Comp. Name

DT

Description

DomainToAllocateIn ()

CX

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (IS)> ^ < assigning facility (HD)

This parameter specifies in which domains to allocate identifiers.

Example: ...|^^^GOOD HEALTH HOSPITAL|...

Only the following components should be valued.

DomainToAllocateIn

Assigning Authority

PID.3.4 must be valued.

DomainToAllocateIn

Identifier type code



Following is an example of a Q24/K24 query/response pair of messages. First is the query:

MSH|^~VALUEamp;|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q24^QBP_Q21|1|D|2.5

QPD|Q24^Allocate Identifiers^HL7nnnn|111069|^^^WEST CLINIC~^^^SOUTH LAB|

RCP||I|

This query is asking for identifiers from WEST CLINIC and SOUTH LAB to be reserved and returned. Here is a sample response:

MSH|^~VALUEamp;|HOSPMPI|HOSP|CLINREG|WESTCLIN|199912121135-0600||RSP^K24^RSP_K23|1|D|2.5|

MSA|AA|8699|

QAK|111069|OK|Q24^Allocate Identifiers^HL7nnnn|1|

QPD|A56^Allocate Identifiers^HL7nnn|111069|^^^WEST CLINIC~^^^SOUTH LAB|

PID|||624335A^^^WEST CLINIC~564325^^^SOUTH LAB|

Note: The PID segment returned does not include any person demographics as the identifiers are not yet "attached" to any person record. Presumably the querying system would eventually send back to the MPI an A28 Add person information to create a person record for the identifiers or an A24 Link patient information to link the identifiers to an existing person record.

QBP^Q24^QBP_Q21: Query By Parameter
HL7 MessageStructure Table - QBP_Q21
Segment Cardinality Must Implement Status
QBP_Q21

Original Mode Acknowledgement Choreography for QBP^Q24^QBP_Q21

Send Application Ack: RSP^K24^RSP_K23

Enhanced Mode Acknowledgement Choreography for QBP^Q24^QBP_Q21

When the MSH-15 value of a QBP^Q24^QBP_Q21 message is AL or ER or SU, an ACK^Q24^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^Q24^QBP_Q21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^Q24^QBP_Q21 message is AL or ER or SU, a RSP^K24^RSP_K23 message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^Q24^QBP_Q21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^Q24^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: RSP^K24^RSP_K23
NE, AL, ER, SU (none)

RSP^K24^RSP_K23: Segment Pattern Response
HL7 MessageStructure Table - RSP_K23
Segment Cardinality Must Implement Status
RSP_K23
MSH 1..1 Yes additional
SFT 0..* additional
UAC 0..1 additional
MSA 1..1 Yes additional
ERR 0..1 additional
QAK 1..1 Yes additional
QPD 1..1 Yes additional
QUERY_RESPONSE 0..1 additional
PID 1..1 Yes additional
DSC 0..1 additional

Original Mode Acknowledgement Choreography for RSP^K24^RSP_K23

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RSP^K24^RSP_K23

When the MSH-15 value of a RSP^K24^RSP_K23 message is AL or ER or SU, an ACK^K24^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a RSP^K24^RSP_K23 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RSP^K24^RSP_K23 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RSP^K24^RSP_K23 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^K24^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

ADT/ACK - Update Adverse Reaction Information (Event A60)

This trigger event is used when person/patient allergy information has changed. It is used in conjunction with a new allergy segment, the IAM - Patient Allergy Information Segment-Unique Identifier, which supports Action code/unique identifier mode update for repeating segments as defined in 2.10.4, "Protocol for interpreting repeating segments or segment groups in an update Message."

ADT^A60^ADT_A60: ADT Message
HL7 MessageStructure Table - ADT_A60
Segment Cardinality Must Implement Status
ADT_A60
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
ARV 0..* B
VISIT_GROUP 0..1 additional
PV1 1..1 Yes additional
PV2 0..1 additional
ARV 0..* B
ADVERSE_REACTION_GROUP 0..* additional
IAM 1..1 Yes additional
NTE 0..* additional
IAR 0..* additional

Original Mode Acknowledgement Choreography for ADT^A60^ADT_A60

Send Application Ack: ADT^A60^ADT_A60

Enhanced Mode Acknowledgement Choreography for ADT^A60^ADT_A60

When the MSH-15 value of an ADT^A60^ADT_A60 message is AL or ER or SU, an ACK^A60^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A60^ADT_A60 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A60^ADT_A60 message is AL or ER or SU, an ACK^A60^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A60^ADT_A60 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A60^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A60^ACK
NE, AL, ER, SU (none)

ADT/ACK - Change Consulting Doctor (Event A61)

An A61 event is used as a result of a change in the consulting physician(s) for the treatment of a patient.

When other important fields change, it is recommended that the A08 (update patient information) event be used in addition. If the Patient Administration system allows demographics to change at the same time (for example an address change), two messages (an A61 followed by an A08) should be sent.

The new consulting doctor(s) of the patient should appear in the PV1-9 - Consulting Doctor and may appear in a role segment per new consulting physician.

If a consulting doctor stops being consulting doctor for this patient-visit, the end date/time can be sent in the PRT-12 - End Date/Time.

For example, an A61 event can be used to notify the billing system that doctors' fees for being a consulting doctor, should be billed to the new doctor(s) starting from the timestamp in the message.

It is recommended that field EVN-6 - Event Occurred contains the date/time the event actually occurred to the patient.

The ROL segment has been deprecated and retained for backwards compatiblity purposes only as of v 2.9. The reader is referred to the PRT segment instead.

The PRT – Participation Information Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the PRT segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the PRT segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the PRT segment following the PR1 segment. Providers related to a specific insurance are reported in the PRT segment following the IN1/IN2/IN3 segments. To communicate the begin- and end-date of the provider, use the PRT-11 - Participation Begin Date/Time and the PRT-12 - Participation End Date/Time in the PRT segment, with the applicable PRT-4 - PArticipation. Refer to Chapter 7 for the definition of the PRT segment.

ADT^A61^ADT_A61: ADT Message
HL7 MessageStructure Table - ADT_A61
Segment Cardinality Must Implement Status
ADT_A61
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
ROL 0..* B
PRT 0..* additional
PV1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
PV2 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A61^ADT_A61

Send Application Ack: ADT^A61^ADT_A61

Enhanced Mode Acknowledgement Choreography for ADT^A61^ADT_A61

When the MSH-15 value of an ADT^A61^ADT_A61 message is AL or ER or SU, an ACK^A61^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A61^ADT_A61 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A61^ADT_A61 message is AL or ER or SU, an ACK^A61^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A61^ADT_A61 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A61^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A61^ACK
NE, AL, ER, SU (none)

ADT/ACK - Cancel Change Consulting Doctor (Event A62)

The A62 event is sent when an A61 (change consulting doctor) event is cancelled, either because of erroneous entry of the A61 event or because of a decision not to change the consulting physician(s) after all. PV1-9 - Consulting Doctor must show the patient's doctor prior to the change being cancelled.

The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event is used.

ADT^A62^ADT_A61: ADT Message
HL7 MessageStructure Table - ADT_A61
Segment Cardinality Must Implement Status
ADT_A61
MSH 1..1 Yes additional
ARV 0..* additional
SFT 0..* additional
UAC 0..1 additional
EVN 1..1 Yes additional
PID 1..1 Yes additional
PD1 0..1 additional
ROL 0..* B
PRT 0..* additional
PV1 1..1 Yes additional
ROL 0..* B
PRT 0..* additional
PV2 0..1 additional

Original Mode Acknowledgement Choreography for ADT^A62^ADT_A61

Send Application Ack: ADT^A62^ADT_A61

Enhanced Mode Acknowledgement Choreography for ADT^A62^ADT_A61

When the MSH-15 value of an ADT^A62^ADT_A61 message is AL or ER or SU, an ACK^A62^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ADT^A62^ADT_A61 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ADT^A62^ADT_A61 message is AL or ER or SU, an ACK^A62^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ADT^A62^ADT_A61 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^A62^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^A62^ACK
NE, AL, ER, SU (none)

QBP/RSP - Find Candidates including Visit Information (QBP) and Response (RSP) (Events Q32 and K32 )

This query/response is designed for interaction between a client system and an MPI (Master Person Index). The query consists of a set of demographic and/or visit attribute values for a person, and the response is the list of candidates considered by the MPI to match that set.

Each returned person, specified by a PID segment and by a PV1 segment containing information about the current visit, can also have an optional QRI - Query Response Instance segment containing information about the quality of the match.

Query Statement ID:

Q32

Query Type:

Query

Query Name:

Q32 Find Candidates with Visit Information

Query Trigger:

QBP^Q32^QBP_Q21

Query Mode:

Response Trigger:

RSP^K32^RSP_K25

Query Characteristics

Purpose:

Returns list of candidates matching demographic and/or visit data specified by the input parameters.


Field Seq.

Field Name

Key/

Search

Sort

LEN

TYPE

Opt

Rep

Match Op

TBL

Segment Field Name

LOINC or HL7 Code/Domain

ElementName

1

Demographics / Visit Fields

QIP

R

Y

2

SearchConfidenceThreshold

NM

O

N

3

AlgorithmName

ST

O

N

4

AlgorithmVersion

ST

O

N

5

AlgorithmDescription

ST

O

N

6

WhatDomainsReturned

CX

O

Y

PID-3

Patient Identifier List


Input Parameter

Comp. Name

DT

Description

Demographics/VisitFields

QIP

Components: <segment field name (ST)> ^ <value1 (ST) & value2 (ST) & value3 (ST...>

Components may be any fields in the PID, PD1, PV1 and/or PV2. If subcomponents of fields need to be specified, each subcomponent should be listed separately.

Example: ...|@PID.5.1^SMITH~@PV1.3.2^389~...

SearchConfidenceThreshold

NM

Indicates the minimum match confidence for candidates to be returned for the query. The value instructs the queried system to return no records (PID segments) for persons whose “match weight” on the lookup was lower than the user-defined value.

Example: |80|

AlgorithmName

ST

Identifies the specific algorithm the queried system should use.

Example: |MATCHWARE|

AlgorithmVersion

ST

Identifies the specific algorithm version the queried system should use.

Example: |1.2|

AlgorithmDescription

ST

Description of the algorithm the queried system should use.

WhatDomainsReturned

CX

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (IS)> ^ < assigning facility (HD)

This parameter restricts the set of domains for which identifiers are returned in PID-3. If this is not specified, then identifiers for all known domains shall be returned. It does not restrict the search for persons.

Example: ...|^^^METRO HOSPITAL~^^^SOUTH LAB|...

Only the following components should be valued.

WhatDomainsReturned

Assigning Authority

PID.3.4 must be valued.

WhatDomainsReturned

Identifier type code



Following is an example of a Q25/K25 query/response pair of messages. First is the query:

MSH|^&~\|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q25^QBP_Q21|8702|D|2.6

QPD|Q25^Find Candidates Including Visit Information^HL70471|111069|@PID.5.1^SMITH~@PV1.3.2^389 |80|MATCHWARE|1.2||^^^METRO HOSPITAL

RCP||I|20^RD

This query is asking for a list of persons matching the name SMITH who are recorded as being in Room 389. Candidates with a match level above 80 using the algorithm Matchware version 1.2 should be returned. The returned records should include identifiers for assigning authority METRO HOSPITAL. The RCP segment specifies that the number of matches should be limited to 20. Here is a sample response:

MSH|^&~\|HOSPMPI|HOSP|CLINREG|WESTCLIN|200412121135-0600||RSP^K25^RSP_K25|H352357509|D|2.6

MSA|AA|8702

QAK|111069|OK|Q25^Find Candidates Including Visit Information^HL70471|1

QPD|Q25^Find Candidates Including Visit Information^HL70471|111069|@PID.5.1^SMITH~ @PID.5.2^JOHN~@PID.8^M|80|MATCHWARE|1.2||^^^METRO HOSPITAL

PID|||66785^^^METRO HOSPITAL||Smith^John||19630423|M||C|N2378 South Street^^Madison^WI^53711

PV1||I|W^389^1^METRO HOSPITAL^^^^3||||12345^MORGAN^REX^J^^^MD^0010^METRO HOSPITAL^L||67890^GRAINGER^LUCY^X^^^MD^0010^METRO HOSPITAL^L|MED|||||A0||13579^POTTER^SHERMAN^T^^^MD^0010^METRO HOSPITAL^L

QRI|95||MATCHWARE 1.2

One candidate was returned. Notice the 1 at the end of the QAK segment signifying the number of matches. The group of segments includes a PID, PV1, and QRI segment; the QRI segment gives a confidence factor for the candidate.

QBP^Q32^QBP_Q21: Query By Parameter
HL7 MessageStructure Table - QBP_Q21
Segment Cardinality Must Implement Status
QBP_Q21

Original Mode Acknowledgement Choreography for QBP^Q32^QBP_Q21

Send Application Ack: RSP^K32^RSP_K32

Enhanced Mode Acknowledgement Choreography for QBP^Q32^QBP_Q21

When the MSH-15 value of a QBP^Q32^QBP_Q21 message is AL or ER or SU, an ACK^Q32^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^Q32^QBP_Q21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^Q32^QBP_Q21 message is AL or ER or SU, a RSP^K32^RSP_K32 message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^Q32^QBP_Q21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^Q32^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: RSP^K32^RSP_K32
NE, AL, ER, SU (none)

RSP^K32^RSP_K32: Segment Pattern Response
HL7 MessageStructure Table - RSP_K32
Segment Cardinality Must Implement Status
RSP_K32
MSH 1..1 Yes additional
SFT 0..* additional
MSA 1..1 Yes additional
ERR 0..1 additional
QAK 1..1 Yes additional
QPD 1..1 Yes additional
QUERY_RESPONSE 0..* additional
PID 1..1 Yes additional
PD1 0..1 additional
NK1 0..* additional
PV1 1..1 Yes additional
PV2 0..1 additional
QRI 0..1 additional
DSC 0..1

Original Mode Acknowledgement Choreography for RSP^K32^RSP_K32

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RSP^K32^RSP_K32

When the MSH-15 value of a RSP^K32^RSP_K32 message is AL or ER or SU, an ACK^K32^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a RSP^K32^RSP_K32 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RSP^K32^RSP_K32 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RSP^K32^RSP_K32 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^K32^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (none)

MESSAGE SEGMENTS

EVN - Event Type Segment

The EVN segment is used to communicate necessary trigger event information to receiving applications. Valid event types for all chapters are contained in HL7 Table 0003 - Event Type.

HL7 Attribute Table - EVN - Event Type Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
EVN
1 Event Type Code W
[0..1] 00099
2 Recorded Date/Time DTM R
[1..1] 00100
3 Date/Time Planned Event DTM O
[0..1] 00101
4 Event Reason Code CWE O
0062 Event Reason
[0..1] 00102
5 Operator ID XCN O
0188 Operator ID
[0..*] 00103
6 Event Occurred DTM O
[0..1] 01278
7 Event Facility HD O
[0..1] 01534

EVN-1: Event Type Code () 00099

FIXME

EVN-2: Recorded Date/Time (DTM) 00100

FIXME

EVN-3: Date/Time Planned Event (DTM) 00101

FIXME

EVN-4: Event Reason Code (CWE) 00102

FIXME

EVN-5: Operator ID (XCN) 00103

FIXME

EVN-6: Event Occurred (DTM) 01278

FIXME

EVN-7: Event Facility (HD) 01534

FIXME

PID - Patient Identification Segment

The PID segment is used by all applications as the primary means of communicating patient identification information. This segment contains permanent patient identifying and demographic information that, for the most part, is not likely to change frequently.

It should be noted that from V2.4 onwards the demographics of animals can also be sent in the PID segment (see PID-35 to PID-38).

The assigning authority, the fourth component of the patient identifiers, is a HD data type that is uniquely associated with the assigning authority that originally assigned the number. A given institution, or group of intercommunicating institutions, should establish a list of assigning authorities that may be potential assignors of patient identification (and other important identification) numbers. The list will be one of the institution's master dictionary lists. Since third parties (other than the assignors of patient identification numbers) may send or receive HL7 messages containing patient identification numbers, the assigning authority in the patient identification numbers may not be the same as the sending and receiving systems identified in the MSH. The assigning authority must be unique across applications at a given site. This field is required in HL7 implementations that have more than a single Patient Administration application assigning such numbers. The assigning authority and identifier type codes are strongly recommended for all CX data types.

With HL7 V2.3, the nomenclature for the fourth component of the patient identifiers was changed from "assigning facility ID" to "assigning authority". While the identifier may be unique to a given healthcare facility (for example, a medical record assigned by facility A in Hospital XYZ), the identifier might also be assigned at a system level (for example a corporate person index or enterprise number spanning multiple facilities) or by a government entity, for example a nationally assigned unique individual identifier. While a facility is usually an assigning authority, not all assigning authorities are facilities. Therefore, the fourth component is referred to as an assigning authority, but retains backward compatibility using the construct of the HD data type (see the note in chapter 2). Additionally, CX data types support the use of assigning facility (HD) as the sixth component.

HL7 Attribute Table - PID - Patient Identification Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PID
1 Set ID - PID SI O
[0..1] 00104 [1..4]
2 Patient ID W
[0..1] 00105
3 Patient Identifier List CX R
[1..*] 00106
4 Alternate Patient ID - PID W
[0..1] 00107
5 Patient Name XPN R
0200(R) Name Type(Required)
[1..*] 00108
6 Mother's Maiden Name XPN O
[0..*] 00109
7 Date/Time of Birth DTM O
[0..1] 00110
8 Administrative Sex CWE O
0001(S) Administrative Sex(Suggested)
[0..1] 00111
9 Patient Alias W
[0..1] 00112
10 Race CWE O
0005(S) Race(Suggested)
[0..*] 00113
11 Patient Address XAD O
[0..*] 00114
12 County Code W
[0..1] 00115
13 Phone Number - Home XTN W
[0..0] 00116
14 Phone Number - Business XTN W
[0..0] 00117
15 Primary Language CWE O
0296 Primary Language
[0..1] 00118
16 Marital Status CWE O
0002(S) Marital Status(Suggested)
[0..1] 00119
17 Religion CWE O
0006(S) Religion(Suggested)
[0..1] 00120
18 Patient Account Number CX O
0061(R) Check Digit Scheme(Required)
[0..1] 00121
19 SSN Number - Patient W
[0..1] 00122
20 Driver's License Number - Patient W
[0..1] 00123
21 Mother's Identifier CX O
0061(R) Check Digit Scheme(Required)
[0..*] 00124
22 Ethnic Group CWE O
0189 Ethnic Group
[0..*] 00125
23 Birth Place ST O
[0..1] 00126 250 #
24 Multiple Birth Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00127 [1..1]
25 Birth Order NM O
[0..1] 00128 2 #
26 Citizenship CWE O
0171 Citizenship
[0..*] 00129
27 Veterans Military Status CWE O
0172 Veterans Military Status
[0..1] 00130
28 Nationality CWE W
0212 Nationality
[0..1] 00739
29 Patient Death Date and Time DTM O
[0..1] 00740
30 Patient Death Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00741 [1..1]
31 Identity Unknown Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 01535 [1..1]
32 Identity Reliability Code CWE O
0445 Identity Reliability Code
[0..*] 01536
33 Last Update Date/Time DTM O
[0..1] 01537
34 Last Update Facility HD O
[0..1] 01538
35 Taxonomic Classification Code CWE O
0446 Species Code
[0..1] 01539
36 Breed Code CWE B
0447 Breed Code
[0..1] 01540
37 Strain ST O
[0..1] 01541 80 #
38 Production Class Code CWE O
0429(S) Production Class Code(Suggested)
[0..2] 01542
39 Tribal Citizenship CWE O
0171 Citizenship
[0..*] 01840
40 Patient Telecommunication Information XTN O
[0..*] 02289

PID-1: Set ID - PID (SI) 00104

FIXME

PID-2: Patient ID () 00105

FIXME

PID-3: Patient Identifier List (CX) 00106

FIXME

PID-4: Alternate Patient ID - PID () 00107

FIXME

PID-5: Patient Name (XPN) 00108

FIXME

PID-6: Mother's Maiden Name (XPN) 00109

FIXME

PID-7: Date/Time of Birth (DTM) 00110

FIXME

PID-8: Administrative Sex (CWE) 00111

FIXME

PID-9: Patient Alias () 00112

FIXME

PID-10: Race (CWE) 00113

FIXME

PID-11: Patient Address (XAD) 00114

FIXME

PID-12: County Code () 00115

FIXME

PID-13: Phone Number - Home (XTN) 00116

FIXME

PID-14: Phone Number - Business (XTN) 00117

FIXME

PID-15: Primary Language (CWE) 00118

FIXME

PID-16: Marital Status (CWE) 00119

FIXME

PID-17: Religion (CWE) 00120

FIXME

PID-18: Patient Account Number (CX) 00121

FIXME

PID-19: SSN Number - Patient () 00122

FIXME

PID-20: Driver's License Number - Patient () 00123

FIXME

PID-21: Mother's Identifier (CX) 00124

FIXME

PID-22: Ethnic Group (CWE) 00125

FIXME

PID-23: Birth Place (ST) 00126

FIXME

PID-24: Multiple Birth Indicator (ID) 00127

FIXME

PID-25: Birth Order (NM) 00128

FIXME

PID-26: Citizenship (CWE) 00129

FIXME

PID-27: Veterans Military Status (CWE) 00130

FIXME

PID-28: Nationality (CWE) 00739

FIXME

PID-29: Patient Death Date and Time (DTM) 00740

FIXME

PID-30: Patient Death Indicator (ID) 00741

FIXME

PID-31: Identity Unknown Indicator (ID) 01535

FIXME

PID-32: Identity Reliability Code (CWE) 01536

FIXME

PID-33: Last Update Date/Time (DTM) 01537

FIXME

PID-34: Last Update Facility (HD) 01538

FIXME

PID-35: Taxonomic Classification Code (CWE) 01539

FIXME

PID-36: Breed Code (CWE) 01540

FIXME

PID-37: Strain (ST) 01541

FIXME

PID-38: Production Class Code (CWE) 01542

FIXME

PID-39: Tribal Citizenship (CWE) 01840

FIXME

PID-40: Patient Telecommunication Information (XTN) 02289

FIXME

PV1 - Patient Visit Segment

The PV1 segment is used by Registration/Patient Administration applications to communicate information on an account or visit-specific basis. The default is to send account level data. To use this segment for visit level data PV1-51 - Visit Indicator must be valued to "V". The value of PV-51 affects the level of data being sent on the PV1, PV2, and any other segments that are part of the associated PV1 hierarchy (e.g., ROL, DG1, or OBX).

The facility ID, the optional fourth component of each patient location field, is a HD data type that is uniquely associated with the healthcare facility containing the location. A given institution, or group of intercommunicating institutions, should establish a list of facilities that may be potential assignors of patient locations. The list will be one of the institution's master dictionary lists. Since third parties other than the assignors of patient locations may send or receive HL7 messages containing patient locations, the facility ID in the patient location may not be the same as that implied by the sending and receiving systems identified in the MSH. The facility ID must be unique across facilities at a given site. This field is required for HL7 implementations that have more than a single healthcare facility with bed locations, since the same <point of care> ^ <room> ^ <bed> combination may exist at more than one facility.

HL7 Attribute Table - PV1 - Patient Visit Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PV1
1 Set ID - PV1 SI O
[0..1] 00131 [1..4]
2 Patient Class CWE R
0004 Patient Class
[1..1] 00132
3 Assigned Patient Location PL O
[0..1] 00133
4 Admission Type CWE O
0007 Admission Type
[0..1] 00134
5 Preadmit Number CX O
[0..1] 00135
6 Prior Patient Location PL O
[0..1] 00136
7 Attending Doctor XCN O
0010 Physician ID
[0..*] 00137
8 Referring Doctor XCN O
0010 Physician ID
[0..*] 00138
9 Consulting Doctor XCN B
[0..*] 00139
10 Hospital Service CWE O
0069 Hospital Service
[0..1] 00140
11 Temporary Location PL O
[0..1] 00141
12 Preadmit Test Indicator CWE O
0087 Pre-Admit Test Indicator
[0..1] 00142
13 Re-admission Indicator CWE O
0092(S) Re-Admission Indicator(Suggested)
[0..1] 00143
14 Admit Source CWE O
0023 Admit Source
[0..1] 00144
15 Ambulatory Status CWE O
0009(S) Ambulatory Status(Suggested)
[0..*] 00145
16 VIP Indicator CWE O
0099 VIP Indicator
[0..1] 00146
17 Admitting Doctor XCN O
0010 Physician ID
[0..*] 00147
18 Patient Type CWE O
0018 Patient Type
[0..1] 00148
19 Visit Number CX O
[0..1] 00149
20 Financial Class FC O
0064 Financial Class
[0..*] 00150
21 Charge Price Indicator CWE O
0032 Charge/Price Indicator
[0..1] 00151
22 Courtesy Code CWE O
0045 Courtesy Code
[0..1] 00152
23 Credit Rating CWE O
0046 Credit Rating
[0..1] 00153
24 Contract Code CWE O
0044 Contract Code
[0..*] 00154
25 Contract Effective Date DT O
[0..*] 00155
26 Contract Amount NM O
[0..*] 00156 12 #
27 Contract Period NM O
[0..*] 00157 3 #
28 Interest Code CWE O
0073 Interest Rate Code
[0..1] 00158
29 Transfer to Bad Debt Code CWE O
0110 Transfer to Bad Debt Code
[0..1] 00159
30 Transfer to Bad Debt Date DT O
[0..1] 00160
31 Bad Debt Agency Code CWE O
0021 Bad Debt Agency Code
[0..1] 00161
32 Bad Debt Transfer Amount NM O
[0..1] 00162 12 #
33 Bad Debt Recovery Amount NM O
[0..1] 00163 12 #
34 Delete Account Indicator CWE O
0111 Delete Account Code
[0..1] 00164
35 Delete Account Date DT O
[0..1] 00165
36 Discharge Disposition CWE O
0112 Discharge Disposition
[0..1] 00166
37 Discharged to Location DLD O
0113 Discharged to Location
[0..1] 00167
38 Diet Type CWE O
0114 Diet Type
[0..1] 00168
39 Servicing Facility CWE O
0115 Servicing Facilities
[0..1] 00169
40 Bed Status CWE W
0116 Bed Status
[0..1] 00170
41 Account Status CWE O
0117 Account Status
[0..1] 00171
42 Pending Location PL O
[0..1] 00172
43 Prior Temporary Location PL O
[0..1] 00173
44 Admit Date/Time DTM O
[0..1] 00174
45 Discharge Date/Time DTM O
[0..1] 00175
46 Current Patient Balance NM O
[0..1] 00176 12 #
47 Total Charges NM O
[0..1] 00177 12 #
48 Total Adjustments NM O
[0..1] 00178 12 #
49 Total Payments NM O
[0..1] 00179 12 #
50 Alternate Visit ID CX O
0203(S) Identifier Type(Suggested)
[0..*] 00180
51 Visit Indicator CWE O
0326(S) Visit Indicator(Suggested)
[0..1] 01226
52 Other Healthcare Provider W
[0..1] 01274
53 Service Episode Description ST O
[0..1] 02290 50 #
54 Service Episode Identifier CX O
[0..1] 02291

PV1-1: Set ID - PV1 (SI) 00131

FIXME

PV1-2: Patient Class (CWE) 00132

FIXME

PV1-3: Assigned Patient Location (PL) 00133

FIXME

PV1-4: Admission Type (CWE) 00134

FIXME

PV1-5: Preadmit Number (CX) 00135

FIXME

PV1-6: Prior Patient Location (PL) 00136

FIXME

PV1-7: Attending Doctor (XCN) 00137

FIXME

PV1-8: Referring Doctor (XCN) 00138

FIXME

PV1-9: Consulting Doctor (XCN) 00139

FIXME

PV1-10: Hospital Service (CWE) 00140

FIXME

PV1-11: Temporary Location (PL) 00141

FIXME

PV1-12: Preadmit Test Indicator (CWE) 00142

FIXME

PV1-13: Re-admission Indicator (CWE) 00143

FIXME

PV1-14: Admit Source (CWE) 00144

FIXME

PV1-15: Ambulatory Status (CWE) 00145

FIXME

PV1-16: VIP Indicator (CWE) 00146

FIXME

PV1-17: Admitting Doctor (XCN) 00147

FIXME

PV1-18: Patient Type (CWE) 00148

FIXME

PV1-19: Visit Number (CX) 00149

FIXME

PV1-20: Financial Class (FC) 00150

FIXME

PV1-21: Charge Price Indicator (CWE) 00151

FIXME

PV1-22: Courtesy Code (CWE) 00152

FIXME

PV1-23: Credit Rating (CWE) 00153

FIXME

PV1-24: Contract Code (CWE) 00154

FIXME

PV1-25: Contract Effective Date (DT) 00155

FIXME

PV1-26: Contract Amount (NM) 00156

FIXME

PV1-27: Contract Period (NM) 00157

FIXME

PV1-28: Interest Code (CWE) 00158

FIXME

PV1-29: Transfer to Bad Debt Code (CWE) 00159

FIXME

PV1-30: Transfer to Bad Debt Date (DT) 00160

FIXME

PV1-31: Bad Debt Agency Code (CWE) 00161

FIXME

PV1-32: Bad Debt Transfer Amount (NM) 00162

FIXME

PV1-33: Bad Debt Recovery Amount (NM) 00163

FIXME

PV1-34: Delete Account Indicator (CWE) 00164

FIXME

PV1-35: Delete Account Date (DT) 00165

FIXME

PV1-36: Discharge Disposition (CWE) 00166

FIXME

PV1-37: Discharged to Location (DLD) 00167

FIXME

PV1-38: Diet Type (CWE) 00168

FIXME

PV1-39: Servicing Facility (CWE) 00169

FIXME

PV1-40: Bed Status (CWE) 00170

FIXME

PV1-41: Account Status (CWE) 00171

FIXME

PV1-42: Pending Location (PL) 00172

FIXME

PV1-43: Prior Temporary Location (PL) 00173

FIXME

PV1-44: Admit Date/Time (DTM) 00174

FIXME

PV1-45: Discharge Date/Time (DTM) 00175

FIXME

PV1-46: Current Patient Balance (NM) 00176

FIXME

PV1-47: Total Charges (NM) 00177

FIXME

PV1-48: Total Adjustments (NM) 00178

FIXME

PV1-49: Total Payments (NM) 00179

FIXME

PV1-50: Alternate Visit ID (CX) 00180

FIXME

PV1-51: Visit Indicator (CWE) 01226

FIXME

PV1-52: Other Healthcare Provider () 01274

FIXME

PV1-53: Service Episode Description (ST) 02290

FIXME

PV1-54: Service Episode Identifier (CX) 02291

FIXME

PV2 - Patient Visit - Additional Information Segment

The PV2 segment is a continuation of information contained on the PV1 segment.

HL7 Attribute Table - PV2 - Patient Visit - Additional Information Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PV2
1 Prior Pending Location PL C
[0..1] 00181
2 Accommodation Code CWE O
0129 Accommodation Code
[0..1] 00182
3 Admit Reason CWE O
[0..1] 00183
4 Transfer Reason CWE O
[0..1] 00184
5 Patient Valuables ST O
[0..*] 00185 25 #
6 Patient Valuables Location ST O
[0..1] 00186 25 #
7 Visit User Code CWE O
0130 Visit User Code
[0..*] 00187
8 Expected Admit Date/Time DTM O
[0..1] 00188
9 Expected Discharge Date/Time DTM O
[0..1] 00189
10 Estimated Length of Inpatient Stay NM O
[0..1] 00711 3 #
11 Actual Length of Inpatient Stay NM O
[0..1] 00712 3 #
12 Visit Description ST O
[0..1] 00713 50 #
13 Referral Source Code XCN O
[0..*] 00714
14 Previous Service Date DT O
[0..1] 00715
15 Employment Illness Related Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00716 [1..1]
16 Purge Status Code CWE O
0213 Purge Status Code
[0..1] 00717
17 Purge Status Date DT O
[0..1] 00718
18 Special Program Code CWE O
0214 Special Program Code
[0..1] 00719
19 Retention Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00720 [1..1]
20 Expected Number of Insurance Plans NM O
[0..1] 00721 1 #
21 Visit Publicity Code CWE O
0215 Publicity Code
[0..1] 00722
22 Visit Protection Indicator ID B
0136(R) Yes/no Indicator(Required)
[0..1] 00723 [1..1]
23 Clinic Organization Name XON O
[0..*] 00724
24 Patient Status Code CWE O
0216 Patient Status Code
[0..1] 00725
25 Visit Priority Code CWE O
0217(S) Visit Priority Code(Suggested)
[0..1] 00726
26 Previous Treatment Date DT O
[0..1] 00727
27 Expected Discharge Disposition CWE O
0112 Discharge Disposition
[0..1] 00728
28 Signature on File Date DT O
[0..1] 00729
29 First Similar Illness Date DT O
[0..1] 00730
30 Patient Charge Adjustment Code CWE O
0218 Patient Charge Adjustment
[0..1] 00731
31 Recurring Service Code CWE O
0219 Recurring Service Code
[0..1] 00732
32 Billing Media Code ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00733 [1..1]
33 Expected Surgery Date and Time DTM O
[0..1] 00734
34 Military Partnership Code ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00735 [1..1]
35 Military Non-Availability Code ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00736 [1..1]
36 Newborn Baby Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00737 [1..1]
37 Baby Detained Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00738 [1..1]
38 Mode of Arrival Code CWE O
0430(S) Mode of Arrival Code(Suggested)
[0..1] 01543
39 Recreational Drug Use Code CWE O
0431 Recreational Drug Use Code
[0..*] 01544
40 Admission Level of Care Code CWE O
0432(S) Admission Level of Care Code(Suggested)
[0..1] 01545
41 Precaution Code CWE O
0433(S) Precaution Code(Suggested)
[0..*] 01546
42 Patient Condition Code CWE O
0434(S) Patient Condition Code(Suggested)
[0..1] 01547
43 Living Will Code CWE O
0315(S) Living Will Code(Suggested)
[0..1] 00759
44 Organ Donor Code CWE O
0316(S) Organ Donor Code(Suggested)
[0..1] 00760
45 Advance Directive Code CWE C
0435 Advance Directive Code
[0..*] 01548
46 Patient Status Effective Date DT O
[0..1] 01549
47 Expected LOA Return Date/Time DTM C
[0..1] 01550
48 Expected Pre-admission Testing Date/Time DTM O
[0..1] 01841
49 Notify Clergy Code CWE O
0534(S) Notify Clergy Code(Suggested)
[0..*] 01842
50 Advance Directive Last Verified Date DT O
[0..1] 02141

PV2-1: Prior Pending Location (PL) 00181

FIXME

PV2-2: Accommodation Code (CWE) 00182

FIXME

PV2-3: Admit Reason (CWE) 00183

FIXME

PV2-4: Transfer Reason (CWE) 00184

FIXME

PV2-5: Patient Valuables (ST) 00185

FIXME

PV2-6: Patient Valuables Location (ST) 00186

FIXME

PV2-7: Visit User Code (CWE) 00187

FIXME

PV2-8: Expected Admit Date/Time (DTM) 00188

FIXME

PV2-9: Expected Discharge Date/Time (DTM) 00189

FIXME

PV2-10: Estimated Length of Inpatient Stay (NM) 00711

FIXME

PV2-11: Actual Length of Inpatient Stay (NM) 00712

FIXME

PV2-12: Visit Description (ST) 00713

FIXME

PV2-13: Referral Source Code (XCN) 00714

FIXME

PV2-14: Previous Service Date (DT) 00715

FIXME

PV2-15: Employment Illness Related Indicator (ID) 00716

FIXME

PV2-16: Purge Status Code (CWE) 00717

FIXME

PV2-17: Purge Status Date (DT) 00718

FIXME

PV2-18: Special Program Code (CWE) 00719

FIXME

PV2-19: Retention Indicator (ID) 00720

FIXME

PV2-20: Expected Number of Insurance Plans (NM) 00721

FIXME

PV2-21: Visit Publicity Code (CWE) 00722

FIXME

PV2-22: Visit Protection Indicator (ID) 00723

FIXME

PV2-23: Clinic Organization Name (XON) 00724

FIXME

PV2-24: Patient Status Code (CWE) 00725

FIXME

PV2-25: Visit Priority Code (CWE) 00726

FIXME

PV2-26: Previous Treatment Date (DT) 00727

FIXME

PV2-27: Expected Discharge Disposition (CWE) 00728

FIXME

PV2-28: Signature on File Date (DT) 00729

FIXME

PV2-29: First Similar Illness Date (DT) 00730

FIXME

PV2-30: Patient Charge Adjustment Code (CWE) 00731

FIXME

PV2-31: Recurring Service Code (CWE) 00732

FIXME

PV2-32: Billing Media Code (ID) 00733

FIXME

PV2-33: Expected Surgery Date and Time (DTM) 00734

FIXME

PV2-34: Military Partnership Code (ID) 00735

FIXME

PV2-35: Military Non-Availability Code (ID) 00736

FIXME

PV2-36: Newborn Baby Indicator (ID) 00737

FIXME

PV2-37: Baby Detained Indicator (ID) 00738

FIXME

PV2-38: Mode of Arrival Code (CWE) 01543

FIXME

PV2-39: Recreational Drug Use Code (CWE) 01544

FIXME

PV2-40: Admission Level of Care Code (CWE) 01545

FIXME

PV2-41: Precaution Code (CWE) 01546

FIXME

PV2-42: Patient Condition Code (CWE) 01547

FIXME

PV2-43: Living Will Code (CWE) 00759

FIXME

PV2-44: Organ Donor Code (CWE) 00760

FIXME

PV2-45: Advance Directive Code (CWE) 01548

FIXME

PV2-46: Patient Status Effective Date (DT) 01549

FIXME

PV2-47: Expected LOA Return Date/Time (DTM) 01550

FIXME

PV2-48: Expected Pre-admission Testing Date/Time (DTM) 01841

FIXME

PV2-49: Notify Clergy Code (CWE) 01842

FIXME

PV2-50: Advance Directive Last Verified Date (DT) 02141

FIXME

NK1 - Next Of Kin / Associated Parties Segment

The NK1 segment contains information about the patient's other related parties. Any associated parties may be identified. Utilizing NK1-1 - set ID, multiple NK1 segments can be sent to patient accounts.

If a person or organization fulfills multiple contact roles, for example, a person is an emergency contact and a next of kin, it is recommended to send a NK1 segment for each contact role (field 7).

HL7 Attribute Table - NK1 - Next of Kin / Associated Parties Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
NK1
1 Set ID - NK1 SI R
[1..1] 00190 [1..4]
2 Name XPN O
0200(R) Name Type(Required)
[0..*] 00191
3 Relationship CWE O
0063 Relationship
[0..1] 00192
4 Address XAD O
[0..*] 00193
5 Phone Number XTN W
[0..0] 00194
6 Business Phone Number XTN W
[0..0] 00195
7 Contact Role CWE O
0131 Contact Role
[0..1] 00196
8 Start Date DT O
[0..1] 00197
9 End Date DT O
[0..1] 00198
10 Next of Kin / Associated Parties Job Title ST O
[0..1] 00199 60 #
11 Next of Kin / Associated Parties Job Code/Class JCC O
[0..1] 00200
12 Next of Kin / Associated Parties Employee Number CX O
[0..1] 00201
13 Organization Name - NK1 XON O
[0..*] 00202
14 Marital Status CWE O
0002(S) Marital Status(Suggested)
[0..1] 00119
15 Administrative Sex CWE O
0001(S) Administrative Sex(Suggested)
[0..1] 00111
16 Date/Time of Birth DTM O
[0..1] 00110
17 Living Dependency CWE O
0223 Living Dependency
[0..*] 00755
18 Ambulatory Status CWE O
0009(S) Ambulatory Status(Suggested)
[0..*] 00145
19 Citizenship CWE O
0171 Citizenship
[0..*] 00129
20 Primary Language CWE O
0296 Primary Language
[0..1] 00118
21 Living Arrangement CWE O
0220 Living Arrangement
[0..1] 00742
22 Publicity Code CWE O
0215 Publicity Code
[0..1] 00743
23 Protection Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00744 [1..1]
24 Student Indicator CWE O
0231(S) Student Status(Suggested)
[0..1] 00745
25 Religion CWE O
0006(S) Religion(Suggested)
[0..1] 00120
26 Mother's Maiden Name XPN O
[0..*] 00109
27 Nationality CWE O
0212 Nationality
[0..1] 00739
28 Ethnic Group CWE O
0189 Ethnic Group
[0..*] 00125
29 Contact Reason CWE O
0222 Contact Reason
[0..*] 00747
30 Contact Person's Name XPN O
0200(R) Name Type(Required)
[0..*] 00748
31 Contact Person's Telephone Number XTN W
[0..0] 00749
32 Contact Person's Address XAD O
[0..*] 00750
33 Next of Kin/Associated Party's Identifiers CX O
[0..*] 00751
34 Job Status CWE O
0311 Job Status
[0..1] 00752
35 Race CWE O
0005(S) Race(Suggested)
[0..*] 00113
36 Handicap CWE O
0295 Handicap
[0..1] 00753
37 Contact Person Social Security Number ST O
[0..1] 00754 16 #
38 Next of Kin Birth Place ST O
[0..1] 01905 250 #
39 VIP Indicator CWE O
0099 VIP Indicator
[0..1] 00146
40 Next of Kin Telecommunication Information XTN O
[0..1] 02292
41 Contact Person's Telecommunication Information XTN O
[0..1] 02293

NK1-1: Set ID - NK1 (SI) 00190

FIXME

NK1-2: Name (XPN) 00191

FIXME

NK1-3: Relationship (CWE) 00192

FIXME

NK1-4: Address (XAD) 00193

FIXME

NK1-5: Phone Number (XTN) 00194

FIXME

NK1-6: Business Phone Number (XTN) 00195

FIXME

NK1-7: Contact Role (CWE) 00196

FIXME

NK1-8: Start Date (DT) 00197

FIXME

NK1-9: End Date (DT) 00198

FIXME

NK1-10: Next of Kin / Associated Parties Job Title (ST) 00199

FIXME

NK1-11: Next of Kin / Associated Parties Job Code/Class (JCC) 00200

FIXME

NK1-12: Next of Kin / Associated Parties Employee Number (CX) 00201

FIXME

NK1-13: Organization Name - NK1 (XON) 00202

FIXME

NK1-14: Marital Status (CWE) 00119

FIXME

NK1-15: Administrative Sex (CWE) 00111

FIXME

NK1-16: Date/Time of Birth (DTM) 00110

FIXME

NK1-17: Living Dependency (CWE) 00755

FIXME

NK1-18: Ambulatory Status (CWE) 00145

FIXME

NK1-19: Citizenship (CWE) 00129

FIXME

NK1-20: Primary Language (CWE) 00118

FIXME

NK1-21: Living Arrangement (CWE) 00742

FIXME

NK1-22: Publicity Code (CWE) 00743

FIXME

NK1-23: Protection Indicator (ID) 00744

FIXME

NK1-24: Student Indicator (CWE) 00745

FIXME

NK1-25: Religion (CWE) 00120

FIXME

NK1-26: Mother's Maiden Name (XPN) 00109

FIXME

NK1-27: Nationality (CWE) 00739

FIXME

NK1-28: Ethnic Group (CWE) 00125

FIXME

NK1-29: Contact Reason (CWE) 00747

FIXME

NK1-30: Contact Person's Name (XPN) 00748

FIXME

NK1-31: Contact Person's Telephone Number (XTN) 00749

FIXME

NK1-32: Contact Person's Address (XAD) 00750

FIXME

NK1-33: Next of Kin/Associated Party's Identifiers (CX) 00751

FIXME

NK1-34: Job Status (CWE) 00752

FIXME

NK1-35: Race (CWE) 00113

FIXME

NK1-36: Handicap (CWE) 00753

FIXME

NK1-37: Contact Person Social Security Number (ST) 00754

FIXME

NK1-38: Next of Kin Birth Place (ST) 01905

FIXME

NK1-39: VIP Indicator (CWE) 00146

FIXME

NK1-40: Next of Kin Telecommunication Information (XTN) 02292

FIXME

NK1-41: Contact Person's Telecommunication Information (XTN) 02293

FIXME

AL1 - Patient Allergy Information Segment

The AL1 segment contains patient allergy information of various types. Most of this information will be derived from user-defined tables. Each AL1 segment describes a single patient allergy.

HL7 Attribute Table - AL1 - Patient Allergy Information Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
AL1
1 Set ID - AL1 SI R
[1..1] 00203 [1..4]
2 Allergen Type Code CWE O
0127 Allergen Type
[0..1] 00204
3 Allergen Code/Mnemonic/Description CWE O
[0..1] 00205
4 Allergy Severity Code CWE O
0128 Allergy Severity
[0..1] 00206
5 Allergy Reaction Code ST O
[0..*] 00207 15 #
6 Identification Date W
[0..1] 00208

AL1-1: Set ID - AL1 (SI) 00203

FIXME

AL1-2: Allergen Type Code (CWE) 00204

FIXME

AL1-3: Allergen Code/Mnemonic/Description (CWE) 00205

FIXME

AL1-4: Allergy Severity Code (CWE) 00206

FIXME

AL1-5: Allergy Reaction Code (ST) 00207

FIXME

AL1-6: Identification Date () 00208

FIXME

IAM - Patient Adverse Reaction Information Segment

The IAM segment contains person/patient adverse reaction information of various types. Most of this information will be derived from user-defined tables. Each IAM segment describes a single person/patient adverse reaction. This segment is used in lieu of the AL1 - Patient Allergy Information Segment to support action code/unique identifier mode update definition of repeating segments as defined in 2.10.4.2 in chapter 2, section 2.4.10, "Protocol for interpreting repeating segments or segment groups in an update Message." The AL1 segment is used to support Snapshot mode update definition as defined in 2.10.4.1.

HL7 Attribute Table - IAM - Patient Adverse Reaction Information Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
IAM
1 Set ID - IAM SI R
[1..1] 01612 [1..4]
2 Allergen Type Code CWE O
0127 Allergen Type
[0..1] 00204
3 Allergen Code/Mnemonic/Description CWE R
[1..1] 00205
4 Allergy Severity Code CWE O
0128 Allergy Severity
[0..1] 00206
5 Allergy Reaction Code ST O
[0..*] 00207 15 #
6 Allergy Action Code CNE R
0206(R) Segment Action Code(Required)
[1..1] 01551
7 Allergy Unique Identifier EI C
[0..1] 01552
8 Action Reason ST O
[0..1] 01553 60 #
9 Sensitivity to Causative Agent Code CWE O
0436 Sensitivity to Causative Agent Code
[0..1] 01554
10 Allergen Group Code/Mnemonic/Description CWE O
[0..1] 01555
11 Onset Date DT O
[0..1] 01556
12 Onset Date Text ST O
[0..1] 01557 60 #
13 Reported Date/Time DTM O
[0..1] 01558
14 Reported By XPN O
[0..1] 01559
15 Relationship to Patient Code CWE O
0063 Relationship
[0..1] 01560
16 Alert Device Code CWE O
0437 Alert Device Code
[0..1] 01561
17 Allergy Clinical Status Code CWE O
0438 Allergy Clinical Status
[0..1] 01562
18 Statused by Person XCN O
[0..1] 01563
19 Statused by Organization XON O
[0..1] 01564
20 Statused at Date/Time DTM O
[0..1] 01565
21 Inactivated by Person XCN O
[0..1] 02294
22 Inactivated Date/Time DTM O
[0..1] 02295
23 Initially Recorded by Person XCN O
[0..1] 02296
24 Initially Recorded Date/Time DTM O
[0..1] 02297
25 Modified by Person XCN O
[0..1] 02298
26 Modified Date/Time DTM O
[0..1] 02299
27 Clinician-Identified Allergen Code CWE O
[0..1] 02300
28 Initially Recorded by Organization XON O
[0..1] 03293
29 Modified by Organization XON O
[0..1] 03294
30 Inactivated by Organization XON O
[0..1] 03295

IAM-1: Set ID - IAM (SI) 01612

FIXME

IAM-2: Allergen Type Code (CWE) 00204

FIXME

IAM-3: Allergen Code/Mnemonic/Description (CWE) 00205

FIXME

IAM-4: Allergy Severity Code (CWE) 00206

FIXME

IAM-5: Allergy Reaction Code (ST) 00207

FIXME

IAM-6: Allergy Action Code (CNE) 01551

FIXME

IAM-7: Allergy Unique Identifier (EI) 01552

FIXME

IAM-8: Action Reason (ST) 01553

FIXME

IAM-9: Sensitivity to Causative Agent Code (CWE) 01554

FIXME

IAM-10: Allergen Group Code/Mnemonic/Description (CWE) 01555

FIXME

IAM-11: Onset Date (DT) 01556

FIXME

IAM-12: Onset Date Text (ST) 01557

FIXME

IAM-13: Reported Date/Time (DTM) 01558

FIXME

IAM-14: Reported By (XPN) 01559

FIXME

IAM-15: Relationship to Patient Code (CWE) 01560

FIXME

IAM-16: Alert Device Code (CWE) 01561

FIXME

IAM-17: Allergy Clinical Status Code (CWE) 01562

FIXME

IAM-18: Statused by Person (XCN) 01563

FIXME

IAM-19: Statused by Organization (XON) 01564

FIXME

IAM-20: Statused at Date/Time (DTM) 01565

FIXME

IAM-21: Inactivated by Person (XCN) 02294

FIXME

IAM-22: Inactivated Date/Time (DTM) 02295

FIXME

IAM-23: Initially Recorded by Person (XCN) 02296

FIXME

IAM-24: Initially Recorded Date/Time (DTM) 02297

FIXME

IAM-25: Modified by Person (XCN) 02298

FIXME

IAM-26: Modified Date/Time (DTM) 02299

FIXME

IAM-27: Clinician-Identified Allergen Code (CWE) 02300

FIXME

IAM-28: Initially Recorded by Organization (XON) 03293

FIXME

IAM-29: Modified by Organization (XON) 03294

FIXME

IAM-30: Inactivated by Organization (XON) 03295

FIXME

IAR - Allergy Reaction Segment

The IAR segment is used to transmit a single reaction and information associated with this single reaction occurrence for a particular patient allergy (IAM – patient adverse reaction).

HL7 Attribute Table - IAR - Allergy Reaction Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
IAR
1 Allergy Reaction Code CWE R
[1..1] 03296
2 Allergy Severity Code CWE R
0128 Allergy Severity
[1..1] 03297
3 Sensitivity to Causative Agent Code CWE O
0436 Sensitivity to Causative Agent Code
[0..1] 03298
4 Management ST O
[0..1] 03299 250 #

IAR-1: Allergy Reaction Code (CWE) 03296

FIXME

IAR-2: Allergy Severity Code (CWE) 03297

FIXME

IAR-3: Sensitivity to Causative Agent Code (CWE) 03298

FIXME

IAR-4: Management (ST) 03299

FIXME

NPU - Bed Status Update Segment

The NPU segment allows the updating of census (bed status) data without sending patient-specific data. An example might include changing the status of a bed from "housekeeping" to "unoccupied."

HL7 Attribute Table - NPU - Bed Status Update Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
NPU
1 Bed Location PL R
[1..1] 00209
2 Bed Status CWE O
0116 Bed Status
[0..1] 00170

NPU-1: Bed Location (PL) 00209

FIXME

NPU-2: Bed Status (CWE) 00170

FIXME

MRG - Merge Patient Information Segment

The MRG segment provides receiving applications with information necessary to initiate the merging of patient data as well as groups of records. It is intended that this segment be used throughout the Standard to allow the merging of registration, accounting, and clinical records within specific applications.

The assigning authority, the fourth component of the patient identifiers, is an HD data type that is uniquely associated with the assigning authority that originally assigned the number. A given institution, or group of intercommunicating institutions, should establish a list of assigning authorities that may be potential assignors of patient identification (and other important identification) numbers. The list will be one of the institution's master dictionary lists. Since third parties (other than the assignors of patient identification numbers) may send or receive HL7 messages containing patient identification numbers, the assigning authority in the patient identification numbers may not be the same as those of the sending and receiving systems identified in the MSH. The assigning authority must be unique across applications at a given site. This field is required in HL7 implementations that have more than a single Patient Administration application assigning such numbers.

HL7 Attribute Table - MRG - Merge Patient Information Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
MRG
1 Prior Patient Identifier List CX R
0061(R) Check Digit Scheme(Required)
[1..*] 00211
2 Prior Alternate Patient ID W
[0..1] 00212
3 Prior Patient Account Number CX O
0061(R) Check Digit Scheme(Required)
[0..1] 00213
4 Prior Patient ID W
[0..1] 00214
5 Prior Visit Number CX O
0061(R) Check Digit Scheme(Required)
[0..1] 01279
6 Prior Alternate Visit ID CX O
0061(R) Check Digit Scheme(Required)
[0..*] 01280
7 Prior Patient Name XPN O
0200(R) Name Type(Required)
[0..*] 01281

MRG-1: Prior Patient Identifier List (CX) 00211

FIXME

MRG-2: Prior Alternate Patient ID () 00212

FIXME

MRG-3: Prior Patient Account Number (CX) 00213

FIXME

MRG-4: Prior Patient ID () 00214

FIXME

MRG-5: Prior Visit Number (CX) 01279

FIXME

MRG-6: Prior Alternate Visit ID (CX) 01280

FIXME

MRG-7: Prior Patient Name (XPN) 01281

FIXME

PD1 - Patient Additional Demographic Segment

The patient additional demographic segment contains demographic information that is likely to change about the patient.

HL7 Attribute Table - PD1 - Patient Additional Demographic Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PD1
1 Living Dependency CWE O
0223 Living Dependency
[0..*] 00755
2 Living Arrangement CWE O
0220 Living Arrangement
[0..1] 00742
3 Patient Primary Facility XON O
0204 Organizational Name Type
[0..*] 00756
4 Patient Primary Care Provider Name & ID No. W
[0..1] 00757
5 Student Indicator CWE O
0231(S) Student Status(Suggested)
[0..1] 00745
6 Handicap CWE O
0295 Handicap
[0..1] 00753
7 Living Will Code CWE O
0315(S) Living Will Code(Suggested)
[0..1] 00759
8 Organ Donor Code CWE O
0316(S) Organ Donor Code(Suggested)
[0..1] 00760
9 Separate Bill ID O
0136(R) Yes/no Indicator(Required)
[0..1] 00761 [1..1]
10 Duplicate Patient CX O
[0..*] 00762
11 Publicity Code CWE O
0215 Publicity Code
[0..1] 00743
12 Protection Indicator ID B
0136(R) Yes/no Indicator(Required)
[0..1] 00744 [1..1]
13 Protection Indicator Effective Date DT B
[0..1] 01566
14 Place of Worship XON O
[0..*] 01567
15 Advance Directive Code CWE C
0435 Advance Directive Code
[0..*] 01548
16 Immunization Registry Status CWE O
0441(S) Immunization Registry Status(Suggested)
[0..1] 01569
17 Immunization Registry Status Effective Date DT O
[0..1] 01570
18 Publicity Code Effective Date DT O
[0..1] 01571
19 Military Branch CWE O
0140 Military Service
[0..1] 01572
20 Military Rank/Grade CWE O
0141 Military Rank/Grade
[0..1] 00486
21 Military Status CWE O
0142 Military Status
[0..1] 01573
22 Advance Directive Last Verified Date DT O
[0..1] 02141
23 Retirement Date DT O
[0..1] 03511

PD1-1: Living Dependency (CWE) 00755

FIXME

PD1-2: Living Arrangement (CWE) 00742

FIXME

PD1-3: Patient Primary Facility (XON) 00756

FIXME

PD1-4: Patient Primary Care Provider Name & ID No. () 00757

FIXME

PD1-5: Student Indicator (CWE) 00745

FIXME

PD1-6: Handicap (CWE) 00753

FIXME

PD1-7: Living Will Code (CWE) 00759

FIXME

PD1-8: Organ Donor Code (CWE) 00760

FIXME

PD1-9: Separate Bill (ID) 00761

FIXME

PD1-10: Duplicate Patient (CX) 00762

FIXME

PD1-11: Publicity Code (CWE) 00743

FIXME

PD1-12: Protection Indicator (ID) 00744

FIXME

PD1-13: Protection Indicator Effective Date (DT) 01566

FIXME

PD1-14: Place of Worship (XON) 01567

FIXME

PD1-15: Advance Directive Code (CWE) 01548

FIXME

PD1-16: Immunization Registry Status (CWE) 01569

FIXME

PD1-17: Immunization Registry Status Effective Date (DT) 01570

FIXME

PD1-18: Publicity Code Effective Date (DT) 01571

FIXME

PD1-19: Military Branch (CWE) 01572

FIXME

PD1-20: Military Rank/Grade (CWE) 00486

FIXME

PD1-21: Military Status (CWE) 01573

FIXME

PD1-22: Advance Directive Last Verified Date (DT) 02141

FIXME

PD1-23: Retirement Date (DT) 03511

FIXME

DB1 - Disability Segment

The disability segment contains information related to the disability of a person. This segment was created instead of adding disability attributes to each segment that contains a person (to which disability may apply). This is an optional segment that can be used to send disability information about a person already defined by the Patient Administration Chapter. The disabled person code and identifier allow for the association of the disability information to the person.

HL7 Attribute Table - DB1 - Disability Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
DB1
1 Set ID - DB1 SI R
[1..1] 01283 [1..4]
2 Disabled Person Code CWE O
0334(S) Disabled Person Code(Suggested)
[0..1] 01284
3 Disabled Person Identifier CX O
[0..*] 01285
4 Disability Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 01286 [1..1]
5 Disability Start Date DT O
[0..1] 01287
6 Disability End Date DT O
[0..1] 01288
7 Disability Return to Work Date DT O
[0..1] 01289
8 Disability Unable to Work Date DT O
[0..1] 01290

DB1-1: Set ID - DB1 (SI) 01283

FIXME

DB1-2: Disabled Person Code (CWE) 01284

FIXME

DB1-3: Disabled Person Identifier (CX) 01285

FIXME

DB1-4: Disability Indicator (ID) 01286

FIXME

DB1-5: Disability Start Date (DT) 01287

FIXME

DB1-6: Disability End Date (DT) 01288

FIXME

DB1-7: Disability Return to Work Date (DT) 01289

FIXME

DB1-8: Disability Unable to Work Date (DT) 01290

FIXME

PDA - Patient Death And Autopsy Segment

This segment carries information on a patient's death and possible autopsy.

HL7 Attribute Table - PDA - Patient Death and Autopsy Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PDA
1 Death Cause Code CWE O
[0..*] 01574
2 Death Location PL O
[0..1] 01575
3 Death Certified Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 01576 [1..1]
4 Death Certificate Signed Date/Time DTM O
[0..1] 01577
5 Death Certified By XCN O
[0..1] 01578
6 Autopsy Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 01579 [1..1]
7 Autopsy Start and End Date/Time DR O
[0..1] 01580
8 Autopsy Performed By XCN O
[0..1] 01581
9 Coroner Indicator ID O
0136(R) Yes/no Indicator(Required)
[0..1] 01582 [1..1]

PDA-1: Death Cause Code (CWE) 01574

FIXME

PDA-2: Death Location (PL) 01575

FIXME

PDA-3: Death Certified Indicator (ID) 01576

FIXME

PDA-4: Death Certificate Signed Date/Time (DTM) 01577

FIXME

PDA-5: Death Certified By (XCN) 01578

FIXME

PDA-6: Autopsy Indicator (ID) 01579

FIXME

PDA-7: Autopsy Start and End Date/Time (DR) 01580

FIXME

PDA-8: Autopsy Performed By (XCN) 01581

FIXME

PDA-9: Coroner Indicator (ID) 01582

FIXME

ARV - Access Restrictions Segment

The ARV segment is used to communicate the requested/required type of access restrictions from system to system, at both the person/patient and the encounter/visit level.

The Access Restrictions segment (ARV) sent after the MSH acts as a manifest and declares the privacy and security classification (i.e the confidentiality level), the sensitivity (i.e. access restriction reason) and provides handling instructions (e.g. what the data can be used for, what must be done to protect it and what may not be done with the data). The segment is optional and can repeat.

Examples:

A person/patient may have the right to object to any or all of his/her information to be disclosed. In addition, the patient may request that protected information not be disclosed to family members or friends who may be involved in their care or for notification purposes.

A realm or organization may have certain privacy policies.

A patient may have the right to opt out of being included on facility directories.

In an international context, a physician may be culturally obligated to protect the patient's privacy.

Any "opt-in" or "opt-out" restrictions are communicated in ARV-3 - Access Restriction Value. This segment replaces PD1-12 and PV2-22, which have been deprecated in V2.6. The ARV segment is optional and as of 2.9 is sent immediately following the MSH segment to allow declaration of access restrictions for specific data elements (ARV-9 – Access Restriction Message Location), that are different from the overall security level declared in the Message Header Segment. The ARV segment can repeat, so that different security attributes across message elements can be declared.

Usage Notes:

The individual system security may want to utilize the Access Restriction Value along with the Access Restriction Reason and with the Confidentiality Code from Code defined in the Security Classification Tag (ARV-7)in order to implement the appropriate type of protection for the identified data. Each system has the flexibility to incorporate/map the access values into their security system appropriately; the actual implementation for access to protected data is determined by the individual system. The Access Restriction Values supported by an enterprise/system would be defined and determined by that organization.

It is expected that these access restriction values would be utilized in combination with other system security information (e.g., patient locations, user department, caregiver-patient relationships, other access restriction parameters) to determine user access.

System implementers should carefully control access to the restriction codes and values, as they themselves hold sensitive information.

HL7 Attribute Table - ARV - Access Restrictions segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
ARV
1 Set ID SI O
[0..1] 02143 [1..4]
2 Access Restriction Action Code CNE R
0206(R) Segment Action Code(Required)
[1..1] 02144
3 Access Restriction Value CWE R
0717 Access Restriction Value
[1..1] 02145
4 Access Restriction Reason CWE O
0719 Access Restriction Reason Code
[0..*] 02146
5 Special Access Restriction Instructions ST O
[0..*] 02147 250 #
6 Access Restriction Date Range DR O
[0..1] 02148
7 Security Classification Tag CWE R
0952(S) Confidentiality Classification(Suggested)
[1..1] 03512
8 Security Handling Instructions CWE O
0953
[0..*] 03513
9 Access Restriction Message Location ERL O
[0..*] 03514
10 Access Restriction Instance Identifier EI C
[0..1] 02470

ARV-1: Set ID (SI) 02143

FIXME

ARV-2: Access Restriction Action Code (CNE) 02144

FIXME

ARV-3: Access Restriction Value (CWE) 02145

FIXME

ARV-4: Access Restriction Reason (CWE) 02146

FIXME

ARV-5: Special Access Restriction Instructions (ST) 02147

FIXME

ARV-6: Access Restriction Date Range (DR) 02148

FIXME

ARV-7: Security Classification Tag (CWE) 03512

FIXME

ARV-8: Security Handling Instructions (CWE) 03513

FIXME

ARV-9: Access Restriction Message Location (ERL) 03514

FIXME

ARV-10: Access Restriction Instance Identifier (EI) 02470

FIXME

OH1 - Person Employment Status Segment

The OH1 segment is a clinical statement about the subject’s state of being employed at the point in time the statement is recorded. Awareness of the subject’s Employment Status can assist in understanding the subject’s resources, access to benefits, and demands at home and work. If the subject is working (regardless of pay), information about their current job is communicated in OH2 Past or Present Job Segment. Information about volunteer work and past jobs can be collected in the Past or Present Job Segment regardless of current employment status, i.e., even if the subject is not employed at the time.

The intent is for the segment to be allowed to repeat within a message definition to allow a history of employment status for the patient.

This segment relates only to the patient and is not intended to relate to the Next of Kin.

Examples:

A person/patient may be currently employed following a period of choosing to not be in the labor force. This would be represented by a repeating OH1 segment.

HL7 Attribute Table - OH1 - Person Employment Status segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
OH1
1 Set ID SI R
[1..1] 03516
2 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]
3 Employment Status CWE R
0957
[1..1] 03518
4 Employment Status Start Date DT O
[0..1] 03519
5 Employment Status End Date DT O
[0..1] 03520
6 Entered Date DT R
[1..1] 03521
7 Employment Status Unique Identifier EI O
[0..1] 02432

OH1-1: Set ID (SI) 03516

FIXME

OH1-2: Action Code (ID) 00816

FIXME

OH1-3: Employment Status (CWE) 03518

FIXME

OH1-4: Employment Status Start Date (DT) 03519

FIXME

OH1-5: Employment Status End Date (DT) 03520

FIXME

OH1-6: Entered Date (DT) 03521

FIXME

OH1-7: Employment Status Unique Identifier (EI) 02432

FIXME

OH2 - Past Or Present Job Segment

The OH2 segment is used to communicate the information about a job or jobs which the subject currently holds or has held in the past. It includes related observations about the occupation (type of work), the type of business (industry) in which that occupation is performed, supervisory level (including military pay grade), and the employer's name and location. It should also include observations about the job's compensation and sector employment type (e.g., paid work, self-employed, volunteer) and work schedule, and may also contain observations for job duties and occupational exposures. The type of work a person performs (occupation) and their industry (type of business in which they work) are critical data elements for patient care, population health, and public health, with the current information being the most important. In the health care encounter, current occupation and industry are important because they provide information regarding the exposures a person may have to substances/environments/hazards that may cause illness/injury or may impact the treatment plan. The combination of occupation and industry serves as a key indicator of the person’s work environment. The segment is designed to ensure that these data remain associated with one-another in perpetuity, even if multiple jobs are included.

This segment may relate either to the patient or to the Next of Kin.

The intent is for the segment to be allowed to repeat within a message definition to enable a job history for the person.

Examples:

A person/patient may currently hold a job as carpenter, and previously held a job as a painter. This would be represented by repeating OH2 segments.

HL7 Attribute Table - OH2 - Past or Present Job segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
OH2
1 Set ID SI R
[1..1] 03522
2 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]
3 Entered Date DT O
[0..1] 03524
4 Occupation CWE R
0958
[1..1] 03525
5 Industry CWE R
0955
[1..1] 03526
6 Work Classification CWE O
0959(S) Work Classification ODH(Suggested)
[0..1] 03527
7 Job Start Date DT O
[0..1] 02494 [8..*]
8 Job End Date DT O
[0..1] 02495 [8..*]
9 Work Schedule CWE O
0954
[0..1] 03528
10 Average Hours worked per Day NM O
[0..1] 03529
11 Average Days Worked per Week NM O
[0..1] 03530
12 Employer Organization XON O
[0..1] 03531 [48..*]
13 Employer Address XAD O
[0..*] 03546 [106..*]
14 Supervisory Level CWE O
0956
[0..1] 03532
15 Job Duties ST O
[0..*] 03533 [250..*]
16 Occupational Hazards FT O
[0..*] 03534 [250..*]
17 Job Unique Identifier EI O
[0..1] 02433
18 Current Job Indicator CWE O
0136(R) Yes/no Indicator(Required)
[0..1] 02471

OH2-1: Set ID (SI) 03522

FIXME

OH2-2: Action Code (ID) 00816

FIXME

OH2-3: Entered Date (DT) 03524

FIXME

OH2-4: Occupation (CWE) 03525

FIXME

OH2-5: Industry (CWE) 03526

FIXME

OH2-6: Work Classification (CWE) 03527

FIXME

OH2-7: Job Start Date (DT) 02494

FIXME

OH2-8: Job End Date (DT) 02495

FIXME

OH2-9: Work Schedule (CWE) 03528

FIXME

OH2-10: Average Hours worked per Day (NM) 03529

FIXME

OH2-11: Average Days Worked per Week (NM) 03530

FIXME

OH2-12: Employer Organization (XON) 03531

FIXME

OH2-13: Employer Address (XAD) 03546

FIXME

OH2-14: Supervisory Level (CWE) 03532

FIXME

OH2-15: Job Duties (ST) 03533

FIXME

OH2-16: Occupational Hazards (FT) 03534

FIXME

OH2-17: Job Unique Identifier (EI) 02433

FIXME

OH2-18: Current Job Indicator (CWE) 02471

FIXME

OH3 - Usual Work Segment

The OH3 segment contains information about the occupation which the subject has held for the longest duration through his or her working history, at the point in time the statement is recorded. Longest-held occupations can be associated with conditions that develop slowly over time or even after the person is no longer performing that type of work, e.g., some respiratory conditions and cancers. It optionally includes a total duration observation, because a person can be in and out of a given occupation over time. In addition, knowing when the person began working in this occupation can provide information about potential exposures and allows the clinician to assess whether sufficient time has elapsed for a chronic condition to appear, i.e. the latency period. This guides appropriate use of screening tests to detect early disease. This segment may be related to either patient or to the Next of Kin.

Examples:

A person/patient may have worked as a waiter for 3 years, and worked as a nurse for 20 years. The Usual Work would reflect an occupation of nurse as the longest held occupation.

The intent is for the segment to be allowed to repeat within a message definition to enable communication of Usual Work for multiple family members, but not the patient. For instance, the Usual Work segment may be repeated in multiple Next of Kin groups in order to allow for inclusion of mother, father, or other related persons, but not more than one usual job is permitted for one person.

HL7 Attribute Table - OH3 - Usual Work segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
OH3
1 Set ID SI R
[1..1] 03535
2 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]
3 Occupation CWE R
0958
[1..1] 03537
4 Industry CWE R
0955
[1..1] 03538
5 Usual Occupation Duration (years) NM O
[0..1] 03539
6 Start year DT O
[0..1] 03540
7 Entered Date DT O
[0..1] 03542
8 Work Unique Identifier EI O
[0..1] 02446

OH3-1: Set ID (SI) 03535

FIXME

OH3-2: Action Code (ID) 00816

FIXME

OH3-3: Occupation (CWE) 03537

FIXME

OH3-4: Industry (CWE) 03538

FIXME

OH3-5: Usual Occupation Duration (years) (NM) 03539

FIXME

OH3-6: Start year (DT) 03540

FIXME

OH3-7: Entered Date (DT) 03542

FIXME

OH3-8: Work Unique Identifier (EI) 02446

FIXME

OH4 - Combat Zone Work Segment

The OH4 segment contains the date range an individual has worked in what is considered a combat or hazardous duty zone; both civilian and military.

The intent is for the segment to be allowed to repeat within a message definition to enable a combat zone history for the patient.

Examples:

A person/ may have worked in a combat zone for 2 years, followed by 3 years where there was no combat zone work, returning to combat zone work for another 2 years. This would be reflected as two Combat work segments documenting the date ranges for the 2 periods when the combat zone work occurred.

HL7 Attribute Table - OH4 - Combat Zone Work segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
OH4
1 Set ID SI R
[1..1] 03543
2 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]
3 Combat Zone Start Date DT R
[1..1] 03544
4 Combat Zone End Date DT O
[0..1] 03545
5 Entered Date DT O
[0..1] 03524
6 Combat Zone Unique Identifier EI O
[0..1] 02449

OH4-1: Set ID (SI) 03543

FIXME

OH4-2: Action Code (ID) 00816

FIXME

OH4-3: Combat Zone Start Date (DT) 03544

FIXME

OH4-4: Combat Zone End Date (DT) 03545

FIXME

OH4-5: Entered Date (DT) 03524

FIXME

OH4-6: Combat Zone Unique Identifier (EI) 02449

FIXME

EXAMPLE TRANSACTIONS

Admit/visit notification - event A01 (admitted patient)-

MSH|^~VALUEamp;|ADT1|GOOD HEALTH HOSPITAL|GHH LAB, INC.|GOOD HEALTH HOSPITAL|198808181126|SECURITY|ADT^A01^ADT_A01|MSG00001|P|2.8||

EVN|A01|200708181123||

PID|1||PATID1234^5^M11^ADT1^MR^GOOD HEALTH HOSPITAL~123456789^^^USSSA^SS||EVERYMAN^ADAM^A^III||19610615|M||C|2222 HOME STREET^^GREENSBORO^NC^27401-1020|GL|(555) 555-2004|(555)555-2004||S||

PATID12345001^2^M10^ADT1^AN^A|444333333|987654^NC|

NK1|1|NUCLEAR^NELDA^W|SPO^SPOUSE||||NK^NEXT OF KIN

PV1|1|I|2000^2012^01||||004777^ATTEND^AARON^A|||SUR||||ADM|A0|

Patient Adam A. Everyman, III was admitted on July 18, 2007 at 11:23 a.m. by Doctor Aaron A. Attending (#004777) for surgery (SUR). He has been assigned to room 2012, bed 01 on nursing unit 2000.

The message was sent from system ADT1 at the Good Health Hospital site to system GHH Lab, also at the Good Health Hospital site, on the same date as the admission took place, but three minutes after the admit.

Pre-admit notification - event A05 (nonadmitted patient)

MSH|^~VALUEamp;|REGADT|GOOD HEALTH HOSPITAL|GHH LAB||200701061000||ADT^A05^ADT_A05|000001|P|2.8||||

EVN|A05|200701061000|200701101400|01||200701061000

PID|1|| PATID1234^^^GOOD HEALTH HOSPITAL^MR^GOOD HEALTH HOSPITAL~123456789^^^USSSA^SS|253763|EVERYMAN^ADAM^A||19560129|M|||2222 HOME STREET^^ISHPEMING^MI^49849^""^||(555) 555-2004|(555)555-2004||S|C|99999^^^GOOD HEALTH HOSPITAL^AN|444-33-3333||

NK1|1|NUCLEAR^NELDA^W|SPO^SPOUSE|6666 HOME STREET ^^ISHPEMING^MI^49849^""^|555-555-5001|555-555-5001555-555-5001|EC^EMERGENCY CONTACT

NK1|2|MUM^MARTHA^M|MOTHER|4444 HOME STREET ^^ISHPEMING^MI^49849^""^|555-555-2006|555-555-2006~555-555-2006|EC^EMERGENCY CONTACT

NK1|3

NK1|4|||6666 WORKER LOOP^^ISHPEMING^MI^49849|555-555-3003|EM^EMPLOYER|19940605||PROGRAMMER|||WORK IS FUN, INC.

PV1||O|||||0148^ATTEND^AARON^A|0148^SENDER^SAM||AMB|||||||0148^ATTEND^AARON^A|S|1400|A|||||||||||||||||||GOOD HEALTH HOSPITAL||||||

PV2||||||||200301101400||||||||||||||||||||||||||200301101400

OBX||ST|1010.1^BODY WEIGHT||62|kg|||||F

OBX||ST|1010.1^HEIGHT||190|cm|||||F

DG1|1|19||BIOPSY||00

GT1|1||EVERYMAN^ADAM^A^""^""^""^""^||2222 HOME STREET ^ISHPEMING^MI^49849^""^|(555) 555-2004|555 555-2004||||SE^SELF|444-33 3333||||    |2222 HOME STREET^^ISHPEMING^MI^49849^""|555-555-2004 |||||||||||||||||||||||||||||||||AUTO CLINIC

IN1|1|0|UA1|UARE INSURED, INC.|8888 INSURERS CIRCLE^^ISHPEMING^M1^49849^^||555-555-3015|90||||||50 OK

IN1|2|""|""

Patient Adam A. Everyman was pre-admitted on January 6th, 2007 for ambulatory surgery, which is scheduled for January 10, 2007 at 1400. As part of the pre-admission process, he specified two emergency contacts as well as employer, insurance, and guarantor information. He also was measured and weighed.

Note: Above, the REGADT system supports the entry of four NK1 type records: first, second, and third emergency contacts and employer information. A third emergency contact was not provided for Adam A. Everyman. However, an NK1 record must be sent to support "snapshot" mode of update. The REGADT system also supports entry of two insurance plans, one guarantor, and one diagnosis.

Register a patient - event A04 (nonadmitted patient)

MSH|^~VALUEamp;|REGADT|GOOD HEALTH HOSPITAL|GHH LAB||200712311501||ADT^A04^ADT_A01|000001|P|2.8||||

EVN|A04|200701101500|200701101400|01||200701101410

PID|||191919^^^GOOD HEALTH HOSPITAL^MR^GOOD HEALTH HOSPITAL^^^USSSA^SS|253763|EVERYMAN^ADAM^A||19560129|M|||2222 HOME STREET^^ISHPEMING^MI^49849^""^||555-555-2004|555-555- 2004||S|C|10199925^^^GOOD HEALTH HOSPITAL^AN|371-66-9256||

NK1|1|NUCLEAR^NELDA|SPOUSE|6666 HOME STREET^^ISHPEMING^MI^49849^""^|555-555-5001|555-555-5001~555-555-5001|EC1^FIRST EMERGENCY CONTACT

NK1|2|MUM^MARTHA|MOTHER|4444 HOME STREET^^ISHPEMING^MI^49849^""^|555-555 2006|555-555-2006~555-555-2006|EC2^SECOND EMERGENCY CONTACT

NK1|3

NK1|4|||6666 WORKER LOOP^^ISHPEMING^MI^49849^""^||(900)545-1200|EM^EMPLOYER|19940605||PROGRAMMER|||WORK IS FUN, INC.

PV1||O|O/R||||0148^ATTEND^AARON^A|0148^ATTEND^AARON^A|0148^ATTEND^AARON^A|AMB|||||||0148^ATTEND^AARON^A|S|1400|A|||||||||||||||||||GOOD HEALTH HOSPITAL|||||199501101410|

PV2||||||||200701101400||||||||||||||||||||||||||200301101400

OBX||ST|1010.1^BODY WEIGHT||62|kg|||||F

OBX||ST|1010.1^HEIGHT||190|cm|||||F

DG1|1|19||BIOPSY||00|

GT1|1||EVERYMAN^ADAM^A||2222 HOME STREET^^ISHPEMING^MI^49849^""^|444-33 3333|555-555-2004||||SE^SELF|444-33 3333||||AUTO CLINIC|2222 HOME STREET^^ISHPEMING^MI^49849^""|555-555-2004|

IN1|0|0|UA1|UARE INSURED, INC.|8888 INSURERS CIRCLE^^ISHPEMING^M149849^""^||555-555-3015|90||||||50 OK|

IN1|2|""|""

Patient Adam A. Everyman arrived at location O/R for surgery on January 10th, 2007 at 1410 for ambulatory surgery which was scheduled for January 10, 2007 at 1400. The visit event was recorded into the Good Health Hospital system on January 10, 2007 at 1500. It was sent to the interface engine (IFENG) at 1501.

Change an outpatient to an inpatient - event A06

MSH|^~VALUEamp;|REGADT|MCM|IFENG||200701110025||ADT^A06^ADT_A06|000001|P|2.8||||

EVN|A06|200701100250||01||200701102300

PID|||191919^^^GOOD HEALTH HOSPITAL^MR^FAC1~11111^^^USSSA^SS|253763|MASSIE^JAMES^A||19560129|M|||2222 HOME STREET^^ISHPEMING^MI^49849^""^||555-555-2004|555-555-2004||S|C|10199925^^^GOOD HEALTH HOSPITAL^AN|371-66-9256||

NK1|1|MASSIE^ELLEN|SPOUSE|2222 HOME STREET^^ISHPEMING^MI^49849^""^|555) 555 2004|555-555-5001~555-555-5001|EC1^FIRST EMERGENCY CONTACT

NK1|2|MASSIE^MARYLOU|MOTHER|300 ZOBERLEIN^^ISHPEMING^MI^49849^""^|555) 555 2004|555-555-5001~555-555-5001|EC2^SECOND EMERGENCY CONTACT

NK1|3

NK1|4|||6666 WORKER LOOP^^ISHPEMING^MI^49849^""^||(900)545-1200|EM^EMPLOYER|19940605||PROGRAMMER|||WORK IS FUN, INC.

PV1||I|6N^1234^A^GOOD HEALTH HOSPITAL||||0100^SENDER,SAM|0148^ATTEND^AARON^A||SUR|||||||0148^SENDER,SAM|S|1400|A|||||||||||||||||||GOOD HEALTH HOSPITAL|||||199501102300|

OBX||ST|1010.1^BODY WEIGHT||62|kg|||||F

OBX||ST|1010.1^HEIGHT||190|cm|||||F

DG1|1|19||BIOPSY||00

GT1|1||EVERYMAN^ADAM^A||2222 HOME STREET^^ISHPEMING^MI^49849^""^|444-33 3333|555-555-2004||||SE^SELF|444-33 3333||||AUTO CLINIC|2222 HOME STREET^^ISHPEMING^MI^49849^""|555-555-2004

IN1|0|0|UA1|UARE INSURED, INC.|8888 INSURERS CIRCLE^^ISHPEMING^M149849^""^||555-555-3015|90||||||50 OK

IN1|2|""|""

Patient Adam A. Everyman was later converted to an inpatient on January 10th, 2007 at 2300 to recover from the operation. The change from outpatient to inpatient was recorded on the MCM system on January 11, 2007 at 0020. He was assigned to room 1234, bed A on unit 6N. When Patient Adam A. Everyman was converted to an inpatient on January 10th, 2007 at 2300, his hospital service changed to SUR. His attending doctor and admitting doctors changed to Dr Sam Sender. As a result of the conversion, his account number changed from 10199923 to 10199925

Transfer patient - event A02 (first example)

MSH|^~VALUEamp;|REGADT|GOOD HEALTH HOSPITAL|IFENG||200701110500||ADT^A02^ADT_A02|000001|P|2.8||||

EVN|A02|200701110520||01||200701110500

PID|||191919^^^GOOD HEALTH HOSPITAL^MR~111111^^^USSSA^SS|253763|EVERYMAN^ADAM^A||19560129|M|||2222 HOME STREET^^ISHPEMING^MI^49849^""^||555-555-2004|555-555-2004||S|C|10199925^^^GOOD HEALTH HOSPITAL^AN|444-33-3333|||||||||

PV1||I|SICU^0001^01^GOOD HEALTH HOSPITAL|||6N^1234^A^GOOD HEALTH HOSPITAL|0200^ATTEND^AARON^A|0148^ SENDER^SAM||ICU|||||||0148^SENDER^SAM|S|1400|A|||||||||||||||||||GOOD HEALTH HOSPITAL|||||200701102300|

On January 11th, 2007 at 0500, Adam A. Everyman condition became worse due to a complication. As a result, he was transferred to the surgical ICU (SICU). The transfer was recorded on the Good Health Hospital system on January 11, 2007 at 0520. He was assigned to room 0001, bed 1. When Patient Adam A. Everyman was transferred to SICU, his hospital service changed to ICU and his attending doctor changed to Dr. Sam Sender.

Cancel transfer - event A12

MSH|^~VALUEamp;|REGADT|GOOD HEALTH HOSPITAL|IFENG||200701110600||ADT^A12^ADT_A12|000001|P|2.8||||

EVN|A02|200701110600||01||200701110500

PID|||191919^^^GOOD HEALTH HOSPITAL|253763|EVERYMAN^ADAM^A||19560129|M|||2222 HOME STREET^^ISHPEMING^MI^49849^""^||555-555-2004|555-555-2004||S|C|10199925|444-33-3333||

PV1||I|6N^1234^A^GOOD HEALTH HOSPITAL|||SICU^0001^1^GOOD HEALTH HOSPITAL|0100^ATTEND^AARON^A|0148^ATTEND^AARON^A||SUR|||||||0148^ATTEND^AARON^A|S|1400|A|||||||||||||||||||GOOD HEALTH HOSPITAL|||||200701102300|

It was determined that Adam A. Everyman was transferred to the wrong room in the SICU. Therefore, the transfer was cancelled.

Transfer patient - event A02 (second example)

MSH|^~VALUEamp;|REGADT|GOOD HEALTH HOSPITAL|IFENG||200701110603||ADT^A02^ADT_A02|000001|P|2.8||||

EVN|A02|200701110603||01||200701110500

PID|||191919^^^GOOD HEALTH HOSPITAL^MR^FAC1~1111^^^USSSA^SS|253763|EVERYMAN^ADAM^A||19560129|M|||2222 HOME STREET^^ISHPEMING^MI^49849^""^||555-555-2004|555-555-2004||S|C|10199925^^^GOOD HEALTH HOSPITAL^AN|444-33-3333||

PV1||I|SICU^0001^02^GOOD HEALTH HOSPITAL|||6N^1234^A^GOOD HEALTH HOSPITAL|0100^ATTEND^AARON^A|0148^ATTEND^AARON^A||SUR|||||||0148^ATTEND^AARON^A|S|1400|A|||||||||||||||||||GOOD HEALTH HOSPITAL|||||200701102300|

The transfer is then repeated, this time to the correct bed: bed 2 of room 0001 in the SICU.

Discharge patient - event A03

MSH|^~VALUEamp;|REGADT|GOOD HEALTH HOSPITAL|IFENG||200701121005||ADT^A03^ADT_A03|000001|P|2.8||||

EVN|A03|200701121005||01||200701121000

PID|||191919^^^GOOD HEALTH HOSPITAL^MR~11111^^^USSSA^SS|253763|EVERYMAN^ADAM^A||19560129|M|||2222 HOME STREET^^ISHPEMING^MI^49849^""^||555-555-2004|555-555-2004||S|C|10199925^^^GOOD HEALTH HOSPITAL^AN|444-33-3333|||||||||

PV1||I|6N||||0100^ATTEND^AARON^A|0148^ATTEND^AARON^A||SUR|||||||0148^ATTEND^AARON^A|S|1400|A||||||||||||||||SNF|ISH^GREEN ACRES RETIREMENT HOME||GOOD HEALTH HOSPITAL|||||200701102300|200791121005

When Adam A. Everyman's condition became more stable, he returned to 6N for another day (transfer not shown) and then was discharged to the Green Acres Retirement Home.

Update adverse reaction info - unique identifier is provided - event A60 (where unique identifier is provided)

MSH|^~VALUEamp;|ADT|CA.SCA|IE|200701310815-0800|200702010101||ADT^A60^ADT_A60|6757498734|P|2.8|

EVN||200701310815-0800

PID|||987654321098||EVERYWOMAN^EVE^E||19530406|F

PV1||O

PV2||||||||200701310800-0800

IAM|1|DA|^Penicillin|SV^^HL70128|^rash on back|A^^HL70323|12345||AL^^HL70436|19990127||200301311015|NUCLEAR^NEVILLE^H|^Husband||C^^HL70438|MLEE^ATTEND^AARON^A^^^MD||

Update adverse reaction info - allergen code provides unique identifier - event A60 (where the allergen code provides unique identifier)

MSH|^~VALUEamp;|ADT|CA.SCA|IE|200701310815-0800|200702010101||ADT^A60^ADT_A60|6757498734|P|2.8|

EVN||200701310815-0800

PID|||987654321098||EVERYWOMAN^EVE^E||19530406|F

PV1||O

PV2||||||||200701310800-0800

IAM|1|DA|PHM1345^Penicillin^local|SV^^HL70128|^rash on back|A^^HL70323|||AL^^HL70436| 01^Penicillins,Cephalosporins^NDDF DAC|20070127||200701311015| NUCLEAR^NEVILLE^H|^Husband||C^^HL70438|MLEE^ATTEND^AARON^A^^^MD||

IMPLEMENTATION NOTES

Swapping a patient

Some systems may handle this as a single function. Others may require a multiple process in which:

  1. patient A is assigned a temporary location

  2. patient B is assigned patient A's location

  3. patient A is assigned patient B's prior location

This three-step scenario requires three separate transfer messages instead of a single swap message. If all beds in a hospital are occupied, it may be necessary to use a dummy location.

Merging patient/person information

Definitions: Merge, move, and change identifier events

The term "identifier" is used throughout this section. An identifier is associated with a set (or sets) of data. For example, an identifier (PID-3 - Patient Identifier List) may be a medical record number which has associated with it account numbers (PID-18 - Patient Account Number). Account number (PID-18 - Patient Account Number) is a type of identifier which may have associated with it visit numbers (PV1-19 - Visit Number).

This section addresses the events that occur usually for the purposes of correcting errors in person, patient, account, or visit identifiers. The types of errors that occur typically fall into three categories:

  1. Duplicate identifier created

    The registrar fails to identify an existing person, patient, account, or visit and creates a new, "duplicate" record instead of using the existing record. A "merge" operation is used to fix this type of error.

  2. Incorrect identifier selected

    The registrar mistakenly selects the wrong person, patient, or account and creates or attaches a patient, account, or visit underneath the incorrect person, patient, or account. A "move" operation is used to fix this type of error.

  3. Incorrect identifier assigned

    The registrar accidentally types in the wrong new identifier for a person, patient, account, or visit. This type of mistake usually occurs when identifiers are manually assigned (not system generated). A "change identifier" operation is used to fix this type of error.

Hierarchy of Identifiers

This section was written from the perspective of one controlling MPI and does not adequately cover the implementation of peer MPIs or multiple enterprise identifiers. To avoid future problems implementors should carefully examine the inferences of multiple identifiers.

Enterprise level MPI systems may collaborate forming either peer-to-peer or hierarchical relationships. When this occurs, multiple enterprise level identifiers may be required in the context of a single HL7 message. An example of a peer-to-peer MPI relationship might be represented by a data sharing application between the US Department of Veterans Affairs and the US Department of Defense, where each have their own MPI. An example of a hierarchical MPI relationship might be required by the need for local, city, and state organizations to collaborate, where each have an MPI.

These events assume a hierarchy of identifiers exists between person, patient, account, and visit. The hierarchy is as follows:

Level 3 - Patient (identified by PID-3 - Patient Identifier List)

Level 2 - Account (identified by PID-18 - Patient Account Number)

Level 1 - Visit (identified by PV1-19 - Visit Number)

The visit-level identifier PV1-19 - Visit Number is the lowest level identifier and is considered subordinate to the account-level identifier PID-18 - Patient Account Number.

This means that visit identifiers are defined within the context of an account identifier, and implies that visit identifiers are unique within account identifiers. Similarly, account identifiers are subordinate to, and unique within, patient identifiers; patient identifiers are subordinate to, and unique within, person identifiers.

Conversely, the person-level identifier is the highest-level identifier and is considered superior to the patient-level identifiers, which are superior to the account-level identifier, which is superior to any visit-level identifiers.

Note that these events will also apply to environments in which one or more of these levels do not occur. For example, some environments may not have a person (or MPI) level, or they may not have a visit level, or they may have a visit level without an account level. The hierarchy concept is depicted graphically below. For example, Adam Everyman might be assigned an MPI number at the Good Health Hospital network (depicted by the circle). He may have different medical records at two hospitals within the network (depicted by the squares). Associated with each of these medical records are two accounts (depicted by the triangles). Note that the environment illustrated does not support the "visit" level, although in other implementations it might.

Merge

A merge event signals that two distinct records have been combined together into a single record with a single set of identifiers and data surviving at the level of the merge. All records at a level subordinate to the merged identifier are combined under the surviving record. For example, an A40 (merge patient - patient identifier list) event would be sent to signal that two person records (identified by MRG-1 - Prior Patient ID and by PID-3 - Patient ID) have been merged into a single record. All of the identifiers, accounts, and visits under the person record are not merged together - they are instead combined under the same person record. The following figure graphically depicts the merge event:

Note: It is not the intent of the merge definition to define the application or implementation specifics of how various systems or environments define, use or handle non-surviving information. "Non-surviving" in this document implies that a data set was existing in a fashion that was incorrect. Merging it into a new data set in itself implies that where there were two datasets, there is now only one. The means by which any system or environment conveys this new data set and the absence of the previous data set to the user is application specific. It is noted that some systems may still physically keep these "incorrect" datasets for audit trail or other purposes.



Move

A "move" involves transferring one or more datasets (identified by a subordinate identifier) from one superior identifier at the next hierarchical level to another superior identifier at the next hierarchical level, while all identifiers involved retain their original value. An exception to retaining the original identifier value may occur if any of the subordinate source identifiers already exist under the target superior identifier. In this case the identifier value may have to be renumbered in order to be uniquely identified under the target superior identifier. (Refer to section 3.5.2.2.8, "A45 - Move visit information" for an illustration of this.)

A move event signals that a patient, account, or visit has been moved from one person, patient, or account, respectively, to another. All records at a subordinate level are also moved. For example, an A43 (move patient information - patient identifier list) event would be sent to signal that a medical records administrator has moved a medical record attached to an incorrect person to a correct person. The following figure graphically depicts the move event:

Note:    The move event implies that all data related to the incorrect source ID and its subordinate IDs (specified in the MRG segment) will be moved to the correct target ID (specified in the PID or PV1 segment). Specifying each subordinate ID in repeating PID/MRG/PV1 sets is optional but not recommended.



Change identifier

A change identifier event signals that a single person, patient, account, or visit identifier has been changed. It does not reflect a merge or a move; it is simply a change of an identifier. For example, a "Change Identifier" event would be sent to signal that the registrar has changed an incorrectly assigned person identifier to a correct person identifier. The following picture graphically depicts this event:

Source and target identifiers

Merge, move, and change events reference target and source identifiers. The incorrect source identifier is specified in the MRG segment. The correct target identifier is identified in the PID or PV1 segment. For example, when you are changing a patient account number the source would be MRG-3 - Prior Patient Account Number. The target is PID-18 - Patient Account Number.

Tightly coupled relationship

When patient/person identifiers are the target in merge, move, or change events, as specified in the PID-2 - Patient ID, PID-3 - Patient Identifier List and PID-4 - Alternate Patient ID-PID, the associated source identifiers in the MRG-4 - Prior Patient ID, MRG-1 - Prior Patient Identifier List, and MRG-2 - Prior Alternate Patient ID, respectively, must be "tightly coupled." Each event that is defined as a merge, move, or change message carries the "tightly" coupled relationship at the appropriate level in one of two ways: first, by virtue of positional placement in the sequence of identifiers; or, second, by identifier type and assigning authority. The methodology used to establish the definition of "tightly coupled" relationship is determined by site negotiation. The recommended definition is by virtue of positional placement in the sequence of identifiers (pairwise). In addition, HL7 allows the use of the second definition by identifier type and assigning authority as an acceptable convention to establish a "tightly coupled" relationship. In the absence of a site negotiated definition, it is assumed that the positional placement of the identifiers is the default method.

The list of identifiers can be aligned positionally in their respective segment fields and processed by the receiving system by virtue of their order. This is sometimes referred to as an "ordered pairwise" relationship and is described further in section 3.5.2.1.7, "Ordered pairwise relationship".

Alternatively, the uniqueness of the identifiers included in the message is determined by the combination of identifier type and assigning authority. It is assumed that both sending system and receiving system can inspect both of these qualifiers as a message is constructed or processed to determine the "tightly coupled" relationship between the identifiers. This can be referred to as "identifier type/assigning authority" relationship and is described further in section 3.5.2.1.8, "Identifier type/assigning authority relationship".

The pairing of identifiers between the MRG segment fields and their associated identifiers in the PID or PV1 segment are defined below:

Person

PID-2 - Patient ID

with

MRG-4 - Prior Patient ID

Patient

Pid-3 - Patient Identifier List

with

MRG-1 - Prior Patient Identifier List

and by

Explicit order of identifiers in the list

or by

<identifier type code> and <assigning authority> field components

PID-4 - Alternate Patient ID

with

MRG-2 - Prior Alternate Patient ID

Account

PID-18 - Patient Account Number

with

MRG-3 - Prior Patient Account Number

Visit

PV1-19 - Visit Number

with

MRG-5 - Prior Visit Number

PV1-50 - Alternate Visit ID

with

MRG-6 - Prior Alternate Visit ID



Ordered pairwise relationship

In a strict sense, this type of relationship is characterized by a one-to-one association based on type (e.g., medical record number to medical record number, etc.) and the corresponding order of the element, and is typically found in list or set operations. However, for purposes of practical implementation, this relationship will be defined as a simple one-for-one pairing, as exists between the PID-3 - Patient Identifier List and the MRG-1 - Prior Patient Identifier List. In other words, elements "A", "B", and "C" in the first list would directly correspond to elements "X", "Y", and "Z" in the second list. No consideration is made to the type or value of the corresponding elements; it is the explicit order of the elements which controls the association process. This scenario could be expressed as follows:

List1 = {A,B,C}

List2 = {X,Y,Z}

A : X

B : Y

C : Z



A second scenario may arise which deserves mention. As in the list example above, elements "A", "B", and "C" in the first list would "pair-up" with elements "X", "Y", "Z", "Q", "R", and "S" in the second list. Again, no consideration is made to the type or value of the corresponding elements; it is the order and presence which controls the association process. This scenario could be expressed as follows:

List1 = {A,B,C}

List2 = {X,Y,Z,Q,R,S}

A : X

B : Y

C : Z

: Q

: R

: S



In the second scenario, the last three elements "Q", "R", and "S" are not affected and their value remains as if no association had been made.

A third scenario may arise which deserves mention. As in the list example above, elements "A", "B", "C", "D", "E", and "F" in the first list would "pair-up" with elements "X", "Y", and "Z" in the second list. Again, no consideration is made to the type or value of the corresponding elements; it is the order and presence which controls the association process. This scenario could be expressed as follows:

List1 = {A,B,C,D,E,F}

List2 = {X,Y,Z}

A : X

B : Y

C : Z

D :

E :

F :



In the third scenario, the last three elements "D", "E", and "F" are not affected and their value remains the same as if no association had been made.

Identifier type / assigning authority relationship

As stated earlier, the uniqueness of the identifiers included in a message can be determined by the combination of identifier type (t) and assigning authority (a). It is assumed that both sending system and receiving system can inspect both of these qualifiers as a message is constructed or processed. This method is used to determine the "tightly coupled" relationship between the identifiers. The implementation of this relationship exists between the PID-3 - Patient Identifier List and the MRG-1 - Prior Patient Identifier List. In other words, elements "B^t2^a1", "C^t3^a1", "D^t4^a1", "A^t1^a1", "E^t5^a1", and "F^t6^a1" in the first list would be associated with elements "X^t1^a1", "Y^t2^a1", and "Z^t3^a1 in the second list. This scenario could be expressed as follows:

List1 = {B^t2^a1,C^t3^a1,D^t4^a1,A^t1^a1,E^t5^a1,F^t6^a1}

List2 = {X^t1^a1,Y^t2^a1,Z^t3^a1}

B^t2^a1 : Y^t2^a1

C^t3^a1 : Z^t3^a1

D^t4^a1 :

A^t1^a1 : X^t1^a1

E^t5^a1 :

F^t6^a1 :



In this scenario, the three elements which do not have corresponding identifier type and assigning authority "D^t4^a1", "E^t5^a1", and "F^t6^a1" are not affected and their value remains the same as if no association had been made.

A second scenario may arise which deserves mention. In the case of identifier type and assigning authority definition, the elements "A^t1^a1", "B^t2^a1", and "C^t3^a1" in the first list would be associated with elements "X^t4^a1", "Y^t2^a1", "Z^t3^a1", "Q^t1^a1", "R^t5^a1", and "S^t6^a1" in the second list. No consideration is made to the order of the identifiers; it is the identifier type and assigning authority of the corresponding elements which controls the association process. This scenario could be expressed as follows:

List1 = {A^t1^a1,B^t2^a1,C^t3^a1}

List2 = {X^t4^a1,Y^t2^a1,Z^t3^a1, Q^t1^a1,R^t5^a1,S^t6^a1}

A^t1^a1 : Q^t1^a1

B^t2^a1 : Y^t2^a1

C^t3^a1 : Z^t3^a1

: X^t4^a1

: R^t5^a1

: S^t6^a1



In the second scenario, the three elements which do not have corresponding identifier type and assigning authority "X^t4^a1", "R^t5^a1", and "S^t6^a1" are not affected and their value remains the same as if no association had been made.

Global merge and move message construct versus repeating segment message constructs

A flexible message construct is provided for merge trigger events. The message construct allows for a repeating set of PID, optional PD1, MRG, and optional PV1 segments as illustrated below:

MSH

EVN

{ PID

[PD1]

MRG

[PV1]

}

Trigger events support the concept of a global move or merge, where all the subordinate identifiers are moved or merged. For example, the use case for A41 (merge account-patient account number) (Section 3.5.2.2.3, "A41 - merge account - patient account number (global)") illustrates a merge on the patient account number (PID-18 - Patient Account Number). All subordinate identifiers (PV1-19 - Visit Number) are moved to the target PID-18 - Patient Account Number Identifier, even though they are not specified in the message.

A repeating segment message construct supports reporting of the subordinate identifiers using the repeating segments. This is illustrated in the use case for A40 (merge patient - patient identifier list) (Section 3.5.2.2.2, "A40 - merge patient - patient identifier list (repeating segment)," A41 (merge account - patient account number) (Section 3.5.2.2.4, "A41 - merge account - patient account number (repeating segment)"), and A45 (move visit information-visit number) (Section 3.5.2.2.9 "A45 - move visit information - visit number (repeating segment)"). Specifying each subordinate ID in repeating segments is optional but not recommended. This construct can be used when renumbering of identifiers is necessary as illustrated in Sections 3.5.2.2.2, "A40 - merge patient - patient identifier list (repeating segment)," 3.5.2.2.4, "A41 - merge account - patient account number (repeating segment)," and 3.5.2.2.9, "A45 - move visit information - visit number (repeating segment)," or to explicitly identify individual subordinate identifiers as illustrated in Section 3.5.2.2.9, "A45 - move visit information - visit number (repeating segment)."

Identifier renumbering

When renumbering of identifiers occurs, the repeating segment construct may be required in order to report identifier number changes. When renumbering occurs, the incorrect source identifier is specified in the MRG segment and the correct target identifier is reported in the PID or PV1 segment. Refer to the use case for A41 (merge account-patient account number) for an illustration.

Superior identifier reporting

When merging or moving subordinate numbers, the higher level, "superior" identifiers should be included in the message. For example, when merging an account where the target is PID-18 - Patient Account Number and the source is MRG-3 - Prior Patient Account Number, the higher level patient identifiers (PID-3 -Patient Identifier List and MRG-1 - Prior Patient Identifier List) and person identifiers (PID-2 - Patient ID and MRG-4 - Prior Patient ID) should also be reported in the message.

Trigger events

The intent of trigger events A40 (merge patient- patient identifier list), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-patient identifier list), A44 (move account information-patient account number), A45 (move visit information-visit number), A47 (change patient identifier list), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID) is to reconcile distinct sets of existing person/patient data records that have been entered under different identification numbers, either deliberately or because of errors. Ideally, following any of these trigger events, all of the person/patient data should be accessible under whatever surviving identifiers were specified in the messages. Because of substantial differences in database architectures and system-dependent data processing requirements or limitations, the exact meaning and implementation of these events must be negotiated between systems.

A40 - merge patient - patient identifier list

A40 - Merge patient - patient identifier list

Use Case - During the admission process, the registrar does not find a record for patient EVE EVERYWOMAN in the ADT system and creates a new record with patient identifier MR2. EVE EVERYWOMAN has actually been to the healthcare facility several times in the past under her maiden name, Eve Maidenname with patient identifier MR1. The problem persists for a while. During that time, several more accounts are assigned to Eve under her newly created patient ID MR2. Finally, the problem is discovered and Medical Records merges her two charts together leaving patient identifier MR1. All the accounts (ACCT1, ACCT2) that were assigned to MR2 are combined under MR1 as a result.

Target: PID-3 - Patient Identifier List (Note: PID-18 - Patient Account Number is not valued; all accounts associated with MR2 are combined under MR1). To merge PID-18 - Patient Account Number data only, use event A41 (merge account-patient account number). To move PID-18 - Patient Account Number data use event A44 (move account information-patient account number).

Source: MRG-1 - Prior Patient Identifier List) (Note: MRG-3 - Prior Patient Account Number is not valued; all accounts associated with MR2 are combined under MR1.)

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A40^ADT_A39|00000003|P|2.8|<cr>

EVN|A40|200301051530<cr>

PID|||MR1^^^XYZ||MAIDENNAME^EVE|....<cr>

MRG|MR2^^^XYZ<cr>

Before Merge

After Merge

MR1 MR2

ACCT1 ACCT1

ACCT2 ACCT2

MR1

ACCT1

ACCT2

ACCT1

ACCT2

Implementation considerations: This scenario exists when two medical records are established for the same person.

Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. In the example above, the implementation allowed the older demographic information (in the PID) to survive. The demographics implied by the IDs in the MRG segment, did not survive. Surviving and non-surviving demographic information is application and implementation specific. An A08 (update patient information) event should be sent and/or negotiated as necessary to provide for implementation and application-specific needs.


A40 - merge patient - patient identifier list (repeating segment)

A40 - Merge patient - patient identifier list

Use Case - During the admission process, the registrar does not find a record for patient EVE EVERYWOMAN in the Patient Administration system and creates a new record with patient identifier MR2. EVE EVERYWOMAN has actually been to the healthcare facility several times in the past under her maiden name, EVE MAIDENNAME with patient identifier MR1. The problem persists for a while. During that time, several more accounts are assigned to EVE under her newly created patient ID MR2. Finally, the problem is discovered and Medical Records merges her two charts together leaving patient identifier MR1. All the accounts (ACCT1, ACCT2) that were assigned to MR2 are combined under MR1 as a result. Since the account numbers are not unique, they are also renumbered.

Target: PID-3 - Patient Identifier List and PID-18 - Patient Account Number

Source: MRG-1 - Prior Patient Identifier List and MRG-3 - Prior Patient Account Number

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A40^ADT_A39|00000003|P|2.8|<cr>

EVN|A40|200301051530<cr>

PID|||MR1^^^XYZ||EVERYWOMAN^EVE|||||||||||||ACCT3<cr>

MRG|MR2^^^XYZ||ACCT1<cr>

PID|||MR1^^^XYZ||EVERYWOMAN^EVE|||||||||||||ACCT4<cr>

MRG|MR2^^^XYZ||ACCT2<cr>

Before Merge

After Merge

MR1 MR2

ACCT1 ACCT1*

ACCT2 ACCT2*

MR1

ACCT1

ACCT2

ACCT3*

ACCT4*

*accounts renumbered

Implementation considerations: This scenario exists when two medical records are established for the same person.

If the account numbers are not unique (as implied by the After Merge example above) and renumbering of the accounts is required, you must use repeating segments as illustrated in the Example Transaction. Refer to Section 3.5.2.1.9, "Global merge and move message construct versus repeating segment message constructs," for additional information regarding message construct.

Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. In the example above, the implementation allowed the older demographic information (in the PID) to survive. The demographics implied by the IDs in the MRG segment, did not survive. Surviving and non-surviving demographic information is application and implementation specific. An A08 (update patient information) event should be sent and/or negotiated as necessary to provide for implementation and application specific needs.


A41 - merge account - patient account number (global)

This event illustrates the concept of a global merge as defined in Section 3.5.2.1.9, "Global merge and move message construct versus repeating segment message constructs."

A41 - Merge account information - patient account number

Use Case - Eve Everywoman (patient identifier MR1) is a recurring outpatient at the Physical Therapy clinic at hospital XYZ with account number ACCT1. She has visited the clinic several times. When she arrives for therapy, a new registrar does not realize she already has an account and opens a new one with account number ACCT2. When the mistake is discovered, the two accounts are merged together, combining all visits under account ACCT1.

Target: PID-18 - Patient Account Number

Source: MRG-3 - Prior Patient Account Number

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A41^ADT_A39|00000005|P|2.8|<cr>

EVN|A41|200301051530<cr>

PID|||MR1^^^XYZ||EVERYWOMAN^EVE||19501010|M|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>

MRG|MR1^^^XYZ||ACCT2<cr>

Before Merge

After Merge

MR1

ACCT1

96124

96126

ACCT2

96128

96130

MR1

ACCT1

96124

96126

96128

96130

Implementation considerations: This scenario exists when two accounts are established for the same patient.

The PV1 segment is not valued since this event is really a merge at the PID-18 - Patient Account Number level. All identifiers below the PID-18 - Patient Account Number are combined under the surviving Patient Account Number.

Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. Surviving and non-surviving demographic information is application and implementation specific. An A08 (update patient information) event should be sent and/or negotiated as necessary to provide for implementation and application-specific needs.


A41 - merge account - patient account number (repeating segment)

This event illustrates the concept of a repeating segment merge as defined in 3.5.2.2.1.

A41 - Merge account - patient account number

Use Case - Eve Everywoman (patient identifier MR1) is a recurring outpatient at the Physical Therapy clinic at hospital XYZ with account number ACCT1. She has visited the clinic several times. When she arrives for therapy, a new registrar does not realize she already has an account and opens a new one with account number ACCT2. When the mistake is discovered, the two accounts are merged together, combining all visits under account ACCT1.

Target: PID-18 - Patient Account Number and PV1-19 - Visit Number

Source: MRG-3 - Prior Patient Account Number and MRG-5 - Prior Visit Number

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A41^ADT_A39|00000005|P|2.8|<cr>

EVN|A41|200301051530<cr>

PID|||MR1^^^XYZ||EVERYWOMAN^EVE||19501010|F|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>

MRG|MR1^^^XYZ||ACCT2||VISIT1<cr>

PV1|1|I|||||||||||||||||VISIT3<cr>

PID|||MR1^^^XYZ||EVERYWOMAN^EVE||19501010|F|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>

MRG|MR1^^^XYZ||ACCT2||VISIT2

PV1|1|I|||||||||||||||||VISIT4<cr>

Before Merge

After Merge

MR1

ACCT1

VISIT1

VISIT2

ACCT2

VISIT1*

VISIT2*

*Visits erroneously assigned

MR1

ACCT1

VISIT1

VISIT2

VISIT3**

VISIT4**

**Visits combined and renumbered as a result of merging the account

Implementation considerations: This scenario exists when two accounts and associated visits are established for the same patient.

Repeating PID/MRG/PV1 segments report each Account Number and Visit Number affected. This construct is required since the visits are renumbered in this example.

Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. Surviving and non-surviving demographic information is application and implementation specific. An A08 (update patient information) event should be sent and/or negotiated as necessary to provide for implementation and application-specific needs.


A42 - Merge visit - visit number

A42 - Merge visit - visit number

Use Case - A42 (merge visit -visit number) - Eve Everywoman (patient identifier MR1) is a recurring outpatient at the Physical Therapy clinic at hospital XYZ with account number ACCT1. She has visited the clinic several times. When she arrives for therapy, two different registrars create a new visit numbers. The mistake is not discovered immediately and clinical data is recorded under both visit numbers. When the mistake is discovered, the two visits are merged together, leaving visit VISIT1.

Target: PV1-19 - Visit Number

Source: MRG-5 - Prior Visit Number

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A42^ADT_A39|00000005|P|2.8|<cr>

EVN|A42|200301051530<cr>

PID|||MR1^^^XYZ||EVERYEWOMAN^EVE||19501010|F|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>

MRG|MR1^^^XYZ||ACCT1||VISIT2<cr>

PV1|1|I|||||||||||||||||VISIT1

Before Merge

After Merge

MR1

ACCT1

VISIT1

VISIT2

MR1

ACCT1

VISIT1

Implementation considerations: This scenario exists when two visits are established in error for the same patient and episode of care.


A43 - move patient information - patient identifier list

A43 - Move patient information - patient identifier list

Use Case - information from ABC HMO is loaded to a repository system each month. Eve Everywoman is entered in January and assigned Enterprise Number 1 (E1). Eve has visited Hospital XYZ and is assigned medical record number MR1. Evi Everywoman (a different person) is also a member of ABC HMO loaded to the repository and assigned Enterprise Number E2. Evi has visited Hospital XYZ and is assigned medical record number MR1. Evi visits Clinic DEF where she is assigned medical record number MR2 which is erroneously associated with Eve's Enterprise Number (E1). When the error is discovered MR2 is moved from Enterprise Number E1 to E2.

Target: PID-2 - Patient ID

Source: MRG-4 - Prior Patient ID

Example transaction:

MSH|^~VALUEamp;|REPOSITORY|ENT|RSP1P8|MCM|200301051530|SEC|ADT^A43^ADT_A43|0000009|P|2.8|<cr>

EVN|A43|200301051530<cr>

PID|1|E2|MR2^^^ABCHMO|||EVERYWOMAN^EVI|....<cr>

MRG|MR2^^^ABCHMO|||E1<cr>

Before Move

After Move

E1 E2

MR1 MR1

MR2

E1 E2

MR1 MR1

MR2

Implementation considerations: PID-3 - Patient Identifier List and MRG-1 - Prior Patient Identifier List are the same value since the PID-3 value does not change in this scenario.

The example above would be expressed as follows. In the following example, the assigning authority ENT1 represents an Enterprise and the PE identifier type code represents the Person's Enterprise number. The MR1 identifier is omitted from the message because it is not moved.

MSH|^~VALUEamp;|REPOSITORY|ENT|RSP1P8|MCM|200301051530|SEC|ADT^A43^ADT_A43|0000009|P|2.8|<cr>

EVN|A43|200301051530<cr>

PID|1||E2^^^ENT1^PE~MR2^^^ABCHMO^MR|||EVERYWOMAN^EVI|....<cr>

MRG|E1^^^ENT1^PE~MR2^^^ABCHMO^MR|. . .<cr>


A44 - move account information - patient account number

A44 - Move account information - patient account number

Use Case - During the admission process, the admitting clerk uses the Medical Record Number of Adam Everyman III (MR1) instead of Adam Everyman, Jr. (MR2). The Patient Administration system assigns the new admission account number ACCT2. When the mistake is discovered, account ACCT2 is moved to the correct Medical Record, MR2. The account number is not changed.

Target: PID-3 - Patient Identifier List and PID-18 - Patient Account Number (Note: PID-18 - Patient Account Number and MRG-3 - Prior Patient Account Number will be the same since the account number does not change in this scenario).

Source: MRG-1 - Prior Patient Identifier List and MRG-3 - Prior Patient Account Number (NOTE: MRG-3 - Prior Patient Account Number must be valued to indicate which account to move)

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A44^ADT_A43|00000007|P|2.8|<cr>

EVN|A44|200301051530<cr>

PID|||MR2^^^XYZ||Everyman^Adam^A^JR||19501010|M|||123 EAST STREET^^NY^NY^10021||(212)111-3333|||S||ACCT2<cr>

MRG|MR1^^^XYZ||ACCT2<cr>

Before Move

After Move

MR1 MR2

ACCT1 ACCT1

ACCT2

MR1 MR2

ACCT1 ACCT1

ACCT2

Implementation considerations: This scenario exists when two medical records legitimately exist for two different people and an account is incorrectly associated with the wrong medical record number.


A45 - move visit information - visit number (repeating segment)





A45 - Move visit information - visit number

Use Case - Eve Everywoman (patient identifier MR1) is a recurring outpatient at the Physical Therapy and Speech Therapy clinics at hospital XYZ. She is assigned a different account for each clinic; her account number for Physical Therapy is ACCT1 and her account number for Speech Therapy is X1. However, on two different occasions, the Speech Therapy registrar accidentally assigned her visits (96102 and 96104) to the Physical Therapy account. The problem is later discovered and the corresponding visits are moved to the correct account.

Target: PID-18 - Patient Account Number and PV1-19 - Visit Number.

Source: MRG-3 - Prior Patient Account Number and MRG-5 - Prior Visit Number.

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A45^ADT_A45|00000005|P|2.8|<cr>

EVN|A45|200301051530<cr>

PID|||MR1^^^XYZ||EVERYWOMAN^EVE||19501010|M|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||X1<cr>

MRG|MR1^^^XYZ||ACCT1||96102<cr>

PV1||O|PT||||||||||||||||96102<cr>

MRG|MR1^^^XYZ||ACCT1||96104<cr>

PV1||O|PT||||||||||||||||96104<cr>

Before Move

After Move

MR1

ACCT1

96100

96102*

96104*

X1

96101

96103

96105

*Visits erroneously assigned

MR1

ACCT1

96100

X1

96101

96102

96103

96104

96105

In the above transaction/implementation, the application that generated the message assigns unique visit numbers.

Implementation Considerations: In this scenario the repeating MRG/PV1 construct is used to indicate which visits are moved, as illustrated in the Example Transaction. MRG-5 - Prior Visit Number and PV1-19 - Visit Number are the same values because the visit numbers do not change. Refer to section 3.5.2.1.9, "Global merge and move message construct versus repeating segment message constructs," for additional information regarding message construct.


A45 - move visit information - visit number (repeating segment)





A45 - Move visit information - visit number

Use Case -Eve Everywoman (patient identifier MR1) is a recurring outpatient at the Physical Therapy and Speech Therapy clinics at hospital XYZ. She is assigned a different account for each clinic; her account number for Physical Therapy is ACCT1 and her account number for Speech Therapy is X1. However, on two different occasions, the Speech Therapy registrar accidentally assigned her visits (VISIT2 and VISIT3) to the Physical Therapy account. The problem is later discovered and the corresponding visits are moved to the correct account.

Target: PID-18 - Patient Account Number and PV1-19 - Visit Number.

Source: MRG-3 - Prior Patient Account Number and MRG-5 - Prior Visit Number.

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A45^ADT_A45|00000005|P|2.8|<cr>

EVN|A45|200301051530<cr>

PID|||MR1^^^XYZ||EVERYWOMAN^EVE||19501010|M|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||X1<cr>

MRG|MR1^^^XYZ||ACCT1||VISIT2<cr>

PV1||O|PT||||||||||||||||VISIT4<cr>

MRG|MR1^^^XYZ||ACCT1||VISIT3<cr>

PV1||O|PT||||||||||||||||VISIT5<cr>

Before Move

After Move

MR1

ACCT1

VISIT1

VISIT2*

VISIT3*

X1

VISIT1

VISIT2

VISIT3

*Visits erroneously assigned

MR1

ACCT1

VISIT1

X1

VISIT1

VISIT2

VISIT3

VISIT4**

VISIT5**

**visits moved and renumbered

In the above transaction/implementation, the application that generated the message allows non-unique visit numbers.

Implementation Considerations: If Visit Numbers are not unique (as implied by the After Move example above) and renumbering of the visits is required, you must use a repeating MRG/PV1 construct as illustrated in the Example Transaction. Refer to 3.5.2.2.1, "A40 - merge patient - patient identifier list," for additional information regarding message construct.


A47 - change patient identifier list

A47 - Change patient identifier list

Use Case - The Medical Records Department of XYZ hospital uses a system of manual medical record number assignment. During the admission process, the registrar accidentally assigned the wrong Medical Record Number (MR2 instead of MR1) to ADAM EVERYMAN. Since the correct Medical Record has not yet been assigned to any patient, no merge takes place. The Patient Identifier List is simply changed.

Target: PID-3 - Patient Identifier List

Source: MRG-1 - Prior Patient Identifier List

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A47|00000002|P|2.8|<cr>

EVN|A47|200301051530<cr>

PID|||MR1^^^XYZ||EVERYMAN^ADAM||19501010|M|||987 SOUTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>

MRG|MR2^^^XYZ||ACCT1<cr>

Before Change

After Change

MR2

ACCT1

MR1

ACCT1

Implementation considerations: None.


A49 - change patient account number

A49 - Change patient account number

Use Case - Patients are automatically assigned an account number by hospital XYZ's Patient Administration system at admission. However, when the Patient Administration system is down, the admitting clerk manually assigns account numbers from a pool of downtime account numbers. ADAM EVERYMAN (patient ID MR1) was manually assigned downtime account number ACCT1. When the Patient Administration system came back up, the admitting clerk accidentally entered the wrong account number, X1, into the system. When the problem was later discovered, the account number was changed from X1 to ACCT1.

Target: PID-18 - Patient Account Number

Source: MRG-3 - Prior Patient Account Number

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A49^ADT_A30|00000006|P|2.8|<cr>

EVN|A49|200301051530<cr>

PID|||MR1^^^XYZ||EVERYMAN^ADAM||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|ACCT1<cr>

MRG|MR1^^^XYZ||X1<cr>

Before Change

After Change

MR1

X1

MR1

ACCT1

Implementation Considerations: None.


A50 - change visit number

A50 - Change visit number

Use Case - Patients are automatically assigned a visit number by hospital XYZ's Patient Administration system at check-in. However, when the Patient Administration system is down, the admitting clerk manually assigns visit numbers from a pool of downtime numbers. ADAM EVERYMAN (patient ID MR1) was manually assigned downtime visit number VISIT1. When the Patient Administration system came back up, the admitting clerk accidentally entered the wrong visit number, VISIT2, into the system. When the problem was later discovered, the visit number was changed from VISIT2 to VISIT1.

Target: PV1-19 - Visit Number

Source: MRG-5 - Prior Visit Number

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A50^ADT_A50|00000006|P|2.8|<cr>

EVN|A50|200301051530<cr>

PID|||MR1^^^XYZ||EVERYMAN^ADAM||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|ACCT1<cr>

MRG|MR1^^^XYZ||ACCT1||VISIT2<cr>

PV1|1|O||3|||99^BROWN^JERRY|||ONC||||1||VIP|99^BROWN^JERRY|O/P|VISIT1...<cr>

Before Change

After Change

MR1

ACCT1

VISIT2

MR1

ACCT1

VISIT1

Implementation considerations: None.


A51 - change alternate visit ID

A51 - Change alternate visit ID

Use Case - Patients are automatically assigned an alternate visit number by hospital XYZ's Patient Administration system at check-in. However, when the Patient Administration system is down, the admitting clerk manually assigns alternate visit numbers from a pool of downtime numbers. ADAM EVERYMAN was manually assigned downtime alternate visit number AV1. When the Patient Administration system came back up, the admitting clerk accidentally entered the wrong alternate visit number, AV2, into the system. When the problem was later discovered, the alternate visit number was changed from AV2 to AV1.

Target: PV1-50 - Alternate Visit ID

Source: MRG-6 - Prior Alternate Visit ID

Example Transaction:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SECURITY|ADT^A51^ADT_A50|00000006|P|2.8|<cr>

EVN|A51|200301051530<cr>

PID|||MR1^^^XYZ||EVERYMAN^ADAM||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|ACCT1<cr>

MRG|MR1^^^XYZ||ACCT1|||AV2<cr>

PV1|1|O||3|||99^BROWN^JERRY|||ONC||||1||VIP|99^BROWN^JERRY|O/P|V1|SP|||||||||||||||||||A|||||19990902081010||||||AV1<cr>

Before Change

After Change

MR1

ACCT1

VISIT1

AV2

MR1

ACCT1

VISIT1

AV1

Implementation Considerations: None.


Example using multiple messages

A47 - Change patient identifier list and A49 - Change patient account number

Use Case - Patients are automatically assigned Medical Records Numbers and account numbers by hospital XYZ's Patient Administration system at admission. However, when the Patient Administration system is down, the admitting clerk manually assigns account numbers and Medical Records numbers from a pool of downtime numbers. ADAM EVERYMAN was manually assigned downtime Medical Record Number MR1 and downtime account number A1. When the Patient Administration system came back up, the admitting clerk accidentally enters the wrong Medical Record Number (MR2) and account number (X1) into the system. The error occurred because she was reading from the paperwork for a different downtime admit not yet entered into the Patient Administration system. The problem is quickly discovered, and the medical record number and account number was fixed accordingly. Since the other downtime admit had not yet been entered into the Patient Administration system, no merge was required.

Target: PID-3 - Patient Identifier List (Message 1) and PID-18 - Patient Account Number (Message 2)

Source: MRG-1 - Prior Patient Identifier List (Message 1) and MRG-3 - Prior Patient Account Number (Message 2)

Example Transaction - Message 1:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A47^ADT_A30|00000006|P|2.8|<cr>

EVN|A47|200301051530<cr>

PID|||MR1^^^XYZ^MR||EVERYMAN^ADAM||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|X1<cr>

MRG|MR2^^^XYZ^MR|<cr>

Example Transaction - Message 2:

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A49^ADT_A30|00000006|P|2.5<cr>

EVN|A49|200301051530<cr>

PID|||MR1^^^XYZ^MR||EVERYMAN^ADAM||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|ACCT1<cr>

MRG|MR1^^^XYZ^MR||X1<cr>

Before Change

After Change

MR2

X1

MR1

ACCT1

Implementation considerations: Message 1 (A47) changes the patient identifier list. Message 2 (A49) changes the account number.


Example using multiple messages

A44 - Move account information - patient account number and A49 - Change patient account number

Use Case - During the admitting process, the admitting clerk uses the Medical Record Number of Adam Everyman, III (MR1) instead of Adam Everyman, Jr. (MR2). The Patient Administration system assigns the new admission account number A1. When the mistake is discovered, the account is moved to the correct Medical Record, MR2. The Patient Administration system generates a new account number as a result: number X1.

Target: PID-3 - Patient Identifier List (Message 1) and PID-18 - Patient Account Number (Message 2)

Source: MRG-1 - Prior Patient Identifier List (Message 1) and MRG-3 - Prior Patient Account Number (Message 2)

Example Transaction (Message 1):

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A44^ADT_A43|00000007|P|2.8|<cr>

EVN|A44|200301051530<cr>

PID|||MR2^^^XYZ^MR||EVERYMAN^ADAM^A^JR||19501010|M|||123 EAST STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>

MRG|MR1^^^XYZ^MR||ACCT1<cr>

Example Transaction (Message 2):

MSH|^~VALUEamp;|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A49^ADT_A30|00000007|P|2.5<cr>

EVN|A49|200301051530<cr>

PID|||MR2^^^XYZ^MR||EVERYMAN^ADAM^A^JR||19501010|M|||123 EAST STREET^^NY^NY^10021||(212)111-3333|||S||X1<cr>

MRG|MR2^^^XYZ^MR||ACCT1<cr>

Before Change

After Change

MR1 MR2

ACCT1

MR1 MR2

X1

Implementation Considerations: Message 1, A44 (move account information-patient account number), moves the account from MR1 to MR2. Message 2, A49 (change patient account number), changes the account number.


Patient record links

Linking two or more patients does not require the actual merging of patient information as discussed in Section 3.5.2, "Merging patient/person information;" following a link trigger event, sets of affected patient data records should remain distinct. However, because of differences in database architectures, there may be system-dependent limitations or restrictions regarding the linking of one or more patients that must be negotiated.

There are multiple approaches for implementing Master Patient Indexes. It is useful for the purpose of MPI mediation to support two types of linkage. Explicit linkage requires a message declaring a link has been made between multiple identifiers. Implicit linkage is performed when a receiving system infers the linkage from the presence of multiple identifiers present in PID-3 - Patient Identifier List.

In an MPI setting, the A24 -link patient information message is preferred for transmitting an explicit link of identifiers whether they are in the same or different assigning authorities. The A37 unlink patient information message is preferred for transmitting the explicit unlinking of identifiers.

Implicit linkage of identifiers, sometimes called passive linking, has been implemented using various messages. An acknowledged method is inclusion of multiple identifiers in PID-3 - Patient Identifier List, which the receiving system implicitly links. An MPI or application that makes such an implicit linkage can generate an A24 - link patient information message to explicitly notify another system of this action.

MPI Integration - an introduction

The purpose of this section is to provide some insight into how HL7 committees have approached the area of MPI integration, as well as to provide concrete examples of how the integration could be done using messages in Version 2.4 and later.

(hidden text)

Definitions - what is an MPI?

There can be quite a bit of confusion as to what defines an MPI. Early definitions called it a Master Patient Index, implying only patient data would be managed. Later the definition was expanded to mean persons in general, including patients, guarantors, subscribers, and even providers; essentially any entity that could be considered a "person." Thus the current acronym MPI generally is inferred to mean Master Person Index.

An MPI is generally used to manage person identification and cross-reference across disparate systems. Healthcare organizations may have several systems handling various different data processing needs, from laboratory to billing, each with its own database of persons and person identifier numbering schemes. Each of these can be called an ID Domain. An MPI can function as a Correlation Manager between these domains, providing a cross-reference of a person's identifiers across each of the domains. Typically an MPI will also have one universal or enterprise identifier that uniquely identifies the person in the MPI itself. The domain for this identifier may or may not be the domain for clients of the MPI.

MPI functionality also typically includes methods to provide an identifier for a person, given a set of traits or demographics for that person. An example of the use of this is for a client system to query the MPI for a person given a set of demographics. The MPI uses matching algorithms to find possible matching persons, and returns to the client system the identifiers for those persons.

This section currently deals only with MPI functionality related to persons in the context of Version 2.4 and later. It is assuming integration using Version 2.4 and later ADT messages, and the functionality surrounding finding and identifying a person.

HL7 and CORBAmed PIDS

There has been an effort to harmonize the modeling work that has been done in the CORBAMed Patient Identification Service (PIDS) with the HL7 message set, with an eye toward HL7 Version 3.0. You may see evidence of CORBAMed modeling in this implementation, but that should not be taken as evidence that full harmonization has taken place. There is much work left to do in this area.

MPI QUERY for person lookup and identification

Several QBP/RSP queries have been developed to aid in the integration of systems with an MPI. They consist of several Qxx/Kxx trigger/response pairs and one Q24/K24 trigger/response pair. The following table lists their functions:

MPI QBP/RSP Queries

Query

Name

MPI Use

Q21/K21

Get Person Demographics

Given a person identifier, return the PID and optionally the PD1 segments for the matching person.

Q22/K22

Find Candidates

Given some demographics, optionally a match threshold and algorithm, find and return a list of matching persons.

Q23/K23

Get Corresponding Identifiers

Given a person's identifier and a list of identifier domains, return the person's identifiers in those domains.

Q24/K24

Allocate Identifiers

Given a list of identifier domains, return new identifiers for those domains. Should not link to a person, just reserve and return identifiers.


The following sections show several scenarios involving looking up a person on a "client" system, and how it can be integrated to an MPI. The basic flow is for a user to enter person information on the client system, and the client system using services of the MPI to match the user's input to a person that exists somewhere on the two systems.

The scenarios are differentiated on two variables:

ID Creator - Which system assigns new person identifiers for the client system. This can either be the MPI or the client system.

Person Existence - On which system the person record currently exists - the client system, the MPI, or both.

Client system assigns identifier, person exists on MPI only

In this scenario, a client system (e.g., a registration system) will query an MPI for a person that does not currently exist on the client system. The MPI returns a list of one or more possible matching candidates, and one is chosen by the user on the client system. The client system assigns the person an identifier and an update is sent to the MPI to notify it of the new assigned identifier.

Figure 3-1 - Client system assigns identifier, person exists on MPI only

The messages are defined as follows:

Q22/K22 Find Candidates - This signals the MPI to search its database for a list of persons that match the demographic criteria sent in the query, using whatever algorithms it has at its disposal, or using the algorithm optionally specified in the query. The response includes a list of "candidates" that matched the criteria in the query, one PID segment for each candidate. The query can also specify the identifier domains to return in PID-3 - Patient Identifier List, so that the client system identifier and the MPI enterprise identifier could be returned for each match.

Q21/K21 Get Person Demographics - Once a candidate is chosen from the list, another query may be done to retrieve the full set of demographics for that person.

A24 or A01/A04/A05 - This transaction is to update the MPI with the new identifier the client system has created for the person. It is acceptable for systems to simply send an A01 Admit/visit notification, A04 Register a patient or A05 Pre-admit a patient as may have been done traditionally, with the new client system identifier and the existing MPI enterprise identifier in PID-3. However an A24 Link patient information may be sent instead, with one PID segment containing the MPI enterprise identifier for the person, and the second PID segment containing the new registration system identifier.

Client system assigns identifier, person exists on both systems

In this scenario, a client system (e.g., a registration system) will query an MPI for a person, and the person record exists on both systems. The MPI returns a list of possible matching candidates, and one is chosen by the user on the client system. The client system simply asks the MPI for an updated set of demographics and does not assign an identifier since the person already exists with an identifier on the client system.

Prior to querying the MPI, the client system may query its own database to reduce network transactions. However, the full searching capabilities of the MPI may be preferred to the client system in order to prevent the selection of the wrong person.

Figure 3-2 - Client system assigns identifier, person exists on both systems

The message flow is identical to the message flow in the 3.5.4.5 example, with the exception that the final update to the MPI is not needed in order to give the MPI a new identifier for the person. The MPI should already have the client system identifier from previous transactions.

An ADT event may be sent later by the client system simply to update the MPI with any demographic changes that occur.

Client system assigns identifier, person exists on neither system

In this scenario, a client system (e.g., a registration system) will query an MPI for a person, and the person does not exist on either system. The MPI returns a list of possible matching candidates, or possibly an empty list. The user does not choose one, and a new person record is created.

Figure 3-3 - Client system assigns identifier, does not exist on either system

The message flow again begins with a Q22/K22 Find Candidates query. The response may or may not contain a list of candidates.

If the client system assigns a person identifier when the record is created, an A28 Add person information could be sent to the MPI to notify it of the record creation. If the client system does not create an identifier until the registration is completed, the A01, A04 or A05 events could serve the purpose of notifying the MPI of an added person and identifier. The fact that the person will have an identifier unknown to the MPI, and no enterprise identifier, will allow the MPI to infer that a person record is being added.

When the person record is added to the MPI with the new identifier, an enterprise identifier is assigned, and ancillary systems may be notified of the new person record creation.

MPI assigns identifier, person exists on MPI

In the next set of three scenarios, it is assumed that a third party (ID Manager) creates identifiers for the client system, and for these examples the MPI fulfills this role. The QBP/RSP queries support this service.

Figure 3-4 - Example of two healthcare organizations merging

Figure 3-4 shows a case where identifiers may need to be assigned by a third party. In the example, East Health Organization had one identifier domain (XXXX numbers) for both the hospital registration system and the outpatient clinic registration numbers. Coordination was done through the use of pre-printed charts for new patients, which prevented the two systems from using the same XXXX number for two patients.

Later West Health Organization is bought and merged with East. West has been using its own identifier domain (YYYY numbers). An MPI is also implemented to keep a cross-reference between the two systems, and assigns its own enterprise identifier (EEEE number) to each patient.

Because the organization is attempting to go paperless, East decides to forgo its pre-printed charts, but still keep the XXXX numbers. Since the pre-printed charts are no longer there to keep numbers from being re-used between the hospital and clinic, a third party is needed to assign the XXXX numbers.

A patient arrives at East Hospital that had never been there, but had been to West previously. To register the patient, the hospital system submits a Find Candidates Q22/K22 query to get from the MPI a list of possible matching patients. The user finds the patient since she had been to West previously. Since the patient is new to East, she must be given a new East identifier (XXXX number). An Allocate Identifiers A56/K24 query is sent from the East Hospital to the MPI and the MPI generates an XXXX number and returns it. Later when the registration is finished, an A24 Link Person Information message is sent to notify the MPI that the allocated identifier has been assigned to a patient

In the following first scenario, the person record exists on the MPI, however it does not exist on the client system. The message flow assumes that the MPI is assigning identifiers for the client system that are not the enterprise identifiers. If this were not the case, the Allocate Identifiers A56/K24 query would not be needed.

Figure 3-5 - MPI assigns identifier, person exists on MPI

The message flow is similar to previous examples, with the exception of the Q24/K24 Allocate Identifiers query and the final A24 Link Patient Information message:

Q24/K24 Allocate Identifiers - This query is for the client system to ask the MPI for an identifier in the client system's domain. It is not to assign the identifier to a particular person record, but rather just to reserve an identifier for later use.

A24 Link patient information - This message is to notify the MPI that the previously allocated identifier has been assigned to a person. The A24 should include one PID segment with the new identifier and one PID segment with the MPI enterprise identifier.

MPI assigns identifier, person exists on both systems

is scenario is identical to the scenario in 3.5.4.2 Client system assigns identifier, person exists on both systems.

RegistrationSystemMatching criteriaenteredFind Candidates Q22DetermineCandidate ListChoose matchResponse K22 - List of matchesGet Person Demographics Q21RetrievedemographicsResponse K21Open patientrecordand continue withregistrationMPIRegistrationSystemMatching criteriaenteredFind Candidates Q22DetermineCandidate ListChoose matchResponse K22 - List of matchesGet Person Demographics Q21RetrievedemographicsResponse K21Open patientrecordand continue withregistrationMPI

Figure 3- 6 - MPI assigns identifier, person exists on both systems

MPI assigns identifier, person exists on neither system

In this scenario, the person does not exist on either system. The message flow is similar to 3.5.4.7, "MPI assigns identifier, person exists on MPI"; however, there is no need for the Q21/K21Get person Demographics query as a double-check for the user since the person does not exist on the MPI. Also, after the person is registered and the identifier assigned, an A28 Add Person Information is sent to the MPI to have it add the person to its database and assign an enterprise identifier.

Figure 3-7 - MPI assigns identifier, person exists on neither system

Usage notes: Non-human PID patient identification

The species attribute is required for non-human patients. The breed and strain attributes are conditional. Thus if the strain attribute is populated, the species attribute must be populated, but the breed attribute is optional. The production class attribute is optional, but if populated the species attribute must also be populated. The name of the animal populates the PID-5 attribute, component 2. The last name of the owner may populate component 1 of PID-5. Owner information is transmitted in the NK1 segment.

Example 1: Mrs. EVERYWOMAN brings her 9 year old, female, spayed miniature poodle, Fluffy, into the Allstate University, Veterinary Medical Teaching Hospital to have skin growths removed. The poodle resides with Mrs. EVERYWOMAN in her apartment at 2222 Home Street, Apt 123, in Ann Arbor, MI 11111, Washtenaw County;

MSH|^~VALUEamp;||ALLSTATE UNIV VMTH|||200702171830||ADT^A04

PID|1||A83245^^^VMTH^MR^UCD||EVERYWOMAN^Fluffy^^^^^^D||19901001|S|||2222 Home St^Apt 123^Ann Arbor^MI^11111^USA^^^Washtenaw||||||||||||MI||||||||||||L-80700^Canine, NOS^SNM3|L-80832^Miniature Poodle, NOS^SNM3

NK1|1|EVERYWOMAN^EVE^M^^Mrs.^^L|O|2222 Home St^Apt 123^Ann Arbor^MI ^11111^USA^^^Washtenaw|(530) 555-4325^^^emeverywoman123@AOL.COM||CP|

PV1|1|O||R|||0045^BARKER^BART^^Dr.^DVM||||||||||||||||||||||||||||||||||||199902161015

OBX|1|NM|21611-9^Age^LN||9|yr

OBX|2|NM|3141-9^Body Weight^LN||16|lb

Example 2: Over the Hill Horses owns the Morgan horse mare named Breeze that is referred by Dr. Equine of Foothill Veterinary Clinic for colic (acute abdominal pain) to the Allstate University, Veterinary Medical Teaching Hospital. The manager of the farm and contact person is Randall "Buck" Shins, who works at the farm headquarters in Ypsilanti, MI, 11111:

MSH|^~VALUEamp;||Foothill Veterinary Clinic||Allstate Univ VMTH|200702171830||ADT^A04

PID|1||N324256^^^^^Foothill Vet Clinic||^Breeze^^^^^^D|||F|||^^^MI^^^^^Lassen||||||||||||||||||19981123|Y|||||L-80400^Horse^SNM3|L-80431^Morgan horse^SNM3||BR

NK1|1||||||O|||||Over the Hill Horses|||||||||||||||||~Shins^Buck^^^Mr.^^N|(530) 555-9843^^^Buckshins@OvertheHill.com|2222 Farm Rd ^Suite A^Ypsilanti^MI^11111^^^^Lassen

PV1|1|E||R|||^Equine^^^Dr.^DVM||||||||||||||||||||||||||||||||||||199903102013

REFERENCED ORGANIZATIONS AND DOCUMENTS

  • HCFA, Health Care Financing Administration, U.S. Dept. of Health and Human Services, USA

  • CMS, Centers for Medicare/Medicaid Services

  • ERISA: Employment Retirement Income Security Act, USA

  • LOINC: Lab Observation Identifier Names and Codes, Regenstrief Institute, Indianapolis, IN, USA

  • CORBAMed Person Identification Service (PIDS) - Adopted Submission. 12 February 1998.