Manual Interface Archiect Ci4100 HL7

ARCHITECT System HL7
Interface Manual
206797-101
Abbott Laboratories © 2012 Abbott Laboratories

Abbott Park, IL 60064
Table of contents
Read me first ..............................................................................Read me first-1

Customer support .................................................................................................Read me first-2
Proprietary statement ...........................................................................................Read me first-3
Disclaimers ...........................................................................................................Read me first-4
ARCHITECT System warranty statement for USA customers only ...................Read me first-5
Agency approvals .................................................................................................Read me first-6
Trademark statement ...........................................................................................Read me first-7
System labeling ....................................................................................................Read me first-8
References .........................................................................................................Read me first-11
Abbott HL7 interface implementation ..............................................................1-1
Low-level protocol ....................................................................................................................1-2
Block format .......................................................................................................................1-2
Network connections .........................................................................................................1-3
Acknowledgement mode ..........................................................................................................1-5
Communication channels and message transactions ............................................................1-6
Message buffering ....................................................................................................................1-8
HL7 interface configuration settings ........................................................................................1-9
Message granularity ...............................................................................................................1-10
Empty and nullified fields .......................................................................................................1-11
Escape sequences .................................................................................................................1-12
Notation for Message Profile Specifications ........................................................................1-13
Notation for Message Structure ......................................................................................1-13
Notation for Message Segments ....................................................................................1-16
Notation for Message Elements ......................................................................................1-17
ARCHITECT HL7 message profiles .................................................................2-1
Unsolicited Order Download Message Profile ........................................................................2-2
OMLÔ33 Message ...........................................................................................................2-3
ORLÔ34 Message ............................................................................................................2-6
Order Query Message Profile ..................................................................................................2-7
QBP^ZOS Message ...........................................................................................................2-8
RSP^ZOS Message ............................................................................................................2-9
Unsolicited Results Upload Message Profile ........................................................................2-12
OUL^R22 Message ..........................................................................................................2-13
ACK^R22 Message ..........................................................................................................2-16
Unsolicited Calibration Results Upload Message Profile .....................................................2-17
OUL^R24 Message ..........................................................................................................2-18
ACK^R24 Message ..........................................................................................................2-19
Automated Equipment Status Message Profile ....................................................................2-21
ESUÛ01 Message ..........................................................................................................2-22
ACKÛ01 Message ..........................................................................................................2-23
ESRÛ02 Message ..........................................................................................................2-24
ACKÛ02 Message ..........................................................................................................2-24
ARCHITECT System HL7 Interface Manual Table of contents-i

(PN 206797-101) January, 2012
Table of contents
Automated Equipment Inventory Message Profile ................................................................2-26

INUÛ05 Message ............................................................................................................2-28
ACKÛ05 Message .......................................................................................................... 2-29
INRÛ06 Message ............................................................................................................2-29
ACKÛ06 Message .......................................................................................................... 2-30
Automated Equipment Notification Message Profile ............................................................ 2-32
EANÛ09 Message .......................................................................................................... 2-33
ACKÛ09 Message .......................................................................................................... 2-33
Automated Equipment Service Update Message Profile ..................................................... 2-35
LSUÛ12 Message ...........................................................................................................2-36
ACKÛ12 Message .......................................................................................................... 2-37
Instrument Configuration Query Message Profile .................................................................2-38
QBP^ZIC Message ...........................................................................................................2-39
RSP^ZIC Message ........................................................................................................... 2-40
Connection Test Message Profile ......................................................................................... 2-42
NMD^N02 Message (ARCHITECT to Informatics) ......................................................... 2-43
ACK^N02 Message (Informatics to ARCHITECT) .......................................................... 2-43
NMD^N02 Message (Informatics to ARCHITECT) ......................................................... 2-44
ACK^N02 Message (ARCHITECT to Informatics) .......................................................... 2-44
ARCHITECT HL7 segment structure ................................................................3-1
EQP Segment ...........................................................................................................................3-3
EQU Segment ...........................................................................................................................3-6
ERR Segment ............................................................................................................................3-9
INV Segment (in Inventory Messages) ..................................................................................3-12
INV Segment (in Result Messages) .......................................................................................3-23
MFE Segment ......................................................................................................................... 3-27
MSA Segment .........................................................................................................................3-29
MSH Segment .........................................................................................................................3-31
NDS Segment ......................................................................................................................... 3-38
NST Segment ..........................................................................................................................3-40
NTE Segment ..........................................................................................................................3-42
OBR Segment ......................................................................................................................... 3-43
OBX Segment (in OUL^R22 specimen result message) ......................................................3-48
OBX Segment (in OUL^R24 calibration result message) .....................................................3-57
ORC Segment .........................................................................................................................3-64
PID Segment ...........................................................................................................................3-66
PV1 Segment ..........................................................................................................................3-70
QAK Segment ......................................................................................................................... 3-74
QPD Segment (in Order Query Messages) ..........................................................................3-76
QPD Segment (in Instrument Configuration Query Messages) ...........................................3-78
RCP Segment ......................................................................................................................... 3-80
SAC Segment ......................................................................................................................... 3-82
SFT Segment ..........................................................................................................................3-86
SID Segment ...........................................................................................................................3-88
SPM Segment .........................................................................................................................3-91
TQ1 Segment ..........................................................................................................................3-95
ZCL Segment .......................................................................................................................... 3-97
Table of contents-ii ARCHITECT System HL7 Interface Manual

(PN 206797-101) January, 2012
Table of contents
ZPS Segment ..........................................................................................................................3-99
ARCHITECT System HL7 Interface Manual Table of contents-iii

(PN 206797-101) January, 2012
Table of contents
NOTES
Table of contents-iv ARCHITECT System HL7 Interface Manual

(PN 206797-101) January, 2012
Read me first
Foreword
This manual specifies HL7-based messaging between the ARCHITECT
Instrument and a Laboratory Informatics solution.
This manual assumes the reader is familiar with programming techniques and is
capable of programming using a high-level language. This manual also assumes
the reader has a good working knowledge of network communications and HL7
as they relate to the computer system that interfaces with the Abbott Instrument
or System.
Refer to the ARCHITECT System Operations Manual for information on
communication setup and instrument communication troubleshooting.
Read me first topics include:
• Customer support, page Read me first-2
• Proprietary statement, page Read me first-3
• Disclaimers, page Read me first-4
• ARCHITECT System warranty statement for USA customers only, page Read
me first-5
• Agency approvals, page Read me first-6
• Trademark statement, page Read me first-7
• System labeling, page Read me first-8
• References, page Read me first-11
ARCHITECT System HL7 Interface Manual Read me first-1

(PN 206797-101) January, 2012
Customer support Read me first
Customer support
If you have any questions regarding your ARCHITECT System, please contact
your local representative or find country-specific contact information on
www.abbottdiagnostics.com.
Read me first-2 ARCHITECT System HL7 Interface Manual

(PN 206797-101) January, 2012
Read me first Proprietary statement
Proprietary statement
The ARCHITECT System software programs and system documentation are
protected by copyright (©1998, 2012 Abbott Laboratories, Abbott Park, Illinois).
All rights are reserved.
The software and manual were developed solely for use with the ARCHITECT
System and for In Vitro diagnostic applications as specified in the operating
instructions.
The information, documents and related graphics published herein (the
"Information") are the sole property of Abbott Laboratories. Permission to use the
Information is granted, provided that
• the copyright notice appears on all copies;
• use of the Information is for operation of ABBOTT products by Abbott
trained personnel or informational use only;
• the Information is not modified in any way; and
• no graphics are used separate from accompanying text.
Each person assumes full responsibility and all risks arising from use of the
Information. The Information is presented "AS IS" and may include technical
inaccuracies or typographical errors. Abbott Laboratories reserves the right to
make additions, deletions, or modifications to the Information at any time without
any prior notification.

(PN 206797-101) January, 2012
Disclaimers Read me first
Disclaimers
All samples (printouts, graphics, displays, screens, etc.) are for information and
illustration purposes only and shall not be used for clinical or maintenance
evaluations. Data shown in sample printouts and screens do not reflect actual
patient names or test results.
The Information was developed to be used by Abbott Laboratories trained
personnel, by other persons knowledgeable or experienced with the operation
and service of the product identified, or under the direct supervision and with
cooperation from Abbott Laboratories technical sales or service representatives.
In no event shall Abbott Laboratories or its affiliates be liable for any damages
or losses incurred in connection with or arising from the use of the Information
by persons not fully trained by Abbott Laboratories. This limitation shall not apply
to those persons knowledgeable or experienced with the operation and service
of the product identified, or under the direct supervision and with cooperation
from Abbott Laboratories technical sales or service representatives.
No confidential relationship shall be established in the event that any user of the
Information should make any oral, written or electronic response to Abbott
Laboratories (such as feedback, questions, comments, suggestions, ideas, etc.).
Such response and any information submitted therewith shall be considered non-
confidential, and Abbott shall be free to reproduce, publish or otherwise use
such information for any purposes whatsoever including, without limitation, the
research, development, manufacture, service, use, or sale of products
incorporating such information. The sender of any information to Abbott is fully
responsible for its content, including its truthfulness and accuracy and its non-
infringement of any other person's proprietary rights.
Abbott Laboratories is not engaged in rendering medical advice or services.
Updates to the Information may be provided in either paper or electronic format.
Always refer to the latest documents for the most current information.
Incremental manual updates may cause the master Table of contents or master
Index page numbering to change.
No part of this media may be reproduced, stored, retrieved, or transmitted in any
form or by any means without the prior written permission of Abbott Laboratories.

(PN 206797-101) January, 2012
Read me first ARCHITECT System warranty statement for USA
customers only
ARCHITECT System warranty statement for USA

customers only
Abbott Laboratories warrants new instruments sold by Abbott Diagnostics
Division to be free from defects in workmanship and materials during normal use
by the original purchaser. This warranty shall continue for a period of one year
from the date of shipment to the original purchaser, or until title is transferred
from the original purchaser, whichever occurs first (the "Warranty Period").
If any defects occur during the Warranty period, contact your Abbott Customer
Service Representative immediately, and be prepared to furnish information
including the serial number, the model number, and pertinent details concerning
the defect.
This Warranty does not cover defects or malfunctions which: (1) are not
reported to Abbott during the Warranty Period and within one week of
occurrence; (2) result from chemical decomposition or corrosion; (3) are caused
primarily by failure to comply with any requirements or instruction contained in
the applicable Abbott Operations Manual; or (4) result from maintenance, repair,
or modification, performed without Abbott's authorization.
Abbott's liability for all matters arising from the supply, installation, use, repair,
and maintenance of the instrument, whether arising under this Warranty or
otherwise, shall be limited solely to the repair or (at Abbott's sole discretion)
replacement of the instrument or of components thereof. Replaced parts shall
become the property of Abbott Laboratories. In no event shall Abbott be liable
for injuries sustained by third parties.
The ICT module Warranty is 20,000 samples or three months post-installation,
whichever occurs first.
The cuvette warranty is one year post-installation.
EXCEPT AS EXPRESSLY PROVIDED ABOVE, ABBOTT LABORATORIES
HEREBY DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, WHETHER
EXPRESS OR IMPLIED, CREATED BY LAW, CONTRACT OR OTHERWISE,
INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT. IN
NO EVENT SHALL ABBOTT LABORATORIES BE LIABLE FOR ANY INDIRECT,
SPECIAL, PUNITIVE, CONSEQUENTIAL OR INCIDENTAL DAMAGES
(INCLUDING WITHOUT LIMITATION LOST REVENUES, PROFITS, OR DATA)
ARISING FROM OR IN CONNECTION WITH THE USE OF THE INSTRUMENT,
REGARDLESS OF WHETHER ABBOTT LABORATORIES HAS BEEN ADVISED
AS TO THE POSSIBILITY OF SUCH DAMAGES.

(PN 206797-101) January, 2012
Agency approvals Read me first
Agency approvals
The ARCHITECT System has been tested and found to comply with the following
agency standards:
• UL 61010A-1 or UL61010-1 Safety Requirements for Electrical Equipment
for Measurement, Control, and Laboratory Use - Part 1 General
Requirements
• CAN/CSA-C22.2 No. 1010.1 or CAN/CSA-C22.2 No. 61010.1 Safety
Requirements for Electrical Equipment for Measurement, Control, and
Laboratory Use - Part 1 General Requirements
• 21CFR Part 1040.10: Performance Standards for Light Emitting Products
• IEC 60825-1: Safety of Laser Products (Class 1 Laser Products)
• Directive 2002/96/EC: Waste Electrical and Electronic Equipment
• CE Marking
In Vitro Diagnostic Directive 98/79/EC

Legal Manufacturer Abbott Laboratories
Diagnostics Division
Abbott Park, IL 60064 USA
Authorized Representative in the European Abbott
Community Max-Planck-Ring 2
65205 Wiesbaden
Germany
+49-6122-580

(PN 206797-101) January, 2012
Read me first Trademark statement
Trademark statement
AbbottLink, ARCHITECT, i1000SR, i2000, i2000SR, i4000SR, c4000, c8000,
c16000, ci4100, ci8200, ci16200, Chemiflex, AxSYM, and MasterCheck are
registered trademarks of Abbott Laboratories in various jurisdictions.
i4000, i6000, i8000, c System, i System, ARCHITECT ARM, FlexRate, and
SmartWash are trademarks of Abbott Laboratories in various jurisdictions.
All Abbott Laboratories product names and trademarks are owned by or licensed
to Abbott Laboratories, its subsidiaries or affiliates. No use of any Abbott
trademark, trade name, trade dress, or product name may be made without the
prior written authorization of Abbott Laboratories, except to identify the product
or services of Abbott Laboratories. All other trademarks, brands, product names,
and trade names are the property of their respective companies. All rights
reserved.
Except as permitted above, no license or right, express or implied, is granted to
any person under any patent, trademark, or other proprietary right of Abbott
Laboratories.
The following U.S. Patents are relevant to the ARCHITECT c System or its
components.
4,533,457 4,619,739 4,647,362 4,678,755
4,797,192 5,025,389 5,413,770
The following U.S. Patents are relevant to ARCHITECT i Systems or

components.
5,468,646 5,536,049 5,543,524 5,545,739
5,565,570 5,669,819 5,682,662 5,723,795
5,795,784 Des. 397,938 Des. 401,699 Des. 401,697
Des. 401,700 5,783,699 5,856,194 5,859,429
Des. 404,829 Des. 406,901 5,915,282 5,915,583
5,938,120 Des. 413,539 5,965,828 6,022,746
6,063,634 6,150,113 6,153,377 6,162,645
6,413,780 6,562,298 6,588,625
There are other such patents and patent applications in the United States and
worldwide.

(PN 206797-101) January, 2012
System labeling Read me first
System labeling
The symbols in the following table are used on ARCHITECT System labeling.
Key to symbols used on labeling
Label Description
Authorized Representative in the European Community
Legal manufacturer
NOTE: A new presentation of the Legal manufacturer
label will be phased into the system labeling in a future
revision.
In Vitro Diagnostic Medical Device
Manufacturer
Date of manufacture
Serial number
Alternating current
Laser
Caution, risk of electrical shock
Electrical and electronic equipment waste
Temperature limitation
Use by/Expiration date
Consult operating instructions
Caution, consult accompanying documents
Batch code/Lot number

(PN 206797-101) January, 2012
Read me first System labeling
Label Description
Quantity
Unit
Biological risks
Biohazard
Caution, hot surface
Assay disk
Version
Conventional units
Standard international unit
Sample cups
ICT Cleaning Fluid
ICT Lyophilized Cleaning Solution
Water Bath Additive
Pre-Trigger Solution
Trigger Solution
Concentrated Wash Buffer
Wash buffer
Reaction vessels
Septum
Replacement caps
Multi-Assay Manual Diluent

(PN 206797-101) January, 2012
System labeling Read me first
Label Description
Catalog number/List number
Acid Wash
Alkaline Wash
ICT Reference Solution
Detergent A
Detergent B

(PN 206797-101) January, 2012
Read me first References
References
This guide is based on the following documents:
• HL7 version 2.5.1 Messaging Standard
• HL7 version 2.3.1 Implementation Support Guide, Appendix C
• IHE Laboratory Technical Framework, Volume 2 - Revision 3.0

(PN 206797-101) January, 2012
References Read me first
NOTES

(PN 206797-101) January, 2012
Section 1 Abbott HL7 interface implementation
Abbott HL7 interface implementation
For more information about instrument-specific communication setup and
instrument communication troubleshooting, refer to the appropriate Abbott
instrument operations manual.
The following topics explain Abbott HL7 implementation:
• Low-level protocol, page 1-2
• Acknowledgement mode, page 1-5
• Communication channels and message transactions, page 1-6
• Message buffering, page 1-8
• HL7 interface configuration settings, page 1-9
• Message granularity, page 1-10
• Empty and nullified fields, page 1-11
• Escape sequences, page 1-12
• Notation for Message Profile Specifications, page 1-13
ARCHITECT System HL7 Interface Manual Section 1-1

(PN 206797-101) January, 2012
Low-level protocol Section 1
Low-level protocol
ARCHITECT uses the Minimal Lower Layer Protocol (MLLP), as defined in
Appendix C, section C.4, of the HL7 v2.3.1 Implementation Support Guide. The
protocol assumes operation in a networked environment, such as TCP/IP, in
which most details of error detection and correction are handled by the lower
levels of the network protocol and do not require supplementation.
This document does not fully specify the HL7 MLLP but provides only some
important characteristics.
The following topics describe in more detail the MLLP implementation as it
relates with ARCHITECT:
• Block format, page 1-2
• Network connections, page 1-3
Block format
The HL7 MLLP uses a single byte to signal the start of a message and two bytes
to signal the end of a message. No other characters or lower-level header or
trailer information are added to the HL7 message.
HL7 messages are enclosed by special characters to form a block.
There are no NAK blocks. Higher-level acknowledgment messages are used to
signal transmission errors.
The block format is as follows:
<SB>dddd><EB><CR>
where:
<SB> Start Block character (1 byte) ASCII <VT>, for example, <0x0B>.
This should not be confused with the ASCII characters SOH or STX.
dddd Data (variable number of bytes)

This is the HL7 data content of the block. The data can contain any single-byte
values greater than 0x1F and the ASCII carriage return character, <CR>.
<EB> End Block character (1 byte) ASCII <FS>, for example, <0x1C>.
This should not be confused with the ASCII characters ETX or EOT.
<CR> Carriage Return (1 byte) ASCII carriage return character, for example, <0x0D>.
Section 1-2 ARCHITECT System HL7 Interface Manual

(PN 206797-101) January, 2012
Section 1 Low-level protocol
Network connections
HL7 messaging between the Instrument and Informatics solution relies on a
virtual circuit, or connection, for reliable, sequenced, error-free, full-duplex data
transmission in a TCP/IP environment. One entity initiates a call operation, and
the other entity performs a listen operation. Each entity identifies the other by IP
address and port. The call transmission is an active connection, and the entity
initiating a call is considered the client in the transaction. The server in the
transaction listens, representing a passive connection. Once the calling entity
has connected to the listening entity, the two-way connection is established, and
the entities may exchange data.
When the data exchange is complete, either side may perform a disconnect
operation, or the connection may remain open for future data exchange.
Normally, one system initiates a message exchange (client) by performing a call
operation. The responding system (server) performs the listen operation.
However, based on network security restrictions of the deployed environment,
only certain systems may be allowed to activate connections (active) while other
systems may only listen for connections (passive).
ARCHITECT supports the following network connection types.
Active persistent connections
The following steps are performed by the ARCHITECT Instrument for an active
persistent network connection:
1. At startup, attempt to connect to the configured IP address and port of the
listening or passive system.
2. If connection is unsuccessful, wait for a short time period and retry the
connection. Retry until retries are exhausted, until the connection is disabled
by operator request, or until the Instrument is shut down.
3. Keep the connection open at all times, even if no more messages remain to
be exchanged.
4. If a disconnection is detected outside of a data exchange, retry the
connection.
5. If a disconnection is detected during a data exchange (for example, while
waiting for a response), a message transmission error is indicated, and the
ARCHITECT disables the HL7 connection.
Active transient connections
The following steps are performed by the ARCHITECT Instrument for an active
transient network connection:
1. Attempt to establish a connection only when a message is ready to be sent.
2. When a message is ready to be sent, attempt to connect to the configured
IP address and port of the listening or passive system.

(PN 206797-101) January, 2012
Low-level protocol Section 1
3. If connection is unsuccessful, wait a short time period and retry the

connection. Retry until retries are exhausted, until the connection is disabled
by operator request, or until the Instrument is shut down.
4. Keep the connection open only if more messages remain to be sent.
Otherwise, close the connection.
Passive connections
The following steps are performed by the ARCHITECT Instrument for a passive
network connection:
1. Open the configured port at startup and passively listen for a connection.
2. Wait for a call to open a port, then leave the connection open at all times.
Do not disconnect.
3. If a disconnection is detected, automatically reopen the port and listen for a
new connection.

(PN 206797-101) January, 2012
Section 1 Acknowledgement mode
Acknowledgement mode
HL7 v2 specifies two major message acknowledgment modes, original and
enhanced. As specified by IHE, the ARCHITECT interface uses the HL7 original
acknowledgement mode, as defined in HL7 v2.5.1 chapter 2, section 2.9.2. The
HL7 enhanced acknowledgement mode is not supported.
These original mode acknowledgements are application-level acknowledgements
(not transport acknowledgements), and must be generated by the receiving
application (ARCHITECT or Informatics) after it has parsed a message and
processed its content. The receiving application automatically generates
application-level acknowledgement messages without human approval of the
received message content.

(PN 206797-101) January, 2012
Communication channels and message transactions Section 1
Communication channels and message

transactions
An HL7 message transaction is initiated by an application in response to a
trigger event. For example, a result produced and released on an Instrument can
trigger the initiation of an Unsolicited Results Upload message transaction. The
initiating application, or client, sends a message over a communication channel.
The receiving application, or server, replies on the same channel with an
application-level acknowledgment message.
The application that initiates an event-triggered transaction is acting as a client
(sender). The application that responds with an acknowledgement message is
acting as a server (receiver).
The Instrument supports two separate network channels:
• Client channel - for application-level transactions that are initiated by the
Instrument
• Server channel - for application-level transactions that are responded to by
the Instrument
Channel use of network connections
Each communication channel uses a Minimal Lower Layer Protocol (MLLP) low-
level network connection to send and receive the messages.The connection
used by the client and server communication channels can be configured, based
on the deployed network security restrictions, as either an active-persistent,
active-transient, or passive connection.
From a transactional viewpoint, a MLLP network connection is unidirectional.
Event-triggered messages flow in one direction. Acknowledgement messages
related to those event-triggered messages flow in the other direction.
The acknowledgement message to an event-triggered message is sent
immediately to the sender on the same MLLP connection that carried the event-
triggered message. The receiver of an event-triggered message should assume
that the sending application is blocking and send an application-level
acknowledgement as soon as possible.
If the MLLP connection is broken while the sending application is waiting for an
acknowledgement, the sending application initiates a new MLLP connection and
resends the message, using the same message ID value in MSH-10 Message
Control ID.
The following diagram shows the relationship between client/server channels,
message transactions, and MLLP network connections.

(PN 206797-101) January, 2012
Section 1 Communication channels and message transactions
Client transactions
The Instrument acts as a client (sender) for the following message transactions:
• Order Query
• Unsolicited Specimen Results Upload (Patient, QC, Calibrator)
• Unsolicited Calibration Results Upload
• Automated Equipment Status (State) Update
• Automated Equipment Inventory Update
• Automated Equipment Notification
• Automated Equipment Service (Maintenance) Event Update
• Connection Test
Server transactions
The Instrument acts as a server (receiver) for the following message

transactions:
• Unsolicited Order Download (Patient and QC)
• Automated Equipment Status (State) Request
• Automated Equipment Inventory Request
• Instrument Configuration Query
• Connection Test

(PN 206797-101) January, 2012
Message buffering Section 1
Message buffering
Message buffering is supported as necessary, based on message handling
behavior.
Client channel
The Client Channel initiates transactions for the Order Query and other
messages triggered by the ARCHITECT Instrument, such as Results. Message
buffering requirements are based on the application behavior associated with the
various message transactions.
The ARCHITECT Instrument issues only one Order Query message transaction
at a time, completing an existing Order Query transaction prior to initiating a new
request. Based on sample processing requirements, an Order Query message
takes priority over any other pending client message transaction but will not
interrupt a message transaction that is in progress (for example, waiting for an
acknowledgement to a results upload message).
For other client message transactions, such as Unsolicited Result Upload, the
ARCHITECT supports the queuing of multiple messages that can be processed
in the background. For example, the operator can request that results for N
samples be sent to the host (Informatics) system. This will result in N result
messages being queued for transmission. Message buffering is also used when
a network connection to the Informatics system cannot be established. In this
case, the message buffer operates as first-in-first-out queue that prioritizes new
Order Query messages. If the queue reaches its maximum capacity, no more
messages are queued for transmission. A buffer-full indication is generated, and
the ARCHITECT disables the HL7 connection.
The Client Channel can be established as an active-transient or passive
connection.
Server channel
The ARCHITECT server channel processes one message transaction at a time.

After the server channel receives and parses a message, it passes the message
to the ARCHITECT application layer for processing. After the application
response from ARCHITECT application layer (or a response time-out, if
configured and response time is exceeded) the server channel builds and sends
the acknowledgement message. It then waits for the next incoming message
transaction. Based on this behavior, no message buffering is required for the
server channel.
The Server Channel can be established only as a passive or active-persistent
connection.

(PN 206797-101) January, 2012
Section 1 HL7 interface configuration settings
HL7 interface configuration settings

Refer to the following topics in the ARCHITECT System Operations Manual for
information on communication setup:
• Configure host interface settings
• Configure the TCP/IP port settings
To test the HL7-TCP/IP settings during setup or when errors occur refer to the
ARCHITECT System Operations Manual topic, Verify HL7-TCP/IP
communications.
For troubleshooting information for error codes associated with the host
interface, refer to the ARCHITECT System Operations Manual.

(PN 206797-101) January, 2012
Message granularity Section 1
Message granularity
Per IHE, a message is generated from a trigger event. Therefore, a message is
related to one business object.
IHE states that Query, Order, and Result messages are related to a single Work
Order Step (WOS), which is defined as one or more tests on a single specimen.
Each Work Order Step has a unique ID, assigned by the LIS or middleware, that
is different from the sample ID (sample container barcode). ARCHITECT does
not currently support the concept of a Work Order Step ID, but it does support
the concept of a sample ID. Therefore, the message granularity for Query,
Order, and Result message profiles is related to a single sample (specimen).

(PN 206797-101) January, 2012
Section 1 Empty and nullified fields
Empty and nullified fields

Per IHE and the HL7 standard, if the value of a field is not present, the receiver
does not change corresponding data in its database. However, if the sender
defines the field value to be the explicit NULL value (represented with two
double quotes ""), any values for that field are removed from the receiver's
database.

(PN 206797-101) January, 2012
Escape sequences Section 1
Escape sequences
HL7 v2.5.1 section 2.7 specifies escape sequences that are supported in fields
of ST, TX, and FT data types. ARCHITECT supports the following escape
sequences for these data types:
\F\ Field separator
\S\ Component separator
\T\ Subcomponent separator
\R\ Repetition separator
\E\ Escape separator
\Xdddd...\ Hexadecimal data - consecutive pairs of hexadecimal digits representing 8-

bit binary values. Used to encode text control code byte values less than
0x20 in UTF-8 (for example, \X09\ = TAB)
\br.\ Begin new output line. Sets the horizontal position to the current left margin
and increments the vertical position by 1.

(PN 206797-101) January, 2012
Section 1 Notation for Message Profile Specifications
Notation for Message Profile Specifications

This Message Profile Specification model documents implementable versions of
HL7 message profiles and supports conformance testing of the implementations.
The message profiles in this document are described using HL7 constrainable
message profiles, HL7 v2.5.1 section 2.12.6. The notation is specifically
described in the following sections:
• Notation for Message Structure, page 1-13
• Notation for Message Segments, page 1-16
• Notation for Message Elements, page 1-17
Notation for Message Structure

Message structure defines the sequence, nesting, and requirements for
segments that may occur in a Message Profile. The following table provides an
example of the initial segments of a message-structure specification, with each
component described in sections that follow:
Table 1.1: Example: Initial segments of a Message Structure
Segment ID Meaning Usage Cardinality

MSH Message Header R [1..1]
[ --- PATIENT begin RE [0..1]
PID Patient Identification R [1..1]
] --- PATIENT end - -
{ --- TEST ORDER begin R [1..*]
OBR Observation Request R [1..1]
OBX Observation related to OBR C [0..*]
} --- TEST ORDER end - -
Segments and segment groups
A segment is a logical grouping of data elements. Segments of a message may

be required or optional. They may occur only once in a message or they may be
allowed to repeat. The Segment ID identifies each HL7 segment that may appear
in the message. The Segment IDs correspond to the IDs used in the standard
HL7 documentation.
Two or more segments may be organized as a logical unit called a segment
group. A segment group may be required or optional and may or may not repeat.
As of HL7 v2.5, the first segment in a newly defined segment group is required,
to ensure that un-parsable messages are not inadvertently defined.

(PN 206797-101) January, 2012
Notation for Message Profile Specifications Section 1
Segment sequence and nesting
The message structure specification for a message type determines the allowed
sequence of segments in a message instance. Braces, {...}, surrounding a group
of segments indicate one or more repetitions of the enclosed group may occur.
Brackets, [...], surrounding a group of segments indicates that the enclosed
group is optional. If a group of segments is optional and may repeat, the group
is enclosed in brackets and braces, [ {...} ].
Usage
Usage refers to whether individual segments and groups of segments are

required or optional. The following designations, from HL7 v2.5.1, Section 2.12,
are used in message structures:
Table 1.2: Example: Initial segments of a Message Structure
Value Description Comment

R Required A conforming sending application populates all R
elements with a non-empty value.
A conforming receiving application processes (saves,
prints, archives) or ignores the information conveyed by
required elements. A conforming receiving application
does not raise an error due to the presence of a required
element, but may raise an error due to the absence of a
required element. Refer to detailed element descriptions
to determine how the Instrument, as a receiver, handles
elements (process, ignore, raise error if missing).
Handling behavior may vary by element. Unless otherwise
specified, the default behavior is to ignore an element.
RE Required but may The element may be missing from the message but is
be empty sent by the sending application if there is relevant data to
report. A conforming sending application is capable of
providing all RE elements. If the conforming sending
application knows the required values for the element,
then it sends that element. If the conforming sending
application does not know the required values, the
conforming sending application omits the element.
Receiving applications process (save, print, archive) or
ignore data contained in the element, but successfully
process the message if the element is omitted. No error
message is generated because the element is missing.
Refer to detailed element descriptions to determine how
the Instrument, as a receiver, handles elements (process,
ignore). Unless otherwise specified, the default behavior
is to ignore an element.
C Conditional This usage has an associated condition predicate.
If the predicate is satisfied:

(PN 206797-101) January, 2012

A conforming sending application always sends the
element. A conforming receiving application processes or
ignores data in the element and may raise an error if the
element is not present.
If the predicate is not satisfied:
A conforming sending application does not send the
element. A conforming receiving application does not
raise an error if the condition predicate is false and the
element is not present, but it may raise an error if the
element is present.
ignore, raise error). Unless otherwise specified, the
default behavior is to ignore an element.
CE Conditional but This usage has an associated condition predicate.
may be empty If the predicate is satisfied:
If the conforming sending application knows the required
values for the element, then the application sends the
element. If the conforming sending application does not
know the values required for this element, then the
element is omitted. The conforming sending application is
capable of knowing the element (when the predicate is
true) for all CE elements.
If the element is present, the conforming receiving
application processes (displays, prints, archives) or
ignores the values of that element. If the element is not
present, the conforming receiving application does not
raise an error due to the presence or absence of the
element.
If the predicate is not satisfied:
The conforming sending application does not populate the
element.
The conforming receiving application may raise an
application error if the element is present.
ignore, raise error). Unless otherwise specified, the
default behavior is to ignore an element.
X Not supported For conforming sending applications, the element is not
sent.
Conforming receiving applications may ignore the element
if it is sent or may raise an application error.
ignore, raise error if present). Unless otherwise specified,
the default behavior is to ignore an element.

