Chapter 3 Patient Administration

• 3 .
  Patient Administration
  • 3.1 PURPOSE
  • 3.2 TRIGGER EVENTS AND MESSAGE DEFINITIONS
    • 3.2.1 ADT/ACK - admit/visit notification (event A01)
    • 3.2.2 ADT/ACK - transfer a patient (event A02)
    • 3.2.3 ADT/ACK - discharge/end visit (event A03)
    • 3.2.4 ADT/ACK - register a patient (event A04)
    • 3.2.5 ADT/ACK - pre-admit a patient (event A05)
    • 3.2.6 ADT/ACK - change an outpatient to an inpatient (event A06)
    • 3.2.7 ADT/ACK - change an inpatient to an outpatient (event A07)
    • 3.2.8 ADT/ACK - update patient information (event A08)
    • 3.2.9 ADT/ACK - patient departing - tracking (event A09)
    • 3.2.10 ADT/ACK - patient arriving - tracking (event A10)
    • 3.2.11 ADT/ACK - cancel admit / visit notification (event A11)
    • 3.2.12 ADT/ACK - cancel transfer (event A12)
    • 3.2.13 ADT/ACK - cancel discharge / end visit (event A13)
    • 3.2.14 ADT/ACK - pending admit (event A14)
    • 3.2.15 ADT/ACK - pending transfer (event A15)
    • 3.2.16 ADT/ACK - pending discharge (event A16)
    • 3.2.17 ADT/ACK - swap patients (event A17)
    • 3.2.18 ADT/ACK - merge patient information (event A18)
    • 3.2.19 QRY/ADR - patient query (event A19)
      • 3.2.19.1 A19 usage notes
    • 3.2.20 ADT/ACK - bed status update (event A20)
    • 3.2.21 ADT/ACK - patient goes on a "leave of absence (event A21)
    • 3.2.22 ADT/ACK - patient returns from a "leave of absence (event A22)
    • 3.2.23 ADT/ACK - delete a patient record (event A23)
    • 3.2.24 ADT/ACK - link patient information (event A24)
    • 3.2.25 ADT/ACK - cancel pending discharge (event A25)
    • 3.2.26 ADT/ACK - cancel pending transfer (event A26)
    • 3.2.27 ADT/ACK - cancel pending admit (event A27)
    • 3.2.28 ADT/ACK - add person information (event A28)
    • 3.2.29 ADT/ACK - delete person information (event A29)
    • 3.2.30 ADT/ACK - merge person information (event A30)
    • 3.2.31 ADT/ACK - update person information (event A31)
    • 3.2.32 ADT/ACK - cancel patient arriving - tracking (event A32)
    • 3.2.33 ADT/ACK - cancel patient departing - tracking (event A33)
    • 3.2.34 ACK/ADT - merge patient information - patient ID only (event A34)
    • 3.2.35 ADT/ACK - merge patient information - account number only (event A35)
    • 3.2.36 ADT/ACK - merge patient information - patient ID & account number (event A36)
    • 3.2.37 ADT/ACK - unlink patient information (event A37)
    • 3.2.38 ADT/ACK - cancel pre-admit (event A38)
    • 3.2.39 ADT/ACK - merge person - patient ID (event A39)
    • 3.2.40 ADT/ACK - merge patient - patient identifier list (event A40)
    • 3.2.41 ADT/ACK - merge account - patient account number (event A41)
    • 3.2.42 ADT/ACK - merge visit - visit number (event A42)
    • 3.2.43 ADT/ACK - move patient information - patient identifier list (event A43)
    • 3.2.44 ADT/ACK - move account information - patient account number (event A44)
    • 3.2.45 ADT/ACK - move visit information - visit number (event A45)
    • 3.2.46 ADT/ACK - change patient ID (event A46)
    • 3.2.47 ADT/ACK - change patient identifier list (event A47)
    • 3.2.48 ADT/ACK - change alternate patient ID (event A48)
    • 3.2.49 ADT/ACK - change patient account number (event A49)
    • 3.2.50 ADT/ACK - change visit number (event A50)
    • 3.2.51 ADT/ACK - change alternate visit ID (event A51)
  • 3.3 MESSAGE SEGMENTS
    • 3.3.1 EVN - event type segment
      • 3.3.1.0 EVN field definitions
      • 3.3.1.1 Event type code (ID) 00099
      • 3.3.1.2 Recorded date/time (TS) 00100
      • 3.3.1.3 Date/time planned event (TS) 00101
      • 3.3.1.4 Event reason code (IS) 00102
      • 3.3.1.5 Operator ID (XCN) 00103
      • 3.3.1.6 Event occurred (TS) 01278
    • 3.3.2 PID - patient identification segment
      • 3.3.2.0 PID field definitions
      • 3.3.2.1 Set ID - PID- (SI) 00104
      • 3.3.2.2 Patient ID (CX) 00105
      • 3.3.2.3 Patient identifier list (CX) 00106
      • 3.3.2.4 Alternate patient ID - PID (CX) 00107
      • 3.3.2.5 Patient name (XPN) 00108
      • 3.3.2.6 Mother's maiden name (XPN) 00109
      • 3.3.2.7 Date/time of birth (TS) 00110
      • 3.3.2.8 Sex (IS) 00111
      • 3.3.2.9 Patient alias (XPN) 00112
      • 3.3.2.10 Race (CE) 00113
      • 3.3.2.11 Patient address (XAD) 00114
      • 3.3.2.12 County code (IS) 00115
      • 3.3.2.13 Phone number - home- (XTN) 00116
      • 3.3.2.14 Phone number - business- (XTN) 00117
      • 3.3.2.15 Primary language (CE) 00118
      • 3.3.2.16 Marital status (CE) 00119
      • 3.3.2.17 Religion (CE) 00120
      • 3.3.2.18 Patient account number (CX) 00121
      • 3.3.2.19 SSN number - patient- (ST) 00122
      • 3.3.2.20 Driver's license number - patient- (DLN) 00123
      • 3.3.2.21 Mother's identifier (CX) 00124
      • 3.3.2.22 Ethnic group (CE) 00125
      • 3.3.2.23 Birth place (ST) 00126
      • 3.3.2.24 Multiple birth indicator (ID) 00127
      • 3.3.2.25 Birth order (NM) 00128
      • 3.3.2.26 Citizenship (CE) 00129
      • 3.3.2.27 Veterans military status (CE) 00130
      • 3.3.2.28 Nationality (CE) 00739
      • 3.3.2.29 Patient death date and time (TS) 00740
      • 3.3.2.30 Patient death indicator (ID) 00741
      • 3.3.2.31 Usage notes: PID patient identification
    • 3.3.3 PV1 - patient visit segment
      • 3.3.3.0 PV1 field definitions
      • 3.3.3.1 Set ID - PV1- (SI) 00131
      • 3.3.3.2 Patient class (IS) 00132
      • 3.3.3.3 Assigned patient location (PL) 00133
      • 3.3.3.4 Admission type (IS) 00134
      • 3.3.3.5 Preadmit number- (CX) 00135
      • 3.3.3.6 Prior patient location (PL) 00136
      • 3.3.3.7 Attending doctor (XCN) 00137
      • 3.3.3.8 Referring doctor (XCN) 00138
      • 3.3.3.9 Consulting doctor (XCN) 00139
      • 3.3.3.10 Hospital service (IS) 00140
      • 3.3.3.11 Temporary location (PL) 00141
      • 3.3.3.12 Preadmit test indicator- (IS) 00142
      • 3.3.3.13 Re-admission indicator- (IS) 00143
      • 3.3.3.14 Admit source (IS) 00144
      • 3.3.3.15 Ambulatory status (IS) 00145
      • 3.3.3.16 VIP indicator (IS) 00146
      • 3.3.3.17 Admitting doctor (XCN) 00147
      • 3.3.3.18 Patient type (IS) 00148
      • 3.3.3.19 Visit number (CX) 00149
      • 3.3.3.20 Financial class (FC) 00150
      • 3.3.3.21 Charge price indicator (IS) 00151
      • 3.3.3.22 Courtesy code (IS) 00152
      • 3.3.3.23 Credit rating (IS) 00153
      • 3.3.3.24 Contract code (IS) 00154
      • 3.3.3.25 Contract effective date (DT) 00155
      • 3.3.3.26 Contract amount (NM) 00156
      • 3.3.3.27 Contract period (NM) 00157
      • 3.3.3.28 Interest code (IS) 00158
      • 3.3.3.29 Transfer to bad debt code (IS) 00159
      • 3.3.3.30 Transfer to bad debt date (DT) 00160
      • 3.3.3.31 Bad debt agency code (IS) 00161
      • 3.3.3.32 Bad debt transfer amount (NM) 00162
      • 3.3.3.33 Bad debt recovery amount (NM) 00163
      • 3.3.3.34 Delete account indicator (IS) 00164
      • 3.3.3.35 Delete account date (DT) 00165
      • 3.3.3.36 Discharge disposition (IS) 00166
      • 3.3.3.37 Discharged to location (CM) 00167
      • 3.3.3.38 Diet type (CE) 00168
      • 3.3.3.39 Servicing facility (IS) 00169
      • 3.3.3.40 Bed status (IS) 00170
      • 3.3.3.41 Account status (IS) 00171
      • 3.3.3.42 Pending location (PL) 00172
      • 3.3.3.43 Prior temporary location (PL) 00173
      • 3.3.3.44 Admit date/time (TS) 00174
      • 3.3.3.45 Discharge date/time (TS) 00175
      • 3.3.3.46 Current patient balance (NM) 00176
      • 3.3.3.47 Total charges (NM) 00177
      • 3.3.3.48 Total adjustments (NM) 00178
      • 3.3.3.49 Total payments (NM) 00179
      • 3.3.3.50 Alternate visit ID (CX) 00180
      • 3.3.3.51 Visit indicator (IS) 01226
      • 3.3.3.52 Other healthcare provider (XCN) 01274
      • 3.3.3.53 PV1 usage notes
    • 3.3.4 PV2 - patient visit - additional information segment
      • 3.3.4.0 PV2 field definitions
      • 3.3.4.1 Prior pending location (PL) 00181
      • 3.3.4.2 Accommodation code (CE) 00182
      • 3.3.4.3 Admit reason (CE) 00183
      • 3.3.4.4 Transfer reason (CE) 00184
      • 3.3.4.5 Patient valuables (ST) 00185
      • 3.3.4.6 Patient valuables location (ST) 00186
      • 3.3.4.7 Visit user code (IS) 00187
      • 3.3.4.8 Expected admit date/time (TS) 00188
      • 3.3.4.9 Expected discharge date/time (TS) 00189
      • 3.3.4.10 Estimated length of inpatient stay (NM) 00711
      • 3.3.4.11 Actual length of inpatient stay (NM) 00712
      • 3.3.4.12 Visit description (ST) 00713
      • 3.3.4.13 Referral source (XCN) 00714
      • 3.3.4.14 Previous service date (DT) 00715
      • 3.3.4.15 Employment illness related indicator (ID) 00716
      • 3.3.4.16 Purge status code (IS) 00717
      • 3.3.4.17 Purge status date (DT) 00718
      • 3.3.4.18 Special program code (IS) 00719
      • 3.3.4.19 Retention indicator (ID) 00720
      • 3.3.4.20 Expected number of insurance plans (NM) 00721
      • 3.3.4.21 Visit publicity code (IS) 00722
      • 3.3.4.22 Visit protection indicator (ID) 00723
      • 3.3.4.23 Clinic organization name (XON) 00724
      • 3.3.4.24 Patient status code (IS) 00725
      • 3.3.4.25 Visit priority code (IS) 00726
      • 3.3.4.26 Previous treatment date (DT) 00727
      • 3.3.4.27 Expected discharge disposition (IS) 00728
      • 3.3.4.28 Signature on file date (DT) 00729
      • 3.3.4.29 First similar illness date (DT) 00730
      • 3.3.4.30 Patient charge adjustment code (CE) 00731
      • 3.3.4.31 Recurring service code (IS) 00732
      • 3.3.4.32 Billing media code (ID) 00733
      • 3.3.4.33 Expected surgery date and time (TS) 00734
      • 3.3.4.34 Military partnership code (ID) 00735
      • 3.3.4.35 Military non-availability code (ID) 00736
      • 3.3.4.36 Newborn baby indicator (ID) 00737
      • 3.3.4.37 Baby detained indicator (ID) 00738
    • 3.3.5 NK1 - next of kin / associated parties segment
      • 3.3.5.0 NK1 field definitions
      • 3.3.5.1 Set ID - NK1- (SI) 00190
      • 3.3.5.2 Name (XPN) 00191
      • 3.3.5.3 Relationship (CE) 00192
      • 3.3.5.4 Address (XAD) 00193
      • 3.3.5.5 Phone number (XTN) 00194
      • 3.3.5.6 Business phone number (XTN) 00195
      • 3.3.5.7 Contact role (CE) 00196
      • 3.3.5.8 Start date (DT) 00197
      • 3.3.5.9 End date (DT) 00198
      • 3.3.5.10 Next of kin / associated parties job title (ST) 00199
      • 3.3.5.11 Next of kin / associated parties job code/class (JCC) 00200
      • 3.3.5.12 Next of kin / associated parties employee number (CX) 00201
      • 3.3.5.13 Organization name - NK1 (XON) 00202
      • 3.3.5.14 Marital status (CE) 00119
      • 3.3.5.15 Sex (IS) 00111
      • 3.3.5.16 Date/time of birth (TS) 00110
      • 3.3.5.17 Living dependency (IS) 00755
      • 3.3.5.18 Ambulatory status (IS) 00145
      • 3.3.5.19 Citizenship (CE) 00129
      • 3.3.5.20 Primary language (CE) 00118
      • 3.3.5.21 Living arrangement (IS) 00742
      • 3.3.5.22 Publicity code (CE) 00743
      • 3.3.5.23 Protection indicator (ID) 00744
      • 3.3.5.24 Student indicator (IS) 00745
      • 3.3.5.25 Religion (CE) 00120
      • 3.3.5.26 Mother's maiden name' (XPN) 00109
      • 3.3.5.27 Nationality (CE) 00739
      • 3.3.5.28 Ethnic group (CE) 00125
      • 3.3.5.29 Contact reason (CE) 00747
      • 3.3.5.30 Contact person's name' (XPN) 00748
      • 3.3.5.31 Contact person's telephone number' (XTN) 00749
      • 3.3.5.32 Contact person's address (XAD) 00750
      • 3.3.5.33 Next of kin/associated party's identifiers (CX) 00751
      • 3.3.5.34 Job status (IS) 00752
      • 3.3.5.35 Race (CE) 00113
      • 3.3.5.36 Handicap (IS) 00753
      • 3.3.5.37 Contact person social security number (ST) 00754
    • 3.3.6 AL1 - patient allergy information segment
      • 3.3.6.0 AL1 field definitions
      • 3.3.6.1 Set ID - AL1 (SI) 00203
      • 3.3.6.2 Allergy type (IS) 00204
      • 3.3.6.3 Allergy code/mnemonic/description (CE) 00205
      • 3.3.6.4 Allergy severity (IS) 00206
      • 3.3.6.5 Allergy reaction (ST) 00207
      • 3.3.6.6 Identification date (DT) 00208
    • 3.3.7 NPU - bed status update segment
      • 3.3.7.0 NPU field definitions
      • 3.3.7.1 Bed location (PL) 00209
      • 3.3.7.2 Bed status (IS) 00170
    • 3.3.8 MRG - merge patient information segment
      • 3.3.8.0 MRG field definitions
      • 3.3.8.1 Prior patient identifier list- (CX) 00211
      • 3.3.8.2 Prior alternate patient ID (CX) 00212
      • 3.3.8.3 Prior patient account number (CX) 00213
      • 3.3.8.4 Prior patient ID (CX) 00214
      • 3.3.8.5 Prior visit number (CX) 01279
      • 3.3.8.6 Prior alternate visit ID (CX) 01280
      • 3.3.8.7 Prior patient name (XPN) 01281
      • 3.3.8.8 Segment notes: MRG merge patient information
    • 3.3.9 PD1 - patient additional demographic segment
      • 3.3.9.0 PD1 field definitions
      • 3.3.9.1 Living dependency (IS) 00755
      • 3.3.9.2 Living arrangement (IS) 00742
      • 3.3.9.3 Patient primary facility (XON) 00756
      • 3.3.9.4 Patient primary care provider name & ID no. (XCN) 00757
      • 3.3.9.5 Student indicator (IS) 00745
      • 3.3.9.6 Handicap (IS) 00753
      • 3.3.9.7 Living will (IS) 00759
      • 3.3.9.8 Organ donor (IS) 00760
      • 3.3.9.9 Separate bill (ID) 00761
      • 3.3.9.10 Duplicate patient (CX) 00762
      • 3.3.9.11 Publicity code (CE) 00743
      • 3.3.9.12 Protection indicator (ID) 00744
    • 3.3.10 DB1 - disability segment
      • 3.3.10.0 DB1 field definitions
      • 3.3.10.1 Set ID - DB1 (SI) 01283
      • 3.3.10.2 Disabled person code (IS) 01284
      • 3.3.10.3 Disabled person identifier (CX) 01285
      • 3.3.10.4 Disability indicator (ID) 01286
      • 3.3.10.5 Disability start date (DT) 01287
      • 3.3.10.6 Disability end date (DT) 01288
      • 3.3.10.7 Disability return to work date (DT) 01289
      • 3.3.10.8 Disability unable to work date (DT) 01290
  • 3.4 EXAMPLE TRANSACTIONS
    • 3.4.1 Admit/visit notification - event A01 (admitted patient)-
    • 3.4.2 Pre-admit notification - event A05 (nonadmitted patient)
    • 3.4.3 Register a patient - event A04 (nonadmitted patient)
    • 3.4.4 Change an outpatient to an inpatient - event A06
    • 3.4.5 Transfer patient - event A02 (first example)
    • 3.4.6 Cancel transfer - event A12
    • 3.4.7 Transfer patient - event A02 (second example)
    • 3.4.8 Discharge patient - event A03
  • 3.5 IMPLEMENTATION CONSIDERATIONS
    • 3.5.1 Swapping a patient
    • 3.5.2 Merging patient/person information
      • 3.5.2.1 Definitions: Merge, move, and change identifier events
        • 3.5.2.1.1 Hierarchy of Identifiers
        • 3.5.2.1.2 Merge
        • 3.5.2.1.3 Move
        • 3.5.2.1.4 Change identifier
        • 3.5.2.1.5 Source and target identifiers
        • 3.5.2.1.6 Tightly coupled relationship
        • 3.5.2.1.7 Ordered pairwise relationship
        • 3.5.2.1.8 Identifier type / assigning authority relationship
        • 3.5.2.1.9 Global merge and move message construct versus repeating segment message constructs
        • 3.5.2.1.10 Identifier renumbering
        • 3.5.2.1.11 Superior identifier reporting
      • 3.5.2.2 Trigger events
        • 3.5.2.2.1 A18 - Merge patient information
        • 3.5.2.2.2 A30 - Merge person information
        • 3.5.2.2.3 A34 - Merge patient information - patient ID only
        • 3.5.2.2.4 A35 - Merge patient information - account number only
        • 3.5.2.2.5 A36 - Merge patient information - patient ID & account number
        • 3.5.2.2.6 A39 - Merge person - patient ID
        • 3.5.2.2.7 A46 - Change patient ID
        • 3.5.2.2.8 A48 - Change alternate patient ID
        • 3.5.2.2.9 A39 - merge person - patient ID
        • 3.5.2.2.10 A40 - merge patient - patient identifier list
        • 3.5.2.2.11 A40 - merge patient - patient identifier list (repeating segment)
        • A41 - merge account - patient account number (global)
        • 3.5.2.2.12 A41 - merge account - patient account number (repeating segment)
        • 3.5.2.2.13 A42 - Merge visit - visit number
        • 3.5.2.2.14 A43 - move patient information - patient identifier list
        • 3.5.2.2.15 A44 - move account information - patient account number
        • 3.5.2.2.16 A45 - move visit information - visit number (repeating segment)
        • 3.5.2.2.17 A45 - move visit information - visit number (repeating segment)
        • 3.5.2.2.18 A46 - change patient ID
        • 3.5.2.2.19 A47 - change patient identifier list
        • 3.5.2.2.20 A48 - change alternate patient ID
        • 3.5.2.2.21 A49 - change patient account number
        • 3.5.2.2.22 A50 - change visit number
        • 3.5.2.2.23 A51 - change alternate visit ID
        • 3.5.2.2.24 Example using multiple messages
        • 3.5.2.2.25 Example using multiple messages
    • 3.5.3 Patient record links

