References to other Chapters

HL7 Chapter 3 Version 2.3

• 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 & (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 - external ID (event A39)
  • 3.2.40 ADT/ACK - merge patient - internal ID (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 - internal ID (event A43)
  • 3.2.44 ADT/ACK - move account information - patient account no. (event A44)
  • 3.2.45 ADT/ACK - move visit information - visit number (event A45)
  • 3.2.46 ADT/ACK - change external ID (event A46)
  • 3.2.47 ADT/ACK - change internal ID (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.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.1 Set ID - patient ID- (SI) 00104
    • 3.3.2.2 Patient ID (external ID) (CX) 00105
    • 3.3.2.3 Patient ID (internal ID) (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 (IS) 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 (IS) 00119
    • 3.3.2.17 Religion (IS) 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 (IS) 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 (IS) 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.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 (IS) 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) 01224
    • 3.3.3.53 PV1 usage notes
  • 3.3.4 PV2 - patient visit - additional information segment
    • 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 (IS) 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.1 Set ID - next of kin / associated parties- (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 (XON) 00202
    • 3.3.5.14 Marital status (IS) 00119
    • 3.3.5.15 Sex code (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 (IS) 00129
    • 3.3.5.20 Primary language (CE) 00118
    • 3.3.5.21 Living arrangement (IS) 00742
    • 3.3.5.22 Publicity indicator (CE) 00743
    • 3.3.5.23 Protection indicator (ID) 00744
    • 3.3.5.24 Student indicator (IS) 00745
    • 3.3.5.25 Religion (IS) 00120
    • 3.3.5.26 Mother's maiden name' (XPN) 00746
    • 3.3.5.27 Nationality (CE) 00739
    • 3.3.5.28 Ethnic group (IS) 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 address (XAD) 00750
    • 3.3.5.33 Next of kin/associated party identifiers (CX) 00751
    • 3.3.5.34 Job status (IS) 00752
    • 3.3.5.35 Race (IS) 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.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.1 Bed location (PL) 00209
    • 3.3.7.2 Bed status (IS) 00170
  • 3.3.8 MRG - merge patient information segment-
    • 3.3.8.1 Prior patient ID - internal- (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 - external (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.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 Patient separate bill indicator (ID) 00761
    • 3.3.9.10 Duplicate patient (CX) 00762
    • 3.3.9.11 Publicity indicator (CE) 00743
    • 3.3.9.12 Protection indicator (ID) 01293
  • 3.3.10 DB1 - Disability segment
    • 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 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 Admit/visit notification - event A04 (nonadmitted patient)
  • 3.4.4 Change outpatient to 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 identifiers
      • 3.5.2.1.7 Global merge and move message construct
      • 3.5.2.1.8 Identifier renumbering
      • 3.5.2.1.9 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 - external ID
      • 3.5.2.2.7 A40 - merge patient - internal ID
      • 3.5.2.2.8 A40 - merge patient - internal ID (repeating segment)
      • 3.5.2.2.9 A41 - merge account - patient account number (global)
      • 3.5.2.2.10 A41 - merge account - patient account no. (repeating segment)
      • 3.5.2.2.11 A42 - Merge visit - visit number
      • 3.5.2.2.12 A43 - move patient information - internal ID
      • 3.5.2.2.13 A44 - move account information - patient account number
      • 3.5.2.2.14 A45 - move visit information - visit number (repeating segment)
      • 3.5.2.2.15 A45 - move visit information - visit number (repeating segment)
      • 3.5.2.2.16 A46 - change external ID
      • 3.5.2.2.17 A47 - change internal ID
      • 3.5.2.2.18 A48 - change alternate patient ID
      • 3.5.2.2.19 A49 - change patient account number
      • 3.5.2.2.20 A50 - change visit number
      • 3.5.2.2.21 A51 - change alternate visit ID
      • 3.5.2.2.22 Example using multiple messages
      • 3.5.2.2.23 Example using multiple messages
  • 3.5.3 Patient record links
• 3.6 OUTSTANDING ISSUES

3.

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 an 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 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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ { NK1 } ] Next of Kin /Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[ { PR1 Procedures 6
[{ROL}] Role 12
}]
[ { GT1 } ] Guarantor 6
[
{ IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[ IN3 ] Insurance Add'l Info - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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, 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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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/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 patient 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-death date/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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { DG1 } ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[ { PR1 Procedures 6
[{ROL}] Role 12
}]
[ { OBX } ] Observation/Result 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ { NK1 } ] Next of Kin /Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[ { PR1 Procedures 6
[{ROL}] Role 12
}]
[ { GT1 } ] Guarantor 6
[
{ IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[ IN3 ] Insurance Add'l Info - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ { NK1 } ] Next of Kin /Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[ { PR1 Procedures 6
[{ROL}] Role 12
}]
[ { GT1 } ] Guarantor 6
[
{ IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[ IN3 ] Insurance Add'l Info - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ MRG ] Merge Information 3
[ { NK1 } ] Next of Kin /Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ DRG ] Diagnosis Related Group 6
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[ { PR1 Procedures 6
[{ROL}] Role 12
}]
[ { GT1 } ] Guarantor 6
[
{ IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[ IN3 ] Insurance Add'l Info - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6

ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ MRG ] Merge Information 3
[ { NK1 } ] Next of Kin /Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ DRG ] Diagnosis Related Group 6
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[ { PR1 Procedures 6
[{ROL]} Role 12
}]
[ { GT1 } ] Guarantor 6
[
{ IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[ IN3 ] Insurance Add'l Info - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6

ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ { NK1 } ] Next of Kin /Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[ { PR1 Procedures 6
[{ROL}] Role 12
}]
[ { GT1 } ] Guarantor 6
[
{ IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[ IN3 ] Insurance Add'l Info - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { DG1 } ] Diagnosis Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { DG1 } ] Diagnosis Information 6

ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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 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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { DG1 } ] Diagnosis Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ DG1 ] Diagnosis Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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 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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ { NK1 } ] Next of Kin /Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[ { PR1 Procedures 6
[{ROL}] Role 12
}]
[ { GT1 } ] Guarantor 6
[
{ IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[ IN3 ] Insurance Add'l Info - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ { NK1 } ] Next of Kin /Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[ { PR1 Procedures 6
[{ROL}] Role 12
}]
[ { GT1 } ] Guarantor 6
[
{ IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[ IN3 ] Insurance Add'l Info - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { DG1 } ] Diagnosis Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[DG1 ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient (1) Identification 3
[PD1] Additional Demographics 3
PV1 Patient (1) Visit 3
[ PV2 ] Patient (1) Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result (1) 7
PID Patient (2) Identification 3
[PD1] Additional Demographics 3
PV1 Patient (2) Visit 3
[ PV2 ] Patient (2) Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result (2) 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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 ID ( internal ID), PID-2-patient ID (external 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 and account number), A39 (merge person-external ID), A40 (merge patient-internal ID), 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-external ID), A40 (merge patient-internal ID), 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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ MRG ] Merge Information 3
PV1 Patient Visit 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
QRY Patient Query Chapter
MSH Message Header 2
QRD Query Definition 2
[ QRF ] Query Filter 2
ADR ADT Response Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
QRD Query Definition 2
[ QRF ] Query Filter 2
{
[ EVN ] Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ {NK1} ] Next of Kin /Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ {OBX} ] Observation/Result 7
[ {AL1} ] Allergy Information 3
[ {DG1} ] Diagnosis Information 6
[DRG] Diagnosis Related Group 6
[ {PR1 Procedures 6
[{ROL}] Role 12
}]
[ {GT1} ] Guarantor 6
[
{
IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[ IN3 ] Insurance Add'l Info - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill Information 6

}
[ DSC ] Continuation Pointer 2

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-3-R/U who subject definition 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:
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
NPU Non-Patient Update 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
This event can also be used to link two patient identifiers when a patient changes from inpatient to outpatient, or vice versa. This event can also be used to link two visits of the same patient.
The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient (1) Identification 3
[PD1] Patient (1) Additional Demographics 3
[ PV1 ] Patient (1) Visit 3
[ { DB1 } ] Disability Information 3
PID Patient (2) Identification 3
[PD1] Patient (2) Additional Demographics 3
[ PV1 ] Patient (2) Visit 3
[ { DB1 } ] Disability Information 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

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 (external), 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 (external). 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.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ { NK1 } ] Next of Kin /Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[ { PR1 Procedures 6
[{ROL}] Role 12
}]
[ { GT1 } ] Guarantor 6
[
{ IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[ IN3 ] Insurance Add'l Info - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.29 ADT/ACK - delete person information (event A29)

An A29 event can be used to delete all demographic information related to a given person. This event "undoes" an A28 (add person information) event. The information from the A28 event is deleted. This event is used, for example, when adding the information was performed in error, or when another record already exists for the person, or one wants to purge the person from the database. When this event occurs, all visit and account level data for this person is also purged.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.30 ADT/ACK - merge person information (event A30)

Event A18 is being retained for backward compatibility. An A30 event can be used to merge person information on an MPI. The A34 (merge patient information-patient ID only), A35 (merge patient information-account number only), A36 (merge patient information-patient ID & account number), A40 (merge patient-internal ID), A41(merge account-patient account number) and A42 (merge visit-visit number)events should be used to merge patient information for a current episode. The "incorrect MRN" identified on the MRG segment (MRG-1-prior patient ID-internal) is to be merged with the "correct MRN" identified on the PID segment (PID-3-patient ID (internal ID)). The "incorrect MRN" then no longer exists. All PID data associated with the "correct MRN" are treated as updated information.
The MRNs involved may or may not have active or inactive cases associated with them. Any episode of care that was previously associated with the "incorrect MRN" is now associated with the "correct MRN." A list of these cases is not provided.
The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.
An A30 (merge person information) is intended for merging person records without merging patient identifiers.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.31 ADT/ACK - update person information (event A31)

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

ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
[ { NK1 } ] Next of Kin /Associated Parties 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { AL1 } ] Allergy Information 3
[ { DG1 } ] Diagnosis Information 6
[ DRG ] Diagnosis Related Group 6
[ { PR1 Procedures 6
{[ROL}] Role 12
}]
[ { GT1 } ] Guarantor 6
[
{ IN1 Insurance 6
[ IN2 ] Insurance Additional Info. 6
[ IN3 ] Insurance Add'l Info - Cert. 6
}
]
[ ACC ] Accident Information 6
[ UB1 ] Universal Bill Information 6
[ UB2 ] Universal Bill 92 Information 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.32 ADT/ACK - cancel patient arriving - tracking (event A32)

The A32 event is sent when an A10 (patient arriving-tracking) event is canceled, either because of erroneous entry of the A10 event or because of a decision not to receive the patient after all.
If the patient was in a non-temporary location, then the PV1-3-assigned patient location may contain (if known) the original patient location prior to the erroneous A10 (patient arriving-tracking) event. If the patient was in a temporary location, then PV1-11-temporary location may contain (if known) the original patient location prior to the erroneous A10 (patient arriving-tracking) event.
The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.33 ADT/ACK - cancel patient departing - tracking (event A33)

The A33 event is sent when an A09 (patient departing-tracking) event is canceled, either because of erroneous entry of the A09 event or because of a decision not to send the patient after all.
If the patient was in a non-temporary location, then PV1-3-assigned patient location must contain the original patient location prior to the erroneous A09 (patient departing-tracking) event. If the patient was in a temporary location, then PV1-11-temporary location must contain the original patient location prior to the erroneous A09 (patient departing-tracking) event.
The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.34 ACK/ADT - merge patient information - patient ID only (event A34)

Event A18 is being retained for backward compatibility. Only PID-3-patient ID (internal ID) has changed as a result of the merge. See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of merge messages.
An A34 (merge patient information-patient ID only) event is intended for merging or changing patient identifiers. It would be used to change patient identifiers on all of this patient's existing accounts.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error Information 2

3.2.35 ADT/ACK - merge patient information - account number only (event A35)

Event A18 is being retained for backward compatibility. Only the patient account number has changed as a result of the merge. See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of merge messages.
An A35 (merge patient information-account number only) event is intended for merging or changing an account number only.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.36 ADT/ACK - merge patient information - patient ID & account number (event A36)

Event A18 is being retained for backward compatibility. Both the patient identification-internal and the patient account number have changed as a result of the merge. See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of merge messages.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.37 ADT/ACK - unlink patient information (event A37)

The A37 event unlinks two PID segments previously linked with an A24 (link patient information) event.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient (1) Identification 3
[PD1] Additional Demographics 3
[ PV1 ] Patient (1) Visit 3
[ { DB1 } ] Disability Information 3
PID Patient (2) Identification 3
[ PV1 ] Patient (2) Visit 3
[ { DB1 } ] Disability Information 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.38 ADT/ACK - cancel pre-admit (event A38)

The A38 event is sent when an A05 (pre-admit a patient) event is canceled, either because of erroneous entry of the A05 event or because of a decision not to pre-admit the patient after all.
The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
[ { DG1 } ] Diagnosis Information 6
[DRG] Diagnosis Related Group 6
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.39 ADT/ACK - merge person - external ID (event A39)

A merge has been done at the external identifier level. That is, two PID-2-patient ID (external ID) identifiers have been merged into one.
An A39 event is used to signal a merge of records for a person that was incorrectly filed under two different external IDs. The "incorrect source external ID" identified in the MRG segment (MRG-4-prior patient ID-external) is to be merged with the required "correct target external ID" identified in the PID segment (PID-2-patient ID (external ID)). The "incorrect source external ID" would then logically never be referenced in future transactions. It is noted that some systems may still physically keep this "incorrect identifier" for audit trail purposes or other reasons associated with database index implementation requirements.
Since this event is a merge at the PID-2-patient ID (external ID) identifier level, PID-3-patient ID (internal ID) and MRG-1-prior patient ID-internal ID are not required.
The external IDs involved in identifying the persons may or may not be patients, who may or may not have accounts, which may or may not have visits. An A39 (merge person-external ID) event is intended for merging person records without merging other subordinate identifiers. Any other subordinate identifiers that were previously associated with the "incorrect source external ID" are now associated with the "correct target external ID." Specification of these other subordinate identifiers is not required.
This event and the message syntax do, however, allow for the specification of "new subordinate identifiers" (in addition to the PID-2-patient ID (external ID) identifier). For those environments that may require changes to these other subordinate identifiers because of an A39 (merge person-external ID), it is required that the old and new identifiers be a "tightly coupled" pair.
See section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of merge messages.
All data associated with the "correct target external ID" are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
{ PID Patient Identification 3
[ PD1 ] Additional Demographics 3
MRG Merge Information 3
[ PV1] Patient Visit 3
}
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.40 ADT/ACK - merge patient - internal ID (event A40)

A merge has been done at the internal identifier level. That is, two PID-3-patient ID (internal ID) identifiers have been merged into one.
An A40 event is used to signal a merge of records for a patient that was incorrectly filed under two different internal IDs. The "incorrect source internal ID" identified in the MRG segment (MRG-1-prior patient ID (internal) is to be merged with the required "correct target internal ID" of the same "identifier type code" component identified in the PID segment (PID-3-patient ID (internal ID)). The "incorrect source internal ID" would then logically never be referenced in future transactions. It is noted that some systems may still physically keep this "incorrect identifier" for audit trail purposes or other reasons associated with database index implementation requirements.
The internal IDs involved in identifying the patients may or may not have accounts, which may or may not have visits. An A40 (merge patient-internal ID) event is intended for merging patient records without merging other subordinate identifiers. Any other subordinate identifiers that were previously associated with the "incorrect source internal ID" are now associated with the "correct target internal ID". Specification of these other subordinate identifiers is not required.
This event and the message syntax do, however, allow for the specification of any other "new subordinate identifiers" (in addition to the PID-3-patient ID (internal ID) identifier). For those environments that may require changes to these other subordinate identifiers because of the A40 (merge patient-internal ID) event, it is required that the old and new identifiers be a "tightly coupled" pair.
Each superior identifier associated with this internal identifier level should have the same value in both the PID and MRG segments.
See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of merge messages.
All data associated with the "correct target internal ID" are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
{ PID Patient Identification 3
[ PD1] Additional Demographics 3
MRG Merge Information 3
[ PV1] Patient Visit 3
}
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.41 ADT/ACK - merge account - patient account number (event A41)

A merge has been done at the account identifier level. That is, two PID-18-patient account number identifiers have been merged into one.
An A41 event is used to signal a merge of records for an account that was incorrectly filed under two different account numbers. The "incorrect source patient account number" identified in the MRG segment (MRG-3-prior patient account number) is to be merged with the "correct target patient account number" identified in the PID segment (PID-18-patient account number). The "incorrect source patient account number" would then logically never be referenced in future transactions. It is noted that some systems may still physically keep this "incorrect identifier" for audit trail purposes or other reasons associated with database index implementation requirements.
The patient account numbers involved may or may not have visits. An A41 (merge account-patient account number) is intended for merging account records without merging other subordinate identifiers. Any other subordinate identifiers that were previously associated with the "incorrect source account number" are now associated with the required "correct target account number." Specification of these other subordinate identifiers is not required.
This event and the message syntax do, however, allow for the specification of any other "new subordinate identifiers" (in addition to the PID-18-patient account number identifier). For those environments that may require changes to these other subordinate identifiers because of this A41 (merge account-patient account number) event, it is required that the old and new identifiers be a "tightly coupled" pair.
Each superior identifier associated with this account identifier level should have the same value in both the PID and MRG segments.
See Section 3.5.23.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of merge messages.
All data associated with the "correct target account number" are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
{ PID Patient Identification 3
[ PD1] Additional Demographics 3
MRG Merge Information 3
[ PV1] Patient Visit 3
}
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.42 ADT/ACK - merge visit - visit number (event A42)

A merge has been done at the visit identifier level. That is, two PV1-19-visit number identifiers have been merged into one.
An A42 event is used to signal a merge of records for a visit that was incorrectly filed under two different visit numbers. The "incorrect source visit number" identified in the MRG segment (MRG-5-prior visit number) is to be merged with the required "correct target visit number" identified in the PV1 segment (PV1-19-visit number). The "incorrect source visit number" would then logically never be referenced in future transactions. It is noted that some systems may still physically keep this "incorrect identifier" for audit trail purposes or other reasons associated with database index implementation requirements.
An A42 (merge visit-visit number) event is intended for merging visit records without merging other identifiers. Any other identifiers that were previously associated with the "incorrect source visit number" are now associated with the "correct target visit number."
Each superior identifier associated with this visit identifier level should have the same value in the PID and MRG segments, or the MRG and PV1 segments, as appropriate.
See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of merge messages.
All data associated with the "correct target visit number" are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
{ PID Patient Identification 3
[ PD1] Additional Demographics 3
MRG Merge Information 3
[ PV1] Patient Visit 3
}
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.43 ADT/ACK - move patient information - internal ID (event A43)

A move has been done at the internal identifier level. That is, a PID-3-patient ID (internal ID) associated with one external identifier (PID-2-patient ID-external ID) has been moved to another external identifier.
An A43 event is used to signal a move of records identified by the MRG-1-prior patient ID-Internal from the "incorrect source external identifier" identified in the MRG segment (MRG-4-prior patient ID-external) to the "correct target external identifier" identified in the PID segment (PID-2-patient ID-external ID).
The internal ID involved in identifying the patient to be moved (MRG-1-prior patient ID-internal) may or may not have accounts, which may or may not have visits. In any case, all subordinate data sets associated with the internal ID in MRG-1-prior patient ID-internal are moved along with the internal ID, from the "incorrect source external ID" (MRG-4-prior patient ID-external) to the "correct target external ID" (PID-2-patient ID-external ID).
No identifiers subordinate to the internal ID (account number, visit number, alternate visit ID) are valued in this message. Specification of these other subordinate identifiers is not required.
This event and the message syntax do, however, allow for the specification of a "new identifier" (PID-3-patient ID-internal ID), which may be application and/or implementation specific and therefore require site negotiation.
All the identifiers superior to the internal ID should be valued in both the MRG segment and the PID segment. In this message, the external ID is superior to the internal id.
See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of move messages.
The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message. However, all PID data associated with the "correct target internal ID" (PID-3-patient ID -internal ID)) are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
{ PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
}
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.44 ADT/ACK - move account information - patient account number (event A44)

A move has been done at the account identifier level. That is, a PID-18-patient ID (account number) associated with one internal identifier (PID-3-patient ID (internal ID) has been moved to another internal identifier.
An A44 event is used to signal a move of records identified by the MRG-3-prior patient account number from the "incorrect source internal identifier" identified in the MRG segment (MRG-1-prior patient ID-internal) to the "correct target internal identifier" identified in the PID segment (PID-3-patient ID internal ID).
The account number involved in identifying the account to be moved (MRG-3-prior patient account number) may or may not have visits. In any case, all subordinate data sets associated with the account number in MRG-3-prior patient account number are moved along with the account number, from the "incorrect source internal" ID (MRG-1-prior patient ID-internal) to the "correct target internal" ID (PID-3-patient ID -internal ID).
No identifiers subordinate to the account number (visit number, alternate visit ID) are valued in this message.
This event and the message syntax do, however, allow for the specification of a "new identifier" (PID-18-patient account number), which may be application and/or implementation-specific and therefore require site negotiation.
All the identifiers superior to the account number should be valued in both the MRG segment and the PID segment. In this message, the internal ID and the external ID are superior to the account number.
See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of move messages.
The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message. However, all PID data associated with the "account number" are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
{ PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
}
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.45 ADT/ACK - move visit information - visit number (event A45)

A move has been done at the visit identifier level. That is, a PV1-19-visit number or PV1-50-alternate visit ID associated with one account identifier (PID-18-account number) has been moved to another account identifier.
An A45 event is used to signal a move of records identified by the MRG-5-prior visit number or the MRG-6-prior alternate visit ID from the "incorrect source account identifier" identified in the MRG segment (MRG-3-prior patient account number) to the "correct target account identifier" identified in the PID segment (PID-18-patient account number).
This event and the message syntax do allow for the specification of "new identifiers" (PV1-19-visit number, or PV1-50-alternate visit ID), which may be application and/or implementation-specific and therefore require site negotiation.
All the identifiers superior to the visit number or alternate visit ID should be valued in both the MRG segment and the PID segment. In this message, the account number, internal ID and external ID are superior to the visit number and alternate visit ID.
See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of move messages.
The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message. However, all PID data associated with the "correct target visit ID" are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
{ MRG Merge Information 3
PV1 Patient Visit 3
}
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.46 ADT/ACK - change external ID (event A46)

A change has been done at the external identifier level. That is, a PID-2-patient ID (external ID) has been found to be incorrect and has been changed.
An A46 event is used to signal a change of an incorrectly assigned external ID value. The "incorrect source external ID" value is stored in the MRG segment (MRG-4-prior patient ID-external) and is to be changed to the "correct target external ID" value stored in the PID segment (PID-2-patient ID-external).
The external ID involved in identifying the person may or may not represent a patient, who may or may not have accounts, which may or may not have visits. An A46 (change external ID) event is intended for changing the value of the external identifier without affecting other subordinate identifiers. Any other subordinate identifiers that were previously associated with the "incorrect source external ID" are now associated with the "correct target external ID." Specification of these other subordinate identifiers is not required to be provided.
This event and the message syntax do, however, allow for the specification of "new subordinate identifiers" (in addition to the PID-2-patient ID(external ID) identifier). For those environments that may require changes to these other subordinate identifiers because of this A46 (change external ID) event, it is required that the old and new identifiers be a "tightly coupled" pair.
Since this event is a change at the PID-2-patient ID (external ID) identifier level, PID-3-patient ID (internal ID) and MRG-1-prior patient ID-internal ID are not required.
See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of change messages.
The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A31 (update person information) event be used in conjunction with this message. However, all PID data associated with the new External ID are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.47 ADT/ACK - change internal ID (event A47)

A change has been done at the internal identifier level. That is, a PID-3-patient ID (internal ID) has been found to be incorrect and has been changed.
An A47 event is used to signal a change of an incorrectly assigned internal ID value. The "incorrect source internal ID" value is stored in the MRG segment (MRG-1-prior patient ID-internal) and is to be changed to the "correct target external ID" value stored in the PID segment (PID-3-patient ID (internal ID).
The internal ID involved in identifying the patient may or may not have accounts, which may or may not have visits. An A47 (change internal ID) event is intended for changing the value of the internal identifier without affecting other subordinate identifiers. Any other subordinate identifiers that were previously associated with the "incorrect source internal ID" are now associated with the "correct target internal ID." Specification of these other subordinate identifiers is not required.
This event and the message syntax do, however, allow for the specification of "new subordinate identifiers" (in addition to the PID-3-patient ID (internal ID) identifier). For those environments that may require changes to these other subordinate identifiers because of this A47 (change internal ID) event, it is required that the old and new identifiers be a "tightly coupled" pair.
Each superior identifier associated with this internal identifier level should have the same value in both the PID and MRG segments.
See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of change messages.
The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message. However, all PID data associated with the "correct target internal ID" are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.48 ADT/ACK - change alternate patient ID (event A48)

A change has been done at the alternate patient identifier level. That is, a PID-4-alternate patient ID has been found to be incorrect and has been changed.
An A48 event is used to signal a change of an incorrectly assigned alternate patient identifier value. The "incorrect source alternate patient ID" value is stored in the MRG segment (MRG-2-prior alternate patient ID) and is to be changed to the "correct target alternate patient ID" value stored in the PID segment (PID-4-alternate patient ID-PID).
The alternate patient ID involved in identifying the patient may or may not have accounts, which may or may not have visits. An A48 (change alternate patient ID) event is intended for changing the value of the alternate patient identifier without affecting other subordinate identifiers. Any other subordinate identifiers that were previously associated with the "incorrect source alternate patient ID" are now associated with the "correct target alternate patient ID." Specification of these other subordinate identifiers is not required.
This event and the message syntax do, however, allow for the specification of "new subordinate identifiers" (in addition to the PID-4-alternate patient ID identifier). For those environments that may require changes to these other subordinate identifiers because of this A48 (change alternate patient ID) event, it is required that the old and new identifiers be a "tightly coupled" pair.
Each superior identifier associated with this alternate patient identifier level should have the same value in both the PID and MRG segments.
See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of change messages.
The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message. However, all PID data associated with the "correct target alternate ID" are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.49 ADT/ACK - change patient account number (event A49)

A change has been done at the account identifier level. That is, a PID-18-patient account number has been found to be incorrect and has been changed.
An A49 event is used to signal a change of an incorrectly assigned account number value. The "incorrect source account number" value is stored in the MRG segment (MRG-3-prior patient account number) and is to be changed to the "correct target account number" value stored in the PID segment (PID-18-patient account number).
The patient account identifier involved in identifying the account may or may not have visits. An A49 (change patient account number) event is intended for changing the value of the account identifier without affecting other subordinate identifiers. Any other subordinate identifiers that were previously associated with the "incorrect source account number" are now associated with the "correct target account number". Specification of these other subordinate identifiers is not required.
This event and the message syntax do, however, allow for the specification of "new subordinate identifiers" (in addition to the PID-18-patient account number identifier). For those environments that may require changes to these other subordinate identifiers because of this A49 (change patient account number) event, it is required that the old and new identifiers be a "tightly coupled" pair.
Each superior identifier associated with this account identifier level should have the same value in both the PID and MRG segments.
See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of change messages.
The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message. However, all PID data associated with the "correct target account number" are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error Information 2

3.2.50 ADT/ACK - change visit number (event A50)

A change has been done at the visit identifier level. That is, a PV1-19-visit number has been found to be incorrect and has been changed.
An A50 event is used to signal a change of an incorrectly assigned visit number value. The "incorrect source visit number" value is stored in the MRG segment (MRG-5-prior visit number) and is to be changed to the "correct target visit number" value stored in the PV1 segment (PV1-19-visit number).
Each superior identifier associated with this visit number identifier level should have the same value in both the PID and MRG segments.
See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of change messages.
The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message. However, all PV1 data associated with the "Visit Number" are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
PV1 Patient Visit 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.2.51 ADT/ACK - change alternate visit ID (event A51)

A change has been done at the alternate visit identifier level. That is, a PV1-50-alternate visit ID has been found to be incorrect and has been changed.
An A51 event is used to signal a change of an incorrectly assigned alternate visit ID value. The "incorrect source alternate visit ID" value is stored in the MRG segment (MRG-6-prior alternate visit ID) and is to be changed to the "correct target alternate visit ID" value stored in the PV1 segment (PV1-50-alternate visit ID).
Each superior identifier associated with this alternate visit identifier level should have the same value in both the PID and MRG segments.
See Section 3.5.2, "Merging patient/person information," for a discussion of issues related to the implementation of change messages.
The fields included when this message is sent should be the fields pertinent to communicate this event. When demographic data in other fields change, it is recommended that the A08 (update patient information) event be used in conjunction with this message. However, all PV1 data associated with the "correct target alternate visit number" are treated as updated information.
ADT ADT Message Chapter
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
MRG Merge Information 3
PV1 Patient Visit 3
ACK General Acknowledgment Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ ERR ] Error 2

3.3 MESSAGE SEGMENTS

3.3.1 EVN - event type segment

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

3.3.1.0 EVN field definitions

3.3.1.1 Event type code (ID) 00099

Definition: This field has been retained for backward compatibility only. We recommend using the second component (trigger event) of MSH-9-message type to transmit event type code information. This field contains the events corresponding to the trigger events described in this section, e.g., admission, transfer, or registration. Refer to Chapter 2, HL7 table 0003 - Event type for valid values.

3.3.1.2 Recorded Date/time (TS) 00100

Definition: Most systems will default to the system date/time when the transaction was entered, but they should also permit an override.

3.3.1.3 Date/time planned event (TS) 00101

Definition: This field contains the date/time that the event is planned. We recommend that the PV2-expected admit date and PV2-9-expected discharge date be used whenever possible.

3.3.1.4 Event reason code (IS) 00102

Definition: This field contains the reason for this event (e.g., patient request, physician order, census management, etc.). Refer to user-defined table 0062 - Event reason for suggested values.

3.3.1.5 Operator ID (XCN) 00103

Components: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^<assigning authority (HD)> ^ <name type code(ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the individual responsible for triggering the event. Refer to user-defined table 0188 - Operator ID for suggested values.

3.3.1.6 Event occurred (TS) 01278

Definition: This field contains the date/time that the event actually occurred. For example, on a transfer (A02 (transfer a patient)), this field would contain the date/time the patient was actually transferred. On a cancellation event, this field should contain the date/time that the event being canceled occurred.

3.3.2 PID - patient identification segment

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

3.3.2.0 PID field definitions

3.3.2.1 Set ID - patient ID- (SI) 00104

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.

3.3.2.2 Patient ID (external ID) (CX) 00105

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: When the patient is from another institution, outside office, etc., the identifier used by that institution can be shown in this field. This may be a number that multiple disparate corporations or facilities share. Refer to HL7 table 0061 - Check digit scheme in Chapter 2.

3.3.2.3 Patient ID (internal ID) (CX) 00106

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the primary identifier, or other identifiers used by the facility to identify a patient uniquely (e.g., medical record number, billing number, birth registry, etc.). Refer to HL7 table 0061 - Check digit scheme for valid values.
When merging patient IDs (A34 (merge patient information-patient ID only) and A36 (merge patient information-patient ID & account number) events), the Patient ID contained in the PID segment cannot repeat.

3.3.2.4 Alternate patient ID - PID (CX) 00107

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the alternate, temporary, or pending optional patient identifier to be used if needed - or additional numbers that may be required to identify a patient. This field may be used to convey multiple patient IDs when more than one exist for a patient. Possible contents might include a visit number, a visit date, or a Social Security Number.

3.3.2.5 Patient name (XPN) 00108

Components: <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <name type code (ID) >
Definition: This field contains the legal name of the patient. All other names for the patient should be sent in PID-9-patient alias. Therefore, the name type code in this field should be "L - Legal." Refer to HL7 table 0200 Name type code for valid values. Repetition of this field is allowed for representing the same name in different character sets. Please refer to the PN data type.

3.3.2.6 Mother's maiden name (XPN) 00109

Components: <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <name type code (ID) >
Definition: This field contains the family name under which the mother was born (i.e., before marriage). It is used to distinguish between patients with the same last name.

3.3.2.7 Date/Time of birth (TS) 00110

Definition: This field contains the patient's date and time of birth.

3.3.2.8 Sex (IS) 00111

Definition: This field contains the patient's sex. Refer to user-defined table 0001 - Sex for suggested values.

3.3.2.9 Patient alias (XPN) 00112

Components: <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <name type code (ID) >
Definition: This field contains the name(s) by which the patient has been known at some time. Refer to HL7 table 0200 - Name type for valid values.

3.3.2.10 Race (IS) 00113

Definition: This field refers to the patient's race. Refer to user-defined table 0005 - Race for suggested values.

3.3.2.11 Patient address (XAD) 00114

Components: <street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^ <country (ID)> ^ < address type (ID)> ^ <other geographic designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)>
Definition: This field contains the mailing address of the patient. Address type codes are user defined. Multiple addresses for the same person may be sent in the following sequence: The primary mailing address must be sent first in the sequence (for backward compatibility); if the mailing address is not sent, then a repeat delimiter must be sent in the first sequence.

3.3.2.12 County code (IS) 00115

Definition: This field has been retained for backward compatibility. This field contains the patient's county code. The county can now be supported in the county/parish code component of the XAD data type (PID-11-patient address). Refer to user-defined table 0289 - County/parish for suggested values.

3.3.2.13 Phone number - home- (XTN) 00116

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the patient's personal phone numbers. All personal phone numbers for the patient are sent in the following sequence. The first sequence is considered the primary number (for backward compatibility). If the primary number is not sent, then a repeat delimiter is sent in the first sequence. Refer to HL7 tables 0201 - Telecommunication use code and 0202 - Telecommunication equipment type for valid values.

3.3.2.14 Phone number - business- (XTN) 00117

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the patient's business telephone numbers. All business numbers for the patient are sent in the following sequence. The first sequence is considered the patient's primary business phone number (for backward compatibility). If the primary business phone number is not sent, then a repeat delimiter must be sent in the first sequence. Refer to HL7 tables 0201 - Telecommunication use code and 0202 - Telecommunication equipment type for valid values.

3.3.2.15 Primary language (CE) 00118

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field contains the patient's primary language. HL7 recommends using ISO table 639 as the suggested values in user-defined table 0296 - Language.

3.3.2.16 Marital status (IS) 00119

Definition: This field contains the patient's marital status. Refer to user-defined table 0002 - Marital status for suggested values.

3.3.2.17 Religion (IS) 00120

Definition: This field contains the patient's religion. Refer to user-defined table 0006 - Religion for suggested values.

3.3.2.18 Patient account number (CX) 00121

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the patient account number assigned by accounting to which all charges, payments, etc., are recorded. It is used to identify the patient's account. Refer to HL7 table 0061 - Check digit scheme in Chapter 2.

3.3.2.19 SSN number - patient- (ST) 00122

Definition: This field contains the patient's social security number. This number may also be an RR retirement number.

3.3.2.20 Driver's license number - patient- (DLN) 00123

Components: <license number (ST)> ^ <issuing state, province, country (IS)> ^ <expiration date (DT)>
Definition: This field contains the patient's driver's license number. Some sites may use this number as a unique identifier of the patient. The default of the second component is the state in which the patient's license is registered.

3.3.2.21 Mother's identifier (CX) 00124

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field is used, for example, as a link field for newborns. Typically a patient ID or account number may be used. This field can contain multiple identifiers for the same mother. Refer to HL7 table 0061 - Check digit scheme as defined in Chapter 2.

3.3.2.22 Ethnic group (IS) 00125

Definition: This field further defines the patient's ancestry. Refer to user-defined table 0189 - Ethnic group for suggested values. ERISA has a published list of ethnic classifications that may be used by local agreement at a site.

3.3.2.23 Birth place (ST) 00126

Definition: This field indicates the location of the patient's birth.

3.3.2.24 Multiple birth indicator (ID) 00127

Definition: This field indicates whether the patient was part of a multiple birth. Refer to HL7 table 0136 - Yes/No indicator as described in Chapter 2.

3.3.2.25 Birth order (NM) 00128

Definition: When a patient was part of a multiple birth, a value (number) indicating the patient's birth order is entered in this field.

3.3.2.26 Citizenship (IS) 00129

Definition: This field contains the patient's country of citizenship. HL7 recommends using ISO table 3166 as the suggested values in user-defined table 0171 - Citizenship.

3.3.2.27 Veterans military status (CE) 00130

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field contains the military status assigned to a veteran. Refer to user-defined table 0172 - Veterans military status for suggested values.

3.3.2.28 Nationality (CE) 00739

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field contains a code that identifies the nation or national grouping to which the insured person belongs. This information may be different from a person's citizenship in countries in which multiple nationalities are recognized (for example, Spain: Basque, Catalan, etc.). HL7 recommends using ISO table 3166 as he suggested values in user-defined table 0212 - Nationality.

3.3.2.29 Patient death date and time (TS) 00740

Definition: This field contains the date and time at which the patient death occurred.

3.3.2.30 Patient death indicator (ID) 00741

Definition: This field indicates whether or not the patient is deceased. Refer to Chapter 2, HL7 table 0136 - Yes/no indicator for valid values.

3.3.2.31 Usage notes: PID patient identification

The assigning facility ID, the fourth component of the patient identifiers, is a string of up to six characters that 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 assignors of patient identification (and other important identification) numbers. The list will be one of the institution's master dictionary lists. Since third parties (other than the assignors of patient identification numbers) may send or receive HL7 messages containing patient identification numbers, the assigning 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 Patient Administration application assigning such numbers.

3.3.3 PV1 - patient visit segment-

The PV1 segment is used by Registration/Patient Administration 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 the use for this segment.

3.3.3.0 PV1 field definitions

3.3.3.1 Set ID - PV1- (SI) 00131

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.

3.3.3.2 Patient class (IS) 00132

Definition: This field is used by systems to categorize patients by site. It does not have a consistent industry-wide definition. It is subject to site-specific variations. Refer to user-defined table 0004 - Patient class for suggested values.

3.3.3.3 Assigned patient location (PL) 00133

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)
Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the patient's initial assigned location or the location to which the patient is being moved. The first component may be the nursing station for inpatient locations, or clinic, department, or home for locations other than inpatient. For canceling a transaction or discharging a patient, the current location (after the cancellation event or before the discharge event) should be in this field. If a value exists in the fifth component (bed status), it supersedes the value in PV1-40-bed status.

3.3.3.4 Admission type (IS) 00134

Definition: This field indicates the circumstances under which the patient was or will be admitted. Refer to user-defined Table 0007 - Admission type for suggested values.

3.3.3.5 Preadmit number- (CX) 00135

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field 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. For backward compatibility, an ST data type can be sent; however HL7 recommends use of the CX data type, like the account number, for new implementations.

3.3.3.6 Prior patient location (PL) 00136

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)
Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the prior patient location if the patient is being transferred. The old location is null if the patient is new. If a value exists in the fifth component (bed status), it supersedes the value in PV1-40-bed status.

3.3.3.7 Attending doctor (XCN) 00137

Components: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the attending physician information. Multiple names and identifiers for the same physician may be sent. The field sequences are not used to indicate multiple attending doctors. The legal name must be sent in the first sequence. If the legal name is not sent, then a repeat delimiter must be sent in the first sequence. Depending on local agreements, either ID or the name may be absent in this field. Refer to user-defined table 0010 - Physician ID for suggested values.

3.3.3.8 Referring doctor (XCN) 00138

Components: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the referring physician information. Multiple names and identifiers for the same physician may be sent. The field sequences are not used to indicate multiple referring doctors. The legal name must be sent in the first sequence. If the legal name is not sent, then a repeat delimiter must be sent in the first sequence. Depending on local agreements, either the ID or the name may be absent from this field. Refer to user-defined table 0010 - Physician ID for suggested values.

3.3.3.9 Consulting doctor (XCN) 00139

Components: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the consulting physician information. The field sequences are used to indicate multiple consulting doctors. Depending on local agreements, either the ID or the name may be absent from this field. Refer to user-defined table 0010 - Physician ID for suggested values.

3.3.3.10 Hospital service (IS) 00140

Definition: This field contains the treatment or type of surgery that the patient is scheduled to receive. It is a required field with trigger events A01 (admit/visit notification), A02 (transfer a patient), A14 (pending admit), A15 (pending transfer). Refer to user-defined table 0069 - Hospital service for suggested values.

3.3.3.11 Temporary location (PL) 00141

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains a 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 supersedes the value in PV1-40-bed status.

3.3.3.12 Preadmit test indicator- (IS) 00142

Definition: This field indicates whether 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 values.

3.3.3.13 Re-admission indicator- (IS) 00143

Definition: This field indicates that a patient is being re-admitted to the facility and gives the circumstances. We suggest using "R" for readmission or else null. Refer to user-defined table 0092 - Re-admission indicator for suggested values.

3.3.3.14 Admit source (IS) 00144

Definition: This field indicates where the patient was admitted. Refer to user-defined table 0023 - Admit source for suggested values.

3.3.3.15 Ambulatory status (IS) 00145

Definition: This field indicates any permanent or transient handicapped conditions. Refer to user-defined table 0009 - Ambulatory status for suggested entries.

3.3.3.16 VIP indicator (IS) 00146

Definition: This field identifies the type of VIP. Refer to user-defined table 0099 - VIP indicator.

3.3.3.17 Admitting doctor (XCN) 00147

Components: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the admitting physician information. Multiple names and identifiers for the same physician may be sent. The field sequences are not used to indicate multiple admitting doctors. The legal name must be sent in the first sequence. If the legal name is not sent, then a repeat delimiter must be sent in the first sequence. By local agreement, the name or ID may be absent in this field. Refer to user-defined table 0010 - Physician ID for suggested values.

3.3.3.18 Patient type (IS) 00148

Definition: This field contains site-specific values that identify the patient type. Refer to user-defined table 0018 - Patient type for suggested values.

3.3.3.19 Visit number (CX) 00149

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: For backward compatibility, an NM data type may be sent, but HL7 recommends that new implementations use the CX data type. This field contains the unique number assigned to each patient visit.

3.3.3.20 Financial class (FC) 00150

Components: <financial class (IS)> ^ <effective date (TS)>
Definition: This field contains the primary financial class assigned to the patient for the purpose of identifying sources of reimbursement. Repeats up to four times. Refer to user-defined table 0064 - Financial class for suggested values.

3.3.3.21 Charge price indicator (IS) 00151

Definition: This field contains the 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 for suggested values.

3.3.3.22 Courtesy code (IS) 00152

Definition: This field indicates whether the patient will be extended certain special courtesies. Refer to user-defined table 0045 - Courtesy code for suggested values.

3.3.3.23 Credit rating (IS) 00153

Definition: This field contains the user-defined code to determine past credit experience. Refer to user-defined table 0046 - Credit rating for suggested values.

3.3.3.24 Contract code (IS) 00154

Definition: This field 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 for suggested values.

3.3.3.25 Contract effective date (DT) 00155

Definition: This field contains the date that the contract is to start or started.

3.3.3.26 Contract amount (NM) 00156

Definition: This field contains the amount to be paid by the guarantor each period according to the contract.

3.3.3.27 Contract period (NM) 00157

Definition: This field specifies the duration of the contract for user-defined periods.

3.3.3.28 Interest code (IS) 00158

Definition: This field indicates the amount of interest that will be charged the guarantor on any outstanding amounts. Refer to user-defined table 0073 - Interest rate code for suggested values.

3.3.3.29 Transfer to bad debt code (IS) 00159

Definition: This field indicates that the account was transferred to bad debts and gives the reason. Refer to user-defined table 0110 - Transfer to bad debt code for suggested values.

3.3.3.30 Transfer to bad debt date (DT) 00160

Definition: This field contains the date that the account was transferred to a bad debt status.

3.3.3.31 Bad debt agency code (IS) 00161

Definition: This field can be used as an ST type for backward compatibility. This field uniquely identifies the bad debt agency to which the account was transferred. This code is site defined. One possible implementation would be to edit against a table such as user-defined table 0021 - Bad debt agency code; however, this is not required.

3.3.3.32 Bad debt transfer amount (NM) 00162

Definition: This field contains the amount that was transferred to a bad debt status.

3.3.3.33 Bad debt recovery amount (NM) 00163

Definition: This field contains the amount recovered from the guarantor on the account.

3.3.3.34 Delete account indicator (IS) 00164

Definition: This field indicates that the account was deleted from the file and gives the reason. Refer to user-defined table 0111 - Delete account code for suggested values.

3.3.3.35 Delete account date (DT) 00165

Definition: This field contains the date that the account was deleted from the file.

3.3.3.36 Discharge disposition (IS) 00166

Definition: This field contains the disposition of the patient at time of discharge (i.e., discharged to home, expired, etc.). Refer to user-defined table 0112 - Discharged disposition for suggested values.

3.3.3.37 Discharged to location (CM) 00167

Components: <discharge location (IS)> ^ <effective date (TS)>
Definition: This field indicates a facility to which the patient was discharged. Refer to user-defined table 0113 - Discharged to location for suggested values.

3.3.3.38 Diet type (IS) 00168

Definition: This field indicates a special diet type for a patient. Refer to user-defined table 0114 - Diet type for suggested values.

3.3.3.39 Servicing facility (IS) 00169

Definition: This field is used in a multiple facility environment to indicate the facility with which this visit is associated. Refer to user-defined table 0115 - Servicing facility for suggested values.
An optional fourth component, the facility ID, may be valued in each individual location field in PV1, instead of placing it here.

3.3.3.40 Bed status (IS) 00170

Definition: This field has been retained for backward compatibility only. This field contains the status of the bed. Refer to user-defined table 0116 - Bed status for suggested values.

An optional fifth component, bed status, may be valued in each individual location field in PV1, instead of placing it here.

3.3.3.41 Account status (IS) 00171

Definition: This field contains the account status. Refer to user-defined table 0117 - Account status for suggested values.

3.3.3.42 Pending location (PL) 00172

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field indicates the point of care, room, bed, facility ID, and bed status to which the patient may be moved. The first component may be the nursing station for inpatient locations, or the clinic, department, or home for locations other than inpatient. If a value exists in the fifth component (bed status), it supersedes the value in PV1-40-bed status.

3.3.3.43 Prior temporary location (PL) 00173

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field is used to reflect the patient's temporary location (such as the OR or X-RAY) prior to a transfer from a temporary location to an actual location, or from a temporary location to another temporary location. The first component may be the nursing station for inpatient locations, or the clinic, department, or home for locations other than inpatient. If a value exists in the fifth component (bed status), it supersedes the value in PV1-40-bed status.

3.3.3.44 Admit date/time (TS) 00174

Definition: This field contains the admit date/time. It is to be used if the event date/time is different than the admit date and time, i.e., a retroactive update. This field is also used to reflect the date/time of an outpatient/emergency patient registration.

3.3.3.45 Discharge date/time (TS) 00175

Definition: This field contains the discharge date/time. It is to be used if the event date/time is different than the discharge date and time, that is, a retroactive update. This field is also used to reflect the date/time of an outpatient/emergency patient discharge.

3.3.3.46 Current patient balance (NM) 00176

Definition: This field contains the visit balance due.

3.3.3.47 Total charges (NM) 00177

Definition: This field contains the total visit charges.

3.3.3.48 Total adjustments (NM) 00178

Definition: This field contains the total adjustments for visit.

3.3.3.49 Total payments (NM) 00179

Definition: This field contains the total payments for visit.

3.3.3.50 Alternate visit ID (CX) 00180

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the alternative, temporary, or pending optional visit ID number to be used if needed. Refer to HL7 table 0061 - Check digit scheme, as defined in Chapter 2, for valid values. Refer to user-defined table 0192 - Visit ID type for suggested values.

3.3.3.51 Visit indicator (IS) 01226

Definition: This field specifies the level on which data are being sent. It is the indicator used to send data at two levels, visit and account. HL7 recommends sending an `A' or no value when the data in the message are at the account level, or `V' to indicate that the data sent in the message is at the visit level. Refer to user-defined table 0326 - Visit indicator for suggested values.

3.3.3.52 Other healthcare provider (XCN) 01224

Components: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the other healthcare providers (e.g., Nurse care practitioner, midwife, physician assistant). Multiple healthcare providers can be sent. Depending on local agreements, either the ID or the name may be absent from this field. Use values in user-defined table 0010 - Physician ID for first component.

3.3.3.53 PV1 usage notes

The facility (servicing) ID, the optional fourth component of each patient location field, is a string of up to six characters that 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 assignors of patient locations. The list will be one of the institution's master dictionary lists. Since third parties other than the assignors of patient locations may send or receive HL7 messages containing patient locations, the facility ID in the patient location may not be the same as that implied by the sending and receiving systems identified in the MSH. The facility ID must be unique across facilities at a given site. This field is required for HL7 implementations that have more than a single facility with bed locations, since the same <nurse unit> ^ <room> ^ <bed> combination may exist at more than one facility.

3.3.4 PV2 - patient visit - additional information segment

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

3.3.4.0 PV2 field definitions

3.3.4.1 Prior pending location (PL) 00181

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field is required for cancel pending transfer (A27 (cancel pending admit)) messages. In all other events it is optional.

3.3.4.2 Accommodation code (CE) 00182

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field indicates the specific patient accommodations for this visit. Refer to user-defined table 0129 - Accommodation code for suggested values.

3.3.4.3 Admit reason (CE) 00183

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field contains the short description of the reason for patient admission.

3.3.4.4 Transfer reason (CE) 00184

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field contains the short description of the reason for a patient location change.

3.3.4.5 Patient valuables (ST) 00185

Definition: This field contains the short description of patient valuables checked in during admission.

3.3.4.6 Patient valuables location (ST) 00186

Definition: This field indicates the location of the patient's valuables.

3.3.4.7 Visit user code (IS) 00187

Definition: This field 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 for suggested values.

3.3.4.8 Expected admit date/time (TS) 00188

Definition: This field contains the date and time that the patient is expected to be admitted. This field is also used to reflect the date/time of an outpatient/emergency patient registration.

3.3.4.9 Expected discharge date/time (TS) 00189

Definition: This field contains the date and time that the patient is expected to be discharged. This is a non-event related date used by ancillaries to determine more accurately the projected workloads. This field is also used to reflect the anticipated discharge date/time of an outpatient/emergency patient, or an inpatient.

3.3.4.10 Estimated length of inpatient stay (NM) 00711

Definition: This field specifies the estimated days of inpatient stays.

3.3.4.11 Actual length of inpatient stay (NM) 00712

Definition: This field contains the actual days of inpatient stays. The actual length of the inpatient stay may not be calculated from the admission and discharge dates because of possible leaves of absence.

3.3.4.12 Visit description (ST) 00713

Definition: This field contains a brief user-defined description of the visit.

3.3.4.13 Referral source (XCN) 00714

Components: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility ID (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the name and the identification numbers of the person or organization that made the referral. This person/organization is not the same as the referring doctor. For example, Joe Smith referred me to the Clinic (or to Dr. Jones at the Clinic).

3.3.4.14 Previous service date (DT) 00715

Definition: This field contains the date of previous service for the same recurring condition. This may be a required field for billing certain illnesses (e.g., accident related) to a third party.

3.3.4.15 Employment illness related indicator (ID) 00716

Definition: This field specifies whether a patient's illness was job-related. Refer to Chapter 2, HL7 table 0136 - Yes/no indicator for valid values.

3.3.4.16 Purge status code (IS) 00717

Definition: This field contains the purge status code for the account. It is used by the application program to determine purge processing. Refer to user-defined table 0213 - Purge status for suggested values.

3.3.4.17 Purge status date (DT) 00718

Definition: This field contains the date on which the data will be purged from the system.

3.3.4.18 Special program code (IS) 00719

Definition: This field designates the specific health insurance program for a visit required for healthcare reimbursement. Examples include Child Health Assistance, Elective Surgery Program, Family Planning, etc. Refer to user-defined table 0214 - Special program codes for suggested values.

3.3.4.19 Retention indicator (ID) 00720

Definition: This field allows the user to control the financial and demographic purge processes at the visit. It is used to preserve demographic and financial data on specific, high priority visits. Refer to Chapter 2, HL7 table 0136 - Yes/no indicator for valid values.

3.3.4.20 Expected number of insurance plans (NM) 00721

Definition: This field contains the number of insurance plans that may provide coverage for this visit.

3.3.4.21 Visit publicity code (IS) 00722

Definition: This field contains a user-defined code indicating what level of publicity is allowed (e.g., No Publicity, Family Only) for a specific visit. Refer to user-defined table 0215 - Publicity code for suggested values. Refer to PD1-11-patient publicity code for the patient level publicity code.

3.3.4.22 Visit protection indicator (ID) 00723

Definition: This field identifies the person's protection that determines, in turn, whether access to information about this person should be kept from users who do not have adequate authority for a specific visit. Refer to Chapter 2, HL7 table 0136 - Yes/no indicator for valid values. Refer to PD1-12-patient protection indicator for the patient level protection indicator.

3.3.4.23 Clinic organization name (XON) 00724

Components: <organization name (ST)> ^ <organization name type code (ID)> ^ <ID number (ID)> ^ <check digit (NM)> ^ < check digit scheme (ID)> ^ <assigning authority (HD)> ^ <identifier type code (ID)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the organization name or sub-unit and identifier that is associated with the (visit) episode of care. For example, the Allergy or Oncology Clinic within the facility might be named.

3.3.4.24 Patient status code (IS) 00725

Definition: This field indicates the status of the episode of care: for instance, Active Inpatient vs. Discharged Inpatient. Refer to user defined table 0216 - Patient status for suggested values.

3.3.4.25 Visit priority code (IS) 00726

Definition: This field contains the priority of the visit, e.g., whether the admission is an emergency, elective, or urgent. Refer to user defined table 0217 - Visit priority for suggested values.

3.3.4.26 Previous treatment date (DT) 00727

Definition: This field contains the date that the patient last had treatment for any condition prior to this visit. In the case of a prior hospital visit, it is likely to be the previous discharge date.

3.3.4.27 Expected discharge disposition (IS) 00728

Definition: This field describes what the patient's disposition is expected to be at the end of the visit. Refer to user-defined table 0112 - Discharge disposition for suggested values.

3.3.4.28 Signature on file date (DT) 00729

Definition: This field contains the date on which a signature was obtained for insurance billing purposes.

3.3.4.29 First similar illness date (DT) 00730

Definition: This field is used to determine if the patient has a pre-existing condition.

3.3.4.30 Patient charge adjustment code (IS) 00731

Definition: This field contains a user-defined code that indicates which adjustments should be made to this patient's charges. Refer to user-defined table 0218 - Charge adjustment for suggested values. This field is the same as GT1-28-guarantor charge adjustment code.

3.3.4.31 Recurring service code (IS) 00732

Definition: This field indicates whether the treatment is continuous. Refer to user-defined table 0219 - Recurring service for suggested values.

3.3.4.32 Billing media code (ID) 00733

Definition: This field indicates if the account is to be rejected from tape billing. Refer to Chapter 2, HL7 table 0136 - Yes/no indicator for valid values.

3.3.4.33 Expected surgery date and time (TS) 00734

Definition: This field contains the date and time on which the surgery is expected to occur.

3.3.4.34 Military partnership code (ID) 00735

Definition: This field indicates that a military facility has contracted with a non-military facility for the use of its services. Refer to Chapter 2, HL7 table 0136 - Yes/no indicator for valid values.

3.3.4.35 Military non availability code (ID) 00736

Definition: This field indicates whether a patient has permission to use a non-military facility for treatment. Refer to Chapter 2, HL7 table 0136 - Yes/no indicator for valid values.

3.3.4.36 Newborn baby indicator (ID) 00737

Definition: This field indicates whether the patient is a baby. Refer to Chapter 2, HL7 table 0136 - Yes/no indicator for valid values.

3.3.4.37 Baby detained indicator (ID) 00738

Definition: This field indicates if the baby is detained after the mother's discharge. Refer to Chapter 2, HL7 table 0136 - Yes/no indicator for valid values.

3.3.5 NK1 - next of kin / associated parties segment-

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

3.3.5.0 NK1 field definitions

3.3.5.1 Set ID - next of kin / associated parties- (SI) 00190

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.

3.3.5.2 Name (XPN) 00191

Components: <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <name type code (ID) >
Definition: This field contains the name of the next of kin or associated party. Multiple names for the same person are allowed, but the legal name must be sent in the first sequence. If the legal name is not sent, then the repeat delimiter must be sent in the first sequence. Refer to Chapter 2 for the name type code table.

3.3.5.3 Relationship (CE) 00192

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field contains the actual personal relationship that the next of kin/associated parties has to the patient. Refer to user-defined table 0063 - Relationship for suggested values. Examples might include: brother, sister, mother, father, friend, spouse, emergency contact, employer, etc.

3.3.5.4 Address (XAD) 00193

Components: <street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^ <country (ID)> ^ <address type (ID)> ^ <other geographic designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)>
Definition: This field contains the address of the next of kin/associated party. Multiple addresses are allowed for the same person. The mailing address must be sent in the first sequence. If the mailing address is not sent, then the repeat delimiter must be sent in the first sequence.

3.3.5.5 Phone number (XTN) 00194

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the telephone number of the next of kin/associated party. Multiple phone numbers are allowed for the same person. The primary telephone number must be sent in the first sequence. If the primary telephone number is not sent, then the repeat delimiter must be sent in the first sequence. Refer to Chapter 2 for suggested telecommunication use and equipment type codes.

3.3.5.6 Business phone number (XTN) 00195

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the business telephone number of the next of kin/associated party. Multiple phone numbers are allowed for the same person. The primary business telephone number must be sent in the first sequence. If the primary business telephone number is not sent, then the repeat delimiter must be sent in the first sequence. Refer to Chapter 2 for suggested telecommunication use and equipment type codes.

3.3.5.7 Contact role (CE) 00196

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field indicates the specific relationship role (next of kin, employer, emergency contact, etc.). Refer to user-defined table 0131 - Contact role for suggested values. This field specifies the role that the next of kin/associated parties plays with regard to the patient. Examples might include an employer, emergency contact, next of kin, insurance company, state agency, federal agency, etc.

3.3.5.8 Start date (DT) 00197

Definition: This field contains the start of the contact role.

3.3.5.9 End date (DT) 00198

Definition: This field contains the end of the contact role.

3.3.5.10 Next of kin / associated parties job title (ST) 00199

Definition: This field contains the title of the next of kin/associated parties at their place of employment. However, if the contact role is the patient's employer, this field contains the title of the patient at their place of employment.

3.3.5.11 Next of kin / associated parties job code/class (JCC) 00200

Components: <job code (IS)> ^ <employee classification (IS)>
Definition: This field contains the employer's job code and the employee classification used for the next of kin/associated parties at their place of employment. However, if the contact role is the patient's employer, this field contains the job code/class of the patient at their place of employment. Refer to user-defined tables 0327 - Job code and 0328 - Employee classification for suggested values.

3.3.5.12 Next of kin / associated parties employee number (CX) 00201

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: For backward compatibility, the ST data type can be sent; however HL7 recommends that the CX data type be used for new implementations. This field contains the number that the employer assigns to the employee that is acting as next of kin/associated parties. However, if the contact role is the patient's employer, this field contains the employee number of the patient at their place of employment.

3.3.5.13 Organization name (XON) 00202

Components: <organization name (ST)> ^ <organization name type code (ID)> ^ <ID number (ID)> ^ <check digit (NM)> ^ < check digit scheme (ID)> ^ <assigning authority (HD)> ^ <identifier type code (ID)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the name of the organization that serves as a next of kin/associated party or as the next of kin of the patient. This field may also be used to communicate the name of the organization at which the associated party works. Multiple names for the same organization may be sent. If multiple names are sent, the legal name must be sent in the first sequence. If the legal name is not sent, then a repeat delimiter must be sent in the first sequence.

3.3.5.14 Marital status (IS) 00119

Definition: This field contains the next of kin/associated party's marital status. Refer to user-defined table 0002 - Marital status for suggested values.

3.3.5.15 Sex code (IS) 00111

Definition: This field contains the next of kin/associated party's sex. Refer to user-defined table 0001 - Sex for suggested values.

3.3.5.16 Date/time of birth (TS) 00110

Definition: This field contains the next of kin/associated party's birth date and time.

3.3.5.17 Living dependency (IS) 00755

Definition: This field identifies specific living conditions (e.g., spouse dependent on patient, walk-up) that are relevant to an evaluation of the patient's healthcare needs. This information can be used for discharge planning. Examples might include Spouse Dependent, Medical Supervision Required, Small Children Dependent. This field repeats because, for example, "spouse dependent" and "medical supervision required" can apply at the same time. Refer to user-defined table 0223 - Living dependency for suggested values.

3.3.5.18 Ambulatory status (IS) 00145

Definition: This field identifies the transient rate of mobility for the next of kin/associated party. Refer to user-defined table 0009 - Ambulatory status for suggested values.

3.3.5.19 Citizenship (IS) 00129

Definition: This field contains the code to identify the next of kin/associated party's citizenship. HL7 recommends using ISO 3166 as the suggested values in user-defined table 0171 - Country code.

3.3.5.20 Primary language (CE) 00118

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field identifies the next of kin/associated party's primary speaking language. HL7 recommends using ISO 639 as the suggested values in user-defined table 0296 - Language.

3.3.5.21 Living arrangement (IS) 00742

Definition: This field identifies the situation that the associated party lives in at his/her residential address. Refer to user-defined table 0220 - Living arrangement for suggested values. Examples of living arrangements might include Alone, Family, Institution, etc.

3.3.5.22 Publicity indicator (CE) 00743

Definition: This field indicates what level of publicity is allowed (e.g., No Publicity, Family Only) for the next of kin/associated party. Refer to user-defined table 0215 - Publicity code for suggested values.

3.3.5.23 Protection indicator (ID) 00744

Definition: This field identifies that next of kin/associated party's protection that determines, in turn, whether access to information about this person should be kept from users who do not have adequate authority. Refer to Chapter 2, HL7 table 0136 - Yes/no indicator for valid values.

3.3.5.24 Student indicator (IS) 00745

Definition: This field identifies whether the next of kin/associated party is currently a student or not, and whether the next of kin/associated party is a full- or a part-time student. This field does not indicate the degree (high school, college) of the student or the field of study. Refer to user-defined table 0231 - Student status for suggested values.

3.3.5.25 Religion (IS) 00120

Definition: This field indicates the type of religion practiced by the next of kin/associated party. Refer to user-defined table 0006 - Religion for suggested values.

3.3.5.26 Mother's maiden name' (XPN) 00746

Components: <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <name type code (ID) >
Definition: This field indicates the maiden name of the next of kin/associated party's mother.

3.3.5.27 Nationality (CE) 00739

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field identifies the nation or national group to which the next of kin/associated party belongs. This information may be different than the person's citizenship in countries in which multiple nationalities are recognized (e.g., Spain: Basque, Catalan, etc.).

3.3.5.28 Ethnic group (IS) 00125

Definition: This field contains the next of kin/associated party's ethnic group. ERISA has a published list of ethnic classifications that may be used by local agreement at a site. Refer to user-defined table 0189 - Ethnic group for suggested values.

3.3.5.29 Contact reason (CE) 00747

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field identifies how the contact should be used (e.g., contact my employer if patient is unable to work).

3.3.5.30 Contact person's name' (XPN) 00748

Components: <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <name type code (ID)>
Definition: This field contains the names of the people to contact, depending on the value of the relationship defined in NK1-3-relationship. This field is typically needed when the NK1 is an organization. The legal name should be sent first in the sequence. Refer to HL7 table 0200 - Name type for valid values.

3.3.5.31 Contact person's telephone number' (XTN) 00749

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the telephone numbers of the contact person depending on the value of the relationship defined in NK1-3-relationship. This field is typically needed when the NK1 is an organization. The primary telephone number must be sent in the first sequence. If the primary telephone number is not sent, then a repeat delimiter must be sent in the first sequence. Refer to HL7 tables 0201 -Telecommunication use code and 0202 - Telecommunication equipment type for valid values.

3.3.5.32 Contact person address (XAD) 00750

Components: <street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^ <country (ID)> ^ < address type (ID)> ^ <other geographic designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)>
Definition: This field contains the addresses of the contact person depending on the value of the relationship defined in NK1-3-relationship. This field is typically used when the NK1 is an organization. When multiple addresses are sent, the mailing address must be sent first in the sequence.

3.3.5.33 Next of kin/associated party identifiers (CX) 00751

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the identifiers for the next of kin/associated party, for example, Social Security Number, driver's license, etc.

3.3.5.34 Job status (IS) 00752

Definition: This field identifies the next of kin/associated party's job status (full-time, part-time, permanent, etc.). Refer to user-defined table 0311 - Job status for suggested values.

3.3.5.35 Race (IS) 00113

Definition: This field identifies the race of the next of kin/associated party. ERISA has published a list of ethnic classifications that may be used by local agreement at a site. Refer to user-defined table 0005 - Race for suggested values.

3.3.5.36 Handicap (IS) 00753

Definition: This field contains the code that describes an associated party's disability. Refer to user-defined table 0295 - Handicap for suggested values.

3.3.5.37 Contact person social security number (ST) 00754

Definition: This field contains the contact person's social security number. This number may also be an RR retirement number. It is the number for the person identified in NK1-2-name. For the Social Security number of the associated party, see NK1-33-next of kin/associated party's identifiers.

3.3.6 AL1 - patient allergy information segment

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

3.3.6.0 AL1 field definitions

3.3.6.1 Set ID - AL1 (SI) 00203

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.

3.3.6.2 Allergy type (IS) 00204

Definition: This field indicates a general allergy category (drug, food, pollen, etc.). Refer to user-defined table 0127 - Allergy type for suggested values.

3.3.6.3 Allergy code/mnemonic/description (CE) 00205

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field uniquely identifies a particular allergy. This element may conform to some external, standard coding system (that must be identified), or it may conform to local, largely textual or mnemonic descriptions.

3.3.6.4 Allergy severity (IS) 00206

Definition: This field indicates the general severity of the allergy (severe, moderate, mild, etc.). Refer to user-defined table 0128 - Allergy severity for suggested values.

3.3.6.5 Allergy reaction (ST) 00207

Definition: This field contains a short, textual description of the specific allergy reaction (convulsions, sneeze, rash, etc.).

3.3.6.6 Identification date (DT) 00208

Definition: This field contains the date that the allergy was identified.

3.3.7 NPU - bed status update segment

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

3.3.7.0 NPU field definitions

3.3.7.1 Bed location (PL) 00209

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the bed location that is a valid bed location.

3.3.7.2 Bed status (IS) 00170

Definition: This field contains the bed status. Refer to user-defined table 0116 - Bed status for suggested values.

3.3.8 MRG - merge patient information segment-

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

3.3.8.0 MRG field definitions

3.3.8.1 Prior patient ID - internal- (CX) 00211

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the internal prior patient identifier. This field contains a list of potential "old" numbers to match. Only one old number can be merged with one new number in a transaction. When merging patient IDs, A34 (merge patient information - patient ID only) and A36 (merge patient information-patient ID & account number), the patient ID contained in the PID segment cannot repeat. Refer to HL7 table 0061 - Check digit scheme as defined in Chapter 2.

3.3.8.2 Prior alternate patient ID (CX) 00212

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the prior alternate patient identifier. Refer to HL7 table 0061 - Check digit scheme as defined in Chapter 2.

3.3.8.3 Prior patient account number (CX) 00213

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the prior patient account number. Refer to HL7 table 0061 - Check digit scheme as defined in Chapter 2.

3.3.8.4 Prior patient ID - external (CX) 00214

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the external prior patient identifier. Refer to HL7 table 0061 - Check digit scheme as defined in Chapter 2.

3.3.8.5 Prior visit number (CX) 01279

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the prior visit number. Refer to HL7 table 0061 - Check digit scheme as defined in Chapter 2.

3.3.8.6 Prior alternate visit ID (CX) 01280

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the prior alternate visit number. Refer to HL7 table 0061 - Check digit scheme as defined in Chapter 2.

3.3.8.7 Prior patient name (XPN) 01281

Components: <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <name type code (ID) >
Definition: This field contains the prior name of the patient This field is not used to change a patient name. Refer to Chapter 2 for the name type code table.

3.3.8.8 Segment notes: MRG merge patient information

The assigning facility ID, the fourth component of the patient identifiers, is an HD data type that 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 assignors of patient identification (and other important identification) numbers. The list will be one of the institution's master dictionary lists. Since third parties (other than the assignors of patient identification numbers) may send or receive HL7 messages containing patient identification numbers, the assigning facility ID in the patient identification numbers may not be the same as those of 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 Patient Administration application assigning such numbers.

3.3.9 PD1 - patient additional demographic segment

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

3.3.9.1 Living dependency (IS) 00755

Definition: This field identifies specific living conditions (e.g., spouse dependent on patient, walk-up) that are relevant to an evaluation of the patient's healthcare needs. This information can be used for discharge planning. Examples might include Spouse Dependent, Medical Supervision Required, Small Children Dependent. This field repeats because, for example, "spouse dependent" and "medical supervision required" can apply at the same time. Refer to user-defined table 0223 - Living dependency for suggested values.

3.3.9.2 Living arrangement (IS) 00742

Definition: This field identifies the situation in which the patient lives at his residential address. Examples might include Alone, Family, Relatives, Institution, etc. Refer to user-defined table 0220 - Patient living arrangement for suggested values.

3.3.9.3 Patient primary facility (XON) 00756

Components: <organization name (ST)> ^ <organization name type code (ID)> ^ <ID number (ID)> ^ <check digit (NM)> ^ < check digit scheme (ID)> ^ <assigning authority (HD)> ^ <identifier type code (ID)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the name and identifier that specifies the primary care facility selected by the patient at the time of enrollment in an HMO Insurance Plan. Multiple facilities are allowed for the same facility. The legal name of the facility must be sent in the first sequence. If the legal name of the facility is not sent, then the repeat delimiter must be sent in the first sequence. See Chapter 2 regarding suggested values for organization name type codes.

3.3.9.4 Patient primary care provider name & ID no. (XCN) 00757

Components: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the provider name and ID of the managed care primary care provider. This information is usually selected by the patient at the time of enrollment in the patient's managed care insurance plan. Multiple names are allowed for the same person. The legal name must be sent in the first sequence. If the legal name is not sent, then the repeat delimiter must be sent in the first sequence.

3.3.9.5 Student indicator (IS) 00745

Definition: This field indicates if the patient is currently a student or not, and whether the patient is a full-time or a part-time student. This field does not indicate the student's degree level (high school, college, elementary) or the student's field of study (accounting, engineering, etc.). Refer to user-defined table 0231 - Student status for suggested values.

3.3.9.6 Handicap (IS) 00753

Definition: This field indicates the nature of the patient's permanent handicapped condition (e.g., deaf, blind). A handicapped condition is defined as a physical or mental disability that is permanent. Transient handicapped conditions should be sent in the ambulatory status. Refer to user-defined table 0295 - Handicap for suggested values.

3.3.9.7 Living will (IS) 00759

Definition: This field indicates whether or not the patient has a living will and, if so, whether a copy of the living will is on file at the facility. If the patient does not have a living will, the value of this field indicates whether the patient was provided information on living wills. Refer to user-defined table 0315 - Living will for suggested values.

3.3.9.8 Organ donor (IS) 00760

Definition: This field indicates whether the patient wants to donate his/her organs and whether his organ donor card is on file with the organization. Refer to user-defined table 0316 - Organ donor for suggested values.

3.3.9.9 Patient separate bill indicator (ID) 00761

Definition: This field specifies that charges for this patient are to be billed separately from other patient bills with the same guarantor. (This bill is now a patient bill rather than a guarantor bill.) Refer to HL7 table 0136 - Yes/no indicator for valid values.

3.3.9.10 Duplicate patient (CX) 00762

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This field indicates that a patient is the same as, or a duplicate of, another patient found on the sending system. The intent is to be informational only and no action is required by the receiver. Include the patient identifier if the sender knows an identifier for the patient.

3.3.9.11 Publicity indicator (CE) 00743

Definition: This field contains a user-defined code indicating what level of publicity is allowed (e.g., No Publicity, Family Only) for the patient. This code is conveyed at the patient level rather than the visit level. It is up to the application to decide processing rules for patient vs. visit-level data. Refer to user-defined table 0215 - Publicity code for suggested values. Refer to PV2-21-visit publicity code for visit level code.

3.3.9.12 Protection indicator (ID) 01293

Definition: This field identifies the person's protection that determines, in turn, whether access to information about this person should be kept from users who do not have adequate authority for the patient. This indicator is conveyed at the patient level rather that the visit level. It is up to the application to decide processing rules for patient vs. visit level data. Refer to Chapter 2, HL7 table 0136 - Yes/no indicator for valid values. Refer to PV2-22-visit protection indicator for visit level code.

3.3.10 DB1 - Disability segment

The disability segment contains information related to the disability of a person. This segment was created instead of adding disability attributes to each segment that contains a person (to which disability may apply). This is an optional segment that can be used to send disability information about a person already defined by the Patient Administration Chapter. The disabled person code and identifier allow for the association of the disability information to the person.

3.3.10.0 DB1 field definitions

3.3.10.1 Set ID - DB1 (SI) 01283

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.

3.3.10.2 Disabled person code (IS) 01284

Definition: The value of this field indicates to which person the disability information relates in the message. For example, if the value is PT, the disability information relates to the patient. Refer to user -defined table 0334 - Disabled person for suggested values.

3.3.10.3 Disabled person identifier (CX) 01285

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Definition: This is the identifier (or identifiers) for the person whose disability information is sent on the segment.

3.3.10.4 Disability indicator 01286

Definition: This field indicates if the person's visit is a disability visit. Refer to HL7 table 0136 - Yes/No indicator for valid values.

3.3.10.5 Disability start date (DT) 01287

Definition: This field specifies the date the person became disabled.

3.3.10.6 Disability end date (DT) 01288

Definition: This field specifies the ending date of the person's disability.

3.3.10.7 Disability return to work date (DT) 01289

Definition: This field indicates the authorized date on which the patient can return to work for a specified disability case.

3.3.10.8 Disability unable to work date (DT) 01290

Definition: This field specifies the first date in the date span that the patient is unable to work due to disability.

3.4 EXAMPLE TRANSACTIONS

3.4.1 Admit/visit notification - event A01 (admitted patient)-

MSH|^~\&|ADT1|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01|MSG00001|P|2.3|<cr>
EVN|A01|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|1|JONES^BARBARA^K|WIFE||||||NK^NEXT OF KIN<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 11:23 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 ADT1 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.

3.4.2 Pre-admit notification - event A05 (nonadmitted patient)

MSH|^~\&|REGADT|MCM|IFENG||199601061000||ADT^A05|000001|P|2.3|||<cr>
EVN|A05|199601061000|199601101400|01||199601061000<cr>
PID|||191919^^^GENHOSP|253763|MASSIE^JAMES^A||19560129|M|||171
ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|
(900)485-5344||S|C|10199925|371-66-9256||<cr>
OBX||ST|1010.1^BODY WEIGHT||62|kg<cr>
OBX||ST|1010.1^HEIGHT||190|cm<cr>
NK1|1|MASSIE^ELLEN|SPOUSE|171 ZOBERLEIN^^ISHPEMING^MI^49849^""^|
(900)485-5344|(900)545-1234~(900)545-1200|EC^EMERGENCY CONTACT<cr>
NK1|2|MASSIE^MARYLOU|MOTHER|300 ZOBERLEIN^^ISHPEMING^MI^49849^""^|
(900)485-5344|(900)545-1234~(900)545-1200|EC^EMERGENCY CONTACT<cr>
NK1|3<cr>
NK1|4|||123 INDUSTRY WAY^^ISHPEMING^MI^49849^""^||(900)545-1200|EM^EMPLOYER|19940605||PROGRAMMER|||ACME SOFTWARE COMPANY<cr>
PV1||O|||||0148^ADDISON,JAMES|0148^ADDISON,JAMES|0148^ADDISON,JAMES|AMB||||||||0148^ADDISON,JAMES|S|1400|A|||||||||||||||||GENHOSP||||||<cr>
PV2||||||||199601101400||||||||||||||||||||||||||199601101400<cr>
DG1|1|19||BIOPSY||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>
IN1|2|""|""<cr>
Patient James A. Massie was pre-admitted on January 6th, 1996 for ambulatory surgery which is scheduled for January 10, 1996 at 1400. As part of the pre-admission process, he specified two emergency contacts as well as employer, insurance, and guarantor, and allergy information. He also was measured and weighed. Note that the REGADT system supports the entry of four NK1 type records: first, second, and third emergency contacts and employer information. A third emergency contact was not provided for James A. Massie. However, an NK1 record must be sent to support "snapshot" mode of update. The REGADT system also supports entry of two insurance plans, one guarantor, and one diagnosis.

3.4.3 Admit/visit notification - event A04 (nonadmitted patient)

MSH|^~\&|REGADT|MCM|IFENG||199112311501||ADT^A04|000001|P|2.3|||<cr>
EVN|A04|199601101500|199601101400|01||199601101410<cr>
PID|||191919^^^GENHOSP|253763|MASSIE^JAMES^A||19560129|M|||171
ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|
(900)485-5344||S|C|10199925|371-66-9256||<cr>
OBX||ST|1010.1^BODY WEIGHT||62|kg<cr>
OBX||ST|1010.1^HEIGHT||190|cm<cr>
NK1|1|MASSIE^ELLEN|SPOUSE|171 ZOBERLEIN^^ISHPEMING^MI^49849^""^|
(900)485-5344|(900)545-1234~(900)545-1200|EC1^FIRST EMERGENCY CONTACT<cr>
NK1|2|MASSIE^MARYLOU|MOTHER|300 ZOBERLEIN^^ISHPEMING^MI^49849^""^|
(900)485-5344|(900)545-1234~(900)545-1200|EC2^SECOND EMERGENCY CONTACT<cr>
NK1|3<cr>
NK1|4|||123 INDUSTRY WAY^^ISHPEMING^MI^49849^""^||(900)545-1200|EM^EMPLOYER|19940605||PROGRAMMER|||ACME SOFTWARE COMPANY<cr>
PV1||O|O/R||||0148^ADDISON,JAMES|0148^ADDISON,JAMES|0148^ADDISON,JAMES|AMB||||||||0148^ADDISON,JAMES|S|1400|A|||||||||||||||||GENHOSP|||||199501101410|<cr>
PV2||||||||199601101400||||||||||||||||||||||||||199601101400<cr>
DG1|1|19||BIOPSY||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|0|0|BC1|BLUE CROSS|171 ZOBERLEIN^^ISHPEMING^M149849^""^||
(900)485-5344|90||||||50 OK|<cr>
IN1|2|""|""<cr>
Patient James A. Massie arrived at location O/R for surgery on January 10th, 1996 at 1410 for ambulatory surgery which was scheduled for January 10, 1996 at 1400. The visit event was recorded into the MCM system on January 10, 1996 at 1500. It was sent to the interface engine (IFENG) at 1501.

3.4.4 Change outpatient to inpatient - event A06

MSH|^~\&|REGADT|MCM|IFENG||199601110025||ADT^A06|000001|P|2.3|||<cr>
EVN|A06|19960110025||01||199601102300<cr>
PID|||191919^^^GENHOSP|253763|MASSIE^JAMES^A||19560129|M|||171
ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|
(900)485-5344||S|C|10199925|371-66-9256||<cr>
NK1|1|MASSIE^ELLEN|SPOUSE|171 ZOBERLEIN^^ISHPEMING^MI^49849^""^|
(900)485-5344|(900)545-1234~(900)545-1200|EC1^FIRST EMERGENCY CONTACT<cr>
NK1|2|MASSIE^MARYLOU|MOTHER|300 ZOBERLEIN^^ISHPEMING^MI^49849^""^|
(900)485-5344|(900)545-1234~(900)545-1200|EC2^SECOND EMERGENCY CONTACT<cr>
NK1|3<cr>
NK1|4|||123 INDUSTRY WAY^^ISHPEMING^MI^49849^""^||
(900)545-1200|EM^EMPLOYER|19940605||PROGRAMMER|||ACME SOFTWARE COMPANY<cr>
PV1||I|6N^1234^A^GENHOSP||||0100^ANDERSON,CARL|0148^ADDISON,JAMES||SUR||||
||||0148^ANDERSON,CARL|S|1400|A|||||||||||||||||GENHOSP|||||199501102300|<cr>
DG1|1|19||BIOPSY||00<cr>
OBX||ST|1010.1^BODY WEIGHT||62|kg<cr>
OBX||ST|1010.1^HEIGHT||190|cm<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|0|0|BC1|BLUE CROSS|171 ZOBERLEIN^^ISHPEMING^M149849^""^||
(900)485-5344|90||||||50 OK<cr>
IN1|2|""|""<cr>
Patient James A. Massie was later converted to an inpatient on January 10th, 1996 at 2300 to recover from the operation. The change from outpatient to inpatient was recorded on the MCM system on January 11, 1996 at 0020. He was assigned to room 1234, bed A on unit 6N. When Patient James A. Massie was converted to an inpatient on January 10th, 1996 at 2300, his hospital service changed to SUR. His attending doctor and admitting doctors changed to Dr. Carl Anderson. As a result of the conversion, his account number changed from 10199923 to 10199925

3.4.5 Transfer patient - event A02 (first example)

MSH|^~\&|REGADT|MCM|IFENG||199601110500||ADT^A02|000001|P|2.3|||<cr>
EVN|A02|199601110520||01||199601110500<cr>
PID|||191919^^^GENHOSP|253763|MASSIE^JAMES^A||19560129|M|||171
ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|
(900)485-5344||S|C|10199925|371-66-9256||
(900)545-1200|EM^EMPLOYER|19940605||PROGRAMMER|||ACME SOFTWARE COMPANY<cr>
PV1||I|SICU^0001^01^GENHOSP|||6N^1234^A^GENHOSP|0200^JONES, GEORGE|0148^ADDISON,JAMES||ICU||||
||||0148^ANDERSON,CARL|S|1400|A|||||||||||||||||GENHOSP|||||199501102300|<cr>
On January 11th, 1996 at 0500, James A. Massie condition became worse due to a complication. As a result, he was transferred to the surgical ICU (SICU). The transfer was recorded on the MCM system on January 11, 1996 at 0520. He was assigned to room 0001, bed 1. When Patient James A. Massie was transferred to SICU, his hospital service changed to ICU and his attending doctor changed to Dr. George Jones.

3.4.6 Cancel transfer - event A12

MSH|^~\&|REGADT|MCM|IFENG||199601110600||ADT^A02|000001|P|2.3|||<cr>
EVN|A02|199601110600||01||199601110500<cr>
PID|||191919^^^GENHOSP|253763|MASSIE^JAMES^A||19560129|M|||171
ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|
(900)485-5344||S|C|10199925|371-66-9256||
(900)545-1200|EM^EMPLOYER|19940605||PROGRAMMER|||ACME SOFTWARE COMPANY<cr>
PV1||I|6N^1234^A^GENHOSP|||SICU^0001^1^GENHOSP|0100^ANDERSON,CARL|0148^ADDISON,JAMES||SUR||||||||0148^ANDERSON,CARL|S|1400|A|||||||||||||||||GENHOSP|||||199501102300|<cr>
It was determined that James A. Massie was transferred to the wrong room in the SICU. Therefore, the transfer was canceled.

3.4.7 Transfer patient - event A02 (second example)

MSH|^~\&|REGADT|MCM|IFENG||199601110603||ADT^A02|000001|P|2.3|||<cr>
EVN|A02|199601110603||01||199601110500<cr>
PID|||191919^^^GENHOSP|253763|MASSIE^JAMES^A||19560129|M|||171
ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|
(900)485-5344||S|C|10199925|371-66-9256||
(900)545-1200|EM^EMPLOYER|19940605||PROGRAMMER|||ACME SOFTWARE COMPANY<cr>
PV1||I|SICU^0001^02^GENHOSP|||6N^1234^A^GENHOSP|0100^ANDERSON,CARL|0148^ADDISON,JAMES||SUR||||||||0148^ANDERSON,CARL|S|1400|A|||||||||||||||||GENHOSP|||||199501102300|<cr>
The transfer is then repeated, this time to the correct bed: bed 2 of room 0001 in the SICU.

3.4.8 Discharge patient - event A03

MSH|^~\&|REGADT|MCM|IFENG||199601121005||ADT^A03|000001|P|2.3|||<cr>
EVN|A03|199601121005||01||199601121000<cr>
PID|||191919^^^GENHOSP|253763|MASSIE^JAMES^A||19560129|M|||171
ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|
(900)485-5344||S|C|10199925|371-66-9256||
(900)545-1200|EM^EMPLOYER|19940605||PROGRAMMER|||ACME SOFTWARE COMPANY<cr>
PV1||I|6N||||0100^ANDERSON,CARL|0148^ADDISON,JAMES||SUR||||||||0148^ANDERSON,CARL|S|1400|A||||||||||||||SNF|ISH^ISHPEMING NURSING HOME||GENHOSP|||||199601102300|199691121005<cr>
When James A. Massie's condition became more stable, he returned to 6N for another day (transfer not shown) and then was discharged to the Ishpeming Nursing Home.

3.5 IMPLEMENTATION CONSIDERATIONS

3.5.1 Swapping a patient

Some systems may handle this as a single function. Others may require a multiple process in which:
a) patient A is assigned a temporary location
b) patient B is assigned patient A's location
c) patient A is assigned patient B's prior location
This three-step scenario requires three separate transfer messages instead of a single swap message. If all beds in a hospital are occupied, it may be necessary to use a dummy location.

3.5.2 Merging patient/person information

3.5.2.1 Definitions: Merge, move, and change identifier events

The term "identifier" is used throughout this section. An identifier is associated with a set (or sets) of data. For example, an internal identifier (PID-3-patient ID [internal ID]) may be a medical record number which has associated with it account numbers (PID-18-patient account number.) Account number (PID-18-patient account number) is a type of identifier which may have associated with it visit numbers (PV1-19-visit number).
This section addresses the events that occur usually for the purposes of correcting errors in person, patient, account, or visit identifiers. The types of errors that occur typically fall into three categories:
1) Duplicate identifier created
The registrar fails to identify an existing person, patient, account, or visit and creates a new, "duplicate" record instead of using the existing record. A "merge" operation is used to fix this type of error.
2) Incorrect identifier selected
The registrar mistakenly selects the wrong person, patient, or account and creates or attaches a patient, account, or visit underneath the incorrect person, patient, or account. A "move" operation is used to fix this type of error.
3) Incorrect identifier assigned
The registrar accidentally types in the wrong new identifier for a person, patient, account, or visit. This type of mistake usually occurs when identifiers are manually assigned (not system generated). A "change identifier" operation is used to fix this type of error.

