References to other Chapters

3.1. PURPOSE

• 3
  Chapter 3
  • 3.1 PURPOSE
  • 3.2 TRIGGER EVENTS AND MESSAGE DEFINITIONS
    • 3.2.1 Admit a Patient (Event Code A01)
    • 3.2.2 Transfer (Event Code A02)
    • 3.2.3 Discharge (Event Code A03)
    • 3.2.4 Register a Patient (Event Code A04)
    • 3.2.5 Pre-admit a Patient (Event Code A05)
    • 3.2.6 Transfer an Outpatient to Inpatient (Event Code A06)
    • 3.2.7 Transfer an Inpatient to Outpatient (Event Code A07)
    • 3.2.8 Update Patient Information (Event Code A08)
    • 3.2.9 Patient Departing (Event Code A09)
    • 3.2.10 Patient Arriving (Event Code A10)
    • 3.2.11 Cancel Admit (Event Code A11)
    • 3.2.12 Cancel Transfer (Event Code A12)
    • 3.2.13 Cancel Discharge (Event Code A13)
    • 3.2.14 Pending Admit (Event Code A14)
    • 3.2.15 Pending Transfer (Event Code A15)
    • 3.2.16 Pending Discharge (Event Code A16)
    • 3.2.17 Swap Patients (Event Code A17)
    • 3.2.18 Merge Patient Information (Event Code A18)
    • 3.2.19 Patient Query (Event Code A19)
    • 3.2.20 3.2.20. Nursing/Census Application Updates (Event Code A20)
    • 3.2.21 Patient Goes On A "Leave Of Absence" (Event Code A21)
    • 3.2.22 A Patient Returns From A "Leave Of Absence" (Event Code A22)
    • 3.2.23 Delete a Patient Record (Event Code A23)
    • 3.2.24 Create a Patient Link Transaction (Event Code A24)
  • 3.3 MESSAGE SEGMENTS
    • 3.3.1 EVN - EVENT TYPE-(Ereignistyp)
    • 3.3.2 MRG-MERGE PATIENT INFORMATION/Patienteninf. zusammenführen
    • 3.3.3 PID - PATIENT IDENTIFICATION-
    • 3.3.4 PV1 - PATIENT VISIT-/Fall
    • 3.3.5 NPU - NON-PATIENT UPDATE/Bettenstatus--
    • 3.3.6 NK1 - NEXT OF KIN/Zu benachrichtigende Person -
  • 3.4 EXAMPLE TRANSACTIONS
    • 3.4.1 Admit a Patient - Trigger Event 01-
    • 3.4.2 Merge Patient Information - Trigger Event 18-
  • 3.5 IMPLEMENTATION CONSIDERATIONS
  • 3.6 OUTSTANDING ISSUES

3
Chapter 3

3.1 PURPOSE

The ADT Transaction Set provides for transmitting new or updated demographic and visit information about patients. Since virtually any system attached to the network requires information about patients, it is one of the most commonly used transaction sets.
Generally, information will be entered into an ADT system and passed to the nursing, ancillary and financial systems either in the form of an unsolicited update or in response to a record-oriented query.
This chapter defines the transactions at the seventh level, i.e., the abstract messages. Various schemes may be used to generate the actual characters that comprise the messages according to the communications environment. The HL7 Encoding Rules will be used where there is not a complete Presentation Layer. This is described in Chapter 1, "Relationship to Other Protocols." The examples included in this chapter were constructed using the HL7 Encoding Rules.

3.2 TRIGGER EVENTS AND MESSAGE DEFINITIONS

Each triggering event is listed below, along with the applicable form of the message exchange. The notation used to describe the sequence, optionality, and repetition of segments is described in Chapter II, "Format for Defining Abstract Messages."
The triggering events that follow are all served by the ADT unsolicited update and the ACK response.

3.2.1 Admit a Patient (Event Code A01)

Normally entered in the primary ADT system and broadcast to the nursing units and ancillary systems. Includes short-stay and John Doe admissions.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
NK1 Next of Kin VI
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.2 Transfer (Event Code A02)

A patient moves from one location to another.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.3 Discharge (Event Code A03)

Refers to changing a patient's status from, for example, inpatient to discharged.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.4 Register a Patient (Event Code A04)