3 .
Patient Administration

3.1 PURPOSE

The Patient Administration transaction set provides for the transmission of new or updated demographic and visit information about patients. Since virtually any system attached to the network requires information about patients, the Patient Administration transaction set is one of the most commonly used.
Generally, information is entered into a Patient Administration system and passed to the nursing, ancillary and financial systems either in the form of an unsolicited update or a response to a record-oriented query.
This chapter defines the transactions that occur at the seventh level, that is, the abstract messages. The examples included in this chapter were constructed using the HL7 Encoding Rules.

3.2 TRIGGER EVENTS AND MESSAGE DEFINITIONS

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.11, "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.

3.2.1 ADT/ACK - admit/visit notification (event A01)

An A01 event is intended to be used for "Admitted" patients only. An A01 event is sent as a result of a patient undergoing the admission process which assigns the patient to a bed. It signals the beginning of a patient's stay in a healthcare facility. Normally, this information is entered in the primary Patient Administration system and broadcast to the nursing units and ancillary systems. It includes short stay and John Doe 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.

3.2.2 ADT/ACK - transfer a patient (event A02)

An A02 event is issued as a result of the patient changing his or her assigned physical location.
The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition. If the transfer function of your Patient Administration system allows demographics to change at the same time as the transfer (for example an address change), we recommend (but do not require) sending two messages (an A02 followed by an A08). This A02 event can be used with admitted and non-admitted patients.
The new patient location should appear in PV1-3-assigned patient location while the old patient location should appear in PV1-6-prior patient location. For example, an A02 event can be used to notify: laboratory, radiology, pathology that the patient has changed location and test results should be redirected; pharmacy that drugs should be redirected for the patient; dietary that the meals should be delivered to a different location; the clinical repository that a transfer has taken place for the EMR.
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.

