Appendix ACommunication

A.1 Connection Control

A.1.1 MPCoagu as TCP Server
The TCP server starts monitoring after the MPCoagu is started up or the communication
setup is modified. It can accept one LIS connection which sustains until message
transmission fails, the communication setup is modified or the MPCoagu is closed.

A.1.2 MPCoagu as TCP Client

After the MPCoagu starts up or communication setup is modified, the system will try to
reconnect to LIS once. If the connection is not established in 10s, it is regarded as failed. But
the connection failing is not reported as an error on the software screen, and the system will
not try to reconnect unless the user initiate a communication call.
If the connection is not built up, the TCP client will try to reconnect when there is a
communication call. If he connection is not established in 10s, a communication error will be
reported and the communication will be canceled.
If the connection is established successfully, it will sustain until the communication setup is
modified or the MPCoagu is closed.

A.1.3 HL7 Network Communication

When the MPCoagu serves as TCP client or server in communication between network
interfaces, the message transmission is different from that between serial interfaces.
As for 1-way LIS communication messages like the analysis results of blood or control
samples, you can select synchronous response in HL7 protocol, which means after the
MPCoagu sends a message, it will send the next message after receiving the response from
LIS or after response time-out.
While saving worklist, or run a count without worklist, the MPCoagu initiates a LIS search
request, and LIS responds to the request in 10s. If the response is received successfully, the
MPCoagu will save the information or run the count in the mode acquired from LIS.

A.1.4 ASTM Communication

ASTM is different from the other two protocols as it defines a independent communication
control protocol based on TCP/IP and serial interface communication. In the ASTM protocol,
the data transmission process has two levels: message and data frame. See C.4. All the

P/N: 046-004655-00 (1.0)

messages need to be transmitted in the form of data frame, so the the smallest unit of the
communication control defined in this section is frame.
Note: in communication between network interfaces, there are more one-byte control
characters (like ENQ, ACK, NAK, EOT, etc.). To reduce the responding time, it is suggest to
disable the "NoDelay" function.

Sending Message

Figure 5Sending a message from MPCoagu to LIS

Before data transmission, the sender needs to send ENQ to the receiver asking for
establishing a connection. The receiver will send back ACK if it is ready to receive data;
otherwise it will send NAK. When the sender receives ACK, it will get ready to send data
since the connection is successfully established; otherwise, it will end the data transmission.
Figure 5shows the complete process of message transmission from MPCoagu to LIS.
When MPCoagu receives ACK, it starts sending data frames as the connection is established;
if the response is NAK, it means the connection is not established and the communication is
failed.
After the connection between MPCoagu and LIS is established successfully, the MPCoagu
starts sending data frames to LIS, and LIS responds with ACK if it is ready to receive data, or
with NAK if it wants MPCoagu to resend the data. The EOT control character will be sent after
the communication is finished.
For transmission from LIS to IPU, the roles of the sender and receiver reverses. LIS sends
ENQ asking for establishing a connection, sends data frames after receiving ACK response,
and then waits for the ACK message for successful transmission.
A transmission refers to the transmission of one message (see C.4 for message definitions).
The data frames of a message consist of middle frame(s) and end frame. The end frame
refers to the last frame of the message; while the middle frame refers to other data frame(s)
except the end frame.
The response waiting time is 4 seconds. If there is no response within 4s, the connection
establishing is regarded as failed, and the communication ends.
Resending Message

Figure 6 Resending data

In the process of data transmission, if LIS requires a data resending since there is error in the
received data frames or for other reasons, it will respond with NAK; if the sender still receives
NAK after resending the same data frame, the transmission will be regarded as failed and it
will end.
2-Way LIS

Figure 7 2-Way LIS communication from MPCoagu to LIS

First, the MPCoagu send a request message to LIS which is the same as that in the "sending
message" process; and then it waits the LIS to respond (see C.4 for message definitions) for
4s. The LIS responding process is the same as as that in the "sending message" process.
A.2 HL7 Communication Protocol
A.2.1 Overview
The LIS/HIS communication function of the MPCoagu enabled the communication between
the analyzer and the PC in laboratory through Ethernet, including sending analysis results to
and receiving worklist from lab PC.
This communication protocol is defined based on the HL7 Standards. HL7 is a series of
electronic data exchange standards for healthcare industry, which is originally defined by the
US and is now adopted worldwide. This protocol is defined based on HL7 v2.3.1. For details
of HL7 standards, see HL7 Interface Standards Version 2.3.1.

A.2.2 Low-Level Transmission Protocol

The MPCoagu communicates through TCP or serial port. See Connection Control for details.

A.2.3 HL7 Message Level Protocol

HL7 Protocol Overview

See A.4

HL7 Low-Level Message Protocol

HL7 of high-level protocol is based on messages. The function of terminating the message is
not provided. In order to determine the message boundary, the MLLP low-level protocol is
used (see HL7 Interface Standards Version 2.3.1).
Communication Level
Messages are transmitted in the following format:
<SB>ddddd<EB><CR>
among which:

<SB> = Start Block character (1 byte)

ASCII <VT>, i.e. <0x0B>. Do not confuse with the SOH or STX character in ASCII.

ddddd = Data (variable number of bytes)

ddddd is the effective data of HL7 message and expressed in the form of string. For
the strings used in the HL7 interface messages of the MPCoagu, the UTF-8 code is used.

<EB> = End Block character (1 byte)

ASCII <FS>, i.e. <0x1C>. Do not confuse with the ETX or EOT character in ASCII.

<CR> = Carriage Return (1 byte)

ASCII carriage return character, i.e. <0x0D>.
Duplex Communication Process

1)The MPCoagu directly sends the analysis results (or QC data) to LIS, as shown in the
figure below.

Figure 8 Analysis results (QC data) communication process

2)Worklist information request.

Worklist belongs to the Order message. Thus, the corresponding HL7 messages: ORM
(General Order Message), ORR (General Order Response Message) can be used. The
communication process is shown in the figure below.

Figure 9 Worklist request communication process

Mostly used messages:

ORU^R01 message: it is mostly used for the transmission of the analysis results
and QC data.
ORU Observational Results (Unsolicited) Description

MSHMessage Header, mandatory, including the communication information like

message No., sending time, message delimiter and coding method, etc.
{
PID Patient demographic information, including patient name, gender, patient
ID, date of birth, etc.
[PV1] Patient visit information, including patient type, department, bed No. and
 payer*, etc.
{
OBRsample information, including sample No., operator and time of
analysis, etc.
{[OBX]} analysis data, including analysis results and mode of analysis, etc.
}
}

ACK^R01 message: it confirms the receival of ORU^R01 message.

ACK Acknowledgment Description

MSHMessage header
MSAmessage acknowledgment, describing whether it has received the
transmitted message

