CDA理解

目的

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

技术实现

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

CDA目录及分类

共53个CDA文档

20个健康档案

生成方式

注册方式：

1. 消息发布（通过电子病历注册接口）：

   2014版本actionName:EMRDocumentRegister

   2016版本actionName：S0014

2. 消息发布（通过各文档actionName注册）：

   actionName采用各文档配置中actionName

   把CDA文档作为发布消息

3. 适配器方式

   参考文档：

   区别：

   通过电子病历注册只生成XDS与文档存储库中的信息，不形成各文档的临床数据中心业务数据

   通过各文档actionName注册与适配器，不仅生成文档XDS与文档存储库数据，还生成临床数据中心各文档业务数据

CDA文档结构

1. CDA文档都由<ClinicalDocument>要素封装，它包括文档头和文档体两部分。

2. CDA文档头都由地域代码，文档注册模型，文档模板编号OID等等组成(实际的配置方法后面会提到)。

文档头

文档信息

病人信息

记录日期

文档管理者信息

数据录入者信息

关联活动信息

文档体

1.文档体包括的是详细的临床报告，它由<component>,<structuredBody>包含。

2. 文档体包含着很多的不同的章节，每个章节(<component>,<section>)由很多不同的条目<entry>组成。

章节头

每个章节头部都会有一个code/test节点（节点<component>、<section>下，<entry>节点之上），这里把它定义为章节头

条目

每个章节(<component>,<section>)由很多不同的条目<entry>组成。

节点

节点是根据有属性的XML元素来确定的。是为了能生成标准的CDA模版。

节点分析法

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

节点定义

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

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

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

约定与假设

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

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

3. CDA文档与数据集一一对应

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

文档属性

文档编码——文档类别编码，系统自动生成

文档actionName——用于注册时的标识

模型类别编码---所有的文档的类别都是一样

如下图：

文档编码---每个CDA文档的标识

actionname---发生响应动作的时候填写的标识，比如在用V3进行发布数据的时候。

Root固定属性---即<ClinicalDocument>节点内的属性

注：actionname不能重。

章节属性

章节编码---元素（节点）所属分类的编码

注：

文档头标志---是否是文档头（文档头不需要填写节点路径）

章节必须存在---在章节内如果没有业务数据节点，其不会显示出来。但有时候我们在有子集的情况下章节内部的一些条目会出现多次，而在章节的某一部分不需要重复出现。这时候需要没有业务数据节点的章节部分也显示出来。

节点路径---章节的第一个叶子节点的路径

一般来说一个子集对应一个章节。同一个章节内的节点可出现循环多次。这时候可将章节进行拆分为不循环部分和循环部分（有子集对应的一部分）见下图：

节点属性

文档表现形式是XML。要生成这样的XML,必须根据XML里有属性的元素，来定义节点。才能有正确的模版来生成标准的XML。如下图：

元素键值

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

元素名称

人识别名称

章节编码

此元素节点属于哪个章节

节点类型

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

开始路径

叶子节点

路径结束

数据类型

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>

元素路径

元素在XML中完整的路径

如：

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

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

元素序号

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

业务数据节点

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

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

元素独立存在

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

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

元素值对应元素

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

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

对应的标准数据元

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

属性编码

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

固定属性

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

代码转换标志

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

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

值依赖属性

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

代码名称编号

代码名称不用displayName显示

脱敏表达式

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

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

条目定义

条目编码

条目唯一性，内部编码

条目名称

参照电子病历共享文档规范文档——章节条目构成（里面有每个章节条目说明）

出现标志

出现标志为是，数据集中没有数据也会出现在文档中

出现1次

出现为1次，如果数据集中有多条数据，则只出现一次

基数

不用机器识别，是给人识别的属性

文档第一个条目

起始条目（每个文档的第一个条目）

出现依赖条目

因为这种条目一般没有数据，但有业务数据条目有可能有数据，也可能没有数据，配置了依赖条目，如果依赖条目有数据，则此条目会现，如果依赖条目没有数据，则不出现

例如：下图过敏史章节头没有业务数据，按照规则是不会出现的，这里让他显示出来让他依赖与下面过敏史条目（每个章节的章节头都需要配置）

顺序号

条目之间顺序关系（生成CDA文档时的文档条目生成顺序）

实体说明

辅助中文说明

条目路径

决定条目开始的节点与条目结尾结点位置

CDA配置说明

业务流程图

配置说明

章节定义

章节编码---元素（节点）所属分类的编码

注：

文档头标志---是否是文档头（文档头不需要填写节点路径）

章节必须存在---在章节内如果没有业务数据节点，其不会显示出来。但有时候我们在有子集的情况下章节内部的一些条目会出现多次，而在章节的某一部分不需要重复出现。这时候需要没有业务数据节点的章节部分也显示出来。

节点路径---章节的第一个叶子节点的路径

一般来说一个子集对应一个章节。同一个章节内的节点可出现循环多次。见下图：

文档类型

给文档分类。一般是一个数据集，一个类别。

如图：

文档编码---每个CDA文档的标识

模型类别编码---所有的文档的类别都是一样

actionname---发生响应动作的时候填写的标识，比如在用V3进行发布数据的时候。

Root固定属性---即<ClinicalDocument>节点内的属性

注：actionname不能重。

文档定义

文档表现形式是XML。要生成这样的XML,必须根据XML里有属性的元素，来定义节点。才能有正确的模版来生成标准的XML。