(PN 206797-101) January, 2012
Condition predicate
If the usage code of an element is C or CE, then a condition predicate is

associated with this element, to identify the conditions under which the element
is required or allowed to be present. The predicate is testable and based on
other values within the message. The predicate may be expressed as a
mathematical expression or in text and may use operators such as equivalence,
logical AND, logical OR and NOT. Both conforming sending and receiving
applications evaluate the predicate. When the usage code is not C or CE, the
conditional predicate is not valued.
Cardinality
Cardinality defines the number of instances of an element in the message type.

A range is provided, with the first value designating the minimum number and the
second value designating the maximum number. A relationship exists between
Usage and Cardinality values:
• Usage of R - minimum Cardinality of 1
• Usage of RE, C, and CE - minimum Cardinality of 0
• Usage of X - minimum and maximum Cardinality of 0
NOTE: The concept of a repeating element is expressed by a cardinality range

with a second value that is greater than 1. For example, a cardinality range of
[1..5] indicates that the element may repeat up to 4 times for a total of 5
instances. A cardinality range of [1..*] indicates that there is no limit to the
number of repetitions of the element.
Notation for Message Segments

For each segment that may appear in a message profile, a specification lists the
allowed elements within that segment and the allowed values of those elements.
The following table provides an example of a segment specification:
SEQ LEN DT Send usage Send card. Rcv. usage Rcv. card. Element name
1 2 ST R [1..1] R [1..1] Field separator
2 4 ST R [1..1] R [1..1] Encoding characters
3 227 HD R [1..1] R [1..1] Sending application
... ... ... ... ... ... ... ...
SEQ The ordinal position (sequence) of the element in the segment.

LEN The maximum element length. For repeating elements, this field specifies the
maximum length of each value, so an element with multiple repeating values
may exceed the specified length. For each value, however, the maximum length
is calculated to include the component and subcomponent separators.

(PN 206797-101) January, 2012
NOTE: The HL7 standard allows conformance profiles to specify element

lengths in excess of those indicated in the message standard. HL7 states that
element length changes can be handled in a conformance profile without
rendering the implementation nonconformant with HL7. For more information,
see HL7 v2.5.1, section 2.5.3.2.
DT The HL7 data type used for the value of the element. Information about the data
type is usually provided in the detailed description of each element. For more
information, see HL7 v2.5.1, Chapter 2a.
Send Usage Use of this field with the Instrument as sender. For usage codes, see Usage,
page 1-14.
Send Card. Minimum and maximum number of occurrences of the field in a segment with
the Instrument as sender. For more information, see Cardinality, page 1-16.
Rcv. Usage Use of this field with the Instrument as receiver. For usage codes, see Usage,
page 1-14.
Rcv. Card. Minimum and maximum number of occurrences of the field in a segment with
the Instrument as receiver. For more information, see Cardinality, page 1-16.
Element name Name of the field. This is for reference purposes only and does not appear in
the message data.
Notation for Message Elements

For each element that may be populated in a message, a narrative section
further describes the element. These descriptions include the standard HL7
definition of the element as well as the specific rules for populating the element
in conformance with this specification.
The descriptions may also include descriptions of unique rules related to the
Instrument as a sender or receiver of an element, as well as one or more
sample values.
The following table shows an example of an HL7 Component Table for a
message element. The values in the Usage column have the same meaning as
defined for segment fields.
Table 1.3: Example: Component table

Component/Sub-component Usage
identifier (ST) R
text (ST) RE
name of coding system (IS) RE
alternate identifier (ST) X
alternate text (ST) X
name of alternate coding system (IS) X
NOTE: In many cases, the specification for an element is more constraining than
the HL7 definition, to better support interoperability. For example, this

(PN 206797-101) January, 2012
specification may require that a certain coding system be used in an element or

may prohibit certain sub-parts of an element from being populated, whereas the
HL7 definition allows any coding system to be used or any sub-parts to be
populated. When this specification and the HL7 definition differ, this specification
takes precedence.

(PN 206797-101) January, 2012
Section 2 ARCHITECT HL7 message profiles
ARCHITECT HL7 message profiles
The following topics define message profiles as implemented by Abbott:
• Unsolicited Order Download Message Profile, page 2-2
Profile of the transaction that enables the Informatics to issue a new order to
the Instrument or to cancel a previously sent order.
• Order Query Message Profile, page 2-7
Profile of the transaction that enables the Instrument to query the Informatics
for orders against a specimen.
• Unsolicited Results Upload Message Profile, page 2-12
Profile of the transaction that enables the Instrument to send test results for
patient, control, and calibrator specimens.
• Unsolicited Calibration Results Upload Message Profile, page 2-17
Profile of the transaction used by the Instrument to send assay calibration
curve results.
• Automated Equipment Status Message Profile, page 2-21
Profile of the transactions used by the Instrument to send information about
the current status (state) of the Instrument module(s).
• Automated Equipment Inventory Message Profile, page 2-26
Profile of the transactions used by the Instrument to send information about
on-board inventory items used by the Instrument to produce assay results.
• Automated Equipment Notification Message Profile, page 2-32
Profile of the transaction used by the Instrument to send notification events
that have occurred on the Instrument.
• Automated Equipment Service Update Message Profile, page 2-35
Profile of the transaction used by the Instrument to send maintenance events
that have occurred on the Instrument.
• Instrument Configuration Query Message Profile, page 2-38
Profile of the transaction used by Informatics to query the Instrument to
obtain configuration settings.
• Connection Test Message Profile, page 2-42
Profile of the transaction used to test the connection between two
applications. The Instrument can both initiate and respond to a connection
test message.

(PN 206797-101) January, 2012
Unsolicited Order Download Message Profile Section 2
Unsolicited Order Download Message Profile

This transaction is used between an Informatics solution and an Instrument
working in download mode. It enables the Informatics to issue a new order to the
Instrument or to cancel or modify a previously sent order. Modification may also
be achieved by canceling a previously sent order and sending a new one.
Interaction diagram
Interaction model
Trigger event Any change to an order that the Informatics has allocated or
scheduled on the Instrument.
Changes include submission of new orders, cancellations, and
updates, where multiple orders are associated with a single sample.
The Informatics has selected one or more Instruments capable of
running the tests on the sample and must inform the Instrument of
these orders.
This profile also covers the case where a previously downloaded
order must be cancelled or modified on the Instrument. To effect an
order modification, the combination of an order cancel and a new
order must be used.

(PN 206797-101) January, 2012
Section 2 Unsolicited Order Download Message Profile
Direction Informatics > Instrument
Application roles Informatics (sender): translates received orders into tests that the
Instrument must run on samples; downloads new, modified, and
canceled orders to the appropriate Instrument.
Instrument (receiver): performs tests (analysis) on specimens.
Receiver Acknowledge order messages and accept or reject orders.

responsibilities
Related information...
• OMLÔ33 Message, page 2-3
• ORLÔ34 Message, page 2-6
OMLÔ33 Message
This message is a laboratory order for multiple orders related to a single
specimen. The following table details the structure of this message.
Table 2.1: OMLÔ33 message structure

[ NTE ] Notes and comments (for Patient) RE [0..1]
[ PV1 ] Patient Visit RE [0..1]
] --- PATIENT end
{ --- SPECIMEN begin R [1..1]
SPM Specimen R [1..1]
[ SAC ] Specimen Container RE [0..1]
{ --- ORDER begin R [1..*]
ORC Common Order (for one test/battery) R [1..1]
[ TQ1 ] Timing Quantity RE [0..1]
--- OBSERVATION REQUEST begin R [1..1]
[ NTE ] Notes and comments (for test order) RE [0..1]
--- OBSERVATION REQUEST end
} --- ORDER end
} --- SPECIMEN end

(PN 206797-101) January, 2012
Notes on message structure
The following notes apply to OMLÔ33 message structure:

1. The PATIENT segment group is not included for QC orders. For patient
sample orders, it is included only if patient information is available to send.
2. The SAC segment carries the dilution factor if the sample has been
manually diluted offline prior to being presented to the Instrument. If the
sample has not been diluted offline, this segment can be omitted from the
message.
3. The ORDER segment group (ORC, [TQ1], OBR, [NTE]) represents an assay
order (a test) against a specimen. In case of multiple tests ordered on the
specimen, this group is repeated for each order against the specimen.
Message granularity
Each unique OMLÔ33 message can contain the following:

• zero or one patient (could be a control order)
• one specimen
• one or more test orders against the specimen
Multiple ORC/OBR segments are supported in one message, but each ORC
segment must have the same ORC-1 value (new or cancel). Mixed ORC-1
values (new and cancel) in the same message are not supported.
Order comments
ARCHITECT supports the concept of a comment on each test order, limited to

50 characters. The comment text is placed in the comment field of an
ARCHITECT system test order in the following sequence:
1. Text is included in the field NTE-3 Comment in the PATIENT segment group
(if present) and is duplicated in the comment field for each test order for
that patient sample.
2. Text is included in the field NTE-3 Comment in the OBSERVATION
REQUEST segment group (if present).
Order processing rules
If the OMLÔ33 message is successfully parsed as a valid order message, the

ARCHITECT responds with an ORLÔ34 message with MSA-1 = AA, to indicate
the order message was accepted by the application.
Following the acknowledgement of the message, each individual test ordered or
cancelled with an ORC/OBR pairing is further processed and validated. If one or
more individual test orders are rejected (for example, the ordered assay is not
installed on the Instrument), the Instrument can be configured to send an
Automated Equipment Notification message (EANÛ09) that contains the reason

(PN 206797-101) January, 2012
Section 2 Unsolicited Order Download Message Profile
the order request was rejected. The Instrument operator is notified of the
rejected test order.
NOTE: The ORLÔ34 acknowledge message does not contain acceptance or
rejection of each individual assay test order. It indicates only that the order
message is accepted.
1. An ARCHITECT test is fully specified by Assay Identifier and (Assay)
Dilution protocol, as encoded in OBR-4 Universal Service Identifier. Assay
Identifier is the only element required to specify a test order.
2. If (Assay) Dilution protocol is not specified in the message, default dilution
protocol configured for the assay.
3. If the test order request specifies an assay that is not defined or is not
enabled on the Instrument, the Instrument rejects the test request.
4. If the test order request specifies an (Assay) Dilution protocol and that
protocol is not defined for the specified assay (protocol names are case
sensitive), or the protocol is a hidden calibration protocol, the Instrument
rejects the test request.
5. If the test order request specifies an (Assay) Dilution protocol and the
message also specifies an offline sample dilution in SAC-29, the Instrument
rejects the test request.
6. If the test order request indicates a new order (ORC-1 = NW and OBR-11
NOT= A) but that same test order already exists for the sample ID (Pending,
Scheduled, Running), the Instrument rejects the test request.
7. If the test order request indicates an add order (ORC-1 = NW and OBR-11
= A), the test order is processed as a mandatory added test order and is
added regardless whether the same test already exists for the sample ID.
8. If the test order request indicates a cancel order (ORC-1 = CA), the test
order is cancelled only if the specified test order is found with a Pending
status for the sample ID. If no test is found or the test order is already in
progress or is complete, the cancel request is rejected.
Example message
MSH|^~\&|||||20091215153731||OMLÔ33ÔML_O33|A478394b0-1101-468e-a09d-
f53be3661caa|P|2.5.1||||||UNICODE UTF-8
PID|1||J20948579324||Doe^John^Q||19960125|M
PV1|1|N|ÂP20||||^Welby
SPM|1|L9845730|||||||||P
SAC|||||||||||||||||||||||||||||^1^:^2
ORC|NW
TQ1|1||||||||S
OBR|1|||631^ÂRCHITECT|||||||A
NTE|1||Order Comment
ORC|NW
TQ1|2||||||||S

(PN 206797-101) January, 2012
ORLÔ34 Message
This message is a response to an OML message, a laboratory order for multiple
orders related to a single specimen. The following table details the structure of
this message.
Table 2.2: ORLÔ34 message structure

MSA Message Acknowledge R [1..1]
[{ ERR }] Error C [0..*]
SFT Software R [1..1]
This message is in response to a received OMLÔ33 message. It is an HL7

original acknowledgement mode - application-level acknowledgement message.
The following notes apply to ORLÔ34 message structure:

1. The ERR segment is conditional. It is present (and mandatory) only in case
of negative acknowledgement (when MSA-1 = AE or AR).
2. The ORLÔ34 RESPONSE segment group is not supported.
3. If ARCHITECT successfully processed the OMLÔ33 message, the MSA-1
field displays AA. This indicates that the message was recognized as a valid
OMLÔ33 message and all individual assay test orders were successfully
dispositioned: accepted as valid or rejected (for example, unrecognized test
or duplicate test order).
Message example
MSH|^~\&|ARCHITECT|12345|||20091215153540+0000||ORLÔ34ÔRL_O34|
F04cb8b2-8297-5123-be8a-87fe8a86e739|P|2.5.1||||||UNICODE UTF-8
MSA|AA|8836bb8b2-8297-4372-be8a-87f38a86e739
SFT|ADD|8.0|ARCHITECT|””

(PN 206797-101) January, 2012
Section 2 Order Query Message Profile
Order Query Message Profile

This transaction is used between an Instrument and Informatics working in query
mode. When the Instrument identifies a specimen (for example, by reading a
tube's barcode) and finds no existing test orders for the specimen in its
database, the Instrument queries the Informatics for orders against the
specimen. The Informatics sends to the Instrument any existing orders for the
specimen.
Interaction diagram
Interaction model
Trigger event The Instrument sends a query when the following conditions are
met:
• a specimen is recognized (for example, by barcode reading) as
being introduced to the Instrument (will not query based on
Sample Carrier and Position, but only based on specimen ID)
• no existing test orders are found in its database for that
specimen
• the specimen is not configured as a control sample on the
Instrument
• Instrument query mode is enabled
The Instrument sends only one query at a time and waits for a
response to that query before it sends the next query for another
specimen.
A query response is considered complete under any of the following
conditions:

(PN 206797-101) January, 2012
Order Query Message Profile Section 2
• receipt of a negative query response

• receipt of a positive query response (for example, orders for
specimen)
• time out waiting for a response (and retry attempts exhausted)
• error in transmission of query (and retry attempts exhausted)
Direction Instrument > Informatics
Application roles Instrument (sender): identifies specimens and performs analytical

testing on them to produce a result.
Informatics (receiver): manages the orders for specimens run on
Instruments.
Receiver Respond immediately with the appropriate test orders for the
responsibilities identified specimen.
• QBP^ZOS Message, page 2-8
• RSP^ZOS Message, page 2-9
QBP^ZOS Message
This message is a Query by parameter (QBP) message. The following table
details the structure of this message.
Table 2.3: QBP^ZOS message structure

QPD Query Parameter Definition R [1..1]
RCP Response Control Parameter R [1..1]
The following note applies to QBP^ZOS message structure:

1. All segments are required and are always provided.
2. The query parameter is the Specimen ID as identified on the specimen
barcode.
Message granularity
Each unique QBP message contains one specimen.

(PN 206797-101) January, 2012
ARCHITECT waits for the query response message before sending another
query.
Message example
MSH|^~\&|ARCHITECT|12345|||20091215153540+0000||QBP^ZOS^QBP_Q11|
SFT|ADD|8.0|ARCHITECT|”“
QPD|ZOSÔrder for SpecimenÂRCHITECT|12345|L0012345
RCP|I||R
RSP^ZOS Message
This message is a Segment Pattern Response to Query (RSP) message. The
following table details the structure of this message.
Table 2.4: RSP^ZOS message structure

MSA Message Acknowledgement R [1..1]
[{ ERR }] Error C [0..*]
QAK Query Acknowledgement R [1..1]
[ --- RESPONSE DATA begin C [0..1]
[ SAC ] Specimen Container RE [0..1]
[ NTE ] Notes and comments (for Patient) RE [0..1]
] --- PATIENT end
ORC Common Order (for one test/battery) R [1..1]
[ TQ1 ] Timing Quantity RE [0..1]
--- OBSERVATION REQUEST begin R [1..1]
[ NTE ] Notes and comments (for test order) RE [0..1]
--- OBSERVATION REQUEST end
} --- ORDER end
} --- SPECIMEN end

(PN 206797-101) January, 2012
Order Query Message Profile Section 2

] --- RESPONSE DATA end
This message is in response to a QBP^ZOS message and contains orders for

the specimen ID that was the target of the query.
The following notes apply to RSP^ZOS message structure:

2. The RESPONSE DATA segment group is conditional. It is present only if test
orders exist for the specimen (when QAK-2 = OK). For a negative query (no
orders for specimen ID, QAK-2 = NF), the RESPONSE DATA segment group
is not present.
3. The PATIENT segment group is not included for QC orders. For patient
sample orders, it is included only if patient information is available to send.
4. The ORDER segment group (ORC, [TQ1], OBR, [ZTC], [NTE]) represents
the Order (a test). This group is repeated for each test to order on the
specimen.
Message and processing rules
For information about processing rules and message granularity, refer to

Unsolicited Order Download Message Profile, page 2-2. The same discussion
applies to an order received as part of a query response in the RSP^ZOS
message.
Message example
Positive query response:

MSH|^~\&|||||20091215153731||RSP^ZOS^RSP_K11|A478394b0-1101-468e-a09d-
MSA|AA|F04cb8b2-8297-5123-be8a-87fe8a86e739
QAK|12345|OK|ZOSÔrder for SpecimenÂRCHITECT
SPM|1| L0012345|||||||||P
PID|1||J20948579324||Doe^John^Q||19960125|M
ORC|NW
TQ1|1||||||||S
ORC|NW
TQ1|2||||||||S

(PN 206797-101) January, 2012
Negative query response:

MSH|^~\&|||||20091215153731||RSP^ZOS^RSP_K11|A478394b0-1101-468e-a09d-
QAK|12345|NF|ZOSÔrder for SpecimenÂRCHITECT

(PN 206797-101) January, 2012
Unsolicited Results Upload Message Profile Section 2
Unsolicited Results Upload Message Profile

This transaction is used by ARCHITECT to send test results for patient, control,
and calibrator specimens.
Interaction diagram
Interaction model
Trigger event The results are sent by the Instrument when the results are
complete and released by the Instrument. A completed result can
either be a successfully completed test or a test that was to be
run but did not produce a result due to some condition (test
exception).
Application roles Instrument (sender): performs analytical testing on the sample

and produces a result.
Informatics (receiver): stores the result of the analysis.
Receiver Accept and register the result information and respond to the
responsibilities Instrument with the ACK message.
• OUL^R22 Message, page 2-13
• ACK^R22 Message, page 2-16

(PN 206797-101) January, 2012
Section 2 Unsolicited Results Upload Message Profile
OUL^R22 Message
This message is an Unsolicited Specimen Oriented Observation message. The
Table 2.5: OUL^R22 message structure

[ PID ] Patient Identification RE [0..1]
{ --- CONTAINER begin R [1..1]
SAC Container Information R [1..1]
[ INV ] Detailed Substance information (for C [0..1]
example, ID, lot, and manufacturer of QC
specimen)
} --- CONTAINER end
TQ1 Timing Quantity R [1..1]
{ --- RESULT begin R [1..*]
OBX Observation Result R [1..1]
[{ SID }] Substance Identifier (reagents used for RE [0..*]
testing)
[ ZCL ] Calibration Info (Local segment - assay RE [0..1]
calibration used to produce result)
[ NTE ] Notes and Comments (for result) RE [0..1]
} --- RESULT end
} --- ORDER end
} --- SPECIMEN end
The following notes apply to OUL^R22 message structure:

1. The PID and PV1 segments are not included for QC and Calibrator results.
For patient sample results, the segments are included only if patient
information is available to send.

(PN 206797-101) January, 2012
2. The INV segment within the SPECIMEN segment group is conditional. The
segment is sent only when results are reported for a control or calibrator
(SPM-11 = "Q" or "C").
3. The ORDER segment group is repeated for each test (assay) result
instance reported in the message.
4. The RESULT segment group is repeated for each assay result reported.
5. The SID segment is sent only when reagents are used to produce the result.
Reagents include both assay-specific and bulk reagents. Calculated results
and some test exception results are generated without using reagents. Also,
if multiple RESULT segment groups are sent for a result (each for a
different part of the result), the SID segment(s) are included in one of the
segment groups.
6. The ZCL calibration information segment is sent only when an assay
calibration is used to produce the result. Calculated results and test
exception results are generated without using calibration information. Also, if
multiple RESULT segment groups are sent for a result (each for a different
part of the result), the ZCL segment is included in one of the segment
groups. The segment is sent following the OBX segment when OBX-3
Observation Identifier-Result Type is set to "F".
7. The NTE segment is sent only when result comments are available for the
test result. Also, if multiple RESULT segment groups are sent for a result
(each for a different part of the result), the NTE segment is included in one
of the segment groups. The segment is sent following the OBX segment
when OBX-3 Observation Identifier-Result Type is set to "F".
Message granularity
Each unique OUL^R22 message can contain the following:

