DB33/T 893.2-2013 临床实验室信息系统 第2部分：数据传输与交换

ICS11.020

C07

DB33

浙江省地方标准

DB33/T893.2—2013

临床实验室信息系统

第2部分：数据传输与交换

Clinicallaboratoryinformationsystem

Part2：Datatransmissionandexchange

2013-05-17发布2013-06-17实施

浙江省质量技术监督局发布

DB33/T893.2—2013

前言

DB33/T893《临床实验室信息系统》分为三个部分：

——第1部分：基本功能规范；

——第2部分：数据传输与交换；

——第3部分：工作流程规范。

本部分为DB33/T893的第2部分，本部分依据GB/T1.1-2009给出的规则起草。

本标准的消息结构参照了《HL7messagingstandardversion2.6》中关于临床实验室的相关内容，

信息系统集成技术框架参考了《IHELaboratoryTechnicalFrameworkRevision2.1》中实施临床实

验室工作流程集成规范的相关内容，并根据浙江省医疗机构临床实验室的实际情况编制而成。

本标准由浙江省卫生厅提出。

本标准由浙江省数字卫生标准化技术委员会归口。

本标准主要起草单位：浙江数字医疗卫生技术研究院、浙江大学医学院附属第一医院、浙江大学医

学院附属妇产科医院、浙江省标准化研究院。

本标准的主要起草人：李兰娟、杨大干、何剑虎、陈瑜、胡长爱、潘洋。

1

DB33/T893.2—2013

临床实验室信息系统

第2部分：数据传输与交换

1范围

DB33/T893的本部分规定了临床实验室信息系统与医嘱管理、自动化装备、电子病历之间的数据传

输与交换协议。

本部分适用于医疗机构内不同信息系统之间的临床检验数据交换。

2术语和定义

下列术语和定义适用于本文件。

2.1

临床实验室信息系统clinicallaboratoryinformationsystem

对患者样本识别、检验申请、结果报告、质量控制以及样本分析各方面相关的数据进行管理的信息

系统。

2.2

触发事件triggerevents

现实世界中产生系统间消息交换的事件。如完成一项肝功能的检测，临床实验室信息系统会触发事

件，把检验结果发送到其他系统，如电子病历。

2.3

消息message

系统间数据交换的基本单位，由顺序确定的一组段组成。每个消息都用一个消息类型来表示其用途。

2.4

段segments

数据字段的逻辑组合，每一个段用唯一的三个字符的代码来标识。在一个消息中，段可能是必需的，

也可能是可选的，段可以只出现一次，也可以重复出现。

2.5

字段field

一个记录的特定属性，由字符串组成。每个字段包括段中按顺序排列的位置、最大字符长度、数据

类型、可选性、重复性、取值表等属性。

2.6

记录record

2

DB33/T893.2—2013

描述了一个已完成信息属性的集合。

2.7

角色actor

现实信息系统功能单元或仪器设备的抽象，它们产生、管理或响应临床医疗活动中各种需要的信息，

并通过事务进行交互。

2.8

事务transaction

为了交换信息而在两个角色之间进行的特定的交互作用。

3缩略语

下列缩略语适用于本文件。

HL7卫生信息传输标准HealthLevelSeven

LIS临床实验室信息系统LaboratoryInformationSystem

LOINC观察指标标识符逻辑命名与编码系统LogicalObservationIndentifiersNamesandCodes

ASCII美国信息互换标准代码AmericanStandardCodeforInformationInterchange

IHE医疗企业集成IntegratingtheHealthcareEnterprise

4数据传输与交换

4.1硬件和底层协议

4.1.1通讯硬件和底层协议

本标准是一个基于文本的应用层协议，对数据传输所依赖的网络协议、网络规则、加密认证不做限

制。

4.1.2最小底层协议

符号约定

单一ASCII字符用单引号标明。特殊字符或非印刷体ASCII字符用单书名号<>标明。特殊字符指的是

通讯内容的开始模块字符、结束模块字符。非印刷体ASCII字符可以写成缩写形式，比如，换码符(Escape

character)写为ESC。非印刷体ASCII字符还可以写成十六进制的值，用0xXX，这里X是一个十六进制数

字。比如，标准ASCII中，<ESC>就是<0x1B>。

