6医院信息平台体系架构

基于电子病历的医院信息平台建设技术解决方案 ( 征求意见稿 ) 技术部分卫生部信息化工作领导小组办公室卫生部统计信息中心二 O 一 O 年十一月

目录 5 医院信息平台体系架构... 491 5.1 平台体系架构... 491 5.1.1 总体架构... 491 5.1.1.1 门户平台... 492 5.1.1.2 医院信息平台应用 ( 层 )... 492 5.1.1.3 医院信息平台信息资源中心... 492 5.1.1.4 医院信息整合平台... 492 5.1.1.5 信息基础设施平台... 492 5.1.1.6 标准规范... 493 5.1.1.7 信息安全与系统运维管理... 493 5.1.2 软件架构... 493 5.1.3 系统软硬件架构... 494 5.1.3.1 大中型医院服务器部署架构... 495 5.1.3.2 中等规模医院服务器部署架构... 496 5.1.3.3 小型医院服务器部署架构... 497 5.1.4 存储架构... 498 5.1.4.1 大型规模的医院的存储规划方案... 498 5.1.4.2 中型规模的医院存储规划方案... 499 5.1.4.3 小型规模的医院存储规划方案... 501 5.1.5 网络拓扑... 502 5.1.6 安全架构... 503 5.2. 医院信息平台设计... 504 5.2.1 注册服务功能... 504 5.2.1.1 患者注册... 504 5.2.1.2 机构 ( 科室 ) 注册... 513 5.2.1.3 医疗卫生服务人员注册... 515 I

5.2.1.4 术语注册... 518 5.2.1.5 注册库和注册服务... 521 5.2.2 患者主索引 (MPI)... 529 5.2.2.1 患者主索引 (MPI) 和机构级患者主索引 (EMPI)... 529 5.2.2.2 患者标识交叉索引... 530 5.2.2.3 MPI 服务功能... 532 5.2.2.4 MPI 管理功能... 536 5.2.2.5 患者新增 / 更新流程... 537 5.2.3 电子病历 (EMR) 文档与临床数据存储库 (CDR)... 538 5.2.3.1 EMR 文档标准... 539 5.2.3.2 EMR 文档的基本内容... 540 5.2.3.3 EMR 文档类型... 540 5.2.3.4 EMR 文档结构... 540 5.2.3.5 临床数据存储库 (CDR Clinical Data Repository)... 543 5.2.4 电子病历浏览器... 545 5.2.4.1 电子病历浏览器的设计要求... 545 5.2.4.2 电子病历浏览器的分类... 548 5.2.4.3 电子病历浏览器的应用... 551 5.2.4.4 电子病历浏览器的功能... 552 5.2.6 全院业务协同支撑服务... 556 5.2.6.1 医院业务协同现状及对协同支撑服务需求... 556 5.2.6.2 医院业务协同支撑服务组成... 558 5.2.6.3 服务编排服务组件... 559 5.2.6.4 信息门户服务组件... 559 5.2.6.5 视频流媒体服务组件... 560 5.2.6.6 业务过程管理及工作流管理服务组件... 560 5.2.6.7 即时消息服务... 565 5.2.6.8 电子邮件服务... 566 5.2.6.9 短消息服务组件... 566 II

5.2.6.10 电话和传真服务组件... 566 5.2.6.11 基于电子病历的医院信息平台协同支撑的案例... 567 5.2.7 医院信息系统集成... 570 5.2.7.1 医院信息系统集成需求分析... 570 5.2.7.2 医院信息集成的方法... 571 5.2.7.3 基于 ESB 的医院信息集成平台组成... 572 5.2.7.4 医院服务总线... 573 5.2.7.5 医院数据交换与共享... 579 5.2.8 数据架构... 581 5.2.8.1 总体架构... 581 5.2.8.2 基础信息库... 583 5.2.8.3 医院信息资源目录库... 584 5.2.8.4 业务信息库... 584 5.2.8.5 交换信息库... 585 5.2.8.6 临床文档信息库 CDR... 585 5.2.8.7 操作数据存储 ODS... 587 5.2.8.8 数据仓库... 589 5.2.8.9 对外服务信息库... 591 5.2.8.10 智能化管理信息库... 591 5.3 医院数据中心构建... 592 5.3.1 概述... 592 5.3.2 基础软件... 593 5.3.2.1 应用服务器... 593 5.3.2.2 门户服务器... 596 5.3.2.3 内容管理和搜索引擎... 599 5.3.2.4 企业服务总线 (ESB)... 602 5.3.2.5 业务流程管理... 604 5.3.2.6 业务规则引擎... 606 5.3.2.7 事件驱动引擎... 607 III

5.3.3 数据库软件... 608 5.3.3.1 关系型数据库... 608 5.3.3.2 对象型数据库... 611 5.3.3.3 XML 数据库... 613 5.3.3.4 知识库管理系统... 614 5.3.3.5 电子化文档管理... 614 5.3.4 服务器部署与虚拟化技术... 616 5.3.4.1 服务器支撑架构... 616 5.3.4.2 虚拟化技术... 627 5.3.4.3 服务器整合技术及方法... 629 5.3.4.4 灾难恢复... 632 5.3.4.5 典型医院环境下服务器部署现状分析... 636 5.3.4.6 医院信息平台服务器整合思路... 644 5.3.4.7 典型医院信息平台服务器物理部署设计... 646 5.3.5 服务器部署与虚拟化技术... 648 5.3.5.1 服务器支撑架构... 648 5.3.5.2 虚拟化技术... 659 5.3.5.3 服务器整合技术及方法... 661 5.3.5.4 灾难恢复... 664 5.3.5.5 典型医院环境下服务器部署现状分析... 668 5.3.5.6 医院信息平台服务器整合思路... 675 5.3.5.7 典型医院信息平台服务器物理部署设计... 677 5.4 存储架构... 679 5.4.1. 存储技术发展趋势... 679 5.4.1.1 DAS... 679 5.4.1.2 NAS... 679 5.4.1.3 FC SAN... 681 5.4.1.4 IP SAN... 681 5.4.2. 医院存储需求分析... 682 IV

5.4.2.1 文档库存储需求分析... 682 5.4.2.2 ODS 数据库存储需求分析... 682 5.4.2.3 医疗影像存储需求分析... 683 5.4.3. 存储设计... 684 5.4.3.1 概述... 684 5.4.3.2 设计原则... 684 5.4.4. 数据保护机制... 686 5.4.4.1 本地数据保护方式... 686 5.4.4.2 异地数据保护方式... 689 5.4.5. 部署模型... 692 5.4.5.1 小型规模的医院存储规划方案... 692 5.4.5.2 中型规模的医院存储规划方案... 693 5.4.5.3 大型规模的医院存储规划方案... 694 5.4.6. 存储管理... 695 5.5 网络与通讯基础架构... 696 5.5.1 医院信息网络应用需求分析... 697 5.5.1.1 医院业务应用分析... 697 5.5.1.2 医院信息网络数据流分析... 699 5.5.1.3 应用需求总结... 700 5.5.2 网络基础设施平台架构设计... 701 5.5.2.1 概述... 701 5.5.2.2 设计原则... 702 5.5.2.3 医院网络分层功能分区设计... 703 5.5.2.4 内外融合的网络架构设计... 708 5.5.2.5 内外网分离的网络架构设计... 714 5.5.2.6 基于业务的无线网络平台架构... 717 5.5.3 基础网络设施平台实现... 721 5.5.3.1 内外融合的平台实现... 721 5.5.3.2 内外网分离的平台实现... 727 V

5.5.3.3 无线网络的平台实现... 735 5.5.4 网络管理... 737 5.5.4.1 IP 地址规划... 737 5.5.4.2 网络设备管理... 740 6 医院应用系统与业务协同... 748 6.1 所有应用的列表... 748 6.2 基于平台的应用... 755 6.2.1 临床决策... 755 6.2.1.1 概述... 755 6.2.1.2 需求分析... 755 6.2.1.3 功能模型... 760 6.2.1.4 服务模型... 762 6.2.1.5 案例... 764 6.2.1.6 系统实施约束... 766 6.2.1.7 典型系统支撑环境... 767 6.2.2 行政管理决策... 771 6.2.2.1 目标... 771 6.2.2.2 需求分析... 771 6.2.2.3 业务功能模型... 772 6.2.2.4 服务模型... 782 6.2.2.5 案例... 784 6.2.2.6 系统实施约束... 785 6.2.2.7 典型系统支撑环境... 786 6.2.3 Portal 应用... 790 6.2.3.1 概述... 790 6.2.3.2 需求分析... 792 6.2.3.3 门户的技术解决方案... 798 6.2.4 电子病历编辑器... 805 6.2.4.1 目标... 805 VI

6.2.4.2 需求分析... 805 6.2.4.3 功能模型... 807 6.2.4.4 系统支撑环境... 813 6.2.5 计算机化的医嘱录入 (CPOE)... 813 6.2.5.1 目标... 813 6.2.5.2 需求分析... 813 6.2.5.3 功能模型... 822 6.2.5.4 系统支撑环境... 823 6.2.6 院内 / 外病人服务... 824 6.2.6.1 概述... 824 6.2.6.2 需求分析... 824 6.2.6.3 功能模型... 827 6.2.6.4 服务模型... 828 6.2.6.5 案例... 829 6.2.6.6 系统实施的约束条件... 835 6.2.7 全院一卡通... 835 6.2.7.1 患者一卡通... 836 6.2.7.2 员工一卡通... 841 6.3 应用和平台的协同, 平台和区域的协同... 847 6.3.1 与电子病历相关的业务协同... 847 6.3.1.1 目标... 847 6.3.1.2 需求分析... 847 6.3.1.3 案例... 849 6.3.2 医院 ERP 决策支持与平台的交互协同... 850 6.3.2.1 概述... 850 6.3.2.2 交互需求分析... 853 6.3.2.3 交互模型... 855 6.3.2.4 案例... 857 6.3.3 与区域卫生信息平台的互联互通... 858 VII