• zero or one patient (could be a control or calibrator result)
• one specimen
• one or more results for the specimen

(PN 206797-101) January, 2012
Section 2 Unsolicited Results Upload Message Profile
Example messages
Patient result
MSH|^~\&|Architect|100|Mirth|100|20110223111928||OUL^R22ÔUL_R22|
19160523-e3ea-4fd3-90f8-92787165e9f6|P|2.5.1||||||UNICODE UTF-8
SFT|ADD|8.00|ARCHITECT|""
PID|1||AbCd56789||Smith^John^Frank||19690815|M
SPM|1|1234567890|||||||||P||||||20100524125959
SAC||||||||||A100|4||||||||||||||||||^1^:^2
OBR|1|||123&DIL1^TSHÂRCHITECT|||||||||||||||||||||F
TQ1|1||||||||R
OBX|1|ST|123&DIL1&F^TSHÂRCHITECT||100,000.00|copies^ÂRCHITECT|
50.00 - 50.00|IUO~A#1~EXP|||F|||||Adam~David||12345&1~ARCH01|
20100526
SID|1&1&SR|ML12345|RG0123456
ZCL|123^TSHÂRCHITECT|ML12345|20100524125959
NTE|1||This is a result record.
OBX|2|NM|123&DIL1&P^TSHÂRCHITECT||100|rlu^ÂRCHITECT|||||F|||||
Adam~David||12345&1~ARCH01|20100526
OBX|3|ST|123&DIL1&I^TSHÂRCHITECT||POSITIVE||||||F|||||Adam~David||
12345&1~ARCH01|20100526
Control result
b3b89bf8-a1e0-4e9d-93ec-cec46a31b5c3|P|2.5.1||||||UNICODE UTF-8
SPM|1|HIV_LOW_A|||||||||Q
SAC||||||||||G100|4
INV|HIV_LOW_A|OK|CO|||||||||20120526||||HIV_QC_LOT
OBR|1|||999^HIVÂRCHITECT|||||||||||||||||||||F
TQ1|1||||||||R
OBX|1|ST|999&&F^HIVÂRCHITECT||100.00|Ng^ÂRCHITECT|||||F|||||||
12345&3~ARCH01|20100526190000
SID|701&1&SR|12351AD58|11129

(PN 206797-101) January, 2012
Calibration result
6e99eaf8-721f-4518-a0d0-7e0db0febe4a|P|2.5.1||||||UNICODE UTF-8
SPM|1|HIV_CAL_A|||||||||C
SAC||||||||||C100|3
INV|HIV_CAL_A|OK|RC|||||||||20990526||||HIV_CAL_LOT
OBR|1|||1999^HIVÂRCHITECT|||||||||||||||||||||F
TQ1|1||||||||R
OBX|1|ST|1999&&F^HIVÂRCHITECT||100.00|Ng^ÂRCHITECT|||||F|||||||
12345&2~ARCH01|20100526220000
SID|701&1&SR|12351AD58|11129
ACK^R22 Message
This message is an acknowledgement of the Unsolicited Specimen Oriented
Observation message. The following table details the structure of this message.
Table 2.6: ACK^R22 message structure

[{ ERR }] Error C [0..*]
This message is in response to a received OUL^R22 message. It is an HL7

The following notes apply to ACK^R22 message structure:

2. When MSA-1 = AA, all the results contained in the OUL^R22 message are
accepted. ARCHITECT marks the results as successfully transmitted to the
Informatics. Other values for MSA-1 (AE, AR) indicate non-acceptance of
all results. No provision exists to selectively accept or reject individual
results in the OUL^R22 message.
Message example
MSH|^~\&|||||20091215153731||ACK^R22ÂCK|A478394b0-1101-468e-a09d-
MSA|AA|478394b0-1101-468e-a09d-f53be3661caa

(PN 206797-101) January, 2012
Section 2 Unsolicited Calibration Results Upload Message Profile
Unsolicited Calibration Results Upload Message

Profile
This transaction is used by the Instrument to send assay calibration curve
results.
Interaction model
Trigger event The calibration curve results are sent by the Instrument when the
assay calibration is completed by the Instrument. A completed
calibration can either be a calibration that succeeded or failed.
Application roles Instrument (sender): performs the calibration and produces the
calibration results.
Informatics (receiver): stores the result of the calibration.
Receiver Accept and register the result information and respond to the
responsibilities Instrument with the acknowledgement message.
• OUL^R24 Message, page 2-18
• ACK^R24 Message, page 2-19

(PN 206797-101) January, 2012
Unsolicited Calibration Results Upload Message Profile Section 2
OUL^R24 Message
This message is an Unsolicited Order Oriented Observation message. The
Table 2.7: OUL^R24 message structure

{ --- ORDER begin R [1..1]
{ --- SPECIMEN begin R [1..*]
{ --- CONTAINER begin R [1..1]
SAC Container Information R [1..1]
INV Detailed Substance information (for R [1..1]
example, ID, lot, manufacturer of cal
specimen)
} --- CONTAINER end
} --- SPECIMEN end
{ --- RESULT begin R [1..1]
OBX Observation Result R [1..1]
{ SID } Substance Identifier (reagents used for R [1..*]
testing)
} --- RESULT end
} --- ORDER end
The following notes apply to OUL^R24 message structure:

1. The ORDER segment group represents a single-assay calibration.
2. The SPECIMEN segment group is repeated for each calibrator specimen
used to produce the assay calibration.
3. The INV segment within the SPECIMEN segment group contains information
about the calibrator specimens.
4. The RESULT segment group contains the assay calibration result.
5. The SID segment identifies the calibrated reagent lot and pack, and any
bulk reagents used during the calibration.

(PN 206797-101) January, 2012
Section 2 Unsolicited Calibration Results Upload Message Profile
Message granularity
Each unique OUL^R24 message can contain the calibration of one assay on one
module for one reagent lot.
Example message
MSH|^~\&|ARCHITECT|12345|||20091215153540+0000||OUL^R24ÔUL_R24|
d36bb8b2-8297-4372-be8a-87fe8a86e739|P|2.5.1||||||UNICODE UTF-8
OBR|1|||241&DILUTION1^TSHÂRCHITECT|||||||||||||||||||||F
SPM|1|TSH Cal 1|||||||||C
SAC||||||||||K600|1
INV|TSH Cal 1|OK|RC|||||||||20110722||||45W1234567
SPM|2|TSH Cal 2|||||||||C
SAC||||||||||K600|2
INV|TSH Cal 2|OK|RC|||||||||20110722||||45W1234567
OBX|1|ED|241&UNDILUTED&C^TSHÂRCHITECT||^text^plain^Base64^JVBERi0xLjMKJeTjz9I
KNSAwI…||||||F|||||||iSR00001&1~E12345678|20091215153631
SID|241&1&SR|55507AC11|11102
ACK^R24 Message
This message is an acknowledgement of the Unsolicited Order Oriented
Observation message. The following table details the structure of this message.
Table 2.8: ACK^R24 message structure

[{ ERR }] Error C [0..*]
This message is in response to a received OUL^R24 message. It is an HL7

The following notes apply to ACK^R24 message structure:

2. When MSA-1 = AA, all the results contained in the OUL^R24 message are
accepted. ARCHITECT marks the results as successfully transmitted to the
Informatics. Other values for MSA-1 (e.g., AE, AR) indicate non-acceptance
of all the results.

(PN 206797-101) January, 2012
Unsolicited Calibration Results Upload Message Profile Section 2
Message example
MSH|^~\&|||||||20091215153541||ACK^R24ÂCK|4d36bb8b2-8297-4372-be8a-
87f38a86e739|P|2.5.1||||||UNICODE UTF-8
MSA|AA|d36bb8b2-8297-4372-be8a-87fe8a86e739

(PN 206797-101) January, 2012
Section 2 Automated Equipment Status Message Profile
Automated Equipment Status Message Profile

These transactions are used by the Instrument to send information about the
current status (state) of the Instrument module(s).
Interaction diagram
Interaction model
Unsolicited Status Change

When Instrument modules change operational status, if this message profile is
enabled, the Instrument sends status/state changes to Informatics.
Trigger event The module state changes.
Application roles Instrument (sender): controls Instrument state changes.

(PN 206797-101) January, 2012
Automated Equipment Status Message Profile Section 2
Informatics (receiver): monitors Instruments for state changes that

may prevent an Instrument from running at full capability; can
notify the user of such a condition and possibly control the
workflow to divert testing from the Instrument:
• monitors Instruments for state changes that may prevent an
Instrument from running at full capability; can notify the user
of such a condition and possibly control the workflow to divert
testing from the Instrument
• monitors Instrument status and responds to the Instrument
with the ACK message
Receiver Monitor Instrument status and responds to the Instrument with the
responsibilities ACK message.
Status Request
Informatics can request current Instrument status at any time, based on a user-
initiated, automatic, or periodic request.
Trigger event Informatics requires status of Instrument-tracked on-board

inventory items.
Application roles Informatics (sender): tracks Instrument status.

Instrument (receiver): monitors Instrument status:
• monitors Instrument status
• replies with status of the requested Instrument module
Receiver responsibilities Reply with status of the requested Instrument module.
• ESUÛ01 Message, page 2-22
• ACKÛ01 Message, page 2-23
• ESRÛ02 Message, page 2-24
ESUÛ01 Message
This message is an Automated Equipment Status Update message. The

(PN 206797-101) January, 2012
Table 2.9: ESUÛ01 message structure

EQU Equipment Detail R [1..1]
The following note applies to ESUÛ01 message structure:

The EQU segment identifies the ARCHITECT Instrument module and its current
state.
Message Granularity
Each unique ESUÛ01 message contains one Instrument module (an

ARCHITECT Instrument can contain more than one module).
Message example
Instrument Module 2 in Running State (Normal Operation):

MSH|^~\&|ARCHITECT|12345|||20091215153540+0000||ESUÛ01ÊSU_U01|
EQU|i2SR0100&2|20091215154510|OP
ACKÛ01 Message
This message is an acknowledgement of the Status Update message. The
Table 2.10: ACKÛ01 message structure

[{ ERR }] Error C [0..*]
This message is in response to a received ESUÛ01 message. It is an HL7

The following notes apply to ACKÛ01 message structure:


(PN 206797-101) January, 2012
Automated Equipment Status Message Profile Section 2
2. When MSA-1 = AA, the equipment status update message is accepted.
Message example
MSH|^~\&|||||||20091215153541||ACKÛ01ÂCK|8836bb8b2-8297-4372-be8a-
87f38a86e739|P|2.5.1||||||UNICODE UTF-8
ESRÛ02 Message
This message is an Automated Equipment Status Request message. The
Table 2.11: ESRÛ02 message structure

The following note applies to ESRÛ02 message structure:

The EQU segment identifies the ARCHITECT Instrument module.
Message Granularity
Each unique ESRÛ02 message contains one Instrument module (an

ARCHITECT Instrument can contain more than one module).
Message example
MSH|^~\&|||||||20091215153541||ESRÛ02ÊSR_U02|8836bb8b2-8297-4372-be8a-
87f38a86e739|P|2.5.1||||||UNICODE UTF-8
EQU|i2SR0100&2|20091215153541
ACKÛ02 Message
This message is an acknowledgement of the Equipment Status Request
message. The following table details the structure of this message.


(PN 206797-101) January, 2012

[{ ERR }] Error C [0..*]
This message is in response to a received ESRÛ02 message. It is an HL7


2. When MSA-1 = AA, the equipment status request message is accepted.
Message example
MSH|^~\&|ARCHITECT|12345|||20091215153540+0000||ACKÛ02ÂCK|
MSA|AA|8836bb8b2-8297-4372-be8a-87f38a86e739

(PN 206797-101) January, 2012
Automated Equipment Inventory Message Profile Section 2
Automated Equipment Inventory Message Profile

These transactions are used by the Instrument to send information about on-
board inventory items used by the Instrument to produce assay results. The
Instrument can send inventory information asynchronously when a significant
inventory event occurs, or in response to an inventory query by an Informatics
application.
Interaction diagram
Interaction model
Unsolicited Inventory Status Change

The Instrument continuously monitors its on-board inventory items and, if this
message profile is enabled, the Instrument sends inventory status changes to
Informatics.
Trigger event Significant inventory state changes, including the following:

(PN 206797-101) January, 2012
Section 2 Automated Equipment Inventory Message Profile
• inventory replenished (bulk supplies)

• new reagent pack loaded or unloaded
• reagent pack disabled or enabled
• expiration override
• stability override
Application roles Instrument (sender): monitors inventory usage and detects inventory
status changes that can impact its ability to run and generate assay
results.
Informatics (receiver):
• monitors Instruments for inventory conditions that may prevent
an Instrument from running at full capability; can notify the
user of such a condition and possibly control the workflow to
divert testing from the Instrument
• monitors the consumption of inventory items by the Instrument
and uses that information to help maintain the level of supplies
in the laboratory
Receiver Monitors Instrument inventory status and responds to the Instrument

responsibilities with the ACK message.
Inventory Request
The Informatics system can request inventory status information from the
Instrument at any time, based on user-initiated, automatic, or periodic request.
The query can request inventory status or calibration status of reagent packs.
Trigger event Informatics requires status of Instrument-tracked on-board

inventory items.
Application roles Informatics (sender): tracks Instrument on-board inventory

information.
Instrument (receiver): monitors Instruments for inventory levels
and status.
Receiver 1. Responds with inventory information of on-board

responsibilities reagent packs and on-board supplies.
2. Responds with calibration status of on-board reagent
packs.

(PN 206797-101) January, 2012
• INUÛ05 Message, page 2-28
• INRÛ06 Message, page 2-29
INUÛ05 Message
This message is an Automated Equipment Inventory Update message. The
Table 2.13: INUÛ05 message structure

{ INV } Inventory Detail R [1..*]
The following notes apply to INUÛ05 message structure:

1. The EQU segment identifies the ARCHITECT Instrument module.
2. The INV segment is repeated for each reported inventory item. A single INV
segment reports either inventory status or assay calibration status for the
assay contained in INV-15 Test/Fluid Identifier. Each inventory item contains
one or more INV segments in the message.
Message Granularity
Each unique INUÛ05 message contains the following:

• one Instrument module (an ARCHITECT Instrument can contain more than
one module)
• one or more inventory items for that module

(PN 206797-101) January, 2012
Message example
MSH|^~\&|ARCHITECT|12345|||20091215153540+0000||INUÛ05ÎNU_U05|
EQU|i2SR0100&2|20091215154510
INV|351&2|LD~IO|SR|12890|RC|1|100|87|87||TESTS|20100425|||351ÂssayNameÂRCHIT
ECT~357ÂssayName2ÂRCHITECT|123456EU09|||128^h
INV|450&1|LD~IO|SR|02818|RC|1|100|100|100||TESTS|20101108|||450ÂssayNameÂRCH
ITECT|987654ER07
INV|TRIGGER|IO|LI||||1000|219|219||mL||||||||11^d
ACKÛ05 Message
This message is an acknowledgement of the Inventory Update message. The

[{ ERR }] Error C [0..*]
This message is in response to a received INUÛ05 message. It is an HL7


2. When MSA-1 = AA, the inventory update message is accepted.
Message example
MSH|^~\&|||||20091215153541||ACKÛ05ÂCK|8836bb8b2-8297-4372-be8a-
87f38a86e739|P|2.5.1||||||UNICODE UTF-8
INRÛ06 Message
This message is an Automated Equipment Inventory Request message. The

(PN 206797-101) January, 2012
Table 2.15: INRÛ06 message structure

INV Inventory Detail R [1..1]
The following notes apply to INRÛ06 message structure:

2. The INV segment occurs only once in the message and specifies that both
inventory status and calibration status are being requested on all on-board
items.
Message Granularity
Each unique INRÛ06 message contains one Instrument module (an ARCHITECT
Instrument can contain more than one module).
Message example
MSH|^~\&|||||20091215153541||INRÛ06ÎNR_U06|8836bb8b2-8297-4372-be8a-
87f38a86e739|P|2.5.1||||||UNICODE UTF-8
EQU|i2SR0100&2|20091215153541
INV|ALL|OK
ACKÛ06 Message
This message is an acknowledgement of the Inventory Request message. The

[{ ERR }] Error C [0..*]
This message is in response to a received INRÛ06 message. It is an HL7


(PN 206797-101) January, 2012

2. When MSA-1 = AA, the inventory request message is accepted.
Message example
MSH|^~\&|ARCHITECT|12345|||20091215153540+0000||ACKÛ06ÂCK|
MSA|AA|8836bb8b2-8297-4372-be8a-87f38a86e739

(PN 206797-101) January, 2012
Automated Equipment Notification Message Profile Section 2
Automated Equipment Notification Message

Profile
This transaction is used by the Instrument to send notification events that have
occurred on the Instrument.
Interaction diagram
Interaction model
Trigger event The Instrument detected notification events, such as error or

warning indications to the Instrument operator. These
notifications each have a four-digit number that identifies the
event and a text description of the event.
Application roles Instrument (sender): monitors and detects conditions that require
user notification.
Informatics (receiver): records notifications that occur on
Instruments.
Receiver Monitors Instrument for notifications, stores them if necessary,

responsibilities and possibly acts on specific notifications received.
• EANÛ09 Message, page 2-33

(PN 206797-101) January, 2012
Section 2 Automated Equipment Notification Message Profile
EANÛ09 Message
This message is an Automated Equipment Notification message. The following
table details the structure of this message.
Table 2.17: EANÛ09 message structure

NDS Notification Detail R [1..1]
The following notes apply to EANÛ09 message structure:

2. The NDS segment contains the notification being reported.
Message Granularity
Each unique EANÛ09 message contains the following:

one module)
• one notification for that module
Message example
MSH|^~\&|ARCHITECT|12345|||20091215153540+0000||EANÛ09ÊAN_U09|
C48bb8b2-8297-5123-be8a-87fe8a86e739|P|2.5.1||||||UNICODE UTF-8
EQU|i2SR0100&2|20091215153539
NDS|””|20091215153539|””|0202^The reagent kit in position (24) has expired or
exceeded the stability time.ÂRCHITECT
ACKÛ09 Message
This message is an acknowledgement of the Equipment Notification message.
The following table details the structure of this message.

(PN 206797-101) January, 2012
Automated Equipment Notification Message Profile Section 2

[{ ERR }] Error C [0..*]
This message is in response to a received EANÛ09 message. It is an HL7


2. When MSA-1 = AA, the notification message is accepted.
Message example
MSH|^~\&|||||||20091215153541||ACKÛ09ÂCK|9d36bb8b2-8297-4372-be8a-
87f38a86e739|P|2.5.1||||||UNICODE UTF-8
MSA|AA|C48bb8b2-8297-5123-be8a-87fe8a86e739

(PN 206797-101) January, 2012
Section 2 Automated Equipment Service Update Message Profile
Automated Equipment Service Update Message

Profile
This transaction is used by the Instrument to send maintenance events that have
occurred on the Instrument. Maintenance events include updates related with
maintenance or diagnostic procedures performed on the Instrument.
Interaction diagram
Interaction model
Trigger event A maintenance or diagnostic procedure has been performed

on the Instrument.
Application roles Instrument (sender): executes the maintenance procedure.

Informatics (receiver): records and maintains a log of
maintenance events for the Instrument.
Receiver responsibilities Monitors Instrument for maintenance events and records the
received events.
• LSUÛ12 Message, page 2-36

(PN 206797-101) January, 2012
Automated Equipment Service Update Message Profile Section 2
LSUÛ12 Message
This message is an Automated Equipment Log / Service Update message. The
Table 2.19: LSUÛ12 message structure

{ EQP } Equipment Log/Service R [1..1]
The following notes apply to LSUÛ12 message structure:

2. The EQP segment contains the maintenance event that is being reported.
The formatted text description of the event is included in the FT data type
field, EQP-5 Transaction Data. The field includes a series of tab-delimited
name/value pairs, with each pair on new line.
Message granularity
Each unique LSUÛ12 message contains the following:

one module)
• one maintenance event (service event) for that module
Message example
NOTE: The EQP-5 element displays on separate lines in the following example,
for readability. The formatted text field escapes the tab and new line.
MSH|^~\&|ARCHITECT|12345|||20091215153540+0000||LSUÛ12^LSU_U12|
C48bb8b2-8297-5123-be8a-87fe8a86e739|P|2.5.1||||||UNICODE UTF-8
EQU|i2SR0100&2|20091215153540
EQP|SER||20091215153400|20091215153540|TYPE\X09\MAINTENANCE\.br\
ID\X09\6014\.br\NAME\X09\Pipetter Probe Cleaning\.br\
VERSION\X09\6\.br\CATEGORY\X09\WEEKLY\.br\OPERATOR ID\X09\
ADMIN\.br\CYCLE COUNT\X09\365229\.br\RESULT\X09\PASS
EQP-5 contents:

(PN 206797-101) January, 2012
Section 2 Automated Equipment Service Update Message Profile
TYPE MAINTENANCE
ID 6014
NAME Pipetter Probe Cleaning
VERSION 6
CATEGORY WEEKLY
OPERATOR ID ADMIN
CYCLE COUNT 365229
RESULT PASS
ACKÛ12 Message
This message is an acknowledgement of the Equipment Notification message.
The following table details the structure of this message.

[{ ERR }] Error C [0..*]
This message is in response to a received LSUÛ12 message. It is an HL7


2. When MSA-1 = AA, the equipment service update message is accepted.
Message example
MSH|^~\&|||||||20091215153541||ACKÛ12ÂCK|9d36bb8b2-8297-4372-be8a-
87f38a86e739|P|2.5.1||||||UNICODE UTF-8
MSA|AA|C48bb8b2-8297-5123-be8a-87fe8a86e739

(PN 206797-101) January, 2012
Instrument Configuration Query Message Profile Section 2
Instrument Configuration Query Message Profile

This transaction is used by Informatics to query the Instrument to obtain
configuration settings. The supported Instrument configuration categories
include:
• Assay Parameters - installed assays and their associated settings
• System Parameters - Instrument-wide configuration settings
• Maintenance Parameters - installed maintenance procedures and their
associated settings
• Electronic TSB Parameters - available and completed electronic Technical
Service Bulletins on the Instrument
Interaction diagram
Interaction model
Trigger event The query is sent by Informatics when a user requests Instrument
configuration settings, typically in order for a user to review and
compare configuration settings across a population of like Instrument
types or to maintain an archive of Instrument configuration settings.
Informatics sends only one query at a time and waits for the
response to complete for one query before it sends another query (if
applicable) for other configuration settings.
A query response is considered complete under any of the following
conditions:
• Receipt of a negative query response
• Receipt of a positive query response (for example, orders for
specimen)

(PN 206797-101) January, 2012
Section 2 Instrument Configuration Query Message Profile
• Time out waiting for a response (and retry attempts exhausted)

• Error in transmission of query (and retry attempts exhausted)
Application roles Informatics (sender): obtains current configuration settings from

Instrument(s) and can provide archival of settings as well as a
comparison report of settings across Instruments. Informatics can
only query settings and cannot update the settings on an Instrument.
Instrument (receiver): reports current configuration settings.
Receiver Responds immediately with the requested Instrument configuration

responsibilities settings.
• QBP^ZIC Message, page 2-39
• RSP^ZIC Message, page 2-40
QBP^ZIC Message
This message is a Query by parameter (QBP) message. The following table
Table 2.21: QBP^ZIC message structure

RCP Response Control Parameter R [1..1]
The following note applies to QBP^ZIC message structure:

1. All segments are required and are always provided.
2. The query parameter contained in the QPD segment contains the Instrument
configuration category, the Master File Identifier, being queried (for
example, Assay Parameters, System Parameters, Maintenance Parameters,
Electronic TSB Status).
Message granularity
Each unique QBP message contains one configuration category and request for
all entries in that category (for example, all currently installed assays).
Informatics waits for the query response message before sending another query.

(PN 206797-101) January, 2012
Instrument Configuration Query Message Profile Section 2
Message example
MSH|^~\&|ARCHITECT|12345|||20091215153540+0000||QBP^ZIC^QBP_Q11|
QPD|ZICÎnstrument ConfigurationÂRCHITECT|QUERYTAG12345|ASY^ÂRCHITECT
RCP|I||R
RSP^ZIC Message
This message is a Segment Pattern Response to Query (RSP) message. The
Table 2.22: RSP^ZIC message structure

MSA Message Acknowledgement R [1..1]
[{ ERR }] Error C [0..*]
QAK Query Acknowledgement R [1..1]
[ --- RESPONSE DATA begin C [0..1]
{ --- MASTER FILE ENTRY begin R [1..*]
MFE Master File Entry (Parameter identifier) R [1..1]
ZPS Parameter Settings (Local segment) R [1..1]
} --- MASTER FILE ENTRY end
] --- RESPONSE DATA end
This message is in response to a QBP^ZIC message and contains all

configuration data for the category that was the target of the query.
The following notes apply to RSP^ZOS message structure:

2. The RESPONSE DATA segment group is conditional. It is present only if
there are entries for the requested category (when QAK-2 = OK). For a
negative query (for example, no entries for the requested category, QAK-2
= NF), the RESPONSE DATA segment group is not present.
3. The MASTER FILE ENTRY segment group represents the parameter
settings for each entry in the category. For example, if the category is
Assay Parameters, the MASTER FILE ENTRY segment group is repeated for
each currently installed assay on the Instrument.

(PN 206797-101) January, 2012
Section 2 Instrument Configuration Query Message Profile
4. The ZPS segment contains the current parameter settings for the entry. This
segment encodes a rich set of parametric data values in a simple text
name/value pair format that is specific to the parameter type.
Message example
Positive query response:

MSH|^~\&|||||20091215153731||RSP^ZIC^RSP_K11|A478394b0-1101-468e-a09d-
QAK|QUERYTAG12345|OK|ZICÎnstrument ConfigurationÂRCHITECT
QPD|ZICÎnstrument ConfigurationÂRCHITECT|QUERYTAG12345|ASY
MFE|MAD|||241^TSHÂRCHITECT|CE
ZPS|241^TSHÂRCHITECT|ED|^text^plain^Base64^JVLID0ioasdf980ksjf…
MFE|MAD|||740^_BNPSTATÂRCHITECT
ZPS|740^_BNPSTATÂRCHITECT|ED|^text^plain^Base64^RES8G9ohsdf980ksaq…
Negative query response:

