2.24.1 MSH - message header segment

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

Figure 2-8. MSH attributes

SEQ
LEN
DT
OPT
RP/#
TBL#
ITEM #
ELEMENT NAME
1 ST
R
    00001 Field Separator
2
4 ST
R
    00002 Encoding Characters
3
180 HD
O
    00003 Sending Application
4
180 HD
O
    00004 Sending Facility
5
180 HD
O
    00005 Receiving Application
6
180 HD
O
    00006 Receiving Facility
7
26 TS
O
    00007 Date/Time Of Message
8
40 ST
O
    00008 Security
9
7 CM
R
    00009 Message Type
10
20 ST
R
    00010 Message Control ID
11
3 PT
R
    00011 Processing ID
12
8 ID
R
  0104 00012 Version ID
13
15 NM
O
    00013 Sequence Number
14
180 ST
O
    00014 Continuation Pointer
15
2 ID
O
  0155 00015 Accept Acknowledgment Type
16
2 ID
O
  0155 00016 Application Acknowledgment Type
17
2 ID
O
    00017 Country Code
18
6 ID
O
Y/3 0211 00692 Character Set
19
60 CE
O
    00693 Principal Language Of Message

2.24.1.0 MSH field definitions

2.24.1.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.24.1.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). See Section 2.7, "MESSAGE DELIMITERS."

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

2.24.1.4 Sending facility (HD) 00004

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

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

2.24.1.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. See comments: MSH-4-sending facility. Entirely site-defined.

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

2.24.1.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.24.1.9 Message type (CM) 00009

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

Definition: This field contains the message type and trigger event for the message. The first component is the message type edited by HL7 table 0076 - Message type; second is the trigger event code edited by HL7table 0003 - Event type.

The receiving system uses this field to know the data segments to recognize, 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 Section 2.17.1.1, "Original mode display query variants." The second component is not required on response or acknowledgment messages.

Table 0076 - Message type
 
 
Value
Description
Chapter
ACK
General acknowledgment message 2
ADR
ADT response 3
ADT
ADT message 3
ARD
Ancillary RPT (display) 7
BAR
Add/change billing account 6
CSU
Unsolicited clinical study data  7
DFT
Detail financial transaction 6
DSR
Display response 2
EDR
Enhanced display response 2
ERP
Event replay response 2
ERQ
Event replay query 2
EQQ
Embedded query language query 2
MCF
Delayed acknowledgment 2
MDM
Documentation message 9
MFN
Master files notification 8
MFK
Master files application acknowledgement 8
MFD
Master files delayed application acknowledgement 8
MFQ
Master files query 8
MFR
Master files query response 8
ORF
Observ. result/record response 7
ORM
Order message 4
ORR
Order acknowledgement message 4
ORU
Observ result/unsolicited 7
OSQ
Order status query 4
OSR
Order status response 4
QRY
Query, original Mode 2
PEX
Product experience 7
PGL
Patient goal 12
PGR
Patient goal response 12
PGQ
Patient goal query 12
PIN
Patient Insurance Information 12
PPG
Patient pathway (goal-oriented) 12
PPP
Patient pathway (problem-oriented) 12
PPR
Patient problem 12
PPT
Patient pathway (goal oriented) 12
PPV
Patient goal response 12
PRQ
Patient care problem query 12
PRR
Patient problem response 12
PTQ
Patient pathway (problem-oriented) query 12
PTR
Patient pathway (problem-oriented) response 12
PTU
Patient pathway (goal-oriented) query 12
PTV
Patient pathway (goal-oriented) response 12
PIN
Patient information 11
RAR
Pharmacy administration information 4
RAS
Pharmacy administration message 4
RCI
Return clinical information 11
RCL
Return clinical list 11
RDE
Pharmacy encoded order message 4
RDR
Pharmacy dispense information 4
RDS
Pharmacy dispense message 4
RGV
Pharmacy give message 4
RGR
Pharmacy dose information 4
REF
Patient referral 11
RER
Pharmacy encoded order information 4
ROD
Request patient demographics 11
ROR
Pharmacy prescription order response 4
RPA
Return patient authorization 11
RPI
Return patient information 11
RPL
Return patient display list 11
RPR
Return patient list 11
RQA
Request patient authorization 11
RQC
Request clinical information 11
RQI
Request patient information 11
RQP
Request patient demographics 11
RRA
Pharmacy administration acknowledgment 4
RRD
Pharmacy dispense acknowledgment 4
RRE
Pharmacy encoded order acknowledgment 4
RRG
Pharmacy give acknowledgment 4
RRI
Return patient referral 11
SIU
Schedule information unsolicited 10
SPQ
Stored procedure request 2
SQM
Schedule query 10
SQR
Schedule query response 10
CRM
Clinical study registration 7
SRM
Schedule request 10
SRR
Scheduled request response 10
SUR
Summary product experience report 7
TBR
Tabular data response 2
UDM
Unsolicited display message 2
VQQ
Virtual table query 2
VXQ
Query for vaccination record 4
VXX
Vaccination query response with multiple PID matches 4
VXR
Vaccination query record response 4
VXU
Unsolicited vaccination record update 4
 
   

Table 0003 - Event type
 
 
Value
Description
A01
ADT/ACK - Admit / visit notification
A02
ADT/ACK - Transfer a patient
A03
ADT/ACK - Discharge/end visit
A04
ADT/ACK - Register a patient
A05
ADT/ACK - Pre-admit a patient
A06
ADT/ACK - Change an outpatient to an inpatient
A07
ADT/ACK - Change an inpatient to an outpatient
A08
ADT/ACK - Update patient information
A09
ADT/ACK - Patient departing - tracking
A10
ADT/ACK - Patient arriving - tracking
A11
ADT/ACK - Cancel admit/visit notification
A12
ADT/ACK - Cancel transfer
A13
ADT/ACK - Cancel discharge/end visit
A14
ADT/ACK - Pending admit
A15
ADT/ACK - Pending transfer
A16
ADT/ACK - Pending discharge
A17
ADT/ACK - Swap patients
A18
ADT/ACK - Merge patient information
A19
QRY/ADR - Patient query
A20
ADT/ACK - Bed status update
A21
ADT/ACK - Patient goes on a "leave of absence"
A22
ADT/ACK - Patient returns from a "leave of absence"
A23
ADT/ACK - Delete a patient record
A24
ADT/ACK - Link patient information
A25
ADT/ACK - Cancel pending discharge
A26
ADT/ACK - Cancel pending transfer
A27
ADT/ACK - Cancel pending admit
A28
ADT/ACK - Add person information
A29
ADT/ACK - Delete person information
A30
ADT/ACK - Merge person information
A31
ADT/ACK - Update person information
A32
ADT/ACK - Cancel patient arriving - tracking
A33
ADT/ACK - Cancel patient departing - tracking
A34
ADT/ACK - Merge patient information - patient ID only
A35
ADT/ACK - Merge patient information - account number only
A36
ADT/ACK - Merge patient information - patient ID and account number
A37
ADT/ACK - Unlink patient information
A38
ADT/ACK - Cancel pre-admit
A39
ADT/ACK - Merge person - external ID
A40
ADT/ACK - Merge patient - internal ID
A41
ADT/ACK - Merge account - patient account number
A42
ADT/ACK - Merge visit - visit number
A43
ADT/ACK - Move patient information - internal ID
A44
ADT/ACK - Move account information - patient account number
A45
ADT/ACK - Move visit information - visit number
A46
ADT/ACK - Change external ID
A47
ADT/ACK - Change internal ID
A48
ADT/ACK - Change alternate patient ID
A49
ADT/ACK - Change patient account number
A50
ADT/ACK - Change visit number
A51
ADT/ACK - Change alternate visit ID
C01
CRM - Register a patient on a clinical trial
C02
CRM - Cancel a patient registration on clinical trial (for clerical mistakes only)
C03
CRM - Correct/update registration information
C04
CRM - Patient has gone off a clinical trial
C05
CRM - Patient enters phase of clinical trial
C06
CRM - Cancel patient entering a phase (clerical mistake)
C07
CRM - Correct/update phase information
C08
CRM - Patient has gone off phase of clinical trial
C09
CSU - Automated time intervals for reporting, like monthly
C10
CSU - Patient completes the clinical trial
C11
CSU - Patient completes a phase of the clinical trial
C12
CSU - Update/correction of patient order/result information
CNQ
QRY/EQQ/SPQ/VQQ/RQQ - Cancel query
G01
PGL/ACK - Patient goal
I01
RQI/RPI - Request for insurance information
I02
RQI/RPL - Request/receipt of patient selection display list
I03
RQI/RPR - Request/receipt of patient selection list
I04
RQD/RPI - Request for patient demographic data
I05
RQC/RCI - Request for patient clinical information
I06
RQC/RCL - Request/receipt of clinical data listing
I07
PIN/ACK - Unsolicited insurance information
I08
RQA/RPA - Request for treatment authorization information
I09
RQA/RPA - Request for modification to an authorization
I10
RQA/RPA - Request for resubmission of an authorization
I11
RQA/RPA - Request for cancellation of an authorization
I12
REF/RRI - Patient referral
I13
REF/RRI - Modify patient referral
I14
REF/RRI - Cancel patient referral
I15
REF/RRI - Request patient referral status
M01
MFN/MFK - Master file not otherwise specified (for backward compatibility only)
M02
MFN/MFK - Master file - Staff Practioner
M03
MFN/MFK - Master file - Test/Observation (for backward compatibility only)
varies
MFQ/MFR - Master files query (use event same as asking for e.g., M05 - location)
M04
MFN/MFK - Master files charge description
M05
MFN/MFK - Patient location master file
M06
MFN/MFK - Clinical study with phases and schedules master file
M07
MFN/MFK - Clinical study without phases but with schedules master file
M08
MFN/MFK - Test/observation (Numeric) master file
M09
MFN/MFK - Test/Observation (Categorical) master file
M10
MFN/MFK - Test /observation batteries master file
M11
MFN/MFK - Test/calculated observations master file
O01
ORM - Order message (also RDE, RDS, RGV, RAS) 
O02
ORR - Order response (also RRE, RRD, RRG, RRA) 
P01
BAR/ACK - Add patient accounts
P02
BAR/ACK - Purge patient accounts
P03
DFT/ACK - Post detail financial transaction
P04
QRY/DSP - Generate bill and A/R statements
P05
BAR/ACK - Update account

 
 
 
P06
BAR/ACK - End account
P07
PEX - Unsolicited initial individual product experience report
P08
PEX - Unsolicited update individual product experience report
P09
SUR - Summary product experience report
PC1
PPR - PC/ Problem Add
PC2
PPR - PC/ Problem Update
PC3
PPR - PC/ Problem Delete
PC4
PRQ - PC/ Problem Query
PC5
PRR - PC/ Problem Response
PC6
PGL - PC/ Goal Add
PC7
PGL - PC/ Goal Update
PC8
PGL - PC/ Goal Delete
PC9
PGQ - PC/ Goal Query
PCA
PGR - PC/ Goal Response
PCB
PPP - PC/ Pathway (Problem-Oriented) Add
PCC
PPP - PC/ Pathway (Problem-Oriented) Update
PCD
PPP - PC/ Pathway (Problem-Oriented) Delete
PCE
PTQ - PC/ Pathway (Problem-Oriented) Query
PCF
PTR - PC/ Pathway (Problem-Oriented) Query Response
PCG
PPG - PC/ Pathway (Goal-Oriented) Add
PCH
PPG - PC/ Pathway (Goal-Oriented) Update 
PCJ
PPG - PC/ Pathway (Goal-Oriented) Delete
PCK
PTU - PC/ Pathway (Goal-Oriented) Query
PCL
PTV - PC/ Pathway (Goal-Oriented) Query Response
Q01
QRY/DSR - Query sent for immediate response
Q02
QRY/QCK - Query sent for deferred response
Q03
DSR/ACK - Deferred response to a query
Q05
UDM/ACK - Unsolicited display update message
Q06
OSQ/OSR - Query for order status
R01
ORU/ACK - Unsolicited transmission of an observation message
R02
QRY - Query for results of observation
R03
QRY/DSR Display-oriented results, query/unsol. update (for backward compatibility only)
R04
ORF - Response to query; transmission of requested observation
R05
QRY/DSR-query for display results
R06
UDM-unsolicited update/display results
RAR
RAR - Pharmacy administration information query response
RDR
RDR - Pharmacy dispense information query response
RER
RER - Pharmacy encoded order information query response
RGR
RGR - Pharmacy dose information query response
ROR
ROR - Pharmacy prescription order query response
S01
SRM/SRR - Request new appointment booking
S02
SRM/SRR - Request appointment rescheduling
S03
SRM/SRR - Request appointment modification
S04
SRM/SRR - Request appointment cancellation
S05
SRM/SRR - Request appointment discontinuation
S06
SRM/SRR - Request appointment deletion
S07
SRM/SRR - Request addition of service/resource on appointment
S08
SRM/SRR - Request modification of service/resource on appointment
S09
SRM/SRR - Request cancellation of service/resource on appointment
S10
SRM/SRR - Request discontinuation of service/resource on appointment
S11
SRM/SRR - Request deletion of service/resource on appointment
S12
SIU/ACK - Notification of new appointment booking
S13
SIU/ACK - Notification of appointment rescheduling
S14
SIU/ACK - Notification of appointment modification
S15
SIU/ACK - Notification of appointment cancellation
S16
SIU/ACK - Notification of appointment discontinuation
S17
SIU/ACK - Notification of appointment deletion
S18
SIU/ACK - Notification of addition of service/resource on appointment
S19
SIU/ACK - Notification of modification of service/resource on appointment
S20
SIU/ACK - Notification of cancellation of service/resource on appointment
S21
SIU/ACK - Notification of discontinuation of service/resource on appointment
S22
SIU/ACK - Notification of deletion of service/resource on appointment
S23
SIU/ACK - Notification of blocked schedule time slot(s)
S24
SIU/ACK - Notification of opened ("unblocked") schedule time slot(s)
S25
SQM/SQR - Schedule query message and response
S26
Notification that patient did not show up for schedule appointment
T01
MDM/ACK - Original document notification
T02
MDM/ACK - Original document notification and content
T03
MDM/ACK - Document status change notification
T04
MDM/ACK - Document status change notification and content
T05
MDM/ACK - Document addendum notification
T06
MDM/ACK - Document addendum notification and content
T07
MDM/ACK - Document edit notification
T08
MDM/ACK - Document edit notification and content
T09
MDM/ACK - Document replacement notification
T10
MDM/ACK - Document replacement notification and content
T11
MDM/ACK - Document cancel notification
T12
QRY/DOC - Document query
V01
VXQ - Query for vaccination record
V02
VXX - Response to vaccination query returning multiple PID matches
V03
VXR - Vaccination record response
V04 
VXU - Unsolicited vaccination record update
W01
ORU - Waveform result, unsolicited transmission of requested information
W02
QRF - Waveform result, response to query
X01
PEX - Product experience

2.24.1.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.24.1.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, above. 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.

Table 0103 - Processing ID
 
 
Value
Description
D
Debugging
P
Production
T
Training

Table 0207 - Processing mode
 
 
Value
Description
A
Archive
R
Restore from archive
I
Initial load
not present
Not present (the default, meaning current processing)

2.24.1.12 Version ID (ID) 00012

Definition: This field is matched by the receiving system to its own version to be sure the message will be interpreted correctly.

Table 0104 - Version ID
 
 
Value
Description  
2.0
Release 2.0 September 1988
2.0D
Demo 2.0 October 1988
2.1
Release 2. 1 March 1990
2.2
Release 2.2 December 1994
2.3
Release 2.3 Ballot #1 February 1996, Ballot #2 July 1996, Final Ballot

2.24.1.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 incremented by one for each subsequent value.

2.24.1.14 Continuation pointer (ST) 00014

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

2.24.1.15 Accept acknowledgment type (ID) 00015

Definition: This field identifies the conditions under which accept acknowledgements 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.24.1.16 Application acknowledgment type (ID) 00016

Definition: This field contains the conditions under which application acknowledgements 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:

Table 0155 - Accept/application acknowledgment conditions
 
 
Value
Description
AL
Always
NE
Never
ER
Error/reject conditions only
SU
Successful completion only

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

2.24.1.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. ISO 3166 provides a list of country codes that may be used [ Available from ISO 1 Rue de Varembe, Case Postale 56, CH 1211, Geneve, Switzerland] .

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

Table 0211 - Alternate character sets
 
 
Value
Description
ASCII
The printable 7-bit ASCII character set . (This is the default if this field is omitted)
8859/1
The printable characters from the ISO 8859/1 Character set
8859/2
The printable characters from the ISO 8859/2 Character set
8859/3
The printable characters from the ISO 8859/3 Character set
8859/4
The printable characters from the ISO 8859/4 Character set
8859/5
The printable characters from the ISO 8859/5 Character set 
8859/6
The printable characters from the ISO 8859/6 Character set
8859/7
The printable characters from the ISO 8859/7 Character set
8859/8
The printable characters from the ISO 8859/8 Character set
8859/9
The printable characters from the ISO 8859/9 Character set
JAS2020
A subset of ISO2020 used for most Kanjii transmissions
JIS X 0202
ISO 2022 with escape sequences for Kanjii
JIS X 0201-1976
Code for Information Exchange
JIS X 0208-1990
Code for the Japanese Graphic Character set for information interchange
JIS X 0212-1990
Code of the supplementary Japanese Graphic Character set for information interchange

 
 
 
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 PN and XPN 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).

• if the field is not valued, the default single-byte character set (ASCII (ISO IR-6)) should be assumed. No other character sets are allowed in the message.

• if the field repeats, but the first element is NULL (i.e., present but unvalued), the single-byte ASCII (ISO IR-6) is assumed as the default character set.

• if the sequence is present and the first element is specified, this character set is regarded as the default character set for the message. This must be a single-byte character set (i.e., ISO-IR 6, ISO-IR 13, ISO-IR 14, ISO-IR 100, etc.)

• elements in the remainder of the sequence (i.e., elements 2..n) are alternate character sets that may be used. These may include multi-byte character sets (i.e., JIS X 0208)

• the default character set should always be a single-byte character set. It should always have ISO-IR 6 (ISO 646) or ISO-IR 14 (JIS X 0201-1976) in the G0 area.

2.24.1.19 Principal language of message (CE) 00693

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

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

Previous PagePrevious PageTOCIndexNext Page
 

2.24.15 NTE - notes and comments segment

The NTE segment is defined here for inclusion in messages defined in other chapters. It is a common format for sending notes and comments.

Figure 2-22. NTE attributes

SEQ
LEN
DT
OPT
RP/#
TBL#
ITEM #
ELEMENT NAME
1
4 SI
O
    00096 Set ID - NTE
2
8 ID
O
  0105 00097 Source of Comment
3
64k FT
O
Y   00098 Comment

2.24.15.0 NTE field definitions

2.24.15.1 Set ID - NTE (SI) 00096

Definition: This field may be used where multiple NTE segments are included in a message. Their numbering must be described in the application message definition.

2.24.15.2 Source of comment (ID) 00097

Definition: This field is used when source of comment must be identified. This table may be extended locally during implementation.

Table 0105 - Source of comment
 
 
Value
Description
L
Ancillary (filler) department is source of comment
P
Orderer (placer) is source of comment
O
Other system is source of comment

2.24.15.3 Comment (FT) 00098

Definition: This field contains the comment contained in the segment.
 
 
Note: In the current HL7 version, this is an FT rather than a TX data type. Since there is no difference between an FT data type without any embedded formatting commands, and a TX data type, this change is compatible with the previous version.

Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page
 

3.3.1 EVN - event type segment

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

Figure 3-1. EVN attributes

SEQ
LEN DT
OPT
RP/# TBL# ITEM# ELEMENT NAME
3 ID
B
  0003 00099 Event Type Code
2
26 TS
R
    00100 Recorded Date/Time 
3
26 TS
O
    00101 Date/Time Planned Event
4
3 IS
O
  0062 00102 Event Reason Code
5
60 XCN
O
  0188 00103 Operator ID
6
26 TS
O
    01278 Event Occurred

3.3.1.0 EVN field definitions

3.3.1.1 Event type code (ID) 00099

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

3.3.1.2 Recorded Date/time (TS) 00100

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

3.3.1.3 Date/time planned event (TS) 00101

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

3.3.1.4 Event reason code (IS) 00102

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

User-defined Table 0062 - Event reason
 
 
Value
Description
01 
Patient request
02 
Physician order
03 
Census management

3.3.1.5 Operator ID (XCN) 00103

Components: <ID number (ST) ^<family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^<assigning authority (HD) ^<name type code(ID) ^<identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field identifies the individual responsible for triggering the event. Refer to user-defined table 0188 - Operator ID for suggested values.

3.3.1.6 Event occurred (TS) 01278

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

Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page

3.3.2 PID - patient identification segment

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

Figure 3-2. PID attributes

SEQ
LEN DT
OPT
RP/# TBL# ITEM# ELEMENT NAME
4 SI
O
    00104 Set ID - Patient ID
2
20 CX
O
    00105 Patient ID (External ID)
3
20 CX
R
Y   00106 Patient ID (Internal ID)
4
20 CX
O
Y   00107 Alternate Patient ID - PID
5
48 XPN
R
    00108 Patient Name
6
48 XPN
O
    00109 Mother’s Maiden Name
7
26 TS
O
    00110 Date/Time of Birth
8
1 IS
O
  0001 00111 Sex
9
48 XPN
O
Y   00112 Patient Alias
10
1 IS
O
  0005 00113 Race
11
106 XAD
O
Y   00114 Patient Address
12
4 IS
B
    00115 County Code
13
40 XTN
O
Y   00116 Phone Number - Home
14
40 XTN
O
Y   00117 Phone Number - Business
15
60 CE
O
  0296 00118 Primary Language
16
1 IS
O
  0002 00119 Marital Status
17
3 IS
O
  0006 00120 Religion
18
20 CX
O
    00121 Patient Account Number
19
16 ST
O
    00122 SSN Number - Patient
20
25 CM
O
    00123 Driver's License Number - Patient
21
20 CX
O
Y   00124 Mother's Identifier
22
3 IS
O
  0189 00125 Ethnic Group
23
60 ST
O
    00126 Birth Place
24
2 ID
O
  0136 00127 Multiple Birth Indicator
25
2 NM
O
    00128 Birth Order
26
4 IS
O
Y 0171 00129 Citizenship
27
60 CE
O
  0172 00130 Veterans Military Status
28
80 CE
O
    00739 Nationality 
29
26 TS
O
    00740 Patient Death Date and Time
30
1 ID
O
  0136 00741 Patient Death Indicator

3.3.2.0 PID field definitions

3.3.2.1 Set ID - patient ID (SI) 00104

Definition: For those messages that permit segments to repeat, the Set ID field is used to identify the repetitions. For example, the swap and query transactions allow for multiple PID segments that would have Set ID values of 1, 2, then 3, etc.

3.3.2.2 Patient ID (external ID) (CX) 00105

Components: <ID (ST) ^ <check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <assigning authority (HD) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: When the patient is from another institution, outside office, etc., the identifier used by that institution can be shown in this field. This may be a number that multiple disparate corporations or facilities share. Refer to HL7 table 0061 - Check digit scheme in Chapter 2.

3.3.2.3 Patient ID (internal ID) (CX) 00106

Components: <ID (ST) ^ <check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <assigning authority (HD) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field contains the primary identifier, or other identifiers used by the facility to identify a patient uniquely (e.g., medical record number, billing number, birth registry, etc.). Refer to HL7 table 0061 - Check digit scheme for valid values.

