HL7 V2 messaging is widely used in Australia, including the transmission of Pathology results from laboratories to providers. This section provides a broad overview of the format and function of pathology messages before detailing specific elements in detail. Electronic ordering is less well developed currently but is used in some arenas and provides significant potential advantages for the requester and filler of laboratory tests.

HL7 V2 was developed before the introduction of xml or json and the format is text based and unique to HL7 v2. It was originally designed to pass 7 bit channels, optimizes file size and in Australia by default uses the ASCII character set as described in the appendix on parsing HL7 v2. Implementers should read and understand Appendix 1 Parsing HL7v2. The file format contains no field names and requires pre-existing knowledge of its structure to process. It is highly storage and bandwidth efficient however.

Most results between laboratories and providers are currently sent in unsolicited mode, where no electronic order was sent, but a paper request was used. An HL7v2 ORU^R01 message is used for this and an example appears below.

 

MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY:3.1.2^L|QML^2184^AUSNATA|||20160612150255+1000||ORU^R01|BGC06121502965-8968|P|2.3.1^AUS&&ISO^AS4700.2&&L|||AL||AUS
PID|||12345678^^^^MR~5432109876^^^AUSHIC^MC||ANTHONY^JENNIFER^KAY||19490709|F|||225 Wises Road^^BUDERIM^QLD^4551||^^^^^^54455055||||||4157269354
PV1|1|O||||||0488077Y^MCKENZIE^RAY^^^DR^^^AUSHICPR^L^^^PRN|0191324T^MCINTYRE^ANDREW^^^DR^^^AUSHICPR^L^^^PRN
ORC|RE||15-57243112-CBC-0^QML^2184^AUSNATA||CM|||||||0488077Y^MCKENZIE^RAY^^^DR^^^AUSHICPR^L^^^PRN
OBR|1||15-57243112-CBC-0^QML^2184^AUSNATA|CBC^MASTER FULL BLOOD COUNT^2184|||20151221|||||||201512211940||0488077Y^MCKENZIE^RAY^^^DR^^^AUSHICPR^L^^^UPIN||From QML"QMLG4399292.oru" 17.03.2016||DR=UMA2P,LN=15-57243112,RC=Y||201603171124||HM|F||^^^201512210000|0488077Y^MCKENZIE^RAY^^^DR^^^AUSHICPR^L^^^UPIN~0191324T^MCINTYRE^ANDREW^^^DR^^^AUSHICPR^L^^^UPIN||||123457Z&Davidson&David&&MBBS&Dr.
OBX|1|ST|15430-2^^LN||FULL BLOOD EXAMINATION||||||F
OBX|2|NM|718-7^Haemoglobin^LN||121|g/L|115-160||||F|||201512212329
OBX|3|NM|789-8^Red Cell Count^LN||3.8|10*12/L|3.6-5.2||||F|||201512212329
OBX|4|NM|4544-3^Haematocrit^LN||0.38||0.33-0.46||||F|||201512212329
OBX|5|NM|787-2^Mean Cell Volume^LN||100|fL|80-98|+|||F|||201512212329
OBX|6|NM|785-6^Mean Cell Haemoglobin^LN||32|pg|27-35||||F|||201512212329
OBX|7|NM|777-3^Platelet Count^LN||393|10*9/L|150-450||||F|||201512212329
OBX|8|NM|6690-2^White Cell Count^LN||8.8|10*9/L|4.0-11.0||||F|||201512212329
OBX|9|NM|770-8^Neutrophils^LN||53|%|||||F|||201512212329
OBX|10|NM|751-8^Neutrophils^LN||4.7|10*9/L|2.0-7.5||||F
OBX|11|NM|736-9^Lymphocytes^LN||30|%|||||F|||201512212329
OBX|12|NM|731-0^Lymphocytes^LN||2.6|10*9/L|1.1-4.0||||F
OBX|13|NM|5905-5^Monocytes^LN||14|%|||||F|||201512212329
OBX|14|NM|742-7^Monocytes^LN||1.2|10*9/L|0.2-1.0|+|||F
OBX|15|NM|713-8^Eosinophils^LN||3|%|||||F|||201512212329
OBX|16|NM|711-2^Eosinophils^LN||0.26|10*9/L|0.04-0.40||||F
OBX|17|NM|706-2^Basophils^LN||0|%|||||F|||201512212329
OBX|18|NM|704-7^Basophils^LN||0.00|10*9/L|< 0.21||||F
OBX|19|FT|5909-7^Interpretation^LN||Comment:\.br\Mild monocytosis and borderline high mean cell volume.  Other significant haematology parameters are within normal limits for age and sex.\.br\||||||F|||201512212329

 

When this message is received and Acknowledgement message is produced and returned to the laboratory.

MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY:3.1.2^L|Demo Server^1FFA8984-7166-4655-B195-7B4FFFD2F136^GUID|EQUATORDXTRAY^EQUATORDXTRAY:3.1.2 (Build 6387) [win32-i386] {SVV=76;DBV=76}^L|QML^2184^AUSNATA|20160612150923+1000||ACK^R01|HOM06121509607-198|P|2.3.1^AUS&&ISO^AS4700.2&&L|||||AUS
MSA|AA|BGC06121502965-8968

 

These two messages are the backbone of result delivery and acknowledgement of delivery for pathology delivery. The first message is the results of the laboratory evaluation (a document), in this case a Full Blood Count, with a message wrapper to address the message and enable the delivery to be confirmed by the second message which is produced by the recipient and returned to the laboratory. The security and authentication around delivery is out of scope of this standard.

Messages are a stream of text which is divided into segments by the CR (ASCII13) character. Each segment starts with a three letter code identifying the content of the segment. eg "MSH", "PID", "OBX" etc. These segments are further defined by the standard to contain fields which are separated by the "|" character. Each field can optionally repeat and each repeat (if present) is separated by the "~" character. The fields themselves are divided into components by the "^" character and the components are divided into SubComponents by the "&" character. There are no levels of hierarchy possible below this. The text content of Fields/components or subcomponents must escape any delimitors used in HL7 ie |^~\& or Line breaks (ASCII 13/10). Escape sequences are provided for this. eg \.br\ replaces a line break in the original text. 

The segments in a message are specified by the standard and are ordered, can be optional and can optionally repeat. Each message type, which is specified in the MSH segment has its own segment structure, but all start with a MSH segment. This creates a hierarchy at the level of the specific message. The full structure of a ORU^R01 message (The main message used to deliver results) is detailed below. This is the full international message structure and in Australia PV1 has been made mandatory and some optional segments have been removed. The Australian message structure is detailed in the section on Observation Reporting.

Legend:

"{}"  Repeat

"[]" Optional

 

ORU^R01           Unsolicited Observation Message
MSH Message Header
{
    [
       PID Patient Identification
       [PD1] Additional Demographics
       [{NK1}] Next of Kin/Associated Parties
       [{NTE}] Notes and Comments
       PV1 Patient Visit
       [PV2] Patient Visit - Additional Info
    ]
    {
        [ORC] Order common
        OBR Observations Report ID
        [CTD] Contact Data
        {
            [OBX] Observation/Result
        }
    }
}
[DSC] Continuation Pointer

 Note that the message structure has been constrained compared with the international standard. This link demonstrates the original message structure: International ORU Structure

In the example message the MSH segment (Line 1) gives this message a Unique ID "BGC06121502965-8968" and Indicated it was sent by QML Pathology "QML^2184^AUSNATA". The response, The ACK^R01 message indicates that this message has been recieved using the Message Acknowledgment Segment (MSA, Line 2) with the original message ID "MSA|AA|BGC06121502965-8968" . The "AA" indicates "Application Accept".

In the PV1 segment, in field 9, the provider this message was delivered to is indicated as "0191324T^MCINTYRE^ANDREW^^^DR^^^AUSHICPR^L^^^PRN"

The message contains a report. The report header is in the OBR Segment (Line 5) and the report has a Unique ID which will never change even if the report is updated "15-57243112-CBC-0^QML^2184^AUSNATA". It also gives the name of the report and who ordered it and who has been sent copies of the report along with the date the test was done.

 

The OBX segments, on lines 6-24, contain the atomic data that form the actual result. Each atomic result is identified with a code (eg Line 7 "718-7^Haemoglobin^LN") and a data type, in this case mostly Numeric(NM).

The details of the other fields and conventions, localized for Australia,  are specified in this standard, which should be read in concert with the International standard.

In the case of an electronic order a ORM^O01 message is sent to the laboratory and this is responded to with a ORR^O02 message.

MSH|^~\&|MERIDIAN^MERIDIAN:3.1.4 (Build 6934) [win32-i386]^L|Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID||QML^2184^AUSNATA|20160814205041+1000||ORM^O01^ORM_O01|XX08142050015-2604|P|2.3.1^AUS&&ISO^AS4700.2&&L|||||AUS
PID|1|....
PV1||O||||||||||||||V1||||BULKBILL
ORC|NW|BGC-00013065-1^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID||BGC-00013065^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID|||||201608142050+1000|||0191324T^MCINTYRE^ANDREW^K^^DR^^^AUSHICPR^L^^^UPIN|||201608142049+1000||||||Buderim GE Centre
OBR|1|BGC-00013065-1^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID||26604007^Full Blood Count^SCT|||||||L|||||0191324T^MCINTYRE^ANDREW^K^^DR^^^AUSHICPR^L^^^UPIN|||||||||||^^^^^R|254327KW^HEFFERNAN^DAMIEN^^^DR^^^AUSHICPR^L^^^UPIN|||||||||||^Pregnant:False~^Fasting:True~^Radiotherapy:False~^Hormonal Therapy:False
OBX|1|FT|11492-6^History and Physical Notes^LN||This is a test message\.br\||||||F|||201608142050+1000