MSH|^~\&|||||20091215153731||RSP^ZIC^RSP_K11|A478394b0-1101-468e-a09d-
QAK|QUERYTAG12345|NF|ZICÎnstrument Configuration
QPD|ZICÎnstrument Configuration|QUERYTAG12345|ASY

(PN 206797-101) January, 2012
Connection Test Message Profile Section 2
Connection Test Message Profile

This transaction is used to test the connection between two applications. The
Instrument can both initiate and respond to a connection test message.
Interaction diagram
Interaction model
Trigger event An operator requests one application to send a test message

to the other application.

Informatics > Instrument
Application roles Sender: initiates test of the application connection.

Receiver: responds to the connection test message.
Receiver responsibilities Acknowledges the message.
• NMD^N02 Message (ARCHITECT to Informatics), page 2-43
• ACK^N02 Message (ARCHITECT to Informatics), page 2-44

(PN 206797-101) January, 2012
Section 2 Connection Test Message Profile
• NMD^N02 Message (Informatics to ARCHITECT), page 2-44

• ACK^N02 Message (Informatics to ARCHITECT), page 2-43
NMD^N02 Message (ARCHITECT to Informatics)

This message is an Application Management Data message. The following table
Table 2.23: NMD^N02 message structure

NST Application Control-level Statistics R [1..1]
The following note applies to NMD^N02 message structure:

The message is intended to be a short test and contains minimal application-
level information.
Message example
ARCHITECT-initiated connection test:

MSH|^~\&|ARCHITECT|12345|||20091215153540+0000||NMD^N02^NMD_N02|
d36bb8b2-8297-4372-be8a-87f38a86e739|P|2.5.1||||||UNICODE UTF-8
NST|N
ACK^N02 Message (Informatics to ARCHITECT)

This message is an acknowledgement of the Connection Test message. The
Table 2.24: ACK^N02 message structure

[{ ERR }] Error C [0..*]
This message is in response to a received NMD^N02 message. It is an HL7


(PN 206797-101) January, 2012
The following notes apply to ACK^N02 message structure:

2. MSA-1 = AA indicates acceptance of the connection test message.
Message example
The following message is an example of an Acknowledgement to ARCHITECT-

initiated Connection Test:
MSH|^~\&|||||20091215153541||ACK^N02ÂCK|Ad36bb8b2-8297-4372-be8a-
87f38a86e739|P|2.5.1||||||UNICODE UTF-8
MSA|AA|d36bb8b2-8297-4372-be8a-87f38a86e739
NMD^N02 Message (Informatics to ARCHITECT)

This message is an Application Management Data message. The following table
Table 2.25: NMD^N02 message structure

NST Application control-level Statistics R [1..1]
The following note applies to NMD^N02 message structure:

The message is intended to be a short test and contains minimal application-
level information.
Message example
Informatics-initiated connection test:

MSH|^~\&|||||20091215153540+0000||NMD^N02^NMD_N02|
d36bb8b2-8297-4372-be8a-87f38a86e739|P|2.5.1||||||UNICODE UTF-8
NST|N
ACK^N02 Message (ARCHITECT to Informatics)

This message is an acknowledgement of the Connection Test message. The

(PN 206797-101) January, 2012
Section 2 Connection Test Message Profile
Table 2.26: ACK^N02 message structure

[{ ERR }] Error C [0..*]
This message is in response to a received NMD^N02 message. It is an HL7

The following notes apply to ACK^N02 message structure:

2. MSA-1 = AA indicates acceptance of the connection test message.
Message example
The following message is an example of an Acknowledgement to ARCHITECT-

initiated Connection Test:
MSH|^~\&|ARCHITECT|12345|||20091215153541||ACK^N02ÂCK|Ad36bb8b2-8297-4372-
be8a-87f38a86e739|P|2.5.1||||||UNICODE UTF-8
MSA|AA|d36bb8b2-8297-4372-be8a-87f38a86e739

(PN 206797-101) January, 2012
NOTES

(PN 206797-101) January, 2012
Section 3 ARCHITECT HL7 segment structure
ARCHITECT HL7 segment structure
The following topics define segment structure as implemented in ARCHITECT:
• EQP Segment, page 3-3
Contains data about a service event that has occurred on the Instrument.
• EQU Segment, page 3-6
Identifies the equipment or Instrument in laboratory automation messages.
• ERR Segment, page 3-9
Used to add error information to acknowledgment messages.
• INV Segment (in Inventory Messages), page 3-12
Contains the data necessary to track the inventory of substances on the
Instrument.
• INV Segment (in Result Messages), page 3-23
Contains the data necessary to track the inventory of substances on the
Instrument.
• MFE Segment, page 3-27
Identifies a particular Master File Entry.
• MSA Segment, page 3-29
Contains information sent while acknowledging another message.
• MSH Segment, page 3-31
Defines the intent, source, destination, and some specifics of the syntax of a
message.
• NDS Segment, page 3-38
Contains details about the event notification sent by the Instrument.
• NST Segment, page 3-40
Allows application-level, control-level statistical information to be passed
between applications.
• NTE Segment, page 3-42
Used for sending notes and comments that accompany test order or result
data.
• OBR Segment, page 3-43
Used to transmit information that is specific to an order for a diagnostic study
or observation.
• OBX Segment (in OUL^R22 specimen result message), page 3-48
Used to transmit a single observation or observation fragment.
• OBX Segment (in OUL^R24 calibration result message), page 3-57
Used to transmit a single observation or observation fragment.
• ORC Segment, page 3-64
Used to transmit elements that are common to all of the tests ordered.
• PID Segment, page 3-66
Used as the primary means of communicating patient identification
information.

(PN 206797-101) January, 2012
ARCHITECT HL7 segment structure Section 3
• PV1 Segment, page 3-70

Used to communicate information that is specific to a patient visit specific
basis.
• QAK Segment, page 3-74
Contains information sent with responses to a query.
• QPD Segment (in Order Query Messages), page 3-76
Defines the parameters of the query message used by ARCHITECT to query
Informatics for specimen orders.
• QPD Segment (in Instrument Configuration Query Messages), page 3-78
Defines the parameters of the query message used by ARCHITECT to query
Informatics for specimen orders.
• RCP Segment, page 3-80
Restricts the amount of data that should be returned in response to a query.
• SAC Segment, page 3-82
Describes the specimen container.
• SFT Segment, page 3-86
Provides additional information about the software product(s) used as
Sending Application.
• SID Segment, page 3-88
Contains data necessary to identify the substance (for example, reagents)
used in the production of analytical test results.
• SPM Segment, page 3-91
Describes the characteristics of a single specimen.
• TQ1 Segment, page 3-95
Specifies the complex timing of events and actions, such as those that occur
in order management and scheduling systems. Determines the quantity,
frequency, priority, and timing of a service.
• ZCL Segment, page 3-97
Identifies the calibration that was produced by running the calibrator.
• ZPS Segment, page 3-99
Contains the Instrument configuration parameter settings.

(PN 206797-101) January, 2012
Section 3 EQP Segment
EQP Segment
EQP segment structure
The EQP (equipment log/service) segment contains data about a service event.
A service event is the performance of a maintenance or diagnostic procedure on
the Instrument.
Table 3.1: EQP segment structure
1 250 CE R [1..1] X [0..0] Event Type
2 20 ST X [0..0] X [0..0] File Name
3 26 TS R [1..1] X [0..0] Start Date/Time
4 26 TS R [1..1] X [0..0] End Date/Time
5 65536 FT R [1..1] X [0..0] Transaction Data
EQP-1 Event Type (CE)
HL7 Definition: This field identifies the type of service event.

This specification: This field contains a subset of values from HL7 Table 0450.
Only the first component is populated.
Table 3.2: Element: EQP-1 Event Type
Component/Sub-component Usage LEN Comment

Identifier (ST) R 3 Taken from HL7 Table 0450.
Text (ST) X
Name of Coding System (ID) X
Alternate Identifier (ST) X
Alternate Text (ST) X
Name of Alternate Coding System (ID) X
Table 3.3: Subset of HL7 Table 0450: Event Type

SER Service Event Maintenance/Diagnostic procedure
EQP-3 Start Date/Time (TS)
HL7 Definition: This field identifies the date and time the event started.
This specification: This element is reported to a precision of seconds.

(PN 206797-101) January, 2012
EQP Segment Section 3
Table 3.4: Element: EQP-3 Start Date/Time
YYYYMMDDHHMMSS+/-ZZZZ R
Degree of precision X
EQP-4 End Date/Time (TS)
HL7 Definition: This field identifies the date and time the event was completed.
Table 3.5: Element: EQP-4 End Date/Time
EQP-5 Transaction Data (FT)
HL7 Definition: This field displays logged data about the service event.
This specification: This field describes the maintenance or diagnostic procedure
that was performed, with results, name of person who performed it, and the
Instrument cycle count at which it was performed. HL7 defines this field as a
Formatted Text (FT) data type. ARCHITECT formats this text field as a series of
tab-separated name/value pairs, with each pair on a new line, for ease of text
data rendering and parsing (if necessary). The tab and new line characters are
escaped in the FT field, using a hexadecimal escape sequence (\Xdd\).
NOTE: Capitalized name labels and value enumerates are not translated based
on ARCHITECT language settings. They always are specified as below.
The name/value pairs are formatted as follows:
TYPE [ MAINTENANCE | DIAGNOSTIC ]
ID Four-digit procedure identifier
NAME Textual name of the procedure
VERSION Version number of procedure
CATEGORY [ BY SHIFT | DAILY | WEEKLY | MONTHLY | QUARTERLY | AS

NEEDED ]
OPERATOR ID Instrument operator ID of the person who performed the procedure
CYCLE COUNT Instrument cycle count (odometer) at the time of the procedure

(PN 206797-101) January, 2012
Section 3 EQP Segment
RESULT [ PASS | FAIL | CANCEL ]
Sample value(s):
TYPE\X09\MAINTENANCE\.br\ID\X09\6014\.br\
NAME\X09\Pipetter Probe Cleaning\.br\VERSION\X09\6\.br\
CATEGORY\X09\WEEKLY\.br\OPERATOR ID\X09\
ADMIN\.br\CYCLE COUNT\X09\365229\.br\RESULT\X09\PASS
The sample message represents the following data:
TYPE MAINTENANCE
ID 6014
NAME Pipetter Probe Cleaning
VERSION 6
CATEGORY WEEKLY
OPERATOR ID ADMIN
CYCLE COUNT 365229
RESULT PASS

(PN 206797-101) January, 2012
EQU Segment Section 3
EQU Segment
EQU segment structure
The EQU segment identifies the equipment or Instrument in HL7 Laboratory

Automation messages.
Table 3.6: EQU segment structure
1 25 EI R [1..1] R [1..1] Equipment Instance Identifier
2 26 TS R [1..1] R [1..1] Event Date/Time
3 250 CE C [0..1] X [0..0] Equipment State
4 250 CE X [0..0] X [0..0] Local/Remote Control State
5 250 CE X [0..0] X [0..0] Alert Level
EQU-1 Equipment Instance Identifier (EI)
HL7 Definition: This field identifies the equipment.

This specification: ARCHITECT is an Instrument system that consists of one or
more assay modules. The system as a whole has a serial number, and each
module has a serial number and module ID. This field identifies the assay
module. This field may not repeat. Therefore, this field does not include the
overall system serial number as in OBX-18.
Table 3.7: Element: EQU-1 Equipment Instance Identifier

Entity Identifier (ST) R
Serial Number RE 11 Module Serial Number
Module ID R 1 Module ID (1 – 5)
Namespace ID (IS) X
Universal ID (ST) X
Universal ID Type (ID) X
Sample value(s):
i2SR0100&2 [Module SN: i2SR0100, Module ID:2]
EQU-2 Event Date/Time (TS)
HL7 Definition: This field indicates the date and time the event occurred (for
example, state transition, command issued, command finished).

(PN 206797-101) January, 2012
Section 3 EQU Segment
This specification: For sent messages, this field represents the date and time the
event occurred. For received messages, this field represents the date and time
of the information request. This element is reported to a precision of seconds.
Table 3.8: Element: EQU-2 Event Date/Time
EQU-3 Equipment State (CE)
HL7 Definition: This field identifies the status of the equipment when the
transaction was initiated.
This specification: This element is conditional. It is present in the Equipment
Status Update (ESU) message or it is empty.
EQU-3 Sender (ESUÛ01 status update):
This field contains a subset of and extensions to values from HL7 Table 0365.
Only the first component is populated.
Table 3.9: Element: EQU-3 Equipment State

Identifier (ST) R 2 Taken from HL7 Table 0365.
Text (ST) X
Subset of/Extensions to HL7 Table 0365: Equipment state

* = extension
Table 3.10: Subset of/Extensions to HL7 Table 0365: Equipment state

ES E-stopped ARCHITECT module STOPPED state
IN Initializing ARCHITECT module INITIALIZING state
ID Idle ARCHITECT module READY state
OP Normal Operation ARCHITECT module RUNNING state
PA Pausing ARCHITECT module SCHEDULED PAUSE state
LP *Load Queue ARCHITECT module LOAD QUEUE PAUSED state
Paused

(PN 206797-101) January, 2012
EQU Segment Section 3

MA *Maintenance ARCHITECT module MAINTENANCE state
procedure in
progress
OF *Offline ARCHITECT module OFFLINE state
EA *Exclusive Access ARCHITECT module EXCLUSIVE ACCESS state
WM *Warming Up ARCHITECT module WARMING state
SC *Scanning ARCHITECT module SCANNING state
Reagents

(PN 206797-101) January, 2012
Section 3 ERR Segment
ERR Segment
ERR segment structure
The ERR segment is used to add error information to acknowledgment

messages. This segment is sent only when, in the accompanying MSA segment,
MSA-1 acknowledgement code is "AR" or "AE".
Table 3.11: ERR segment structure
1 493 ELD X [0..0] X [0..0] Error Code and Location
2 18 ERL R [1..*] R [1..*] Error Location
3 705 CWE R [1..1] R [1..1] HL7 Error Code
4 2 ID R [1..1] R [1..1] Severity
5 705 CWE X [0..0] X [0..0] Application Error Code
6 80 ST X [0..0] X [0..0] Application Error Parameter
7 2048 TX X [0..0] X [0..0] Diagnostic Information
8 250 TX X [0..0] X [0..0] User Message
9 20 IS X [0..0] X [0..0] Inform Person Indicator
10 705 CWE X [0..0] X [0..0] Override Type
11 705 CWE X [0..0] X [0..0] Override Reason Code
12 652 XTN X [0..0] X [0..0] Help Desk Contact Point
ERR-2 Error Location (ERL)
HL7 Definition: This field identifies the location in a message related to the
identified error, warning, or message. If multiple repetitions are present, the error
results from the values in a combination of places.
This specification: No additional guidance.
Components: <Segment ID (ST)> ^ <Segment Sequence (NM)> ^
<Field Position (NM)> ^ <Field Repetition (NM)> ^
<Component Number (NM)> ^ <Sub-Component Number (NM)>
ERR-3 HL7 Error Code (CWE)
HL7 Definition: This element identifies the HL7 communications error code.
This specification: Only the first component (Identifier) is supported, using codes
from the subset of codes in HL7 Table 0357.

(PN 206797-101) January, 2012
ERR Segment Section 3
Table 3.12: Subset of HL7 Table 0357 - Message error condition codes

100 Segment Error: The message segments were not in the proper
sequence error order, or required segments are missing.
101 Required field Error: A required field is missing from a segment.
missing
102 Data type error Error: The field contained data of the wrong data type.
For example, an NM field contained "FOO".
103 Table value not Error: A field of data type ID or IS was compared against
found the corresponding table, and no match was found.
200 Unsupported Rejection: The Message Type is not supported.
message type
201 Unsupported event Rejection: The Event Code is not supported.
code
202 Unsupported Rejection: The Processing ID is not supported.
Processing ID
203 Unsupported Rejection: The Version ID is not supported.
Version ID
207 Application Rejection: Includes internal errors not explicitly covered by
internal error other codes.
Table 3.13: Element: ERR-3 HL7 Error Code
Identifier (ST) R
Text (ST) X
Alternate identifier (ST) X
Coding System Version ID (ST) X
Alternate Coding System Version ID (ST) X
Original Text (ST) X
ERR-4 Severity (ID)
HL7 Definition: This field identifies the severity of an application error (Error,
Warning, or Information), which determines how the content of the message is
handled.
This specification: This interface supports only a subset of codes from the HL7
Table 0516.

(PN 206797-101) January, 2012
Section 3 ERR Segment
Table 3.14: Subset of HL7 Table 0516 - Error severity

E Error Transaction was unsuccessful
W Warning Not used at this time

(PN 206797-101) January, 2012
INV Segment (in Inventory Messages) Section 3
INV Segment (in Inventory Messages)

INV segment structure (Inventory Messages)
The INV segment contains the data necessary to track the inventory of
substances on the Instrument. The segment can be used as follows:
• substance information for onboard reagents and bulk consumables in the
INUÛ05 message
• request inventory status in INRÛ06 message
Table 3.15: INV segment structure
1 22 CE R [1..1] R [1..1] Substance Identifier
2 2 CE R [1..*] R [1..1] Substance Status
3 2 CE R [1..1] X [0..0] Substance Type
4 250 CE RE [0..1] X [0..0] Inventory Container Identifier
5 250 CE RE [0..2] X [0..0] Container Carrier Identifier
6 250 CE RE [0..2] X [0..0] Position on Carrier
7 20 NM RE [0..1] X [0..0] Initial Quantity
8 20 NM RE [0..1] X [0..0] Current Quantity
9 20 NM RE [0..1] X [0..0] Available Quantity
10 20 NM X [0..0] X [0..0] Consumption Quantity
11 250 CE RE [0..1] X [0..0] Quantity Units
12 26 TS RE [0..1] X [0..0] Expiration Date/Time
13 26 TS X [0..0] X [0..0] First Used Date/Time
14 200 TQ X [0..0] X [0..0] On-board Stability Duration
15 250 CE RE [0..*] X [0..0] Test/Fluid Identifier(s)
16 20 ST RE [0..1] X [0..0] Manufacturer Lot Number
17 250 CE X [0..0] X [0..0] Manufacturer Identifier
18 250 CE X [0..0] X [0..0] Supplier Identifier
19 20 CQ RE [0..1] X [0..0] On-board Stability Time
20 20 CQ X [0..0] X [0..0] Target Value
INV-1 Substance Identifier (CE)
HL7 Definition: This field represents a unique, manufacturer-specific identifier for

the substance that is in inventory.
This specification: The value of INV-1 is dependent on the message that is sent.
The INV segment can be used to identify any of the following items:

(PN 206797-101) January, 2012
Section 3 INV Segment (in Inventory Messages)
• assay-specific reagents (inventory update message)

• bulk liquid supplies (inventory update message)
• bulk solid supplies (inventory update message)
• waste (inventory update message)
• "all" inventory items (inventory request message)
Table 3.16: Element: INV-1 Substance Identifier

Identifier (ST) R
Substance Identifier (ST) R 20 Identifier of substance
Substance Version (NM) RE 1 Version of substance (if applicable)
Text (ST) X
INV-1 Sender (Assay reagents sent with INUÛ05 inventory update):

When the INV segment is used in the INUÛ05 message to send inventory status
for assay specific reagents, sub-components follow these formats:
• Substance Identifier: Reagent Configuration ID.
– For i System reagents, this is a 4-digit number.
– For c System reagents, this is an N-character identifier.
• Substance Version: Reagent configuration version (1-digit number)
(INV-3 Substance Type: SR)

Sample value(s):
1024&2 [Reagent ID 1024, version 2]
AST00&1 [Reagent ID AST00, version 1]
SALINE&1 [Reagent ID SALINE, version 1]
INV-1 Sender (Bulk supplies/waste sent with INUÛ05 inventory update):

When the INV segment is used in the INUÛ05 message to send inventory status
for bulk liquid reagents, solid supplies, and waste, the Substance Identifier is
taken from the table:

(PN 206797-101) January, 2012
Table 3.17: INV-1 Substance Identifier: Sub-component for Bulk Supplies
Value Description
PRE_TRIGGER i System pre-trigger solution
TRIGGER i System trigger solution
WASH_BUFFER i System Wash Buffer solution
RVS i System Reaction Vessels
SOLID_WASTE i System Solid Waste
ICT_REFERENCE c System ICT Reference solution
ALKALINE_WASH c System Alkaline Wash solution
ACID_WASH c System Acid Wash solution
LIQUID_WASTE c System or i System Liquid Waste
DETERGENT_A c System Detergent A solution (can reside
in Sample Carousel and Reagent Supply
Areas)
10_DETERGENT_B c System 10% Detergent B solution (can
reside in Reagent Supply Areas)
0.5_ACID_WASH c System 0.5% Acid Wash (can reside in
Sample Carousel and Reagent Supply
Areas)
ICT_MODULE c System ICT module
Substance Version: <empty>

(INV-3 Substance Type: LW, SW, SC, or LI)
Sample value(s):
PRE_TRIGGER [Pre-trigger bulk solution]
RVS [Reaction Vessels]
INV-1 Receiver (INRÛ06 inventory request):

When the INV segment is used in the INRÛ06 message to request inventory
status for all onboard inventory items, the Substance Identifier is taken from HL7
User-defined Table 0451.
Table 3.18: INV-1 Substance Identifier: Inventory Request from HL7 Table
0451
Value Description
ALL Inventory and calibration status for all on-
board assay reagents, bulk supplies, and
waste

(PN 206797-101) January, 2012
INV-2 Substance Status (CE)
HL7 Definition: This field represents the current status of the inventoried
substance.
This specification: Only the first component is supported.
INV-2 Sender (INUÛ05 inventory update):
This field contains a subset of and extensions to values in HL7 Table 0383. An
INV segment contains one or more values to specify inventory or calibration
status. An INV segment does not contain both inventory and calibration status
values. This field can repeat. At least one status is always present.
Table 3.19: Element: INV-2 Substance Status

Identifier (ST) R 2 Substance status
Text (ST) X
Subset of/Extensions to HL7 Table 0383: Substance Inventory Status

* = extension
Table 3.20: Subset of/Extensions to HL7 Table 0383: Substance Inventory

Status

EE Expired Error Past expiration date
EO *Expiration Expiration override by Instrument operator
Override
SE *Stability Error Exceeded on-board stability
SO *Stability Override Stability override by Instrument operator
NW Not Available Low capacity remaining
Warning
NE Not Available Error No capacity remaining (for example, Empty supply, waste
full)
DI *Disabled Reagent pack disabled
LE *LLS Error Liquid level sense error encountered
LD *Loaded Reagent pack loaded on Instrument
UL *Unloaded Reagent pack unloaded from Instrument
RP *Replenished Bulk supply replenished/waste emptied

(PN 206797-101) January, 2012

IO *Inventory OK Inventory status OK
MX *Mixing Reagent pack mixing
Subset of/Extensions to HL7 Table 0383: Substance Calibration Status

* = extension
Table 3.21: Subset of/Extensions to HL7 Table 0383: Substance Calibration

Status

CN *Calibration None Has not been calibrated
CE Calibration Error Last calibration attempt failed
CX *Calibration Full calibration expired
Expired
AX *Adjustment Adjustment calibration expired
Expired
CI *Calibration In- Calibration in progress but not yet complete
progress
CO *Calibration OK Calibration status OK
CV *Calibration Calibration has been overridden
Overridden
OL *Overridden Lot Calibrator lot material expiration has been overridden
CQ *Pending QC QC is required to be run after a calibration
INV-2 Receiver (INRÛ06 inventory request):

This field contains a subset of values from HL7 Table 0383. This field is
required in all INV segments.
ARCHITECT accepts any value in this field, since the INRÛ06 message
requests the status of all inventory items regardless their status.
Table 3.22: Subset HL7 Table 0383: Substance status (for Inventory Request)

OK OK status
* Other Any value accepted and ignored for inventory request
Sample value(s):
LD [Reagent pack loaded]
CN~CI [Not calibrated, but calibration in progress]

(PN 206797-101) January, 2012
INV-3 Substance Type (CE)
HL7 Definition: This field represents the type of substance.

This specification: INV-3 contains a subset of values from HL7 Table 0384.
Table 3.23: Element: INV-3 Substance Type

Identifier (ST) R 2 Type of substance (for example, Control,
Reagent, Bulk Supply, Waste)
Text (ST) X
Table 3.24: Subset HL7 Table 0384: Substance type

SR Single Test Assay-specific reagent pack
Reagent
LW Liquid Waste
SW Solid Waste
SC Countable Solid for example, i System reaction vessel
Item
OT Other for example, c System ICT Module
LI Measurable Liquid for example, i System Pre-Trigger, Trigger, and Wash
Item Buffer, or c System reference, wash, and detergent
solutions
INV-4 Inventory Container Identifier (CE)
HL7 Definition: This field identifies the inventory container, using a unique
identifier of a specific package instance of a manufacturer-specific substance.
This specification: For ARCHITECT, only the assay-specific reagent packs have
unique identifiers (serial numbers), so this field is populated only for reagent
packs with the reagent pack serial number.
Table 3.25: Element: INV-4 Inventory Container Identifier

Identifier (ST) R 5 Reagent pack serial number
Text (ST) X

(PN 206797-101) January, 2012

INV-5 Container Carrier Identifier (CE)
HL7 Definition: This field identifies the carrier used to transport the substance
containers.
This specification: For ARCHITECT, assay-specific reagent packs and some bulk
liquid supplies on the c System modules (0.5% Acid Wash, Detergent A, 10%
Detergent B) can be loaded on a carousel or reagent storage area. For these
supplies, this field contains the sample carousel or reagent supply area
identifier. This field can repeat for c System reagent packs, since they can be
located in both the R1 and R2 reagent storage areas. For c System packs, the
first repeat is always R1, while the second repeat (if present) is R2.
Table 3.26: INV-5 Container Carrier Identifier: ARCHITECT i System and c

System
Value Description
RC i System reagent carousel
SC c System sample carousel
R1 c System reagent supply center R1
R2 c System reagent supply center R2
R1R2 c4000 reagent supply center R1/R2
Table 3.27: Element: INV-5 Container Carrier Identifier

Identifier (ST) R 5 Reagent or sample carousel identifier
Text (ST) X
Sample value(s):
RC [Reagent carousel on i System]
R1~R2 [R1 and R2 reagent storage areas on c System]