ORM^O01 message: Common order message, all the actions related to order basically
use the message of this type. For example, create a new order or cancel an order. Here, the
MPCoagu requests LIS/HIS to re-fill the order message.
ORM General Order Message Dexription

MSHMessage header
{ORC}Common message of Order, including the ID information of the sample
searched

ORR^O02 Message: acknowledgement of the ORM^O01 message. Here, returning the

completed information of order (i.e. worklist).
ORR^O02 General Order Response Message Description

MSHMessage header
MSA Message acknowledgment
[PIDpatient information
[PV1]]patient visit information
{
ORCCommon message of Order, including the sample ID
[
OBRSample information
{[OBX]}Data of other sample information, including analysis mode, etc.
]
}

A.2.4 HL7 Segment Definitions

The tables in this section provide detailed definitions of the fields in all the message
segments. Each row provides the information of one field, and the content of each column is
described as follows:
1. No.: the HL7 message begins with the segment name of 3 characters followed by the fields
which are separated by delimiters. "No." refers to the order of the field in the HL7
message segment.

E.g.
PID |1 | |7393670^^^^MR||^Liu Jia||19950804000000|Female
↑ ↑ ↑
Segment name Field 1 Field 3
Note: for MSH segment, the field delimiter subsequential to the segment name is considered
to be the first field, used to define the field delimiter values of the whole message.

2. Field name: the logic sense of the field.

3. Data type: the data type based on HL7 standards. See C.5 for details;

4. Recommended max length: the recommended max length based on HL7 standards. But
during the communication process, the data length may be longer than recommended,
in which case the fields shall be identified by delimiters while analyzing the message
segment.

5. Description: description to the value of the field.

6. Example: example of the fields.

MSH

MSH (Message Header) segment contains basic information of HL7 messages, including
delimiter value, message type and coding method etc. It is the first field of every HL7
message.
Message example:
MSH|^~\&| MPCoagu |Mindray|||20130419104618||ORU^R01|1|P|2.3.1||||||UNICODE
See Table 1 for definition of each field in MSH segment.

Table 1 MSH Field Definitions

No. Field/De Dat Rec Description Example

limiter a om
Name Typ men
e ded
Max
Len
gth
1 Field ST 1 Includes the delimiter of the first field |
Seperato after the segment name; used to
r determine the delimiter values of the rest
part of the message.

2 Encodin ST 4 Includes component delimiters, repetition ^~\&

g delimiters, escape delimiters and
Characte subcomponent delimiters.
rs
3 Sending EI 180 Application of sending terminal. MPCoagu
applicati
on
4 Sending EI 180 Device of sending terminal. Value: Mindray
Facility Mindray
7 Date/Tim TS 26 Time of creating the message (in the 2013041910461
e Of format of YYYY[MM[DD[HH[MM[SS]]]]]), 8
Message using the system time

9 Message CM 7 Message type, in the format of "message ORU^R01

Type type^event type".

10 Message ST 20 Message control ID, used as the unique 1

Control identifier of a message.
ID
11 Processi PT 3 Message processing ID. Value: P
ng ID
"P": sample and worklist request
message;
"Q": QC analysis result message;
In Ack messages, it is consistent with the
previously received message.
12 Version VID 60 HL7 version number. Value: "2.3.1". 2.3.1
ID
18 Characte ID 10 Character set. UNICODE
r Set Value: "UNICODE", which means the
message in communication is expressed
in UTF-8 strings.

MSA

The MSA (Message Acknowledgement) segment contains message acknowledge

information.
Message example:
MSA|AA|1
See Table 2 for field definitions in use.

Table 2 MSA Field Definitions

No. Field/Delimiter Data Recommended Description Example

Name Type Max Length
1 Acknowledgment ID 2 Acknowledgement AA
Code code:“AA”- received;
“AE” – error; “AR”-
rejected.
2 Message Control ST 20 Message control ID, 1
ID consistent with the
MSH-10 of the received
message
6 Error Condition CE 100 Error condition (status
code), can be selected to
 transmit, and contains
error condition
descriptions; see Table 3*
for the values.

Tab;e3 Error Codes of MSA-6 Field

Status Code Status Text (MSA-3) Description/Remark

(MSA-6)
Succeeded: AA
0 Message accepted Succeed
Error status code: AE
100 Segment sequence Segment sequence in the message is wrong,
error required segment missing

101 Required field Required field in a segment missing

missing

102 Data type error Segment data type error, e.g. data type is
character instead of numeric
103 Table value not found Table value not found; not used temporarily
Rejected status AR
code:
200 Unsupported Message type not supported
message type
201 Unsupported event Event code not supported
code
202 Unsupported Processing ID not supported
processing id

203 Unsupported version Version ID not supported

id

204 Unknown key Unknown key identifier, e.g. transmitting a

identifier nonexistent patient information
205 Duplicate key Repeated key words existed
identifier
206 Application record Issues can not be executed in the application
locked saving level, e.g. database is locked
207 Application internal Other unknown error of the application
error

PID

The PID (Patient Identification) segment contains the patient demographic information.
Message example:
PID|1||7393670^^^^MR||^Liu Jia||19950804000000|Female
See Table 4 for field definitions in use.
 Table 4 PID Field Definitions

No. Field/Delimiter Data Recommended Description Example

Name Type Max Length
1 Set ID - PID SI 4 Serial No., used to 1
identify different PID
segments in a
message
3 Patient CX 20 Used as patient ID in 7393670^^^^MR
Identifier List
the sample analysis
result messages, in the
form of
"MR"Number^^^^MR”.
Used as batch No. of
control in QC
messages.
5 Patient Name XPN 48 Patient name (consists Liu Jia
of FirstName and
LastName), in the form
of
"LastName^FirstName"
7 Date/Time of TS 26 Used as time of birth 19950804000000
Birth
in sample informatio
n messages.
In the form of YYYY
[MM[DD[HH[MM[S
S]]]]].
Used as expiration da
te of the control in Q
C messages.
8 Sex IS 1 Gender, string. Female

PV1

The PV1 (Patient Visit) segment contains the patient visit information.
Message example:
PV1|1|Outpatient|Internal Medicine|||||||||||||||||Patient
See Table 5 for field definitions in use.

Table 5 PV1 Field Definitions

No. Field/Delimiter Data Recommended Description Example

Name Type Max Length
1 Set ID - PV1 SI 4 Serial No., used to identify 1
different PV1 segments in a
message.
2 Patient Class IS 1 Patient type, string, content Outpatient
not defined.
3 Assigned Patient PL 80 Patient location information, Medicine^
Location in the form of "Department^ ^BN1
^ Bed No."
20 Financial Class FC 50 Payer, string, content not MedicalIn
defined. surance

OBR