3.2.3 ADT/ACK - discharge/end visit (event A03)

An A03 event signals the end of a patient's stay in a healthcare facility. It signals that the patient's status has changed to "discharged" and that a discharge date has been recorded. The patient is no longer in the facility. The patient's location prior to discharge should be entered in PV1-3-assigned patient location.
An A03 event can be sent to notify: the pharmacy that the patient's stay has ended and that entitlement to drugs has changed accordingly; the nursing system that the patient has been discharged and that the care plan can be completed; the 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 and 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.

3.2.4 ADT/ACK - register a patient (event A04)

An A04 event signals that the patient has arrived or checked in as a one-time, or recurring outpatient, and is not assigned to a bed. One example might be its use to signal the beginning of a visit to the Emergency Room. 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.

3.2.5 ADT/ACK - pre-admit a patient (event A05)

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

3.2.6 ADT/ACK - change an outpatient to an inpatient (event A06)

An A06 event is sent when a patient who was present for a non-admitted visit is being admitted after an evaluation of the seriousness of the patient's condition. This event changes a patient's status from non-admitted to admitted. The new patient location should appear in PV1-3-assigned patient location, while the old patient location (if different) should appear in PV1-6-prior patient location. The new patient class should appear in PV1-2-patient class.
It will be left to implementation negotiation to determine whether disparate systems merely change the patient class, or close and open a new account. The current active account number should appear in 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.