(PN 206797-101) January, 2012
R1 [R1 storage area on c System]
INV-6 Position on Carrier (CE)
HL7 Definition: This field identifies the position (index) on the carrier.
This specification: For ARCHITECT, assay-specific reagent packs and some bulk
liquid supplies on the c System modules (0.5% Acid Wash, Detergent A, 10%
Detergent B) can be loaded on a carousel or in a reagent storage area. INV-6
contains the position of these supplies in the sample carousel or reagent supply
area. This field can repeat for c System reagent packs, since they can be
located in both the R1 and R2 reagent storage areas. The first repeat is always
R1, while the second repeat (if present) is R2.
Table 3.28: Element: INV-6 Position on Carrier

Identifier (ST) R 5 Position on reagent or sample carousel
Text (ST) X
Sample value(s):
4 [Reagent carousel location 4 on i System]
B3~C6 [R1 and R2 reagent storage area positions on c System]
A10 [R1 storage area position on c System]
INV-7 Initial Quantity (NM)
HL7 Definition: This field identifies the initial quantity of the substance in
inventory.
This specification: For assay-specific reagent packs, this is the initial test
capacity of the pack at manufacture. For bulk supplies, it represents the
maximum capacity of the on-board inventory of the supply. This field may be
empty for c System supplies on the sample carousel (for example, Detergent A),
since the Instrument does not track their remaining quantities.
INV-8 Current Quantity (NM)
HL7 Definition: This field is the current quantity, determined by initial quantity
minus what has already been used.
This specification: For assay-specific reagent packs, this field represents the
remaining tests in the pack. For bulk supplies, it represents the current quantity

(PN 206797-101) January, 2012
of the on-board inventory. This field may be empty for c System supplies on the
sample carousel (for example, Detergent A), since the Instrument does not track
their remaining quantities.
INV-9 Available Quantity (NM)
HL7 Definition: This field is the available quantity of substance. This is the
current quantity minus any planned consumption (for example, for tests that are
planned).
This specification: This field represents the current quantity minus any quantity
planned to be used by scheduled tests but not yet consumed.
INV-11 Quantity Units (CE)
HL7 Definition: The units of measure of the available quantity.

This specification: For ARCHITECT, measurement units are based on substance:
• reagent packs - number of tests
• bulk liquid supplies - mL
• RVs and solid waste - numeric count
Table 3.29: INV-11 Quantity units: ARCHITECT i System and c System
Value Description
TESTS Tests in a reagent pack
mL Milliliters of liquid
L Liters of liquid
COUNT Count of RVs or waste disposals
Table 3.30: Element: INV-11 Quantity units

Identifier (ST) R 5 Unit of measure
Text (ST) X
INV-12 Expiration Date/Time (TS)
HL7 Definition: This field is the expiration date/time of the substance.

This specification: For inventory information sent with IRUÛ05, this is the
expiration date of the inventory item contained on the item barcode or entered
by the ARCHITECT operator. Precision is to the day.

(PN 206797-101) January, 2012
Table 3.31: Element: INV-12 Expiration Date/Time
YYYYMMDD R
INV-15 Test/Fluid Identifiers (CE)
HL7 Definition: This field represents the list of tests and body fluid that apply to
this substance. This is a repeating field. An empty INV-15 field means that this
substance is not test-specific.
This specification: For assay-specific reagents, this field is a repeating field that
contains the assay(s) that use this reagent. For all other inventory types, this
field is empty.
Table 3.32: Element: INV-15 Test/fluid identifiers

Identifier (ST) R 4 Assay number for the test
Text (ST) R 10 Assay name for the test
Name of Coding System (ID) R 9 "ARCHITECT" (without quotation marks)
INV-16 Manufacturer Lot Number (ST)
HL7 Definition: This field specifies the lot number assigned by the manufacturer
during production of the substance.
This specification: For inventory information sent with Inventory update INUÛ05,
this is the lot number of the material as known by the ARCHITECT (read from
barcode). This field may be empty for items for which the Instrument does not
track lot number.
INV-19 On-board Stability Time (CQ)
HL7 Definition: This field is the duration of time that the calibration/usability of
the substance is stable.
This specification: If the INV segment is reporting inventory status, then for
inventory items for which ARCHITECT tracks on-board stability time, this field
contains the amount of time remaining before the substance exceeds its on-
board stability. For ARCHITECT, reagent packs are tracked in hours. Some bulk
supplies are tracked in days.
If the INV segment is reporting calibration status for assay calibrations that have
stability expiration, this field contains the amount of time remaining before the
calibration expires (in hours).

(PN 206797-101) January, 2012
Table 3.33: Element: INV-19 On-board Stability Time

Quantity (NM) R 5 Time remaining
Units (CE) R Units
Identifier (ST) R 2 d = days
hr = hours
Text (ST) X
Sample value(s):
14^h [14 hours remaining stability]

(PN 206797-101) January, 2012
Section 3 INV Segment (in Result Messages)
INV Segment (in Result Messages)

INV segment structure (Result Messages)
The INV segment contains the data necessary to track the inventory of
substances on the Instrument. The segment can be used to identify these types
of substance information:
• QC material used for QC results sent in OUL^R22 message
• calibrator material used for calibrator results sent in OUL^R22 message
• calibrator material used for calibration curve results sent in OUL^R24
message
Table 3.34: INV segment structure
1 20 CE R [1..1] X [0..0] Substance Identifier
2 2 CE R [1..1] X [0..1] Substance Status
3 2 CE R [1..1] X [0..0] Substance Type
4 250 CE X [0..0] X [0..0] Inventory Container
Identifier
5 250 CE X [0..0] X [0..0] Container Carrier
Identifier
6 250 CE X [0..0] X [0..0] Position on Carrier
7 20 NM X [0..0] X [0..0] Initial Quantity
8 20 NM X [0..0] X [0..0] Current Quantity
9 20 NM X [0..0] X [0..0] Available Quantity
10 20 NM X [0..0] X [0..0] Consumption Quantity
11 250 CE X [0..0] X [0..0] Quantity Units
12 26 TS RE [0..1] X [0..0] Expiration Date/Time
13 26 TS X [0..0] X [0..0] First Used Date/Time
14 200 TQ X [0..0] X [0..0] On-board Stability
Duration
15 250 CE X [0..0] X [0..0] Test/Fluid Identifier(s)
16 20 ST RE [0..1] X [0..0] Manufacturer Lot
Number
17 250 CE X [0..0] X [0..0] Manufacturer
Identifier
18 250 CE X [0..0] X [0..0] Supplier Identifier
19 20 CQ X [0..0] X [0..0] On-board Stability
Time
20 20 CQ X [0..0] X [0..0] Target Value

(PN 206797-101) January, 2012
INV Segment (in Result Messages) Section 3
INV-1 Substance Identifier (CE)
HL7 Definition: Unique, manufacturer-specific identifier for the substance that is

in inventory.
This specification: The INV segment can be used to identify either of the
following items in a results upload message:
• a control material
• a calibrator material
Table 3.35: Element: INV-1 Substance Identifier

Identifier (ST) R
Substance Version (NM) X Version of substance
Text (ST) X
INV-1 Sender (Control material sent with OUL^R22 results upload):

When the INV segment is used in the OUL^R22 QC results message to send
information about control material used, sub-components follow these
guidelines:
Substance Identifier: The name of the control as defined on ARCHITECT. This is
also the specimen ID of the control material. If the control material is in a bar-
coded tube, the Substance Identifier is encoded in the bar code to identify the
material. The name is often a concatenation of the control name and control
level.
(INV-3 Substance Type: CO)
Sample value(s):
TSH_LOW [TSH Low Control Material]
INV-1 Sender (Calibrator material sent with OUL^R22 results upload):

When the INV segment is used in the OUL^R22 Calibrator results message to
send information about calibrator material used, sub-components follow these
guidelines:
Substance Identifier: The name of the calibrator as defined on ARCHITECT. This
is also the specimen ID of the calibrator material.

(PN 206797-101) January, 2012
Section 3 INV Segment (in Result Messages)

(INV-3 Substance Type: RC)
Sample value(s):
CAL1 [CAL1 Calibrator Material]
INV-2 Substance Status (CE)
HL7 Definition: The current status of the inventoried substance.

This specification: This field contains a subset of and extensions to values in
HL7 Table 0383. Only the first component is supported.
Table 3.36: Element: INV-2 Substance Status

Identifier (ST) R 2 Substance status
Text (ST) X
Table 3.37: Subset of/Extensions to HL7 Table 0383: Substance Status (for
Control and Calibrator material)

OK OK Status
INV-3 Substance Type (CE)
HL7 Definition: This field represents the type of substance.

This specification: INV-3 contains a subset of values from HL7 Table 0384.
Table 3.38: Element: INV-3 Substance Type

Identifier (ST) R 2 Type of substance (for example, Control,
Reagent, Bulk Supply, Waste)
Text (ST) X

(PN 206797-101) January, 2012
INV Segment (in Result Messages) Section 3

Table 3.39: Subset HL7 Table 0384: Substance type

CO Control Quality Control Sample
RC Reagent Calibrator Calibrator Specimen
INV-12 Expiration Date/Time (TS)
HL7 Definition: This field is the expiration date/time of the substance.

This specification: For control or calibrator material information sent with control/
calibrator results OUL^R22, this is the expiration date of the material as
configured by the ARCHITECT operator, if applicable. Precision is to the day.
Table 3.40: Element: INV-12 Expiration Date/Time
YYYYMMDD R
INV-16 Manufacturer Lot Number (ST)
This specification: For control or calibrator material information sent with control/
calibrator results OUL^R22, this is the lot number of the material as configured
by the ARCHITECT operator.

(PN 206797-101) January, 2012
Section 3 MFE Segment
MFE Segment
MFE segment structure
The MFE segment identifies a particular Master File Entry.
Table 3.41: MFE segment structure
1 3 ID R [1..1] - - Record Level Event Code
2 20 ST X [0..0] - - MFN Control ID
3 26 TS X [0..0] - - Effective Date/Time
4 201 CE R [1..1] - - Primary Key Value
5 3 ID R [1..1] - - Primary Key Value Type
MFE-1 Record Level Event Code (ID)
HL7 Definition: This field defines the record-level event for the master file record
identified by the MFI segment and the primary key field in MFE-1.
This specification: Only the values from HL7 Table 0180 are supported.
Table 3.42: Subset of HL7 Table 0180: Record level event code

MAD Add record to
master file
MFE-4 Primary Key Value (CE)
HL7 Definition: This field uniquely identifies the record of the master file
(identified in the MFI segment) to be changed, as defined by the record-level
event code.
This specification: This field identifies the entry as assay, maintenance/
diagnostic procedure, or TSB.
NOTE: The maximum element length for MFE-4 has been extended to 201
characters from the HL7-prescribed length of 200 characters. This extension
allows for necessary characters to be included in the field.
Table 3.43: Element: MFE-4 Primary Key Value

Identifier (ST) R 10 Contains one of the following, depending on
the configuration category:

(PN 206797-101) January, 2012
MFE Segment Section 3

• Assay number
• "SYS" for system parameters (without
quotation marks)
• Maintenance/Diagnostics procedure
number
• TSB number
Text (ST) R 180 Contains one of the following, depending on
• Assay name
• "System" for system parameters (without
quotation marks)
• Maintenance/Diagnostics procedure name
• TSB subject
Name of Coding System (ID) R 9 ARCHITECT
MFE-5 Primary Key Value Type (ID)
HL7 Definition: This field contains the HL7 data type of MFE-4 Primary Key
Value.
This specification: Only values taken from HL7 Table 0355 are supported.
Table 3.44: Subset of HL7 Table 0355: Primary key value type

CE Coded Element

(PN 206797-101) January, 2012
Section 3 MSA Segment
MSA Segment
MSA segment structure
The MSA segment contains information sent while acknowledging another

message.
Table 3.45: MSA segment structure
1 2 ID R [1..1] R [1..1] Acknowledgement Code
2 50 ST R [1..1] R [1..1] Message Control ID
3 80 ST X [0..0] X [0..0] Text Message
4 15 NM X [0..0] X [0..0] Expected Sequence Number
5 X [0..0] X [0..0] Delayed Acknowledgment Type
6 250 CE X [0..0] X [0..0] Error Condition
MSA-1 Acknowledgment Code (ID)
HL7 Definition: This element contains the acknowledgment code, based on HL7
message processing rules.
This specification: This interface supports only the HL7 original
acknowledgement mode. Only the following subset of codes from HL7 Table
0008 are supported.
Table 3.46: Subset of HL7 Table 0008 - Acknowledgement Code

AA Original mode: Message processed and accepted
Application Accept
AE Original mode: Message processed, has either content or format errors
Application Error
AR Original mode: Message rejected due to MSH error(s)
Application Reject
MSA-1 Sender:
Supports the values described in Subset of HL7 Table 0008 - Acknowledgement
Code, with this additional detail:
• AA indicates an accepted message
• AE indicates application-detected error, typically related to errors in the
message content or structure outside the MSH segment

(PN 206797-101) January, 2012
MSA Segment Section 3
• AR indicates a rejected message due to error in the MSH segment (see

MSH segment description for required elements that may cause message
rejection)
NOTE: The ERR segment that accompanies the MSA segment in the
acknowledgement message indicates the location of the error.
MSA-1 Receiver:
Supports the values described in Subset of HL7 Table 0008 - Acknowledgement
Code, with this additional detail:
• AA indicates that a message is successfully processed and accepted
• all other values indicate message failure
MSA-2 Message Control ID (ST)
HL7 Definition: This field contains the message control ID of the message sent
by the sending system. MSA-2 allows the sending system to associate this
response with the message for which it is intended.
This specification: This field contains the value in MSH-10 Message Control ID
of the message being acknowledged.

(PN 206797-101) January, 2012
Section 3 MSH Segment
MSH Segment
MSH segment structure
The MSH segment defines the intent, source, destination, and some specifics of
the syntax of a message.
Table 3.47: MSH segment structure

1 1 ST R [1..1] R [1..1] Field Separator
2 4 ST R [1..1] R [1..1] Encoding Characters
3 20 HD RE [0..1] X [0..0] Sending Application
4 20 HD RE [0..1] X [0..0] Sending Facility
5 20 HD RE [0..1] X [0..0] Receiving Application
6 20 HD RE [0..1] X [0..0] Receiving Facility
7 26 TS R [1..1] R [1..1] Date/Time of Message
8 40 ST X [0..0] X [0..0] Security
9 15 MSG R [1..1] R [1..1] Message Type
10 50 ST R [1..1] R [1..1] Message Control ID
11 3 PT R [1..1] R [1..1] Processing ID
12 60 VID R [1..1] R [1..1] Version ID
13 15 NM X [0..0] X [0..0] Sequence Number
14 180 ST X [0..0] X [0..0] Continuation Pointer
15 2 ID X [0..0] X [0..0] Accept Acknowledgement Type
16 2 ID X [0..0] X [0..0] Application Acknowledgement
Type
17 3 ID X [0..0] X [0..0] Country Code
18 16 ID R [1..1] R [1..1] Character Set
19 250 CE X [0..0] X [0..0] Principal Language of Message
20 20 ID X [0..0] X [0..0] Alternate Character Set Handling
Scheme
21 427 EI X [0..0] X [0..0] Message Profile Identifier
MSH-1 Field Separator (SI)
This interface supports the HL7-recommended value, | (ASCII 124).
MSH-2 Encoding Characters (ST)
This field contains the four characters in the following order:

1. component separator

(PN 206797-101) January, 2012
MSH Segment Section 3
2. repetition separator
3. escape character
4. subcomponent separator
This interface supports the HL7-recommended values ^~\& (ASCII 94, 126, 92,
and 38, respectively).
MSH-3 Sending Application (HD)
HL7 Definition: This field uniquely identifies the sending application among all
other applications that participate in the exchange of HL7 messages within the
network.
This specification:
MSH-3 Sender:
Only the first component of this element is populated. A configuration parameter
allows the value of MSH-3 to be set for all sent messages. The default value is
the name of the Instrument (for example, ARCHITECT).
Table 3.48: MSH-3 Sender
Component/Sub-component Usage LEN Contents

namespace ID (IS) RE 20 Configuration parameter; default is
ARCHITECT
universal ID (ST) X
universal ID type (ID) X
MSH-3 Receiver:
This element is not supported and is ignored if present.
MSH-4 Sending Facility (HD)
HL7 Definition: This field further describes the sending application, MSH-3
Sending Application. This field is promoted to an HD data type. The usage is
broadened to include the sending facility and other organizational entities such
as the following:
• the organizational entity responsible for sending application
• the responsible unit
• a product or vendor’s identifier
This specification:
MSH-4 Sender:
allows the value of MSH-4 to be set for all sent messages. The default value is
the system serial number of the ARCHITECT that is sending the message, to

(PN 206797-101) January, 2012
uniquely identify the instance of the Instrument. More than one Instrument
instance can exist on a single network.

namespace ID (IS) RE 20 Configuration parameter; default is system
serial number
universal ID (ST) X
MSH-4 Receiver:
MSH-5 Receiving Application (HD)
HL7 Definition: This field uniquely identifies the receiving application among all
other applications that participate in the exchange of HL7 messages within the
network.
This specification:
MSH-5 Sender:
allows the value of MSH-5 to be set for all sent messages. By default, the value
is <empty>.

namespace ID (IS) RE 20 Configuration parameter
universal ID (ST) X
MSH-5 Receiver:
MSH-6 Receiving Facility (HD)
HL7 Definition: This field identifies the receiving application among multiple
identical instances of the application running on behalf of different
organizations.
This specification:
MSH-6 Sender:
allows the value of MSH-6 to be set for all sent messages. By default, the value
is <empty>.

(PN 206797-101) January, 2012

namespace ID (IS) RE 20 Configuration parameter
universal ID (ST) X
MSH-6 Receiver:
MSH-7 Date/Time of Message (TS)
This field contains the date and time that the sending system created the
message.
NOTE: This field is required, as of HL7 version 2.4 Messaging Standard.
Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision
(ID)>
MSH-7 Sender:
The date and time of the message are reported to a precision of seconds.
Table 3.52: Element: MSH-7 Date/Time of Message (Sent messages)
YYYYMMDDHHMMSS R
MSH-7 Receiver:
Indication of time zone is not supported and is ignored if present. No time zone
adjustments are made by the Instrument software for time stamps in incoming
messages.
Table 3.53: Element: MSH-7 Date/Time of Message (Received messages)
YYYYMMDDHHMMSS[+/-ZZZZ] R
MSH-9 Message Type (MSG)
HL7 Definition: This field contains the message type, trigger event, and message
structure ID.
This specification: All components are required.

(PN 206797-101) January, 2012
Table 3.54: Element: MSH-9 Message Type
Message Code (ID) R
Trigger Event (ID) R
Message Structure (ID) R
MSH-9 Sender:
All three components are populated (for example, ORLÔ34ÔRL_O34).
MSH-9 Receiver:
Message types not recognized in this specification cause message rejection.
MSH-10 Message Control ID (ST)
HL7 Definition: This field contains a number or other identifier that uniquely
identifies the message. Each message is given a unique identifier by the sending
system. The receiving system returns this ID to the sending system in the
Message Acknowledgment (MSA) segment.
This specification:
NOTE: The maximum element length for MSH-10 is extended to 50 characters
from the HL7-prescribed length of 20 characters. This extension allows sending
systems to use globally unique identifiers, such as GUIDs, for Message IDs.
MSH-11 Processing ID (PT)
HL7 Definition: This field indicates whether to process a message as defined in

HL7 Application (level 7) Processing rules.
This specification: Only the first component is required and supports only a
value of "P".
Table 3.55: Element: MSH-11 Processing ID
processing ID (ID) R
processing mode (ID) X
Table 3.56: Subset of HL7 Table 0103 - Processing ID

P Production Message processed.
MSH-11 Sender:
Value is always "P".
MSH-11 Receiver:

(PN 206797-101) January, 2012
Values other than "P" cause message rejection.
MSH-12 Version ID (VID)
HL7 Definition: This field identifies the version of HL7 supported. The receiving
system compares the value in this field to its own version to ensure correct
message interpretation.
This specification: Only the first component is supported.
Table 3.57: Element: MSH-12 Version ID
Version ID (ID) R
Internationalisation Code (CE) X
International Version ID (CE) X
MSH-12 Sender:
Value is always "2.5.1".
MSH-12 Receiver:
Accepts values starting with the character string "2.5". Later minor releases such
as "2.5.1" are also supported. All other values cause message rejection.
MSH-18 Character Set (ID)
HL7 Definition: This field contains the character set for the entire message.
Refer to HL7 table 0211 - Alternate character sets, for valid values.
This specification: Only the subset of values from HL7 table 0211 are supported.
Table 3.58: Subset of HL7 Table 0211 - Alternate character sets

UNICODE UCS UTF-8 is a variable-length encoding. Each code
UTF-8 Transformation value is represented by 1, 2, or 3 bytes, depending
Format, 8-bit form on the code value. Seven-bit (7-bit) ASCII is a proper
subset of UTF-8.
NOTE: The code contains a space before UTF but
not before and after the hyphen.
Though the field is repeatable in HL7, only one occurrence (one character set)
is supported by this interface specification. The character set specified in this
field is used for encoding of all characters within the message.
MSH-18 Sender:
Only one character set encoding is supported, as specified in Subset of HL7
Table 0211.
MSH-18 Receiver:

(PN 206797-101) January, 2012
Values other than those specified cause message rejection.

(PN 206797-101) January, 2012
NDS Segment Section 3
NDS Segment
NDS segment structure
The NDS segment contains details about the event notification sent by the
Instrument.
Table 3.59: NDS segment structure
1 20 NM R [1..1] X [0..0] Notification Reference Number
2 26 TS R [1..1] X [0..0] Notification Date/Time
3 250 CE R [1..1] X [0..0] Notification Alert Severity
4 250 CE R [1..1] X [0..0] Notification Code
NDS-1 Notification Reference Number (NM)
HL7 Definition: This field contains a unique sequential reference number that
may be used by various components to refer to this transaction. This number is
generated by the originator of this notification.
This specification: This field is present but has a value of null (""). This element
is required by HL7 v2.5.1, section 13.4.7, but ARCHITECT does not generate a
unique sequential reference number for each notification transaction.
NDS-2 Notification Date/Time (TS)
HL7 Definition: This field is the date and time of the notification.
Table 3.60: Element: NDS-2 Notification Date/Time
NDS-3 Notification Alert Severity (CE)
HL7 Definition: This field represents the severity of the specific notification.
This specification: This field is present but has a value of null (""). This element
is required by HL7 v2.5.1, section 13.4.7, but ARCHITECT does not associate a
severity for each notification transaction.

(PN 206797-101) January, 2012
Section 3 NDS Segment
NDS-4 Notification Code (CE)
HL7 Definition: This field contains manufacturer- and equipment-specific error or

status codes related with the specific notification.
This specification: Only the first three components are supported. The Identifier
component contains the four (4)-digit AIM codes defined by ARCHITECT.
Table 3.61: Element: NDS-4 Notification Code
Component/Sub-component Usage Comment

Identifier (ST) R Four (4)-digit AIM code
Text (ST) R Text associated with error code (in configured
language of ARCHITECT)
Name of Coding System (ID) R ARCHITECT

(PN 206797-101) January, 2012
NST Segment Section 3
NST Segment
NST segment structure
The NST segment allows application-level, control-level statistical information to

be passed between applications.
Table 3.62: NST segment structure

1 1 ID R [1..1] R [1..1] Statistics Available
2 30 ST X [0..0] X [0..0] Source Identifier
3 3 ID X [0..0] X [0..0] Source Type
4 26 TS X [0..0] X [0..0] Statistics Start
5 26 TS X [0..0] X [0..0] Statistics End
6 10 NM X [0..0] X [0..0] Receive Character Count
7 10 NM X [0..0] X [0..0] Send Character Count
8 10 NM X [0..0] X [0..0] Messages Received
9 10 NM X [0..0] X [0..0] Messages Sent
10 10 NM X [0..0] X [0..0] Checksum Errors Received
11 10 NM X [0..0] X [0..0] Length Errors Received
12 10 NM X [0..0] X [0..0] Other Errors Received
13 10 NM X [0..0] X [0..0] Connect Timeouts
14 10 NM X [0..0] X [0..0] Receive Timeouts
15 10 NM X [0..0] X [0..0] Application control-level Errors
NST-1 Statistics Available (ID)
HL7 Definition: This field indicates the availability of statistics. Valid values are
"Y" and "N".
Y - The responding application keeps statistics. Fields 4 and 5 are required.
The response message contains one or more non-null fields in the ranges 2 -
3 and 6 - 15.
N - The responding application does not keep statistics. If the value "N" is
specified, the response message is used to signify to the initiating application
that the communication link between the initiating and responding
applications is operational. Fields 2 - 15 are empty in the response message.
This specification: Only the "N" value is supported, to indicate an operational
application. This segment is present only in the NMD^N02 message used to test
the connection.
NST-1 Sender:
This field always has a value of "N".

(PN 206797-101) January, 2012
Section 3 NST Segment
NST-1 Receiver:
The value of this field can be either "Y" or "N". All other NST fields are ignored,
if present.

(PN 206797-101) January, 2012
NTE Segment Section 3
NTE Segment
NTE segment structure
The NTE segment is used for sending notes and comments that accompany test
order or result data. The placement of the NTE segment within a message's
segment structure dictates the context of the comment (for example, order
comment or result comment).
Table 3.63: NTE segment structure
1 4 SI R [1..1] R [1..1] Set ID - NTE
2 8 ID X [0..0] X [0..0] Source of Comment
3 50 FT R [1..1] R [1..1] Comment
4 250 CE X [0..0] X [0..0] Comment Type
NTE-1 Set ID (SI)
HL7 Definition: This field contains the sequence number and is used to identify
segment instances in message structures (segment groups) where the segment
repeats within that structure. The sequence number of the first occurrence of
the segment is one, the sequence number of the second occurrence is two, and
subsequent instances follow the same convention.
If the segment occurs only once within a message structure, its value is "1". If
the message structure (segment group) repeats, the first occurrence of the
segment in each segment group is "1".
NTE-3 Comment (FT)
HL7 Definition: The field contains the actual comment text.

This specification: The field contains text for order comments and result
comments.