3.5.2.1.1 Hierarchy of Identifiers

These events assume a hierarchy of identifiers exists between person, patient, account, and visit. The hierarchy is as follows:

Level 4 - Person (identified by PID-2-external ID)
Level 3 - Patient (identified by PID-3-internal ID)
Level 2 - Account (identified by PID-18-patient account number)
Level 1 - Visit (identified by PV1-19-visit number)

The visit-level identifier PV1-19-visit number is the lowest level identifier and is considered subordinate to the account-level identifier PID-18-patient account number.
This means that visit identifiers are defined within the context of an account identifier, and implies that visit identifiers are unique within account identifiers. Similarly, account identifiers are subordinate to, and unique within, patient identifiers; patient identifiers are subordinate to, and unique within, person identifiers.
Conversely, the person-level identifier PID-2-external ID is the highest level identifier and is considered superior to the patient-level identifiers, which are superior to the account-level identifier, which is superior to any visit-level identifiers.
Note that these events will also apply to environments in which one or more of these levels do not occur. For example, some environments may not have a person (or MPI) level, or they may not have a visit level, or they may have a visit level without an account level. The hierarchy concept is depicted graphically below. For example, Bob Kelly might be assigned an MPI number at the ABC hospital network (depicted by the circle). He may have different medical records at two hospitals within the network (depicted by the squares). Associated with each of these medical records are two accounts (depicted by the triangles). Note that the environment illustrated does not support the "visit" level, although in other implementations it might.
Click here for Picture