The OBR (Observation Request) segment contains the test report information.
Message example:
OBR|1||20121207011|00001^Automated Count^99MRC||20121207080000|201212071
60000|||Mindray|||Influenza|20121207083000||||||||||HM||||||||Mindray
See Table 6 for field definitions in use.

Table 6 OBR Field Definitions

No. Field/Deli Dat Reco Description Example

miter a mme
Name Typ nded
e Max
Leng
th
1 Set ID - SI 10 Serial No., used to identify different 1
OBR OBR segments in a message
2 Placer EI 22 Used as sample ID in the worklist
Order request response messages (i.e.
Number ORR^O02 messages).。

3 Filler Order EI 22 Used as sample ID in sample TestSampleID1

Number +
analysis result messages.
Used as QC file No. in QC
messages.
4 Universal CE 200 Universal service ID, used to 00001^Automated
Service ID identify different types of analysis Count^99MRC
results. See the configuration files
C
6 Requested TS 26 Draw time. 20121207080000
Date/time Used as the time when the blood
sample is drawn.
7 Observatio TS 26 Time of analysis. 20121207160000
n
Date/Time
#

10 Collector XC 60 Analysis orderer Li

Identifier * N Here indicates the person who
order the analysis.
13 Relevant ST 300 Relevant clinical information. Cold
 Clinical Can be used as the clinical
Info. diagnostic information of patient
information.
14 Specimen TS 26 Time when the sample is received. 20121207083000
Received Used as the time when the
Date/Time analysis is ordered.
*

15 Specimen CM 300 Source of the sample.

Source *
Value definitions in HL7:
BLDV: venous blood
BLDC: capillary blood
20 Filler Field ST 60 As Sample ID Number 1
1+

22 Results TS 26 Result report/Status change - Tie.

Rpt/Status Used as the time of validation.
Chng -
Date/Time
+
24 Diagnostic ID 10 Diagnosis maker ID; value: "HM" HM
Serv Sect (means Hematology)
ID

28 Result XC 150 Copy the result to.

Copies To N Used as the person who validate
the sample results.
32 Principal CM 200 Principal result interpreter. admin
Result
Used as the operator of the sample
Interpreter
+ analysis in sample messages.
Used as the operator of the QC
count in QC messages.

OBX

The OBX (Observation/Result) segment contains the parameter information of each test
result.
Message example:
OBX|6|NM|6690-2^WBC^LN||4.63|10*9/L|11.00-12.00|L|||F||E
See Table 7 for field definitions in use.

Table 7 OBX Field Definitions

No. Field/Deli Dat Reco Description Example

miter a mme
Name Typ nded
e Max
Leng
th
1 Set ID - SI 10 Serial No., used to identify different 8
OBX OBX segments in a message.
2 Value Type ID 3 Data type of the analysis result. NM
Value: "ST", "NM", "ED", "IS", etc.
3 Observatio CE 590 Analysis item identifier. 14979-9^APTT^L
n Identifier N
In the form of "ID^Name^Encode
Sys", where ID is the identifier o
f the analysis item; Name is the
description of the item; Encode
Sys is the coding system of the
item.
See the configuration files and
C for the values of the codes fo
r different items.
Note: ID and EncodeSys are used
to identify different analysis
parameters, while Name is for
description purpose rather than
identification.

5 Observatio * 6553 Analysis result data, which can be 2.20

