区域医疗病历管理及共享的高端信息架构设计

《区域医疗病历管理及共享的高端信息架构设计》由会员分享，可在线阅读，更多相关《区域医疗病历管理及共享的高端信息架构设计（7页珍藏版）》请在金锄头文库上搜索。

1、 96区域医疗病历管理及共享的高端信息架构设计 区域医疗病历管理及共享的高端信息架构设计 任力欣 IBM 中国有限公司软件部，100027，北京朝阳区工体北路甲二号盈科中心 IBM 大厦 25 层 1 病历管理及共享的业务模式 1 病历管理及共享的业务模式 病历数据(Clinical Document)是指患者在医疗机构就诊后产生的，针对不同医疗处置而形成的记录性文档。病历数据在医疗机构中占有非常重要的地位，是进行医疗研究、患者管理的基础信息之一， 而随着近年来区域医疗管理的需求逐步明确， 如何在不同医疗机构之间实现病例信息的共享和交换， 也成为一个重要的业务趋势。 因此应该从业务上把整个区域

2、医疗病历管理及共享系统分成两个组成部分进行考虑： 医疗机构内部的病历组织管理和区域医疗病历共享交换。 实现的业务模式可以分为三类，大集中模式、迁移分布模式和引用分布模式。 1.1 大集中模式1.1 大集中模式 各医疗机构不建立独立的电子病历模型，所有的病历模型全部集中存储在一个集中式的区域病历中心，由区域病历中心对电子病例进行统一设计、建模、存储、分析利用和访问发布。 该模式的优势在于对于一个区域内的病历进行统一建模， 利于进行基于病历的进一步分析和利用， 方便进行统一存储规划和建设， 区域内各个医疗机构将不再建立各自独立的电子病历系统，而将成为区域集中式电子病历系统的使用客户端，因此病历的归

3、属，访问权限，生命周期管理将成为系统建设的关键。 1.2 迁移分布模式1.2 迁移分布模式 各医疗机构分别建立独立的电子病历模型，同时区域内各医疗机构按照统一规定的病历交换模型，按照既定的迁移策略（例如时间点迁移，归档迁移等） ，将各自系统内的电子病历迁移到一个集中的区域电子病历中心， 由区域电子病历中心对电子病例进行进一步的分析利用和访问发布。 该模式的优势在于仍然可以对于一个区域内的病历进行统一建模， 利于进行基于病历的进一步分析和利用。 同时保持了区域内各个医疗机构的特殊性， 可以按照各自业务特点建立自身的电子病历系统， 这是一种以交换模型统一分布式电子病历的模式， 其建设的重点和难点在

4、于交换模型的定义， 交换接口的定义和迁移策略的制定， 同时也同样需要兼顾病历的归属，访问权限，生命周期管理等问题。 971.3 引用分布模式1.3 引用分布模式 以上两种建设方式在美国和欧洲均可以看到实际的实施案例，但如果从中国的实际情况出发， 就会发现以上两种模式都不太适合于中国目前的实际情况， 首先，由于法律法规方面的限制， 病历信息的归属权是严格归属于医院这一特定主体的， 一个大集中式的电子病历系统必然会遇到安全性方面的限制。 同时由于现在国内电子病历建设缺乏标准， 导致建立不同电子病历系统迁移接口的技术难度过大， 因此迁移分布式模式在实际操作过程中会遇到很复杂的问题。 基于以上分析，

5、同时参照当前 IT 业界的 SOA （Service Oriented Architecture）理论，一种基于“服务”的引用分布模式更适用于当前国内区域医疗的病历管理和共享交换系统建设。 所谓引用分布模式，就是允许区域内各个医疗机构根据自身特点建立电子病历系统，电子病历信息严格归属与所属医院， 但是各个医疗机构需要按照区域医疗管理的需要， 对其病历信息进行“服务封装” ，与迁移分布模式不同，各个医疗机构并不是把电子病历迁移到集中的区域中心， 而是以服务访问注册的形式注册到区域电子病历中心， 因此区域电子病历中心并不是一个物理集中的电子病历存储中心， 而是一个虚拟的电子病历服务访问中心。 一方