(PN 206797-101) January, 2012
Section 3 OBR Segment
OBR Segment
OBR segment structure
The OBR segment is used to transmit information that is specific to an order for
a diagnostic study or observation, primarily to identify the test to run on the
specimen.
NOTE: The fields OBR-2 Placer Order Number and OBR-3 Filler Order Number
are not supported by ARCHITECT. ARCHITECT does not support Order Numbers
as distinct values from Sample Identifiers. For ARCHITECT, all test orders are
specified as tests ordered against Sample Identifier as specified in SPM-2
Specimen Identifier.
Table 3.64: OBR segment structure
1 4 SI R [1..1] R [1..1] Set ID - OBR
2 22 EI X [0..0] X [0..0] Placer Order Number
3 22 EI X [0..0] X [0..0] Filler Order Number
4 250 CE R [1..1] R [1..1] Universal Service Identifier
5 2 ID X [0..0] X [0..0] Priority - OBR
6 26 TS X [0..0] X [0..0] Requested Date/Time
7 26 TS X [0..0] X [0..0] Observation Date/Time
8 26 TS X [0..0] X [0..0] Observation End Date/Time
9 20 CQ X [0..0] X [0..0] Collection Volume
10 250 XCN X [0..0] X [0..0] Collection Identifier
11 1 ID X [0..0] RE [0..1] Specimen Action Code
12 51 CE X [0..0] X [0..0] Danger Code
13 50 ST X [0..0] X [0..0] Relevant Clinical Information
14 26 TS X [0..0] X [0..0] Specimen Received Date/Time *
15 300 SPS X [0..0] X [0..0] Specimen Source
16 250 XCN X [0..0] X [0..0] Ordering Provider
17 250 XTN X [0..0] X [0..0] Order Callback Phone Number
18 60 ST X [0..0] X [0..0] Placer Field 1
19 60 ST X [0..0] X [0..0] Placer Field 2
20 60 ST X [0..0] X [0..0] Filler Field 1 +
21 60 ST X [0..0] X [0..0] Filler Field 2 +
22 26 TS X [0..0] X [0..0] Results Rpt/Status Chng - Date/
Time +
23 40 MOC X [0..0] X [0..0] Charge to Practice +

(PN 206797-101) January, 2012
OBR Segment Section 3
24 10 ID X [0..0] X [0..0] Diagnostic Serv Sect ID
25 1 ID R [1..1] X [0..0] Result Status +
26 400 PRL X [0..0] X [0..0] Parent Result +
27 200 TQ X [0..0] X [0..0] Quantity/Timing
28 200 XCN X [0..0] X [0..0] Result Copies To
29 200 EIP X [0..0] X [0..0] Parent
30 20 ID X [0..0] X [0..0] Transportation Mode
31 250 CE X [0..0] X [0..0] Reason for Study
32 200 NDL X [0..0] X [0..0] Principal Result Interpreter
33 200 NDL X [0..0] X [0..0] Assistant Result Interpreter
34 200 NDL X [0..0] X [0..0] Technician
35 200 NDL X [0..0] X [0..0] Transcriptionist
36 25 TS X [0..0] X [0..0] Scheduled Date/Time
37 4 NM X [0..0] X [0..0] Number of Sample Containers
38 250 CE X [0..0] X [0..0] Transport Logistics of Collected
Sample
39 250 CE X [0..0] X [0..0] Collector's Comment
40 250 CE X [0..0] X [0..0] Transport Arrangement
Responsibility
41 30 ID X [0..0] X [0..0] Transport Arranged
42 1 ID X [0..0] X [0..0] Escort Required
43 250 CE X [0..0] X [0..0] Planned Patient Transport
Comment
44 250 CE X [0..0] X [0..0] Procedure Code
45 250 CE X [0..0] X [0..0] Procedure Code Modifier
46 250 CE X [0..0] X [0..0] Placer Supplemental Service
Information
47 250 CE X [0..0] X [0..0] Filler Supplemental Service
Information
48 250 CWE X [0..0] X [0..0] Medically Necessary Duplicate
Procedure Reason
49 2 IS X [0..0] X [0..0] Result Handling
50 250 CWE X [0..0] X [0..0] Parent Universal Service Identifier
OBR-1 Set ID (SI)

(PN 206797-101) January, 2012
OBR-4 Universal Service Identifier (CE)
HL7 Definition: This element contains the identifier code for the requested
observation, test, or battery. Its value can be based on local or universal codes.
This specification: For ARCHITECT, only individual tests can be ordered.
Identification of batteries (panels) through this interface is not supported.
ARCHITECT supports only its own local coding system, which is the assay
number and optional dilution protocol name as defined for the ARCHITECT
Instrument.
OBR-4 Sender:
Table 3.65: Element: OBR-4 Universal Service Identifier (Sender)

Identifier (ST) R
Assay Identifier (ST) R 4 Assay number for the test.
Dilution protocol (ST) RE 10 Dilution protocol name.
NOTE: No dilution protocol name is provided
for calibrator results.
Text (ST) R 10 Assay name for the test.

OBR-4 Receiver:
Table 3.66: Element: OBR-4 Universal Service Identifier (Receiver)

Identifier (ST) R
Assay Identifier (ST) R 4 Assay number for the test.
Dilution protocol (ST) RE 10 Dilution protocol name. If blank, the default
protocol for the assay is selected.
Text (ST) RE 10 Assay name for the test may be empty and is
ignored if present on received messages. Only
the alternate identifier component is used to
identify the test.

(PN 206797-101) January, 2012
OBR Segment Section 3

Sample value(s):
241^TSHÂRCHITECT
241&DILUTION1^TSHÂRCHITECT
OBR-11 Specimen Action Code (ID)
HL7 Definition: This field represents the action to be taken with respect to the
specimens that accompany or precede this order. This field further qualifies
(when appropriate) the general action indicated by the order control code
contained in the accompanying ORC segment.
This specification:
OBR-11 Sender:
This element is not supported.
OBR-11 Receiver:
Only values from HL7 Table 0065 are supported.
Table 3.67: Subset of HL7 Table 0065: Specimen Action Code

A Add ordered tests
to the existing
specimen
* All others, Treated as new
including empty
(not specified)
Table 3.68: Example use of ORC-1 and OBR-11 combinations
ORC-1 OBR-11 Comment

Order Specimen Action Code
Control
NW A Process as a mandatory added test order. It is
added to the test order list regardless whether
the same test order exists (Pending, Scheduled,
or Running) in the Instrument’s database.
NW * Process as a new test order. If the same test
order for this sample ID already exists (Pending,
Scheduled, or Running), the system considers
this an invalid request.

(PN 206797-101) January, 2012
ORC-1 OBR-11 Comment

Order Specimen Action Code
Control
CA * Process as a cancelled test order. Only the first
Pending test order for the specified test is
cancelled. Cannot cancel a test that is
Scheduled, Running or Complete.
OBR-25 Result Status (DI)
HL7 Definition: This conditional field contains the status of results for this order
and is required whenever the OBR is contained in a report message. It is not
required as part of an initial order.
This specification: Only the following subset of codes from HL7 Table 0123 are
allowed.
OBR-25 Sender:
Only the following values from HL7 Table 0123 are supported.
Table 3.69: Subset of HL7 Table 0123: Result Status
Value Description
F Final results
OBR-25 Receiver:
This element is not supported.

(PN 206797-101) January, 2012
OBX Segment (in OUL^R22 specimen result message) Section 3
OBX Segment (in OUL^R22 specimen result

message)
OBX segment structure (in OUL^R22 specimen result message)
The OBX segment is used to transmit a single observation or observation

fragment. This segment is sent by ARCHITECT but not processed, if received.
Table 3.70: OBX segment structure (in OUL^R22 specimen result message)
1 4 SI R [1..1] - - Set ID - OBX
2 2 ID R [1..1] - - Value Type
3 250 CE R [1..1] - - Observation Identifier
4 1 ST X [0..0] - - Observation Sub-ID
5 99999 varies R [1..1] - - Observation Value
6 250 CE C [0..1] - - Units
7 60 ST RE [0..1] - - References Range
8 8 IS RE [0..*] - - Abnormal Flags
9 5 NM X [0..0] - - Probability
10 2 ID X [0..0] - - Nature of Abnormal Test
11 1 ID R [1..1] - - Observation Result Status
12 26 TS X [0..0] - - Effective Date of Reference
Range Values
13 20 ST X [0..0] - - User Defined Access Checks
14 26 TS X [0..0] - - Date/Time of the Observation
15 250 CE X [0..0] - - Producer's Reference
16 250 XCN RE [0..*] - - Responsible Observer
17 250 CE X [0..0] - - Observation Method
18 25 EI R [2..2] - - Equipment Instance Identifier
19 26 TS R [1..1] - - Date/Time of the Analysis
20 705 CWE X [0..0] - - Observation Site
21 427 EI X [0..0] - - Observation Instance Identifier
22 705 CNE X [0..0] - - Mode Code
23 567 XON X [0..0] - - Performing Organization Name
24 631 XAD X [0..0] - - Performing Organization Address
25 3002 XCN X [0..0] - - Performing Organization Medical
Director

(PN 206797-101) January, 2012
Section 3 OBX Segment (in OUL^R22 specimen result message)
OBX-1 Set ID (SI)
HL7 Definition: This field contains the sequence number. This field is used to
identify segment instances in message structures (segment groups) where the
segment repeats within that structure. The sequence number of the first
occurrence of the segment is one, the sequence number of the second
occurrence is two, and subsequent instances follow the same convention.
OBX-2 Value Type (ID)
HL7 Definition: This field contains the format of the observation value in OBX.
Use of the SN data type is preferred over use of the ST data type. Although NM
is a valid type, observations that are usually reported as numbers sometimes
have the string (ST) data type, because non-numeric characters are often
reported as part of the result. An example is ">300," to indicate the result was
off-scale for the Instrument. In this example, > is a symbol, and the digits are
considered to be a numeric value. However, the structured numeric (SN) data
type now accommodates non-numeric reporting and permits the receiving
system to interpret the magnitude.
This specification: Only the following subset of values from HL7 Table 0125 are
allowed.
Table 3.71: Subset of HL7 Table 0125: Value Type

CE Coded Entry Used to report exception code (reason test failed to
produce a final result yet)
NM Numeric Numeric result value only
SN Structured Used when result is above or below dynamic range of
Numeric assay (> or <)
ST String Interpretation string result
OBX-3 Observation Identifier (CE)
HL7 Definition: This field contains a unique identifier for the observation.
This specification: Multiple result parts are reported for each assay, depending
on the test:
• result concentration/index value for the test
• raw/preliminary Instrument response value used to calculate the
concentration/index result
• qualitative result interpretation assigned by the Instrument based on the
result concentration/index value

(PN 206797-101) January, 2012
This element is used to distinguish the different parts of the observation (result).
The Alternate Identifier component contains a sub-component suffix. The first
sub-components identify the assay number and dilution, as used in OBR-4
Universal Service Identifier. The last sub-component distinguishes the result
type.
Table 3.72: Element: OBX-3 Observation Identifier

Identifier (ST) R - -
Assay Identifier (ST) R 4 Assay number for the test
Dilution protocol (ST) RE 10 Dilution protocol used to produce result
NOTE: No dilution protocol name is provided
for calibrator results.
Result Type (IS) R 1 Type of result

Table 3.73: Local Table 9001: Result Type as used in OBX-3, Component 1,
sub-component 4