Includes Emergency Room patients and outpatients.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
NK1 Next of Kin VI
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MS Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.5 Pre-admit a Patient (Event Code A05)

A patient may be pre-admitted for a variety of reasons; e.g. prior to surgery so that they will be able to receive tests administered in the lab. The data may be entered into the surgery scheduling system and passed to the ADT system.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
NK1 Next of Kin VI
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.6 Transfer an Outpatient to Inpatient (Event Code A06)

ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.7 Transfer an Inpatient to Outpatient (Event Code A07)

ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.8 Update Patient Information (Event Code A08)

This trigger event is used when any patient information has changed, but no other trigger event has occurred.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
NK1 Next of Kin VI
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.9 Patient Departing (Event Code A09)

A patient is being moved from his assigned location to a new location. For example, this can be used when the nursing system is not the same as the ADT system.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.10 Patient Arriving (Event Code A10)

The patient arrives at his new assigned location.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.11 Cancel Admit (Event Code A11)

ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.12 Cancel Transfer (Event Code A12)

New location must show the location of the patient prior to the transfer.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.13 Cancel Discharge (Event Code A13)

New location must show the location of the patient prior to the discharge.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.14 Pending Admit (Event Code A14)

ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PD1 Patient Demographics III
NK1 Next of Kin VI
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.15 Pending Transfer (Event Code A15)

ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.16 Pending Discharge (Event Code A16)

ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
[ DG1 ] Diagnosis Information VI
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.17 Swap Patients (Event Code A17)

Used when it is decided that two patients will exchange beds. The patient id and visit data is repeated for the two patients being swapped. There is an implementation issue related to how systems will handle this.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
{ PID Patient Identification III
PV1 }
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.18 Merge Patient Information (Event Code A18)

Used to merge current and previous patient ids. This is required, for example, when a patient has previously been registered under a new id because of an error or because there was insufficient time to determine the actual patient id. The merge event occurs when the decision is made to combine the information under either the new or old id.
The PID segment contains the surviving patient id information. The MRG segment contains the non-surviving information.
The receiving application may also have to update patient data in other files.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
MRG Merge Information III
[ PV1 ] Patient Visit III
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II
The following triggering event is served by QRY (a query from another system) and ADR (a response from an ADT system.)

3.2.19 Patient Query (Event Code A19)

Another application determines a need for ADT data about a patient and sends a query to the ADT system. The Who Filter in the QRD can identify the patient or account number upon which the query is defined and can contain a Format Code of R (record oriented). If the query is based on Patient ID and there are data associated with multiple accounts, it is an implementation issue as to which account data should be returned. The ADT Event Type Segment, if included in the response, describes the last event for which the ADT system initiated an unsolicited update.
QRY Query Chapter
MSH Message Header II
QRD Query Definition V
ADR ADT Response Chapter
MSH Message Header II
MSA Message Acknowledgement II
QRD Query Definition V
{ [EVN] Event Type III
PID Patient Identification III
PV1 } Patient Visit III
[ DSC ] Continuation Pointer V
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 the 'who subject filter' may be used, such as:
IP Inpatient
OP Outpatient
DC Discharged
For the ANU subject filter, the ADT systems response must have some method of conveying the fact that some beds are empty (as well as returning the data for all patients in the occupied beds). This will be done as follows:
1) Bed Full:
Regular { [EVN], PID, PV1 } segment group for each patient with bed status value of 'O' occupied.
2) Bed Empty:
For this case, all fields in the corresponding EVN, PID, and PV1 segments are null except for the following fields in the PV1 segment.
* new patient location contains the bed location information
* Bed status contains one of the following values: U (unoccupied), H (housekeeping), or C (closed).

3.2.20 3.2.20. Nursing/Census Application Updates (Event Code A20)

Certain nursing/census applications need to be able to update the ADT system's bed status. The following is the associated record layout.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
NPU Non-Patient Update III
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.21 Patient Goes On A "Leave Of Absence" (Event Code A21)

ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.22 A Patient Returns From A "Leave Of Absence" (Event Code A22)

ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.23 Delete a Patient Record (Event Code A23)

ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.2.24 Create a Patient Link Transaction (Event Code A24)

Where the first PID segment needs to be linked to the second PID segment.
ADT ADT Message Chapter
MSH Message Header II
EVN Event Type III
PID Patient Identification III
PV1 Patient Visit III
PID Patient Identification III
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error Information II

