Figure 2-8. MSH attributes
|
|
|
|
|
|
|
ELEMENT NAME |
|
1 | ST |
|
00001 | Field Separator | ||
|
4 | ST |
|
00002 | Encoding Characters | ||
|
180 | HD |
|
00003 | Sending Application | ||
|
180 | HD |
|
00004 | Sending Facility | ||
|
180 | HD |
|
00005 | Receiving Application | ||
|
180 | HD |
|
00006 | Receiving Facility | ||
|
26 | TS |
|
00007 | Date/Time Of Message | ||
|
40 | ST |
|
00008 | Security | ||
|
7 | CM |
|
00009 | Message Type | ||
|
20 | ST |
|
00010 | Message Control ID | ||
|
3 | PT |
|
00011 | Processing ID | ||
|
8 | ID |
|
0104 | 00012 | Version ID | |
|
15 | NM |
|
00013 | Sequence Number | ||
|
180 | ST |
|
00014 | Continuation Pointer | ||
|
2 | ID |
|
0155 | 00015 | Accept Acknowledgment Type | |
|
2 | ID |
|
0155 | 00016 | Application Acknowledgment Type | |
|
2 | ID |
|
00017 | Country Code | ||
|
6 | ID |
|
Y/3 | 0211 | 00692 | Character Set |
|
60 | CE |
|
00693 | Principal Language Of Message |
2.24.1.0 MSH field definitions
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.
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.
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.
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.
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.
|
|
|
|
General acknowledgment message | 2 |
|
ADT response | 3 |
|
ADT message | 3 |
|
Ancillary RPT (display) | 7 |
|
Add/change billing account | 6 |
|
Unsolicited clinical study data | 7 |
|
Detail financial transaction | 6 |
|
Display response | 2 |
|
Enhanced display response | 2 |
|
Event replay response | 2 |
|
Event replay query | 2 |
|
Embedded query language query | 2 |
|
Delayed acknowledgment | 2 |
|
Documentation message | 9 |
|
Master files notification | 8 |
|
Master files application acknowledgement | 8 |
|
Master files delayed application acknowledgement | 8 |
|
Master files query | 8 |
|
Master files query response | 8 |
|
Observ. result/record response | 7 |
|
Order message | 4 |
|
Order acknowledgement message | 4 |
|
Observ result/unsolicited | 7 |
|
Order status query | 4 |
|
Order status response | 4 |
|
Query, original Mode | 2 |
|
Product experience | 7 |
|
Patient goal | 12 |
|
Patient goal response | 12 |
|
Patient goal query | 12 |
|
Patient Insurance Information | 12 |
|
Patient pathway (goal-oriented) | 12 |
|
Patient pathway (problem-oriented) | 12 |
|
Patient problem | 12 |
|
Patient pathway (goal oriented) | 12 |
|
Patient goal response | 12 |
|
Patient care problem query | 12 |
|
Patient problem response | 12 |
|
Patient pathway (problem-oriented) query | 12 |
|
Patient pathway (problem-oriented) response | 12 |
|
Patient pathway (goal-oriented) query | 12 |
|
Patient pathway (goal-oriented) response | 12 |
|
Patient information | 11 |
|
Pharmacy administration information | 4 |
|
Pharmacy administration message | 4 |
|
Return clinical information | 11 |
|
Return clinical list | 11 |
|
Pharmacy encoded order message | 4 |
|
Pharmacy dispense information | 4 |
|
Pharmacy dispense message | 4 |
|
Pharmacy give message | 4 |
|
Pharmacy dose information | 4 |
|
Patient referral | 11 |
|
Pharmacy encoded order information | 4 |
|
Request patient demographics | 11 |
|
Pharmacy prescription order response | 4 |
|
Return patient authorization | 11 |
|
Return patient information | 11 |
|
Return patient display list | 11 |
|
Return patient list | 11 |
|
Request patient authorization | 11 |
|
Request clinical information | 11 |
|
Request patient information | 11 |
|
Request patient demographics | 11 |
|
Pharmacy administration acknowledgment | 4 |
|
Pharmacy dispense acknowledgment | 4 |
|
Pharmacy encoded order acknowledgment | 4 |
|
Pharmacy give acknowledgment | 4 |
|
Return patient referral | 11 |
|
Schedule information unsolicited | 10 |
|
Stored procedure request | 2 |
|
Schedule query | 10 |
|
Schedule query response | 10 |
|
Clinical study registration | 7 |
|
Schedule request | 10 |
|
Scheduled request response | 10 |
|
Summary product experience report | 7 |
|
Tabular data response | 2 |
|
Unsolicited display message | 2 |
|
Virtual table query | 2 |
|
Query for vaccination record | 4 |
|
Vaccination query response with multiple PID matches | 4 |
|
Vaccination query record response | 4 |
|
Unsolicited vaccination record update | 4 |
|
|
Description |
|
ADT/ACK - Admit / visit notification |
|
ADT/ACK - Transfer a patient |
|
ADT/ACK - Discharge/end visit |
|
ADT/ACK - Register a patient |
|
ADT/ACK - Pre-admit a patient |
|
ADT/ACK - Change an outpatient to an inpatient |
|
ADT/ACK - Change an inpatient to an outpatient |
|
ADT/ACK - Update patient information |
|
ADT/ACK - Patient departing - tracking |
|
ADT/ACK - Patient arriving - tracking |
|
ADT/ACK - Cancel admit/visit notification |
|
ADT/ACK - Cancel transfer |
|
ADT/ACK - Cancel discharge/end visit |
|
ADT/ACK - Pending admit |
|
ADT/ACK - Pending transfer |
|
ADT/ACK - Pending discharge |
|
ADT/ACK - Swap patients |
|
ADT/ACK - Merge patient information |
|
QRY/ADR - Patient query |
|
ADT/ACK - Bed status update |
|
ADT/ACK - Patient goes on a "leave of absence" |
|
ADT/ACK - Patient returns from a "leave of absence" |
|
ADT/ACK - Delete a patient record |
|
ADT/ACK - Link patient information |
|
ADT/ACK - Cancel pending discharge |
|
ADT/ACK - Cancel pending transfer |
|
ADT/ACK - Cancel pending admit |
|
ADT/ACK - Add person information |
|
ADT/ACK - Delete person information |
|
ADT/ACK - Merge person information |
|
ADT/ACK - Update person information |
|
ADT/ACK - Cancel patient arriving - tracking |
|
ADT/ACK - Cancel patient departing - tracking |
|
ADT/ACK - Merge patient information - patient ID only |
|
ADT/ACK - Merge patient information - account number only |
|
ADT/ACK - Merge patient information - patient ID and account number |
|
ADT/ACK - Unlink patient information |
|
ADT/ACK - Cancel pre-admit |
|
ADT/ACK - Merge person - external ID |
|
ADT/ACK - Merge patient - internal ID |
|
ADT/ACK - Merge account - patient account number |
|
ADT/ACK - Merge visit - visit number |
|
ADT/ACK - Move patient information - internal ID |
|
ADT/ACK - Move account information - patient account number |
|
ADT/ACK - Move visit information - visit number |
|
ADT/ACK - Change external ID |
|
ADT/ACK - Change internal ID |
|
ADT/ACK - Change alternate patient ID |
|
ADT/ACK - Change patient account number |
|
ADT/ACK - Change visit number |
|
ADT/ACK - Change alternate visit ID |
|
CRM - Register a patient on a clinical trial |
|
CRM - Cancel a patient registration on clinical trial (for clerical mistakes only) |
|
CRM - Correct/update registration information |
|
CRM - Patient has gone off a clinical trial |
|
CRM - Patient enters phase of clinical trial |
|
CRM - Cancel patient entering a phase (clerical mistake) |
|
CRM - Correct/update phase information |
|
CRM - Patient has gone off phase of clinical trial |
|
CSU - Automated time intervals for reporting, like monthly |
|
CSU - Patient completes the clinical trial |
|
CSU - Patient completes a phase of the clinical trial |
|
CSU - Update/correction of patient order/result information |
|
QRY/EQQ/SPQ/VQQ/RQQ - Cancel query |
|
PGL/ACK - Patient goal |
|
RQI/RPI - Request for insurance information |
|
RQI/RPL - Request/receipt of patient selection display list |
|
RQI/RPR - Request/receipt of patient selection list |
|
RQD/RPI - Request for patient demographic data |
|
RQC/RCI - Request for patient clinical information |
|
RQC/RCL - Request/receipt of clinical data listing |
|
PIN/ACK - Unsolicited insurance information |
|
RQA/RPA - Request for treatment authorization information |
|
RQA/RPA - Request for modification to an authorization |
|
RQA/RPA - Request for resubmission of an authorization |
|
RQA/RPA - Request for cancellation of an authorization |
|
REF/RRI - Patient referral |
|
REF/RRI - Modify patient referral |
|
REF/RRI - Cancel patient referral |
|
REF/RRI - Request patient referral status |
|
MFN/MFK - Master file not otherwise specified (for backward compatibility only) |
|
MFN/MFK - Master file - Staff Practioner |
|
MFN/MFK - Master file - Test/Observation (for backward compatibility only) |
|
MFQ/MFR - Master files query (use event same as asking for e.g., M05 - location) |
|
MFN/MFK - Master files charge description |
|
MFN/MFK - Patient location master file |
|
MFN/MFK - Clinical study with phases and schedules master file |
|
MFN/MFK - Clinical study without phases but with schedules master file |
|
MFN/MFK - Test/observation (Numeric) master file |
|
MFN/MFK - Test/Observation (Categorical) master file |
|
MFN/MFK - Test /observation batteries master file |
|
MFN/MFK - Test/calculated observations master file |
|
ORM - Order message (also RDE, RDS, RGV, RAS) |
|
ORR - Order response (also RRE, RRD, RRG, RRA) |
|
BAR/ACK - Add patient accounts |
|
BAR/ACK - Purge patient accounts |
|
DFT/ACK - Post detail financial transaction |
|
QRY/DSP - Generate bill and A/R statements |
|
BAR/ACK - Update account |
|
BAR/ACK - End account |
|
PEX - Unsolicited initial individual product experience report |
|
PEX - Unsolicited update individual product experience report |
|
SUR - Summary product experience report |
|
PPR - PC/ Problem Add |
|
PPR - PC/ Problem Update |
|
PPR - PC/ Problem Delete |
|
PRQ - PC/ Problem Query |
|
PRR - PC/ Problem Response |
|
PGL - PC/ Goal Add |
|
PGL - PC/ Goal Update |
|
PGL - PC/ Goal Delete |
|
PGQ - PC/ Goal Query |
|
PGR - PC/ Goal Response |
|
PPP - PC/ Pathway (Problem-Oriented) Add |
|
PPP - PC/ Pathway (Problem-Oriented) Update |
|
PPP - PC/ Pathway (Problem-Oriented) Delete |
|
PTQ - PC/ Pathway (Problem-Oriented) Query |
|
PTR - PC/ Pathway (Problem-Oriented) Query Response |
|
PPG - PC/ Pathway (Goal-Oriented) Add |
|
PPG - PC/ Pathway (Goal-Oriented) Update |
|
PPG - PC/ Pathway (Goal-Oriented) Delete |
|
PTU - PC/ Pathway (Goal-Oriented) Query |
|
PTV - PC/ Pathway (Goal-Oriented) Query Response |
|
QRY/DSR - Query sent for immediate response |
|
QRY/QCK - Query sent for deferred response |
|
DSR/ACK - Deferred response to a query |
|
UDM/ACK - Unsolicited display update message |
|
OSQ/OSR - Query for order status |
|
ORU/ACK - Unsolicited transmission of an observation message |
|
QRY - Query for results of observation |
|
QRY/DSR Display-oriented results, query/unsol. update (for backward compatibility only) |
|
ORF - Response to query; transmission of requested observation |
|
QRY/DSR-query for display results |
|
UDM-unsolicited update/display results |
|
RAR - Pharmacy administration information query response |
|
RDR - Pharmacy dispense information query response |
|
RER - Pharmacy encoded order information query response |
|
RGR - Pharmacy dose information query response |
|
ROR - Pharmacy prescription order query response |
|
SRM/SRR - Request new appointment booking |
|
SRM/SRR - Request appointment rescheduling |
|
SRM/SRR - Request appointment modification |
|
SRM/SRR - Request appointment cancellation |
|
SRM/SRR - Request appointment discontinuation |
|
SRM/SRR - Request appointment deletion |
|
SRM/SRR - Request addition of service/resource on appointment |
|
SRM/SRR - Request modification of service/resource on appointment |
|
SRM/SRR - Request cancellation of service/resource on appointment |
|
SRM/SRR - Request discontinuation of service/resource on appointment |
|
SRM/SRR - Request deletion of service/resource on appointment |
|
SIU/ACK - Notification of new appointment booking |
|
SIU/ACK - Notification of appointment rescheduling |
|
SIU/ACK - Notification of appointment modification |
|
SIU/ACK - Notification of appointment cancellation |
|
SIU/ACK - Notification of appointment discontinuation |
|
SIU/ACK - Notification of appointment deletion |
|
SIU/ACK - Notification of addition of service/resource on appointment |
|
SIU/ACK - Notification of modification of service/resource on appointment |
|
SIU/ACK - Notification of cancellation of service/resource on appointment |
|
SIU/ACK - Notification of discontinuation of service/resource on appointment |
|
SIU/ACK - Notification of deletion of service/resource on appointment |
|
SIU/ACK - Notification of blocked schedule time slot(s) |
|
SIU/ACK - Notification of opened ("unblocked") schedule time slot(s) |
|
SQM/SQR - Schedule query message and response |
|
Notification that patient did not show up for schedule appointment |
|
MDM/ACK - Original document notification |
|
MDM/ACK - Original document notification and content |
|
MDM/ACK - Document status change notification |
|
MDM/ACK - Document status change notification and content |
|
MDM/ACK - Document addendum notification |
|
MDM/ACK - Document addendum notification and content |
|
MDM/ACK - Document edit notification |
|
MDM/ACK - Document edit notification and content |
|
MDM/ACK - Document replacement notification |
|
MDM/ACK - Document replacement notification and content |
|
MDM/ACK - Document cancel notification |
|
QRY/DOC - Document query |
|
VXQ - Query for vaccination record |
|
VXX - Response to vaccination query returning multiple PID matches |
|
VXR - Vaccination record response |
|
VXU - Unsolicited vaccination record update |
|
ORU - Waveform result, unsolicited transmission of requested information |
|
QRF - Waveform result, response to query |
|
PEX - Product experience |
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.
|
Description |
|
Debugging |
|
Production |
|
Training |
|
Description |
|
Archive |
|
Restore from archive |
|
Initial load |
|
Not present (the default, meaning current processing) |
|
Description | |
|
Release 2.0 | September 1988 |
|
Demo 2.0 | October 1988 |
|
Release 2. 1 | March 1990 |
|
Release 2.2 | December 1994 |
|
Release 2.3 | Ballot #1 February 1996, Ballot #2 July 1996, Final Ballot |
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
|
Description |
|
Always |
|
Never |
|
Error/reject conditions only |
|
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. |
Table 0211 - Alternate character
sets
|
Description |
|
The printable 7-bit ASCII character set . (This is the default if this field is omitted) |
|
The printable characters from the ISO 8859/1 Character set |
|
The printable characters from the ISO 8859/2 Character set |
|
The printable characters from the ISO 8859/3 Character set |
|
The printable characters from the ISO 8859/4 Character set |
|
The printable characters from the ISO 8859/5 Character set |
|
The printable characters from the ISO 8859/6 Character set |
|
The printable characters from the ISO 8859/7 Character set |
|
The printable characters from the ISO 8859/8 Character set |
|
The printable characters from the ISO 8859/9 Character set |
|
A subset of ISO2020 used for most Kanjii transmissions |
|
ISO 2022 with escape sequences for Kanjii |
|
Code for Information Exchange |
|
Code for the Japanese Graphic Character set for information interchange |
|
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.
Definition: This field contains the principal language of the message. Codes come from ISO 639.
Figure 2-22. NTE attributes
|
|
|
|
|
|
|
ELEMENT NAME |
|
4 | SI |
|
00096 | Set ID - NTE | ||
|
8 | ID |
|
0105 | 00097 | Source of Comment | |
|
64k | FT |
|
Y | 00098 | Comment |
2.24.15.0 NTE field definitions
Table 0105 - Source of comment
|
Description |
|
Ancillary (filler) department is source of comment |
|
Orderer (placer) is source of comment |
|
Other system is source of comment |
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. |
Figure 3-1. EVN attributes
|
LEN | DT |
|
RP/# | TBL# | ITEM# | ELEMENT NAME |
|
3 | ID |
|
0003 | 00099 | Event Type Code | |
|
26 | TS |
|
00100 | Recorded Date/Time | ||
|
26 | TS |
|
00101 | Date/Time Planned Event | ||
|
3 | IS |
|
0062 | 00102 | Event Reason Code | |
|
60 | XCN |
|
0188 | 00103 | Operator ID | |
|
26 | TS |
|
01278 | Event Occurred |
3.3.1.0 EVN field definitions
User-defined Table 0062 - Event reason
|
Description |
|
Patient request |
|
Physician order |
|
Census management |
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.
Figure 3-2. PID attributes
|
LEN | DT |
|
RP/# | TBL# | ITEM# | ELEMENT NAME |
|
4 | SI |
|
00104 | Set ID - Patient ID | ||
|
20 | CX |
|
00105 | Patient ID (External ID) | ||
|
20 | CX |
|
Y | 00106 | Patient ID (Internal ID) | |
|
20 | CX |
|
Y | 00107 | Alternate Patient ID - PID | |
|
48 | XPN |
|
00108 | Patient Name | ||
|
48 | XPN |
|
00109 | Mother’s Maiden Name | ||
|
26 | TS |
|
00110 | Date/Time of Birth | ||
|
1 | IS |
|
0001 | 00111 | Sex | |
|
48 | XPN |
|
Y | 00112 | Patient Alias | |
|
1 | IS |
|
0005 | 00113 | Race | |
|
106 | XAD |
|
Y | 00114 | Patient Address | |
|
4 | IS |
|
00115 | County Code | ||
|
40 | XTN |
|
Y | 00116 | Phone Number - Home | |
|
40 | XTN |
|
Y | 00117 | Phone Number - Business | |
|
60 | CE |
|
0296 | 00118 | Primary Language | |
|
1 | IS |
|
0002 | 00119 | Marital Status | |
|
3 | IS |
|
0006 | 00120 | Religion | |
|
20 | CX |
|
00121 | Patient Account Number | ||
|
16 | ST |
|
00122 | SSN Number - Patient | ||
|
25 | CM |
|
00123 | Driver's License Number - Patient | ||
|
20 | CX |
|
Y | 00124 | Mother's Identifier | |
|
3 | IS |
|
0189 | 00125 | Ethnic Group | |
|
60 | ST |
|
00126 | Birth Place | ||
|
2 | ID |
|
0136 | 00127 | Multiple Birth Indicator | |
|
2 | NM |
|
00128 | Birth Order | ||
|
4 | IS |
|
Y | 0171 | 00129 | Citizenship |
|
60 | CE |
|
0172 | 00130 | Veterans Military Status | |
|
80 | CE |
|
00739 | Nationality | ||
|
26 | TS |
|
00740 | Patient Death Date and Time | ||
|
1 | ID |
|
0136 | 00741 | Patient Death Indicator |
3.3.2.0 PID field definitions
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.
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.
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.
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.
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.
User-defined Table 0001 - Sex
|
Description |
|
Female |
|
Male |
|
Other |
|
Unknown |
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.
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.
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.
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.
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.
User-defined Table 0002 - Marital status
|
Description |
|
Separated |
|
Divorced |
|
Married |
|
Single |
|
Widowed |
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.
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.
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.
Definition: This field contains the military status assigned to a veteran. Refer to user-defined table 0172 - Veterans military status for suggested values.
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.).
Figure 3-9. PD1 attributes
|
LEN | DT |
|
RP/# | TBL# | ITEM# | ELEMENT NAME |
|
2 | IS |
|
Y | 0223 | 00755 | Living Dependency |
|
2 | IS |
|
0220 | 00742 | Living Arrangement | |
|
90 | XON |
|
Y | 00756 | Patient Primary Facility | |
|
90 | XCN |
|
Y | 00757 | Patient Primary Care Provider Name & ID No. | |
|
2 | IS |
|
0231 | 00745 | Student Indicator | |
|
2 | IS |
|
0295 | 00753 | Handicap | |
|
2 | IS |
|
0315 | 00759 | Living Will | |
|
2 | IS |
|
0316 | 00760 | Organ Donor | |
|
2 | ID |
|
0136 | 00761 | Separate Bill | |
|
2 | CX |
|
Y | 00762 | Duplicate Patient | |
|
1 | IS |
|
0125 | 00743 | Publicity Indicator | |
|
1 | ID |
|
0136 | 01283 | Protection Indicator |
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.
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.
User-defined Table 0315 - Living will
|
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 |
User-defined Table 0316 - Organ donor
|
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 |
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)
Figure 3-3. PV1 attributes
|
LEN | DT |
|
RP/# | TBL# | ITEM# | ELEMENT NAME |
|
4 | SI |
|
00131 | Set ID - PV1 | ||
|
1 | IS |
|
0004 | 00132 | Patient Class | |
|
80 | PL |
|
00133 | Assigned Patient Location | ||
|
2 | IS |
|
0007 | 00134 | Admission Type | |
|
20 | CX |
|
00135 | Preadmit Number | ||
|
80 | PL |
|
00136 | Prior Patient Location | ||
|
60 | XCN |
|
Y | 0010 | 00137 | Attending Doctor |
|
60 | XCN |
|
Y | 0010 | 00138 | Referring Doctor |
|
60 | XCN |
|
Y | 0010 | 00139 | Consulting Doctor |
|
3 | IS |
|
0069 | 00140 | Hospital Service | |
|
80 | PL |
|
00141 | Temporary Location | ||
|
2 | IS |
|
0087 | 00142 | Preadmit Test Indicator | |
|
2 | IS |
|
0092 | 00143 | Readmission Indicator | |
|
3 | IS |
|
0023 | 00144 | Admit Source | |
|
2 | IS |
|
Y | 0009 | 00145 | Ambulatory Status |
|
2 | IS |
|
0099 | 00146 | VIP Indicator | |
|
60 | XCN |
|
Y | 0010 | 00147 | Admitting Doctor |
|
2 | IS |
|
0018 | 00148 | Patient Type | |
|
20 | CX |
|
00149 | Visit Number | ||
|
50 | CM |
|
Y | 0064 | 00150 | Financial Class |
|
2 | IS |
|
0032 | 00151 | Charge Price Indicator | |
|
2 | IS |
|
0045 | 00152 | Courtesy Code | |
|
2 | IS |
|
0046 | 00153 | Credit Rating | |
|
2 | IS |
|
Y | 0044 | 00154 | Contract Code |
|
8 | DT |
|
Y | 00155 | Contract Effective Date | |
|
12 | NM |
|
Y | 00156 | Contract Amount | |
|
3 | NM |
|
Y | 00157 | Contract Period | |
|
2 | IS |
|
0073 | 00158 | Interest Code | |
|
1 | IS |
|
0110 | 00159 | Transfer to Bad Debt Code | |
|
8 | DT |
|
00160 | Transfer to Bad Debt Date | ||
|
10 | IS |
|
0021 | 00161 | Bad Debt Agency Code | |
|
12 | NM |
|
00162 | Bad Debt Transfer Amount | ||
|
12 | NM |
|
00163 | Bad Debt Recovery Amount | ||
|
1 | IS |
|
0111 | 00164 | Delete Account Indicator | |
|
8 | DT |
|
00165 | Delete Account Date | ||
|
3 | IS |
|
0112 | 00166 | Discharge Disposition | |
|
25 | CM |
|
0113 | 00167 | Discharged to Location | |
|
2 | IS |
|
0114 | 00168 | Diet Type | |
|
2 | IS |
|
0115 | 00169 | Servicing Facility | |
|
1 | IS |
|
0116 | 00170 | Bed Status | |
|
2 | IS |
|
0117 | 00171 | Account Status | |
|
80 | PL |
|
00172 | Pending Location | ||
|
80 | PL |
|
00173 | Prior Temporary Location | ||
|
26 | TS |
|
00174 | Admit Date/Time | ||
|
26 | TS |
|
00175 | Discharge Date/Time | ||
|
12 | NM |
|
00176 | Current Patient Balance | ||
|
12 | NM |
|
00177 | Total Charges | ||
|
12 | NM |
|
00178 | Total Adjustments | ||
|
12 | NM |
|
00179 | Total Payments | ||
|
20 | CX |
|
0192 | 00180 | Alternate Visit ID | |
|
1 | IS |
|
0326 | 01226 | Visit Indicator | |
|
60 | XCN |
|
Y | 0010 | 01224 | Other Healthcare Provider |
3.3.3.0 PV1 field definitions
User-defined Table 0004 - Patient class
|
Description |
|
Emergency |
|
Inpatient |
|
Outpatient |
|
Preadmit |
|
Recurring Patient |
|
Obstetrics |
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.
User-defined Table 0007 - Admission type
|
Description |
|
Accident |
|
Emergency |
|
Labor and Delivery |
|
Routine |
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.
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.
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.
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.
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.
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.
User-defined Table 0009 - Ambulatory status
|
Description |
|
No functional limitations |
|
Ambulates with assistive device |
|
Wheelchair/stretcher bound |
|
Comatose; non-responsive |
|
Disoriented |
|
Vision impaired |
|
Hearing impaired |
|
Speech impaired |
|
Non-English speaking |
|
Functional level unknown |
|
Oxygen Therapy |
|
Special equipment (tubes, IVs, catheters) |
|
Amputee |
|
Mastectomy |
|
Paraplegic |
|
Pregnant |
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.
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.
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.
Definition: This field indicates a facility to which the patient was discharged. Refer to user-defined table 0113 - Discharged to location 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.
User-defined Table 0116 - Bed status
|
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.
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.
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.
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.
User-defined Table 0326 - Visit Indicator
|
Description |
|
Account Level (default) |
|
Visit Level |
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.
Figure 3-4. PV2 attributes
|
LEN | DT |
|
RP/# | TBL# | ITEM# | ELEMENT NAME |
|
80 | PL |
|
00181 | Prior Pending Location | ||
|
60 | CE |
|
0129 | 00182 | Accommodation Code | |
|
60 | CE |
|
00183 | Admit Reason | ||
|
60 | CE |
|
00184 | Transfer Reason | ||
|
25 | ST |
|
Y | 00185 | Patient Valuables | |
|
25 | ST |
|
00186 | Patient Valuables Location | ||
|
2 | IS |
|
0130 | 00187 | Visit User Code | |
|
8 | DT |
|
00188 | Expected Admit Date | ||
|
8 | DT |
|
00189 | Expected Discharge Date | ||
|
3 | NM |
|
00711 | Estimated Length of Inpatient Stay | ||
|
3 | NM |
|
00712 | Actual Length of Inpatient Stay | ||
|
50 | ST |
|
00713 | Visit Description | ||
|
90 | XCN |
|
00714 | Referral Source Code | ||
|
8 | DT |
|
00715 | Previous Service Date | ||
|
1 | ID |
|
0136 | 00716 | Employment Illness Related Indicator | |
|
1 | IS |
|
0213 | 00717 | Purge Status Code | |
|
8 | DT |
|
00718 | Purge Status Date | ||
|
2 | IS |
|
0214 | 00719 | Special Program Code | |
|
1 | ID |
|
0136 | 00720 | Retention Indicator | |
|
1 | NM |
|
00721 | Expected Number of Insurance Plans | ||
|
1 | IS |
|
0215 | 00722 | Visit Publicity Code | |
|
1 | ID |
|
0136 | 00723 | Visit Protection Indicator | |
|
90 | XON |
|
Y | 00724 | Clinic Organization Name | |
|
2 | IS |
|
0216 | 00725 | Patient Status Code | |
|
1 | IS |
|
0217 | 00726 | Visit Priority Code | |
|
8 | DT |
|
00727 | Previous Treatment Date | ||
|
2 | IS |
|
0112 | 00728 | Expected Discharge Disposition | |
|
8 | DT |
|
00729 | Signature on File Date | ||
|
8 | DT |
|
00730 | First Similar Illness Date | ||
|
3 | IS |
|
0218 | 00731 | Patient Charge Adjustment Code | |
|
2 | IS |
|
0219 | 00732 | Recurring Service Code | |
|
1 | ID |
|
0136 | 00733 | Billing Media Code | |
|
26 | TS |
|
00734 | Expected Surgery Date & Time | ||
|
2 | ID |
|
0136 | 00735 | Military Partnership Code | |
|
2 | ID |
|
0136 | 00736 | Military Non-Availability Code | |
|
1 | ID |
|
0136 | 00737 | Newborn Baby Indicator | |
|
1 | ID |
|
0136 | 00738 | Baby Detained Indicator |
3.3.4.0 PV2 field definitions
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.
Definition: This field indicates the specific patient accommodations for this visit. Refer to user-defined table 0129 - Accommodation code for suggested values.
Definition: This field contains the short description of the reason for patient admission.
Definition: This field contains the short description of the reason for a patient location change.
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).
User-defined table 0213 - Purge status
|
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. |
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.
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 }
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.
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
|
|
|
|
|
|
|
ELEMENT NAME |
2 | ID |
|
|
0119 | 00215 | Order Control | |
22 | EI |
|
|
00216 | Placer Order Number | ||
22 | EI |
|
|
00217 | Filler Order Number | ||
22 | EI |
|
|
00218 | Placer Group Number | ||
2 | ID |
|
|
0038 | 00219 | Order Status | |
1 | ID |
|
|
0121 | 00220 | Response Flag | |
200 | TQ |
|
|
00221 | Quantity/Timing | ||
200 | CM |
|
|
00222 | Parent | ||
26 | TS |
|
|
00223 | Date/Time of Transaction | ||
120 | XCN |
|
|
00224 | Entered By | ||
120 | XCN |
|
|
00225 | Verified By | ||
120 | XCN |
|
|
00226 | Ordering Provider | ||
80 | PL |
|
|
00227 | Enterer's Location | ||
40 | XTN |
|
|
00228 | Call Back Phone Number | ||
26 | TS |
|
|
00229 | Order Effective Date/Time | ||
200 | CE |
|
|
00230 | Order Control Code Reason | ||
60 | CE |
|
|
00231 | Entering Organization | ||
60 | CE |
|
|
00232 | Entering Device | ||
120 | XCN |
|
|
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
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.
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)
|
|
|
ORC |
|
1st replaced ORC |
OBR |
|
1st replaced order's detail segment |
|
||
ORC |
|
2nd replaced ORC |
OBR |
|
2nd replaced order's detail segment |
|
||
ORC |
|
1st replacement ORC |
OBR |
|
1st replacement order's detail segment |
|
||
ORC |
|
2nd replacement ORC |
OBR |
|
2nd replacement order's detail segment |
|
||
ORC |
|
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)
|
|
|
ORC |
|
1st replaced ORC |
OBR |
|
1st replaced order's detail segment |
|
||
ORC |
|
2nd replaced ORC |
OBR |
|
2nd replaced order's detail segment |
|
||
ORC |
|
1st replacement ORC |
OBR |
|
1st replacement order's detail segment |
|
||
ORC |
|
2nd replacement ORC |
OBR |
|
2nd replacement order's detail segment |
|
||
ORC |
|
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
|
|
Comment |
|
|
1st parent ORC |
|
|
1st child ORC |
|
|
1st child order |
|
|
|
|
|
2nd child ORC |
|
|
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)
|
|
Comment |
|
|
|
|
|
|
|
|
First new order |
|
|
First order segment |
|
|
|
|
|
2nd new order |
|
|
2nd order segment |
|
|
Patient-specific observation, optional in V 2.2 |
|
|
Observation OBR, optional in V 2.2 |
|
|
An observation segment |
|
|
Another observation segment |
|
|
Another observation segment |
|
|
Another observation segment |
|
|
|
|
|
3rd order |
|
|
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. |
|
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
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.
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).
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.
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."
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
|
|
|
Some, but not all, results available |
|
Order was canceled |
|
Order is completed |
|
Order was discontinued |
|
Error, order not found |
|
Order is on hold |
|
In process, unspecified |
|
Order has been replaced |
|
In process, scheduled |
Table 0121 - Response flag
|
|
|
Report exceptions only |
|
Same as E, also Replacement and Parent-Child |
|
Same as R, also other associated segments |
|
Same as D, plus confirmations explicitly |
|
Only the MSA segment is returned |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Definition: This field is the identifier of the physical device (terminal, PC) used to enter the order.
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.
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)."
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. |
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.
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 |
C | 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).
Ex: 2nd component of quantity/timing field:
...^QID&0230,0830,1430,2030^...
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 |
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.
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.
S | = | Stat. | With highest priority |
A | = | ASAP | Fill after S orders |
R | = | Routine. | Default |
P | = | Preop | |
C | = | Callback | |
T | = | 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.
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^D10then the EKG would be done for only three days since the number of repeats (3) defined the earlier stopping time.
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. |
Figure 4-7. Subcomponents of order sequences
|
|
Notes |
|
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 |
|
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. |
|
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. |
|
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 |
||
|
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. |
|
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. |
|
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. |
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.
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).
4.4.11 Examples of quantity/timing usage
3^oncePerform the service at one point in time, e.g., order 3 units of blood to be given once.
1^QHS^X2Perform the service twice at bedtime, e.g., give a unit of blood at bedtime on two sequential nights.
1^C^3DDo a service continuously for 3 days.
1^Q1H^X4^^^^PVCs>10/minPerform an EKG every hour up to a maximum of 4 EKGs, if patient is having more than 10 PVCs per minute.
1^Q2J^^1432Perform a service every Tuesday at 2:32 p.m.
1^^^^198911210800Perform a test before 11/21/89 0800, e.g., some preop laboratory tests.
1^Q3600S^X5^198911051030Perform 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~^^^^^RDraw a blood specimen exactly at 8:00 a.m. on 12/12/1988 and report results routinely.
|1^QPM^^19910415|.Figure 4-9. ODS attributes
|
|
|
|
|
|
|
ELEMENT NAME |
|
1 | ID |
|
0159 | 00269 | Type | |
|
60 | CE |
|
Y/10 | 00270 | Service Period | |
|
60 | CE |
|
Y/20 | 00271 | Diet, Supplement, or Preference Code | |
|
80 | ST |
|
Y/2 | 00272 | Text Instruction |
4.6.1.0 ODS field definitions
Table 0159 - Diet type
|
Description |
|
Diet |
|
Supplement |
|
Preference |
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.
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.
Figure 4-10. ODT attributes
|
LEN | DT |
|
RP/ # | TBL # | ITEM # | ELEMENT NAME |
|
60 | CE |
|
0160 | 00273 | Tray Type | |
|
60 | CE |
|
Y/10 | 00270 | Service Period | |
|
80 | ST |
|
00272 | Text Instruction |
4.6.2.0 ODT field definitions
Definition: This field defines the type of dietary tray. Refer to HL7table 0160 - Tray type for valid entries.
Table 0160 - Tray type
|
Description |
|
Early tray |
|
Late tray |
|
Guest tray |
|
No tray |
|
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.
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.
|PLASTIC SILVERWARE|.
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
|
|
|
|
|
|
|
ELEMENT NAME |
1 | 4 | SI |
|
00237 | Set ID - OBR | ||
2 | 75 | EI |
|
00216 | Placer Order Number | ||
3 | 75 | EI |
|
00217 | Filler Order Number + | ||
4 | 200 | CE |
|
00238 | Universal Service ID | ||
5 | 2 | ID |
|
00239 | Priority | ||
6 | 26 | TS |
|
00240 | Requested Date/time | ||
7 | 26 | TS |
|
00241 | Observation Date/Time # | ||
8 | 26 | TS |
|
00242 | Observation End Date/Time # | ||
9 | 20 | CQ |
|
00243 | Collection Volume * | ||
10 | 60 | XCN |
|
Y | 00244 | Collector Identifier * | |
11 | 1 | ID |
|
0065 | 00245 | Specimen Action Code * | |
12 | 60 | CE |
|
00246 | Danger Code | ||
13 | 300 | ST |
|
00247 | Relevant Clinical Info. | ||
14 | 26 | TS |
|
00248 | Specimen Received Date/Time * | ||
15 | 300 | CM |
|
0070 | 00249 | Specimen Source * | |
16 | 80 | XCN |
|
Y | 00226 | Ordering Provider | |
17 | 40 | XTN |
|
Y/2 | 00250 | Order Callback Phone Number | |
18 | 60 | ST |
|
00251 | Placer field 1 | ||
19 | 60 | ST |
|
00252 | Placer field 2 | ||
20 | 60 | ST |
|
00253 | Filler Field 1 + | ||
21 | 60 | ST |
|
00254 | Filler Field 2 + | ||
22 | 26 | TS |
|
00255 | Results Rpt/Status Chng - Date/Time + | ||
23 | 40 | CM |
|
00256 | Charge to Practice + | ||
24 | 10 | ID |
|
0074 | 00257 | Diagnostic Serv Sect ID | |
25 | 1 | ID |
|
0123 | 00258 | Result Status + | |
26 | 400 | CM |
|
00259 | Parent Result + | ||
27 | 200 | TQ |
|
Y | 00221 | Quantity/Timing | |
28 | 150 | XCN |
|
Y/5 | 00260 | Result Copies To | |
29 | 150 | CM |
|
00261 | Parent | ||
30 | 20 | ID |
|
0124 | 00262 | Transportation Mode | |
31 | 300 | CE |
|
Y | 00263 | Reason for Study | |
32 | 200 | CM |
|
00264 | Principal Result Interpreter + | ||
33 | 200 | CM |
|
Y | 00265 | Assistant Result Interpreter + | |
34 | 200 | CM |
|
Y | 00266 | Technician + | |
35 | 200 | CM |
|
Y | 00267 | Transcriptionist + | |
36 | 26 | TS |
|
00268 | Scheduled Date/Time + | ||
37 | 4 | NM |
|
01028 | Number of Sample Containers * | ||
38 | 60 | CE |
|
Y | 01029 | Transport Logistics of Collected Sample * | |
39 | 200 | CE |
|
Y | 01030 | Collector's Comment * | |
40 | 60 | CE |
|
01031 | Transport Arrangement Responsibility | ||
41 | 30 | ID |
|
0224 | 01032 | Transport Arranged | |
42 | 1 | ID |
|
0225 | 01033 | Escort Required | |
43 | 200 | CE |
|
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.
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.
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.
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.
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.)
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.
Table 0065 - Specimen action code
|
Description |
|
Add ordered tests to the existing specimen |
|
Generated order; reflex order |
|
Lab to obtain specimen from patient |
|
Specimen obtained by service other than Lab |
|
Pending specimen; Order sent prior to delivery |
|
Revised order |
|
Schedule the tests specified below |
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.
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
|
Description |
|
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 |
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.
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.
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).
Table 0074 - Diagnostic service section ID
|
Description |
|
Description |
|
Audiology |
|
OB Ultrasound |
|
Blood gases |
|
Occupational Therapy |
|
Blood bank |
|
Other |
|
Cardiac Ultrasound |
|
Outside Lab |
|
Cardiac catheterization |
|
Pharmacy |
|
CAT scan |
|
Physical Therapy |
|
Chemistry |
|
Physician (Hx. Dx, admission note, etc.l) |
|
Cytopathology |
|
Pulmonary function |
|
Electrocardiac (e.g., EKG, EEC, Holter) |
|
Radiology |
|
Electroneuro (EEG, EMG,EP,PSG) |
|
Radiograph |
|
Hematology |
|
Radiology ultrasound |
|
Bedside ICU Monitoring |
|
Respiratory Care (therapy) |
|
Immunology |
|
Radiation therapy |
|
Laboratory |
|
Serology |
|
Microbiology |
|
Surgidal Pathology |
|
Mycobacteriology |
|
Toxicology |
|
Mycology |
|
Vascular Ultrasound |
|
Nuclear medicine scan |
|
Virology |
|
Nuclear magnetic resonance |
|
Cineradiograph |
|
Nursing service measures |
|
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
|
Description |
|
Description |
|
Order received; specimen not yet received |
|
Results stored; not yet verified |
|
No results available; specimen received, procedure incomplete |
|
Final results; results stored and verified. Can only be changed with a corrected result. |
|
No results available; procedure scheduled, but not done |
|
No results available; Order canceled. |
|
Some, but not all, results available |
|
No order on record for this test. (Used only on queries) |
|
Preliminary: A verified early result is available, final results not yet obtained |
|
No record of this patient. (Used only on queries) |
|
Correction to results |
|
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.
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."
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.
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.
Table 0124 - Transportation mode
|
Description |
|
Cart - patient travels on cart or gurney |
|
The examining device goes to patient's location |
|
Patient walks to diagnostic service |
|
Wheelchair |
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.
Definition: This field identifies the physician or other clinician who interpreted the observation and is responsible for the report content.
Definition: This field identifies the clinical observer who assisted with the interpretation of this study.
Definition: This field identifies the performing technician.
Definition: This field identifies the report transcriber.
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.
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..
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.
Table 0224 - Transport arranged
|
Description |
|
Arranged |
|
Not Arranged |
|
Unknown |
|
Description |
|
Required |
|
Not Required |
|
Unknown |
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.
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.
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
|
|
|
|
|
|
|
ELEMENT NAME |
1 | 10 | SI |
|
00569 | Set ID - OBX | ||
2 | 2 | ID |
|
0125 | 00570 | Value Type | |
3 | 590 | CE |
|
00571 | Observation Identifier | ||
4 | 20 | ST |
|
00572 | Observation Sub-ID | ||
5 | 65536 [ The length of the observation value field is variable, depending upon value type. See OBX-2-value type .] | * |
|
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 |
|
00574 | Units | ||
7 | 10 | ST |
|
00575 | References Range | ||
8 | 5 | ID |
|
Y/5 | 0078 | 00576 | Abnormal Flags |
9 | 5 | NM |
|
00577 | Probability | ||
10 | 2 | ID |
|
Y | 0080 | 00578 | Nature of Abnormal Test |
11 | 1 | ID |
|
0085 | 00579 | Observ Result Status | |
12 | 26 | TS |
|
00580 | Date Last Obs Normal Values | ||
13 | 20 | ST |
|
00581 | User Defined Access Checks | ||
14 | 26 | TS |
|
00582 | Date/Time of the Observation | ||
15 | 60 | CE |
|
00583 | Producer's ID | ||
16 | 80 | XCN |
|
00584 | Responsible Observer | ||
17 | 60 | CE |
|
Y | 00936 | Observation Method |
7.3.2.0 OBX field definitions
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
|
Description |
|
Address |
|
Coded Entry |
|
Coded Element With Formatted Values |
|
Composite ID With Check Digit |
|
Composite ID And Name |
|
Composite Price |
|
Extended Composite ID With Check Digit |
|
Date |
|
Encapsulated Data |
|
Formatted Text (Display) |
|
Money |
|
Numeric |
|
Person Name |
|
Reference Pointer |
|
Structured Numeric |
|
String Data. |
|
Time |
|
Telephone Number |
|
Time Stamp (Date & Time) |
|
Text Data (Display) |
|
Extended Address |
|
Extended Composite Name And Number For Persons |
|
Extended Composite Name And Number For Organizations |
|
Extended Person Number |
|
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.
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.
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 |
|
|
|
|
Sub ID 1st Group |
|
|
|
|
Sub ID 2nd Group |
|
|
|
|
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|. . .
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 HEARTThe 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.
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.
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.
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
|
|
|
|
|
|
|
|||||
ampere | a | kelvin | k | meter | m |
candela | cd | kilogram | kg | mole | mol |
second | s | ||||
|
|||||
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 |
|
|||||
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 |
|
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½ . 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
|
|
|
|
|
|
|
|
|
|||
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 | ||||
|
|
||||
square foot | sqf | dram | dr | ||
square inch | sin | grain | gr (avoir) | ||
square yard | syd | ounce (weight) | oz | ||
pound | lb | ||||
|
|||||
**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
|
|
|
|
|
|
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
|
|
/(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 ´ 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 ´ second) / liter (e.g., mean pulmonary resistance) |
cm_h20/(s.m) | (Centimeters H20 / second) / meter = centimeters H20 / (second ´ 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 ´ Second / centimeter5 (1 dyne = 10 micronewton = 10 un) (e.g., systemic vascular resistance) |
10.un.s/(cm5.m2) | ((Dyne ´ second) / centimeter5) / meter2 = (Dyne ´ second) / (centimeter5 ´ 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 |
g | 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 ´ day) (e.g., mass dose of medication per body weight per day) |
g/(kg.hr) | (Gram / Kilogram) / Hour = gram / (kilogram ´ hour) (e.g., mass dose of medication per body weight per hour) |
g/(8.kg.hr) | (Gram / Kilogram) /8 Hour Shift = gram / (kilogram ´ 8 hour shift) (e.g., mass dose of medication per body weight per 8 hour shift) |
g/(kg.min) | (Gram / Kilogram) / Minute = gram / (kilogram ´ 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 ´ meter / heart
beat
(e.g., ventricular stroke work) |
g.m/((hb).m2) | (Gram ´ meter/ heartbeat)
/ meter2 = (gram ´ meter) / (heartbeat ´
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 ´ 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 ´ 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 ´ 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 ´ day) (e.g., mass dose of medication per patient body weight per day) |
mg/(kg.hr) | (Microgram / Kilogram) / Hour = microgram / (kilogram ´ hours) (e.g., mass dose of medication per patient body weight per hour) |
mg/(8.hr.kg) | (Microgram / Kilogram) / 8 hour
shift = microgram / (kilogram ´ 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 ´ 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 ´ 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 ´ day) (e.g., dose of medication in milliequivalents per patient body weight per day) |
meq/(kg.hr) | (Milliequivalents / Kilogram) / Hour = milliequivalents / (kilogram ´ 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 ´ 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 ´ 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 ´ day) (e.g., mass dose of medication per patient body weight per day) |
mg/(kg.hr) | (Milligram / Kilogram) / Hour = milligram/ (kilogram ´ hour) (e.g., mass dose of medication per patient body weight per hour) |
mg/(8.hr.kg) | (Milligram / Kilogram) /8 Hour Shift = milligram / (kilogram ´ 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 ´ 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 ´ 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 ´ day) (e.g., volume dose of medication or treatment per patient body weight per day) |
mL/(kg.hr) | (Milliliter / Kilogram) / Hour = milliliter / (kilogram ´ 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 ´ 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 ´ 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 ´ 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 ´ day) (e.g., molar dose of medication per patient body weight per day) |
mmol/(kg.hr) | (Millimole / Kilogram) / Hour = millimole / (kilogram ´ hour) (e.g., molar dose of medication per patient body weight per hour) |
mmol/(8.hr.kg) | (Millimole / Kilogram) / 8 Hour Shift = millimole / (kilogram ´ 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 ´ 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 ´ 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 ´ day) (e.g., mass dose of medication per patient body weight per day) |
ng/(kg.hr) | (Nanogram / Kilogram) / Hour = nanogram / (kilogram ´ hour) (e.g., mass dose of medication per patient body weight per hour) |
ng/(8.hr.kg) | (Nanogram / Kilogram) / 8 Hour Shift = nanogram / (kilogram ´ 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 ´ 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 |
_
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.
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
|
Description |
|
Below low normal |
|
Above high normal |
|
Below lower panic limits |
|
Above upper panic limits |
|
Below absolute low-off instrument scale |
|
Above absolute high-off instrument scale |
|
Normal (applies to non-numeric results) |
|
Abnormal (applies to non-numeric results) |
|
Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units) |
|
No range defined, or normal ranges don't apply |
|
Significant change up |
|
Significant change down |
|
Better--use when direction not relevant |
|
Worse--use when direction not relevant |
For microbiology susceptibilities only: | |
|
Susceptible |
|
Resistant |
|
Intermediate |
|
Moderately susceptible |
|
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.
Table 0080 Nature of abnormal testing
|
Description |
|
An age-based population |
|
None - generic normal range |
|
A race-based population |
|
A sex-based population |
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
|
Description |
|
Record coming over is a correction and thus replaces a final result |
|
Deletes the OBX record |
|
Final results; Can only be changed with a corrected result. |
|
Specimen in lab; results pending |
|
Preliminary results |
|
Results entered -- not verified |
|
Partial results |
|
Results cannot be obtained for this observation |
|
Results status change to Final. without retransmitting results already sent as ‘preliminary.’ E.g., radiology changes status from preliminary to final |
|
Post original as wrong, e.g., transmitted for wrong patient |
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.
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.
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.
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.
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.
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.
|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
Table 0159 - Diet type
Value | Description |
D | Diet |
S | Supplement |
P | Preference |
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.
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.
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
Definition: This field defines the type of dietary tray. Refer to HL7 table 0160 - Tray type for valid entries.
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.
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.
|PLASTIC SILVERWARE|.
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
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.
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.
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. |
Definition: This field contains the unit of measure for this item.
Definition: This field contains the unique identifier and descriptive name of the department/location where the item should be delivered.
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."
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
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.
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.
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.