3.5.2.1.2 Merge

A merge event signals that two distinct records have been combined together into a single record with a single set of identifiers and data surviving at the level of the merge. All records at a level subordinate to the merged identifier are combined under the surviving record. For example, an A39 (merge person-external ID) event would be sent to signal that two person records (identified by MRG-4-prior patient ID external and by PID-2-patient ID [external ID]) have been merged into a single record. All of the internal identifiers, accounts, and visits under the person record are not merged together - they are instead combined under the same person record. The following figure graphically depicts the merge event:
Click here for Picture

3.5.2.1.3 Move

A "move" involves transferring one or more datasets (identified by a subordinate identifier) from one superior identifier at the next hierarchical level to another superior identifier at the next hierarchical level, while all identifiers involved retain their original value. An exception to retaining the original identifier value may occur if any of the subordinate source identifiers already exist under the target superior identifier. In this case the identifier value may have to be renumbered in order to be uniquely identified under the target superior identifier. (Refer to Section 3.5.2.2.15, "A45 - move visit information - visit number (repeating segment)," for an illustration of this.)
A move event signals that a patient, account, or visit has been moved from one person, patient, or account to another. All records at a subordinate level are also moved. For example, an A43 (move patient information-internal ID) event would be sent to signal that a medical records administrator has moved a medical record attached to an incorrect person to a correct person. The following figure graphically depicts the move event:
Click here for Picture