3.3 MESSAGE SEGMENTS

3.3.1 EVN - EVENT TYPE-(Ereignistyp)

The EVN segment is used to communicate necessary trigger event information to receiving applications. Valid event types for all chapters are contained in TABLE 0003. They include for example:
A01-ADMIT PATIENT; A06-TRANSFER O/P to I/P; etc.

FIELD NOTES: EVN EVENT TYPE

1. 00029 EVENT TYPE CODE. Codes correspond to the trigger events described in this section. e.g., (admission, transfer, registration ....).

2. 00030 DATE/TIME OF EVENT. Most systems will default to the system date/time when the transaction was entered, but should also permit an override.

3. 00032 DATE/TIME PLANNED EVENT. This field contains the date/time the event is planned. If the event type is 05 (pre-admit a patient), then this field is required. Other events will use this date/time field as needed.

4. 00369 EVENT REASON CODE. This field contains a code describing the reason for this event (e.g.: patient request, physician order, census management, etc.). Refer to table 0062 for valid codes.

3.3.2 MRG-MERGE PATIENT INFORMATION/Patienteninf. zusammenführen

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.

FIELD NOTES: MRG MERGE PATIENT INFORMATION

1. 00576 PRIOR PATIENT ID - INTERNAL. In the form patient id^check digit^check digit scheme.

2. 00577 PRIOR ALTERNATE PATIENT ID. In the form patient-id^check digit^check digit scheme.

3. 00578 PRIOR PATIENT ACCOUNT NUMBER. In the form account number^check digit^check digit scheme.

3.3.3 PID - PATIENT IDENTIFICATION-

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 change frequently.

Anm.:
Beruf, Staatsangehörigkeit und Geburtsort sind in der Version 2.2 in den Segment PV2 und NK1 vorgesehen.
FIELD NOTES: PID PATIENT IDENTIFICATION

1. 00572 SET ID - PATIENT ID. For those messages that permit multiple data sets about different patients, the SET ID field is used to identify the repetitions. For example, the swap and query transactions allow for multiple PID segments.

2. 00581 PATIENT ID (EXTERNAL ID). If the patient is from another institution, outside office, etc., the identifier used by that institution can be shown here. In the form patient id^check digit^check digit scheme. See table 0061 for check digit scheme ID's.

3. 00034 PATIENT ID (INTERNAL ID). Primary ID used by the facility to uniquely identify a patient at the time of admit, (e.g., medical record number, billing number, etc). In the form patient id^check digit^ check digit scheme. See table 0061 for valid check digit ID's.

4. 00038 ALTERNATE PATIENT ID. A third number may be required to identify a patient. Possible contents include a visit number, a visit date, or Social Security number.
Vorgesehen für die in deutschen Krankenhäusern benutzte Fallnummer.

5. 00041 PATIENT NAME. Name is standard format described in Chapter II.

6. 00582 MOTHER'S MAIDEN NAME. The family name under which the mother was born (i.e., before marriage.) Used to disambiguate patients with the same last name.
Geburtsname des Patienten

7. 00043 DATE OF BIRTH. Patient's Date of Birth.

8. 00042 SEX. Patient's Sex. Refer to table 0001 for valid codes.

9. 00597 PATIENT ALIAS. Another name(s) by which the patient has been known at some time.

10. 00044 ETHNIC GROUP. ERISA also has a published list of ethnic classifications which may be used by local agreement at a site. Refer to table 0005 for valid codes.

11. 00020 PATIENT ADDRESS. Mailing address of the patient. Refer to Chapter II for a description of the standard format.

12. 00026 COUNTY CODE. Patient's County Code.

13. 00049 PHONE NUMBER - HOME. Up to 3 repetitions are permitted. The first is considered the primary number. Refer to Chapter II for standard format.

14. 00050 PHONE NUMBER - BUSINESS. Up to 3 repetitions are permitted. The first is considered the primary one. Refer to Chapter II for standard format.

15. 00464 LANGUAGE - PATIENT. The patient's primary language.

16. 00046 MARITAL STATUS. Patient's marital status. Refer to table 0002 for valid entries.

17. 00045 RELIGION. Patient's religion. Refer to table 0006 for valid entries.

