HL7V3理解

目的

互联互通：内部系统实现互联互通。

技术实现

不关注技术实现，关注协议与数据标准。

版本分类及目录

2014版本（评测版本）

个人信息

医护人员

医疗卫生机构科室

电子病历文档

门诊就诊登记

住院就诊登记

出院登记

医嘱

申请单

2017版本（内部版本）

个人信息注册、查询服务

医疗卫生机构注册、查询服务

医疗卫生人员注册、查询服务

术语注册、查询服务

文档注册、查询服务

就诊信息交互服务

医嘱信息交互服务

申请单信息交互服务

预约信息交互服务

结果、状态信息交互服务

消息结构

消息头

消息一般都会有消息头，在< controlActProcess>节点上的节点称之为消息头用来配置订阅者和发送者的的基本信息，配置消息的信息（创建时间、消息Id、发送状态）。

消息主体

消息主体一般包含在<subject>节点，保存这个消息的所有信息，与业务有很大的关联

配置方法

1、消息定义一个消息模型后分析这个消息模型中有没有可循环的节点段，如果有

需要配置消息数据分类；

2、消息与数据集匹配，一个消息模型与数据集匹配；

3、如果是新增或更新类型的消息模型，可以进行消息的保存配置和消息的发布配置，这是一种并行关系，因为可以非V3协议的发布，但如果是查询类型的消息模型，就需要先配置查询请求消息，然后再配置消息查询返回配置。

节点分析法

节点分析法：是平台对HL7V3格式的一种解析和构建的方法

节点定义

1. 任何一个叶子节点可以通过XML唯一的路径可以找到

2. 任何一个叶子节点可以有多个属性和最多有一个节点值

3. 假设一个叶子节点有多个节点属性值的时候，通过值元素值对节点进行构建实现，多个值元素值时用分号分隔，元素值对应元素的节点设置非独立存在

约定与假设

1. 每个条目第一个业务数据对应的节点路径具有唯一标识，如果节点不能构成唯一标 准识，需要加上值依赖属性来区分

2. 如果节点路径一样（包括加上值依赖属性后的定义），在文档定义所有的节点要么 是数据节点，要么是非数据节点

3. 交互消息与数据集一一对应

4. 节点值或节点属性值与数据元一一对应

节点属性

V3消息节点也称之为消息元素，是由元素键值、元素名称、节点类型（比较重要）、业务数据节点、数据元类型、元素序号、属性编码、元素路径等等这些属性组成的， V3消息中的消息结构是节点是按照一定顺序和规则组成的。

元素键值

具有唯一性是节点的唯一标识，系统通过这个标识识别节点中的属性与值

元素名称

人识别名称

节点类型

节点类型---开始路径，叶子节点，结束路径（如果将一个文档比喻成一棵树，那么开始路径就相当于树枝，叶子节点就相当于树叶），结束路径是对某一段节点进行强制性结束的操作。

开始路径

叶子节点

路径结束

业务数据节点

如果是业务数据节点，则是末级节点，如果维护非末级节点主要是实现XML特殊的构建，形成特殊的树干

判断是否是业务数据，即我们需要从这个节点解析存储数据到数据库里的数据或者值是变化的（如需要配成常量的消息ID,消息创建时间等）

数据元类型

ST

String类型

标识

属性：

root:标识编码

extension:标识值

例子：

<id root="2.16.156.10011.1.3" extension="420106201101011919"/>

代码表（03）

属性：

codeSystem:代码系统

codeSystemName:代码系统名称

code：代码值

displayName：代码值名称

例子：

<administrativeGenderCode code="1" codeSystem="2.16.156.10011.2.3.3.4" codeSystemName="生理性别代码表（GB/T 2261.1)" displayName="男性"/>

代码表2（09）

属性：

codeSystem:代码系统

codeSystemName:代码系统名称

code：代码值

displayName：代码值名称

例子：