3.5.2.1.4 Change identifier

A change identifier event signals that a single person, patient, account, or visit identifier has been changed. It does not reflect a merge or a move, it is simply a change of an identifier. For example, a "Change Identifier" event would be sent to signal that the registrar has changed an incorrectly assigned person identifier to a correct person identifier. The following picture graphically depicts this event:
Click here for Picture

3.5.2.1.5 Source and target identifiers

Merge, move, and change events reference target and source identifiers. The incorrect source identifier is specified in the MRG segment. The correct target identifier is identified in the PID or PV1 segment. For example, when you are changing a patient account number the source would be MRG-3-prior patient account number. The target is PID-18-patient account number.

3.5.2.1.6 Tightly coupled identifiers

PID-3-patient ID (internal ID) and PID-4-alternate patient ID-PID can be repeating in the PID segment. When these identifiers are the target in a merge, move, or change event, the associated source identifiers in the MRG must be "tightly" coupled. This means there must be a one-to-one match between the repeating PID-3-patient ID (internal ID) and the repeating MRG-1-prior patient ID-internal numbers, or between the repeating PID-4-alternate patient ID and the repeating MRG-2-prior alternate patient ID numbers. For example, if MRG-1-prior patient ID-internal numbers reports |MR2^^^XYZ^MR~200^^^XYZ^PI|, a corresponding MR and PI number should be reported in PID-3-patient ID (internal ID), e.g., |MR1^^^XYZ^MR~100^^^XYZ^PI|. See the use case for A40 (merge patient information-internal ID) for an illustration.
Another aspect of tightly coupled identifiers deals with the pairings of identifiers between the MRG segment and their associated identifier in the PID or PV1 segment as defined below:
The pairings that define "tightly coupled" are as follows:
Person: PID-2-patient ID (external ID) with MRG-4-prior patient ID (external ID)
Patient: PID-3-patient ID (internal ID) with MRG-1-prior patient ID (internal ID)
by <identifier type code> field component
PID-4-alternate patient ID with MRG-2-prior alternate patient ID
Account: PID-18-patient account number with MRG-3-prior patient account number
Visit: PV1-19-visit number with MRG-5-prior visit number
PV1-50-alternate visit ID with MRG-6-prior alternate visit ID