Unter 2.2 zusätzlich
Z Buddhist
G Griech. Orthodox
I Moslem
W Zeugen Jehovas
Kann b. Bed. erweitert werden
18. 00035 PATIENT ACCOUNT NUMBER. The number assigned by accounting to which all charges, payments, etc. are recorded. It is used to identify the patient's account.

19. 00457 SSN NUMBER - PATIENT. The patient's social security number. This number may also be an RR retirement number.
20. 00453 DRIVER'S LIC NUM - PATIENT. Patient's Drivers license number. Some sites may use this as a unique number that identifies the patient. The second subfield, if present, is a code indicating the state, province, or country that issued the driver's license. Default is the state in which the patient is being registered.

3.3.4 PV1 - PATIENT VISIT-/Fall

The PV1 segment is used by Registration/ADT applications to communicate information on a visit specific basis. This segment can be used to send multiple visit statistic records to the same patient account, or single visit records to more than one account. Individual sites must determine this segments use.

Anm.: Hausarzt, Chefarzt fehlt, empfohlen wird hierfür das erste (HA) und zweite (CA) Element des wiederholbaren Feldes 9
FIELD NOTES: PV1 PATIENT VISIT

1. 00458 SET ID - PATIENT VISIT. The number that uniquely identifies this transaction for the purpose of adding, changing, or deleting the transaction.

2. 00052 PATIENT CLASS. Generally denoted as I - 'inpatient', O - outpatient; P - 'preadmit', E -'emergency' .... Subject to site-specific variations. Refer to table 0004 for valid codes.

3. 00053 ASSIGNED PATIENT LOCATION. Format is NURSE UNIT^ROOM^BED. New location is the patient's initial assigned location, or the location to which he/she is being moved. For canceling a transaction or discharging a patient, the current room number should be in this field. Refer to user defined table 0079 for valid entries.
Vorgesehenes Format in 2.2 Station^Zimmer^Bett^Klinik-ID^Bettenstatus (Gilt ebenfalls für Felder 6, 11, 42, 43)

4. 00218 ADMISSION TYPE. This code indicates the circumstance under which the patient was or will be admitted.

5. 00219 PRE-ADMIT NUMBER. The number that 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.

6. 00056 PRIOR PATIENT LOCATION. The format contains up to three components: NURSE UNIT^ROOM^ BED. The old location is null if the patient is new. It contains the prior patient location if the patient is being transferred. Refer to user defined table 0079 for valid entries.

7. 00057 ATTENDING DOCTOR. In the form "physician id^name". Depending on local agreements, either id or the name may be absent. Refer to user defined table 0010 for valid entries.

8. 00579 REFERRING DOCTOR. In the form "physician id^name". Depending on local agreements, either id or the name may be absent. Refer to user defined table 0010 for valid entries.

9. 00580 CONSULTING DOCTOR. In the form "physician id^name". Depending on local agreements, either id or the name may be absent. Refer to user defined table 0010 for valid entries.
10. 00059 HOSPITAL SERVICE. The treatment or type of surgery the patient is scheduled to receive. Required field with trigger events 01, 02, 14, 15. Refer to user defined table 0069 for valid entries.

11. 00060 TEMPORARY LOCATION. A location other than the assigned location required for a temporary period of time (e.g., OR). In the form: "NURSE UNIT^ROOM^BED". Refer to user defined table 0079 for valid entries.
(abweichend von Feld 3). z. B. Aufwachraum.
12. 00220 PRE-ADMIT TEST INDICATOR. The code indicates that the patient must have pre-admission testing done in order to be admitted. Refer to table 0087 for valid codes.

13. 00221 RE-ADMISSION INDICATOR. 'R' for readmission or else null. The code used to indicate that a patient is being re-admitted to the facility and the circumstances. Refer to user table 0092 for valid entries.

14. 00063 ADMIT SOURCE. The code contained in this field indicates where the patient was admitted from. Refer to table 0023 for valid codes.
(z. B. einw. Krankenhaus)
15. 00064 AMBULATORY STATUS. Refer to table 0009 for valid entries.

Anm.:
Feld 15 ist ab V2.2 wiederholbar
16. 00193 VIP INDICATOR. This field is a user defined code to identify the type of VIP. Refer to table 0099 for valid entries.

17. 00189 ADMITTING DOCTOR. In the form doctor id^doctor name. By local agreement name or id may not be present. Refer to user defined table 0010 for valid entries.