6.3.3.1 患者身份交叉索引 (PIX)... 859 6.3.3.2 医疗卫生机构注册服务... 860 6.3.3.3 电子病历文档共享 (XDS)... 861 6.3.3.4 医疗业务协同服务... 864 7 安全架构... 868 7.1 概述... 868 7.2 安全目标... 868 7.3 安全等级... 868 7.3.1 定级过程... 869 7.3.2 等级变更... 871 7.3.3 医院信息平台安全等级建议... 872 7.4 风险分析... 874 7.4.1 信息和信息系统分析... 874 7.4.2 安全风险分析... 874 7.4.3 资产分析... 875 7.4.4 威胁分析... 876 7.5 需求分析... 877 7.5.1 安全需求... 877 7.5.2 隐私保护需求... 878 7.6 总体设计... 879 7.6.1 设计思想... 879 7.6.2 总体框架... 880 7.6.3 关于隐私保护的说明... 881 7.7 安全技术保障... 883 7.7.1 确定保护对象... 883 7.7.1.1 确定计算环境... 883 7.7.1.2 确定区域边界... 885 7.7.1.3 确定通信网络... 885 7.7.2 计算环境安全... 886 VIII

7.7.2.1 用户身份鉴别... 886 7.7.2.2 访问控制... 887 7.7.2.3 系统安全审计... 888 7.7.2.4 数据保密性... 889 7.7.2.5 数据完整性... 891 7.7.2.6 备份与恢复... 891 7.7.2.7 主机恶意代码防范... 892 7.7.3 区域边界安全... 894 7.7.3.1 边界访问控制... 894 7.7.3.2 边界安全审计... 895 7.7.3.3 边界入侵防护... 896 7.7.3.4 边界恶意代码防范... 896 7.7.3.5 边界完整性保护... 897 7.7.4 通信网络安全... 898 7.7.4.1 网络结构安全... 898 7.7.4.2 网络安全审计... 899 7.7.4.3 网络设备防护... 899 7.7.4.4 通信完整性和保密性... 900 7.7.4.5 网络可信接入... 900 7.7.5 安全管理中心... 901 7.7.5.1 集中网络管理... 902 7.7.5.2 统一数字身份管理... 902 7.7.5.3 统一安全管理... 904 7.7.5.4 集中日志审计... 904 7.7.6 物理安全保护... 905 7.7.7 主要安全技术实现... 906 7.7.7.1 边界访问控制... 906 7.7.7.2 入侵检测措施... 907 7.7.7.3 无线安全措施... 908 IX

7.7.7.4 病毒检测措施... 909 7.7.7.5 日志审计措施... 910 7.7.7.6 备份恢复措施... 911 7.7.7.7 身份认证和访问管理相关控制措施... 911 7.7.7.8 物理安全措施... 912 7.7.8 不同等级系统互联互通... 915 7.8 安全管理设计... 916 7.8.1 安全管理设计... 916 7.8.1.1 安全管理制度... 916 7.8.1.2 安全管理机构... 917 7.8.1.3 人员安全管理... 917 7.8.1.4 系统建设管理... 917 7.8.1.5 系统运维管理... 918 7.8.2 安全管理措施实现... 919 8 项目管理... 925 8.1 概述... 925 8.1.1 项目管理存在问题... 925 8.1.1.1 管理意识问题... 925 8.1.1.2 整体管理问题... 926 8.1.1.3 范围管理问题... 926 8.1.1.4 需求管理问题... 926 8.1.1.5 人才建设问题... 926 8.1.2 项目管理的重要性... 927 8.1.3 项目管理基本内容... 928 8.1.3.1 项目管理基本概念... 928 8.1.3.2 项目管理发展历程... 929 8.1.3.3 项目管理知识体系... 929 8.2 启动阶段... 933 8.2.1 组织建设... 933 X

8.2.1.1 项目组织结构... 933 8.2.1.2 项目领导小组... 934 8.2.1.3 项目执行小组... 934 8.2.2 制度建设... 935 8.2.3 项目启动... 936 8.3 实施阶段... 936 8.3.1 项目范围管理... 936 8.3.1.1 范围管理计划... 936 8.3.1.2 项目范围控制... 937 8.3.2 项目时间管理... 939 8.3.2.1 项目进度计划... 939 8.3.2.2 项目进度控制... 940 8.3.3 项目成本管理... 941 8.3.3.1 项目成本计划... 941 8.3.3.2 项目成本控制... 942 8.3.4 项目质量管理... 942 8.3.4.1 质量管理计划... 943 8.3.4.2 项目质量控制... 943 8.3.5 人力资源管理... 944 8.3.6 项目沟通管理... 945 8.3.7 项目风险管理... 946 8.3.7.1 风险计划... 947 8.3.7.2 风险识别... 948 8.3.7.3 风险度量... 948 8.3.7.4 风险控制... 948 8.3.8 项目监理... 949 8.4 收尾阶段... 949 8.4.1 项目验收... 949 8.4.2 项目评估... 950 XI

8.4.2.1 信息技术评估... 951 8.4.2.2 管理效益评估... 952 9 基于 ITIL 的医院信息平台的管理... 953 9.1 医院 IT 环境分析... 953 9.1.1 IT 技术发展给医院带来的挑战... 953 9.1.2 医院 IT 环境的复杂... 953 9.1.3 医院业务对于 IT 环境的依赖... 953 9.2 基于 ITIL 的医院信息平台管理体系... 954 9.2.1 医院 IT 服务管理组成部分... 955 9.2.2 医院 IT 运维管理体系架构... 957 9.2.3 医院 IT 基础设施管理... 958 9.2.3.1 基于 ITIL 的医院信息平台设计原则... 958 9.2.3.2 IT 资源统一监控平台系统架构及技术实现... 960 9.2.4 IT 服务管理体系... 964 9.2.4.1 服务台... 964 9.2.4.2 事件管理... 966 9.2.4.3 问题管理... 968 9.2.4.4 变更管理... 970 9.2.4.5 发布管理... 973 9.2.4.6 配置管理... 974 XII

5 医院信息平台体系架构 5.1 平台体系架构 5.1.1 总体架构图 5-1 医院信息平台总体架构如上图所示, 医院信息平台的总体架构设计分为八个部分, 包括 : 医院门户平台医院信息平台应用层医院信息平台信息资源中心医院信息整合平台信息基础设施平台以及标准规范和信息安全与系统运维管理 491

5.1.1.1 门户平台门户平台是整个医院信息平台对内和对外使用和展示的界面, 根据不同的使用者部署不同的网络, 如下 : 内网信息门户 : 即应用整合门户, 主要针对医院内部用户, 对不同的角色, 提供相应的信息服务, 并针对管理层, 提供统一的业务管理和辅助管理支持 ; 外网公众服务门户 : 针对公众患者提供各项医疗卫生业务并开展所涉及的信息服务 ; 5.1.1.2 医院信息平台应用 ( 层 ) 基于医院信息平台, 通过基础业务数据的交换共享和整合, 结合实际的医疗业务和管理需要, 建立扩展应用, 主要包括 : 全院级病人主索引服务电子病历共享医院业务协同应用临床辅助决策支持医院管理辅助决策支持以及针对区域卫生协同业务的支撑应用 5.1.1.3 医院信息平台信息资源中心医院信息平台的信息资源中心用于整个平台各类数据的存储处理和管理, 主要包括 : 信息目录库基础信息库业务信息库临床文档信息库 CDR 交换信息库操作数据存储 ODS 数据仓库对外服务信息库智能化管理信息库 5.1.1.4 医院信息整合平台医院信息整合平台的主要任务以满足临床信息医疗服务信息和医院管理信息的共享和协同应用为目标, 采集相关业务数据, 并对外部系统提供数据交换服务, 包括与区域平台的数据交换信息资源整合平台为整个系统平台的数据来源提供了技术基础和保障, 通过信息标准交换原则的制定, 对业务系统提供标准的信息交换服务, 确保数据交换过程的安全性可靠性, 实现数据在系统平台范围内自由可靠可信的交换 5.1.1.5 信息基础设施平台信息基础设施平台是支撑整个医院信息平台运行的基础设施资源软硬件及网络等资源, 主要包括各类系统软件系统硬件网络设备安全设备容灾备份以及数据存储等 492