When merging patient IDs (A34 and A36 events), the Patient ID contained in the PID segment cannot repeat.

3.3.2.4 Alternate patient ID - PID (CX) 00107

Components: <ID (ST) ^ <check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <assigning authority (HD) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field contains the third number that may be required to identify a patient. This field may be used to convey multiple patient IDs when more than one exist for a patient. Possible contents might include a visit number, a visit date, or a Social Security Number.

3.3.2.5 Patient name (XPN) 00108

Components: <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <name type code (ID)

Definition: This field contains the legal name of the patient. All other names for the patient should be sent in PID-9-patient alias. Therefore, the name type code in this field should be "L - Legal." Refer to HL7 table 0200 Name type code for valid values.

3.3.2.6 Mother's maiden name (XPN) 00109

Components: <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <name type code (ID)

Definition: This field contains the family name under which the mother was born (i.e., before marriage). It is used to distinguish between patients with the same last name.

3.3.2.7 Date/Time of birth (TS) 00110

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

3.3.2.8 Sex (IS) 00111

Definition: This field contains the patient’s sex. Refer to user-definedtable 0001 - Sex for suggested values.

User-defined Table 0001 - Sex
 
 
Value
Description
Female
Male
Other
Unknown

3.3.2.9 Patient alias (XPN) 00112

Components: <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <name type code (ID)

Definition: This field contains the name(s) by which the patient has been known at some time. Refer to HL7 table 0200 - Name type for valid values.

3.3.2.10 Race (IS) 00113

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

3.3.2.11 Patient address (XAD) 00114

Components: <street address (ST) ^ <other designation (ST) ^ <city (ST) ^ <state or province (ST) ^ <zip or postal code(ST) ^ <country (ID) ^ < address type (ID) ^ <other geographic designation (ST)^ <county/parish code (IS) ^ <census tract (IS)

Definition: This field contains the mailing address of the patient. Address type codes are user defined. Multiple addresses for the same person may be sent in the following sequence: The mailing address must be sent first in the sequence; if the mailing address is not sent, then a repeat delimiter must be sent in the first sequence.

3.3.2.12 County code (IS) 00115

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

3.3.2.13 Phone number - home (XTN) 00116

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID) ^ <telecommunication equipment type (ID) ^ <email address (ST) ^ <country code (NM) ^ <area/city code (NM) ^ <phone number (NM) ^ <extension (NM) ^ <any text (ST)

Definition: This field contains the patient’s personal phone numbers. All personal phone numbers for the patient are sent in this sequence. The first sequence is considered the primary number. If the primary number is not sent, then a repeat delimiter is sent in the first sequence. Refer to HL7 tables 0201 - Telecommunication use code and 0202 - Telecommunication equipment type for valid values.

3.3.2.14 Phone number - business (XTN) 00117

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^<telecommunication use code (ID) ^ <telecommunication equipment type (ID)^ <email address (ST) ^ <country code (NM) ^ <area/city code (NM) ^ <phone number (NM) ^ <extension (NM) ^ <any text (ST)

Definition: This field contains the patient’s business telephone numbers. All business numbers for the patient are sent in this sequence. The first sequence is considered the patient’s primary business phone number. If the primary business phone number is not sent, then a repeat delimiter must be sent in the first sequence. Refer to HL7 tables 0201 - Telecommunication use code and 0202 - Telecommunication equipment type for valid values.

3.3.2.15 Primary language (CE) 00118

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

Definition: This field contains the patient’s primary language. HL7 recommends using ISO table 639 as the suggested values in user-defined table 0296 - Language.

3.3.2.16 Marital status (IS) 00119

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

User-defined Table 0002 - Marital status
 
 
Value
Description
Separated
Divorced
Married
Single
Widowed

3.3.2.17 Religion (IS) 00120

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

3.3.2.18 Patient account number (CX) 00121

Components: <ID (ST) ^ <check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <assigning authority (HD) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field contains the patient account number assigned by accounting to which all charges, payments, etc., are recorded. It is used to identify the patient’s account. Refer to HL7 table 0061 - Check digit scheme in Chapter 2.

3.3.2.19 SSN number - patient (ST) 00122

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

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

Components: <license number (ST) ^ <issuing state, province, country (IS) ^ <expiration date (DT)

Definition: This field contains the patient’s drivers license number. Some sites may use this number as a unique identifier of the patient. The default of the second component is the state in which the patient’s license is registered.

3.3.2.21 Mother's identifier (CX) 00124

Components: <ID (ST) ^ <check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <assigning authority (HD) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field is used, for example, as a link field for newborns. Typically a patient ID or account number may be used. This field can contain multiple identifiers for the same mother. Refer to HL7 table 0061 - Check digit scheme as defined in Chapter 2.

3.3.2.22 Ethnic group (IS) 00125

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

3.3.2.23 Birth place (ST) 00126

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

3.3.2.24 Multiple birth indicator (ID) 00127

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

3.3.2.25 Birth order (NM) 00128

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

3.3.2.26 Citizenship (IS) 00129

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

3.3.2.27 Veterans military status (CE) 00130

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

Definition: This field contains the military status assigned to a veteran. Refer to user-defined table 0172 - Veterans military status for suggested values.

3.3.2.28 Nationality (CE) 00739

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

Definition: This field identifies the nation or national group to which the patient belongs. This information may be different than the person’s citizenship in countries in which multiple nationalities are recognized (e.g., Spain: Basque, Catalan, etc.).

3.3.2.29 Patient death date and time (TS) 00740

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

3.3.2.30 Patient death indicator (ID) 00741

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

3.3.2.31 Usage notes: PID patient identification

The assigning facility ID, the fourth component of the patient identifiers, is a string of up to six characters that is uniquely associated with the facility that originally assigned the number. A given institution, or group of intercommunicating institutions, should establish a list of facilities that may be potential assigners of patient identification (and other important identification) numbers. The list will be one of the institution’s master dictionary lists. Since third parties (other than the assigners of patient identification numbers) may send or receive HL7 messages containing patient identification numbers, the assigning facility ID in the patient identification numbers may not be the same as the sending and receiving systems identified in the MSH. The assigning facility ID must be unique across applications at a given site. This field is required in HL7 implementations that have more than a single ADT/REG application assigning such numbers.

Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page
 
 

3.3.9 PD1 - patient additional demographic segment

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

Figure 3-9. PD1 attributes
 
 
SEQ
LEN DT
OPT
RP/# TBL# ITEM# ELEMENT NAME
2 IS
O
Y 0223 00755 Living Dependency
2
2 IS
O
  0220 00742 Living Arrangement
3
90 XON
O
Y   00756 Patient Primary Facility
4
90 XCN
O
Y   00757 Patient Primary Care Provider Name & ID No.
5
2 IS
O
  0231 00745 Student Indicator
6
2 IS
O
  0295 00753 Handicap
7
2 IS
O
  0315 00759 Living Will
8
2 IS
O
  0316 00760 Organ Donor
9
2 ID
O
  0136 00761 Separate Bill
10
2 CX
O
Y   00762 Duplicate Patient
11
1 IS
O
  0125 00743 Publicity Indicator
12
1 ID
O
  0136 01283 Protection Indicator

3.3.9.1 Living dependency (IS) 00755

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

3.3.9.2 Living arrangement (IS) 00742

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

3.3.9.3 Patient primary facility (XON) 00756

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

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

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

Definition: This field contains the name and identifier that specifies the primary care facility selected by the patient at the time of enrollment in an HMO Insurance Plan. Multiple facilities are allowed for the same facility. The legal name of the facility must be sent in the first sequence. If the legal name of the facility is not sent, then the repeat delimiter must be sent in the first sequence. See Chapter 2 regarding suggested values for organization name type codes.

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

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field contains the provider name and ID of the managed care primary care provider. This information is usually selected by the patient at the time of enrollment in the patient’s managed care insurance plan. Multiple names are allowed for the same person. The legal name must be sent in the first sequence. If the legal name is not sent, then the repeat delimiter must be sent in the first sequence.

3.3.9.5 Student indicator (IS) 00745

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

3.3.9.6 Handicap (IS) 00753

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

3.3.9.7 Living will (IS) 00759

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

User-defined Table 0315 - Living will
 
 
Value
Description
Yes, patient has a living will
Yes, patient has a living will but it is not on file
No, 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

3.3.9.8 Organ donor (IS) 00760

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

User-defined Table 0316 - Organ donor
 
 
Value
Description
Yes, patient is a donor and card is on file
Yes, patient is a donor, but card is not on file
No, patient does not have a living will but information was provided
Unknown

3.3.9.9 Patient separate bill indicator (ID) 00761

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

3.3.9.10 Duplicate patient (CX) 00762

Components: <ID (ST) ^ <check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <assigning authority (HD) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

3.3.9.11 Publicity indicator (IS) 00743

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

3.3.9.12 Protection indicator (ID) 01282

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

Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page
 

3.3.3 PV1 - patient visit segment

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

Figure 3-3. PV1 attributes

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

3.3.3.0 PV1 field definitions

3.3.3.1 Set ID - PV1 (SI) 00131

Definition: PV1-1-set ID-patient visit contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be 1, for second occurrence it shall be 2, etc.

3.3.3.2 Patient class (IS) 00132

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

User-defined Table 0004 - Patient class
 
 
Value
Description
Emergency
Inpatient
Outpatient
Preadmit
Recurring Patient
Obstetrics

3.3.3.3 Assigned patient location (PL) 00133

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

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

Definition: This field contains the patient’s initial assigned location or the location to which the patient is being moved. The first component may be the nursing station for inpatient locations, or clinic, department, or home for locations other than inpatient. For canceling a transaction or discharging a patient, the current location (after the cancellation event) should be in this field. If a value exists in the fifth component (bed status), it supersedes the value in PV1-40-bed status.

3.3.3.4 Admission type (IS) 00134

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

User-defined Table 0007 - Admission type
 
 
Value
Description
Accident
Emergency
Labor and Delivery
Routine

3.3.3.5 Preadmit number (CX) 00135

Components: <ID (ST) ^ <check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <assigning authority (HD) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field uniquely identifies the patient’s pre-admit account. Some systems will continue to use the pre-admit number as the billing number after the patient has been admitted. For backward compatibility, an ST data type can be sent, however HL7 recommends use of the CX data type, like the account number, for new implementations.

3.3.3.6 Prior patient location (PL) 00136

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

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

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

3.3.3.7 Attending doctor (XCN) 00137

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

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

3.3.3.8 Referring doctor (XCN) 00138

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

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

3.3.3.9 Consulting doctor (XCN) 00139

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field contains the consulting physician information. The field sequences are used to indicate multiple consulting doctors. Depending on local agreements, either the ID or the name may be absent from this field. Refer to user-defined table 0010 - Physician ID for suggested values.

3.3.3.10 Hospital service (IS) 00140

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

3.3.3.11 Temporary location (PL) 00141

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

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

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

3.3.3.12 Preadmit test indicator (IS) 00142

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

3.3.3.13 Re-admission indicator (IS) 00143

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

3.3.3.14 Admit source (IS) 00144

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

3.3.3.15 Ambulatory status (IS) 00145

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

User-defined Table 0009 - Ambulatory status
 
 
Value
Description
A0 
No functional limitations
A1 
Ambulates with assistive device
A2 
Wheelchair/stretcher bound
A3 
Comatose; non-responsive
A4 
Disoriented
A5 
Vision impaired
A6 
Hearing impaired
A7 
Speech impaired
A8 
Non-English speaking
A9 
Functional level unknown
B1 
Oxygen Therapy
B2 
Special equipment (tubes, IVs, catheters)
B3 
Amputee
B4 
Mastectomy
B5 
Paraplegic
B6 
Pregnant

3.3.3.16 VIP indicator (IS) 00146

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

3.3.3.17 Admitting doctor (XCN) 00147

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

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

3.3.3.18 Patient type (IS) 00148

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

3.3.3.19 Visit number (CX) 00149

Components: <ID (ST) ^ <check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <assigning authority (HD) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: For backward compatibility, an NM data type may be sent, but HL7 recommends that new implementations use the CX data type. This field contains the unique number assigned to each patient visit.

3.3.3.20 Financial class (CM) 00150

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

Definition: This field contains the primary financial class assigned to the patient for the purpose of identifying sources of reimbursement. Repeats up to four times. Refer to user-defined table 0064 - Financial class for suggested values.

3.3.3.21 Charge price indicator (IS) 00151

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

3.3.3.22 Courtesy code (IS) 00152

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

3.3.3.23 Credit rating (IS) 00153

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

3.3.3.24 Contract code (IS) 00154

Definition: This field identifies the type of contract entered into by the facility and the guarantor for the purpose of settling outstanding account balances. Refer to user-defined table 0044 - Contract code for suggested values.

3.3.3.25 Contract effective date (DT) 00155

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

3.3.3.26 Contract amount (NM) 00156

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

3.3.3.27 Contract period (NM) 00157

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

3.3.3.28 Interest code (IS) 00158

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

3.3.3.29 Transfer to bad debt code (IS) 00159

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

3.3.3.30 Transfer to bad debt date (DT) 00160

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

3.3.3.31 Bad debt agency code (IS) 00161

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

3.3.3.32 Bad debt transfer amount (NM) 00162

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

3.3.3.33 Bad debt recovery amount (NM) 00163

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

3.3.3.34 Delete account indicator (IS) 00164

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

3.3.3.35 Delete account date (DT) 00165

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

3.3.3.36 Discharge disposition (IS) 00166

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

3.3.3.37 Discharged to location (CM) 00167

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

Definition: This field indicates a facility to which the patient was discharged. Refer to user-defined table 0113 - Discharged to location for suggested values.

3.3.3.38 Diet type (IS) 00168

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

3.3.3.39 Servicing facility (IS) 00169

Definition: This field is used in a multiple facility environment to indicate the facility with which this visit is associated. Refer to user-defined table 0115 - Servicing facility for suggested values.

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

3.3.3.40 Bed status (IS) 00170

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

User-defined Table 0116 - Bed status
 
 
Value
Description
Closed
Housekeeping
Occupied
Unoccupied
Contaminated
Isolated

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

3.3.3.41 Account status (IS) 00171

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

3.3.3.42 Pending location (PL) 00172

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

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

Definition: This field indicates the point of care, room, bed, facility ID, and bed status to which the patient may be moved. The first component may be the nursing station for inpatient locations, or the clinic, department, or home for locations other than inpatient. If a value exists in the fifth component (bed status), it supersedes the value in PV1-40-bed status.

3.3.3.43 Prior temporary location (PL) 00173

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

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

Definition: This field is used to reflect the patient’s temporary location (such as the OR or XRAY) prior to a transfer from a temporary location to an actual location, or from a temporary location to another temporary location. The first component may be the nursing station for inpatient locations, or the clinic, department, or home for locations other than inpatient. If a value exists in the fifth component (bed status), it supersedes the value in PV1-40-bed status.

3.3.3.44 Admit date/time (TS) 00174

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

3.3.3.45 Discharge date/time (TS) 00175

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

3.3.3.46 Current patient balance (NM) 00176

Definition: This field contains the visit balance due.

3.3.3.47 Total charges (NM) 00177

Definition: This field contains the total visit charges.

3.3.3.48 Total adjustments (NM) 00178

Definition: This field contains the total adjustments for visit.

3.3.3.49 Total payments (NM) 00179

Definition: This field contains the total payments for visit.

3.3.3.50 Alternate visit ID (CX) 00180

Components: <ID (ST) ^ <check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <assigning authority (HD) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field contains the alternative, temporary, or pending optional visit ID number to be used if needed. It is the ID used by the facility to identify a patient uniquely at the time of an admit or visit. Refer to HL7 table 0061 - Check digit scheme, as defined in Chapter 2, for valid values. Refer to user-defined table 0192 - Visit ID type for suggested values.

3.3.3.51 Visit indicator (IS) 01226

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

User-defined Table 0326 - Visit Indicator
 
 
Value
Description
Account Level (default)
Visit Level

3.3.3.52 Other healthcare provider (XCN) 01224

Components: <ID number (ST) ^<family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^<assigning authority (HD) ^<name type code(ID) ^<identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field contains the other healthcare providers (e.g., Nurse care practitioner, midwife, physician assistant). Multiple healthcare providers can be sent. Depending on local agreements, either the ID or the name may be absent from this field. Use values in user-defined table 0010 - Physician ID for first component.

3.3.3.53 PV1 usage notes

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

Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page
 
 

3.3.4 PV2 - patient visit - additional information segment

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

Figure 3-4. PV2 attributes

SEQ
LEN DT
OPT
RP/# TBL# ITEM# ELEMENT NAME
80 PL
C
    00181 Prior Pending Location
2
60 CE
O
  0129 00182 Accommodation Code
3
60 CE
O
    00183 Admit Reason
4
60 CE
O
    00184 Transfer Reason
5
25 ST
O
Y   00185 Patient Valuables
6
25 ST
O
    00186 Patient Valuables Location
7
2 IS
O
  0130 00187 Visit User Code
8
8 DT
O
    00188 Expected Admit Date
9
8 DT
O
    00189 Expected Discharge Date
10
3 NM
O
    00711 Estimated Length of Inpatient Stay
11
3 NM
O
    00712 Actual Length of Inpatient Stay
12
50 ST
O
    00713 Visit Description
13
90 XCN
O
    00714 Referral Source Code
14
8 DT
O
    00715 Previous Service Date
15
1 ID
O
  0136 00716 Employment Illness Related Indicator
16
1 IS
O
  0213 00717 Purge Status Code
17
8 DT
O
    00718 Purge Status Date
18
2 IS
O
  0214 00719 Special Program Code
19
1 ID
O
  0136 00720 Retention Indicator
20
1 NM
O
    00721 Expected Number of Insurance Plans
21
1 IS
O
  0215 00722 Visit Publicity Code
22
1 ID
O
  0136 00723 Visit Protection Indicator
23
90 XON
O
Y   00724 Clinic Organization Name
24
2 IS
O
  0216 00725 Patient Status Code
25
1 IS
O
  0217 00726 Visit Priority Code
26
8 DT
O
    00727 Previous Treatment Date
27
2 IS
O
  0112 00728 Expected Discharge Disposition
28
8 DT
O
    00729 Signature on File Date
29
8 DT
O
    00730 First Similar Illness Date
30
3 IS
O
  0218 00731 Patient Charge Adjustment Code
31
2 IS
O
  0219 00732 Recurring Service Code
32
1 ID
O
  0136 00733 Billing Media Code
33
26 TS
O
    00734 Expected Surgery Date & Time
34
2 ID
O
  0136 00735 Military Partnership Code
35
2 ID
O
  0136 00736 Military Non-Availability Code
36
1 ID
O
  0136 00737 Newborn Baby Indicator
37
1 ID
O
  0136 00738 Baby Detained Indicator

3.3.4.0 PV2 field definitions

3.3.4.1 Prior pending location (PL) 00181

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

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

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

3.3.4.2 Accommodation code (CE) 00182

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

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

3.3.4.3 Admit reason (CE) 00183

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

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

3.3.4.4 Transfer reason (CE) 00184

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

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

3.3.4.5 Patient valuables (ST) 00185

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

3.3.4.6 Patient valuables location (ST) 00186

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

3.3.4.7 Visit user code (IS) 00187

Definition: This field further categorizes a patient’s visit with respect to an individual institution’s needs (e.g., teaching flag = TE, indicating the patient is a teaching case). Refer to user-defined table 0130 - Visit user code for suggested values.

3.3.4.8 Expected admit date (DT) 00188

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

3.3.4.9 Expected discharge date (DT) 00189

Definition: This field contains a non-event related date used by ancillaries to determine more accurately the projected workloads. This field is also used to reflect the date/time of an outpatient/emergency patient registration.

3.3.4.10 Estimated length of inpatient stay (NM) 00711

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

3.3.4.11 Actual length of inpatient stay (NM) 00712

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

3.3.4.12 Visit description (ST) 00713

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

3.3.4.13 Referral source (XCN) 00714

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type (ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <identifier type code (IS) ^ <assigning facility ID (HD)

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

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

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

3.3.4.14 Previous service date (DT) 00715

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

3.3.4.15 Employment illness related indicator (ID) 00716

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

3.3.4.16 Purge status code (IS) 00717

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

User-defined table 0213 - Purge status

Value
Description
Marked for purge. User is no longer able to update the visit.
The visit is marked for deletion and the user cannot enter new data against it.
The visit is marked inactive and the user cannot enter new data against it.

3.3.4.17 Purge status date (DT) 00718

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

3.3.4.18 Special program code (IS) 00719

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

3.3.4.19 Retention indicator (ID) 00720

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

3.3.4.20 Expected number of insurance plans (NM) 00721

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

3.3.4.21 Visit publicity code (IS) 00722

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

3.3.4.22 Visit protection indicator (ID) 00723

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

3.3.4.23 Clinic organization name (XON) 00724

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

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

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

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

3.3.4.24 Patient status code (IS) 00725

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

3.3.4.25 Visit priority code (IS) 00726

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

3.3.4.26 Previous treatment date (DT) 00727

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

3.3.4.27 Expected discharge disposition (IS) 00728

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

3.3.4.28 Signature on file date (DT) 00729

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

3.3.4.29 First similar illness date (DT) 00730

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

3.3.4.30 Patient charge adjustment code (IS) 00731

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

3.3.4.31 Recurring service code (IS) 00732

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

3.3.4.32 Billing media code (ID) 00733

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

3.3.4.33 Expected surgery date and time (TS) 00734

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

3.3.4.34 Military partnership code (ID) 00735

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

3.3.4.35 Military non availability code (ID) 00736

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

3.3.4.36 Newborn baby indicator (ID) 00737

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

3.3.4.37 Baby detained indicator (ID) 00738

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

Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page
 

4.2.1 ORM - general order message

The function of this message is to initiate the transmission of information about an order. This includes placing new orders, cancellation of existing orders, discontinuation, holding, etc. ORM messages can originate also with a placer, filler, or an interested third party.

The trigger event for this message is any change to an order. Such changes include submission of new orders, cancellations, updates, patient and nonpatient specific orders, etc.

ORM     General Order Message      Chapter



MSH     Message Header        2



 [{NTE}]    Notes and Comments (for Header)    2



[



   PID    Patient Identification      3



   [PD1]    Additional Patient Identification    3



      [{NTE}]  Notes and Comments (for Patient ID)    2



   [PV1    Patient Visit        3



    [PV2|]   Patient Visit Additional Information   3



    [{IN1   Insurance         6



      [IN2]   Insurance Additional Info      6



   [IN3]   Insurance Additional Info      6



    }]



    [GT1]   Guarantor         6



    [{AL1}]   Allergy          3



  ]    



]



 {



   ORC    Common Order         4



  [



   Order Detail Segment OBR, etc.         4



       [{NTE}]  Notes and Comments (for Detail)      2



       [{DG1}]  Diagnosis         6



       [



        {



         OBX   Observation/Result       7



              [{NTE}] Notes and Comments (for Results)     2



         }



       ]



  ]



  {[CTI]}   Clinical Trial Identification     7



 [BLG]    Billing segment                      4



 }

4.2.1.1 ORM use notes

a) The abstract message syntax for some order segments vary slightly. Please refer to the appropriate sections for specific examples: for supply orders (RQ), see Section 4.7, "SUPPLY ORDERS"; for pharmacy, see Section 4.8, "PHARMACY/TREATMENT ORDERS"; and for dietary orders, see Section 4.6, "DIET ORDERS."

b) The segment named "Order Detail Segment" represents whichever of these order detail segment(s) is appropriate to the message, currently OBR, RQD, RQ1, RXO, ODS, ODT.