3.2.7 ADT/ACK - change an inpatient to an outpatient (event A07)

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

3.2.8 ADT/ACK - update patient information (event A08)

This trigger event is used when any patient information has changed but when no other trigger event has occurred. For example, an A08 event can be used to notify the receiving systems of a change of address or a name change. We 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.

3.2.9 ADT/ACK - patient departing - tracking (event A09)

The A09 and A10 (patient arriving-tracking) events are used when there is a change in a patient's physical location and when this is NOT a change in the official census bed location. 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 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.

3.2.10 ADT/ACK - patient arriving - tracking (event A10)

The A10 event is sent when a patient arrives at a new location in the healthcare facility. 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. 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.

3.2.11 ADT/ACK - cancel admit / visit notification (event A11)

For "admitted" patients, the A11 event is sent when an A01 (admit/visit notification) event is canceled, 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 canceled, 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.

3.2.12 ADT/ACK - cancel transfer (event A12)

The A12 event is sent when an A02 (transfer a patient) event is canceled, 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.

3.2.13 ADT/ACK - cancel discharge / end visit (event A13)

The A13 event is sent when an A03 (discharge/end visit) event is canceled, 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.

3.2.14 ADT/ACK - pending admit (event A14)

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

3.2.15 ADT/ACK - pending transfer (event A15)