3.5.2.1.7 Global merge and move message construct versus repeating segment message constructs

A flexible message construct is provided for merge trigger events. The message construct allows for a repeating set of PID, optional PD1, MRG, and optional PV1 segments as illustrated below:
MSH
EVN
{ PID
[PD1]
MRG
[PV1]
}
Trigger events support the concept of a global move or merge, where all the subordinate identifiers are moved or merged. For example, the use case for A41 (merge account-patient account number) (Section 3.5.2.2.9, "A41 - merge account - patient account number (global)") illustrates a merge on the patient account number (PID-18-patient account number). All subordinate identifiers (PV1-19-visit number) are moved to the target PID-18-patient account number identifier, even though they are not specified in the message.
A repeating segment message construct supports reporting of the subordinate identifiers using the repeating segments. This is illustrated in the use case for A40 (merge patient-internal ID) (Section 3.5.2.2.8, "A40 - merge patient - internal ID (repeating segment)"), A41 (merge account - patient account number) (Section 3.5.2.2.10, "A41 - merge account - patient account number (repeating segment)"), and A45 (move visit information-visit number) (Section 3.5.2.2.15, "A45 - move visit information - visit number (repeating segment)"). Specifying each subordinate ID in repeating segments is optional but not recommended. This construct can be used when renumbering of identifiers is necessary as illustrated in Sections 3.5.2.2.8, "A40 - merge patient - internal ID (repeating segment)," 3.5.2.2.10, "A41 - merge account - patient account number (repeating segment)," and 3.5.2.2.15, "A45 - move visit information - visit number (repeating segment)," or to explicitly identify individual subordinate identifiers as illustrated in Section 3.5.2.2.14, "A45 - move visit information - visit number (repeating segment)."