n Value 5 numeric, string, enumeration
value, binary data, etc. See C for
detailed value definitions (Binary
data like histogram or scattergram
are converted to codes using the
Base64 coding method.

6 Units CE 60 Unit of analysis items. Use ISO Sec

standard units. See table:C for
units used in communication.
7 References ST 60 Reference range of analysis 4.00-10.00
Range results, in the form of "lower
limit-higher limit", "<upper limit" or
">lower limit".
8 Abnormal ID 5 Analysis result flags. Value defini L~A
Flags
tions:
"N": normal
"A": abnormal
"H": higher than upper limit
"L": lower than lower limit
Note: The flag for normal or
abnormal and that for high or low
result may appear in this field at
the same time. In this case, the two
types of flags are connected by a
“~”, e.g. “H~A”
11 Observ ID 1 Status of the analysis result. "F": F
Result final result.
Status

13 User ST 20 User-defined. For flags of reagent

Defined expiration or modification, etc. In
Access
 Checks the form of "Flag1~Flag2".
There are 3 types of flags in all:
O – reagent expiration
E – result edited flag
e – result changed due to the
manual editing of another
parameter result based on which it
is calculated

ORC

The ORC (Common Order) segment contains the common information of order.
Message example:
ORC|RF||SampleID||IP
See Table 8 for field definitions.

Table 8 ORC Field Definitions

No. Field/Deli Dat Reco Description Example

miter a mme
Name Typ nded
e Max
Leng
th
1 Order ID 2 Order control. RF
Control
In ORM message, the value is
"RF", which means "re-fill order
request"
In ORR message, the value is
"AF", which means "acknowledge
order re-filling"
2 Placer EI 22 Code for order placer.
Order In ORM message, the value is null.
Number In ORR message, the value is the
sample ID.
3 Filler EI 22 Code for order receiver. SampleID
OrderNum In ORM message, the value is the
sample ID. In ORR message, the
value is null.

5 Order ID 2 Order status. IP

Status In ORM message of worklist
information searching
communication, the value is "IP",
which means "the order is being
processed, but has no result yet";
in ORR message, the value is null.
A.2.5 Complete Message Examples
The two message examples below shows the communication process of sample data
Sample Message

MSH|^~\&|MPCoagu|Mindray|||20130424094913||ORU^R01|1|P|2.3.1||||||UNICODEPID|1||2
00456^^^^MR||^smith||20120430173815|malePV1|1|patienttype|dept^^205|||||||||||||||||Patient
OBR|1||1|00001^Automated
Count^99MRC||20130415173815|20130420125148|||sender|||Influenza|20130416173815|sa
mpletype|||||||20130424094852||HM||||Admin||||AdminOBX|1|IS|05007^Project
Type^99MRC||T/B/NK-Auto||||||FOBX|2|NM|30525-0^Age^LN||1|yr|||||FOBX|3|NM|20598-9^T
#^LN||37037.000| 个
/ul|||||FOBX|4|NM|20599-7^T%^LN||100.00|%|||||FOBX|5|NM|20592-2^B#^LN||0.000| 个
/ul|||||FOBX|6|NM|20593-0^B%^LN||0.00|%|||||FOBX|7|NM|20620-1^NK%^LN||0.00|%|||||FO
BX|8|NM|32515-9^CD4+T%#^LN||37037.000| 个
/ul|||||FOBX|9|NM|32516-7^CD4+T%%^LN||100.00|%|||||FOBX|10|NM|32517-5^CD8+T%#^L
N||37025.000| 个
/ul|||||FOBX|11|NM|32518-3^CD8+T%%^LN||99.97|%|||||FOBX|12|NM|20607-8^CD4+T/CD8
+T^LN||1.00||||||F

Sample Response Message

In synchronous communication of MPCoagu, each analysis result message need a response

message which contains two segments: MSH and MSA. To send a correct response
message, take into consideration that: the MSH-9 field should be ACK^R01 which indicates
that it is a sample response message; If the value in the MSA-2 field is the same with the
MSH-10 value of the received analysis result, it indicates that this response message is
corresponding to the sent analysis result. The MSA-2 value in the following example is 1
MSH|^~\&|LIS||||20130424095049||ACK^R01|1|P|2.3.1||||||UNICODEMSA|AA|1

2-Way LIS/HIS Request Message

A 2-way LIS/HIS request message contains a sample ID. After the LIS/HIS received the
request message, it will search for the corresponding patient and sample information to
provide a response.
A request response message contains two segments: MSH and ORC. The MSH segment is
almost the same with that of the analysis result message, except that the MSH-9 value is
ORM^O01. The ORC-3 field should be filled with the receiver code (in this case, the sample
ID; where in the following sample, it is SampleID1). Note that in the autoloading analysis, if
there is a barcode scanning error while sending a request message, the sample ID will be
“Invalid”.
An example of the request message is shown as follows:
MSH|^~\&|MPCoagu|Mindray|||20130424095111||ORM^O01|2|P|2.3.1||||||UNICODEOR
C|RF||1||IP
2-Way LIS/HIS Request Response Message

When the LIS received an request message, it needs to send back an request response
message. The first two message segments of the request response message are MSH and
MSA. The MSH-9 message type field (indicating the type of the segment) is filled with
ORR^O02, while the MSA segment should be filled up as shown in the following example of
the request response message. If the LIS/HIS gets searching results for the request, there
will be PID, PV1, ORC, OBR and OBX message segments after the two heading segments to
provide the patient and sample information, in the same way as the sample data message
does. The ORC segment is indispensable for an request response message with searching
results, in which the ORC-1 value is AF, and ORC-2 is the key searching field(the sample ID).
Note that the OBR-2 field indicates the sample ID, which should be the same as in the ORC-2
field; otherwise, the message will be regarded as incorrect.
An example of the request response message with searching results is shown as follows:
MSH|^~\&|LIS|LISSimulator|||20130424095815||ORR^O02|0|P|2.3.1||||||UNICODE
MSA|AA|1||||
PID|1||20123^^^^MR||LastName^fisrtName||20120422192223|male
PV1|1|waike|dept45^^234|||||||||||||||||gongfei
ORC|AF|1
OBR|1|1||00001^Automated
Count^99MRC||20130422091323||||sender||||20130422185915||||||||||HM
OBX|1|IS|05007^Project Type^99MRC||CD348||||||F
OBX|2|NM|30525-0^Age^LN||12|d|||||F
OBX|3|ST|01001^Remark^99MRC||||||||F
An example of the request response message with no search result is shown as follows, in
which the MSA-2 field indicates the result of the response. In this example, the MSA-2 value
is “AR”, indicating the request was rejected; if it is “AE", then there is an error in the request
process.
MSH|^~\&|LIS||||20130424095815||ORR^O02|1|P|2.3.1||||||UNICODEMSA|AR|9
A.3 Appendix: ASTM Communication Protocol
A.3.1 ASTM Protocol Overview
See the ASTM protocol documents for details of the protocol:
NCCLS LIS1-A (formerly ASTM 1381- 02): Data Link Protocol
NCCLS LIS2-A (formerly 1394- 97): Message Structure Protocol
Note: the characters used in ASTM protocol are standard ASCII characters (ISO 8859-1 ：
1987) unless there is a note for exception.

A.3.2 Protocol Levels

Figure 10 Levels of the ASTM protocol

Message: A complete data package is called message. It is a set of information, which can be
a sample analysis result, QC result or request information. Message is the unit of a call for
communication.
Frame: the component of a message which is the unit of communication control and
communication error identification.
The ASTM communication protocol is a protocol based on TCP/IP protocol and serial port
communication control. ASTM protocol has two layers: the low-level protocol for message
transmission, and message level protocol between MPCoagu and LIS.

A.3.3 Frame Structure

All the frame control characters are ASCII characters which shall not be contained in the text
part of the frame. As required by the protocol, the maximal data length of a frame is 64,000
bytes (including the control character).
Frame Description
Frame structure:
<STX>FN Text[<ETB>|<ETX>] C1 C2 <CR><LF>

STX: text transmission start control character;

FN: serial number of the frame, use numbers from 0 to 7 in turn (starting from 1) to
identify different frames;
Text: content of the message;
ETB: end character for text in the middle frame;
ETX: end character for text in the end frame;
C1: first-4-bit value of the check sum, expressed by 0-9 and A-F;
C2: last-4-bit value of the check sum, expressed by 0-9 and A-F;
CR: frame end "carriage return" control character
LF: frame end "line feed" control character;

Control Character

Key Dec Hex Printable Description

(decimal) (hexadecimal)

^B 2 02 <STX> Frame start character

^C 3 03 <ETX> End frame, text end character

^J 10 0A <LF> Frame end line feed

character

^M 13 0D <CR> Frame end carriage return

character

^W 23 17 <ETB> Middle frame, text end

character

^E 5 05 <ENQ> Connection establishing

request (transmission
preparation) character

^D 4 04 <EOT> Transmission completion

character

^F 6 06 <ACK> Successful reception

response character

^U 21 15 <NAK> Re-sent response

Middle Frame

Structure of a middle frame:

<STX>FN Text<ETB> C1 C2 <CR><LF>
End Frame

Structure of an end frame:

 <STX>FN Text<ETB> C1 C2 <CR><LF>
Check and Calculation

In the frame <STX> FN text [<ETB>|<ETX>] C1 C2 <CR><LF>, add every

character value from FN to [<ETB>|<ETX>] (note: do not add <STX> C1 C2 <CR><LF>),
divide the sum by 256, get the remainder, and convert it to 8bit where the 4 most significant
bits (first 4 bits) are C1, and the 4 least significant bits (last 4 bits) are C2. E.g. 01111010,
convert it to hexadecimal, that is 7A, then C1 = "7", C2 = "A".

A.3.4 Message Structure

Message Description

Message
Record 00 Record 01 Record
##
Field 00 Field Field 00 Field …
## ##
Component … Component ... Component …… Component … …
00 ## 00 ##

Message: a set of records from message header record (H) to message terminator record
(T).
Record: a set of fields. It has information about a certain subject, e.g. patient information.
The first field of each record is the record type field.
Field: a set of components. The description of special property of the record, e.g. date of
birth in patient information.
Component: basic unit of message data. E.g. for patient name, it consists of two basic units,
Last Name and First Name which are separated by component delimiter.

Maximal field length: no limit to the length of a field.

Maximal record length: no limit to the length of a record, only depends on the length limit for
character processing.

Message Coding

1）Character Limit and Coding

The message transmission is text transmission, so it is not allowed to use invisible characters.
For the universal ASCII characters:
Supported characters: 7, 9, 11, 12, 13, 32-126, 128-254
Unsupported characters: 0-6, 8, 10, 14-31, 127, 255
In the communication process, it is not allowed to use the following characters since they are
used as control characters:
 <STX>, <EOT>, <ENQ>, <ACK>, <NAK>, <ETB>, <ETX>, <CR>, <LF>.
Considering communication between different platforms, the characters which are not in
ASCII standard character set are coded using UTF-8.

2）Binary Data Coding

For raw binary data, they need to be converted to strings using BASE64 (SeeC.8) for
transmission.
Since there may be big-endian and little-endian difference at the sending end and the
receiving end, in the transmission process of raw data, if the smallest unit data of the raw
data needs to be expressed by 2 bytes or more, the raw data need to be converted to
network byte order before being coded using Base64. Take the transmission of 32-bit integer
digit group as an example. The smallest unit of the raw data (integer digit group) is integer
that is expressed by 4 bytes, so before Base64 coding, the integer digit group needs to be
converted to one-byte digit group based in network byte order, and then converted to text
using Base64.
Note: the characters are case sensitive.

delimiter

In a complete message, all the records shall be ended with <CR> (carriage return).
To identify different components, fields, or repeated texts in a record, different delimiters are
used between fields, components, and repeated texts.
ASTM use the following ASCII characters:

Record end character <CR> Carriage return character (invisible)

Field delimiter |

Repetition delimiter \

Component delimiter ^

Escape delimiter &

1）Transmission of delimiter:
The delimiter definition is in the second field of the message header record, normally in the
format "H | \ˆ & |", where H is the record type identifier, followed by 4 delimiter definitions, and
the last '|' is a field delimiter, indicating what follows is another field. The delimiters are in the
following order: field delimiter, repetition delimiter, component delimiter and escape delimiter.

2）Null delimiter:
For null field or component, if it is the last one, delimiter is not needed; if not, a delimiter for
this field/component is needed to separate it from the following field/component. That is to
say, in a record, the position of a field or a component matters. So even if a field/component is
null, the position shall be reserved by using a delimiter.
Note: according to the ASTM standard, the position of a null field/component shall be
reserved rather than being omitted.

Escape Character

While transmitting data, there may be protocol control characters or other characters that are
not allowed to transmit. In this case, these characters need to be converted to escape
character.
According to the escape character conversion rules in the ASTM standard, the escape
characters needed in message transmission are shown as follows:

Escape sequence Delimiter Remarks

&F& | Field delimiter

&R& \ Repetition delimiter

&S& ^ Component delimiter

&E& & Escape delimiter

Escape characters of low-level protocol control characters:

Escape sequence Delimiter Remarks

&X5& <ENQ>

&X4& <EOT>

&X2& <STX>

&X17& <ETB>

&X3& <ETX>

&XD& <CR>

&XA& <LF>

&X6& <ACK>

&X15& <NAK>

Note: in a message, the record terminator character (<CR>) is the protocol control character
which does not need to be converted.

Record Type

As defined in ASTM, the following record types are involved:

Record type Type identifier Remarks
 Message Header Record H Message Header Record

Patient Information Record P Patient information record

Test Order Record O Test order record

Result Record R Result record

Comment Record C (Not in use)

Scientific Record S (Not in use)

Manufacturer Information M (Not in use)

Record

Request Information Record Q Request information record

(bi-directional LIS)

Message Terminator Record L Message terminator record

Special Notice

1. Time:
Format of time:
Date: YYYYMMDD
Date+Time: YYYYMMDDHHMMSS
2. Record sequence number:
In the message level protocol, all records except message header records begin with two
fields: "Record Type ID" and "Sequence Number".
Record Type ID: record type identifier. E.g. the record type ID for patient information is "P".
Sequence Number: record sequence number, numeric string, indicating the sequence
number of the record among all records of the same type. E.g.: if there are 2 "O" records, 3
"R" records in a message, then the sequence number of the first "O" record is "1", and the
second one "2"; the sequence number of the first, second and third "R" records are "1", "2"
and "3" respectively. If there are more records of the same type, the sequence number
increases accordingly.

A.3.5 Message Records

Message Header and terminator Records

1)Message Header Record