5.1.1.6 标准规范标准规范应该是贯穿于医院信息化建设的整个过程, 通过规范的业务梳理和标准化的数据定义, 要求系统建设必须遵循相应的规范标准来加以实施, 严格遵守既定的标准和技术路线, 从而实现多部门 ( 单位 ) 多系统多技术以及异构平台环境下的信息互联互通, 确保整个系统的成熟性拓展性和适应性, 规避系统建设的风险 5.1.1.7 信息安全与系统运维管理信息安全与系统运维管理是整个平台建设和运作的重要组成部分, 也应该贯穿项目建设的始终其中, 信息安全不仅包括技术层面的安全保障 ( 如网络安全系统安全应用安全等 ), 而且还包括各项安全管理制度, 因为只有在一系列安全管理的规章制度实行的前提下, 技术才能更好地为安全保障作出贡献同时, 完善的系统的运维管理也是系统稳定安全运行的重要保障 5.1.2 软件架构区域卫生信息平台应用系统一卡通系统电子病历管理系统医疗服务协作系统公共卫生协作系统综合决策支持系统居民公众服务系统电子病历 / 健康档案浏览器基于电子病历的医院信息平台注册服务电子病历存储服务个人注册服务个人基本信息病历概要门急诊病历记录住院病历记录健康体检记录转诊记录法定医院证明及报告其它数据仓库医疗卫生人员注册服务医疗卫生机构注册服务业务文档库索引服务业务服务数据服务事务处理 ODS 电子化文档库物资库术语 / 字典注册服务电子病历档案服务安全管理数据隐私数据配置信息医疗信息交换层病人服务系统医护工作站医技系统用药系统手术麻醉系统治疗系统费用结算系统医疗质控系统药事管理系统院感控制系统医疗风险管理人力管理系统财务管理系统物资管理系统临床服务医疗管理医院运营管理图 5-2 软件架构图 493

医院信息平台软件架构分为三个层次 : 最低层是医院业务系统, 中间是医院信息平台, 最上层是基于医院信息平台的应用系统医院信息平台的主要作用包括 : 1 接入医院业务系统 2 实现医院信息的统一管理 : 病人主索引电子病历决策支持数据业务协同数据对外服务数据区域卫生共享和协同数据 3 实现医院业务系统之间的协同 4 基于 3 和 4, 开发新型的应用, 包括电子病历共享医院决策支持医院业务协同对外公众服务区域卫生共享和协同应用医院信息平台包括 : 1 医院信息服务总线, 用以接入医院业务系统, 支撑医院业务系统之间的协同 2 注册服务, 实现医院基础信息和元数据信息的统一管理, 包括病人信息的注册, 是实现全院级病人主索引 (EMPI) 服务的基础, 医院人员的注册和科室的注册, 医疗卫生术语和字典的注册 3 电子病历文档存储与临床文档仓库 (CDR) 服务 4 数据仓库 5 电子病历浏览器 5.1.3 系统软硬件架构为了更好的对基于电子病历的医院信息平台建设提供参考, 我们对典型医院环境下的服务器部署现状做了分析依照医院的不同规模, 大致划分为大中型医院中等规模医院和小型医院 494

5.1.3.1 大中型医院服务器部署架构图 5-3 大中型医院信息系统服务器与存储系统部署方案 1) HIS EMR LIS 等关键业务系统, 多数的医院采用了 X86 架构的 PC 服务器,Windows Server 或 LINUX 平台为主, 双机集群方案 ; 采用 UNIX 服务器的医院也比较多, 且大多数还采用了 UNIX 双机集群模式, 主要是基于 UNIX 小型机本身的高可用角度考虑的 ; 2)PACS/RIS 以及超声病理心电等影像系统相对比较独立, 通常来说, 医院会单独进行部署, 影像系统的服务器通常由数据库服务器应用和归档服务器 RIS 服务器临床浏览服务器等组成, 其中 PACS 主数据库服务器一般双机模式 ; 3) 其他各种应用和管理类服务器一般采用 X86 架构 PC 服务器, 主要有中间件 ( 双机 ) 集成平台 ( 双机 ) 网络管理备份管理终端桌面管理防病毒管理域控制器等等 ; 4) 由于 HIS 系统是支撑医院基本业务开展的基础应用系统, 因此一般的大中型医院都部署有 HIS 门急诊业务应急系统, 主要是采用每天从在线数据库下传公用数据, 通过应用程序的设定, 当在线系统故障时, 临时启用应急系统 ; 5) 大中型医院的信息系统与外部网络的连接也是相当广泛的, 主要分为两部分 : 一是与医院业务紧密关联的区域系统, 例如医保系统新农合系 495

统社区卫生健康档案系统远程医疗的接入等等, 这些系统的接入一般都部署有前置服务器 ; 二是医院本身基于改善医患关系提高工作效率考虑基于 Internet 公网开展的一些外延应用, 主要有短信平台语音自助服务 OA 远程办公接入医院门户网站电子邮件系统等等 ; 5.1.3.2 中等规模医院服务器部署架构图 5-4 中等规模医院信息系统服务器与存储部署方案 1) 根据各个业务系统的上线时间不同, 采用搭积木形式, 逐步增加服务器 ; 例如 HIS 是最早上线的, 一般都有双机热备, 要上 EMR 时, 再部署 2 台双机服务器, 要上 LIS 时又部署服务器, 如此类推横向扩展, 与大医院一样也存在服务器资源浪费的问题 ; 2) 中型医院也同样会部署有各类外部业务系统的接入, 医保新农合等, 因此也需要前置机 ; 3) 至于管理类中间应用层外网应用应急备份等方面, 中型医院也通常采用要用什么就部署什么的思路, 很难找到共性 ; 4) 中型医院的服务器大多数采用的是 X86 架构 PC 服务器, 其中 HIS EMR PACS 等通常会采用中高端配置 ; 496

5.1.3.3 小型医院服务器部署架构图 5-5 小型医院信息系统服务器和存储部署方案 1)HIS 服务器, 有的是双机形式, 有的就只用单机运行 ; 2) 可能会有 LIS 系统, 单独配置 1 台服务器 ; 3) 根据需要会有一些前置服务器, 比如社区 EHR 接入医保新农合等等 ; 4) 小型医院的信息系统数据备份也比较简单, 通常会在服务器本地做一下备份, 然后定期在管理员的电脑上或做异地备份 ; 5) 小型医院的信息系统安全性和稳定性较差, 如果服务器出现故障, 基本就让信息系统处于瘫痪状态, 转为手工操作, 直到服务器修复 ; 且小型医院的 IT 维护力量非常薄弱, 因此采用简单有效低成本的服务器整合方案是非常有必要的 ; 目前已有一些地区, 在当地卫生主管部门的筹划下, 将小型医院的服务器全部集中到区级平台的数据中心集中管理, 本地不再部署服务器 ; 497

5.1.4 存储架构 5.1.4.1 大型规模的医院的存储规划方案 HIS HIS PACS RIS LIS 备份服务器 WAN 磁盘阵列磁带库库磁盘阵列数据中心灾备中心图 5-6 大型规模医院存储规划方案大型规模的医院对业务连续性要求更加苛刻, 在要求本地数据中型有完善业务连续性保障和数据安全的同时, 需要在远程建立灾备中心, 通过灾备中心防止一些自然人为等灾难因素在线存储 : 1 基于 IP 或者 FC 存储系统, 控制器缓存大于等于 16G, 支持高速硬盘和低速硬盘混插, 支持 SSD 硬盘技术 2 考虑未来扩容, 建议采用万兆 IP 或者 8Gb FC 存储系统 3 主存储容量至少 10T, 可支持快照镜像 CDP 技术基于 IP 复制技术 4 支持在线升级软件和存储扩容近线备份存储 : 1 建议采用基于万兆 IP 或者 8Gb FC 存储系统, 控制器缓存大于等于 16Gb, 支持高速硬盘和低速硬盘混插, 支持 SSD 硬盘技术 2 存储容量可以扩展 64TB 以上 498

灾难备份系统 : 离线存储 : 3 可支持快照镜像 CDP 技术基于 IP 复制技术 4 支持在线升级软件和存储扩容 1 支持基于增量的备份机制 2 支持断点续传 3 基于 IP 复制技术 1 采用 VTL 虚拟带库或者带库的方式 2 离线存储至少 20T, 存储容量最大可以扩展 64TB 以上 3 物理带库支持至少 1 个机械臂以上, 至少 2 个以上 LTO3\LTO4 驱动器, 磁带槽位可以达到 150 盘以上 5.1.4.2 中型规模的医院存储规划方案 HIS HIS PACS RIS LIS 备份服务器在线阵列近线阵列磁带库图 5-7 中型规模的医院存储规划方案中型规模的医院已经实现了最基本的数据集中存储和备份, 需要加强业务系统业务连续性方面因素, 在本地建设近线存储, 通过连续数据保护方式把在线阵列的数据备份到近线阵列之上, 当数据发生灾难时, 可以通过近线阵列进行恢复或直接把业务切换到近线阵列, 通过这种方式提升了存储系统整体的可靠性, 中型规模 499

医院已经具备一定规模的医疗影像设备数量, 影像数据的长期备份和归档可以采用物理带库进行在线存储 : 近线存储 : 离线存储 : 1 基于 IP 或者 FC 存储系统, 控制器缓存大于等与 4Gb 2 主存储容量至少 6T, 可扩展 100TB 以上, 可支持快照镜像 CDP 技术 3 支持在线升级软件和存储扩容 1 基于 IP 或者 FC 存储系统, 控制器缓存大于等于 4Gb, 支持高速 FC/SAS 硬盘和低速 SATA 硬盘混插. 2 存储容量最大可以扩展 200TB 以上, 可支持快照镜像 CDP 技术和基于 IP 复制技术 3 支持在线升级软件和存储扩容 1 采用磁带库的方式 2 离线存储至少 12T, 存储容量最大可以扩展 64TB 以上 3 物理带库支持至少 1 个机械臂 2 个以上 LTO4 驱动器 4 物理带库支持 LTO3\LTO4 驱动器 500