18. 00191 PATIENT TYPE. Site specific values. Refer user defined table 0018 for valid entries.

19. 00194 VISIT NUMBER. The unique number assigned to each patient visit.

20. 00195 FINANCIAL CLASS. The primary financial class assigned to the patient for the purpose of identifying sources of reimbursement. The first subfield is the class, the second subfield is the effective date (DT format). Repeats up to 4 times. Refer to user defined table 0064 for valid codes.

21. 00199 CHARGE PRICE INDICATOR. The code used to determine which price schedule is to be used for room and bed charges. Refer to table 0032 for valid entries.

22. 00386 COURTESY CODE. A code that indicates whether the patient will be extended certain special courtesies. Refer to user defined table 0045 for valid entries.

23. 00200 CREDIT RATING. A user defined code to determine past credit experience. Refer user defined table 0046 for valid entries.

24. 00201 CONTRACT CODE. This code is used to identify 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 for valid entries.

25. 00202 CONTRACT EFFECTIVE DATE. The date the contract is to start.

26. 00203 CONTRACT AMOUNT. The amount to be paid by the guarantor each period as per the contract.
27. 00204 CONTRACT PERIOD. Specifies the duration of the contract for user defined periods.

28. 00387 INTEREST CODE. The code that indicates the amount of interest that will be charged the guarantor on any outstanding amounts. Refer to user defined table 0073 for valid entries.

29. 00205 TRANSFER TO BAD DEBT CODE. Code to indicate that the account was transferred to bad debts and the reason. Refer to user defined table 0110 for valid entries.

30. 00388 TRANSFER TO BAD DEBT DATE. The date that the account was transferred to a bad debt status.

31. 00206 BAD DEBT AGENCY CODE. Code used to uniquely identify the bad debt agency that the account was transferred to. This code is site-defined. Refer to user defined table 0021 for valid entries.

32. 00389 BAD DEBT TRANSFER AMOUNT. The amount that was transferred to a bad debt status.

33. 00390 BAD DEBT RECOVERY AMOUNT. The amount recovered from the guarantor on the account.

34. 00207 DELETE ACCOUNT INDICATOR. Code to indicate that the account was deleted from the file and the reason. Refer to user defined table 0111 for valid entries.

35. 00208 DELETE ACCOUNT DATE. The date that the account was deleted from the file.

36. 00613 DISCHARGE DISPOSITION. The disposition of the patient at time of discharge(i.e.: discharged to home; expired; etc.). Refer to table 0112 for valid entries.

37. 00614 DISCHARGED TO LOCATION. A coded field indication a facility to which the patient was discharged. Refer to user defined table 0113 for valid entries.

38. 00615 DIET TYPE. A coded field indication a special diet type for a patient. Refer to user defined table 0114 for valid entries.

39. 00616 SERVICING FACILITY. Used in a multiple facility environment to indicate the facility this visit is associated with. Refer to user defined table 0115 for valid entries. (Kann für interne Zwecke verwendet werden)

40. 00617 BED STATUS. Refer to user defined table 0116 for valid entries.

ed Frei
Anm.: Der Bettenstatus wird als letzte Komponente der versch. Aufenthaltsfelder (3, 6, 11, 42, 43) benutzt
41. 00703 ACCOUNT STATUS. Refer to user defined table 0117 for valid entries.

42. 00704 PENDING LOCATION. This field indicates the Nursing Station, Room, and Bed the patient may be moved to. Refer to user defined table 0079 for valid entries.

43. 00705 PRIOR TEMPORARY LOCATION. This field can be used when patient arriving or departing or general update events. The format contains up to 3 components; "NURSE UNIT^ROOM^BED". Refer to user defined table 0079 for valid entries.

44. 00775 ADMIT DATE/TIME. Admit date/time. To be used if the event date/time is different than the admit date and time, i.e., a retroactive update.
(Falls unterschiedlich zum Ereigniszeitpunkt im EVN Segment)
45. 00776 DISCHARGE DATE/TIME. Discharge date/time. To be used if the event date/time is different than the admit date and time, i.e., a retroactive update. (Falls unterschiedlich zum Ereigniszeitpunkt im EVN Segment)

46. 00777 CURRENT PATIENT BALANCE. Visit balance due.

47. 00778 TOTAL CHARGES. Total charges.