The first record of every message is called message header record,
which consists of record delimiter definition, instrument name, instrument ID, protocol version
number, message creation time, etc.
Field Name Field Value Note:
Sequence Example
Number
Record Type ID 1 H Record type field; value fixed
Delimiter Definition 2 |\^& ASTM delimiter set; value fixed
Message Control ID 3 1 Message control ID field
Sender Name or ID 5
Manufacturer Mindray Fixed
Instrument Model BC6800 Fixed
Protocol Version Reserved
Special Instructions 11 Message text type field. See C.7
Table 7 for values.
Name Automated Count "Name" item
ID 00001 "ID" item
Processing ID 12 P Current message type; fixed to be
"P" indicating sample messages.
Version Number 13 LIS2-A2 Version number of ASTM; fixed
Date and Time of 14 20100208145026 Time of message transmission;
Message use current system time; in the
format of YYYYMMDDHHMMSS
Message Control ID: the unique identifier of a message Commonly starts from 1.
Taking the communication of sample analysis result as an exmaple, the complete message
header is shown below:
1H|\^&|1||Mindray^ BriCyte E6^||||||Automated
Count^00001||LIS2-A2|20100208145026<CR>
Note: "<CR>" stands for carriage return.

2)Message Terminator Record

The last record of every message is called message terminator record, which is defined as
follows:

Field Name Field Value Note:

Sequence Example
Number
Record Type ID 1 L Record type field; value fixed
Sequence Number 2 1 Sequence number of record; fixed
Termination Code 3 N Termination code; value: "N"; fixed
A complete message terminator record is shown as follows:
L|1|N<CR>

Patient Information Record

Mainly includes patient ID, patient name, date of birth, age, physician, department, etc.
Used in sample analysis result message and worklist request response message.

Field Name Field Value Note:

Sequence Example
 Number
Record Type 1 P Fixed
Sequence Number 2 1 Record sequence number; see
C.4.4.6 for details
Patient ID Number 3 5 333 Patient ID
Patient Name 6 Patient name
First name FirstName
Last name LastName
Birthdate 8
Date of birth 20091220000000 YYYYMMDDHHMMSS
Age 2
Age unit Y Values of age unit:
Null
Y: year
M: month
W: week
D: day
H: hour
Patient Sex 9 Female Entry by the operator (string)
Admission Status 25 Emergency Department, string displayed on
screen
Location 26
Inpatient zone EA String displayed on screen
Bed No. 32~-1 String displayed on screen
Complete record example:
P|1|||333|FirstName^LastName||20091220000000^2^Y|Female||||||||||||||||Emergency|EA^32-
1<CR>.