This message is requesting a Full Blood Count encoded as "26604007^Full Blood Count^SCT" from QML Laboratories encoded as "QML^2184^AUSNATA" with an order number of "BGC-00013065-1^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID". "ORC|NW|" indicates this is a new order. In the order we specify the ordering provider in the ORC segment which is "0191324T^MCINTYRE^ANDREW^K^^DR^^^AUSHICPR^L^^^UPIN" and request a copy be sent to "254327KW^HEFFERNAN^DAMIEN^^^DR^^^AUSHICPR^L^^^UPIN" in the OBR Segment.

 

The response to this message is as below

MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY:3.1.4 (Build 6896) [win32-i386] {SVV=78;DBV=76}^L|Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID|MERIDIAN^MERIDIAN:3.1.4 (Build 6934) [win32-i386]^L|Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID|20160814205104+1000||ORR^O02|BGC08142051838-6830|P|2.3.1^AUS&&ISO^AS4700.2&&L|||||AUS
MSA|AA|XX08142050015-2604
PID|1|....
ORC|OK|BGC-00013065-1^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID||BGC-00013065^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID|||||201608142050+1000|||0191324T^MCINTYRE^ANDREW^K^^DR^^^AUSHICPR^L^^^UPIN|||201608142049+1000||||||Buderim GE Centre
OBR|1|BGC-00013065-1^Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID||26604007^Full Blood Count^SCT|||||||L|||||0191324T^MCINTYRE^ANDREW^K^^DR^^^AUSHICPR^L^^^UPIN|||||||||||^^^^^R|254327KW^HEFFERNAN^DAMIEN^^^DR^^^AUSHICPR^L^^^UPIN|||||||||||^Pregnant:False~^Fasting:True~^Radiotherapy:False~^Hormonal Therapy:False


The MSA segment "MSA|AA|XX08142050015-2604" indicates this message has been accepted and the ORC value of "ORC|OK|" indicates the order has been accepted.

 

The combination or the ORU^R01 report message and its response and the ORM^O01 order message and its acknowledgement are the backbone of pathology messaging. The details of the order and report messages are covered in subsequent sections. Segments common to all message processing are covered in this section. In some settings the messages and segments used in the examples will be all that is encountered in normal usage but the international standard covers similar messages used in queries for orders and results and these will be seen in some settings but are no covered in this guide. Messages can be batched into files using a single batch inside a File Header structure as illustrated below. In Australia only one Batch is supported but a batch can contain any number of messages. The main purpose of this wrapper is to ensure the collection of messages has not been truncated in transport as the file should end with a BTS and FTS and this should be checked for when processing files.  The specification of the segments used in many HL7v2 message types is provided in section 2.1, where usage notes and some example values are provided.


FHS|^~\&|EQUATORDXTRAY:0.12.8 (Build 310)|1FFA8984-7166-4655-B195-7B4FFFD2F136|||20050417220634+1000
BHS|^~\&|EQUATORDXTRAY:0.12.8 (Build 310)|1FFA8984-7166-4655-B195-7B4FFFD2F136|||20050417220634+1000
MSH|^~\&|EQUATORDXTRAY^EQUATORDXTRAY:0.12.8 (Build 310)^L|Demo Server^1FFA8984-7166-4655-B195-7B4FFFD2F136^GUID|||20050417220634+1000||ORU^R01|20050417.736428|P|2.3.1^AUS&&ISO^0.9&&L|||AL||AUS
PID|1||100333^^^Medical-Objects&7C3E3682-91F6-11D2-8F2C-444553540000&GUID^SR^Demo Server&1FFA8984-7166-4655-B195-7B4FFFD2F136&GUID||TESTER^Testy^^^Mr^^L||19900101|M|||3 Drury Lane^^NAMBOUR^QLD^4560^AUS^H||61(07)54455055^PRN^PH^^61^07^54455055|||||||||||||||||N
PV1|1|O||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN|0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN|||||||N
ORC|RE||E062CF28-A67B-45D6-A5F8-B1423EDFB093^Demo Server^1FFA8984-7166-4655-B195-7B4FFFD2F136^GUID||CM|||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN
OBR|1||E062CF28-A67B-45D6-A5F8-B1423EDFB093^Demo Server^1FFA8984-7166-4655-B195-7B4FFFD2F136^GUID|11486-8^Chemotherapy Record^LN|||20050417+1000|||||||||0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN||From Demo Server in File 20050417.736425 dated 17.04.2005||LN=E062CF28-A67B-45D6-A5F8-B1423EDFB093||200504172206+1000||PHY|C||^^^20050417+1000|0191322W^ANDERSON^THOMAS^^^DR^^^AUSHICPR^L^^^UPIN||||0191322W&ANDERSON&THOMAS&&&Dr&&AUSHICPR&AUSHICPR
OBX|1|NM|3141-9^Weight^LN||70|kg^^ISO+|||||F
OBX|2|NM|28325-9^Performance Status^LN||2||||||F
OBX|3|ST|21946-9^Chemotherapy Rx^LN||CHOP||||||F
OBX|4|FT|11486-8^^LN||This is a record of chemo being given.\.br\||||||F
BTS|1||1
FTS|1

 


ACKNOWLEDGEMENT PROCESSING

The HL7 standard specifies two levels of acknowledgement processing: Original and Enhanced Modes.

(a) Original Mode, specifies that the message be acknowledged at the application level. The reasoning is that it is not sufficient to know that the underlying communications system guaranteed delivery of the message. It is also necessary to know that the receiving application processed the data successfully at a logical application level.

(b) Enhanced mode, The HL7 acknowledgment paradigm has been extended to distinguish both accept and application acknowledgments. With a positive accept acknowledgment, the receiving system commits the message to safe storage in a manner that releases the sending system from the need to resend the message. After the message has been processed by the receiving system, an application acknowledgment may be used to return the resultant status to the sending system.

This standard recommends the use of Enhanced Mode Acknowledgment.

2.1 MESSAGE CONTROL SEGMENTS 

The following segments are necessary to support the functionality described in this chapter.

If a value is the usual default for use in Australia it has been highlighted in blue.

 

Figure 2-8. HL7 message segments 

Segment Category

Segment Name

HL7 Section Reference

Control

ADD2.1.1
 BHS2.1.2
 BTS2.1.3
 DSC 2.1.4 
 ERR2.1.5
 FHS 2.1.6 
 FTS 2.1.7 
 MSA 2.1.8
 MSH2.1.9

2.1.1 ADD - addendum segment

The ADD segment is used to define the continuation of the prior segment in a continuation message. See Section2.15.2, “Continuation messages and segments,” for details.

HL7 Attribute Table - ADD – Addendum

SEQLENDTOPTRP/#TBL# ITEM#ELEMENT NAME
1-n

655

36

36O  00066Addendum Continuation Pointer

2.1.1.0 ADD field definition

2.1.1.1 ADD-1 Addendum continuation pointer (ST) 00066

Definition: This field is used to define the continuation of the prior segment in a continuation message.

See section 2.15.2, “Continuation messages and segments” for details. When the ADD is sent after the segment being continued, it contains no fields. It is only a marker that the previous segment is being continued in a subsequent message. Thus fields 1-N are not present. The sequence designation, 1-N, means the remainder of the fields in the segment being continued. These remainder of the segment being continued fields are present only when the ADD is sent with a continuation message.

2.1.2 BHS - batch header segment

The BHS segment defines the start of a batch.

HL7 Attribute Table - BHS – Batch Header

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
11ST R  00081Batch Field Separator
23STR  00082Batch Encoding Characters
315STO  00083Batch Sending Application
420STO  00084Batch Sending Facility
515STO  00085Batch Receiving Application
620STO  00086Batch Receiving Facility
726TSO  00087Batch Creation Date/Time
840STO  00088Batch Security
920STO  00089Batch Name/ID/Type
1080STO  00090Batch Comment
1120STO  00091Batch Control ID
12 20ST   00092 Reference Batch Control ID 

2.1.2.0 BHS field definitions

2.1.2.1 BHS-1 Batch field separator (ST) 00081

Definition: This field contains the separator between the segment ID and the first real field, BHS-2-batch encoding characters. As such it serves as the separator and defines the character to be used as a separator for the rest of the message. Recommended value is |,(ASCII 124).

2.1.2.2 BHS-2 Batch encoding characters (ST) 00082

Definition: This field contains the four characters in the following order: the component separator, repetition separator, escape characters, and subcomponent separator. Recommended values are ^~\& (ASCII 94,126, 92, and 38, respectively). See Section 2.8, “MESSAGE DELIMITERS.”

2.1.2.3 BHS-3 Batch sending application (ST) 00083

Definition: This field uniquely identifies the sending application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined.

2.1.2.4 BHS-4 Batch sending facility (ST) 00084

Definition: This field contains the address of one of several occurrences of the same application within the sending system. Absent other considerations, the Medicare Provider ID might be used with an appropriate sub-identifier in the second component. Entirely user-defined.

2.1.2.5 BHS-5 Batch receiving application (ST) 00085

Definition: This field uniquely identifies the receiving applications among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined.