c) The NTE segment(s) can be included in the ORM message in four places; in each place the NTE refers to the segment which it follows. In particular, the NTEs following the MSH refer only to the message header, the NTEs following the order detail segment apply to the service defined by that ORC and order detail segment.

d) The PID segment is required if and only if new orders are being entered and they are related to a particular patient. For nonpatient-related orders the PID segment is never included.

e) The optional PV1 segment is present mainly to permit transmission of patient visit information such as current location with an order.

f) The order detail segments are not required when a simple control message is being sent. For example, a hold message (ORC-1-order control = HD) does not require that an order segment follow it.

g) ORC-1-order control is critical to the operation of both ORM and ORR messages. For example, to request cancellation of an order, one would transmit a CA in ORC-1-order control of the appropriate ORC. (See the definition of ORC-1-order control.)

h) A method to inquire for order status in the display format is provided in Chapter 2, and uses the record format provided in Chapter 7.

i) Each order message that defines any type of new order (ORC-1-order control = NW, CH, RO or SN) requires an ORC/OBR pair to define each order to the receiving application. This also applies to any other types of orders, with the OBR being replaced by the appropriate order detail segment, as defined below. Thus two consecutive ORCs could occur if a cancel order request (needing only the order numbers) were followed by a second cancel order request. Many other examples are possible.

j) The insurance segments (IN1, IN2, and GT1) are typically used for external fillers, e.g., reference labs, where formal ADT transactions are overly complex or not needed.

Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page
 

4.3.1 ORC - common order segment

The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). The ORC segment is required in the Order (ORM) message. ORC is mandatory in Order Acknowledgment (ORR) messages if an order detail segment is present, but is not required otherwise..

If details are needed for a particular type of order segment (e.g., Pharmacy, Dietary), the ORC must precede any order detail segment (e.g., RXO, ODS). In some cases, the ORC may be as simple as the string ORC|OK|<placer order number|<filler order number|<CR.

If details are not needed for the order, the order detail segment may be omitted. For example, to place an order on hold, one would transmit an ORC with the following fields completed: ORC-1-order control with a value of HD, ORC-2-placer order number, and ORC-3-filler order number.

There is some overlap between fields of the ORC and those in the order detail segments. These are described in the succeeding sections.

Figure 4-1. ORC attributes

SEQ
LEN
DT
OPT
RP/#
TBL#
ITEM#
ELEMENT NAME
2 ID
R
 
0119 00215 Order Control
22 EI
C
 
  00216 Placer Order Number
22 EI
C
 
  00217 Filler Order Number
22 EI
O
 
  00218 Placer Group Number
2 ID
O
 
0038 00219 Order Status
1 ID
O
 
0121 00220 Response Flag
200 TQ
O
 
  00221 Quantity/Timing
200 CM
O
 
  00222 Parent
26 TS
O
 
  00223 Date/Time of Transaction
10 
120 XCN
O
 
  00224 Entered By
11 
120 XCN
O
 
  00225 Verified By
12 
120 XCN
O
 
  00226 Ordering Provider
13
80 PL
O
 
  00227 Enterer's Location
14 
40 XTN
O
Y/2
  00228 Call Back Phone Number
15 
26 TS
O
 
  00229 Order Effective Date/Time
16 
200 CE
O
 
  00230 Order Control Code Reason
17 
60 CE
O
 
  00231 Entering Organization
18 
60 CE
O
 
  00232 Entering Device
19 
120 XCN
O
 
  00233 Action By

ORC use notes

a) placer order groups

The Standard supports a mechanism to collect several orders together in a group. Most often this is used to represent an "ordering session" for a single patient.

An order group is a list of orders (ORCs) associated with a ORC-4-placer group number. A group is established when the placer supplies a placer group number with the original order. The order group consists of all the ORCs and order detail segments that have the same placer group number. Orders can be removed from the group using cancel, or added using the replacement or parent-child mechanisms. New orders cannot otherwise be added to the group.

b) duplicate fields

The ORC is intended to uniformly define the fields that are common to all orders (i.e., requested services). Some ORC fields are duplicated in some order detail segments (e.g., OBR, RXO). For example, ORC-2-placer order number has the same meaning and purpose as OBR-2-placer order number field. This promotes upward compatibility with past versions and ASTM.

The rule for using these fields is that the value must appear in the order detail segment if it does not appear in the ORC. However, it is recommended to transmit the field value in both places to avoid confusion.

c) parent/child - cancel, hold, discontinue

During transmission of a request to cancel, hold, or discontinue a parent order, the request is intended to apply recursively to the parent order and all associated child orders.

For example:

1) An EKG application receives an order for three EKGs on successive mornings.

2) The EKG application creates three child orders, one for each requested EKG.

3) The first daily EKG has already been performed when a request is received to cancel the original parent order. (The parent is beyond the point of cancellation.)

4) The remaining, unperformed, children are canceled as a result of the request.

4.3.1.0. ORC field definitions

4.3.1.1 Order control (ID) 00215

Definition: determines the function of the order segment. Refer to HL7 table 0119 - Order control for valid entries. Very detailed explanatory notes are given at the end of this section.

This field may be considered the "trigger event" identifier for orders. The codes fall roughly into the following three categories:

a) event request

Codes like "NW" (new order) and "CA" (cancel order request) are used to initiate an event.

b) event acknowledgment

Codes like "OK" (order accepted) and "CR" (canceled as requested) are used to reply to the event request.

c) event notification

Codes like "OC" (order canceled) and "OD" (order discontinued) are used to notify other applications that an event has occurred. No application reply is necessary.

Event request codes are intended to initiate an event. Event acknowledgment codes are intended to reply to an application that requested an event. Event notification codes are intended to notify another application that, e.g., the filler has performed some action on an order that the other application, e.g., the placer needs to know.

Fillers, placers, and other applications can use event requests, event acknowledgments, and event - notification-type trigger events interchangeably. However, certain order control codes can originate only from the filler (e.g., CR) and others can only originate from the placer (e.g., CA).

Table 0119 - Order control codes and their meaning

Value1 Description Originator2 Field Note3
NW New order P I
OK Order accepted & OK F I
UA Unable to Accept Order F n
       
CA Cancel order request P a
OC Order canceled F  
CR Canceled as requested F  
UC Unable to cancel F b
       
DC Discontinue order request P c
OD Order discontinued F  
DR Discontinued as requested F  
UD Unable to discontinue F  
       
HD Hold order request P  
OH Order held F  
UH Unable to put on hold F  
HR On hold as requested F  
       
RL Release previous hold P  
OE Order released F  
OR Released as requested F  
UR Unable to release F  
       
RP Order replace request P e,d,h
RU Replaced unsolicited F f,d,h
RO Replacement order P,F g,d,h,l
RQ Replaced as requested F d,e,g,h
UM Unable to replace F  
       
PA Parent order F I
CH Child order F,P i
       
XO Change order request P  
XX Order changed, unsol. F  
UX Unable to change F  
XR Changed as requested F  
       
DE Data errors P,F  
RE Observations to follow P,F j
RR Request received P,F k
SR Response to send order status request F  
SS Send order status request P  
SC Status changed F,P  
SN Send order number F l
NA Number assigned P l
CN Combined result F m
       
RF Refill order request F, P o
AF Order refill request approval P p
DF Order refill request denied P q
FU Order refilled, unsolicited F r
OF Order refilled as requested F s
UF Unable to refill F t
LI Link order to patient care message u  
UN Unlink order from patient care message u  

Notes:

1 The order control value field

2 "F": Values originate from the filler and are not restricted to be sent only to the placer. P": Values originate from the placer or other application with placer privileges (as agreed in interface negotiation.

3 See table notes below for explanation of codes.

4.3.1.1.1 Table notes for order control codes of ORC
a) CA

A cancellation is a request not to do a previously ordered service. Confirmation of the cancellation request is provided by the filler, e.g., a message with an ORC-1-order control value of CR.

b) UC

An unable-to-cancel code is used when the ordered service is at a point that it cannot be canceled by the filler or when local rules prevent cancellation by the filler. The use of this code is dependent on the value of ORC-6-response flag.

c) DC

A discontinue request code is used to stop an ongoing ordered service. It is not the same as a cancellation request, which is used in an attempt to prevent an order from happening.

d) RP, RQ, RU, RO

A replacement is the substitution of one or more orders for one or more previously ordered services.

The replaced orders are treated as though they were canceled. If and when an ordered service can be replaced are local site-specific determinations.

Use the parent/child order control codes if the site specifies that the original order must remain intact. Do not use the replacement codes under this circumstance.

For each order to be replaced, use an ORC-1-order control value of RP (request for a replacement going to a filler) or RU (an unsolicited replacement created by the filler) used by the filler to notify the placer and/or other systems). By local agreement, the ORC segment (with RP or RU) may be followed by its original order detail segment. The ORC segments (with RP or RU) must be followed by an ORC segment with an ORC-1-order control value of RO (indicating the replacement order). By local agreement, the ORC with the RO value may be followed by an order detail segment.

For example, suppose that an ancillary application were replacing two OBR orders with three different orders. The sequence of segments would be as follows:

Figure 4-2. RU and RO usage (example)
 
 
Segment
Order Control
Comment
ORC
RU
1st replaced ORC
OBR
 
1st replaced order's detail segment
 
 
 
ORC
RU
2nd replaced ORC
OBR
 
2nd replaced order's detail segment
 
 
 
ORC
RO
1st replacement ORC
OBR
 
1st replacement order's detail segment
 
 
 
ORC
RO
2nd replacement ORC
OBR
 
2nd replacement order's detail segment
 
 
 
ORC
RO
3rd replacement ORC
OBR
 
3rd replacement order's detail segment

Whether the OBR segments must be present is determined by the value of ORC-6-response flag.

The described replacement method will handle all possible cases of replacement: one-into-one, many-into-one, one-into-many, and many-into-many. If the placer sent this request to the filler with two RPs, and this was a response back from the filler to the placer, the two RUs (replaced unsolicited) would be two RQs (replaced as requested).

Figure 4-3. RQ and RO usage (example)
 
 
Segment
Order Control
Comment
ORC
RQ
1st replaced ORC
OBR
 
1st replaced order's detail segment
 
 
 
ORC
RQ
2nd replaced ORC
OBR
 
2nd replaced order's detail segment
 
 
 
ORC
RO
1st replacement ORC
OBR
 
1st replacement order's detail segment
 
 
 
ORC
RO
2nd replacement ORC
OBR
 
2nd replacement order's detail segment
 
 
 
ORC
RO
3rd replacement ORC
OBR
 
3rd replacement order's detail segment

e) RP, RQ

The order replace request code permits the order filler to replace one or more new orders with one or more new orders, at the request of the placer application.

f) RU

The unsolicited replacement code permits the filler application to notify another application without being requested from the placer application.

g) RO, RQ

The replacement order code is sent by the filler application to another application indicating the exact replacement ordered service. It is used with the RP and RU order control codes as described above.

h) RP, RQ, RU, RO

The rules for the order numbers in ORC segments with an order control value of RO are determined by the replacement type (RP or RU).

In the case of the RU type (i.e., unsolicited replacement by the filler), the filler order number is generated as usual by the filler application. The placer order number is identical to the placer order number of the first transmitted ORC with an order control value of RU.

In the case of the RP type (i.e., a replacement request from another application to the filler), the placer order number is generated by the placer application using the procedure for new orders. The filler order number is generated by the filler application using the procedure identical for new orders.

If a replacement sequence is used in an ORU message (i.e., during results reporting), the following are the recommended segments to be used for the replacement orders:

1) ORC with an order control value of RO

2) Any OBR segments (can be replaced by any order detail segments)

3) Optionally followed by observation result segments (OBX)

4) NTE segments can appear after the OBR (or any order detail segment) or after an OBX segment as in a regular ORU message

i) PA, CH

The parent (PA) and child (CH) order control codes allow the spawning of "child" orders from a "parent" order without changing the parent (original order). One or more ORC segments with an ORC-1-order control value of PA are followed by one or more ORC segments with an ORC-1-order control value of CH. Whether OBR segments must be present is determined by the value of ORC-6-response flag.

For example, suppose that a microbiology culture produced two organisms and corresponding susceptibility reports. Then the sequence of segments would be as follows:

Figure 4-4. Example of two child orders
 
 
Segment
Order Control
Comment
ORC
PA
1st parent ORC
ORC
CH
1st child ORC
OBR
 
1st child order
 
 
 
ORC
CH
2nd child ORC
OBR
 
2nd child order

The assignment of placer numbers in the parent-child paradigm depends on whether the placer or filler creates the child order and in the latter case, on whether the placer supports the SN/NA transaction. If the placer creates the child orders it will assign their placer numbers according to its usual procedures. If the filler creates the child orders there are two possibilities: each child will inherit the placer number of its parent, or the filler will use the SN/NA transaction to request that the placer assign a placer number. In either case, the filler application creates the filler numbers of the children according to its usual procedures.

Whenever a child order is transmitted in a message the ORC segment’s ORC-8-parent is valued with the parent’s filler number (if originating from the filler) and with the parent’s placer number (if originating from the filler or if originating from the placer).

The parent-child mechanism can be used to "expand" a parent order (e.g., an order for three EKGs on successive mornings).

j) RE

The observations-to-follow code is used to transmit patient-specific information with an order. An order detail segment (e.g., OBR) can be followed by one or more observation segments (OBX). Any observation that can be transmitted in an ORU message can be transmitted with this mechanism. When results are transmitted with an order, the results should immediately follow the order or orders that they support.

The following example shows the sequence of segments for three Pharmacy orders. It illustrates the use of the RE code:

Figure 4-5. RE usage (example)

Segment
Order Control
Comment
MSH
 
 
PID
 
 
ORC
NW
First new order
RXO
 
First order segment
 
 
 
ORC
NW
2nd new order
RXO
 
2nd order segment
[ORC
RE
Patient-specific observation, optional in V 2.2
OBR]
 
Observation OBR, optional in V 2.2
OBX
 
An observation segment
OBX
 
Another observation segment
OBX
 
Another observation segment
OBX
 
Another observation segment
 
 
 
ORC
NW
3rd order
RXO
 
3rd order segment

In this version of HL7, results can be transmitted with an order as one or more OBX segments without the necessity of including the ORC and OBR segments.

Observations can be transmitted in an ORU message without using an ORC. There are times when it is necessary to transmit information not included in the OBR segments of the ORU message. In this case, it is recommended that the ORC be included in the ORU message.

The order control value of RE is required only in ORM messages to indicate that an order is followed by observation results (OBX). The RE code is not necessary in the ORU message because it is expected that the OBR segments can be followed by observation results (OBX).

k) RR

Left in for backwards compatibility. In the current version it is equivalent to an accept acknowledgment. The request-received code indicates that an order message has been received and will be processed later. The order has not yet undergone the processing that would permit a more exact response.

l) SN, NA, NW

There are three circumstances that involve requesting an order number (ORC-2-placer order number or ORC-3-filler order number):

1) When the filler application needs to request an ORC-3-filler order number from a centralized application (e.g., HIS)

2) When the filler application needs to request an ORC-2-placer order number from some other application (e.g., Order Entry)

3) When an application (not the filler application) wants to assign an ORC-3-filler order number for a new order

1) The filler application needs a centralized filler order number

SN The send order number code provides a mechanism for the filler to request an ORC-3-filler order number from some centralized application (called "other" in the table below), such as a central HIS, by sending an ORM message containing an ORC-1-order control value of SN. This ORC has a null ORC-3-filler order number and an ORC-2-placer order number created by the filler application when the filler originates the order.

The ORM (SN type) message can be acknowledged by two methods:

i) By an ORR message containing an ORC-1-order control value of OK. An unsolicited ORM message can be sent at a future time, containing an ORC with ORC-1-order control value of NA.

ii) By an ORR message containing an ORC-1-order control value of NA as described below.

NA The number assigned code allows the "other" application to notify the filler application of the newly assigned filler order number. ORC-1-order control contains value of NA, ORC-2-placer order number (from the ORC with the SN value), and the newly assigned filler order number.
 
 
Note: Both the placer order number and the filler order number have the filler's application ID.

 

Code
From
ORC-2-Placer Order Number
ORC-3-Filler Order Number
SN filler application placer order number^filler application ID null
NA other application placer order number^filler application ID filler order number^filler application ID

2) The filler application needs a placer order number

SN The send order number code provides a mechanism for the filler application to request an ORC-2-placer order number from another application (called "other" in the table below) by sending an ORM message containing an ORC-1-order control value of SN. This ORC has a null ORC-2-placer order number and an ORC-3-filler order number created by the filler application when the filler originates the order.

The ORM (SN type) message can be acknowledged by two methods:

i) By an ORR message containing an ORC-1-order control value of OK. An unsolicited ORM message can be sent at a future time, containing an ORC-1-order control value of NA.

ii) By an ORR message containing an ORC-1-order control value of NA as described below.

NA The number assigned code allows the "other" application to notify the filler application of the newly assigned ORC-2-placer order number. The ORC contains an ORC-1-order control value of NA, the newly assigned ORC-2-placer order number, and the ORC-3-filler order number (from the ORC with the SN value).
 
 
Note: The new ORC-2-placer order number has the placer's application ID.

 

Code
From
ORC-2-Placer Order Number
ORC-3-Filler Order Number
SN filler application null filler order number^filler application ID
NA other application placer order number^placer application ID filler order number^filler application ID

3) An application wants to assign a filler order number

NW When the application creating an order (not the filler application) wants to assign a filler order number for a new order

or

RO (RO following an RP). In this case, the "other" application completes ORC-3-filler order number, using the filler application ID as the second component of the filler order number.

Code
From
ORC-2-Placer Order Number
ORC-3-Filler Order Number
NW or RO other application to the filler placer order number^placer application ID filler order number^filler application ID

m) CN

The combined result code provides a mechanism to transmit results that are associated with two or more orders. This situation occurs commonly in radiology reports when the radiologist dictates a single report for two or more exams represented as two or more orders. For example, knee and hand films for a rheumatoid arthritis patient might generate a single dictation on the part of the radiologist.

When such results are reported the CN code replaces the RE code in all but the last ORC, and the results follow the last ORC and its OBR. An example follows of a single report following three ORCs:

MSH|...



PID|...



ORC|CN|...



OBR||A4461XA^HIS|81641^RAD|73666^Bilateral Feet|...



ORC|CN|...



OBR||A4461XB^HIS|81642^RAD|73642^Bilateral Hand PA|... 



ORC|RE|...



OBR||A4461XC^HIS|81643^RAD|73916^Bilateral Knees|...



OBX||CE|73916&IMP||Radiologist's Impression|...



OBX||CE|73642&IMP||Radiologist's Impression|...



OBX||FT|73642&GDT||Description|...
n) UA

An unable-to-accept code is used when a new order cannot be accepted by the filler. Possible reasons include requesting a prescription for a drug which the patient is allergic to or for an order which requires certain equipment resources which are not available such that the order cannot be filled. Note that this is different from the communication level acceptance as defined within the MSA segment.

o) RF

RF accommodates requests by both the filler or the placer. The filler may be requesting refill authorization from the placer. A placer system may be requesting a refill to be done by the filler system.

p) AF

AF is a response back from the placer authorizing a refill or quantity of refills.

q) DF

DF indicates that the placer will not authorize refills for the order. The order control code reason may be used to indicate the reason for the request denial. Some suggested values include:

AA Patient unknown to the provider
AB Patient never under provider care
AC Patient no longer under provider care
AD Patient has requested refill too soon
AE Medication never prescribed for the patient
AF Patient should contact provider first
AG Refill not appropriate

Note that these values originate from the NCPDP SCRIPT Response Segment Code List Qualifiers.

r) FU

FU notifies the placer that the filler issued a refill for the order at the patient’s request.

s) OF

OF directly responds to the placer system’s request for a refill

t) UF

UF indicates an application level denial by the filler system to an authorized refill request.

u) LI, UN

Use only with patient care messages, Chapter 12.

4.3.1.2 Placer order number ( EI) 00216

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

Definition: This field is the placer application's order number.

This field is a case of the Entity Identifier data type (2.8.13). The first component is a string that identifies an individual order (e.g., OBR). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.8.18, "HD - Hierarchic designator"). The second components, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The two components are separated by a component delimiter.

There are three situations in which the true placer is somewhat arbitrary (and thus not unique):

a) in ORC-1-order control value of RO, following an RU replacement;

b) in ORC-1-order control value of CH (child orders); and

c) in ORC-1-order control value of SN (send number).

See the Table Notes under ORC-1-order control for the details of how the ORC-2-placer order number is assigned in these cases.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution’s master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

ORC-2-placer order number is the same as OBR-2-placer order number. If the placer order number is not present in the ORC, it must be present in the associated OBR and vice versa. If both fields, ORC-2-placer order number and OBR-2-placer order number are valued, they must contain the same value. When results are transmitted in an ORU message, an ORC is not required, and the identifying placer order number must be present in the OBR segments.

These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).

4.3.1.3 Filler order number ( EI) 00217

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

Definition: This field is the order number associated with the filling application. It is a case of the Entity Identifier data type (2.8.13). Its first component is a string that identifies an order detail segment (e.g., OBR). A limit of fifteen (15) characters is suggested but not required. It is assigned by the order filler (receiving) application. This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see Section 2.8.18, "HD - hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third- party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the filler application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