F Final result Primary result value for the test run - the quantitative
concentration or result
index value
P Preliminary Instrument response value used to calculate the result
Instrument concentration/index value. Not applicable for calculated
response tests.
I Interpretative Qualitative interpretation assigned by the Instrument
result based on the result concentration/index value. Not
applicable to all assays.
X Exception result Test exception - attempt to run test on specimen failed.
The reason for failure is reported.
Sample value(s):
0241&UNDILUTED&F^TSHÂRCHITECT [Result concentration for TSH (assay

#241)]
0241&UNDILUTED&P^TSHÂRCHITECT [Instrument response for TSH (assay

#241)]

(PN 206797-101) January, 2012
OBX-5 Observation Value (varies)
HL7 Definition: This field contains the value observed by the observation
producer. The field, OBX-2 Value Type, contains the data type for this field
according to which observation value is formatted.
This specification: The observation value is reported using one of the allowed
value types as specified in OBX-2. This field contains the result value for the
test result part identified in OBX-3 Observation Identifier.
If the result type is for an exception result, the CE data type is used to report the
exception code as the reason the test failed to run.
Table 3.74: Element: OBX-5 Observation Value (when CE data type)

Identifier (ST) R 4 Four (4)-digit exception/error code
Text (ST) R 260 Text message associated with exception, in the
language currently configured on ARCHITECT
Sample value(s):
7.3 [Numeric (NM) value type]
>^100 [Structured Numeric (SN) value type]
REACTIVE [String data (ST) value type]
1051Ûnable to calculate result, [Exception result (CE) value type]

absorbance exceeded optical
limitsÂRCHITECT
OBX-6 Units (CE)
HL7 Definition: When the value of an observation is measured on a continuous

scale, measurement units are reported in the units field of the OBX segment. All
fields that contain units are CE data type.
This specification: This field is populated with the units that apply to the result.
Condition: The value of this field is dependent on the value of OBX-3
Observation ID result type:
Result Type Description of OBX-6 Contents
F Result units for the test

(PN 206797-101) January, 2012
Result Type Description of OBX-6 Contents

P Response units (RLU, Abs, or mV)
I Empty
X Empty
For ARCHITECT, the units of measure for each assay are defined in the assay
definition and can be selected by the Instrument operator. No universal coding
system is supported.
Table 3.75: Element: OBX-6 Units

Identifier (ST) R 7 Unit of measure configured on Instrument.
Text (ST) X
OBX-7 Reference Range (ST)
HL7 Definition: For numeric values, the suggested format of reference ranges is
lower limit-upper limit, when both lower and upper limits are defined (for
example, 3.5-4.5).
This specification: If OBX-3, Identifier.Result Type subcomponent is F, this field
is populated:
• For control results - control min-max range, as configured on ARCHITECT
• For patient results - empty or minimum-maximum range, if a normal/
therapeutic range has been defined on ARCHITECT for the assay
If populated, the field must conform to the HL7 Definition of this field.
OBX-8 Abnormal Flags (IS)
HL7 Definition: This field contains a table lookup indicating the normality of the
result.
This specification: If OBX-3, Identifier.Result Type subcomponent is F, OBX-8
contains ARCHITECT-defined result flags (if any) that are assigned to the result.
If OBX-3, Identifier.Result Type subcomponent is a value other than F, this field
is empty.
This field can repeat, since multiple flags can be assigned to a result. Multiple
flags are separated by the repeat delimiter (for example, LOW~EXP).
For ARCHITECT, the following flags are allowed:

(PN 206797-101) January, 2012
Table 3.76: ARCHITECT-defined Abnormal Flags

IUO Investigation Use Assay released for investigational use only.
Only
EDIT Result Edited The result was manually edited by the Instrument operator
and was not calculated by the Instrument.
EXP Expired Reagent The result was measured using expired reagent, Pre-
Used Trigger or Trigger solutions.
EXPC Expired
Calibration Used
A#1 Only 1 read within c System assays
Absorbance limit
A#2 Only 2 reads c System assays
within Absorbance
limit
CNTL Control failure Applied to patient result when Westgard rule failure
detected by ARCHITECT.
< Below assay
dynamic range
> Above assay
dynamic range
LL Below assay panic
range
HH Above assay panic
range
LOW Below assay
normal/therapeutic
range
HIGH Above assay
normal/therapeutic
range
FLEX Flexible read time c System assays
data used
PSHH Previous Sample The result may be affected by the ICT sample that was
Extreme High measured immediately prior to this sample (c System ICT
assays).
1-2s Westgard rule flag Applies only to control results.
1-3s Westgard rule flag Applies only to control results.
2-2s1R1 Westgard rule flag Applies only to control results.
M
2-2s1Rx Westgard rule flag Applies only to control results.
M
2-2sxR1 Westgard rule flag Applies only to control results.
M

(PN 206797-101) January, 2012

R-4s Westgard rule flag Applies only to control results.
4-1s1M Westgard rule flag Applies only to control results.
4-1sxM Westgard rule flag Applies only to control results.
10-x1M Westgard rule flag Applies only to control results.
10-xxM Westgard rule flag Applies only to control results.
OBX-11 Observation Result Status (ID)
HL7 Definition: This field contains the observation result status and reflects the
current completion status of the results for one Observation Identifier.
This specification: The field can contain a subset of values taken from HL7 User
Defined Table 0085.
Table 3.77: Subset of HL7 User Defined Table 0085 - Observation Result
Status

F Final results
X Results cannot be Test Exception on ARCHITECT. Rerun may be possible if
obtained situation that led to exception is resolved.
OBX-16 Responsible Observer (XCN)
HL7 Definition: When required, this field contains the identifier of the individual
directly responsible for the observation (for example, the person who either
performed or verified it). In a nursing service, the observer is usually the
professional who performed the observation (for example, the professional who
took the blood pressure). In a laboratory, the observer is the technician who
performed or verified the analysis.
This specification: For ARCHITECT, this element can repeat two times. The first
repeat is used for the Operator ID logged into the system at the time of order (if
any). The second repeat is the Operator ID logged into the system at the time of
result release (if any). It is not required for an operator to be logged in at the
time of either event, so either or both repeats could be empty. Only the first
component of each repeating element is populated.
Table 3.78: Element: OBX-16 Responsible Observer (XCN)
Component/Sub-component Usage LEN

ID number (ST) R 12
family name (FN) X
family name (ST) X
own family name prefix (ST) X
own family name (ST) X

(PN 206797-101) January, 2012

family name prefix from partner/spouse (ST) X
family name from partner/spouse (ST) X
given name (ST) X
second and further given names or initials thereof (ST) X
suffix (for example, JR or III) (ST) X
prefix (for example, DR) (ST) X
degree (for example, MD) (IS) X
source table (IS) X
assigning authority (HD) X
name type code (ID) X
identifier check digit (ST) X
code identifying the check digit scheme employed (ID) X
identifier type code (IS) X
assigning facility (HD) X
name representation code (ID) X
name context (CE) X
name validity range (DR) X
name assembly order (ID) X
effective date (TS) X
expiration date (TS) X
professional suffix (for example, MD) (ST) X
assigning jurisdiction (CWE) X
assigning agency or department (CWE) X
Sample value(s):
OPER1~OPER2 [OPER1 at time of order, OPER2 at time of release]
~OPER2 [no login at time of order, OPER2 at time of release]
OBX-18 Equipment Instance Identifier (EI)
HL7 Definition: This field identifies the Equipment Instance that produces the
observation (for example, Analyzer, Analyzer module, group of Analyzers). The
source of this identifier is an institution's master list of equipment, where the
institution is specified by the namespace ID or, if blank, by the Producer's ID
(OBX-15). The equipment type, serial number, etc., are retrievable from this
master list. However, this information is not transferred with every OBX. This
field repeats, for the hierarchical representation of the equipment, beginning with
the lowest level (for example, module of an Instrument, Instrument consisting of
modules, cluster of multiple Instruments).
more assay modules. The entire system has a serial number, and each module

(PN 206797-101) January, 2012
has a serial number and a module ID. Since this element repeats, to allow for
the hierarchical representation of the equipment (lowest level first), the first
repeat is the module serial number/ID that performed the test, except for
calculated test results. The first repeat for calculated test results is the SCC
serial number. The second repeat is the serial number of the entire Instrument
system.
Table 3.79: Element: OBX-18 Equipment Instance Identifier (EI)

Entity Identifier (ST) R First repeat: module serial number/ID.
Second repeat: system serial number.
Serial Number RE 11 Module or System Serial Number
Module ID RE 1 Module ID (1 - 5). Applies only to Module,
empty for System.
Namespace ID (IS) X
Universal ID (ST) X
Sample value(s):
i2SR0100&2~10852 [Module SN: i2SR0100, Module ID:2, System SN: 10852]
OBX-19 Date/Time of the Analysis (TS)
HL7 Definition: This field is used to transfer the time stamp associated with
generation of the analytical result by the Instrument specified in OBX-18.
This specification: Contains the date and time the test processing completed.
Neither the Time zone indicator nor the Degree of precision component is
supported.
Table 3.80: Element: OBX-19 Date/Time of Analysis

(PN 206797-101) January, 2012
Section 3 OBX Segment (in OUL^R24 calibration result message)
OBX Segment (in OUL^R24 calibration result

message)
OBX segment structure (in OUL^R24 calibration result message)
The OBX segment is used to transmit a single observation or observation

fragment. This segment is sent by ARCHITECT but not processed, if received.
Table 3.81: OBX segment structure (in OUL^R22 specimen result message)
1 4 SI R [1..1] Set ID - OBX
2 2 ID R [1..1] Value Type
3 250 CE R [1..1] Observation Identifier
4 1 ST X [0..0] Observation Sub-ID
5 99999 varies R [1..1] Observation Value
6 250 CE X [0..0] Units
7 60 ST X [0..0] References Range
8 5 IS X [0..0] Abnormal Flags
9 5 NM X [0..0] Probability
10 2 ID X [0..0] Nature of Abnormal Test
11 1 ID R [1..1] Observation Result Status
12 26 TS X [0..0] Effective Date of Reference
Range Values
13 20 ST X [0..0] User Defined Access Checks
14 26 TS X [0..0] Date/Time of the Observation
15 250 CE X [0..0] Producer's Reference
16 250 XCN RE [0..*] Responsible Observer
17 250 CE X [0..0] Observation Method
18 25 EI R [2..2] Equipment Instance Identifier
19 26 TS R [1..1] Date/Time of the Analysis
20 705 CWE X [0..0] Observation Site
21 427 EI X [0..0] Observation Instance Identifier
22 705 CNE X [0..0] Mode Code
23 567 XON X [0..0] Performing Organization Name
24 631 XAD X [0..0] Performing Organization Address
25 3002 XCN X [0..0] Performing Organization Medical
Director

(PN 206797-101) January, 2012
OBX Segment (in OUL^R24 calibration result message) Section 3
OBX-1 Set ID (SI)
segment instances in message structures (for example, segment group) where
the segment repeats within that structure. On the first occurrence of the
segment, the sequence number is one, and on the second occurrence, the
sequence number is two. Successive segments are numbered incrementally.
If the segment occurs only one time within a message structure, its value is "1".
If the message structure (for example, segment group) repeats, the first
occurrence of the segment in each segment group is "1".
OBX-2 Value Type (ID)
HL7 Definition: This field contains the format of the observation value in OBX.
This specification: Assay calibration result data and statistics from ARCHITECT
are sent as a text blob using the HL7 ED (Encapsulated Data) type. For more
information, see the description of OBX-5 Observation Value.
Table 3.82: Subset of HL7 Table 0125: Value Type

ED Encapsulated Calibration Curve results as a text blob
Data
OBX-3 Observation Identifier (CE)
HL7 Definition: This field contains a unique identifier for the observation.
This specification: This element identifies the assay calibration results for the
specified assay.
Table 3.83: Element: OBX-3 Observation Identifier

Identifier (ST) R
Assay Identifier (ST) R 4 Assay number for the test
Dilution protocol (ST) RE 10 Dilution protocol used to produce result
Result Type (IS) R 1 Type of result
Name of Coding System (ID) R 9 “ARCHITECT” (without quotation marks)

(PN 206797-101) January, 2012
Table 3.84: Result Type as used in OBX-3, component 1, subcomponent 4

C Calibration Result Assay calibration results for the assay
Sample value(s):
0241&UNDILUTED&C^TSHÂRCHITECT [Result calibration for TSH (assay #241)]
OBX-5 Observation Value (ED)
HL7 Definition: This field contains the value observed by the observation
producer. OBX-2 Value Type contains the data type for this field, based on
which observation value is formatted.
This specification: Assay calibration result data and statistics from ARCHITECT
can vary greatly, based on the underlying math model and calibration type
performed (for example, full or adjust). Rendering this highly variable result data
as discrete elements in HL7 OBX segments is complex. Therefore, the OBX
segment for a calibration result contains a plain-text format rendered by
ARCHITECT that can either be rendered as-is by Informatics, imported into a
spreadsheet, or parsed to extract specific data elements. The format of this text
matches the format of the assay calibration archive file that can be written to a
CD on ARCHITECT. The fields in the text are tab-delimited. The date formats
are based on the date format selected in the ARCHITECT system configuration.
NOTE: Per HL7, values for Type of Data and Data subtype elements contain the
values of MIME media types and MIME media subtypes, established in
accordance with RFC 2046. The encoding used is Base64, in accordance with
MIME standard RFC 1521.
Table 3.85: Element: OBX-5 Observation Value (ED) - Calibration Results

Source Application (HD) X
Type of Data (ID) R 4 text
Data subtype (ID) R 5 plain
Encoding (ID) R 6 Base64 (taken from HL7 Table 0299)
Data (TX) R 65535 Calibration result in Base64 encoding
Sample value(s):
^text^plain^Base64^JVBERi0xLjMKJeTjz9IKNSAwI…(more bytes)
Examples of the ARCHITECT Calibration Text Format that is encoded in Base64:
NOTE: Format can vary, based on the particular math model and calibration
type. Capitalized name labels and value enumerates are not translated based on
ARCHITECT language setting. They are always as specified in the following
examples.

(PN 206797-101) January, 2012
Example 1:
ASSAY TSH
ASSAY NUMBER 241
REAGENT LOT 75611M100
REAGENT S/N 01976
REAGENT EXP DATE 10.06.2010
CAL STATUS Active
CAL DATE/TIME 09.16.2009 15:19
CAL METHOD 4PLC Y
CAL TYPE Adjust
CAL LOT 50935JN00
CAL LOT EXP DATE 02.29.2008
MODULE/SN 2/iSR12345
OPERATOR ID TECH1
ERROR CODE
CAL 1 RATIO 0.594
CAL 2 RATIO 0.822
CAL ID MEAN RLU REP 1 RLU REP 2 RLU
Cal 1 184.0 167 201
Cal 2 1893970.5 1901256 1886685
CONCENTRATION REF CURVE RLU FIT CURVE RLU
0.00 310 184.5
0.50 58804 47671.5
2.00 220292 184287.7
10.00 943685 771465.2
40.00 2305140 1895710.1
100.00 3249795 2668491.5
Example 2:
ASSAY Ca
ASSAY NUMBER 1008
REAGENT LOT 64071HW00
REAGENT S/N 38934
REAGENT EXP DATE 03.31.2010
CAL STATUS Expired
CAL DATE/TIME 09.23.2009 10:28
CURVE EXP FULL 11.03.2009 10:28
CAL METHOD Linear
CAL TYPE Full
CAL LOT 49585-2
CAL LOT EXP DATE 12.31.2008
MODULE/SN 1/c1670188
OPERATOR ID ADMIN
ERROR CODE
CAL ID CONCENTRATION CAL ABS CAL FACTOR REP 1 ABS REP 2
ABS REP 3 ABS
Blank 0.000 0.1252 NA 0.1250 0.1252 0.1255
Cal 1 2.250 0.3029 7.4282 0.4302 0.4275 0.4281
Cal 2 3.230 0.4241 8.0858 0.5496 0.5482 0.5493

(PN 206797-101) January, 2012
OBX-11 Observation Result Status (ID)
HL7 Definition: This field contains the observation result status and reflects the
current completion status of the results for one Observation Identifier.
This specification: This element can contain a subset of values taken from HL7
User Defined Table 0085.
Table 3.86: Subset of HL7 User Defined Table 0085 - Observation Result
Status

F Final results Successful calibration
X Results cannot be Failed calibration
obtained
OBX-16 Responsible Observer (XCN)
HL7 Definition: When required, this field contains the identifier of the individual
directly responsible for the observation (the person who either performed or
verified it). In a nursing service, the observer is usually the professional who
performed the observation (for example, took the blood pressure reading). In a
laboratory, the observer is the technician who performed or verified the analysis.
This specification: For ARCHITECT, this element can repeat two times. The first
repeat is used for the Operator ID logged into the system at time of order (if
any), and the second repeat will be the Operator ID logged into the system at
the time of result release (if any). It is not required for an operator to be logged
in at the time of either event. Therefore, either or both repeats could be empty.
Only the first component of each repeating element is populated.
Table 3.87: Element: OBX-16 Responsible Observer (XCN)

ID number (ST) R 12
family name (FN) X
family name (ST) X
given name (ST) X
second and further given names or initials thereof (ST) X

(PN 206797-101) January, 2012

source table (IS) X
identifier type code (IS) X
name context (CE) X
Sample value(s):
OPER1~OPER2 [OPER1 at time of order, OPER2 at time of release]
~OPER2 [no login at time of order, OPER2 at time of release]
OBX-18 Equipment Instance Identifier (EI)
HL7 Definition: This field identifies the Equipment Instance that produces the
observation (for example, Analyzer, Analyzer module, group of Analyzers). The
source of this identifier is an institution's master list of equipment, where the
institution is specified by the namespace ID or, if blank, by the Producer's ID
(OBX-15). The equipment type, serial number, etc., are retrievable from this
master list. However, this information is not transferred with every OBX. This
field repeats, for the hierarchical representation of the equipment, beginning with
the lowest level (for example, module of an Instrument, Instrument consisting of
modules, cluster of multiple Instruments).
more assay modules. The entire system has a serial number, and each module
has a serial number and a module ID. Since this element repeats, to allow for
the hierarchical representation of the equipment (lowest level first), the first
repeat is the module serial number/ID that performed the calibration. The
second repeat is the serial number of the entire Instrument system.

(PN 206797-101) January, 2012
Table 3.88: Element: OBX-18 Equipment Instance Identifier (EI)

Entity Identifier (ST) R First repeat: module serial number/ID.
Second repeat: system serial number.
Serial Number RE 11 Module or System Serial Number
Module ID RE 1 Module ID (1 - 5). Applies only to Module,
empty for System
Namespace ID (IS) X
Universal ID (ST) X
Sample value(s):
i2SR0100&2~10852 [Module SN: i2SR0100, Module ID:2, System SN: 10852]
OBX-19 Date/Time of the Analysis (TS)
HL7 Definition: This field is used to transfer the time stamp associated with
generation of the analytical result by the Instrument specified in OBX-18
Equipment Instance Identifier.
This specification: This field contains the date and time the calibration
completed. Neither the Time zone indicator nor the Degree of precision
component is supported.
Table 3.89: Element: OBX-19 Date/Time of Analysis

(PN 206797-101) January, 2012
ORC Segment Section 3
ORC Segment
ORC segment structure
The Common Order segment (ORC) is used to transmit elements that are
common to all of the tests ordered.
Table 3.90: ORC segment structure
1 2 ID X [0..0] R [1..1] Order Control
2 22 EI X [0..0] X [0..0] Placer Order Number
3 22 EI X [0..0] X [0..0] Filler Order Number
4 22 EI X [0..0] X [0..0] Placer Group Number
5 2 ID X [0..0] X [0..0] Order Status
6 1 ID X [0..0] X [0..0] Response Flag
7 200 TQ X [0..0] X [0..0] Quantity/Timing
8 200 EIP X [0..0] X [0..0] Parent
9 26 TS X [0..0] X [0..0] Date/Time of Transaction
10 250 XCN X [0..0] X [0..0] Entered By
11 250 XCN X [0..0] X [0..0] Verified By
12 250 XCN X [0..0] X [0..0] Ordering Provider
13 80 PL X [0..0] X [0..0] Enterer’s Location
14 250 XTN X [0..0] X [0..0] Call Back Phone Number
15 26 TS X [0..0] X [0..0] Order Effective Date/Time
16 250 CE X [0..0] X [0..0] Order Control Code Reason
17 250 CE X [0..0] X [0..0] Entering Organization
18 250 CE X [0..0] X [0..0] Entering Device
19 250 XCN X [0..0] X [0..0] Action By
20 250 CE X [0..0] X [0..0] Advanced Beneficiary Notice
Code
21 250 XON X [0..0] X [0..0] Ordering Facility Name
22 250 XAD X [0..0] X [0..0] Ordering Facility Address
23 250 XTN X [0..0] X [0..0] Ordering Facility Telephone
Number
24 250 XAD X [0..0] X [0..0] Ordering Provider Address
25 250 CWE X [0..0] X [0..0] Order Status Modifier
26 60 CWE X [0..0] X [0..0] Advanced Beneficiary Notice
Override Reason

(PN 206797-101) January, 2012
Section 3 ORC Segment
27 26 TS X [0..0] X [0..0] Filler's Expected Availability Date/
Time
28 250 CWE X [0..0] X [0..0] Confidentiality Code
29 250 CWE X [0..0] X [0..0] Order Type
30 250 CNE X [0..0] X [0..0] Enterer Authorization Mode
31 250 CWE X [0..0] X [0..0] Parent Universal Service Identifier
ORC-1 Order Control (ID)
This field may be considered the trigger event identifier for orders. It determines
the function of the order segment. Many order control codes are defined in HL7
table 0119 - Order Control Codes.
This specification:
ORC-1 Receiver:
For order downloads, this specification supports only a subset of HL7 table 0119
- Order Control Codes.
Table 3.91: Subset of HL7 Table 0119: Order Control Codes
Value Description
NW New Order. This is a new order request to the Instrument.
CA Cancel order/ service request. This is a request to cancel a
previously sent order.

(PN 206797-101) January, 2012
PID Segment Section 3
PID Segment
PID segment structure
The PID segment is used as the primary means of communicating patient

identification information. This segment contains permanent patient-identifying
and demographic information. It is optional for patient result and is not used for
control results.
Table 3.92: PID segment structure
1 4 SI R [1..1] R [1..1] Set ID - PID
2 20 CX X [0...0] X [0...0] Patient ID
3 20 CX RE [0...1] RE [0...1] Patient Identifier List
4 20 CX X [0...0] X [0...0] Alternate Patient ID - PID
5 20^20^ XPN RE [0...1] RE [0...1] Patient Name
12
6 250 XPN X [0...1] X [0...1] Mother’s Maiden Name
7 8 TS RE [0..1] RE [0..1] Date/Time of Birth
8 1 IS RE [0..1] RE [0..1] Administrative Sex
9 250 XPN X [0..0] X [0..0] Patient Alias
10 250 CE X [0..1] X [0..1] Race
11 250 XAD X [0..0] X [0..0] Patient Address
12 4 IS X [0..0] X [0..0] County Code
13 250 XTN X [0..0] X [0..0] Phone Number - Home
14 250 XTN X [0..0] X [0..0] Phone Number - Business
15 250 CE X [0..0] X [0..0] Primary Language
16 250 CE X [0..0] X [0..0] Marital Status
17 250 CE X [0..0] X [0..0] Religion
18 250 CX X [0..0] X [0..0] Patient Account Number
19 16 ST X [0..0] X [0..0] SSN Number - Patient
20 25 DLN X [0..0] X [0..0] Driver's License Number - Patient
21 250 CX X [0..0] X [0..0] Mother's Identifier
22 250 CE X [0..0] X [0..0] Ethnic Group
23 250 ST X [0..0] X [0..0] Birth Place
24 1 ID X [0..0] X [0..0] Multiple Birth Indicator
25 2 NM X [0..0] X [0..0] Birth Order
26 250 CE X [0..0] X [0..0] Citizenship
27 250 CE X [0..0] X [0..0] Veterans Military Status

(PN 206797-101) January, 2012
Section 3 PID Segment
28 250 CE X [0..0] X [0..0] Nationality
29 26 TS X [0..0] X [0..0] Patient Death Date and Time
30 1 ID X [0..0] X [0..0] Patient Death Indicator
31 1 ID X [0..0] X [0..0] Identity Unknown Indicator
32 20 IS X [0..0] X [0..0] Identity Reliability Code
35 250 CE X [0..0] X [0..0] Species Code
36 250 CE X [0..0] X [0..0] Breed Code
37 80 ST X [0..0] X [0..0] Strain
38 250 CE X [0..0] X [0..0] Production Class Code
39 250 CWE X [0..0] X [0..0] Tribal Citizenship
PID-1 Set ID (SI)
segment instances in message structures (for example, segment groups) where
the segment repeats within that structure. The sequence number of the first
If the segment occurs only once within a message structure (segment group), its
value is "1". If the message structure (segment group) repeats, the first
PID-3 Patient Identifier List (CX)
HL7 Definition: This element supports the list of identifiers (one or more) used by
the health care facility to uniquely identify a patient (for example, medical record
number, billing number, birth registry, and national unique individual identifier).
This specification: Only the first component of the first repetition in the list of
potentially repeating elements is supported. The maximum length of patient
identifier is 20 characters. A patient identifier is not required for patient test
orders.
Table 3.93: Element: PID-3 Patient Identifier List (CX)
ID (ST) R
check digit (ST) X
identifier type code (ID) X
effective date (DT) X

(PN 206797-101) January, 2012
PID Segment Section 3
expiration date (DT) X
Sample value(s):
JX2009347958 [PID of JX20099347958]
PID-5 Patient Name (XPN)
HL7 Definition: This element contains the names of the patient, with the primary
or legal name reported first. The name type code in this element is "L - Legal".
Refer to HL7 Table 0200 - Name Type for valid values. Repetition of this
element is allowed, for representing the same name in different character sets.
The component, last name prefix, is synonymous with the component, own
family name prefix, of previous versions of HL7. The component, second and
further given names or initials thereof, is synonymous with the component,
middle initial or name, of previous versions of HL7. Multiple given names and
initials are separated by spaces.
This specification: Only the first component of the first repetition in the list of
potentially repeating elements is supported.
Table 3.94: Element: PID-5 Patient Name (XPN)

family name (FN) RE
family name (ST) (last name) RE 20
given name (ST) (first name) RE 20
second and further given names or initials thereof (ST) (middle RE 12
name)
name context (CE) X
Sample value(s):

(PN 206797-101) January, 2012
Section 3 PID Segment
Doe^John^Quincy [John Quincy Doe]
Smith^Jane [Jane Smith]
PID-7 Date/Time of Birth (TS)
HL7 Definition: This element contains the date and time of the patient's birth.
This specification: Only the birth date is supported. Time of birth, time zone
indicator, and Degree of precision are not supported.
Table 3.95: Element: PID-7 Date/Time of Birth (TS)
YYYYMMDD R
Sample value(s):
19610813 [indicates date of birth of Aug. 13, 1961]
PID-8 Administrative Sex (IS)
HL7 Definition: This element contains the patient’s gender.

This specification: This field may be empty or contain only values listed in HL7
User Defined Table 0001.
Table 3.96: HL7 User Defined Table 0001 - Administrative Sex

F Female
M Male
U Unknown

(PN 206797-101) January, 2012
PV1 Segment Section 3
PV1 Segment
PV1 segment structure
The PV1 segment is used to communicate information that is specific to a

patient visit. This segment is optional for patient results and is not used for
control results.
Table 3.97: PV1 segment structure
1 4 SI R [1..1] R [1..1] Set ID - PV1
2 1 IS RE [0..1] RE [0..1] Patient Class
3 21 PL RE [0..1] RE [0..1] Assigned Patient Location
4 2 IS X [0..0] X [0..0] Admission Type
5 250 CX X [0..0] X [0..0] Preadmit Number
6 80 PL X [0..0] X [0..0] Prior Patient Location
7 250 XCN RE [0..1] RE [0..1] Attending Doctor
8 250 XCN X [0..0] X [0..0] Referring Doctor
9 250 XCN X [0..0] X [0..0] Consulting Doctor
10 3 IS X [0..0] X [0..0] Hospital Service
11 80 PL X [0..0] X [0..0] Temporary Location
12 2 IS X [0..0] X [0..0] Preadmit Test Indicator
13 2 IS X [0..0] X [0..0] Re-admission Indicator
14 6 IS X [0..0] X [0..0] Admit Source
15 2 IS X [0..0] X [0..0] Ambulatory Status
16 2 IS X [0..0] X [0..0] VIP Indicator
17 250 XCN X [0..0] X [0..0] Admitting Doctor
18 2 IS X [0..0] X [0..0] Patient Type
19 250 CX X [0..0] X [0..0] Visit Number
20 50 FC X [0..0] X [0..0] Financial Class
21 2 IS X [0..0] X [0..0] Charge Price Indicator
22 2 IS X [0..0] X [0..0] Courtesy Code
23 2 IS X [0..0] X [0..0] Credit Rating
24 2 IS X [0..0] X [0..0] Contract Code
25 8 DT X [0..0] X [0..0] Contract Effective Date
26 12 NM X [0..0] X [0..0] Contract Amount
27 3 NM X [0..0] X [0..0] Contract Period
28 2 IS X [0..0] X [0..0] Interest Code

(PN 206797-101) January, 2012
Section 3 PV1 Segment
29 4 IS X [0..0] X [0..0] Transfer to Bad Debt Code
30 8 DT X [0..0] X [0..0] Transfer to Bad Debt Date
31 10 IS X [0..0] X [0..0] Bad Debt Agency Code
32 12 NM X [0..0] X [0..0] Bad Debt Transfer Amount
33 12 NM X [0..0] X [0..0] Bad Debt Recovery Amount
34 1 IS X [0..0] X [0..0] Delete Account Indicator
35 8 DT X [0..0] X [0..0] Delete Account Date
36 3 IS X [0..0] X [0..0] Discharge Disposition
37 47 DLD X [0..0] X [0..0] Discharged to Location
38 250 CE X [0..0] X [0..0] Diet Type
39 2 IS X [0..0] X [0..0] Servicing Facility
40 1 IS X [0..0] X [0..0] Bed Status
41 2 IS X [0..0] X [0..0] Account Status
42 80 PL X [0..0] X [0..0] Pending Location
43 80 PL X [0..0] X [0..0] Prior Temporary Location
44 26 TS X [0..0] X [0..0] Admit Date/Time
45 26 TS X [0..0] X [0..0] Discharge Date/Time
46 12 NM X [0..0] X [0..0] Current Patient Balance
47 12 NM X [0..0] X [0..0] Total Charges
48 12 NM X [0..0] X [0..0] Total Adjustments
49 12 NM X [0..0] X [0..0] Total Payments
50 250 CX X [0..0] X [0..0] Alternate Visit ID
51 1 IS X [0..0] X [0..0] Visit Indicator
52 250 XCN X [0..0] X [0..0] Other Healthcare Provider
PV1-1 Set ID (SI)
PV1-2 Patient Class (IS)
HL7 Definition: This field is used by systems to categorize patients by site. This
is a required element.

(PN 206797-101) January, 2012
PV1 Segment Section 3
This specification: This field can be empty or contain only values taken from
HL7 User Defined Table 0004.
Table 3.98: Subset of HL7 User Defined Table 0004: Patient Class

N Not applicable
PV1-3 Assigned Patient Location (PL)
HL7 Definition: This field contains the patient’s initial assigned location or the
location to which the patient is being moved. The first component may be the
nursing station for inpatient locations, or clinic or department for locations other
than inpatient.
This specification: Only a single patient location element is supported by the
ARCHITECT System, so only a single component is supported for patient orders.
Table 3.99: Element: PV1-3 Assigned Patient Location (PL)

Point of Care (IS) X
Room (IS) RE 20
Bed (IS) X
Facility (HD) X
Location Status (IS) X
Person Location Type (IS) X
Building (IS) X
Floor (IS) X
Location Description (ST) X
Comprehensive Location Identifier (EI) X
Assigning Authority for Location (HD) X
Sample value(s):
^GHH ROOM 2331 [patient room location]
PV1-7 Attending Doctor (XCN)
HL7 Definition: This field contains the attending physician information. Multiple
names and identifiers for the same physician may be sent.
This specification: Only the family name component of the first repeating
element is supported.

(PN 206797-101) January, 2012
Section 3 PV1 Segment
Table 3.100: Element: PV1-7 Attending Doctor (XCN)

ID number (ST) X
family name (FN) RE
family name (ST) (last name) RE 20
given name (ST) X
middle name or initials thereof (ST) X
source table (IS) X
identifier type code (ST) X
name context (CE) X
Sample value(s):
^Welby [Dr. Welby (last name only)]

(PN 206797-101) January, 2012
QAK Segment Section 3
QAK Segment
QAK segment structure
The QAK segment contains information sent with responses to a query.
Table 3.101: QAK segment structure
1 32 ST R [1..1] R [1..1] Query Tag
2 2 ID R [1..1] R [1..1] Query Response Status
3 38 CE R [1..1] R [1..1] Message Query Name
4 10 NM X [0..0] X [0..0] Hit Count
5 10 NM X [0..0] X [0..0] This payload
6 10 NM X [0..0] X [0..0] Hits remaining
QAK-1 Query Tag (ST)
HL7 Definition: This field may be valued by the initiating system to identify the
query and may be used to match response messages to the originating query. If
it is valued, the responding system is required to echo it back as the first field in
the query acknowledgment segment (QAK).
This specification: In the query response message, this field should echo QPD-2
in the query message.
QAK-2 Query Response Status (ID)
HL7 Definition: This field allows the responding system to return a precise
response status. It is especially useful in the case where no data is found that
matches the query parameters, but where there is also no error.
This specification: This interface allows the following codes from the HL7 Table
0208.
Table 3.102: HL7 Table 0208 – Query Response Status

OK Data found; no
errors
NF No data found; no
errors
AE Application Error
AR Application Reject

(PN 206797-101) January, 2012
Section 3 QAK Segment
QAK-3 Message Query Name (CE)
HL7 Definition: This field contains the name of the query. Site-specific query
names begin with the letter "Z".
This specification: This field in the response message should echo QPD-2 in the
query message.
QAK-3 Sender:
ARCHITECT echoes the Query Name in response to the Instrument
Configuration query.
Table 3.103: Element: QAK-3 Message Query Name

Identifier (ST) R 3 "ZIC" (without quotation marks)
Text (ST) R 24 "Instrument Configuration" (without quotation
marks)
Sample value(s):
ZICÎnstrument ConfigurationÂRCHITECT
QAK-3 Receiver:
Informatics echoes the Query Name in response to the Specimen Order query.
Table 3.104: Element: QAK-3 Message Query Name

Identifier (ST) R 3 "ZOS" (without quotation marks)
Text (ST) R 18 "Order for Specimen" (without quotation
marks)
Sample value(s):
ZOSÔrder for SpecimenÂRCHITECT

(PN 206797-101) January, 2012
QPD Segment (in Order Query Messages) Section 3
QPD Segment (in Order Query Messages)

QPD segment structure (in Order Query Messages)
The QPD segment defines the parameters of the query message used by
ARCHITECT to query Informatics for specimen orders. In the query response
message (RSP), this segment echoes the QPD segment from the original query
message (QBP).
Table 3.105: QPD segment structure (in Order Query Messages)
2 32 ST R [1..1] R [1..1] Query Tag
3 20 EIP R [1..1] R [1..1] SPM-2: Specimen ID
QPD-1 Message Query Name (CE)
This specification: This is an ARCHITECT-specific message query, and it begins
with the letter "Z". The value of each component is specified below to indicate
that this is locally defined query name.
Table 3.106: Element: QPD-1 Message Query Name

Identifier (ST) R 3 "ZOS" (without quotation marks)
Text (ST) R 18 "Order for Specimen" (without quotation
marks)
Sample value(s):
ZOSÔrder for SpecimenÂRCHITECT
QPD-2 Query Tag (CE)
this field is valued, the responding system is required to echo it back as the first
field in the query acknowledgement segment (QAK).

(PN 206797-101) January, 2012
Section 3 QPD Segment (in Order Query Messages)
This specification: For each query sent, ARCHITECT generates an integer-value

query tag.
QPD-3 Specimen ID (EIP)
HL7 Definition: This is the first field for user parameters.

This specification: Per the IHE Laboratory Technical Framework, the first
parameter is the Specimen ID, as carried in SPM-2 in other messages.
ARCHITECT can query based only on the Specimen ID. No other conditional
parameters defined by IHE to be carried in QPD-4 and following are supported.
Table 3.107: Element: QPD-3 Specimen ID (EIP)

Placer Assigned Identifier (EI) R
Entity Identifier (ST) R 20
Namespace ID (IS) X
Universal ID (ST) X
Filler Assigned Identifier (EI) X
Entity Identifier (ST) X
Namespace ID (IS) X
Universal ID (ST) X

(PN 206797-101) January, 2012
QPD Segment (in Instrument Configuration Query Messages) Section 3
QPD Segment (in Instrument Configuration Query

Messages)
QPD segment structure (in Instrument Configuration Query Messages)
The QPD segment defines the parameters of the query message used by
ARCHITECT to query Informatics for configuration parameter settings. In the
query response message (RSP), this segment echoes the QPD segment from
the original query message (QBP).
Table 3.108: QPD segment structure (in Instrument Configuration Query Messages)
2 32 ST R [1..1] R [1..1] Query Tag
3 14 CE R [1..1] R [1..1] MFI-1: Master File Identifier
QPD-1 Message Query Name (CE)
This specification: This is an ARCHITECT-specific message query, and it begins
with the letter "Z". The value of each component is specified below to indicate
that this is locally defined query name.
Table 3.109: Element: QPD-1 Message Query Name

Identifier (ST) R 3 "ZIC" (without quotation marks)
Text (ST) R 24 "Instrument Configuration" (without quotation
marks)
Sample value(s):
ZICÎnstrument ConfigurationÂRCHITECT
QPD-2 Query Tag (CE)

(PN 206797-101) January, 2012
Section 3 QPD Segment (in Instrument Configuration Query Messages)
this field is valued, the responding system is required to echo it back as the first
field in the query acknowledgement segment (QAK).
This specification: For each query, the sending system generates a query tag
value.
QPD-3 Master File Identifier (CE)
HL7 Definition: This is the first field for user parameters.

This specification: This field identifies the category of Instrument configuration
parameters. This category is equivalent to the HL7 concept of a Master File, and
it is encoded per the HL7 MFI-1 Master File Identifier component. This field
contains values that extend HL7 Table 0175.
Table 3.110: Element: QPD-3 Master File Identifier (CE)

Identifier (ST) R 3 Identifier taken from Table 0175
Text (ST) X
Table 3.111: Extensions to HL7 Table 0175: Master file identifier code

ASY Instrument Assay Assay Parameters for installed assays
Parameters
SYS Instrument System System Parameters Settings
Configuration
MND Maintenance and M&D Procedures that are installed
Diagnostics
TSB Electronic TSBs that are available or applied
Technical Service
Bulletins

(PN 206797-101) January, 2012
RCP Segment Section 3
RCP Segment
RCP segment structure
The RCP segment is used to restrict the amount of data that should be returned
in response to a query. This segment is sent as part of the query message.
Table 3.112: RCP segment structure
1 1 ID R [1..1] R [1..1] Query Priority
2 10 CQ X [0..0] X [0..0] Quantity Limited Request
3 1 CE R [1..1] R [1..1] Response Modality
4 26 TS X [0..0] X [0..0] Execution and Delivery Time
5 1 ID X [0..0] X [0..0] Modify Indicator
6 512 SRT X [0..0] X [0..0] Sort-by Field
7 256 ID X [0..0] X [0..0] Segment group inclusion
RCP-1 Query Priority (ID)
HL7 Definition: This field contains the time frame in which the response is
expected.
This specification: Immediate responses to queries are expected, so this element
supports only the value from the Subset of HL7 Table 0091.
Table 3.113: Subset of HL7 Table 0091 - Query Priority

I Immediate
RCP-3 Response Modality (CE)
HL7 Definition: This field specifies the timing and grouping of the response
message(s).
This specification: Immediate and real-time responses to queries are expected,
so this field contains a subset of values from HL7 Table 0394. Only the first
component is supported.
Table 3.114: Subset of HL7 Table 0394 - Response Modality

R Real time

(PN 206797-101) January, 2012
Section 3 RCP Segment
Table 3.115: Element: RCP-3 Response Modality

Identifier (ST) R 1
Text (ST) X

(PN 206797-101) January, 2012
SAC Segment Section 3
SAC Segment
SAC segment structure
The SAC segment is used to describe the specimen container.
Table 3.116: SAC segment structure
1 80 EI X [0..0] X [0..0] External Accession Identifier
2 80 EI X [0..0] X [0..0] Accession Identifier
3 80 EI X [0..0] X [0..0] Container Identifier
4 80 EI X [0..0] X [0..0] Primary (parent) Container
Identifier
5 80 EI X [0..0] X [0..0] Equipment Container Identifier
6 300 SPS X [0..0] X [0..0] Specimen Source
7 26 TS X [0..0] X [0..0] Registration Date/Time
8 250 CE X [0..0] X [0..0] Container Status
9 250 CE X [0..0] X [0..0] Carrier Type
10 80 EI R [1..1] X [0..0] Carrier Identifier
11 80 NA RE [0..1] X [0..0] Position in Carrier
12 250 CE X [0..0] X [0..0] Tray Type - SAC
13 80 EI X [0..0] X [0..0] Tray Identifier
14 80 NA X [0..0] X [0..0] Position in Tray
15 250 CE X [0..0] X [0..0] Location
16 20 NM X [0..0] X [0..0] Container Height
17 20 NM X [0..0] X [0..0] Container Diameter
18 20 NM X [0..0] X [0..0] Barrier Delta
19 20 NM X [0..0] X [0..0] Bottom Delta
20 250 CE X [0..0] X [0..0] Container Height/Diameter/Delta
Units
21 20 NM X [0..0] X [0..0] Container Volume
22 20 NM X [0..0] X [0..0] Available Specimen Volume
23 20 NM X [0..0] X [0..0] Initial Specimen Volume
24 250 CE X [0..0] X [0..0] Volume Units
25 250 CE X [0..0] X [0..0] Separator Type
26 250 CE X [0..0] X [0..0] Cap Type
27 250 CWE X [0..0] X [0..0] Additive
28 250 CE X [0..0] X [0..0] Specimen Component

(PN 206797-101) January, 2012
Section 3 SAC Segment
29 20 SN RE [0..1] RE [0..1] Dilution Factor
30 250 CE X [0..0] X [0..0] Treatment
31 20 SN X [0..0] X [0..0] Temperature
32 20 NM X [0..0] X [0..0] Hemolysis Index
33 250 CE X [0..0] X [0..0] Hemolysis Index Units
34 20 NM X [0..0] X [0..0] Lipemia Index
35 250 CE X [0..0] X [0..0] Lipemia Index Units
36 20 NM X [0..0] X [0..0] Icterus Index
37 250 CE X [0..0] X [0..0] Icterus Index Units
38 20 NM X [0..0] X [0..0] Fibrin Index
39 250 CE X [0..0] X [0..0] Fibrin Index Units
40 250 CE X [0..0] X [0..0] System Induced Contaminants
41 250 CE X [0..0] X [0..0] Drug Interference
42 250 CE X [0..0] X [0..0] Artificial Blood
43 250 CWE X [0..0] X [0..0] Special Handling Code
44 250 CE X [0..0] X [0..0] Other Environmental Factors
SAC-10 Carrier Identifier (EI)
HL7 Definition: This field identifies the carrier. It is the ID (for example, number
or bar code) of the carrier where the container (for example, tube) is located.
This specification:
SAC-10 Sender:
This field contains the sample carrier ID or sample carousel ID in which the
sample is located. If the sample is on the LAS track, this element contains "LAS"
(without quotation marks). If the sample is the ARCHITECT water blank, this
element contains "SYS" (without quotation marks).
Table 3.117: Element: SAC-10 Carrier Identifier

Entity Identifier (ST) R 6 Sample Carrier ID, Sample Carousel ID, literal
string "LAS" if from LAS track, or literal string
"SYS" if water blank sample.
Namespace ID (IS) X
Universal ID (ST) X
SAC-10 Receiver:
Not supported; ignored on received messages.

(PN 206797-101) January, 2012
SAC Segment Section 3
SAC-11 Position in Carrier (NA)
HL7 Definition: This field identifies the position of the container in the carrier (for
example, 1...3...). The sub-components allow, if necessary, to transfer multiple
axis information, such as two-dimensional carrier (X^Y).
This specification:
SAC-11 Sender:
This field contains the position in the sample carrier or sample carousel in which
the sample is located. The ARCHITECT sample carrier and carousel each has
only one dimension, therefore, only the first component is used. If the sample is
on the LAS track, this element is empty.
Table 3.118: Element: SAC-11 Position in Carrier (NA)

Value1 (NM) RE 2 Position within Carrier or Carousel ID as an
Integer (blank for LAS).
Value2 (NM) X
Value2 (NM) X
... X
SAC-11 Receiver:
Not supported; ignored on received messages.
SAC-29 Dilution Factor (SN)
HL7 Definition: This field identifies the factor of dilution already performed on
the specimen.
This specification: If a manual/offline dilution has been performed on the
specimen prior to presenting it to the Instrument, this value is populated with the
dilution factor. On ARCHITECT, when a test is ordered, the order can optionally
include a sample manual dilution factor of 1:N. As part of a result message, the
result value reported in OBX-5 for the assay result will have been scaled by this
dilution factor upon reporting. This field will be blank if no dilution factor is
provided.
Table 3.119: Element: SAC-29 Dilution Factor (SN)

Comparator (ST) X
Num1 (NM) R 1 Always 1
Separator/Suffix (ST) R 1 Always :
Num2 (NM) R 3 Integer between 2 - 999
Sample value(s):

(PN 206797-101) January, 2012
Section 3 SAC Segment
^1^:^5 [1 to 5 dilution]

(PN 206797-101) January, 2012
SFT Segment Section 3
SFT Segment
SFT segment structure
The SFT segment provides additional information about the software product(s)
used as a sending application. This segment is sent by the Instrument as part of
each message but is ignored if present on receipt by the Instrument.
Table 3.120: SFT segment structure
1 567 XON R [1..1] - - Software Vendor Organization
2 15 ST R [1..1] - - Software Certified Version or
Release Number
3 20 ST R [1..1] - - Software Product Name
4 20 ST R [1..1] - - Software Binary ID
5 1024 TX X [0..0] - - Software Product Information
6 26 TS X [0..0] - - Software Install Date
SFT-1 Software Vendor Organization (XON)
HL7 Definition: This field identifies the software vendor whose application
created this transaction. This vendor is responsible for maintaining the
application. The purpose of this field, and the remaining fields in this segment, is
to provide a more complete picture of applications that are sending HL7
messages.
This specification: This field identifies Abbott Diagnostics, and it contains the
string "ADD". Only the first field is supported.
Table 3.121: Element: SFT-1 Software Vendor Organization

Organization Name (ST) R 3 "ADD" (without quotation marks)
Organization Name Type Code (IS) X
ID Number (NM) X
Check Digit (NM) X
Check Digit Scheme (ID) X
Assigning Authority (HD) X
Identifier Type Code (ID) X
Assigning Facility (HD) X
Name Representation Code (ID) X
Organization Identifier (ST) X

(PN 206797-101) January, 2012
Section 3 SFT Segment
SFT-2 Software Certified Version or Release Number (ST)
HL7 Definition: This field contains the latest software version number of the
sending system that is compliance tested and accepted.
This specification: This field identifies the ARCHITECT software version in the
format 1.23.
SFT-3 Software Product Name (ST)
HL7 Definition: This field contains the name of the software product that
submitted the transaction.
This specification: This field identifies the ARCHITECT software product. It
contains the string "ARCHITECT" (without quotation marks).
SFT-4 Software Binary ID (ST)
HL7 Definition: This field contains an identifier issued by a vendor for each
unique software version instance, to distinguish between like versions of the
same software (for example, a checksum).
This specification: This field is not meaningful for ARCHITECT software but,
since this field is required per HL7, it is present but null ("").

(PN 206797-101) January, 2012
SID Segment Section 3
SID Segment
SID segment structure
The SID segment contains data necessary to identify the substance (for
example, reagents) used in the production of analytical test results. The
combination of the fields in this segment uniquely identify the substance.
Depending on the substance manufacturer, all or some fields are required. If the
analysis requires multiple substances, this segment repeats for each substance.
Table 3.122: SID segment structure
1 250 CE R [1..1] - - Application/Method Identifier
2 20 ST RE [1..1] - - Substance Lot Number
3 200 ST RE [0..1] - - Substance Container Identifier
4 200 CE X [0..0] - - Substance Manufacturer Identifier
SID-1 Application / Method Identifier (CE)
HL7 Definition: This field identifies the application / method used for the
analysis.
This specification: The SID segment can identify any of the following substances
used in the production of the result.
• assay-specific reagents
• multi-test bulk liquid reagents (for example, Trigger solution)
To fully identify a substance, both an identifier and a substance type are

needed. In the INV segment, these are INV-1 and INV-3 elements. Since the SID
segment does not have a substance type field, these elements are combined in
SID-1.
Table 3.123: Element: SID-1 Application / Method Identifier (CE)

Identifier (ST) R
Substance Version (NM) RE 1 Version of substance (if applicable)
Substance Type (ST) R 2 Type of substance (for example, Reagent,
Bulk Supply)
Text (ST) X

(PN 206797-101) January, 2012
Section 3 SID Segment

Each of the sub-components can vary based on the type of substance. The
Substance Type sub-component contains one of the following values, taken
from HL7 Table 0384.
Table 3.124: Subset of HL7 Table 0384: Substance Type

SR Single Test Assay Specific Reagent Pack
Reagent
LI Measurable Liquid for example, i System Pre-Trigger, Trigger, Wash Buffer
Item for example, c System reference, wash, and detergent
solutions
OT Other for example, c System ICT Module
SC Countable Solid for example, i System Reaction Vessels
Item
SID-1 Sender (Assay reagent sent with results message):

• Substance Identifier: Reagent Configuration ID.
– For i System reagents, this is a 4-digit number.
– For c System reagents, this is an N-character identifier.
• Substance Version: reagent configuration version (1-digit number)
• Substance Type: SR
Sample value(s):
1024&2&SR [Reagent ID 1024, version 2]
AST00&1&SR [Reagent ID AST00, version 1]
SALINE&1&SR [Reagent ID SALINE, version 1]
SID-1 Sender (Bulk supplies/waste sent with results message):

Substance Identifier: Taken from the table, SID-1 Substance Identifier Sub-
component for Bulk Supplies.
Table 3.125: SID-1 Substance Identifier Sub-component for Bulk Supplies
Value Description
PRE_TRIGGER i System Pre-Trigger solution
TRIGGER i System Trigger solution

(PN 206797-101) January, 2012
SID Segment Section 3
Value Description
WASH_BUFFER i System Wash Buffer solution
ICT_REFERENCE c System ICT Reference solution
ALKALINE_WASH c System Alkaline Wash solution
ACID_WASH c System Acid Wash solution
DETERGENT_A c System Detergent A solution (can reside in Sample Carousel
and Reagent Supply Areas)
10_DETERGENT_B c System 10% Detergent B solution (can reside in Reagent
Supply Areas)
0.5_ACID_WASH c System 0.5% Acid Wash (can reside in Sample Carousel and
Reagent Supply Areas)
ICT_MODULE c System ICT module
RV i System Reaction Vessel

Substance Type: LI or SC
Sample value(s):
PRE_TRIGGER&&LI [Pre-trigger bulk solution]
RV&&SC [Reaction Vessel]
SID-2 Substance Lot Number (ST)
This specification: This field identifies the master lot number of the reagent.
SID-3 Substance Container Identifier (ST)
HL7 Definition: This field specifies the container assigned by the manufacturer
during production of the substance. This identifier must be unique within specific
lot of specific application / method.
This specification: For assay specific reagents, this is the reagent pack serial
number. Bulk reagent containers are not serialized, therefore, this field may be
empty.

(PN 206797-101) January, 2012
Section 3 SPM Segment
SPM Segment
SPM segment structure
The SPM segment describes the characteristics of a single specimen. The SPM
segment relays information about the type of specimen and the date and time
the specimen was received. It differs from the intent of the OBR segment; the
OBR addresses order-specific information. It differs from the SAC segment; the
SAC addresses specimen-container attributes.
Table 3.126: SPM segment structure
1 4 SI R [1..1] R [1..1] Set ID - SPM
2 20 EIP R [1..1] R [1..1] Specimen ID
3 80 EIP X [0..0] X [0..0] Specimen Parent IDs
4 51 CWE X [0..0] X [0..0] Specimen Type
5 250 CWE X [0..0] X [0..0] Specimen Type Modifier
6 250 CWE X [0..0] X [0..0] Specimen Additives
7 250 CWE X [0..0] X [0..0] Specimen Collection Method
8 51 CWE X [0..0] X [0..0] Specimen Source Site
9 250 CWE X [0..0] X [0..0] Specimen Source Site Modifier
10 250 CWE X [0..0] X [0..0] Specimen Collection Site
11 1 CWE R [1..1] RE [0..1] Specimen Role
12 20 CQ X [0..0] X [0..0] Specimen Collection Amount
13 6 NM X [0..0] X [0..0] Grouped Specimen Count
14 250 ST X [0..0] X [0..0] Specimen Description
15 250 CWE X [0..0] X [0..0] Specimen Handling Code
16 250 CWE X [0..0] X [0..0] Specimen Risk Code
17 26 DR RE [0..1] RE [0..1] Specimen Collection Date/Time
18 26 TS X [0..0] X [0..0] Specimen Received Date/Time
19 26 TS X [0..0] X [0..0] Specimen Expiration Date/Time
20 1 ID X [0..0] X [0..0] Specimen Availability
21 250 CWE X [0..0] X [0..0] Specimen Reject Reason
22 250 CWE X [0..0] X [0..0] Specimen Quality
23 250 CWE X [0..0] X [0..0] Specimen Appropriateness
24 250 CWE X [0..0] X [0..0] Specimen Condition
25 20 CQ X [0..0] X [0..0] Specimen Current Quantity
26 4 NM X [0..0] X [0..0] Number of Specimen Containers
27 250 CWE X [0..0] X [0..0] Container Type

(PN 206797-101) January, 2012
SPM Segment Section 3
28 250 CWE X [0..0] X [0..0] Container Condition
29 250 CWE X [0..0] X [0..0] Specimen Child Role
SPM-1 Set ID (SI)
HL7 Definition: This field contains the sequence numbe and is used to identify
SPM-2 Specimen ID (EIP)
HL7 Definition: This element contains a unique identifier for the specimen as
referenced by the Placer application, the Filler application, or both.
This specification: Only the first identifier is supported. The Placer application
role is played by the Informatics, while the Filler application role is played by
ARCHITECT. ARCHITECT does not assign its own Specimen ID but uses the
Specimen ID as assigned by the Placer. The Specimen ID is normally encoded
as the barcode on the sample tube. For assay calibrator results, the specimen
ID is the name of the calibrator specimen.
Table 3.127: Element: SPM-2 Specimen ID

Placer Assigned Identifier (EI) R
Entity Identifier (ST) R 20
Namespace ID (IS) X
Universal ID (ST) X
Filler Assigned Identifier (EI) X
Entity Identifier (ST) X
Namespace ID (IS) X
Universal ID (ST) X
SPM-11 Specimen Role (CWE)
HL7 Definition: This field indicates the role of the sample.

(PN 206797-101) January, 2012
Section 3 SPM Segment
This specification: This field identifies the role of the specimen as a Calibrator,
Patient, or QC specimen. Only the first component (Identifier) is supported. The
Identifier component contains only values from HL7 User Defined Table 0369.
SPM-11 Sender:
Table 3.128: Subset of HL7 User Defined Table 0369 - Specimen Role

C Calibrator Used to calibrate the assay
P Patient
Q Control specimen
Table 3.129: Element: SPM-11 Specimen Role

Identifier (ST) R Taken from Subset of HL7 User Defined Table
0369
Text (ST) X
SPM-11 Receiver:
This field may be empty; if so, the the specimen role defaults to Patient.
Table 3.130: Subset of HL7 User Defined Table 0369 - Specimen Role

P Patient
Q Control specimen
Table 3.131: Element: SPM-11 Specimen Role

0369
Text (ST) X

(PN 206797-101) January, 2012
SPM Segment Section 3

SPM-17 Specimen Collection Date/Time (DR)
HL7 Definition: This field indicates the date and time the specimen was acquired
from the source. The Date Range data type allows for description of specimens
collected over a period of time, such as 24-hour urine collection. For specimens
collected at a point in time, only the first component (Start Date/Time) is
populated.
This specification: Only the first component (Start Date/Time) is supported. For
patient specimens, this field is optional and can be sent if data is available. For
control specimens, this field is not used and is empty.
This element is reported to a precision of seconds. Neither the Time zone
indicator nor the Degree of precision component is supported.
Table 3.132: Element: SPM-17 Specimen Collection Start Date/Time

(PN 206797-101) January, 2012
Section 3 TQ1 Segment
TQ1 Segment
TQ1 segment structure
The TQ1 segment specifies the complex timing of events and actions, such as
those that occur in order management and scheduling systems. This segment
determines the quantity, frequency, priority, and timing of a service. For the
purposes of ARCHITECT, the Timing/Quantity segment is used to communicate
the priority at which the order is intended to be performed. If this segment is not
present, the default priority is Routine.
Table 3.133: TQ1 segment structure
1 4 SI R [1..1] R [1..1] Set ID - TQ1
2 20 CQ X [0..0] X [0..0] Quantity
3 540 RPT X [0..0] X [0..0] Repeat Pattern
4 20 TM X [0..0] X [0..0] Explicit Time
5 20 CQ X [0..0] X [0..0] Relative Time and Units
6 20 CQ X [0..0] X [0..0] Service Duration
7 26 TS X [0..0] X [0..0] Start date/time
8 26 TS X [0..0] X [0..0] End date/time
9 250 CWE R [1..1] R [1..1] Priority
10 250 TX X [0..0] X [0..0] Condition text
11 250 TX X [0..0] X [0..0] Text instruction
12 10 ID X [0..0] X [0..0] Conjunction
13 20 CQ X [0..0] X [0..0] Occurrence duration
14 10 NM X [0..0] X [0..0] Total occurrences
TQ1-1 Set ID (SI)
TQ1-9 Priority (CWE)
HL7 Definition: This field describes the urgency of the request.

(PN 206797-101) January, 2012
TQ1 Segment Section 3
This specification: This field identifies the priority of the order to be either
Routine or Stat. Only the first component (Identifier) is supported. The Identifier
component contains only values from HL7 User Defined Table 0485.
Table 3.134: Subset of HL7 User Defined Table 0485 - Priority

S Stat
R Routine
Table 3.135: Element: TQ1-9 Priority

0485
Text (ST) X

(PN 206797-101) January, 2012
Section 3 ZCL Segment
ZCL Segment
ZCL segment structure
The local (Z) calibration identification (ZCL) segment is used in the OUL^R22
message to identify the calibration used to produce a test result for patient and
control results. For calibrator results, the ZCL segment identifies the calibration
that was produced by running the calibrator.
Table 3.136: ZCL segment structure
1 250 CE R [1..1] - - Assay Identifier
2 20 ST R [1..1] - - Reagent Lot Number
3 26 TS R [1..1] - - Calibration Date and Time
ZCL-1 Assay Identifier (CE)
HL7 Definition: This field identifies the assay (test) used for the analysis.
Table 3.137: Element: ZCL-1 Assay Identifier (CE)

Identifier (ST) R 4 Assay number for the test.
Text (ST) R 10 Assay name for the test.
Sample value(s):
241^TSHÂRCHITECT
ZCL-2 Reagent Lot Number (ST)
HL7 Definition: This field specifies the lot number of the reagent.
ZCL-3 Calibration Date and Time (TS)
HL7 Definition: This field is the date/time of the assay calibration used to
produce the test result, reported to a precision of one second.

(PN 206797-101) January, 2012
ZCL Segment Section 3
Table 3.138: Element: ZCL-3 Calibration Date and Time
YYYYMMDDHHMMSS R

(PN 206797-101) January, 2012
Section 3 ZPS Segment
ZPS Segment
ZPS segment structure
The local (Z) parameters settings (ZPS) segment is used in the RSP^ZIC
message to contain the Instrument configuration parameter settings.
Table 3.139: ZPS segment structure

1 250 CE R [1..1] - - Parameter Identifier
2 2 ID R [1..1] - - Parameter Value Data Type
3 99999 Varies R [1..1] - - Parameter Value
ZPS-1 Parameter Identifier (CE)
HL7 Definition: This field identifies the entry (assay, maintenance/diagnostic

procedure, or TSB).
Table 3.140: Element: ZPS-1 Parameter Identifier (CE)

Identifier (ST) R 10 Contains one of the following, depending on
• Assay number
quotation marks)
• Maintenance / diagnostic procedure
number
• TSB number
Text (ST) R 180 Contains one of the following, depending on
• Assay name
quotation marks)
• Maintenance / diagnostic procedure name
• TSB subject
ZPS-2 Parameter Value Data Type (ID)
HL7 Definition: This field specifies data type of the ZPS-3 Parameter Value.
Parameter value data from ARCHITECT is sent as a text blob using the HL7

(PN 206797-101) January, 2012
ZPS Segment Section 3
Encapsulated Data (ED) type. For more information, see the description of
ZPS-3 Parameter Value.
Table 3.141: Subset of HL7 Table 0125 - Value Type

ED Encapsulated Parameter values as a text blob
Data
ZPS-3 Parameter Value (ED)
HL7 Definition: This field contains the actual parameter values from ARCHITECT.
These values can vary greatly, based on the parameter category. Given the
complexity of rendering this highly complex set of parameter values as discrete
elements in HL7 Z-segments, the ZPS-3 element contains a plain-text format
rendered by ARCHITECT that can either be rendered as-is by Informatics,
imported into a spreadsheet, or parsed to extract specific data elements.
NOTE: Per HL7, values for Type of Data and Data subtype elements contain the
values of MIME media types and MIME media subtypes, established in
accordance with RFC 2046. The encoding used is Base64, in accordance with
MIME standard RFC 1521.
Table 3.142: Element: ZPS-3 Parameter Value (ED)

Source Application (HD) X
Type of Data (ID) R 4 text
Data subtype (ID) R 5 plain
Encoding (ID) R 6 Base64 (taken from HL7 Table 0299)
Data (TX) R 65535 Parameter values in Base64 encoding
Sample value(s):
^text^plain^Base64^JVBERi0xLjMKJeTjz9IKNSAwI…(more bytes)
Examples of ARCHITECT Assay Parameters, encoded in Base64, follow.
NOTE: Based on the particular math model and calibration type, this format can
vary. Name labels and value enumerates are not translated based on
ARCHITECT language setting. They are always as specified below.
Example - ARCHITECT Assay Parameters:
------------------------------------------------
GENERAL PARAMETERS:
Name: B-hCG
STAT Assay
number:
30

(PN 206797-101) January, 2012
Section 3 ZPS Segment
QC by Kit/Lot:
Lot Assay
version:
9
Cal version:
1
Assay type: Two step
4-4
Pretreat option:
None Assay
availability:
Enabled
Assay status:
Primary Assay
sensitivity:
1.20
------------------------------------------------
ADDITIONAL GENERAL ASSAY PARAMETERS:
Number Label Validity Low
High
------------------------------------------------
CALIBRATION PARAMETERS:
Type: Full Calibration
method: 4PLC
Y
Adjustment method: No method Calibration Reference
Assay:
Replicates: 2 Calibration
Interval:
Standard Concentrations
Level Concentration
Cal A 0.00
Cal B 10.00
Cal C 250.00
Cal D 1000.00
Cal E 7500.00
Cal F 15000.00
Adjustors
Adjustor name Concentration
------------------------------------------------
DILUTION PARAMETERS:
Manual dilution:
On Default
dilution:
UNDILUTED
Result concentration unit: mIU/
mL
Dilution Ranges
Dilution name Low
High

(PN 206797-101) January, 2012
ZPS Segment Section 3
UNDILUTED 1.20
15000.00
1:15 7000.00
225000.00
------------------------------------------------
RESULT PARAMETERS:
Linearity range: 1.20 - 15000.00
Flag Range Specifications
Gender Age Normal range Extreme
range
------------------------------------------------
INTERPRETATION PARAMETERS:
Name Range Results
review required
Negative < 5.01
Off
5.01 to < 25.00
Off
Positive >= 25.00
Off
------------------------------------------------
RESULT UNITS:
Decimal place: 2 Result
concentration unit: mIU/
mL

(PN 206797-101) January, 2012
Revision History
Revision History
Document control numbers Revision date Content revised
206797-101 01/2012 Original issue
ARCHITECT System HL7 Interface Manual Revision History-1

(PN 206797-101) January, 2012
Revision History Revision History
NOTES
Revision History-2 ARCHITECT System HL7 Interface Manual

(PN 206797-101) January, 2012

Manual Interface Archiect Ci4100 HL7

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Manual Interface Archiect Ci4100 HL7

Загружено:

Авторское право:

Доступные форматы

ARCHITECT System HL7

Abbott Laboratories © 2012 Abbott Laboratories

Read me first ..............................................................................Read me first-1

ARCHITECT System HL7 Interface Manual Table of contents-i

Automated Equipment Inventory Message Profile ................................................................2-26

Table of contents-ii ARCHITECT System HL7 Interface Manual

ZPS Segment ..........................................................................................................................3-99

ARCHITECT System HL7 Interface Manual Table of contents-iii

Table of contents-iv ARCHITECT System HL7 Interface Manual

ARCHITECT System HL7 Interface Manual Read me first-1

Read me first-2 ARCHITECT System HL7 Interface Manual

ARCHITECT System HL7 Interface Manual Read me first-3

Read me first-4 ARCHITECT System HL7 Interface Manual

ARCHITECT System warranty statement for USA

ARCHITECT System HL7 Interface Manual Read me first-5

In Vitro Diagnostic Directive 98/79/EC

Read me first-6 ARCHITECT System HL7 Interface Manual

The following U.S. Patents are relevant to ARCHITECT i Systems or

ARCHITECT System HL7 Interface Manual Read me first-7

Key to symbols used on labeling

Authorized Representative in the European Community

In Vitro Diagnostic Medical Device

Caution, risk of electrical shock

Electrical and electronic equipment waste

Use by/Expiration date

Consult operating instructions

Caution, consult accompanying documents

Batch code/Lot number

Read me first-8 ARCHITECT System HL7 Interface Manual

Caution, hot surface

Standard international unit

ICT Cleaning Fluid

ICT Lyophilized Cleaning Solution

Water Bath Additive

Concentrated Wash Buffer

Multi-Assay Manual Diluent

ARCHITECT System HL7 Interface Manual Read me first-9

Catalog number/List number

ICT Reference Solution

Read me first-10 ARCHITECT System HL7 Interface Manual

ARCHITECT System HL7 Interface Manual Read me first-11

Read me first-12 ARCHITECT System HL7 Interface Manual

ARCHITECT System HL7 Interface Manual Section 1-1

dddd Data (variable number of bytes)

Section 1-2 ARCHITECT System HL7 Interface Manual

Active persistent connections

Active transient connections

ARCHITECT System HL7 Interface Manual Section 1-3

3. If connection is unsuccessful, wait a short time period and retry the

Section 1-4 ARCHITECT System HL7 Interface Manual

ARCHITECT System HL7 Interface Manual Section 1-5

Communication channels and message

Channel use of network connections

Section 1-6 ARCHITECT System HL7 Interface Manual

The Instrument acts as a server (receiver) for the following message

ARCHITECT System HL7 Interface Manual Section 1-7

The ARCHITECT server channel processes one message transaction at a time.

Section 1-8 ARCHITECT System HL7 Interface Manual

HL7 interface configuration settings

ARCHITECT System HL7 Interface Manual Section 1-9

Section 1-10 ARCHITECT System HL7 Interface Manual

Empty and nullified fields

ARCHITECT System HL7 Interface Manual Section 1-11

\F\ Field separator