如图：

元素键值---全局唯一

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

节点的结束与否是由下一个节点相同部分决定，它会在不相同部分进行节点结束。

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

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

3./component/structuredBody/component/section/code

会分别在code， entry这里结束

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

对应标准数据元---当作为业务数据节点时需要配置一个数据元编码与元素节点进行对应

元素序号---元素节点的位置排序

属性编码---从属性获取值的属性名称

固定属性---构建消息与文档时不变的属性

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

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

代码转换标志---当某一个属性在元素里的属性值和数据库存贮值不一致时，则需要转换，这时需要选“是”（如不同的root代表门诊、住院和体检，而就诊类别的代码表中的代码是1、2、3，则需要转换。）

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

脱敏表达式---有一些信息不想显示真实的给别人则可以用表达式替换。

元素路径---元素在文档中所处的位置，路径

数据元类型---不同数据类型分类的配置方法

1字符串

如图：

如同这里的箭头标识的<name>和<assignedAuthor>两个节点。<name>取值是字符串类型。

<assignedAuthor>节点属性为固定属性。

选择类型如图：

条目定义

实体定义

一个文档结构由文档头、文档体组成（其中文档体由多个章节组成），实体命名按照对应的国家规范文档如图：

条目分类

每个章节由N个条目组成，条目命名参考对应的国家规范文档，如图（既往史章节）：

具体V3例子在国家规范文档最下方，一般条目都在节点<entry>里面，如图：

条目属性

条目编码——节点（元素）所属分类编码

条目名称——人识别的名称

出现标志——根据业务场景使用，默认选是（评测时可能要求某个条目不出现，修改此处）

出现1次——这里对应后面的基数（1..* 至少出现1次；1..1只出现1次；0..1 可能不出现，出现且只出现1次； 0..* N次）

基数——参考对应的国家规范文档，如图：

文档第一个条目——文档开始条目，这里只设置文档头中的第一个条目

出现依赖条目——每个章节条目分类完之后都会有一个章节头，章节头没有业务数据节点（规则：有业务数据的条目才会出现），为了构建出的结构跟国家规范一致，每个章节头需要依赖与章节内其他条目（这里需要找一个必须出现的条目，即基数是1开头的，如果没有就依赖全部条目，否则依赖的条目不出现章节头也不会出现）

顺序号——条目排序

节点路径——元素路径---条目在文档中所处的位置，路径

文档与数据集匹配

将CDA文档与数据集进行匹配（告诉它从哪个数据集中存取数据），从而实现存储与获取数据。一个文档对应一个数据集（主子集）。

操作界面如下图：

CDA解析配置

将平台的数据集中数据元与元素节点进行匹配，从而获取V3消息的数据。

一般在完成以上的步骤后会自动匹配上。

文档保存配置操作如下图：

值类型----节点值（直接从该节点取数据），

注：代码转换【当某一个属性在元素里的属性值和数据库存贮值不一致时，则需要转换，（如不同的root代表门诊、住院和体检，而就诊类别的代码表中的代码是1、2、3，则需要转换。）】定义节点的时候需要把代码转换标志选是，这边选择代码转换，则可以在修改旁边RootOID转换。

CDA构建配置

与CDA保存配置相反，是将元素节点与数据元进行配置。

这样才能让第三方从平台进行订阅数据时将平台的数据按照V3的格式发送给第三方的配置。一般也会自动匹配上。

但某些常量和双属性节点需要手动配置如下图：

如上述中的单位，它是非独立存在节点，依赖于值而存在，并且一般是常量。

如图：

取数值转换标志：

文档注册配置

所有文档，包括CDA、影像文件等，都需要统一注册到XDS存储库中。第三方注册向平台注册电子病历文档或者是通过平台产生的CDA文档最终都要进行XDS注册。CDA文档注册配置详见图：

CDA验证步骤

验证平台CDA构建和解析能力

定义测试发布者

1. 定义发布者

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

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

   如图：

   

定义测试订阅者

1. 定义订阅者

2. 定义订阅者协议为HL7V3

3. 订阅者订阅数据集（1.与发布者发布的数据集一致 2.订阅D02006电子病历文档注册数据集） 如图：

   

测试构建能力

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

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

2. 订阅者LIS使用HL7V3订阅

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

测试解析能力

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

   

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

   

验证数据存储

1.验证：

查看注册表(T_EMR)、存储库(T_BLOB_SAVE_D02006)、业务库(相应数据集所属子集对 应的物理表)对应的信息

查看业务库业务字段是否都有值

2.关联关系：

数据集：业务主键

注册表：文档编码File_sn=数据集编码+业务主键

注册表与存储库关联：注册表中File_details与存储库中的codeid一一对应关系

CDA通过电子病历注册接口验证

1. 发布者通过发布工具进行电子病历注册数据集发布

2. 订阅者通过订阅工具进行订阅查看注册CDA文档

3. 通过XDS查看模块进行生成数据导出

4. 查看注册表T_EMR的注册数据

5. 查看T_BLOB_SAVE_D02006中BLOBCONTENT中文档内容

6. 找出注册表与存储之间关系：注册表中File_details与存储库中的codeid一一对应关系

常见问题处理

系统登录默认的密码

用户名/密码1:center/data

用户名/密码2:test/test

内存同步

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

关于系统初始化

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

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

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

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

1. 删除某个字段；

2. 修改业务主键；

3. 更新字段类型

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

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

上线前清库

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

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