ORC-3-filler order number is the same as OBR-3-filler order number. If the filler order number is not present in the ORC, it must be present in the associated OBR. (This rule is the same for other identical fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is particularly important when results are transmitted in an ORU message. In this case, the ORC is not required and the identifying filler order number must be present in the OBR segments.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

4.3.1.4 Placer group number (EI) 00218

Components: <entity identifier (ST) ^ <namespace (D (IS) ^ <universal ID (ST) ^ <universal ID type (ID)

Definition: This field allows an order placing application to group sets of orders together and subsequently identify them. It is a case of an Entity Identifier data type (2.8.13).

The first component is a string that uniquely identifies all order groups from the given placer application. A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer application and may come from the same series as the placer order number of the ORC, but this is not required.

The second through fourth components constitute a placer application ID identical to the analogous components of ORC-2-placer order number. Order groups and how to use them are described in detail in Section 4.3.1, "PRC - common order segment."

4.3.1.5 Order status (ID) 00219

Definition: This field is the status of an order. Refer to HL7 table 0038 - Order status for valid entries. The purpose of this field is to report the status of an order either upon request (solicited), or when the status changes (unsolicited). It does not initiate action. It is assumed that the order status always reflects the status as it is known to the sending application at the time that the message is sent. Only the filler can originate the value of this field.

Although HL7 table 0038 - Order status contains many of the same values contained in HL7 table 0119 - Order control, the purpose is different. Order status may typically be used in a message with an ORC-1-order control value of SR or SC to report the status of the order on request or to any interested party at any time.

Table 0038 - Order status

Value 
Description
A
Some, but not all, results available
CA
Order was canceled
CM
Order is completed
DC
Order was discontinued
ER
Error, order not found
HD
Order is on hold
IP
In process, unspecified
RP
Order has been replaced
SC
In process, scheduled

4.3.1.6 Response flag (ID) 00220

Definition: This field allows the placer (sending) application to determine the amount of information to be returned from the filler. Sometimes the requested level of response may not be possible immediately, but when it is possible, the filler (receiving) application must send the information. When the field is null, D is the default value of the field. Refer to HL7table 0121 - Response flag for valid entries.

Table 0121 - Response flag

Value
Description
E
Report exceptions only
R
Same as E, also Replacement and Parent-Child
D
Same as R, also other associated segments
F
Same as D, plus confirmations explicitly
N
Only the MSA segment is returned

4.3.1.7 Quantity/timing (TQ) 00221

Components: <quantity (CQ) ^ <interval (CM) ^ <duration ^ <start date/time (TS) ^ <end date/time (TS) ^ <priority (ID) ^ <condition (ST) ^ <text (TX) ^ <conjunction (ID) ^ <order sequencing

Definition: This field determines the priority, quantity, frequency, and timing of an atomic service. Order segments should be thought of as describing an atomic service. It is a composite field that is defined in detail in Section 4.4, "Quantity/Timing (TQ) Definition."

For example, if an OBR segment describes a unit of blood, this field might request that 3 such units be given on successive mornings. In this case ORC-7-quantity/timing would be "1^XQAM^X3". ORC-7-quantity/timing is the same as OBR-27-quantity/timing.

4.3.1.8 Parent (CM) 00222

Components: <parent's placer order number (EI) ^ <parent's filler order number (EI)

Subomponents of parent’s placer order number: <entity identifier (ST) & <namespace ID (IS) & <universal ID (ST) & <universal ID type (IS)

Subomponents of parent’s filler order number: <entity identifier (ST) & <namespace ID (IS) & <universal ID (ST) & <universal ID type (IS)

Definition: This field relates a child to its parent when a parent-child relationship exists. The parent-child mechanism is described under ORC-1-order control notes. The first component contains the placer order number of the parent order. It is required when the order is a child.

The second through fourth components contain the filler order number of the parent order.

The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field. ORC-8-parent is the same as OBR-29-parent.

4.3.1.9 Date/time of transaction (TS) 00223

Definition: This field is the date and time the current transaction enters the ordering application. For messages creating new orders, this is the date and time the order was entered.

For other messages, this is the date and time the current transaction (e.g., cancellation) enters the sending application. This date and time is for the current transaction and is not a "replacement" time for a correction to the original order. Similarly, ORC-10-entered by, ORC-11-verified by, and ORC-13-enterers location of this segment relate to the current transaction, not the original order.

4.3.1.10 Entered by (XCN) 00224

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID ) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field is the identity of the person who actually keyed the request into the application. It provides an audit trail in case the request is entered incorrectly and the ancillary department needs to clarify the request. By local agreement, either the ID number or name component may be omitted.

4.3.1.11 Verified by (XCN) 00225

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID ) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field is the identity of the person who verified the accuracy of the entered request. It is used in cases where the request is entered by a technician and needs to be verified by a higher authority (e.g., a nurse). By local agreement, either the ID number or name component may be omitted.

4.3.1.12 Ordering provider (XCN) 00226

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID ) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field is the identity of the person who is responsible for creating the request (i.e., ordering physician). ORC-12-ordering provider is the same as OBR-16-ordering provider.

4.3.1.13 Enterer's location (PL) 00227

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 the location (e.g., nurse station, ancillary service location, clinic, floor) where the person who entered the request was physically located when the order was entered. Only those subcomponents relevant to enterer’s location should be valued (commonly nursing unit; facility; building; floor). The person who entered the request is defined in ORC-10-entered by.

4.3.1.14 Call back phone number (XTN) 00228

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID) ^ <telecommunication equipment type (ID) ^ <email address (ST) ^ <country code (NM) ^ <area/city code (NM) ^ <phone number (NM) ^ <extension (NM) ^ <any text (ST)

Definition: This field is the telephone number to call for clarification of a request or other information regarding the order. ORC-14-call back phone number is the same as OBR-17-order call back phone number.

4.3.1.15 Order effective date/time (TS) 00229

Definition: This field is the date/time that the changes to the request took effect or are supposed to take effect.

If ORC-9-transaction date/time is after or equal to ORC-16-order effective date/time, the data values in the ORC and its subordinate segments took effect on the order effective date/time.

If ORC-9-transaction date/time is before the time specified in ORC-15-order effective date/time, the data values in ORC and its subordinate segments are planned to take effect on the order effective date/time.

If ORC-15-order effective date/time is left blank, its value is assumed to be equal to that specified in ORC-9-transaction date/time or MSH-7-message date/time if the transaction date/time is blank.

In the case where the time specified in ORC-15-effective date/time (for the order control code event in the same ORC segment) is different from the corresponding date/time in ORC-7-quantity/timing, the time specified in ORC-15-order effective date/time takes precedence. Thus if the ORC event is a discontinue request to the filler for a continuing order, and the order-effective date/time is prior to the end date/time of ORC-7-quantity/timing, the order effective date/time should take precedence. If the order identified in the ORC has children, the children which have not started should be canceled; if there is a child in process, it should be discontinued; if a child has progressed beyond the point where it can be discontinued, its status is unaffected.

4.3.1.16 Order control code reason (CE) 00230

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

Definition: This field is the explanation (either in coded or text form) of the reason for the order event described by the order control code (HL7table 0119). Whereas an NTE after the order specific segment (e.g., RXO, ORO, OBR) would provide a comment for that specific segment, the purpose of the order control code reason is only to expand on the reason for the order event.

ORC-16-order control code reason is typically not valued when ORC-1-order control is NW, although it could be. In the case of a canceled order, for example, this field is commonly used to explain the cancellation. A Pharmacy system that canceled a drug order from a physician because of a well documented allergy would likely report the fact of the allergy in this field.

If it canceled the order because of a drug interaction this field might contain at least the names (and codes, if needed) of the interacting substances, the text describing the interaction, and the level of severity of the interaction.

4.3.1.17 Entering organization (CE) 00231

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

Definition: This field is the organization that the enterer belonged to at the time he/she enters/maintains the order, such as medical group or department. The person who entered the request is defined in ORC-10 -entered by.

4.3.1.18 Entering device (CE) 00232

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

Definition: This field is the identifier of the physical device (terminal, PC) used to enter the order.

4.3.1.19 Action by (XCN) 00233

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID ) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field is the identity of the person who initiated the event represented by the corresponding order control code. For example, if the order control code is CA (cancel order request), this field represents the person who requested the order cancellation. This person is typically a care provider but may not always be the same as ORC-12 ordering provider.

Previous PageTOCIndexNext Page

4.4 QUANTITY/TIMING (TQ) DEFINITION

Components: <quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ST)> ^ <order sequencing (CM)>

Definition: Quantity/timing (ORC-7, OBR-27) provides a means of specifying when the service described by the order segment is to be performed and how frequently. It is a complex multicomponent field that can have repeats; i.e., more than one quantity/timing specification, separated by repeat delimiters, may appear. It is a distinct data type (see Section 2.8.41, "TQ - timing quantity"). The components of a single quantity/timing specification are described in the Sections: 4.4.1, "OVERVIEW," through 4.4.10, "Order sequencing component (CM)."

Previous PagePrevious PageTOCIndexNext Page

4.4.1 Quantity component (CQ)

Subcomponents: <quantity (NM) & units (CE)>

Definition: This field is the quantity of the service that should be provided at each service interval. E.g, if two blood cultures to be obtained every 4 hours, the quantity would be 2. If three units of blood are to be typed and cross-matched, the quantity would be 3. The default value is 1. When units are required, they can be added, specified by a subcomponent delimiter.
 
Note: The component delimiter in this CQ is demoted to a subcomponent delimiter.

Previous PageTOCIndexNext Page

4.4.2 Interval component (CM)

Subcomponents: <repeat pattern (IS)> ^ <explicit time interval (ST)>

Definition: This field determines the interval between repeated services.

The default is one time only, the first subcomponent is the repeat pattern, and the second subcomponent is the explicit time at which pattern is to be executed.

4.4.2.1 Repeat pattern

Definition: The repeating frequency with which the treatment is to be administered. It is similar to the frequency and SIG code tables used in order entry systems. The following is preferred syntax for repeat patterns:

User-defined table 4001 - Repeat pattern
 
Q<integer>S  every <integer> seconds
Q<integer>M  every <integer> minutes
Q<integer>H  every <integer> hours
Q<integer>D  every <integer> days
Q<integer>W  every <integer> weeks
Q<integer>L  every <integer> months (Lunar cycle)
Q<integer>J<day#>  repeats on a particular day of the week, from the French jour (day). If <integer> is missing, the repeat rate is assumed to be 1. Day numbers are counted from 1=Monday to 7=Sunday. So Q2J2 means every second Tuesday; Q1J6 means every Saturday.
BID  twice a day at institution-specified times (e.g., 9AM-4PM)
TID  three times a day at institution-specified times (e.g., 9AM-4PM-9PM)
QID  four times a day at institution-specified times (e.g., 9AM-11AM-4PM-9PM)
xID  "X" times per day at institution-specified times, where X is a numeral 5 or greater. E.g., 5ID=five times per day; 8ID=8 times per day
Note: None of the above three specifications are equivalent to their Q<integer>H counterpart. QID is not Q6H. The former is unequally spaced; the latter is equally spaced.
QAM  in the morning at institution-specified time
QSHIFT  during each of three eight-hour shifts at institution-specified times
QOD  every other day (same as Q2D)
QHS  every day before the hour of sleep
QPM  in the evening at institution-specified time
service is provided continuously between start time and stop time
U <spec>  for future use, where <spec> is an interval specification as defined by the UNIX cron specification.
PRN  given as needed
PRNxxx  where xxx is some frequency code (e.g., PRNQ6H); given as needed over the frequency period.
Once  one time only. This is also the default when this component is null.

The first subcomponent may repeat, with repeat values separated by a space. The repeats are interpreted as connected by logical ANDs. E.g.,

Twice per day, every other day: BID QOD

Three times per day, Monday Wednesday and Friday: TID QJ135

Because of this syntax, repeat values should never contain blanks. If a free text frequency, such as "Twice a day, every other day" is to be sent, use the text component (component 8).

4.4.2.2 Explicit time interval subcomponent

Definition: This field explicitly lists the actual times referenced by the code in the first subcomponent, in the following format: HHMM,HHMM,HHMM,.… This second subcomponent will be used to clarify the first subcomponent in cases where the actual administration times vary within an institution. If the time of the order spans more than a single day, this new subcomponent is only practical if the same times of administration occur for each day of the order. If the actual start time of the order (as given by the fourth subcomponent of the quantity/timing field) is after the first explicit time, the first administration is taken to be the first explicit time after the start time. In the case where the patient moves to a location having a different set of explicit times, the existing order may be updated with a new quantity/timing field showing the changed explicit times.

Ex: 2nd component of quantity/timing field:

...^QID&0230,0830,1430,2030^...
Previous PageTOCIndexNext Page

4.4.3 Duration component (ST)

Definition: This field indicates how long the service should continue after it is started. The default is INDEF (do indefinitely). This component is coded as follows:
 
S<integer>  <integer> seconds
M<integer>  <integer> minutes
H<integer>  <integer> hours
D<integer>  <integer> days
W<integer>  <integer> weeks
L<integer>  <integer> months
X<integer>  <integer> times at interval specified in the order. A request for 2 blood cultures Q2H X3 would imply obtaining 2 blood cultures 3 different times at 2-hour intervals for a total of 6 blood cultures.
T<integer>  at the interval and amount stated until a total of <integer> "DOSAGE" is accumulated. Units would be assumed to be the same as in the QUANTITY field.
INDEF  = do indefinitely - also the default

Previous PageTOCIndexNext Page

4.4.4 Start date/time component (TS)

Definition: This field may be specified by the orderer, in which case it indicates the earliest date/time at which the services should be started. In many cases, however, the start date time will be implied or will be defined by other fields in the order record (e.g., urgency - STAT). In such a case, this field will be empty.

The filling service will often record a value in this field after receipt of the order, however, and compute an end time on the basis of the start date/time for the filling service’s internal use.

Previous PageTOCIndexNext Page

4.4.5 End date/time component (TS)

Definition: When filled in by the requester of the service, this field should be the latest date-time that the service should be performed. If it has not been performed by the specified time, it should not be performed at all. The requester may not always fill in this value, yet the filling service may fill it in on the basis of the instruction it receives and the actual start time.

Regardless of the value of the end date/time, the service should be stopped at the earliest of the date/times specified by either the duration or the end date/time.

Previous PageTOCIndexNext Page

4.4.6 Priority component (ST)

Definition: This field describes the urgency of the request. The following values are suggested (the default for Priority is R):
 
Stat.  With highest priority
ASAP  Fill after S orders
Routine.  Default
P Preop 
Callback 
Timing critical.  A request implying that it is critical to come as close as possible to the requested time, e.g., for a trough antimicrobial level.
PRN  As Needed 

If using the value "T" (timing critical), the degree of criticality can be specified thus:

Format:
 
TS<integer>  = timing critical within <integer> seconds
TM<integer>  = timing critical within <integer> minutes
TH<integer>  = timing critical within <integer> hours
TD<integer>  = timing critical within <integer> days
TW<integer>  = timing critical within <integer> weeks
TL<integer>  = timing critical within <integer> months

For the sequential orders specification, these values specify the time criticality with which the predecessor order must be followed by the given order.

The priority component may repeat; separate repeating values with the repeat delimiter separated by a space.

Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page

4.4.7 Condition component (ST)

Definition: This is a free text field that describes the conditions under which the drug is to be given. For example, PRN pain, or to keep blood pressure below 110. The presence of text in this field should be taken to mean that human review is needed to determine the how and/or when this drug should be given.

Previous PageTOCIndexNext Page

4.4.8 Text component (TX)

Definition: This field is a full text version of the instruction (optional).

Previous PageTOCIndexNext Page

4.4.9 Conjunction component (ST)

Definition: This non-null component indicates that a second timing specification is to follow using the repeat delimiter. This field can take three values:

a) S = Synchronous

Do the next specification after this one (unless otherwise constrained by the following components: ORC-4^4-start date/time and ORC-4^5-end date/time).

An "S" specification implies that the second timing sequence follows the first, e.g., when an order is written to measure blood pressure Q15 minutes for the 1st hour, then every 2 hours for the next day.

b) A = Asynchronous

Do the next specification in parallel with this one (unless otherwise constrained by the following components: ORC-4^4-start date/time and ORC-4^5-end date/time). The conjunction of "A" specifies two parallel instructions, as are sometimes used in medication, e.g., prednisone given at 1 tab on Monday, Wednesday, Friday, and at 1/2 tab on Tuesday, Thursday, Saturday, Sunday.

c) C = This is an actuation time

It will be followed by a completion time for the service. This code allows one to distinguish between the time and priority at which a service should be actuated (e.g., blood should be drawn) and the time and priority at which a service should be completed (e.g., results should be reported).

For continuous or periodic services, the point at which the service is actually stopped is determined by the components ORC-4^5-end date/time and ORC-4^3-duration, whichever indicates an earlier stopping time. Ordinarily, only one of these components would be present, but if one requested an EKG with the specification

 ^1^QAM^X3^D10
then the EKG would be done for only three days since the number of repeats (3) defined the earlier stopping time.

Previous PageTOCIndexNext Page

4.4.10 Order sequencing component (CM)

Definition: There are many situations, such as the creation of an order for a group of intravenous (IV) solutions, where the sequence of the individual intravenous solutions (each an service in itself) needs to be specified, e.g., hyperalimentation with multi-vitamins in every third bottle.

There are other situations, where part of the order's instructions contains a results condition of some type, such as "PRN pain." There is currently a free text "condition" component of ORC-4-quantity/timing which allows any condition to be specified. However, to support a fully encoded version of order sequencing, or results condition, we have defined in the following paragraphs a 10th component of ORC-4-quantity/timing.

The sequencing conditions supported by this 10th component are based on the completion of a predecessor service.

Components beyond the 10th are reserved for future use in specifying multiple conditions to be evaluated before the execution of the order. Any such future specifications will be upwardly compatible from the current quantity/timing definitions.
 
Note: If the 10th component is present, the 7th component (condition) will be considered as a text "note" to be displayed on the order. That is, no attempt will be made to interpret it as part of the machine-readable sequencing specification. 

4.4.10.1 Subcomponents of sequences

To define a sequence condition, the 10th component of the quantity/timing field component is divided into the subcomponents described in Figure 4-7.

Figure 4-7. Subcomponents of order sequences

Subcomponent
Contains
Notes
1
Sequence/Results Flag S for sequence conditions; C for cyclical; R is reserved for possible future use. The C will be used for indicating a repeating cycle of orders; for example, individual intravenous solutions used in a cyclical sequence (a.k.a. "Alternating IVs"). This value would be compatible with linking separate orders or with having all cyclical order components in a single order. Likewise, the value would be compatible with either Parent-Child messages or a single order message to communicate the orders’ sequencing
2, 3 
Placer Order Number,

first two components

Required/Optional: Contains the first two components of the placer order number: entity identifier (ST) and namespace ID (IS) (respectively). Uses two subcomponents since the place order number is an EI data type. We have not defined sub-subcomponents in HL7.
4, 5
Filler Order Number,

first two components

Required/Optional: Contains the first two components of the filler order number: entity identifier (ST) and namespace ID (IS) (respectively). Uses two subcomponents since the place order number is an EI data type. We have not defined sub-subcomponents in HL7.
6
Sequence Condition Value The acceptable condition values have the form commonly used in project planning methodologies:
  <one of "SS", "EE", "SE", or "ES"> +/- <time>
  The first letter stands for start (S) or end (E) of predecessor order, where the predecessor is defined by the placer or filler order number in subcomponents 1,2 or subcomponents 3,4.
  The second letter stands for the start (S) or end (E) of the successor order, where the successor order is the order containing this quantity/timing specification.
  The time specifies the interval between the predecessor and successor starts or ends (see following examples).
  Where <time> is defined as: 

S<integer> do for <integer> seconds

M<integer> do for <integer> minutes

H<integer> do for <integer> hours

D<integer> do for <integer> days

W<integer> do for <integer> weeks

L<integer> do for <integer> months

7
Maximum Number of Repeats The maximum number of repeats to be used only on cyclic groups. The total number of repeats is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first.
8, 9
Place Order Number,

last two components

Required/Optional: Contains the last two components of the placer order number: universal ID (ST) and universal ID type (ID) (respectively). Uses two subcomponentsn since the place order number is an EI data type. We have not defined sub-subcomponents in HL7.
10, 11
Filler Order Number,

last two components

Required/Optional: Contains the last two components of the filler order number: universal ID (ST) and universal ID type (ID) (respectively). Uses two subcomponentsn since the place order number is an EI data type. We have not defined sub-subcomponents in HL7.

Use notes:

Suppose the following:

The predecessor order is defined by the OE1000&OrdEnt as the placer order number, in subcomponents 2 and 3 of component 10 of ORC-4-quantity/timing.

The successor order, this order, has the placer order number OE1001^OrdEnt in the ORC segment.

The following sequence condition values have the following meanings:
 
ES + 10M  The finish time of OE1000&OrdEnt (predecessor) plus 10 minutes defines the start time of the successor, OE1001^OrdEnt (this order); i.e., start this order 10 minutes after the completion of its predecessor.
SS - 10M  The start time of the predecessor minus 10 minutes defines the start time of this order; i.e., start this order 10 minutes before its predecessor.

4.4.10.2 Cyclic placer order groups

