The ADT transaction set provides for transmitting new or updated demographic
and visit information about patients. Since virtually any system attached to
the network requires information about patients, it is one of the most commonly
used transaction sets.
Generally, information is entered into an ADT system and passed to the nursing,
ancillary and financial systems either in the form of an unsolicited update or
in response to a record-oriented query.
This chapter defines the transactions at the seventh level, i.e., the abstract
messages. The examples included in this chapter were constructed using the HL7
Encoding Rules.
Each triggering 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, "Format for Defining Abstract
Messages."
The triggering events that follow are all served by the ADT unsolicited update
and the ACK response.
Normally entered in the primary ADT system and broadcast to the nursing units
and ancillary systems. Includes short-stay and John Doe admissions.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[ { NK1 } ] Next of Kin 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ { PR1 } ] Procedures 6
[ { GT1 } ] Guarantor Information 6
[
{ IN1 Insurance Information 6
[ IN2 ] Insurance Information - Addit. Info. 6
[ IN3 ] Insurance Information - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
A patient moves from one location to another.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Refers to changing a patient's status from, for example, inpatient to
discharged.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Includes emergency room patients and outpatients.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[ { NK1 } ] Next of Kin 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ { PR1 } ] Procedures 6
[ { GT1 } ] Guarantor Information 6
[
{ IN1 Insurance Information 6
[ IN2 ] Insurance Information - Addit. Info. 6
[ IN3 ] Insurance Information - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
A patient may be pre-admitted for a variety of reasons; e.g., prior to surgery
so that they will be able to receive tests administered in the lab. The data
may be entered into the surgery scheduling system and passed to the ADT
system.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[ { NK1 } ] Next of Kin 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ { PR1 } ] Procedures 6
[ { GT1 } ] Guarantor Information 6
[
{ IN1 Insurance Information 6
[ IN2 ] Insurance Information - Addit. Info. 6
[ IN3 ] Insurance Information - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[ MRG ] Merge Information 3
[ { NK1 } ] Next of Kin 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ { PR1 } ] Procedures 6
[ { GT1 } ] Guarantor Information 6
[
{ IN1 Insurance Information 6
[ IN2 ] Insurance Information - Addit. Info. 6
[ IN3 ] Insurance Information - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[ MRG ] Merge Information 3
[ { NK1 } ] Next of Kin 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ { PR1 } ] Procedures 6
[ { GT1 } ] Guarantor Information 6
[
{ IN1 Insurance Information 6
[ IN2 ] Insurance Information - Addit. Info. 6
[ IN3 ] Insurance Information - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
This trigger event is used when any patient information has changed, but no
other trigger event has occurred.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[ { NK1 } ] Next of Kin 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ { PR1 } ] Procedures 6
[ { GT1 } ] Guarantor Information 6
[
{ IN1 Insurance Information 6
[ IN2 ] Insurance Information - Addit. Info. 6
[ IN3 ] Insurance Information - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
A patient is being moved from his assigned location to a new location. For
example, this can be used when the nursing system is not the same as the ADT
system or to indicate a patient leaving an outpatient bed. The DG1 segment
remains in this message for backwards compatibility only.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { DG1 } ] Diagnosis Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
The patient arrives at his new assigned location.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { DG1 } ] Diagnosis Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { DG1 } ] Diagnosis Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
New location must show the location of the patient prior to the transfer.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { DG1 } ] Diagnosis Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
New location must show the location of the patient prior to the discharge.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[ { NK1 } ] Next of Kin 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ { PR1 } ] Procedures 6
[ { GT1 } ] Guarantor Information 6
[
{ IN1 Insurance Information 6
[ IN2 ] Insurance Information - Addit. Info. 6
[ IN3 ] Insurance Information - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Reservation or when patient admission is to occur imminently. Similar to a
pre-admit.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[ { NK1 } ] Next of Kin 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ { PR1 } ] Procedures 6
[ { GT1 } ] Guarantor Information 6
[
{ IN1 Insurance Information 6
[ IN2 ] Insurance Information - Addit. Info. 6
[ IN3 ] Insurance Information - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { DG1 } ] Diagnosis Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { DG1 } ] Diagnosis Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Used when it is decided that two patients will exchange beds. The patient ID
and visit data are repeated for the two patients being swapped. See Section
3.5.1 for a discussion of issues related to implementing this trigger event.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient (1) Identification 3
PV1 Patient (1) Visit 3
[ PV2 ] Patient (1) Visit - Additional Info. 3
[ { OBX } ] Observation/Result (1) 7
PID Patient (2) Identification 3
PV1 Patient (2) Visit 3
[ PV2 ] Patient (2) Visit - Additional Info. 3
[ { OBX } ] Observation/Result (2) 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Used to merge current and previous patient identification numbers: patient ID
- internal, patient ID - external, alternate patient ID and patient account
number. This is required, for example, when a patient has previously been
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 the decision is made to
combine the information under either the new or old identifier(s). It is
recommended that events A34, A35 and A36 be utilized in place of the A18 event
whenever possible. [Event A18 is being kept for backwards compatibility.]
The PID segment contains the surviving patient ID information. The MRG
segment contains the non-surviving information.
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, three new
events (A34, A35, and A36) are available as alternatives. These events
restrict the merge to patient ID - internal, or patient account number, or both
respectively. See Section 3.5.2 for a discussion of issues related to
implementing patient merge events.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[ MRG ] Merge Information 3
PV1 Patient Visit 3
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
The following triggering event is served by QRY (a query from another system)
and ADR (a response from an ADT system.)
Another application determines a need for ADT data about a patient and sends a
query to the ADT 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 Patient ID and there are data
associated with multiple accounts, it is an implementation issue as to which
account data should be returned. The ADT Event Type Segment, if included in
the response, describes the last event for which the ADT system initiated an
unsolicited update.
QRY Query Chapter
MSH Message Header 2
QRD Query Definition 2
[ QRF ] Query Filter 2
ADR ADT Response Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ERR] Error 2
QRD Query Definition 2
{
[ EVN ] Event Type 3
PID Patient Identification 3
[ {NK1} ] Next of Kin 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ {OBX} ] Observation/Result 7
[ {AL1} ] Allergy Information 3
[ {DG1} ] Diagnosis Information 6
[ {PR1} ] Procedures 6
[ {GT1} ] Guarantor Information 6
[
{
IN1 Insurance Information 6
[ IN2 ] Insurance Information - Addit. Info. 6
[ IN3 ] Insurance Information - Cert. 6
}
]
[ 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 physician (APP).
For multiple patient responses, additional values for URD-3-R/U who subject
defintion may be used, such as:
IP Inpatient
OP Outpatient
DC Discharged
For the ANU subject filter, the ADT systems response must have some method of
conveying the fact that some beds are empty (as well as returning the data for
all patients in the occupied beds). This will be done 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
For 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 ADT system's
bed status. The following is the associated record layout.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
NPU Non-patient Update 3
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Delete visit specific information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Where the first PID segment needs to be linked to the second PID segment. See
Section 3.5.3 for a discussion of issues related to implementing patient link
messages.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient (1) Identification 3
[ PV1 ] Patient (1) Visit 3
PID Patient (2) Identification 3
[ PV1 ] Patient (2) Visit 3
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
The purpose of this message and the three following messages is to allow sites
with multiple systems and respective master data bases to communicate activity
related to a person between systems. Each system has an interest in the data
base activity of the others in order to maintain data integrity across an
institution. While defined within the ADT message set, these messages differ
in that they are not patient specific.
For example, a site with separate inpatient, outpatient and medical record
systems may require that each system maintain concurrent person information.
Prior to an admit, in the inpatient system the new patient is added to the
master data base of the system resulting in the broadcast of a message. The
outpatient system receives the message and adds the person to its data base
with the possibility that the person may some day become a patient in its
system. The medical record system receives the message and adds the person to
its data base with the possibility that it will track inpatient, outpatient or
clinical data for the person.
In addition to adding a person to a data base, the delete, update and merge
messages work in a similar manner to maintain concurrent person information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[ { NK1 } ] Next of Kin 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ { PR1 } ] Procedures 6
[ { GT1 } ] Guarantor Information 6
[
{ IN1 Insurance Information 6
[ IN2 ] Insurance Information - Addit. Info. 6
[ IN3 ] Insurance Information - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Delete all demographic information related to this person.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
MRG Merge Information 3
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[ { NK1 } ] Next of Kin 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ { PR1 } ] Procedures 6
[ { GT1 } ] Guarantor Information 6
[
{ IN1 Insurance Information 6
[ IN2 ] Insurance Information - Addit. Info. 6
[ IN3 ] Insurance Information - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Only Patient Identification - Internal has changed as a result of the merge.
See Section 3.5.2 for a discussion of issues related to implementing merge
messages.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
MRG Merge Information 3
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Only Patient Account Number has changed as a result of the merge. See Section
3.5.2 for a discussion of issues related to implementing merge messages.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
MRG Merge Information 3
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Both Patient Identification - Internal and Patient Account Number have changed
as a result of the merge. See Section 3.5.2 for a discussion of issues related
to implementing merge messages.
ADT ADT Message Chapter
MSH Hessage Header 2
EVN Event Type 3
PID Patient Identification 3
MRG Merge Information 3
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
Unlinks two PID segments previously linked via an A24.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient (1) Identification 3
[ PV1 ] Patient (1) Visit 3
PID Patient (2) Identification 3
[ PV1 ] Patient (2) Visit 3
ACK General Acknowledgement Chapter
MSH Message Header 2
MSA Message Acknowledgement 2
[ ERR ] Error Information 2
The EVN segment is used to communicate necessary trigger event information to
receiving applications. Valid event types for all chapters are contained in
table 0003 - event type code.
Figure 3-1 EVN attributes
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
3 |
ID |
R |
0003 |
00099 |
Event
Type Code |
3.3.1.0 EVN field definitions
Definition: codes correspond to the trigger events described in this section.
e.g., admission, transfer, registration. This field is left in for backwards
compatibility. It is recommended to use the second component (trigger event)
of MSH-9-message type to transmit event type code information.
Value |
Description |
A01 |
Admit
a patient |
Definition: most systems will default to the system date/time when the
transaction was entered, but should also permit an override.
Definition: date/time the event is planned. Recommend that the PV2 expected
admit date and expected discharge date be used whenever possible.
Definition: describes the reason for this event (e.g., patient request,
physician order, census management, etc.). Refer to user-defined table 0062
- event reason for valid codes.
User-defined Table 0062 Event reason
Value |
Description |
01 |
Patient
request |
Definition: identifies the individual responsible for triggering the event.
Refer to user-defined table 0188 - operator ID for suggested values.
The PID segment is used by all applications as the primary means of
communicating patient identification information. This segment contains
permanent patient identifying, and demographic information that, for the most
part, is not likely to change frequently.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
|
|
|
00104 |
Set
ID - Patient ID |
3.3.2.0 PID field definitions
Definition: for those messages that permit segments to repeat, the Set ID
field is used to identify the repetitions. For example, the swap and query
transactions allow for multiple PID segments would have Set ID values of 1, 2,
then 3, etc.
Components: <patient ID (ST)> ^ <check digit (NM)> ^
<check digit scheme (ID)> ^ <assigning facility ID (ST)>
Definition: if the patient is from another institution, outside office, etc.,
the identifier used by that institution can be shown here. This may be a
number which multiple disparate corporations or facilities share. Refer to
table 0061 - check digit scheme in Chapter 2.
Components: <patient ID (NM)> ^ <check digit (NM)> ^ <
check digit scheme (ID)> ^ <assigning facility ID (ST)> ^ <type
(ID)>
Definition: primary ID used by the facility to uniquely identify a patient at
the time of admit, (e.g., medical record number, billing number, etc). Refer
to table 0061-check digit scheme.
Definition: third number may be required to identify a patient. Possible
contents include a visit number, a visit date, or Social Security Number.
Components: <family name> ^ <given name> ^ <middle initial
or name> ^ <suffix (e.g., JR or III)> ^ <prefix (e.g., DR)> ^
<degree (e.g., MD)>
Definition: name is standard format described in Chapter 2.
Definition: family name under which the mother was born (i.e., before
marriage.) Used to disambiguate patients with the same last name.
Definition: patient's date of birth.
Definition: patient's sex. Refer to table 0001 - sex for valid codes.
Table 0001 Sex
Value |
Description |
F |
Female |
Components: <family name> ^ <given name> ^ <middle initial
or name> ^ <suffix (e.g., JR or III)> ^ <prefix (e.g., DR)> ^
<degree (e.g., MD)>
Definition: name(s) by which the patient has been known at some time.
Definition: ERISA also has a published list of ethnic classifications which
may be used by local agreement at a site. Refer to user-defined table 0005
- race.
Components: <street address> ^ < other designation> ^
<city> ^ <state or province> ^ <zip or postal code> ^
<country> ^ <type> ^ <other geographic designation>
Definition: mailing address of the patient.
Definition: patient's county code. This field was left in for backwards
compatibility. County can now be supported in the other geographic designation
component of the AD data type.
Definition: up to three repetitions are permitted. The first is considered
the primary number.
Definition: up to three repetitions are permitted. The first is considered
the primary one.
Definition: the patient's primary language.
Definition: patient's marital status. Refer to user-defined table 0002 -
marital status for suggested entries.
User-defined Table 0002 Marital status
Value |
Description |
A |
Separated |
Definition: patient's religion. Refer to user-defined table 0006 -
religion.
Components: <patient ID (ST)> ^ <check digit (NM)> ^
<check digit scheme (ID)> ^ <assigning facility ID (ST)>
Definition: number assigned by accounting to which all charges, payments,
etc. are recorded. It is used to identify the patient's account. Refer to
table 0061 - check digit scheme in Chapter 2.
Definition: patient's social security number. This number may also be an RR
retirement number.
Components: <license number> ^ <issuing state, province,
country>
Definition: patient's drivers license number. Some sites may use this as a
unique number that identifies the patient. Default of the second component is
the state in which the patient is being registered.
Components: <patient ID (ST)> ^ <check digit (NM)> ^
<check digit scheme (ID)> ^ <assigning facility ID (ST)>
Definition: used as a link field for newborns, for example. Typically a
patient ID or account number may be used. Refer to HL7 table 0061 - check
digit scheme as defined in Chapter 2.
Definition: further defines patient ancestry. Refer to user-defined table
0189 - ethnic group for suggested values.
Definition: indicates the location of the patient's birth.
Definition: indicates if the patient was part of a multiple birth. Refer to
HL7 table 0136 - Y/N indicator as described in Chapter 2.
Definition: if a patient was part of a multiple birth, a value (number)
indicating the patient's birth order.
Definition: indicates the patient's country of citizenship. Refer to
user-defined table 0171 - country code for suggested values or to ISO
3166.
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: indicates the military status assigned to a veteran. Refer to
user-defined table 0172 - veterans military status for suggested codes.
The assigning facility ID, the fourth component of the patient identifiers, is
a string of up to six characters which is uniquely associated with the facility
that originally assigned the number. A given institution or group of
intercommunicating institutions should establish a list of facilities that may
be potential assigners of patient identification (and other important
identification) numbers. The list will be one of the institution's master
dictionary lists. Since third parties (other than the assigners of patient
identification numbers) may send or receive HL7 messages containing patient
identification numbers, the assigning facility ID in the patient identification
numbers may not be the same as the sending and receiving systems identified in
the MSH. The assigning facility ID must be unique across applications at a
given site. This field is required in HL7 implementations that have more than
a single ADT/REG application assigning such numbers.
The PV1 segment is used by Registration/ADT applications to communicate
information on a visit specific basis. This segment can be used to send
multiple visit statistic records to the same patient account, or single visit
records to more than one account. Individual sites must determine this
segment's use.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
|
|
|
00131 |
Set
ID - Patient Visit |
3.3.3.0 PV1 field definitions
Definition: number that uniquely identifies this transaction for the purpose
of adding, changing, or deleting the transaction. For those messages that
permit segments to repeat, the Set ID field is used to identify the
repetitions. For example, the swap and query transactions allow for multiple
PID segments would have Set ID values of 1, 2, then 3, etc.
Definition: a common field used by systems to categorize patients by site.
It does not have a consistent industry-wide definition. Subject to
site-specific variations. Refer to user-defined table 0004 - patient
class for suggested codes.
User-defined Table 0004 Patient class
Value |
Description |
E |
Emergency |
Components: <nurse unit> ^ <room> ^ <bed> ^ <
facility ID> ^ <bed status>
Definition: New location is the patient's initial assigned location, or the
location to which he is being moved. For canceling a transaction or
discharging a patient, the current room number should be in this field. If a
value exists in the fifth component (bed status) it supercedes the value in
3.3.3.40.
Definition: indicates the circumstance under which the patient was or will be
admitted.
User-defined Table 0007 Admission type
Value |
Description |
A |
Accident |
Definition: uniquely identifies the patient's pre-admit account. Some
systems will continue to use the pre-admit number as the billing number after
the patient has been admitted. In the future, this field should be a CK data
type -- like the account number.
Components: <nurse unit> ^ <room> ^ <bed> ^
<facility ID> ^ <bed status>
Definition: old location is null if the patient is new. It contains the
prior patient location if the patient is being transferred. If a value exists
in the fifth component (bed status) it supercedes the value in 3.3.3.40.
Components: <physician ID> ^ <family name> ^ <given
name> ^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source table
ID>
Definition: Depending on local agreements, either ID or the name may be
absent. Refer to user-defined table 0010 - physician ID.
Components: <physician ID> ^ <family name> ^ <given
name> ^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source table
ID>
Definition: depending on local agreements, either ID or the name may be
absent. Refer to user-defined table 0010 - physician ID.
Components: <physician ID> ^ <family name> ^ <given
name> ^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source table
ID>
Definition: depending on local agreements, either ID or the name may be
absent. Refer to user-defined table 0010 - physician ID.
Definition: The treatment or type of surgery the patient is scheduled to
receive. Required field with trigger events A01, A02, A14, A15. Refer to
user-defined table 0069 - hospital service.
Components: <nurse unit> ^ <room> ^ <bed> ^
<facility ID> ^ <bed status>
Definition: location other than the assigned location required for a
temporary period of time (e.g., OR). If a value exists in the fifth component
(bed status) it supercedes the value in 3.3.3.40.
Definition: indicates that the patient must have pre-admission testing done
in order to be admitted. Refer to user-defined table 0087 - pre-admit test
indicator for suggested codes.
Definition: indicates that a patient is being re-admitted to the facility and
the circumstances. R for readmission or else null. Also recurring
patient visits can be indicated. Refer to user-defined table 0092 -
re-admission indicator.
Definition: indicates where the patient was admitted. Refer to
user-defined table 0023 - admit source for suggested codes.
Definition: refer to user-defined table 0009 - ambulatory status for
suggested entries.
Value |
Description |
A0 |
No
functional limitations |
Definition: user-defined code to identify the type of VIP. Refer to
user-defined table 0099 - VIP indicator.
Components: <doctor ID> ^ <family name> ^ <given name>
^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^
<prefix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source table
ID>
Definition: by local agreement name or ID may not be present. Refer to
user-defined table 0010 - physician ID.
Definition: site-specific values. Refer user-defined table 0018 - patient
type.
Definition: unique number assigned to each patient visit. This is left as NM
data type for backwards compatibility but HL7 recommends new implementations
use CK data type.
Components: <financial class (ID)> ^ <effective date
(TS)>
Definition: primary financial class assigned to the patient for the purpose
of identifying sources of reimbursement. Repeats up to 4 times. Refer to
user-defined table 0064 - financial class for suggested codes.
Definition: code used to determine which price schedule is to be used for
room and bed charges. Refer to user-defined table 0032 - charge/price
indicator.
Definition: code that indicates whether the patient will be extended certain
special courtesies. Refer to user-defined table 0045 - courtesy code.
Definition: user-defined code to determine past credit experience. Refer
user-defined table 0046 - credit rating.
Definition: identifies the type of contract entered into by the facility and
the guarantor for the purpose of settling outstanding account balances. Refer
to user-defined table 0044 - contract code.
Definition: date the contract is to start.
Definition: amount to be paid by the guarantor each period as per the
contract.
Definition: specifies the duration of the contract for user-defined periods.
Definition: indicates the amount of interest that will be charged the
guarantor on any outstanding amounts. Refer to user-defined table 0073 -
interest rate code.
Definition: indicates the account was transferred to bad debts and the reason.
Refer to user-defined table 0110 - transfer to bad debt code.
Definition: date that the account was transferred to a bad debt status.
Definition: uniquely identifies the bad debt agency that the account was
transferred to. This code is site-defined. This field was kept as an ST type
for backwards compatibility. One possible implementation is to edit against a
table such as, user-defined table 0021 - bad debt agency code, however
this is not required.
Definition: amount that was transferred to a bad debt status.
Definition: amount recovered from the guarantor on the account.
Definition: indicates that the account was deleted from the file and the
reason. Refer to user-defined table 0111 - delete account code.
Definition: date that the account was deleted from the file.
Definition: disposition of the patient at time of discharge (i.e., discharged
to home; expired; etc.). Refer to user-defined table 0112 - discharged
disposition.
Components: <code> ^ <description>
Definition: indicates a facility to which the patient was discharged. Refer
to user-defined table 0113 - discharged to location.
Definition: indicates a special diet type for a patient. Refer to
user-defined table 0114 - diet type.
Definition: used in a multiple facility environment to indicate the facility
with which this visit is associated. Refer to user-defined table 0115 -
servicing facility.
An optional fourth component, facility ID, may be valued in each individual
location field in PV1, instead of placing it here.
Definition: refer to user-defined table 0116 - bed status.
Value |
Description |
C |
Closed |
An optional fifth component, bed status, may be valued in each individual
location field in PV1, instead of placing it here. This field is maintained
for backward compatibility.
Definition: refer to user-defined table 0117 - account status.
Components: <nurse unit> ^ <room> ^ <bed> ^
<facility ID> ^ <bed status>
Definition: indicates the nursing station, room, bed, facility ID and bed
status to which the patient may be moved. If a value exists in the fifth
component (bed status) it supercedes the value in 3.3.3.40.
Components: <nurse unit> ^ <room> ^ <bed> ^
<facility ID> ^ <bed status>
Definition: can be used when a patient is arriving or departing or for
general update events. If a value exists in the fifth component (bed status)
it supercedes the value in 3.3.3.40.
Definition: admit date/time. To be used if the event date/time is different
than the admit date and time, i.e., a retroactive update.
Definition: discharge date/time. To be used if the event date/time is
different than the admit date and time, i.e., a retroactive update.
Definition: visit balance due.
Definition: total visit charges.
Definition: total adjustments for visit.
Definition: total payments for visit.
Components: <patient ID (ST)> ^ <check digit (NM)> ^ <
check digit scheme (ID)> ^ <assigning facility ID (ST)>^<visit ID
type (ID)>
Definition: optional visit ID number to be used if needed. - ID used by
the facility to uniquely identify a patient at the time of admit. Refer to HL7
table 0061 - check digit scheme as defined in Chapter 2. Refer to
user-defined table 0192 - visit ID type.
The facility (servicing) ID, the optional fourth component of each patient
location field, is a string of up to six characters which is uniquely
associated with the facility containing the location. A given institution or
group of intercommunicating institutions should establish a list of facilities
that may be potential assigners of patient locations. The list will be one of
the institution's master dictionary lists. Since third parties other than the
assigners of patient locations may send or receive HL7 messages containing
patient locations, the facility ID in the patient location may not be the same
as that implied by the sending and receiving systems identified in the MSH.
The facility ID must be unique across facilities at a given site. This field
is required in HL7 implementations that have more than a single facility with
bed locations, since the same <nurse unit> ^ <room> ^ <bed>
combination may exist at more than one facility.
The PV2 segment is a continuation of visit specific information contained on
the PV1 segment.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
12 |
CM |
|
|
00181 |
Prior
Pending Location |
3.3.4.0 PV2 field definitions
Components: <nurse unit> ^ <room> ^ <bed> ^ <facility
ID> ^ <bed status>
Definition: required only for Cancel Pending Transfer (A27) messages.
Components: <identifier> ^ <text> ^ <name of coding
system>^ <alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: indicates the specific patient accommodations for this visit.
Refer to user-defined table 0129 - accommodation code.
Components: <identifier> ^ <text> ^ <name of coding
system>^ <alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: short description the patient admission reason.
Components: <identifier> ^ <text> ^ <name of coding
system>^ <alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: short description of the patient location change reason.
Definition: short description of patient valuables checked in during admission.
Definition: indicates the location of the patient's valuables.
Definition: further categorizes a patient's visit with respect to an
individual institution's needs (e.g., teaching flag = TE, indicating the
patient is a teaching case). Refer to user-defined table 0130 - visit user
code.
Definition: date patient expected to be admitted.
Definition: non-event related date used by ancillaries to more accurately
determine projected workloads.
The NK1 segment contains information about the patient's other related
parties. Any associated parties may be identified. Utilizing NK1-1-set
ID, multiple NK1 segments can be sent to patient accounts.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
R |
|
|
00190 |
Set
ID - Next of Kin |
3.3.5.0 NK1 field definitions
Definition: uniquely identifies the NK1 records for the purpose of adding,
changing, or deleting records. For those messages that permit segments to
repeat, the Set ID field is used to identify the repetitions. For example, the
swap and query transactions allow for multiple PID segments would have Set ID
values of 1, 2, then 3, etc.
Components: <family name> ^ <given name> ^ <middle initial or
name> ^ <suffix (e.g., JR or III)> ^ <prefix (e.g., DR)> ^
<degree (e.g., MD)>
Definition: name of the next of kin.
Components: <identifier> ^ <text> ^ <name of coding
system>^ <alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: defines the actual personal relationship that the next of kin has
to the patient. Refer to user-defined table 0063 - relationship.
Examples might include: brother, sister, mother, father, friend, spouse,
emergency contact, employer, etc.
Components: <street address> ^ < other designation> ^
<city> ^ <state or province> ^ <zip or postal code> ^
<country> ^ <type> ^ <other geographic designation>
Definition: defines the address of the associated party.
Definition: defines the telephone number of the associated party.
Definition: defines the business telephone number of the associated party.
Components: <identifier> ^ <text> ^ <name of coding
system>^ <alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: indicates the specific relationship role (next of kin, employer,
emergency contact, etc.). Refer to user-defined table 0131 - contact
role. This field specifies the role that the next of kin plays with
regards to the patient. For example, an employer, emergency contact, next of
kin, insurance company, state agency, federal agency etc.
Definition: start of relationship.
Definition: end of relationship.
Definition: title of the next of kin at their place of employment.
Components: <job code (ID)> ^ <employee classification (ID)>
Definition: the employers Job Code or Employee Classification used for the
next of kin at their place of employment.
Definition: number the employer assigns to the employee that is acting as
next of kin.
Definition: in cases where an employer serves as next of kin, this is the
name of the organization which serves as the next of kin. This field may also
be used to communicate the name of the organization where the next of kin
works.
The AL1 segment contains patient allergy information of various types.
Most of this information will be derived from user-defined tables. Each AL1
segment describes a single patient allergy.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
R |
|
00203 |
Set
ID - Allergy |
3.3.6.0 AL1 field definitions
Definition: number that uniquely identifies the individual transaction for
adding, deleting or updating an allergy description in the patient's record.
For those messages that permit segments to repeat, the Set ID field is used to
identify the repetitions. For example, the swap and query transactions allow
for multiple PID segments would have Set ID values of 1, 2, then 3, etc.
Definition: indicates a general allergy category (drug, food, pollen,
etc.).
Value |
Description |
DA |
Drug
Allergy |
Components: <identifier> ^ <text> ^ <name of coding
system>^ <alternate identifier> ^ <alternate text> ^ <name of
alternate coding system>
Definition: uniquely identifies a particular allergy. This element may
conform to some external, standard coding system (which must be identified), or
it may conform to local, largely textual or mnemonic descriptions.
Definition: indicates the general severity of the allergy (severe, moderate,
mild, etc.).
Value |
Description |
SV |
Severe |
Definition: short, textual description of the specific allergy reaction
(convulsions, sneeze, rash, etc.).
Definition: date the allergy was identified.
The NPU segment allows the updating of census (bed status) data without
sending patient specific data. For example: changing the status of a bed from
housekeeping to unoccupied.
Figure 3-7 NPU attributes
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
12 |
CM |
R |
0079 |
00209 |
Bed
Location |
3.3.7.0 NPU field definitions
Components: <nurse unit> ^ <room> ^ <bed> ^ <facility
ID> ^ <bed status>
Definition: bed location is a valid bed location. Refer to user-defined
table 0079 - location.
Definition: refer to user-defined table 0116 - bed status for
suggested entries.
The MRG segment provides receiving applications with information necessary
to initiate the merging of patient data as well as groups of records. It is
intended that this segment be used throughout the standard to allow the merging
of registration, accounting, and clinical records within specific applications.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
20 |
CM |
R |
00211 |
Prior
Patient ID - Internal |
3.3.8.0 MRG field definitions
Components: <patient ID (ST)> ^ <check digit (NM)> ^ <check
digit scheme (ID)> ^ <assigning facility ID (ST)> ^ <type
(ID)>
Definition: table 0061 - check digit scheme is defined in Chapter 2.
Components: <patient ID (ST)> ^ <check digit (NM)> ^ <check
digit scheme (ID)> ^ <assigning facility ID (ST)> ^ <type
(ID)>
Definition: table 0061 - check digit scheme is defined in Chapter 2.
Components: <account number (NM)> ^ <check digit (NM)> ^
<check digit scheme (ID)> ^ <assigning facility ID (ST)>
Definition: table 0061 - check digit scheme is defined in Chapter 2.
Components: <patient ID (ST)> ^ <check digit (NM)> ^ <check
digit scheme (ID)> ^ <assigning facility ID (ST)>
Definition: table 0061 - check digit scheme is defined in Chapter 2.
The assigning facility ID, the fourth component of the patient identifiers, is
a string of up to six characters which is uniquely associated with the facility
that originally assigned the number. A given institution or group of
intercommunicating institutions should establish a list of facilities that may
be potential assigners of patient identification (and other important
identification) numbers. The list will be one of the institution's master
dictionary lists. Since third parties (other than the assigners of patient
identification numbers) may send or receive HL7 messages containing patient
identification numbers, the assigning facility ID in the patient identification
numbers may not be the same as the sending and receiving systems identified in
the MSH. The assigning facility ID must be unique across applications at a
given site. This field is required in HL7 implementations that have more than
a single ADT/REG application assigning such numbers.
MSH|^~\&|REGADT|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01|MSG00001|P|2.2|<cr>
EVN|01|198808181123||<cr>
PID|||PATID1234^5^M11||JONES^WILLIAM^A^III||19610615|M||C|1200 N ELM
STREET^
...GREENSBORO^NC^27401-1020|GL|(919)379-1212|(919)271-3434||S||
...PATID12345001^2^M10|123456789|987654^NC|<cr>
NK1|JONES^BARBARA^K|WIFE|<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||ADM|A0|<cr>
Patient William A. Jones, III was admitted on July 18, 1988 at 1123 a.m. by
doctor Sidney J. Lebauer (#004777) for surgery (SUR). He has been assigned to
room 2012, bed 01 on nursing unit 2000.
The message was sent from system REGADT at the MCM site to system LABADT also
at the MCM site on the same date as the admission took place but three minutes
after the admit.
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|198808181320|SECURITY|ADT^A18|MSG00002|P|2.2|<cr>
EVN|18|198808181318||<cr>
PID|||PATID5678^9^M11||JONES^WILLIAM^A^JR||19310615|M||C|303
EDWARDS
...DRIVE^GREENSBORO^NC^27410|GL|(919)294-1212|(919)288-0101||M||
...PATID12345001^2^M10|987654321|143257^NC|<cr>
MRG|PATID1234^5^M11||<cr>
NK1|JONES^NANCY^K|WIFE|<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||||<cr>
During the admission process, the admitting secretary used the medical record
number of William A. Jones, III instead of William A. Jones, Jr. The billing
number stayed the same since it is tied to the visit and numerous charges have
already been incurred. The inclusion of the MRG segment with the old patient
ID filled in, triggers the merge.
MSH|^~\&|REGADT|MCM|LABADT||199112311418||ADT^A01|000001|P|2.2|||<CR>
EVN|A01|199112311418|199112311418|01|<CR>
PID|||2-68708-5|253763|MASSIE^JAMES^""^""^""^""^||19560129|M|||171
...ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|
...(900)485-5344||S|C||371-66-9256||<CR>
NK1||MASSIE^MARYLOU^""^""^""^""^|MOTHER|171
ZOBERLEIN^^ISHPEMING^MI^49849^""^|
...(900)485-5344|<CR>
PV1||E|EMERG||||0148^ADDISON,JAMES|0148^ADDISON,JAMES|0148^ADDISON,JAMES|2||
...||||||0148^ADDISON,JAMES|S||A|||||||||||||||||||||||199112311418|
...199201210800|||||<CR>
DG1|1|19||L FIFTH FINGER LAC||00|||||||||<CR>
GT1|1||MASSIE^JAMES^""^""^""^""^||171
ZOBERLEIN^^ISHPEMING^MI^49849^""^|
...(900)485-5344|(900)485-5344||||SELF|371-66-925||||MOOSES AUTO
...CLINIC|171
ZOBERLEIN^^ISHPEMING^MI^49849^""|(900)485-5344||||<CR>
IN1|1|0|BC1|BLUE CROSS|171 ZOBERLEIN^^ISHPEMING^M149849^""^||
...(900)485-5344|90||||||50 OK|||||||||||||||||||||<CR>
Some systems may handle this as a single function. Others may require a
multiple process where:
a) patient A is assigned as temporary location
b) patient B is assigned patient A's location
c) patient A is assigned patient B's prior location
The three-step scenario requires three separate transfer messages instead
of a single swap message. If all beds in a hospital are occupied, it may be
necessary to use a dummy location.
The intent of trigger events A18, A30, A34, A35, and A36 are to reconcile
distinct sets of existing patient data records which have been entered under
different identification numbers, either deliberately or due to errors.
Ideally, following one of these trigger events, all of the affected patient
data should be accessible under whatever surviving patient identifiers were
specified in the messages. Due to substantial differences in database
architectures and system dependent data processing requirements or limitations,
the exact meaning and implementation of these events must be negotiated between
systems.
Linking two or more patients does not require the actual merging of patient
information as discussed in Section 3.5.2; following a link trigger event, sets
of affected patient data records should remain distinct. However, due to
differences in database architectures, there may be system dependent
limitations or restrictions regarding the linking of one or more patients which
must be negotiated.
None.
Admit a Patient Event 3-2
ADT Transaction Set 3-1
AL1 3-38
Discharge Event 3-3
EVN 3-19
Leave of Absence Event
Return 3-13
NK1 3-36
NPU 3-40
PID 3-21
PV1 3-26
Segments
AL1 3-38
EVN 3-19
NK1 3-36
NPU 3-40
PID 3-21
PV1 3-26
Transfer Event
Transfer 3-2
Trigger Event
A01 3-2
A02 3-2
A03 3-3
A04 3-3
A05 3-4
A06 3-4
A07 3-5
A08 3-6
A09 3-6
A10 3-7
A11 3-7
A12 3-7
A13 3-8
A14 3-8
A15 3-9
A16 3-9
A17 3-10
A18 3-10
A19 3-11
A20 3-12
A21 3-12
A22 3-13
A23 3-13
A24 3-13
A25 3-14
A26 3-14
A27 3-14
A28 3-15
A29 3-16
A30 3-16
A31 3-17
A32 3-17
A33 3-17
A34 3-18
A35 3-18
A36 3-18
A37 3-19