基于HL7-RIM的医卫科学数据共享技术方案.docVIP

基于HL7-RIM的医卫科学数据共享技术方案 2007年5月 1 工作内容 1.1 提取并规范化数据 将分散在各个数据中心的数据从它们的原始数据库中提取出来，并在不改变数据具体内容的情况下，将它们转换为符合HL7 RIM的标准化数据，再放入新的数据库（以下简称“规范化数据库”）中。这一步骤涉及的具体工作内容为： 根据原始数据的具体情况，为其找到所属的HL7 Domain，并选取Domain中合适的R-MIM作为规范化数据的标准。如果找不到合适的R-MIM，则自行设计新的R-MIM。（注：我们关注的并不是R-MIM展现出来的整体业务流程，而是它其中每个类的定义。它对于每个RIM类的定义和限制就对应着我们需要的数据标准。） 根据已制定的数据标准，对规范化数据库进行详细设计。 选取合适的数据提取方式，并开发相应模块，完成数据的提取、规范化、进入新库的实际过程。 1.2 拆分、重组、聚合数据 根据实际数据的特征和查询服务的需求，对规范化数据库中的数据进行拆分、重组、聚合等操作，建立数据仓库。 1.3 提供查询服务 提供综合性数据查询服务，深入到数据具体信息进行查询；并能根据查询需求的领域、主题的不同，提供相关主题数据挖掘服务。 大致的技术路线如图1所示。 图1 技术路线 2 数据库设计 根据原始数据的定义和HL7 R-MIM的定义共同确定数据库的设计。例如，ncci的数据采集系统对于临床用药的定义如图2所示，而HL7的Medication域中定义的一个关于药物的R-MIM如图3所示。那么我们就需要考虑如何将ncci的临床用药数据映射到这个R-MIM中，以及是否需要进一步为这个R-MIM增加限制，从而生成更加符合我们需求的R-MIM等等。 图2 ncci临床用药数据表单（节选） 图3 HL7 “Medication Detail Response” R-MIM（节选） 3 提取并规范化数据 在提取和规范化过程中，数据的存在形式大致是： 一条原始数据（原始数据库中） - 原始格式的数据（系统内存中） - 规范格式的数据（系统内存中） - 规范格式的数据（符合HL7消息格式的XML文件） - 一条规范化数据（规范化数据库中） 3.1 方案一：定期抽取数据 不改变原始数据的输入方式，定期将原始数据从其数据库抽取到规范化数据库中。可以使用HTB提供的一系列支持HL7的API，如图4所示。 图4 HTB中的API（节选） 优点： 由于各个分中心已有大量的数据，且新的数据会以相对比较缓慢的频率加入进来，所以这种方法省去了为各个分中心开发新的前端应用的多余工作量。 对各数据分中心的原有应用无需进行任何改动。 实现简单，成本低。 缺点： 由于原始数据是不符合HL7标准的，所以对数据进行规范化的成本会比较高，甚至不可行。比如，在HL7词汇表中定义了一些类的属性的取值范围，而如果在原始数据已经按其原先格式生成以后再对其进行规范化，就不可能知道它的某个字段取值对应的是哪个HL7词汇了。因此，规范化后的数据并不能完全符合HL7标准。 3.2 方案二：融合HL7标准的前端应用 为各个分中心开发新的前端应用，进行数据的录入。录入界面需根据相关的HL7标准进行设计，使得录入的数据满足HL7标准。比如，根据HL7词汇表定义的属性的取值范围，让用户选择相应的词汇作为数据某一字段的取值。用户每录入一条数据，系统会将其存入分中心数据库和规范化数据库。 同样可以使用HTB的API协助完成此项工作。 优点： 数据与HL7标准的贴合更紧密，数据可以完全符合HL7标准。 数据在生成的时候就满足HL7标准，省去了再次规范化的过程。 缺点： 增加了输入数据人员的工作量 改变前端应用会引起用户的不适应，并且增加培训成本。 3.3两种方案的比较 表1 两种方案的比较 方案一 方案二 实现复杂度 较低 较高 对数据分中心的改动 无 开发全新的数据录入模块 对HL7标准的支持 不完整。只能实现元数据级的规范化，无法做到数据内容本身的规范化 较完整。 将来能提供的查询质量 较低 较高 4 数据的拆分、重组、聚合 使用HTB提供的一系列支持HL7的API 建立数据仓库 5 数据的分析和查询 提供综合查询服务。由于数据格式是统一的，所以能够指定根据数据的任意字段进行精细查找。比如，在所有临床用药数据中查找“适应症 头痛”的数据。 根据需求涉及的不同领域和主题，在数据仓库上建立多个数据集市 在数据集市的基础上提供基于主题的数据挖掘服务