For the special case where there is a cycle of orders that must be repeated, the first order to be executed will have a "sequence condition value" whose first character must be an asterisk (*). The last order to be executed may have a "sequence condition value" whose first character must be a pound sign (#).

Example:
 
*FS+10M  translates to: execute this order the first time without evaluating the condition specified in the 10th component; but repeat only its execution when the specified external order's start or finish date/time has met this condition. This specification generates a repetition of the order for each iteration of the cycle.

 
 
Note: This requires that the ordering application be able to specify the placer order number of the last order in the cycle in the first order's quantity/timing specification.

To implement a cyclic group of four IV orders, using the parent/child paradigm, the parent specifies a custom group of IVs, and the following occurs:

ORC-4-quantity/timing of the second child order specifies that it follows the first child order.

ORC-4-quantity/timing of the third child order specifies that it follows the second child order.

ORC-4-quantity/timing of the fourth child order specifies that it follows the third order.

To repeat the group of four child orders in a cyclic manner, the following occurs:

ORC-4-quantity/timing of the first child order specifies that it is to be executed once without any dependence on the completion of other orders.

Its second execution follows the completion of the fourth order. See example in Section 4.8.16.2, "Custom IV example."

This scheme allows the following to be tracked:

The status of the whole group of orders to be reported back at the level of the parent order.

The status for each individual IV order by following the status of the corresponding child order.

Separate Orders example:

The same group of orders can be sent as a group of four orders (without a common parent), linked only by the data in their quantity/timing fields. In this case, there is no convenient HL7 method of transmitting the order status of the group as a whole without transmitting the status of each of the four separate orders.

4.4.10.3 Inheritance of order status

Cancellation/discontinuation/hold order control events:

This logic implies the normal execution of the referenced predecessor order. Thus a cancel (or discontinuation or hold) of a predecessor order implies the cancellation (or discontinuation or hold) of all subsequent orders in the chain.

If the referenced order has been canceled (or discontinued or held), the current order inherits that same status.

In the case of hold, the removal of the hold of the predecessor implies a removal of the hold for the given order (which can then be executed according to the specification in the 10th component).

TOCIndexNext Page

4.4.11 Examples of quantity/timing usage

3^once
Perform the service at one point in time, e.g., order 3 units of blood to be given once.
1^QHS^X2
Perform the service twice at bedtime, e.g., give a unit of blood at bedtime on two sequential nights.
1^C^3D
Do a service continuously for 3 days.
1^Q1H^X4^^^^PVCs>10/min
Perform an EKG every hour up to a maximum of 4 EKGs, if patient is having more than 10 PVCs per minute.
1^Q2J^^1432
Perform a service every Tuesday at 2:32 p.m.
1^^^^198911210800
Perform a test before 11/21/89 0800, e.g., some preop laboratory tests.
1^Q3600S^X5^198911051030
Perform a service every hour for 5 hours starting at 10:30 a.m. 11/5/89, e.g., draw a blood glucose.
1^QAM^X3^^^^^S~1^QOD^4D^^^if K+>5.5.
Perform a service every morning for 3 days and then do it every other morning for 4 days (i.e., max twice) if the serum potassium is greater than 5.5.
^^^198812120800^^T^^Trough specimen for MIC^C~^^^^^R
Draw a blood specimen exactly at 8:00 a.m. on 12/12/1988 and report results routinely.
 
 

4.6.1 ODS - dietary orders, supplements, and preferences segment

The ORC sequence items of interest to ODS are ORC-1-order control,ORC-2-placer order number, ORC-3-filler order number, ORC-7-quantity/timing, ORC-9-date/time of transaction, ORC-10-entered by, and ORC-11-verified by. For ORC-1-order control, the values may be New (NW), Cancel (CA), Discontinue Order Request (DC), Change (XO), Hold Order Request (HD), and Release Previous Hold (RL). The HD and RL codes could stop service for a specified length of time. ORC-4-quantity/timing should be used to specify whether an order is continuous or for one service period only. It is also useful for supplements which are part of a diet but only delivered, say, every day at night. Example:
|1^QPM^^19910415|.
Figure 4-9. ODS attributes
SEQ
LEN
DT
OPT
RP/ #
TBL #
ITEM #
ELEMENT NAME
1 ID
R
  0159 00269 Type 
2
60 CE
O
Y/10   00270 Service Period
3
60 CE
R
Y/20   00271 Diet, Supplement, or Preference Code
4
80 ST
O
Y/2   00272 Text Instruction

4.6.1.0 ODS field definitions

4.6.1.1 Type (ID) 00269

Definition: This field specifies type of diet. Refer to HL7 table 0159 - Diet type for valid entries.

Table 0159 - Diet type
 
 
Value
Description
D
Diet
S
Supplement
P
Preference

4.6.1.2 Service period (CE) 00270

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

Definition: When blank, the modifier applies to all service periods. Diet orders, for example, typically apply to all service periods. This field usually specifies supplements. This field allows you to designate a modification for one or more of the service periods during a day by combining service specifications as needed. The service periods will be local CEs, normally numbers. Suggested are:
 
 
service 1  is  breakfast
service 2  is  mid-a.m. snack
service 3  is  lunch
service 4  is  mid-afternoon snack
service 5  is  dinner
service 6  is  bedtime snack

Ex: |1~5| means service 1 and service 5, whatever these are locally defined to be.

4.6.1.3 Diet, supplement, or preference code (CE) 00271

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

Definition: This field is the identifier of the ordered item for a patient; it is equivalent to OBR-4-universal service ID in function. Since ODS is a repeating segment, multiple entities get multiple segments. Example:

|^REG^L&FD7|, |023^^L&FD6|, |^NOLACT^L&FD5|, |^TUBEFD^L&FD4|, and |011^HIPRO100^L&FD1~123^LOFAT20^L&FD1|
In the case where this segment requests a diet supplement, i.e., ODS-1-type = S, this attribute specifies a particular item or class of items. If institutional codes for patient food preferences (P) have been codified, they are also expressed as coded segments; otherwise, the information is passed as a text string in the fourth component of the ODS segment, described below.

4.6.1.4 Text instruction (ST) 00272

Definition: This field defines the specific instructions for dietary. These instructions may address specific patient needs, such as isolation. This field provides the ordering provider’s dietary instructions as free text. It can represent the full dietary instruction or indicate supplemental information.

Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page
 

4.6.2 ODT - diet tray instructions segment

This segment addresses tray instructions. These are independent of diet codes, supplements, and preferences and therefore get separate order numbers.

Figure 4-10. ODT attributes
 
 
SEQ
LEN DT
OPT
RP/ # TBL # ITEM # ELEMENT NAME
60 CE
R
  0160 00273 Tray Type
2
60 CE
O
Y/10   00270 Service Period
3
80 ST
O
    00272 Text Instruction

4.6.2.0 ODT field definitions

4.6.2.1 Tray type (CE) 00273

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

Definition: This field defines the type of dietary tray. Refer to HL7table 0160 - Tray type for valid entries.

Table 0160 - Tray type
 
 
Value
Description
EARLY
Early tray
LATE
Late tray
GUEST
Guest tray
NO
No tray
MSG
Tray message only

Tray specifications are useful for early and late tray delivery in cases where a patient undergoes a procedure during normal feeding times. Tray specifications can also be used for guest trays, no trays, and messages. The value MSG means the ODT segment does not specify the type of tray but provides additional information about an existing tray. This information is found in ODT-3-text instructions.

4.6.2.2 Service period (CE) 00274

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

Definition: When blank, the modifier applies to all service periods. This field allows you to designate one or more of the feeding periods during a day by combining the codes as needed. It can also combine with quantity/timing to give such information as which service period the order belongs with. This field is identical in meaning with ODS-2-service period. See Section 4.6.1.2, "Service period (CE) 00270 for further details.

4.6.2.3 Text Instruction (ST) 00272

Definition: This field defines instructions associated with the tray. Example:
|PLASTIC SILVERWARE|.
Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page
 
 

4.5.1 OBR - observation request segment

General (taken from ASTM 1238-91)

The Observation Request (OBR) segment is used to transmit information specific to an order for a diagnostic study or observation, physical exam, or assessment.

The Observation Request segment defines the attributes of a particular request for diagnostic services (e.g., laboratory, EKG) or clinical observations, e.g., vital signs or physical exam. When a placer requests a given set of observations, always include an order segment. For lab tests, the information in the order segment usually applies to a single specimen. However, there is not a one-to-one relationship between specimen and tests ordered. Different test batteries will usually require their own order segments even when they can be performed on a single specimen. In this case, the specimen information must be duplicated in each of the order segments that employ that specimen. For other diagnostic studies, e.g., chest x-ray, a separate order segment will usually be generated for each diagnostic study.

Though multiple observation batteries can be ordered on a single order segment, the observation filler shall generate a separate order segment for each battery that it processes independently, e.g., electrolyte, CBC, vital signs. When reporting the observations, the filling service shall copy the appropriate order (specimen) information from the original order segment into each of the new order segments so that a separate "order" segment is returned to the placer as a "header" for each separate battery of observations.

In the event that an ordered battery of observations cannot be performed, e.g., because of hemolysis on a blood sample, an order segment will be returned to the placer with OBR-25-result status equal to X (to indicate that the study was not performed). In this case, no observation segments will be transmitted.

When observations are successfully completed, the message returned to the placer will include the order segment (OBR) followed by observation (OBX) segments for each distinct observation generated by the order (see Chapter 7). The number of such observation segments will depend upon the number of individual measurements performed in the process.

OBX segments can be sent by the placer along with an order to provide the filling service with clinical data needed to interpret the results. (See Chapter 7 for OBX details.)

Figure 4-8. OBR attributes

SEQ
LEN
DT
OPT
RP/#
TBL#
ITEM #
ELEMENT NAME
1 4 SI
C
    00237 Set ID - OBR
75 EI
C
    00216 Placer Order Number
3 75 EI
C
    00217 Filler Order Number +
4 200 CE
R
    00238 Universal Service ID
5 2 ID
B
    00239 Priority
6 26 TS
    00240 Requested Date/time
7 26 TS
C
    00241 Observation Date/Time #
8 26 TS
O
    00242 Observation End Date/Time #
9 20 CQ
O
    00243 Collection Volume *
10 60 XCN
O
Y   00244 Collector Identifier *
11 1 ID
O
  0065 00245 Specimen Action Code *
12 60 CE
O
    00246 Danger Code
13 300 ST
O
    00247 Relevant Clinical Info.
14 26 TS
C
    00248 Specimen Received Date/Time *
15 300 CM
O
  0070 00249 Specimen Source *
16 80 XCN
O
Y   00226 Ordering Provider
17 40 XTN
O
Y/2   00250 Order Callback Phone Number
18 60 ST
O
    00251 Placer field 1
19 60 ST
O
    00252 Placer field 2
20 60 ST
O
    00253 Filler Field 1 +
21 60 ST
O
    00254 Filler Field 2 +
22 26 TS
C
    00255 Results Rpt/Status Chng - Date/Time +
23 40 CM
O
    00256 Charge to Practice +
24 10 ID
O
  0074 00257 Diagnostic Serv Sect ID
25 1 ID
C
  0123 00258 Result Status +
26 400 CM
O
    00259 Parent Result +
27 200 TQ
O
Y   00221 Quantity/Timing
28 150 XCN
O
Y/5   00260 Result Copies To
29 150 CM
O
    00261 Parent 
30 20 ID
O
  0124 00262 Transportation Mode
31 300 CE
O
Y   00263 Reason for Study
32 200 CM
O
    00264 Principal Result Interpreter +
33 200 CM
O
Y   00265 Assistant Result Interpreter + 
34 200 CM
O
Y   00266 Technician +
35 200 CM
O
Y   00267 Transcriptionist +
36 26 TS
O
    00268 Scheduled Date/Time +
37 4 NM
O
    01028 Number of Sample Containers *
38 60 CE
O
Y   01029 Transport Logistics of Collected Sample *
39 200 CE
O
Y   01030 Collector's Comment *
40 60 CE
O
    01031 Transport Arrangement Responsibility
41 30 ID
O
  0224 01032 Transport Arranged
42 1 ID
O
  0225 01033 Escort Required
43 200 CE
O
Y   01034 Planned Patient Transport Comment

4.5.1.0 OBR field definitions

The daggered (+) items in this segment are known to the filler, not the placer. They are valued by the filler as needed when the OBR segment is returned as part of a report.

The starred (*) fields are only relevant when an observation is associated with a specimen. These are completed by the placer when the placer obtains the specimen. They are completed by the filler when the filler obtains the specimen.

OBR-7-observation date/time and OBR-8-observation end date/time (flagged with #) are the physiologically relevant times. In the case of an observation on a specimen, they represent the start and end of the specimen collector. In the case of an observation obtained directly from a subject (e.g., BP, Chest X-ray), they represent the start and end time of the observation.

4.5.1.1 Set ID - OBR (SI) 00237

Definition: For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.

4.5.1.2 Placer order number ( EI) 00216

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

Definition: This field is identical to ORC-2-placer order number.

The first component is a string of up to 15 characters that identifies an individual order segment (e.g., OBR). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The application ID is a string of up to six (6) characters that will be uniquely associated with an application. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs.

The second component contains the application ID of the placing application. The two components are separated by a component delimiter.

4.5.1.3 Filler order number ( EI) 00217

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

Definition: This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, Section 2.8.15, "EI - entity identifier").

The first component is a string that identifies an individual order segment (e.g., OBR). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory).

The second component is the filler application ID.

OBR-3-filler order number is identical to ORC-3-filler order number.

4.5.1.4 Universal service ID (CE) 00238

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

Definition: This field is the identifier code for the requested observation/test/battery. This can be based on local and/or "universal" codes. We recommend the "universal" procedure identifier. The structure of this CE data type is described in the control section.

4.5.1.5 Priority (ID) 00239

Definition: This field has been retained for backward compatibility only. It is not used. Previously priority (e.g., STAT, ASAP), but that information is carried as the sixth component of OBR-27-quantity/timing.

4.5.1.6 Requested date/time (TS) 00240

Definition: This field has been retained for backward compatibility only. This is not used. Previously requested date/time. That information is now carried in the fourth component of the OBR-27-quantity/timing.

4.5.1.7 Observation date/time (TS) 00241

Definition: This field is the clinically relevant date/time of the observation. In the case of observations taken directly from a subject, it is the actual date and time the observation was obtained. In the case of a specimen-associated study, this field shall represent the date and time the specimen was collected or obtained. (This is a results-only field except when the placer or a third-party has already drawn the specimen.) This field is conditionally required. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field must be filled in because this specimen time is the physiologically relevant date-time of the observation.

4.5.1.8 Observation end date/time (TS) 00242

Definition: This field is the end date and time of a study or timed specimen collection. If an observation takes place over a substantial period of time, it will indicate when the observation period ended. For observations made at a point in time, it will be null. This is a results field except when the placer or a party other than the filler has already drawn the specimen.

4.5.1.9 Collection volume (CQ) 00243

Components: <quantity (NM) ^ <units (CE)

Definition: For laboratory tests, the collection volume is the volume of a specimen. The default unit is ML. Specifically, units should be expressed in the ISO Standard unit abbreviations (ISO-2955,1977). This is a results-only field except when the placer or a party has already drawn the specimen. (See Chapter 7 for full details about units.)

4.5.1.10 Collector identifier (XCN) 00244

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID ) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present.

4.5.1.11 Specimen action code (ID) 00245

Definition: This field is the action to be taken with respect to the specimens that accompany or precede this order. The purpose of this field is to further qualify (when appropriate) the general action indicated by the order control code contained in the accompanying ORC segment. For example, when a new order (ORC - "NW") is sent to the lab, this field would be used to tell the lab whether or not to collect the specimen ("L" or "O"). Refer to HL7 table 0065 - Specimen action code for valid values.

Table 0065 - Specimen action code

Value
Description
A
Add ordered tests to the existing specimen
G
Generated order; reflex order
L
Lab to obtain specimen from patient
O
Specimen obtained by service other than Lab
P
Pending specimen; Order sent prior to delivery
R
Revised order
S
Schedule the tests specified below

4.5.1.12 Danger code (CE) 00535

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

Definition: This field is the code and/or text indicating any known or suspected patient or specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter.

4.5.1.13 Relevant clinical information (ST) 00247

Definition: This field is the additional clinical information about the patient or specimen will be provided here. This field is used to report the suspected diagnosis and clinical findings on requests for interpreted diagnostic studies. Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. For some orders this information may be sent on a more structured form as a series of OBX segments (see Chapter 7) that immediately follow the order segment.

4.5.1.14 Specimen received date/time (TS) 00248

Definition: For observations requiring a specimen, the specimen received date/time is the actual login time at the diagnostic service. This field must contain a value when the order is accompanied by a specimen, or when the observation required a specimen and the message is a report.

4.5.1.15 Specimen source (CM) 00249

Components: <specimen source name or code (CE) ^ <additives (TX) ^ <freetext (TX) ^ <body site (CE) ^ <site modifier (CE) ^ <collection method modifier code (CE)

Definition: This field is the site where the specimen should be obtained or where the service should be performed.

The first component contains the specimen source name or code (as a CE data type component). (Even in the case of observations whose name implies the source, a source may be required, e.g., blood culture-heart blood.) Refer to HL7 table 0070 - Source of specimen for valid entries.

The second component should include free text additives to the specimen such as Heparin, EDTA, or Oxlate, when applicable.

The third is a free text component describing the method of collection when that information is a part of the order. When the method of collection is logically an observation result, it should be included as a result segment.

The fourth component specifies the body site from which the specimen was obtained, and the fifth is the site modifier. For example, the site could be anticubital foss, and the site modifier "right." The components of the CE fields become subcomponents. Refer to HL7 table 0163 - Administrative site for valid entries.

Table 0163 - Administrative site
 
 
Value
Description
Value
Description
BE Bilateral Ears LVL Left Vastus Lateralis
OU Bilateral Eyes NB Nebulized
BN Bilateral Nares PA Perianal
BU Buttock PERIN Perineal
CT Chest Tube RA Right Arm
LA Left Arm RAC Right Anterior Chest
LAC Left Anterior Chest RACF Right Antecubital Fossa
LACF Left Antecubital Fossa RD Right Deltoid
LD Left Deltoid RE Right Ear
LE Left Ear REJ Right External Jugular
LEJ Left External Jugular  OD Right Eye
OS Left Eye RF Right Foot
LF Left Foot RG Right Gluteus Medius
LG Left Gluteus Medius RH Right Hand
LH Left Hand RIJ Right Internal Jugular
LIJ Left Internal Jugular RLAQ Rt Lower Abd Quadrant
LLAQ Left Lower Abd Quadrant RLFA Right Lower Forearm
LLFA Left Lower Forearm RMFA Right Mid Forearm
LMFA Left Mid Forearm RN Right Naris
LN Left Naris RPC Right Posterior Chest
LPC Left Posterior Chest RSC Right Subclavian
LSC  Left Subclavian RT Right Thigh
LT Left Thigh RUA Right Upper Arm
LUA Left Upper Arm RUAQ Right Upper Abd Quadrant
LUAQ Left Upper Abd Quadrant RUFA Right Upper Forearm
LUFA Left Upper Forearm RVL Right Vastus Lateralis
LVG  Left Ventragluteal RVG Right Ventragluteal

The fifth component indicates whether the specimen is frozen as part of the collection method. Suggested values are F (Frozen); R (Refrigerated). If the component is blank, the specimen is assumed to be at room temperature.

Table 0070 - Specimen source codes

Value Description Value Description Value  Description
ABS Abscess FLU Body fluid, unsp SER Serum
AMN Amniotic fluid GAS Gas SKN Skin
ASP Aspirate GAST Gastric fluid/contents SKM Skeletal muscle
BPH Basophils GEN Genital SPRM Spermatozoa
BIFL Bile fluid GENC Genital cervix SPT Sputum
BLDA Blood arterial GENL Genital lochia SPTC Sputum - coughed
BBL Blood bag GENV Genital vaginal SPTT Sputum - tracheal aspirate
BLDC Blood capillary HAR Hair STON Stone (use CALC)
BPU Blood product unit IHG Inhaled Gas STL Stool = Fecal
BLDV Blood venous IT Intubation tube SWT Sweat
BON Bone ISLT Isolate SNV Synovial fluid (Joint fluid)
BRTH Breath (use EXHLD) LAM Lamella TEAR Tears
BRO Bronchial WBC Leukocytes THRT Throat
BRN Burn LN Line THRB Thrombocyte (platelet)
CALC Calculus (=Stone) LNA Line arterial TISS Tissue
CDM Cardiac muscle LNV Line venous TISG Tissue gall bladder
CNL Cannula LIQ Liquid NOS TLGI Tissue large intestine
CTP Catheter tip LYM Lymphocytes TLNG Tissue lung
CSF Cerebral spinal fluid MAC Macrophages TISPL Tissue placenta
CVM Cervical mucus MAR Marrow TSMI Tissue small intestine
CVX Cervix MEC Meconium TISU Tissue ulcer
COL Colostrum MBLD Menstrual blood TUB Tube NOS
CBLD Cord blood MLK Milk ULC Ulcer
CNJT Conjunctiva MILK Breast milk UMB Umbilical blood
CUR Curettage NAIL Nail UMED Unknown medicine
CYST Cyst NOS Nose (nasal passage) URTH Urethra
DIAF Dialysis fluid ORH Other UR Urine
DOSE Dose med or substance  PAFL Pancreatic fluid URC Urine clean catch
DRN Drain PAT Patient URT Urine catheter
DUFL Duodenal fluid PRT Peritoneal fluid /ascites URNS Urine sediment
EAR Ear PLC Placenta USUB Unknown substance
EARW Ear wax (cerumen) PLAS Plasma VOM Vomitus
ELT Electrode PLB Plasma bag BLD Whole blood 
ENDC Endocardium PLR  Pleural fluid (thoracentesis fld) BDY Whole body
ENDM Endometrium PMN Polymorphonuclear neutrophils WAT Water
EOS Eosinophils PPP Patelet poor plasma WICK Wick
RBC Erythrocytes PRP Platelet rich plasma WND Wound
EYE Eye PUS Pus WNDA Wound abscess
EXHLD Exhaled gas (=breath) RT Route of medicine WNDE Wound exudate
FIB Fibroblasts SAL Saliva WNDD Wound drainage
FLT Filter SEM Seminal fluid XXX To be specified in another part of the message
FIST Fistula        

4.5.1.16 Ordering provider (XCN) 00226

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID ) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field identifies the provider who ordered the test. Either the ID code or the name, or both, may be present. This is the same as ORC-12-ordering provider.

4.5.1.17 Order callback phone number (XTN) 00250

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID) ^ <telecommunication equipment type (ID) ^ <email address (ST) ^ <country code (NM) ^ <area/city code (NM) ^ <phone number (NM) ^ <extension (NM) ^ <any text (ST)

Definition: This field is the telephone number for reporting a status or a result using the Standard format with extension and/or beeper number when applicable.

4.5.1.18 Placer field #1 (ST) 00251

Definition: This field is user field #1. Text sent by the placer will be returned with the results.

4.5.1.19 Placer field #2 (ST) 00252

Definition: This field is similar to placer field #1.

4.5.1.20 Filler field #1 (ST) 00253

Definition: This field is definable for any use by the filler (diagnostic service).

4.5.1.21 Filler field #2 (ST) 00254

Definition: This field is similar to filler field #1.

4.5.1.22 Results rpt/status chng - date/time (TS) 00255

Definition: This field specifies the date/time results reported or status changed. This field is used to indicate the date and time that the results are composed into a report and released, or that a status, as defined in Order Status, is entered or changed. (This is a results field only.) When other applications (such as office or clinical database applications) query the laboratory application for untransmitted results, the information in this field may be used to control processing on the communications link. Usually, the ordering service would want only those results for which the reporting date/time is greater than the date/time the inquiring application last received results.

4.5.1.23 Charge to practice (CM) 00256

Components: <dollar amount (MO) ^ <charge code (CE)

Definition: This field is the charge to the ordering entity for the studies performed when applicable. The first component is a dollar amount when known by the Filler. The second is a charge code when known by the filler (results only).

4.5.1.24 Diagnostic serv sect ID (ID) 00257

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7table 0074 - Diagnostic service section ID for valid entries.

Table 0074 - Diagnostic service section ID

Value 
Description
Value
Description
AU
Audiology
OUS
OB Ultrasound
BG
Blood gases
OT
Occupational Therapy
BLB
Blood bank
OTH
Other
CUS
Cardiac Ultrasound
OSL
Outside Lab
CTH
Cardiac catheterization
PHR
Pharmacy
CT
CAT scan
PT
Physical Therapy
CH
Chemistry
PHY
Physician (Hx. Dx, admission note, etc.l)
CP
Cytopathology
PF
Pulmonary function
EC
Electrocardiac (e.g., EKG, EEC, Holter)
RAD
Radiology
EN
Electroneuro (EEG, EMG,EP,PSG)
RX
Radiograph
HM
Hematology
RUS
Radiology ultrasound
ICU
Bedside ICU Monitoring
RC
Respiratory Care (therapy)
IMM
Immunology
RT
Radiation therapy
LAB
Laboratory
SR
Serology
MB
Microbiology
SP
Surgidal Pathology
MCB
Mycobacteriology
TX
Toxicology
MYC
Mycology
VUS
Vascular Ultrasound
NMS
Nuclear medicine scan
VR
Virology
NMR
Nuclear magnetic resonance
XRC
Cineradiograph
NRS
Nursing service measures
 
 

4.5.1.25 Result status (ID) 00258

Definition: This field is the status of results for this order. This conditional field is required whenever the OBR is contained in a report message. It is not required as part of an initial order.

There are two methods of sending status information. If the status is that of the entire order, use ORC-15-order effective date/time and ORC-5-order status. If the status pertains to the order detail segment, use OBR-25-result status and OBR-22-results report/status change - date/time. If both are present, the OBR values override the ORC values.

This field would typically be used in a response to an order status query where the level of detail requested does not include the OBX segments. When the individual status of each result is necessary, OBX-11-observ result status may be used. Refer to HL7 table 0123 - Result status for valid entries.

Table 0123 - Result status

Value
Description
Value 
Description
O
Order received; specimen not yet received
R
Results stored; not yet verified
I
No results available; specimen received, procedure incomplete
F
Final results; results stored and verified. Can only be changed with a corrected result.
S
No results available; procedure scheduled, but not done
X
No results available; Order canceled.
A
Some, but not all, results available
Y
No order on record for this test. (Used only on queries)
P
Preliminary: A verified early result is available, final results not yet obtained
Z
No record of this patient. (Used only on queries)
C
Correction to results
 
 

4.5.1.26 Parent result (CM) 00259

Components: <OBX-3-observation identifier of parent result (CE) ^ <OBX-4-sub-ID of parent result (ST) ^ <part of OBX-5 observation result from parent (TX) see discussion

Definition: This field is defined to make it available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29-parent number, uniquely identifies the parent result’s OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports. E.g., if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result which identifies the organism on which the susceptibility were run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization.

The third component may be used to record the name of the microorganism identified by the parent result directly. The organism in this case should be identified exactly as it is in the parent culture.

We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems which could not generate unambiguous Observation Ids and sub-Ids.

This field is present only when the parent result is identified by OBR-29-parent number and the parent spawns child orders for each of many results. (See Chapter 7 for more details about this linkage.)

A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-subID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism.

4.5.1.27 Quantity/timing (TQ) 00221

Components: <quantity (CQ) ^ <interval (CM) ^ <duration ^ <start date/time (TS) ^ <end date/time (TS) ^ <priority (ID) ^ <condition (ST) ^ <text (TX) ^ <conjunction (ID) ^ <order sequencing

Definition: This field contains information about how many services to perform at one service time and how often the service times are repeated, and to fix duration of the request. See Section 4.4, "QUANTITY/TIMING (TQ) DEFINITION."

4.5.1.28 Result copies to (XCN) 00260

Components: <ID number (ST) ^ <family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^ <assigning authority (HD) ^ <name type code(ID) ^ <identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID ) ^ <identifier type code (IS) ^ <assigning facility (HD)

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

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

Definition: This field is the people who are to receive copies of the results. By local convention, either the ID number or the name may be absent.