消息格式

消息以<SB>dddd<EB><CR>的格式传输，其中：

——<SB>=ASCII<VT>，即<0x0B>。开始模块字符，一个字节。不要和ASCII中的字符SOH或

STX混淆。

——dddd=数据。HL7消息内容，即通讯数据内容。数据可能包括任何可显示的ASCII字符和

回车字符<CR>，数据的字节数可变。

——<EB>=ASCII<FS>,即<0x1C>。结束模块字符，一个字节。不要和ASCII中的字符ETX或

3

DB33/T893.2—2013

EOT混淆。

——<CR>=ASCII<CR>，即<0x0D>。回车字符，一个字节。

数据结构

LIS与其它医疗系统的数据交换由不同类型的HL7消息完成。每个消息由一组顺序确定的段组成。段

由一系列顺序确定的字段组成。字段由格式确定的组件组成，组件又可由子组件组成。HL7消息的层次

结构，参见图1。

消息（Message）

段1（segment1）段2（segment2）„„„„段N（segmentN）

字段1（field1）字段2（field2）„„„„字段N（fieldN）

组件1（component1）组件2（component2）„„„„组件N（componentN）

子组件（）子组件（）„„子组件（）

1Subcomponent12Subcomponent2NSubcomponentN

图1HL7消息层次结构

网络连接

如果连接尚不存在，想要发送消息的应用程序必须初始化一个连接，以启动事务。接受方应用程序

将会用一个应答信息作为响应或对查询做出反应，但不会在该网络连接上发起新的事务。

应答模式

采用HL7原始应答模式来发送应答消息。应答属于应用程序级应答，且必须是在接受方应用程序

解析了消息并处理其内容之后产生。接收方应用程序应自动产生应用级确认消息，而无需等待人工核准

所收到消息的内容。

4.2消息

4.2.1概述

本标准使用的HL7消息有OML（实验室医嘱消息）、ORL（通用实验室医嘱应答消息）、ORU（主动观

察消息）、OUL（主动实验室观察消息）、ACK（一般确认消息）。

4

DB33/T893.2—2013

4.2.2消息结构

每个触发事件发生时，该触发事件引起的交换消息按照HL7抽象消息语法进行定义。

每条消息都是由特定的符号所定义，在这些符号中，按照消息里出现的顺序列出了它们的段

标识。

大括号{…}，表示大括号中的一组信息段可以是一个或者多个重复。

中括号[…]，表示中括号中的一组信息段是可选的。

如果一组信息段是可选的而且可重复，它应该包括用中括号和大括号括起来，如{[…]}。

如果大括号或中括号圈起的段标识符多于一个，左侧开始位置缩进两格，显示层次结构。

4.2.3消息构建规则

按消息定义的顺序构建消息的段。每个段构建如下：

a)前三个字符是段标识代码。

b)序列中的每个字段按下列方式插入段：

1)首先要在信息段中先放置一个字段分隔符。

2)如果该字段没有值，不必用其他的字符来表示（即直接使用两个字段分隔符来表示，如：

||）。

3)如果该字段有值，但为空，那么以字符""（两个连续的半角双引号）来表示。

4)另外，在字段中放置代表值的字符。字段中可以有许多字符，直到达到字段的最大长度为

止。

5)如果字段定义要求字段分割成许多组件，那么就要遵循下列规则：

——如果包括多个组件，使用组件分隔符进行分隔；

——如果出现为空的组件，则用字符""表示；

——如果组件中不包括任何字符，则将该组件视为不存在；

——在字段结尾处不必有空的组件出现。如：|ABC^DEF^^|和|ABC^DEF|是相等的。

6)如果组件定义要求将组件分解成子组件，则使用下列规则：

——如果包括多个子组件，它们用子组件分隔符分隔；

——存在但为空的子组件用字符""表示；

——如果子组件中不包含任何字符，则将该子组件视为不存在；

——组件末尾的不存在的子组件不需要用子组件分隔符来表示。如：^XXX&YYY&&^和

^XXX&YYY^是相等的。

7)如果字段定义允许其重复，重复分隔符仅在传递重复字段时使用。在这种情况下，重复分