5.1.4.3 小型规模的医院存储规划方案 HIS HIS PACS RIS LIS 备份服务器磁盘阵列磁带库图 5-8 小型规模的医院存储规划方案小型规模医院存储部署通常是满足医院信息系统的数据实现基本的数据集中存储和备份需求, 服务器端通过与存储网络的连接, 把数据存储到磁盘阵列之上 ; 数据安全保障通过备份服务器对业务系统数据按照指定的周期进行数据保护, 通常在周一至周五夜间进行增量或者差异数据保护, 周六至周日进行一周数据的完全数据保护, 并把最终备份数据备份到磁带库中在线存储 : 备份软件 : 离线存储 : 1 基于 IP 或者 FC 存储系统, 控制器缓存大于等与 4Gb 2 主存储容量至少 2T, 可扩展到 60TB 以上, 可支持快照镜像 CDP 技术 3 支持在线升级软件和存储扩容 1 要求可以支持主流操作系统数据库文件等数据备份 2 支持 LAN-BASE LAB-FREE 等备份模式 1 离线存储至少 4T 2 采用 VTL 虚拟带库或者带库的方式 3 支持 LTO3\LTO4 驱动器 501

5.1.5 网络拓扑图 5-9 内外网分离的三层网络架构设计内外网分离的网络架构设计, 就是指将医院的内外网分别建设, 两网物理隔离内网主要承载医疗核心业务, 如 HIS LIS PACS 和计价系统等外网作为行政办公对外发布互联网医学资料查询的主要平台, 对于稳定性和保密性的要求低于内网, 并且接入终端及数据流特点也更为复杂内外网无共用设备和链路, 两网之间互不影响此种网络架构设计, 能够最大程度保证内网安全医院信息平台内外网分界如下 : 内网 : 内网核心区内网中心服务器区安全网络管理区数据灾备区外联接口区门诊终端接入区住院终端接入区医技终端接入区 502

外网 : 外网核心区互联网出口区外网中心服务器区行政终端接入区其他终端接入区 5.1.6 安全架构医院信息平台的信息安全体系覆盖信息系统安全所要求的各项内容, 本方案通过技术手段和非技术手段来保障平台中电子病历等相关数据信息免受各种形式的窃取破坏篡改以及非授权使用为实现这个目标, 需要从计算环境区域边界通信网络安全管理以及物理安全等多层面部署安全保障措施, 达到安全目标总体框架如下图所示 : 图 5-10 医院信息平台的信息安全体系总体框架如上图所示, 从技术体系上, 通过 PKI 技术中的数字证书等服务来实现计算环境区域边界通信网络的安全物理安全, 并基于关联分析技术建立统一的安全 503

管理中心, 实现数据系统网络等层次安全防护的数据交换和关联分析, 制定完善的安全管理策略, 并落实相关法规政策以及标准规范, 形成一体化的安全防护体系, 从而全面满足医院信息平台中的信息安全和隐私保护需求 5.2. 医院信息平台设计 5.2.1 注册服务功能注册服务用于医院信息平台各种共享服务资源的注册, 通过服务资源的发布 - 发现 - 访问机制, 实现服务资源共享注册服务是医疗信息闭环系统中最基础的服务之一注册服务包括对个人医疗卫生人员医疗卫生机构医疗卫生术语的注册管理服务, 系统对这些实体提供唯一的标识针对各类实体形成各类注册库 ( 如个人注册库医疗卫生机构注册库等 ), 每个注册库都具有管理和解决单个实体具有多个标识符问题的能力注册库具有一个内部的非公布的标识符本节将对这种机制进行描述, 并定义相关注册服务的基本功能接口要求等, 同时给出注册服务的参考实现 5.2.1.1 患者注册患者注册的目的患者注册用于对前来医院就诊患者的基本信息进行管理, 通过对病患者基本信息的统一管理, 可以实现对患者信息最完整的保存, 可以解决患者信息在各个系统中的不一致问题, 以避免重复录入患者基本信息的情况患者注册服务在医院信息平台上, 形成一个个人注册库, 安全地保存和维护个人的诊疗标识号基本信息, 并可为医疗就诊及公共卫生相关的业务系统提供人员身份识别功能患者注册库主要扮演着两大角色其一, 它是唯一的权威信息来源, 并尽可能地成为唯一的个人基本信息来源, 用于医疗卫生信息系统确认一个人是某个居民或患者其二, 解决在跨越多个系统时用到居民身份唯一性识别问题患者注册服务是医院信息平台正常运行所不可或缺的, 以确保记录在健康档案中的每个人被唯一 504

地标识, 他们的数据被一致地管理且永不会丢失患者注册信息模型患者注册信息的主要内容按照卫生部 2009 年电子病历基本架构与数据标准的规定, 应包括该标准的 H.02 服务对象标识 H.03 人口学 H.04 联系人 H.05 地址 H.06 通信等数据组具体数据规定如下 : 505

表 5-1 患者注册信息临床数据组数据元标识符 (DE) 数据元名称重复次数定义数据元值的数据类型表示格式数据元允许值 HR01.01.002.01 标识号 - 类别代码 1..1 特定环境下本人身份标识 ( 证明文件 ) 号码的类别代码 S N2 CV0100.03 个体标识号类别代码 HR01.01.002.02 标识号 - 号码 1..1 特定环境下本人身份标识 ( 证明文件 ) 号码 S N..30 HR01.01.002.03 标识号 - 生效日期 0..1 特定环境下本人身份标识 ( 证明文件 ) 号码的生效日期 D D8 H.02 服 HR01.01.002.04 标识号 - 失效日期 0..1 特定环境下本人身份标识 ( 证明文件 ) 号码的失效日期 D D8 务对象标识 HR01.01.002.05 标识号 - 提供标识的机构名称 0..1 提供本人身份标识的机构或单位的名称 S AN..70 HR02.01.001.01 姓名 - 标识对象 0..1 姓名的标识对象, 如本人姓名户主姓名母亲姓名丈夫姓名等, 默认值为本人姓名 S A..20 CV0100.01 姓名类别代码 HR02.01.001.02 姓名 - 标识对象代码 0..1 姓名的标识对象代码 S N2 CV0100.02 姓名标识对象代码 HR02.01.002 姓名 1..1 本人在公安户籍管理部门正式登记注册的姓氏和名称 S A..30 HR42.01.012 病人类型代码标识病人类型的代码 S N1 病人类型代码 506

临床数据组数据元标识符 (DE) 数据元名称重复次数定义数据元值的数据类型表示格式数据元允许值 H.02.001 个体生 HR51.03.003 ABO 血型 1..1 标识本人按照 ABO 血型系统决定的血型类别代码 S N1 CV5103.02ABO 血型代码物学标识 HR51.03.004 RH 血型 1..1 标识本人按照 Rh 血型系统决定的血型类别代码 S N1 0.Rh 阳性 1.Rh 阴性 3. 不详 H.02.002 个体危险性标识 HR01.03.001.01 个体危险性名称 1..1 个体危险性标识的名称 S AN..20 HR01.03.001.02 个体危险性代码 1..1 个体危险性标识的类别代码 S N2 个体危险性标识代码 HR02.02.001 性别代码 1..1 标识本人生理性别的代码 S N1 GB/T 2261.1-2003 个人基本信息分类与代码第 1 部分人的性别代码 H.03 人口学 HR02.03.001 年龄 ( 岁 ) 人的生存年数, 计量单位为岁 N N..3 HR02.04.001 国籍代码 0..1 标识本人所属国籍的代码 S AN3 HR02.05.001 民族代码 1..1 标识本人所属民族类别的代码 S N2 HR02.06.003 婚姻状况类别代码 1..1 本人当前婚姻状况类别的代码 S AN1 GB/T 2659-2000 世界各国和地区名称代码 GB 3304-1991 中国各民族名称的罗马字母拼写法和代码 GB/T 2261.2-2003 个人基本信息与分类代码婚姻状况代码 507

临床数据组数据元标识符 (DE) 数据元名称重复次数定义数据元值的数据类型表示格式数据元允许值标识职业编码系统的名称, 如国标职 HR02.07.011.01 职业编码系统名称 0..* 业类别代码传染病报告职业类别代 S AN..50 码 HR02.07.011.02 职业代码 0..* 标识本人当前职业类别的代码 S AN..3 GB/T 6565-1999 职业分类与代码 HR02.08.001 文化程度代码 0..1 标识本人受教育的最高程度类别的代码 S N2 GB/T 4658-1984 文化程度代码 HR30.00.001 出生日期 1..1 本人出生当天的公元纪年日期 D D8 出生时地址的详细描述, 包括省 ( 自 HR30.00.005 出生地 0..1 治区直辖市 ) 市 ( 地区 ) 县 ( 区 ) S AN..120 乡 ( 镇街道办事处 ) HR01.01.002.01 标识号 - 类别代码 0..1 特定环境下本人身份标识 ( 证明文件 ) 号码的类别代码 S N2 CV0100.03 个体标识号类别代码 HR01.01.002.02 标识号 - 号码 0..1 特定环境下本人身份标识 ( 证明文件 ) 号码 S N..30 H.04 联系人 HR01.01.002.03 标识号 - 生效日期 0..1 特定环境下本人身份标识 ( 证明文件 ) 号码的生效日期 D D8 HR01.01.002.04 标识号 - 失效日期 0..1 特定环境下本人身份标识 ( 证明文件 ) 号码的失效日期 D D8 HR01.01.002.05 标识号 - 提供标识的机构名称 0..1 提供本人身份标识的机构或单位的名称 S AN..70 508