4.5.1.29 Parent (CM) 00261

Components: <parent's placer order number (EI) ^ <parent's filler order number (EI)

Subomponents of parent’s placer order number: <entity identifier (ST) & <namespace ID (IS) & <universal ID (ST) & <universal ID type (IS)

Subomponents of parent’s filler order number: <entity identifier (ST) & <namespace ID (IS) & <universal ID (ST) & <universal ID type (IS)

Definition: This field is identical to ORC-8-parent. This field relates a child to its parent when a parent-child relationship exists. For example, observations that are spawned by previous observations, e.g., antimicrobial susceptibilities spawned by blood cultures, need to record the parent (blood culture) filler order number here. The parent-child mechanism is described under the order control field notes (see Section 4.3.1.1.1, "Table notes for order control codes of ORC"). It is required when the order is a child.

Parent is a two-component field. The first component contains the parent’s placer order number. The second component is optional and contains the parent’s filler order number. The components of the placer order number and the filler order number are transmitted in subcomponents of the two components of this field.

4.5.1.30 Transportation mode (ID) 00262

Definition: This field identifies how (or whether) to transport a patient, when applicable. Refer to HL7 table 0124 - Transportation mode for valid codes.

Table 0124 - Transportation mode

Value
Description
CART
Cart - patient travels on cart or gurney
PORT
The examining device goes to patient's location
WALK
Patient walks to diagnostic service
WHLC
Wheelchair

4.5.1.31 Reason for study (CE) 00263

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

Definition: This field is the code or text using the conventions for coded fields given in the Control/Query Chapter (Chapter 2). This is required for some studies to obtain proper reimbursement.

4.5.1.32 Principal result interpreter ( CM) 00264

Components: <name (CN) ^ <start date/time (TS) ^ <end date/time (TS) ^ <point of care (IS) ^ <room (IS) ^ <bed (IS) ^ <facility (HD) ^ <location status (IS) ^ <patient location type (IS) ^ <building (IS) ^ <floor (IS)

Definition: This field identifies the physician or other clinician who interpreted the observation and is responsible for the report content.

4.5.1.33 Assistant result interpreter ( CM) 00265

Components: <name (CN) ^ <start date/time (TS) ^ <end date/time (TS) ^ <point of care (IS) ^ <room (IS) ^ <bed (IS) ^ <facility (HD) ^ <location status (IS) ^ <patient location type (IS) ^ <building (IS) ^ <floor (IS)

Definition: This field identifies the clinical observer who assisted with the interpretation of this study.

4.5.1.34 Technician ( CM) 00266

Components: <name (CN) ^ <start date/time (TS) ^ <end date/time (TS) ^ <point of care (IS) ^ <room (IS) ^ <bed (IS) ^ <facility (HD) ^ <location status (IS) ^ <patient location type (IS) ^ <building (IS) ^ <floor (IS)

Definition: This field identifies the performing technician.

4.5.1.35 Transcriptionist ( CM) 00267

Components: <name (CN) ^ <start date/time (TS) ^ <end date/time (TS) ^ <point of care (IS) ^ <room (IS) ^ <bed (IS) ^ <facility (HD) ^ <location status (IS) ^ <patient location type (IS) ^ <building (IS) ^ <floor (IS)

Definition: This field identifies the report transcriber.

4.5.1.36 Scheduled - date/time (TS) 00268

Definition: This field is the date/time the filler scheduled an observation, when applicable (e.g., action code in OBR-11-specimen action code = "S"). This is a result of a request to schedule a particular test and provides a way to inform the Placer of the date/time a study is scheduled (result only).

4.5.1.37 Number of sample containers (NM) 01028

Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples which accompany the order.

4.5.1.38 Transport logistics of collected sample (CE) 01029

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

Definition: This field is the means by which a sample reaches the diagnostic service provider. This information is to aid the lab in scheduling or interpretation of results. Possible answers: routine transport van, public postal service, etc. If coded, requires a user-defined table.

4.5.1.39 Collector's comment (CE) 01030

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

Definition: This field is for reporting additional comments related to the sample. If coded, requires a user-defined table. If only free text is reported, it is placed in the second component with a null in the first component, e.g., ^difficult clotting after venepuncture and echymosis..

4.5.1.40 Transport arrangement responsibility (CE) 01031

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

Definition: This field is an indicator of who is responsible for arranging transport to the planned diagnostic service. Examples: Requester, Provider, Patient. If coded, requires a user defined table.

4.5.1.41 Transport arranged (ID) 01032

Definition: This field is an indicator of whether transport arrangements are known to have been made. Refer to HL7 table 0224 - Transport arranged for valid codes.

Table 0224 - Transport arranged

Value
Description
A
Arranged
N
Not Arranged
U
Unknown

4.5.1.42 Escort required (ID) 01033

Definition: This field is an indicator that the patient needs to be escorted to the diagnostic service department. Note: The nature of the escort requirements should be stated in the "Planned Patient Transport Comment" field (OBR-43). See HL7 table 0225 - Escort required for valid values.

Table 0225 - Escort required

Value
Description
R
Required
N
Not Required
U
Unknown

4.5.1.43 Planned patient transport comment (CE) 01034

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

Definition: This field is the code or free text comments on special requirements for the transport of the patient to the diagnostic service department. If coded, requires a user-defined table.

Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page
 
 

7.2.1 ORU/ACK - unsolicited transmission of an observation message (event R01)

With the type (OBX) defined in this chapter, and the OBR defined in Chapter 4, one can construct almost any clinical report as a three-level hierarchy, with the PID segment defined in Chapter 3 at the upper level, an order record (OBR) at the next level and one or more observation records (OBX) at the bottom.

One result segment (OBX) is transmitted for each component of a diagnostic report, such as an EKG or obstetrical ultrasound or electrolyte battery.

ORU     Observational Results (Unsolicited)  Chapter



MSH     Message Header        2



{  



   



   [



    PID    Patient Identification      3



   [PD1]   Additional Patient Identification    3



      [{NTE}]  Notes and Comments       2



    [PV1    Patient Visit        3



      [PV2]]   Additional Patient Visit      3



   ]



    {



     [ORC]   Order common         4



      OBR   Observations Report ID      7



      {[NTE]}  Notes and comments       2



        {



         [OBX]  Observation/Result       7



          {[NTE]}  Notes and comments       2



        }   



 {[CTI]}   Clinical Trial Identifier      7



     }   



}   



[DSC]    Continuation Pointer        2



ACK     Acknowledgement       Chapter



MSH     Message header        2



MSA     Message acknowledgement      2
Note: The ORC is permitted but not required in this message. Any information that could be included in either the ORC or the OBR must be included in the OBR on reporting. Notice also that the ORU (and the QRY) messages accommodate reports about many patients. 

Many report headers (OBR) may be sent beneath each patient segment, with many separate observation segments (OBX) beneath each OBR. Note segments (NTE) may be inserted after any of the above segments. The note segment applies to the entity that immediately precedes it, i.e., the patient if it follows the PID segment, the observation if it follows the OBR segment, and the individual result if it follows the OBX segment.

Previous PageTOCIndexNext Page

Previous PageTOCIndexNext Page
 

7.3.2 OBX - observation/result segment

The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report. Its structure is summarized in Figure 7-5.

Its principal mission is to carry information about observations in report messages. But the OBX can also be part of an observation order (see Section 4.2, "Order Message Definitions"). In this case, the OBX carries clinical information needed by the filler to interpret the observation the filler makes. For example, an OBX is needed to report the inspired oxygen on an order for a blood oxygen to a blood gas lab, or to report the menstrual phase information which should be included on an order for a pap smear to a cytology lab. Appendix 7A includes codes for identifying many of pieces of information needed by observation producing services to properly interpret a test result. OBX is also found in other HL7 messages that need to include patient clinical information.

Figure 7-5. OBX attributes

SEQ
LEN
DT
OPT
RP/#
TBL#
ITEM#
ELEMENT NAME
10 SI
O
    00569 Set ID - OBX
2 ID
C
  0125 00570 Value Type
3 590 CE
R
    00571 Observation Identifier
4 20 ST
C
    00572 Observation Sub-ID