<code code="1" codeSystem="2.16.156.10011.2.3.1.248" codeSystemName="医疗保 险类别代码">
<displayName value="城镇职工基本医疗保险"/>
</code>

日期

日期:YYYY-MM-dd

例子:

<time value=”20070803”/>

时间

时间:HH:mm:ss

例子:

<time value=” 130624”/>

日期时间

日期时间:yyyy-MM-dd HH:mm:ss

例子:

<time value=” 20070803130624”/>

代码表CD（07）

属性：

xsi:type

codeSystem:代码系统

codeSystemName:代码系统名称

code：代码值

displayName：代码值名称

例子：

<code xsi:type="CD" code="1" codeSystem="2.16.156.10011.2.3.1.248" codeSystemName="医疗保险类别代码" displayName="城镇职工基本医疗保险"/>

代码表CD2（10）

属性：

xsi:type

codeSystem:代码系统

codeSystemName:代码系统名称

code：代码值

displayName：代码值名称

例子：

<code xsi:type="CD" code="1" codeSystem="2.16.156.10011.2.3.1.248" codeSystemName="医疗保险类别代码" >
<displayName value="城镇职工基本医疗保险"/>
</code>

代码表ST

属性：

xsi:type

值

例子：

<value xsi:type="ST">过敏情况详细描述</value>

代码名称编码

代码名称不用displayName显示。

对应的标准数据元

如果XML节点有与数据元关联，在这个地方需要维护，以减少后面配置工作，如果是标识类型，并且标识编码需要与数据元进行转换，则这个务必进行数据元维护。

元素序号

节点在XML文件的顺序（为了以后维护这里以100递增）。

属性编码

如果维护这个，表示从XML节点中取值是对应这个属性，不维护从XML文件中取值是取节点值。

固定属性

解析时用到的一个属性值，XML节点有些是固定的属性编码与属性，此时通过个进行维护，在构建XML节点时会自动把这个固定属性带入节点。

元素值对应元素

双属性构建时依赖的属性的元素键值填写（比如年龄单位）；

因为对元素与数据元匹配时是一对一的匹配，如果出现节点出现多重属性或一个属性与值时，通过这个属性的配置实现节点获取其它一个属性或值。

元素独立存在

独立存在是要形成树中的节点或树干，构建时如果不是独立存在，则辅助独立的节点形成相关的属性与值；解析时，获取业务属性值；

判断该节点是独立存在还是依赖于某一节点而存在。

代码转换标志

root编码需要作转换时，需要维护对应的数据元，也可以用于非RootID转换

（如不同的root代表门诊、住院和体检，而就诊类别的代码表中的代码是1、2、3，则需要转换。）

值依赖属性

节点路径一样，这时无法区分节点唯一路径，可以定义值依赖属性来识别路径，用于XML解析。

脱敏表达式

信息脱敏，把数据信息变成类似的*号

比如：身份证：*{7,15} 431121********0988

元素路径

元素在XML中完整的路径

如：

1./component/structuredBody/component/section/entry/observation/code

2./component/structuredBody/component/section/entry/observation/value

交互消息配置说明

业务流程

配置说明

消息定义

根据卫生部发布的消息规范，对各种不同业务对应消息与每个消息的消息节点进行定义。系统把消息分类三个大类：注册类消息、业务类消息、查询类消息；系统内置了卫生部五级互联互通的81个消息。

消息定义，如图：

注：

其中消息模型的基本属性定义如下：

1. 消息模型分类：分为请求消息、正确返回、错误返回 三类，一般以V3消息请求发

都会有一个返回结果，不是正确就是错误。

2、成功返回消息编码：同一个消息模型的成功返回消息模型的内部编码；

3、错误返回消息编码：同一个消息模型的错误返回消息模型的内部编码；

4、消息类型:一个V3消息分为注册、业务、查询三类。

5、操作类型：一个消息模型（请求，成功，异常）的操作类型必须相同；