6、面区域内医疗机构可以根据自身的电子病历安全性要求和访问权限要求对电子病历进行加工（即服务封装） ，同时区域电子病历中心可以基于一个“服务调用”的交换体系实现区域内电子病历共享。 从而实现区域电子病历中心的四个业务目标：建立基于统一病患索引的电子病历目录；建立基于服务封装的电子病历发布机制；建立基于服务调用的电子病历访问机制；建立基于电子病历发布模版的病历信息质量控制和分析利用。 为了实现上述业务目标，需要一套坚实的 IT 系统作为基础，而其中的关键是一个信息架构， 保证病历信息模型在一个有总有分的跨机构分布式环境下， 一方面保证病历信息的完整性、安全性和唯一性，另一方面保证共享交换机制的实现。

7、 982 病历共享的高端信息架构设计 2 病历共享的高端信息架构设计 2.1 病历信息架构设计2.1 病历信息架构设计 病历信息共享设计首先要从病历信息本身的信息架构设计入手。病历数据首先是一个文档型数据，现在大多数 IT 技术公司将病历数据过分结构化是导致病历数据录入复杂、 检索困难、 利用不充分的根本原因。 以纸质病历为基础数据参考蓝本，我们会发现，病历数据应具备如下关键特征： 2.1.1 模版化2.1.1 模版化 不同的病历，不同的医疗机构对病历数据的描述都是以模版为信息组织的基本框架的，每一份实际的病历都是对某一个具体病历记录模版的具体化实现。 2.1.2 术语化2.1.2 术语化 卫

8、生部针对病历书写规范的主要限定之一就是书写语言的规范化，病历数据应以一种医学术语的表述方式进行描述。 2.1.3 可追加2.1.3 可追加 病历数据在正式归档之前， 都是具有可追加的特性的， 用户可以根据模版，按照术语化的要求追加不同的数据项。 2.1.4 可参照2.1.4 可参照 病历数据之间具有明显的参照性特征，参照性又可以分为显性参照和隐形参照，显性参照是指病历数据之间的一种已知医疗相关性的体现，例如“血常规检查”数据与部分“炎症”数据之间的参照关系，但是还有部分参照性是一种隐性的参照性，例如同种病历表现的病历之间的参照关系。 2.1.5 可标注2.1.5 可标注 由于医疗行业有非常规范

9、的术语体系，因此病历数据就需要建立与术语体系标注关系，方便对病历数据进行关键字提取、索引和检索，方便建立 不同病历数据之间的可参照性。 2.1.6 可审计2.1.6 可审计 病历数据是高度敏感和机密的数据，因此对病历数据的生成、访问、存取、修改、追加、归档等操作需要建立独立的审计机制。 2.1.7 分角色2.1.7 分角色 对病历数据对象而言，会存在多种角色对其进行操作，包括：创建者（主治医生） 、录入者（主治医生/主管护士） 、查询者（医生/护士） 、归档者（病历科管理人员）等，不同角色的人员针对不同的病历数据具有不同的权限。 2.1.8 隐私性2.1.8 隐私性 病历数据是隐私类数据，其最

10、终归属应该是患者本人，医疗机构是在其授权下进行管理维护，因此需要在分角色、可审计的基础上实现隐私管理。 基于以上分析，一个病历数据信息架构见图 1。 99图 1 病历数据信息架构 根据病历数据的信息特点，以及相应的业务应用场景分析，将病历信息从信息组件级别分为七个核心组件和四个辅助组件。 核心组件构成了病历数据的结构化主体， 辅助组件配合核心组件完成对病历数据的利用。 2.2 病历数据核心组件 2.2 病历数据核心组件 病历数据的的核心组件是一个分层次的结构化模型组，主要的用途是实现不同病历数据的结构化建模。 整个结构化模型组的顶层是一个病历模板模型（Clinical Document Tem

11、plet ） ，根100据不同的病历需要定制不同的文档模板， 模板模型应对模板本身的标记性信息 （ID、 名称、描述） ，以及过程记录性信息（版本，时间标记等）进行结构化建模和存储，病历模板本身的结构（Templet Structure）以一种基于 ebXML 的形式进行建模和存储，通过 Templet ID 与病例模板（Clinical Document Templet）实现关联。需要说明的是，一种病例模板会存在不同的编辑版本， 由于病历的结构化建模是与其使用的病历模板相关联的， 因此病历模板的修改和创建均应以版本追加的方式实现。 患者信息模型（Patient）是对患者信息的建模，主要是对患