2.1.2.6 BHS-6 Batch receiving facility (ST) 00086

Definition: This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations. See comments BHS-4-batch sending facility. Entirely site-defined.

2.1.2.7 BHS-7 Batch creation date/time (TS) 00087

Definition: This field contains the date/time that the sending system created the message. If the time zone is specified, it will be used throughout the message as the default time zone.

2.1.2.8 BHS-8 Batch security (ST) 00088

Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified.

2.1.2.9 BHS-9 Batch name/ID/type (ST) 00089

Definition: This field can be used by the application processing the batch. It can have extra components if needed.

2.1.2.10 BHS-10 Batch comment (ST) 00090

Definition: This field is a comment field that is not further defined in the HL7 protocol.

2.1.2.11 BHS-11 Batch control ID (ST) 00091

Definition: This field is used to uniquely identify a particular batch. It can be echoed back in BHS-12-reference batch control ID if an answering batch is needed.

2.1.2.12 BHS-12 Reference batch control ID (ST) 00092

Definition: This field contains the value of BHS-11-batch control ID when this batch was originally transmitted.

Not present if this batch is being sent for the first time. See definition for BHS-11-batch control ID.

2.1.3 BTS - batch trailer segment

The BTS segment defines the end of a batch.

HL7 Attribute Table - BTS – Batch Trailer

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
110STO  00093Batch Message Count
280STO  00090Batch Comment
3100NM OY 00095Batch Totals

2.1.3.0 BTS field definitions

2.1.3.1 BTS-1 Batch message count (ST) 00093

Definition: This field contains the count of the individual messages contained within the batch.

2.1.3.2 BTS-2 Batch comment (ST) 00090

Definition: This field is a comment field that is not further defined in the HL7 protocol.

2.1.3.3 BTS-3 Batch totals (NM) 00095

Definition: We encourage new users of this field to use the HL7 Version 2.3 data type of NM and to define it as “repeating.” This field contains the batch total. If more than a single batch total exists, this field may be repeated.

This field may be defined as a CM data type for backward compatibility with HL7 Versions 2.2 and 2.1with each total being carried as a separate component. Each component in this case is an NM data type.

2.1.4 DSC - continuation pointer segment

The DSC segment is used in the continuation protocol.

HL7 Attribute Table - DSC – Continuation Pointer

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
180 ST   00014Continuation Pointer
1ID  039801354 Continuation Style 

2.1.4.0 DSC field definitions

2.1.4.1 DSC-1 Continuation pointer (ST) 00014

Definition: This field contains the continuation pointer. In an initial query, this field is not present. If the responder returns a value of null or not present, then there is no more data to fulfill any future continuation requests. For use with continuations of unsolicited messages, see chapter 5 and section 2.15.2, "Continuation messages and segments.” Note that continuation protocols work with both display- and record-oriented messages.

2.1.4.2 DSC-2 Continuation style (ID) 01354

Definition: Indicates whether this is a fragmented message (see Section 2.15.2, "Continuation messages and segments"), or if it is part of an interactive continuation message (see Section 5.6.3, "Interactive continuation of response messages").

Refer to HL7 Table 0398 – Continuation style code for valid values.

HL7 Table 0398 - Continuation style code

ValueDescription
FFragmentation
IInteractive Continuation

 2.1.5 ERR - error segment

The ERR segment is used to add error comments to acknowledgment messages.

HL7 Attribute Table - ERR –Error

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
180CMRY 00024Error Code and Location

2.1.5.0 ERR field definition

2.1.5.1 ERR-1 Error code and location (CM) 00024

Components: <segment ID (ST)> ^ <sequence (NM)> ^ <field position (NM)> ^ <code identifying error (CE)>

Definition: This field identifies an erroneous segment in another message. The second component is an index if there is more than one segment of type <segment ID>. For systems that do not use the HL7 Encoding Rules, the data item number may be used for the third component. The fourth component (which references HL7 Table 0357 - Message error condition codes, (as a CE data type)) is restricted from having any subcomponents as the subcomponent separator is now the CE’s component separator.

Note: See section 2.1.8.6, MSA-6-error condition, for a listing of this table.

2.1.6 FHS - file header segment

The FHS segment is used to head a file (group of batches) as defined in Section 2.15.3, “HL7 batch protocol.”

HL7 Attribute Table - FHS - File Header   

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
11STR  00067File Field Separator
24STR  00068File Encoding Characters
315STO  00069File Sending Application
420STO  00070File Sending Facility
515STO  00071File Receiving Application
620STO  00072File Receiving Facility
726TSO  00073File Creation Date/Time
840STO  00074File Security
920STO  00075File Name/ID
1080STO  00076File Header Comment
1120STO  00077File Control ID
1220STO  00078Reference File Control ID

2.1.6.0 FHS field definitions

2.1.6.1 FHS-1 File field separator (ST) 00067

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.2 FHS-2 File encoding characters (ST) 00068

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.3 FHS-3 File sending application (ST) 00069

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.4 FHS-4 File sending facility (ST) 00070

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.5 FHS-5 File receiving application (ST) 00071

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.6 FHS-6 File receiving facility (ST) 00072

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.7 FHS-7 File creation date/time (TS) 00073

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.8 FHS-8 File security (ST) 00074

Definition: This field has the same definition as the corresponding field in the MSH segment.

2.1.6.9 FHS-9 File name/ID (ST) 00075

Definition: This field can be used by the application processing file. Its use is not further specified.

2.1.6.10 FHS-10 File header comment (ST) 00076

Definition: This field contains the free text field, the use of which is not further specified.

2.1.6.11 FHS-11 File control ID (ST) 00077

Definition: This field is used to identify a particular file uniquely. It can be echoed back in FHS-12-reference file control ID.

2.1.6.12 FHS-12 Reference file control ID (ST) 00078

Definition: This field contains the value of FHS-11-file control ID when this file was originally transmitted.

Not present if this file is being transmitted for the first time.

2.1.7 FTS - file trailer segment

The FTS segment defines the end of a file.

HL7 Attribute Table - FTS - File Trailer

SEQ LENDTOPTRP/#TBL#ITEM #ELEMENT NAME
110NMO  00079File Batch Count
280STO  00080File Trailer Comment

2.1.7.0 FTS field definitions

2.1.7.1 FTS-1 File batch count (NM) 00079

Definition: This field contains the number of batches contained in this file.

2.1.7.2 FTS-2 File trailer comment (ST) 00080

Definition: The use of this free text field is not further specified.

2.1.8 MSA - message acknowledgment segment

The MSA segment contains information sent while acknowledging another message.

HL7 Attribute Table - MSA - Message Acknowledgment

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
12IDR 000800018Acknowledgment Code
220STR  00010Message Control ID
380STO  00020Text Message
415NMO  00021Expected Sequence Number
51IDB 010200022Delayed Acknowledgment Type
6250 CEO 035700023Error Condition

2.1.8.0 MSA field definitions

2.1.8.1 MSA-1 Acknowledgment code (ID) 00018

Definition: This field contains an acknowledgment code, see message processing rules. Refer to HL7 Table 0008 - Acknowledgment code for valid values.

HL7 Table 0008 - Acknowledgment code

ValueDescription 
AAOriginal mode: Application Accept - Enhanced mode: Application acknowledgment: Accept 
AE Original mode: Application Error - Enhanced mode: Application acknowledgment: Error 
AROriginal mode: Application Reject - Enhanced mode: Application acknowledgment: Reject 
CA Enhanced mode: Accept acknowledgment: Commit Accept 
CEEnhanced mode: Accept acknowledgment: Commit Error 
CR Enhanced mode: Accept acknowledgment: Commit Reject 

2.1.8.2 MSA-2 Message control ID (ST) 00010

Definition: This field contains the message control ID of the message sent by the sending system. It allows the sending system to associate this response with the message for which it is intended.

2.1.8.3 MSA-3 Text message (ST) 00020

Definition: This optional field further describes an error condition. This text may be printed in error logs or presented to an end user.

Use of MSA-3-text message and MSA-6-error condition are deprecated in favor of ERR-1-Error code and location. The ERR segment allows for richer descriptions of the erroneous conditions.

2.1.8.4 MSA-4 Expected sequence number (NM) 00021

Definition: This optional numeric field is used in the sequence number protocol.

2.1.8.5 MSA-5 Delayed acknowledgment type (ID) 00022

Definition:  This field has been retained for backward compatibility.   This field is used only as described above, in Section 2.13.2, “Application (level 7) processing rules, deferred processing two phase reply (original acknowledgment mode only).” Otherwise this field is not used.

HL7 Table 0102 - Delayed acknowledgment type

ValueDescription
DMessage received, stored for later processing
Facknowledgment after processing

2.1.8.6 MSA-6 Error condition (CE) 00023

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field allows the acknowledging system to use a user-defined error code to further specify AR or AE type acknowledgments. This field is a generalized replacement for MSA-3-text message .

Use of MSA-3-text message  and MSA-6-error condition  are deprecated in favor of ERR-1 -Error code and location. The ERR segment allows for richer descriptions of the erroneous conditions.

The Message Error Condition codes are defined by HL7 Table 0357 - Message error condition codes.

HL7 Table 0357 - Message error condition codes

Error Condition CodeError Condition Text Description/Comment
Success  
0Message accepted

Success. Optional, as the AA conveys success. Used for systems that must always return a status code.