6、anctionname: 消息发布时的请求名字，一个请求消息模型的anctionname和它对应的返回消息的anctionname相同，对于别的请求消息来说是唯一的；

7、root 固定属性：消息根节点中的属性。

节点定义，如图：

注：

1、节点类型：在消息中节点包含了节点的节点，称之为“开始路径”节点；

反之为“叶子节点”，“路径结束”节点一般不用配置，系统自动配置；

2、业务数据节点：与业务相关且属性值不是固定的都为业务数据节点；

3、所属数据分类：某些消息中会有节点段可循环，当这种情况发生时，所以需要配置对应的数据分类；

4、对应标准数据元：业务数据节点消息元素对应的数据元；

5、元素序号：每个消息定义的节点都是从上往下顺序排列的；

6、属性编码：节点的非固定属性编码；

7、元素值对应元素： 双属性构建时依赖的属性的元素键值填写（比如年龄单位）；

8、元素独立存在：判断该节点是独立存在还是依赖于某一节点而存在；

9、 允许为空、多次标志: 默认填是；

10、代码转换标志: 当root编码不为固定时候，不同属性对应不同的数据元时

写（如当门诊和住院号在某些业务场景里只有一个存在时，会用到）；

11、值依赖属性 当某几个节点路径相同的时候取值填写一个固定属性进行分辨解析

12、元素路径： 元素在消息中所处的位置，路径。

消息数据分类

当消息的节点需要循环时，就需要消息数据分类，如图：

注：

1、主集标志：数据分类主集唯一；

2、分类仅出现1次：有的消息段只能出现一次的情况；

3、分类必须存在：主集和消息的尾端一般都必须存在，可循环的一般为否；

4、节点路径：分类的节点路径，主集的节点路径可以不用配置；

5、基本上消息成功返回都需要配置消息数据分类。

消息与数据集匹配

为了实现V3消息与其它的协议的转换，需要建立消息与数据集的对应关系，如图：

注：

每一个消息模型类型（例如：手术排班的新增、更新、查询）只能对应一个数据集，一般来说一个数据集也只能对应一个类型的数据模型，否则可能会出现订阅者订阅的消息不正确（一个数据集同时与两种类型的的数据匹配，那返回的结果是系统规则决定的）。

消息解析配置

第三方发布V3消息给平台，平台实现对V3消息解析的同时，同时进行发布消息的分类存储，已实现数据中心的自动构建，消息保存配置是实现上述功能的前提基础，如图：

注：

一般来说，只要消息中是业务数据节点的节点数据元匹配正确，那么消息保存配置时

据集数据元和消息的元素键值都匹配正确了。

消息构建配置

为了实现第三方通过V3协议来获取业务消息，需要通过“消息发布配置”进行协议

换配置，如图：

注：

值转换标志：发布消息时有的元素需要转换值（如发布者Id就会设置成常量），

RootOID转换，当root编码不是固定的，不同属性对应不同的数据元时填写（如当门诊和住院号在某些业务场景里只有一个存在时，会用到）进行值转换，如下图所示：

还有其他类型值标志转换如下图：

消息查询请求配置

消息查询请求配置实现V3查询请求参数的可视化配置，实现对查询条件的配置，从

满足各种场景下的第三方对于数据查询的需要，详见图：

注：在这里查询消息通过什么条件配置，这里的元素键值与数据集数据元编码的匹配与消息保存配置同理。

消息查询返回配置

消息查询返回配置实现查询数据集与V3节点关系的对应，详见图：

注：

消息返回配置，与消息发布配置同理，不过在异常返回时必须配置消息处理说明（常量errMsg），在图39-3也有说明。每一个消息返回（成功，异常）时，都需要配置消息id，不然消息发布返回来的结果是系统指定的消息返回模型，如下图所示：

交互消息验证步骤

工具

1.在线格式化工具：

JSON：https://www.bejson.com/?src=xiaof

XML：https://tool.oschina.net/codeformat/xml/

2.比较工具：

UE

3.查找重复节点：