3.5.2.1.8 Identifier renumbering

When renumbering of identifiers occurs, the repeating segment construct may be required in order to report identifier number changes. When renumbering occurs, the incorrect source identifier is specified in the MRG segment and the correct target identifier is reported in the PID or PV1 segment. Refer to the use case for A41 (merge account-patient account number) for an illustration.

3.5.2.1.9 Superior identifier reporting

When merging or moving subordinate numbers, the higher level, "superior" identifiers should be included in the message. For example, when merging an account where the target is PID-18-patient account number and the source is MRG-3-prior patient account number, the higher level patient identifiers (PID-3 -patient ID- internal ID and MRG-1-prior patient ID-internal) and person identifiers (PID-2-patient ID-external ID and MRG-4-prior patient ID-external) should also be reported in the message.

3.5.2.2 Trigger events

The intent of trigger events A18 (merge patient information), A30 (merge person information), A34 (merge patient information-patient ID only), A35 (merge patient information-account number only), A36 (merge patient information-patient ID and account number), A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID) is to reconcile distinct sets of existing person/patient data records that have been entered under different identification numbers, either deliberately or because of errors. Ideally, following any of these trigger events, all of the person/patient data should be accessible under whatever surviving identifiers were specified in the messages. Because of substantial differences in database architectures and system-dependent data processing requirements or limitations, the exact meaning and implementation of these events must be negotiated between systems.