Errors  
100Segment sequence errorThe message segments were not in the proper order, or required segments are missing.
101Required field missingA required field is missing from a segment
102Data type errorThe field contained data of the wrong data type, e.g. an NM field contained "FOO".
103Table value not foundA field of data type ID or IS was compared against the corresponding table, and no match was found.
Rejection  
200Unsupported message typeThe Message Type is not supported.
201Unsupported event codeThe Event Code is not supported.
202Unsupported processing idThe Processing ID is not supported.
203Unsupported version idThe Version ID is not supported.
204Unknown key identifierThe ID of the patient, order, etc., was not found. Used for transactions other than additions, e.g. transfer of a non-existent patient.
205Duplicate key identifierThe ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.).
206 Application record locked  The transaction could not be performed at the application storage level, e.g. database locked. 
207 Application internal error   A catchall for internal errors not explicitly covered by other codes.

2.1.9 MSH - message header segment

The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message.

HL7 Attribute Table - MSH - Message Header

SEQLENDTOPTRP/#TBL#ITEM #ELEMENT NAME
11STR  00001Field Separator
2STR  00002Encoding Characters
3180 HDO 0361 00003Sending Application
4180HDO 036200004Sending Facility
5180HDO 036100005Receiving Application
6180HDO 036200006Receiving Facility
726TSR  00007Date/Time Of Message
840STO  00008Security
913CM 0076/000300009Message Type
1020STR  00010Message Control ID
113PTR  00011Processing ID
1260VIDR 010400012Version ID
1315NMO  00013Sequence Number
14180STO  00014Continuation Pointer
152IDO 015500015Accept Acknowledgment Type
162IDO 015500016Application Acknowledgment Type
173IDO 039900017Country Code
1816IDOY021100692Character Set
19250CEO  00693Principal Language Of Message
2020ID  035601317 Alternate Character Set Handling Scheme 
2110ID O0449 01598  Conformance Statement ID

2.1.9.0 MSH field definitions

2.1.9.1 MSH-1 Field separator (ST) 00001

Definition: This field contains the separator between the segment ID and the first real field, MSH-2-encoding characters. As such it serves as the separator and defines the character to be used as a separator for the rest of the message. Recommended value is |, (ASCII 124).

2.1.9.2 MSH-2 Encoding characters (ST) 00002

Definition: This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. Recommended values are ^~\& (ASCII 94,126, 92, and 38, respectively). In the Australian context the separators are fixed to these values.

2.1.9.3 MSH-3 Sending application (HD) 00003

Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

Definition: This field uniquely identifies the sending application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined.

User-defined Table 0361-Sending/receiving application is used as the user-defined table of values for the first component.

User-defined Table 0361 – Sending/receiving application

ValueDescription
MERIDIAN^MERIDIAN:3.1.4 (Build 6934) [win32-i386]^LExample application identifier
Best Practice 1.8.5.743Application identifier with only namespace ID valued
PRSLT^HL7PIT^LExample Lab Sending application

Note: By site agreement, implementors may continue to use User-defined Table 0300 – Namespace ID  for the first component.

2.1.9.4 MSH-4 Sending facility (HD) 00004

Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

Definition: This field further describes the sending application, MSH-3-sending application . With the promotion of this field to an HD data type, the usage has been broadened to include not just the sending facility but other organizational entities such as a) the organizational entity responsible for sending application; b) the responsible unit; c) a product or vendor’s identifier, etc. Entirely site-defined.

User-defined Table 0362 – Sending/receiving facility is used as the HL7 identifier for the user-defined table of values for the first component.

User-defined Table 0362 – Sending/receiving facility

ValueDescription
Buderim GE Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUIDExample sending facility identified with GUID
QML^2184^AUSNATALab example using AUSNATA as coding scheme

Note: By site agreement, implementers may continue to use User-defined Table 0300 – Namespace ID  for the first component.

2.1.9.5 MSH-5 Receiving application (HD) 00005

Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

Definition: This field uniquely identifies the receiving application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined. User-defined Table 0361- Sending/receiving application is used as the HL7 identifier for the user-defined table of values for the first component.

Note: By site agreement, implementers may continue to use User-defined Table 0300 – Namespace ID  for the first component.

2.1.9.6 MSH-6 Receiving facility (HD) 00006

Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

Definition: This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations. 

User-defined Table 0362 – Sending/receiving facility is used as the HL7 identifier for the user-defined table of values for the first component. Entirely site-defined.

Note: By site agreement, implementers may continue to use User-defined Table 0300 – Namespace ID  for the first component.

2.1.9.7 MSH-7 Date/time of message (TS) 00007

Definition: This field contains the date/time that the sending system created the message. If the time zone is specified, it will be used throughout the message as the default time zone.

Note: This field was made required in version 2.4. Messages with versions prior to 2.4 are not required to value this field. This usage supports backward compatibility.

2.1.9.8 MSH-8 Security (ST) 00008

Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified.

2.1.9.9 MSH-9 Message type (CM) 00009

Components: <message type (ID)> ^ <trigger event (ID)> ^ <message structure (ID)>

Definition: This field contains the message type, trigger event, and the message structure ID for the message.

The first component is the message type code defined by HL7 Table 0076 - Message type. This table contains values such as ACK, ADT, ORM, ORU etc. See section 2.17.1 or Appendix A for complete listing.

The second component is the trigger event code defined by HL7 Table 0003 - Event type. This table contains values like A01, O01, R01 etc. See section 2.17.2 or Appendix A for a complete listing

The third component is the abstract message structure code defined by HL7 Table 0354 - Message structure.

This table has two columns. The first column contains the value of this code, which describes a particular HL7 “abstract message structure definition” in terms of segments, as defined in sections 2.12, “CHAPTER FORMATS FOR DEFINING HL7 MESSAGES” and 2.12.1, “HL7 abstract message syntax example”. The second column of table 0354 lists the various HL7 trigger events that use the particular abstract message definition. For example, the message structure code ADT_A01 describes the single abstract message structure used by the trigger events A01, A04, A05, A08, A13, A14, A28 and A31. See section 2.17.3 or Appendix A for a complete listing.

The receiving system uses this field to recognize the data segments, and possibly, the application to which to route this message. For certain queries, which may have more than a single response event type, the second component may, in the response message, vary to indicate the response event type. See the discussion of the display query variants in chapter 5. The second component is not required on response or acknowledgment messages.

2.1.9.10 MSH-10 Message control ID (ST) 00010

Definition: This field contains a number or other identifier that uniquely identifies the message. The receiving system echoes this ID back to the sending system in the Message acknowledgment segment (MSA).

2.1.9.11 MSH-11 Processing ID (PT) 00011

Components: <processing ID (ID)> ^ <processing mode (ID)>

Definition: This field is used to decide whether to process the message as defined in HL7 Application (level 7) Processing rules. The first component defines whether the message is part of a production, training, or debugging system (refer to HL7 Table 0103 - Processing ID for valid values). The second component defines whether the message is part of an archival process or an initial load (refer to HL7 Table 0207 - Processing mode for valid values). This allows different priorities to be given to different processing modes. The value used in normal usage is highlighted in blue.

HL7 Table 0103 - Processing ID

ValueDescription
DDebugging
PProduction
TTraining

HL7 Table 0207 - Processing mode

ValueDescription
AArchive
RRestore from archive
IInitial load
TCurrent processing, transmitted at intervals (scheduled or on demand)
Not presentNot present (the default, meaning current processing) 

2.1.9.12 MSH-12 Version ID (VID) 00012

Components: <version ID (ID)> ^ <internationalization code (CE)> ^ <internal version ID (CE)>

Definition: This field is matched by the receiving system to its own version to be sure the message will be interpreted correctly. Beginning with Version 2.3.1, it has two additional “internationalization” components, for use by HL7 international affiliates. The <internationalization code> is CE data type (using the ISO country codes where appropriate) which represents the HL7 affiliate. The <internal version ID> is used if the HL7 Affiliate has more than a single ‘local’ version associated with a single US version. The <internal version ID> has a CE data type, since the table values vary for each HL7 Affiliate.

HL7 Table 0104 - Version ID

ValueDescriptionDate
2.0Release 2.September 1988
2.0DDemo 2.0October 1988
2.1Release 2.1March 1990
2.2Release 2.2December 1994
2.3Release 2.3March 1997
2.3.1 Release 2.3.1  May 1999 
 2.4Release 2.4 November 2000 

2.1.9.13 MSH-13 Sequence number (NM) 00013

Definition: A non-null value in this field implies that the sequence number protocol is in use. This numeric field is incremented by one for each subsequent value.

2.1.9.14 MSH-14 Continuation pointer (ST) 00014

Definition: This field is used to define continuations in application-specific ways.

Only the sender of a fragmented message values this field.

2.1.9.15 MSH-15 Accept acknowledgment type (ID) 00015

Definition: This field identifies the conditions under which accept acknowledgments are required to be returned in response to this message. Required for enhanced acknowledgment mode. Refer to HL7 Table 0155 - Accept/application acknowledgment conditions for valid values.

2.1.9.16 MSH-16 Application acknowledgment type (ID) 00016

Definition: This field contains the conditions under which application acknowledgments are required to be returned in response to this message. Required for enhanced acknowledgment mode.

The following table contains the possible values for MSH-15-accept acknowledgment type and MSH-16- application acknowledgment type:

HL7 Table 0155 - Accept/application acknowledgment conditions

ValueDescription
ALAlways
NENever
ERError/reject conditions only
SUSuccessful completion only

