Chapter Chair: |
Freida
B. Hall |
Chapter Chair: |
Michael
Hawver |
Editor: |
Klaus
D. Veil |
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.
Each
trigger event is listed below, along with the applicable form of the message
exchange. The notation used to describe the sequence, optionality, and
repetition of segments is described in Chapter 2, Section 2.12, "Chapter
Formats for Defining HL7 Messages."
The trigger events that follow are all served by the ADT unsolicited update and
the ACK response.
In the following trigger event descriptions, the term "admitted" patient will
be used instead of "inpatient" to indicate any patient classes that are
assigned to a patient bed for at least a few hours. "Non-admitted" patients
will be used instead of "outpatients" to indicate any patient classes that are
not assigned to a bed, but rather to an exam room or another type of encounter
room or clinic waiting room.
We recognize that different hospital systems use different definitions of the
terms "inpatient," "outpatient," "emergency room," and "recurring patient
classes," or handle these patients differently. Therefore, the trigger events
are not defined as specific to any patient class. The patient class for any
visit related information must be specified in PV1-2 - Patient class in
order to enable each system to handle the transaction properly. This means
that both the event and the patient class must be checked in order to determine
how to handle the transaction. If a certain patient class can sometimes be
assigned to a bed and sometimes not, for example, "observation patients," then
PV1-3 - Assigned patient location must also be checked.
In order to accommodate non-admitted patient events without using the same
trigger events as those for admitted patients, we would need an entirely new
set of non-admitted patient events. If we do that, disparate systems would
still have a hard time agreeing about whether certain patient classes should
use the admitted patient events or the non-admitted patient events, because of
the differences between how admitted and non-admitted patients are defined and
handled.
Both admitted and non-admitted patient events are transmitted using most of the
same events. The meaning or interpretation of those events will depend upon
the patient class.
The information that is included in any of these trigger event transactions can
be more than the minimum necessary to communicate the event. Any of the
fields can be used that are in the segments listed for the message. As many or
as few fields can be used as are agreed upon during implementation. However,
please note that when the contents of a field change for a field that is not
necessarily related to the trigger event, it is a matter for implementation
negotiation as to whether the receiving systems can capture this changed
data.
In order to alleviate this ambiguity, we recommend (but do not require) that
the A08 (update patient information) transaction be used to update fields that
are not necessarily related to any of the other trigger events. For example,
if a Patient Administration system allows the patient's medical service and
attending doctor to be changed in the transfer function, the Patient
Administration system should send two HL7 messages. It should send an A02
(transfer a patient) event to reflect the location change, followed by an A08
(update patient information) event to reflect the change in the medical service
and the attending doctor.
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 "John Doe" (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 - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
Begin Date/Time and the ROL-6 - Role End Date/Time in the ROL
segment, with the applicable ROL-3 - Role Code. Refer to section 12.3.3
for the definition of the ROL segment.
ADT^A01^ADT_A01 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
[{ NK1 }] |
Next of Kin / Associated Parties |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ AL1 }] |
Allergy Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ |
||
PR1 |
Procedures |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[{ GT1 }] |
Guarantor |
6 |
[{ |
||
IN1 |
Insurance |
6 |
[ IN2 ] |
Insurance Additional Info. |
6 |
[{ IN3 }] |
Insurance Additional Info - Cert. |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[ ACC ] |
Accident Information |
6 |
[ UB1 ] |
Universal Bill Information |
6 |
[ UB2 ] |
Universal Bill 92 Information |
6 |
[ P DA ] |
Patient Death and Autopsy |
3 |
ACK^A01^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
Begin Date/Time and the ROL-6 - Role End Date/Time in the ROL
segment, with the applicable ROL-3 - Role Code. Refer to section 12.3.3
for the definition of the ROL segment.
ADT^A02^ADT_A02 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
P V1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[ PD A ] |
Patient Death and Autopsy |
3 |
ACK^A02^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 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. When other important fields change, it is recommended
that the A08 (update patient information) event be used in addition.
The ROL - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
Begin Date/Time and the ROL-6 - Role End Date/Time in the ROL
segment, with the applicable ROL-3 - Role Code. Refer to section 12.3.3
for the definition of the ROL segment.
ADT^A03^ADT_A03 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ |
||
PR1 |
Procedures |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[{ OBX }] |
Observation/Result |
7 |
[ PDA ] |
Patient Death and Autopsy |
3 |
ACK^A03^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 that 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 - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
Begin Date/Time and the ROL-6 - Role End Date/Time in the ROL
segment, with the applicable ROL-3 - Role Code. Refer to section 12.3.3
for the definition of the ROL segment.
ADT^A04^ADT_A01 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
[{ NK1 }] |
Next of Kin / Associated Parties |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ AL1 }] |
Allergy Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ |
||
PR1 |
Procedures |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[{ GT1 } ] |
Guarantor |
6 |
[{ |
||
IN1 |
Insurance |
6 |
[ IN2 ] |
Insurance Additional Info. |
6 |
[{ IN3 }] |
Insurance Additional Info - Cert. |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[ ACC ] |
Accident Information |
6 |
[ UB1 ] |
Universal Bill Information |
6 |
[ UB2 ] |
Universal Bill 92 Information |
6 |
[ PDA ] |
Patient Death and Autopsy |
3 |
ACK^A04^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Visit level
providers (corresponding to the PV1 data) are reported in the ROL segment
following the PV1/PV2 segments. Providers related to a specific procedure are
reported in the ROL segment following the PR1 segment. Providers related to a
specific insurance are reported in the ROL segment following the IN1/IN2/IN3
segments. To communicate the begin and end date of the provider, use the
ROL-5 - Role Begin Date/Time and the ROL-6 - Role End Date/Time
in the ROL segment, with the applicable ROL-3 - Role Code. Refer to
section 12.3.3 for the definition of the ROL segment.
ADT^A05^ADT_A05 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
[{ NK1 }] |
Next of Kin / Associated Parties |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ AL1 }] |
Allergy Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ |
||
PR1 |
Procedures |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[{ GT1 }] |
Guarantor |
6 |
[{ |
||
IN1 |
Insurance |
6 |
[ IN2 ] |
Insurance Additional Info. |
6 |
[{ IN3 }] |
Insurance Additional Info - Cert. |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[ ACC ] |
Accident Information |
6 |
[ UB1 ] |
Universal Bill Information |
6 |
[ UB2 ] |
Universal Bill 92 Information |
6 |
ACK^A05^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 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, but the MRG segment is used here for MRG-3 - Prior patient
account number.
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 - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Visit level
providers (corresponding to the PV1 data) are reported in the ROL segment
following the PV1/PV2 segments. Providers related to a specific procedure are
reported in the ROL segment following the PR1 segment. Providers related to a
specific insurance are reported in the ROL segment following the IN1/IN2/IN3
segments. To communicate the begin and end date of the provider, use the
ROL-5 -Role begin date/time and the ROL-6 - Role end date/time in
the ROL segment, with the applicable ROL-3 - Role code. Refer to
section 12.3.3 for the definition of the ROL segment.
ADT^A06^ADT_A06 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
[ MRG ] |
Merge Information |
3 |
[{ NK1 }] |
Next of Kin / Associated Parties |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ AL1 }] |
Allergy Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ |
||
PR1 |
Procedures |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[{ GT1 }] |
Guarantor |
6 |
[{ |
||
IN1 |
Insurance |
6 |
[ IN2 ] |
Insurance Additional Info. |
6 |
[{ IN3 }] |
Insurance Additional Info - Cert. |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[ ACC ] |
Accident Information |
6 |
[ UB1 ] |
Universal Bill Information |
6 |
[ UB2 ] |
Universal Bill 92 Information |
6 |
ACK^A06^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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.
We leave it 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 only used here for MRG-3 - Prior
patient account number. PV1-19 - Visit number can 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 - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
begin date/time and the ROL-6 - Role end date/time in the ROL
segment, with the applicable ROL-3 - Role code. Refer to section 12.3.3
for the definition of the ROL segment.
ADT^A07^ADT_A06 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
[ MRG ] |
Merge Information |
3 |
[{ NK1 }] |
Next of Kin / Associated Parties |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ O BX }] |
Observation/Result |
7 |
[{ AL1 }] |
Allergy Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ |
||
PR1 |
Procedures |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[{ GT1 }] |
Guarantor |
6 |
[{ |
||
IN1 |
Insurance |
6 |
[ IN2 ] |
Insurance Additional Info. |
6 |
[{ IN3 }] |
Insurance Additional Info - Cert. |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[ ACC ] |
Accident Information |
6 |
[ UB1 ] |
Universal Bill Information |
6 |
[ UB2 ] |
Universal Bill 92 Information |
6 |
ACK^A07^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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
recommend that the A08 transaction be used to update fields that are not
related to any of the other trigger events. The A08 event can include
information specific to an episode of care, but it can also be used for
demographic information only.
The ROL - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
begin date/time and the ROL-6 - Role end date/time in the ROL, with
the applicable ROL-3 - Role code. Refer to section 12.3.3 for the
definition of the ROL segment.
ADT^A08^ADT_A01 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
[{ NK1 }] |
Next of Kin / Associated Parties |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ AL1 }] |
Allergy Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ |
||
PR1 |
Procedures |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[{ GT1 }] |
Guarantor |
6 |
[{ |
||
IN1 |
Insurance |
6 |
[ IN2 ] |
Insurance Additional Info. |
6 |
[{ IN3 }] |
Insurance Additional Info - Cert. |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[ ACC ] |
Accident Information |
6 |
[ UB1 ] |
Universal Bill Information |
6 |
[ UB2 ] |
Universal Bill 92 Information |
6 |
[PDA] |
Patient Death and Autopsy |
3 |
ACK^A08^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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.
The DG1 segment remains in this message for backward compatibility
only.
ADT^A09^ADT_A09 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ DG1 }] |
Diagnosis Information |
6 |
ACK^A09^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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, HALLWAY) to the new
assigned location. If the patient is arriving at a temporary location (such as
the O/R, X-RAY, LIMBO, the 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. The
DG1 segment remains in this message for backward compatibility only.
ADT^A10^ADT_A09 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ DG1 }] |
Diagnosis Information |
6 |
ACK^A10^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 is 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.
The DG1 segment remains in this message for backward compatibility
only.
ADT^A11^ADT_A09 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ DG1 }] |
Diagnosis Information |
6 |
ACK^A11^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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.
The DG1 segment remains in this message for backward compatibility
only.
ADT^A12^ADT_A09 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[ DG1 ] |
Diagnosis Information |
6 |
ACK^A12^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 that 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 ROL - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
begin date/time and the ROL-6 - Role end date/time in the ROL, with
the applicable ROL-3 - Role code. Refer to section 12.3.3 for the
definition of the ROL segment.
ADT^A13^ADT_A01 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
[{ NK1 }] |
Next of Kin / Associated Parties |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ AL1 }] |
Allergy Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ |
||
PR1 |
Procedures |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[{ GT1 }] |
Guarantor |
6 |
[{ |
||
IN1 |
Insurance |
6 |
[ IN2 ] |
Insurance Additional Info. |
6 |
[{ IN3 }] |
Insurance Additional Info - Cert. |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[ ACC ] |
Accident Information |
6 |
[ UB1 ] |
Universal Bill Information |
6 |
[ UB2 ] |
Universal Bill 92 Information |
6 |
[ PDA ] |
Patient Death and Autopsy |
3 |
ACK^A13^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 ROL - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
begin date/time and the ROL-6 - Role end date/time in the ROL, with
the applicable ROL-3 - Role code. Refer to section 12.3.3 for the
definition of the ROL segment.
ADT^A14^ADT_A05 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ P D1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
[{ NK1 }] |
Next of Kin / Associated Parties |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ROL}] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ AL1 }] |
Allergy Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ |
||
PR1 |
Procedures |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[{ GT1 }] |
Guarantor |
6 |
[{ |
||
IN1 |
Insurance |
6 |
[ IN2 ] |
Insurance Additional Info. |
6 |
[{ IN3 }] |
Insurance Additional Info - Cert. |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[ ACC ] |
Accident Information |
6 |
[ UB1 ] |
Universal Bill Information |
6 |
[ UB2 ] |
Universal Bill 92 Information |
6 |
ACK^A14^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
begin date/time and the ROL-6 - Role end date/time in the ROL
segment, with the applicable ROL-3 - Role code. Refer to section 12.3.3
for the definition of the ROL segment.
The DG1 segment remains in this message for backward compatibility
only.
ADT^A15^ADT_A15 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ DG1 }] |
Diagnosis Information |
6 |
ACK^A15^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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.
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 - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
begin date/time and the ROL-6 - Role end date/time in the ROL, with
the applicable ROL-3 - Role code. Refer to section 12.3.3 for the
definition of the ROL segment.
ADT^A16^ADT_A16 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
ACK^A16^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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.6.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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient (1) Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient (1) Visit |
3 |
[ PV2 ] |
Patient (1) Visit - Additional Info. |
3 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result (1) |
7 |
PID |
Patient (2) Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient (2) Visit |
3 |
[ PV2 ] |
Patient (2) Visit - Additional Info. |
3 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result (2) |
7 |
ACK^A17^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
Event
A18 has been retained for backward compatibility. The A18 event was used
to merge current and previous patient identification numbers: PID-3 -
patient identifier list, PID-2 - patient ID, PID-4 - alternate
patient ID-PID, and PID-18 - patient account number. This procedure
is required, for example, when a previous patient is registered under a new
patient identification number because of an error, or because there was
insufficient time to determine the actual patient identification number. The
merge event occurs when a decision is made to combine the information under
either the new or the old identifier(s). The PID segment contains the
surviving patient ID information. The MRG segment contains the non-surviving
information.
From V2.3.1 onwards events A40 (merge patient-patient identifier list), A41
(merge account-patient account number), and A42 (merge visit-visit number)
should be utilized in place of the A18 event.
This merge event is non-specific in that, as a result of the merge, several
patient identifiers may or may not have changed. For sites requiring (or
desiring) greater specificity with regard to this type of message, new events
A40 (merge patient-patient identifier list), A41 (merge account-patient account
number) and A42 (merge visit-visit number)) are now available as alternatives.
See Section 3.6.2, "Merging patient/person information," for a discussion of
issues related to implementing patient merge events.
ADT^A18^ADT_A18 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
PV1 |
Patient Visit |
3 |
ACK^A18^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
The
following trigger event is served by QRY (a query from another system) and ADR
(a response from an Patient Administration system.)
Another application determines a need for Patient Administration data about a
patient and sends a query to the Patient Administration system. The Who Filter
in the QRD can identify the patient or account number upon which the query is
defined and can contain a format code of "R" (record-oriented). If the query
is based on the Patient ID and there are data associated with multiple
accounts, the problem of which account data should be returned becomes an
implementation issue. The ADT event-type segment, if included in the response,
describes the last event for which the Patient Administration system initiated
an unsolicited update.
The ROL - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
begin date/time and the ROL-6 - Role end date/time in the ROL, with
the applicable ROL-3 - Role code. Refer to section 12.3.3 for the
definition of the ROL segment.
QRY^A19^QRY_A19 |
Patient Query |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QRD |
Query Definition |
2 |
[ QRF ] |
Query Filter |
2 |
ADR^A19^ADR_A19 |
ADT Response |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
[ QAK ] |
Query Acknowledgment |
5 |
QRD |
Query Definition |
2 |
[ QRF ] |
Query Filter |
2 |
{ |
||
[ EVN ] |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
[{ NK1 }] |
Next of Kin / Associated Parties |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ AL1 }] |
Allergy Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ |
||
PR1 |
Procedures |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[{ GT1 }] |
Guarantor |
6 |
[{ |
||
IN1 |
Insurance |
6 |
[ IN2 ] |
Insurance Additional Info. |
6 |
[{ IN3 }] |
Insurance Additional Info - Cert. |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[ ACC ] |
Accident Information |
6 |
[ UB1 ] |
Universal Bill Information |
6 |
[ UB2 ] |
Universal Bill Information |
6 |
} |
||
[ DSC ] |
Continuation Pointer |
2 |
In
addition to single-patient responses, the ADT record-oriented query/response
needs to support responses containing multiple patients for the following query
types (by subject filter): return census for a nursing unit (ANU), return
patients matching a name search (APN), and return patients for a given medical
practitioner, physician, etc. (APP).
For multiple patient responses, additional values for QRD-9 - What subject
filter may be used, such as:
IP |
Inpatient |
OP |
Outpatient |
DC |
Discharged |
For
the ANU subject filter, the Patient Administration systems response must have
some method for conveying the fact that some beds are empty (as well as for
returning the data for all patients in the occupied beds). This method will
function as follows:
a) Bed Full
Regular { [EVN], PID, PV1 } segment group for each patient with
PV1-40 - bed status value of "O" occupied.
b) Bed Empty
In this case, all fields in the corresponding EVN, PID, and PV1
segments are null except for the following fields in the PV1 segment.
* PV1-3 - assigned patient location contains the new bed location
information
* PV1-40 - bed status contains one of the following values: U
(unoccupied), H (housekeeping), or C (closed).
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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
NPU |
Non-Patient Update |
3 |
ACK^A20^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
ACK^A21^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
ACK^A22^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[ { DB1 } ] |
Disability Information |
3 |
[ { OBX } ] |
Observation/Result |
7 |
ACK^A23^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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.6.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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient (1) Identification |
3 |
[ PD1 ] |
Patient (1) Additional Demographics |
3 |
[ PV1 ] |
Patient (1) Visit |
3 |
[{ DB1 }] |
Patient (1) Disability Information |
3 |
PID |
Patient (2) Identification |
3 |
[ PD1 ] |
Patient (2) Additional Demographics |
3 |
[ PV1 ] |
Patient (2) Visit |
3 |
[{ DB1 }] |
Patient (2) Disability Information |
3 |
ACK^A24^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[ { DB1 } ] |
Disability Information |
3 |
[ { OBX } ] |
Observation/Result |
7 |
ACK^A25^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[ { DB1 } ] |
Disability Information |
3 |
[ { OBX } ] |
Observation/Result |
7 |
ACK^A26^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
The
A27 event is sent when an A14 (pending admit) event is canceled, 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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[ { DB1 } ] |
Disability Information |
3 |
[ { OBX } ] |
Observation/Result |
7 |
ACK^A27^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
Begin Date/Time and the ROL-6 - Role End Date/Time in the ROL, with
the applicable ROL-3 - Role Code. Refer to section 12.3.3 for the
definition of the ROL segment.
ADT^A28^ADT_A05 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
[{ NK1 }] |
Next of Kin / Associated Parties |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ AL1 }] |
Allergy Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ |
||
PR1 |
Procedures |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[{ GT1 }] |
Guarantor |
6 |
[{ |
||
IN1 |
Insurance |
6 |
[ IN2 ] |
Insurance Additional Info. |
6 |
[{ IN3 }] |
Insurance Additional Info - Cert. |
6 |
[{ ROL }] |
Role |
12 |
}] |
||
[ ACC ] |
Accident Information |
6 |
[ UB1 ] |
Universal Bill Information |
6 |
[ UB2 ] |
Universal Bill 92 Information |
6 |
ACK^A28^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[ { DB1 } ] |
Disability Information |
3 |
[ { OBX } ] |
Observation/Result |
7 |
ACK^A29^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
Event
A30 has been retained for backward compatibility only. An A30 event was
used to merge person information on an MPI. From V 2.3.1 onwards, the A40
(merge patient-patient identifier list) events should be used to merge patient
information for a current episode. The "incorrect MRN" identified on the MRG
segment (MRG-1 - prior patient identifier list) is to be merged with the
"correct MRN" identified on the PID segment (PID-3 - patient identifier
list). The "incorrect MRN" then no longer exists. All PID data associated
with the "correct MRN" are treated as updated information.
The MRNs involved may or may not have active or inactive cases associated with
them. Any episode of care that was previously associated with the "incorrect
MRN" is now associated with the "correct MRN." A list of these cases is not
provided.
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.
An A30 (merge person information) is intended for merging person records
without merging patient identifiers.
ADT^A30^ADT_A30 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
ACK^A30^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 - Role Segment is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3 segments.
To communicate the begin and end date of the provider, use the ROL-5 - Role
Begin Date/Time and the ROL-6 - Role End Date/Time in the ROL
segment, with the applicable ROL-3 - Role Code. Refer to section 12.3.3
for the definition of the ROL segment.
ADT^A31^ADT_A05 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD 1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
[{ NK1 }] |
Next of Kin / Associated Parties |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
[{ DB1 }] |
Disability Information |
3 |
[{ OBX }] |
Observation/Result |
7 |
[{ AL1 }] |
Allergy Information |
3 |
[{ DG1 }] |
Diagnosis Information |
6 |
[ DRG ] |
Diagnosis Related Group |
6 |
[{ PR1 |
Procedures |
6 |
{ ROL }] |
Role |
12 |
}] |
||
[{ GT1 }] |
Guarantor |
6 |
[ |
||
{ IN1 |
Insurance |
6 |
[ IN2 ] |
Insurance Additional Info. |
6 |
[{ IN3 }] |
Insurance Additional Info - Cert. |
6 |
[{ ROL }] |
Role |
12 |
} |
||
] |
||
[ ACC ] |
Accident Information |
6 |
[ UB1 ] |
Universal Bill Information |
6 |
[ UB2 ] |
Universal Bill 92 Information |
6 |
ACK^A31^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[ { DB1 } ] |
Disability Information |
3 |
[ { OBX } ] |
Observation/Result |
7 |
ACK^A32^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[ { DB1 } ] |
Disability Information |
3 |
[ { OBX } ] |
Observation/Result |
7 |
ACK^A33^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
Event
A34 has been retained for backward compatibility only. From V2.3.1
onwards, event A40 (Merge patient - patient identifier list) should be used
instead. Only the patient identifier list has changed as a result of the merge.
See Section 3.6.2, "Merging patient/person information," for a discussion of
issues related to the implementation of merge messages.
An A34 (merge patient information-patient ID only) event was intended for
merging or changing patient identifiers. It was used to change patient
identifiers on all of this patient's existing accounts.
ADT^A34^ADT_A30 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
ACK^A34^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error Information |
2 |
Event
A35 has been retained for backward compatibility only. From V2.3.1
onwards, event A41 (Merge patient - patient account number) should be used
instead. Only the patient account number has changed as a result of the merge.
See Section 3.6.2, "Merging patient/person information," for a discussion of
issues related to the implementation of merge messages.
An A35 (merge patient information-account number only) event was intended for
merging or changing an account number only.
ADT^A35^ADT_A30 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
ACK^A35^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
Event
A36 has been retained for backward compatibility only. From V2.3.1 onwards,
events A40 (merge patient - patient identifier list) and A41 (merge patient -
patient account number) should be used instead. Both patient identifier list
and the patient account number have changed as a result of the merge. See
Section 3.6.2, "Merging patient/person information," for a discussion of issues
related to the implementation of merge messages.
ADT^A36^ADT_A30 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
ACK^A36^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
The
A37 event unlinks two patient identifiers.
ADT^A37^ADT_A37 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient (1) Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[ PV1 ] |
Patient (1) Visit |
3 |
[ { DB1 } ] |
Disability Information |
3 |
PID |
Patient (2) Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[ PV1 ] |
Patient (2) Visit |
3 |
[ { DB1 } ] |
Disability Information |
3 |
ACK^A37^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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.
ADT^A38^ADT_A38 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[ { DB1 } ] |
Disability Information |
3 |
[ { OBX } ] |
Observation/Result |
7 |
[ { DG1 } ] |
Diagnosis Information |
6 |
[DRG] |
Diagnosis Related Group |
6 |
ACK^A38^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
Event
A39 has been retained for backward compatibility only. From V2.3.1 onwards,
event A40 (merge patient - patient identifier list) should be used instead. A
merge has been done at the patient identifier level. That is, two PID-2 -
patient ID identifiers have been merged into one.
An A39 event is used to signal a merge of records for a person that was
incorrectly filed under two different PID-2 - patient IDs. The
"incorrect source patient ID" identified in the MRG segment (MRG-4 - prior
patient ID) is to be merged with the required "correct target patient ID"
identified in the PID segment (PID-2 - patient ID). The "incorrect
source patient ID" 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.
Since this event is a merge at the PID-2 - patient ID identifier level,
PID-3 - patient identifier list and MRG-1 - prior patient identifier
list are not required.
The patient IDs involved in identifying the persons may or may not be patients,
who may or may not have accounts, which may or may not have visits. An A39
(merge person-patient ID) event is intended for merging person records without
merging other subordinate identifiers. Any other subordinate identifiers that
were previously associated with the "incorrect source patient ID" are now
associated with the "correct target patient ID." 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-2 - patient ID
identifier). For those environments that may require changes to these other
subordinate identifiers because of an A39 (merge person-patient ID), it is
required that the old and new identifiers be a "tightly coupled" pair.
See sections 3.5.2 "
Merging
patient/person information" and <IP_ADDRESS>.2 "Merge," for a discussion of issues
related to the implementation of merge messages.
All data associated with the "correct target patient ID" are treated as updated
information.
ADT^A39^ADT_A39 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
{ PID |
Patient Identification |
3 |
[ PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
[ PV1] |
Patient Visit |
3 |
} |
ACK^A39^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 <IP_ADDRESS>.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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
{ PID |
Patient Identification |
3 |
[ PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
[ PV1] |
Patient Visit |
3 |
} |
ACK^A40^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 <IP_ADDRESS>.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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
{ PID |
Patient Identification |
3 |
[ PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
[ PV1] |
Patient Visit |
3 |
} |
ACK^A41^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 <IP_ADDRESS>.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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
{ PID |
Patient Identification |
3 |
[ PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
[ PV1] |
Patient Visit |
3 |
} |
ACK^A42^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 <IP_ADDRESS>.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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
{ PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
} |
ACK^A43^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 <IP_ADDRESS>.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_A43 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
{ PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
} |
ACK^A44^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 <IP_ADDRESS>.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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
{ MRG |
Merge Information |
3 |
PV1 |
Patient Visit |
3 |
} |
ACK^A45^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
Event
A46 has been retained for backward compatibility only, corresponding with
PID-2 - patient ID, which is also retained for backward compatibility.
From V2.3.1 onwards, event A47 (change patient identifier list) should be used
instead. A change has been done at the patient identifier level. That is, a
PID-2 - patient ID has been found to be incorrect and has been
changed.
An A46 event is used to signal a change of an incorrectly assigned PID-2 -
patient ID value. The "incorrect source patient ID" value is stored in the
MRG segment (MRG-4 - prior patient ID) and is to be changed to the
"correct target patient ID" value stored in the PID segment (PID-2 - patient
ID).
The patient ID involved in identifying the person may or may not represent a
patient, who may or may not have accounts, which may or may not have visits.
An A46 (change patient ID) event is intended for changing the value of the
patient identifier without affecting other subordinate identifiers. Any other
subordinate identifiers that were previously associated with the "incorrect
source patient ID" are now associated with the "correct target patient ID."
Specification of these other subordinate identifiers is not required to be
provided.
This event and the message syntax do, however, allow for the specification of
"new subordinate identifiers" (in addition to the PID-2 - patient ID
identifier). For those environments that may require changes to these
other subordinate identifiers because of this A46 (change patient ID) event, it
is required that the old and new identifiers be a "tightly coupled" pair.
Since this event is a change at the PID-2 - patient ID identifier level,
PID-3 - patient identifier list and MRG-1 - prior patient identifier
list are not required.
See Sections 3.5.2, "Merging patient/person information," and <IP_ADDRESS>.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 person information) event be used in
conjunction with this message. However, all PID data associated with the new
patient ID is treated as updated information.
ADT^A46^ADT_A30 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
ACK^A46^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 <IP_ADDRESS>.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_A30 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
ACK^A47^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
Event
A48 has been retained for backward compatibility only, corresponding with
PID-4 - alternate Patient ID-PID, which is also retained for backward
compatibility. From V2.3.1 onwards, event A47 (change patient identifier list)
should be used instead. A change has been done at the alternate patient
identifier level. That is, a PID-4 - alternate patient ID-PID has been
found to be incorrect and has been changed.
An A48 event is used to signal a change of an incorrectly assigned alternate
patient identifier value. The "incorrect source alternate patient ID" value is
stored in the MRG segment (MRG-2 - prior alternate patient ID) and is to
be changed to the "correct target alternate patient ID" value stored in the PID
segment (PID-4 - alternate patient ID-PID).
The alternate patient ID involved in identifying the patient may or may not
have accounts, which may or may not have visits. An A48 (change alternate
patient ID) event is intended for changing the value of the alternate patient
identifier without affecting other subordinate identifiers. Any other
subordinate identifiers that were previously associated with the "incorrect
source alternate patient ID" are now associated with the "correct target
alternate patient ID." 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-4 - alternate patient
ID-PID identifier). For those environments that may require changes to
these other subordinate identifiers because of this A48 (change alternate
patient ID) event, it is required that the old and new identifiers be a
"tightly coupled" pair.
Each superior identifier associated with this alternate patient identifier
level should have the same value in both the PID and MRG segments.
See Sections 3.5.2, "Merging patient/person information," and <IP_ADDRESS>.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^A48^ADT_A30 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
ACK^A48^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 <IP_ADDRESS>.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_A30 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
ACK^A49^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error Information |
2 |
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 <IP_ADDRESS>.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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
PV1 |
Patient Visit |
3 |
ACK^A50^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 <IP_ADDRESS>.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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
MRG |
Merge Information |
3 |
PV1 |
Patient Visit |
3 |
ACK^A51^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
ACK^A52^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
ACK^A53^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 is used in this message to communicate providers not
specified elsewhere. Person level providers with an ongoing relationship are
reported in the ROL segment following the PID/PD1 segments. Providers
corresponding to the PV1 data are reported in the ROL segment following the
PV1/PV2 segments. Providers related to a specific procedure are reported in
the ROL segment following the PR1 segment. Providers related to a specific
insurance are reported in the ROL segment following the IN1/IN2/IN3
segments.
To communicate the begin and end date of the attending, referring, or admitting
doctor, use the ROL-5 - Role begin date/time and the ROL-6 - Role end
date/time in the ROL segment, with the applicable ROL-3 - Role code.
Refer to section 12.3.3 for the definition of the ROL segment. Use "UP" in
ROL-2 - Action code.
ADT^A54^ADT_A54 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[ PD1 ] |
Additional Demographics |
3 |
[{ ROL }] |
Role |
12 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
[{ ROL }] |
Role |
12 |
ACK^A54^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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_A52 |
ADT Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
PV1 |
Patient Visit |
3 |
[ PV2 ] |
Patient Visit - Additional Info. |
3 |
ACK^A55^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
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 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 |
QBP^Q21^QBP_Q21 |
Query By Parameter |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QPD |
Query Parameter Definition Segment |
5 |
RCP |
Response Control Parameters |
5 |
[ DSC ] |
Continuation Pointer |
2 |
RSP^K21^RSP_K21 |
Segment Pattern Response |
Group Control |
Comment |
Support Indicator |
Chapter |
|---|---|---|---|---|---|
MSH |
Message Header |
2 |
|||
MSA |
Message Acknowledgement |
2 |
|||
[ERR] |
Error |
2 |
|||
QAK |
Query Acknowledgement |
5 |
|||
QPD |
Query Parameter Definition Segment |
5 |
|||
[ |
Query Result Cluster, Begin PID Group |
||||
PID |
Patient Identification |
3 |
|||
[PD1] |
Additional Demographics |
3 |
|||
] |
End PID Group, End Query Results |
||||
[DSC] |
Continuation Pointer |
2 |
Field Seq. |
Field Name |
Key/ |
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^^^METRO HOSPITAL|... |
|||
Only one PID.3 may be specified, only 1 segment pattern will be returned. |
|||
The following components may be talked about |
|||
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: ...|^^^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 Q21/K21 query/response pair of messages. First is the
query:
MSH|^&~\|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q21^QBP_Q21|1|D|2.4
QPD|Q21^Get Person Demographics^HL7nnn|111069|112234^^^METRO HOSPITAL|^^^METRO
HOSPITAL~^^^SOUTH LAB|
RCP||I|
This query is asking for demographics for the person identified by the
identifier 112234 from the assigning authority METRO HOSPITAL. With the
demographics, we want identifiers returned for the person from the assigning
authorities METRO HOSPITAL and SOUTH LAB. Here is a sample response:
MSH|^&~\|HOSPMPI|HOSP|CLINREG|WESTCLIN|199912121135-0600||RSP^K21^RSP_K21|1|D|2.4|
MSA|AA|8699|
QAK|111069|OK|Q21^Get Person Demographics^HL7nnn|1|
QPD|Q21^Get Person Demographics^HL7nnn|111069|112234^^^METRO HOSPITAL|^^^METRO
HOSPITAL~^^^SOUTH LAB|
PID|||112234^^^METRO HOSPITAL~98223^^^SOUTH
LAB||Everyman^Adam||19600614|M||C|2101 Webster # 106^^Oakland^CA^94612|
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. |
QBP^Q22^QBP_Q21 |
Query By Parameter |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QPD |
Query Parameter Definition Segment |
5 |
RCP |
Response Control Parameters |
5 |
[DSC] |
Continuation Pointer |
2 |
RSP^K22^RSP_K22 |
Segment Pattern Response |
Group control |
Comment |
Support Indicator |
Chapter |
|---|---|---|---|---|---|
MSH |
Message Header |
2 |
|||
MSA |
Message Acknowledgement |
2 |
|||
[ERR] |
Error |
2 |
|||
QAK |
Query Acknowledgement |
5 |
|||
QPD |
Query Parameter Definition Segment |
5 |
|||
{ |
Query Result Cluster, Begin PID Group |
||||
[ |
|||||
PID |
Patient Identification |
3 |
|||
[PD1] |
Additional Demographics |
5 |
|||
[QRI] |
Query Response Instance |
5 |
|||
] |
|||||
} |
End PID Group, End Query Results |
||||
[ DSC ] |
Continuation Pointer |
2 |
Field Seq. |
Field Name |
Key/ |
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^SMITH~<EMAIL_ADDRESS>|
|||
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 Q22/K22 query/response pair of messages. First is the
query:
MSH|^&~\|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q22^QBP_Q21|1|D|2.4
QPD|Q22^Find Candidates^HL7nnn|111069|<EMAIL_ADDRESS>@PID.8^M|80|MATCHWARE|1.2||^^^METRO HOSPITAL~^^^SOUTH LAB|
RCP||I|20^RD
This query is asking for a list of persons matching the name JOHN SMITH 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 METRO HOSPITAL and SOUTH LAB.
The RCP segment specifies that the number of matches should be limited to 20.
Here is a sample response:
MSH|^&~\|HOSPMPI|HOSP|CLINREG|WESTCLIN|199912121135-0600||RSP^K22^RSP_K22|1|D|2.4|
MSA|AA|8699|
QAK|111069|OK|Q22^Find Candidates^HL7nnnn|3|
QPD|Q22^Find<EMAIL_ADDRESS><EMAIL_ADDRESS>HOSPITAL~^^^SOUTH LAB|
PID|||66785^^^METRO HOSPITAL~66532^^^SOUTH LAB||Smith^John||19630423|M||C|N2378
South Street^^Madison^WI^53711|
QRI|95||MATCHWARE 1.2|
PID|||87443^^^METRO HOSPITAL~651189^^^SOUTH LAB||Smith^Jon||19470606|M||C|124
Second Street^^Madison^WI^53711|
QRI|90||MATCHWARE 1.2|
PID|||43266^^^METRO HOSPITAL~81209^^^SOUTH
LAB||Smithy^John||19901210|M||C|W11234 Bay Drive^^Lodi^WI^53555|
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
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. |
QBP^Q23^QBP_Q21 |
Query By Parameter |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QPD |
Query Parameter Definition Segment |
5 |
RCP |
Response Control Parameters |
5 |
[ DSC ] |
Continuation Pointer |
2 |
RSP^K23^RSP_K23 |
Segment Pattern Response |
Group Control |
Comment |
Support Indicator |
Chapter |
|---|---|---|---|---|---|
MSH |
Message Header |
2 |
|||
MSA |
Message Acknowledgement |
2 |
|||
[ERR] |
Error |
2 |
|||
QAK |
Query Acknowledgement |
5 |
|||
QPD |
Query Parameter Definition Segment |
5 |
|||
[ |
Query Result Cluster, Begin PID Group |
||||
PID |
Patient Identification |
Only PID.3 of this segment is to be valued |
3 |
||
] |
End PID Group, End Query Results |
||||
[DSC] |
Continuation Pointer |
2 |
Field Seq. |
Field Name |
Key/ |
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^^^METRO HOSPITAL|... |
|||
Only one PID.3 may be specified, only 1 segment pattern will be returned. |
|||
The following components may be talked about |
|||
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: ...|^^^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 Q23/K23 query/response pair of messages. First is the
query:
MSH|^&~\|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q23^QBP_Q21|1|D|2.4
QPD|Q23^Get Corresponding IDs^HL7nnnn|111069|112234^^^METRO HOSPITAL|^^^WEST
CLINIC~^^^SOUTH LAB|
RCP||I|
SEC|0614
This query is asking for identifiers from WEST CLINIC and SOUTH LAB for the
person identified with the identifier 112234 from the assigning authority METRO
HOSPITAL. Here is a sample response:
MSH|^&~\|HOSPMPI|HOSP|CLINREG|WESTCLIN|199912121135-0600||RSP^K23^RSP_K23|1|D|2.4|
MSA|AA|8699|
QAK|111069|OK|Q23^Get Corresponding IDs^HL7nnnn|1|
QPD|Q23^Get Corresponding IDs^HL7nnn|111069|112234^^^METRO HOSPITAL|^^^WEST
CLINIC~^^^SOUTH LAB|
PID|||56321A^^^WEST CLINIC~66532^^^SOUTH LAB||Smith^John||19630423|M||C|N2378
South Street^^Madison^WI^53711|
Note that the identifiers returned do not include the METRO HOSPITAL
identifier, as it was not specified in the list of WhatDomainsReturned.
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_K24 |
Query Characteristics |
|
Purpose: |
Request that an MPI allocate an identifier for a given domain. |
QBP^Q24^QBP_Q21 |
Query By Parameter |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QPD |
Query Parameter Definition Segment |
5 |
RCP |
Response Control Parameters |
5 |
[ DSC ] |
Continuation Pointer |
2 |
RSP^K24^RSP_K24 |
Segment Pattern Response |
Group Control |
Comment |
Support Indicator |
Chapter |
|---|---|---|---|---|---|
MSH |
Message Header |
2 |
|||
MSA |
Message Acknowledgement |
2 |
|||
[ERR] |
Error |
2 |
|||
QAK |
Query Acknowledgement |
5 |
|||
QPD |
Query Parameter Definition Segment |
5 |
|||
[ |
Query Result Cluster, Begin PID Group |
||||
PID |
Patient Identification |
Only PID.3 of this segment is to be valued |
3 |
||
] |
End PID Group, End Query Results |
||||
[DSC] |
Continuation Pointer |
2 |
Field Seq. |
Field Name |
Key/ |
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: ...|^^^METRO 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|^&~\|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q24^QBP_Q11|1|D|2.4
QPD|Q24^Allocate Identifiers^HL7nnnn|111069|^^^WEST CLINIC~^^^SOUTH LAB|
RCP||I|
SEC|0614
This query is asking for identifiers from WEST CLINIC and SOUTH LAB to be
reserved and returned. Here is a sample response:
MSH|^&~\|HOSPMPI|HOSP|CLINREG|WESTCLIN|199912121135-0600||RSP^K24^RSP_K11|1|D|2.4|
MSA|AA|8699|
QAK|111069|OK|Q24^Allocate Identifiers^HL7nnnn|1|
QPD|A56^Allocate Identifiers^HL7nnn|111069|^^^WEST CLINIC~^^^SOUTH LAB|