Test Order Record

The record of analysis sequence number, usually followed by result record.Commonly , a

Test Order Record contains sample sequence number and related information of analysis
result messages (including both sample analysis results and QC results)

Field Name Field Value Note:

Sequence Example
Number
Record Type ID 1 O Fixed
Sequence Number 2 1 Record sequence number; see
C.4.4.6 for details
Specimen ID 3 K11321 Sample ID
Requested Date and 7 20100613010203 Blood sample: time of analysis;
Time QC: time of QC run
Collection Date and 8 20100612153501 Time of sample collection
Time
Collector ID 11 Jones The person who ordered the
analysis
Relevant Clinical 14 Diagnosis Clinical diagnosis
Information
Date/Time Specimen 15 20100612153501 Date/Time when the specimen is
Received received
Specimen Descriptor 16
Specimen Type Sample Type Sample type
Specimen Source Reserved
Ordering Physician 17 XQRD Blood sample: operator; QC:
operator
User Field Number 1 19 Alice User-defined; used for validater
here
User Field Number 2 20 User-defined; used for time of
validation here
Lab Field Number 1 21 1 As Sample ID Number
Date/Time Results 23 20111220153501 Report time
Reported or Last
Modified
Report Type 26 F Report types:
F – final results; not request
response; fixed to be F
Q – has result for request
Y – no result for request
Complete record example:
O|1|K11321||||20100613010203|20100612153501|||Jones|||Diagnosis|20100612153501|Sa
mple Type^|XQRD||Alice|||20111220153501|||F<CR>

Analysis Result record

Contains sample analysis result/QC result/extend information.

Since the default fields of Patient Information Record and Test Order Record can not meet
our requirements of sample information/patient information/sample result/QC information
transmission, Result Record is used to bring extra fields for transmission. See C.4.4Message
Code for extended codes. For extended information items, only message ID and result are
needed.
Result Record is used in messages other than worklist searching messages.

Field Name Field Value Note:

Sequence Example
Number
Record Type ID 1 R Fixed
Sequence Number 2 14 Record sequence number; see
C.4.4 for details
Universal Test ID 3
Universal Test ID Universal test ID; reserved
Universal Test ID WBC Name. See Table:C
Name
Universal Test ID ID type; reserved
Type
Manufacturer’s or 6690~2 ID. See Table:C
Local Code
Data or 4 2.30 Result data
Measurement Value
Units 5 10^9/L Unit of result; use the units
displayed on screen
Reference Ranges 6 Reference range
Lower limit 4.00
Upper limit 12.00
Result Abnormal 7 Result flags
Flags
High/Low flags L H – higher than upper limit
L – lower than lower limit
Result edited flag e E – result edited flag
e – result changed due to the
manual editing of another
parameter result based on which it
is calculated
Null if the result is not edited
Suspicious flag N N - normal
A - abnormal
Reagent expiration O O – reagent expired
flag Null if the reagent is not expired
Temperature flag T T - instrument overtemperature
Null if no overtemperature
Result corrected flag C C - Result corrected flag
Null if not corrected
Out of linearity range V V - out of linearity range
flag Null if within range
Complete record example:
R|14|^WBC^^6690-2|2.30|10&S&9/L|4.00^12.00|L^e^N^O^T^C^V<CR>

Request Searching Record

Used in bi-directional LIS request (worklist request).

 Field Name Field Value Note:
Sequence Example
Number
Record Type ID 1 Q Fixed
Sequence Number 2 1 Record sequence number; see
C.4.4.6 for details
Starting Range ID 3 K11321 Sample ID in the worklist to be
Number requested
Beginning Request 7 20111220153501 Time when the request begins;
Results data and use the current system time;
Time format: YYYYMMDDHHMMSS
Complete record example:
Q|1|K11321||||20111220153501<CR>

A.3.6 Message for Communication

Note: the message examples contains complete frame header and terminator. Since special
characters may have problems in display, the frame header and terminator are replaced by
strings that can be displayed properly. E.g. use <STX> for frame header. The frames in the
example after conversion should be continuous, but the frames are separated by line feed
characters for better readability.
Sample Analysis Result Message

1)Record Structure
Record Structure:
1 Header
2 Patient
3 Order
4 Result1
5 Result2
6 Result3
......
n Message Terminator

2)Content of Sample Data

Content of sample analysis result message for communication:
Record Record Value Field Position: Component Value Value Description
Type Content
H Record header 12: message Sample Analysis See the table of OBR-4
type Result code*
P Patient 5: Patient ID The patient ID
Demographics displayed on
 screen
6: Patient name First name First name of patient
Last Name Last name of patient
8: date of birth Date of birth YYYYMMDDHHMMSS
Age
Age unit Available age units:
null, Y, M, W, D, and H,
indicating null, year,
month, week, day, and
hour respectively
9: gender Gender What displayed on
screen
25: department Department What displayed on
screen
26: location Inpatient zone What displayed on
screen
Bed No. What displayed on
screen
O Sample 3: Sample ID Sample ID What displayed on
Information screen
7: time of Time of analysis YYYYMMDDHHMMSS;
analysis what displayed on
screen
8: Time of Time of sample YYYYMMDDHHMMSS;
sample collection what displayed on
collection screen
11: The person The person who String
who ordered the ordered the
analysis analysis
14: clinical Clinical What displayed on
diagnosis diagnosis screen
15: Date/Time Date/Time when YYYYMMDDHHMMSS;
when the the specimen is what displayed on
specimen is received screen
received
16: sample type Sample type What displayed on
screen
Sample source Reserved; null
17: operator Operator What displayed on
screen
19: validater Validater What displayed on
screen
20: time of Checked at: YYYYMMDDHHMMSS;
 validation what displayed on
screen
23: Report time Report time YYYYMMDDHHMMSS;
what displayed on
screen
26: report type Result F, fixed
R Inspection Item 2: ID ID See Table:C
ID See Table:C
4: result Panel See Table:C
5: unit Null
6: reference Null
range
7: flag Null
R Payer 4: result, value displayed on screen; value same as above
R Patient type 4: result, value displayed on screen; value same as above
R APTT 2: ID; format same as above; see data type and coding system
in C.7 for the value
4: result Sample Analysis What displayed on
Result screen
5: unit Unit of sample What displayed on
analysis result screen
6: reference Upper limit What displayed on
range screen
Lower limit What displayed on
screen
7: flag Null
R PT PT: value same as above
R PT_INR PT_INR: value same as above
R TT TT: value same as above
R FIB FIB: value same as above
R II II: value same as above
R V V: value same as above
R VII VII: value same as above
R X X: value same as above
R VIII VIII: value same as above
R IX IX: value same as above
R XI XI: value same as above
R XII XII: value same as above
R FDP FDP: value same as above
R D_D D_D: value same as above
R AT_III AT_III: value same as above
R PROC PROC: value same as above
R PROS PROS: value same as above
R HEP HEP: value same as above
R LMWH LMWH: value same as above
R vWF vWF: value same as above
R LAC LAC: value same as above
R PLG PLG: value same as above
R AP AP: value same as above