Note: If MSH-15-accept acknowledgment type and MSH-16-application acknowledgment type are omitted (or are both null), the original acknowledgment mode rules are used.

2.1.9.17 MSH-17 Country code (ID) 00017

Definition: This field contains the country of origin for the message. It will be used primarily to specify default elements, such as currency denominations. The values to be used are those of ISO 3166, which are reprinted here upon written approval from ANSI.2. The ISO 3166 table has three separate forms of the country code: HL7 specifies that the 3-character (alphabetic) form be used for the country code.

2 Available from ISO 1 Rue de Varembe, Case Postale 56, CH 1211, Geneve, Switzerland

Refer to HL7 Table 0399 – Country code for the 3-character codes as defined by ISO 3166 table.

HL7 Table 0399 – Country code 

ValueDescription
ABWARUBA
AFGAFGHANISTAN
AFTFRENCH SOUTHERN TERRITORIES
AGOANGOLA
AIAANGUILLA
ALBALBANIA
ANDANDORRA
ANTNETHERLANDS ANTILLES
AREUNITED ARAB EMIRATES
ARGARGENTINA
ARMARMENIA
ASMAMERICAN SAMOA
ATAANTARCTICA
ATGANTIGUA AND BARBUDA
AUSAUSTRALIA
AUTAUSTRIA
AZEAZERBAIJAN
BDIBURUNDI
BELBELGIUM
BEN BENIN 
BFA  BURKINA FASO
BGD BANGLADESH 
BGRBULGARIA 
BHR BAHRAIN 
BHS BAHAMAS 
BIH BOSNIA AND HERZEGOVINA 
BLR BELARUS 
BLZ BELIZE
BMU BERMUDA 
BOL BOLIVIA 
BRA BRAZIL
BRB BARBADOS 
BRN BRUNEI DARUSSALAM 
BTN BHUTAN 
BVTBOUVET ISLAND
BWA BOTSWANA 
CAFCENTRAL AFRICAN REPUBLIC 
CAN CANADA 
CCK COCOS (KEELING) ISLANDS 
CHE SWITZERLAND 
CHL CHILE
CHN CHINA 
CIV COTE D'VOIRE 
CMR CAMEROON 
COD CONGO, THE DEMOCRATIC REPUBLIC OF THE 
COG CONGO 
COK COOK ISLAND 
COL COLOMBIA 
COM COMOROS 
CPV CAPE VERDE 
CRI COSTA RICA 
CUB CUBA
CXR CHRISTMAS ISLAND 
CYM CAYMAN ISLANDS 
CYP CYPRUS 
CZE CZECH REPUBLIC 
DEU GERMANY 
DJIDJIBOUTI 
DMA DOMINICA 
DNK DENMARK 
DOM DOMINICAN REPUBLIC 
DZA ALGERIA 
ECU ECUADOR 
EGY EGYPT 
ERI  ERITREA 
ESH WESTERN SAHARA 
ESP SPAIN
EST ESTONIA 
ETH ETHIOPIA 
FIN FINLAND 
FJI FIJI 
FLK FALKLAND ISLANDS (MALVINAS) 
FRA FRANCE 
FRO FAROE ISLANDS 
FSMMICRONESIA, FEDERATED STATES OF 
GAB GABON 
GBR UNITED KINGDOM 
GEO GEORGIA 
GHA GHANA 
GIB GIBRALTAR 
GIN GUINEA 
GLP GUADELOUPE 
GMB GAMBIA 
GNB GUINEA-BISSAU 
GNQ EQUATORIAL GUINEA 
GRC GREECE 
GRD GRENADA 
GRLGREENLAND
GTM GUATEMALA 
GUF FRENCH GUIANA 
GUM GUAM 
GUY GUYANA 
HKG HONG KONG 
HMD HEARD ISLAND AND MCDONALD ISLANDS 
HND HONDURAS 
HRV CROATIA 
HTI HAITI 
HUN HUNGARY 
IDN INDONESIA 
IND INDIA 
IOT BRITISH INDIAN OCEAN TERRITORY 
IRL IRELAND 
IRN IRAN, ISLAMIC REPUBLIC OF 
IRQ IRAQ 
ISL ICELAND
ISR ISRAEL 
ITA ITALY 
JAM JAMAICA 
JOR JORDAN 
JPN  JAPAN
KAZ  KAZAKSTAN
KEN KENYA 
KGZ KYRGYZSTAN 
KHMCAMBODIA 
KIRKIRIBATI 
KNA SAINT KITTS AND NEVIS 
KOR KOREA, REPUBLIC OF 
KWT KUWAIT 
LAOLAO PEOPLE'S DEMOCRATIC REPUBLIC 
LBN LEBANNON 
LBR LIBERIA 
LBY LIBYAN ARAB JAMAHIRIYA 
LCA SAINT LUCIA 
LIE LIECHTENSTEIN 
LKA SRI LANKA 
LSO LESOTHO 
LTU LITHUANIA 
LUX LUXEMBOURG 
LVA LATIVA 
MAC MACAU 
MAR MOROCCO 
MCO MONACO 
MDA MOLDOVA, REPUBLIC OF 
MDG MADAGASCAR 
MDV MALDIVES 
MEX MEXICO 
MHL MARSHALL ISLANDS 
MKD MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF 
MLI MALI 
MLT MALTA 
MMR MYANMAR 
MNG MONGOLIA 
MNP NORTHERN MARIANA ISLANDS 
MOZ MOZAMBIQUE 
MRT MAURITANIA 
MSR MONTSERRAT 
MTQ MARTINIQUE 
MUS MAURITUS 
MWI MALAWI 
MYS MALAYSIA 
MYT MAYOTTE 
NAMNAMIBIA 
NCL NEW CALEDONIA 
NER NIGER 
NFK NORFOLK ISLAND 
NGA NIGERIA 
NIC NICARAGUA 
NIU NIUE 
NLD NETHERLANDS 
NOR NORWAY 
NPL NEPAL 
NRU NAURU 
NZL NEW ZEALAND 
OMN OMAN 
PAK PAKISTAN 
PAN PANAMA 
PCN PITCAIRN 
PER PERU 
PHL PHILIPPINES 
PLW PALAU 
PNG PAPUA NEW GUINEA 
POL POLAND 
PRI PUERTO RICO 
PRK KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF 
PRT PORTUGAL 
PRY PARAGUAY 
PYFFRENCH POLYNESIA 
QAT QATAR 
REUREUNION 
ROM ROMANIA 
RUS RUSSIAN FEDERATION 
RWA RWANDA 
SAU SAUDI ARABIA 
SDN SUDAN 
SEN SENEGAL
SGP SINGAPORE
SGS SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS 
SHN SAINT HELENA 
SJM SVALBARD AND JAN MAYEN 
SLB  SOLOMON ISLANDS 
SLE SIERRA LEONE 
SLV EL SALVADOR 
SMR SAN MARINO 
SOMSOMALIA 
SPM SAINT PIERRE AND MIQUELON 
STP SAO TOME AND PRINCIPE 
SUR SURINAME 
SVK SLOVAKIA 
SVN SLOVENIA 
SWESWEDEN 
SWZ SWAZILAND 
SYCSEYCHELLES 
SYRSYRIAN ARAB REPUBLIC 
TCATURKS AND CAICOS ISLANDS 
TCD CHAD 
TGO TOGO 
THA THAILAND 
TJK TAJIKISTAN 
TKL TOKELAU 
TKM TURKMENISTAN
TMP EAST TIMOR 
TON TONGA 
TTO TRINIDAD AND TOBAGO 
TUN TUNISIA 
TURTURKEY 
TUV TUVALU 
TWN TAIWAN, PROVINCE OF CHINA 
TZA TANZANIA, UNITED REPUBLIC OF 
UGA UGANDA 
UKR UKRAINE 
UMI UNITED STATES MINOR OUTLYING ISLANDS 
URY URUGUAY 
USA UNITED STATES 
UZB UZBEKISTAN 
VAT HOLY SEE (VATICAN CITY STATE) 
VCT SAINT VINCENT AND THE GRENADINES 
VEN VENEZUELA 
VGB VIRGIN ISLANDS, BRITISH 
VIR VIRGIN ISLANDS, U.S. 
VNM VIET NAM 
VUT VANUATU 
WLF WALLIS AND FUTUNA
WSM SAMOA
YEM YEMEN 
YUG YUGOSLAVIA 
ZAF SOUTH AFRICA 
ZMB ZAMBIA 
ZWE ZIMBABWE 

2.1.9.18 MSH-18 Character set (ID) 00692

Definition: This field contains the character set for the entire message. Refer to HL7 Table 0211 - Alternate character sets for valid values.

In Australian usage only ASCII, which is the default if blank, or 8859/1 should be used. UNICODE or UTF-8 messages should only be used by specific agreement.

HL7 Table 0211 - Alternate character sets

ValueDescription
ASCIIThe printable 7-bit ASCII character set. (This is the default if this field is omitted)
8859/1The printable characters from the ISO 8859/1 Character set
8859/2The printable characters from the ISO 8859/2 Character set
8859/3The printable characters from the ISO 8859/3 Character set
8859/4The printable characters from the ISO 8859/4 Character set
8859/5The printable characters from the ISO 8859/5 Character set
8859/6The printable characters from the ISO 8859/6 Character set
8859/7The printable characters from the ISO 8859/7 Character set
8859/8The printable characters from the ISO 8859/8 Character set
8859/9 The printable characters from the ISO 8859/9 Character set 
ISO IR14  Code for Information Exchange (one byte)(JIS X 0201-1976). Note that the code contains a space,i.e. "ISO IR14". 
ISO IR87  Code for the Japanese Graphic Character set for information interchange (JIS X 0208-1990), Note that the code contains a space, i.e. "ISO IR87". 
ISO IR159  Code of the supplementary Japanese Graphic Character set for information interchange (JIS X 0212-1990). Note that the code contains a space, i.e. "ISO IR159". 
UNICODE The world wide character standard from ISO/IEC 10646-1-19933 