3.5.2.2.1 A18 - Merge patient information

This event is retained for backward compatibility. This event is non-specific and heavily dependent on implementation negotiations. Sites requiring (or desiring) greater specificity can use the following events: A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID).

3.5.2.2.2 A30 - Merge person information

This event is retained for backward compatibility. This event is non-specific and heavily dependent on implementation negotiations. Sites requiring (or desiring) greater specificity can use the following events: A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID).

3.5.2.2.3 A34 - Merge patient information - patient ID only

This event is retained for backward compatibility. This event is non-specific and heavily dependent on implementation negotiations. Sites requiring (or desiring) greater specificity can use the following events: A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID).

3.5.2.2.4 A35 - Merge patient information - account number only

This event is retained for backward compatibility. This event is non-specific and heavily dependent on implementation negotiations. Sites requiring (or desiring) greater specificity can use the following events: A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID).

3.5.2.2.5 A36 - Merge patient information - patient ID & account number

This event is retained for backward compatibility. This event is non-specific and heavily dependent on implementation negotiations. Sites requiring (or desiring) greater specificity can use the following events: A39 (merge person-external ID), A40 (merge person-internal ID), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-internal ID), A44 (move account information-patient account number), A45 (move visit information-visit number), A46 (change external ID), A47 (change internal ID), A48 (change alternate patient ID), A49 (change patient account number), A50 (change visit number), and A51 (change alternate visit ID).

3.5.2.2.6 A39 - merge person - external ID

3.5.2.2.7 A40 - merge patient - internal ID

3.5.2.2.8 A40 - merge patient - internal ID (repeating segment)

3.5.2.2.9 A41 - merge account - patient account number (global)

This event illustrates the concept of a global merge as defined in Section 3.5.2.1.7, "Global merge and move message construct versus repeating segment message constructs."

3.5.2.2.10 A41 - merge account - patient account number (repeating segment)

This event illustrates the concept of a repeating segment merge as defined in 3.5.2.1.7.

3.5.2.2.11 A42 - Merge visit - visit number

3.5.2.2.12 A43 - move patient information - internal ID

3.5.2.2.13 A44 - move account information - patient account number

3.5.2.2.14 A45 - move visit information - visit number (repeating segment)

3.5.2.2.15 A45 - move visit information - visit number (repeating segment)

3.5.2.2.16 A46 - change external ID

3.5.2.2.17 A47 - change internal ID

3.5.2.2.18 A48 - change alternate patient ID

3.5.2.2.19 A49 - change patient account number

3.5.2.2.20 A50 - change visit number

3.5.2.2.21 A51 - change alternate visit ID