An A15 event notifies other systems of a plan to transfer a patient to a new location when the patient has not yet left the old location. It is used when advanced notification of a transfer is required in order to prepare for the patient's location change. For example, this transaction could be sent so that orderlies 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 DG1 segment remains in this message for backward compatibility only.

3.2.16 ADT/ACK - pending discharge (event A16)

An A16 event notifies other systems of a plan to discharge a patient when the patient has not yet left the healthcare facility. It is used when advanced notification of a discharge is required in order to prepare for the patient's change in location. For example, it is used to notify the pharmacy of the possible need for discharge drugs or to notify psychotherapy of the possible need for post-discharge appointments.
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.

3.2.17 ADT/ACK - swap patients (event A17)

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

3.2.18 ADT/ACK - merge patient information (event A18)

Event A18 is being retained for backward compatibility. The A18 event is 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). We recommend that events A34 (merge patient information-patient ID only), A35 (merge patient information-account number only), A36 (merge patient information-patient ID & account number), A39 (merge person-patient ID), A40 (merge patient-patient identifier list), A41 (merge account-patient account number), and A42 (merge visit-visit number) be utilized in place of the A18 event whenever possible.
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, new events (A34 (merge patient information-patient ID only), A35 (merge patient information-account number only), A36 (merge patient information-patient ID & account number), A39 (merge person-patientID), 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.5.2, "Merging patient/person information," for a discussion of issues related to implementing patient merge events.

3.2.19 QRY/ADR - patient query (event A19)

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.

3.2.19.1 A19 usage notes

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 QRD-9-what subject filter may be used, such as:

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).