Note: The field separator character must still be chosen from the printable 7-bit ASCII character set.

The repetitions of this field to specify different character sets apply only to fields of the, FT, ST, and TX data types.

The field MSH-18-character set is an optional, repeating field of data type ID, using IDs outlined in HL7 Table 0211 - Alternate character sets (or equivalents from "ISO 2375").

2.1.9.19 MSH-19 Principal language of message (CE) 00693

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains the principal language of the message. Codes come from ISO 639.

2.1.9.20 MSH-20 Alternate character set handling scheme (ID) 01317

Definition: When any alternative character sets are used (as specified in the second or later components of MSH-18 character sets), and if any special handling scheme is needed, this component is to specify the scheme used, according to HL7 Table 0356- Alternate character set handling scheme as defined below:

HL7 Table 0356 - Alternate character set handling scheme

ValueDescription
ISO 2022-1994This standard is titled "Information Technology - Character Code Structure and Extension Technique". This standard specifies an escape sequence from basic one byte character set to specified other character set, and vice versa. The escape sequence explicitly specifies what alternate character set to be evoked. Note that in this mode, the actual ASCII escape character is used as defined in the referenced ISO document. As noted in 1.6.1., escape sequences to/from alternate character set should occur within HL7 delimiters. In other words, HL7 delimiters are basic one byte characters only, and just before and just after delimiters, character encoding status should be the basic one byte set.
2.3The character set switching mode specified in HL7 2.3, sections 2.8.28.6.1, and 2.9.2. Note that the escape sequences used in this mode do not use the ASCII "esc" character. They are "HL7 escape sequences" as defined in HL7 2.3, sec. 2.9 as defined in ISO 2022-1994 (Also, note that sections 2.8.28.6.1and 2.9.2 in HL7 2.3 correspond to sections 2.8.31.6.1and 2.9.2 in HL7 2.4.)
<null>This is the default, indicating that there is no character set switching occurring in this message.

2.1.9.21 MSH-21 Conformance statement ID (ID) 01598

Definition: Sites may use this field to assert adherence to a Conformance Statement published by HL7 or by a site. Conformance Statements contain detailed explanations of grammar, syntax, and usage for a particular message or set of messages. Examples of the use of Conformance Statements appear in Chapter 5, "Query."

Repetition of this field allows more flexibility in creating and naming conformance statements. For example, the first repetition could reference a standard conformance statement, and the second, just some changes to it.

Values for HL7-standard conformance statements appear in HL7 Table 0449 - Conformance statements as defined below.

HL7 Table 0449 - Conformance statements

ValueDescription
 ???? Nothing in this table

Note: As HL7 technical committees ballot conformance statements, table 449 will be populated with their identifiers. No identifiers have been issued as of v 2.4. As with any HL7 table, this table may be extended with site-defined identifiers.

 

2.2 Other Segments used in Pathology Messaging

 

 

2.2.1  PV1 - patient visit segment

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

SEQLENDTOPTRP/#TBL#ITEM#ELEMENT NAME
14SIO  00131Set ID - PV1
21ISR 000400132Patient Class
380PLO  00133Assigned Patient Location
IS  0007 00134 Admission Type 
250 CX   00135  Preadmit Number 
80 PL   00136Prior Patient Location 
250 XCN Y0010 00137 Attending Doctor 
250 XCN 0010 00138 Referring Doctor 
250 XCN Y0010 00139 Consulting Doctor 
10  3IS  0069 00140 Hospital Service 
11 80PL   00141 Temporary Location 
12 2IS  0087 00142  Preadmit Test Indicator 
13 IS  0092  00143 Re-admission Indicator 
14 IS  0023  00144 Admit Source 
15 IS Y0009 00145 Ambulatory Status
16 IS  0099 00146 VIP Indicator 
17 250 XCN 0010 00147 Admitting Doctor 
18  IS 0018 00148 Patient Type 
19 250 CX O  00149 Visit Number 
20 50  FCO Y0064 00150 Financial Class 
21 IS O 0032 00151  Charge Price Indicator 
22IS  0045 00152 Courtesy Code
23 IS  0046 00153 Credit Rating 
24 IS 0044 00154 Contract Code 
25 DT Y 00155 Contract Effective Date 
26 12 NM  00156 Contract Amount 
27 NM  00157 Contract Period 
28 IS  0073 00158 Interest Code 
29 IS  0110 00159  Transfer to Bad Debt Code 
30 DT   00160Transfer to Bad Debt Date 
31 10 IS  0021 00161 Bad Debt Agency Code 
32 12NM   00162  Bad Debt Transfer Amount 
33 12 NM   00163  Bad Debt Recovery Amount 
34 IS  0111 00164  Delete Account Indicator 
35 DT   00165  Delete Account Date 
36 IS  0112 00166 Discharge Disposition 
37 25 CM  0113 00167 Discharged to Location 
38 250 CE 0114 00168 Diet Type 
39 IS   0115 00169 Servicing Facility 
40 IS  0116 00170 Bed Status 
41 2  IS  0117 00171  Account Status
42 80 PL   00172 Pending Location 
43 80 PL   00173 Prior Temporary Location 
44 26 TS   00174 Admit Date/Time 
45 26 TS  Y 00175 Discharge Date/Time 
46 12 NM   00176 Current Patient Balance 
47 12 NM   00177 Total Charges 
48 12 NM   00178 Total Adjustments 
49 12 NM   00179 Total Payments 
50 250 CX  0203  00180 Alternate Visit ID 
51IS  0326 01226 Visit Indicator 
52 250 XCN  Y0010  01274Other Healthcare Provider 

2.2.1.0 PV1 field definitions

2.2.1.1 PV1-1 Set ID - PV1 (SI) 00131

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

2.2.1.2 PV1-2 Patient class (IS) 00132

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

User-defined Table 0004 - Patient class

ValueDescription
EEmergency
IInpatient
OOutpatient
PPreadmit
RRecurring patient
BObstetrics
CCommercial Account
Not Applicable 
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).

2.2.1.3 PV1-3 Assigned patient location (PL) 00133

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status(IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)

Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains the patient’s initial assigned location or the location to which the patient is being moved. The first component may be the nursing station for inpatient locations, or clinic or department, for locations other than inpatient. For cancelling 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.

2.2.1.4 PV1-4 Admission type (IS) 00134

 Definition: This field indicates the circumstances under which the patient was or will be admitted. Refer  to User-defined Table 0007 - Admission type for suggested values. In the US, it is recommended to report the UB92 FL 19 "Type of Admission" in this field.

User-defined Table 0007 - Admission type

ValueDescriptionComments
AAccident 
EEmergencyUS UB92 code "1"
LLabor and Delivery 
RRoutine 
Newborn (Birth in healthcare facility) US UB92 code "4" 
Urgent US UB92 code "2" 
Elective  US UB92 code "3" 

2.2.1.5 PV1-5 Preadmit number (CX) 00135

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)>^ < assigning authority (HD)> ^ <identifier type code (ID)> ^ < assigning facility (HD)^ <effective date (DT)> ^ <expiration date (DT)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type(ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type(ID)>

Definition: This field uniquely identifies the patient’s pre-admit account. Some systems will continue to use the pre-admit number as the billing number after the patient has been admitted. For backward compatibility, 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 code are strongly recommended for all CX data types.

2.2.1.6 PV1-6 Prior patient location (PL) 00136

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status(IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)

Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains the prior patient location if the patient is being transferred. The old location is null if the patient is new. If a value exists in the fifth component (location status), it supersedes the value in PV1-40 - bed status.

2.2.1.7 PV1-7 Attending doctor (XCN) 00137

Components: <ID number (ST)> ^ <family name (ST)> ^ <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)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)>

Subcomponents of family name: <family name (ST)> & <own family name prefix (ST)> & <own family name (ST)> & <family name prefix from partner/spouse (ST)> & <family name from partner/spouse (ST)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains the attending physician information. Multiple names and identifiers for the same physician may be sent. The field sequences are not used to indicate multiple attending doctors. The legal name must be sent in the first sequence. If the legal name is not sent, then a repeat delimiter must be sent in the first sequence. Depending on local agreements, either ID or the name may be absent in this field. Refer to User-defined Table 0010 - Physician ID for suggested values.

User-defined Table 0010 - Physician ID

ValueDescription
 No suggested values defined

2.2.1.8 PV1-8 Referring doctor (XCN) 00138

Components: <ID number (ST)> ^ <family name (ST)> ^ <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)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)>

Subcomponents of family name: <family name (ST)> & <own family name prefix (ST)> & <own family name (ST)> & <family name prefix from partner/spouse (ST)> & <family name from partner/spouse (ST)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains the referring physician information. Multiple names and identifiers for the same physician may be sent. The field sequences are not used to indicate multiple referring doctors. The legal name must be sent in the first sequence. If the legal name is not sent, then a repeat delimiter must be sent in the first sequence. Depending on local agreements, either the ID or the name may be absent from this field. Refer to User-defined Table 0010 - Physician ID for suggested values.