储存过程：P_Find_RepetitionNodeV3在plsql执行

验证平台交互消息构建和解析能力

准备工作

1. 确定交换点

2. 找到相应的数据集

定义测试发布者

1. 定义发布者

2. 发布者采用（json、xml）

3. 确定发布者发布数据集

   如图：

   

定义测试订阅者

1. 定义订阅者

2. 定义订阅者协议为HL7V3

3. 订阅者订阅数据集（1.与发布者发布的数据集一致） 如图：

   

测试构建能力

1. 用发布工具进行json发布

   发布者HIS用json发布了一条中药处方消息

   

2. 订阅者LIS使用HL7V3订阅

   

3. 浏览LIS订阅的HL7V3消息，复制到UE等比较工具跟规范标准进行对比，检查平台构建的XML例子跟规范标准是否一样

   

   

测试解析能力

1. 用v3消息进行消息发布

   

2. 用订阅回来的V3消息和规范标准进行对比，检查例子结构是否跟规范标准一样，同时看业务数据是否有值

   

新增服务测试

1. 用发布工具进行V3发布

   发布者HIS用v3发布了一条出院登记消息

   

2. 注册成功：把工具下方的返回消息复制到UE跟规范标准成功返回例子对比，检查平台构建的XML例子跟规范标准是否一样，最后检查一下业务库数据是否变化

   

   

3. 注册失败：把工具下方的返回消息复制到UE跟规范标准失败返回例子对比，检查平台构建的XML例子跟规范标准是否一样（这里模拟失败，把主键为空）

   

   

更新服务测试

1. 用发布工具进行V3发布

   发布者HIS用v3发布了一条出院更新消息

   

2. 更新成功：把工具下方的返回消息复制到UE跟规范标准成功返回例子对比，检查平台构建的XML例子跟规范标准是否一样，最后检查一下业务库数据是否变化

   

3. 更新失败：把工具下方的返回消息复制到UE跟规范标准失败返回例子对比，检查平台构建的XML例子跟规范标准是否一样（这里模拟失败，把主键为空）

   

   

查询服务测试

1. 用测试工具中的共享消息测试

   查询出院信息（这里要查询的信息关键词需要在业务库中查找是否有数据）

   

2. 查询成功：把工具下方的返回消息复制到UE跟规范标准成功返回例子对比，检查平台构建的XML例子跟规范标准是否一样

   

   

3. 查询失败：把工具下方的返回消息复制到UE跟规范标准失败返回例子对比，检查平台构建的XML例子跟规范标准是否一样（这里模拟失败，把查询条件去掉）

   

常见问题处理

系统登录默认的密码

用户名/密码1:center/data

用户名/密码2:test/test

内存同步

系统对于基础信息的加载是在第一次使用到这个基础信息时加载到内存中的，如果修改了这些基础信息，需要通过“内存同步”功能进行基础信息的内存加载。

关于系统初始化

有时安装部署为了采用某个地方的标准，直接把别的地方的数据库进行导入后需要对系统进行初始化，采用平台提供的“系统清库”功能。

注：系统正式运行后，千万不要使用这个功能，后果十分严重，廖氏软件不对使用这个功能产生的后果进行负责。

物理表发布后删除某个字段或修改主键或字段类型

物理表发布后，平台只提供对于字段长度增长修改功能及增加新的字段的功能发布。如果在物理表发布后，出现以下几种场景：

1. 删除某个字段；

2. 修改业务主键；

3. 更新字段类型。

   需要对删除物理表然后进行重建，操作方法如下：

   选择“删除物理表”功能，对已建表进行删除，然后修改数据集，最后用“物理表发布”功能重建物理表。

上线前清库

一般在平台正式运行前，会有一段时间的测试，这些数据需要进行删除，通过平台“上线前清库”功能对这些数据进行清除。

注：系统正式运行后，千万不要使用这个功能，后果十分严重，廖氏软件不对使用这个功能产生的后果进行负责。