隔符放在出现的字段之间。如果传递三个重复字段，则用两个重复分隔符。如

|010-12345678~0571-12345678|是发送电话号码的两个字段。

c)如果有其他字段要发送，则重复b)。如果所有在段定义的数据字段不存在，则不必

添加任何分隔符。

d)用ASCII回车字符结束每个段。

重复a)直到生成了所有的段。

接收HL7消息以及将它们的内容转换成数据值时，忽略没有被要求却存在的信息段、字段、

组件、子组件和重复的字段；将要求出现但没有出现的信息段视为其中的所有字段都没有出现；将要

求在信息中出现，但却没有包含在段内的字段或组件视为没有出现。

4.2.4消息静态定义

5

DB33/T893.2—2013

用于描述某种消息的表格将包括以下属性：

a)字段：字段的名称，并确定该字段在当前消息层级结构中的位置。采用方括号[]来分隔可选性

字段，采用大括号{}来分隔重复性字段。

b)含义：HL7定义的字段含义。

a)用法：字段的用法代码，采用以下代码值：

——R：必需型。发送方应用程序应采用某种非空取值填写所有“R”型字段，接收方应用程序

应处理必需型字段。一个必需型元素存在时，接收方应用程序不能提示错误，但缺少一个

必需型元素时，可提示错误。

——RE：可缺省的必需型。该字段可为空，但是如果存在相关的数据，发送方应用程序就应当

对其予以发送。发送方应用程序应该能够提供所有的必需型字段。如果发送方应用程序拥

有所需RE字段的值，就应当发送该字段。接受方应用程序应处理或忽略该字段中所包含

的数据，但是，在该字段缺省的情况下，也应当能成功地处理。

——O：可选型。可以出现也可以不出现该字段。

——C：条件限制型。如果满足该选项：发送方应用程序应该始终发送该字段。接收方应用程

序应该处理或忽略该字段中的数据，如果元素不存在，该程序则可产生某种错误。如果并

不满足该选项：则发送方应用程序不应该发送该字段。如果该条件选项不成立且该字段并

不存在，则接收方应用程序不应该产生错误。

——X：不支持型。该字段不被系统所支持，不仅不能被发送方应用程序发送，并且接收方应

用程序也会忽略该字段或出现程序错误报告。

b)基数：位于方括号中，允许该段出现的最大数和最小数，*表示可重复多次，参见表1。

表1基数意义说明

基数描述

[0..0]该元素不存在

[0..1]该元素可以省略，或出现1次

[1..1]该元素只能必须而且只能出现1次

[0..n]该元素可以省略，也可以出现n次

[1..n]该元素至少出现1次，最多出现n次

[0..*]该元素可以省略，或者重复任意次数

[1..*]该元素可以出现1次，或重复任意次数

[m..n]该元素可以出现至少m次，最多n次

4.2.5OML——实验室医嘱消息

实验室医嘱消息，可用于传输实验室医嘱，以及在实验室自动化的环境下传输试验请求、标

本和容器信息。

OML消息包含SAC段，用于传输标本容器信息，允许一个实验室医嘱需要多个容器，多个实

验室医嘱关联一个容器，或是实验室医嘱对应的试验请求需要多个容器。

OML^O21消息结构，适用于传输一个包含多个标本的医嘱或一个包含多个容器的医嘱，如肌

酐清除率、糖耐量试验。见表2。

6

DB33/T893.2—2013

表2OML^O21——实验室医嘱消息结构

字段含义用法基数

MSH消息头R[1..1]

[---患者信息开始RE[0..1]

PID患者标识R[1..1]

[PV1]患者就诊RE[0..1]

]---患者信息结束

{---医嘱开始R[1..*]

ORC通用医嘱（针对单独一个组合项目）R[1..1]

[TQ1]时间安排/数量RE[0..1]

[---观察指标请求开始R[1..1]

OBR观察指标申请R[1..1]

{[NTE]}注释和说明O[0..*]

[{---观察指标开始O[0..*]

OBX观察指标结果R[1..1]

[{NTE}]结果的说明C[0..*]

}]---观察指标结束

[{---标本开始O[0..*]

SPM标本R[1..1]

{[SAC]}---容器信息C[0..*]

}]---标本结束

[{---以前结果开始O[0..*]

PV1患者就诊——之前结果R[1..1]

{---以前医嘱开始R[1..*]

ORC通用医嘱——之前结果R[1..1]

OBR医嘱细节——之前结果R[1..1]

{[NTE]}注释——之前的结果O[0..*]

{---以前观察指标开始R[1..*]

OBX观察指标结果——之前结果R[1..1]

{[NTE]}注释—之前结果O[0..*]

}---以前观察指标结束

}---以前医嘱结束

]}---以前结果结束

]---观察请求结束

}---医嘱结束