48. 00779 TOTAL ADJUSTMENTS. Total adjustments.

49. 00780 TOTAL PAYMENTS. Total payments.

3.3.5 NPU - NON-PATIENT UPDATE/Bettenstatus--

The NPU segment allows the updating of census (bed status) data without sending patient specific data. For example: changing the status of a bed from HOUSEKEEPING to UNOCCUPIED.

FIELD NOTES: NPU NON-PATIENT UPDATE

1. 00785 BED LOCATION. Format is NURSE UNIT^ROOM^BED. Bed location is a valid bed location. Refer to user-defined table 0079 for valid entries.
Form.: Station^Zimmer^Bett^Klinik^Bettenstatus (aus 2.2)
2. 00671 BED STATUS. Refer to table 0116 for valid entries.

TABLE 0116 BED STATUS Bettenstatus

3.3.6 NK1 - NEXT OF KIN/Zu benachrichtigende Person -

The NK1 segment contains information about the patient's next of kin. Utilizing the SET ID field, multiple NT1 segments can be sent to patient accounts.

FIELD NOTES: NK1 NEXT OF KIN

1. 00712 SET ID - NEXT OF KIN. This field is used to uniquely identify the NK1 records for the purpose of adding, changing, or deleting records.

2. 00048 NEXT OF KIN NAME.

3. 00047 NEXT OF KIN RELATIONSHIP. This code indicates the next-of-kin relationship to the patient.

4. 00225 NEXT OF KIN - ADDRESS.

5. 00230 NEXT OF KIN-PHONE NUMBER.

3.4 EXAMPLE TRANSACTIONS

3.4.1 Admit a Patient - Trigger Event 01-

MSH|^~\|REGADT|MCM|LABADT|MCM|198808181126|SECURITY|ADT|
MSG00001|P|2.1|<cr>
EVN|01|198808181123||<cr>
PID|||PATID1234^5^M11||JONES^WILLIAM^A^III||19610615|M||C|
1200 N ELM STREET^GREENSBORO^NC^27401-1020|GL|(919)379-1212|
(919)271-3434||S||PATID12345001^2^M10|123456789|
987654^NC|<cr>
NK1|JONES^BARBARA^K|WIFE|<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||ADM|
A0|<cr>
Patient William A. Jones, III was admitted on July 18, 1988 at 1123 a.m. by doctor Sidney J. Lebauer (#004777) for surgery (SUR). He has been assigned to room 2012, bed 01 on nursing unit 2000.
The message was sent from system REGADT at the MCM site to system LABADT also at the MCM site on the same date as the admission took place but three minutes after the admit.

3.4.2 Merge Patient Information - Trigger Event 18-

MSH|^~\|REGADT|MCM|RSP1P8|MCM|198808181320|SECURITY|ADT|
MSG00002|P|2.1|<cr>
EVN|18|198808181318||<cr>
PID|||PATID5678^9^M11||JONES^WILLIAM^A^JR||19310615|M||C|
303 EDWARDS DRIVE^GREENSBORO^NC^27410|GL|(919)294-1212|
(919)288-0101||M||PATID12345001^2^M10|987654321|143257^NC|
<cr>
MRG|PATID1234^5^M11||<cr>
NK1|JONES^NANCY^K|WIFE|<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||||<cr>
During the admission process, the admitting secretary used the medical record number of William A. Jones, III instead of William A. Jones, Jr. The billing number stayed the same since it is tied to the visit and numerous charges have already been incurred. The inclusion of the "MRG" segment with the old patient ID filled in, triggers the merge.

3.5 IMPLEMENTATION CONSIDERATIONS

1. Swapping a Patient. Some systems may handle this as a single function. Others may require a three-step process where:
a) patient A is assigned as temporary location;
b) patient B is assigned patient A's location; and
c) patient A is assigned patient B's prior location.
The three-step scenario requires three separate transfer messages. If all beds are occupied, it may be necessary to use a dummy location.
2. Valid Codes. The lists of possible codes included with each field are considered to be HL7 standard values. If there is a desire to add or change these values, please submit your request to HL7 in writing for prompt consideration.

3.6 OUTSTANDING ISSUES

1. It may be appropriate to separate the set seq # or SET ID fields (this field name is in the process of changing which is why the 'or' exists) into separate segments.
2. We need to determine some way to include the transmission of data related to allergies.