临床数据组数据元标识符 (DE) 数据元名称重复次数定义数据元值的数据类型表示格式数据元允许值 HR02.01.001.01 姓名 - 标识对象 0..1 姓名的标识对象, 如本人姓名户主姓名母亲姓名丈夫姓名等, 默认值为本人姓名 S A..20 CV0100.01 姓名类别代码 HR02.01.001.02 姓名 - 标识对象代码 0..1 姓名的标识对象代码 S N2 CV0100.02 姓名标识对象代码 HR02.01.002 姓名 1..1 本人在公安户籍管理部门正式登记注册的姓氏和名称 S A..30 HR02.07.006 工作单位名称 0..* 本人工作单位的组织机构名称 S A..70 HR03.00.003 标识地址类别的代码 0..* 标识地址类别的代码 S N1 CV0300.01 地址类别代码 HR03.00.004.01 地址 - 省 ( 自治区直辖市 ) 0..* 地址中的省自治区或直辖市名称 S A..20 HR03.00.004.02 地址 - 市 ( 地区 ) 地址中的市或地区名称 S A..20 HR03.00.004.03 地址 - 县 ( 区 ) 地址中的县或区名称 S A..20 H.05 地址 HR03.00.004.04 地址 - 乡 ( 镇街道办事处 ) 地址中的乡镇或城市的街道办事处名称 S A..20 HR03.00.004.05 地址 - 村 ( 街路弄等 ) 地址中的村或城市的街路里弄等名称 S A..20 HR03.00.004.06 地址 - 门牌号码地址中的门牌号码 S AN..20 HR03.00.005 邮政编码 1..1 由阿拉伯数字组成, 用来表示与地址对应的邮局及其投递区域的邮政通 S N6 信代号 HR03.00.006 行政区划代码 1..1 标识中华人民共和国县级及县级以上行政区划的代码 S N6 509

临床数据组数据元标识符 (DE) 数据元名称重复次数定义数据元值的数据类型表示格式数据元允许值 HR04.00.001.01 联系电话 - 类别 0..* 联系电话所属者类别的名称 S A..20 H.06 通信 HR04.00.001.02 联系电话 - 类别代码 0..* 标识联系电话所属者类别的代码 S N1 CV0400.01 联系电话类别代码 HR04.00.001.03 联系电话 - 号码 0..* 电话号码, 包括国际国内区号和分机号 S N..20 HR04.00.002 电子邮件地址 0..* 本人的电子邮箱名称 S AN..20 H.07 医 HR02.09.001.01 医疗保险 - 类别 0..* 本人参加的某个医疗保险的类别名称 S A..20 保 HR02.09.001.02 医疗保险 - 类别代码 0..* 本人参加的某个医疗保险的类别代码 S N2 CV0209.01 医疗保险类别代码 HR21.01.100.01 机构名称 1..1 卫生服务机构的组织机构名称 S AN..70 GB/T 17538-1998 全国干部人事管理信息系统数据结构 HR21.01.100.02 机构组织机构代码 0..* 卫生服务机构的组织机构代码 S N22 H.08 卫生服务机构 HR21.01.100.03 机构负责人 ( 法人 ) 0..* 卫生服务机构负责人的姓名 S A..30 HR21.01.100.04 机构地址 0..* 卫生服务机构的地址 S A..100 HR21.01.100.05 科室名称 0..* 卫生服务机构内就诊科室的名称 S AN..50 HR21.01.100.06 机构角色 0..* 标识机构在某项活动中的角色, 如转出机构转入机构 S AN..50 HR21.01.100.07 机构角色代码 0..* 标识机构在某项活动中角色的代码 S N2 机构角色代码 NA H.09 卫 HR22.01.100 服务者姓名 1..1 卫生服务提供者的姓名 S A..30 510

临床数据组数据元标识符 (DE) 数据元名称重复次数定义数据元值的数据类型表示格式数据元允许值生服务者 HR22.01.101.01 服务者职责 ( 角色 ) 1..1 标识服务者在某项活动中的职责和角色, 如接诊医师收费员化验员 S A..30 HR22.01.101.02 服务者职责 ( 角色 ) 代码 0..* 标识服务者在某项活动中的职责和角色的代码 S N2 服务者职责 ( 角色 ) 代码 NA HR22.01.102 服务者医师资格标志 0..1 标识服务者所具备的医师资格, 如主任医师副主任医师 S A..30 HR22.01.103 服务者学历 0..1 标识服务者求学的经历, 如本科大专 S A..30 HR22.01.104 服务者所学专业 1..* 标识服务者所学的学业门类, 如公共卫生专业卫生管理专业等 S A..30 HR22.01.105 服务者专业技术职称 1..* 标识服务者的专业技术等级, 如高级中级等 S A..30 HR22.01.106 服务者职务 1..* 标识服务者所担任的职务工作 S A..30 511

患者注册信息来源患者注册信息根据就诊情况可以来自以下几个的方面 : 患者自述及相关有效证件患者个人健康档案患者转诊电子病历患者个人基本信息的合并与最优化, 由医院 MPI 系统完成患者注册的流程患者注册的主要流程为, 当病人前来就诊时, 对患者基本信息进行收集, 并将此信息发送到病人主索引系统进行病人注册, 病人主索引系统根据传入的基本信息同病人主索引库中信息进行比对并计算匹配度, 匹配度会有三个结果 : 完全匹配完全不匹配可能匹配, 根据匹配度会有三种结果返回给注册者, 如果完全匹配, 那么说明已经拥有此病人的基本信息, 可以使用此病人已经获得的 GUID 继续就诊, 如果完全不匹配, 那么说明没有此病人的基本信息, 那么分配给此病人一个新的 GUID 进行就诊, 如果可能匹配, 则需要注册者根据匹配列表进行人工选择, 是否已有此病人的记录 512

表 5-2 患者注册中所涉及的功能个人注册操作查询个人信息服务获取个人 ID 服务注册新人服务更新个人信息服务作废个人信息服务个人身份匹配服务描述根据部分信息查找个人根据所有符合要求的个人信息返回个人 ID 添加一个新的个人信息根据个人 ID 更新其它信息作废某位个人信息及其相关 ID 根据模糊身份匹配算法, 对数据中心个人身份进行合并注册异常处理回滚处理 5.2.1.2 机构 ( 科室 ) 注册机构 ( 科室 ) 注册的目的科室注册用于对医院各科室基本信息进行管理, 通过对科室基本信息的统一管理, 可以向患者提供最完整的科室特色信息通过建立医疗卫生机构注册库, 提供本医疗机构所有科室的综合目录, 系统为每个科室分配唯一的标识, 可以解决居民所获取的医疗卫生服务场所唯一性识别问题, 从而保证在维护居民健康信息的不同系统中使用统一的规范化的标识符, 同时也满足与各医疗卫生机构服务点层的互联互通要求科室注册信息模型科室注册信息的主要内容按照卫生部 2009 年电子病历基本架构与数据标准的规定, 应包括该标准的 H.08 卫生服务机构数据组具体数据规定如下 : 513

表 5-3 科室注册信息临床数据组数据元标识符 (DE) 数据元名称重复次数定义数据元值的数据类型表示格式数据元允许值 HR04.0 0.001.0 1 联系电话 - 类别 0..* 联系电话所属者类别的名称 S A..20 H.06 通信 HR04.0 0.001.0 2 HR04.0 0.001.0 3 联系电话 - 类别代码联系电话 - 号码 0..* 0..* 标识联系电话所属者类别的代码电话号码, 包括国际国内区号和分机号 S S N1 N..20 CV0400.01 联系电话类别代码 HR04.0 0.002 电子邮件地址 0..* 本人的电子邮箱名称 S AN..20 GB/T HR21.0 1.100.0 1 机构名称 1..1 卫生服务机构的组织机构名称 S AN..70 17538-1998 全国干部人事管理信息系统数据结构 HR21.0 1.100.0 2 机构组织机构代码 0..* 卫生服务机构的组织机构代码 S N22 H.08 卫 HR21.0 1.100.0 3 机构负责人 ( 法人 ) 0..* 卫生服务机构负责人的姓名 S A..30 生服务机构 HR21.0 1.100.0 4 机构地址 0..* 卫生服务机构的地址 S A..100 HR21.0 1.100.0 5 科室名称 0..* 卫生服务机构内就诊科室的名称 S AN..50 HR21.0 标识机构在某项活 1.100.0 机构角色 0..* 动中的角色, 如转出 S AN..50 6 机构转入机构 HR21.0 1.100.0 7 机构角色代码 0..* 标识机构在某项活动中角色的代码 S N2 机构角色代码 NA 514