OML^O33消息结构，适用于传输一个样本包含多个医嘱多个可选容器的情况。见表3。

1

DB33/T893.2—2013

表3OML^O33——同一样本多个医嘱的实验室医嘱结构

字段含义用法基数

MSH消息头R[1..1]

[---患者消息开始RE[0..1]

PID患者标识符R[1..1]

[PV1]患者就诊RE[0..1]

]---患者消息结束

{样本开始R[1..*]

SPM样本R[1..*]

[{SAC}]样本容器C[0..*]

{---医嘱开始R[1..*]

ORC通用医嘱（针对单独一个组合项目）R[1..*]

[{TQ1}]时间安排/数量RE[0..1]

[---观察指标请求开始R[1..1]

OBR观察指标申请R[1..1]

[{---观察指标开始O[0..*]

OBX观察指标结果R[1..1]

[{NTE}]结果的说明C[0..1]

}]---观察指标结束

[{---以前结果开始O[0..*]

PV1病人就诊—之前的结果R[1..1]

{---以前医嘱开始R[1..*]

ORC通用医嘱—之前的结果R[1..1]

OBR医嘱细节—之前的结果R[1..1]

{---以前观察指标开始R[1..*]

OBX观察指标结果-之前的结果R[1..1]

[{NTE}]结果注释和说明C[0..*]

}---以前观察指标结束

}---以前医嘱结束

}]---以前结果结束

]---观察指标请求结束

}---医嘱结束

}---样本结束

OML^O35消息结构，适用于包含一个或多个样本，每个样本包含一个或多个容器，且每个容

器可能包含一个或多个之前结果的医嘱。适合于按容器分选的实验室医嘱。见表4。

表4OML^O35——同一容器多个医嘱结构

字段含义用法字段

MSH消息头R[1..1]

[---患者消息开始RE[0..1]

PID患者标识符R[1..1]

[PV1]病人就诊RE[0..1]

2

DB33/T893.2—2013

表4OML^O35——同一容器多个医嘱结构（续）

字段含义用法字段

]---患者信息结束

{---样本信息开始R[1..*]

SPM样本R[1..1]

{---容器信息开始R[1..*]

SAC容器细节R[1..1]

{---医嘱开始R[1..*]

ORC通用医嘱R[1..1]

[{TQ1}]时间安排/数量RE[0..1]

[---观察指标请求开始R[1..1]

OBR观察指标申请R[1..1]

[{---观察指标开始O[0..*]

OBX观察指标结果R[1..*]

[{NTE}]结果注释和说明C[0..*]

}]---观察指标结束

[{---以前结果开始O[0..*]

PV1患者就诊R[1..1]

{---以前医嘱开始R[1..*]

ORC之前的通用医嘱R[1..1]

OBR之前的医嘱细节R[1..1]

{[NTE]}之前结果的注释和说明O[0..*]

{---以前观察指标开始R[1..*]

OBX之前的观察指标和结果R[1..1]

{[NTE]}之前结果的注释和说明O[0..*]

}---以前观察指标结束

}---以前医嘱结束

}]---以前结果结束

]---观察指标请求结束

}---医嘱结束

}---容器结束

}---样本结束

4.2.6ORL——通用实验室医嘱应答消息

ORL消息对OML消息进行应答，是对OML消息的应用层确认。

ORL^O22消息结构，用于对OML^O21消息的应答，见表5。

表5ORL^O22——通用实验室医嘱应答消息结构

字段含义用法基数

MSH消息头R[1..1]

MSA消息应答R[1..1]

[---应答开始C[0..1]

3

DB33/T893.2—2013

表5ORL^O22——通用实验室医嘱应答消息结构（续）