3.2.20 ADT/ACK - bed status update (event A20)

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

3.2.21 ADT/ACK - patient goes on a "leave of absence (event A21)

An A21 event is sent to notify systems that an admitted patient has left the healthcare institution temporarily. It is used for systems in which a bed is still assigned to the patient, and it puts the current admitted patient activities on hold. For example, it is used to notify dietary services and laboratory systems when the patient goes home for the weekend.
The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

3.2.22 ADT/ACK - patient returns from a "leave of absence (event A22)

An A22 event is sent to notify systems that an admitted patient has returned to the healthcare institution after a temporary "leave of absence." It is used for systems in which a bed is still assigned to the patient, and it takes their current admitted patient activities off of "hold" status. For example, it is used to notify dietary services and laboratory systems when the patient returns from a weekend trip to his/her home.
The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

3.2.23 ADT/ACK - delete a patient record (event A23)

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

3.2.24 ADT/ACK - link patient information (event A24)

The A24 event is used when the first PID segment needs to be linked to the second PID segment and when both patient identifiers identify the same patient. Linking two or more patients does not require the actual merging of patient information; following a link event, the affected patient data records should remain distinct. For example, this event could be used in a hospital network environment in which there are multiple campuses and in which records need to be linked. For example, hospital A, hospital B, and hospital C would each keep their own records on a patient, but an A24 link event would be sent to a corporate-wide MPI to enable the coupling of ID information with the corporate ID number. It is used for corporate data repositories, etc. This event is not meant to link mothers and babies since a field exists (PID-21-mother's identifier) for that purpose. See Section 3.5.3, "Patient record links," for a discussion of issues related to implementing patient link messages and MPI issues.
This event can also be used to link two patient identifiers when a patient changes from inpatient to outpatient, or vice versa. This event can also be used to link two visits of the same patient.
The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.

3.2.25 ADT/ACK - cancel pending discharge (event A25)

The A25 event is sent when an A16 (pending discharge) event is canceled, 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.

3.2.26 ADT/ACK - cancel pending transfer (event A26)

The A26 event is sent when an A15 (pending transfer) event is canceled, 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.

3.2.27 ADT/ACK - cancel pending admit (event A27)

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.

3.2.28 ADT/ACK - add person information (event A28)

The purpose of this and the three following messages is 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. Visit information may be included but is not required. 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-2-patient ID, 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-2-patient ID. 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.