5 65536 [ The length of the observation value field is variable, depending upon value type. See OBX-2-value type . *
C
Y [ May repeat for multipart, single answer results with appropriate data types, e.g., CE, TX, and FT data types.   00573 Observation Value
6 60 CE
O
    00574 Units
7 10 ST
O
    00575 References Range
8 5 ID
O
Y/5 0078 00576 Abnormal Flags
9 5 NM
O
    00577 Probability
10 2 ID
O
Y 0080 00578 Nature of Abnormal Test
11 1 ID
R
  0085 00579 Observ Result Status
12 26 TS
O
    00580 Date Last Obs Normal Values
13 20 ST
O
    00581 User Defined Access Checks
14 26 TS
O
    00582 Date/Time of the Observation
15 60 CE
O
    00583 Producer's ID
16 80 XCN
O
    00584 Responsible Observer
17 60 CE
O
Y   00936 Observation Method

7.3.2.0 OBX field definitions

7.3.2.1 Set ID - observation simple (SI) 00569

Definition: This field contains the sequence number. For compatibility with ASTM.

7.3.2.2 Value type (ID) 00570

Definition: This field contains the format of the observation value in OBX. It must be valued if OBX-11-Observation result status is not valued with an ‘X". If the value is CE then the result must be a coded entry. When the value type is TX or FT then the results are bulk text. The valid values for the value type of an observation are listed in HL7 table 0125 - Value type.

The observation value must be represented according to the format for the data type defined in Chapter 2, Section 2.8, "Data Types." For example, a PN consists of 6 components, separated by component delimiters.

Although NM is a valid type, observations which are usually reported as numbers will sometimes have the string (ST) data type because non-numeric characters are often reported as part of the result, e.g., 300 to indicate the result was off-scale for the instrument. In the example, "300", "" is a symbol and the digits are considered a numeric value. However, this usage of the ST type should be discouraged since the SN (structured numeric) data type now accommodates such reporting and, in addition, permits the receiving system to interpret the magnitude.

All HL7 data types are valid, and are included in Table 0125 except CM, CQ, SI, and ID. For a CM definition to have meaning, the specifics about the CM must be included in the field definition. OBX-5-observation value is a general field definition that is influenced by the data type OBX-3, so CMs are undefined in this context. CQ is invalid because units for OBX-5-observation value are always specified explicitly in an OBX segment with OBX-6 units. SI is invalid because it only applied to HL7 message segments, and ID because it requires a constant field definition.

The RP value (reference pointer) must be used if the actual observation value is not sent in OBX but exists somewhere else. For example, if the observation consists of an image (document or medical), the image itself cannot be sent in OBX. The sending system may in that case opt to send a reference pointer. The receiving system can use this reference pointer whenever it needs access to the actual image through other interface standards, e.g., DICOM, or through appropriate data base servers.

Table 0125 - Value type

Value
Description
AD
Address
CE
Coded Entry
CF
Coded Element With Formatted Values
CK
Composite ID With Check Digit
CN
Composite ID And Name
CP
Composite Price
CX
Extended Composite ID With Check Digit
DT
Date
ED
Encapsulated Data
FT
Formatted Text (Display)
MO
Money
NM
Numeric
PN
Person Name
RP
Reference Pointer
SN
Structured Numeric
ST
String Data.
TM
Time
TN
Telephone Number
TS
Time Stamp (Date & Time)
TX
Text Data (Display)
XAD
Extended Address
XCN
Extended Composite Name And Number For Persons
XON
Extended Composite Name And Number For Organizations
XPN
Extended Person Number
XTN
Extended Telecommunications Number

The full definition of these data types is given in Chapter 2, Section 2.8, "Data Types." The structured numeric (SN) data type, new to version 2.3, provides for reporting ranges (e.g., 3-5 or 10-20), titres (e.g., 1:10), and out-of-range indicators (e.g., 50) in a structured and computer interpretable way.

We allow the FT data type in the OBX segment but its use is discouraged. Formatted text usually implies a meaningful structure e.g., a list of three independent diagnoses reported on different lines. But ideally, the structure in three independent diagnostic statements would be reported as three separate OBX segments.

TX should not be used except to send large amounts of text. In the TX data type, the repeat delimiter can only be used to identify paragraph breaks. Use ST to send short, and possibly encodable, text strings.

7.3.2.3 Observation identifier (CE) 00571

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

Definition: This field contains a unique identifier for the observation. The format is that of the Coded Element (CE). Example: 93000.3^P-R interval^A34.

In most systems the identifier will point to a master observation table that will provide other attributes of the observation that may be used by the receiving system to process the observations it receives. A set of message segments for transmitting such master observation tables is described in Chapter 8. The relation of an observation ID to a master observation table is analogous to the relationship between a charge code (in a billing record) and the charge master.

When local codes are used as the first identifier in this field we strongly encourage sending a universal identifier as well to permit receivers to equivalence results from different providers of the same service (e.g., a hospital lab and commercial lab that provides serum potassium to a nursing home). One possible universal identifier is LOINC codes for laboratory and clinical measurements (see Figure 7-3 and the HL7 www listserver); see Section 7.15, "WAVEFORM RESULT DATA TYPES," and Appendix X2 of ASTM E1467 for neurophysiology tests.

7.3.2.4 Observation sub-ID (ST) 00572

Definition: This field is used to distinguish between multiple OBX segments with the same observation ID organized under one OBR. For example, a chest xray report might include three separate diagnostic impressions. The standard requires three OBX segments, one for each impression. By putting a 1 in the Sub-ID of the first of these OBX segments, 2 in the second, and 3 in the third, we can uniquely identify each OBX segment for editing or replacement.

The sub-identifier is also used to group related components in reports such as surgical pathology. It is traditional for surgical pathology reports to include all the tissues taken from one surgical procedure in one report. Consider, for example, a single surgical pathology report that describes the examination of gallbladder and appendix tissue. This report would be transmitted roughly as shown in Figure 7-6.

Figure 7-6. Example of sub-identifier usage

OBR|1|||88304&SURG PATH REPORT...



OBX|1|CE|88304&ANT|1|T57000^GALLBLADDER^SNM...



OBX|2|TX|88304&GDT|1|THIS IS A NORMAL GALLBLADDER...



OBX|3|TX|88304&MDT|1|MICROSCOPIC EXAM SHOWS HISTOLOGICALLY 



 NORMAL GALLBLADDER TISSUE...



OBX|4|CE|88304&IMP|1|M-00100^NML^SNM...



OBX|5|CE|88304&ANT|2|T66000^APPENDIX^SNM...



OBX|6|TX|88304&GDT|2|THIS IS A RED, INFLAMED, SWOLLEN, BOGGY APPENDIX...



OBX|7|TX|88304&MDT|2|INFILTRATION WITH MANY PMN's - INDICATING INFLAMATORY CHANGE...



OBX|8|CE|88304&IMP|2|M-40000^INFLAMMATION NOS^SNM...
The example in Figure 7-6 has two segments for each component of the report, one for each of the two tissues. Thus, there are two 88304&ANT segments; there are two 88304&GDT segments, and there are two 88304&MDT segments. Segments that apply to the gallbladder all have the sub-identifier 1. Segments that apply to the appendix all have sub-identifier 2.

The observation sub ID has other grouping uses. It can be used to organize the reporting of some kinds of fluid intakes and outputs. For example, when intake occurs through multiple intravenous lines; a number of separate observations (OBX segments), the intake volume, the type of intake (Blood, D5W, Plasma, etc.), the site of the IV line, etc. may be needed for each intravenous line, each requiring a separate OBX segment. If more than one IV line is running, we can logically link all of the OBX segments that pertain to the first IV line by assigning them an observation sub ID of 1. We can do the same with the second IV line by assigning them a sub ID 2 and so on. The same would apply to the outputs of surgical drains when there are multiple such drains.

The use of the sub ID to distinguish repeating OBXs for the same observation ID is really a special case of using the sub ID to group, as can be seen if we picture the OBX segments in Figure 7-6 as part of a table where the rows correspond to a particular species of observation and the cells correspond to the sub ID numbers that would be associated with each corresponding OBX.
 
 
Distinct Observations
88304&ANT
88304&GDT
80304&MDT
80304&IMP
Sub ID 1st Group
1
1
1
1
Sub ID 2nd Group
2
2
2
2

The use of Sub IDs to group results is equivalent to defining a table, and the use of sub IDs to distinguish repeats is just a special case, represented by one column in this table.

However, this approach introduces ambiguities if we have a set of repeating observations within a group, e.g., if the appendix observations include two impressions as in the 8th and 9th OBXs shown in Figure 7-7. This really represents the existence of a row nested within a single cell of the table given above.

Figure 7-7. Example of sub-identifier usage

OBX|1|CE|880304&ANT|1|T57000^GALLBLADDER^SNM...



OBX|2|TX|880304&GDT|1|THIS IS A NORMAL GALL BLADDER...



OBX|3|TX|880304&MDT|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY 



 NORMAL GALLBLADDER TISSUE...



OBX|4|CE|880304&IMP|1|M-00100^NML^SNM...



OBX|5|CE|880304&ANT|2|T57000^APPENDIX^SNM...



OBX|6|TX|880304&GDT|2|THIS IS A RED, INFLAMED APPENDIX...



OBX|7|TX|880304&MDT|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION...



OBX|8|CE|880304&IMP|2|M-40000^INFLAMMATION NOS^SNM...



OBX|9|CE|880304&IMP|2|M-30280^FECALITH^SNM...
The text under OBX-5 provides guidance about dealing with two OBXs with the same observation ID and observation sub IDs. They are sent and replaced as a unit. However, some systems will take this to mean that the set of OBXs are to be combined into one composite observation in the receiving system. We suggest the use of a dot and a string (similar to the Dewey Decimal system) when users wish to distinguish each of the repeats within one type, or results within a cell for editing and correction purposes. Using this system, Figure 7-7 would become 7-8. If there are cases where such nesting occurs at even deeper levels, this approach could be extended.

Figure 7-8. Example of sub-identifier usage

OBX|1|CE|880304&ANT|1|T57000^GALLBLADDER^SNM...



OBX|2|TX|880304&GDT|1|THIS IS A NORMAL GALL BLADDER...



OBX|3|TX|880304&MDT|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY 



 NORMAL GALLBLADDER TISSUE...



OBX|4|CE|880304&IMP|1|M-00100^NML^SNM...



OBX|5|CE|880304&ANT|2|T57000^APPENDIX^SNM...



OBX|6|TX|880304&GDT|2|THIS IS A RED, INFLAMED APPENDIX...



OBX|7|TX|880304&MDT|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION...



OBX|8|CE|880304&IMP|2.1|M-40000^INFLAMMATION NOS^SNM...



OBX|9|CE|880304&IMP|2.2|M-30280^FECALITH^SNM...
Use a null or 1 when there is no need for multiples.

If the observation includes a number of OBXs with the same value for the observation ID OBX-3, then one must use different values for the sub-ID. This is in fact the case of the repeats depicted in Figure 7-8, but without any need to group sets of OBXs. Three such OBXs could be distinguished by using sub-Ids 1,2,e; alternatively, sub-Ids 1.1, 1.2, 1.3 could be used, as shown in Figure 7-8. Figure 7-9 shows and example of an electrocardiograph chest radiograph report with three diagnostic impressions, using 1,2,3 in the sub-ID field to distinguish the three separate results.

Figure 7-9 Example of Sub-ID used to distinguish three independent results with the same observation ID

OBX|1|CE|8601-7^EKG IMPRESSION ^LN|1|^atrial fibrillation|. . .



OBX|2|CE|8601-7^EKG IMPRESSION ^LN|2|^OLD SEPTAL MYOCARDIAL INFARCT| . . .



OBX|3|CE|8601-7^EKG IMPRESSION ^LN|3|^poor R wave progression|. . .

7.3.2.5 Observation value (*) 00573

Definition: This field contains the value observed by the observation producer. OBX-2-value type contains the data type for this field according to which observation value is formatted. It is not a required field because some systems will report only the normalcy/abnormalcy (OBX-8), especially in product experience reporting.

Representation

This field contains the value of OBX-3-observation identifier of the same segment. Depending upon the observation, the data type may be a number (e.g., a respiratory rate), a coded answer (e.g., a pathology impression recorded as SNOMED), or a date-time (the date-time that a unit of blood is sent to the ward). An observation value is always represented as the data type specified in OBX-2-value type of the same segment. Whether numeric or short text, the answer shall be recorded in ASCII text.

Reporting logically independent observations

The main sections of dictated reports, such as radiologic studies or history and physicals, are reported as separate OBX segments. In addition, each logically independent observation should be reported in a separate OBX segment, i.e. one OBX segment should not contain the result of more than one logically independent observation. This requirement is included to assure that the contents of OBX-6-units, OBX-8-abnormal flags, and OBX-9-probability can be interpreted unambiguously. The electrolytes and vital signs batteries, for example, would each be reported as four separate OBX segments. Two diagnostic impressions, e.g., congestive heart failure and pneumonia, would also be reported as two separate OBX segments whether reported as part of a discharge summary or chest xray report. Similarly, two bacterial organisms isolated in a single bacterial culture would be reported as two separate OBX segments.

Though two independent diagnostic statements cannot be reported in one OBX segment, multiple categorical responses are allowed (usually as CE data types separated by repeat delimiters), so long as they are fragments (modifiers) that together construct one diagnostic statement. Right upper lobe (recorded as one code) and pneumonia (recorded as another code), for example, could be both reported in one OBX segment. Such multiple "values" would be separated by repeat delimiters.

Multiple OBX segments with the same observation ID and Sub ID

In some systems, a single observation may include fragments of more than one data type. The most common example is a numeric result followed by coded comments (CE). In this case, the logical observation can be sent in more than one OBX segment. For example, one segment of numeric or string data type for the numeric result and another segment of CE data type for coded comments. If the producer was reporting multiple coded comments they would all be sent in one OBX segment separated by repeat delimiters because they all modified a single logical observation. Multiple OBX segments with the same observation ID and sub ID should always be sent in sequence with the most significant OBX segment (the one that has the normal flag/units and or reference range and status flag) first. The value of OBX-6 through 12 should be null in any following OBX segments with the same OBX-3-observation identifier and OBX-4-observation sub-ID. For the purpose of replacement or deletion, multiple OBX segments with the same observation ID and sub ID are treated as a unit. If any are replaced or deleted, they all are replaced.

Coded values

When an OBX segment contains values of CE data types, the observations are stored as a combination of codes and/or text. In Section 7.4.4, "Example of narrative report messages," examples of results that are represented as CE data types are shown in the first and second OBX segments of OBR 1 and the first and second OBX segments of OBR 2. The observation may be an observation battery ID (for recommended studies), a diagnostic code or finding (for a diagnostic impression), or an anatomic site for a pathology report, or any of the other kinds of coded results.

It is not necessary to always encode the information stored within a coded observation. For example, a chest xray impression could be transmitted as pure text even though it has a CE data type. In this case, the test must be recorded as the second component of the result code, e.g.,

OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE.
However, separate impressions, recommendations, etc., even if recorded as pure text, should be recorded in separate result segments. That is, congestive heart failure and pneumonia should not be sent as:
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE AND PNEUMONIA|
but as:
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE| 



OBX|2|CE|71020&IMP|2|^PNEUMONIA|.
Even better would be fully-coded results that include computer understandable codes (component 1) instead of, or in addition to, the text description (component 2). One may include multiple values in a CE value and these can be mixtures of code and text, but only when they are needed to construct one diagnosis, impression, or concept. When text follows codes as an independent value it would be taken as a modifier or addenda to the codes. E.g.,
OBX|1|CE|710120&IMP^CXR|1|428.0^CONGESTIVE HEART FAILURE^I9C~^MASSIVE HEART
The text in component 2 should be an accurate description of the code in component 1. Likewise, if used, the text in component 5 should be an accurate description of the code in component 4.

7.3.2.6 Units (CE) 00574

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

Definition: This field contains the units have a data type of CE. The default coding system for the units codes consists of the ISO+ abbreviation for a single case unit (ISO 2955-83) plus extensions, that do not collide with ISO abbreviations (see introductory section to this chapter). We designate this coding system as ISO+. Both the ISO unit’s abbreviations and the extensions are defined in Section 7.3.2.6.1.2, "ISO and ANSI customary units abbreviations,"and listed in Figure 7-13. The ISO+ abbreviations are the codes for the default coding system. Consequently, when ISO+ units are being used, only ISO+ abbreviations need be sent, and the contents of the units field will be backward compatible to HL7 Version. 2.1.

7.3.2.6.1 Identifying reporting units
7.3.2.6.1.1 Background
When an observation’s value is measured on a continuous scale, one must report the measurement units within the units field of the OBX segment. Since in HL7 version 2.2 of the specification, all fields that report units are of data type CE. The default coding system for the units codes consists of the ISO abbreviation for a single case unit (ISO 2955-83) plus extensions that do not collide with ISO abbreviations. We designate this coding system as ISO+ (see Figure 7-13). Both the ISO unit’s abbreviations and the extensions are defined in Section 7.3.2.6.1.2, "ISO and ANSI customary units abbreviations." The ISO+ abbreviations are the codes for the default coding system. Consequently, when ISO+ units are being used, only ISO+ abbreviations need be sent, and the contents of the units field will be backward compatible to HL7 version 2.1 and ASTM 1238-88.

We strongly encourage observation producers to use ISO+ abbreviated units exclusively, but permit the use of other code systems, including US customary units (ANSI X3.50) and locally defined codes where necessary. Local units are designated L or 99zzz where z is an alpha numeric character (see figures 7-2 and 73). ANSI X3.50 -1986 provides an excellent description of these standards, as well as a table of single case abbreviations for US customary units such as foot or gallon.

We had originally intended to include the ANSI X3.50 - 1986 US customary units in the default ISO+ coding system. However, there are overlaps between ISO’s abbreviations and the abbreviations for US customary units. For example, ft is the abbreviation for foot in US customary units and for femtotesla in ISO; pt is the abbreviation for pint in US customary and for picotesla in ISO. (Be aware that the ANSI document also differs from the ISO document regarding the abbreviation of a few ISO units, as well.) In order to avoid potential ambiguity, we have defined another coding system, designated ANS+. It includes the US customary units (e.g., feet, pounds) and ISO abbreviations defined in ANSI X3.50-1986, as well as other non-metric units listed in Figure 7-13 and the ISO combinations of these units. Be aware that a few of the ANSI ISO unit abbreviations differ from their abbreviations in ISO (see note at bottom of Figure 7-13).

Because the ANS+ specification includes both ISO and US customary units, as well as miscellaneous non-metric units, some of the abbreviations are ambiguous. Although there should be little confusion, in the context of a particular observation, this ambiguity is a good reason for avoiding ANS+ unit codes when possible.

When ANS+ units codes (abbreviations) are being transmitted, ANS+ must be included in the 3rd (6th) component of the field. If the units of distance were transmitted as meters (ISO+) it would be transmitted as m because ISO+ is the default coding system for units. However, if transmitted in the US customary units of feet, the units would be transmitted as ft^^ANS+. When required, the full text of the units can be sent as the second component in keeping with the CE data type conventions.

Both ISO and ANSI also provide a set of mixed case abbreviations, but these abbreviations cannot be translated to single case without loss of meaning, and should not be used in this specification whose content is required to be case insensitive.

7.3.2.6.1.2 ISO and ANSI customary units abbreviations
ISO builds its units from seven base dimensions measured as meters, kilograms, seconds, amperes, kelvins, moles and candelas (see Figure 7-10). Other units can be derived from these by adding a prefix to change the scale and/or by creating an algebraic combination of two or more base or derived units. However, some derived units have acquired their own abbreviations (see Figure 7-10). Abbreviations for U.S. customary units are given in Figure 7-11.

The ISO rules, well explained in ANSI X3.50, provide a way to create units of different scales by adding multiplier prefixes. These prefixes can be expressed as words or abbreviations. In this standard we are only concerned with the abbreviations.

Figure 7-10. ISO single case units abbreviations

Units
Abbreviation
Units
Abbreviation
Units
Abbreviation
Base units code/abbreviations
ampere a kelvin k meter m
candela cd kilogram kg mole mol
        second s
Derived units with specified name and abbreviation
coulomb c hour hr pascal pal
day d joule j volt v
degree Celsius cel minute (ti) min watt w
farad f newton n weber wb
hertz hz ohm ohm year ann
Other units
atomic mass unit u grey gy minute of arc mnt
bel b henry h radian rad
decibel db liter l siemens sie
degree deg lumen lm steradian sr
gram g lux lx tesla t
See ISA 2955-1983 for full set

The ISO abbreviations for multiplier prefixes are given in Figure 7-12. Prefixes ranging from 10-24 (1/billion billionth) to 1024 (a billion billion) are available. The single case abbreviation for kilo (x1000) is k. A unit consisting of 1000 seconds would be abbreviated as ks, 1000 grams as kg, 1000 meters as km, and so on. Some prefixes share the abbreviation of a base unit. Farad and femto, for example, (10-18) both have the abbreviation of f. To avoid confusion, ISO forbids the use of solitary prefixes. It also deprecates the use of two prefixes in one complex unit. Thus, f always means farad, ff would mean 1 million billionth of a farad. Compound prefixes are not allowed.

A unit can be raised to an exponential power. Positive exponents are represented by a number immediately following a unit’s abbreviation, i.e., a square meter would be denoted by m2. Negative exponents are signified by a negative number following the base unit, e.g., 1/m2 would be represented as m-2 Fractional exponents are expressed by a numeric fraction in parentheses: the square root of a meter would be expressed as m(1/2). The multiplication of units is signified by a period (.) between the units, e.g., meters X seconds would be denoted m.s. Notice that spaces are not permitted. Division is signified by a slash (/) between two units, e.g. meters per second would be denoted as m/s. Algebraic combinations of ISO unit abbreviations constructed by dividing, multiplying, or exponentiating base ISO units, are also valid ISO abbreviations units. Exponentiation has precedence over multiplication or division. For example, microvolts squared per hertz (a unit of spectral power) would be denoted uv2/hz and evaluated as uv 2/hz while microvolts per square root of hertz (a unit of spectral amplitude) would be denoted uv/hz(1/2) and evaluated as uv/hz&frac12; . If more than one division operator is included in the expression the associations should be parenthesized to avoid any ambiguity, but the best approach is to convert a/(b/c) to a.c/b or a.c.b-1 to simplify the expression.

Figure 7-11. ANSI+ unit codes for some U.S. customary units

Units
Abbreviation
Units
Abbreviation
Units
Abbreviation
LENGTH
VOLUME
TIME
inch in cubic foot cft year yr
foot ft cubic inch cin month mo
mile (statute) mi cubic yard cyd week wk
mautical mile nmi tablespoon tbs day d
rod rod teaspoon tsp hour hr
yard yd pint pt minute  min
    quart qt second sec
    gallon gal    
    ounce (fluid) foz    
AREA
MASS
   
square foot sqf dram dr    
square inch sin grain gr (avoir)    
square yard syd ounce (weight) oz    
    pound lb    
Other ANSI units, derived units, and miscellanous
**British thermal unit btu **degrees fahrenheit degf **millirad mrad
cubic feet/minute cft/min **feet/minute ft/min **RAD rad
Note: the abbreviations for conventional U.S. units of time are the same as ISO, except for year. ISO = ANN, AMSI = yr. The metric units in X3.50 are the same as ISO, except for: pascal ("pa" in ANSI, "pal" in ISO); ANSI uses "min" for both time and arc while ISO uses "mnt" for minutes of arc; and in ISA seconds are abbreviated "s", in ANSI, "sec". 
This list is not exhaustive. Refer to ANSI X3.50-1986, Table 1, for other metric and standard U.S. units.
**Non-metric units not explicitly listed in ANSI

Figure 7-12. Single case ISO abbreviations for multiplier prefixes

Prefix 
 
Code 
Prefix 
 
Code
yotta* 1024 ya yocto 10-24 y
zetta* 1021 za zepto 10-21 z
exa 1018 ex atto 10-18 a
peta 1015 pe femto 10-15 f
tera 1012 t pico 10-12 p
giga 109 g nano 10-9 n
mega 106 ma micro 10-6 u
kilo 103 k milli 10-3 m
hecto 102 h centi 10-2 c
deca 101 da deci 10-1 d
*These abbreviations are not defined in the ISO specification for single case abbreviations. 

Figure 7-13 lists the abbreviations for common ISO derived units. It also includes standard unit abbreviations for common units, e.g., Milliequivalents, and international units, mm(Hg), and for counting per which we denote by a division sign, a denominator, but no numerator, e.g., /c, that are not part of the above referenced ISO standards. We have extended the units table to better accommodate drug routes and physiologic measures, and otherwise fill in gaps in Version 2.2.

We have generally followed the IUPAC 1995 Silver Book2 in the definitions of units. However, IUPAC specifies standards for reporting or displaying units and employs 8-bit data sets to distinguish them. This standard is concerned with the transmission of patient information. Therefore, we have restricted ourselves to case insensitive alphabetic characters and a few special characters (e.g., ".", "/", "( ", ") ","*", and "_" ) to avoid any possible confusion in the transmission. Therefore, we use ISO 2955-1983 (Information processing -- representation of SI and other units in systems with limited character sets) and ANSI X3.50-1986 (Representations for U.S. customary, SI, and other units to be used in systems with limited character sets) case insensitive units abbreviations where they are defined. This means that in some cases, IUPAC abbreviations have different abbreviations in ISO+ even when the IUPAC abbreviations use only standard alphabetic characters. For example, Pascal is abbreviated Pa in IUPAC but PAL in ISO+ (following ISO 2955) because Pa in a case insensitive context also means Picoampere. However, the requirements for transmission do not preclude usage of IUPAC standards for presentation on paper or video display reports to end users.

All unit abbreviations are case insensitive. One could write milliliters as ML, ml, or mL. In this table we have used lower case for all of the abbreviations except for the letter L which we represent in upper case so that readers will not confuse it with the numeral one (1). This is just a change in presentation, not a change in the standard. Systems should continue to send the codes as upper or lower case as they always have.

Figure 7-13. Common ISO derived units and *ISO extensions

Code/Abbr.
Name
/(arb_u) *1 / arbitrary unit
/iu *1 / international unit
/kg *1 / kilogram
/L 1 / liter
1/mL *1 / milliliter 
10.L/min *10 x liter / minute
10.L /(min.m2) *10 x (liter / minute) / meter2 = liter / (minute &acute; meter2)
10*3/mm3 *103 / cubic millimeter (e.g., white blood cell count)
10*3/L *103 / Liter
10*3/mL *103 / milliliter
10*6/mm3 *106 / millimeter3
10*6/L *106 / Liter
10*6/mL *106 / milliliter
10*9/mm3 *109 / millimeter3
10*9/L *109 / Liter
10*9/mL *109 / milliliter
10*12/L *1012 / Liter
10*3(rbc) *1000 red blood cells
a/m Ampere per meter
(arb_u) *Arbitrary unit
bar Bar (pressure; 1 bar = 100 kilopascals)
/min Beats Per Minute
bq Becquerel
(bdsk_u) *Bodansky Units
(bsa) *Body surface area
(cal) *Calorie 
1 *Catalytic Fraction
/L Cells / Liter
cm Centimeter
cm_h20 * Centimeters of water =H20 (pressure)
cm_h20.s/L Centimeters H20 / (liter / second) = (centimeters H20 &acute; second) / liter (e.g., mean pulmonary resistance)
cm_h20/(s.m) (Centimeters H20 / second) / meter = centimeters H20 / (second &acute; meter) (e.g., pulmonary pressure time product)
(cfu) *Colony Forming Units
m3/s Cubic meter per second
d Day 
db Decibels 
dba *Decibels a Scale
cel Degrees Celsius
deg Degrees of Angle
(drop) Drop
10.un.s/cm5 Dyne &acute; Second / centimeter5 (1 dyne = 10 micronewton = 10 un) (e.g., systemic vascular resistance) 
10.un.s/(cm5.m2) ((Dyne &acute; second) / centimeter5) / meter2 = (Dyne &acute; second) / (centimeter5 &acute; meter2) (1 dyne = 10 micronewton = 10 un) (e.g., systemic vascular resistance/body surface area)
ev Electron volts (1 electron volt = 160.217 zeptojoules)
eq Equivalent
f Farad (capacitance)
fg Femtogram
fL Femtoliter
fmol Femtomole
/mL *Fibers / milliliter
Gram
g/d *Gram / Day
g/dL Gram / Deciliter
g/hr Gram / Hour
g/(8.hr) *Gram / 8 Hour Shift
g/kg Gram / Kilogram (e.g., mass dose of medication per body weight)
g/(kg.d) (Gram / Kilogram) / Day = gram / (kilogram &acute; day) (e.g., mass dose of medication per body weight per day)
g/(kg.hr) (Gram / Kilogram) / Hour = gram / (kilogram &acute; hour) (e.g., mass dose of medication per body weight per hour)
g/(8.kg.hr) (Gram / Kilogram) /8 Hour Shift = gram / (kilogram &acute; 8 hour shift) (e.g., mass dose of medication per body weight per 8 hour shift)
g/(kg.min) (Gram / Kilogram) / Minute = gram / (kilogram &acute; minute) (e.g., mass dose of medication per body weight per minute)
g/L  Gram / Liter
g/m2 Gram / Meter2

(e.g., mass does of medication per body surface area)

g/min Gram / Minute
g.m/(hb) Gram &acute; meter / heart beat 

(e.g., ventricular stroke work)

g.m/((hb).m2) (Gram &acute; meter/ heartbeat) / meter2 = (gram &acute; meter) / (heartbeat &acute; meter2

(e.g., ventricular stroke work/body surface area, ventricular stroke work index)

g(creat) *Gram creatinine
g(hgb) *Gram hemoglobin
g.m Gram meter
g(tot_nit) *Gram total nitrogen
g(tot_prot) *Gram total protein
g(wet_tis) *Gram wet weight tissue
gy Grey (absorbed radiation dose)
hL Hectaliter = 102 liter
h Henry
in Inches
in_hg Inches of Mercury (=Hg)
iu *International Unit
iu/d *International Unit / Day
iu/hr *International Unit / Hour
iu/kg International Unit / Kilogram
iu/L  *International Unit / Liter
iu/mL *International Unit / Milliliter
iu/min *International Unit / Minute
j/L Joule/liter 

(e.g., work of breathing)

kat *Katal
kat/kg *Katal / Kilogram
kat/L *Katal / Liter
k/watt Kelvin per watt
(kcal) Kilocalorie (1 kcal = 6.693 kilojoule)
(kcal)/d *Kilocalorie / Day
(kcal)/hr *Kilocalorie / Hour
(kcal)/(8.hr) *Kilocalorie / 8 Hours Shift
kg Kilogram
kg(body_wt) * kilogram body weight
kg/m3 Kilogram per cubic meter
kh/h Kilogram per hour
kg/L Kilogram / liter
kg/min Kilogram per minute
kg/mol Kilogram / mole
kg/s Kilogram / second

 
kg/(s.m2) (Kilogram / second)/ meter2 = kilogram / (second &acute; meter2)
kg/ms Kilogram per square meter
kg.m/s Kilogram meter per second
kpa Kilopascal (1 mmHg = 0.1333 kilopascals)
ks Kilosecond
(ka_u) King-Armstrong Unit
(knk_u) *Kunkel Units
L Liter
L/d *Liter / Day
L/hr Liter / hour
L/(8.hr) *Liter / 8 hour shift
L/kg Liter / kilogram
L/min Liter / minute
L/(min.m2) (Liter / minute) / meter2 = liter / (minute &acute; meter2

(e.g., cardiac output/body surface area = cardiac index)

L/s Liter / second 

(e.g., peak expiratory flow)

L.s Liter / second / second2 = liter &acute; second
lm Lumen
lm/m2 Lumen / Meter2
(mclg_u) *MacLagan Units
mas Megasecond
m Meter
m2 Meter2

(e.g., body surface area)

m/s Meter / Second
m/s2 Meter / Second2
ueq *Microequivalents
ug Microgram
ug/d Microgram / Day
ug/dL Microgram / Deciliter
ug/g Microgram / Gram
ug/hr *Microgram / Hour
ug(8hr) Microgram / 8 Hour Shift
ug/kg Microgram / Kilogram
mg/(kg.d) (Microgram / Kilogram) /Day = microgram / (kilogram &acute; day) (e.g., mass dose of medication per patient body weight per day)
mg/(kg.hr) (Microgram / Kilogram) / Hour = microgram / (kilogram &acute; hours) (e.g., mass dose of medication per patient body weight per hour)
mg/(8.hr.kg) (Microgram / Kilogram) / 8 hour shift = microgram / (kilogram &acute; 8 hour shift) 

(e.g., mass dose of medication per patient body weight per 8 hour shift)

mg/(kg.min) (Microgram / Kilogram) / Minute = microgram / (kilogram &acute; minute) 

(e.g., mass dose of medication per patient body weight per minute)

ug/L Microgram / Liter
ug/m2 Microgram / Meter2 (e.g., mass dose of medication per patient body surface area)
ug/min Microgram / Minute
uiu *Micro international unit 
ukat *Microkatel
um Micrometer (Micron)
umol Micromole 
umol/d Micromole / Day
umol/L Micromole / Liter
umol/min Micromole / Minute
us Microsecond
uv Microvolt
mbar Millibar (1 millibar = 100 pascals)
mbar.s/L Millibar / (liter / second) =(millibar &acute; second) / liter (e.g., expiratory resistance)
meq *Milliequivalent
meq/d *Milliequivalent / Day
meq/hr *Milliequivalent / Hour
meq/(8.hr) Milliequivalent / 8 Hour Shift
meq/kg Milliequivalent / Kilogram (e.g., dose of medication in milliequivalents per patient body weight)
meq/(kg.d) (Milliequivalents / Kilogram) / Day = milliequivalents / (kilogram &acute; day) (e.g., dose of medication in milliequivalents per patient body weight per day)
meq/(kg.hr) (Milliequivalents / Kilogram) / Hour = milliequivalents / (kilogram &acute; hour) (e.g., dose of medication in milliequivalents per patient body weight per hour)
meq/(8.hr.kg) (Milliequivalents / Kilogram) / 8 Hour Shift = milliequivalents / (kilogram &acute; 8 hour shift) (e.g., dose of medication in milliequivalents per patient body weight per 8 hour shift)
meq/(kg.min) (Milliequivalents / Kilogram) / Minute = milliequivalents / (kilogram &acute; minute) (e.g., dose of medication in milliequivalents per patient body weight per minute)
meq/L Milliequivalent / Liter
  Milliequivalent / Meter2 (e.g., dose of medication in milliequivalents per patient body surface area)
meq/min Milliequivalent / Minute
mg Milligram
mg/m3 Milligram / Meter3
mg/d Milligram / Day
mg/dL Milligram / Deciliter
mg/hr Milligram / Hour
mg/(8.hr) Milligram / 8 Hour shift
mg/kg Milligram / Kilogram
mg/(kg.d) (Milligram / Kilogram) / Day = milligram / (kilogram &acute; day) (e.g., mass dose of medication per patient body weight per day)
mg/(kg.hr) (Milligram / Kilogram) / Hour = milligram/ (kilogram &acute; hour) (e.g., mass dose of medication per patient body weight per hour)
mg/(8.hr.kg) (Milligram / Kilogram) /8 Hour Shift = milligram / (kilogram &acute; 8 hour shift) (e.g., mass dose of medication per patient body weight per 8 hour shift)
mg/(kg.min) (Milligram / Kilogram) / Minute = milligram / (kilogram &acute; minute) (e.g., mass dose of medication per patient body weight per hour)
mg/L Milligram / Liter
mg/m2 Milligram / Meter2 (e.g., mass dose of medication per patient body surface area)
mg/min Milligram / Minute
mL Milliliter
mL/cm_h20 Milliliter / Centimeters of Water (H20) (e.g., dynamic lung compliance)
mL/d *Milliliter / Day
mL/(hb) Milliliter / Heart Beat (e.g., stroke volume)
mL/((hb).m2) (Milliliter / Heart Beat) / Meter2 = Milliliter / (Heart Beat &acute; Meter2) (e.g., ventricular stroke volume index)
mL/hr *Milliliter / Hour
mL/(8.hr) *Milliliter / 8 Hour Shift
mL/kg Milliliter / Kilogram (e.g., volume dose of medication or treatment per patient body weight)
mL/(kg.d) (Milliliter / Kilogram) / Day = milliliter / (kilogram &acute; day) (e.g., volume dose of medication or treatment per patient body weight per day)
mL/(kg.hr) (Milliliter / Kilogram) / Hour = milliliter / (kilogram &acute; hour) (e.g., volume dose of medication or treatment per patient body weight per hour)
mL/(8.hr.kg) (Milliliter / Kilogram) / 8 Hour Shift = milliliter / (kilogram &acute; 8 hour shift) (e.g., volume dose of medication or treatment per body weight per 8 hour shift)
mL/(kg.min) (Milliliter / Kilogram) / Minute = milliliter / (kilogram &acute; minute) (e.g., volume dose of medication or treatment per patient body weight per minute)
mL/m2 Milliliter / Meter2 (e.g., volume of medication or other treatment per patient body surface area)
mL/mbar Milliliter / Millibar (e.g., dynamic lung compliance)
mL/min Milliliter / Minute
mL/(min.m2) (Milliliter / Minute) / Meter2 = milliliter / (minute &acute; meter2) (e.g., milliliters of prescribed infusion per body surface area; oxygen consumption index)
mL/s Milliliter / Second
mm Millimeter
mm(hg) *Millimeter (HG) (1 mm Hg = 133.322 kilopascals)
mm/hr Millimeter/ Hour
mmol/kg Millimole / Kilogram (e.g., molar dose of medication per patient body weight)
mmol/(kg.d) (Millimole / Kilogram) / Day = millimole / (kilogram &acute; day) (e.g., molar dose of medication per patient body weight per day)
mmol/(kg.hr) (Millimole / Kilogram) / Hour = millimole / (kilogram &acute; hour) (e.g., molar dose of medication per patient body weight per hour)
mmol/(8.hr.kg) (Millimole / Kilogram) / 8 Hour Shift = millimole / (kilogram &acute; 8 hour shift) (e.g., molar dose of medication per patient body weight per 8 hour shift)

 
mmol/(kg.min) (Millimole / Kilogram) / Minute = millimole / (kilogram &acute; minute) (e.g., molar dose of medication per patient body weight per minute)
mmol/L Millimole / Liter
mmol/hr Millimole / Hour
mmol/(8hr) Millimole / 8 Hour Shift
mmol/min Millimole / Minute
mmol/m2 Millimole / Meter2 (e.g., molar dose of medication per patient body surface area)
mosm/L *Milliosmole / Liter
ms Milliseconds
mv Millivolts
miu/mL *Milliunit / Milliliter
mol/m3 Mole per cubic meter
mol/kg Mole / Kilogram
mol/(kg.s) (Mole / Kilogram) / Second = mole / (kilogram &acute; second)
mol/L Mole / Liter
mol/s Mole / Second
ng Nanogram
ng/d Nanogram / Day
ng/hr *Nanogram / Hour
ng/(8.hr) Nanogram / 8 Hour shift
ng/L Nanogram / Liter
ng/kg Nanogram / Kilogram (e.g., mass dose of medication per patient body weight)
ng/(kg.d) (Nanogram / Kilogram) / Day = nanogram / (kilogram &acute; day) (e.g., mass dose of medication per patient body weight per day)
ng/(kg.hr) (Nanogram / Kilogram) / Hour = nanogram / (kilogram &acute; hour) (e.g., mass dose of medication per patient body weight per hour)
ng/(8.hr.kg) (Nanogram / Kilogram) / 8 Hour Shift = nanogram / (kilogram &acute; 8 hour shift) (e.g., mass dose of medication per patient body weight per 8 hour shift)
ng/(kg.min) (Nanogram / Kilogram) / Minute = nanogram / (kilogram &acute; minute) (e.g., mass dose of medication per patient body weight per minute)
ng/m2 Nanogram / Meter2 (e.g., mass dose of medication per patient body surface area)
ng/mL Nanogram / Milliliter
ng/min *Nanogram / Minute
ng/s *Nanogram / Second
nkat *Nanokatel
nm Nanometer
nmol/s Nanomole / Second
ns Nanosecond
n Newton (force)
n.s Newton second
(od) *O.D. (optical density)
ohm Ohm (electrical resistance)
ohm.m Ohm meter
osmol Osmole
osmol/kg Osmole per kilogram
osmol/L Osmole per liter
/m3 *Particles / Meter3
/L *Particles / Liter
/(tot) *Particles / Total Count
(ppb) *Parts Per Billion
(ppm) *Parts Per Million
(ppth) Parts per thousand
(ppt) Parts per trillion (10^12)
pal Pascal (pressure)
/(hpf) *Per High Power Field
(ph) *pH
pa Picoampere
pg Picogram
pg/L Picogram / Liter
pg/mL Picogram / Milliliter
pkat *Picokatel
pm Picometer
pmol *Picomole
ps Picosecond
pt Picotesla
(pu) *P.U.
% Percent
dm2/s2 Rem (roentgen equivalent man) = 10-2 meter2 / second2 = decimeter2 / second2 Dose of ionizing radiation equivalent to 1 rad of x-ray or gamma ray) [From Dorland's Medical Dictionary]
sec Seconds of arc
sie Siemens (electrical conductance)
sv Sievert
m2/s Square meter / second
cm2/s Square centimeter / second
t Tesla (magnetic flux density)
(td_u) Todd Unit
v Volt (electric potential difference)
1 Volume Fraction
wb Weber (magnetic flux)
*Starred items are not genuine ISO, but do not conflict.

†This approach to units is discouraged by IUPAC. We leave them solely for backwards compatibility

_

7.3.2.6.1.3 Local unit codes
Local codes can be used for the units by indicating the code source of 99zzz in the third component (where 99zzz is an alpha-numeric string). In the case of local codes, the text name of the codes or the description of the units should also be transmitted (in the second component), so that the receiving system can compare the results with results for the same measurement sent by another service (refer to Chapter 2, Section 2.8, "Data Types"). An "L" should be stored in the third component to indicate that the code is locally defined. More specialized local code designations, as specified in the CE data type definition, can also be employed.

7.3.2.7 References range (ST) 00575

Components: for numeric values in the format:

a) lower limit-upper limit (when both lower and upper limits are defined, e.g., for potassium 3.5 - 4.5)

b) lower limit (if no upper limit, e.g., 10)

c) < upper limit (if no lower limit, e.g., <15)

alphabetical values: the normal value may be reported in this location

Definition: When the observation quantifies the amount of a toxic substance, then the upper limit of the range identifies the toxic limit. If the observation quantifies a drug, the lower limits identify the lower therapeutic bounds and the upper limits represent the upper therapeutic bounds above which toxic side effects are common.

7.3.2.8 Abnormal flags (ID) 00576

Definition: This field contains a table lookup indicating the normalcy status of the result. We strongly recommend sending this value when applicable. If the observation is an antimicrobial susceptibility, the interpretation codes are: S=susceptible; R=resistant; I=intermediate; MS=moderately susceptible; VS=very susceptible. (See ASTM 1238 - review for more details). Refer to HL7table 0078 - Abnormal flags for valid entries.

When the laboratory can discern the normal status of a textual report, such as chest X-ray reports or microbiologic culture, these should be reported as N when normal and A when abnormal. Multiple codes, e.g., abnormal and worse, would be separated by a repeat delimiter, e.g., A~W.

Table 0078 Abnormal flags

Value
Description
L
Below low normal
H
Above high normal
LL
Below lower panic limits
HH
Above upper panic limits
<
Below absolute low-off instrument scale
 
Above absolute high-off instrument scale
N
Normal (applies to non-numeric results)
A
Abnormal (applies to non-numeric results)
AA
Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units)
null
No range defined, or normal ranges don't apply
U
Significant change up
D
Significant change down
B
Better--use when direction not relevant
W
Worse--use when direction not relevant
For microbiology susceptibilities only:
S
Susceptible
R
Resistant
I
Intermediate
MS
Moderately susceptible
VS
Very susceptible