3)Example of Sample Analysis Result Message

H|\^&|1||Mindray^MPCoagu^||||||Automated Count^00001|P|LIS2-A2|20141114113110
P|1|||no1234|^microowen||19860623122325^12^yr|nan||||||||||||||||dep|v44^b201
O|1|1||||20141114112359||||sender||||20141114170825||Admin||Admin|20141114113107||||||F
R|1|^Charge type^^01015|gongfei||
R|2|^APTT^^14979-9|10.00|Sec|24.00-38.00
R|3|^PT_INR^^6301-6|0.81|INR|0.75-1.35
R|4|^PT^^5902-2|10.00|Sec|11.00-16.00
R|5|^TT^^3243-3|10.00|Sec|8.00-16.00
R|6|^FIB^^3255-7|3.00|g/L|2.00-4.00
R|7|^D_D^^7799-0|0.00|μg/ml|0.00-0.00
R|8|^FDP^^29263-1|0.00|μg/ml|0.00-0.01
R|9|^AT_III^^3174-0|24.00|%|81.50-121.30 L|1|N

2-Way LIS Request Message

1)Record Structure
Record Structure:
1 Header
2 Request
3 Message Terminator

2)Content of Request Message

Content of bidirectional LIS request:
Record Record Field Position: Component Value Value Description
Type Value Content
H Message 3: message ID Message ID Message ID, which is
Header also used in analysis
Record result messages
12: message type Worklist search See the table of OBR-4
code*
Q Request 3: Sample ID Sample ID What displayed on
information screen
7: time of request Time of request YYYYMMDDHHMMSS;
time when the message
is generated
 3)Example of Request Message
H|\^&|2||Mindray^MPCoagu^||||||Worksheet request^00010|P|LIS2-A2|20141114115214

Q|1|1||||20141114115214

L|1|N

2-Way LIS Response Message

1)Record Structure
Record Structure:
1 Header
2 Patient
3 Order
4 Result1
5 Result2
6 Result3
......
n Message Terminator

2)Content of Request Response

Result of request response
Record Record Value Field Position: Component Value Value Description
Type Content
H Record 3: message ID Message ID Use the ID of the
header request message
12: message type Result of worklist See the table of OBR-4
request code*
P Patient 5: Patient ID The patient ID
Demographics displayed on
screen
6: Patient name First name First name of patient
Last Name Last name of patient
8: date of birth Date of birth YYYYMMDDHHMMSS
Age
Age unit Available age units: null,
Y, M, W, D, and H,
indicating null, year,
month, week, day, and
hour respectively
9: gender Gender What displayed on
screen
25: department Department What displayed on
screen
26: location Inpatient zone What displayed on
screen
 Bed No. What displayed on
screen
O Sample 3: Sample ID Sample ID ID of the requested
Information sample
8: Time of sample Time of sample YYYYMMDDHHMMSS
collection collection
11: The person The person who String in UI
who ordered the ordered the
analysis analysis
14: clinical Clinical diagnosis What displayed on
diagnosis screen
15: Date/Time Date/Time when YYYYMMDDHHMMSS;
when the the specimen is what displayed on
specimen is received screen
received
16: sample type Sample type What displayed on
screen
Sample source Reserved; null
26: report type Result of request Q – result of request is
found
Y – result of request is
not found
R Remarks 4: result, value displayed on screen; value same as above
R Payer 4: result, value displayed on screen; value same as above
R Patient type 4: result, value displayed on screen; value same as above
R APTT The same data format

3)Example of Request Response Message

H|\\^&|3||LISSimulator^LIS||||||Worksheet response^00011|P|LIS2-A2|20141114115252
P|1|||no1234|owen^micro||19860623122325^12^yr|nan||||||||||||||||dep|v44^b201
O|1|2|||||20141113170825|||sender||||20141114170825|||||||||||Q
R|1|^Remark^^01001|remarks
R|2|^Patient type^^01016|patientype
R|3|^Charge type^^01015|gongfei
R|4|^Patient Area^^01008|v44
R|5|^APTT^^14979-9|
R|6|^PT^^5902-2|
R|7|^FIB^^3255-7|
R|8|^D_D^^7799-0|
L|1|N
A.4 Appendix: HL7 Protocol Overview
A.4.1 Message Constructing Principles
Every HL7 message consists of several segments, each of which ends up with the <CR>
(0x0D).
Each segment consists of the segment name of three characters and a number of fields, and
each field consists of some components and subcomponents. For each message, the
delimiters of the fields, components and subcomponents are defined in the MSH segment.
E.g.
MSH|^~\&|Mindray|BriCyte E6|||20060427194802||ORU^R01|1|P|2.3.1||||||UNICODE
among which:
The five characters following MSH define the delimiters used between fields, components
and subcomponents. Although they can be any non-text characters, HL7 standard
recommends you use the characters in the table below:

Table 9 HL7 Delimiters

Character Meaning

| Field delimiter

^ Component delimiter

& Subcomponent delimiter

~ Repetition delimiter

\ ESC

The first two fields of MSH contains all the delimiters. Some fields behind are null because
they are optional and not used by Mindray HL7 interface. Details about field definition and
selection will be stated in the following sections.
For message of any type, the segments behind MSH appear in a fixed order. The order will
be described in the following sections and the following grammar is used to organize the
segments in proper order.
[] encloses optional segments.
{ } encloses segmetns which can repeat once or more.

A.4.2 Principles of Escape Character Conversion

For the field data of ST, TX, FT, and CF, etc. delimiters may be used in strings like remarks,
clinical diagnosis and customized gender etc. When coding, the delimiters in the original
strings shall be converted to escape sequence; which is restored in decoding. The principles
for escape character conversion for HL7 interface are as follows:
 ESC Sequence Original Character
\F\ Field delimiter
\S\ Component delimiter
\T\ Subcomponent delimiter
\R\ Repetition delimiter
\E\ Escape delimiter
\.br\ <CR>, segment end character.

Note: the "\" in the escapq sequence represents the ESC delimiter, whose value is defined in
the MSH segment.
A.5 Appendix: HL7 Data Type Definition

 CE - Code Element

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

 CM - Composite