12、者的静态信息进行结构化建模和存储，需要通过一个病患主索引（Patient ID）对患者进行唯一标识。 病历信息主要记录患者的动态信息， 但是病历信息的记录需要一种基于病历模板的方式进行建模和存储，一个病历模板可以应用于多个病历，一个病人也对应多个病历。 病历信息由一个四层复合模型组成： 2.2.1 病历头（Document Header）2.2.1 病历头（Document Header） 主要记录病历的基本属性年及对病历模板的引用信息，可以考虑包含的信息内容包括： 文档基本信息类：文档 ID，引用模板 ID，关键字提取，文档标题，文档有效期，文档生成日期，文档语言集代码，病患 ID。 文档关

13、联信息类：一般一份病历文档信息还会存在与其他病历信息的关联关系，例如一份住院病历文档， 会与多份医学检查结果文档关联， 因此需要记录与其关联的文档ID 及关联关系信息。 文档权限信息类：一份病历文档的访问需要配合授权模型实现可控的信息访问，因此在病历头部分需要记录授权信息，由授权码，文档所有者（角色） ，所属组织机构代码等信息组成。 2.2.2 病历部件（Document Section）2.2.2 病历部件（Document Section） 不同的病历模板会由不同的病历部件组成，主要按照病历组织的要求， 对病历信息本省按照不同的组织方式进行组织。 例如一份住院入院病历可以考虑由以下病历部件

14、组成：病历首页，主诉，现病史，既往病史，过敏史，其它情况，体格检查，辅助检查，初步诊断等。需要注意的是病历部件是可以以一种嵌套的定义方式进行建模组织的，例如，体格检查的病历部件可以嵌套定义两个病历部件，一般状况和专科状况。 2.2.3 病历条目（Document Entry）2.2.3 病历条目（Document Entry） 病历条目是对病历部件内容的一个细化描述，根据对病历使用的需要， 可以灵活设定病历条目的内容， 病历条目的设计需要结合病历书写术101语体系，将病历部件的内容按照规范的数据体系进行标注后实现条目化。 2.2.4 病历条目关系（Entry Relationship）2.2.

15、4 病历条目关系（Entry Relationship） 描述不同病历条目之间的隐含关系，用于建立临床描述之间的关系管理， 例如我们在主诉部件标注了一个条目 （Entry） “胸痛” ，在检查部件标注了一个检查项目条目（Entry）“平板运动试验” ，而这两者之间存在一个隐含的关系（Relationship）“接受服务原因” ，即因为“胸痛” ，所以做“平板运动试验” 。类似的关系还有“病因学关系” ， “整体-部分关系” ， “顺序发生的”等。 2.3 病历数据辅助组件2.3 病历数据辅助组件 病历数据服务主组件用来配合核心组件，实现基于病历数据的整体应用，从整体上划分，分为四类角色。 “角

16、色” 定义组件， 从对病历数据的操作来分可以分为 “创建” ， “追加” ， “检索” ， “修正” ， “归档”五类角色，我们需要将这五类角色分别建模，这与我们在一个医疗机构内的主治医生，主管护士，检查科医生，病历科医生等角色并不完全是一个一一对应的关系，需要配合授权组件，针对病历，才能与医疗机构内的具体角色实现对应。 “授权”定义组件，在进行授权模型的定义时，要注意到授权粒度不止需要涵盖病历头（Document Header ） ，而且需要涵盖到病历部件（ Document Section ） ，这样我们在实际建模过程中，就可以结合这一授权体系，将敏感数据定义为一个单独的病历部件（ Document Section ） ，并通过授权体系进行访问控制。 “审计”定义组件，所有对避难数据的创建，修改，追加，查询等操作，都要通过“审计”组件，以一种操作日志的形式记录下来，并提供相应的管理功能。 “术语集”定义组件，包含临床术语集，以及其他医疗辅助术语集，例如检查结果术语集 LOINC 等。 “术语集”组件一方面指导生成不同的病历模板的结构（ Temp