2.2.1.9 PV1-9 Consulting doctor (XCN) 00139

Components: <ID number (ST)> ^ <family name (ST)> ^ <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)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)>

Subcomponents of family name: <family name (ST)> & <own family name prefix (ST)> & <own family name (ST)> & <family name prefix from partner/spouse (ST)> & <family name from partner/spouse (ST)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

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

2.2.1.10 PV1-10 Hospital service (IS) 00140

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

User-defined Table 0069 - Hospital service

ValuesDescription
MEDMedical Service
SURSurgical Service
UROUrology Service
PULPulmonary Service 
CAR Cardiac Service

2.2.1.11 PV1-11 Temporary location (PL) 00141

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status  (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)>

Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains a location other than the assigned location required for a temporary period of time (e.g., OR, operating theatre, etc.). If a value exists in the fifth component (location status), it supersedes the value in PV1-40 - bed status.

2.2.1.12 PV1-12 Preadmit test indicator (IS) 00142

Definition: This field indicates whether the patient must have pre-admission testing done in order to be admitted. Refer to User-defined Table 0087 - Pre-admit test indicator for suggested values.

User-defined Table 0087 - Pre-admit test indicator

ValueDescription
 No suggested values defined

2.2.1.13 PV1-13 Re-admission indicator (IS) 00143

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

ValueDescription
RRe-admission

2.2.1.14 PV1-14 Admit source (IS) 00144

Definition: This field indicates where the patient was admitted. Refer to User-defined Table 0023 - Admit source for suggested values. 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

ValueDescription
1Physician referral
2Clinic referral
3HMO referral
4Transfer from a hospital
5Transfer from a skilled nursing facility
6Transfer from another health care facility
7Emergency room
8Court/law enforcement
Information not available

 2.2.1.15 PV1-15 Ambulatory status (IS) 00145

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

User-defined Table 0009 - Ambulatory status

ValueDescription
A0No functional limitations
A1Ambulates with assistive device
A2Wheelchair/stretcher bound
A3 Comatose; non-responsive 
A4 Disoriented 
A5 Vision impaired 
A6Hearing impaired 
A7 Speech impaired 
A8 Non-English speaking 
A9 Functional level unknown 
B1Oxygen therapy 
B2 Special equipment (tubes, IVs, catheters) 
B3 Amputee 
B4  Mastectomy 
B5 Paraplegic 
B6 Pregnant 

 2.2.1.16 PV1-16 VIP indicator (IS) 00146

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

ValueDescription
 No suggested values defined

2.2.1.17 PV1-17 Admitting doctor (XCN) 00147

Components: <ID number (ST)> ^ <family name (ST)> ^ <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)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)>

Subcomponents of family name: <family name (ST)> & <own family name prefix (ST)> & <own family name (ST)> & <family name prefix from partner/spouse (ST)> & <family name from partner/spouse (ST)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains the admitting physician information. Multiple names and identifiers for the same physician may be sent. The field sequences are not used to indicate multiple admitting doctors. The legal name must be sent in the first sequence. If the legal name is not sent, then a repeat delimiter must be sent in the first sequence. By local agreement, the name or ID may be absent in this field. Refer to User-defined Table 0010 - Physician ID for suggested values.

2.2.1.18 PV1-18 Patient type (IS) 00148

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

User-defined Table 0018 - Patient type

ValueDescription
 No suggested values defined

2.2.1.19 PV1-19 Visit number (CX) 00149

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (ID)> ^ < assigning facility (HD) ^ <effective date (DT)> ^ <expiration date (DT)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition:  For backward compatibility , 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.

2.2.1.20 PV1-20 Financial class (FC) 00150

Components: <financial class (IS)> ^ <effective date (TS)>

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

ValueDescription
 No suggested values defined

2.2.1.21 PV1-21 Charge price indicator (IS) 00151

Definition: This field contains the code used to determine which price schedule is to be used for room and  bed charges. Refer to User-defined Table 0032 - Charge/price indicator  for suggested values.

User-defined Table 0032 - Charge/price indicator

ValueDescription
 No suggested values defined

2.2.1.2 PV1-22 Courtesy code (IS) 00152

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

User-defined Table 0045 - Courtesy code

ValueDescription
 No suggested values defined

2.2.1.23 PV1-23 Credit rating (IS) 00153

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

User-defined Table 0046 - Credit rating

ValueDescription
 No suggested values defined

2.2.1.24 PV1-24 Contract code (IS) 00154

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

ValueDescription
 No suggested values defined

2.2.1.25 PV1-25 Contract effective date (DT) 00155

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

2.2.1.26 PV1-26 Contract amount (NM) 00156

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

2.2.1.27 PV1-27 Contract period (NM) 00157

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

2.2.1.28 PV1-28 Interest code (IS) 00158

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

User-defined Table 0073 - Interest rate code

ValueDescription
 No suggested values defined

2.2.1.29 PV1-29 Transfer to bad debt code (IS) 00159

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

User-defined Table 0110 - Transfer to bad debt code

ValueDescription
 No suggested values defined

2.2.1.30 PV1-30 Transfer to bad debt date (DT) 00160

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

2.2.1.31 PV1-31 Bad debt agency code (IS) 00161

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

ValueDescription
 No suggested values defined

2.2.1.32 PV1-32 Bad debt transfer amount (NM) 00162

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

2.2.1.33 PV1-33 Bad debt recovery amount (NM) 00163

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

2.2.1.34 PV1-34 Delete account indicator (IS) 00164

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

User-defined Table 0111 - Delete account code

ValueDescription
 No suggested values defined

2.2.1.35 PV1-35 Delete account date (DT) 00165

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

2.2.1.36 PV1-36 Discharge disposition (IS) 00166

Definition: This field contains the disposition of the patient at time of discharge (i.e., discharged to home, expired, etc.). Refer to User-defined Table 0112 - 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

ValueDescription
01Discharged to home or self care (routine discharge)
02Discharged/transferred to another short term general hospital for inpatient care
03Discharged/transferred to skilled nursing facility (SNF)
04Discharged/transferred to an intermediate care facility (ICF)
05Discharged/transferred to another type of institution for inpatient care or referred for outpatient services to another institution
06Discharged/transferred to home under care of organized home health service organization
07Left against medical advice or discontinued care
08Discharged/transferred to home under care of Home IV provider
09Admitted 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 

 2.2.1.37 PV1-37 Discharged to location (CM) 00167

Components: <discharge location (IS)> ^ <effective date (TS)>

Definition: This field indicates the healthcare facility to which the patient was discharged. Refer to User defined Table 0113 - Discharged to location for suggested values.

User-defined Table 0113 - Discharged to location

ValueDescription
 No suggested values defined

2.2.1.38 PV1-38 Diet type (CE) 00168

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

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

ValueDescription
 No suggested values defined

2.2.1.39 PV1-39 Servicing facility (IS) 00169

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

ValueDescription
 No suggested values defined

An optional sixth component, the facility ID, may be valued in each individual location field in PV1, instead of placing it here.

2.2.1.40 PV1-40 Bed status (IS) 00170

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

ValueDescription
CClosed
HHousekeeping
OOccupied
Unoccupied 
Contaminated 
 Isolated

 2.2.1.41 PV1-41 Account status (IS) 00171

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

User-defined Table 0117 - Account status

ValueDescription
 No suggested values defined

2.2.1.42 PV1-42 Pending location (PL) 00172

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)>

Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field indicates the point of care, room, bed, 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 .

2.2.1.43 PV1-43 Prior temporary location (PL) 00173

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)>

Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field is used to reflect the patient’s temporary location (such as the 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.

2.2.1.44 PV1-44 Admit date/time (TS) 00174

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

2.2.1.45 PV1-45 Discharge date/time (TS) 00175

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

2.2.1.46 PV1-46 Current patient balance (NM) 00176

Definition: This field contains the visit balance due.

2.2.1.47 PV1-47 Total charges (NM) 00177

Definition: This field contains the total visit charges.

2.2.1.48 PV1-48 Total adjustments (NM) 00178

Definition: This field contains the total adjustments for visit.

2.2.1.49 PV1-49 Total payments (NM) 00179

Definition: This field contains the total payments for visit.

2.2.1.50 PV1-50 Alternate visit ID (CX) 00180

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (ID)> ^ < assigning facility (HD) ^ <effective date (DT)> ^ <expiration date (DT)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains the alternative, temporary, or pending optional visit ID number to be used if needed. Refer to HL7 Table 0061 - Check digit scheme  for valid values. Refer to HL7 Table 0203 - Identifier type for valid values. The assigning authority and identifier type code are strongly recommended for all CX data types.

2.2.1.51 PV1-51 Visit indicator (IS) 01226

Definition: This field specifies the level on which data are being sent. It is the indicator used to send data at two levels, visit and account. HL7 recommends sending an ‘A’ or no value when the data in the message are at the account level, or ‘V’ to indicate that the data sent in the message 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

ValueDescription
AAccount level (default)
VVisit level

2.2.1.52 PV1-52 Other healthcare provider (XCN) 01274

Components: <ID number (ST)> ^ <family name (ST)> ^ <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)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE) ^ <name validity range (DR)>

Subcomponents of family name: <family name (ST)> & <own family name prefix (ST)> & <own family name (ST)> & <family name prefix from partner/spouse (ST)> & <family name from partner/spouse (ST)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field has been retained for backward compatibility only.  Use the ROL-Role Segment to communicate providers not specified elsewhere. Refer to section 12.3.3 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.