表 5-4 医疗卫生机构 ( 科室 ) 注册中所涉及的服务功能医疗卫生机构注册操作列出医疗卫生机构场所服务查询医疗卫生机构服务获取医疗卫生机构 ID 服务注册医疗卫生机构服务更新医疗卫生机构信息服务废除医疗机构描述根据条件返回满足要求的场所列表根据部分信息查找机构根据所有符合要求的信息返回机构 ID 添加一个新的医疗卫生机构根据机构 ID 更新其它信息根据相关要求作废指定科室信息 5.2.1.3 医疗卫生服务人员注册医疗卫生服务人员注册的目的医生注册用于对医疗单位内部所有医疗服务人员的基本信息进行注册和管理, 医疗服务人员包括医生护士医技人员药事人员等全部提供医疗服务的医务人员, 通过对医生基本信息专业信息的记录, 可以实现对医疗服务人力资源的全面掌控统一管理合理配置医疗卫生人员注册库, 是一个单一的目录服务, 为本区域内所有卫生管理机构的医疗服务提供者, 包括全科医生专科医生护士实验室医师医学影像专业人员疾病预防控制专业人员妇幼保健人员及其他从事与居民健康服务相关的从业人员, 系统为每一位医疗卫生人员分配一个唯一的标识, 并提供给平台以及与平台交互的系统和用户所使用医疗卫生服务人员注册信息模型医疗卫生服务人员注册信息的主要内容按照卫生部 2009 年电子病历基本架构与数据标准的规定, 应包括该标准的 H.09 卫生服务者数据组具体数据规定如下 : 515

表 5-5 卫生服务人员注册信息临床数据组数据元标识符 (DE) 数据元名称重复次数定义数据元值的数据类型表示格式数据元允许值 HR04.0 0.001.0 1 联系电话 - 类别 0..* 联系电话所属者类别的名称 S A.. 20 H.06 通信 HR04.0 0.001.0 2 联系电话 - 类别代码 0..* 标识联系电话所属者类别的代码 S N1 CV0400.01 联系电话类别代码 HR04.0 0.001.0 3 联系电话 - 号码 0..* 电话号码, 包括国际国内区号和分机号 S N.. 20 HR04.0 0.002 电子邮件地址 0..* 本人的电子邮箱名称 S AN..20 HR22.0 1.100 服务者姓名 1..1 卫生服务提供者的姓名 S A.. 30 HR22.0 1.101.0 1 服务者职责 ( 角色 ) 1..1 标识服务者在某项活动中的职责和角色, 如接诊医师收费员化验员 S A.. 30 HR22.0 1.101.0 2 服务者职责 ( 角色 ) 代码 0..* 标识服务者在某项活动中的职责和角色的代码 S N2 服务者职责 ( 角色 ) 代码 NA H.09 卫生服务者 HR22.0 1.102 服务者医师资格标志 0..1 标识服务者所具备的医师资格, 如主任医师副主任医师 S A.. 30 HR22.0 1.103 服务者学历 0..1 标识服务者求学的经历, 如本科大专 S A.. 30 HR22.0 1.104 服务者所学专业 1..* 标识服务者所学的学业门类, 如公共卫生专业卫生管理专业等 S A.. 30 HR22.0 1.105 服务者专业技术职称 1..* 标识服务者的专业技术等级, 如高级中级等 S A.. 30 HR22.0 1.106 服务者职务 1..* 标识服务者所担任的职务工作 S A.. 30 516

医疗卫生服务人员注册流程医生注册流程是, 首先建立医生注册中心, 将医院全部医疗服务人员的信息整理后批量注册, 当有新医生加入或医生离职, 资格提升, 或吊销行医许可证, 那么需要及时通过人事系统调用医生注册服务, 对相关信息进行更新作为院内医疗服务人员信息的唯一管理者, 医生注册服务向授权管理访问控制及其它需要使用医护人员信息的业务系统提供信息发布服务, 感兴趣的系统可以订阅医生注册主题表 5-6 医疗卫生人员注册中所涉及的服务功能医疗卫生人员注册操作查询医疗卫生人员信息服务获取医疗卫生人员 ID 服务注册医疗卫生人员服务更新医疗卫生人员信息服务医疗卫生人员身份匹配服务描述根据部分信息查找卫生人员根据所有符合要求的人员信息返回卫生人员 ID 添加一个新的医疗卫生人员信息根据卫生人员 ID 更新其它信息根据模糊身份匹配算法, 对数据中心医疗卫生人员身份进行合并医疗卫生服务人员角色管理基于角色的访问控制 (RBAC,Role Based Access Contro1), 其组成要素有资源权限角色用户, 控制的实质是在用户和权限之间建立一种机制, 以角色为单元来分配系统的权限, 用户通过扮演角色获得了对资源的访问权限在医院的实际应用中可以按照相关人员的工作内容及所需要访问的系统资源来划分出多个业务角色, 每个角色被赋予对一定资源的访问控制权限角色之间的权限可以交叉, 用户所获得的权限为其扮演的所有角色的权限并集角色可以继承, 通过继承的方式下级角色拥有上级角色的授权, 以此构建出完整的角色树应用系统根据角色信息和资源访问控制列表 (Access Control List, ACL) 确定医护人员的功能权限用户的身份认证可以借助数字证书由医院信息平台和第三方机构共同完成角色对资源的访问分为公共和私有两种类型, 私有类型的访问其继承者不能 517

拥有, 公共类型的访问其继承者通过继承自动拥有角色可以根据控制的资源粒度划分为平台级角色和应用级角色平台级角色是整个全院信息系统的基础角色, 独立于具体的应用系统之上, 它在比较粗的粒度上控制平台级资源的访问应用级角色针对特定应用的角色, 它可以是应用内独立的角色, 也可以是继承于平台级角色应用角色是在比较细力度上控制应用级资源的访问从平台角色继承的应用角色自动具有平台级角色的公共权限, 可以访问平台级的公共资源对应于角色的划分, 角色的管理也分为平台角色管理和各应用的角色管理平台角色管理负责平台级资源的访问控制, 应用角色管理负责各应用内部资源的访问控制, 继承自平台角色的应用角色在访问平台资源时可以以父类角色访问医院可以按照医护人员工作角色建设医疗卫生服务人员 RA 管理中心, 分别设置医生护士检验管理等多个医务角色, 每个角色可被赋予相应的权限和某一个保密等级角色按照医务人员的工作内容采用面向对象的方法来定义角色对象存储在 RA 服务器中角色信息应按照国家有关规定根据医护人员注册信息确定医护人员的责任权利和执业时效等应符合国家及卫生部相关法律法规和办法, 例如中华人民共和国执业医师法医师执业注册暂行办法医师资格考试暂行办法医师外出会诊管理暂行规定中华人民共和国护士管理办法乡村医生从业管理条例等等, 同时身份认证应遵从卫生部的卫生系统电子认证服务管理办法 ( 试行 ) 等办法 5.2.1.4 术语注册术语注册信息的主要内容术语注册用于从数据定义层次来解决各系统的互操作问题术语的范围包括医疗卫生领域所涉及到的各类专业词汇, 以及所遵循的数据标准建立术语和字典注册库, 用来规范医疗卫生事件中所产生的信息含义的一致性问题术语可由平台管理者进行注册更新维护 ; 字典既可由平台管理者又可由机构来提供注册更新维护各系统使用术语库, 根据术语库的更新频率, 及其数据量级, 可以通过在线离线两种方式来获取服务, 如果选择离线方式, 那么需要考虑到更新频率和更新 518

策略的问题, 对于更新频率较多且数据量较大的术语, 应采用订阅发布机制来完成术语注册信息模型基于 UDDI/WSDL 的注册服务参考实现采用基于 XML 表示的注册信息, 其数据结构中包括四个核心部分 : 业务实体 (bussinessentity ) 业务服务 (businessservice) 绑定模板 (bindingtemplate) 和技术模型 (tmodel), 它们的结构及相互之间的关系如下图所示 : 图 5-11 注册服务其中业务实体用于对提供服务的单位机构等的基本情况进行描述, 同时包含有该单位或机构提供服务资源的描述信息 - 业务服务业务服务用于对服务资源的内容分类体系等基本信息进行描述, 同时包含 519

有对服务资源技术信息的描述内容 - 绑定模板绑定模板用于描述服务资源的访问信息服务资源访问信息以服务描述语言 (WSDL) 进行描述技术模型相对独立于其它三个部分, 用于描述服务资源相关的技术规范协议命名空间等信息术语注册的流程术语注册的流程是, 首先对各系统所使用的专业词汇遵循标准进行收集和整理, 当全部术语确定后, 将其注册入术语库由于某些术语是可以不断扩充的, 随着业务的发展, 需要加入新的数据, 此时首先应该通过术语注册申请服务来进行增加新术语的申请操作, 术语管理者进行评判通过后, 才可以正式加入术语库表 5-7 医疗卫生术语和字典注册中所涉及的服务功能医疗卫生术语和字典注册操作列出术语和字典服务查询卫生术语和字典服务注册卫生术语和字典服务更新卫生术语和字典信息服务描述根据条件返回满足要求的术语及字典列表根据部分信息查找术语和字典信息添加一个新的医疗卫生术语或字典根据术语和字典 ID 更新其它信息术语注册服务接口实现基于 UDDI/WSDL 的注册服务参考实现检索接口 GetDescriptors 注册管理接口 RegisterService, 接口实现说明如下表所示 : 表 5-8 注册服务参考实现检索接口接口实现接口功能 GetDescriptors UDDI Inquire 利用 UDDI 的 Inquire API 实现对注册信息库的检索, 查询符合要求的服务资源描述 -UDDI 注册信息 RegisterService UDDI Publication 利用 UDDI 的 Publication 和 Replication API 实现对注册信息的发布, 包括 : 注册注销注册信息更新 520