Format defined by the field.

 CX - Extended composite ID with check digit

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

 ED – Encapsulate Data

<source application（HD）> ^ <type of data（ID）> ^ <data sub type（ID）> ^ <encoding（ID）>

^ <data（ST）>

 EI - Entity Identifier

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

(ID)>

 FC – Financial Class

<financial class（IS）> ^ <effective date（TS）>

 HD - Hierarchic designator

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

Used only as part of EI and other data types.

 FT - Formatted text

This data type is derived from the string data type by allowing the addition of embedded
formatting instructions. These instructions are limited to those that are intrinsic and
independent of the circumstances under which the field is being used.

 IS - Coded value for user-defined tables

The value of such a field follows the formatting rules for an ST field except that it is drawn
from a site-defined (or user-defined) table of legal values. There shall be an HL7 table
number associated with IS data types.

 ID - Coded values for HL7 tables

The value of such a field follows the formatting rules for an ST field except that it is drawn
from a table of legal values. There shall be an HL7 table number associated with ID data
types.

 NM - Numeric

A number represented as a series of ASCII numeric characters consisting of an optional

leading sign (+ or -), the digits and an optional decimal point.

 PL - Person location

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

 PT - Processing type

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

 SI - Sequence ID

A non-negative integer in the form of an NM field. The uses of this data type are defined in the
chapters defining the segments and messages in which it appears.

 ST – String

 TS - Time stamp

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ] ^ <degree of precision>

 XCN - Extended composite ID number and name

In Version 2.3, use instead of the CN data type. <ID number (ST)> ^ <family name
(ST)>&<last_name_prefix (ST) ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix
(e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table
(IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^
<code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)>

 XPN - Extended person name

In Version 2.3, replaces the PN data type. <family name (ST)> ^ <given name
(ST)>&<last_name_prefix (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^<name type code (ID) > ^ <name
representation code (ID)>

 VID - Version identifier

<version ID (ID)> ^ <internationalization code (CE)> ^ <international version ID (CE)>

A.6 Appendix: Message Coding Definition
1. In HL communication messages, the OBR-4 (Universal Serview ID) field, in the form of
“ID^Name^EncodeSys”, is used to identify the type of the analysis result (e.g. sample
analysis result, microscopic examination result, QC result, etc.). Table 10 lists all the codes of
this field.

Table 10 OBR-4 and ASTM Message Type Codes

Data Code (ID) Name EncodeSys Remarks
Sample Analysis Result 00001 Automated Count 99MRC
Worksheet
Worklist search 00010 99MRC
Request
Response to worklist Worksheet
00011 99MRC
request Response

2. Each OBX segment contains information of one analysis parameter or non-parameter data
item. It consists of the following fields: OBX-2, indicating the type of the HL7 data contained;
OBX-3 (Observation Identifier), the identifier of the data in the form of “ID^Name^EncodeSys”;
OBX-5, containing the value of the data; OBX-6, containing the unit for the parameter, (in the
standard unit recommended by HL7).
Table 11 lists the HL7 type and code identifier of each communication data item. Table 12 lists
all the units for parameters in the communication.

See 11 for data type and coding system

HL7
Type Code Encode Example of
Data Name
(OBX (ID) Sys OBX-3 field
-2)
Non-parameter Data Items
30525 30525-0^Age^LN
Age NM Age LN
~-0
01001^Remark^99
Remarks ST 01001 Remark 99MRC
MRC
01007^Sample
Sample type IS 01007 Sample Type 99MRC
Type^99MRC
01008^Patient
Inpatient zone IS 01008 Patient Area 99MRC
Area^99MRC
01009^Custom
Custom patient Custom
ST 01009 99MRC patient info
information 1 patient info 1
1^99MRC
Custom patient Custom 01010^Custom
ST 01010 99MRC
information 2 patient info 2 patient info
 2^99MRC
01011^Custom
Custom patient Custom
ST 01011 99MRC patient info
information 3 patient info 3
3^99MRC
01014^Report
Report time ST 01014 Report Time 99MRC
Time^99MRC
01015^Charger
Payer ST 01015 Charger type 99MRC
type^99MRC
01016^Patient
Patient type ST 01016 Patient type 99MRC
type^99MRC

Table 12 Parameter Units in Communication

Parameter Units in Parameter Units in

Software Communication (OBX-6)
Sec Sec
g/l g/l
μg/l μg/l
ng/ml ng/ml
Mg/dl Mg/dl
μg/ml μg/ml
U/L U/L
% %
INR INR
Ratio Ratio

3. Some OBX messages uses custom enumeration values. See Table 13 for the meaning of
the values.

Table 13 HL7 and ASTM Enumeration Definitions

Data Value Enumeration

Age Unit Value enumeration:
"yr"- year
"mo"- month
"wk"- week
"d"- day
"hr"-hour

4. Communication of patient age: the age of the patient is transmitted in an OBX segment
which contains an integer and a unit. The age could be "<1" day (same as the MPCoagu
UI).
A.7 Appendix: Base64 Encoding Process
1. 1. Select the 3 adjacent bytes (i.e. 24 bit) from the data stream to be encoded; from left to
right, divide them into 4 6-bit groups; and then, the ASCII string is obtained by mapping
based on Table 14. below.

Raw data: 15H A3H 4BH

Binary data 00010101 10100011 01001011
6-bit groups obtained after dividing 000101 011010 001101 001011
Corresponding codes 5H 1AH 0DH 0BH
Corresponding characters F a N L

Table 14 Base64 Mapping

Value/Code Value/Code Value/Code Value/Code

0A 17 R 34 I 51 z
1B 18 S 35 j 52 0
2C 19 T 36 k 53 1
3D 20 U 37 l 54 2
4E 21 V 38 m 55 3
5F 22 W 39 n 56 4
6G 23 X 40 o 57 5
7H 24 Y 41 p 58 6
8I 25 Z 42 q 59 7
9J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
2. Repeat step 1 continuously till the whole data stream is encoded.
When the data left is less than 3 bytes, 0 is added to the right to complement. If the 6-bit
groups obtained is composed of the complement bit (0) only, then it is mapped to the “=”
character. When there is the last one byte left, there will be two “=” characters in the obtained
coding string; when two bytes are left, then the obtained coding string consists of one “=”
character. See the two examples below:
① Raw data 0AH
00001010
Data obtained after complementing 00001010 00000000 00000000
6-bit groups obtained after dividing 000010 100000 000000 000000
Corresponding codes 02H 20H 00H 00H
Corresponding characters C g = =
②Raw data 0AH 0BH
00001010 00001011
Data obtained after complementing00001010 000010110 0000000
6-bit groups obtained after dividing 000010 10 0000 101100 000000
Corresponding codes 02H 20H 2CH 00H
Corresponding characters C g s =