2.2.2 PV2 - patient visit - additional information segment

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

HL7 Attribute Table - PV2 – Patient visit – additional information

SEQLENDTOPTRP/#TBL#ITEM#ELEMENT NAME
180PLC  00181Prior Pending Location
2250CEO 012900182Accommodation Code
3250CE  00183 Admit Reason
4250CEO  00184Transfer Reason
525STOY 00185Patient Valuables
625STO  00186Patient Valuables Location
72ISOY013000187Visit User Code
826TSO  00188Expected Admit Date/Time
926TSO  00189Expected Discharge Date/Time
103NMO  00711Estimated Length of Inpatient Stay
113NMO  00712Actual Length of Inpatient Stay
1250 ST   00713 Visit Description 
13250 XCN  Y 00714 Referral Source Code 
14DT   00715 Previous Service Date 
15ID  0136 00716  Employment Illness Related Indicator 
16IS  0213 00717 Purge Status Code 
17DT   00718  Purge Status Date 
18IS  0214 00719 Special Program Code 
19ID  0136 00720  Retention Indicator 
20NM   00721  Expected Number of Insurance Plans 
21IS  0215  00722  Visit Publicity Code 
22 1XON  0136 00723  Visit Protection Indicator 
23250 IS  Y 00724 Clinic Organization Name 
24IS  0216 00725 Patient Status Code 
25IS  0217 00726 Visit Priority Code 
26DT   00727 Previous Treatment Date 
27IS  0112 00728  Expected Discharge Disposition 
28DT   00729 Signature on File Date
29DT  00730 First Similar Illness Date 
30250 CE 021800731 Patient Charge Adjustment Code 
31IS  0219 00732  Recurring Service Code 
32ID   0136 00733  Billing Media Code 
3326 TS   00734 Expected Surgery Date and Time 
34ID  0136 00735  Military Partnership Code 
35ID  0136 00736 Military Non-Availability Code 
36ID  0136   00737 Newborn Baby Indicator 
37 1ID  0136 00738Baby Detained Indicator 
38250 CE 0430 01543Mode of Arrival Code 

2.2.2.0 PV2 field definitions

2.2.2.1 PV2-1 Prior pending location (PL) 00181

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)>

Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field is required for cancel pending transfer (A26) messages. In all other events it is optional.

2.2.2.2 PV2-2 Accommodation code (CE) 00182

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field indicates the specific patient accommodations for this visit. Refer to User-defined Table 0129 - Accommodation code for suggested values.

2.2.3.3 PV2-3 Admit reason (CE) 00183

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier

(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains the short description of the reason for patient admission.

2.2.2.4 PV2-4 Transfer reason (CE) 00184

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains the short description of the reason for a patient location change.

2.2.2.5 PV2-5 Patient valuables (ST) 00185

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

2.2.2.6 PV2-6 Patient valuables location (ST) 00186

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

2.2.2.7 PV2-7 Visit user code (IS) 00187

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

ValueDescription
TETeaching
HOHome
MOMobile Unit
PH Phone 

2.2.2.8 PV2-8 Expected admit date/time (TS) 00188

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

2.2.2.9 PV2-9 Expected discharge date/time (TS) 00189

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

2.2.2.10 PV2-10 Estimated length of inpatient stay (NM) 00711

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

2.2.2.11 PV2-11 Actual length of inpatient stay (NM) 00712

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

2.2.2.12 PV2-12 Visit description (ST) 00713

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

2.2.2.13 PV2-13 Referral source code (XCN) 00714

 Components: <ID number (ST)> ^ <family name (ST)> ^ <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)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE) ^ <name validity range (DR)>

Subcomponents of family name: <family name (ST)> & <own family name prefix (ST)> & <own family name (ST)> & <family name prefix from partner/spouse (ST)> & <family name from partner/spouse (ST)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains the name and the identification numbers of the person or organization that made the referral. This person/organization is not the same as the referring doctor. For example, Joe Smith referred me to the Clinic (or to Dr. Jones at the Clinic).

2.2.2.14 PV2-14 Previous service date (DT) 00715

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

2.2.2.15 PV2-15 Employment illness related indicator (ID) 00716

Definition: This field specifies whether a patient’s illness was job-related. Refer to HL7 Table 0136 - Yes/no indicator for valid values.

2.2.2.16 PV2-16 Purge status code (IS) 00717

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

User-defined Table 0213 - Purge status code

ValueDescription
PMarked for purge. User is no longer able to update the visit.
DThe visit is marked for deletion and the user cannot enter new data against it.
IThe visit is marked inactive and the user cannot enter new data against it.

2.2.2.17 PV2-17 Purge status date (DT) 00718

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

2.2.2.18 PV2-18 Special program code (IS) 00719

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

User-defined Table 0214 – Special program codes

ValueDescription
 No suggested values

2.2.2.19 PV2-19 Retention indicator (ID) 00720

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

2.2.2.20 PV2-20 Expected number of insurance plans (NM) 00721

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

2.2.2.21 PV2-21 Visit publicity code (IS) 00722

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

2.2.2.22 PV2-22 Visit protection indicator (ID) 00723

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

2.2.2.23 PV2-23 Clinic organization name (XON) 00724

Components: <organization name (ST)> ^ <organization name type code (ID)> ^ <ID number (ID)> ^ <check digit (NM)> ^ < check digit scheme (ID)> ^ <assigning authority (HD)> ^ <identifier type code (ID)> ^ <assigning facility (HD)> ^ <name representation code (ID)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains the organization name or sub-unit and identifier that is associated with the (visit) episode of care. For example, the Allergy or Oncology Clinic within the healthcare facility might be named.

2.2.2.24 PV2-24 Patient status code (IS) 00725

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

User-defined Table 0216 – Patient status

ValueDescription
 No suggested values defined

2.2.2.25 PV2-25 Visit priority code (IS) 00726

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

ValueDescription
1Emergency
2Urgent
3Elective

2.2.2.26 PV2-26 Previous treatment date (DT) 00727

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

2.2.2.27 PV2-27 Expected discharge disposition (IS) 00728

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

2.2.2.28 PV2-28 Signature on file date (DT) 00729

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

2.2.2.29 PV2-29 First similar illness date (DT) 00730

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

2.2.2.30 PV2-30 Patient charge adjustment code (CE) 00731

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

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 .

2.2.2.31 PV2-31 Recurring service code (IS) 00732

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

User-defined Table 0219 – Recurring service

ValueDescription
 No selected values

2.2.2.32 PV2-32 Billing media code (ID) 00733

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.

2.2.2.33 PV2-33 Expected surgery date and time (TS) 00734

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

2.2.2.34 PV2-34 Military partnership code (ID) 00735

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.

2.2.2.35 PV2-35 Military non-availability code (ID) 00736

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.

2.2.2.36 PV2-36 Newborn baby indicator (ID) 00737

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

2.2.2.37 PV2-37 Baby detained indicator (ID) 00738

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.

2.2.2.38 PV2-38 Mode of arrival code (CE) 01543

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

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

ValueDescription
AAmbulance
CCar
FOn foot
HHelicopter
PPublic Transport
O  Other 
Unknown 

 

2.2.2.39 PV2-39 Recreational drug use code (CE) 01544

 

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

 

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

ValueDescription
AAlcohol
KKava
MMarijuana
TTobacco - smoked
CTobacco - chewed
OOther
UUnknown

 

 

2.2.2.40 PV2-40 Admission level of care code (CE) 01545

 

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

 

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

ValueDescription
ACAcute
CHChronic
COComatose
CRCritical
IMImproved 
MO Moribund 

 

 

2.2.2.41 PV2-41 Precaution code (CE) 01546

 

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

 

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

ValueDescription
AAggressive
BBlind
CConfused
DDeaf
IOn IV
N"No-code" (i.e. Do not resuscitate)
PParaplegic
OOther
U  Unknown 

 

 

2.2.2.42 PV2-42 Patient condition code (CE) 01547

 

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

 

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

ValueDescription
ASatisfactory
CCritical
PPoor
SStable
Other 
Unknown 

 

 

2.2.2.43 PV2-43 Living will code (IS) 00759

 

Definition: This field indicates whether or not the patient has a living will and, if so, whether a copy of the living will is on file at the 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 code.

User-defined Table 0315 - Living will code

ValueDescription
YYes, patient has a living will
FYes, patient has a living will but it is not on file
NNo, patient does not have a living will and no information was provided
No, patient does not have a living will but information was provided 
Unknown 

2.2.2.44 PV2-44 Organ donor code (IS) 00760

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

ValueDescription
YYes, patient is a documented donor and documentation is on file
FYes, patient is a documented donor, but documentation is not on file
NNo, patient has not agreed to be a donor
INo, patient is not a documented donor, but information was provided
RPatient leaves organ donation decision to relatives
PPatient leaves organ donation decision to a specific person
UUnknown 

2.2.2.45 PV2-45 Advance directive code (CE) 01548

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

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

ValueDescription
DNRDo not resuscitate

2.2.2.46 PV2-46 Patient status effective date (DT) 01549

Definition: This field indicates the effective date for PV2-24 - Patient Status .

2.2.2.47 PV2-47 Expected LOA return date/time (TS) 01550

 

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.

 

 

 

 

 

 

 

 

 

   

2.2.3 AL1