5.2.1.5 注册库和注册服务服务注册用于对企业服务总线上所提供的各类基础服务, 以及外部系统通过总线开放的业务服务进行注册和管理服务注册, 可以提供两方面的服务, 首先是对服务的统一管理, 其次是提供容灾处理, 自动服务迁移的功能服务注册的流程是, 首先建立一个服务注册中心, 平台内部的系统, 以及平台接入的系统, 需要将所能提供的服务, 通过调用服务注册 API, 全部注册到服务注册中心里当其它系统希望调用已注册服务的系统的功能时, 服务的使用者可以通过向服务注册中心查询 API, 来找到此服务, 并进一步获取到中心所保存的服务描述, 最后通过描述中所提供的访问地址来访问这个服务如果已经注册的系统发生了崩溃, 或暂时无法提供服务, 那么可以暂时将已注册的信息禁用, 如果还有备份系统可以使用, 那么也可以通过调用服务更新 API, 将新的服务描述信息更新到服务注册中心, 当服务的使用者去调用服务提供者所提供的服务时, 如果发现无法访问的时候, 可以调用服务对比 API, 将中心和本地缓存的服务描述信息进行对比, 如果发现中心的信息已经更新, 再获取服务的最新描述信息, 并重新建立服务绑定, 完成服务连接的迁移一注册服务注册服务作为一种网络服务, 用于数据服务资源的共享服务提供者开发服务资源, 通过对服务资源描述信息的注册发布其开发的网络服务 ; 应用系统通过对服务注册信息的检索发现网络服务资源注册信息对服务资源进行描述, 包括服务内容用途服务资源定位信息等内容, 同时说明了对服务资源进行访问和使用的具体方法, 如 : 访问接口协议参数等 ; 应用系统以此对网络服务资源进行访问注册服务在开放的分布式的数据共享工程中, 能够帮助应用系统定位访问并使用任意的服务资源, 这种系统能力, 对于动态的异构环境是十分重要的注册服务提供对服务资源的发布发现和访问功能 : 服务资源发布服务提供者开发某种网络服务, 通过描述信息所包含的相应内容对该服务进行描述, 包括网络服务资源的内容用途定位信息以及访问和使用服务的细节服务提供者将服务描述信息注册到注册服务器注册服务器对 521

服务资源描述信息进行发布, 以便服务访问者进行访问注册服务对服务描述和服务实现是有区分的不同的服务提供者可以以不同的技术和方式进行实现注册服务器以不同的服务实例注册这些服务资源 ; 以相同的服务类别对这些服务资源进行发布这样可以允许服务请求者 ( 应用系统 ) 在开发部署或运行阶段能够绑定特定的服务实例服务资源审批服务提供者提交资源发布申请后, 应由服务管理者进行审批审批的方式可以是自动的也可以是人工干预的, 审批的内容包括技术审批 ( 形势审批 ) 和内容审批当管理者判定该服务功能正确, 且不会妨碍已有服务的运行, 服务才可以发布服务资源发现服务请求者通过注册服务提供的发现功能, 查找到特定的服务资源注册信息通过服务注册信息, 服务请求者可以获得服务资源的定位信息, 以及服务资源的访问接口, 以及参数和消息的定义, 以便连接服务提供者发布的服务资源服务资源访问服务提供者检索到服务资源注册信息, 通过注册信息中的相应内容可以获得服务实现的定位信息, 接口规范, 参数及消息定义等信息服务提供者可以绑定并访问服务提供者发布的服务实例二注册服务概念模型注册服务的概念模型描述了注册服务所涉及的三个角色以及三个操作环节如下图所示, 是注册服务的概念模型 : 图 5-12 注册服务概念模型 522

服务提供者网络服务资源的开发者服务提供者根据一定的标准规范, 为实现特定的功能, 开发网络服务服务提供者所面临的问题是如何在一个分布的异构的环境中将服务资源发布出去, 以提供更多用户的访问服务请求者网络服务资源的调用者服务请求者为实现特定的应用系统功能, 需要访问并使用网络服务资源服务请求者通过一系列服务调用, 实现应用系统中所需的功能服务请求者所面临的问题是如何在一个分布的异构的环境中找到所需的服务资源, 又如何对这个服务资源进行访问服务代理服务提供者和服务请求者的中介服务代理为服务提供者提供发布服务资源的空间, 为服务请求者提供发现服务资源的渠道服务请求者通过服务代理获得所需服务的详细信息, 于是可以与服务提供者进行连接, 访问服务提供者发布的服务资源在注册服务的工作机制中, 包含三个重要的环节 : 发布发现和访问发布服务提供者公布其开发的服务资源的手段服务提供者通过将服务描述信息注册到服务代理完成服务资源的发布服务描述信息包含对服务资源的详细说明, 包括 : 服务提供者的基本情况, 服务中, 并提供服务请求者检索的功能通过服务提供者的注册和服务请求者的检索对服务资源进行发布发现服务请求者寻找其所需服务资源的手段服务请求者通过对服务描述信息所描述的服务提供者以及服务资源本身特征的查询, 可以发现所需的服务资源访问服务请求者从服务描述信息中可以获得服务资源的定位及访问信息, 如 : 服务资源的网络地址, 通讯协议, 消息格式等服务请求者可以手工地或程序化地构造服务访问请求, 并连接服务资源地址, 发送服务请求消息, 以实现服务的访问在注册服务的工作机制中, 服务资源的描述信息是十分重要的服务描述信息在发布发现及访问的过程中起着不同的作用服务描述信息包含有服务提供者的基本信息, 如 : 提供者名称, 涉及的业务领域等, 服务代理以这些基本信息对服务提供者进行分类, 以支持对服务资源的发现服务描述信息包含有服务的非功能性的信息, 如 : 服务内容描述, 服务用途 523

等, 服务代理可以针对这些信息建立复杂的分类系统, 以支持对服务资源的发现服务描述信息包含有服务访问接口的描述, 如 : 接口的标识, 允许的操作, 数据类型以及访问协议等服务请求者使用这些信息连接服务提供者并调用服务功能注册服务与分布系统的其它服务及标准的关系如下图所示 : 图 5-13 注册服务与分布系统标准关系三注册服务结构参考模型注册服务的功能是通过参与注册服务的三个角色共同实现的, 注册服务规范定义角色之间的接口, 通过接口实现注册服务的功能下图是注册服务结构的参考模型, 应用服务器实现查询及发现接口, 向应用客户端 ( 服务请求者 ) 提供注册服务的发现功能, 帮助应用客户端寻找所需的服务资源并且, 应用服务器实现注册管理接口, 向网络服务资源 ( 服务提供者 ) 提供服务描述信息的注册功能, 帮助网络服务资源发布服务实例应用客户端通过服务实例的描述信息了解服务访问的细节, 访问服务实例所提供的具体功能 524

图 5-14 注册服务结构参考模型注册管理接口用于对服务描述信息进行注册更新以及组织和管理注册管理是服务提供者和服务代理之间的接口查询及发现用于人工地或程序化地发现发布的注册信息该接口是服务请求者与服务代理之间的接口访问用于协商并绑定与服务资源通讯的请求 / 响应的类型及语义访问接口是服务请求者与服务提供者之间的接口该接口通过服务描述信息的相应内容进行定义的, 服务请求者根据这些信息确定访问服务的细节, 如 : 通讯协议和连接方式等四注册服务消息注册服务访问基于客户端和注册服务器之间的消息传递注册服务采用 HTTP 协议传递服务消息, 并采用无状态的通讯模式, 客户端发送注册服务请求, 注册服务器进行操作并返回响应下图是注册服务消息的逻辑模型 : 525

图 5-15 注册服务消息逻辑模型注册服务消息 (WrsMessage) 注册服务消息定义了注册服务消息的核心参数该类为注册服务消息的基类, 所有服务消息类均继承自该类注册服务请求 (WrsRequest) 注册服务请求消息定义了注册服务请求的核心参数, 该类是请求消息的基类注册项提取请求 (GetDescriptorsRequest) 检索请求消息定义了注册服务客户端检索注册信息的操作请求注册服务器处理该请求, 并执行对注册信息库的检索注册请求 (RegisterServiceRequest) 注册管理请求消息定义了注册服务客户端进行服务资源注册注销注册信息更新以及注册信息库的建立和删除的操作请求注册服务器处理该请求, 并执行相应的注册信息管理操作能力信息请求 (GetCapabilitiesRequest) 注册服务能力描述请求消息定义了注册服务客户端要求服务器解释自身能力情况的请求注册服务响应 (WrsResponse) 注册服务响应消息定义了注册服务响应的核心参数, 该类是响应消息的基类 526

图 5-16 注册服务响应模型注册项提取响应 (GetDescriptorsResponse) 检索响应消息定义了注册服务器执行注册信息检索的响应消息结构注册响应 (RegisterServiceResponse) 注册管理响应消息定义服务器执行注册管理操作的响应结果能力信息响应 (GetCapabilitiesResponse) 注册信息查询接口 (GetDescriptors) 该接口提供注册服务客户端对注册信息的检索功能接口参数是注册服务的检索请求消息注册服务器处理检索请求消息, 根据检索请求消息指定的操作细节对注册信息库进行检索, 产生符合要求的注册信息, 并以检索响应消息返回客户端注册功能接口 (RegisterService) 该接口提供注册注册注销注册信息更新注册库建立和删除功能接口参数是注册服务的注册管理请求消息, 请求消息中指定注册服务管理的具体操作注册服务器处理管理请求, 根据请求所指定的具体操作进行注册注销等, 并根据操作执行状态返回响应消息五注册库和注册信息数据结构注册库用于存放各类在医院信息平台上注册的公用服务信息, 由于各种注册信息结构各异, 一般采用 XML 格式予以存储将元数据作为注册信息描述服务资源基于目录服务 / 服务元数据的注册服务参考实现, 以服务元数据作为注册信息对服务资源进行描述服务元数据的内容及结构遵循 ISO-19115 地理信息元数 527