Results may also be reported in shorthand by reporting the normalcy status without specifying the exact numeric value of the result. Such shorthand is quite common in clinical notes, where physicians will simply say that the glucose result was normal. Such shorthand reporting is also seen in drug experience reporting. In such cases, the result can be reported in the OBX by reporting the normalcy code in OBX-8-abnormal flags without specifying any value in OBX-5-observation value.

7.3.2.9 Probability (NM) 00577

Definition: This field contains the probability of a result being true for results with categorical values. It mainly applies to discrete coded results. It is a decimal number represented as an ASCII string that must be between 0 and 1, inclusive.

7.3.2.10 Nature of abnormal test (ID) 00578

Definition: This field contains the nature of the abnormal test. Refer to HL7 table 0080 - Nature of abnormal testing for valid values. As many of the codes as apply may be included, separated by repeat delimiters. For example, normal values based on age, sex, and race would be codes as A~S~R.

Table 0080 Nature of abnormal testing

Value
Description
A
An age-based population
N
None - generic normal range
R
A race-based population
S
A sex-based population

7.3.2.11 Observ result status (ID) 00579

Definition: This field contains the observation result status. Refer to HL7 table 0085 - Observation result status for valid values. This field reflects the current completion status of the results for one Observation Identifier.

It is a required field. Previous version of HL7 stated this implicitly by defining a default value of "F." Code F indicates that the result has been verified to be correct and final. Code W indicates that the result has been verified to be wrong (incorrect); a replacement (corrected) result may be transmitted later. Code C indicates that data contained in the OBX-5-observation value field are to replace previously transmitted (verified and) final result data with the same observation ID (including suffix, if applicable) and observation sub-ID usually because the previous results were wrong. Code D indicates that data previously transmitted in a result segment with the same observation ID (including suffix) and observation sub-ID should be deleted. When changing or deleting a result, multiple OBX segments with the same observation ID and observation sub-ID are replaced or deleted as a unit. Normal progression of results through intermediate (e.g., ‘gram positive cocci’) to final (e.g., ‘staphylococcus aureus’) should not be transmitted as C (correction); they should be transmitted as P or S (depending upon the specific case) until they are final.

Table 0085 - Observation result status codes interpretation

Value
Description
C
Record coming over is a correction and thus replaces a final result
D
Deletes the OBX record
F
Final results; Can only be changed with a corrected result.
I
Specimen in lab; results pending
P
Preliminary results
R
Results entered -- not verified
S
Partial results
X
Results cannot be obtained for this observation
U
Results status change to Final. without retransmitting results already sent as ‘preliminary.’ E.g., radiology changes status from preliminary to final
W
Post original as wrong, e.g., transmitted for wrong patient

7.3.2.12 Effective date last obs normal value (TS) 00580

Definition: This field contains the changes in the observation methods that would make values obtained from the old method not comparable with those obtained from the new method.

Null if there are no normals or units. If present, a change in this date compared to date-time recorded, the receiving system’s test dictionary should trigger a manual review of the results to determine whether the new observation ID should be assigned a new ID in the local system to distinguish the new results from the old.

7.3.2.13 User defined access checks (ST) 00581

Definition: This field permits the producer to record results-dependent codes for classifying the observation at the receiving system. This field should be needed only rarely, because most classifications are fixed attributes of the observation ID and can be defined in the associated observation master file (see description in Chapter 8).

However, there are a few cases when such controls vary with the value of the observation in a complex way that the receiving system would not want to re-calculate. An example is an antimicrobial susceptibility result. Some systems prefer to display only the susceptibility results of inexpensive antimicrobials depending upon the organism, the source of the specimen and the patients allergy status. The sending service wants to send all of the susceptibilities so that certain privileged users (e.g., Infectious Disease specialists) can review all of the results but nonprivileged users would see only the "preferred" antimicrobials to which the organism was susceptible. We expect that other cases also occur.

7.3.2.14 Date-time of the observation (TS) 00582

Definition: This field is required in two circumstances. The first is when the observations reported beneath one report header (OBR) have different dates. This could occur in the case of queries, timed test sequences, or clearance studies where one measurement within a battery may have a different time than another measurement.

It is also needed in the case of OBX segments that are being sent by the placer to the filler, in which case the date of the observation being transmitted is likely to have no relation to the date of the requested observation. In France, requesting services routinely send a set of the last observations along with the request for a new set of observations. The date of these observations is important to the filler laboratories.

In all cases, the observation date-time is the physiologically relevant date-time or the closest approximation to that date-time. In the case of tests performed on specimens, the relevant date-time is the specimen’s collection date-time. In the case of observations taken directly on the patient (e.g., X-ray images, history and physical), the observation date-time is the date-time that the observation was performed.

7.3.2.15 Producer's ID (CE) 00583

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

Definition: This field contains a unique identifier of the responsible producing service. It should be reported explicitly when the test results are produced at outside laboratories, for example. When this field is null, the receiving system assumes that the observations were produced by the sending organization. This information supports CLIA regulations in the US. The code for producer ID is recorded as a CE data type. In the US, the Medicare number of the producing service is suggested as the identifier.

7.3.2.16 Responsible observer (XCN) 00584

Components: <ID number (ST) ^<family name (ST) ^ <given name (ST) ^ <middle initial or name (ST) ^ <suffix (e.g., JR or III) (ST) ^ <prefix (e.g., DR) (ST) ^ <degree (e.g., MD) (ST) ^ <source table (IS) ^<assigning authority (HD) ^<name type (ID) ^<identifier check digit (ST) ^ <code identifying the check digit scheme employed (ID) ^ <identifier type code (IS) ^ <assigning facility ID (HD)

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

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

Definition: When required, this field contains the identifier of the individual directly responsible for the observation (i.e., the person who either performed or verified it). In a nursing service, the observer is usually the professional who performed the observation (e.g., took the blood pressure). In a laboratory, the observer is the technician who performed or verified the analysis. The code for the observer is recorded as a CE data type. If the code is sent as a local code, it should be unique and unambiguous when combined with OBX-15-producer ID.

7.3.2.17 Observation method (CE) 00936

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

This optional field can be used to transmit the method or procedure by which an observation was obtained when the sending system wishes to distinguish among one measurement obtained by different methods and the distinction is not implicit in the test ID. Chemistry laboratories do not usually distinguish between two different methods used to measure a given serum constituent (e.g., serum potassium) as part of the test name. See the LOINC Users Manual [ LOINC Committee. Logical Observation Identifier Names and Codes. Indianapolis: Regenstrief Institute and LOINC Committee, 1995. c/o Kathy Hutchins, 1001 West 10th Street RG-5, Indianapolis, IN 46202. 317/630-7433. Available via FTP/Gopher (dumccss.mc.duke.edu/standards/HL7/termcode/loinclab) and World Wide Web (http://dumccss.mc.duke.edu/standards/HL7/termcode/loinc.htm). The LOINC Code System is described in Forrey AW, McDonald CJ, DeMoor G, Huff SM, Leavelle D, Leland D, et.al. Logical Observation Identifier Names and Codes (LOINC) database: a public use set of codes and names for electronic reporting of clinical laboratory test results. Clinical Chemistry 1996;42:81-90] for a more complete discussion of these distinctions. If an observation producing service wanted to report the method used to obtain a particular observation, and the method was NOT embedded in the test name, they can use this field.

The Centers for Disease Control and Prevention (CDC) Method Code (CDCM) (see Figure 7-3) is one candidate code system for reporting methods/instruments. EUCLIDES method codes are another. User-defined tables are an alternative.
 
 
 

4.6.1 ODS - dietary orders, supplements, and preferences segment

The ORC sequence items of interest to ODS are ORC-1-order control,ORC-2-placer order number, ORC-3-filler order number, ORC-7-quantity/timing, ORC-9-date/time of transaction, ORC-10-entered by, and ORC-11-verified by. For ORC-1-order control, the values may be New (NW), Cancel (CA), Discontinue Order Request (DC), Change (XO), Hold Order Request (HD), and Release Previous Hold (RL). The HD and RL codes could stop service for a specified length of time. ORC-4-quantity/timing should be used to specify whether an order is continuous or for one service period only. It is also useful for supplements which are part of a diet but only delivered, say, every day at night. Example:
|1^QPM^^19910415|.
Figure 4-9. ODS attributes
 
SEQ LEN DT OPT RP/ # TBL # ITEM # ELEMENT NAME
1 1 ID R 0159 00269 Type 
2 60 CE O Y/10 00270 Service Period
3 60 CE R Y/20 00271 Diet, Supplement, or Preference Code
4 80 ST O Y/2 00272 Text Instruction

4.6.1.0 ODS field definitions

4.6.1.1 Type (ID) 00269

Definition: This field specifies type of diet. Refer to HL7 table 0159 - Diet type for valid entries.

Table 0159 - Diet type
 
Value Description
D Diet
S Supplement
P Preference

4.6.1.2 Service period (CE) 00270

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

Definition: When blank, the modifier applies to all service periods. Diet orders, for example, typically apply to all service periods. This field usually specifies supplements. This field allows you to designate a modification for one or more of the service periods during a day by combining service specifications as needed. The service periods will be local CEs, normally numbers. Suggested are:
service 1 is breakfast
service 2 is mid-a.m. snack
service 3 is lunch
service 4 is mid-afternoon snack
service 5 is dinner
service 6 is bedtime snack

Ex: |1~5| means service 1 and service 5, whatever these are locally defined to be.

4.6.1.3 Diet, supplement, or preference code (CE) 00271

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

Definition: This field is the identifier of the ordered item for a patient; it is equivalent to OBR-4-universal service ID in function. Since ODS is a repeating segment, multiple entities get multiple segments. Example:

|^REG^L&FD7|, |023^^L&FD6|, |^NOLACT^L&FD5|, |^TUBEFD^L&FD4|, and |011^HIPRO100^L&FD1~123^LOFAT20^L&FD1|
In the case where this segment requests a diet supplement, i.e., ODS-1-type = S, this attribute specifies a particular item or class of items. If institutional codes for patient food preferences (P) have been codified, they are also expressed as coded segments; otherwise, the information is passed as a text string in the fourth component of the ODS segment, described below.

4.6.1.4 Text instruction (ST) 00272

Definition: This field defines the specific instructions for dietary. These instructions may address specific patient needs, such as isolation. This field provides the ordering provider’s dietary instructions as free text. It can represent the full dietary instruction or indicate supplemental information.
 
 

4.6.2 ODT - diet tray instructions segment

This segment addresses tray instructions. These are independent of diet codes, supplements, and preferences and therefore get separate order numbers.

Figure 4-10. ODT attributes
 
SEQ LEN DT OPT RP/ # TBL # ITEM # ELEMENT NAME
1 60 CE R 0160 00273 Tray Type
2 60 CE O Y/10 00270 Service Period
3 80 ST O 00272 Text Instruction

4.6.2.0 ODT field definitions

4.6.2.1 Tray type (CE) 00273

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

Definition: This field defines the type of dietary tray. Refer to HL7 table 0160 - Tray type for valid entries.

Table 0160 - Tray type
 
Value Description
EARLY Early tray
LATE Late tray
GUEST Guest tray
NO No tray
MSG Tray message only

Tray specifications are useful for early and late tray delivery in cases where a patient undergoes a procedure during normal feeding times. Tray specifications can also be used for guest trays, no trays, and messages. The value MSG means the ODT segment does not specify the type of tray but provides additional information about an existing tray. This information is found in ODT-3-text instructions.

4.6.2.2 Service period (CE) 00274

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

Definition: When blank, the modifier applies to all service periods. This field allows you to designate one or more of the feeding periods during a day by combining the codes as needed. It can also combine with quantity/timing to give such information as which service period the order belongs with. This field is identical in meaning with ODS-2-service period. See Section 4.6.1.2, "Service period (CE) 00270 for further details.

4.6.2.3 Text Instruction (ST) 00272

Definition: This field defines instructions associated with the tray. Example:
|PLASTIC SILVERWARE|.

4.7.1 RQD - requisition detail segment

RQD contains the detail for each requisitioned item. See assumptions above.

Figure 4-11. RQD attributes
 

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME
1 4 SI O 00275 Requisition Line Number
2 60 CE C 00276 Item Code - Internal
3 60 CE C 00277 Item Code - External
4 60 CE C 00278 Hospital Item Code
5 6 NM O 00279 Requisition Quantity
6 60 CE O 00280 Requisition Unit of Measure
7 30 IS O 0319 00281 Dept. Cost Center
8 30 IS O 0320 00282 Item Natural Account Code
9 60 CE O 00283 Deliver To ID
10 8 DT O 00284 Date Needed

4.7.1.0 RQD field definitions

4.7.1.1 Requisition line number (SI) 00275

Definition: This field contains the number that identifies this line in the requisition.

4.7.1.2 Item code - internal (CE) 00276

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

Definition: This field contains the identifier and description that uniquely identifies the item on the application sending the requisition. This field is conditional because at least one of the three fields RQD-2-item code - internal, RQD-3-item code - external, or RQD-4-hospital item code must be valued.

4.7.1.3 Item code - external (CE) 00277

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

Definition: This field contains the identifier and description that uniquely identifies the item on the application receiving the requisition. This field is conditional because at least one of the three fields RQD-2-item code - internal, RQD-3-item code - external or RQD-4-hospital item code must be valued.

4.7.1.4 Hospital item code (CE) 00278

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

Definition: This field contains the identifier and description that uniquely identifies the item on all applications in the hospital. The identifier is usually controlled by the hospital Financial application in the Charge Description Master file. This field is conditional because at least one of the three fields RQD-2-item code - internal, RQD-3-item code - external or RQD-4-hospital item code must be valued.
Note: At least one of the three fields 4.7.1.2 through 4.7.1.4 must be non-null.

4.7.1.5 Requisition quantity (NM) 00279

Definition: This field contains the quantity requisitioned for this item.

4.7.1.6 Requisition unit of measure (CE) 00280

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

Definition: This field contains the unit of measure for this item.

4.7.1.7 Dept. cost center (IS) 00281

Definition: This field contains the accounting code that identifies this department in order to charge for this item. Refer to user-defined table 0319 - Dept. cost center for suggested values.

4.7.1.8 Item natural account code (IS) 00282

Definition: This field contains the accounting code that identifies this item in order to charge for this item. Refer to user-defined table 0320 - Item natural account code for suggested values.

4.7.1.9 Deliver to ID (CE) 00283

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

Definition: This field contains the unique identifier and descriptive name of the department/location where the item should be delivered.

4.7.1.10 Date needed (DT) 00284

Definition: This field contains the date this item is required.
Note: Although none of the fields are required, one of the three identifying codes--Item Code - Internal, Item Code - External, or Hospital Item Code--must be specified in order for the receiving application to process the request.

It is left to the vendors to determine which will be used as the common link between the two applications. HL7 recommends using the RQD-4-hospital item code.

Hospital accounting requires an identifier to charge a particular cost center or patient for a requisitioned supply. If the supply is for a patient, then this identifier comes from the PID segment; otherwise, from RQD-7-dept. cost center and RQD-8-item natural account code must be used. It is recommended that the "final" cost center responsible for providing the supply to the patient be included, even when the patient ID is provided.

Hospital accounting applications use RQD-7-dept. cost center concatenated with RQD-8-item natural account code in order to post this transaction to the General Ledger. This concatenated value should correspond to a valid entry in the accounting applications "Chart of Accounts."
 
 

4.7.2 RQ1 - requisition detail-1 segment

RQ1 contains additional detail for each nonstock requisitioned item. This segment definition is paired with a preceding RQD segment.

Figure 4-12. RQ1 attributes
 

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME
1 10 ST O 00285 Anticipated Price
2 60 CE C 00286 Manufactured ID
3 16 ST C 00287 Manufacturer's Catalog
4 60 CE C 00288 Vendor ID
5 16 ST C 00289 Vendor Catalog
6 1 ID O 0136 00290 Taxable
7 1 ID O 0136 00291 Substitute Allowed

4.7.2.0 RQ1 field definitions

4.7.2.1 Anticipated price (ST) 00285

Definition: This field contains the reference price for the requisition unit of measure that is known to the Requisition application. It may or may not be the actual cost of acquiring the item from a supplier. It is also not the price charged to the patient.

4.7.2.2 Manufacturer ID (CE) 00286

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

Definition: This field contains the unique code that identifies the manufacturer on the application receiving the requisition. This field is conditional because either RQ1-2-manufacturer ID and RQ1-3-manufacturer's catalog or RQ1-4-vendor ID and RQ1-5-vendor catalog must be valued.

Codes may be selected from HIBCC Manufacturers Labeler ID Code (LIC), the UPC or the NDC. These code sets may be obtained from the appropriate organization whose addresses are included in Figure 7-3.

4.7.2.3 Manufacturer's catalog (ST) 00287

Definition: This field is the manufacturer’s catalog number or code for this item. This field is conditional because either RQ1-2-manufacturer ID and RQ1-3-manufacturer’s catalog or RQ1-4-vendor ID and RQ1-5-vendor catalog must be valued.

4.7.2.4 Vendor ID (CE) 00288

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

Definition: This field is the unique code that identifies the vendor on the application receiving the requisition. This field is conditional because either RQ1-2-manufacturer ID and RQ1-3-manufacturer’s catalog or RQ1-4-vendor ID and RQ1-5-vendor catalog must be valued.

Because of this, it is recommended that each nonstock item have RQ1-2-manufacturers ID and RQ1-3-manufacturer’s catalog, or RQ1-4-vendor ID and RQ1-5-vendor catalog. It is also possible that the requisitioning application will not know the identifier, as listed in the Manufacturer’s or Vendor’s catalog. In this case, it is important to include the name portion of this coded element field.

4.7.2.5 Vendor catalog (ST) 00289

Definition: This field is the vendor’s catalog number, name, or code for this item. This field is conditional because either RQ1-2-manufacturer ID and RQ1-3-manufacturer’s catalog or RQ1-4-vendor ID and RQ1-5-vendor catalog must be valued.

4.7.2.6 Taxable (ID) 00290

Definition: This field indicates whether this item is subject to tax.

In general, nonstock requisitioned items will be printed by the receiving application and then processed by a human. In other words, the human will use the information to call the vendor or manufacturer to get pricing and other related purchasing information before placing the order with an outside vendor. Refer to HL7 table 0136 -Yes/no indicator as defined in Chapter 2.

4.7.2.7 Substitute allowed (ID) 00291

Definition: This field indicates whether the ancillary department may substitute an equivalent version of the item(s) ordered. Refer to HL7 table 0136 - Yes/no indicator as defined in Chapter 2.