3. Patient Administration |
|
Chapter Chair:
Jean Ferraro McKesson
Chapter Chair:
Gregg Seppala Veterans Affairs
Chapter Chair/Editor:
Klaus D. Veil HL7 Australia
The Patient Administration transaction set provides for the transmission of new or updated demographic and visit information about patients. Since virtually any system attached to the network requires information about patients, the Patient Administration transaction set is one of the most commonly used.
Generally, information is entered into a Patient Administration system and passed to the nursing, ancillary and financial systems either in the form of an unsolicited update or a response to a record-oriented query.
This chapter defines the transactions that occur at the seventh level, that is, the abstract messages. The examples included in this chapter were constructed using the HL7 Encoding Rules.
Each trigger event is listed below, along with the applicable form of the message exchange. The notation used to describe the sequence, optionality, and repetition of segments is described in Chapter 2, Section 2.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.
An A01 event is intended to be used for _Admitted_ patients only. An A01 event is sent as a result of a patient undergoing the admission process which assigns the patient to a bed. It signals the beginning of a patient_s stay in a healthcare facility. Normally, this information is entered in the primary Patient Administration system and broadcast to the nursing units and ancillary systems. It includes short stay and _John Doe_ (e.g. patient name is unknown) admissions. For example, an A01 event can be used to notify: the pharmacy system that a patient has been admitted and may be legitimately prescribed drugs; the nursing system that the patient has been admitted and needs a care plan prepared; the finance system of the start of the billing period; the dietary system that a new patient has been installed and requires dietary services; the laboratory, pathology, and radiology systems that a patient has been admitted and is entitled to receive services; the clinical repository that an admission has taken place for the EMR (electronic medical record).
When an account_s start and end dates span a period greater than any particular visit, the P01 (add patient account) event should be used to transmit the opening of an account. The A01 event can notify systems of the creation of an account as well as notify them of a patient_s arrival in the healthcare facility. In order to create a new account without notifying of patient_s arrival, use the P01 event.
The ROL - Role Segment is used in this message to communicate providers not specified elsewhere. Person level providers with an ongoing relationship are reported in the ROL segment following the PID/PD1 segments. Providers corresponding to the PV1 data are reported in the ROL segment following the PV1/PV2 segments. Providers related to a specific procedure are reported in the ROL segment following the PR1 segment. Providers related to a specific insurance are reported in the ROL segment following the IN1/IN2/IN3 segments. To communicate the begin and end date of the provider, use the ROL-5 - Role Begin Date/Time and the ROL-6 - Role End Date/Time in the ROL segment, with the applicable ROL-3 - Role Code. Refer to Chapter 15 for the definition of the ROL segment.
ADT^A01^ADT_A01 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ UB1 ] | Universal Bill Information |
| 6 | DB |
[ UB2 ] | Universal Bill 92 Information |
| 6 | DB |
[ PDA ] | Patient Death and Autopsy |
| 3 | DB |
ACK^A01^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A02^ADT_A02 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ PDA ] | Patient Death and Autopsy |
| 3 | DB |
ACK^A02^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A03^ADT_A03 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ PDA ] | Patient Death and Autopsy |
| 3 | DB |
ACK^A03^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A04^ADT_A01 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ UB1 ] | Universal Bill Information |
| 6 | DB |
[ UB2 ] | Universal Bill 92 Information |
| 6 | DB |
[ PDA ] | Patient Death and Autopsy |
| 3 | DB |
ACK^A04^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A05^ADT_A05 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ UB1 ] | Universal Bill Information |
| 6 | DB |
[ UB2 ] | Universal Bill 92 Information |
| 6 | DB |
ACK^A05^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A06^ADT_A06 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ MRG ] | Merge Information |
| 3 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ UB1 ] | Universal Bill Information |
| 6 | DB |
[ UB2 ] | Universal Bill 92 Information |
| 6 | DB |
ACK^A06^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A07^ADT_A06 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ MRG ] | Merge Information |
| 3 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ UB1 ] | Universal Bill Information |
| 6 | DB |
[ UB2 ] | Universal Bill 92 Information |
| 6 | DB |
ACK^A07^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A08^ADT_A01 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ UB1 ] | Universal Bill Information |
| 6 | DB |
[ UB2 ] | Universal Bill 92 Information |
| 6 | DB |
[ PDA ] | Patient Death and Autopsy |
| 3 | DB |
ACK^A08^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A09^ADT_A09 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { DG1 } ] | Diagnosis Information | B | 6 | DB |
ACK^A09^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A10^ADT_A09 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { DG1 } ] | Diagnosis Information | B | 6 | DB |
ACK^A10^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A11^ADT_A09 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { DG1 } ] | Diagnosis Information | B | 6 | DB |
ACK^A11^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A12^ADT_A12 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ DG1 ] | Diagnosis Information | B | 6 | DB |
ACK^A12^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A13^ADT_A01 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ UB1 ] | Universal Bill Information |
| 6 | DB |
[ UB2 ] | Universal Bill 92 Information |
| 6 | DB |
[ PDA ] | Patient Death and Autopsy |
| 3 | DB |
ACK^A13^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A14^ADT_A05 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ UB1 ] | Universal Bill Information |
| 6 | DB |
[ UB2 ] | Universal Bill 92 Information |
| 6 | DB |
ACK^A14^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A15^ADT_A15 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { DG1 } ] | Diagnosis Information | B | 6 | DB |
ACK^A15^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A16^ADT_A16 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
|
|
|
|
|
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
|
|
|
|
ACK^A16^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A17^ADT_A17 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient (1) Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient (1) Visit |
| 3 | DB |
[ PV2 ] | Patient (1) Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result (1) |
| 7 | DB |
PID | Patient (2) Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient (2) Visit |
| 3 | DB |
[ PV2 ] | Patient (2) Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result (2) |
| 7 | DB |
ACK^A17^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A18^ADT_A18 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
ACK^A18^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
QRY^A19^QRY_A19 | Patient Query | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
QRD | Query Definition |
| 5 | DB |
[ QRF ] | Query Filter |
| 5 | DB |
ADR^A19^ADR_A19 | ADT Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
[ QAK ] | Query Acknowledgment |
| 5 | DB |
QRD | Query Definition |
| 5 | DB |
[ QRF ] | Query Filter |
| 5 | DB |
{ | --- QUERY_RESPONSE begin |
|
|
|
[ EVN ] | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ UB1 ] | Universal Bill Information |
| 6 | DB |
[ UB2 ] | Universal Bill Information |
| 6 | DB |
} | --- QUERY_RESPONSE end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2 | DB |
In addition to single-patient responses, the ADT record-oriented query/response needs to support responses containing multiple patients for the following query types (by subject filter): return census for a nursing unit (ANU), return patients matching a name search (APN), and return patients for a given medical practitioner, physician, etc. (APP).
For multiple patient responses, additional values for QRD-9 - What Subject Filter may be used, such as:
3.3.19.1 A19 usage notes
IP | Inpatient |
OP | Outpatient |
DC | Discharged |
For the ANU subject filter, the Patient Administration systems response must have some method for conveying the fact that some beds are empty (as well as for returning the data for all patients in the occupied beds). This method will function as follows:
Bed Full Regular { [EVN], PID, PV1 } segment group for each patient with PV1-40 - Bed Status value of _O_ occupied.
Bed Empty In this case, all fields in the corresponding EVN, PID, and PV1 segments are null except for the following fields in the PV1 segment.
PV1-3 - Assigned Patient Location contains the new bed location information
PV1-40 - Bed Status contains one of the following values: U (unoccupied), H (housekeeping), or C (closed).
Certain nursing/census applications need to be able to update the Patient Administration system_s bed status. The following is the associated record layout:
ADT^A20^ADT_A20 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
NPU | Non-Patient Update |
| 3 | DB |
ACK^A20^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A21^ADT_A21 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
ACK^A21^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A22^ADT_A21 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
ACK^A22^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A23^ADT_A21 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
ACK^A23^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A24^ADT_A24 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient (1) Identification |
| 3 | DB |
[ PD1 ] | Patient (1) Additional Demographics |
| 3 | DB |
[ PV1 ] | Patient (1) Visit |
| 3 | DB |
[ { DB1 } ] | Patient (1) Disability Information |
| 3 | DB |
PID | Patient (2) Identification |
| 3 | DB |
[ PD1 ] | Patient (2) Additional Demographics |
| 3 | DB |
[ PV1 ] | Patient (2) Visit |
| 3 | DB |
[ { DB1 } ] | Patient (2) Disability Information |
| 3 | DB |
ACK^A24^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A25^ADT_A21 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
ACK^A25^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A26^ADT_A21 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
ACK^A26^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A27^ADT_A21 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
ACK^A27^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A28^ADT_A05 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- PROCEDURE begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[{ | --- INSURANCE begin |
|
|
|
IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
}] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ UB1 ] | Universal Bill Information |
| 6 | DB |
[ UB2 ] | Universal Bill 92 Information |
| 6 | DB |
ACK^A28^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A29^ADT_A21 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
ACK^A29^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A30^ADT_A30 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
ACK^A30^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A31^ADT_A05 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { NK1 } ] | Next of Kin / Associated Parties |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { AL1 } ] | Allergy Information |
| 3 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
[{ | --- Procedure begin |
|
|
|
PR1 | Procedures |
| 6 | DB |
{ ROL }] | Role |
| 15 | DB |
}] | --- PROCEDURE end |
|
|
|
[ { GT1 } ] | Guarantor |
| 6 | DB |
[ | --- INSURANCE begin |
|
|
|
{ IN1 | Insurance |
| 6 | DB |
[ IN2 ] | Insurance Additional Info. |
| 6 | DB |
[ { IN3 } ] | Insurance Additional Info - Cert. |
| 6 | DB |
[ { ROL } ] | Role |
| 15 | DB |
} |
|
|
|
|
] | --- INSURANCE end |
|
|
|
[ ACC ] | Accident Information |
| 6 | DB |
[ UB1 ] | Universal Bill Information |
| 6 | DB |
[ UB2 ] | Universal Bill 92 Information |
| 6 | DB |
ACK^A31^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A32^ADT_A21 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
ACK^A32^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A33^ADT_A21 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
ACK^A33^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A34^ADT_A30 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
ACK^A34^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error Information |
| 2 | DB |
ADT^A35^ADT_A30 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
ACK^A35^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A36^ADT_A30 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
ACK^A36^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A37^ADT_A37 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient (1) Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ PV1 ] | Patient (1) Visit |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
PID | Patient (2) Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ PV1 ] | Patient (2) Visit |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
ACK^A37^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A38^ADT_A38 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { DB1 } ] | Disability Information |
| 3 | DB |
[ { OBX } ] | Observation/Result |
| 7 | DB |
[ { DG1 } ] | Diagnosis Information |
| 6 | DB |
[ DRG ] | Diagnosis Related Group |
| 6 | DB |
ACK^A38^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A39^ADT_A39 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
{ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
[ PV1 ] | Patient Visit |
| 3 | DB |
} | --- PATIENT end |
|
|
ACK^A39^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A40^ADT_A39 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
{ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
[ PV1 ] | Patient Visit |
| 3 | DB |
} | --- PATIENT end |
|
|
ACK^A40^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A41^ADT_A39 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
{ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
[ PV1 ] | Patient Visit |
| 3 | DB |
} | --- PATIENT end |
|
|
ACK^A41^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A42^ADT_A39 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
{ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
[ PV1 ] | Patient Visit |
| 3 | DB |
} | --- PATIENT end |
|
|
ACK^A42^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A43^ADT_A43 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
{ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
} | --- PATIENT end |
|
|
ACK^A43^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A44^ADT_A43 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
{ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
} | --- PATIENT end |
|
|
ACK^A44^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A45^ADT_A45 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
{ | --- MERGE_INFO begin |
|
|
|
MRG | Merge Information |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
} | --- MERGE_INFO end |
|
|
ACK^A45^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A46^ADT_A30 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
ACK^A46^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A47^ADT_A30 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
ACK^A47^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A48^ADT_A30 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
ACK^A48^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A49^ADT_A30 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
ACK^A49^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error Information |
| 2 | DB |
ADT^A50^ADT_A50 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
ACK^A50^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A51^ADT_A50 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
MRG | Merge Information |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
ACK^A51^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A52^ADT_A52 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
ACK^A52^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A53^ADT_A52 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
ACK^A53^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A54^ADT_A54 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
ACK^A54^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A55^ADT_A52 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
ACK^A55^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
Query ID | Q21 |
Query Type | Query |
Query Name | Q21 Get Person Demographics |
Query Trigger | QBP^Q21^QBP_Q21 |
|
|
Response Trigger | RSP^K21^RSP_K21 |
Query Characteristics |
|
Query Purpose | Returns demographics information for a specified person |
QBP^Q21^QBP_Q21 | Query By Parameter | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
|
|
|
|
|
QPD | Query Parameter Definition Segment |
| 5 | DB |
RCP | Response Control Parameters |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
RSP^K21^RSP_K21 | Segment Pattern Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgement |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgement |
| 5 | DB |
QPD | Query Parameter Definition Segment |
| 5 | DB |
[ | --- QUERY_RESPONSE begin |
|
|
|
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
[ { NK1 } ] | Next of Kin |
| 3 | DB |
QRI | Query Response Instances |
| 5 | DB |
] | --- QUERY_RESPONSE end |
|
|
|
|
|
|
|
|
[ DSC ] | Continuation Pointer |
| 2 | DB |
Field Seq. | Field Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | LOINC or HL7 Code/Domain | ElementName |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | PersonIdentifier | S | Y | 250 | CX | R | N |
|
| PID-3 |
| Patient Identifier List |
2 | WhatDomainsReturned |
|
|
| CX | O | Y |
|
| PID-3 |
| Patient Identifier List |
Input Parameter | Comp. Name | DT | Description |
---|---|---|---|
PersonIdentifier () |
| CX |
Components: ^ < assigning authority (HD)> ^ |
|
|
| The combination of values for PersonIdentifier.ID, and PersonIdentifier.AssigningAuthority, are intended to identify a person uniquely. The PersonIdentifier.IDTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. |
|
|
| Example: ...|112234^^^METRO HOSPITAL|... |
|
|
| Only one PID.3 may be specified, only 1 segment pattern will be returned. |
|
|
|
|
PersonIdentifier. | ID |
| PID.3.1must be valued. |
PersonIdentifier | Assigning Authority |
| PID.3.4 must be valued. |
PersonIdentifier | Identifier type code |
|
|
WhatDomainsReturned |
| CX |
Components: ^ < assigning authority (HD)> ^ |
|
|
| This parameter restricts the set of domains for which identifiers are returned in PID-3. If this is not specified, then identifiers for all known domains shall be returned. It does not restrict the search for the person. |
|
|
| Example: ...|^^^METRO HOSPITAL~^^^SOUTH LAB|... |
|
|
| Only the following components should be valued. |
WhatDomainsReturned | Assigning Authority |
| PID.3.4 must be valued. |
WhatDomainsReturned | Identifier type code |
|
|
Following is an example of a Q21/K21 query/response pair of messages. First is the query:
MSH|^&~\|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q21^QBP_Q21|1|D|2.5
QPD|Q21^Get Person Demographics^HL7nnn|111069|112234^^^METRO HOSPITAL|^^^METRO HOSPITAL~^^^SOUTH LAB|
RCP||I|
This query is asking for demographics for the person identified by the identifier 112234 from the assigning authority METRO HOSPITAL. With the demographics, we want identifiers returned for the person from the assigning authorities METRO HOSPITAL and SOUTH LAB. Here is a sample response:
MSH|^&~\|HOSPMPI|HOSP|CLINREG|WESTCLIN|199912121135-0600||RSP^K21^RSP_K21|1|D|2.5|
MSA|AA|8699|
QAK|111069|OK|Q21^Get Person Demographics^HL7nnn|1|
QPD|Q21^Get Person Demographics^HL7nnn|111069|112234^^^METRO HOSPITAL|^^^METRO HOSPITAL~^^^SOUTH LAB|
PID|||112234^^^METRO HOSPITAL~98223^^^SOUTH LAB||Everyman^Adam||19600614|M||C|2101 Webster # 106^^Oakland^CA^94612|
This query/response is designed for interaction between a client system and an MPI (Master Person Index). The query consists of a set of demographics for a person, and the response is the list of candidates considered by the MPI to match that set.
Each returned person, specified by a PID segment, can also have an optional QRI - Query Response Instance segment containing information about the quality of the match.
Query ID | Q22 |
Query Type | Query |
Query Name | Q22 Find Candidates |
Query Trigger | QBP^Q22^QBP_Q21 |
|
|
Response Trigger | RSP^K22^RSP_K21 |
Query Characteristics |
|
Query Purpose | Returns list of candidates matching demographic data specified by the input parameters. |
QBP^Q22^QBP_Q21 | Query By Parameter | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
|
|
|
|
|
QPD | Query Parameter Definition Segment |
| 5 | DB |
RCP | Response Control Parameters |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
RSP^K22^RSP_K21 | Segment Pattern Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgement |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgement |
| 5 | DB |
QPD | Query Parameter Definition Segment |
| 5 | DB |
[{ | --- QUERY_RESPONSE begin |
|
|
|
|
|
|
|
|
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 5 | DB |
[ { NK1 } ] | Next of Kin |
| 3 | DB |
[ QRI ] | Query Response Instance |
| 5 | DB |
|
|
|
|
|
}] | --- QUERY_RESPONSE end |
|
|
|
[ DSC ] |
|
| 2 |
Field Seq. | Field Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | LOINC or HL7 Code/Domain | ElementName |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | DemographicsFields |
|
|
| QIP | R | Y |
|
|
|
|
|
2 | SearchConfidenceThreshold |
|
|
| NM | O | N |
|
|
|
|
|
3 | AlgorithmName |
|
|
| ST | O | N |
|
|
|
|
|
4 | AlgorithmVersion |
|
|
| ST | O | N |
|
|
|
|
|
5 | AlgorithmDescription |
|
|
| ST | O | N |
|
|
|
|
|
6 | WhatDomainsReturned |
|
|
| CX | O | Y |
|
| PID-3 |
| Patient Identifier List |
Input Parameter | Comp. Name | DT | Description |
---|---|---|---|
DemographicsFields |
| QIP |
Components: |
|
|
| Components may be any fields in the PID or PD1. If subcomponents of fields need to be specified, each subcomponent should be listed separately. |
|
|
| Example: ...|@PID.5.1^SMITH~@PID.5.2^JOHN~@PID.8^M|... |
SearchConfidenceThreshold |
| NM | Indicates the minimum match confidence for candidates to be returned for the query. The value instructs the queried system to return no records (PID segments) for persons whose _match weight_ on the lookup was lower than the user-defined value. |
|
|
| Example: |80| |
AlgorithmName |
| ST | Identifies the specific algorithm the queried system should use. |
|
|
| Example: |MATCHWARE| |
AlgorithmVersion |
| ST | Identifies the specific algorithm version the queried system should use. |
|
|
| Example: |1.2| |
AlgorithmDescription |
| ST | Description of the algorithm the queried system should use. |
WhatDomainsReturned |
| CX |
Components: ^ < assigning authority (HD)> ^ |
|
|
| This parameter restricts the set of domains for which identifiers are returned in PID-3. If this is not specified, then identifiers for all known domains shall be returned. It does not restrict the search for persons. |
|
|
| Example: ...|^^^METRO HOSPITAL~^^^SOUTH LAB|... |
|
|
| Only the following components should be valued. |
WhatDomainsReturned | Assigning Authority |
| PID.3.4 must be valued. |
WhatDomainsReturned | Identifier type code |
|
|
Following is an example of a Q22/K22 query/response pair of messages. First is the query:
MSH|^&~\|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q22^QBP_Q21|1|D|2.5
QPD|Q22^Find Candidates^HL7nnn|111069|@PID.5.1^SMITH~@PID.5.2^JOHN~ @PID.8^M|80|MATCHWARE|1.2||^^^METRO HOSPITAL~^^^SOUTH LAB|
RCP||I|20^RD
This query is asking for a list of persons matching the name JOHN SMITH with the gender Male. Candidates with a match level above 80 using the algorithm Matchware version 1.2 should be returned. The returned records should include identifiers for both the assigning authorities METRO HOSPITAL and SOUTH LAB. The RCP segment specifies that the number of matches should be limited to 20. Here is a sample response:
MSH|^&~\|HOSPMPI|HOSP|CLINREG|WESTCLIN|199912121135-0600||RSP^K22^RSP_K21|1|D|2.5|
MSA|AA|8699|
QAK|111069|OK|Q22^Find Candidates^HL7nnnn|3|
QPD|Q22^Find Candidates^HL7nnn|111069|@PID.5.1^SMITH~ @PID.5.2^JOHN~@PID.8^M|80|MATCHWARE|1.2||^^^METRO HOSPITAL~^^^SOUTH LAB|
PID|||66785^^^METRO HOSPITAL~66532^^^SOUTH LAB||Smith^John||19630423|M||C|N2378 South Street^^Madison^WI^53711|
QRI|95||MATCHWARE 1.2|
PID|||87443^^^METRO HOSPITAL~651189^^^SOUTH LAB||Smith^Jon||19470606|M||C|124 Second Street^^Madison^WI^53711|
QRI|90||MATCHWARE 1.2|
PID|||43266^^^METRO HOSPITAL~81209^^^SOUTH LAB||Smithy^John||19901210|M||C|W11234 Bay Drive^^Lodi^WI^53555|
QRI|85||MATCHWARE 1.2|
Three candidates were returned. Notice the 3 at the end of the QAK segment signifying the number of matches. Each has a PID and QRI segment, and the QRI segment in each case gives a confidence factor for each of the candidates
This query/response is designed for interaction between a client system and an MPI (Master Person Index). The query consists of an identifier for a person, and the response is a list of identifiers for that person from the domains specified.
Query ID | Q23 |
Query Type | Query |
Query Name | Q23 Get Corresponding Identifiers |
Query Trigger | QBP^Q23^QBP_Q21 |
|
|
Response Trigger | RSP^K23^RSP_K23 |
Query Characteristics |
|
Query Purpose | Returns list of identifiers from the specified domains, given an identifier from a given domain. |
QBP^Q23^QBP_Q21 | Query By Parameter | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
|
|
|
|
|
QPD | Query Parameter Definition Segment |
| 5 | DB |
RCP | Response Control Parameters |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
RSP^K23^RSP_K23 | Segment Pattern Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgement |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgement |
| 5 | DB |
QPD | Query Parameter Definition Segment |
| 5 | DB |
[ | --- QUERY_RESPONSE begin |
|
|
|
PID | Patient Identification |
| 3 | DB |
] | --- QUERY_RESPONSE end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2 | DB |
Field Seq. | Field Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | LOINC or HL7 Code/Domain | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | PersonIdentifier | S | Y | 20 | CX | R | N |
|
| PID-3 |
| Patient Identifier List |
2 | WhatDomainsReturned |
|
|
| CX | O | Y |
|
| PID-3 |
| Patient Identifier List |
Input Parameter | Comp. Name | DT | Description |
---|---|---|---|
PersonIdentifier |
| CX |
Components: ^ < assigning authority (HD)> ^ |
|
|
| The combination of values for PersonIdentifier.ID, and PersonIdentifier.AssigningAuthority, are intended to identify a person uniquely. The PersonIdentifier.IDTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. |
|
|
| Example: ...|112234^^^METRO HOSPITAL|... |
|
|
| Only one PID.3 may be specified, only 1 segment pattern will be returned. |
|
|
|
|
PersonIdentifier | ID |
| PID.3.1must be valued. |
PersonIdentifier | Assigning Authority |
| PID.3.4 must be valued. |
PersonIdentifier | Identifier type code |
|
|
WhatDomainsReturned |
| CX |
Components: ^ < assigning authority (HD)> ^ |
|
|
| This parameter restricts the set of domains for which identifiers are returned in PID-3. If this is not specified, then identifiers for all known domains shall be returned. It does not restrict the search for the person. |
|
|
| Example: |^^^METRO HOSPITAL~^^^SOUTH LAB| |
|
|
| Only the following components should be valued. |
WhatDomainsReturned | Assigning Authority |
| PID.3.4 must be valued. |
WhatDomainsReturned. | Identifier type code |
|
|
Following is an example of a Q23/K23 query/response pair of messages. First is the query:
MSH|^&~\|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q23^QBP_Q21|1|D|2.5
QPD|Q23^Get Corresponding IDs^HL7nnnn|111069|112234^^^METRO HOSPITAL|^^^WEST CLINIC~^^^SOUTH LAB|
RCP||I|
SEC|0614
This query is asking for identifiers from WEST CLINIC and SOUTH LAB for the person identified with the identifier 112234 from the assigning authority METRO HOSPITAL. Here is a sample response:
MSH|^&~\|HOSPMPI|HOSP|CLINREG|WESTCLIN|199912121135-0600||RSP^K23^RSP_K23|1|D|2.5|
MSA|AA|8699|
QAK|111069|OK|Q23^Get Corresponding IDs^HL7nnnn|1|
QPD|Q23^Get Corresponding IDs^HL7nnn|111069|112234^^^METRO HOSPITAL|^^^WEST CLINIC~^^^SOUTH LAB|
PID|||56321A^^^WEST CLINIC~66532^^^SOUTH LAB||Smith^John||19630423|M||C|N2378 South Street^^Madison^WI^53711|
Note that the identifiers returned do not include the METRO HOSPITAL identifier, as it was not specified in the list of WhatDomainsReturned.
This query/response is designed for interaction between a client system and an MPI (Master Person Index). The query consists of domains in which identifiers should be allocated. The response is new identifiers in those domains.
This event is not meant to cause the creation of a new person record, or to bind identifiers to a particular person record. The events A28 - Add person information and A24 - Link patient information should be used for that purpose. This event is meant to simply reserve the use of identifiers.
Query ID | Q24 |
Query | |
---|---|
Query Name | Allocate Identifiers |
Query Trigger | QBP^Q24^QBP_Q21 |
|
|
Response Trigger | RSP^K24^RSP_K23 |
Query Characteristics |
|
Query Purpose | Request that an MPI allocate an identifier for a given domain. |
QBP^Q24^QBP_Q21 | Query By Parameter | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
|
|
|
|
|
QPD | Query Parameter Definition Segment |
| 5 | DB |
RCP | Response Control Parameters |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
RSP^K24^RSP_K23 | Segment Pattern Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgement |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgement |
| 5 | DB |
QPD | Query Parameter Definition Segment |
| 5 | DB |
[ | --- QUERY_RESPONSE begin |
|
|
|
PID | Patient Identification |
| 3 | DB |
] | --- QUERY_RESPONSE end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2 | DB |
Field Seq. | Field Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | LOINC or HL7 Code/Domain | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | DomainToAllocateIn |
|
|
| CX | R | Y |
|
| PID-3 |
| Patient Identifier |
Input Parameter | Comp. Name | DT | Description |
---|---|---|---|
DomainToAllocateIn () |
| CX |
Components: ^ < assigning authority (HD)> ^ |
|
|
| This parameter specifies in which domains to allocate identifiers. |
|
|
| Example: ...|^^^METRO HOSPITAL|... |
|
|
| Only the following components should be valued. |
DomainToAllocateIn | Assigning Authority |
| PID.3.4 must be valued. |
DomainToAllocateIn | Identifier type code |
|
|
Following is an example of a Q24/K24 query/response pair of messages. First is the query:
MSH|^&~\|CLINREG|WESTCLIN|HOSPMPI|HOSP|199912121135-0600||QBP^Q24^QBP_Q21|1|D|2.5
QPD|Q24^Allocate Identifiers^HL7nnnn|111069|^^^WEST CLINIC~^^^SOUTH LAB|
RCP||I|
SEC|0614
This query is asking for identifiers from WEST CLINIC and SOUTH LAB to be reserved and returned. Here is a sample response:
MSH|^&~\|HOSPMPI|HOSP|CLINREG|WESTCLIN|199912121135-0600||RSP^K24^RSP_K23|1|D|2.5|
MSA|AA|8699|
QAK|111069|OK|Q24^Allocate Identifiers^HL7nnnn|1|
QPD|A56^Allocate Identifiers^HL7nnn|111069|^^^WEST CLINIC~^^^SOUTH LAB|
PID|||624335A^^^WEST CLINIC~564325^^^SOUTH LAB|
Note that the PID segment returned does not include any person demographics as the identifiers are not yet _attached_ to any person record. Presumably the querying system would eventually send back to the MPI an A28 Add person information to create a person record for the identifiers or an A24 Link patient information to link the identifiers to an existing person record.
This trigger event is used when person/patient allergy information has changed. It is used in conjunction with a new allergy segment, the IAM - Patient Allergy Information Segment-Unique Identifier, which supports Action code/unique identifier mode update for repeating segments as defined in 2.14.4 Modes for updating via repeating segments.
ADT^A60^ADT_A60 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PV1 ] | Patient Visit |
| 3 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
[ { IAM } ] | Patient adverse reaction information |
| 3 | DB |
ACK^A60^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A61^ADT_A61 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
ACK^A61^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
ADT^A62^ADT_A61 | ADT Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EVN | Event Type |
| 3 | DB |
PID | Patient Identification |
| 3 | DB |
[ PD1 ] | Additional Demographics |
| 3 | DB |
PV1 | Patient Visit |
| 3 | DB |
[ { ROL } ] | Role |
| 15 | DB |
[ PV2 ] | Patient Visit - Additional Info. |
| 3 | DB |
ACK^A62^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
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.
HL7 Attribute Table - EVN _ Event Type
3.4 MESSAGE SEGMENTS
3.4.1 EVN - Event Type Segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 3 | ID | B |
| 0003 | 00099 | Event Type Code | DB |
2 | 26 | TS | R |
|
| 00100 | Recorded Date/Time | DB |
3 | 26 | TS | O |
|
| 00101 | Date/Time Planned Event | DB |
4 | 3 | IS | O |
| 0062 | 00102 | Event Reason Code | DB |
5 | 250 | XCN | O | Y | 0188 | 00103 | Operator ID | DB |
6 | 26 | TS | O |
|
| 01278 | Event Occurred | DB |
7 | 241 | HD | O |
|
| 01534 | Event Facility | DB |
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 HL7 Table 0003 - Event type for valid values.
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: Most systems will default to the system date/time when the transaction was entered, but they should also permit an override.
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: This field contains the date/time that the event is planned. We recommend that PV2-8 - Expected Admit Date/Time, PV2-9 - Expected Discharge Date/Time or PV2-47 - Expected LOA Return date/time be used whenever possible.
Definition: This field contains the reason for this event. Refer to User-defined Table 0062 - Event Reason for suggested values.
User-defined Table 0062 - Event reason
3.4.1.0 EVN field definitions
3.4.1.1 EVN-1 Event Type Code (ID) 00099
3.4.1.2 EVN-2 Recorded Date/Time (TS) 00100
3.4.1.3 EVN-3 Date/Time Planned Event (TS) 00101
3.4.1.4 EVN-4 Event Reason Code (IS) 00102
Value | Description | Comment |
---|---|---|
01 | Patient request |
|
02 | Physician/health practitioner order |
|
03 | Census management |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
O | Other |
|
U | Unknown |
|
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ < Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field identifies the individual responsible for triggering the event. Refer to User-defined Table 0188 - Operator ID for suggested values.
User-defined Table 0188 - Operator ID
3.4.1.5 EVN-5 Operator ID (XCN) 00103
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
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 cancelled occurred.
Components: <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>
Definition: This field identifies the actual facility where the event occurred as differentiated from the sending facility (MSH-4). It would be the facility at which the Operator (EVN-5) has entered the event.
Use Case: System A is where the patient is originally registered. This registration message is sent to an MPI, System B. The MPI needs to broadcast the event of this update and would become the sending facility. This new field would allow for retention of knowledge of the originating facility where the event occurred. The MPI could be the assigning authority for the ID number as well which means that it is performing the function of assigning authority for the facility originating the event.
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.
It should be noted that from V2.4 onwards the demographics of animals can also be sent in the PID segment (see PID-35 to PID-38).
The assigning authority, the fourth component of the patient identifiers, is a HD data type that is uniquely associated with the assigning authority that originally assigned the number. A given institution, or group of intercommunicating institutions, should establish a list of assigning authorities 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 authority in the patient identification numbers may not be the same as the sending and receiving systems identified in the MSH. The assigning authority 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. The assigning authority and identifier type codes are strongly recommended for all CX data types.
With HL7 V2.3, the nomenclature for the fourth component of the patient identifiers was changed from _assigning facility ID_ to _assigning authority_. While the identifier may be unique to a given healthcare facility (for example, a medical record assigned by facility A in Hospital XYZ), the identifier might also be assigned at a system level (for example a corporate person index or enterprise number spanning multiple facilities) or by a government entity, for example a nationally assigned unique individual identifier. While a facility is usually an assigning authority, not all assigning authorities are facilities. Therefore, the fourth component is referred to as an assigning authority, but retains backward compatibility using the construct of the HD data type (see the note in chapter 2). Additionally, CX data types support the use of assigning facility (HD) as the sixth component.
HL7 Attribute Table - PID - Patient Identification
3.4.1.6 EVN-6 Event Occurred (TS) 01278
3.4.1.7 EVN-7 Event Facility (HD) 01534
3.4.2 PID - Patient Identification Segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 4 | SI | O |
|
| 00104 | Set ID - PID | DB |
2 | 20 | CX | B |
|
| 00105 | Patient ID | DB |
3 | 250 | CX | R | Y |
| 00106 | Patient Identifier List | DB |
4 | 20 | CX | B | Y |
| 00107 | Alternate Patient ID - PID | DB |
5 | 250 | XPN | R | Y |
| 00108 | Patient Name | DB |
6 | 250 | XPN | O | Y |
| 00109 | Mother_s Maiden Name | DB |
7 | 26 | TS | O |
|
| 00110 | Date/Time of Birth | DB |
8 | 1 | IS | O |
| 0001 | 00111 | Administrative Sex | DB |
9 | 250 | XPN | B | Y |
| 00112 | Patient Alias | DB |
10 | 250 | CE | O | Y | 0005 | 00113 | Race | DB |
11 | 250 | XAD | O | Y |
| 00114 | Patient Address | DB |
12 | 4 | IS | B |
| 0289 | 00115 | County Code | DB |
13 | 250 | XTN | O | Y |
| 00116 | Phone Number - Home | DB |
14 | 250 | XTN | O | Y |
| 00117 | Phone Number - Business | DB |
15 | 250 | CE | O |
| 0296 | 00118 | Primary Language | DB |
16 | 250 | CE | O |
| 0002 | 00119 | Marital Status | DB |
17 | 250 | CE | O |
| 0006 | 00120 | Religion | DB |
18 | 250 | CX | O |
|
| 00121 | Patient Account Number | DB |
19 | 16 | ST | B |
|
| 00122 | SSN Number - Patient | DB |
20 | 25 | DLN | B |
|
| 00123 | Driver's License Number - Patient | DB |
21 | 250 | CX | O | Y |
| 00124 | Mother's Identifier | DB |
22 | 250 | CE | O | Y | 0189 | 00125 | Ethnic Group | DB |
23 | 250 | ST | O |
|
| 00126 | Birth Place | DB |
24 | 1 | ID | O |
| 0136 | 00127 | Multiple Birth Indicator | DB |
25 | 2 | NM | O |
|
| 00128 | Birth Order | DB |
26 | 250 | CE | O | Y | 0171 | 00129 | Citizenship | DB |
27 | 250 | CE | O |
| 0172 | 00130 | Veterans Military Status | DB |
28 | 250 | CE | B |
| 0212 | 00739 | Nationality | DB |
29 | 26 | TS | O |
|
| 00740 | Patient Death Date and Time | DB |
30 | 1 | ID | O |
| 0136 | 00741 | Patient Death Indicator | DB |
31 | 1 | ID | O |
| 0136 | 01535 | Identity Unknown Indicator | DB |
32 | 20 | IS | O | Y | 0445 | 01536 | Identity Reliability Code | DB |
33 | 26 | TS | O |
|
| 01537 | Last Update Date/Time | DB |
34 | 241 | HD | O |
|
| 01538 | Last Update Facility | DB |
35 | 250 | CE | C |
| 0446 | 01539 | Species Code | DB |
36 | 250 | CE | C |
| 0447 | 01540 | Breed Code | DB |
37 | 80 | ST | O |
|
| 01541 | Strain | DB |
38 | 250 | CE | O | 2 | 0429 | 01542 | Production Class Code | DB |
39 | 250 | CWE | O | Y | 0171 | 01840 | Tribal Citizenship | DB |
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.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field has been retained for backward compatibility only. The arbitrary term of _external ID_ has been removed from the name of this field. The repetition, assigning authority, healthcare facility, and identifier type code attributes of PID-3 - Patient Identifier List allow for distinctive identifier representation. This field remains for systems with a negotiated understanding of _external._ It is recommended to use PID-3 - Patient Identifier List for all patient identifiers.
When used for backward compatibility, this field is valued when the patient is from another institution, outside office, etc., and 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.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field contains the list of identifiers (one or more) used by the healthcare facility to uniquely identify a patient (e.g., medical record number, billing number, birth registry, national unique individual identifier, etc.). In Canada, the Canadian Provincial Healthcare Number should be sent in this field. The arbitrary term of _internal ID_ has been removed from the name of this field for clarity.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: From V2.3.1, this field has been retained for backward compatibility only. It is recommended to use PID-3 - Patient Identifier List for all patient identifiers. When used for backward compatibility, 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.
Components: <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Name Type Code (ID)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Definition: This field contains the names of the patient, the primary or legal name of the patient is reported first. Therefore, the name type code in this field should be _L - Legal_. Refer to HL7 Table 0200 - Name Type for valid values. Repetition of this field is allowed for representing the same name in different character sets. Note that _last name prefix_ is synonymous to _own family name prefix_ of previous versions of HL7, as is _second and further given names or initials thereof_ to _middle initial or name_. Multiple given names and/or initials are separated by spaces.
HL7 Table 0200 - Name Type
3.4.2.0 PID field definitions
3.4.2.1 PID-1 Set ID - PID (SI) 00104
3.4.2.2 PID-2 Patient ID (CX) 00105
3.4.2.3 PID-3 Patient Identifier List (CX) 00106
3.4.2.4 PID-4 Alternate Patient ID - PID (CX) 00107
3.4.2.5 PID-5 Patient Name (XPN) 00108
Value | Description | Comment |
---|---|---|
A | Alias Name |
|
B | Name at Birth |
|
C | Adopted Name |
|
D | Display Name |
|
I | Licensing Name |
|
L | Legal Name |
|
M | Maiden Name |
|
N | Nickname /_Call me_ Name/Street Name |
|
P | Name of Partner/Spouse - obsolete | Deprecated in V2.4 |
R | Registered Name (animals only) |
|
S | Coded Pseudo-Name to ensure anonymity |
|
T | Indigenous/Tribal/Community Name |
|
U | Unspecified |
|
For animals, if a Name Type of _R_ is used, use _Name Context_ to identify the authority with which the animal_s name is registered.
Components: <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Name Type Code (ID)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (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.
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: This field contains the patient_s date and time of birth.
Definition: This field contains the patient_s sex. Refer to User-defined Table 0001 - Administrative Sex for suggested values.
User-defined Table 0001 - Administrative Sex
Value | Description | Comment |
---|---|---|
F | Female |
|
M | Male |
|
O | Other |
|
U | Unknown |
|
A | Ambiguous |
|
N | Not applicable |
|
Components: <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Name Type Code (ID)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Definition: From V2.4, this field has been retained for backward compatibility only. It is recommended to use PID-5 - Patient Name for all patient names. This field contained the name(s) by which the patient has been known at some time. Refer to HL7 Table 0200 - Name Type for valid values.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field refers to the patient_s race. Refer to User-defined Table 0005 - Race for suggested values. The second triplet of the CE data type for race (alternate identifier, alternate text, and name of alternate coding system) is reserved for governmentally assigned codes.
User-defined Table 0005 - Race
3.4.2.9 PID-9 Patient Alias (XPN) 00112
3.4.2.10 PID-10 Race (CE) 00113
Value | Description | Comment |
---|---|---|
1002-5 | American Indian or Alaska Native |
|
2028-9 | Asian |
|
2054-5 | Black or African American |
|
2076-8 | Native Hawaiian or Other Pacific Islander |
|
2106-3 | White |
|
2131-1 | Other Race |
|
Note: The above values contain a pre-calculated Mod 10 check digit separated by a dash.
Components: <Street Address (SAD)> ^ <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)> ^ <Address Representation Code (ID)> ^ <Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>
Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>
Subcomponents for Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Definition: This field contains the mailing address of the patient. Address type codes are defined by HL7 Table 0190 - Address Type. 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.
Definition: From V2.3, 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
Components: <Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^ <Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)> ^ <Area/City Code (NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^ <Extension Prefix (ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (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 Table 0201 - Telecommunication Use Code and HL7 Table 0202 - Telecommunication Equipment Type for valid values.
Components: <Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^ <Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)> ^ <Area/City Code (NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^ <Extension Prefix (ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (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 Table 0201 - Telecommunication Use Code and HL7 Table 0202 - Telecommunication Equipment Type for valid values.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the patient_s primary language. HL7 recommends using ISO table 639 as the suggested values in User-defined Table 0296 - Primary Language.
User-defined Table 0296 - Primary Language
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the patient_s marital (civil) status. Refer to User-defined Table 0002 - Marital Status for suggested values.
User-defined Table 0002 - Marital Status
3.4.2.16 PID-16 Marital Status (CE) 00119
Value | Description | Comment |
---|---|---|
A | Separated |
|
D | Divorced |
|
M | Married |
|
S | Single |
|
W | Widowed |
|
C | Common law |
|
G | Living together |
|
P | Domestic partner |
|
R | Registered domestic partner |
|
E | Legally Separated |
|
N | Annulled |
|
I | Interlocutory |
|
B | Unmarried |
|
U | Unknown |
|
O | Other |
|
T | Unreported |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the patient_s religion. Refer to User-defined Table 0006 - Religion for suggested values.
User-defined Table 0006 - Religion
3.4.2.17 PID-17 Religion (CE) 00120
Value | Description | Comment |
---|---|---|
AGN | Agnostic |
|
ATH | Atheist |
|
BAH | Baha'i |
|
BUD | Buddhist |
|
BMA | Buddhist: Mahayana |
|
BTH | Buddhist: Theravada |
|
BTA | Buddhist: Tantrayana |
|
BOT | Buddhist: Other |
|
CFR | Chinese Folk Religionist |
|
CHR | Christian |
|
ABC | Christian: American Baptist Church |
|
AMT | Christian: African Methodist Episcopal |
|
AME | Christian: African Methodist Episcopal Zion |
|
ANG | Christian: Anglican |
|
AOG | Christian: Assembly of God |
|
BAP | Christian: Baptist |
|
CAT | Christian: Roman Catholic |
|
CRR | Christian: Christian Reformed |
|
CHS | Christian: Christian Science |
|
CMA | Christian: Christian Missionary Alliance |
|
COC | Christian: Church of Christ |
|
COG | Christian: Church of God |
|
COI | Christian: Church of God in Christ |
|
COM | Christian: Community |
|
COL | Christian: Congregational |
|
EOT | Christian: Eastern Orthodox |
|
EVC | Christian: Evangelical Church |
|
EPI | Christian: Episcopalian |
|
FWB | Christian: Free Will Baptist |
|
FRQ | Christian: Friends |
|
GRE | Christian: Greek Orthodox |
|
JWN | Christian: Jehovah's Witness |
|
LUT | Christian: Lutheran |
|
LMS | Christian: Lutheran Missouri Synod |
|
MEN | Christian: Mennonite |
|
MET | Christian: Methodist |
|
MOM | Christian: Latter-day Saints |
|
NAZ | Christian: Church of the Nazarene |
|
ORT | Christian: Orthodox |
|
COT | Christian: Other |
|
PRC | Christian: Other Protestant |
|
PEN | Christian: Pentecostal |
|
COP | Christian: Other Pentecostal |
|
PRE | Christian: Presbyterian |
|
PRO | Christian: Protestant |
|
QUA | Christian: Friends |
|
REC | Christian: Reformed Church |
|
REO | Christian: Reorganized Church of Jesus Christ-LDS |
|
SAA | Christian: Salvation Army |
|
SEV | Christian: Seventh Day Adventist |
|
SOU | Christian: Southern Baptist |
|
UCC | Christian: United Church of Christ |
|
UMD | Christian: United Methodist |
|
UNI | Christian: Unitarian |
|
UNU | Christian: Unitarian Universalist |
|
WES | Christian: Wesleyan |
|
WMC | Christian: Wesleyan Methodist |
|
CNF | Confucian |
|
ERL | Ethnic Religionist |
|
HIN | Hindu |
|
HVA | Hindu: Vaishnavites |
|
HSH | Hindu: Shaivites |
|
HOT | Hindu: Other |
|
JAI | Jain |
|
JEW | Jewish |
|
JCO | Jewish: Conservative |
|
JOR | Jewish: Orthodox |
|
JOT | Jewish: Other |
|
JRC | Jewish: Reconstructionist |
|
JRF | Jewish: Reform |
|
JRN | Jewish: Renewal |
|
MOS | Muslim |
|
MSU | Muslim: Sunni |
|
MSH | Muslim: Shiite |
|
MOT | Muslim: Other |
|
NAM | Native American |
|
NRL | New Religionist |
|
NOE | Nonreligious |
|
OTH | Other |
|
SHN | Shintoist |
|
SIK | Sikh |
|
SPI | Spiritist |
|
VAR | Unknown |
|
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
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 for valid values.
Definition: From V2.3.1 onward, this field has been retained for backward compatibility only. It is recommended to use PID-3 - Patient Identifier List for all patient identifiers. However, in order to maintain backward compatibility, this field should also be populated. When used for backward compatibility, this field contains the patient_s social security number. This number may also be a RR retirement number.
Components: <License Number (ST)> ^ <Issuing State, Province, Country (IS)> ^ <Expiration Date (DT)>
Definition: From V2.5 onward, this field has been retained for backward compatibility only. It is recommended to use PID-3 - Patient Identifier List for all patient identifiers. When used for backward compatibility, this field contains the patient_s driver_s license number. The default of the second component is the state in which the patient_s license is registered.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
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 for valid values.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field further defines the patient_s ancestry. Refer to User-defined Table 0189 - Ethnic Group for suggested values. The second triplet of the CE data type for ethnic group (alternate identifier, alternate text, and name of alternate coding system) is reserved for governmentally assigned codes. In the US, a current use is to report ethnicity in line with US federal standards for Hispanic origin.
User-defined Table 0189 - Ethnic Group
3.4.2.18 PID-18 Patient Account Number (CX) 00121
3.4.2.19 PID-19 SSN Number - Patient (ST) 00122
3.4.2.20 PID-20 Driver's License Number - Patient (DLN) 00123
3.4.2.21 PID-21 Mother's Identifier (CX) 00124
3.4.2.22 PID-22 Ethnic Group (CE) 00125
Value | Description | Comment |
---|---|---|
H | Hispanic or Latino |
|
N | Not Hispanic or Latino |
|
U | Unknown |
|
Definition: This field indicates the location of the patient_s birth, for example _St. Francis Community Hospital of Lower South Side_. The actual address is reported in PID-11 with an identifier of _N_.
Definition: This field indicates whether the patient was part of a multiple birth. Refer to HL7 Table 0136 - Yes/No Indicator for valid values.
Y the patient was part of a multiple birth
N the patient was a single birth
Definition: When a patient was part of a multiple birth, a value (number) indicating the patient_s birth order is entered in this field.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
This field contains the information related to a person's country citizenship. For country citizenship HL7 recommends using ISO table 3166. For a local definition, User-defined Table 0171 - Citizenship should be used.
This field repeats since persons can be citizens of more than one country. The Name of Coding System component(s) of the CE datatype should be used to identify the table from which citizenship membership is drawn.
In the Netherlands, this field is used for "Nationaliteit".
User-defined Table 0171 - Citizenship
3.4.2.23 PID-23 Birth Place (ST) 00126
3.4.2.24 PID-24 Multiple Birth Indicator (ID) 00127
3.4.2.25 PID-25 Birth Order (NM) 00128
3.4.2.26 PID-26 Citizenship (CE) 00129
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the military status assigned to a veteran. Refer to User-defined Table 0172 - Veterans Military Status for suggested values.
User-defined Table 0172 - Veterans Military Status
3.4.2.27 PID-27 Veterans Military Status (CE) 00130
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: From V2.4 onward, this field has been retained for backward compatibility only. It is recommended to refer to PID-10 - Race, PID-22 - Ethnic group and PID-26 - Citizenship. This field contains a code that identifies the nation or national grouping to which the 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.).
User-defined Table 0212 - Nationality
3.4.2.28 PID-28 Nationality (CE) 00739
Value | Description | Comment |
---|---|---|
| No suggested values defined |
|
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: This field contains the date and time at which the patient death occurred.
Definition: This field indicates whether the patient is deceased. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y the patient is deceased
N the patient is not deceased
Definition: This field indicates whether or not the patient_s/person_s identity is known. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y the patient_s/person_s identity is unknown
N the patient_s/person_s identity is known
Definition: This field contains a coded value used to communicate information regarding the reliability of patient/person identifying data transmitted via a transaction. Values could indicate that certain fields on a PID segment for a given patient/person are known to be false (e.g., use of default or system-generated values for Date of Birth or Social Security Number. Refer to User-defined Table 0445 - Identity Reliability Code for suggested values.
User-defined Table 0445 - Identity Reliability Code
3.4.2.29 PID-29 Patient Death Date and Time (TS) 00740
3.4.2.30 PID-30 Patient Death Indicator (ID) 00741
3.4.2.31 PID-31 Identity Unknown Indicator (ID) 01535
3.4.2.32 PID-32 Identity Reliability Code (IS) 01536
Value | Description | Comment |
---|---|---|
US | Unknown/Default Social Security Number |
|
UD | Unknown/Default Date of Birth |
|
UA | Unknown/Default Address |
|
AL | Patient/Person Name is an Alias |
|
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: This field contains the last update date and time for the patient_s/person_s identifying and demographic data, as defined in the PID segment. Receiving systems will use this field to determine how to apply the transaction to their systems. If the receiving system (such as an enterprise master patient index) already has a record for the person with a later last update date/time, then the EMPI could decide not to apply the patient_s/person_s demographic and identifying data from this transaction.
Components: <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>
Definition: This field identifies the facility of the last update to a patient_s/person_s identifying and demographic data, as defined in the PID segment. Receiving systems or users will use this field to determine how to apply the transaction to their systems. If the receiving system (such as a hospital_s patient management system) already has a record for the patient/person, then it may decide to only update its data if the source is a _trusted_ source. A hospital might consider other hospitals trusted sources, but not _trust_ updates from non-acute care facilities. For example:
...|Metro Hospital|...
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: The species of living organism. This may include the common or scientific name, based on the coding system(s) used. SNOMED is the recommended coding system. If this field is not valued, a human is assumed. Refer to User-defined Table 0446 - Species Code for suggested values.
User-defined Table 0446 - Species Code
3.4.2.33 PID-33 Last Update Date/Time (TS) 01537
3.4.2.34 PID-34 Last Update Facility (HD) 01538
3.4.2.35 PID-35 Species Code (CE) 01539
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Conditionality Rule: This field must be valued if PID-36 - Breed Code or PID-38 - Production Class Code is valued.
For example:
...|L-80700^Canine, NOS^SNM3|...
...|L-80100^Bovine^SNM3|...
...|L-80A00^Feline^SNM3|...
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: The specific breed of animal. This field, unlike Species and Strain is specific to animals and cannot be generally used for all living organisms. SNOMED is the recommended coding system. Refer to User-defined Table 0447 - Breed Code for suggested values.
User-defined Table 0447 - Breed Code
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Conditionality Rule: This field must be valued if PID-37 - Strain is valued.
For example, (showing primary and alternative coding systems, using locally defined _American Kennel Club_ nomenclature):
...|L-80733^ Staffordshire bull terrier^SNM3^^American Staffordshire Terrier^99AKC|...
...|L-80900^Weimaraner^SNM3|...
...|L-80439^Peruvian Paso Horse^SNM3|...
Definition: This field contains the specific strain of animal. It can also be expanded to include strain of any living organism and is not restricted to animals.
Example:
...|DeKalb|...
...|Balb/c|...
...|DXL|...
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the code and/or text indicating the primary use for which the living subject was bred or grown. Refer to User-defined Table 0429 - Production Class Code for suggested values. For example:
...|DA^Dairy^L|...
...|MT^Meat^L|...
...|RA^Racing^L|...
User-defined Table 0429 - Production Class Code
Value | Description | Comment |
---|---|---|
BR | Breeding/genetic stock |
|
DA | Dairy |
|
DR | Draft |
|
DU | Dual Purpose |
|
LY | Layer, Includes Multiplier flocks |
|
MT | Meat |
|
OT | Other |
|
PL | Pleasure |
|
RA | Racing |
|
SH | Show |
|
NA | Not Applicable |
|
U | Unknown |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>
This field contains the information related to a person's tribal citizenship. For tribal citizenship, in the United States, HL7 recommends using the Bureau of Indian Affairs (BIA) Tribal Identity List. For a local definition, User-defined Table 0171 - Citizenship should be used.
This field repeats since persons can have tribal membership(s) and can be members of more than one tribe. The Name of Coding System component(s) of the CWE datatype should be used to identify the table from which tribal membership is drawn.
The PV1 segment is used by Registration/Patient Administration applications to communicate information on an account or visit-specific basis. The default is to send account level data. To use this segment for visit level data PV1-51 - Visit Indicator must be valued to _V_. The value of PV-51 affects the level of data being sent on the PV1, PV2, and any other segments that are part of the associated PV1 hierarchy (e.g. ROL, DG1, or OBX).
The facility ID, the optional fourth component of each patient location field, is a HD data type that is uniquely associated with the healthcare 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 healthcare facility with bed locations, since the same <point of care> ^ <room> ^ <bed> combination may exist at more than one facility.
HL7 Attribute Table - PV1 - Patient Visit
3.4.2.39 PID-39 Tribal Citizenship (CWE) 01840
3.4.3 PV1 - Patient Visit Segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 4 | SI | O |
|
| 00131 | Set ID - PV1 | DB |
2 | 1 | IS | R |
| 0004 | 00132 | Patient Class | DB |
3 | 80 | PL | O |
|
| 00133 | Assigned Patient Location | DB |
4 | 2 | IS | O |
| 0007 | 00134 | Admission Type | DB |
5 | 250 | CX | O |
|
| 00135 | Preadmit Number | DB |
6 | 80 | PL | O |
|
| 00136 | Prior Patient Location | DB |
7 | 250 | XCN | O | Y | 0010 | 00137 | Attending Doctor | DB |
8 | 250 | XCN | O | Y | 0010 | 00138 | Referring Doctor | DB |
9 | 250 | XCN | B | Y | 0010 | 00139 | Consulting Doctor | DB |
10 | 3 | IS | O |
| 0069 | 00140 | Hospital Service | DB |
11 | 80 | PL | O |
|
| 00141 | Temporary Location | DB |
12 | 2 | IS | O |
| 0087 | 00142 | Preadmit Test Indicator | DB |
13 | 2 | IS | O |
| 0092 | 00143 | Re-admission Indicator | DB |
14 | 6 | IS | O |
| 0023 | 00144 | Admit Source | DB |
15 | 2 | IS | O | Y | 0009 | 00145 | Ambulatory Status | DB |
16 | 2 | IS | O |
| 0099 | 00146 | VIP Indicator | DB |
17 | 250 | XCN | O | Y | 0010 | 00147 | Admitting Doctor | DB |
18 | 2 | IS | O |
| 0018 | 00148 | Patient Type | DB |
19 | 250 | CX | O |
|
| 00149 | Visit Number | DB |
20 | 50 | FC | O | Y | 0064 | 00150 | Financial Class | DB |
21 | 2 | IS | O |
| 0032 | 00151 | Charge Price Indicator | DB |
22 | 2 | IS | O |
| 0045 | 00152 | Courtesy Code | DB |
23 | 2 | IS | O |
| 0046 | 00153 | Credit Rating | DB |
24 | 2 | IS | O | Y | 0044 | 00154 | Contract Code | DB |
25 | 8 | DT | O | Y |
| 00155 | Contract Effective Date | DB |
26 | 12 | NM | O | Y |
| 00156 | Contract Amount | DB |
27 | 3 | NM | O | Y |
| 00157 | Contract Period | DB |
28 | 2 | IS | O |
| 0073 | 00158 | Interest Code | DB |
29 | 4 | IS | O |
| 0110 | 00159 | Transfer to Bad Debt Code | DB |
30 | 8 | DT | O |
|
| 00160 | Transfer to Bad Debt Date | DB |
31 | 10 | IS | O |
| 0021 | 00161 | Bad Debt Agency Code | DB |
32 | 12 | NM | O |
|
| 00162 | Bad Debt Transfer Amount | DB |
33 | 12 | NM | O |
|
| 00163 | Bad Debt Recovery Amount | DB |
34 | 1 | IS | O |
| 0111 | 00164 | Delete Account Indicator | DB |
35 | 8 | DT | O |
|
| 00165 | Delete Account Date | DB |
36 | 3 | IS | O |
| 0112 | 00166 | Discharge Disposition | DB |
37 | 47 | DLD | O |
| 0113 | 00167 | Discharged to Location | DB |
38 | 250 | CE | O |
| 0114 | 00168 | Diet Type | DB |
39 | 2 | IS | O |
| 0115 | 00169 | Servicing Facility | DB |
40 | 1 | IS | B |
| 0116 | 00170 | Bed Status | DB |
41 | 2 | IS | O |
| 0117 | 00171 | Account Status | DB |
42 | 80 | PL | O |
|
| 00172 | Pending Location | DB |
43 | 80 | PL | O |
|
| 00173 | Prior Temporary Location | DB |
44 | 26 | TS | O |
|
| 00174 | Admit Date/Time | DB |
45 | 26 | TS | O | Y |
| 00175 | Discharge Date/Time | DB |
46 | 12 | NM | O |
|
| 00176 | Current Patient Balance | DB |
47 | 12 | NM | O |
|
| 00177 | Total Charges | DB |
48 | 12 | NM | O |
|
| 00178 | Total Adjustments | DB |
49 | 12 | NM | O |
|
| 00179 | Total Payments | DB |
50 | 250 | CX | O |
| 0203 | 00180 | Alternate Visit ID | DB |
51 | 1 | IS | O |
| 0326 | 01226 | Visit Indicator | DB |
52 | 250 | XCN | B | Y | 0010 | 01274 | Other Healthcare Provider | DB |
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.
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.
User-defined Table 0004 - Patient Class
3.4.3.0 PV1 field definitions
3.4.3.1 PV1-1 Set ID - PV1 (SI) 00131
3.4.3.2 PV1-2 Patient Class (IS) 00132
Value | Description | Comment |
---|---|---|
E | Emergency |
|
I | Inpatient |
|
O | Outpatient |
|
P | Preadmit |
|
R | Recurring patient |
|
B | Obstetrics |
|
C | Commercial Account |
|
N | Not Applicable |
|
U | Unknown |
|
_Commercial Account_ is used by reference labs for specimen processing when the service is billed back to a third party. A registration is processed for the specimen to facilitate the subsequent billing. The identity of the patient may be known or unknown. In either case, for billing and statistical purposes, the patient class is considered a commercial account due to the third party billing responsibility.
_Not Applicable_ is used only in cases where the PV1 segment itself is not applicable but is retained in the message definitions for backwards compatibility (for example when a managed care system sends A28, A29, or A31 messages to indicate the enrolment of a patient in the system and there is no scheduled "visit" or "encounter" and hence the entire PV1 segment is not applicable).
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)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>
Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Authority for Location (HD): <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 or department, 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 (location status), it supersedes the value in PV1-40 - Bed Status.
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. In the US, it is recommended to report the UB92 FL 19 _Type of Admission_ in this field.
User-defined Table 0007 - Admission Type
Value | Description | Comments |
---|---|---|
A | Accident |
|
E | Emergency | US UB92 code _1_ |
L | Labor and Delivery |
|
R | Routine |
|
N | Newborn (Birth in healthcare facility) | US UB92 code _4_ |
U | Urgent | US UB92 code _2_ |
C | Elective | US UB92 code _3_ |
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
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, a ST data type can be sent; however HL7 recommends use of the CX data type, like the account number, for new implementations. The assigning authority and identifier type codes are strongly recommended for all CX data types.
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)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>
Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Authority for Location (HD): <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 (location status), it supersedes the value in PV1-40 - Bed Status.
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ < Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
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.
User-defined Table 0010 - Physician ID
3.4.3.5 PV1-5 Preadmit Number (CX) 00135
3.4.3.6 PV1-6 Prior Patient Location (PL) 00136
3.4.3.7 PV1-7 Attending Doctor (XCN) 00137
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ < Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
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.
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ < Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: From V2.4 onward, this field has been retained for backward compatibility only. It is recommended to use the ROL - Role segment for consulting physicians instead. 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.
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.
User-defined Table 0069 - Hospital Service
3.4.3.8 PV1-8 Referring Doctor (XCN) 00138
3.4.3.9 PV1-9 Consulting Doctor (XCN) 00139
3.4.3.10 PV1-10 Hospital Service (IS) 00140
Values | Description | Comment |
---|---|---|
MED | Medical Service |
|
SUR | Surgical Service |
|
URO | Urology Service |
|
PUL | Pulmonary Service |
|
CAR | Cardiac Service |
|
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)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>
Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Authority for Location (HD): <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, operating theatre, etc.). If a value exists in the fifth component (location status), it supersedes the value in PV1-40 - Bed Status.
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.
User-defined Table 0087 - Pre-Admit Test Indicator
3.4.3.11 PV1-11 Temporary Location (PL) 00141
3.4.3.12 PV1-12 Preadmit Test Indicator (IS) 00142
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Definition: This field indicates that a patient is being re-admitted to the healthcare 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.
User-defined Table 0092 - Re-Admission Indicator
3.4.3.13 PV1-13 Re-Admission Indicator (IS) 00143
Value | Description | Comment |
---|---|---|
R | Re-admission |
|
Definition: This field indicates where the patient was admitted. Refer to User-defined Table 0023 - Admit Source for suggested values. In the US, this field is used on UB92 FL20 _Source of Admission_. The UB codes listed as examples are not an exhaustive or current list; refer to a UB specification for additional information.
Note: The official title of UB is _National Uniform Billing Data Element Specifications._ Most of the codes added came from the UB-92 specification, but some came from the UB-82.
User-defined Table 0023 - Admit Source
3.4.3.14 PV1-14 Admit Source (IS) 00144
Value | Description | Comment |
---|---|---|
1 | Physician referral |
|
2 | Clinic referral |
|
3 | HMO referral |
|
4 | Transfer from a hospital |
|
5 | Transfer from a skilled nursing facility |
|
6 | Transfer from another health care facility |
|
7 | Emergency room |
|
8 | Court/law enforcement |
|
9 | Information not available |
|
Definition: This field indicates any permanent or transient handicapped conditions. Refer to User-defined Table 0009 - Ambulatory Status for suggested entries.
User-defined Table 0009 - Ambulatory Status
3.4.3.15 PV1-15 Ambulatory Status (IS) 00145
Value | Description | Comment |
---|---|---|
A0 | No functional limitations |
|
A1 | Ambulates with assistive device |
|
A2 | Wheelchair/stretcher bound |
|
A3 | Comatose; non-responsive |
|
A4 | Disoriented |
|
A5 | Vision impaired |
|
A6 | Hearing impaired |
|
A7 | Speech impaired |
|
A8 | Non-English speaking |
|
A9 | Functional level unknown |
|
B1 | Oxygen therapy |
|
B2 | Special equipment (tubes, IVs, catheters) |
|
B3 | Amputee |
|
B4 | Mastectomy |
|
B5 | Paraplegic |
|
B6 | Pregnant |
|
Definition: This field identifies the type of VIP. Refer to User-defined Table 0099 - VIP Indicator for suggested values.
User-defined Table 0099 - VIP Indicator
3.4.3.16 PV1-16 VIP Indicator (IS) 00146
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ < Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
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.
Definition: This field contains site-specific values that identify the patient type. Refer to User-defined Table 0018 - Patient Type for suggested values.
User-defined Table 0018 - Patient Type
3.4.3.17 PV1-17 Admitting Doctor (XCN) 00147
3.4.3.18 PV1-18 Patient Type (IS) 00148
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: For backward compatibility, a 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. The assigning authority and identifier type code are strongly recommended for all CX data types.
Components: <Financial Class Code (IS)> ^ <Effective Date (TS)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Definition: This field contains the financial class(es) assigned to the patient for the purpose of identifying sources of reimbursement. Refer to User-defined Table 0064 - Financial Class for suggested values.
User-defined Table 0064 - Financial Class
3.4.3.19 PV1-19 Visit Number (CX) 00149
3.4.3.20 PV1-20 Financial Class (FC) 00150
Value | Description | Comment |
---|---|---|
| no suggested values |
|
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.
User-defined Table 0032 - Charge/Price Indicator
3.4.3.21 PV1-21 Charge Price Indicator (IS) 00151
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Definition: This field indicates whether the patient will be extended certain special courtesies. Refer to User-defined Table 0045 - Courtesy Code for suggested values.
User-defined Table 0045 - Courtesy Code
3.4.3.22 PV1-22 Courtesy Code (IS) 00152
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Definition: This field contains the user-defined code to determine past credit experience. Refer to User-defined Table 0046 - Credit Rating for suggested values.
User-defined Table 0046 - Credit Rating
3.4.3.23 PV1-23 Credit Rating (IS) 00153
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Definition: This field identifies the type of contract entered into by the healthcare facility and the guarantor for the purpose of settling outstanding account balances. Refer to User-defined Table 0044 - Contract Code for suggested values.
User-defined Table 0044 - Contract Code
3.4.3.24 PV1-24 Contract Code (IS) 00154
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Definition: This field contains the date that the contract is to start or started.
Definition: This field contains the amount to be paid by the guarantor each period according to the contract.
Definition: This field specifies the duration of the contract for user-defined periods.
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.
User-defined Table 0073 - Interest Rate Code
3.4.3.25 PV1-25 Contract Effective Date (DT) 00155
3.4.3.26 PV1-26 Contract Amount (NM) 00156
3.4.3.27 PV1-27 Contract Period (NM) 00157
3.4.3.28 PV1-28 Interest Code (IS) 00158
Value | Description | Comment |
---|---|---|
| no suggested values |
|
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.
User-defined Table 0110 - Transfer to Bad Debt Code
3.4.3.29 PV1-29 Transfer to Bad Debt Code (IS) 00159
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Definition: This field contains the date that the account was transferred to a bad debt status.
Definition: This field can be used as a 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.
User-defined Table 0021 - Bad Debt Agency Code
3.4.3.30 PV1-30 Transfer to Bad Debt Date (DT) 00160
3.4.3.31 PV1-31 Bad Debt Agency Code (IS) 00161
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Definition: This field contains the amount that was transferred to a bad debt status.
Definition: This field contains the amount recovered from the guarantor on the account.
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.
User-defined Table 0111 - Delete Account Code
3.4.3.32 PV1-32 Bad Debt Transfer Amount (NM) 00162
3.4.3.33 PV1-33 Bad Debt Recovery Amount (NM) 00163
3.4.3.34 PV1-34 Delete Account Indicator (IS) 00164
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Definition: This field contains the date that the account was deleted from the file.
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 - Discharge Disposition for suggested values. In the US, this field is used on UB92 FL22. The UB codes listed as examples are not an exhaustive or current list; refer to a UB specification for additional information.
User-defined Table 0112 - Discharge Disposition
3.4.3.35 PV1-35 Delete Account Date (DT) 00165
3.4.3.36 PV1-36 Discharge Disposition (IS) 00166
Value | Description | Comment |
---|---|---|
01 | Discharged to home or self care (routine discharge) |
|
02 | Discharged/transferred to another short term general hospital for inpatient care |
|
03 | Discharged/transferred to skilled nursing facility (SNF) |
|
04 | Discharged/transferred to an intermediate care facility (ICF) |
|
05 | Discharged/transferred to another type of institution for inpatient care or referred for outpatient services to another institution |
|
06 | Discharged/transferred to home under care of organized home health service organization |
|
07 | Left against medical advice or discontinued care |
|
08 | Discharged/transferred to home under care of Home IV provider |
|
09 | Admitted as an inpatient to this hospital |
|
10 _19 | Discharge to be defined at state level, if necessary |
|
20 | Expired (i.e. dead) |
|
21 ... 29 | Expired to be defined at state level, if necessary |
|
30 | Still patient or expected to return for outpatient services (i.e. still a patient) |
|
31 _ 39 | Still patient to be defined at state level, if necessary (i.e. still a patient) |
|
40 | Expired (i.e. died) at home |
|
41 | Expired (i.e. died) in a medical facility; e.g., hospital, SNF, ICF, or free standing hospice |
|
42 | Expired (i.e. died) - place unknown |
|
Components: <Discharge Location (IS)> ^ <Effective Date (TS)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Definition: This field indicates the healthcare facility to which the patient was discharged and the date. Refer to User-defined Table 0113 - Discharged to Location for suggested values.
User-defined Table 0113 - Discharged to Location
3.4.3.37 PV1-37 Discharged to Location (DLD) 00167
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates a special diet type for a patient. Refer to User-defined Table 0114 - Diet Type for suggested values.
User-defined Table 0114 - Diet Type
3.4.3.38 PV1-38 Diet Type (CE) 00168
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Definition: This field is used in a multiple facility environment to indicate the healthcare facility with which this visit is associated. Refer to User-defined Table 0115 - Servicing Facility for suggested values.
User-defined Table 0115 - Servicing Facility
3.4.3.39 PV1-39 Servicing Facility (IS) 00169
Value | Description | Comment |
---|---|---|
| no suggested values |
|
An optional sixth component, the facility ID, may be valued in each individual location field in PV1, instead of placing it here.
Definition: This field has been retained for backward compatibility only. The information is now held in the fifth component of the PL datatype in PV1-3. This field contains the status of the bed. Refer to User-defined Table 0116 - Bed Status for suggested values.
User-defined Table 0116 - Bed Status
Value | Description | Comment |
---|---|---|
C | Closed |
|
H | Housekeeping |
|
O | Occupied |
|
U | Unoccupied |
|
K | Contaminated |
|
I | Isolated |
|
Definition: This field contains the account status. Refer to User-defined Table 0117 - Account Status for suggested values.
User-defined Table 0117 - Account Status
3.4.3.41 PV1-41 Account Status (IS) 00171
Value | Description | Comment |
---|---|---|
| no suggested values |
|
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)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>
Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Authority for Location (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Definition: This field indicates the point of care, room, bed, healthcare 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 (location status), it supersedes the value in PV1-40 - Bed Status.
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)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>
Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Authority for Location (HD): <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 operating room/theatre 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.
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
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.
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
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.
Definition: This field contains the visit balance due.
Definition: This field contains the total visit charges.
Definition: This field contains the total adjustments for visit.
Definition: This field contains the total payments for visit.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
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 for valid values. Refer to HL7 Table 0203 - Identifier Type for valid values. The assigning authority and identifier type codes are strongly recommended for all CX data types.
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 are at the visit level. Refer to User-defined Table 0326 - Visit Indicator for suggested values.
The value of this element affects the context of data sent in PV1, PV2 and any associated hierarchical segments (e.g. DB1, AL1, DG1, etc.).
User-defined Table 0326 - Visit Indicator
3.4.3.42 PV1-42 Pending Location (PL) 00172
3.4.3.43 PV1-43 Prior Temporary Location (PL) 00173
3.4.3.44 PV1-44 Admit Date/Time (TS) 00174
3.4.3.45 PV1-45 Discharge Date/Time (TS) 00175
3.4.3.46 PV1-46 Current Patient Balance (NM) 00176
3.4.3.47 PV1-47 Total Charges (NM) 00177
3.4.3.48 PV1-48 Total Adjustments (NM) 00178
3.4.3.49 PV1-49 Total Payments (NM) 00179
3.4.3.50 PV1-50 Alternate Visit ID (CX) 00180
3.4.3.51 PV1-51 Visit Indicator (IS) 01226
Value | Description | Comment |
---|---|---|
A | Account level (default) |
|
V | Visit level |
|
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ < Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: From V2.4 onward, this field has been retained for backward compatibility only. Use the ROL-Role Segment to communicate providers not specified elsewhere. Refer to Chapter 15 for the definition of the ROL segment. 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.
The PV2 segment is a continuation of information contained on the PV1 segment.
HL7 Attribute Table - PV2 - Patient Visit - Additional Information
3.4.3.52 PV1-52 Other Healthcare Provider (XCN) 01274
3.4.4 PV2 - Patient Visit - Additional Information Segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 80 | PL | C |
|
| 00181 | Prior Pending Location | DB |
2 | 250 | CE | O |
| 0129 | 00182 | Accommodation Code | DB |
3 | 250 | CE | O |
|
| 00183 | Admit Reason | DB |
4 | 250 | CE | O |
|
| 00184 | Transfer Reason | DB |
5 | 25 | ST | O | Y |
| 00185 | Patient Valuables | DB |
6 | 25 | ST | O |
|
| 00186 | Patient Valuables Location | DB |
7 | 2 | IS | O | Y | 0130 | 00187 | Visit User Code | DB |
8 | 26 | TS | O |
|
| 00188 | Expected Admit Date/Time | DB |
9 | 26 | TS | O |
|
| 00189 | Expected Discharge Date/Time | DB |
10 | 3 | NM | O |
|
| 00711 | Estimated Length of Inpatient Stay | DB |
11 | 3 | NM | O |
|
| 00712 | Actual Length of Inpatient Stay | DB |
12 | 50 | ST | O |
|
| 00713 | Visit Description | DB |
13 | 250 | XCN | O | Y |
| 00714 | Referral Source Code | DB |
14 | 8 | DT | O |
|
| 00715 | Previous Service Date | DB |
15 | 1 | ID | O |
| 0136 | 00716 | Employment Illness Related Indicator | DB |
16 | 1 | IS | O |
| 0213 | 00717 | Purge Status Code | DB |
17 | 8 | DT | O |
|
| 00718 | Purge Status Date | DB |
18 | 2 | IS | O |
| 0214 | 00719 | Special Program Code | DB |
19 | 1 | ID | O |
| 0136 | 00720 | Retention Indicator | DB |
20 | 1 | NM | O |
|
| 00721 | Expected Number of Insurance Plans | DB |
21 | 1 | IS | O |
| 0215 | 00722 | Visit Publicity Code | DB |
22 | 1 | ID | O |
| 0136 | 00723 | Visit Protection Indicator | DB |
23 | 250 | XON | O | Y |
| 00724 | Clinic Organization Name | DB |
24 | 2 | IS | O |
| 0216 | 00725 | Patient Status Code | DB |
25 | 1 | IS | O |
| 0217 | 00726 | Visit Priority Code | DB |
26 | 8 | DT | O |
|
| 00727 | Previous Treatment Date | DB |
27 | 2 | IS | O |
| 0112 | 00728 | Expected Discharge Disposition | DB |
28 | 8 | DT | O |
|
| 00729 | Signature on File Date | DB |
29 | 8 | DT | O |
|
| 00730 | First Similar Illness Date | DB |
30 | 250 | CE | O |
| 0218 | 00731 | Patient Charge Adjustment Code | DB |
31 | 2 | IS | O |
| 0219 | 00732 | Recurring Service Code | DB |
32 | 1 | ID | O |
| 0136 | 00733 | Billing Media Code | DB |
33 | 26 | TS | O |
|
| 00734 | Expected Surgery Date and Time | DB |
34 | 1 | ID | O |
| 0136 | 00735 | Military Partnership Code | DB |
35 | 1 | ID | O |
| 0136 | 00736 | Military Non-Availability Code | DB |
36 | 1 | ID | O |
| 0136 | 00737 | Newborn Baby Indicator | DB |
37 | 1 | ID | O |
| 0136 | 00738 | Baby Detained Indicator | DB |
38 | 250 | CE | O |
| 0430 | 01543 | Mode of Arrival Code | DB |
39 | 250 | CE | O | Y | 0431 | 01544 | Recreational Drug Use Code | DB |
40 | 250 | CE | O |
| 0432 | 01545 | Admission Level of Care Code | DB |
41 | 250 | CE | O | Y | 0433 | 01546 | Precaution Code | DB |
42 | 250 | CE | O |
| 0434 | 01547 | Patient Condition Code | DB |
43 | 2 | IS | O |
| 0315 | 00759 | Living Will Code | DB |
44 | 2 | IS | O |
| 0316 | 00760 | Organ Donor Code | DB |
45 | 250 | CE | O | Y | 0435 | 01548 | Advance Directive Code | DB |
46 | 8 | DT | O |
|
| 01549 | Patient Status Effective Date | DB |
47 | 26 | TS | C |
|
| 01550 | Expected LOA Return Date/Time | DB |
48 | 26 | TS | O |
|
| 01841 | Expected Pre-admission Testing Date/Time | DB |
49 | 20 | IS | O | Y | 0534 | 01842 | Notify Clergy Code | DB |
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)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>
Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Authority for Location (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates the specific patient accommodations for this visit. Refer to User-defined Table 0129 - Accommodation Code for suggested values.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the short description of the reason for patient admission.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the short description of the reason for a patient location change.
Definition: This field contains the short description of patient valuables checked in during admission.
Definition: This field indicates the location of the patient_s valuables.
Definition: This field further categorizes a patient_s visit with respect to an individual institution_s needs, and is expected to be site-specific. Refer to User-defined Table 0130 - Visit User Code for suggested values.
User-defined Table 0130 - Visit User Code
3.4.4.0 PV2 field definitions
3.4.4.1 PV2-1 Prior Pending Location (PL) 00181
3.4.4.2 Definition: This field is required for cancel pending transfer (A26) messages. In all other events it is optional.PV2-2 Accommodation Code (CE) 00182
3.4.4.3 PV2-3 Admit Reason (CE) 00183
3.4.4.4 PV2-4 Transfer Reason (CE) 00184
3.4.4.5 PV2-5 Patient Valuables (ST) 00185
3.4.4.6 PV2-6 Patient Valuables Location (ST) 00186
3.4.4.7 PV2-7 Visit User Code (IS) 00187
Value | Description | Comment |
---|---|---|
TE | Teaching |
|
HO | Home |
|
MO | Mobile Unit |
|
PH | Phone |
|
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
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.
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
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.
Definition: This field specifies the estimated days of inpatient stays.
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.
Definition: This field contains a brief user-defined description of the visit.
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ < Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
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).
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.
Definition: This field specifies whether a patient_s illness was job-related. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y the patient's illness was job-related
N the patient's illness was not job-related
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 Code for suggested values.
User-defined Table 0213 - Purge Status Code
3.4.4.8 PV2-8 Expected Admit Date/Time (TS) 00188
3.4.4.9 PV2-9 Expected Discharge Date/Time (TS) 00189
3.4.4.10 PV2-10 Estimated Length of Inpatient Stay (NM) 00711
3.4.4.11 PV2-11 Actual Length of Inpatient Stay (NM) 00712
3.4.4.12 PV2-12 Visit Description (ST) 00713
3.4.4.13 PV2-13 Referral Source Code (XCN) 00714
3.4.4.14 PV2-14 Previous Service Date (DT) 00715
3.4.4.15 PV2-15 Employment Illness Related Indicator (ID) 00716
3.4.4.16 PV2-16 Purge Status Code (IS) 00717
Value | Description | Comment |
---|---|---|
P | Marked for purge. User is no longer able to update the visit. |
|
D | The visit is marked for deletion and the user cannot enter new data against it. |
|
I | The visit is marked inactive and the user cannot enter new data against it. |
|
Definition: This field contains the date on which the data will be purged from the system.
Definition: This field designates the specific health insurance program for a visit required for healthcare reimbursement. Refer to User-defined Table 0214 - Special Program Codes for suggested values.
User-defined Table 0214 - Special Program Code
3.4.4.17 PV2-17 Purge Status Date (DT) 00718
3.4.4.18 PV2-18 Special Program Code (IS) 00719
Value | Description | Comment |
---|---|---|
CH | Child Health Assistance |
|
ES | Elective Surgery Program |
|
FP | Family Planning |
|
O | Other |
|
U | Unknown |
|
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 HL7 Table 0136 - Yes/no Indicator for valid values.
Y retain data
N normal purge processing
Definition: This field contains the number of insurance plans that may provide coverage for this visit.
Definition: This field contains a user-defined code indicating what level of publicity is allowed for a specific visit. Refer to User-defined Table 0215 - Publicity Code for suggested values. Refer to PD1-11 - Publicity Code for the patient level publicity code.
User-defined Table 0215 - Publicity Code
3.4.4.19 PV2-19 Retention Indicator (ID) 00720
3.4.4.20 PV2-20 Expected Number of Insurance Plans (NM) 00721
3.4.4.21 PV2-21 Visit Publicity Code (IS) 00722
Value | Description | Comment |
---|---|---|
F | Family only |
|
N | No Publicity |
|
O | Other |
|
U | Unknown |
|
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 HL7 Table 0136 - Yes/no Indicator for valid values.
Y protect access to patient information
N normal access
Refer to PD1-12 - Protection Indicator for the patient level protection indicator.
Components: <Organization Name (ST)> ^ <Organization Name Type Code (IS)> ^ <ID Number (NM)> ^ <Check Digit (NM)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Organization Identifier (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <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 healthcare facility might be named.
Definition: This field indicates the status of the episode of care. Refer to User-defined Table 0216 - Patient Status for suggested values.
User-defined Table 0216 - Patient Status Code
3.4.4.22 PV2-22 Visit Protection Indicator (ID) 00723
3.4.4.23 PV2-23 Clinic Organization Name (XON) 00724
3.4.4.24 PV2-24 Patient Status Code (IS) 00725
Value | Description | Comment |
---|---|---|
AI | Active Inpatient |
|
DI | Discharged Inpatient |
|
Definition: This field contains the priority of the visit. Refer to User-defined Table 0217 - Visit Priority Code for suggested values.
User-defined Table 0217 - Visit Priority Code
3.4.4.25 PV2-25 Visit Priority Code (IS) 00726
Value | Description | Comment |
---|---|---|
1 | Emergency |
|
2 | Urgent |
|
3 | Elective |
|
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.
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.
Definition: This field contains the date on which a signature was obtained for insurance billing purposes.
Definition: This field is used to determine if the patient has a pre-existing condition.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
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-26 - Guarantor Charge Adjustment Code.
Definition: This field indicates whether the treatment is continuous. Refer to User-defined Table 0219 - Recurring Service for suggested values.
User-defined Table 0219 - Recurring Service Code
3.4.4.26 PV2-26 Previous Treatment Date (DT) 00727
3.4.4.27 PV2-27 Expected Discharge Disposition (IS) 00728
3.4.4.28 PV2-28 Signature on File Date (DT) 00729
3.4.4.29 PV2-29 First Similar Illness Date (DT) 00730
3.4.4.30 PV2-30 Patient Charge Adjustment Code (CE) 00731
3.4.4.31 PV2-31 Recurring Service Code (IS) 00732
Value | Description | Comment |
---|---|---|
| no suggested values |
|
Definition: This field indicates if the account is to be rejected from tape billing. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y reject account from tape billing
N normal processing
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: This field contains the date and time on which the surgery is expected to occur.
Definition: This field indicates that a military healthcare facility has contracted with a non-military healthcare facility for the use of its services. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y contract(s) exist
N no contract(s) exist
Definition: This field indicates whether a patient has permission to use a non-military healthcare facility for treatment. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y the patient has permission to use a non-military healthcare facility
N the patient does not have permissions to use a non-military healthcare facility
Definition: This field indicates whether the patient is a baby. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y the patient is a baby
N the patient is not a baby
Definition: This field indicates if the baby is detained after the mother_s discharge. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y the baby was detained
N normal discharge of mother and baby
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: Identifies how the patient was brought to the healthcare facility. Refer to User-defined Table 0430 - Mode of Arrival Code for suggested values.
User-defined Table 0430 - Mode of Arrival Code
3.4.4.32 PV2-32 Billing Media Code (ID) 00733
3.4.4.33 PV2-33 Expected Surgery Date and Time (TS) 00734
3.4.4.34 PV2-34 Military Partnership Code (ID) 00735
3.4.4.35 PV2-35 Military Non-Availability Code (ID) 00736
3.4.4.36 PV2-36 Newborn Baby Indicator (ID) 00737
3.4.4.37 PV2-37 Baby Detained Indicator (ID) 00738
3.4.4.38 PV2-38 Mode of Arrival Code (CE) 01543
Value | Description | Comment |
---|---|---|
A | Ambulance |
|
C | Car |
|
F | On foot |
|
H | Helicopter |
|
P | Public Transport |
|
O | Other |
|
U | Unknown |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates what recreational drugs the patient uses. It is used for the purpose of room assignment. Refer to User-defined Table 0431 - Recreational Drug Use Code for suggested values.
User-defined Table 0431 - Recreational Drug Use Code
3.4.4.39 PV2-39 Recreational Drug Use Code (CE) 01544
Value | Description | Comment |
---|---|---|
A | Alcohol |
|
K | Kava |
|
M | Marijuana |
|
T | Tobacco - smoked |
|
C | Tobacco - chewed |
|
O | Other |
|
U | Unknown |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates the acuity level assigned to the patient at the time of admission. Refer to User-defined Table 0432 - Admission Level of Care Code for suggested values.
User-defined Table 0432 - Admission Level of Care Code
3.4.4.40 PV2-40 Admission Level of Care Code (CE) 01545
Value | Description | Comment |
---|---|---|
AC | Acute |
|
CH | Chronic |
|
CO | Comatose |
|
CR | Critical |
|
IM | Improved |
|
MO | Moribund |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates non-clinical precautions that need to be taken with the patient. Refer to User-defined Table 0433 - Precaution Code for suggested values.
User-defined Table 0433 - Precaution Code
3.4.4.41 PV2-41 Precaution Code (CE) 01546
Value | Description | Comment |
---|---|---|
A | Aggressive |
|
B | Blind |
|
C | Confused |
|
D | Deaf |
|
I | On IV |
|
N | _No-code_ (i.e. Do not resuscitate) |
|
P | Paraplegic |
|
O | Other |
|
U | Unknown |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates the patient_s current medical condition for the purpose of communicating to non-medical outside parties, e.g. family, employer, religious minister, media, etc. Refer to User-defined Table 0434 - Patient Condition Code for suggested values.
User-defined Table 0434 - Patient Condition Code
3.4.4.42 PV2-42 Patient Condition Code (CE) 01547
Value | Description | Comment |
---|---|---|
A | Satisfactory |
|
C | Critical |
|
P | Poor |
|
S | Stable |
|
O | Other |
|
U | Unknown |
|
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 healthcare 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 Code for suggested values. See also PD1-7 - Living Will.
User-defined Table 0315 - Living Will Code
3.4.4.43 PV2-43 Living Will Code (IS) 00759
Value | Description | Comment |
---|---|---|
Y | Yes, patient has a living will |
|
F | Yes, patient has a living will but it is not on file |
|
N | No, patient does not have a living will and no information was provided |
|
I | No, patient does not have a living will but information was provided |
|
U | Unknown |
|
Definition: This field indicate whether the patient wants to donate his/her organs and whether an organ donor card or similar documentation is on file with the healthcare organization. Refer to User-defined Table 0316 - Organ Donor Code for suggested values. See also PD1-8 - Organ Donor.
User-defined Table 0316 - Organ Donor Code
3.4.4.44 PV2-44 Organ Donor Code (IS) 00760
Value | Description | Comment |
---|---|---|
Y | Yes, patient is a documented donor and documentation is on file |
|
F | Yes, patient is a documented donor, but documentation is not on file |
|
N | No, patient has not agreed to be a donor |
|
I | No, patient is not a documented donor, but information was provided |
|
R | Patient leaves organ donation decision to relatives |
|
P | Patient leaves organ donation decision to a specific person |
|
U | Unknown |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates the patient_s instructions to the healthcare facility. Refer to User-defined Table 0435 - Advance Directive Code for suggested values. See also PD1-15 - Advance Directive Code.
User-defined Table 0435 -Advance Directive Code
3.4.4.45 PV2-45 Advance Directive Code (CE) 01548
Value | Description | Comment |
---|---|---|
DNR | Do not resuscitate |
|
Definition: This field indicates the effective date for PV2-24 - Patient Status.
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: This field is conditionally required for A21 - Patient goes on LOA. It may be populated in A22 - Patient returns from LOA as well as in the A53 - Cancel LOA for a patient and the A54 - Cancel patient returns from LOA triggers. This field contains the date/time that the patient is expected to return from LOA.
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: This field contains the date/time that the patient is expected for pre-admission testing.
Definition: This field allows the user to indicate whether the clergy should be notified. Refer to User-defined Table 0534 - Notify Clergy Code for suggested values.
User-defined Table 0534 - Notify Clergy Code
3.4.4.46 PV2-46 Patient Status Effective Date (DT) 01549
3.4.4.47 PV2-47 Expected LOA Return Date/Time (TS) 01550
3.4.4.48 PV2-48 Expected Preadmission Testing Date/Time (TS) 01841
3.4.4.49 PV2-49 Notify Clergy Code (IS) 01842
Value | Description | Comment |
---|---|---|
Y | Yes |
|
N | No |
|
L | Last Rites only |
|
O | Other |
|
U | Unknown |
|
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.
If a person or organization fulfills multiple contact roles, for example, a person is an emergency contact and a next of kin, it is recommended to send a NK1 segment for each contact role (field 7).
HL7 Attribute Table - NK1 - Next of Kin / Associated Parties
3.4.5 NK1 - Next of Kin / Associated Parties Segment
SEQ | LEN | DT | OPT | R P/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 4 | SI | R |
|
| 00190 | Set ID - NK1 | DB |
2 | 250 | XPN | O | Y |
| 00191 | Name | DB |
3 | 250 | CE | O |
| 0063 | 00192 | Relationship | DB |
4 | 250 | XAD | O | Y |
| 00193 | Address | DB |
5 | 250 | XTN | O | Y |
| 00194 | Phone Number | DB |
6 | 250 | XTN | O | Y |
| 00195 | Business Phone Number | DB |
7 | 250 | CE | O |
| 0131 | 00196 | Contact Role | DB |
8 | 8 | DT | O |
|
| 00197 | Start Date | DB |
9 | 8 | DT | O |
|
| 00198 | End Date | DB |
10 | 60 | ST | O |
|
| 00199 | Next of Kin / Associated Parties Job Title | DB |
11 | 20 | JCC | O |
| 0327/ | 00200 | Next of Kin / Associated Parties Job Code/Class | DB |
12 | 250 | CX | O |
|
| 00201 | Next of Kin / Associated Parties Employee Number | DB |
13 | 250 | XON | O | Y |
| 00202 | Organization Name - NK1 | DB |
14 | 250 | CE | O |
| 0002 | 00119 | Marital Status | DB |
15 | 1 | IS | O |
| 0001 | 00111 | Administrative Sex | DB |
16 | 26 | TS | O |
|
| 00110 | Date/Time of Birth | DB |
17 | 2 | IS | O | Y | 0223 | 00755 | Living Dependency | DB |
18 | 2 | IS | O | Y | 0009 | 00145 | Ambulatory Status | DB |
19 | 250 | CE | O | Y | 0171 | 00129 | Citizenship | DB |
20 | 250 | CE | O |
| 0296 | 00118 | Primary Language | DB |
21 | 2 | IS | O |
| 0220 | 00742 | Living Arrangement | DB |
22 | 250 | CE | O |
| 0215 | 00743 | Publicity Code | DB |
23 | 1 | ID | O |
| 0136 | 00744 | Protection Indicator | DB |
24 | 2 | IS | O |
| 0231 | 00745 | Student Indicator | DB |
25 | 25080 | CE | O |
| 0006 | 00120 | Religion | DB |
26 | 250 | XPN | O | Y |
| 00109 | Mother_s Maiden Name | DB |
27 | 250 | CE | O |
| 0212 | 00739 | Nationality | DB |
28 | 250 | CE | O | Y | 0189 | 00125 | Ethnic Group | DB |
29 | 250 | CE | O | Y | 0222 | 00747 | Contact Reason | DB |
30 | 250 | XPN | O | Y |
| 00748 | Contact Person_s Name | DB |
31 | 250 | XTN | O | Y |
| 00749 | Contact Person_s Telephone Number | DB |
32 | 250 | XAD | O | Y |
| 00750 | Contact Person_s Address | DB |
33 | 250 | CX | O | Y |
| 00751 | Next of Kin/Associated Party_s Identifiers | DB |
34 | 2 | IS | O |
| 0311 | 00752 | Job Status | DB |
35 | 250 | CE | O | Y | 0005 | 00113 | Race | DB |
36 | 2 | IS | O |
| 0295 | 00753 | Handicap | DB |
37 | 16 | ST | O |
|
| 00754 | Contact Person Social Security Number | DB |
38 | 250 | ST | O |
|
| 01905 | Next of Kin Birth Place | DB |
39 | 2 | IS | O |
| 0099 | 00146 | VIP Indicator | DB |
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.
Components: <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Name Type Code (ID)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (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 HL7 Table 0200 - Name Type for valid values.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the actual personal relationship that the next of kin/associated party has to the patient. Refer to User-defined Table 0063 - Relationship for suggested values.
User-defined Table 0063 - Relationship
3.4.5.0 NK1 field definitions
3.4.5.1 NK1-1 Set ID - NK1 (SI) 00190
3.4.5.2 NK1-2 Name (XPN) 00191
3.4.5.3 NK1-3 Relationship (CE) 00192
Value | Description | Comment |
---|---|---|
SEL | Self |
|
SPO | Spouse |
|
DOM | Life partner |
|
CHD | Child |
|
GCH | Grandchild |
|
NCH | Natural child |
|
SCH | Stepchild |
|
FCH | Foster child |
|
DEP | Handicapped dependent |
|
WRD | Ward of court |
|
PAR | Parent |
|
MTH | Mother |
|
FTH | Father |
|
CGV | Care giver |
|
GRD | Guardian |
|
GRP | Grandparent |
|
EXF | Extended family |
|
SIB | Sibling |
|
BRO | Brother |
|
SIS | Sister |
|
FND | Friend |
|
OAD | Other adult |
|
EME | Employee |
|
EMR | Employer |
|
ASC | Associate |
|
EMC | Emergency contact |
|
OWN | Owner |
|
TRA | Trainer |
|
MGR | Manager |
|
NON | None |
|
UNK | Unknown |
|
OTH | Other |
|
Components: <Street Address (SAD)> ^ <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)> ^ <Address Representation Code (ID)> ^ <Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>
Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>
Subcomponents for Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
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.
Components: <Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^ <Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)> ^ <Area/City Code (NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^ <Extension Prefix (ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (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 HL7 Table 0201 - Telecommunication Use Code and HL7 Table 0202 - Telecommunication Equipment Type for valid values.
Components: <Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^ <Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)> ^ <Area/City Code (NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^ <Extension Prefix (ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (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 HL7 Table 0201 - Telecommunication Use Code and HL7 Table 0202 - Telecommunication Equipment Type for valid values.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates the specific relationship role. 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.
User-defined Table 0131 - Contact Role
3.4.5.4 NK1-4 Address (XAD) 00193
3.4.5.5 NK1-5 Phone Number (XTN) 00194
3.4.5.6 NK1-6 Business Phone Number (XTN) 00195
3.4.5.7 NK1-7 Contact Role (CE) 00196
Values | Description | Comment |
---|---|---|
E | Employer |
|
C | Emergency Contact |
|
F | Federal Agency |
|
I | Insurance Company |
|
N | Next-of-Kin |
|
S | State Agency |
|
O | Other |
|
U | Unknown |
|
Definition: This field contains the start date of the contact role.
Definition: This field contains the end date of the contact role.
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.
Components: <Job Code (IS)> ^ <Job Class (IS)> ^ <Job Description Text (TX)>
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 Table 0327 - Job Code and User-defined Table 0328 - Employee Classification for suggested values.
Note: The JCC data element appears in other segments as ITEM# 00786 (GT1-50, IN2-47, STF-19). It is assigned a different ITEM# in the NK1 segment because the element name and usage is variable. For example the job code/class can be for the patient's employer, or for an associated party's employment information.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
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. The assigning authority and identifier type codes are strongly recommended for all CX data types.
Components: <Organization Name (ST)> ^ <Organization Name Type Code (IS)> ^ <ID Number (NM)> ^ <Check Digit (NM)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Organization Identifier (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <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.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the next of kin/associated party_s marital status. Refer to User-defined Table 0002 - Marital Status for suggested values.
Definition: This field contains the next of kin/associated party_s sex. Refer to User-defined Table 0001 - Administrative Sex for suggested values.
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: This field contains the next of kin/associated party_s birth date and time.
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.
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.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
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 - Citizenship.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
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.
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.
User-defined Table 0220 - Living Arrangement
3.4.5.8 NK1-8 Start Date (DT) 00197
3.4.5.9 NK1-9 End Date (DT) 00198
3.4.5.10 NK1-10 Next of Kin / Associated Parties Job Title (ST) 00199
3.4.5.11 NK1-11 Next of Kin / Associated Parties Job Code/Class (JCC) 00200
3.4.5.12 NK1-12 Next of Kin / Associated Parties Employee Number (CX) 00201
3.4.5.13 NK1-13 Organization Name - NK1 (XON) 00202
3.4.5.14 NK1-14 Marital Status (CE) 00119
3.4.5.15 NK1-15 Administrative Sex (IS) 00111
3.4.5.16 NK1-16 Date/Time of Birth (TS) 00110
3.4.5.17 NK1-17 Living Dependency (IS) 00755
3.4.5.18 NK1-18 Ambulatory Status (IS) 00145
3.4.5.19 NK1-19 Citizenship (CE) 00129
3.4.5.20 NK1-20 Primary Language (CE) 00118
3.4.5.21 NK1-21 Living Arrangement (IS) 00742
Value | Description | Comment |
---|---|---|
A | Alone |
|
F | Family |
|
I | Institution |
|
R | Relative |
|
U | Unknown |
|
S | Spouse Only |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
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.
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 HL7 Table 0136 - Yes/no Indicator for valid values.
Y protect access to next-of-kin information
N normal access
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 in Chapter 6 for suggested values.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
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.
Components: <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Name Type Code (ID)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Definition: This field indicates the maiden name of the next of kin/associated party_s mother.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
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.). Refer to User-defined Table 0212 - Nationality for suggested values.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the next of kin/associated party_s ethnic group. Refer to User-defined Table 0189 - Ethnic Group for suggested values. The second triplet of the CE data type for ethnic group (alternate identifier, alternate text, and name of alternate coding system) is reserved for governmentally assigned codes. In the US, a current use is to report ethnicity in line with US federal standards for Hispanic origin.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field identifies how the contact should be used (e.g., contact employer if patient is unable to work). Refer to User-defined Table 0222 - Contact Reason in Chapter 6 for suggested values.
Components: <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Name Type Code (ID)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (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.
Components: <Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^ <Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)> ^ <Area/City Code (NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^ <Extension Prefix (ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (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 Table 0201 -Telecommunication Use Code and HL7 Table 0202 - Telecommunication Equipment Type for valid values.
Components: <Street Address (SAD)> ^ <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)> ^ <Address Representation Code (ID)> ^ <Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>
Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>
Subcomponents for Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
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.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field contains the identifiers for the next of kin/associated party, for example, Social Security Number, driver_s license, etc. The assigning authority and identifier type code are strongly recommended for all CX data types.
Definition: This field identifies the next of kin/associated party_s job status. Refer to User-defined Table 0311 - Job Status for suggested values.
User-defined Table 0311 - Job Status
3.4.5.22 NK1-22 Publicity Code (CE) 00743
3.4.5.23 NK1-23 Protection Indicator (ID) 00744
3.4.5.24 NK1-24 Student Indicator (IS) 00745
3.4.5.25 NK1-25 Religion (CE) 00120
3.4.5.26 NK1-26 Mother_s Maiden Name (XPN) 00109
3.4.5.27 NK1-27 Nationality (CE) 00739
3.4.5.28 NK1-28 Ethnic Group (CE) 00125
3.4.5.29 NK1-29 Contact Reason (CE) 00747
3.4.5.30 NK1-30 Contact Person_s Name (XPN) 00748
3.4.5.31 NK1-31 Contact Person_s Telephone Number (XTN) 00749
3.4.5.32 NK1-32 Contact Person_s Address (XAD) 00750
3.4.5.33 NK1-33 Next of Kin/Associated Party_s Identifiers (CX) 00751
3.4.5.34 NK1-34 Job Status (IS) 00752
Values | Description | Comment |
---|---|---|
P | Permanent |
|
T | Temporary |
|
O | Other |
|
U | Unknown |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field identifies the race of the next of kin/associated party. Refer to User-defined Table 0005 - Race for suggested values. The second triplet of the CE data type for race (alternate identifier, alternate text, and name of alternate coding system) is reserved for governmentally assigned codes.
Definition: This field contains the code that describes an associated party_s disability. Refer to User-defined Table 0295 - Handicap for suggested values.
User-defined Table 0295 - Handicap
3.4.5.35 NK1-35 Race (CE) 00113
3.4.5.36 NK1-36 Handicap (IS) 00753
Value | Description | Comment |
---|---|---|
| No suggested values defined |
|
Definition: In the US, this field contains the contact person_s social security number. This number may also be a RR retirement number. For the Social Security number of the associated party, see NK1-33 - Next of Kin/Associated Party_s identifiers.
Definition: This field indicates the location of the next-of-kin_s birth, for example _St. Francis Community Hospital of Lower South Side._ The actual address is reported in NK1-4 - Address with an identifier of _N_.
Definition: This field identifies the type of VIP for the next-of-kin. Refer to User-defined Table 0099 _ VIP Indicator.
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.
HL7 Attribute Table - AL1 - Patient Allergy Information
3.4.5.37 NK1-37 Contact Person Social Security Number (ST) 00754
3.4.5.38 NK1-38 Next-of-Kin Birth Place (ST) 01905
3.4.5.39 NK1-39 VIP Indicator (IS) 00146
3.4.6 AL1 - Patient Allergy Information Segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 4 | SI | R |
|
| 00203 | Set ID - AL1 | DB |
2 | 250 | CE | O |
| 0127 | 00204 | Allergen Type Code | DB |
3 | 250 | CE | R |
|
| 00205 | Allergen Code/Mnemonic/Description | DB |
4 | 250 | CE | O |
| 0128 | 00206 | Allergy Severity Code | DB |
5 | 15 | ST | O | Y |
| 00207 | Allergy Reaction Code | DB |
6 | 8 | DT | B |
|
| 00208 | Identification Date | DB |
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.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates a general allergy category (drug, food, pollen, etc.). Refer to User-defined Table 0127 - Allergen Type for suggested values.
User-defined Table 0127 - Allergen Type
3.4.6.0 AL1 field definitions
3.4.6.1 AL1-1 Set ID - AL1 (SI) 00203
3.4.6.2 AL1-2 Allergen Type Code (CE) 00204
Value | Description | Comment |
---|---|---|
DA | Drug allergy |
|
FA | Food allergy |
|
MA | Miscellaneous allergy |
|
MC | Miscellaneous contraindication |
|
EA | Environmental Allergy |
|
AA | Animal Allergy |
|
PA | Plant Allergy |
|
LA | Pollen Allergy |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field uniquely identifies a particular allergen. 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.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates the general severity of the allergy. Refer to User-defined Table 0128 - Allergy Severity for suggested values.
User-defined Table 0128 - Allergy Severity
3.4.6.3 AL1-3 Allergen Code/Mnemonic/Description (CE) 00205
3.4.6.4 AL1-4 Allergy Severity Code (CE) 00206
Value | Description | Comment |
---|---|---|
SV | Severe |
|
MO | Moderate |
|
MI | Mild |
|
U | Unknown |
|
Definition: This field identifies the specific allergic reaction that was documented. This element may conform to some external, standard coding system, or it may conform to a local, largely textual or mnemonic descriptions (e.g., convulsions, sneeze, rash, etc.).
Definition: From V2.4 onward, this field has been retained for backward compatibility only. This field contains the date that the allergy was identified.
The IAM segment contains person/patient adverse reaction information of various types. Most of this information will be derived from user-defined tables. Each IAM segment describes a single person/patient adverse reaction. This segment is used in lieu of the AL1 - Patient Allergy Information Segment to support action code/unique identifier mode update definition of repeating segments as defined in 2.14.4.2. The AL1 segment is used to support Snapshot mode update definition as defined in 2.14.4.1.
HL7 Attribute Table - IAM - Patient Adverse Reaction Information
3.4.6.5 AL1-5 Allergy Reaction Code (ST) 00207
3.4.6.6 AL1-6 Identification Date (DT) 00208
3.4.7 IAM - Patient Adverse Reaction Information Segment - Unique Identifier
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 4 | SI | R |
|
| 01612 | Set ID - IAM | DB |
2 | 250 | CE | O |
| 0127 | 00204 | Allergen Type Code | DB |
3 | 250 | CE | R |
|
| 00205 | Allergen Code/Mnemonic/Description | DB |
4 | 250 | CE | O |
| 0128 | 00206 | Allergy Severity Code | DB |
5 | 15 | ST | O | Y |
| 00207 | Allergy Reaction Code | DB |
6 | 250 | CNE | R |
| 0323 | 01551 | Allergy Action Code | DB |
7 | 427 | EI | C |
|
| 01552 | Allergy Unique Identifier | DB |
8 | 60 | ST | O |
|
| 01553 | Action Reason | DB |
9 | 250 | CE | O |
| 0436 | 01554 | Sensitivity to Causative Agent Code | DB |
10 | 250 | CE | O |
|
| 01555 | Allergen Group Code/Mnemonic/Description | DB |
11 | 8 | DT | O |
|
| 01556 | Onset Date | DB |
12 | 60 | ST | O |
|
| 01557 | Onset Date Text | DB |
13 | 8 | TS | O |
|
| 01558 | Reported Date/Time | DB |
14 | 250 | XPN | O |
|
| 01559 | Reported By | DB |
15 | 250 | CE | O |
| 0063 | 01560 | Relationship to Patient Code | DB |
16 | 250 | CE | O |
| 0437 | 01561 | Alert Device Code | DB |
17 | 250 | CE | O |
| 0438 | 01562 | Allergy Clinical Status Code | DB |
18 | 250 | XCN | O |
|
| 01563 | Statused by Person | DB |
19 | 250 | XON | O |
|
| 01564 | Statused by Organization | DB |
20 | 8 | TS | O |
|
| 01565 | Statused at Date/Time | DB |
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.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates a general allergy category (drug, food, pollen, etc.). Refer to User-defined Table 0127 - Allergen Type for suggested values.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field uniquely identifies a particular allergen. 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.
If a system maintains allergen codes as it's unique identifier for a particular allergy, and two systems have agreed to process the IAM using update mode, then this field can be used as the unique identifier instead of IAM-8 - Allergy Unique Identifier. This does not preclude using allergen codes for unique identifiers for snapshot processing.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates the general severity of the allergy. Refer to User-defined Table 0128 - Allergy Severity Code for suggested values.
Definition: This field identifies the specific allergic reaction that was documented. This element may conform to some external, standard coding system, or it may conform to a local, largely textual or mnemonic descriptions (e.g., convulsions, sneeze, rash, etc.).
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>
Definition: This field contains a code defining the status of the record. It allows allergy messages to be sent to delete or update previously sent allergy messages. Refer to HL7 Table 0323 - Action Code for suggested values.
HL7 Table 0323 - Action Code
3.4.7.0 IAM field definitions
3.4.7.1 IAM-1 Set ID - IAM (SI) 01612
3.4.7.2 IAM-2 Allergen Type Code (CE) 00204
3.4.7.3 IAM-3 Allergen Code/Mnemonic/Description (CE) 00205
3.4.7.4 IAM-4 Allergy Severity Code (CE) 00206
3.4.7.5 IAM-5 Allergy Reaction Code (ST) 00207
3.4.7.6 IAM-6 Allergy Action Code (CNE) 01551
Value | Description | Comment |
---|---|---|
A | Add/Insert |
|
D | Delete |
|
U | Update |
|
X | No change |
|
Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>
Definition: This field contains a value that uniquely identifies a single allergy for a person. It is unique across all segments and messages for a person. If a system maintains allergen codes as a unique identifier for a particular allergy, then this field should not be used.
This field is conditionally required. The surrogate field to use is IAM-3 - Allergen Code/Mnemonic/Description, if that field can uniquely identify the allergy on the receiving system.
Definition: This field contains the reason for the action indicated in the IAM-7 - Allergy Action Code field.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the reason why the patient should not be exposed to a substance. Refer to User-defined Table 0436 - Sensitivity to Causative Agent Code for suggested values.
User-defined Table 0436 - Sensitivity to Causative Agent Code
3.4.7.7 IAM-7 Allergy Unique Identifier (EI) 01552
3.4.7.8 IAM-8 Action Reason (ST) 01553
3.4.7.9 IAM-9 Sensitivity to Causative Agent Code (CE) 01554
Value | Description | Comment |
---|---|---|
AD | Adverse Reaction (Not otherwise classified) |
|
AL | Allergy |
|
CT | Contraindication |
|
IN | Intolerance |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the code, mnemonic, or description used to uniquely identify an allergen group when both a detailed allergy (IAM-3 - Allergen Code/Mnemonic/Description) and group level (IAM-10 - Allergen Group Code/Mnemonic/Description) need to be communicated. In cases where systems want to communicate both a specific drug allergy and the group of drugs to which the specific drug belongs (i.e., Bactrim and Sulfa drugs; Ceclor and Penicillins/Cephalosporins) then the specific drug allergy is sent in IAM-3 - Allergen Code/Mnemonic/Description and the group level is sent in IAM-10 - Allergen Group Code/Mnemonic/Description. However, if only a group level is being communicated, then it can be sent in IAM-3 as the primary identifier of the allergy.
Definition: This field contains the actual date of the first reaction.
Definition: This field contains a text description of the time period of the first reaction when an exact date is not known. (e.g., adolescence, childhood, spring 1990).
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: This field contains the date/time the allergy was reported to a caregiver.
Components: <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Name Type Code (ID)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Definition: This field contains the name of the person reporting the allergy to a caregiver at the time reported in IAM-14 - Reported Date/Time.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the personal relationship that the person reporting the allergy has to the patient. It uses the same table as that used by NK1-3. Refer to User-defined Table 0063 - Relationship for suggested values. Examples include: brother, sister, mother, father, friend, spouse, etc.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field describes any type of allergy alert device the patient may be carrying or wearing. Refer to User-defined Table 0437 - Alert Device for suggested values.
User-defined Table 0437 - Alert Device Code
3.4.7.10 IAM-10 Allergen Group Code/Mnemonic/Description (CE) 01555
3.4.7.11 IAM-11 Onset Date (DT) 01556
3.4.7.12 IAM-12 Onset Date Text (ST) 01557
3.4.7.13 IAM-13 Reported Date/Time (TS) 01558
3.4.7.14 IAM-14 Reported by (XPN) 01459
3.4.7.15 IAM-15 Relationship to Patient Code (CE) 01560
3.4.7.16 IAM-16 Alert Device Code (CE) 01561
Value | Description | Comment |
---|---|---|
B | Bracelet |
|
N | Necklace |
|
W | Wallet Card |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates the verification status for the allergy. Refer to User-defined Table 0438 - Allergy Clinical Status for suggested values.
User-defined Table 0438 - Allergy Clinical Status
3.4.7.17 IAM-17 Allergy Clinical Status Code (CE) 01562
Value | Description | Comment |
---|---|---|
U | Unconfirmed |
|
P | Pending |
|
S | Suspect |
|
C | Confirmed or verified |
|
I | Confirmed but inactive |
|
E | Erroneous |
|
D | Doubt raised |
|
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ < Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field identifies the provider who assigned the clinical status to the allergy. (e.g. ...| S12345^Smith^John^J^III^DR^MD|...).
Components: <Organization Name (ST)> ^ <Organization Name Type Code (IS)> ^ <ID Number (NM)> ^ <Check Digit (NM)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Organization Identifier (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Definition: This field contains the name of the organization providing the update to the allergy (e.g. a General Hospital).
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: The date and time that this allergy was last statused by the IAM-18 - Statused by Person in the IAM-19 - Statused by Organization.
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._
HL7 Attribute Table - NPU - Bed Status Update
3.4.7.18 IAM-18 Statused by Person (XCN) 01563
3.4.7.19 IAM-19 Statused by Organization (XON) 01564
3.4.7.20 IAM-20 Statused at Date/Time (TS) 01565
3.4.8 NPU - Bed Status Update Segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 80 | PL | R |
|
| 00209 | Bed Location | DB |
2 | 1 | IS | O |
| 0116 | 00170 | Bed Status | DB |
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)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>
Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Authority for Location (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Definition: This field contains the bed location that is a valid bed location.
Definition: This field contains the bed status. Refer to User-defined Table 0116 - Bed Status for suggested values.
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.
The assigning authority, the fourth component of the patient identifiers, is an HD data type that is uniquely associated with the assigning authority that originally assigned the number. A given institution, or group of intercommunicating institutions, should establish a list of assigning authorities 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 authority in the patient identification numbers may not be the same as those of the sending and receiving systems identified in the MSH. The assigning authority 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.
HL7 Attribute Table - MRG - Merge Patient Information
3.4.8.0 NPU field definitions
3.4.8.1 NPU-1 Bed Location (PL) 00209
3.4.8.2 NPU-2 Bed Status (IS) 00170
3.4.9 MRG - Merge Patient Information Segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 250 | CX | R | Y |
| 00211 | Prior Patient Identifier List | DB |
2 | 250 | CX | B | Y |
| 00212 | Prior Alternate Patient ID | DB |
3 | 250 | CX | O |
|
| 00213 | Prior Patient Account Number | DB |
4 | 250 | CX | B |
|
| 00214 | Prior Patient ID | DB |
5 | 250 | CX | O |
|
| 01279 | Prior Visit Number | DB |
6 | 250 | CX | O |
|
| 01280 | Prior Alternate Visit ID | DB |
7 | 250 | XPN | O | Y |
| 01281 | Prior Patient Name | DB |
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field contains the prior patient identifier list. 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. Refer to HL7 Table 0061 - Check Digit Scheme for valid values. The assigning authority and identifier type code are strongly recommended for all CX data types.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field has been retained for backward compatibility only. Use MRG-1 - Prior Patient Identifier List for all patient identifiers. This field contains the prior alternate patient identifier. Refer to HL7 Table 0061 - Check Digit Scheme for valid values. The assigning authority and identifier type code are strongly recommended for all CX data types.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field contains the prior patient account number. Refer to HL7 Table 0061 - Check Digit Scheme for valid values. The assigning authority and identifier type code are strongly recommended for all CX data types.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field has been retained for backward compatibility only. Use MRG-1 - Prior Patient Identifier List for all patient identifiers. This field contains the prior patient identifier. Refer to HL7 Table 0061 - Check Digit Scheme for valid values. The assigning authority and identifier type code are strongly recommended for all CX data types.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field contains the prior visit number. Refer to HL7 Table 0061 - Check Digit Scheme for valid values. The assigning authority and identifier type code are strongly recommended for all CX data types.
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field contains the prior alternate visit number. Refer to HL7 Table 0061 - Check Digit Scheme for valid values. The assigning authority and identifier type code are strongly recommended for all CX data types.
Components: <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Name Type Code (ID)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Definition: This field contains the prior name of the patient. This field is not used to change a patient name. Refer to HL7 Table 0200 - Name Type for valid values.
The patient additional demographic segment contains demographic information that is likely to change about the patient.
HL7 Attribute Table - PD1 - Patient Additional Demographic
3.4.9.0 MRG field definitions
3.4.9.1 MRG-1 Prior Patient Identifier List (CX) 00211
3.4.9.2 MRG-2 Prior Alternate Patient ID (CX) 00212
3.4.9.3 MRG-3 Prior Patient Account Number (CX) 00213
3.4.9.4 MRG-4 Prior Patient ID (CX) 00214
3.4.9.5 MRG-5 Prior Visit Number (CX) 01279
3.4.9.6 MRG-6 Prior Alternate Visit ID (CX) 01280
3.4.9.7 MRG-7 Prior Patient Name (XPN) 01281
3.4.10 PD1 - Patient Additional Demographic Segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 2 | IS | O | Y | 0223 | 00755 | Living Dependency | DB |
2 | 2 | IS | O |
| 0220 | 00742 | Living Arrangement | DB |
3 | 250 | XON | O | Y |
| 00756 | Patient Primary Facility | DB |
4 | 250 | XCN | B | Y |
| 00757 | Patient Primary Care Provider Name & ID No. | DB |
5 | 2 | IS | O |
| 0231 | 00745 | Student Indicator | DB |
6 | 2 | IS | O |
| 0295 | 00753 | Handicap | DB |
7 | 2 | IS | O |
| 0315 | 00759 | Living Will Code | DB |
8 | 2 | IS | O |
| 0316 | 00760 | Organ Donor Code | DB |
9 | 1 | ID | O |
| 0136 | 00761 | Separate Bill | DB |
10 | 250 | CX | O | Y |
| 00762 | Duplicate Patient | DB |
11 | 250 | CE | O |
| 0215 | 00743 | Publicity Code | DB |
12 | 1 | ID | O |
| 0136 | 00744 | Protection Indicator | DB |
13 | 8 | DT | O |
|
| 01566 | Protection Indicator Effective Date | DB |
14 | 250 | XON | O | Y |
| 01567 | Place of Worship | DB |
15 | 250 | CE | O | Y | 0435 | 01568 | Advance Directive Code | DB |
16 | 1 | IS | O |
| 0441 | 01569 | Immunization Registry Status | DB |
17 | 8 | DT | O |
|
| 01570 | Immunization Registry Status Effective Date | DB |
18 | 8 | DT | O |
|
| 01571 | Publicity Code Effective Date | DB |
19 | 5 | IS | O |
| 0140 | 01572 | Military Branch | DB |
20 | 2 | IS | O |
| 0141 | 00486 | Military Rank/Grade | DB |
21 | 3 | IS | O |
| 0142 | 01573 | Military Status | DB |
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. 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.
User-defined Table 0223 - Living Dependency
3.4.10.0 PD1 field definitions
3.4.10.1 PD1-1 Living Dependency (IS) 00755
Value | Description | Comment |
---|---|---|
S | Spouse Dependent |
|
M | Medical Supervision Required |
|
C | Small Children Dependent |
|
O | Other |
|
U | Unknown |
|
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 - Living Arrangement for suggested values.
Components: <Organization Name (ST)> ^ <Organization Name Type Code (IS)> ^ <ID Number (NM)> ^ <Check Digit (NM)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Organization Identifier (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Definition: This field contains the name and identifier that specifies the _primary care_ healthcare facility selected by the patient at the time of enrolment in an HMO Insurance Plan. Multiple names and identifiers are allowed for the same facility. The legal name of the healthcare 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. Refer to User-defined Table 0204 - Organizational Name Type for suggested values.
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ < Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field is retained for backward compatibility only. The ROL segment is now used to convey more complete information about the primary care provider. This field contained the provider name and ID of the primary care provider. 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.
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 in Chapter 6 for suggested values.
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.
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 healthcare 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 Code for suggested values. See also PV2-43 - Living Will Code.
Definition: This field indicates whether the patient wants to donate his/her organs and whether an organ donor card or similar documentation is on file with the healthcare organization. Refer to User-defined Table 0316 - Organ Donor Code for suggested values. See also PV2-44 - Organ donor Code.
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.
Y Bill separately
N normal processing
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
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. The assigning authority and identifier type code are strongly recommended for all CX data types.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains a user-defined code indicating what level of publicity is allowed (e.g., No Publicity, Family Only) for the patient. Refer to User-defined Table 0215 - Publicity Code for suggested values. Refer to PV2-21 - Visit Publicity Code for visit level code.
Definition: This field identifies the patient_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. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y protect access to information
N normal access
Refer to PV2-22 - Visit Protection Indicator for visit level code.
Definition: This field indicates the effective date for PD1-12 - Protection Indicator.
Components: <Organization Name (ST)> ^ <Organization Name Type Code (IS)> ^ <ID Number (NM)> ^ <Check Digit (NM)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Organization Identifier (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Definition: The patient_s place of worship. For example, the patient attends the First Baptist Church of Atlanta.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field indicates the patient_s instructions to the healthcare facility. Refer to User-defined Table 0435 - Advance Directive Code for suggested values. See also PV2-45 - Advance Directive Code.
Definition: This field identifies the registry status of the patient. The field may be used to indicate the changed status of a once active patient in a registry, such as an immunization registry. Refer to User-defined Table 0441 - Immunization Registry Status for suggested values.
User-defined Table 0441 - Immunization Registry Status
3.4.10.2 PD1-2 Living Arrangement (IS) 00742
3.4.10.3 PD1-3 Patient Primary Facility (XON) 00756
3.4.10.4 PD1-4 Patient Primary Care Provider Name & ID No. (XCN) 00757
3.4.10.5 PD1-5 Student Indicator (IS) 00745
3.4.10.6 PD1-6 Handicap (IS) 00753
3.4.10.7 PD1-7 Living Will Code (IS) 00759
3.4.10.8 PD1-8 Organ Donor Code (IS) 00760
3.4.10.9 PD1-9 Separate Bill (ID) 00761
3.4.10.10 PD1-10 Duplicate Patient (CX) 00762
3.4.10.11 PD1-11 Publicity Code (CE) 00743
3.4.10.12 PD1-12 Protection Indicator (ID) 00744
3.4.10.13 PD1-13 Protection Indicator Effective Date (DT) 01566
3.4.10.14 PD1-14 Place of Worship (XON) 01567
3.4.10.15 PD1-15 Advance Directive Code (CE) 01568
3.4.10.16 PD1-16 Immunization Registry Status (IS) 01569
Value | Description | Comment |
---|---|---|
A | Active |
|
I | Inactive |
|
L | Inactive - Lost to follow-up (cancel contract) |
|
M | Inactive - Moved or gone elsewhere (cancel contract) |
|
P | Inactive - Permanently inactive (Do not reactivate or add new entries to the record) |
|
O | Other |
|
U | Unknown |
|
Definition: This field indicates the effective date for the registry status reported in PD1-16 - Immunization Registry Status.
Definition: This is the effective date for PD1-11 - Publicity Code.
Definition: This field is defined by CMS or other regulatory agencies. Refer to User-defined Table 0140 - Military Service for suggested values.
User-defined Table 0140 - Military Service
3.4.10.17 PD1-17 Immunization Registry Status Effective Date (DT) 01570
3.4.10.18 PD1-18 Publicity Code Effective Date (DT) 01571
3.4.10.19 PD1-19 Military Branch (IS) 01572
Value | Description | Comment |
---|---|---|
USA | US Army |
|
USN | US Navy |
|
USAF | US Air Force |
|
USMC | US Marine Corps |
|
USCG | US Coast Guard |
|
USPHS | US Public Health Service |
|
NOAA | National Oceanic and Atmospheric Administration |
|
NATO | North Atlantic Treaty Organization |
|
AUSA | Australian Army |
|
AUSN | Australian Navy |
|
AUSAF | Australian Air Force |
|
Definition: This user-defined field identifies the military rank/grade of the patient. Refer to User-defined Table 0141 - Military Rank/Grade for suggested values.
User-defined Table 0141 - Military Rank/Grade
3.4.10.20 PD1-20 Military Rank/Grade (IS) 00486
Value | Description | Comment |
---|---|---|
E1... E9 | Enlisted |
|
O1 ... O9 | Officers |
|
W1 ... W4 | Warrant Officers |
|
Definition: This field is defined by CMS or other regulatory agencies. Refer to User-defined Table 0142 - Military Status for suggested values.
User-defined Table 0142 - Military Status
3.4.10.21 PD1-21 Military Status (IS) 01573
Value | Description | Comment |
---|---|---|
ACT | Active duty |
|
RET | Retired |
|
DEC | Deceased |
|
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.
HL7 Attribute Table - DB1 - Disability
3.4.11 DB1 - Disability Segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 4 | SI | R |
|
| 01283 | Set ID - DB1 | DB |
2 | 2 | IS | O |
| 0334 | 01284 | Disabled Person Code | DB |
3 | 250 | CX | O | Y |
| 01285 | Disabled Person Identifier | DB |
4 | 1 | ID | O |
| 0136 | 01286 | Disabled Indicator | DB |
5 | 8 | DT | O |
|
| 01287 | Disability Start Date | DB |
6 | 8 | DT | O |
|
| 01288 | Disability End Date | DB |
7 | 8 | DT | O |
|
| 01289 | Disability Return to Work Date | DB |
8 | 8 | DT | O |
|
| 01290 | Disability Unable to Work Date | DB |
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.
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 Code for suggested values.
User-defined Table 0334 - Disabled Person Code
3.4.11.0 DB1 field definitions
3.4.11.1 DB1-1 Set ID - DB1 (SI) 01283
3.4.11.2 DB1-2 Disabled Person Code (IS) 01284
Value | Description | Comment |
---|---|---|
PT | Patient |
|
GT | Guarantor |
|
IN | Insured |
|
AP | Associated party |
|
Components: <ID Number (ST)> ^ <heck Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date (DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This is the identifier (or identifiers) for the person whose disability information is sent on the segment. The assigning authority and identifier type code are strongly recommended for all CX data types.
Definition: This field indicates if the person_s visit is a disability visit. Refer to HL7 Table 0136 - Yes/No Indicator for valid values.
Y a disability visit
N not a disability visit
Definition: This field specifies the date the person became disabled.
Definition: This field specifies the ending date of the person_s disability.
Definition: This field indicates the authorized date on which the patient can return to work for a specified disability case.
Definition: This field specifies the first date in the date span that the patient is unable to work due to disability.
This segment carries information on a patient_s death and possible autopsy.
HL7 Attribute Table - PDA - Patient Death and Autopsy
3.4.11.3 DB1-3 Disabled Person Identifier (CX) 01285
3.4.11.4 DB1-4 Disability Indicator (ID) 01286
3.4.11.5 DB1-5 Disability Start Date (DT) 01287
3.4.11.6 DB1-6 Disability End Date (DT) 01288
3.4.11.7 DB1-7 Disability Return to Work Date (DT) 01289
3.4.11.8 DB1-8 Disability Unable to Work Date (DT) 01290
3.4.12 PDA - Patient Death and Autopsy Segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 250 | CE | O | Y |
| 01574 | Death Cause Code | DB |
2 | 80 | PL | O |
|
| 01575 | Death Location | DB |
3 | 1 | ID | O |
| 0136 | 01576 | Death Certified Indicator | DB |
4 | 26 | TS | O |
|
| 01577 | Death Certificate Signed Date/Time | DB |
5 | 250 | XCN | O |
|
| 01578 | Death Certified By | DB |
6 | 1 | ID | O |
| 0136 | 01579 | Autopsy Indicator | DB |
7 | 53 | DR | O |
|
| 01580 | Autopsy Start and End Date/Time | DB |
8 | 250 | XCN | O |
|
| 01581 | Autopsy Performed By | DB |
9 | 1 | ID | O |
| 0136 | 01582 | Coroner Indicator | DB |
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field is valued with the reason of the death.
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)> ^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>
Subcomponents for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Authority for Location (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Definition: This field is valued with the place the death occurred.
Definition: This field indicates whether a death was officially certified or not. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y death has been certified
N death has not been certified
Components: <Time (DTM)> ^ <Degree of Precision (ID)>
Definition: This field is valued with the date and time the death certificate was signed.
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ < Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field is valued with the person who signed the death certificate.
Definition: This field indicates whether an autopsy was performed. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y an autopsy was performed
N an autopsy was not performed
Components: <Range Start Date/Time (TS)> ^ <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Definition: If an autopsy is performed, this field is valued with the date and time the autopsy was begun and completed
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ < Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Subcomponents for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Range End Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field is valued with the authority who performed the autopsy.
Definition: This flag indicates whether the case/death has been assigned to the coroner/medical examiner for investigative purposed. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.
Y Has been assigned to the coroner.
N Has not been assigned to the coroner.
MSH|^~\&|ADT1|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01^ADT_A01|MSG00001|P|2.5|<cr>
EVN|A01|198808181123||<cr>
PID|1||PATID1234^5^M11^ADT1^MR^MCM~123456789^^^USSSA^SS||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^ADT1^AN^A|123456789|987654^NC|<cr>
NK1|1|JONES^BARBARA^K|WI^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.
MSH|^~\&|REGADT|MCM|IFENG||200301061000||ADT^A05^ADT_A05|000001|P|2.5|||<cr>
EVN|A05|200301061000|200301101400|01||200301061000<cr>
PID|1||191919^^^GENHOS^MR^MCM~371-66-9256^^^USSSA^SS|253763|MASSIE^JAMES^A||19560129|M|||171 ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|(900)485-5344||S|C|10199925^^^GENHOS^AN|371-66-9256||<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|||||||||||||||||||GENHOS||||||<cr>
PV2||||||||200301101400||||||||||||||||||||||||||200301101400<cr>
OBX||ST|1010.1^BODY WEIGHT||62|kg|||||F<cr>
OBX||ST|1010.1^HEIGHT||190|cm|||||F<cr>
DG1|1|19||BIOPSY||00<cr>
GT1|1||MASSIE^JAMES^""^""^""^""^||171 ZOBERLEIN^^ISHPEMING^MI^49849^""^|(900)485-5344|(900)485-5344||||SE^SELF|371-66-925|||| |171 ZOBERLEIN^^ISHPEMING^MI^49849^""|(900)485-5344|||||||||||||||||||||||||||||||||MOOSES AUTO CLINIC<cr>
IN1|1|0|BC1|BLUE CROSS|171 ZOBERLEIN^^ISHPEMING^M1^49849^^||(900)485-5344|90||||||50 OK<cr>
IN1|2|""|""<cr>
Patient James A. Massie was pre-admitted on January 6th, 1999 for ambulatory surgery, which is scheduled for January 10, 1999 at 1400. As part of the pre-admission process, he specified two emergency contacts as well as employer, insurance, and guarantor 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.
MSH|^~\&|REGADT|MCM|IFENG||199112311501||ADT^A04^ADT_A01|000001|P|2.5|||<cr>
EVN|A04|200301101500|200301101400|01||200301101410<cr>
PID|||191919^^^GENHOS^MR~371-66-9256^^^USSSA^SS|253763|MASSIE^JAMES^A||19560129|M|||171 ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|(900)485-5344||S|C|10199925^^^GENHOS^AN|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||O|O/R||||0148^ADDISON,JAMES|0148^ADDISON,JAMES|0148^ADDISON,JAMES|AMB|||||||0148^ADDISON,JAMES|S|1400|A|||||||||||||||||||GENHOS|||||199501101410|<cr>
PV2||||||||200301101400||||||||||||||||||||||||||200301101400<cr>
OBX||ST|1010.1^BODY WEIGHT||62|kg|||||F<cr>
OBX||ST|1010.1^HEIGHT||190|cm|||||F<cr>
DG1|1|19||BIOPSY||00|<cr>
GT1|1||MASSIE^JAMES^""^""^""^""^||171 ZOBERLEIN^^ISHPEMING^MI^49849^""^|(900)485-5344|(900)485-5344||||SE^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, 1999 at 1410 for ambulatory surgery which was scheduled for January 10, 1999 at 1400. The visit event was recorded into the MCM system on January 10, 1999 at 1500. It was sent to the interface engine (IFENG) at 1501.
MSH|^~\&|REGADT|MCM|IFENG||200301110025||ADT^A06^ADT_A06|000001|P|2.5|||<cr>
EVN|A06|20030110025||01||200301102300<cr>
PID|||191919^^^GENHOS^MR^FAC1~371-66- 9256^^^USSSA^SS|253763|MASSIE^JAMES^A||19560129|M|||171 ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|(900)485-5344||S|C|10199925^^^GENHOS^AN|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^GENHOS||||0100^ANDERSON,CARL|0148^ADDISON,JAMES||SUR|||||||0148^ANDERSON,CARL|S|1400|A|||||||||||||||||||GENHOS|||||199501102300|<cr>
OBX||ST|1010.1^BODY WEIGHT||62|kg|||||F<cr>
OBX||ST|1010.1^HEIGHT||190|cm|||||F<cr>
DG1|1|19||BIOPSY||00<cr>
GT1|1||MASSIE^JAMES^""^""^""^""^||171 ZOBERLEIN^^ISHPEMING^MI^49849^""^|(900)485-5344|(900)485-5344||||SE^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, 1999 at 2300 to recover from the operation. The change from outpatient to inpatient was recorded on the MCM system on January 11, 1999 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, 1999 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
MSH|^~\&|REGADT|MCM|IFENG||200301110500||ADT^A02^ADT_A02|000001|P|2.5|||<cr>
EVN|A02|200301110520||01||200301110500<cr>
PID|||191919^^^GENHOS^MR~371-66-9256^^^USSSA^SS|253763|MASSIE^JAMES^A||19560129|M|||171 ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|(900)485-5344||S|C|10199925^^^GENHOS^AN|371-66-9256|||||||||<cr>
PV1||I|SICU^0001^01^GENHOS|||6N^1234^A^GENHOS|0200^JONES, GEORGE|0148^ADDISON, JAMES||ICU|||||||0148^ANDERSON,CARL|S|1400|A|||||||||||||||||||GENHOS|||||199501102300|<cr>
On January 11th, 1999 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, 1999 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.
MSH|^~\&|REGADT|MCM|IFENG||200301110600||ADT^A12^ADT_A12|000001|P|2.5|||<cr>
EVN|A02|200301110600||01||200301110500<cr>
PID|||191919^^^GENHOS|253763|MASSIE^JAMES^A||19560129|M|||171 ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|(900)485-5344||S|C|10199925|371-66-9256||
PV1||I|6N^1234^A^GENHOS|||SICU^0001^1^GENHOS|0100^ANDERSON,CARL|0148^ADDISON,JAMES||SUR|||||||0148^ANDERSON,CARL|S|1400|A|||||||||||||||||||GENHOS|||||199501102300|<cr>
It was determined that James A. Massie was transferred to the wrong room in the SICU. Therefore, the transfer was canceled.
MSH|^~\&|REGADT|MCM|IFENG||200301110603||ADT^A02^ADT_A02|000001|P|2.5|||<cr>
EVN|A02|200301110603||01||200301110500<cr>
PID|||191919^^^GENHOS^MR^FAC1~371-6609256^^^USSSA^SS|253763|MASSIE^JAMES^A||19560129|M|||171 ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|(900)485-5344||S|C|10199925^^^GENHOS^AN|371-66-9256||
PV1||I|SICU^0001^02^GENHOS|||6N^1234^A^GENHOS|0100^ANDERSON,CARL|0148^ADDISON,JAMES||SUR|||||||0148^ANDERSON,CARL|S|1400|A|||||||||||||||||||GENHOS|||||199501102300|<cr>
The transfer is then repeated, this time to the correct bed: bed 2 of room 0001 in the SICU.
MSH|^~\&|REGADT|MCM|IFENG||200301121005||ADT^A03^ADT_A03|000001|P|2.5|||<cr>
EVN|A03|200301121005||01||200301121000<cr>
PID|||191919^^^GENHOS^MR~371-66-9256^^^USSSA^SS|253763|MASSIE^JAMES^A||19560129|M|||171 ZOBERLEIN^^ISHPEMING^MI^49849^""^||(900)485-5344|(900)485-5344||S|C|10199925^^^GENHOS^AN|371-66-9256|||||||||<cr>
PV1||I|6N||||0100^ANDERSON,CARL|0148^ADDISON,JAMES||SUR|||||||0148^ANDERSON,CARL|S|1400|A||||||||||||||||SNF|ISH^ISHPEMING NURSING HOME||GENHOS|||||200301102300|199991121005<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.
MSH|^&~\|ADT|CA.SCA|IE|200301310815-0800||ADT^A60^ADT_A60|6757498734|P|2.5
EVN||200301310815-0800
PID|||987654321098||Smith^Alice||19530406|F
PV1||O
PV2||||||||200301310800-0800
IAM|1|DA|^Penicillin|SV^^HL70128|^rash on back|A^^HL70323|12345||AL^^HL70436| 19990127||200301311015|Smith^John|^Husband||C^^HL70438|MLEE^Lee^Mark^^^MD||
MSH|^&~\|ADT|CA.SCA|IE|200301310815-0800||ADT^A60^ADT_A60|6757498734|P|2.5
EVN||200301310815-0800
PID|||987654321098||Smith^Alice||19530406|F
PV1||O
PV2||||||||200301310800-0800
IAM|1|DA|PHM1345^Penicillin^local|SV^^HL70128|^rash on back|A^^HL70323|||AL^^HL70436| 01^Penicillins,Cephalosporins^NDDF DAC|20030127||200301311015| Smith^John|^Husband||C^^HL70438|MLEE^Lee^Mark^^^MD||
Some systems may handle this as a single function. Others may require a multiple process in which:
patient A is assigned a temporary location
patient B is assigned patient A_s location
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.
The term _identifier_ is used throughout this section. An identifier is associated with a set (or sets) of data. For example, an identifier (PID-3 - Patient Identifier List) 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:
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.
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.
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.
This section was written from the perspective of one controlling MPI and does not adequately cover the implementation of peer MPIs or multiple enterprise identifiers. To avoid future problems implementors should carefully examine the inferences of multiple identifiers.
Enterprise level MPI systems may collaborate forming either peer-to-peer or hierarchical relationships. When this occurs, multiple enterprise level identifiers may be required in the context of a single HL7 message. An example of a peer-to-peer MPI relationship might be represented by a data sharing application between the US Department of Veterans Affairs and the US Department of Defense, where each have their own MPI. An example of a hierarchical MPI relationship might be required by the need for local, city, and state organizations to collaborate, where each have an MPI.
These events assume a hierarchy of identifiers exists between person, patient, account, and visit. The hierarchy is as follows:
Level 3 - Patient (identified by PID-3 - Patient Identifier List)
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 - Patient 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.
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 A40 (merge patient - patient identifier list) event would be sent to signal that two person records (identified by MRG-4 - Prior Patient ID and by PID-2 - Patient ID) have been merged into a single record. All of the 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:
Note: It is not the intent of the merge definition to define the application or implementation specifics of how various systems or environments define, use or handle non-surviving information. "Non-surviving" in this document implies that a data set was existing in a fashion that was incorrect. Merging it into a new data set in itself implies that where there were two datasets, there is now only one. The means by which any system or environment conveys this new data set and the absence of the previous data set to the user is application specific. It is noted that some systems may still physically keep these _incorrect_ datasets for audit trail or other purposes.
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.6.2.2.8 _A45 - Move visit information_ for an illustration of this.)
A move event signals that a patient, account, or visit has been moved from one person, patient, or account, respectively, to another. All records at a subordinate level are also moved. For example, an A43 (move patient information - patient identifier list ) 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:
Note: The move event implies that all data related to the incorrect source ID and its subordinate IDs (specified in the MRG segment) will be moved to the correct target ID (specified in the PID or PV1 segment). Specifying each subordinate ID in repeating PID/MRG/PV1 sets is optional but not recommended.
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:
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.
When patient/person identifiers are the target in merge, move, or change events, as specified in the PID-2 - Patient ID, PID-3 - Patient Identifier List and PID-4 - Alternate Patient ID-PID, the associated source identifiers in the MRG-4 - Prior Patient ID, MRG-1 - Prior Patient Identifier List, and MRG-2 - Prior Alternate Patient ID, respectively, must be _tightly coupled._ Each event that is defined as a merge, move, or change message carries the _tightly_ coupled relationship at the appropriate level in one of two ways. First, by virtue of positional placement in the sequence of identifiers, or second, by identifier type and assigning authority. The methodology used to establish the definition of _tightly coupled_ relationship is determined by site negotiation. The recommended definition is by virtue of positional placement in the sequence of identifiers (pairwise). In addition, HL7 allows the use of the second definition by identifier type and assigning authority as an acceptable convention to establish a _tightly coupled_ relationship. In the absence of a site negotiated definition, it is assumed that the positional placement of the identifiers is the default method.
The list of identifiers can be aligned positionally in their respective segment fields and processed by the receiving system by virtue of their order. This is sometimes referred to as an _ordered pairwise_ relationship and is described further in section 3.5.2.1.7.
Alternatively, the uniqueness of the identifiers included in the message is determined by the combination of identifier type and assigning authority. It is assumed that both sending system and receiving system can inspect both of these qualifiers as a message is constructed or processed to determine the _tightly coupled_ relationship between the identifiers. This can be referred to as _identifier type/assigning authority_ relationship and is described further in section 3.5.2.1.8.
The pairing of identifiers between the MRG segment fields and their associated identifiers in the PID or PV1 segment are defined below:
3.4.12.0 PDA field definitions
3.4.12.1 PDA-1 Death Cause Code (CE) 01574
3.4.12.2 PDA-2 Death Location (PL) 10575
3.4.12.3 PDA-3 Death Certified Indicator (ID) 01576
3.4.12.4 PDA-4 Death Certificate Signed Date/Time (TS) 01577
3.4.12.5 PDA-5 Death Certified by (XCN) 01578
3.4.12.6 PDA-6 Autopsy Indicator (ID) 01579
3.4.12.7 PDA-7 Autopsy Start and End Date/Time (DR) 01580
3.4.12.8 PDA-8 Autopsy Performed by (XCN) 01581
3.4.12.9 PDA-9 Coroner Indicator (ID) 01582
3.5 EXAMPLE TRANSACTIONS
3.5.1 Admit/visit notification - event A01 (admitted patient)
3.5.2 Pre-admit notification - event A05 (nonadmitted patient)
3.5.3 Register a patient - event A04 (nonadmitted patient)
3.5.4 Change an outpatient to an inpatient - event A06
3.5.5 Transfer patient - event A02 (first example)
3.5.6 Cancel transfer - event A12
3.5.7 Transfer patient - event A02 (second example)
3.5.8 Discharge patient - event A03
3.5.9 Update adverse reaction info - unique identifier is provided - event A60 (where unique identifier is provided)
3.5.10 Update adverse reaction info - allergen code provides unique identifier - event A60 (where the allergen code provides unique identifier)
3.6 IMPLEMENTATION NOTES
3.6.1 Swapping a patient
3.6.2 Merging patient/person information
3.6.2.1 Definitions: Merge, move, and change identifier events
3.6.2.1.1 Hierarchy of Identifiers
3.6.2.1.2 Merge
3.6.2.1.3 Move
3.6.2.1.4 Change identifier
3.6.2.1.5 Source and target identifiers
3.6.2.1.6 Tightly coupled relationship
Person | ||
PID-2 - Patient ID | with | MRG-4 - Prior Patient ID |
Patient | ||
Pid-3 - Patient Identifier List | with | MRG-1 - Prior Patient Identifier List |
| and by | Explicit order of identifiers in the list |
| or by |
|
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 |
A : X |
B : Y |
C : Z |
A second scenario may arise which deserves mention. As in the list example above, elements _A_, _B_, and _C_ in the first list would _pair-up_ with elements _X_, _Y_, _Z_, _Q_, _R_, and _S_ in the second list. Again, no consideration is made to the type or value of the corresponding elements, it is the order and presence which controls the association process. This scenario could be expressed as follows:
List1 = {A,B,C}
List2 = {X,Y,Z,Q,R,S}
A : X |
B : Y |
C : Z |
: Q |
: R |
: S |
In the second scenario, the last three elements _Q_, _R_, and _S_ are not affected and their value remains as if no association had been made.
A third scenario may arise which deserves mention. As in the list example above, elements _A_, _B_, _C_, _D_, _E_, and _F_ in the first list would _pair-up_ with elements _X_, _Y_, and _Z_ in the second list. Again, no consideration is made to the type or value of the corresponding elements, it is the order and presence which controls the association process. This scenario could be expressed as follows:
List1 = {A,B,C,D,E,F}
List2 = {X,Y,Z}
A : X |
B : Y |
C : Z |
D : |
E : |
F : |
In the third scenario, the last three elements _D_, _E_, and _F_ are not affected and their value remains the same as if no association had been made.
As stated earlier, the uniqueness of the identifiers included in a message can be determined by the combination of identifier type (t) and assigning authority (a). It is assumed that both sending system and receiving system can inspect both of these qualifiers as a message is constructed or processed. This method is used to determine the _tightly coupled_ relationship between the identifiers. The implementation of this relationship exists between the PID-3 - Patient Identifier List and the MRG-1 - Prior Patient Identifier List. In other words, elements _B^t2^a1_, _C^t3^a1_, _D^t4^a1_, _A^t1^a1_, _E^t5^a1_, and _F^t6^a1_ in the first list would be associated with elements _X^t1^a1_, _Y^t2^a1_, and _Z^t3^a1 in the second list. This scenario could be expressed as follows:
List1 = {B^t2^a1,C^t3^a1,D^t4^a1,A^t1^a1,E^t5^a1,F^t6^a1}
List2 = {X^t1^a1,Y^t2^a1,Z^t3^a1}
B^t2^a1 : Y^t2^a1 |
C^t3^a1 : Z^t3^a1 |
D^t4^a1 : |
A^t1^a1 : X^t1^a1 |
E^t5^a1 : |
F^t6^a1 : |
In this scenario, the three elements which do not have corresponding identifier type and assigning authority _D^t4^a1_, _E^t5^a1_, and _F^t6^a1_ are not affected and their value remains the same as if no association had been made.
A second scenario may arise which deserves mention. In the case of identifier type and assigning authority definition, the elements _A^t1^a1_, _B^t2^a1_, and _C^t3^a1_ in the first list would be associated with elements _X^t4^a1_, _Y^t2^a1_, _Z^t3^a1_, _Q^t1^a1_, _R^t5^a1_, and _S^t6^a1_ in the second list. No consideration is made to the order of the identifiers, it is the identifier type and assigning authority of the corresponding elements which controls the association process. This scenario could be expressed as follows:
List1 = {A^t1^a1,B^t2^a1,C^t3^a1}
List2 = {X^t4^a1,Y^t2^a1,Z^t3^a1, Q^t1^a1,R^t5^a1,S^t6^a1}
A^t1^a1 : Q^t1^a1 |
B^t2^a1 : Y^t2^a1 |
C^t3^a1 : Z^t3^a1 |
: X^t4^a1 |
: R^t5^a1 |
: S^t6^a1 |
In the second scenario, the three elements which do not have corresponding identifier type and assigning authority _X^t4^a1_, _R^t5^a1_, and _S^t6^a1_ are not affected and their value remains the same as if no association had been made.
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.6.2.2.3, _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 - patient identifier list) (Section 3.6.2.2.2, _A40 - merge patient - patient identifier list (repeating segment),_ A41 (merge account - patient account number) (Section 3.6.2.2.4, _A41 - merge account - patient account number (repeating segment)_), and A45 (move visit information-visit number) (Section 3.6.2.2.9 _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.6.2.2.2, _A40 - merge patient - patient identifier list (repeating segment),_ 3.6.2.2.4, _A41 - merge account - patient account number (repeating segment),_ and 3.6.2.2.9, _A45 - move visit information - visit number (repeating segment),_ or to explicitly identify individual subordinate identifiers as illustrated in Section 3.6.2.2.9, _A45 - move visit information - visit number (repeating segment)._
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.
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 Identifier List and MRG-1 - Prior Patient Identifier List) and person identifiers (PID-2 - Patient ID and MRG-4 - Prior Patient ID) should also be reported in the message.
The intent of trigger events A40 (merge patient- patient identifier list), A41 (merge account-patient account number), A42 (merge visit-visit number), A43 (move patient information-patient identifier list), A44 (move account information-patient account number), A45 (move visit information-visit number), A47 (change patient identifier list), 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.
A40 - Merge patient - patient identifier list |
---|
Use Case - During the admission process, the registrar does not find a record for patient Allison Smith in the ADT system and creates a new record with patient identifier MR2. Allison Smith has actually been to the healthcare facility several times in the past under her maiden name, Allison Evans with patient identifier MR1. The problem persists for a while. During that time, several more accounts are assigned to Allison under her newly created patient ID MR2. Finally, the problem is discovered and Medical Records merges her two charts together leaving patient identifier MR1. All the accounts (ACCT1, ACCT2) that were assigned to MR2 are combined under MR1 as a result. |
Target: PID-3 - Patient Identifier List (Note: PID-18 - Patient Account Number is not valued; all accounts associated with MR2 are combined under MR1). To merge PID-18 - Patient Account Number data only, use event A41 (merge account-patient account number). To move PID-18 - Patient Account Number data use event A44 (move account information-patient account number). |
Source: MRG-1 - Prior Patient Identifier List) (Note: MRG-3 - Prior Patient Account Number is not valued; all accounts associated with MR2 are combined under MR1.) |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A40^ADT_A39|00000003|P|2.5<cr>
EVN|A40|200301051530<cr>
PID|||MR1^^^XYZ||EVANS^ALLISON|....<cr>
MRG|MR2^^^XYZ<cr>
Before Merge | After Merge |
MR1 MR2
ACCT1 ACCT1 ACCT2 ACCT2 |
MR1
ACCT1 ACCT2 ACCT1 ACCT2 |
3.6.2.2.2 A40 - merge patient - patient identifier list (repeating segment)
A40 - Merge patient - patient identifier list |
---|
Use Case - During the admission process, the registrar does not find a record for patient Allison Smith in the Patient Administration system and creates a new record with patient identifier MR2. Allison Smith has actually been to the healthcare facility several times in the past under her maiden name, Allison Evans with patient identifier MR1. The problem persists for a while. During that time, several more accounts are assigned to Allison under her newly created patient ID MR2. Finally, the problem is discovered and Medical Records merges her two charts together leaving patient identifier MR1. All the accounts (ACCT1, ACCT2) that were assigned to MR2 are combined under MR1 as a result. Since the account numbers are not unique, they are also renumbered. |
Target: PID-3 - Patient Identifier List and PID-18 - Patient Account Number |
Source: MRG-1 - Prior Patient Identifier List and MRG-3 - Prior Patient Account Number |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A40^ADT_A39|00000003|P|2.5<cr>
EVN|A40|200301051530<cr>
PID|||MR1^^^XYZ||EVANS^ALLISON|||||||||||||ACCT3<cr>
MRG|MR2^^^XYZ||ACCT1<cr>
PID|||MR1^^^XYZ||EVANS^ALLISON|||||||||||||ACCT4<cr>
MRG|MR2^^^XYZ||ACCT2<cr>
Before Merge | After Merge |
MR1 MR2
ACCT1 ACCT1* ACCT2 ACCT2* |
MR1
ACCT1 ACCT2 ACCT3* ACCT4* *accounts renumbered |
Implementation considerations: This scenario exists when two medical records are established for the same person.
If the account numbers are not unique (as implied by the After Merge example above) and renumbering of the accounts is required, you must use repeating segments as illustrated in the Example Transaction. Refer to Section 3.6.2.1.9, _Global merge and move message construct versus repeating segment message constructs,_ for additional information regarding message construct. Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. In the example above, the implementation allowed the older demographic information (in the PID) to survive. The demographics implied by the IDs in the MRG segment, did not survive. Surviving and non-surviving demographic information is application and implementation specific. An A08 (update patient information) event should be sent and/or negotiated as necessary to provide for implementation and application specific needs. |
A41 - Merge account information - patient account number |
---|
Use Case - Mary Jones (patient identifier MR1) is a recurring outpatient at the Physical Therapy clinic at hospital XYZ with account number ACCT1. She has visited the clinic several times. When she arrives for therapy, a new registrar does not realize she already has an account and opens a new one with account number ACCT2. When the mistake is discovered, the two accounts are merged together, combining all visits under account ACCT1. |
Target: PID-18 - Patient Account Number |
Source: MRG-3 - Prior Patient Account Number |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A41^ADT_A39|00000005|P|2.5<cr>
EVN|A41|200301051530<cr>
PID|||MR1^^^XYZ||JONES^MARY||19501010|M|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>
MRG|MR1^^^XYZ||ACCT2<cr>
Before Merge | After Merge |
MR1
ACCT1 96124 96126 ACCT2 96128 96130 |
MR1
ACCT1 96124 96126 96128 96130 |
Implementation considerations: This scenario exists when two accounts are established for the same patient.
The PV1 segment is not valued since this event is really a merge at the PID-18 - Patient Account Number level. All identifiers below the PID-18 - Patient Account Number are combined under the surviving Patient Account Number. Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. Surviving and non-surviving demographic information is application and implementation specific. An A08 (update patient information) event should be sent and/or negotiated as necessary to provide for implementation and application-specific needs. |
A41 - Merge account - patient account number |
---|
Use Case - Mary Jones (patient identifier MR1) is a recurring outpatient at the Physical Therapy clinic at hospital XYZ with account number ACCT1. She has visited the clinic several times. When she arrives for therapy, a new registrar does not realize she already has an account and opens a new one with account number ACCT2. When the mistake is discovered, the two accounts are merged together, combining all visits under account ACCT1. |
Target: PID-18 - Patient Account Number and PV1-19 - Visit Number |
Source: MRG-3 - Prior Patient Account Number and MRG-5 - Prior Visit Number |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A41^ADT_A39|00000005|P|2.5<cr>
EVN|A41|200301051530<cr>
PID|||MR1^^^XYZ||JONES^MARY||19501010|F|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>
MRG|MR1^^^XYZ||ACCT2||VISIT1<cr>
PV1|1|I|||||||||||||||||VISIT3<cr>
PID|||MR1^^^XYZ||JONES^MARY||19501010|F|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>
MRG|MR1^^^XYZ||ACCT2||VISIT2
PV1|1|I|||||||||||||||||VISIT4<cr>
Before Merge | After Merge |
MR1
ACCT1 VISIT1 VISIT2 ACCT2 VISIT1* VISIT2* *Visits erroneously assigned |
MR1
ACCT1 VISIT1 VISIT2 VISIT3** VISIT4** **Visits combined and renumbered as a result of merging the account |
Implementation considerations: This scenario exists when two accounts and associated visits are established for the same patient.
Repeating PID/MRG/PV1 segments report each Account Number and Visit Number effected. This construct is required since the visits are renumbered in this example. Since there could be a discrepancy in the demographic information between the two records, reconciliation may be required. Surviving and non-surviving demographic information is application and implementation specific. An A08 (update patient information) event should be sent and/or negotiated as necessary to provide for implementation and application-specific needs. |
3.6.2.2.5 A42 - Merge visit - visit number
A42 - Merge visit - visit number |
---|
Use Case - A42 (merge visit -visit number) - Mary Jones (patient identifier MR1) is a recurring outpatient at the Physical Therapy clinic at hospital XYZ with account number ACCT1. She has visited the clinic several times. When she arrives for therapy, two different registrars create a new visit numbers. The mistake is not discovered immediately and clinical data is recorded under both visit numbers. When the mistake is discovered, the two visits are merged together, leaving visit VISIT1. |
Target: PV1-19 - Visit Number |
Source: MRG-5 - Prior Visit Number |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A42^ADT_A39|00000005|P|2.5<cr>
EVN|A42|200301051530<cr>
PID|||MR1^^^XYZ||JONES^MARY||19501010|F|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>
MRG|MR1^^^XYZ||ACCT1||VISIT2<cr>
PV1|1|I|||||||||||||||||VISIT1
Before Merge | After Merge |
MR1
ACCT1 VISIT1 VISIT2 |
MR1
ACCT1 VISIT1 |
Implementation considerations: This scenario exists when two visits are established in error for the same patient and episode of care. |
3.6.2.2.6 A43 - move patient information - patient identifier list
A43 - Move patient information - patient identifier list |
---|
Use Case - information from ABC HMO is loaded to a repository system each month. Jane Jones is entered in January and assigned Enterprise Number 1 (E1). Jane has visited Hospital XYZ and is assigned medical record number MR1. Jayne Jones (a different person) is also a member of ABC HMO loaded to the repository and assigned Enterprise Number E2. Jayne has visited Hospital XYZ and is assigned medical record number MR1. Jayne visits Clinic DEF where she is assigned medical record number MR2 which is erroneously associated with Jane_s Enterprise Number (E1). When the error is discovered MR2 is moved from Enterprise Number E1 to E2. |
Target: PID-2 - Patient ID |
Source: MRG-4 - Prior Patient ID |
MSH|^~\&|REPOSITORY|ENT|RSP1P8|MCM|200301051530|SEC|ADT^A43^ADT_A43|0000009|P|2.5<cr>
EVN|A43|200301051530<cr>
PID|1|E2|MR2^^^ABCHMO|||JONES^JAYNE|....<cr>
MRG|MR2^^^ABCHMO|||E1<cr>
Before Move | After Move |
E1 E2
MR1 MR1 MR2 |
E1 E2
MR1 MR1 MR2 |
Implementation considerations: PID-3 - Patient Identifier List and MRG-1 - Prior Patient Identifier List are the same value since the PID-3 value does not change in this scenario.
The example above would be expressed as follows. In the following example, the assigning authority ENT1 represents an Enterprise and the PE identifier type code represents the Person_s Enterprise number. The MR1 identifier is omitted from the message because it is not moved. |
MSH|^~\&|REPOSITORY|ENT|RSP1P8|MCM|200301051530|SEC|ADT^A43^ADT_A43|0000009|P|2.5<cr>
EVN|A43|200301051530<cr>
PID|1||E2^^^ENT1^PE~MR2^^^ABCHMO^MR|||JONES^JAYNE|....<cr>
MRG|E1^^^ENT1^PE~MR2^^^ABCHMO^MR|. . .<cr>
A44 - Move account information - patient account number |
---|
Use Case - During the admission process, the admitting clerk uses the Medical Record Number of William A. Jones III (MR1) instead of William A. Jones, Jr. (MR2). The Patient Administration system assigns the new admission account number ACCT2. When the mistake is discovered, account ACCT2 is moved to the correct Medical Record, MR2. The account number is not changed. |
Target: PID-3 - Patient Identifier List and PID-18 - Patient Account Number (Note: PID-18 - Patient Account Number and MRG-3 - Prior Patient Account Number will be the same since the account number does not change in this scenario). |
Source: MRG-1 - Prior Patient Identifier List and MRG-3 - Prior Patient Account Number (NOTE: MRG-3 - Prior Patient Account Number must be valued to indicate which account to move) |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A44^ADT_A43|00000007|P|2.5<cr>
EVN|A44|200301051530<cr>
PID|||MR2^^^XYZ||JONES^WILLIAM^A^JR||19501010|M|||123 EAST STREET^^NY^NY^10021||(212)111-3333|||S||ACCT2<cr>
MRG|MR1^^^XYZ||ACCT2<cr>
Before Move | After Move |
MR1 MR2
ACCT1 ACCT1 ACCT2 |
MR1 MR2
ACCT1 ACCT1 ACCT2 |
Implementation considerations: This scenario exists when two medical records legitimately exist for two different people and an account is incorrectly associated with the wrong medical record number. |
3.6.2.2.8 A45 - move visit information - visit number (repeating segment)
A45 - Move visit information - visit number |
---|
Use Case - Mary Jones (patient identifier MR1) is a recurring outpatient at the Physical Therapy and Speech Therapy clinics at hospital XYZ. She is assigned a different account for each clinic; her account number for Physical Therapy is ACCT1 and her account number for Speech Therapy is X1. However, on two different occasions, the Speech Therapy registrar accidentally assigned her visits (96102 and 96104) to the Physical Therapy account. The problem is later discovered and the corresponding visits are moved to the correct account. |
Target: PID-18 - Patient Account Number and PV1-19 - Visit Number. |
Source: MRG-3 - Prior Patient Account Number and MRG-5 - Prior Visit Number. |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A45^ADT_A45|00000005|P|2.5<cr>
EVN|A45|200301051530<cr>
PID|||MR1^^^XYZ||JONES^MARY||19501010|M|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||X1<cr>
MRG|MR1^^^XYZ||ACCT1||96102<cr>
PV1||O|PT||||||||||||||||96102<cr>
MRG|MR1^^^XYZ||ACCT1||96104<cr>
PV1||O|PT||||||||||||||||96104<cr>
Before Move | After Move |
MR1
ACCT1 96100 96102* 96104* X1 96101 96103 96105 *Visits erroneously assigned |
MR1
ACCT1 96100 X1 96101 96102 96103 96104
96105
|
In the above transaction/implementation, the application that generated the message assigns unique visit numbers.
Implementation Considerations: In this scenario the repeating MRG/PV1 construct is used to indicate which visits are moved, as illustrated in the Example Transaction. MRG-5 - Prior Visit Number and PV1-19 - Visit Number are the same values because the visit numbers do not change. Refer to Section 3.6.2.1.9, _Global merge and move message construct versus repeating segment message constructs,_ for additional information regarding message construct. |
3.6.2.2.9 A45 - move visit information - visit number (repeating segment)
A45 - Move visit information - visit number |
---|
Use Case -Mary Jones (patient identifier MR1) is a recurring outpatient at the Physical Therapy and Speech Therapy clinics at hospital XYZ. She is assigned a different account for each clinic; her account number for Physical Therapy is ACCT1 and her account number for Speech Therapy is X1. However, on two different occasions, the Speech Therapy registrar accidentally assigned her visits (VISIT2 and VISIT3) to the Physical Therapy account. The problem is later discovered and the corresponding visits are moved to the correct account. |
Target: PID-18 - Patient Account Number and PV1-19 - Visit Number. |
Source: MRG-3 - Prior Patient Account Number and MRG-5 - Prior Visit Number. |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A45^ADT_A45|00000005|P|2.5<cr>
EVN|A45|200301051530<cr>
PID|||MR1^^^XYZ||JONES^MARY||19501010|M|||123 NORTH STREET^^NY^NY^10021||(212)111-3333|||S||X1<cr>
MRG|MR1^^^XYZ||ACCT1||VISIT2<cr>
PV1||O|PT||||||||||||||||VISIT4<cr>
MRG|MR1^^^XYZ||ACCT1||VISIT3<cr>
PV1||O|PT||||||||||||||||VISIT5<cr>
Before Move | After Move |
MR1
ACCT1 VISIT1 VISIT2* VISIT3* X1 VISIT1 VISIT2 VISIT3 *Visits erroneously assigned |
MR1
ACCT1 VISIT1 X1 VISIT1 VISIT2 VISIT3 VISIT4** VISIT5** **visits moved and renumbered |
In the above transaction/implementation, the application that generated the message allows non-unique visit numbers.
Implementation Considerations: If Visit Numbers are not unique (as implied by the After Move example above) and renumbering of the visits is required, you must use a repeating MRG/PV1 construct as illustrated in the Example Transaction. Refer to 3.6.2.2.1, _A40 - merge patient - patient identifier list,_ for additional information regarding message construct. |
3.6.2.2.10 A47 - change patient identifier list
A47 - Change patient identifier list |
---|
Use Case - The Medical Records Department of XYZ hospital uses a system of manual medical record number assignment. During the admission process, the registrar accidentally assigned the wrong Medical Record Number (MR2 instead of MR1) to John Meyers. Since the correct Medical Record has not yet been assigned to any patient, no merge takes place. The Patient Identifier List is simply changed. |
Target: PID-3 - Patient Identifier List |
Source: MRG-1 - Prior Patient Identifier List |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A47|00000002|P|2.5<cr>
EVN|A47|200301051530<cr>
PID|||MR1^^^XYZ||MEYERS^JOHN||19501010|M|||987 SOUTH STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>
MRG|MR2^^^XYZ||ACCT1<cr>
Before Change | After Change |
MR2
ACCT1 |
MR1
ACCT1 |
Implementation considerations: None. |
3.6.2.2.11 A49 - change patient account number
A49 - Change patient account number |
---|
Use Case - Patients are automatically assigned an account number by hospital XYZ_s Patient Administration system at admission. However, when the Patient Administration system is down, the admitting clerk manually assigns account numbers from a pool of downtime account numbers. John Rodriguez (patient ID MR1) was manually assigned downtime account number ACCT1. When the Patient Administration system came back up, the admitting clerk accidentally entered the wrong account number, X1, into the system. When the problem was later discovered, the account number was changed from X1 to ACCT1. |
Target: PID-18 - Patient Account Number |
Source: MRG-3 - Prior Patient Account Number |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A49^ADT_A30|00000006|P|2.5<cr>
EVN|A49|200301051530<cr>
PID|||MR1^^^XYZ||RODRIGUEZ^JOHN||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|ACCT1<cr>
MRG|MR1^^^XYZ||X1<cr>
Before Change | After Change |
MR1
X1 |
MR1
ACCT1 |
Implementation Considerations: None. |
3.6.2.2.12 A50 - change visit number
A50 - Change visit number |
---|
Use Case - Patients are automatically assigned a visit number by hospital XYZ_s Patient Administration system at check-in. However, when the Patient Administration system is down, the admitting clerk manually assigns visit numbers from a pool of downtime numbers. John Rodriguez (patient ID MR1) was manually assigned downtime visit number VISIT1. When the Patient Administration system came back up, the admitting clerk accidentally entered the wrong visit number, VISIT2, into the system. When the problem was later discovered, the visit number was changed from VISIT2 to VISIT1. |
Target: PV1-19 - Visit Number |
Source: MRG-5 - Prior Visit Number |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A50^ADT_A50|00000006|P|2.5<cr>
EVN|A50|200301051530<cr>
PID|||MR1^^^XYZ||RODRIGUEZ^JOHN||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|ACCT1<cr>
MRG|MR1^^^XYZ||ACCT1||VISIT2<cr>
PV1|1|O||3|||99^BROWN^JERRY|||ONC||||1||VIP|99^BROWN^JERRY|O/P|VISIT1...<cr>
Before Change | After Change |
MR1
ACCT1 VISIT2 |
MR1
ACCT1 VISIT1 |
Implementation considerations: None. |
3.6.2.2.13 A51 - change alternate visit ID
A51 - Change alternate visit ID |
---|
Use Case - Patients are automatically assigned an alternate visit number by hospital XYZ_s Patient Administration system at check-in. However, when the Patient Administration system is down, the admitting clerk manually assigns alternate visit numbers from a pool of downtime numbers. John Rodriguez was manually assigned downtime alternate visit number AV1. When the Patient Administration system came back up, the admitting clerk accidentally entered the wrong alternate visit number, AV2, into the system. When the problem was later discovered, the alternate visit number was changed from AV2 to AV1. |
Target: PV1-50 - Alternate Visit ID |
Source: MRG-6 - Prior Alternate Visit ID |
Example Transaction: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SECURITY|ADT^A51^ADT_A50|00000006|P|2.5<cr>
EVN|A51|200301051530<cr>
PID|||MR1^^^XYZ||RODRIGUEZ^JOHN||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|ACCT1<cr>
MRG|MR1^^^XYZ||ACCT1|||AV2<cr>
PV1|1|O||3|||99^BROWN^JERRY|||ONC||||1||VIP|99^BROWN^JERRY|O/P|V1|SP|||||||||||||||||||A|||||19990902081010||||||AV1<cr>
Before Change | After Change |
MR1
ACCT1 VISIT1 AV2 |
MR1
ACCT1 VISIT1 AV1 |
Implementation Considerations: None. |
3.6.2.2.14 Example using multiple messages
A47 - Change patient identifier list and A49 - Change patient account number |
---|
Use Case - Patients are automatically assigned Medical Records Numbers and account numbers by hospital XYZ_s Patient Administration system at admission. However, when the Patient Administration system is down, the admitting clerk manually assigns account numbers and Medical Records numbers from a pool of downtime numbers. John Rodriguez was manually assigned downtime Medical Record Number MR1 and downtime account number A1. When the Patient Administration system came back up, the admitting clerk accidentally enters the wrong Medical Record Number (MR2) and account number (X1) into the system. The error occurred because she was reading from the paperwork for a different downtime admit not yet entered into the Patient Administration system. The problem is quickly discovered, and the medical record number and account number was fixed accordingly. Since the other downtime admit had not yet been entered into the Patient Administration system, no merge was required. |
Target: PID-3 - Patient Identifier List (Message 1) and PID-18 - Patient Account Number (Message 2) |
Source: MRG-1 - Prior Patient Identifier List (Message 1) and MRG-3 - Prior Patient Account Number (Message 2) |
Example Transaction - Message 1: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A47^ADT_A30|00000006|P|2.5<cr>
EVN|A47|200301051530<cr>
PID|||MR1^^^XYZ^MR||RODRIGUEZ^JOHN||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|X1<cr>
MRG|MR2^^^XYZ^MR|<cr>
Example Transaction - Message 2: |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A49^ADT_A30|00000006|P|2.5<cr>
EVN|A49|200301051530<cr>
PID|||MR1^^^XYZ^MR||RODRIGUEZ^JOHN||19501010|M|||123 SOUTH STREET^^NY^NY^10021||(212)111-2222|||S|CAT|ACCT1<cr>
MRG|MR1^^^XYZ^MR||X1<cr>
Before Change | After Change |
MR2
X1 |
MR1
ACCT1 |
Implementation considerations: Message 1 (A47) changes the patient identifier list. Message 2 (A49) changes the account number. |
3.6.2.2.15 Example using multiple messages
A44 - Move account information - patient account number and A49 - Change patient account number |
---|
Use Case - During the admitting process, the admitting clerk uses the Medical Record Number of William A. Jones, III (MR1) instead of William A. Jones, Jr. (MR2). The Patient Administration system assigns the new admission account number A1. When the mistake is discovered, the account is moved to the correct Medical Record, MR2. The Patient Administration system generates a new account number as a result: number X1. |
Target: PID-3 - Patient Identifier List (Message 1) and PID-18 - Patient Account Number (Message 2) |
Source: MRG-1 - Prior Patient Identifier List (Message 1) and MRG-3 - Prior Patient Account Number (Message 2) |
Example Transaction (Message 1): |
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A44^ADT_A30|00000007|P|2.5<cr>
EVN|A44|200301051530<cr>
PID|||MR2^^^XYZ^MR||JONES^WILLIAM^A^JR||19501010|M|||123 EAST STREET^^NY^NY^10021||(212)111-3333|||S||ACCT1<cr>
MRG|MR1^^^XYZ^MR||ACCT1<cr>
Example Transaction (Message 2):
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|200301051530|SEC|ADT^A49^ADT_A30|00000007|P|2.5<cr>
EVN|A49|200301051530<cr>
PID|||MR2^^^XYZ^MR||JONES^WILLIAM^A^JR||19501010|M|||123 EAST STREET^^NY^NY^10021||(212)111-3333|||S||X1<cr>
MRG|MR2^^^XYZ^MR||ACCT1<cr>
Before Change | After Change |
MR1 MR2
ACCT1 |
MR1 MR2
X1 |
Implementation Considerations: Message 1, A44 (move account information-patient account number), moves the account from MR1 to MR2. Message 2, A49 (change patient account number), changes the account number. |
Linking two or more patients does not require the actual merging of patient information as discussed in Section 3.6.2, _ Merging patient/person information;_ following a link trigger event, sets of affected patient data records should remain distinct. However, because of differences in database architectures, there may be system-dependent limitations or restrictions regarding the linking of one or more patients that must be negotiated.
There are multiple approaches for implementing Master Patient Indexes. It is useful for the purpose of MPI mediation to support two types of linkage. Explicit linkage requires a message declaring a link has been made between multiple identifiers. Implicit linkage is performed when a receiving system infers the linkage from the presence of multiple identifiers present in PID-3 - Patient Identifier List.
In an MPI setting, the A24 -link patient information message is preferred for transmitting an explicit link of identifiers whether they are in the same or different assigning authorities. The A37 unlink patient information message is preferred for transmitting the explicit unlinking of identifiers.
Implicit linkage of identifiers, sometimes called passive linking, has been implemented using various messages. An acknowledged method is inclusion of multiple identifiers in PID-3 - Patient Identifier List, which the receiving system implicitly links. An MPI or application that makes such an implicit linkage can generate an A24 - link patient information message to explicitly notify another system of this action.
The purpose of this section is to provide some insight into how HL7 committees have approached the area of MPI integration, as well as to provide concrete examples of how the integration could be done using messages in Version 2.4 and later.
There can be quite a bit of confusion as to what defines an MPI. Early definitions called it a Master Patient Index, implying only patient data would be managed. Later the definition was expanded to mean persons in general, including patients, guarantors, subscribers, and even providers; essentially any entity that could be considered a _person._ Thus the current acronym MPI generally is inferred to mean Master Person Index.
An MPI is generally used to manage person identification and cross-reference across disparate systems. Healthcare organizations may have several systems handling various different data processing needs, from laboratory to billing, each with its own database of persons and person identifier numbering schemes. Each of these can be called an ID Domain. An MPI can function as a Correlation Manager between these domains, providing a cross-reference of a person_s identifiers across each of the domains. Typically an MPI will also have one universal or enterprise identifier that uniquely identifies the person in the MPI itself. The domain for this identifier may or may not be the domain for clients of the MPI.
MPI functionality also typically includes methods to provide an identifier for a person, given a set of traits or demographics for that person. An example of the use of this is for a client system to query the MPI for a person given a set of demographics. The MPI uses matching algorithms to find possible matching persons, and returns to the client system the identifiers for those persons.
This section currently deals only with MPI functionality related to persons in the context of Version 2.4 and later. It is assuming integration using Version 2. ADT messages, and the functionality surrounding finding and identifying a person.
There has been an effort to harmonize the modeling work that has been done in the CORBAMed Patient Identification Service (PIDS) with the HL7 message set, with an eye toward HL7 Version 3.0. You may see evidence of CORBAMed modeling in this implementation, but that should not be taken as evidence that full harmonization has taken place. There is much work left to do in this area.
Several QBP/RSP queries have been developed to aid in the integration of systems with an MPI. They consist of several Qxx/Kxx trigger/response pairs and one Q24/K24 trigger/response pair. The following table lists their functions:
MPI QBP/RSP Queries
3.6.3 Patient record links
3.6.4 MPI Integration - an introduction
3.6.4.0
3.6.4.1 Definitions - what is an MPI?
3.6.4.2 HL7 and CORBAmed PIDS
3.6.4.3 MPI QUERY for person lookup and identification
Query | Name | MPI Use |
---|---|---|
Q21/K21 | Get Person Demographics | Given a person identifier, return the PID and optionally the PD1 segments for the matching person. |
Q22/K22 | Find Candidates | Given some demographics, optionally a match threshold and algorithm, find and return a list of matching persons. |
Q23/K23 | Get Corresponding Identifiers | Given a person_s identifier and a list of identifier domains, return the person_s identifiers in those domains. |
Q24/K24 | Allocate Identifiers | Given a list of identifier domains, return new identifiers for those domains. Should not link to a person, just reserve and return identifiers. |
The following sections show several scenarios involving looking up a person on a _client_ system, and how it can be integrated to an MPI. The basic flow is for a user to enter person information on the client system, and the client system using services of the MPI to match the user_s input to a person that exists somewhere on the two systems.
The scenarios are differentiated on two variables:
ID Creator - Which system assigns new person identifiers for the client system. This can either be the MPI or the client system.
Person Existence - On which system the person record currently exists - the client system, the MPI, or both.
In this scenario, a client system (e.g. a registration system) will query an MPI for a person that does not currently exist on the client system. The MPI returns a list of one or more possible matching candidates, and one is chosen by the user on the client system. The client system assigns the person an identifier and an update is sent to the MPI to notify it of the new assigned identifier.
Figure 3-1 - Client system assigns identifier, person exists on MPI only
The messages are defined as follows:
Q22/K22 Find Candidates - This signals the MPI to search its database for a list of persons that match the demographic criteria sent in the query, using whatever algorithms it has at its disposal, or using the algorithm optionally specified in the query. The response includes a list of _candidates_ that matched the criteria in the query, one PID segment for each candidate. The query can also specify the identifier domains to return in PID-3 - Patient Identifier List, so that the client system identifier and the MPI enterprise identifier could be returned for each match.
Q21/K21 Get Person Demographics - Once a candidate is chosen from the list, another query may be done to retrieve the full set of demographics for that person.
A24 or A01/A04/A05 - This transaction is to update the MPI with the new identifier the client system has created for the person. It is acceptable for systems to simply send an A01 Admit/visit notification, A04 Register a patient or A05 Pre-admit a patient as may have been done traditionally, with the new client system identifier and the existing MPI enterprise identifier in PID-3. However an A24 Link patient information may be sent instead, with one PID segment containing the MPI enterprise identifier for the person, and the second PID segment containing the new registration system identifier.
In this scenario, a client system (e.g. a registration system) will query an MPI for a person, and the person record exists on both systems. The MPI returns a list of possible matching candidates, and one is chosen by the user on the client system. The client system simply asks the MPI for an updated set of demographics and does not assign an identifier since the person already exists with an identifier on the client system.
Prior to querying the MPI, the client system may query its own database to reduce network transactions. However, the full searching capabilities of the MPI may be preferred to the client system in order to prevent the selection of the wrong person.
Figure 3-2 - Client system assigns identifier, person exists on both systems
The message flow is identical to the message flow in the 3.5.4.1 example, with the exception that the final update to the MPI is not needed in order to give the MPI a new identifier for the person. The MPI should already have the client system identifier from previous transactions.
An ADT event may be sent later by the client system simply to update the MPI with any demographic changes that occur.
In this scenario, a client system (e.g. a registration system) will query an MPI for a person, and the person does not exist on either system. The MPI returns a list of possible matching candidates, or possibly an empty list. The user does not choose one, and a new person record is created.
Figure 3-3 - Client system assigns identifier, does not exist on either system
The message flow again begins with a Q22/K22 Find Candidates query. The response may or may not contain a list of candidates.
If the client system assigns a person identifier when the record is created, an A28 Add person information could be sent to the MPI to notify it of the record creation. If the client system does not create an identifier until the registration is completed, the A01, A04 or A05 events could serve the purpose of notifying the MPI of an added person and identifier. The fact that the person will have an identifier unknown to the MPI, and no enterprise identifier, will allow the MPI to infer that a person record is being added.
When the person record is added to the MPI with the new identifier, an enterprise identifier is assigned, and ancillary systems may be notified of the new person record creation.
In the next set of three scenarios, it is assumed that a third party (ID Manager) creates identifiers for the client system, and for these examples the MPI fulfills this role. The QBP/RSP queries support this service.
Figure 3-4 - Example of two healthcare organizations merging
Figure 3-4 shows a case where identifiers may need to be assigned by a third party. In the example, East Health Organization had one identifier domain (XXXX numbers) for both the hospital registration system and the outpatient clinic registration numbers. Coordination was done through the use of pre-printed charts for new patients, which prevented the two systems from using the same XXXX number for two patients.
Later West Health Organization is bought and merged with East. West has been using its own identifier domain (YYYY numbers). An MPI is also implemented to keep a cross-reference between the two systems, and assigns its own enterprise identifier (EEEE number) to each patient.
Because the organization is attempting to go paperless, East decides to forgo its pre-printed charts, but still keep the XXXX numbers. Since the pre-printed charts are no longer there to keep numbers from being re-used between the hospital and clinic, a third party is needed to assign the XXXX numbers.
A patient arrives at East Hospital that had never been there, but had been to West previously. To register the patient, the hospital system submits a Find Candidates Q22/K22 query to get from the MPI a list of possible matching patients. The user finds the patient since she had been to West previously. Since the patient is new to East, she must be given a new East identifier (XXXX number). An Allocate Identifiers A56/K24 query is sent from the East Hospital to the MPI and the MPI generates an XXXX number and returns it. Later when the registration is finished, an A24 Link Person Information message is sent to notify the MPI that the allocated identifier has been assigned to a patient
In the following first scenario, the person record exists on the MPI, however it does not exist on the client system. The message flow assumes that the MPI is assigning identifiers for the client system that are not the enterprise identifiers. If this were not the case, the Allocate Identifiers A56/K24 query would not be needed.
Figure 3-5 - MPI assigns identifier, person exists on MPI
The message flow is similar to previous examples, with the exception of the Q24/K24 Allocate Identifiers query and the final A24 Link Patient Information message:
Q24/K24 Allocate Identifiers - This query is for the client system to ask the MPI for an identifier in the client system_s domain. It is not to assign the identifier to a particular person record, but rather just to reserve an identifier for later use.
A24 Link patient information - This message is to notify the MPI that the previously allocated identifier has been assigned to a person. The A24 should include one PID segment with the new identifier and one PID segment with the MPI enterprise identifier.
is scenario is identical to the scenario in 3.5.4.2 Client system assigns identifier, person exists on both systems.
Figure 3- 6 - MPI assigns identifier, person exists on both systems
In this scenario, the person does not exist on either system. The message flow is similar to 3.5..4.4 MPI assigns identifier, person exists on MPI, however there is no need for the Q21/K21Get person Demographics query as a double-check for the user since the person does not exist on the MPI. Also, after the person is registered and the identifier assigned, an A28 Add Person Information is sent to the MPI to have it add the person to its database and assign an enterprise identifier.
Figure 3-7 - MPI assigns identifier, person exists on neither system
The species attribute is required for non-human patients. The breed and strain attributes are conditional. Thus if the strain attribute is populated, the species attribute must be populated, but the breed attribute is optional. The production class attribute is optional, but if populated the species attribute must also be populated. The name of the animal populates the PID-5 attribute, component 2. The last name of the owner may populate component 1 of PID-5. Owner information is transmitted in the NK1 segment.
Example 1: Mrs. Jones brings her 9 year old, female, spayed miniature poodle, Fluffy, into the University of California, Davis Veterinary Medical Teaching Hospital to have skin growths removed. The poodle resides with Mrs. Jones in her apartment at 1634 J St, Apt 214, in Davis, CA 95616, Yolo county;
MSH|^~\&||UC Davis VMTH|||199902171830||ADT^A04<cr>
PID|1||A83245^^^VMTH^MR^UCD||Jones^Fluffy^^^^^^D||19901001|S|||1634 J St^Apt 214^Davis^CA^95616^USA^^^Yolo||||||||||||CA||||||||||||L-80700^Canine, NOS^SNM3|L-80832^Miniature Poodle, NOS^SNM3<cr>
PV1|1|O||R|||0045^Griffin^John^^Dr.^DVM||||||||||||||||||||||||||||||||||||199902161015<cr>
NK1|1|Jones^Eunice^M^^Mrs.^^L|O|1634 J St^Apt 214^Davis^CA ^95616^USA^^^Yolo|(530) 555-4325^^^emjones123@AOL.COM||CP|
OBX|1|NM|21611-9^Age^LN||9|yr<cr>
OBX|2|NM|3141-9^Body Weight^LN||16|lb<cr>
Example 2: Over the Hill Horses owns the Morgan horse mare named Breeze that is referred by Dr. Schuster of Foothill Veterinary Clinic for colic (acute abdominal pain) to the University of California, Davis Veterinary Medical Teaching Hospital. The manager of the farm and contact person is Randall _Buck_ Shins, who works at the farm headquarters in Chester, CA, 96020:
MSH|^~\&||Foothill Veterinary Clinic||UC Davis VMTH|199902171830||ADT^A04<cr>
PID|1||N324256^^^^^Foothill Vet Clinic||^Breeze^^^^^^D|||F|||^^^CA^^^^^Lassen||||||||||||||||||19981123|Y|||||L-80400^Horse^SNM3|L-80431^Morgan horse^SNM3||BR<cr>
PV1|1|E||R|||^Schuster^^^Dr.^DVM||||||||||||||||||||||||||||||||||||199903102013<cr>
NK1|1||||||O|||||Over the Hill Horses|||||||||||||||||~Shins^Buck^^^Mr.^^N|(530) 555-9843^^^Buckshins@OvertheHill.com|23 West Main^Suite A^Chester^CA^96020^^^^Lassen<cr>
HCFA, Health Care Financing Administration, U.S. Dept. of Health and Human Services, USA
CMS, Centers for Medicare/Medicaid Services
ERISA: Employment Retirement Income Security Act, USA
LOINC: Lab Observation Identifier Names and Codes, Regenstrief Institute, Indianapolis, IN, USA
CORBAMed Person Identification Service (PIDS) - Adopted Submission. 12 February 1998.