据及 ISO-19119 地理信息服务标准图 5-17 地理信息服务标准模型上图是 ISO-19119 对服务资源技术细节描述的核心内容, 该部分内容对服务的名称接口规范以及接口操作等技术细节进行详细描述, 用于服务请求者对服务实例进行访问服务资源描述的核心内容包括服务接口描述和服务实例描述服务接口描述用于对服务接口的技术信息进行描述, 包括服务类型及接口操作接口操作对接口操作的技术信息进行描述, 包括参数等服务实例描述用于对该类型服务的实例进行描述, 包括访问信息如地址端口等服务资源技术细节的描述包含在服务资源的元数据中, 服务资源的元数据描述采用 ISO-19115 所定义的数据结构 528

5.2.2 患者主索引 (MPI) 5.2.2.1 患者主索引 (MPI) 和机构级患者主索引 (EMPI) 患者个人主索引 MPI(master patient identifiers), 是指在特定域范围内, 用以标识该域内每个病人实例并保持其唯一性的编码病人唯一标识是指用于临床实际业务并且能够辅助进行病人信息唯一性识别, 在该域或跨域各涉众均可见的病人唯一编码患者主索引服务是指为保持在多域或跨域中用以标识病人实例所涉及的所有域中病人实例的唯一性, 所提供的一种跨域的系统服务各地可采用社保卡 ( 市民卡 ) 加补充的健康卡来进行唯一标识的加载与识别 MPI 是一个十分宽泛的概念, 但它通常是和患者主 ID 域的建立联系在一起的这个主 ID 域相对其他的 ID 域, 通常可以在更大的范围内适用, 是一个机构级别的 ID 域将多个患者 ID 域分级包含入一个患者主 ID 域中的方法, 可以被看作是交叉索引的一个特殊用法, 其中的各个 ID 域中的 ID 都和主 ID 域中的 ID 建立交叉索引关系下图描述了两种可能采用的配置方式图 5-18 PIX 集成规范与 MPI 的关系如上图所示, 一个典型的 MPI 方式中的患者主 ID 域 ( 域 C), 可以被认为是 PIX( 患者标识交叉索引 ) 方式中的一个普通的患者 ID 域是否将一个覆盖全机构范围的系统 ( 如临床数据仓库 ) 作为主 ID 域仅仅是一个结构选择另外, 有时候这种结构假设, 域 A 中的系统不仅要管理域 A 中的 ID, 还需要知道域 C 529

中的 ID 在 PIX 集成规范中, 某个系统被设计部署为跨多个 ID 域进行工作, 这是另外一种结构的选择以这种角度看, 被称作 MPI 的实体 ( 图中用椭圆圈起 ) 实际上是患者标识信息源角色和 PIX 管理器角色的混合体 PIX 集成规范可以和一个已经部署了 MPI 的环境共存, 还可以进一步为此环境提供更大的扩展性 PIX 规范还支持很多其他部署配置方式, 尤其是在一个覆盖其他 ID 域的主 ID 域并不是必需的情况下 ( 例如, 存在多个域的联合体, 但其中并没有主 ID 域 ) 在本文中,MPI 一般指医院内部使用的患者主索引,EMPI(Enterprise master patient identifiers, 机构级 MPI ) 通常指区域范围内使用的患者主索引 MPI 信息的主要内容按照卫生部 2009 年电子病历基本架构与数据标准的规定, 应包括该标准的 H.02 服务对象标识 H.03 人口学 H.04 联系人 H.05 地址 H.06 通信等数据组其中主要元素包括 : 患者主 ID 业务系统 ID 病人 ID 姓名性别出生日期出生地民族母亲姓名婚姻状况身份证号住址电话等 5.2.2.2 患者标识交叉索引不同医疗机构采用不同的标识码标识同一个患者, 当患者在不同医疗机构间转诊需要交换转诊或协作信息进而共享医疗文档时, 首先要求能够准确识别患者的身份, 这就需要一个交叉索引系统, 把患者在不同医疗机构的标识码通过索引联系起来, 在需要访问某个系统时可以提供患者在该系统的识别码下图展示不同系统通过交叉索引系统注册和提供患者标识, 从而顺利完成跨系统信息访问的任务 530

图 5-19 交叉索引注册和使用 1) A 医院向交叉索引管理系统输入患者标识信息 2) 交叉索引系统将输入的信息与系统中的现有患者进行匹配, 形成 A 医院患者标识与现有患者的交叉索引 3) B 医院向交叉索引管理系统输入患者标识信息 4) 交叉索引系统将输入的信息与系统中的现有患者进行匹配, 形成 B 医院患者标识与现有患者的交叉索引 5) A 医院系统需要访问一位患者在 B 医院的资料, 向 B 医院系统发送请求 6) A 医院的请求中只有 A 医院的患者标识, 因此 B 医院收到请求后首先到交叉索引管理系统查询该患者在本院的标识 7) B 医院系统获得请求的患者在本院的标识后可以在本院系统查找该患者的资料 8) B 医院系统将结果回复给请求的 A 医院系统如上面的一般场景所述, 交叉索引系统主要提供索引注册和索引查询服务, 另外还有一些保证系统运转的系统管理和维护需求 531

5.2.2.3 MPI 服务功能图 5-20 患者标识交叉索引系统服务用例患者信息注册业务系统希望把一个病人的索引加入到交叉索引系统时, 向交叉索引系统传送请求注册消息, 消息中包含待注册的病人信息, 主要元素包括 : 业务系统 ID 病人 ID 姓名性别出生日期出生地民族母亲姓名婚姻状况身份证号住址电话等交叉索引系统通过匹配规则检查系统中是否已存在该病人的索引, 按照新增索引或更新索引两种情况分别处理新增索引需要在交叉索引系统中记录业务系统的索引, 同时产生主索引如果该病人在交叉索引系统中有潜在重复的记录, 还需要记录潜在重复信息更新索引需要更新匹配的业务系统的索引, 同时更新主索引主索引更新时, 需要对订阅主索引的系统发布更新的主索引登记病人流程图示如下 : 532

图 5-21 登记病人流程患者信息匹配接收到外部系统登记病人的请求信息后, 交叉索引系统首先使用业务系统号 + 病人局部 ID(LID) 查找, 如果存在精确匹配的索引, 只需要对原索引信息进行更新即可, 如果没有找到精确匹配的病人索引, 则需要根据病人的其它信息和系统中的记录进行匹配交叉索引匹配引擎首先通过预定义的匹配条件选定一批相近的记录, 对每个记录计算匹配度, 再根据这组记录的匹配度确定请求登记的信息属于新病人现有病人或者潜在重复病人这里所说的潜在重复是指两个病人的信息匹配度比较高但还不足以判定为同一个人患者信息匹配流程如下 : 533

通过系统号和 LID 查找索引匹配不成功匹配成功检索可能匹配集合没有匹配记录存在潜在重复记录高度匹配得到匹配记录空匹配记录得到匹配记录得到潜在重复记录图 5-22 登记病人流程更新主索引在交叉索引系统新增或更新一个病人的索引信息后, 同时需要对主索引进行更新向交叉索引提供患者信息注册的系统可能拥有不同的信息可信度, 因此其提供的信息对主索引的影响有所不同更新操作根据新的信息对主索引每个字段记录的信息进行评价, 确定该字段的最佳值记录潜在重复匹配引擎检测到申请登记的病人和现存索引存在潜在重复时, 需要对潜在重复的情况进行记录, 并返回给业务系统或系统管理员进行处理发布主索引业务系统可以向交叉索引系统订阅主索引, 便于在以后的应用中加快应用, 提高信息准确性, 交叉索引系统在对一个病人的主索引更新或增加新索引后, 需要向订阅主索引的业务系统发布更新记录操作日志交叉索引系统业务记录发生的变化都需要记录操作日志, 并能实现回退 534

需要记录的业务操作 : 新增局部索引更新局部索引合并索引新增主索引更新主索引取消索引合并索引自动匹配取消自动匹配获取患者交叉索引交叉索引系统的主要功能是为业务系统提供业务系统交叉索引表, 业务系统可以通过两种方式获取交叉索引 : 通过全局标识获取通过患者信息获取如果业务系统中记录了病人全局标识, 交叉索引系统可以直接检索到该病人的交叉索引表当业务系统仅提供病人本地信息向交叉索引系统检索交叉索引时, 交叉索引系统首先要进行患者信息匹配, 即使用用例 2 所描述的过程在交叉索引库中查找可以匹配的病人如果能够精确匹配, 则返回该病人的交叉索引 ; 如果仅能匹配到潜在重复, 则返回潜在重复信息, 由业务系统进一步选择 ; 如果匹配失败, 则返回空记录获取患者主索引信息交叉索引系统存储了病人在多个系统中的标识信息, 并由此维护一个主索引, 记录最准确的病人基本信息, 该信息可以提供给业务系统使用, 提高业务系统中病人信息的质量获取患者主索引信息的使用方法要求与获取患者交叉索引类似, 可以由业务系统提供全局标识获取, 也可以由业务系统提供病人本地信息获取 535