XX市卫生局智慧医疗信息系统(一期)需求规格说明书V1.1_436套软件开发需求文档_VD516-软件开发需求文档_10各类系统软件开发需求_更新内容

武汉市卫生局智慧医疗信息系统 市级卫生信息平台一期建设项目 需求规格说明书 1万达信息股份有限公司 目 录 1. 引言.........................................................................................................................6 1.1 目的..................................................................................................................6 1.2 项目背景..........................................................................................................6 1.3 项目建设内容..................................................................................................7 1.4 项目相关机构..................................................................................................8 1.5 术语和缩略语..................................................................................................9 1.6 条件与限制....................................................................................................10 1.7 参考资料........................................................................................................10 2. 项目总体业务现状及需求...................................................................................11 2.1 业务现状及问题............................................................................................11 2.1.1 武汉卫生现状全局..............................................................................11 2.1.2 信息化建设基础条件..........................................................................12 2.1.3 医院整体信息化..................................................................................12 2.1.4 社区卫生服务中心信息化..................................................................13 2.1.5 标准体系使用情况..............................................................................13 2.1.6 武汉市卫生信息化存在的问题..........................................................13 22.2 试点医院调研现状汇总................................................................................14 2.2.1 医院系统使用情况..............................................................................14 2.2.2 医院信息化现状分析..........................................................................20 2.3 试点区卫生局调研现状汇总........................................................................23 2.4 项目整体需求分析........................................................................................30 2.4.1 用户需求..............................................................................................30 2.4.2 业务需求..............................................................................................32 2.4.3 应用需求..............................................................................................35 2.4.4 标准规范使用需求..............................................................................37 2.4.5 技术需求..............................................................................................38 3. 项目需求1-专网设计...........................................................................................43 3.1 武汉市卫生专网建设蓝图............................................................................43 3.2 武汉市卫生专网本期建设内容....................................................................45 3.3 建设原则与要求............................................................................................46 3.4 项目带宽需求................................................................................................47 3.5 IP地址分配要求.............................................................................................47 4. 项目需求2-市数据中心扩建...............................................................................50 4.1 网络系统........................................................................................................50 4.1.1 网络总体设计......................................................................................50 4.1.2 网络拓扑..............................................................................................53 4.1.3 数据中心网络设计..............................................................................53 4.1.4 分支机构网络设计..............................................................................54 4.2 主机系统........................................................................................................57 4.2.1 系统架构图..........................................................................................57 4.2.2 主机系统设计......................................................................................57 4.3 存储系统设计................................................................................................58 4.3.1 存储设计分析......................................................................................58 4.3.2 存储管理..............................................................................................59 4.4 备份系统设计................................................................................................60 4.4.1 本地备份系统设计..............................................................................61 4.4.2 远程灾难备份设计..............................................................................62 4.4.3 平台备份方案......................................................................................63 4.5 数据中心采购清单........................................................................................63 5. 项目需求3-软件功能设计...................................................................................67 5.1 市级卫生信息平台建设................................................................................67 35.1.1 注册服务系统......................................................................................67 5.1.2 存储服务系统......................................................................................72 5.1.3 共享协同服务系统..............................................................................78 5.1.4 全程诊疗档案服务系统......................................................................85 5.1.5 信息接口服务系统..............................................................................89 5.1.6 数据交换整合系统..............................................................................95 5.1.7 卫生信息基础资源库........................................................................102 5.1.8 健康浏览器........................................................................................104 5.1.9 隐私保护............................................................................................107 5.1.10 应用安全审计..................................................................................108 5.1.11 系统管理..........................................................................................109 5.1.12 单点登陆..........................................................................................111 5.2 基于平台的应用系统建设..........................................................................115 5.2.1 居民健康卡系统................................................................................115 5.2.2 市民电子病历共享系统....................................................................120 5.2.3 市民检验检查结果共享系统............................................................123 5.2.4 市民双向转诊系统............................................................................128 5.2.5 市民健康自助管理系统....................................................................149 5.2.6 医疗业务分析系统............................................................................156 5.2.7 合理用药预警及管理系统................................................................161 5.2.8 数据质量监管系统............................................................................170 5.2.9 公众健康服务门户............................................................................170 5.3 医院前置软件系统......................................................................................199 5.3.1 功能流程............................................................................................200 5.3.2 设计思路............................................................................................201 6. 项目需求4-标准规范设计.................................................................................203 7. 项目需求5-非功能性需求.................................................................................205 7.1 用户界面规范..............................................................................................205 7.2 运行环境......................................................................................................205 7.3 性能需求......................................................................................................206 7.4 性能需求......................................................................................................206 7.4.1 数据精确度........................................................................................206 7.4.2 运行效率............................................................................................206 7.4.3 响应速度............................................................................................207 7.4.4 异常处理............................................................................................207 47.5 安全性需求..................................................................................................207 7.6 标准化需求..................................................................................................208 7.6.1 异构系统的需求................................................................................208 7.6.2 数据标准管理的需求........................................................................208 7.6.3 权限分析............................................................................................209 7.7 运维需求......................................................................................................209 7.7.1 保障系统稳定高效运行....................................................................209 7.7.2 保障数据的安全和保密....................................................................210 7.7.3 保障系统安全运行............................................................................211 8. 项目需求6-接口需求.........................................................................................212 8.1 试点机构数据接口......................................................................................212 8.1.1 医院端提交数据的方式....................................................................212 8.1.2 前置端数据反馈与处理....................................................................213 8.1.3 中心端数据反馈和处理....................................................................214 8.1.4 数据交换形式说明............................................................................215 8.1.5 接口数据集概述................................................................................216 8.2 与现有系统的接口......................................................................................220 8.2.1 对接市突发公卫应急指挥系统........................................................220 8.2.2 对接市局OA系统.............................................................................220 8.2.3 对接省级预约系统............................................................................221 8.2.4 对接家庭健康档案............................................................................221 8.2.5 对接新农合系统................................................................................222 9. 附件.....................................................................................................................223 51.引言 1.1 目的 本文主要针对武汉市区域卫生信息平台建设内容，详细的提出了系统的功能 性、非功能性需求，说明了系统的各种功能。为后续的设计工作划定范围、重点方 向。本文针对的读者为系统管理者、系统使用者、信息数据提供者、应用接入单位 系统设计开发人员和相关评审人员。 1.2 项目背景 2009年3月17日，国务院出台《中共中央国务院关于深化医药卫生体制改革 的意见》。“建立四大体系、八项支撑，实施五项重点改革任务”的医药卫生体制 改革正在全国全面推进。信息化作为医改的重要技术支撑和保障，卫生部根据新 “医改方案”的总体目标和任务，提出了“以人为本，打好三个基础、建立三级 平台、提升业务应用”的医疗卫生信息化建设总体思路。2010年，卫生部在全国 卫生信息化工作会议上制定了我国医疗卫生信息化“十二五”规划（草案），进 一步确定了卫生信息化“3521-2”的总体框架，医疗卫生信息化建设正在按照国 家的总体要求在全国各地全面推进。因此，基于健康档案的区域卫生信息平台建 设成为卫生领域内信息化建设的重要任务。 武汉市医药卫生体制改革现正处在重要的关键时期和攻坚阶段。随着经济社 会的发展、全面小康目标的实现，人民群众对医疗卫生服务的需求也正在变得越 来越高。同时，工业化、城镇化、人口老龄化、疾病谱的改变以及生态环境的变化， 给居民健康的影响都带来了新的严峻挑战。目前，在卫生服务体系中还存在着医 疗服务费用增长过快、医疗服务可及性差、医疗资源配置不均衡、卫生服务效率 不高、医疗服务质量参差不齐等问题，如果不进行改革，将难以应对这些挑战。深 6化医药卫生体制改革事关百姓切身利益和社会和谐发展。众所周知，构建富有效 率的卫生体制是一个世界性难题，纵观各国卫生体制改革之路可以看出，尽管改 革思路和方法有所不同，但在利用信息化手段推动卫生体制改革，以此更好地解 决医疗卫生服务需求与供给平衡方面，都有着共同的期望。 武汉市委、市政府长期高度重视卫生信息化建设。2010年8月22日，阮成发 书记批示要大力推进武汉市的智能化医疗信息网。2011年武汉市十二届人大七 次会议上，市人民政府工作报告中提出将“推进智慧医疗便民工程”为今年的十 件实事之一。2011年8月12日，唐良智市长在调研全市卫生工作后指出：要尽快 完成市卫生数据中心和医疗服务、公共卫生、卫生管理三大平台建设；将智慧医 疗纳入智慧城市信息系统建设，统筹进行整体规划；把智慧医疗信息系统纳入中 部医疗服务中心建没，并加快推进。 按照武汉市领导指示要求，市卫生局一直将卫生信息化建设作为今年工作的 一项重要任务来抓。在武汉市局草拟的武汉市“十二五”卫生信息化发展规划中 明确的提出了“以电子病历和居民健康档案为核心的区域卫生信息平台为中心， 以医疗卫生服务信息“一卡通”为重点，大力推进武汉市卫生信息化建设”的总 体目标，和“一库、三台、九系统”的总体建设任务（简称“139工程”）以及未 来5年的阶段实施步骤。 1.3 项目建设内容 为贯彻落实武汉市委市政府工作要求，围绕武汉市“十二五”卫生信息化发 展规划，2011年武汉市智慧医疗信息系统（市级卫生信息平台一期建设项目）的 主要建设目标是：启动市级卫生数据中心建设项目，以医疗服务电子信息平台为 突破口进行重点建设，初步搭建武汉市智慧医疗卫生信息系统的框架；支撑试点 医疗机构间医疗卫生服务信息的互联互通和信息共享以及业务协同，实现网上监 督，探索建立患者在试点医疗机构就医实现医疗服务“一卡通”；为整体推进全 市智慧医疗卫生信息系统建设，缓解看病难、看病贵开好头、起好步。 本期具体目标是完成以下几个方面的建设： 7序号 建设项目 具体目标 启动武汉市卫生专网建设，先期选择16家医院和24家 1 卫生专网 社区卫生服务中心做试点，实现互联互通。 启动建设武汉市市级卫生数据中心，为今年及今后武 2 数据中心 汉市智慧医疗卫生信息化的正常运营提供保障。 重点推进医疗服务电子信息平台的建设，完成试点范 围内居民健康卡应用、电子病历共享、检验检查结果共 3 平台及应用 享、公众健康服务、合理用药预警及管理、卫生综合管 理框架等信息化建设。 1.4 项目相关机构 接入机构说明：按照《招标书》我们的接入机构是16家医院，24个社区，14个合理用 药的医院。通过《补充协议》，我们要接入的单位是16家医院，14个合理用药医院，8 个区卫生局平台，由区平台再与社区进行对接。 序号 区卫生局 1 江汉区卫生局 2 汉阳区卫生局 3 东西湖经济开发区卫生局 4 硚口区卫生局 5 洪山区卫生局 6 黄陂区卫生局 7 江夏区卫生局 8 汉南区卫生局 序号 医院 应用接口部分 合理用药接口 1 武汉市汉口医院 ★ ★ 2 武汉市妇女儿童医疗保健中心 ★ ★ 3 武汉市中心医院 ★ ★ 4 武汉市中医院 ★ ★ 85 武汉市第四医院 ★ ★ 6 武汉市中西医结合医院 ★ ★ 7 武汉市第三医院 ★ ★ 8 武汉市武昌医院 ★ ★ 9 武汉市武东医院 ★ ★ 10 武汉市第十一医院 ★ 11 武汉市第五医院 ★ 12 武汉市第六医院 ★ 13 武汉市第八医院 ★ 14 黄陂区人民医院 ★ 15 武汉协和医院 ★ 16 广州军区武汉总医院 ★ 17 武汉市东湖医院 ★ 18 武汉市精神卫生中心 ★ 19 武汉市医疗救治中心 ★ 20 武汉市普仁医院 ★ 21 武汉市结核病防治所 ★ ★表示是接入机构 1.5 术语和缩略语 HIS：医院管理信息系统； CIS：医生工作站、护士工作站等医院内部的临床信息管理系统； LIS：实验室信息系统； RIS：检查报告信息系统； CHSS：社区卫生管理信息系统； RHIN：区域卫生信息网络。 91.6 条件与限制 本项目是否能够成功实施，主要取决于以下的条件： ①各试点单位要积极配合系统改造，能否按时提交数据； ②各试点单位提交的数据的质量，能否满足平台的应用要求； ③市卫生局数据中心的网络、硬件及相关软件及时到位； ④各试点单位的网络、前置机及时到位。 1.7 参考资料  卫生部《健康档案基本架构与数据标准（试行）》  卫生部《电子病历基本架构与数据标准（试行）》  卫生部《基于健康档案的区域卫生信息平台建设指南（试行）》  卫生部《基于健康档案的区域卫生信息平台建设技术解决方案（试行）》  卫生部《综合卫生管理信息平台建设指南（征求意见稿）》  卫生部《医院信息系统软件基本功能规范》  卫生部《社区卫生服务系统功能规范》  卫生部《妇幼卫生系统功能规范》  卫生部《国家基本公共卫生服务规范》  卫生部《社区卫生信息技术标准》  武汉市卫生信息化工程标准规范体系  武汉市卫生数据中心数据规范、接口规范  武汉市卫生数据中心管理和运行规范  武汉市区（市）平台建设规范 102.项目总体业务现状及需求 2.1 业务现状及问题 2.1.1 武汉卫生现状全局 武汉全市现辖13 个区、3 个国家级开发区（武汉经济技术开发区、东湖新技 术开发区、东湖风景区），总面积 8494 平方公里，常住人口 858 万人。 全市现有综合医院190家，其中500张床位以上的医院23家，100-499张床 位的医院32家，100张床位以下的医院135家。全市现有专科医院(西医类)43家 全市现有中医和中西医结合医院49家，其中公立中医医院17家。 全市共有540个社区卫生服务机构，其中，社区卫生服务中心124个，社区卫 生服务站416个。有乡镇卫生院86家，村卫生室1845个。 全市现有门诊部393家，其中中医门诊部144家，诊所2129家，其中中医诊 所592家，妇幼保健机构17家；产科及助产技术服务机构128家；临床检验中心 5家，血液中心1家，急救中心和站12家，体检机构13家。 全市现共有床位51413张，平均每千人口拥有床位6.15张。现有卫生技术人 员62343人，其中医生25223人，护士25382人。平均每千人口拥有医生数3.02 人。 全市居民死亡原因前6中，主要疾病顺位及所占比重为: 脑血管疾病31.23%， 恶性肿瘤26.51%，心脏病17.37%，损伤和中毒7.85%，呼吸系统疾病7.22%，消化 系统疾病3.08%。 2010年全市医疗机构诊疗人次合计5100.2万人次,其中门诊4467.3万人次， 急诊 632.9 万人次，住院 155.1 万人次,病床使用率 91.17%, 出院者平均住院日 11.1日。 112.1.2 信息化建设基础条件 武汉市启动市卫生局信息中心一期建设，已具备了一定的有利条件。主要包 括以下三个方面： （一）市卫生局机关大楼信息中心机房建设已基本完成。2011年，卫生局机关 大楼信息中心80平方的标准机房已经建成，其内放置了16个标准机柜（目前在 用8个），各种信息化设备50多台套，基础光纤，网络也全部建设完成。机房现有 硬件、网络等环境已基本具备武汉市智慧医疗信息系统一期硬件建设基础，只需 在此基础上进行相关硬件扩容建设，可有效节约成本，减少重复投资。 （二）试点医院电子病历及社区卫生服务中心信息化建设进展顺利。2011年5 月，经过前期调研，卫生局选择了协和、武汉市中心医院等16家试点医院推进标 准化电子病历建设工作，目前各试点医院电子病历建设工作开展顺利。社区卫生 服务中心信息化建设也已全面展开，按照整区推进的原则，首批确定江汉及汉阳 区共24家试点单位，积极推进基于电子健康档案的社区卫生服务信息系统建设。 试点医院及社区卫生服务中心的信息化建设为武汉市电子病历共享，医疗“一卡 通”创造了一定基础。 （三）120院前急救、疾控、妇幼、社区、新农合、卫生应急等信息系统基本建成。 “十一五”期间，武汉市投入大量资金建设了120急救指挥、疫情直报、妇幼保 健、社区综合管理、新农合、卫生应急等各类公共卫生信息系统，在卫生工作中起 到了很好的作用。但是，目前各系统都是独立建设，彼此之间信息不能互通共享， 亟待整合资源。 2.1.3 医院整体信息化 目前武汉市医疗机构的信息化正处于以财务结算为中心的医院管理信息系 统（HMIS）到以患者为中心、医疗为主线的临床信息系统（HCIS）的过渡阶段。所有 医院建有挂号、收费、药品、物资管理等必备的HMIS功能模块，近50%的医院已 12建或在建门急诊医生工作站、住院医生工作站、护士工作站、医技管理系统（如 LIS、RIS、PACS等）以及相应的经济管理、综合管理功能模块，实现以患者为中心、 医疗为主线的相关功能。个别信息化程度较高的医院则在积极探索如何通过信息 化手段加强对医疗行为的监管、方便群众就医，如医疗管理与质量监控系统、临 床路径管理、预约挂号等。系统架构大多采用C/S应用体系架构，系统的部署、升 级与维护相对复杂。其中，市中心医院对此进行了大范围的革新，除挂号、收费等 系统为了保持系统稳定采用C/S外，其余系统均采用B/S架构，以便于系统的统 一管理及维护。同时，武汉市中心医院还在积极探索以电子病历为核心的医院信 息整合平台的建设。 2.1.4 社区卫生服务中心信息化 武汉市在2008年开发了面向全市的社区卫生服务中心信息管理系统，采用 了统一的B/S架构，目前武汉全市124家社区已基本连接使用。但是，目前该系统 功能只覆盖部分慢病等公卫条线的应用，特别是医疗业务仍未实现信息化管理。 2.1.5 标准体系使用情况 目前武汉市各医院由于医保（含新农合）的结算需求，故普遍采用了以身份证 号为主的统一信息编码体系。ICD9/ICD10 的应用较普及，并且由于医保结算规则 的经济驱动，药品、检验检查项目等涉及结算项目也大都采用医保代码。此外，也 有若干医院在尝试HL7的应用。 2.1.6 武汉市卫生信息化存在的问题 尽管武汉市卫生信息化取得了一定的成绩，但由于卫生服务本身固有的特殊 性和复杂性，导致其总体上还不能满足当前卫生事业发展和深化医疗改革工作的 需要，目前仍存在以下问题、差距和挑战： 基础设施仍需较大建设力度。借助卫生专网实现市各级医疗卫生单位网络互 13联的目标尚未完全实现，目前仍需依靠Internet、医保网、政务外网等多种链路交 错实现，难以满足武汉市卫生信息化发展的各种应用需求。 软件应用仍然是纵强横弱，“信息孤岛”现象严重。医院内部业务或部门的 信息系统建设完善，但缺少全院的信息平台建设，信息共享困难；各公共卫生机 构相关的业务系统建设较为全面，但没有统一的公共卫生信息平台，数据大量冗 余；各业务领域系统相对独立建设，缺乏区域化建设相关的关联设计，互联互通 性困难，增加了武汉市区域卫生信息建设整合的复杂性。 医疗卫生领域的新技术应用不足。当前武汉市医院和公卫机构信息化建设中 采用的信息技术以高速以太网、条码技术、数据库安全技术、数据仓库及中间件 服务器技术为主，云计算、物联网和无线移动等新技术应用明显不足。医疗卫生 领域急需要引入相关信息化新型技术，探索和推进这些前沿技术在武汉市医疗卫 生行业的重点应用，逐步构筑基于“智慧医疗”的行业服务和管理体系。 卫生信息化机构不全且专业人才匮乏。卫生信息化组织管理不够完善，人才 队伍薄弱，资源配置不够充分，具有信息化管理理念、既熟悉卫生业务又具有信 息化系统建设经验的高层次人才较为缺乏，专业人才队伍尚未建成，制约着信息 化建设与发展。 2.2 试点医院调研现状汇总 2.2.1 医院系统使用情况 软件系统 武汉市中心医 武汉市妇女儿 广州军区武汉 武汉市第一医 院 童医疗保健中 总医院 院 心 HIS 1998 年开始使 1999 年开始使 使 用 军 卫 一 2011 年 10 月 用自主开发的 用 众 邦 的 系 号，系统采用 开始使用东华 系统，系统采 统，系统采用 C/S 架 构 ， 合创的系统， 用 C/S 架构， C/S 架 构 ， oracle数据库，系统采用 B/S Informix 数 据 oracle数据库，现有数据量为 架构，cache数 14库，当前数据 现有数据量为 270G，每年数 据库，现有数 量约为20G，每 45G，每年数据 据增长量约为 据量100G 年数据增长量 增 长 量 约 为 20G 无统计 35G，最近两年 数据增长较多 CIS 自主开发，门 2011 年 11 月 使用了多家厂 东 华 合 创 系 诊医生站没有 份开始使用东 商的，门诊医 统，门诊医生 全部科室使用 华 合 创 的 软 生站和住院医 站2011年开始 （部分科室没 件，门诊医生 生站使用的是 使用，住院医 有配置电脑），站现在还未使 军卫一号 生站 2012 年 3 住院医生站全 用，收费处会 月份开始使用 部使用 录 入 处 方 信 息，但是药品 用法频次类信 息可能缺失 LIS 使用蓝博的， 2006 年开始使 使 用 科 华 系 2011 年 11 月 但是医院对现 用南方惠桥的 统，检验设备 份开始使用东 有 系 统 不 满 检验系统，检 齐全，整个系 华 合 创 的 系 意，准备更换 验设备齐全， 统走电子化流 统，整个系统 整个系统走电 程 走电子化流程 子化流程 RIS 2007 年开始使 2009 年起使用 使 用 东 软 系 已经招标东软 用东软开发的 锐科的系统， 统，整个系统 的产品，目前 系统，在住院 2011 年将超声 走电子化流程 还未使用 医生站和门诊 设备也接入系 医生站可直接 统，整个系统 调阅报告，整 走电子化流程 个系统走电子 化流程 PACS 2007 年开始使 2009 年起使用 使 用 东 软 系 已经招标东软 用东软开发的 锐科的系统， 统，整个系统 的产品，目前 系统，在住院 2011 年将超声 走电子化流程 还未使用 医生站和门诊 设备也接入系 医生站可直接 统，整个系统 调阅报告，整 走电子化流程 个系统走电子 化流程 电子病历系统 2007 年使用海 2011 年 11 月 使用浙江和仁 2012 年 1 月份 15泰的电子病例 份开始使用东 系统，所有住 开始使用东华 系统，门诊使 华合创的软件 院科室使用 合创系统，所 用 了 部 分 科 有住院科室都 室，住院科室 使用 全部使用 合理用药系统 使用大通的合 使用大通的合 使用美康的合 使用大通的合 理用药系统， 理用药系统， 理用药系统， 理用药系统， 同时嵌入在门 嵌入在医生工 嵌入在医生工 嵌入在医生工 诊医生站和住 作站中，医生 作站中，医生 作站中，医生 院医生站中， 在保存处方时 在保存处方时 在保存处方时 医生在保存处 给出配伍禁忌 给出配伍禁忌 给出配伍禁忌 方时给出配伍 提示，医生可 提示，医生可 提示，医生可 禁忌提示，医 查看药品说明 查看药品说明 查看药品说明 生可查看药品 书等信息 书等信息 书等信息 说明书等信息 预约挂号系统 114 平台与 HIS 114 平台与 HIS 114 平台与 HIS 114 平台与 HIS 做接口，2011 做接口，2011 做接口 做接口，2011 年左右开始使 年左右开始使 年左右开始使 用 用 用 双向转诊系统 有双向转诊的 医院现无双向 可实现体系内 有双向转诊的 业务，但是没 转诊系统 部的转诊 业务，但是没 有通过系统实 有通过系统实 现 现 软件系统 武汉市普爱医 武汉市武昌医 武汉协和医院 武汉市中医院 院 院 HIS 2008年开始使 2008年开始使 2002年开始使 2000年开始使 用东软系统， 用中联的系统，用杭州创业的 用，厂家已经 系统采用C/S 系统采用C/S架 系统，采用C/S 倒闭，准备换 架构，oracle数 构，oracle数据 架构，sybase数 新的系统 据库，现有数 库，现有数据量 据库，现有数 据量200G，每 100G，每年数 据量130G，每 年增长约为 据增长量约为 年数据增长约 30G 20G 为60G CIS 2008年开始使 2008年开始使 2002年开始使 2010年开始使 用东软系统， 用中联的系统，用创业系统， 用门诊医生 16门诊医生站和 门诊医生站住 门诊医生站住 站，使用了部 住院医生站使 院医生站全部 院医生站全部 分科室。2011 用情况良好 科室使用 科室使用 年开始试用住 院医生工作 站，医院认为 效果不理想， 要重新招标 LIS 2008年开始使 2008年开始使 上海新合的系 使用锐科的， 用东软系统， 用中联系统，整 统，整个系统 可能需要重新 整个系统走电 个系统走电子 走电子化流程 招标 子化流程 化流程 RIS 2008年开始使 2008年开始使 2008年起使用 无RIS系统 用东软系统， 用中联系统，整 锐科的系统， 整个系统走电 个系统走电子 整个系统走电 子化流程 话流程 子化流程 PACS 2008年开始使 2008年开始使 2008年起使用 无PACS系统 用东软系统， 用中联系统，整 锐科的系统， 整个系统走电 个系统走电子 整个系统走电 子化流程 话流程 子化流程 电子病历系统 2009年开始使 2011年开始使 2011年开始使 试用了一个厂 用东软的系 用中联的电子 用东华合创的 家的，要重新 统，所有住院 病例系统，住院 电子病例系 招标 科室都已经使 全部科室使用 统，部分住院 用电子病例系 科室使用 统 合理用药系统 使用大通的合 使用美康的合 使用美康的合 无专门的合理 理用药系统， 理用药系统，嵌 理用药系统， 用药系统 嵌入在医生工 入在医生工作 嵌入在医生工 作站中，医生 站中，医生在保 作站中，医生 在保存处方时 存处方时给出 在保存处方时 给出配伍禁忌 配伍禁忌提示，给出配伍禁忌 提示，医生可 医生可查看药 提示，医生可 查看药品说明 品说明书等信 查看药品说明 书等信息 息 书等信息 预约挂号系统 114平台与HIS 现在有系统，但 武汉中科， 无预约挂号系 做接口 是未开展业务 2011年开始使 统 17用 双向转诊系统 无双向转诊系 无双向转诊系 2011年开始使 无双向转诊系 统 统 用杭州邦泰的 统 双向转诊系 统，与部分医 院有转诊业务 软件系统 武汉市汉口医 黄陂区人民医 武汉市第八医 武汉市第三医 院 院 院 院 HIS 杭 州 创 业 系 使用金仕达卫 飞博系统，采 东华系统，采 统，采用C/S架 宁系统，采用 用 C/S 架构， 用 B/S 架构， 构，oracle数据 C/S 架 构 ， MSSQL数据库 Cache数据库 库 sqlserver 数 据 库，每年数据 增 加 量 约 为 8G，数据库现 有 数 据 量 为 40G CIS / 金仕达卫宁系 / / 统，采用C/S架 构，sqlserver数 据库 LIS 杭 州 创 业 系 金仕达卫宁系 / 东华系统，采 统，采用C/S架 统，采用C/S架 用 C/S 架构， 构，oracle数据 构，sqlserver数 Cache数据库 库 据库 RIS / 金仕达卫宁系 / / 统，采用C/S架 构，sqlserver数 据库 PACS / / / 东华系统，采 用 C/S 架构， Cache数据库 电子病历系统 杭 州 创 业 系 金仕达卫宁系 / 东华系统，采 统，采用C/S架 统，采用C/S架 用 B/S 架构， 构，oracle数据 构，sqlserver数 Cache数据库 库 据库 合理用药系统 / 使用美康的合 / 使用大通的合 18理用药系统 理用药系统 预约挂号系统 / / / / 双向转诊系统 / / / / 软件系统 武汉市第十一 武汉市第五医 武汉市武东医 武汉市第六医 医院 院 院 院 HIS 天 健 系 统 ， 金 维 思 特 ， 成都信通，C/ 东软，Oracle数 oracle数据库 sqlserver 数 据 S/S+ 据库 库 B/S/S 架 构 ， sqlserver 数 据 库 CIS / 金 维 思 特 ， 成都信通，C/ 东软，Oracle数 sqlserver 数 据 S/S+ 据库 库 B/S/S 架 构 ， sqlserver 数 据 库 LIS 天 健 系 统 ， 金 维 思 特 ， 成都信通，C/ 上 海 联 轩 ， sqlserver 数据 sqlserver 数 据 S/S+ Oracle数据库 库 库 B/S/S 架 构 ， sqlserver 数 据 库 RIS / 金 维 思 特 ， 成都信通，C/ 东软，Oracle数 oracle数据库 S/S+ 据库 B/S/S 架 构 ， sqlserver 数 据 库 PACS / 金 维 思 特 ， 成都信通，C/ 东软，Oracle数 oracle数据库 S/S+ 据库 B/S/S 架 构 ， sqlserver 数 据 库 电子病历系统 天 健 系 统 ， 金 维 思 特 ， 成都信通，C/ 东软，Oracle数 oracle数据库 sqlserver 数 据 S/S+ 据库 库 B/S/S 架 构 ， sqlserver 数 据 库 合理用药系统 / 金 维 思 特 ， 四川美康 上 海 大 通 ， 19sqlserver 数 据 Sqlserver 数 据 库 库 预约挂号系统 / 金 维 思 特 ， 成都信通，C/ 武汉中科信， mysql数据库 S/S+ sqlserver 数 据 B/S/S 架 构 ， 库 sqlserver 数 据 库 双向转诊系统 / 金维思特， / 无双向转诊系 sqlserver数据 统 库 2.2.2 医院信息化现状分析 从调研结果来看，本次调研的16家医院中，大部分医院信息化建设水平 较高，医院信息系统齐全，实现了HIS、CIS（包括住院医生站、门诊医生站）、LIS、 RIS、PACS等系统实现互联互通。各医院信息化程度相差较大。以下为各个医院信 息化的具体情况。 1.武汉市中心医院：调研所列系统中，除双向转诊系统外，其他系统都已使用。 其中门诊医生工作站因为有部分科室未配置电脑，医生未使用门诊医生站，处方 等信息由医生手工开出，由收费处将处方录入系统。LIS系统目前医院使用不满意 希望更换新系统。 2.武汉市妇女儿童医疗保健中心：现医院无双向转诊系统，门诊医生工作站暂 未使用，处方信息采集将不完整。其他系统之间都实现互联互通，运行良好。 3.广州军区武汉总医院：信息系统完善，医院信息化水平较高，各系统运行情 况良好，HIS与CIS、LIS、RIS、PACS等系统间实现互联互通，医院也可通过转诊系统 实现体制内的转诊。 4.武汉市第一医院：医院的PACS系统已经招标，但目前尚未使用。门诊医生站、 住院医生站以及电子病历使用时间从2011年底到现在逐步推进，现全部科室都 已使用。HIS与CIS、LIS之间的信息能够互通。双向转诊系统目前暂未使用。 205.武汉市普爱医院：医院有东西院两个点，使用独立的数据库。目前两个点的 信息话状况良好，各个系统使用较全。HIS、CIS、LIS、RIS、PACS等系统间实现互联 互通。目前暂未使用双向转诊系统。 6.武汉市武昌医院：医院信息化程度较高，HIS、CIS、LIS、RIS、PACS等系统间实 现互联互通。有预约挂号系统，但因业务量并不是很大，所以预约挂号的业务并 未开展。双向转诊系统暂无。 7.武汉协和医院：医院信息系统完善，HIS、CIS、LIS、RIS、PACS等系统间实现互 联互通。其中住院电子病例系统于2011年开始推进，目前部分科室还未使用。 8.武汉市中医院：HIS系统由于不能满足医院现在需求，医院希望重新招标，门 诊医生站使用了部分科室，住院医生站与电子病例系统需要重新招标，检验系统 基本实现电子化，RIS、PACS、合理用药系统、预约挂号系统、双向转诊系统现在都 还未使用。 9.武汉市汉口医院：医院目前已经使用了HIS和CIS系统，电子病历系统目 前使用了部分科室。LIS系统已经使用，但是未跟HIS联通，报告信息不能关联到 病人。医院现暂未使用RIS、PACS以及合理用药、预约挂号、双向转诊等系统。 补充说明：在系统总体情况表格中，医院填写了无CIS系统，但是从详细回答 推断，医院应该目前已经在使用医生工作站，医院应该将CIS归入到了HIS中。 10.黄陂区人民医院：医院目前已经使用了HIS、CIS、LIS、RIS以及电子病历系 统，这几个系统为同一厂家，系统间已经实现了互联互通。LIS和RIS有部分设备 未接入系统。合理用药使用美康公司，嵌入医生工作站。PACS、预约挂号、双向转 诊系统暂未使用。 11.武汉市第八医院：医院暂只有HIS系统，但门诊系统不存储患者基本信息， 挂号信息、处方信息未电子化，门诊只存储电子化的收费信息，收费与挂号未能 关联。住院的病人基本信息、医嘱以及收费信息能够关联。未使用电子病历系统， 使用蓝星公司的病案关联系统，存储病案报告等信息。其他信息系统暂未使用。 12.武汉市第三医院：医院信息系统较为齐全，系统间能够实现互联。电子 病历使用了部分科室，双向转诊、预约挂号系统暂未使用。 21补充说明：医院在总体情况表中未写有CIS，但从详细回答推断，现已在使用 医生工作站；医院回答已有PACS系统但无RIS系统，可能是RIS和PACS已经整合， 认为RIS系统是PACS的一部分。 13.武汉市第十一医院：医院目前使用了HIS、LIS以及电子病历系统，HIS与LIS 系统之间实现联通。CIS系统使用不完善，未有手术登记信息，住院的医嘱和收费 信息不能跟一次住院相关联。RIS、PACS、合理用药、预约挂号、双向转诊系统暂未 使用。 14.武汉市第五医院：医院信息系统齐全，所有系统皆为一个厂家，系统间能够 实现互联互通。 15.武汉市武东医院：医院信息系统较为齐全，且各系统之间实现互联互通，其 中电子病历系统使用了部分科室。除双向转诊系统外，其他系统均已使用。 16.武汉市第六医院：医院信息系统较为齐全，且各系统之间实现互联互通 除双向转诊系统外，其他系统均已使用。 2.3 试点区卫生局调研现状汇总 本次调研覆盖了全市14个区卫生局的基层医疗卫生机构。主要调研内容是 各区信息化项目建设情况。调查结论如下： 蔡甸区：人口总数为44.6万人，其中农村人口数为31.8万人。 共有乡镇卫生院11家，已部署HIS、健康档案管理系统和新农合系统；读卡器设 备共21台；可用的应用终端共189台；共有社区卫生服务中心1家，已部署HIS 和健康档案管理系统；读卡器设备共1台； 共有村卫生室254家，已部署健康档案管理系统和新农合系统；读卡器设备 共1台；共有社区卫生服务站5家；可用的应用终端共5台； 共有新农合一卡通9.6万张；资金投入方面，地方政府投入资金90万元，自筹 资金50万元，利用中央、省级项目资金250万元；规划方面，已制定长期规划；已 安排年度信息化工作；已有区域卫生信息数据中心建设方案；已制定基层医疗卫 生机构信息化建设项目工作方案；机构人员方面，已成立卫生信息化建设领导小 22组；已成立基层医疗卫生机构信息化建设项目工作专班；基础环境及硬件建设方 面，已经完成机房建设；人员培训方面，共需培训387人，其中乡镇卫生院13人， 村卫生室254人，社区卫生服务中心/站1人。 东湖新技术开发区：人口总数为39.6万人，其中农村人口数为17万人。共有 社区卫生服务中心7家，已部署HIS和健康档案管理系统；读卡器设备共7台；共 有村卫生室60家，已部署健康档案管理系统和新农合系统；读卡器设备共60台； 共有社区卫生服务站6家，已部署HIS和健康档案管理系统；读卡器设备共6台； 共有新农合一卡通4.6888万张；资金投入方面，地方政府投入资金70万元，自筹 资金30万元；卫生信息专网链路方面，村卫生室共接入60个，社区卫生服务中心 共接入7个，社区卫生服务站共接入6个；规划方面，已安排年度信息化工作；机 构人员方面，已成立卫生信息化建设领导小组；资金情况方面，计划开展政府采 购金额25万元；计划政府采购内容：待信息化方案制定后视需求采购相关设备。 基础环境及硬件建设方面，已安排基层医疗卫生机构信息化建设项目进度时间。 东西湖区：人口总数为45.2万人，其中农村人口数为26.9万人。 共有乡镇卫生院10家，已部署HIS、LIS、电子病历、健康档案管理系统和新农 合系统；条码枪设备共20台；读卡器设备共32台；共有社区卫生服务中心2家， 已部署HIS和健康档案管理系统；条码枪设备共15台；读卡器设备共10台；共有 村卫生室50家，已部署村卫生室信息系统、健康档案管理系统和新农合系统；读 卡器设备共50台；共有社区卫生服务站10家，已部署HIS；读卡器设备共7台； 共有新农合一卡通6.8025万张；资金投入方面，地方政府投入资金139万元，自 筹资金19.5万元，利用中央、省级项目资金150万元；卫生信息专网链路方面，乡 镇卫生院共接入10个，村卫生室共接入50个，社区卫生服务中心共接入2个，社 区卫生服务站共接入2个；规划方面，已安排年度信息化工作，已有区域卫生信 息数据中心建设方案，已制定基层医疗卫生机构信息化建设项目工作方案；机构 人员方面，已成立卫生信息化建设领导小组，已成立基层医疗卫生机构信息化建 设项目工作专班；资金情况方面，中央补助资金已到位，地方配套资金已到位金 额：139 万元。已采购硬件185.3万元；软件 61.15万元；网络建设开支43.6755 万 23元。基础环境及硬件建设方面，已安排基层医疗卫生机构信息化建设项目进度时 间，已经完成机房建设；人员培训方面，共需培训290人，其中乡镇卫生院180人， 村卫生室80人，社区卫生服务中心/站30人。 汉南区：人口总数为11.497万人，其中农村人口数为8.22万人。 共有乡镇卫生院6家，已部署HIS、健康档案管理系统和新农合系统；读卡器设备 共6台；共有社区卫生服务中心2家，已部署HIS和健康档案管理系统；读卡器设 备共2台；共有村卫生室45家，已部署村新农合系统；读卡器设备共45台；共有 新农合一卡通3.0994万张；资金投入方面，地方政府投入资金20万元，自筹资金 50万元，利用中央、省级项目资金100万元；卫生信息专网链路方面，乡镇卫生院 共接入6个，村卫生室共接入45个，社区卫生服务中心共接入2个；机构人员方 面，已成立卫生信息化建设领导小组，已成立基层医疗卫生机构信息化建设项目 工作专班；资金情况方面，中央补助资金已到位。 汉阳区：人口总数为53.4万人。共有社区卫生服务中心11家，已部署HIS； 共有社区卫生服务站48家；资金投入方面，地方政府投入资金20万元，自筹资金 98万元；规划方面，已制定长期规划，已安排年度信息化工作，已有区域卫生信息 数据中心建设方案，已制定基层医疗卫生机构信息化建设项目工作方案；机构人 员方面，已成立卫生信息化建设领导小组，已成立基层医疗卫生机构信息化建设 项目工作专班；资金情况方面，计划开展政府采购金额 227万元；计划政府采购 内容：用于中心机房装修、中心机房硬件、基层单位硬件、全区网络建设共需约 142万元，软件及服务约85万元；基础环境及硬件建设方面，已经完成机房建设。 洪山区：人口总数为85.7万人，其中农村人口数为1.9万人。 共有乡镇卫生院1家，已部署新农合系统；读卡器设备共1台；共有社区卫生 服务中心18家，已部署HIS和健康档案管理系统； 共有村卫生室38家，已部署村卫生室信息系统；读卡器设备共38台；共有社 区卫生服务站44家，已部署健康档案管理系统；共有新农合一卡通2.2万张；卫 生信息专网链路方面，乡镇卫生院共接入1个，村卫生室共接入38个，社区卫生 服务中心共接入18个，社区卫生服务站共接入44个；资金情况方面，中央补助资 24金已到位；人员培训方面，乡镇卫生院2人，村卫生室76人。 黄陂区：人口总数为92.2万人，其中农村人口数为74.5万人。 共有乡镇卫生院18家，已部署HIS、健康档案管理系统和新农合系统；条码枪设 备共23台；读卡器设备共18台；共有社区卫生服务中心2家，已部署HIS和健康 档案管理系统；条码枪设备共2台；读卡器设备共2台；共有村卫生室580家，已 部署健康档案管理系统和新农合系统；读卡器设备共310台； 共有新农合一卡通 21.5 万张；资金投入方面，自筹资金18万元，利用中央、省级项目资金150万元； 卫生信息专网链路方面，乡镇卫生院共接入18个，村卫生室共接入310个，社区 卫生服务中心共接入2个；规划方面，已制定长期规划，已安排年度信息化工作， 已有区域卫生信息数据中心建设方案，已制定基层医疗卫生机构信息化建设项目 工作方案；机构人员方面，已成立卫生信息化建设领导小组，已成立基层医疗卫 生机构信息化建设项目工作专班；基础环境及硬件建设方面，已经完成机房建设 江岸区：人口总数为89.56万人。共有社区卫生服务中心19家，已部署HIS和 健康档案管理系统；条码枪设备共14台；读卡器设备共17台；可用的应用终端共 2台；共有社区卫生服务站53家，已部署健康档案管理系统；资金投入方面，地方 政府投入资金30万元；卫生信息专网链路方面，社区卫生服务中心共接入19个， 社区卫生服务站共接入13个；规划方面，已安排年度信息化工作；机构人员方面 已成立卫生信息化建设领导小组，已成立基层医疗卫生机构信息化建设项目工作 专班；基础环境及硬件建设方面，已安排基层医疗卫生机构信息化建设项目进度 时间。 江汉区：人口总数为69.8万人。共有社区卫生服务中心13家，已部署HIS和 健康档案管理系统；条码枪设备共30台；读卡器设备共13台；共有社区卫生服务 站23家，已部署HIS和健康档案管理系统；条码枪设备共30台；读卡器设备共13 台；资金投入方面，地方政府投入资金202万元，自筹资金202万元；卫生信息专 网链路方面，社区卫生服务中心共接入13个，社区卫生服务站共接入23个；规划 方面，已制定长期规划，已安排年度信息化工作，已有区域卫生信息数据中心建 设方案，已制定基层医疗卫生机构信息化建设项目工作方案；机构人员方面，已 25成立卫生信息化建设领导小组，已成立基层医疗卫生机构信息化建设项目工作专 班；资金情况方面，中央补助资金已到位135万，地方配套资金已到位202万。计 划开展政府采购金额：135 万元；下属13家社区卫生服务中心与江汉区医疗卫生 信息平台对接设备（山石安全网关）；基础环境及硬件建设方面，已安排基层医疗 卫生机构信息化建设项目进度时间，已经完成机房建设；人员培训方面，社区卫 生服务中心/站200人。 江夏区：人口总数为60万人，其中农村人口数为34万人。共有乡镇卫生院13 家，已部署HIS、健康档案管理系统和新农合系统；读卡器设备共13台；共有社区 卫生服务中心3家，已部署HIS和健康档案管理系统；读卡器设备共3台；共有村 卫生室247家，已部署村卫生室信息系统、健康档案管理系统和新农合系统；读 卡器设备共204台；共有社区卫生服务站10家，已部署HIS和健康档案管理系统 读卡器设备共10台；共有新农合一卡通12 万张；资金投入方面，地方政府投入资 金300 万元，自筹资金200 万元，利用中央、省级项目资金400 万元；卫生信息专 网链路方面，乡镇卫生院共接入13个，村卫生室共接入204个，社区卫生服务中 心共接入3个；社区卫生服务站共接入10个；规划方面，已制定长期规划，已安 排年度信息化工作，已有区域卫生信息数据中心建设方案，已制定基层医疗卫生 机构信息化建设项目工作方案；机构人员方面，已成立卫生信息化建设领导小组 已成立基层医疗卫生机构信息化建设项目工作专班；基础环境及硬件建设方面， 已经完成机房建设；人员培训方面，共需培训407人，其中乡镇卫生院121人，村 卫生室287人，社区卫生服务中心/站79人。 硚口区：人口总数为72万人。共有社区卫生服务中心11家；共有社区卫生服 务站33家；规划方面，已制定长期规划，已安排年度信息化工作，已有区域卫生 信息数据中心建设方案，已制定基层医疗卫生机构信息化建设项目工作方案；机 构人员方面，已成立卫生信息化建设领导小组，已成立基层医疗卫生机构信息化 建设项目工作专班；资金情况方面，中央补助资金已到位；基础环境及硬件建设 方面，已经完成机房建设；人员培训方面，社区卫生服务中心/站30人。 青山区：人口总数为50.5万人，其中农村人口数为0.6万人。共有社区卫生服 26务中心14家；共有村卫生室12家，已部署新农合系统；共有社区卫生服务站44 家；共有新农合一卡通0.4万张；卫生信息专网链路方面，村卫生室共接入12个， 社区卫生服务中心共接入14个，社区卫生服务站共接入44个。 武昌区：人口总数为113.59万人。共有社区卫生服务中心18家，已部署HIS 和健康档案管理系统；条码枪设备共14台；读卡器设备共25台；可用的应用终端 共247台；共有社区卫生服务站37家，已部署HIS和健康档案管理系统，条码枪 设备共2台；读卡器设备共1台；可用的应用终端共2台；卫生信息专网链路方面 社区卫生服务中心共接入26个，社区卫生服务站共接入16个。 新洲区：人口总数为96.0866万人。共有乡镇卫生院15家，已部署HIS、LIS、 PACS、电子病历、健康档案管理系统和新农合系统；读卡器设备共30台；可用的 应用终端共45台；共有社区卫生服务中心2家，已部署HIS和健康档案管理系统； 读卡器设备共1台； 共有村卫生室528家，已部署村卫生室信息系统、健康档案管理系统和新农合系 统；读卡器设备共611台；共有新农合一卡通20.87万张；卫生信息专网链路方面， 乡镇卫生院共接入15个，村卫生室共接入528个，社区卫生服务中心共接入1个； 机构人员方面，已成立卫生信息化建设领导小组，已成立基层医疗卫生机构信息 化建设项目工作专班；基础环境及硬件建设方面，已经完成机房建设；人员培训 方面，共需培训562人，其中乡镇卫生院30人，村卫生室528人，社区卫生服务中 心/站4人。 以上是各个区信息化的详细介绍，我们对这些区做了一些对比分析，得出如 下统计结果： 1、乡镇卫生院：存在乡镇卫生院的行政区有7个，部署了HIS系统的共6个区； 部署了LIS系统的共2个区；部署了PACS系统的共1个区；部署了电子病历系统 的共2个区；部署了健康档案管理系统的共6个区；部署了新农合系统的共7个 区。从乡镇卫生院信息化程度来看，从有乡镇卫生院的几个区来对比，东西湖区、 新洲区和蔡甸区占有一定的比较优势。 272、社区卫生服务中心：部署了HIS系统的共12个区，有可用应用终端的共2 个区。从社区卫生服务中心信息化程度来看，从有社区卫生服务中心的几个区来 对比，武昌、江岸、江汉、东西湖占有一定的比较优势。 3、村卫生室：存在村卫生室的行政区有9个。部署了村卫生室信息系统的共 4个区；部署了健康档案管理系统的共6个区；部署了新农合系统的共8个区；各 区均无条码枪设备；有读卡器设备的共7个区；有可用应用终端的共1个区。从村 卫生室信息化程度来看，从有村卫生室的几个区来对比，东西湖区、新洲区和江 夏区占有一定的比较优势。 4、社区卫生服务站：存在社区卫生服务站的行政区有11个。部署了HIS系统 的共5个区；部署了健康档案管理系统的共5个区；有条码枪设备的共2个区；有 读卡器设备的共5个区；有可用应用终端的共2个区。从社区卫生服务站信息化 程度来看，从有社区卫生服务站的几个区来对比，江汉区、武昌区和江夏区占有 一定的比较优势。 5、新农合一卡通：共有9个行政区有新农合一卡通，且均为一户一卡配备方 式，共81.1607万张，新农合主要实现功能均为刷卡就医、身份识别、即时结报。 6、资金投入：共有9个行政区进行上报，其中最多的为江夏区，最少的是江岸 区。 7、卫生信息专网链路：有乡镇卫生院的区是7个，其中7个区中的乡镇卫生 院卫生信息专网链路覆盖率100%；有村卫生室的区是8个，其中6个区的村卫生 室的卫生信息专网链路覆盖率100%；有社区卫生服务中心的区是14个，其中12 个区的社区卫生服务中心的卫生信息专网链路覆盖率100%；有社区卫生服务站 的区是11个，其中5个区的社区卫生服务站的卫生信息专网链路覆盖率100%； 从卫生信息专网链路层面分析， 14个区来对比，东湖新技术开发区、东西湖区、 汉南区、洪山区、江汉区、青山区占有一定的比较优势。 8、规划情况：制定长期规划共有6个区；有年度信息化工作安排共有9个区； 有区域卫生信息数据中心建设方案共有7个区；制定基层医疗卫生机构信息化建 设项目工作方案共有7个区；蔡甸区、汉阳区、黄陂区、江夏区、江汉区处于比较 28优势。 9、机构人员情况：各区均未成立由编制部门批复同意的卫生信息中心机构； 成立卫生信息化建设领导小组共有11个区；成立基层医疗卫生机构信息化建设 项目工作专班共有10个区。蔡甸区、东湖新技术开发区、东西湖区、汉南区、汉阳 区、江岸区、江汉区、江夏区、硚口区处于比较优势。 10、基层医疗卫生机构信息化建设项目资金情况共有7个区进行上报。基础 环境及硬件建设情况：有基层医疗卫生机构信息化建设项目进度时间安排的共有 4个区；已经完成机房建设共有8个区；有硬件设备的共有7个区。东湖新技术开 发区、东西湖区、汉南区、汉阳区、洪山区、江汉区处于比较优势。 11、基础环境及硬件建设情况：基层医疗卫生机构信息化建设项目进度时间 安排中，只有东湖新技术开发区、东西湖区、江岸区、江汉区有过安排；黄陂区、江 汉区、江夏区和新洲区已经完成机房建设。 12、人员培训情况：培训人员数量共有5个区进行上报，其中最多的是新洲区 562人，最少的是硚口区30人；乡镇卫生院培训人数共有5个区进行上报，其中 最多的是东西湖区180人，最少的是洪山区2人；村卫生室培训人数共有5个区 进行上报，其中最多的是新洲区528人，最少的是洪山区76人；社区卫生服务中 心/站培训人数共有6个区进行上报，其中最多的是江汉区200人，最少的是蔡甸 区1人。 综上，处于比较优势的区域包含江汉区、汉阳区、东西湖区、江夏区。 2.4 项目整体需求分析 2.4.1 用户需求 2.4.1.1 居民 居民是医疗卫生服务的对象，是医疗卫生服务的受益者。获取方便、廉价的医 29疗服务以及公共卫生服务是居民的根本需求。通过提供“以居民为中心”生命周 期健康管理和服务，居民可随时掌握和管理自身连续健康记录，可通过与医疗卫 生服务人员的互动，获取更便利、优质的医疗卫生服务。 1、获取基本健康知识，提高保健意识 居民可通过门户网站、手机订阅服务等多种方式查阅基本健康知识，如常见 慢性病防治信息、家庭用药注意事项、日常饮食准则等，以提高居民自身保健意 识，从源头上减少居民患病率，增强居民健康水平。 2、居民自我健康信息管理 居民可通过门户网站等多种方式查阅个人健康相关各类信息。比如个人健康 档案查询：居民可查阅个人健康档案，包括历次医院就诊诊疗信息、公共卫生服 务信息（如注射疫苗等）等。 3、可及的卫生服务 通过市级卫生信息平台，医院开展专家远程咨询会诊、转诊等服务，使居民就 医更方便。通过建立区域性健康档案，实现健康信息共享，改变城乡居民的就医 观念，逐步实现“小病在社区,大病在医院”，有效缓解“看病难”的状况。 2.4.1.2 各级医院和社区卫生服务中心 医生是为居民提供医疗服务的重要组成人员，在就医人群数量庞大的现状下 如何通过信息化的支撑在提高医生诊断质量、减少医疗纠纷的同时不降低诊疗效 率，有效减轻医生和医院的压力成为卫生信息化重点考虑问题之一。 对于医生来说，在诊疗过程中包括如下需求： 1、按需调阅居民健康档案和电子病历，掌握居民健康状况，以便更准确地进 行诊断 为了提高医疗质量和提供更合适的治疗方案，医生可以调阅到当前患者的历 次诊疗信息，包括在其他医院就诊的检验、检查、诊断等各类资料。另外，为了能 够让医生在海量的历史诊疗信息快速找到有帮助的信息，提高诊疗效率，可将患 者个人健康史及近期诊疗等信息进行整合，形成“个人健康摘要”供医生查阅。 302、利用信息技术和知识库，辅助、规范诊疗过程，提高医疗质量 医生在诊疗过程中可以获得药物过敏、重点人群、慢病患者等各类警示信息 等，以提高诊断质量，减少医患纠纷，同时也可降低患者重复检验检查费用，提高 患者满意度。 2.4.1.3 卫生行政管理部门 市级卫生信息平台系统通过建立科学合理的指标体系，对医疗服务、公共卫 生服务等各类信息进行挖掘分析，进而可为卫生局领导制定政策、优化流程提供 支撑。如可提供以下分析： 1、监测预警与风险评估 基于居民疾病数据分析，可加强对突发公共卫生事件的监测预警和风险评估 并及时掌握卫生资源分布情况，有序指导实施突发公共卫生事件预防控制与应急 处置。 2、医疗行为监管 获取医疗过程中医疗行为相关信息，如医生调阅患者健康档案等信息，一方 面作为处理医疗纠纷、医疗事故的有效依据，另一方面，也可作为考核医务人员 的有效指标之一，促进提高医疗质量，减少医患纠纷。 3、绩效考核 基于对各医疗卫生相关机构、人员、运营等各类数据分析，制定机构、岗位的 核心考核指标，列入机构、岗位职能要求，并通过绩效考核规范明确奖惩，促进行 风建设，提升行政效能。 2.4.2 业务需求 2.4.2.1 医疗卫生服务 在医疗卫生业务工作中，我们不仅需要获取跨越不同系统的健康信息，还需 要获取跨越不同区域卫生管理机构与边界的健康信息，在更大的医疗服务范围内 31实现就诊预约、双向转诊乃至病情追踪。 电子病历包括居民从生到死，各个生命时期所有的关于医疗服务的信息和资 料，包括居民的基本信息，以及每次就诊的病历、报告、处方、体检结果等等。电子 病历的共享就是各医疗卫生机构(各级医院、社区卫生服务中心/卫生院等)将本单 位的医疗服务业务数据采用统一的标准汇总到数据中心，形成每个居民完整的电 子病历信息，同时面向区域内各医疗卫生机构开放共享查询等功能，以便于为居 民提供有针对性的、连续的医疗卫生服务。  节省患者支出,缓解群众“看病贵”问题的需要 通过基于网络的信息技术，为每个市民建立电子病历，实现个体化的疾病管 理。居民个人的疾病资料，像中老年人慢性病的情况、大医院的就诊记录，以及诊 断治疗的重要的记录，如CT、核磁、X线的检查、影像学的资料，以居民为中心形 成电子病历。患者在区域联网医院范围内就诊，医生可即时查询到患者近期在其 他医院的就诊记录及相关的实验室检验、影像检查报告，在检验检查结果互认的 前提下可减少重复检验检查，在一定程度上缓解了患者的医疗支出。  提高医疗服务质量的需要 电子病历是居民疾病诊治管理过程的规范、科学记录，是居民健康及疾病发 展过程的直接描述，医生可根据电子病历及时、全面了解居民的主要疾病/健康问 题与相关的禁忌，了解其他医院或医生对其的处治方案、治疗效果，便于医生作 出科学的判断，提出有针对性的治疗方案，既能提高医疗卫生服务效率，又能较 大程度的提高医疗服务质量。  争抢生命绿色通道“黄金时间”的需要 院前急救是急救医疗服务系统的3大组成部分之一，是抢救病人的前沿，院 前急救工作直接关系到病人的生死存亡，具有很强的医疗性和社会性。急症患者 很多因为错过了急诊抢救的黄金6小时，而面临愈后效果差，甚至失去生命的结 果。 通过居民电子病历可以在第一时间了解决患者的病史、药物过敏史等情况， 并有针对性地进行医疗诊治准备，避免无法询问病情因病史不明确导致救治不力 32的情况，真正的把握急诊抢救的黄金6小时。  有效、合理利用医疗资源的需要 通过电子病历的建设，在不同机构之间开展的有效、持续的患者服务与医疗 管理，加强农村卫生服务体系和城市社区卫生服务体系建设两项基础工作，促进 城乡医疗卫生事业协调发展，真正缓解城乡居民“看病难看病贵”问题。 实行社区卫生服务机构与大中型医院多种形式的联合与合作，建立分级医疗 和双向转诊制度，探索开展社区首诊制、远程会诊试点，由社区卫生服务机构逐 步承担大中型医院的一般门诊、康复和护理等服务。从而促进大中型医院与城市 社区卫生服务机构之间形成业务联动、优势互补、疾病诊治连续化管理的机制， 最终实现小病在社区，大病进医院，康复回社区的就医格局。 实现各级医疗卫生机构间业务联动的重要一点就是信息共享与沟通，这有赖 于信息化建设。没有居民电子病历等基础信息，信息化支撑转诊、会诊可谓无源 之水；只有有了基础信息，才能够说得上转诊、会诊时各类医疗机构之间共享信 息，才能谈以此实现提高质量降低费用的目的，实现区域医疗资源的合理布局与 利用。 2.4.2.2 卫生综合管理 卫生综合管理部门可以利用基于区域卫生信息平台，结合社会各方面的资源 加强对医疗、公共卫生及社区服务等全方位的管理；及时了解全市医疗卫生服务 现状及发展趋势，根据全市疾病发生的时间及空间分布了解卫生资源的需求，从 而有利于相关卫生政策的制定。  进一步深化医疗体制改革的需要 目前利用信息化建设进行卫生体制的改革取得了显著的成绩，为了满足更深 入的卫生体制改革,需要进一步加强信息化建设广度和深度,实现数据更广泛的共 享与交换，充分利用数据实现医疗卫生管理与服务的需求，同时加强系统的运营 维护管理，才能推动进一步的医疗卫生服务体制的深化改革。  合理配置医疗卫生资源需求 33区域卫生信息平台建成后，卫生行政部门可以获得宏观管理所需的数据支持, 以辅助其决策，高效开展电子政务、疾病监测、资源调度等；通过互联互通的医疗 卫生网络体系将使行政管理部门对卫生业务部门的监督和控制更加的及时和准 确，提高对整体卫生资源的调配力度，加强对医疗卫生服务的引导，提高行业内 的科学决策能力。卫生信息的发布与公示将加强了对医疗机构的管理和约束，增 强政策的透明度。 加强宏观管理，优化卫生资源的配置。为城乡居民提供更加便捷的健康服务。 保障区内各类人才的健康需求，增强区域竞争能力。可以通过网络全面掌握医疗 卫生服务体系、救助体系、保障体系等方面的详细资讯，为制定公共卫生政策提 供准确依据。  资源整合，减少重复投资需求 近年来卫生信息化建设的发展速度较快，但不可忽视的是，不管是硬件建设， 还是应用系统的开发，以及数据的采集与信息利用，大多数都是出于一种低水平 重复的无序状态。每个单位都建设小而全的网络信息系统，采用不统一的系统软 件，使用不规范的应用系统，配备不少的专业计算技术人员，投入不菲的建设与 维护资金，结果是财力、物力与人力投入很大，带来的却不是令人满意的效益。各 部门、各系统的数据无法交换共享，遇到如SARS等突发事件时，连最基本的统计 数据都无法自动获取，还要通过手工方式收集、上报、统计，难以发挥卫生信息系 统的作用。  实现跨业务跨系统的数据共享利用的需求 由于卫生信息化建设各自为政，缺乏统一规范和部署，各医疗卫生机构之间 的网络物理上不联通，业务标准、数据标准不一致，数据无法交换共享，形成了各 单位、各条线的信息孤岛。首先，各单位对基础与公共信息都要重复采集与存储， 由此造成人力、物力与财力的重复投资；其次，由于数据的重复采集与存储，导致 数据冗余，影响数据的一致性与唯一性；最后，虽然数据被多处采集与存储，但由 于标准不一致，数据还是无法交换、共享。 342.4.3 应用需求 结合武汉市卫生信息化“十二五”规划的总体业务需求，武汉市的卫生信息 化将按照“整体规划，分步实施，试点先行，全面推进”的原则稳步推进，在2011 年初步搭建武汉市智慧医疗信息系统的框架，基本实现医疗服务电子信息平台建 设，启动试点工程，实现试点范围内医疗卫生服务信息的互联互通和信息共享， 重点实现试点医疗机构之间有关医疗服务信息的互联互通和业务的协同联动，探 索建立患者在试点医院看病就医实现医疗服务“一卡通”，为整体推进全市智慧 医疗卫生信息系统建设开好头、起好步。项目推进的具体应用需求如下： 2.4.3.1 患者身份唯一识别 目前，武汉市各级医院的信息化程度差距较大，总体信息化水平落后，除医保 新农合患者实现一卡通外，大部分医院尚未实现自费患者的电子化身份识别，仍 采用传统的持病历本就诊的模式，只有少部分信息化建设程度较高的医院针对自 费患者自行发卡。 要实现电子病历信息在各医疗卫生机构之间的共享和交换，就必须要解决各 医院信息系统之间信息共享的唯一身份标识。 2.4.3.2 电子病历共享 将居民在每家医疗卫生机构的卫生服务数据统一采集，原先分布在医疗机构 社区内的关于区域内居民的健康信息均可以交换整合到本平台中的卫生信息数 据中心，实现区域卫生信息资源的互通，形成每个居民完整的医疗相关信息档案 供居民自己、临床医生、责任全科医生及相关机构调阅。 电子病历共享除需要解决对居民身份唯一性的识别外，还需制定标准，规范 数据采集、交换、整合、调阅，着重考虑保护居民的健康隐私，保证数据的安全，做 到全程数据监控。 352.4.3.3 区域业务协同 业务协同需求是指基于本平台实现医疗机构之间的业务协同，医疗机构、社 区及条线机构的业务联动。通过业务协同，可以有效利用医疗资源，降低医疗成 本，提高医疗质量。具体可包括：可包括远程会诊、双向转诊、跨院转检、远程会诊 等。 2.4.3.4 区域卫生信息管理 日常医疗业务中产生的数据经过统计分析能够变成对卫生业务管理可用的 信息,通过丰富的统计分析信息可以帮助管理者及时掌握医疗卫生服务状况，并 持续改进医疗质量，保障医疗安全，改善医疗服务，控制医疗费用，为群众提供安 全、有效、方便、价廉的医疗服务。 2.4.3.5 区域卫生决策支持 传统的业务管理难以满足管理和决策的需要。管理者/业务人员自身掌握的 知识和经验有限，难以从大量数据中得出有价值的信息，从而做出判断或决策。 通过辅助决策从大量数据中找出规律，利用数学模型产生信息，为决策者提供分 析问题、建立模型等，帮助管理者/业务人员做出判断或决策。 2.4.3.6 公众服务 在信息资源整合共享和业务协作的基础上，最终通过卫生公众服务网站，实 现与居民的健康互动。根据数据中心数据采集的情况及卫生政策的改革情况，结 合社会公众关心的信息需求，将数据中心处理后的数据动态地发布在相关的网站 上。居民可获取权威机构发布的及时、准确、客观、全面的卫生事件相关信息。 2.4.4 标准规范使用需求 统一标准是卫生信息化建设的基础工作，也是进行信息交换与共享的基本前 36提。在卫生信息化建设中，必须强调“统一规范、统一代码、统一接口”。 武汉市智慧医疗信息系统既要从总体上对标准进行规划，以确保标准的完整 性，又要加强对当前标准化重点工作的设计，如本次建设涉及到的诊疗信息、公 共卫生信息等数据标准、本次建设接入机构间的接口规范需先行制定，并逐步运 用在系统的设计和建设中；其他标准可根据系统建设的不同阶段，有计划地、循 序渐进地制定并运用，逐步建立和完善武汉市的医疗卫生信息化标准规范。 另外，标准的制定工作应参考并遵循国家卫生部、湖北省卫生厅等已有的各 类规范标准，部分国家或湖北省标准需根据武汉市的实际情况进行本地化处理， 以符合武汉市卫生业务的具体开展情况。 2.4.5 技术需求 2.4.5.1 网络分析 武汉市智慧医疗信息系统涉及整个武汉市医疗卫生服务和公共卫生服务体 系，它需要在不同单位、部门间进行业务协同和数据交换。这种协同与交换必须 通过基础的网络平台来支持，连接全市各级各类医疗卫生机构和省、市、区卫生 行政部门以及有关其它单位，最终将覆盖全市医疗和公共卫生体系及相关单位。 通过本项目的网络平台建设，可以解决武汉市卫生信息化建设中存在的数据交换 困难、信息孤岛等问题,相关单位和部门通过本平台建立网络连接,实现信息交换 和数据共享。 本期系统建设基本现状与需求如下：  涵盖的各有关单位  武汉市卫生局。  16家医院。  24家社区卫生服务中心。  网络条件 武汉市智慧医疗信息系统所依托的网络环境即武汉市“卫生专网”是一个 37全新建设的网络。根据目前业务的相关需求，现阶段的武汉市“卫生专网”主要 采用MPLS VPN 光纤专线或ADSL拨号两种方式接入。  MPLS VPN光纤专线 卫生专网将采用租用网络运营商线路的方式来实现。其中数据中心的接入； 疾控、卫监、血站等卫生行政机构以及各二级以上医院的卫生专网接入均通过光 纤专线的方式来实现。  ADSL拨号 对于业务量相对较少的社区卫生服务中心，我们从合理规划及保护投资的角 度出发，建议采用ADSL拨号的方式接入社区，通过网络运营商的汇接，接入卫生 专网，以实现与数据中心的数据交互与共享。 据此，通过卫生专网的方式来承载武汉市智慧医疗信息系统，可以为系统提 供一个健壮的、稳定的网络支撑，在很大程度上提高系统的整体安全性及使用性 能。 2.4.5.2 服务器处理能力分析 武汉市智慧医疗信息系统将支持市民电子健康档案和电子病历、健康信息查 询和共享等一系列的业务。考虑到业务模型复杂且实时性高，主要是基于内存的 数据交换及基于多数据源的交易处理，因而对于数据库服务器内存及处理器的要 求较高，服务器需具备优良的OLTP 能力。 根据卫生部《基于健康档案的区域卫生信息平台建设技术解决方案》的测算， 高级规模系统是500万到1000万人口以上，按照三甲医院、二甲医院、以及大致 社区卫生服务中心的数量估算。 考虑武汉的具体情况，武汉现有910万常住人口，流动人口约200万，本期接 入16家医院2010年的门急诊总人数：1276.7万人次，住院人次：49.21万人次； 全市2100年门急诊总人数5100.2万人次，住院人次：155.1万人次；按照卫生部 及卫生行业内的经验测算方法  每人次诊疗发生EHR数据访问8次 38 每人次诊疗发生 EHR交易缓存访问(HIAL)20次，  每人次诊疗发生PACS索引访问1次计算  业务量年增长为20%  一次交易操作的TRANSACTION 的平均TPC-C 值为10左右  服务器系统一般不可能满负荷运行的因素，假设余量为50% 则本期：每日EHR交易缓存系统访问次数约为（（1276.7万次+49.21万次）/ 365天*20次）＝72.65万次/天，EHR数据访问次数约为(（1276.7万次+49.21万 次）/365天*8次)＝29.06万次/天，PACS索引访问次数为(（1276.7万次+49.21万 次）/365天*1次)＝3.63万次/天，因此每日总访问次数约为72.65万次/天+29.06 万次/天+3.63万次/天＝105.35万次/天。同样认为医疗机构80%的患者集中在上 午 8：30-10：30，因此峰值访问次数约为 105.35 万次×10000×80%/2/3600 秒 =117.05次/秒，及117.05次/秒×60＝7023次/分钟，本期数据库服务器的TPCC值 需求约为7023×10/(1－50%)＝140460TPCC。 在未来3年，考虑武汉市全市医疗卫生机构已接入平台，且每年业务大约以 20%的速度增长，第三年每天的业务频度将达到（（5100.2万次+155.1万次）/365 天×（20次+8次+1次））×（1+20%)）3＝622万次/天。考虑到业务高峰因素，假设 80%的业务量都是在2 个小时的高峰时间内完成。综上算出高峰时段每分钟的交 易和查询量：6220000 笔*0.8/2/60=48101 笔/分钟。 所以，所选机型的TPC-C 值至少应达到：48101 * 10 / (1-50%) = 962020TPCC。 本次项目招标对核心数据库及核心应用服务器的要求是88万TPCC值，考虑 实际使用情况及业务可能的发展规模，我们本次配置的小型机为1074223TPCC值 系统设计方案时是采用集群方式实现双机互备。 2.4.5.3 存储分析 以在线存储系统容量估算方式为例，由于本次建设将采取混合式存储分布， 其中的注册系统、EHR索引系统、PACS索引系统、EHR交易缓存和EHR数据系统 均保存在市级平台。考虑武汉市约1110万人口（常住910万，流动200万左右）， 39本期接入16家医院近一年门急诊总人数约：1276.7万人次，住院人次约：49.21 万人次；全市近一年门急诊总人数约5100.2万人次，住院人次约：155.1万人次。 按照三甲医院的经验数据:  每诊疗人次大致产生15KB，  每服务对象基本信息数据量为20KB，  EHR缓存相关数据与EHR数据量基本一致，  每人次诊疗发生PACS索引访问1次计算  PACS缩略数据为100KB每份  PACS缩略信息保留期为8个月  业务量年增长为20% 则储存16家试点医疗机构2010年电子健康档案相关数据需要（(1276.7万 次+49.21万次）*15KB/次+1110万人*20KB/人）*10000*2/1024/1024=802.8GB。 另外，在一期系统规划中，将不考虑存储部分PACS缩略信息，后续项目建设 中假设PACS缩略数据为100KB每份，平均每次诊疗发生的影像检查为1次，则存 储2010年PACS缩略信息需要(1276.7万次+49.21万次)*1*100KB/次 *10000/1024/1024=1264GB，当然在实际操作中并不需要保存全年的PACS缩略信 息，在此我们选择8个月为保存期限，则在市级平台需存储的PACS缩略数据约为 1T。 则第1年16家试点医院接入时，平台所需存储空间为802.8GB+1T；约为 2TB。 在未来3年，考虑武汉市全市医疗卫生机构已接入平台，且每年业务大约以 20%的速度增长，在个人基础信息变化不大的情况下。武汉市智慧医疗信息系统 的3年数据容量为（（（5100.2万次+155.1万次）×（1+20%)）3×15 KB/次）+1110万 人×20 KB/人）×10000*2/1024/1024＝3022GB。 3年后，全市PACS部分的缩略信息约为（5100.2万次+155.1万次）×（1+20%)） 3×1×100 KB/次×10000/1024/1024=8661GB,同样按8个月的保存期，则第三年市级 平台需存储的PACS缩略数据约为6T。 40则3年后，当所有医疗机构接入后，平台所需存储空间为3022GB+6T，约为 10TB。 综上所述，武汉市智慧医疗信息系统的存储注册系统、EHR索引系统、PACS索 引系统、EHR交易缓存和EHR数据系统以及PACS缩略数据，第1年16家试点医 疗机构接入时所需2TB，3年后所有医疗机构接入后所需为10TB。 因本期项目PACS相关业务还未开展，考虑到今后的业务发展以及系统冗余， Raid 消耗，表空间损耗等因素，本次项目的在线存储容量为配置10TB SAS高速硬 盘。 而近线存储中考虑存放多个时间节点的全拷贝，按照其他副省级城市区域卫 生平台上的参考数据，初步定位在线存储容量的4～5倍，即近线存储设备容量考 虑48TB。 2.4.5.4 性能分析 医疗卫生信息的共享调阅用户涉及到临床医生、社区医生和居民等，医生在 诊疗的过程中时间比较紧张，因此在医生工作站的查询调阅功能对系统的响应速 度要求较高，一般控制在1秒之内；居民通过公众健康服务门户的调阅响应速度 一般控制在2秒之内。 卫生管理和决策由于涉及到大数据量的分类汇总统计分析，运算量较大，一 般响应时间控制在5秒之内。 2.4.5.5 安全分析 系统的安全是任何业务开展的基础，除了信息系统通用的物理安全、网络安 全、系统安全、应用安全及安全管理外，针对本项目，还需着重考虑以下几个方面 的安全问题：  用户访问的身份认证：采用严格的操作员身份认证机制，防止伪造身份 人员冒用系统资源。  数据调阅的安全（居民健康信息隐私保护）：居民健康信息关乎个人隐 41私，因此在医生工作站调阅或居民通过健康网站查询健康档案过程中，需要充分 考虑安全策略，以保护居民隐私。  内外网数据交换的安全：本项目为居民提供健康信息查询服务，涉及到 内外和外网的数据交换，为保证居民健康信息的安全性，要充分考虑内外网数据 交换的安全性。 423.项目需求 1-专网设计 医疗专网的接入是为了实现各级医疗机构的互联互通，从而解决各医疗机构 之间的“信息孤岛”问题，其接入的数量是各类专网中最多、分布最广的。目前 湖北省卫生厅依托通信运营商的基础网络资源已建设了一张与其他公共网络隔 离的、独立的、安全稳定的全省性的业务承载支撑专网，其网络结构分为骨干网 和接入网2级，骨干网节点包括1个省节点、21个市州节点、91个县（区）节点； 而武汉市卫生网络现阶段仍处于借助政务外网、新农合业务专网等其他网络来进 行搭建，为了能更安全、高效、直接地掌握智慧医疗的各类信息，建立覆盖整个武 汉市卫生机构的卫生专网，形成科学、规范、高效的卫生网络管理运行体系，已是 当前武汉市卫生信息化建设的迫切工作之一。 3.1 武汉市卫生专网建设蓝图 卫生专网的建设蓝图包括武汉市所有医疗卫生机构，包含： （1）卫生行政管理机构。 （2）公共卫生机构：妇幼保健机构17家；产科及助产技术服务机构128家； 临床检验中心5家，血液中心1家，急救中心和站12家，体检机构13家。 （3）二级以上的医疗卫生机构：综合医院190家；专科医院(西医类)43家；中 医和中西医结合医院49家。 （4）基层医疗机构：社区卫生服务中心124个，社区卫生服务站416个。有乡 镇卫生院86家，村卫生室1845个。 （5）民营医疗机构：诊所2129家。 卫生专网蓝图的建设拓扑图如下所示： 43443.2 武汉市卫生专网本期建设内容 为贯彻落实武汉市委市政府工作要求，围绕武汉市“十二五”卫生信息化发 展规划，为配合2011年武汉市智慧医疗信息系统（市级卫生信息平台一期建设项 目）的建设，武汉市卫生专网项目的建设目标是：初步搭建武汉市区域卫生信息 专网，为本次纳入试点的8个区卫生局，21家医院，4家公卫机构搭建相关线路， 保证各机构在满足带宽和安全需求的基础上接入武汉市卫生专网，实现互联互通 本期项目，专网接入机构包含： 1、市卫生局 2、8个区卫生局（排名不分先后）： 其中8个区卫生局，包括： （1） 江汉区卫生局 （2） 汉阳区卫生局 （3） 东西湖经济开发区卫生局 （4） 硚口区卫生局 （5） 洪山区卫生局 （6） 黄陂区卫生局 （7） 江夏区卫生局 （8） 汉南区卫生局 3、21家医院，包括（排名不分先后）： （1） 武汉市汉口医院 （2） 武汉市妇女儿童医疗保健中心 （3） 武汉市中心医院 （4） 武汉市中医院 （5） 武汉市第四医院 45（6） 武汉市中西医结合医院 （7） 武汉市第三医院 （8） 武汉市武昌医院 （9） 武汉市武东医院 （10） 武汉市第十一医院 （11） 武汉市第五医院 （12） 武汉市第六医院 （13） 武汉市第八医院 （14） 黄陂区人民医院 （15） 武汉协和医院 （16） 广州军区武汉总医院 （17） 武汉市东湖医院 （18） 武汉市精神卫生中心 （19） 武汉市医疗救治中心 （20） 武汉市普仁医院 （21） 武汉市结核病防治所 4、4家公卫机构：包括（排名不分先后）： （1）市疾控中心 （2）市急救中心 （3）市血液中心 （4）市妇保院 3.3 建设原则与要求  在网络负载80%情况下，执行 Ping命令 (1000字节) ，时延应小于30ms；  在网络负载80%情况下，数据传送的抖动值应小于 30ms；  节点互联之间网络丢包率不超过 0.5%；  设备互联端口建议固定双工模式、固定速率模式、固定MTU值； 46 音视视频流传输尽量避免穿越防火墙、各类加密或封装隧道所构建 的网络链路；  运营商应负责各接入端专网光纤及其接入转化设备的部署、安装、配 置、维护等工作；  卫生专网应具有极高的安全性，从社区卫生服务中心（社区卫生服务 站）到市级数据中心的接入网络都必须与互联网或其他专网隔离；  所有线路在今后业务增长时均能平滑升级。 3.4 项目带宽需求 （1）卫生行政管理机构； 市卫生局可考虑通过裸光纤或50Mbps 以上线路接入。运营商需考虑冗余备 份线路，备份线路带宽不小于20Mbps。 区县卫生局可考虑不小于20Mbps。 （2）公共卫生机构； 可考虑不小于10Mbps专线接入。 （3）二级以上的医疗卫生机构； 不小于10Mbps专线接入。部分数据量大的医院可建议采用20Mbps线路。 （4）基层医疗机构； 不小于4Mbps线路接入，未来可平滑过渡过10M。 （5）民营医疗机构； 不小于4Mbps线路接入，未来可平滑过渡过10M。部分数据量大的医院可 建议采用10Mbps线路。 3.5 IP 地址分配要求 武汉市卫生专网为了保证与湖北省卫生专网实现互联互通，建议遵循湖北省 卫生厅全省的IP地址和路由规划。具体IP规划如下表： 47武汉市卫生专网IP地址规划 序 区卫生局服务器和PC VPDN终端（自动分配） 定点医疗机构 号 地域 地址段 掩码 地址段 掩码 地址段 掩码 1 武汉市 172.16.192.0 255.255.254.0 2 黄陂区 172.16.8.0 255.255.255.0 172.16.0.0 255.255.248.0 172.16.13.0 255.255.254.0 3 新洲区 172.16.24.0 255.255.255.0 172.16.16.0 255.255.248.0 172.16.29.0 255.255.254.0 东西湖 4 区 172.16.40.0 255.255.255.0 172.16.32.0 255.255.248.0 172.16.45.0 255.255.254.0 5 汉南区 172.16.56.0 255.255.255.0 172.16.48.0 255.255.248.0 172.16.61.0 255.255.254.0 6 蔡甸区 172.16.72.0 255.255.255.0 172.16.64.0 255.255.248.0 172.16.77.0 255.255.254.0 7 江夏区 172.16.88.0 255.255.255.0 172.16.80.0 255.255.248.0 172.16.93.0 255.255.254.0 8 沌口 172.16.104.0 255.255.255.0 172.16.96.0 255.255.248.0 172.16.109.0 255.255.254.0 9 洪山区 172.16.120.0 255.255.255.0 172.16.112.0 255.255.248.0 172.16.125.0 255.255.254.0 东湖高 10 新 172.16.136.0 255.255.255.0 172.16.128.0 255.255.248.0 172.16.141.0 255.255.254.0 11 江汉区 172.16.152.0 255.255.255.0 172.16.144.0 255.255.248.0 172.16.157.0 255.255.254.0 12 武昌区 172.16.168.0 255.255.255.0 172.16.160.0 255.255.248.0 172.16.173.0 255.255.254.0 13 青山区 172.16.184.0 255.255.255.0 172.16.176.0 255.255.248.0 172.16.189.0 255.255.254.0 14 汉阳区 172.16.200.0 255.255.255.0 172.16.192.0 255.255.248.0 172.16.205.0 255.255.254.0 15 江岸区 172.16.216.0 255.255.255.0 172.16.208.0 255.255.248.0 172.16.221.0 255.255.254.0 16 硚口区 172.16.232.0 255.255.255.0 172.16.224.0 255.255.248.0 172.16.237.0 255.255.254.0 项目一期医疗机构接入IP地址规划，如下表： 一期医疗机构接入IP地址 序 定点医疗机构专网IP 号 定点医疗机构名称 IP地址 掩码 1 武汉市卫生局 172.16.240.0 255.255.254.0 2 江汉区卫生局 172.16.144.0 255.255.248.0 3 汉阳区卫生局 172.16.192.0 255.255.248.0 4 东西湖区卫生局 172.16.32.0 255.255.248.0 5 硚口区卫生局 172.16.224.0 255.255.248.0 6 洪山区卫生局 172.16.112.0 255.255.248.0 7 黄陂区卫生局 172.16.0.0 255.255.248.0 8 江夏区卫生局 172.16.80.0 255.255.248.0 9 汉南区卫生局 172.16.48.0 255.255.248.0 10 武汉市汉口医院 172.16.252.16 255.255.255.240 11 武汉市妇女儿童医疗保健中心 172.16.252.32 255.255.255.240 12 武汉市中心医院 172.16.252.48 255.255.255.240 13 武汉市中医院 172.16.252.64 255.255.255.240 4814 武汉市第四医院 172.16.252.80 255.255.255.240 15 武汉市中西医结合医院 172.16.252.96 255.255.255.240 16 武汉市第三医院 172.16.252.112 255.255.255.240 17 武汉市武昌医院 172.16.252.128 255.255.255.240 18 武汉市武东医院 172.16.252.144 255.255.255.240 19 武汉市第十一医院 172.16.252.160 255.255.255.240 20 武汉市第五医院 172.16.252.176 255.255.255.240 21 武汉市第六医院 172.16.252.192 255.255.255.240 22 武汉市第八医院 172.16.252.208 255.255.255.240 23 东湖医院 172.16.252.224 255.255.255.240 24 市精神卫生中心 172.16.252.240 255.255.255.240 25 普仁医院 172.16.251.0 255.255.255.240 26 黄陂区人民医院 172.16.13.0 255.255.255.248 27 市医疗救治中心 172.31.22.0 255.255.255.0 28 武汉协和医院 172.31.7.0 255.255.255.0 29 广州军区武汉总医院 172.31.14.0 255.255.255.0 30 市结防所 172.31.4.0 255.255.255.0 494.项目需求 2-市数据中心扩建 具体数据中心集成方案参考附件《武汉市卫生局智慧医疗信息系统（市级卫 生信息平台一期）系统集成实施方案》 4.1 网络系统 武汉市智慧医疗卫生信息系统涉及整个武汉市公共卫生体系，它需要在不同 单位、部门间进行业务协同和数据交换。这种协同与交换必须通过基础的网络平 台来支持，连接全市各级各类医疗卫生机构和省、市、区卫生行政部门以及有关 其它单位，最终将覆盖全市公共卫生体系及相关单位。 4.1.1 网络总体设计 首先，武汉市智慧医疗卫生信息系统平台相关应用在物理上采用的数据“大 集中”的模式，遍布全市的节点要求连接数据中心的特点，决定了系统以星型拓 扑架构为基础。在这个架构中，根据不同的网络特征和连接特征进行了网络两层 体系分类。 其次，根据国际、国内网络技术的发展趋势，以国际通行的主流网络技术与协 议作为本系统网络技术与协议，如TCP/IP协议、千兆位骨干网技术、三层交互技术、 VLAN协议、HSRP/VRRP协议、动态路由协议、STP协议、Qos技术、MPLS VPN隧道技 术等。 第三，根据网络安全需求采用了多种网络安全措施。如链路冗余、设备冗余、 防火墙隔离、入侵保护等。 第四，结合网络中安全和日常可维护的需要，进一步提高网络管理、运维的 智能性、有效性，结合带外管理KVM技术，实现对重要网络和主机设备运行维护。 并根据不同的业务需求，构建业务功能区域，在区域之间建立良好的数据过滤、 50安全防护措施，并由针对的分级部署，明确安全级别。 4.1.1.1 节点分层构架 根据接入节点的业务和应用属性，首先将全网网络构架分层部署，我们将武 汉市智慧医疗卫生信息系统网络构架抽象为核心层、接入层。其中核心层包括核 心节点，接入层包括骨干节点、一般接入节点，每类节点不同具备不同的功能，组 网结构也均不相同。 514.1.1.2 冗余构架设计 武汉市智慧医疗卫生信息系统网络平台承载了重要的信息业务和应用系统, 其故障响应时间不应超过0.5小时。因此对网络平台的可靠性要求势必很高。为了 提高网络系统的可靠性，在设计中对各部分的冗余性进行了充分的考虑，包括： 52核心设备冗余设计、链路冗余设计和电源冗余设计。 4.1.2 网络拓扑 如上图所示，整个网络构架概述为一个核心节点－数据中心；14个骨干节点 －疾控、卫监、血站、妇幼保健所等卫生职能机构及各级医院；20个一般接入节点 －各社区卫生服务中心。 4.1.3 数据中心网络设计 为了保证数据中心网络的可靠性和安全性，根据数据中心建设的相关需求, 本方案采用了多种网络安全和冗余保护措施。如链路冗余、设备冗余、模块冗余、 防火墙隔离等。 根据对数据中心相关应用的需求分析,结合网络中安全和日常可维护的需要， 53进一步提高网络管理、运维的智能性、有效性。根据不同的业务需求，构建业务功 能区域，在区域之间建立良好的数据过滤、安全防护措施，不同的区域定义以不 同的安全级别。每个区域具备不同的功能，安全要求、组网方式、以及采用的技术 均有不同。 数据中心主要划分为核心数据区、广域网接入区、安全交换区、数据交换区、 Internet外网区、内部办公区、内网运维区。 4.1.4 分支机构网络设计 4.1.4.1 骨干节点-市级医疗单位设计 如上面的拓扑图所示，骨干接入单位接入设备部署在目前接入单位所在机房内， 新系统和原局域网系统，分别属于不同的物理机柜。主要为原接入单位内部局域 网具备Internet或其他网络出口,同时实现对武汉智慧医疗的访问。 544.1.4.2 汇聚节点-区卫生局设计 如上面的拓扑图所示，区汇聚节点部署在区卫生局机房，新系统和原局域网系统 分别属于不同的物理机柜。 4.1.4.3 接入节点-区属医疗机构设计 接入节点-区属医疗机构的接入类似于骨干节点的接入,在这里不再做重复描述。 554.1.4.4 其它接入节点设计 如上面的拓扑图所示，其它接入节点主要是指医院下属的各社区卫生服务站，这 些节点基本上从属于各个医院，相关业务也与其主管医院对接，基本上通过2M ～4M的运营商接入主管医院或数据中心，我们这里就不在描述了。 564.2 主机系统 4.2.1 系统架构图 4.2.2 主机系统设计 从系统平台总体架构图中可以看到，我们对武汉市智慧医疗卫生信息系统进 行了统一规划。 按照武汉市智慧医疗卫生信息系统的业务功能需求，我们将整个武汉市区域 医疗卫生信息系统分成以下几个逻辑区域，分别为数据中心处理区、数据存储区 57系统管理区和外网服务区等几个部分进行描述。  数据中心处理区 数据中心处理区是武汉市智慧医疗卫生信息系统的业务处理核心，所以在整 个信息平台的建设中是非常重要的。根据信息系统业务特点，我们将整个数据中 心处理区的服务器划分为几个功能群：核心数据库和核心应用服务器群，综合应 用服务器群，数据交换服务器群，其它功能型服务器群等。  SAN存储区 存储系统是数据集中存储的核心区域，通过SAN存储区域网络技术，构建统 一的数据存储平台。依据武汉市智慧医疗卫生信息系统的业务特点，我们建议配 置一台中高端SAN主存储设备作为在线存储设备，一台中高端SAN主存储设备作 为离线存储设备。  系统管理区 系统管理区的功能主要是实现对整个系统网络、计算机、系统平台和数据等 资源的管理（包含数据备份），为医疗卫生应用系统可靠运行提供保障。系统管理 区中包含的资源有系统管理服务器、数据备份服务器、防病毒服务器以及网络管 理服务器等。  网站服务区 网站服务区提供对外服务的网站平台，除了作为武汉市智慧医疗卫生信息系 统的门户网站，负责对外的信息发布等功能，还是市民使用深武汉市智慧医疗卫 生信息系统服务的门户。患者可以通过网站办理预约业务，调阅临床信息。另外， 所属医院可以直接通过医院内网访问内网门户网站。 584.3 存储系统设计 4.3.1 存储设计分析 基于健康档案和电子病历的区域卫生信息平台建设中最关键的是数据。如何 满足区域卫生信息平台的存储需求，是我们必须考虑的问题。以下我们对区域卫 生信息平台中所涉及的存储需求进行设计分析。 4.3.1.1 数据库存储设计 区域卫生信息平台有大量的数据需要存储在关系型数据库中，包括：MPI、 EHR索引、健康档案摘要、标准数据、其他注册数据等。其中XML文档也可能存储 在关系型数据库或者基于关系型数据库的Native XML数据库。在这些数据中， MPI、EHR索引等数据是区域卫生信息平台数据交换、检索和统计的基础，平台系 统对这部分数据的访问量是最大的，在数据库的存储设计中应该重点考虑。 4.3.1.2 影像数据存储设计 在本期设计中，考虑到系统解决方案的全面性，影像数据存储需要建立多级 存储机制，以满足对于存储空间和效率的要求、数据访问控制等其他安全性、通 过冗余/镜像技术实现高可用性和备份和恢复机制等。 4.3.1.3 信息生命周期管理 数据信息等从产生的那一刻起就进入到了一个循环，经过收集、复制、访问、 迁移、退出等多个步骤，最终完成一个生命周期，信息数据是有生命周期的，信息 生命周期管理(ILM)通过存储、保护、管理、集成四个组成部分实现信息管理费用 与业务需求之间的平衡，从而达到降低区域卫生信息平台建设的风险和费用的目 的。ILM可以使区域卫生信息平台实现“适当的信息，在适当的时间，以适当的费 用，存储在适当的设备上”。 594.3.2 存储管理 4.3.2.1 分层存储 所谓分层存储就是将不同I/O性能要求的信息保存在相应不同的I/O性能的 存储介质中，以使存储系统的性能最优化同时降低存储系统的总体拥有成本。通 过数据分级存储，将数据客体存放在不同级别的存储设备（磁盘、磁盘阵列、光盘 库、磁带库）中，通过数据分级存储管理软件实现数据客体在存储设备之间的自 动迁移。根据数据的访问频率、保留时间、容量、性能要求等因素确定数据迁移的 规则，达到最佳的存储策略。在分级数据存储结构中，磁带库等成本较低的存储 资源用来存放访问频率较低的信息，而磁盘或磁盘阵列等成本高、速度快的设备 用来存储经常访问的重要信息。 本项目从三种存储模式的角度建立分层存储机制：集中式存储、分布式存储 和混合（联邦）式存储。 4.3.2.2 存储阵列模式设计 对于区域卫生平台的数据存储，主要采用Raid5模式。 基于前面存储数据量分析与预测的结论，储存三年的数据约需要10TB的存 储量，在本项目建设时，在线存储设计为10TB的高速SAS，近线存储设计为48 TB 的SAS存储。 4.4 备份系统设计 武汉市智慧医疗卫生信息系统包括了多种与民众利益息息相关的职能系统， 数据的安全性关系到整个系统能否正常的运行，最终关系到业务系统能否提供正 常的服务。所以对业务系统的数据做好数据保护是至关重要的，是保证武汉市智 慧医疗卫生信息系统提供正常服务的必要条件。 60随着系统数据量的不断增大，数据维护的复杂程度不断提高，备份对业务系 统的影响越来越大。如果采用人工备份，由于其自动化程度低，出错的可能性也 越来越大，所以人工的备份手段已经不能保证快速、有效的保护数据，并且直接 影响到业务系统的正常运行。 4.4.1 本地备份系统设计 需要不间断为客户提供服务。即使发生短暂的业务中断，也会导致难以估量 的经济损失，同时，政府形象也会受损。因此，保证系统的安全性和数据的持续可 用性是十分重要的。 影响系统正常运行的因素有很多，而在系统中断时能够在最短的时间内恢复 数据是最重要的，所以需要采用一套磁带或者磁盘备份系统对数据库中的数据进 行保护。是按照武汉市智慧医疗卫生信息系统的系统结构，根据备份数据的需求 建立一个高效、集中、易于恢复的备份系统，为业务数据的安全提供有效的保障。 制定一套完整的备份策略，实现数据库中的数据以及文件系统中关键文件的集中 高效的备份。当数据出现故障时，可以及时实施恢复，保证数据的完整性和系统 的持续可用性。 设计中我们为武汉市智慧医疗卫生信息系统构建了SAN存储区域网络，因 此需要配置一台采用光纤接口的高速磁带库，也接入SAN中。用一台PC服务器 作为备份主控服务器，通过SAN控制磁带库或者虚拟带库，并配置备份策略、管 理磁带介质。各数据库服务器则作为备份介质服务器，安装备份软件的数据库 Agent，实现各自数据库的LAN-free备份。如下图所示： 61图：数据库服务器示意图 备份软件为武汉市智慧医疗卫生信息系统等多个系统核心数据库及其他应 用服务器提供数据备份，需要有直观的图形用户界面，允许组织机构管理所有备 份和恢复任务的方方面面，并为用户制定完全一致的备份策略，备份软件需要为 DB2、Oracle等提供数据库识别和应用备份与恢复解决方案。 在武汉市智慧医疗卫生信息系统中，采用带库来完成日常的磁带备份，自动 的在逻辑上实现机械手，驱动器的功能，磁盘存储系统的RAID，镜像等功能可以 从底层保护备份的数据。虚拟磁带库能够和各大厂家的备份软件无缝的兼容，实 现许多高级的备份功能，最大程度上保护用户的数据。 4.4.2 远程灾难备份设计 武汉市智慧医疗卫生信息系统将存储武汉1110万人口的健康档案信息，为 了减少灾难发生时或发生后造成的损失而采取的防范措施。在主中心的不同地方 另外再建立一个备份中心，当主中心发生计算机系统灾难后，在远离灾难现场的 备份中心重新组织系统运行以保护数据的完整性，使业务数据损失最少甚至没有 业务数据损失，并有可能继续提供业务服务（本期不做，后续项目）。灾难备份的 62种类主要包括：数据级备份和应用级备份。其中，应用级备份又分成了非实时方 式与实时方式两种。 从灾难备份的种类上看，灾备系统主要包括数据保护和应用切换两大方面。 应该说，其中最为重要的是数据保护部分，这是实现灾难备份的基础和核心内容 即使是应用级灾难备份，也必须在完成数据同步的基础上，才能实现应用切换和 接管。而随着计算机技术的不断发展，数据的同步与恢复也有了多种实现方式。 而各种方式采用的技术、需要的投资、可以达到的效果均不相同，主要的方式包 括：硬件镜像、软件镜像、数据库复制、数据库备份与恢复和应用复做等。 4.4.3 平台备份方案 基于武汉市智慧医疗卫生信息系统的总体策略，从投资保护及项目实际操作 的流程来看，目前先阶段我们只考虑本地备份，当武汉市智慧医疗卫生信息系统 的相关应用及数据量达到一定规模时，我们再为武汉市智慧医疗卫生信息系统规 划设计异地灾备中心。 4.5 数据中心采购清单 序 单 数 备 货物名称 规格型号 产品描述 号 位 量 注 主机系统 8路3.2 GHz POWER7 CPU,64G内存，2*300G硬盘，2块双 核心应用服务器及核 口千兆网卡，2块4GB HBA，DVD－ROM,冗余电源，AIX6.1 1 IBM P750 台 2 心数据库服务器 操作系统，HA双机集群软件,两台机器包含一套HMC管 理控制台，TF3，T42机柜（含PDU电源模块） 4颗E7-4820 2.00GHz（8C),128G内存，ServeRAID M5015 2 综合应用服务器 IBM 3850X5 阵列卡，2块300G SAS硬盘，2块4GB HBA,双端口千兆以 台 4 太网，DVD光驱，冗余电源，风扇 Internet 区域 Web 服 2颗 Intel(R) Xeon(R) Processor E5620 2.40GHz（4C),12G内 3 IBM HS22 台 1 务器 存，2块300G SAS硬盘，双口千兆网卡 Internet 区域 数据库 2颗 Intel(R) Xeon(R) Processor E5620 2.40GHz（4C),12G内 4 IBM HS22 台 1 服务器 存，2块300G SAS硬盘，双口千兆网卡 5 备份服务器 IBM HS22 2颗 Intel(R) Xeon(R) Processor E5620 2.40GHz（4C),12G内 台 1 63存，2块300G SAS硬盘，双口千兆网卡 2颗 Intel(R) Xeon(R) Processor E5620 2.40GHz（4C),12G内 6 认证服务器 IBM HS22 台 1 存，2块300G SAS硬盘，双口千兆网卡 系统管理及病毒防护 2颗 Intel(R) Xeon(R) Processor E5620 2.40GHz（4C),12G内 7 IBM HS22 台 1 服务器 存，2块300G SAS硬盘，双口千兆网卡 2颗 Intel(R) Xeon(R) Processor E5620 2.40GHz（4C),12G内 8 数据交换服务器 IBM HS22 台 2 存，2块300G SAS硬盘，双口千兆网卡 刀片机箱，9U高，支持14个刀片，内置2个BNT Layer 2/3 9 刀片服务器机箱 IBM BCH 台 1 交换机模块，4个冗余电源及风扇 1U 17in Flat Panel Monitor Console Kit w/o keyboard/IBM 1 KVM IBM 8口KVM Local 1x8 Console Manager (LCM8)/IBM USB Conversion 台 3 0 Option Pack 存储和备份系统 双控制器，支持FC及ISCSI 端口，16GB缓存，支持多种 RAID功能，包括 RAID 0 ,1 ,3,5,10的功能；配置双冗余电 11 在线存储设备 IBM V7000 台 1 源，配置10T容量（17块600G SAS 硬盘),支持快照等功 能/5 m Fiber Optic Cable LC-LC*8 12 SAN 交换机 IBM 2498-B24 24个8Gb/s的光纤交换接口，当前激活16口 8Gb SFP 台 2 Storbridge C5562 存储产品，12盘位，冗余控制器，配置双 控双活许可，配置IP SAN 及NAS许可 ，16G缓存，最大支 持96GB缓存，支持SAS/NL SAS/SSD磁盘，支持 13 近线存储 圣桥 C5562 RAID0/1/10/5/6热备盘，配置8个GbE主机端口，冗余电 台 1 源,机架式/圣桥 Storix 嵌入式操作系统软件 V3.0/圣桥 Storbridge 网络存储管理软件V2.0/圣桥SAS专用热插拔 磁盘 2TB 7200rpm*24/C5000系列扩展磁盘柜 12盘位*1 配置2个LTO4 FC驱动器磁带库，24盘LTO4磁带，1盘清 14 磁带库 IBM TS3100 台 1 洗带/13m LC/LC Fibre Channel Cable*2 支持IBM AIX，HP-UX，Sun Sloaris，SGI IRIX，Linux以及MS SYMC Windows等操作系统环境，基于SAN备份方式，支持全 NETBACKUP 15 备份软件 量、增量和差量备份；支持对大量小文件高效备份；支持 套 1 ENTERPRISE 数据库的在线和离线备份；可同时写入多份磁带及磁盘； SERVER 7.5 可进行磁盘物理数据块的快速备份，并能恢复单个文件。 网络安全运维系统 64中网防火墙 提供4个千兆电口、4个千兆多模光口,防火墙并发连接数 16 边界防火墙 台 3 EX-560 可达到300万，吞吐量可达4 Gbps。 机架式独立IDS硬件设备， 2U标准机型，全内置封闭式 结构，具有完全自主知识产权的专用安全操作系统，稳定 绿盟NIDS 1200 可靠。1个RJ45串口，配置4个1000M工作接口和4*SFP 17 入侵检测系统 台 1 Series 插槽，标配两路监听，可以扩展到8路监听。检测能力 ≤1.2Gbps；最大并发TCP会话≤100万；每秒新增TCP≤30 万；最大包处理能力≤100万pps；最大策略数：4,000 绿盟极光远程 最大允许并发扫描30个IP地址以上，一分钟内可扫描IP 18 漏洞扫描设备 安全评估系统 台 1 数为5个以上 RSAS-S 19 网络防病毒系统 SEP12.1 网络防病毒系统企业版,100个客户端+1个服务器端 套 1 杭州安恒网站 网站防篡改系统，能有效保护门户网站的安全，提供多钟 20 网站防篡改系统 套 1 卫士系统软件 恢复及告警手段，含2服务器许可 NetScout nGenius Performance Manager Workgroup Professional - Licensed for use with up to 10 Type 1 NetScout interfaces and 2,000 Type 2 interfaces. 21 网络流量监控 9500W- nGenius InfiniStream, 台 1 WG+1906/GS 2-Port 10/100/1000Base-T, 1TB，High Capacity 分布式硬件探针架构,有效监控网络数据中心内部流量， 及时发现网络问题,保障网络性能。 2U硬件，4个千兆电口接入，含专用操作系统与上网行为 管理标准软件，能够分析多种的应用层协议，支持基于时 间、用户、协议、内容等多种条件组合的信息审计策略，对 22 网络审计系统 网康NI5000-10 台 1 邮件收发（WEBMAIL、SMTP、POP3）、文件上传下载 （HTTP、FTP）、论坛、即时通讯等进行全面信息审计，提供 实时告警等功能 24个10/100/1000Base-T,4个100/1000Base-X Combo口, 23 安全交换区交换机 华为S5700 台 2 交流供电 核心数据区核心交 S9706总装6槽机箱，主控单元板配置1块24口千兆光 24 华为S9706 台 2 换机 口板及1块48口千兆电口板，冗余电源 25 负载均衡设备 Radware 4008 6个千兆电口，2个千兆光口，4GB的处理能力 台 2 游龙SiteView 26 网管软件 支持SNMP协议，能管理主流的服务器及网络设备 套 1 网络管理系统 系统及平台软件 65Windows 2008 MS Windows Srv 2008 R2 Enterprise (1-8 CPU, 10 CAL) ROK- 27 操作系统 1 套 4 企业版 Chinese Simp Windows 2008 MS Windows Srv 2008 R2 Standard (1-4 CPU, 5 CAL) ROK - 28 操作系统 2 套 7 标准版 Chinese Simp MS SQL 2008 标 29 数据库软件 MS SQL Server 2008 R2 CAL (5 user) 套 1 准版 30 J2EE中间件 IBM Webshpere WebSphere Application Server(2CPU 许可) 套 1 统计分析和报表工 SAP Business Objects Edge BI, version data integration 10 31 SAP BO套件 套 1 具 用户许可 VMware 32 虚拟化软件 vSphere 5 企业 VMware vSph5 EntPlus 16CPU许可（企业增强版） 套 1 版 Plus 665.项目需求 3-软件功能设计 5.1 市级卫生信息平台建设 5.1.1 注册服务系统 5.1.1.1 总体概述 注册服务主要是对个人、医疗卫生人员、医疗卫生机构、医疗卫生术语字典、 医疗药品、医疗设备等卫生信息平台的基础数据提供注册管理服务。 5.1.1.2 业务需求分析 5.1.1.2.1 业务需求  个人注册服务 个人注册服务分两部分，其一是门户网站注册，其二是平台注册。 门户网站注册服务，是居民通过市卫生局门户网站进行注册，形成一个个人 注册库并分配一个唯一的标识，提供给居民查询健康信息用。 平台注册服务，是指在一定区域管辖范围内，形成一个个人注册库，个人的健 康标识号、基本信息被安全地保存和维护着，提供给区域卫生信息平台所使用， 并可为医疗就诊及公共卫生相关的业务系统提供人员身份识别功能，该注册服务 主要由各医院、社区和公共卫生机构来使用，完成居民的注册功能。 平台对门户网站注册的居民和平台内的居民信息进行合并，合并后居民就可 以登录平台查询自己的健康信息。  医疗卫生人员注册服务 医疗卫生人员注册服务，是一个单一的目录服务，为本区域内所有卫生管理 机构的医疗服务提供者，包括全科医生、专科医生、护士、实验室医师、医学影像 67专业人员、疾病预防控制专业人员、妇幼保健人员及其他从事与居民健康服务相 关的从业人员，系统为每一位医疗卫生人员分配一个唯一的标识，并提供给平台 以及与平台交互的系统和用户所使用。 各医院、社区和公共卫生机构提供所辖医疗卫生人员基础信息给医政，医政 完成审核并将这些医疗卫生人员信息在平台上给予注册。  医疗卫生机构注册服务 医疗卫生机构注册服务，提供本区域内医疗机构的综合目录，相关的机构包 括二三级医院、社区卫生服务中心、疾病预防控制中心、卫生监督所、妇幼保健所 等，系统为每个机构分配唯一的标识，可以解决居民所获取的医疗卫生服务场所 唯一性识别问题，从而保证在维护居民健康信息的不同系统中使用统一的规范化 的标识符，同时也满足区域卫生信息平台层与下属医疗卫生机构服务点层的互联 互通要求。 医疗卫生机构注册服务主要由医政（卫监）来使用，完成医疗卫生机构的注册  医疗卫生术语字典注册服务 医疗卫生术语和字典注册服务，是用来规范医疗卫生事件中所产生的信息含 义的一致性问题。术语可由平台管理者进行注册、更新维护；字典既可由平台管 理者又可由机构来提供注册、更新维护。。  医疗药品注册服务 医疗药品注册服务，是用来规范诊疗过程中所使用的药品，实现新医改推进 医药分开，逐步解决“以药养医”问题的关键，同时实行药品目录注册功能，也 满足药监局对于药品管理的需要。药品目录注册服务将由卫生局会同药监局、医 保局共同管理，进行注册、更新维护。  医疗设备注册服务 医疗设备注册服务，是用来实现医疗设备的统一管理，做到全市范围内的资 源整合，同时从医管局角度也可以对下属医院的医疗设备做到充分管理，最大程 度地避免了设备的重复配置，提高资源的使用率。 5.1.1.2.2 用户角色分析 本期注册服务系统面向居民、医疗卫生机构、医疗卫生人员、卫生局。 685.1.1.2.3 业务流程图 ①个人注册流服务流程图 ②医疗卫生人员、医疗设备注册流程图 ③医疗卫生机构、医疗卫生术语字典、医疗药品注册流程图 695.1.1.3 功能需求分析 注册服务主要是对个人、医疗卫生人员、医疗卫生机构、医疗卫生术语字典、 医疗药品、医疗设备等卫生信息平台的基础数据提供添加、修改、删除、查询、审 核、注销操作功能。 5.1.1.3.1 个人注册服务 ①门户网站注册服务 个人门户网站注册中所涉及的服务组件有： 个人门户网站注册操作 描述 注册新人服务 添加一个新的个人信息 更新个人信息服务 根据个人ID更新其它信息 获取个人健康信息服务 根据个人ID返回个人在平台内的健康信息 ②平台注册服务 个人平台注册中所涉及的服务组件有： 个人平台注册注册操作 描述 查询居民信息服务 根据部分信息查找个人 获取个人ID服务 根据所有符合要求的个人信息返回个人ID 70注册新人服务 添加一个新的个人信息 更新个人信息服务 根据个人ID更新其它信息 个人身份匹配服务 根据模糊身份匹配算法，对数据中心个人身份进行合并 5.1.1.3.2 医疗卫生人员注册服务 卫生人员注册中所涉及的服务组件有： 医疗卫生人员注册操作 描述 查询卫生人员信息服务 根据部分信息查找卫生人员 获取卫生人员ID服务 根据所有符合要求的人员信息返回卫生人员ID 注册卫生人员服务 添加一个新的卫生人员信息 更新卫生人员信息服务 根据卫生人员ID更新其它信息 注销卫生人员服务 根据卫生人员ID注销卫生人员 审核卫生人员服务 根据卫生人员ID审核卫生人员 5.1.1.3.3 医疗卫生机构注册服务 卫生机构注册中所涉及的服务组件有： 医疗卫生机构注册操作 描述 列出卫生机构场所服务 根据条件返回满足要求的列表 查询卫生机构服务 根据部分信息查找机构 获取卫生机构ID服务 根据所有符合要求的信息返回机构ID 注册卫生机构服务 添加一个新的卫生机构 更新卫生机构信息服务 根据机构ID更新其它信息 注销卫生机构服务 根据卫生机构ID注销卫生机构 审核卫生机构服务 根据卫生机构ID审核卫生机构 5.1.1.3.4 医疗卫生术语字典注册服务 卫生术语字典注册中所涉及的服务组件有： 医疗卫生术语字典注册操作 描述 查询卫生术语字典服务 根据部分信息查找卫生术语字典 获取卫生术语字典ID服务 根据所有符合要求的信息返回卫生术语字典ID 注册卫生术语字典服务 添加一个新的卫生术语字典 更新卫生术语字典信息服务 根据机构ID更新其它信息 注销卫生术语字典服务 根据卫生术语字典ID注销卫生术语字典 审核卫生术语字典服务 根据卫生术语字典ID审核卫生术语字典 715.1.1.3.5 医疗药品注册服务 药品注册目录注册中所涉及的服务组件有： 药品注册操作 描述 列出药品服务 根据条件返回满足要求的药品详细信息 查询药品服务 根据部分信息查找药品信息 注册药品服务 添加一个新的药品详细信息 更新药品信息服务 根据药品ID更新其它信息 审核药品服务 根据药品ID审核药品 5.1.1.3.6 医疗设备注册服务 医疗设备注册中所涉及的服务组件有： 医疗设备注册操作 描述 列出医疗设备服务 根据条件返回满足要求的医疗设备详细信息 根据医疗卫生机构ID查找该机构所拥有的医 查询医疗卫生机构的医疗设备服务 疗设备信息 注册医疗设备服务 添加一个新的医疗设备详细信息 根据医疗设备ID更新其信息，完成医疗设备诸 更新医疗设备信息服务 如报废、移机等操作 审核医疗设备服务 根据医疗设备ID审核医疗设备 5.1.2 存储服务系统 存储服务除了对POS和业务协同平台提供健康档案的访问服务，也承担将来 自POS和业务协同平台的业务文档按照健康档案的数据模型解析和封装为健康 档案文档。健康档案存储服务建议遵循IHE ITI XDS规范。 5.1.2.1 存储内容 健康档案存储服务是一系列存储库，用于存储健康档案的信息。根据健康档 案信息的分类，健康档案存储服务分为七个存储库：个人基本信息存储库、主要 72疾病和健康问题摘要存储库、儿童保健存储库、妇女保健存储库、疾病控制存储 库、疾病管理存储库以及医疗服务存储库。 5.1.2.2 存储构成 基于健康档案的区域卫生信息平台中存在三种类型的数据，文档数据、操作 型数据、数据仓库数据，分别存在文档库、ODS库和数据仓库中，本次方案参考国 际标准的通用EHR存储模型，以支持EHR的灵活扩展。 5.1.2.2.1 文档库 EHR文档库是存储客户端上传的原始文档信息，是结果数据，其信息内容主 要是CDA的原始文档。这些文档要求保留和客户端上报格式完全一致未经修改 的数据，作为文档档案备份存储，在以后发生任何疑问时，可调阅此文档进行核 实。此文档要求在存储后不能被修改和删除，他将作为系统的原始凭证被永久保 留。 EHR存储以技术手段分类主要由索引存储、数据库存储、文件存储构成。索引 存储是以索引文件的方式进行存储，其具体表现为以目前的搜索方式组织的文件 存储，在实际运行过程中，将频繁调用的索引将被加载在内存中，减少磁盘读写 频率；数据库存储是当前最常用的存储方式，采用目前主流的大型数据库存储方 式，主要存储已经被结构化的数据，这些数据将被迅速定位统计，ODS库主要以 此方式进行存储；文件存储是以文件系统方式对EHR中文档、影像信息进行存放 文件存储可以减少数据库存储中其他多余的运算和磁盘开销，直接依赖文件系统 提高EHR中心对大容量数据的吞吐能力。 5.1.2.2.2 ODS库 EHR数据库的组织形式以个人健康档案为核心展开，其存储结构方式更多的 以个人基本索引模式组织展开，以结果数据为主体，这样的组织形式在以个人视 角所见的健康档案中能够完整迅速的定位，但对纵向条线业务的支持却明显缺乏 有力的索引组织，不能完全满足业务的需求。所以很多业务数据并不都在EHR数 73据库中存储，为了完成某些特定业务上的流程要求，可能产生很多中间数据，而 这些中间数据都有赖ODS数据库实现其存储方式。 ODS数据库（操作型数据库）主要是作为EHR存储外的业务需求的补充。除了 EHR信息外，在EHR数据中心还需要支持一些其他业务，比如说CDC的疾病健康 妇幼所的围产保健等具体医疗业务，这些业务所需的一些信息可以从EHR中抽 取，但是同时另一部分信息可能和健康信息毫无关系只是为业务统计分析时使用 他们也有一定的业务流程，辅助存储就是为此类数据的存放场所。 ODS数据库还包含对这些业务数据的汇总、展现、统计功能的支持，他不仅 仅是一个单纯的存储服务，他可以依赖健康档案全程索引服务实现共享和使用 EHR信息中已经存储信息的展示。 ODS数据库既可以被用来针对工作数据做决策支持，又可用做将数据加载到 数据仓库时的过渡区域。与EDW相比较，ODS有下列特点：ODS是面向主题和面 向综合的；ODS是易变的；ODS仅仅含有目前的、详细的数据，不含有累计的、历 史性的数据。 5.1.2.2.3 数据仓库 数据仓库提供用户用于决策支持的当前和历史数据，这些数据在传统的操作 型数据库中很难或不能得到。数据仓库技术是为了有效的把操作形数据集成到统 一的环境中以提供决策型数据访问，的各种技术和模块的总称。所做的一切都是 为了让用户更快更方便查询所需要的信息，提供决策支持。 数据仓库由三个部分组成：数据仓库数据库、数据抽取工具和数据挖掘工具。  数据仓库数据库：是整个数据仓库环境的核心，是数据存放的地方和提供对 数据检索的支持。相对于操纵型数据库来说其突出的特点是对海量数据的支持和 快速的检索技术。  数据抽取工具：把数据进行必要的转化、整理，再存放到数据仓库内。数据转 换都包括，删除对决策应用没有意义的数据段；转换到统一的数据名称和定义； 计算统计和衍生数据；给缺值数据赋给缺省值；把不同的数据定义方式统一。  数据挖掘工具：数据挖掘工具利用数据仓库中的大量数据中获取有效的、新 74颖的、潜在有用的、最终可理解的模式的过程。 此平台的数据仓库模块将会通过第三方成熟产品实现，只需要定制数据抽取 工具的接口。数据抽取工具将会直接使用Data Service、LDS和Registry Service的 Web Service接口，通过他们读取所需的数据，通过数据抽取工具的整理之后，存 入数据仓库数据库。对于数据的分析将直接面向数据仓库数据库中的数据，对中 心其他服务的运行没有影响。 对于数据的挖掘功能，开发运营人员可以使用成熟产品中数据挖掘工具，制 定相应分析模型，通过数据挖掘工具的报表和图形功能来读取结果，或者继续调 整模型来得到更准确的结果。 1、数据仓库的类型 数据仓库的类型根据数据仓库所管理的数据类型和它们所解决的企业问题 范围，一般可将数据仓库分为下列3种类型：企业数据仓库（EDW）、操作型数据 库（ODS）和数据市集（DataMart）。 企业数据仓库为通用数据仓库，它既含有大量详细的数据，也含有大量累赘 的或聚集的数据，这些数据具有不易改变性和面向历史性。此种数据仓库被用来 进行涵盖多种企业领域上的战略或战术上的决策。 操作型数据库既可以被用来针对工作数据做决策支持，又可用做将数据加载 到数据仓库时的过渡区域。与EDW相比较，ODS有下列特点：ODS是面向主题和 面向综合的；ODS是易变的；ODS仅仅含有目前的、详细的数据，不含有累计的、 历史性的数据。 数据市集是数据仓库的一种具体化，它可以包含轻度累计、历史的部门数据， 适合特定企业中某个部门的需要。几组数据市集可以组成一个EDW。随着数据仓 库发展的需求，软件工具升级相当快，新产品也层出不穷。为了便于追踪其技术 发展和更好地选择相关的工具，数据仓库的构造者应该广泛地收集这方面的文件 和数据，以便做出最佳的选择。 为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据， 也可称为部门数据或主题数据（subjectarea）。在数据仓库的实施过程中往往可以 75从一个业务的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库。 需要注意的就是再实施不同的数据集市时，同一含义的字段定义一定要相容，这 样再以后实施数据仓库时才不会造成大麻烦。 2、数据仓库处理方法 ETL是从EHR-Storage中攥取数据以及存储数据的底层数据服务，他负责按照 一定频度将EHR的物理存储中的实际数据保存入最后的数据仓库中的多维数据 模型中，这些源存储可能是文件存储、数据库存储也可能是索引存储中。其转储 频度根据数据仓库的实际需求而定，原则上以不影响EHR存储的正常操作为底 线。 5.1.2.3 健康档案存储处理流程 区域卫生信息平台涉及到与居民健康相关的所有业务，因此其业务数据具有 类型多、容量大的特点。根据业务数据的特点，对数据存储的要求也不尽相同。系 统架构与数据存储的模式分为集中式、分布式和混合式。 EHR数据库存储处理有集中存储和分布存储两种模式，集中存储是在统一的 EHR中心对EHR范围内的数据进行统一存放，此方式主要以文档性数据为主；分 布存储是在EHR中心考虑其存储容量以及网络带宽情况，对大文件内容以及无 法结构化且调用频度很低的健康档案内容采用的存储方式，中心对这些文件的位 置以及主要属性信息进行索引存储，而不在EHR中心存储其实体数据，需方在进 行调用时，通过数据中心索引寻找其文件位置，然后加载到EHR中心，再提供给 内容需求方使用，影像数据、语音数据等大容量文件建议采取此种存储方式。 5.1.2.3.1 集中存储处理流程 集中存储的模式是在EHR库中对数据实体进行统一存储的方式，所有的数据 实体除了在POS端有其数据实体外，在EHR库也保存其一份备份信息，此模式适 合单体数据较小的数据存储，如诊疗过程中的门诊诊断、门诊医嘱等文字性描述 信息。这些数据通过POS系统，推送到EHR平台中，EHR平台对其进行初步的加 工后（对其进行数据格式转换和人员定位），将其存入EHR存储中，按照其EHR的 76要求建立索引存储和文档存储，如果数据是以无格式的文档形式报送的，EHR存 储原则上按照文件存储的模式进行存放，如果是以有格式的文档形式报送的， EHR存储采用结构化的数据库存储方式进行存放。这些数据都存放在EHR存储本 地，以后其他的POS调用，平台只需要从EHR本地存储中获取这些文档实体，无 需依赖报送POS进行路由调用。 5.1.2.3.2 分布存储处理流程 分布存储的模式是在EHR库中对只对数据实体分布的地址信息以及关键字 段信息进行索引存储，不在中心对数据实体数据再次存储。当需求POS端需要调 用其实体数据时，首先由寻址服务通过其地址存储得到其实际存储的物理位置， 通过HIAL从实际物理存储的POS中将数据拉到EHR中心，再推送给需求POS方。 需求POS方在整个过程中并不需要知道其实际的物理存储地址，所有的操作都 在EHR中心完成，其形式同集中存储一样。这种存储方式依赖于数据物理存储的 POS端，如果在物理存储的POS端对其数据进行删除或变更后将无法保证这些数 据能够一定被调用。 分布存储的存储模式适合如影像文件、语音文件等并不需要被频繁调或需参 加到业务处理的大容量数据，同时一些如病程录等主观信息也可以采用此种方式 存储。这些数据将在EHR存储中保留其索引信息、地址信息等关键信息，这样的 存储方式可以让系统减少网络的要求以及中心存储空间的要求，降低EHR中心 的造价。 5.1.3 共享协同服务系统 健康档案信息共享和业务协同服务提供了医疗卫生机构之间的信息共享服 务。 5.1.3.1 个人基本信息域 个人基本信息域对外提供个人基本信息共享服务，其提供的主要服务组件如下： 77个人基本信息域服务操作 描述 查询个人基本信息服务 根据个人ID查找并返回对应的基本信息 5.1.3.2 主要疾病和健康问题摘要域 主要疾病和健康问题摘要域是区域卫生信息平台中的一个核心部件，它将 所有与个人健康相关基础摘要信息进行汇集、存储、并对外提供服务。主要疾病 和健康问题摘要域在区域卫生信息平台中主要包含以下内容：血型、过敏史、慢 病信息等，这些的摘要信息汇集不是从某个基础业务系统中单独获取，而是从 众多的基础业务系统中抽取汇集而成。摘要域的主要服务方式是为医疗卫生人 员提供一种通用的、及时的、可信的调阅服务，为医疗卫生人员在进行医疗卫生 服务时能够及时、快捷的了解患者、居民基础健康信息提供一种技术支撑。 主要疾病和健康问题摘要域提供的服务组件如下： 主要疾病和健康问题服务操作 描述 查询主要疾病和健康问题服务 根据个人ID查找对应的主要疾病和健康问题信息 5.1.3.3 儿童保健域 儿童保健域用于维护及管理区域妇幼机构、社区卫生服务中心、儿童医院、 幼托机构、计生委、民政局等机构所产生的儿童保健数据及提供的儿童保健服务 数据主要包括出生医学证明、新生儿疾病筛查、出生缺陷监测、体弱儿童管理、儿 童健康体检、儿童死亡管理等数据。 儿童保健域可以支撑儿童保健领域的业务协同，以及儿童保健域与其他 业务领域的业务协同，如根据出生医学证明可以触发新生儿访视和儿童计划 免疫服务。 儿童保健域提供的服务组件如下： 儿童保健服务操作 描述 单个儿童保健信息查询服务 根据个人ID查找对应的儿童保健信息 更新儿童保健服务 根据提交的儿童保健数据更新儿童保健档案 儿童保健查询服务 支持多条件查询，例如年龄段、疾病名称、缺陷 78名称等，返回批量信息 5.1.3.4 妇女保健域 妇女保健域用于维护及管理区域妇幼机构、社区卫生服务中心、助产医 院、计生委、民政局等机构所产生的妇女保健数据及提供的妇幼保健服务。数 据主要包括妇女婚前保健、计划生育、妇女病普查、孕产妇保健服务及高危管 理、产前筛查与诊断、孕产妇死亡报告等数据。 妇女保健数据体现了数据间的联动性，如妇女在三级医院发现自己怀孕 后，需要三级医院将怀孕数据及时传送到妇女所在的社区卫生服务中心及区 妇幼保健所，由社区卫生服务中心的防保医生提供产前保健服务，社区服务中 心也需将此产前保健数据传送给妇女生产医院，生产医院将妇女产前检查、分 娩数据传送回社区卫生服务中心，社区卫生服务可获知妇女分娩并及时上门 进行产后访视服务。 妇女保健域提供的服务组件如下： 妇女保健服务操作 描述 单个妇女保健信息查询服务 根据个人ID查找对应的妇女保健信息 更新妇女保健服务 根据提交的妇女保健数据更新妇女保健档案 妇女保健查询服务 支持多条件查询，例如年龄段、产前诊断、孕妇 死亡等，返回批量信息 5.1.3.5 疾病控制域 疾病预防控制域用于维护和管理区县 CDC、社区卫生服务中心、二三级 医院、地市CDC所产生的突发公共卫生事件应急处置和日常业务管理（人群 健康的疾病预防控制级监测、干预、评估）数据及各种服务。突发公共卫生事 件应急处置数据是针对事件处置的全过程管理数据，日常业务管理数据是针 对人群的疾病健康预防和控制的数据。 数据主要包括免疫接种、传染病报告、结核病防治、艾滋病综合防治、血吸 虫病病人管理、职业病报告、职业性健康监护、伤害监测报告、中毒报告、行为 79危险因素监测、死亡医学登记。 数据着重体现了过程性及联动性，即区域内各个医疗机构（CDC、医院、 社区卫生服务中心）形成紧密的卫生业务联动，如某社区的居民在市级三级 医院发现传染病，需要市级三级医院形成传染病管理报告卡，并将报告卡数 据传送到居民所在的社区卫生服务中心及区CDC，区CDC负责审核报告卡， 社区卫生服务中心的防保医生进行上门确认及随访，区CDC审核随访数据。 疾病控制域提供的服务组件如下： 疾病控制服务操作 描述 单个病人信息查询服务 根据个人ID和病种信息查找对应的疾病控制档案信息 更新疾病控制档案服务 根据提交的疾病控制数据更新疾病控制档案 疾病控制档案查询服务 支持多条件查询，例如年龄段、病种等，返回批量信息 5.1.3.6 疾病管理域 疾病管理域用于维护和管理区县CDC、社区卫生服务中心、二三级医院、 地市CDC所产生的疾病管理数据及各种服务。 数据主要包括高血压病例管理、糖尿病病例管理、肿瘤病例管理、精神分 裂症病例管理、老年人健康管理。 数据着重体现了过程性及联动性，即区域内各个医疗机构（CDC、医院、社 区卫生服务中心）形成紧密的卫生业务联动，如某社区居民在市级三级医院发 现糖尿病，需要市级三级医院马上形成糖尿病管理报告卡，并将报告卡数据传 送到居民所在的社区卫生服务中心及区CDC，区CDC负责审核报告卡，社区卫 生服务中心的防保医生进行上门确认及随访，区CDC审核随访数据。 疾病管理域提供的服务组件如下： 疾病管理服务操作 描述 单个病人信息查询服务 根据个人ID和病种信息查找对应的疾病管理信息 更新疾病管理服务 根据提交的疾病管理数据更新疾病管理档案 疾病管理查询服务 支持多条件查询，例如年龄段、病种等，返回批量信息 805.1.3.7 医疗服务域 医疗服务域是用于临床信息共享和医疗业务协同的，包括诊断信息域、药品 处方域、临床检验域、临床检查域和医学影像域。 5.1.3.7.1 诊断信息域 诊断信息域系统——也被称为临床诊断信息系统。临床诊断信息系统记 录患者的临床表现和诊断信息，提供完整的诊断记录，并为医生开处方和医 技医嘱提供支持服务。区域卫生信息平台诊断信息域服务支持用户通过药品 处方或医技医嘱提取患者临床表现和诊断并进行显示。 诊断信息域提供的服务组件如下： 诊断信息服务操作 描述 获取诊断服务 获取诊断的详细信息 诊断列表服务 允许根据如下标准查询和提取患者的医嘱列表： 客户ID、医嘱类型、诊断代码、日期范围、服务场所、诊断 医师 获取完整记录 这是一个扩展功能，允许在本域中提取某个患者的完整 记录。将返回几种类型的数据结构，打包成单一的消息。 查询条件包括客户ID、日期范围、上次提取记录书签和 页码值。 诊断统计服务 统计某诊断的出现次数及分布情况 疾病信息查询 为医生提供某疾病特征的查询服务 5.1.3.7.2 药品处方信息域 药品处方域系统——也被称为药物信息系统。药物信息系统记录处方和 药物治疗信息，提供完整的患者用药记录，并为医师开处方和调配药物提供决 策支持服务。区域卫生信息平台药品处方域服务支持用户通过药品处方域存 储服务提取患者临床数据并显示。 药品处方信息域提供的服务组件如下： 药品处方信息服务操作 描述 81处方调配列表 查找一个具体处方（为一个患者）的所有调配记录 调配记录列表 查找指定时间段内给一个患者调配、发出了什么药 品。也称为患者调配药品查询。 获取调配详细信息 指定药物调配的详细信息，包括注记。 获取处方汇总 提供患者所有已调配处方的列表 获取处方 通过处方序号来获取一个指定处方的具体信息，调 配不包括在内。 获取药物治疗的详细信 对于指定患者，列出其所有未分装的处方、已经给 息 出医嘱且部分或全部分装完成的处方、其他正在进 行的药物治疗信息、没有处方的发药信息。重点是 处方的完整详细信息。 获取药物概况 对于指定患者，列出其所有未分装的处方、已经给 出医嘱且部分或全部分装完成的处方、其他正在进 行的药物治疗信息、没有处方的发药信息。重点是 处方的汇总信息。 获取其他用药情况详细 获取患者其他正在进行的药物治疗信息 信息 获取完整药品使用记录 这是一个扩展功能，允许在药物域中提取某个患者 的完整用药记录。将返回几种类型的数据结构，打 包成单一的消息。查询条件包括客户ID、日期范围、 上次提取记录书签和页码值。 5.1.3.7.3 临床检验信息域 临床检验信息域系统——也被称为区域实验室信息系统，是一个管理患 者检验申请单和向临床医师发布患者检验结果的区域系统。在不同的卫生管 理区域，实验室域系统可采取各种不同的形式和规模。关键在于要将浏览检验 结果的解决方案与为了获得结果而涉及的与医嘱信息相关的一系列支持数据 的解决方案的区别开来。 可以汇总化验结果及伴随数据（如之前的医嘱），这样可以向医疗卫生人 员提供结果汇总信息视图。在最简单的状态下，检验域系统会自动从源系统中 采集检验相关事件，如申请、标本、检验结果，并且允许基于标准消息查询这 些数据以提取其中的任何信息。更先进的解决方案除提供这些基本功能外，也 将支持流程自动化和申请及结果生成状态的管理，同时也会以一个更加积极 82的方式与源系统交互，生成警告和通知，以加快处理。 检验信息域服务通过基于标准的消息与产生和管理申请的实验室系统 进行交互，同时也与系统中用以产生结果的采样和检测机构进行交互。换句 话说，实验室机构内的医师用户和实验技师用户使用其本地信息系统解决方 案进行其工作。这些应用系统，通过与信息平台相连接，能把关键相关结果数 据发布或提升到患者的电子健康记录中。 检验信息域提供的服务组件如下： 检验信息服务操作 描述 获取检验医嘱服务 获取某检验医嘱的详细信息 获取检验报告服务 获取某次检验的报告信息 医嘱列表服务 允许根据如下标准查询和提取患者的医嘱列表：客户ID、 医嘱类型、检验项目、日期范围、服务场所、申请医师 检验列表服务 允许如下检索标准查询和提取患者的检验列表：客户ID、 文档类型：标本、诊断、日期范围、服务场所、申请医师。 此查询的相关元数据包括：检验日期、检验项目、标本类 型、操作代码 获取完整记录 这是一个扩展功能，允许在本域中提取某个患者的完整 记录。将返回几种类型的数据结构，打包成单一的消息。 查询条件包括客户ID、日期范围、上次提取记录书签和页 码值。 5.1.3.8 服务实现方式要求 对上述信息共享与业务协同服务的描述方式，文档参照了国家卫生部相 关标准的分类方式。 需要补充说明的是，项目在具体实现时，应考虑用户在进行数据共享请求 和业务协同服务数据请求时基本都不是针对单一数据域进行数据请求的。因 此在实际对用户提供相应的数据查询、数据更新、信息订阅服务时，应主要考 虑采取根据用户实际操作要求，通过以个人基本信息为主线对用户请求的相 应数据域进行综合处理，最终提供用户一个符合其要求的统一完整的息共享 与业务协同服务接口。 83提出上述需求主要目的是：在实际工作中避免出现，基层用户在调用相应 接口后还需要自己重新对信息进行再次组织的情况发生。 5.1.4 全程诊疗档案服务系统 所有到区域卫生信息平台中访问数据的事务希望由全程健康档案服务进行 处理。全程健康档案服务是区域卫生信息平台中唯一一个知晓所有的事务和业务 逻辑以及数据访问规则的部件，所以它可以围绕任何数据主题汇集出真正的全程 和综合的健康档案视图。 5.1.4.1 索引服务 索引服务全面掌握区域卫生信息平台所有关于居民的健康信息事件，包 括居民何时、何地、接受过何种医疗卫生服务，并产生了哪些文档。索引服务 主要记录两大类的信息，一是医疗卫生事件信息，另一为文档目录信息。 区域卫生信息平台用户在被授权的情况下，可以通过全程健康档案服务提供的索引 服务从基本业务系统查看某居民的健康事件信息，以及事件信息所涉及的文档目录及摘 要信息。再结合健康档案数据存储服务可以实现文档信息的即时展示，使用户更多的了 解居民（患者）既往的健康情况，为本次医疗服务提供相应的辅助参考作用。 索引服务操作 描述 单个病人索引查询服务 根据个人ID查找对应的事件目录和文档目录信息 索引更新服务 根据提交的健康档案数据更新索引 索引查询服务 支持多条件查询，例如时间、事件类型、文档类型等，返 回批量信息 5.1.4.2 业务服务 这个组件由处理健康档案数据访问事务的服务组成。这些服务被组合在一起 84建立一个以处理和管理这些健康档案访问事务的场景。这是区域卫生信息平台内 协调和执行事务的唯一地点，其中需要涉及区域卫生信息平台里的多个服务和系 统、或需要访问其他区域卫生信息平台的事件。这一组件中的服务管理着区域卫 生信息平台中事务的全局性表示、编排流、响应组装、业务规则应用以及与区域 卫生信息平台的各类其他系统或服务的数据访问。业务联动的众多需求则需要本 业务服务组件来配合实现。包括的主要服务组件有： 一个平台互联互通规范的执行可能包括调用不同的组件生 1. 组装服务 成多个结果集。组装服务将把这些结果集一起组合成一定输 出格式。这些服务将使用组合模板的方式来实现这些功能. 这些服务管理注册、存储和提取，更重要的是各类处理流程 的编排协同。编排服务是驱动事务执行的引擎。它知道服务 2. 编排服务 产生的步骤，知道怎样为了触发和管理每一步并行或串行实 现而调用服务。 业务规则服务组件是由细颗粒的验证和逻辑处理规则对象 的采集器，它在运行期间进行组合以执行适用于正在被处理 3. 业务规则服务 的特定类型的平台互联互通性事务的业务逻辑。这些业务规 则可以被硬编码（指作为程序代码）进入域业务组件或者可 以通过业务规则服务动态的使用。 这些服务是在平台互联互通性执行的语境中被调用以转换 成不同形式下描述的数据。典型地，这个服务常用于应用标 4. 标准化服务 准，把特定的输入串修改成符合标准化基础的编码串。数据 的格式和实质含义都可以转换。特殊的逻辑和编码表常用于 完成这种转化。 用于跟踪和监控区域卫生信息平台里的数据质量。因为区域 卫生信息平台的数据是用于研究、监测和进行临床决策的， 跟踪区域卫生信息平台内部信息质量水平的能力是一个必 5. 数据质量服务 须的特性。这些服务能用于支持人工数据质量评估处理，将 来甚至发展到完全自动的数据质量指标评估。例如：某些指 标可以从监控应用业务逻辑算法的结果中得到。 855.1.4.3 数据服务 这些服务为健康档案业务服务提供功能性的支持，以执行正确的数据访问过程和与不 同的注册服务、存储服务、业务管理或辅助决策服务交互所需的转换。 在现有的区域卫生信息平台内的系统或数据库之间 1. 复制服务 提供数据复制功能。 数据仓库服务管理从不同的存储库中抽取和插入数 据，经过抽取、转换和装载等加工处理后，提供生成 2. 数据仓库服务 区域卫生信息平台范围内使用的各种数据分析利用 资源。 当数据访问来自不同数据源时，会出项这样的情 况，即某个主索引键或次索引键在源系统间不唯一 3. 键值管理服务 或不存在。键值管理服务将在健康档案存储库插入 和更新操作期间生成和管理这些键值。 为不同的注册库、电子健康记录系统或辅助服务相 关的数据访问过程的正确调用提供支持。它存储着 4. 数据访问服务 有关数据结构和调用过程的元数据，以在运行 I-IPs 的语境中或数据维护类型过程中执行存储库的操 作。 1.1.1.1 事务处理 根据对事务的调用和处理，全程健康档案服务将配置成协调处理所有的 “列表”和“获取”事务。对于任何这些事务，将建立管理这些事务的语境， 将知晓如何调用一个特定的编排流，并指导编排流的执行，允许在实现这些事 务时调用适当的服务。典型的调用包括： 1.调用个人、医疗卫生人员和医疗卫生机构注册服务来鉴别每个实体，并 且在它们的使用过程中获得区域卫生信息平台内部标识符； 862.通过交换层服务去调用许可、加密、数字签名、访问控制、匿名访问或 其他任何服务，这些服务用于对事务的实现施加适当的控制； 3.调用平台定位服务，以确定特定居民的特定事务在不同区域存储服务可 能有数据的情况下，需要查询其他哪些区域卫生信息平台； 4.调用存储服务来执行特定平台互联互通规范时访问或获取数据； 5.通过交换层服务将子事务代理调用到存有客户相关数据的其他区域卫 生信息平台中； 6.通过交换层服务为正在执行的平台互联互通规范传递一个组合响应。 为了担当处理健康档案数据访问事务的核心，全程健康档案服务必须有 能力建立健康档案的完整视图。全程健康档案服务中的索引服务提供这一能 力。当全程健康档案服务处理事务时必须依赖索引服务，索引服务可以了解在 健康档案里存有哪些数据，并知道这些数据在参与到区域卫生信息平台中的 众多系统里的位置。当全程健康档案服务是索引服务所有者时，在索引服务里 全程健康档案服务也会提供一套特定的事务来管理、维护和使用索引数据。 集中处理复杂的复合事务时，全程健康档案服务是一个事务处理层，侧重 于处理复杂的混合事务，这些事务需要得到一个多域或多平台的信息视图。希 望大多数区域卫生信息平台数据访问事务获得这类能力，因为来自于注册服 务、访问和同意管理服务、并且常常一个或多个存储服务的数据必须结合在一 起才能实现一个请求。本质上，希望到达区域卫生信息平台的更新或“PUT” 事件对于单一的域是特定的并被限制在处理该域的一个数据存储服务组件范 围内。 1.1.1.1 服务实现方式要求 上述服务主要都是后台应用服务功能，在设计时应考虑尽量对用户透明 降低对平台实际使用者的相关业务、技术要求。 875.1.5 信息接口服务系统 信息接口服务系统，我们主要用cute info产品来实现。 图 CuteInfo技术架构 从技术架构的角度，CuteInfo包括了管理服务、运行服务和监控服务三大部 88分。 管理服务是面向信息资源集成平台管理员所提供的服务功能，它由消息集成 数据集成、服务集成和流程集成中相关的管理服务联合组成。 运行服务是面向其它系统或者相关业务操作人员提供的服务功能。运行服务 的对象主要是参与交换的其它系统，例如：一个前置机上的前置库、文件目录，一 个交换中心的中心库等。操作人员使用运行服务主要是在一些数据交换流程中有 些人工参与的地方，例如：人工的数据比对。 监控服务是面向信息资源集成系统管理人员提供的监控信息资源集成过程 的功能。它分别由消息集成、数据集成、服务集成和流程集成中监控相关的功能 组成。 CuteInfo的技术架构图中的系统互联部分是由运行服务中部分功能实现的， 而这些功能分别来自消息集成、数据集成和服务集成中的与系统连接相关的功能 联合完成。 CuteInfo在设计和开发中遵循各类标准规范，保持系统具有足够的开放性。 这些标准规范涵盖了系统互联、管理、安全、数据等方面。 5.1.5.1 消息集成服务 消息集成是应用整合的基础，消息传送为系统间特别是异构的系统间的应用 整合提供通讯基础。消息传送的功能包括：消息收发、消息安全、消息地址、消息 路由、消息转换等。  支持点对点通讯。消息发送应用可以向定点的目标系统发送消息。  支持点对多点通讯。消息发送应用可以同时向多个目标系统发送消息。  支持同步发送模式。消息发送应用可以以同步的方式向目标系统发送消 息，这种模式保证消息发送完成后才将应用控制权交给消息发送应用。  支持异步发送模式。消息发送应用以异步的方式向目标系统发送消息， 这种模式下，消息发送指令执行后立即将应用的控制权交给消息发送应 89用。  支持请求/响应消息交互模式。请求响应模式是远程服务调用中一种最基 本的模式，消息收发功能提供了对这种模式的支持，消息发送者可以发 送完请求消息后获取目标系统对请求消息的处理结果消息。  支持通知消息交互模式。通知消息交互模式是消息应用向目标系统执行 信息公告的交互模式，目标系统接收到通知类型的消息可以根据业务需 求自行处理。  支持回执消息交互模式。回执的交互模式要求消息的收到方在收到消息 后给发送方一个收到确认消息。  支持消息携带附件发送。一个消息可以携带任意数量和大小的附件进行 发送，对于大附件，消息收发会自动进行文件切割发送和收到数据组装 的工作，方便消息收发应用对大数据的交换处理。  支持丰富的消息连接器类型。连接器是系统互联部分的重要服务，通过 它系统外界进行通讯的通道。连接器管理可以让管理人员自定义各种类 型的连接器，并且在系统中注册这些连接器。对于已有的连接器也可以 根据实际的环境变化进行动态的删除和参数调整。目前 CuteInfo支持的 连接器类型包括：socket，ftp,smtp，jms，vm，file，soap等。 5.1.5.2 服务集成 服务集成是交换节点间采用服务调用的方式完成彼此间数据的发送和接收 的过程。在服务集成中服务调用仅指具有远程能力的服务调用，例如：xml-rpc、 web services、ejb、dcom、corba等。 在这些服务调用的技术中，大部分要求调用的客户端采用的技术与服务提供 端的技术相同，例如：必须采用J2EE技术的客户端调用EJB，采用dcom的客户端 调用dcom服务端程序等。这种限制对于在不同技术的系统间采用服务调用方式 完成系统互联产生了很大的障碍。由此，也产生了相关的技术屏蔽这种技术的差 90异， 其中xml-rpc和web services 是可以使用的两种方案，而web services因为 其相关协议和规范的不断发展而逐渐成为一个主要的解决异构系统间服务调用 的方案。 服务集成的目标指数据交换平台能够以统一的方式完成服务调用，CuteInfo 采用web services作为服务的统一提供和调用方式。同时，CuteInfo也支持对于 一些主要的非web services 提供服务包装的功能，目前支持的包装类型有 java bean、EJB。 5.1.5.3 数据集成服务 数据集成是完成对分布在网络上的各种数据提供统一访问和处理的功能，它 主要包括提供统一访问的数据网格服务和面向复杂处理的数据处理服务。另外， 作为支撑模块在数据集成中还包括元数据访问的服务。主要的功能特点如下：  提供丰富的元数据服务功能。元数据注册管理是为多个系统间基于统一 服务接口实现联合查询或者数据交换提供的基础管理服务。注册管理的 内容是元数据的注册管理，元数据种类包括代码、数据元和数据类资源。 数据元注册管理了信息资源数据最小单元，代码作为数据元管理中的一 个部分定义了数据的取值。数据类资源注册管理了信息资源的基本含义、 信息资源的内容格式内容等。  支持灵活的数据采集服务。数据采集是数据网格中的一项重要功能，是 实现异构来源数据集成和共享的重要手段。数据采集主要是将某一个数 据资源在一个数据源中的全部或部分数据，抽取并输出到另一个数据源 中。这两个数据源可以是在同一个数据网络节点上的，也可以是不同数 据网络节点上的；可以是同一种类型的数据源，也可以是不同类型。数据 网格的数据采集支持大部分类型的关系数据库和文件。  支持数据转换。映射转换服务是对输入的数据按照一定的映射规则进行 数据结构、数据值的修改。在结构的转换中数据项的数量可能缩小，也可 91能扩大。对于数据项缩小的情况来说，就是指从输入的数据项中挑选了 部分数据项，分别作为输出的数据结构中的数据项，同时可以在数据项 对应关系的基础上进行简单的数据值改动操作。这些改动通常可以包括： 常量化、函数调用、前缀、后缀。  支持数据分发。数据输出是指将系统中的数据输出到外部系统的过程。 数据输出中的数据来源可以来自：内存变量、数据库、文件系统等。数据 输出的目的地可以是本地/远程文件、关系数据库、XMLDB、邮件系统、输 出消息路由器、消息队列/主题、web服务等。 5.1.5.4 流程集成服务 在CuteInfo中流程集成服务是指采用统一流程模型语言描述复杂数据交换 过程，并且在流程活动中内置支持CuteInfo中多种类型的内置服务，例如：消息 收发、数据处理、服务调用等。整个建模支持可视化工具建模，同时对于正在交换 的流程可以监控。 在CuteInfo中对于流程的启动支持下面几种方式：  定时启动。这种情况是数据交换流程自主按时启动的方式。  外部事件触发。这种情况通常是由外部发生的事件引发数据交换的流程 启动。通常外部事件可以是业务系统完成一笔业务、某个数据文件到达 目的地、收到某个邮件等。这些事件可以根据类型不同触发不同的流程， 这个是通过定义事件处理规则完成。  手工启动。由用户选择目标数据交换流程完成数据交换流程的启动。这 种情况通常用在某种临时任务、数据迁移任务等方面。 5.1.5.5 运行监控服务 CuteInfo提供对数据交换全过程的监控，包括数据采集、转换、映射、输出的 92全过程，以及内部的线程运作、各类异常等，提供多种报警方式，包括弹出窗口、 音乐、邮件等，能够实时感知运行期间的各类问题，及时应对。 具体包括：  对主机、数据库、传输通道可用性的监控，支持多通道的冗余切换和自动 恢复。  对采集、转换、映射、输出的全过程监控，以及交换时间的监控，对超时的 处理、异常中断的流程进行监控报警。  对交换中各处理过程的数据量进行关联匹配监控，对数据丢失、无法入 库等情况进行监控报警。  对CuteInfo运行期间的各类异常进行统一管理和过滤，对关键性异常进 行报警。  对操作运行日志、内部流程和线程调度等进行全面细致的监控，发现潜 在的问题。  提供弹出窗口、音乐、邮件等多种报警方式，方便使用。 5.1.5.6 异构系统集成与交换服务 CuteInfo支持异构系统、异构数据库之间的数据交换，通过WebService接口 集成基于SOA的应用系统，提供Java、Win32等多种方式的接口和开发框架，适应 于不同应用系统的集成和数据交换。 具体包括：  支持跨网络、跨系统的之间的交换，支持穿越防火墙、网闸的交换  支持异构数据之间的交互，包括：ORACLE、SQLServer、DB2、Informix、 Sybase、MySQL等主流数据库  自适应对数据库、网络等系统故障，故障恢复后能够自动重新交换，无需 人工干预  提供安全、稳定的传输通道，保证交换数据的不重不漏 93 采用多线程，进行并发的采集与输出，高效稳定，支持超大容量的数据交 换  支持Excel、文件、Ftp等文件型数据与数据库之间的交换  支持不同表结构、不同字段数据类型之间的交换  支持海量、增量的定时交换  支持数据的集中与分发 5.1.6 数据交换整合系统 我们对于数据交换平台的功能框架如下图所示。 图 数据交换功能架构 信息资源整合的功能总体上可以分为系统互联服务、消息服务、数据处理服 务和流程服务。 系统互联服务是解决其它交换节点接入数据交换平台的问题。它提供消息互 联、数据互联和服务互联三种服务解决这个问题。 94消息服务主要是解决上层应用对互联服务的使用接口问题。消息服务向上层 应用提供对系统互联服务的统一使用接口及消息模型。同时，基于统一的消息服 务接口和消息模型可以完成交换的消息的日志及路由服务。 数据处理服务主要是解决对消息中携带的业务数据的处理问题。这是一个深 层次的数据交换需求的问题。基于数据处理服务数据不仅可以借助消息在不同系 统间传递，同时可以自动完成一些典型的处理任务。 流程服务解决的是复杂的数据处理过程的问题。有些数据处理是由多个处理 活动按照一定的先后顺序组合完成的。例如：企业基础信息交换中的数据比对， 首先需要采集待比对的数据，其次对企业类型完成一个代码转化，然后再与标准 的企业基础数据进行必对。这样一个过程可以通过流程服务把数据采集、代码转 化、数据比对组合在一起。 另外，在信息资源整合平台的设计中必须考虑管理和安全的问题。各个层面 的功能必须要考虑安全相关的问题，安全的问题在不同层面都回存在，但是类型 和要求有些不同。管理监控是为各个层面的功能配置维护和监控提供相关的服务 955.1.6.1 数据交换基本流程图 图 5.1.6.2 具体步骤及其原理说明 1. 数据交换任务，调用数据采集服务。、 原理说明：  交换任务分为手动任务与自动任务，周期运行自动任务是通过定时器来实 现。 96 任务是一切活动的起始点。 2. 数据采集服务启动数据采集器，数据采集器会根据采集类型，采集全量数据 或者增量数据。 原理说明:  增量数据感知，是通过在表上建立的特定触发器与对应的监控表共同协作实 现。  若有增量数据，触发器往cuteinfo所创建的监控表中插入数据（默认为主键）， 并设置标志位，等待采集。 3. 采集器调用数据抽取服务去数据库抽取数据。 原理说明：  数据抽取根据采集器传递的资源，根据存储映射关系，找到对应的资源 实体（表），抽取数据。  抽取的数据格式为cuteinfo的自定义数据格式数据网格文件，后缀名 为.dgf。该文件中保存有资源描述文件（资源的ID号,数据量等）及其数据。 4. 数据网格文件，传到目的端后，调用数据输出服务，输出数据。 原理说明：  数据输出时会查看目的端存储映射里的资源，若该资源Id号与读取的dgf 描述文件里资源Id号匹配，则解析dgf包中的数据输出到目的端存储映射 对应的资源实体（表）中。  若是单节点直接输出，该输出的过程对用户来说是透明的，在内部处理。  若是多节点输出，源端节点先采集输出到本地文件夹，然后通过cutefile 传输模块，传输dgf数据包到目的端节点所在服务器的相关文件夹后，再 采集输出。 975.1.6.3 数据交换复杂流程图 图2-3 5.1.6.4 具体步骤及其原理说明 1. 数据交换任务，调用数据采集服务。、 原理说明：  交换任务分为手动任务与自动任务，周期运行自动任务是通过定时器来实 现。 98 任务是一切活动的起始点。 2. 数据采集服务启动数据采集器，数据采集器会根据采集类型，采集全量数据 或者增量数据。 原理说明:  增量数据感知，是通过在表上建立的特定触发器与对应的监控表共同协作实 现。  若有增量数据，触发器为往cuteinfo所创建的监控表中插入数据（默认为主键 信息），并设置标志位，等待采集。 3. 采集器调用数据抽取服务去数据库抽取数据。 原理说明：  数据抽取根据采集器传递的资源，根据存储映射关系，找到对应的资源 实体（表），抽取数据。  抽取的数据格式为cuteinfo的自定义数据格式数据网格文件，后缀名 为.dgf。该文件中保存有资源描述文件（资源的ID号,数据量等）及其数据。 4. 带数据的事件通知模块，不同于基本流程中直接输出。 原理说明：  当数据采集完成后，不是直接输出，而是发送通知消息给事件通道。  事件一直处于监听状态。 5. 事件匹配，事件监听根据发来的事件通知消息。 原理说明：  在事件处理规则中配置事件来源选择采集器，带数据的通知消息中的采 集器与某个事件的采集器相匹配时，该事件将会运行。 6. 事件启动流程活动(数据处理规则的顺序组合)。 99原理说明：  数据处理活动为模块化的顺序工作流方式对外服务，用户使用数据处理 规则组合成多种流程活动。  事件负责调用这些流程活动，顺序处理数据。 7. 数据输出服务 原理说明：  流程里最后的数据输出规则将和基本流程一样调用数据输出服务。  数据输出时会查看目的端存储映射里的资源，若该资源Id号与读取的dgf 描述文件里资源Id号匹配，则解析dgf包中的数据输出到目的端存储映射 对应的资源实体（表）中。 5.1.6.5 基本配置过程 注：配置过程与数据交换流程基本上是相反的一个过程，配置简要过程如下： 1．基本流程：  建立数据源（源端，目的）  抽取资源，建立对应关系，建立存储映射  建立增量触发器，若没有权限，需要拷贝触发器脚本发给DBA  建立相关类型的数据采集器  建立任务，任务里面关联数据采集器。 2.复杂流程：  建立数据源（源端，目的）  抽取资源，建立对应关系，建立存储映射  建立增量触发器，若没有权限，需要拷贝触发器脚本发给DBA 100 建立相关类型的数据采集器  建立数据处理规则。  建立事件，事件里面选择事件来源，并串联相关的数据处理规则。  建立任务，任务里面关联数据采集器，并发送事件。 5.1.7 卫生信息基础资源库 卫生信息基础共享资源库集中了整个卫生信息系统的基础数据，是为各个分 系统提供基础信息服务的。 卫生信息资源库包括了数据元和代码标准数据库（数据字典）、人口信息、法 人数据库、公共危险因素数据库、卫生资源信息以及其他各专业系统所需的基础 信息等。 5.1.7.1 数据字典 根据目前所了解到的应用需求，作为卫生信息基础资源库中的最基础信 息数据元和代码标准数据库中主要包含了下列数据字典信息：  《医疗机构和公卫机构字典表》  《行政区划字典表》  《诊断编码表》  ICD-10疾病诊断编码  中医诊断编码(参照中医国标95制定)  手术诊断编码(参照ICD-9-CM3的标准制定)  《标本字典表》  《仪器设备字典表》  《检查类型字典表》 101 《科室字典表》  《医护人员字典表》  《医保药品字典表》  西药编码表  草药编码表  《医保诊疗项目字典表》 …… 5.1.7.2 人口信息 人口信息是基础信息数据库中的核心内容之一。无论是健康档案、医疗业 务、临床信息，还是疾病预防控制信息都是以人口信息为基础的。在此基础上， 实现健康档案、医疗业务（含临床数据）和疾病预防控制数据的关联。 如果要实现临床、健康档案、疾控、妇幼的信息联动，必须建立标准化的 居民基本信息。这些信息都是以人口信息为基础。 目前以居民健康档案中的人员基本信息为基础。 5.1.7.3 法人信息 法人信息是基础信息数据库中的另一个核心内容，以卫生监督提供的法 人信息为基础可以建立公共危险因素数据库、卫生资源数据库。 目前已卫生监督提供的许可信息为基础。 5.1.7.4 维护方式 上述卫生基础信息中，依据相关信息的提供者和提供方式，平台将分别采 取下列两种不同的维护方式，对相应的基础资源信息进行诸如(新增、修改、删 102除、查询)的操做。  相关基础资源信息由稳定的外部数据提供者和稳定的数据提供 渠道，譬如：医保药品代码信息、医保诊疗代码信息等 对于此类信息为保障数据不出现二义问题，要求平台原则上不提供对此 类信息的新增、修改、删除操作功能。仅仅提供对此类信息的查询功能。  相关基础资源信息缺乏稳定的外部数据提供者和稳定的数据提 供渠道，需要由平台自身进行标准化整理和维护 对于此类信息要求平台提供相应的新增、修改、删除、查询操作功能，方便 用户进行调整。但要提醒的是由于本系统为核心平台，相关代码的调整最终的 影响范围可能会非常大，因此不建议用户直接对代码进行调整，因此上述功能 的直接使用人群应该是高级的系统管理员或维护单位。 5.1.8 健康浏览器 健康档案浏览器（即EHR浏览器）是为终端用户提供的基于web 的访问个人 电子健康记录的应用程序，提供健康档案的展现。健康档案浏览器的目标是建立 一个用户友好的环境，在该环境下被授权的卫生专业人员或居民可以方便地访问 健康档案中保存的相关数据。健康档案信息由临床信息、预防保健信息、康复信 息等组成，健康档案浏览器可以根据使用者的特定需求提供不同卫生领域的调阅 展示服务。 5.1.8.1 一般需求 用户可以访问同一居民信息，无需考虑是从哪个工作站登录的； 向用户提供访问居民纵向记录的窗口，必须能够显示EHR 存储库中的 数据； 对于EHR 浏览器来说，注册库应该是信息平台标识符的唯一来源，尤 其在选择患者和医疗机构或者解析服务位置标识时； 103提供能够使用EHR平台中的居民注册服务来检索居民信息的功能； 提供在客户记录间方便的导航能力，同时维持特定用户会话的语境信 息如用户ID、密码和患者标识信息；  提供记住活跃患者的列表能力，提供优化机制以访问活动名录（预先查 询，缓存等）中的患者记录； 纵向记录服务包含的EHR 索引应当是任何和所有（即纵向的）患者EHR 查询的起点（即第一级的）。EHR 浏览器应使用户能“下钻”到由LRS 索 引的任何特定事件、文档或其他公布的条目； 对于给定的患者来说，提供代表客户EHR 内容的概览视图； 提供不同方式的视图，如按日期、按服务提供者、按服务地点排序的按 事件访问客户EHR，或者按视图中展现的特定域来访问EHR； 提供方便灵活的信息导航特征，如，改变列表中分类顺序、改变列的位 置、可变更可视长度等；  提供全科医师在患者就诊期间或在就诊的上下文环境中获得对居民健 康记录的访问。为了有助于这些方案的应用，EHR 浏览器需要易于使用和 导航，易于学习，高效提供数据和有效地与信息平台交互以访问所呈现的 数据； 5.1.8.2 隐私和安全需求  居民健康相关信息属于个人隐私，健康档案浏览器需要通过安全、保密 访问控制等手段，提供健康信息的隐私保护和数据安全保护；  为安全起见，EHR 浏览器利用信息平台的安全机制，即用户应该在信息 平台域上注册并被全域所知晓；  通过应用保持在接入层中可用于用户EHR 访问的政策、规则和控制，提 供与用户交互的能力，以执行认证和授权访问控制；  提供应用辖区许可管理的政策的特征，例如紧急情况下的处置，许可收 集等；  在适当的系统安全日志机制内，记录所有导致访问或更新信息平台系 104统任何组件的系统/用户事务日志； 5.1.8.3 系统集成需求  EHR 浏览器应用通过执行EHR 互联互通性框架标准化消息来访问所有 平台服务；  所有与EHR平台的交互都依赖于国家EHR 标准。包括数据消息通信标 准，术语标准，协议和其他技术标准；  可以在任意支持当前工业标准的web 浏览器客户端的台式/便携式/无 线计算设备上运行；  依赖于行业认可的基于web 方式的“瘦客户端”方案，该方案可以最 小化拥有成本，包括维护和开发成本。如.使用Web 界面，不需要将代码下 载到客户端计算设备，而是使用运行时编译对象或脚本语言如Java、.Net 或 JavaScript；  基于公认的web 门户技术，提供了灵活、开放、组件驱动、面向服务的 应用架构，如基于web 的门户和端口小程序技术；  能易于整合到现有PoS 应用用户接口环境，该环境基于开放 W3C 标准 的互联互通技术，如HTML，HTTP，XML 等；  能在用户界面级整合到现有 PoS 应用，采用上下文环境管理技术和标 准，例如CCOW 等，在一个或多个软件应用间进行传递用户会话和居民标 识。 5.1.8.4 性能/可伸缩性需求  高性能的客户数据访问，在网络通常的情况下，任何单一访问信息平台 进行数据调阅通信必须在5 秒内在终端用户屏幕上响应；  能够支持EHR平台下规划的所有用户； 105 能够支持一个EHR平台内预计用户基数的用户请求/事务的高峰容量；  用松散耦合的软件部件支持基于服务的N 层架构（即非客户服务器模 式）的概念、设计和实现，允许容易地变更或增加新功能； 5.1.9 隐私保护 在EHR共享时，平台除了提供一般的安全服务（如单点登录、授权、认证、基 于角色的访问、数据库高级安全、应用流程控制等）外，还需要基于政府配套法规 提供更加复杂的安全和隐私服务。  匿名服务 在分析研究时隐去患者资料，保证不向非授权用户透露患者的身份  许可管理服务 转换由政策和个人特定许可指令带来的隐私要求，将其用到EHR共享中。在 提供个人健康信息时，许可服务决定是否允许或限制可以公开；也可以阻止和屏 蔽某一医疗服务提供者访问个人健康信息；也可以在紧急治疗情况下，不经过许 可直接开放共享。  身份保护服务 将客户或患者的身份解释为一个EHR客户标识符（ECID）。EHR客户标识符是 一个受保护信息,只有信息平台内部才知道。  杜绝超级用户 数据库的安全性越来越受到重视，而其中大部分的威胁往往来自内部，如何 进行有效的内部控制，多年来一直没有很好的解决办法。其中一个突出的问题就 是如何限制DBA对应用数据的存取。DBA具有系统“至高无上”的权限，对他们 而言数据库中的数据是没有任何秘密可言的。此外，为了保证运营系统的正常运 行，某些“危险”操作是应禁止执行的。 1065.1.10 应用安全审计 主要实现功能：  审计日志记录：提供多种级别的日志记录功能。  审计日志查询：根据用户需要，灵活的设定查询条件，提供良好的日 志跟踪、分析等服务。  审计日志归档。 5.1.11 系统管理 5.1.11.1 用户管理 用户信息是整个系统的基础信息，会被多种上层应用使用，而这些应用对用 户信息的描述有不同的要求，因此要求用户信息管理功能非常灵活，容易扩展， 并提供丰富的维护和查询接口。如果用户量比较大，还需要有很好的查询性能。 用户信息包括基本信息如：名称，性别，民族，学历，通讯地址，电话，邮件地 址等，另外还提供用户信息的灵活扩展。用户信息和组织管理权限管理的结合能 实现人员分级管理，子管理员只能维护自己可管辖的系统用户，并对用户进行授 权等。 5.1.11.2 统一权限管理 统一授权管理构件主要负责对内提供系统权限配置功能，对外提供权限验证 接口，支持基于角色的访问控制以及自主访问控制标准，可按等级实现个人级， 文件类别级，文件级，市民自定义保护级四级保护机制。它支持对功能、菜单、页 面元素、数据等不同粒度的资源进行授权，不同应用系统中的资源可以被接入并 107统一管理。它支持分级授权，管理员可以对某些权限有管理（将它赋予他人）的权 力，但是没有使用这些权限的权力。 在系统运行过程中，安全管理员可以选择对某个角色/人员/组织/岗位进行授 权，再选择需要进行授权的资源的类型，不同类型的资源具有不同的操作。安全 管理员可以指定某个角色可以对哪些资源具有某些操作的权限，还可以进行分层 授权等。这些授权的策略信息被集中存储，并对外提供访问接口。 安全支撑平台支持对管理员的权限进行分级。低级别的管理员没有权限修改 比其级别高的管理员（包括平级）的权限，也没有权限为比其级别高的管理员（包 括平级）指派用户。系统中默认具有一个超级管理员，具有最高的权限级别，有权 新增任何比其等级低的各级管理员，并为他们指派用户。 高级别的管理员可以把自己有权赋权的部分权限赋予低等级的管理员，也可 以把自己有权赋权的权限赋予最终的用户。作为系统的管理员，无论是超级管理 员还是其他各个级别的管理员，都只具有赋权的权限，而没有行使其权限规定的 各种操作的权限。真正利用权限执行业务操作的是最终的用户。当然，一个用户 既可以拥有管理员的角色，也具有业务逻辑的角色。 外部应用系统可以使用统一权限管理提供的访问控制接口，判断某个用户是 否能够对某个/某些资源进行一个操作。 5.1.11.3 角色管理 安全支撑平台实现了基于角色的访问控制机制，并依据安全原则中的职责分 离和最少权限原则，预定义了系统管理员、安全管理员和安全审计员的角色。 职责分离：系统的控制不同的人被分配不同的任务，没有一个人有系统安全 全部的控制能力。传统上很多计算机系统管理员负责系统全部的系统管理和安全 管理，这种情况在安全系统中是不允许的，因为安全任务和功能不应该自动分配 给系统管理员。在高安全的计算机系统中，需要三种职责分离的角色：系统管理 员（System Administrator）、安全管理员（Security Administrator）和安全审计员。 108最少权限：只能给予系统的用户进行他们工作所需要的最少权限、特权和所 需要的最短时间周期。职责分离后最有效的安全方法是最少权限。 在安全支撑平台的控制下，系统管理员可以进行用户的管理、系统的管理等 工作，但是和其他一般用户一样，并不能去访问未经授权的资源。这样可以防止 系统管理员具有过大的权力，以及可能由于误操作而给系统带来的损失，黑客即 使窃取了系统管理员的身份和权限，也无法访问系统中的敏感数据。安全管理员 可以为某个角色授权、制定安全策略等，但是不能管理用户。安全审计员则可以 查看和审计用户的访问记录，发现异常和处理。这三个角色互相制约，任何一个 人的操作都可以得到其他人的监督，共同完成安全管理功能。 5.1.12 单点登陆 单点登录组件负责向用户提供统一的登录入口，即便是系统中存在着多套用 户管理模块、授权以及认证系统，通过单点登陆组件，用户仍然可以通过一次登 录获得所有需要访问的网站的授权，实现了“一处登录，多系统展现”。通过使 用单点登录功能，用户只需要记忆一套用户名和密码，极大的方便了用户的使用 改善了用户使用应用系统的体验。 单点登录组件支持相互独立的网站之间的单点登录（这些网站可以采用不同 的技术框架，例如J2EE技术的网站和ASP技术的网站之间），提供了端到端的安 全性，方便集成。他涉及的角色分为两种： Service Provider 和 Identity Provider，其中， Service Provider是各个提供应用功能的系统，单点登录功能 就是要将它们提供的不同的登录和认证方式统一起来；而Identity Provider是 通过将各个Service Provider建立成一个联盟，管理和维护联盟中的各种用户 信息和关联。 单点登录组件主要实现了以下功能： 1、结盟管理 此功能一般提供给系统管理员使用。在实现单点登录之前，首先由管理员将 门户中某帐户和应用系统之间建立结盟关系，当用户以该帐户从门户登录后访问 109这个应用系统时就不需要再次登录了，通过单点登录服务器交互获得用户在这个 应用功能中的身份信息，直接访问这个应用功能，管理员也可以撤消结盟关系， 阻止用户以该帐号在门户和应用之间实现单点登录。 2、集中的权限控制和身份验证 实现了基于角色的权限管理模型，可根据用户的需求实现任意粒度的资源的 权限控制。 3、应用系统联盟的管理 包括将一个应用系统加入联盟、退出联盟。 4、用户凭证管理 用户在门户登录，再通过认证之后，还会将用户的身份信息发送给单点登录 服务器，由单点登录服务器创建一个全联盟有效的会话，并且获得用户凭证。如 果去访问联盟系统中的另一站点时，依靠有效凭证，通过单点登录服务器获得此 站点上的用户身份信息，模拟正常登录的系统状态。当用户退出登录时，单点登 录服务器创建的会话凭证将被注销，从而保证了系统的安全性。用户的凭证是经 过密码加密的，避免了非法访问时伪造用户凭证，并能够保证用户凭证的保密性 完整性、不可抵赖性。 另外，单点登录模块基于开放的架构，提供了一套方便实用的应用编程接口 （API），用户可以根据自身的业务需要将应用集成进来。 单点登录的具体实现方式： 集成环境：Tomcat 6.0 准备工作：采用SSH框架集成的Web项目，该单点会和权限系统整合在一起，需 拥有本平台权限系统 操作步骤： 1. 拷贝sso.war包到Tomcat根目录下webapp中 1102. 拷贝cuteframework-sso-client-20080808.jar到本项目WEB-INF下lib中 3. 对应本Web项目，拷贝applicationContext-filter.xml和applicationContext- sso.xml文件到该项目对应存放spring配置文件的位置 4. 拷贝web.xml将里面内容添加至本Web项目web.xml文件中 5. 拷贝源文件src下com.wondersgroup. common.web下的代码添加至本项 目中（如果更改目录结构，请修改applicationContext-sso.xml中对应的spring 的注入bean的路径） 6. 拷贝源文件src下com.wondersgroup.model.auth中的对应权限的实体类 和hibernate对应的映射文件至相应目录。 7. 在spring对应hibernate对应配置的地方添加步骤5中，hibernate对应的 映射文件 8. Struts配置文件中配置2个登录的action，即：单点会拦截的action及本 地登录的action 单点登录分析： SSO单点是目前比较流行的服务于企业业务整合的解决方案之一，，本系统 采用对SSO实现框架CAS （Yale 大学发起的一个开源项目）的应用。 分为server端和client端。以下对上述的简单介绍：（以下提到的客户端即需 要配置单点的本项目） server端： 即步骤1中拷贝的sso.war，在该war中有单点登录的登录页面，对于登录的 用户名和密码会查询权限系统的用户表，拿到用户的基本信息。（对于登录密码 可以用spring注入对应的加密方式，现在采用的MD5加密方式），如果单点登录 成功后，在客户端通过request.getRemoteUser()方法可以获得登录的用户名。 Client端： web.xml的配置，将 struts、hibernate、charsetEncoding等相关的配置通过 spring代理的方式由spring配置文件管理（类似spring security的配置） 111applicationContext-filter.xml中配置相关说明： 1、nonefilter：该过滤器实际上没有对请求有任何的拦截，即：配置该过滤 器的请求将不会呗拦截 2、loginfilter：本地登录过滤器 属性： myMatchUrl即：不进过滤器的URL，尤其是本地登录页面的处理 loginAction 即：com.wondersgroup.common.web.action.LoginAction，该登录 Action继承BaseLoginAction,在该action中login()方法，适用于本地登录和单点登 录过来，登录成功用户不为空后，通过用户获得其对应的权限（由于本权限系统 涵盖整个单点及子系统，在用户拿到自己的权限的同时，客户端需要通过 keyword值，取的子系统下所有的菜单与用户拥有的权限匹配，从而得到该用户 对应子系统的权限而显示菜单） 3、casfilter：该过滤器为单点登录的过滤器 属性： casLogin即：server端登录的请求路径 localPortalIndexUrl即：本地登录的请求路径 casPortalLoginUrl即：server端的单点登录路径 4、wondersCommonFilter该配置过滤器的顺序，请求的流向。 Strtus配置文件： 该配置文件中配置了2个登录action 访问main.action即本地登录，访问ssomain.action即单点登录 流程： 该单点没有使用CA认证，采用用户及密码验证用户基本信息，到子系统 判断单点登录与否，如果登录到权限系统获得该用户的权限。如果没登录，返回 单点登录页面。 子系统登录，对子系统登录请求不配置casfilter过滤器，子系统登录直接 112访问本地登录action 注意： 以上参照sjzk_cen 中心端数据质控，源码及配置详见该项目 权限系统为auth_cen该项目 5.2 基于平台的应用系统建设 5.2.1 居民健康卡系统 5.2.1.1 市注册管理中心系统 5.2.1.1.1 卡注册服务 市级平台所提供的卡注册服务，主要是为了实现在居民健康卡的全生命周期过程 中，完成对卡、网点、机具、终端等各类实体的注册服务。市级平台对这些实体提 供唯一的标识，以便于在居民健康卡的各类活动域中，一方面通过这些实体索引， 提供持卡跨医疗卫生机构的临床诊疗或公共卫生等多种业务服务的入口；另一方 面，通过每一次持卡业务过程中对卡片和机具的有效性验证，来完成行业安全监 管。例如对于使用单位使用伪造的、非本单位的、无权限的机具产生的交易数据， 可以开展有效的监控。这两项工作是基于市级平台的居民健康卡注册管理中心的 最为基本性的工作。一旦注册成功后，各级医疗机构就可以根据市级平台分配的 标识，开展后续的业务活动。 该服务组件的基本功能，涵盖以下几个方面：  按照注册对象类别划分，包括：用户卡注册服务、SAM卡注册服务、受理 网点注册服务、业务应用网点注册服务、业务终端注册服务。  按照注册功能类别划分，包括：新增、修订和合并、检索等。 113 按照注册信息的来源和去向划分，包括异地卡注册，注册信息提交省厅、 省厅注册信息落地等。  按照应用目的划分，包括：基本信息注册、身份唯一识别、有效性验证。 此外，由于居民健康卡业务的特殊性，其注册服务需要贯穿到全生命周期的各个 阶段，即，需要在不同阶段，完成不同信息的注册。以用户卡为例：  当完成制卡后，卡注册服务需要对制卡信息进行注册，包括：安全码、 芯片序列号、卡的类别、规范版本等。  当完成发卡后，卡注册服务需要对发卡信息进行注册，包括发卡机构 发卡时间、卡有效期等的注册  当持卡业务应用过程中，通过和银行的对接，需要完成对居民健康卡 状态的注册，包括解冻、冻结、挂失、解挂、补换卡、注销等。 5.2.1.1.2 卡业务统计 作为武汉市卫生平台应用子系统之一的居民健康卡系统，可以得到来自平台的 数据支撑，平台采集各医疗机构数据时支持对居民健康卡业务流程数据的采集， 根据采集后的数据可进行相关的业务指标统计： （1） 发卡数量统计 统计所有发卡网点每日、每月发卡数量； （2） 发卡网点排行 对网点发卡按时间段统计、汇总、排序； （3） 避免重卡统计 发卡时银行系统会通过注册服务中心系统，提供的校验接口判断申请人是否满 足发卡条件，这样可以使发卡环节可控，以提高资金投入的有效利用率； （4） 居民健康卡使用监测； 可以根据平台采集各医疗机构的数据进行分析，监测居民健康卡的使用情况与 使用频率； 1145.2.1.1.3 SAM卡生命周期管理系统 SAM卡在整个安全体系中是一个非常重要的环节，基于安全角度考虑，市局必 须按照严格的流程，对各个服务网点申领和部署的SAM卡进行管理。一期是否实 施，视试点范围大小而定。 该系统主要功能包括： （5） SAM卡入库 所有从卫生部或者其他上级单位领取的SAM卡必须登记入库，确保不会被非 法使用。 （6） SAM卡下发登记 所有SAM卡下发到有关使用方时，使用方必须指定专人负责领用接口工作，此 过程须登记，用作管理查询。 （7） 成品卡回收 当有SAM卡损坏或终止使用，必须由使用方及时返还给有关管理部门，此过程 须登记，用作管理查询。 5.2.1.1.4 市密钥管理系统 该系统由银行提供，但需部署在市卫生局数据中心，由市卫生局指定专人进 行日常管理。 该系统的功能实现，综合规划为三个业务应用子系统： （1） 密钥生成子系统 是一个仅限部署于市卫生局居民健康卡管理机构内的子系统，其运行组成包 括：密钥母卡（CPU IC卡）、母卡读写机具、加密机、管理专用PC。实现的业务管理 功能为： － 定义密钥组成 115－ 密钥的生成过程 － 密钥的存储和传输 （2） 密钥应用子系统 是一个仅限部署于市卫生局居民健康卡管理机构内的子系统，其运行组成包括 加密机（或密钥母卡及母卡读写机具）、SAM卡、读写机具、管理专用PC。实现的 业务管理功能为： － 发行居民健康卡 （3） 密钥安全服务子系统 是一组可部署于市卫生局居民健康卡管理机构或线路中央主机系统中的安全 服务模块，其运行组成包括：加密机、安全服务主机、管理终端PC。实现的业务管 理及应用功能为： － 数据传输过程中的加解密计算 － 消息报文的MAC计算 － 系统中的用户管理及访问控制 5.2.1.1.5 基于健康卡的公众健康服务 密码申领 平台提供查询密码申领的功能，持卡人可访问市级平台子系统之一的居民健康门 户，使用其中健康自服务功能向平台发起申请，系统为该持卡人开通网上查询功 能，并分配一个查询密码给持卡人。 网上查询 持卡人领取到网上查询密码后，登录居民健康门户网站，输入自己的居民健康卡 卡号和密码，即可进入网站内部查看到自己的居民健康卡信息，并提供在线信息 打印的功能，另外持卡人登录网站后还可以对自己的密码进行修改。 利用互联网实现对居民健康卡持卡人的综合服务是统一公共服务平台的重要内 容，在现有门户网站，网上办事的基础上，实现包括领卡的网上申报、网上申请、 116网上咨询的提交等网站服务功能。 利用互联网实现居民健康卡的网上挂失服务。 5.2.1.2 基于市级平台的数据交换 5.2.1.2.1 对接省级居民健康卡注册管理系统 （1） 注册信息：用户卡、SAM卡、服务网点的标识信息 （2） 用户卡信息：个人基本信息、制作发行信息、生命周期信息 （3） 业务统计信息 （4） SAM卡信息：申领签收信息、生命周期信息 （5） 黑名单信息（假设省、地市需要分布式部署） 5.2.1.2.2 对接银行系统 （1） 个人发卡校验： 个人识别唯一标识（如：身份证）校验是否满足发卡条件并返回校验 结果。 （2） 居民健康卡基本信息： 个人基本信息、卡号、卡状态； 5.2.1.2.3 对接新农合系统 由于目前新农合卡无法写入卫生部密钥，建议暂时不对接。 5.2.1.2.4 对接医院临床系统 与医院信息系统接口，采集患者诊疗过程的信息，门诊记录，住院记录，检验 检查信息，影像信息，收费信息等。 详细接口要求请见： 《武汉市区域卫生信息平台医疗服务数据接口标准》 1175.2.1.2.5 对接医院自助终端 需要查询EHR、将EHR写入居民健康卡、激活卡等工作，包括： （1） 卡识别数据 （2） 健康档案信息 5.2.2 市民电子病历共享系统 5.2.2.1 总体业务概述 电子病历共享是以个人基本信息为基础，通过市民身份识别主索引（例如居 民健康卡等）的方式，来保证各个医疗机构的应用系统识别出同一个自然人，在 就诊时形成就诊信息，在住院时形成病案首页信息，在出院时形成出院小结等信 息，通过将以上信息的综合，形成个人的诊疗档案。通过武汉市区域卫生信息平 台提供的健康信息浏览器，嵌入到各医院及社区医生工作站，使医生在权限允许 范围内可查阅患者在各个医疗机构的历次诊疗信息，从而最大限度利用已有医疗 信息资源，降低医疗成本，减少或避免不合理检查，减少医疗错误和不良反应的 发生。 市民电子病历数据共享信息的收集需要融入到医疗卫生机构的日常服务工 作中，随时产生、主动推送，一方采集、多方共享。 5.2.2.2 业务需求分析 5.2.2.2.1 业务范围 市民电子病历共享系统一般包含调阅患者基本信息、调阅患者主要疾病与健 康问题摘要、调阅患者就诊履历以及调阅患者外院住院病案、住院小结等功能。 1、调阅患者基本信息 118用户可以按照姓名、健康卡号、身份证、地址等条件查询患者。一般情况下该 功能不单独使用，作为其他功能定位患者时使用。 2、调阅主要疾病与健康问题摘要 在患者接受诊疗或预防保健管理过程中，医生可通过健康信息浏览器对保存 在市级卫生信息平台中的主要疾病与健康问题摘要进行调阅，包括对患者健康 （病历）摘要信息（既往史、生育史等）以及在各级医院的历次就诊信息（含用药记 录、住院病案、出院小结等）所能反映的患者主要疾病与健康问题的调阅。 3、调阅患者就诊履历 对于一般的患者（非特殊患者或病症），在门诊挂号或入院登记后，医院的医 生工作站系统（CIS）即可以通过患者信息来查看患者在其他医院的就诊履历，包 括历次诊断、医嘱明细、收费明细。 4、调阅外院住院病案、出院小结 系统提供调阅患者外院的住院病案、住院小结的功能。患者在门诊挂号或入 院登记后，医院的CIS系统即可以获取患者外院的住院病案报告。 5.2.2.2.2 用户角色分析 本期建设的电子病历共享系统面向接诊医生、区域卫生管理者及居民。其 中接诊医生分为临床医生及社区全科医生。 1195.2.2.2.3 业务结构图 1205.2.2.2.4 业务流程图 业务流程图说明： （1） 市民在医疗机构看完病后，医疗机构医生工作站记录保存患者的基础 信息及医疗服务信息。 （2） 医疗机构的医生工作站将患者信息及医疗服务数据传送到区域卫生 数据中心集中归档保存，并在此基础上形成了主要疾病与健康问题摘 要。 （3） 患者再次在其他医疗机构看病时，如果医生需要了解患者以前的病历 信息，通过医生工作站向数据中心提交调阅病人病历申请。 （4） 患者身份认证通过后，数据中心响应医生的调阅请求，将医生所需病 人数据通过EHR浏览器展示给医生。 1215.2.2.3 应用场景 场景一：居民到医院就诊时，临床医生可调阅居民的电子病历，了解患者详 细诊疗信息。 场景二：社区全科医生在为居民进行卫生服务时，可调阅当前居民的电子病 历信息。 场景三：在远程医疗过程中，医学专家可以远程调阅患者电子病历信息。 场景四：在双向转诊过程中，接收医院可以调阅患者电子病历信息，从而及早做好救治 准备。 5.2.2.4 系统功能说明 市民电子病历共享系统将提供以下功能： 业务类型 功能编号 功能名称 医疗机构 区域卫生管理员 市民 1 调阅患者基本信息功能 √ √ √ 调阅主要疾病与健康问题摘 2 √ √ √ 要功能 3 调阅患者就诊履历功能 √ √ √ 调阅外院住院病案、出院小 4 √ √ √ 结 5 患者身份认证管理 √ 6 系统权限管理 √ √ 5.2.3 市民检验检查结果共享系统 5.2.3.1 总体概述 当下，“看病难、看病贵”，已成为公众关注的一个热点问题，而过于昂贵的 医疗检验检查费用是造成“看病贵”的一个主要原因。如浙江省卫生部门统计， 122一个住院病人检验检查的费用约占总医疗费用的30%至40%，其中有相当一部分 是由于医院间缺乏有效的检验检查质控手段，信息不连不通，导致患者只能对相 同项目做重复检验检查所产生的费用。为此，卫生部办公厅于2006年2月24日， 下发《关于医疗机构间医学检验、医学影像检查互认有关问题的通知》，要求各地 卫生厅都相继制定实施意见，逐步推行医学检验、医学影像检查结果互认，以此 减轻了患者的负担。 从实际诊疗过程看，要贯彻落实上述工作要求，一方面要加大医疗卫生领域 的行政干预力度，规范医疗机构的医疗行为，建立起有效的质控机制，逐步推行 实验室检验结果、影像检验报告的互认；另一方面，必须借助信息化手段，通过检 验检查结果的信息共享和监管，从而高效利用有限的医疗资源，大大降低患者的 实验室检验和影像检查费用，有效减缓“看病难，看病贵”的矛盾。 5.2.3.2 业务需求分析 5.2.3.2.1 业务需求范围 ①检验检查信息的采集的功能 通过区域卫生信息平台，从联网的各家医院采集患者的每次诊疗的检验检查 结果信息形成患者检验检查特征库；另外，从医生工作站中即时采集医生针对患 者的检验检查医嘱，以便于与特征库核对发现检验检查内容。 ②数据交换服务的功能 采取星型信息交换方式直接汇聚市级卫生信息平台，再通过平台数据流转至 对应医院完成整个数据交换过程。具体交换的内容包括：检验检查医嘱、检验/检 查报告和/或原始数据交换。 ③患者检验检查表推送的功能 在患者挂号或者办理入院时，通过就诊医院的前置机向中心端发送该患者的 主索引编码和就诊医院的医院代码，中心端可以根据接收到的主索引编码，快速 检索到该患者的检验检查表，并推送指定医院（以医院代码为标识）的前置机上， 供医院端的重复检验检查提示应用系统调用。 123④调阅跨院的检验检查结果的功能 系统提供调阅患者跨院的检验检查报告功能。患者在门诊挂号或入院登记后 医院的CIS系统即可以获取患者存储在外院的检验检查报告。 ⑤检验检查结果发布的功能 本期建设，实现检验检查结果发布在公众健康门户上，支持患者以实名方式 通过Internet或短信平台等方式，获取本人某次检验检查的位置、状态、检验结果 等信息。 5.2.3.2.2 用户角色分析 本期检验检查结果共享系统面向检验医师、临床医生、区域卫生管理者以及 居民。 5.2.3.2.3 业务流程图 业务流程说明： 1. 医院临床医生开检验（检查）申请单，通过前置端验证是否为重复检验（检 124查）项目。 2. 验证是重复检验项目时通过平台调用该患者的检验报告。 3. 验证不是重复检验项目时，发送检验指令给检验室检查。 4. 检验（检查）室检查（检查）得出结果后将数据传给临床医生和医院前置机。 5. 前置机最后将数据传送到数据中心归档，以备其他医疗机构调用和查看。 5.2.3.2.4 典型业务场景 以下将用时序图方式，对其中典型的检验申请进行业务场景分析。 病人去医院就诊时，医院医生为了病情需要要求病人做某种实验室检验，但 患者前不久刚在另一家医疗机构做过这个检验检查，因此就诊医院只需要将该患 者的检验检查结果通过平台调阅，即可得知病人的检验检查情况。 1. 门诊或住院医生给患者开出检验申请 2. 通过平台验证该检验申请单在近期是否做过 1253. 验证没有做过检查则病人那检验申请单到收费处缴费 4. 医院检验科室取到缴费的检验申请进行检验，并将数据推送到前置机 5. 通过前置机将数据存储到数据中心，方便其他医疗机构临床医生的调用。 6. 验证近期做过该类检查则通过前置机调阅该患者在数据中心的检验结果信 息，临床医生根据这些信息做出临床诊断。 5.2.3.3 系统功能设计 联网医疗机构检验检查事务管理主要涉及患者、首诊医院及其医护人员、B 机构及其医护人员、卫生局行政管理部门。业务活动包括医院业务服务类功能、 数据交换类功能、、公众服务类功能。 5.2.3.3.1 业务服务 该部分功能主要是针对患者在医院就诊时，针对已经在其他医疗机构做过的 检验检查项目而避免重复检查，主要包括检验检验申请的验证及检验检查结果的 调阅两种。。 注：这些功能需要对医院的原有HIS、，以能适合记录验证及结果调阅的过程。 5.2.3.3.2 数据交换服务 采取网状点对点方式直接院间交换；而数据流则采用HL7 V3的消息交换方式 （非前置表交换）通过本期建设的EHR信息交换平台和EHR平台进行数据交换。 具体交换的内容包括：检验检查医嘱、检验/检查报告和/或原始数据交换。 5.2.3.3.3 联网医疗机构注册管理 调用EHR平台的注册服务对联网医疗机构进行注册管理并及时发布各个 B 机构相关的设备、服务项目等优势资源信息。 5.2.3.3.4 公众服务 公众服务功能，可以使得患者通过Internet或短信平台等方式，获取自身本 126次检验检查的位置、状态、检验结果等信息。 5.2.3.3.5 系统功能说明 市民电子病历共享系统将提供以下功能： 业务类型 功能编号 功能名称 医疗机构 区域卫生管理员 市民 1 检验检查申请 √ 2 检验检查数据交换 √ 3 检验检查结果查询 √ √ √ 4 医疗机构注册管理 √ 5 系统权限管理 √ 5.2.3.3.6 系统接口 需服务请求方和接受方分别交换如下数据：  送测医院提供：检验检查单唯一标识、医嘱申请项目信息、医嘱申请 项目执行大类、标本种类等。  联网医疗机构提供：报告仪器信息、报告项目信息、影像报告等。 5.2.4 市民双向转诊系统 诊中心和转入医院之间转诊业务的管理；必须支持统一挂号。主要的业务需 求包括转诊计划的设定和转诊的相关审批。 2、转诊临床信息共享 转入医院的医生能够通过健康档案浏览调阅到该病人在转出医院就诊时的 病史资料、检验/检查报告、处方和治疗信息；并且可以查阅该病人以前的病史信 息。减少不必要的重复化验和检查。 医疗信息共享系统提供了相关的病人基本信息、疾病信息、诊断信息、用药信 127息、检验信息、检查信息；健康档案共享系统提供病人病史资料等。这些信息集中 的存储于卫生数据中心。 3、转诊相关医疗资源管理 系统需要管理与转诊相关的医生、病床、手术室等资源的情况，需要记录医院 科室的特色，医生的排班情况，病床的使用情况等。只有具备这些信息才能确保 转诊的有效。资源管理系统将对医生、床位、设备、药品等可利用的资源之信息进 行维护、统计、调配、分析。在发起转诊请求时，可以了解资源存量的实时信息，确 保转诊成功。 医疗资源管理的主要目标是：采集参与双向转诊的医院卫生资源的信息，并 形成动态维护机制，建立医疗资源信息库，为双向转诊提供基础数据。 1285.2.4.1 双向转诊业务流程 接诊符合双向转诊指征的患者 社区卫生服务中心（站） 填写双向转诊上转单 责任医生 向患者交待双向转诊注意事项 患者持双向转诊单到定点支援医院就诊 支援医院双向转诊专职机构 安排医生接诊 患者需门诊诊治 患者需住院 患者进行门诊 安排转诊患者 诊治 住院治疗 可以转回社区 明确诊断，确定治疗 患者病情稳定符 方案，完成门诊转诊 合转回社区指征 可以转回社区 门诊医生填写双向 住院医生填写出 转诊下转单，提出治 院小结，提出治疗 疗意见及建议上交 意见及建议上交 双向转诊业务流程图 1295.2.4.2 典型业务场景  常规转诊  医生创建转诊（出）申请，并传递给自己医院的转诊协调员  转诊协调员将转诊（出）申请发送到接诊机构转诊协调员  接诊机构协调员查寻资源（如病床是否有空余，或门诊医生是否 有空余）信息，确认同意转诊  转诊（出）医院办理患者转出事务（包括结算），患者离开医院并 前往接诊机构（这里可能需要救护车接送，本系统不涉及这个，但需 要了解患者是否已经离开）。患者手持一张转诊单（最好带条码，便于 加快业务操作）  患者来到接诊机构，出示转诊单，接诊协调员确认患者达到，并 完成注册。  急诊抢救病患转诊 当病人在某医院急诊抢救时，由于医院的医疗条件限制需要转移到医疗条件和设 备先进的医院时的情况。  其他 武汉市A医院急诊抢救病患者，但A医院的医疗仪器设备比较落，而武汉市 B医院有先进的医设备，病人需要转诊到B医院，同时考虑病人病情严重复杂，为 及时抢救病患，并需要两家医院专家会诊。 5.2.4.3 设计思路 系统建设目标是在二三级医院和社区卫生服务中心之间实现院间转诊，包括 同级医院之间、社区卫生服务中心和二三级医院之间进行病人转诊，同时随着病 人转诊传递的还有病人的病案信息、检验/检查信息和健康档案信息。这里包含两 种情况：  已建CIS、LIS系统的医院，双向转诊系统提供接口，CIS、LIS系统将相应病 人病案信息、检验/检查信息和健康档案信息传递到区域卫生信息平台； 130转诊医院根据转诊要求，CIS系统自动通过数据交换平台从市区域平台的 信息资源中心获取相应病人诊疗信息和病史信息；  未建CIS、LIS的医院，直接进入双向转诊系统，填写相应病人病案信息、检 验/检查信息和健康档案信息传递到数据中心；转诊医院通过双向转诊系 统直接访问RHI区域卫生信息平台获取相应病人诊疗信息和健康档案信 息。 系统实现病人在社区卫生服务中心就诊后，经社区卫生服务中心全科医生向 二级医院转诊，病人到二级医院就诊时，二级医院的医师能够通过健康档案浏览 器调阅到该病人在社区卫生服务中心就诊时的检验/检查报告、处方和治疗信息； 并且可以查阅该病人以前的健康档案信息。同时双向转诊对于二级医院转向社区 卫生服务中心同样有效。 1) 社区转出： 如下图所示，当病人先到社区卫生服务中心进行治疗，然后转出到二级医院 进行治疗，社区医生可通过双向转诊系统提出转诊请求，同时附上病人的治 疗费用信息，当二级医院医生接受请求后，向ＲＨＩＮ区域卫生信息平台请 求该转诊病人的诊疗信息，同时可根据病人原治疗费用信息根据相关政策进 行费用减免。 病人 请求转诊病人 病史信息 RHIN 获取转诊病人 CIS系统 CIS系统 病人病史信息 区域卫生信息平 病史信息 台 费用信息 费用信息 接受转诊 二级医院 社区卫生服务中心 全科医生 向上转诊 双向转诊系统 医生 2) 社区转入 如下图所示，当病人先到二级医院进行治疗和住院，然后转回社区医院进行 131康复性治疗，二级医院医生可通过双向转诊系统提出转诊请求，当社区卫生 服务中心医生接受请求后，向区域卫生信息平台请求该转诊病人的诊疗信息 病人 CIS系统 请求转诊病人 CIS系统 诊疗信息 获取转诊病人 病人诊疗信息 RHIN 诊疗信息 区域卫生信息平 台 二级医院 社区卫生服务中心 向下转诊 医生 全科医生 接受转诊 双向转诊系统  社区医院或二级医院(以下简称“下级医院”)通过本协同平台预约三级 医院(以下简称“上级医院”)向下级医院开放的专家门诊资源；  上级医院对下级医院开放的专家门诊资源通过本协同平台可更新维护；  协同平台提供WEB方式的预约门诊页面，在页面上进行预约操作，并减 扣相应的门诊资源；  医生帮患者预约成功后，在页面上打印预约凭证；  患者需要凭预约成功的凭证，到上级医院挂号并就诊；  对转诊暂不考虑费用结算的需求；  对转诊暂不考虑信用评价的需求。 5.2.4.3.1 用户角色分析  转诊请求医生：转诊事务的发起人，医生。门诊和住院医生都可能成 为转诊（转出）的发起者。  转诊协调员：这个人类似提供窗口病人注册/就诊管理的服务人员， 负责处理转诊（入）请求事务，负责接待转诊到来的或离开的病人，即告 132诉系统“病人到了”，“病人走了”。同时这个人还是医院转诊（特别是 转入）事务的唯一指定联系人，代表医院完成对外转诊事务的处理。  医务科/处转诊审批人（可选）：有些医院的转诊，是需要医务科/处审 批的。  医保转诊审核员（可选）：根据医保政策和该患者所拥有的医保类型， 决定是否可以转诊。  转诊规则制订者（可选，高级功能）  首先，这些规则应该统一管理，比如，武汉应该有自己本地的政 策。这些规则的维护者，可以授权给系统管理员。  转诊规则可以是一段自由的文本，显示给相关的人员，让他们明 白如何正确办理转诊。也可以是结构化的知识规则，便于实现某些自 动化操作，比如提醒某患者应该转诊。  转诊监控员：政府或医院相关管理者需要对转诊事务分析，看看存在 的问题，运营绩效等。  HIS:病人管理系统ADT：负责将转诊患者登记到系统中。  HIS:电子病历系统：负责从转诊评估中获取信息，并保存到患者的病 历记录中。 5.2.4.3.2 业务用例描述(故事板) 场景 参与者 活动 获取信息 预期结果 病人在社区卫生 病人 到社区卫生服务中心 获取病史、医 在社区获得治疗 服务中心就医， 就医 嘱、检查结果、 或转诊到区域内 社区卫生服务中 转诊要求 上级医院 心医生不能确 社区全科 门诊诊疗 获取、产生病人 建立门诊电子病 诊，需转诊到区 医生 基本信息、病 历 域内上级医院， 史、诊断、医嘱、 病人在上级医院 检查检验等信息 门诊就医并入院 社区全科 转诊申请 获取病人基本信 产生转诊申请 治疗后出院，回 医生 息、病史信息、 社区随访，并接 角色：转 诊断，提出转诊 受康复治疗 诊请求转 理由，选择转诊 出医生 医院、科室 社区全科 转诊预约 通过区域平台获 产生预约申请 医生 取病人基本信 息、预约医院、 133科室、医生、时 间等信息 病人 获取预约信息 获取预约医院、 明确转诊医院、 科室、医生、时 科室、医生、时 间等信息 间 社区全科 审核转诊申请 获取转诊申请 确认转诊申请 团队负责 人 角色：医 务科/处 转诊审批 人 社区质控 审核转诊申请 获取转诊申请 确认转诊申请 部门负责 人 双向转诊 发送转诊申请 获取转诊申请 转诊申请发送到 系统 目的医院 双向转诊 接受转诊申请 获取转诊申请 接收转诊申请并 系统 提交目的医院 …… 病人 到上级医院就医 获取挂号科室、 挂号成功 医生 上级医院 挂号 获取转诊病人基 挂号记录 门诊挂号 本信息、挂号科 员 室、医生 角色：转 诊协调员 上级医院 接受转诊 获取病人基本信 转诊接受 门诊医生 息、病史信息， 角色：转 提出转诊理由 诊协调员 上级医院 调阅健康档案 健康档案 调阅转诊病人健 门诊医生 康档案信息，辅 角色：转 助诊疗决策 诊请求转 入医生 上级医院 门诊诊疗 获取、产生病人 建立门诊电子病 门诊医生 基本信息、病 历 角色：转 史、诊断、医嘱、 诊请求转 检查检验等信息 入医生 上级医院 申请入院 获取病人基本信 入院申请 门诊医生 息、诊断，产生 角色：转 入院科室、时间 诊请求转 等信息 入医生 上级医院 审核转诊 获取转诊申请及 转诊接受审核 双向转诊 本院医生接受信 主管部门 息 负责人 角色：医 134务科/处 转诊审批 人 …… 病人 到上级医院住院 住院预约病区、 入院 时间 上级医院 入院 获取病人基本信 完成入院登记 出入院管 息、诊断、入院 理人员 科室等信息 上级医院 住院治疗 获取、产生病人 产生住院电子病 住院医生 基本信息、病 历 史、诊断、医嘱、 检查检验等信息 上级医院 申请出院转回社区 获取、产生病人 产生转诊回社区 住院医生 基本信息、住院 请求，出院回社 角色：转 电子病历、出院 区继续治疗或康 诊请求转 小结、诊断、出 复 回医生 院治疗方案、随 访建议 病人 回社区就诊 出院小结、诊 获得及时继续治 断、出院治疗方 疗、康复服务 案、随访建议 社区全科 接受转回社区 获取病人出院转 及时提供继续治 医生 诊回社区请求、 疗、康复服务， 出院小结 建立医疗、随 访、康复服务记 录 本业务用例故事板描述采用了社区卫生服务中心与上级医院(2、3级医院)之 间的双向转诊特例，在实际双向转诊过程中，还存在着如下的可能性：  三级医院之间的转诊；  二级医院之间的转诊；  二、三级医院之间的转诊。 在实际应用中，还存在着双向转诊的指征控制问题，即符合转诊条件的医生 应执行双向转诊操作，这一规范属于医疗知识支持应用领域，在目前条件下不易 制定相关规范，待今后双向转诊业务成熟规范后，双向转诊规范的升级版本中采 用双向转诊指征控制规范。 (2) 业务用例图 根据上表的业务用例故事板描述，可将双向转诊的业务用例归结为： 角色 联系 用例 社区全科医生 使用 转诊申请 社区全科医生 扩展 转诊预约 135社区全科团队负责人 使用 审核转诊申请 社区质控部门负责人 使用 审核转诊申请 上级医院门诊挂号员 使用 接受转诊挂号 上级医院门诊医生 使用 接受转诊 上级医院门诊医生 使用 调阅健康档案 上级医院双向转诊主管部门负责人 使用 审核转诊 上级医院住院医生 使用 申请出院转回社区 社区全科医生 使用 接受转回社区 双向转诊业务用例图如下图所示。 <> 接受转回社区 病人 <> <> <> <> 三甲医院出入院管理人员 <> 三甲医院住院医生 <> <> <> <> 到社区卫生服务中心就医 获取预约信息 到三甲医院门诊就医 到三甲医院住院 入院 <> <> <> <> <> <> <> 门诊诊疗 挂号 住院治疗 申请出院转回社区 <> <> 转诊申请 转诊预约 <> 三甲医院门诊挂号员 社区全科医生 <> <> 审核转诊申请 接受转诊 调阅健康档案 门诊诊疗 申请入院 <> <> <> 社区全科团队负责人 <><><><> <> <> 审核转诊申请 发送转诊申请 接受转诊申请 审核转诊 <> <> <> 社区质控部门负责人 双向转诊系统 三甲医院双向转诊主管部门负责人 三甲医院门诊医生 双向转诊业务用例图 5.2.4.3.3 双向转诊参考指征 为解决群众“看病难、看病贵”问题，促进卫生资源合理利用，规范医疗行为 136建立有效、严密、实用、畅通的上下级转诊治疗渠道，需要建立双向转诊参考指证  上转参考指征 1、不能确诊的疑难复杂病例； 2、重大伤亡事件中，处置能力受限的病例； 3、有手术指征的危重病人； 4、因技术、设备条件限制不能诊断、治疗的病例； 5、由支援医院与受援社区卫生服务中心（站）共同商定的其他转诊病人。  下转参考指征 1、急性期治疗后病情稳定，具有出院指征的病例； 2、需要继续康复治疗的病例； 3、诊断明确且需要长期治疗的慢性病病例； 4、老年护理病例； 5、一般常见病、多发病病例； 6、由支援医院与受援社区卫生服务中心（站）共同商定的其他转诊病人。 5.2.4.3.4 转诊业务分析  社区医院或二级医院(以下简称“下级医院”)通过区域卫生信息平 台预约三级医院(以下简称“上级医院”)向下级医院开放的专家门诊资 源；  上级医院对下级医院开放的专家门诊资源通过区域卫生信息平台可 更新维护；  区域卫生信息平台提供WEB方式的预约门诊页面，在页面上进行预 约操作，并减扣相应的门诊资源； 137 医生帮患者预约成功后，在页面上打印预约凭证；  患者需要凭预约成功的凭证，到上级医院挂号并就诊。 5.2.4.3.5 双向转诊业务流程分析 根据第前面章节中的业务用例故事板描述，采用双向转诊业务序列图描述双 向转诊业务的流程。 见上图： 138双向转诊的业务包括以下三个过程： (1) 社区卫生服务中心转诊到上级医院； (2) 上级医院接受转诊； (3) 上级医院转回社区卫生服务中心。 双向转诊业务序列图不仅包含了双向转诊业务的时间序列流程，而且包含了 双向转诊业务流转过程中的信息流需求，保证双向转诊的信息流与业务流程同步 双向转诊业务序列图采用时间序列的方式描述了双向转诊业务中涉及的角色(医 生、病人、管理人员等)、数据对象(病史、申请表、审核表、预约纪录、挂号记录、服 务记录) 、事务(申请、预约、审核、挂号、入院、出院)之间的关系。 5.2.4.4 业务规则 双向转诊业务规则包含双向转诊业务涉及对象之间的关系、事件的触发条件 约束、以及事务处理： 5.2.4.4.1 正常情况下的业务流程 1. 病人就诊：病人到转出方就诊 2. 转出方的医生到区域卫生信息平台查阅转诊资源并填报双向转诊单，填报 成功后给病人一份纸质预约挂号单/号 3. 每工作日二次，转入方到区域卫生信息平台查阅转入为本院的双向转诊单 逐条受理，并将确认消息发送区域卫生信息平台 4. 区域卫生信息平台向病人发送短信/邮件告之预约受理结果 5. 病人到转入方履约赴诊 6. 转入方受理病人就诊，挂号并接诊，填写就诊反馈记录发送区域卫生信息 平台 7. 转出方的医生可到区域卫生信息平台查阅就诊反馈记录以及查阅预约就 诊情况 1395.2.4.4.2 预约资源维护 转入方在区域卫生信息平台上维护提供转诊的资源： - 专家姓名、职称 - 专科科别、接诊病种或科别或特长 - 接诊日期(周几)+上/下午，区域卫生信息平台自动转换日期 - 限定预约人数 - 接诊地点 - 附页：专家情况简要介绍 注：1、 “接诊日期+专家姓名”为关键字 2、限定预约人数不必按时间片划分，填一个总数即可 3、资源开放预约的结束时间是可设定的参数 5.2.4.4.3 预约资源变更规则 如遇突发情况导致预定接诊的专家时间暂停，则转入方将在区域卫生信息平台 上： – 以跳出框的形式发布停诊通知 – 将原先该医生的那条资源数据变色并标明“取消” – 要求区域卫生信息平台向已经确认的病人自动发送通知 – 封闭该医生的该条资源数据，不允许再进行预约 – 同时转入方医院人工通知相关社区服务中心的医生，由社区医生通 知到患者本人 5.2.4.4.4 提出预约的规则 转出方医生为就诊病人办理预约： – 在开放预约的时限范围内办理(例如：最早提前二周，最晚提前4小 140时)，时限为可设置的参数 – 在限定的资源数量范围内预约  其中已约人数（经确认人数待确认人数）  尚余可预约人数 – 对提示为黑名单的人了解具体情况，决定是否确实可再给予预约 – 当发生转入方资源取消的紧急情况，尽可能通知病人 5.2.4.4.5 转诊预约申请单 转出方填写的双向转诊预约申请单内容包括： – 患者基本信息：姓名、性别、年龄、出生日期、社保卡号/就诊卡号 （或其他身份证件及号码）、家庭地址、联系方式(手机、固定电话、邮箱) – 转出方信息：医院名称（哪个社区卫生服务中心及站点）、医务人员 姓名、科别、联系方式 (手机、固定电话、邮箱) – 病情简介：主述、疾病基本情况、初步诊断、转诊原因 – 目前暂不执行：以附件形式提交其他附件资料 5.2.4.4.6 转出方向病人提供预约单 转出方填报预约申请单后，向病人提供纸质预约单，内容包括（打印预约单可 在专门的服务窗口）： – 预约接诊医生、专科、职称、特长 – 预约接诊医院、地点、就诊日期与时间 – 预约就诊编号 – 预约接诊联系电话、联系电话时限 • 例如：若因故无法履约就诊，请提前通过该电话告之。 – 注意事项以及免责事项等 • 交通工具、提前多少时间、若遇突发事宜原接诊医生无法接 141诊，将更换其他医生或取消…… 5.2.4.4.7 预约受理规则 转入方安排人员每日二次从区域卫生信息平台获取转诊到本院的预约： – 上午大约8：00一次，中午大约12：00一次，根据此规则，设置预约 的截止受理时间 – 查阅预约的全部清单 – 将其中尚未经过“确认”操作的，在没有特殊原因的情况下进行逐 条“确认”操作 – 对于预约内容完全错误，或者由于资源发生了变更而导致的无法接 受预约的情况，予以“拒绝”操作 – 经过确认操作的预约条目将由区域卫生信息平台自动下载数据到 转入方医院信息系统本地 5.2.4.4.8 接诊情况反馈 转入方接诊后需要向区域卫生信息平台填报接诊情况反馈，内容包括： – 预约就诊编号 – 接诊时间，或者无履约就诊 – 接诊医生 – 接诊后安排的相关治疗措施，随访要求等 5.2.4.4.9 预约变更或爽约 • 病人可提前电话告之取消预约，转入方受理人到区域卫生信息平台对资源 进行维护，开放被取消的预约资源 • 对无提前告之且未履约的，需要在区域卫生信息平台记录，三次以及无通 知爽约则进入黑名单） 142• 区域卫生信息平台受理预约时需要核对黑名单，提示黑名单的人 5.2.4.5 功能设计 双向转诊应该包括但不限于下列功能特征：  转诊事务管理。  支持灵活的审批程序，支持自动/半自动基于审批规则的审批。  转诊病人（位置）跟踪。  临床信息共享，支持转诊病历交换，支持标准转诊通讯协议。  支持跨区域平台之间的转诊事务管理和诊疗文档流转。  医疗资源管理  电子会诊 5.2.4.5.1 转诊事务管理 转诊发生在转出医院和转入医院之间。转出医院与转入医院之间必须根据约 定的业务流程来管理转诊事务。也可以设立专门的转诊中心来审定批准病人各类 检查（物流）、病人费用、门诊还是住院、治疗还是康复、检查还是治疗、是否需要 第三方参与（病人移送、专家会诊）等。双向转诊系统必须能够支撑转出医院和转 入医院之间，或转出医院、转诊中心和转入医院之间转诊业务的管理；必须支持 统一挂号。主要的业务需求包括转诊计划的设定和转诊的相关审批。 转诊业务管理包括以下几点功能：  签约关系管理 管理医院之间的双向转诊协议并进行维护。定义和维护转诊业务流程，可根 据协议医院之间的约定定义具体病种转向具体医院，定义费用减免关系等。  转诊业务流程 根据现状，二级医院或社区医院对应的有多家协议医院，系统向用户提供了 转诊配置功能，对于不同病种可转向不同的协议医院，用户可根据需求灵活 配置。医生和医院根据设置好的转诊流程来实现病人的转诊。 143 转诊费用结算 当病人由社区转出到二级以上医院进行治疗时，根据国家政策，可对挂号费 用和其他治疗费用进行相应的减免，系统向用户提供了减免配置功能，用户 可根据需求灵活配置。 5.2.4.5.2 转诊临床信息共享 转入医院的医生能够通过健康档案浏览调阅到该病人在转出医院就诊时的 病史资料、检验/检查报告、处方和治疗信息；并且可以查阅该病人以前的病史信 息。减少不必要的重复化验和检查。 医疗信息共享系统提供了相关的病人基本信息、疾病信息、诊断信息、用药信 息、检验信息、检查信息；健康档案共享系统提供病人病史资料等。这些信息集中 的存储于卫生数据中心。 转出医生负责选择哪些病史可以供转入医生调阅。 信息调阅的机制由时间、空间、角色等因素来决定。 5.2.4.5.3 医生间、医生患者间在线信息交流 转出主治医生和转入主治医生之间在转前能够实现信息交流，互通有关病人 的情况，以便判断是否合适转到转入医院；在转诊诊疗过程中转入主治医生也需 要与转出主治医生信息交流；在转诊诊疗之后双方仍需信息交流。在线信息交流 的主要形式是视频会议、手术直播等，但是在视频会议的过程中还辅之以临床信 息。另外，医生与患者之间也需要及时的信息交流，在转诊前、中、后都需要。 5.2.4.5.4 转诊相关医疗资源管理 系统需要管理与转诊相关的医生、病床、手术室等资源的情况，需要记录医院 科室的特色，医生的排班情况，病床的使用情况等。只有具备这些信息才能确保 转诊的有效。资源管理系统将对医生、床位、设备、药品等可利用的资源之信息进 行维护、统计、调配、分析。在发起转诊请求时，可以了解资源存量的实时信息，确 保转诊成功。 144医疗资源管理的主要目标是：采集参与双向转诊的医院卫生资源的信息，并 形成动态维护机制，建立医疗资源信息库，为双向转诊提供基础数据。 5.2.4.5.5 电子会诊协作 通过视频会议、共享桌面、共享白板等方式，转出医生和转入医生可以在线 讨论病人的相关问题。同步查看病人的临床信息，共同制定治疗和检查方案。 5.2.4.6 系统接口 医疗机构间双向转诊系统与区域卫生信息平台外部系统之间的数据交换采 用基于HL7的消息接口。  下级医院通过本协同平台操作，不在医院信息系统上操作；  为下级医院信息系统提供WEB界面调用的服务接口；  调用接口时的参数除了操作地点、人员外，还需要传递患者的局域身份 标识；  患者的局域身份标识通过市级平台的PIX进行交叉索引并取得个人基础 信息在WEB界面上展示，对于初始就诊患者，交叉索引不成功时则不暂 时个人基础信息；  与上级医院的接口两种方式：人工处理方式及服务接口方式；  对上级医院的人工处理方式：  预先设定可供下级医院预约的资源数量，每产生一个预约则划扣一 份资源  上级医院可在本协同平台上主动操作获取预约单据  对上级医院的服务接口方式：  不预先设定资源数量，本协同平台对上级医院实时发送资源预约请 求，等待回复确认。仅当获取了回复确认才预约成功  上级医院不必在本协同平台上获取预约单据，而在医院信息系统中 即可直接按内部挂号的方式处理 1455.2.4.6.1 填写转诊单  功能：为系统外部提供一个填写转诊单的接口，医疗机构填写转诊单后，调用 此接口提供的接口，便可以将转诊单提交至中心平台。  参数：认证码、患者姓名、性别、年龄、档案编号、家庭地址、联系电话、转诊时 间、初步印象、主要现病史(转出原因)、主要既往史、治疗经过、转入医疗机构、 转入科室、接诊医生、转诊医生、联系电话、填写日期、转出医疗机构等。  返回值：是否成功 5.2.4.6.2 填写转诊回单  功能：为系统外部提供一个填写转诊回单的接口，医疗机构填写转诊单后，调 用此接口提供的接口，便可以将转诊回单提交至区域卫生信息平台。  参数：认证码、患者姓名、性别、年龄、病案号、家庭住址、联系电话、转回时间、 主要检查结果、治疗经过、下一步治疗方案及康复建议、转回医疗机构、接诊 医生、转诊医生、联系电话、填写日期、转出医疗机构等。  返回值：是否成功 5.2.4.6.3 获取转诊单列表  功能：为系统外部提供一个获取转诊单列表的接口，医疗机构输入查询转诊 单的条件后，调用此接口提供的方法，便可以从区域卫生信息平台获取相应 的转诊单  参数：认证码、医疗机构、患者姓名、转诊时间等  返回值：转诊单列表 5.2.4.6.4 获取转诊回单列表  功能：为系统外部提供一个获取转诊回单列表的接口，医疗机构输入查询转 诊回单的条件后，调用此接口提供的方法，便可以从区域卫生信息平台获取 相应的转诊回单 146 参数：认证码、医疗机构、患者姓名、转诊时间等  返回值：转诊回单列表 5.2.4.6.5 获取转诊单  功能：为系统外部提供一个获取转诊单的接口，医疗机构根据转诊单的ID，调 用此方法，可以从区域卫生信息平台上获取此转诊单的详细信息。  参数：认证码、转诊单ID  返回值：转诊单的详细信息 5.2.4.6.6 获取转诊回单  功能：为系统外部提供一个获取转诊回单的接口，医疗机构根据转回诊单的 ID，调用此方法，可以从区域卫生信息平台上获取此转诊回单的详细信息。  参数：认证码、转诊回单ID  返回值：转诊回单的详细信息 5.2.5 市民健康自助管理系统 5.2.5.1 总体概述 市民健康自助管理系统主要是为市民提供健康档案、个人病历、检验履历， 检验结果、健康卡等健康相关的各类资料的查询和自助管理服务。 5.2.5.2 业务需求分析 5.2.5.2.1 用户角色分析 患者：患者通过外网门户可以查询自己健康相关的各类资料，如健康档案、个 人病历、检验履历、检验结果等，方便了解自身健康状况，并对个人信息进行管理 此类用户需对个人身份进行认证后方可登陆。 147系统管理人员：系统管理员负责对内网的系统日常维护，如信息发布、用户管 理、权限分配等。此类用户根据不同的管理级别给予不同的管理权限。 5.2.5.2.2 业务需求 ①居民登录验证 居民个人诊疗信息具有一定的隐私性，而本查询系统通过Internet对外公开， 所以需要有严密的控制措施以保证居民的个人隐私不被轻易泄露。系统可考虑多 种手段识别唯一居民身份，从而得到提供服务的授权。如考虑居民签约授信方式 控制系统的安全：通过与居民签约的方式对调阅机构、调阅内容范围、时间期限 等进行授信，居民需提供个人身份信息（身份证、社保卡，如需通过网站、移动终 端访问个人健康信息，还要提供手机号码）。授信可考虑属地签约和居民意向两 种方式。并且可采用手机动态密码方式来进行访问安全认证，即居民在查询访问 时，系统自动通过短信方式发给居民动态密码。 居民登陆后可对居民查询系统中的相关登陆信息进行管理，如设置查询密码 等，进一步保护居民自身的健康信息的安全。 ②居民健康卡自助服务 该系统主要是对于本期发行的居民健康卡一些非关键基本信息，例如联系方 式、联系电话等信息，提供维护修改的途径。 ③居民健康自助管理 居民可自行输入的与健康相关的信息，如既往病史、药物过敏、生活习惯、日 常自我健康监测等信息。该类信息在展示给主治医生时，将以特殊颜色标注，做 临床治疗参考。 ④居民健康自助查询调阅 支持2种途径，一是直接以身份证或是其他就医凭证信息，登陆公众健康服 务门户的居民，只能查看其近期的检验检查信息。二是通过签约手机接收动态密 码方式登录的居民，可查看到自己完整的健康档案信息。 以查询检验报告为例，居民登陆后，可根据检验履历查询相应日期的检验结 148果，包含患者在全市试点范围内各家医院所做的实验室检验。 对于各医院的实验室检验检查报告式样，也可以考虑两种模式，一是须协商 使其具有兼容性。二是通过XML交换方式，保持与数据源头的各类诊疗报告式样 一致性。 以查询检验报告为例，居民登陆后，可根据检验履历查询相应日期的检验结 果，包含患者在全市范围内各家医院所做的实验室检验。 各医院的实验室检验检查报告式样须协商，使其具有兼容性。如下图显示患 者查询“血液常规”信息的样式。 其它基础就诊信息查询： 149⑤居民健康档案和电子病历共享权限自助维护 该项功能可以在申领新的居民健康卡时，通过填表方式，确定自己的健康档 案和电子病历目录中，哪类卫生服务记录，可以共享，共享给哪类医护人员；由受 理网点服务人员初始化录入系统。居民后期也可以通过网站或短信方式，自助修 改维护。  健康档案权限管理 居民查询系统所发布的个人健康档案信息属于患者的个人隐私信息，系统必 须对服务用户进行严格筛查，以最大限度防止隐私信息的泄漏。系统通过应用门 户的统一身份认证和相应的用户、权限管理机制确保患者信息的安全使用。系统 维护人员对居民健康档案使用者的身份的进行控制和管理，对其权限进行控制和 管理。建议健康档案的访问采用实名认证，以最大限度的保障个人隐私的安全性  日志管理 系统提供日志管理功能，记录健康档案的新增、更新和查询的日志信息，以 及用户登录、调阅的时间、过程以及调阅计算机的IP地址等信息，以备系统统计 和进行有效的追溯。  健康档案维护 居民健康门户发布的健康档案信息主要来源于内网卫生信息资源中心，居民 150健康档案发布内容的范围需经过严格的授权控制。对于门户发布健康档案的范围 系统将提供管理界面进行增加、删除等，以方便系统管理员进行适当调整。另外， 门户发布健康档案信息将通过接口的方式定时自动更新到外网数据库服务器，以 方便居民获取最新的健康档案信息，更新的频率可依据系统使用频率和实时性要 求进行确定。 ⑥居民健康自助提醒和套餐自助订阅 通过和运营商的合作，平台系统将整理、分析、评估居民的档案信息，技术上 支持依据不同情况向居民提供个性化的建议和意见，如针对不同疾病的最新诊疗 信息、防控知识、注意事项等，根据气候的变化对不同疾病的防范提醒，对不同流 行病易感人群的及时提醒等健康干预。  个人注册服务 个人注册服务分两部分，其一是门户网站注册，其二是平台注册。 门户网站注册服务，是居民通过市卫生局门户网站进行注册，形成一个个人 注册库并分配一个唯一的标识，提供给居民查询健康信息用。 平台注册服务，是指在一定区域管辖范围内，形成一个个人注册库，个人的健 康标识号、基本信息被安全地保存和维护着，提供给区域卫生信息平台所使用， 并可为医疗就诊及公共卫生相关的业务系统提供人员身份识别功能，该注册服务 主要由各医院、社区和公共卫生机构来使用，完成居民的注册功能。 平台对门户网站注册的居民和平台内的居民信息进行合并，合并后居民就可 以登录平台查询自己的健康信息。  医疗卫生人员注册服务 医疗卫生人员注册服务，是一个单一的目录服务，为本区域内所有卫生管理 机构的医疗服务提供者，包括全科医生、专科医生、护士、实验室医师、医学影像 专业人员、疾病预防控制专业人员、妇幼保健人员及其他从事与居民健康服务相 关的从业人员，系统为每一位医疗卫生人员分配一个唯一的标识，并提供给平台 以及与平台交互的系统和用户所使用。 151各医院、社区和公共卫生机构提供所辖医疗卫生人员基础信息给医政，医政 完成审核并将这些医疗卫生人员信息在平台上给予注册。  医疗卫生机构注册服务 医疗卫生机构注册服务，提供本区域内医疗机构的综合目录，相关的机构包 括二三级医院、社区卫生服务中心、疾病预防控制中心、卫生监督所、妇幼保健所 等，系统为每个机构分配唯一的标识，可以解决居民所获取的医疗卫生服务场所 唯一性识别问题，从而保证在维护居民健康信息的不同系统中使用统一的规范化 的标识符，同时也满足区域卫生信息平台层与下属医疗卫生机构服务点层的互联 互通要求。 医疗卫生机构注册服务主要由医政（卫监）来使用，完成医疗卫生机构的注册  医疗卫生术语字典注册服务 医疗卫生术语和字典注册服务，是用来规范医疗卫生事件中所产生的信息含 义的一致性问题。术语可由平台管理者进行注册、更新维护；字典既可由平台管 理者又可由机构来提供注册、更新维护。。  医疗药品注册服务 医疗药品注册服务，是用来规范诊疗过程中所使用的药品，实现新医改推进 医药分开，逐步解决“以药养医”问题的关键，同时实行药品目录注册功能，也 满足药监局对于药品管理的需要。药品目录注册服务将由卫生局会同药监局、医 保局共同管理，进行注册、更新维护。  医疗设备注册服务 医疗设备注册服务，是用来实现医疗设备的统一管理，做到全市范围内的资 源整合，同时从医管局角度也可以对下属医院的医疗设备做到充分管理，最大程 度地避免了设备的重复配置，提高资源的使用率。 5.2.5.2.3 业务流程图 1525.2.5.3 功能需求分析 5.2.5.3.1 居民登录验证 居民登录验证 描述 居民登录验证 对登录者身份进行验证 5.2.5.3.2 居民健康卡自助服务 居民健康卡自助服务操作 描述 居民健康卡信息维护 维护居民健康卡一些非关键基本信息 5.2.5.3.3 居民健康自助管理 居民健康自助管理操作 描述 居民健康信息添加 添加居民健康信息 5.2.5.3.4 居民健康自助查询调阅 居民健康自助查询操作 描述 153居民健康信息查询 查询居民健康信息 5.2.5.3.5 居民健康档案和电子病历共享权限自助维护 居民健康档案和电子病历操作 描述 居民健康档案权限自助管理 居民自助分配健康档案的权限 日志管理 记录健康档案的新增、更新和查询的日志信息 居民健康档案管理 管理居民健康档案 5.2.5.3.6 居民健康自助提醒和套餐自助订阅 居民健康自助提醒和套餐订阅操作 描述 健康自助提醒管理 管理健康自助提醒 健康套餐订阅管理 管理健康套餐订阅 短信发送管理 管理短信发送 5.2.6 医疗业务分析系统 5.2.6.1 业务概述 根据当前武汉医疗卫生信息化的现状，可以看出多数的医院内部信息系统存 在“信息孤岛”的现象，从而也就产生了相应的孤岛数据。而由于医疗卫生管理 者/业务人员自身掌握的知识和经验有限，难以从大量数据中得出有价值的信息， 从而做出判断或决策。 医疗业务分析就是从日常医疗业务中产生的数据经过统计分析能够变成对 卫生业务管理可用的信息,通过丰富的统计分析信息可以帮助管理者及时掌握医 疗卫生服务状况，并持续改进医疗质量，保障医疗安全，改善医疗服务，控制医疗 费用，为群众提供安全、有效、方便、价廉的医疗服务。 1545.2.6.2 业务需求分析 5.2.6.2.1 业务需求范围 医疗业务统计分析系统分为三大模块：医院运行基本监测指标、日常报表展 示模块以及数据综合分析模块。 （1）医院运行基本监测指标 该功能主要是依据卫生部印发的《三级综合医院评审标准（2011年版）》日常 统计学评价指标，在本期信息化能采集的范畴内，加以汇总统计分析。一般采用 两种方式，其一是按时间段展示，用于观察时序趋势；其二是按各医院展示，用于 各医院间的横向比较。 其中，主要决策指标统计的时间区间应为月度、季度、年度，也可以选择以 “日”为起点；其中多数指标还要按住院和门诊分别统计。业务统计分析系统还 可能达到下述效果：当某一指标过高或过低时，指标字体的颜色应相应改变，从 而实现的监控和预警的功能。 （2）日常报表动态展示 此处描述的报表范畴主要覆盖卫生部以及武汉市的医疗业务常用报表。通过 对静态报表和动态报表的设计和应用，有效解决了以往传统手工报表及时性差， 数据质量差的问题。另外，所有动态报表的数据源都直接采集于各家医院日常运 作中的数据，并根据预先约定的规则，有效过滤出异常值，以确保数据的有效性 和质量。 （3）数据综合分析 数据综合分析部分是指对于医疗业务用于多角度、多层次地、较为深入的统 计分析部分。它包括五大部分：疾病谱分析、疾病分布比例分析、手术分析、检验 检查分析以及治疗结果分析。 5.2.6.2.2 业务角色及权限分析 1、主要决策指标的服务对象包括： 155(1)市卫生管理机构和领导层，可以查看全市各家医院的指标数据； (2)各家医院的管理部门和领导，有权查看自己医院的各项指标数据，同时 也可查看其他医院的部分指标数据； 2、动态报表的服务对象包括： (1)市卫生管理机构和领导层，可以查看全市各家医院的动态报表； (2)各家医院的管理部门和领导，有权查看自己医院的动态报表数据； 3、数据综合分析的服务对象包括： (1)市卫生管理机构和领导层，可以查看全市各家医院的分析数据； (2)各家医院的管理部门和领导，有权查看自己医院的分析数据。 5.2.6.2.3 业务结构图 5.2.6.3 系统功能设计 医疗业务分析系统主要以各类指标分析为主，通过对医院运行基本监测指标 日常报表动态展示、数据综合分析三个反面展示系统功能。 （1）医院运行基本监测指标包括： 156编号 指标 指标内容说明 1.实际开放床位、重症医学科实际开放床位、急诊留观实际开放床 位。 1. 资源配置 2.全院员工总数、卫生技术人员数（其中：医师数、护理人员数、医技 人数）。 3.医院医用建筑面积。 2. 医疗收入 医疗总费用情况，门急诊总费用情况，住院总费用情况 1.年门诊人次、健康体检人次、年急诊人次、留观人次。 3. 工作负荷 2.年住院患者入院、出院例数，出院患者实际占用总床日。 3.年住院手术例数、年门诊手术例数。 1.出院患者平均住院日。 2.平均每张床位工作日。 4. 工作效率 3.床位使用率%。 4.床位周转次数。 每医生门急诊人次、每医生住院人次、每医生手术人次、住院者平均 5. 服务效率 占有床位数，出院者平均占有床位数，床位的使用率，科室实际空闲 床位，床位的周转率等，当前住院人数,平均住院时间； 1.每门诊人次费用（元），其中药费（元）。 2.每住院人次费用（元），其中药费（元）。 6. 患者负担 3.床日均费用 4.平均药品处方费用 5.基本药品使用次数的比值 运行监控指 系统的查询量，系统的调阅人次数，系统的调阅次数，上传数据的总 7. 标 量和正确量等； （2）日常报表动态展示主要包括： 此处描述的报表主要参照卫生部以及武汉市的医疗业务常用报表。 编号 报表类型 报表内容说明 门急诊观察室及住院动态情况的指标：门诊人次、急诊人 次、期内入院观察人数、期内出院人数、期内手术人数、实 际开放总床日数、实际占用总床日数、出院者占用总床日 数、出院者医疗总费用及其中医疗费用、期末固定实有床 1 收入报表 位。 业务收入情况指标：业务收入及其中的特需医疗收入医疗 收入和药品收入、其它收入。展示维度为患者就医属性， 可选维度为：医疗实体（医院）、年份、年内时间（最小粒度 到月）、同环比增长情况。 主要包括：诊疗总次数及急诊观察工作情况、门急诊分科 2 工作质量报表 诊疗次数、手术质量情况、诊断质量情况、住院病人动态 及病床使用情况、门诊医疗费用、出院者医疗费用等。 157编号 报表类型 报表内容说明 卫生部门医院住院病人疾病分类报表（1）~（3）（卫统5 表-1）； 3 疾病分类报表 卫生部医院出院病人疾病分类年龄别情况（卫统5表-2）； 卫生部医院部分病种住院医疗费用报表（卫统5表-3）； （3）数据综合分析主要包括： 编号 数据综合分析 综合分析内容说明 统计分析指标为疾病发生的次数，以ICD-10为准。统计分 析的时间区间为月度、季度、年度等；统计分析的患者属 1 疾病谱统计分析 性包括：性别、年龄区段等维度；统计分析包括的医疗服 务维度包括门急诊、住院等。数据来源为：就诊记录主表， 住院病历主表，出院诊断明细表。 常见疾病病例在各家医院的分布和比例情况，包括统计单 常见疾病病例分布和 2 位时间内，某类疾病病例的发生总数，分布在各家医院的 比例分析 数量，所占百分比等。 用于统计分析一定时间段内医院手术情况。手术以ICD-9- CM3中列出的项作为统计粒度，统计分析指标为手术的次 数。时间维度包括月度、季度、年度等层次；疾病维度包括 3 手术分析 主要疾病和其他；患者属性包括：性别、年龄区段等维度。 数据来源为：就诊记录主表，住院病历主表，手术明细表， 出院诊断明细表。 用于统计分析一定时间段内医院内检验、检查的服务利用 情况以及检验、检查的情况。统计指标为检验、检查的次 数，检验以《检验报告单表》中的报告单中的报告单类别 4 检验检查分析 编码为准，检查不再分类。时间维度包括月度、季度、年度 等层次；患者属性包括：性别、年龄区段等维度；疾病维度 包括主要疾病和其他；医疗服务包括门急诊、住院等。数 据来源为：就诊记录主表，检验报告单表。 用于统计分析一定时间段内住院患者的治疗结果。统计分 析指标为治疗结果发生的次数，治疗结果以病案首页中定 义的情况为准。时间维度包括月度、季度、年度等层次；疾 5 治疗结果分析 病维度包括主要疾病和其他；患者属性包括：性别、年龄 区段等维度。数据来源为：就诊记录主表，住院病历主表， 出院诊断明细表。 5.2.7 合理用药预警及管理系统 5.2.7.1 业务概述 从国内的部分探索和我市试点情况看，信息化在治理医药购销领域商业贿赂 158工作中所发挥的作用越来越重要，特别是其在业务过程中的预警及监控作用对于 实现腐败的源头防范意义重大。 开展合理用药电子预警管理工作，是推进医疗行业反腐倡廉建设科学化的重 要手段。将信息技术融入对权力运行监督制约的制度设计，达到 “不想犯错、不 敢犯错”的目标，推进医疗行业反腐倡廉建设科学化。 开展合理用药电子预警管理工作，就是为了建立起阻断医药购销领域商业贿 赂的“隔离带”，达到让医生“不想犯错、不能犯错”的目标，对端正行业风气， 规范诊疗行为，缓解群众“看病难、看病贵”将起到重要作用。 开展合理用药电子预警管理工作，是规范管理流程，强化医院医疗行为监管 的重要手段。利用各项信息技术，充分利用各项信息技术，对供应商、医疗机构、 医务人员等的用药行为过程点进行预警监控，以医疗机构业务信息系统为基础， 建立覆盖药品采供、合理使用、动态监管的系统化、常态化的医疗行为全过程市、 院两级电子监管平台监测网络体系，对供应商、医疗机构、医务人员等的用药行 为进行预警监控。对于不规范的药品采供和不合理用药行为，应尽可能做到事前 阻断和预警、源头防范达到“不能犯错”的目的，用电子监管为市民筑起药品安 全的坚固防线。 开展合理用药电子预警管理工作，是大力推进我市医药卫生信息化发展的重 要手段。建设中，需要统筹规划、资源整合，加强顶层设计、建立统一标准规范，避 免“烟囱”、“孤岛”式的低水平重复建设；既要突出服务功能，直接让患者成 为卫生信息化发展的受益者，也要完善管理，促进医疗服务成本的降低，优化医 疗服务流程，规范医疗服务与管理。 5.2.7.2 业务需求分析 5.2.7.2.1 业务需求范围 合理用药预警及管理系统将从各医疗机构采集药品的生产、配送、使用机构 以及患者的用药信息，在市级平台上要实现如下功能： 159（1）建立全市用药的基础信息管理功能。包括：药品目录、企业目录等管理。 （2）对各医疗机构、供应商、药品进行汇总、横向对比、趋势分析。包括：非招 标药品使用情况、药品采购及库存量、供应商供药量、药品消耗量排名、结构及波 动分析、药品综合加成率（差价率）分析、药品收入占总收入比例分析等。 （3）考虑到各医院的信息化建设程度不同，水平参差不齐，对于未完成院内建 设的部分单位可根据市局给出的标准规范，支持采取人工收集数据的方式形成电 子文档，通过市级卫生信息平台，进行文件导入完成网络直报。 （4）在市级平台上形成各类用药史，激活和丰富市民健康档案和患者诊疗档 案。 5.2.7.2.2 业务结构图 1605.2.7.3 系统架构设计 5.2.7.3.1 系统架构分析 系统自上向下分为平台端和医院端两个层次，依托医院信息平台和武汉市区 域卫生信息平台实现互联互通，本期主要完成平台端系统功能部分。 平台端系统：通过区域卫生信息平台采集市属医院合理用药管理所需的真实 完整、动态的数据资源，并在项目后续建设过程中建立区域医疗行为数据库、预 案库和决策支持等数据仓库，通过科学的理论方法和指标体系，分析从医院端采 集的药物进销存数据,建立区域合理用药的监控、预警和处置机制，必要时市级可 以有效干预，并提供统计分析和决策支持。 医院端系统：通过医院信息平台实时获得医院信息系统产生的业务信息，实 161现医院内部药物使用和病人医药费用等方面的自身监管和数据上报。 5.2.7.3.2 基本流程设计图 5.2.7.4 系统功能设计 本系统主要实现用户管理、权限管理、字典管理、数据质控、合理用药分析及 网络直报等功能。 5.2.7.4.1 用户管理 在用户管理方面，系统依靠各级系统管理员，对用户信息进行分级管理。  系统中默认具有一个超级管理员，具有最高的权限级别，有权创建系统管理 员用户，并为他们指派用户管理范围。  系统管理员可以在统一安全授权系统中对资源进行统一的授权管理；系统管 理员可以选择对某个角色授权，再选择需要进行授权的资源的类型，不同类型的 资源具有不同的操作；系统管理员可以指定某个角色可以对哪些资源具有某些操 作的权限。这些授权的策略信息被集中存储，并对外提供访问接口。  作为系统的管理员，无论是超级管理员还是一般的系统管理员，都只具有赋 162权的权限，而没有行使其权限规定的各种操作的权限。真正利用权限执行业务操 作的是最终的用户。当然，一个用户既可以拥有管理员的角色，也具有业务逻辑 的角色。 5.2.7.4.2 权限管理 权限管理建立系统功能、系统信息资源与具体用户的映射关系，定义不同用 户访问系统内容的范围。为了满足灵活的授权需求，权限管理功能要求提供基于 岗位、角色、用户等多种粒度的授权机制。 各系统管理员能以自身所拥有的赋权范围，自行进行用户角色定制，且相互 间互不干扰。实现由超级系统管理员根据各个组织机构应用需求，创建用户角色 并通过角色赋权，对各个组织机构中相应的系统管理员进行授权范围的规约。各 系统管理员在获得授权后，无法了解到其它系统管理员的角色创建方式，而是依 照其自身需要重新进行角色创建，并对自身所辖系统应用人员进行应用授权管理 5.2.7.4.3 数据字典 药品字典 本系统的药物目录包括：食药监药物目录、基本药物集中采购平台、医保、新 农合、医院自制药药物目录。该功能通过市级数据交换平台和各委办局或医疗机 构对接，建立起各种同步策略，及时维护和更新药品目录信息。 在市级平台端，该功能将提供维护工具平台，对药品目录字典进行字典维护， 维护的内容包括：（统一）代码、名称（通用名和化学名）、包装规格、有效时限等 信息；支持的功能性操作包括： 添加。新增一条新的药品信息； 暂停。针对已经存在的药品信息，作暂停使用处理。 废止。针对已经存在的药品信息，作废止处理即无法重新启用，但不删除记 录。 企业字典 该功能将提供维护工具平台，对企业目录字典进行字典维护，维护的内容包 括：企业名称、企业统一编码、企业分类（按资质或按规模等信息）；支持的功能性 163操作包括： 添加。新增一条新的企业信息； 暂停。针对已经存在的企业信息，作暂停使用处理。 废止。针对已经存在的企业信息，作废止处理即无法重新启用，但不删除记 录。 5.2.7.4.4 数据质控 该功能是系统后台服务功能，主要用于为数据维护人员提供异常数据的维护 手段及对异常数据的处理。 异常数据的维护： 系统无法根据现有处理规则对数据进行自动的转换、清洗时，会自动的将这 些异常业务数据和采集时间、地点、异常类型、异常数据内容、异常情况说明等信 息维护到系统中的临时库（在前置机上称为备份库），等待数据维护人员进行干 预维护。数据维护人员通过异常数据维护功能浏览、查询这些异常数据。 异常数据处理： 数据维护人员通过对异常数据的人工查看，对于不同的异常类型进行人工干 预。常用数据异常类型及处理方法包括： （1）字典异常：即数据无法在标准的元数据规范中查询到对应的字典。这类异常 通常可以由人工根据上下文来判断，之后形成数据转换规则； （2）数据范围异常：这类异常通常可以由人工通过常识来判断，对于显见的错误， 可以由数据维护人员修改同时记录数据历史状态，可以以选择退回业务单位重新 核查数据等； （3）数据冲突异常：即有多家单位报送的数据出现冲突，而又无法根据相关信息 进行处理。这类异常通常是数据维护人员无法也不能处理的，需要同时退回数据 的产生单位进行核查； 5.2.7.4.5 合理用药分析 该功能是本系统的核心，包括：药物的采购、库存量及使用情况分析。通过对 164药物采购、配备使用、报销情况等环节的数据进行分析，评价合理用药行为制度 的执行情况。 业务维度主要包括： 采供分析：包括药品采购及库存量监控、供应商供药量分析。 使用分析：基于医院信息系统数据库提供的详细诊疗数据，以医疗机构为单 位进行用药情况分析，可以根据医保药品通用名分类、商品名分类，对医院药品 使用情况进行统计，监控非招标药物的使用比例与药品及处方结构分析（种类、 金额、用量、张数），从而分析用药的合理性。 收入分析：基于医院信息系统数据库提供的详细诊疗数据，以医疗机构为单 位，从药品收入的各角度进行分类统计。系统也可以根据医疗机构下钻到科室甚 至开药医生。包括：药品综合加成率（差价率）分析、药品收入占总收入比例分析。 分析形式主要包括： 数据统计：以各类指标为单位，支持对数据进行各个层面的统计，从而实现 对数据的多角度查询，支持对基本药物制度执行情况的分析与评价。 指标分析：是监管的主要手段，系统提供计算分析、比较分析、排名分析和用 药物合理性分析等功能，其中计算分析提供基本的计算功能，实现对基础数据的 占比、增值率、累加等计算功能，通过计算实现对数据的深入使用；比较分析提供 针对不同指标时间比较、地区比较等功能，帮助用户明确各地执行差距；排名分 析提供各类指标最高、最低分析；趋势分析利用各个指标时间序列数据，观察在 一个时间段内分析指标的变化情况；提供对医疗机构和医务人员临床用药分析， 根据诊断与用药情况，分析用药的合理性。 业务报表：根据具体的监管要求进行定制，采用固定的格式组织各类数据内 容，根据业务需求报表内和报表间可建立复杂的钩稽和关联关系，通过业务报表 功能，实现对手工编制报表的自动化，在报表的格式、内容和生成周期确定后，在 时间点到达后自动生成报表。 1655.2.7.5 系统整体业务分析指标 整体业务的分析指标如下表所示： 指标 所需数据源分析 数据指标内容分析 数据来源 国家、省、市发布的药物目录及增补 药物相关信息，这些信息来源包括 药物 基本药物集中采购平台药品目录、 （1）药品目录管理、 药房药库 目录 食药监局药品目录、医保（新农合） （2）药品分类管理 系统 分析 药品目录以及医院自制药品目录。 包括药物分类、药物品种、剂型等。 企业 （3）企业目录管理（对 企业名称、企业统一编码、企业分类 药房药库 目录 企业进行统一编码、分 （按资质或按规模） 系统 分析 类等） 药物 主要包括集中采购的各药物种类、 （4）药品采购监控、（5） 药房药库 采购 数量、价格（采购、零售、实际售价）。 供应商供药量分析 系统 分析 （6）药品收入占总收入 药房药库 药品 主要包括医疗机构库存配备的药物 比例分析，（7）药品综 系统、门 收入 种类和数量及临床药物使用数量、 合加成率（差价率）分 诊收费、 分析 零售金额等数据 析 住院收费 （8）药品消耗量排名、 结构及波动分析（9）非 药品 门诊收 包括临床或住院时的药物使用品 招标药物使用监控 使用 费、住院 种、数量、类型等数据。 分析 （10）药品及处方结构 收费 分析（种类、金额、用 量、张数） 5.2.7.6 数据接口要求 （ 1 ）数据自动采集 医院： （1）医院已建或拟建医院信息平台的，由医院信息平台负责采集和整合数据，满 166足医院管理的需求。 （2）医院未建医院信息平台的，由医院以业务信息系统为基础，从医院管理信息 系统（HIS）、电子病历系统（EMR）、合理用药预警监控系统及查询统计系统等采 集数据，并进行加工、整理、分析而形成。 （3）数据提交频率每天至少上传批量明细数据一次。对于信息化程度高的医院， 推荐实时上传。 市局：基于各医院推送的药品数据，市局通过数据交换平台进行收集和汇总，并 做进一步分析和处理。 （ 2 ）网上直报 各市级医疗机构应在2012年年底前完成院内的合理用药系统建设和用药数 据自动提交工作。在2012年年底前，对于未完成院内建设的部分单位可根据市局 给出的标准规范，采取人工收集数据的方式形成电子文档，通过市级卫生信息平 台，进行文件导入完成网络直报。 5.2.8 数据质量监管系统 5.2.9 公众健康服务门户 武汉市 公众健康信息服务门户网站主要是依托所建设的公共健康信息服务门户，利 用区域卫生信息平台采集到的医疗卫生数据，为居民提供各项便捷服务。包括健 康档案查询，健康提醒及咨询，健康资讯发布，网上预约，自我健康评估和健康管 理服务等。 门户的概念用通俗的讲法来说就是“一网打尽”，是将相关使用者、相关应 用服务、相关数据访问（包括内容和访问方式）、以及统一登陆、身份认证等进行 167集成提供一门式服务的机制。 公众健康信息服务门户通过门户把各种应用系统、数据资源和互联网资源统 一集成，根据每种用户使用特点和角色的不同，形成不同的应用界面，并通过对 事件和消息的处理传输把用户有机地联系在一起。它不仅仅局限于建立一个网站 提供一些医疗服务信息，更重要的是要求能实现多业务系统的集成、能对用户的 各种要求做出快速响应、并且能对整个医疗服务网点进行统一管理。 5.2.9.1 门户网站需求 5.2.9.1.1 网站定位 本门户网站定位于高服务、高集成、高绩效的网站。以用户为中心，以服务为 向导，并为其提供大量公共服务为标志的易用型、便捷型网站。具体如下： 1、方便群众就医，优化就诊流程，减少重复检查和重复开药的现象；达到提 高医疗服务质量、降低医疗费用； 2、实现医疗卫生单位间信息互联互通及信息资源区域共享，使医生在患者 就诊时能快速掌握患者既往病史； 3、提高社会医疗资源的使用率，增强政府的监管能力和对突发公共卫生的应 急处置能力； 4、方便居民管理自己的健康档案、查询自己的健康信息等目的。 5.2.9.1.2 总体架构 公众健康信息服务门户提供基于不同角色和权限的，个性化的信息、知识、服 务与应用。它是一种基于WEB的，将不同应用、业务过程、后端系统、服务和信息 知识等内容集成到一个个性化窗口中的功能强大的工具箱、或者说系统平台。 本次公众健康信息服务门户设计的系统架构如下图： 168公众健康信息服务门户通过统一支撑平台，提供信息安全、统一身份认证、用 户权限管理、个性化服务、信息交流互动、多通道访问支持等，为各类用户等提供 个性化入口。居民健康门户将提供统一的门户管理功能，包括栏目管理、信息发 布、数据发布管理、门户网访问统计、外部信息访问，并基于此提供健康档案查询 居民健康门户服务、网上预约挂号等各类功能。 5.2.9.1.3 网站栏目设计 网站栏目构建是网站规划的重要环节，好的网站栏目能够树立网站品牌，提 高网站的社会影响力，同时，网站栏目的构建是网站开发的样本和蓝图，能够有 效地减少网站开发过程中因目标含糊而造成的重复开发，从而减少网站建设的成 本，有效地抑制资源浪费。网站栏目构建应该注重品牌，品牌栏目构建应重视栏 目的独特性、权威性和贴近性。 本次武汉市公众健康信息服务门户网站的设计主要以服务市民为理念，强化 健康服务信息，在力求提高网站信息质量、保障栏目维护力度、加强人性化服务 169的基础上，区别于其他健康网站，并突出武汉市公众健康信息服务门户网站的亮 点与服务实力。网站栏目或功能设计会在项目建设过程中根据具体用户的需求、 管理组织职能的明晰、信息化技术的进步，对所列出的栏目及具体功能模块进行 逐步增删和完善工作。 设计思路原则： 本次栏目设计紧密围绕武汉市公众健康信息服务门户网站定位，突显服务功 能，提升武汉市卫生服务品质。其设计思路上贯穿国家‘十二五’规划建议稿 “以信息共享、互联互通为重点，大力推进国家电子政务网络建设，整合提升政 府公共服务和管理能力”、 “整合、创新、服务、便捷”网站发展四个主题词以 及未来网站向“智能化公共服务平台”发展的趋势，突出“提升公共服务能力” 作为武汉市公众健康信息服务门户网站建设的使命，立足整合与提升发展策略， 充分发挥本站的作用与地位。 武汉市公众健康信息服务门户网站的栏目体系架构以打造优秀的服务型网 站为主线，深度整合医疗工作信息、业务动态和相关服务信息，全方位、多视角为 公众提供服务，体现信息时代下武汉市卫生行业履职状况的实力、活力与魅力。 其主要由三大功能与三大中心组成，具体栏目架构图如下： 【栏目架构图】 170服务功能：  政务公开 由“卫生信息、政务信息、组织机构、政策法规、专题专栏”等二级栏目组成 一级栏目 二级栏目 栏目说明 信息保障单位 卫生信息 及时发布公众关注的热点卫生信息。 各直属单位与医院 政务信息 及时发布相关通知政务信息。 各直属单位与医院 组织机构 提供本市的组织医疗机构。 各直属单位与医院 政务公开 提供有关医疗方面的政策法规及规范性文件、 政策法规 市卫生局 政策解读。 专题专栏 提供专题栏目 市卫生局 。。。。 。。。。 。。。。  网上办事 一级栏目 二级栏目 栏目说明 信息保障单位 办事制度 及时发布公众办事所需要的信息。 各直属单位与医院 办事程序 及时发布公众办事所需要的流程。 各直属单位与医院 网 上 办 事 范本展示 提供公众办事所需要的范本。 各直属单位与医院 。。。。 。。。。 。。。。  电子医疗 由“预约挂号、健康档案查询、检验检查结果查询”等二级栏目组成。 一级栏 二级栏目 栏目说明 信息保障单位 目 预约挂号 提供网上预约挂号系统 各医院 电 子 医 疗 健康档案查询 公众提供健康档案查询功能 市卫生局 。。。。 。。。。 。。。。 171 健康服务 由“健康新闻、健康顾问、健康提醒”等二级栏目组成。 一级栏 二级栏目 栏目说明 信息保障单位 目 家庭保健、生活保健、康复保健、养生保健 市卫生局牵头，各单位 健康新闻 等各类新闻资讯 配合 健 康 服 务 健康顾问（健康管理） 传染病管理、慢性病管理、疾病管理 市卫生局牵头，各单位 配合 市卫生局牵头，各单位 健康提醒 对于登陆人员提供健康提醒功能 配合 。。。。 。。。。 。。。。  卫生新风 由“组织工作、作风建设、学习园地、行业新风、文明创建、曝光台”等二级 栏目组成。 一级栏 二级栏目 栏目说明 信息保障单位 目 市卫生局牵头，各 组织工作 包括组工指要、干部工作及文件选编组成 单位配合 包括职业规范、行业纪律、民主评议、经 市卫生局牵头，各 作风建设 验交流等 单位配合 市卫生局牵头，各 学习园地 提供居民和医务人员学习资料 单位配合 卫 生 新 风 行业新风 对公众提供先进集体、先进个人的信息 市卫生局 市卫生局牵头，各 文明创建 提供各部门文明创建的信息 单位配合 曝光台 公示不良事件 市卫生局 。。。。 。。。。 。。。。 服务主题：  查询中心 由“医疗机构查询、药品信息查询、专家信息查询、医疗服务价格查询、 执业资格查询”等二级栏目组成。 172一级栏 二级栏目 栏目说明 信息保障单位 目 提供本市医疗机构和公卫机构的名称、简 市卫生局牵头，各单位配 医疗机构查询 介、营业时间、联系电话、地址、交通等 合 市卫生局牵头，各单位配 药品信息查询 基本药物目录查询、社保药物目录查询 合 查 询 中 心 专家信息查询 对各医院的专家提供分类查询，并对专家进 市卫生局牵头，各单位配 行详细介绍，如工作经验、成功案例 合 医疗服务价格查 市卫生局牵头，各单位配 提供常规医疗服务价格表（政府指导价格） 询 合 市卫生局牵头，各单位配 执业资格查询 提供执业医师和执业护士资格查询 合 。。。。 。。。。 。。。。  互动中心 由“我要咨询、局长信箱、我要投诉、健康答疑”等二级栏目组成。 一级栏 二级栏目 栏目说明 信息保障单位 目 设置在线咨询平台，并提供使用帮助、信件 市卫生局 我要咨询 回复查询服务等。 各直属单位与各医院 局长信箱 设置局长接受居民各项事务 市卫生局 互 动 中 设置在线投诉平台，并提供使用帮助、回复 我要投诉 市卫生局 心 时限、信件回复查询服务等。 市卫生局 健康答疑 提供医务人员对居民健康问题的答复 各直属单位与各医院 。。。 。。。 。。。 5.2.9.1.4 页面展现要求 武汉市公众健康信息服务门户网站在页面表现上，通常应考虑三个基本要素 内容、速度和美观。内容是最重要的，武汉市公众健康信息服务门户网站首先应 在内容上具有吸引力，包括文本信息与功能应用，整个网站页面设计都应该围绕 这些内容进行构思创作，武汉市公众健康信息服务门户网站网上服务的权威性。 另外，在确定内容的基础上，尽量提高网站速度也尤为重要，一个对用户需求能 作出快速响应的网站比设计美观却等待漫长的网站更具亲和力，更能赢得用户再 次访问。基于这两个前提，再考虑页面的美观性，以及如何通过细节修饰，从而实 现更高的网站访问量与用户满意度。 173页面框架设计： 网站页面总体要求布局平衡、页面简约、无多余空白行，主体页面稳重大方， 保持一致。首页布局应优先采用横向表格化的布局，有利于模板制作，提高页面 访问速度。 显著标示：网站所有一级栏目入口必须在网站首页明显的地方标示；一般要 在网页上部展现各个一级栏目的入口；专题性栏目可根据需要在首页显著位置上 放置链接，设为弹出式窗口、专项链接、移动图标等。 快速切换：可在任何一个栏目页面可以直接点击切换到其它一级栏目和返回 首页。 区块划分：应根据所属机构的工作特点和主要业务范围，划分相应的内容与 服务等功能区块；网站首页要明显体现内容与服务区块划分；频道设置应体现网 站内容与服务功能区块的划分。 多种表现形式：根据实际需求使用动画、视频和音频等多种表现形式。应将多 媒体内容设定为选用功能。 风格规范与视觉效果： 风格规范：网站应有统一的色彩风格、能体现自身特色，网站色调通常不超过 三种。色彩搭配应做到总体协调、局部对比。 视觉效果：建议网站尽量采用表格布局网页，避免内容出现报告罗列形式，要 注意多用表格把网站内容的层次性和空间性突出显示出来，突出网站的重点所在 尽量避免在页面上填满图像，引起视觉疲劳。 网站导航性： 所有页面从头至尾都要使用导航标识，尤其是要设置“返回到首页”链接。 如果是图像导航按钮，那么图像标识必须准确反映内容和功能；如果是文本导航 则其链接颜色最好是约定俗成的：未访问的用蓝色，访问过的用紫色或栗色。应 使文本链接，与页面上其他文字有所区分，为用户提供更为清晰、便捷的导向。  导航规范：  导航要简单、清晰，建议不超过三层的链接  用于导航的文字要简明扼要，字数限制在一行以内 174 首页和各栏目一级页面之间互链，各栏目一级和本栏目二级页面之 间互链  超过三级页面，在页面顶部设置导航条，标明位置  突出最近更新的信息，可以加上更新时间或New标识  连续性页面应加入上一页，下一页按钮  超过一屏的内容，在底部应有go top按钮  超过三屏的内容，应在头部设提纲，直接链接到文内锚点 人性化与易用性  网页人性化要求 页面尽量使用1024*768的分辨率，使其达到较佳的视觉效果；首页的图片不 宜过多，图片对网站访问速度，具有极大的影响，建议网站合理安排、有机组合页 面内容，使页面达到平衡；网站导航清晰明了，方便浏览者查找信息。  服务承诺 对服务的承诺、信箱回复时间、回复内容要求等对公众的答复方面，力求严 格按照承诺要求进行回复。  用词与栏目名称 在栏目名称、网站介绍、网站使用说明等方面，力求用词准确、权威、浅显明 了，亲和力强。  其他要求 可以根据网站的一些资源特性，开辟一些图片、流媒体等方面的信息服务内 容，也可以开辟网站的专题讲座等。 图片与文字说明  动态与静态图片 减小图形文件的大小，保证网页的传输速度。每个非首页静态页面含图片字 节不超过60K，全尺寸Banner不超过14K。在进行网页设计时要确定是否必须使 用GIF动画或Flash插件，尽量选用静止的图片或采用图像缩微图进行预览。尽量 不使用横跨整个屏幕的图像，避免用户滚动屏幕。确保动画、静态图片和网页内 容有关联，且繁体版、英文版的图片应和简体版的图片对应统一。 175 图片附属文字说明 尽量为所有图像附上文字说明，尤其是导航按钮和大图片，保证在网速慢的 情况下，或用户采用文本类型的浏览器时，也能快速了解图片所示信息。 5.2.9.2 功能需求 5.2.9.2.1 统一身份认证 身份认证是应用安全的前提，在保证了登陆的用户是合法用户，并确认了其 身份之后，才能基于用户的身份信息控制他能够访问的信息资源和业务功能。统 一用户权限管理提供的统一身份认证服务需要提供一个可扩展的认证框架，可以 按照所需要的安全级别，插入不同的认证模块，在本地实现用户的身份认证。 1、技术方案 身份认证模块用以判断用户身份的合法性。身份认证模块支持灵活的验证方 式，包括一般的基于数据库或者LDAP目录服务器的用户名、密码认证，通过扩展 可以支持基于证书的认证。 身份认证的另外一个部分是账号的管理。账号管理包括新建、修改和删除一 个账号，另外可以为某一个账号指定有效期、停用或者激活一个账号。如果需要 修改一个账号的密码，只有比该账号具有更加高级别的用户才有权限。比如说， 一般用户是没有权限修改管理员用户的账号密码。账号的每一次操作，系统都会 进行详细的记录。包括用户登陆（账号的验证），账号密码的修改，账号激活或者 停用等。 2、主要应用需求  用户注册管理 用户访问服务站点，进入用户注册页面，填写用户注册信息处理；服务站点将 用户注册信息直接上传至单点登陆服务器；单点登陆服务器对用户注册信息进行 处理，并将用户注册信息状态返回给服务站点；服务站点根据返回的用户注册状 态信息做出相应处理。 用户注册流程图如下图所示： 176用户注册服务流程图  用户认证 用户访问服务站点A，进入用户登陆页面，填写用户登陆信息；服务站点A将 用户认证信息直接发送给单点登陆服务器；单点登陆服务器进行用户认证的操作 若失败，单点登陆服务器返回用户原始登陆信息，服务站点A按照自己的规则处 理；若通过，研发公共服务平台将用户令牌标志码返回给服务站点A；服务站点A 则按照自己的授权规则进行服务。 5.2.9.2.2 用户管理 1、技术方案 在用户管理方面，系统依靠各级系统管理员，对用户信息进行分级管理。  系统中默认具有一个超级管理员，具有最高的权限级别，有权创建系统 管理员用户，并为他们指派用户管理范围。  系统管理员可以在统一安全授权系统中对资源进行统一的授权管理；系 统管理员可以选择对某个角色授权，再选择需要进行授权的资源的类型， 不同类型的资源具有不同的操作；系统管理员可以指定某个角色可以对 哪些资源具有某些操作的权限。这些授权的策略信息被集中存储，并对 外提供访问接口。  系统管理员可以把自己有权赋权的部分权限委托给其它系统管理员，也 可以把自己有权赋权的权限赋予最终的用户。作为系统的管理员，无论 177是超级管理员还是一般的系统管理员，都只具有赋权的权限，而没有行 使其权限规定的各种操作的权限。真正利用权限执行业务操作的是最终 的用户。当然，一个用户既可以拥有管理员的角色，也具有业务逻辑的角 色。 2、主要应用场景  由超级系统管理人员首先创建整个系统中最核心的也是唯一的行政组织 机构树。  超级系统管理人员将组织机构树上相应节点所对应的组织机构、和人员 账户的管理权限分配给基层系统管理员。  由基层系统管理员自行进行组织机构信息的维护。  由基层系统管理员进行用户登陆账户的创建工作。  基层系统管理员在进行账户创建时，必须先将账户链接到，核心的行政 组织机构树上。  基层系统管理员可根据用户使用的需要，将账户同其他虚拟组织机构树 进行关联。 最终实现每个账户信息必然存在于核心的行政组织机构树上，同时还可能存在于 其他由具体业务对应的组织机构树中。 5.2.9.2.3 权限管理 1、概述 由于系统用户众多，且支持系统管理员分级管理功能，如果进行统一用户角 色管理设置的话，整个系统将拥有众多的用户角色且相互含混不清，不利于整个 系统的管理工作。应此在设想中，各级系统管理人员都应具备角色制定功能。 各系统管理员能以自身所拥有的赋权范围，自行进行用户角色定制，且相互 间互不干扰。实现由超级系统管理员根据各个组织机构应用需求，创建用户角色 并通过角色赋权，对各个组织机构中相应的系统管理员进行授权范围的规约。各 系统管理员在获得授权后，无法了解到其它系统管理员的角色创建方式，而是依 照其自身需要重新进行角色创建，并对自身所辖系统应用人员进行应用授权管理 1782、技术方案 所有需要进行访问控制的资源被称为受控资源，这些受控资源必须被进行统 一管理，系统管理员在授权时需要能够看到系统中当前实际的受控资源的信息。 可以通过用户授权、角色授权进行权限设置，控制访问者对于各种资源的操作权 限。 对于权限的定义，可以概括为“一个特定的主体对某一项受控资源拥有指定 操作”，从这句话中可以看到权限涉及到三个对像，分别是：  主体（Subject） 执行权限的对象，可能为个人（某一个账号）、角色；  资源（Resource） 受保护的对象，可能是一个URL，也可能是页面上的一个按钮，或者是用 户自定义的复合指定条件的对象的集合；  操作（Operation） 定义在资源上的一类动作，比如如果是文件类型的资源，可能拥有读 （view）、修改（update）、删除（delete）的操作； 以上述说的一种普遍的情况。如果对于某一类资源只有一项操作，或者某一 类型的操作只属于某一个资源，那么关于权限的三元描述可以退化为两元。 为了集成外部应用系统的权限管理功能，需要把这些系统的用户信息和受保 护资源的信息集成进来。同时，需要在统一身份认证中心用户（简称统一用户）和 各个应用系统用户之间建立映射关系。这样在授权的时候，可以简单地只是针对 统一用户进行授权，而在具体的权限判断的过程中，需要根据受保护资源所在的 系统，利用已有的映射信息，得到相对于统一用户的具体应用系统的用户信息。 为了提供灵活的权限功能，统一用户权限管理系统需要维护一部分和权限相 关的信息，比如组织信息、角色信息、职级信息、工作代理信息等等。  角色管理 包括角色本身的维护（增加、删除、修改），和注销，还有一个主要的部分就是 维护角色和人员之间的关系。 179 工作代理管理 在实际的应用中，往往会出现有人由于某种原因（比如出差）不能履行自己的 工作。如果没有相应的措施，很多工作流程或者任务就没有办法进行。这时候可 以选择另外一个人（或者是多个人）来代理他的角色，代替他执行相应的工作（工 作代理只能是完全代理，不支持部分代理）。在这个过程中需要指定代理人的有 效期，同时由代理人执行的工作需要进行特殊的记录，以便日后查找。具体此类 记录由实际应用系统，根据权限管理系统提供相应的信息实现日志采集。  资源类别管理 统一用户权限管理，对受保护的资源进行分类，不同的资源类别一般具有不 同的操作，另外不同的资源类别也往往具有不同的访问方式。系统支持灵活的资 源类型管理，包括对各个资源类型之上的操作的维护。系统还支持按照开发和规 范注入不同的资源类型。  主要应用场景  由超级系统管理人员首先根据自己赋权的需要，创建用户角色；  由超级系统管理人员将具体的应用资源权限同用户角色进行关联；  由超级系统管理人员将用户角色以可授权权限的方式，赋予基层系 统管理员；  基层系统管理员根据自身已经获得的可授权权限，重新进行用户角 色创建，将具体的应用资源权限同用户角色进行关联；  基层系统管理员对自身所辖账户信息，利用自己创建的用户角色，进 行可用权限设置工作。 5.2.9.2.4 个性化引擎 门户网站系统提供了丰富而复杂的内容频道，例如新闻公告类有政府公告、 机构介绍、新闻活动、法律制度公告和修改；互动性功能有全文检索、意见反馈以 及网上办事等，这些内容和功能中，不是每个用户都需要，这样就要求门户网站 提供的这些内容频道或互动性功能是由用户可定制的，实现用户自己的自主管理 180可定制性是门户系统一个主要功能需求。 网站的个性化引擎可以为不同的用户提供不同的信息展示和互动的服务，改 善用户使用系统的体验，为每个工作人员提供个性化的桌面，不同角色的用户， 可以拥有自己的界面。根据用户所在的部门、用户的职位和权限，后台管理员可 以事先对门户的页面进行个性化的设置。用户也可以按照自己的兴趣，在浏览的 过程中实时地进行个性化设置。 门户网站的个性化引擎支持用户从布局、风格、结构、内容等多个方面进行 定制。它将一个用户所见的主页（page）分成以下一些元素： 其中，导航条中可以放置系统的logo，链接等。面板（Pane）类似于书签的功能， 使用户可以在多个页面（Screen）之间进行切换。页面中包括了一些Portlet，每一 个Portlet完成一个主题的信息展示或者服务交互。 用户登陆后可以对首页的Portlet的种类，首页的布局进行定制。用户还可以 对每个Portlet中的内容进行过滤，对每个Portlet的显示风格进行定义，包括自由 调整视窗的摆放位置，可对视窗标题、边框、栅格、背景等版面形式自由设计。具 体而言，用户可以：  定制整个系统的风格，包括增加、删除面板，调整面板的排列顺序，选 择面板的布局方式（如标签、菜单等各种方式），并且可以调整系统的外 衣（即显示风格，包括系统的色彩搭配、边框、图标的样式等）。  定制面板，包括编辑Portlet在面板中的显示方式、位置，当前面板的 显示风格，增加或者删除Portlet，设置Portlet的边框等。 181 定制Portlet，每个Portlet提供了定制、打印、最小化、最大化、Portlet 信息、以及关闭按钮。用户可以对Portlet进行的定制功能包括更改标题、 显示风格、以及在Portlet中显示的内容，并可以定制过滤内容的条件参 数。 另外，个性化引擎也支持用户定制自己获取信息的手段，例如通过邮件、WAP、短 信、Web Service等，而不仅仅是传统的Web页面浏览的方式。而通讯模式也由以 往的被动接受查询，转变为主动的信息推送、面向主题的信息订阅和发布机制。 从而能够更好地支持政府部门中协同办公的需要。 5.2.9.2.5 信息交流互动 信息交流互动，是通过在门户网站上建立统一的信息交流平台，应用多种信 息交互手段，最大程度的方便领导、工作人员、居民之间的信息交流。信息交流平 台可以独立作为信息发布交流平台，也可以作为模块而支撑各操作性应用和其他 高层应用体系信息交流平台支撑业务系统应用，如与居民之间的交流互动等。 应用门户网站还可提供基于手机短信、电子邮件的信息互动功能，使得门户 网站可提供各种丰富的信息互动的服务。  手机短信 手机短信息服务简称SMS（Short Message Service），是通过手机发送和接收 有限长度的文本信息的功能，1条短消息可以包括140个英文字母或70个汉字。 利用手机短信息特有的双向通信功能，可以为系统提供更好的支持，也可以为广 大市民，提供更广更好的卫生服务。 短信管理平台针对短信用户提供短信接收（MT）和短信发送（MO）两种业务：  MO业务流程 对于MO业务，用户归属地的短信中心会将短信转发给负责连接该短信中心 的短信网关，由短信网关根据服务代码和业务代码判别将请求转发给相应的SP； 若该SP为该短信网关负责连接的SP，则短信网关直接转发；若该SP非其负责连 接的SP，需向汇接网关查询路由，查询到路由后再将请求转发给负责的短信网关 由该负责的短信网关转发给该SP。  MT业务流程 182对于MT业务，短信网关根据接收用户手机号码判断其归属地短信中心，若 该短信中心由本短信网关负责连接，则直接将业务数据发送给短信中心；否则向 汇接网关查询路由，根据路由查询结果将业务数据发送给负责连接的短信网关， 再由该短信网关发给归属地短信中心，继而发送给用户。  电子邮件 电子邮件，是目前应用最多的信息交互方式之一，应用门户平台，提供安全 易用的电子邮件服务器，支持SMTP/POP3，提供Webmail的使用界面，可以在网 页上在线收发邮件, 修改密码, 进行个人设置等操作，访问门户系统的用户可以通 过电子邮件进行工作交流和信息互动。 通过门户平台提供的电子邮件服务，每个使用内部门户的用户均可拥有一个 电子信箱，可以接收、发送、回复电子邮件及超文本邮件。每个用户拥有树状的邮 箱目录，包括收件箱、发件箱、草稿箱、垃圾箱等，可以方便的管理个人的电子邮 件；提供通信录功能，电子邮件用户可结合通讯录来选择邮件地址，实现单发或 者群发邮件。 电子邮件系统还可以和手机短信平台进行挂接，实现电子邮件到达的实时提醒， 保证信息互动的内容丰富和交流快捷。 5.2.9.2.6 门户网站访问统计 门户网站的访问、维护、发布等操作，系统均有记录，门户网站的管理员可以 对历史的维护和访问信息按照关键字、时间段、信息栏目、信息类别等分别对网 站的数据进行统计，也可以任意组合这些指标对网站的数据量进行统计。通过这 些分析，为网站内容和功能的调整提供科学依据。管理员可以对网站内容进行优 化，使网站构架、内容等方面更具吸引、更出色，提升门户网站的功能。 5.2.9.2.7 健康档案查询 结合健康档案浏览器或者通过健康服务门户，可以将整合的面向公众健康信 183息（比如检验信息）通过共享的方式为公众提供查询功能，充分体现武汉市政府 面向民众的数字健康服务。 业务需求 通过将居民在每家医疗卫生机构的卫生服务数据统一采集，原先分布在医 疗机构、社区、公共卫生机构内的关于区域内居民的健康信息均可以交换整合到 本平台中的卫生信息数据中心，实现区域卫生信息资源的互通与共享，并按照 2009年5月发布的《健康档案基本架构与数据标准》所提出的三维形式进行文档 和卫生事件的组织，形成每个居民完整的健康相关信息档案，供公众调阅自己的 健康档案。 健康信息共享需要解决对居民身份唯一性的识别，并制定标准规来范健康 档案数据采集、交换、整合、调阅，着重考虑保护居民的健康隐私。健康档案展示 首页根据内容分类可划分为多个信息块。对于不同的调阅者，由于关心的侧重点 不同，所以在首页的内容安排上应该有所差异。经过对摘要信息分析后，初步整 理了一些信息块，并列出了信息块和角色的对应关系。同时，在健康档案展现调 阅时，通过技术手段，实现给不同的用户角色呈现不同的信息内容，满足不同用 户对于信息不同的要求。 除了信息共享的需求之外，由于传统的业务管理难以满足管理和决策的需 要，而管理者或业务人员自身掌握的知识和经验有限，难以从大量数据中得出有 价值的信息，从而做出判断或决策。通过辅助决策从大量数据中找出规律，利用 数学模型产生信息，为决策者提供分析问题、建立模型等，帮助管理者或业务人 员做出判断或决策。 健康档案 健康档案的概念均指包含了诊疗、预防保健等各种医疗卫生信息的与居民个 人直接相关各类文档和事件注册信息的综合内容，而不是指过去对健康档案的仅 包含居民个人健康特征/基础信息的某一份或若干份文档。根据健康档案的基本 概念和系统架构，健康档案的基本内容主要由个人基本信息和主要卫生服务记录 两部分组成。“病历”是医疗机构对门诊、住院患者（或保健对象）临床诊疗、指 184导干预的卫生服务工作记录。健康档案与“病历”既有区别、更有联系。“病 历”是健康档案的主要信息来源和重要组成部分，健康档案对“病历”的信息需 求并非“病历”的全部，具有高度的目的性和抽象性。在此文档中的健康档案结 构表述形式和概要内容如下： 健康档案展示首页根据内容分类可划分为多个信息块。对于不同的调阅者， 由于关心的侧重点不同，所以在首页的内容安排上应该有所差异。经过对摘要信 息分析后，初步整理了一些信息块，并列出了信息块和角色的对应关系。同时，在 健康档案展现调阅时，通过技术手段，实现给不同的用户角色呈现不同的信息内 容，满足不同用户对于信息不同的要求。 三维模型 健康档案的系统架构是以人的健康为中心，以生命阶段、健康和疾病问题、 卫生服务活动（或干预措施）作为三个维度构建的一个逻辑架构，用于全面、有效 多视角地描述健康档案的组成结构以及复杂信息间的内在联系。 三维坐标轴上的某一区间连线所圈定的空间域，表示个人在特定的生命阶段 因某种健康或疾病问题而发生相应的卫生服务活动所记录的信息数据集。 卫生服务记录 185由于人的主要健康和疾病问题一般是在接受相关卫生服务（如预防、保健、 医疗、康复等）过程中被发现和被记录，所以健康档案的信息内容主要来源于各 类卫生服务记录。主要有三个方面：一是卫生服务过程中的各种服务记录；二是 定期或不定期的健康体检记录；三是专题健康或疾病调查记录。卫生服务记录的 主要载体是卫生服务记录表单。按照业务领域划分，与健康档案相关的主要卫生 服务记录有： 儿童保健：出生医学证明信息、新生儿疾病筛查信息、儿童健康体检信息、体 弱儿童管理信息等。 妇女保健：婚前保健服务信息、妇女病普查信息、计划生育技术服务信息、孕 产期保健服务与高危管理信息、产前筛查与诊断信息、出生缺陷监测信息等。 疾病预防：预防接种信息、传染病报告信息、结核病防治信息、艾滋病防治信 息、寄生虫病信息、职业病信息、伤害中毒信息、行为危险因素监测信息、死亡医 学证明信息等。 疾病管理：高血压、糖尿病、肿瘤、重症精神疾病等病例管理信息，老年人健 康管理信息等。 医疗服务：门诊诊疗信息、住院诊疗信息、住院病案首页信息、成人健康体检 信息等。 文档与事件的组织 健康事件、生命周期、健康问题、干预措施（卫生活动）四种目录组织方式，按 照各类文档倒排的方式进行组织。 卫生服务、卫生事件与健康事件 主要卫生服务记录是从居民个人一生中所发生的重要卫生事件的详细记录 中动态抽取的重要信息。基本数据集是指构成某个卫生事件（或活动）记录所必 需的基本数据元集合。与健康档案相关的每一个卫生服务活动（或干预措施）均 对应一个基本数据集。 186个体卫生事件的类别标识，数据元如：产前 类别 01 检查标志、新生儿疾病筛查标志 个体卫生 个体卫生事件发生的日期/时间，数据元 42 时间 02 事件 如：检查（测）日期、产前筛查孕周、翻身月 龄、手术日期 个体卫生事件发生的地点，数据元如：分娩 地点 03 地点类别、伤害发生地点代码 健康档案索引服务全面掌握区域卫生信息平台所有关于个人的健康信息事 件，包括居民何时、何地、接受过何种医疗服务，并产生了哪些文档。 区域卫生信息平台用户在被授权的情况下，可以通过全程健康档案服务提 供的索引服务从基本业务系统查看某居民的健康事件信息，以及事件信息所涉及 的文档目录及摘要信息。 健康档案数据的存储模型以一次健康事件为基本单位，在存储上不对健康 事件进行合并和加工。在存储时系统抽取健康事件的类型、健康事件存储时间， 发生时间，事件唯一号，以及健康事件的版本信息作为基础索引。 应用功能需求： （ 1 ）登录方式说明 居民通过密码和短信等多种手段识别唯一居民身份，从而得到提供服务 的授权，查询居民本人健康档案信息。在居民登录过程中充分考虑系统登录安 全性，防止泄露居民隐私。 （ 2 ）功能需求说明  首页 健康档案查询的主要功能是展示整合后的居民卫生信息，包括诊疗、疾 控、公卫各条线的数据等，它由需要调阅健康档案信息的终端触发。展示系统 的界面首页参考如下图所示。 187 左侧目录树 左侧目录树由4个tab页组成，这4个tab页分别以“健康事件”、“生 命周期”、“健康问题”和“干预措施”作为目录树的顶层节点，底层节点均 为“文档”。各tab页的目录树完整的组织方式参考下图。 188点击各目录树的底层“文档”节点，则右侧主展示区域会展示相应的详细 文档信息，参考如下图所示。 189 自定制摘要块 在展示系统的首页右侧，点“修改显示内容”，再点击列表项中拟修改模 块最右侧的“修改”链接, 调整某个摘要块纵向或横向的位置及其展示高度。  首页数据元界定 名称 抽取字段 居民个人健康特征信息A 包括：血型、身高、体重、BMI、行为危险因素 居民个人健康特征信息B 包括：血型、职业、重大手术史、药物过敏史、行为危险因素、婚 孕产、家族遗传史、残疾情况 居民个人健康特征信息C 包括：血型、过敏史、行为危险因素、出生地、国籍、民族、身份 证件、文化程度、婚孕产、家族遗传病史、残疾情况 居民个人社会保障信息 包括：参保类型、待遇类型、伤残待遇类型、伤残待遇类型 慢性病跟踪-高血压 检测时间. 血压检测值（收缩压、舒张压）. 当前主要用药. 非药 物治疗 慢性病跟踪-糖尿病 检测时间、检测方法、检测值、当前主要措施 居民个人基础信息 包括：户籍地、户籍性质、常住地、最近联系地址、最近联系方 式、最近职业、最近所辖街道/乡镇、工作单位 亲属信息 包括：父亲姓名、母亲姓名、子女数 预防接种史 包括：疫苗名称、接种时间、医疗机构 既往主要疾病史 包括：疾病名称、确诊时间、医疗机构 体检 包括：日期、体检机构、主要异常项目 慢病随访 包括：随访日期、随访方式、随访医生、随访内容、随访机构 近期就诊 包括：日期、医院、就诊类型、科室、诊断摘要 近期住院或手术 包括：医院、入院/手术日期、入院科室、出院诊断、出院时间、手 术名称 近期用药 包括：药名、用法、用量、频度、规格、发药量、下达医院、下达科 190室、下达时间、执行时间、开医嘱医生 近期实验室检验报告 包括：报告单类别、样本、检验单位、报告日期 近期医学影像类检查报告 包括：检查类别、检查单位、检查部位、检查日期 后台辅助程序 身份整合程序 居民身份整合程序是居民卫生信息综合展示系统的一个后台支撑性的应用。 居民身份整合程序的功能是合并属于同一位居民的、来源于不同业务系统、身份 标识也不尽相同的身份信息。 数据校验转换程序 中心端数据校验转换程序是以存储过程的形式表现，它的作用是：（1）校验 上传数据是否符合产品数据底层的格式要求；（2）将中心端正式业务库的数据表 格式转换为中心端产品数据底层的格式。 首页抽取程序 展示系统首页摘要抽取程序是居民卫生信息综合展示系统的一个后台支撑 性的应用。展示系统首页摘要抽取程序的功能是将“正式业务库”中的原始业务 数据抽取、整理成右侧展示模块中所需的信息格式，并存入相应的数据表中。 目录抽取程序 展示系统首页目录抽取程序是居民卫生信息综合展示系统的一个后台支撑 性的应用。展示系统首页目录抽取程序的功能是将“正式业务库”中的原始业务 数据抽取、整理成左侧目录树所需的信息格式，并存入相应的数据表中。 查询日志管理 查询日志管理记录健康档案查询的记录日志。以及用户登录、调阅的时间、过 程以及调阅计算机的IP地址等信息，以备统计和追溯。 5.2.9.2.8 网上预约挂号 武汉市公众健康信息服务网上预约平台建设项目的总体目标是：依托武汉 市区域卫生信息平台，建立一个全市统一的网上门诊预约平台，通过提供互联网 预约服务，更好的方便患者就医，缓解看病难等就医难题。 在这个层面上，一期打算与“健康之路”实现链接，满足挂号要求。 1915.2.9.2.9 健康互动 健康互动是居民通过网络，一方面与卫生领域专家和卫生行政管理部门之间 进行互动信息交流，以能享受更便捷、更优质的卫生服务，另一方面居民也可对 卫生相关各类服务进行满意度评价，以达到居民与卫生从业人员之间的有效沟通 和互动，包括健康咨询、网上投诉、网上接待和满意度调查。 1、 设计原则 由于这些需求的功能都涉及卫生服务人员与公众之间的健康互动交互流程， 而不涉及其他业务系统的数据交互，因此设计一套互动交互体系，允许公众和卫 生工作人员通过这个平台，进行交流和响应。 由于交互的时限要求不是非常的严格，因此不采用即时响应的机制，而是采 用比较正式的BBS公告板机制，保证互动的信息可以长期在线保存，方便后续浏 览者能及时获取已知的信息。 为防止出现意外情况，防止未获授权的用户通过互动机制发布不恰当的、或 者是不雅的甚至是反动的、不合法的信息，在系统设计时，对用户认证采用比较 严格的实名认证机制，以确保互动交流秩序的正常。 2、 功能说明 1) 健康咨询 市民通过公众健康服务系统发起健康咨询请求，简单请求可通过系统自动应 答（系统可根据事先设好的各类指标规则，自动给出简单建议），复杂请求由医务 人员（专家）或者管理人员捕获到后，进行及时响应。此项服务内容需卫生管理单 位指定专人负责。 2) 网上投诉 市民通过公众健康服务系统，进行网上投诉。卫生管理人员发现投诉后，登记 并告知市民投诉已被受理，然后启动内部调查处理程序，处理结束后将处理结果 公示并反馈给投诉市民。 3) 局长信箱 市民过公众健康服务系统，与卫生局局长通过局长信箱，进行比较便捷的交 192流，提出疑问及意见；卫生局局长针对市民意见进行解答。另外，可依据前期实时 交流的效果和需求灵活调整网上接待的频率。 3、 功能使用 1) 使用系统  发起主题：供用户在BBS系统中发表一篇评论、文章或发起对某一问题的投 票。  回复主题：用户在查看了其它用户发表的评论之后，可用此功能回复用户的 评论或投票。  精华列表：查看BBS系统中的所有被归为精华的用户主题。  锁定列表：查看BBS系统中被锁定的用户主题。  热门列表：查看BBS系统中被归为热门主题的用户主题。  查看公告：查看管理员在BBS系统中发布的公告。  搜索主题：用户可在此搜索坛论中的某一主题。 2) 个人事务  基本信息查看：查看自己在BBS系统中的帐号的个人人信息。  基本信息维护：可以修改自己在系统中的个人信息。  个人积分查看：查看自己的帐号在BBS系统中的积分情况。  我发起的主题：查看自己在BBS系统中所发起的主题。  我参与的主题：查看自己在BBS系统中参予的主题。  我的收藏：查看自己在BBS系统中收藏的主题。 3) 信息管理  审核信息：管理员可通过此功能审核用户新发表的信息  综合查询：在此管理员可通过不同的查询条件找到用户发表的信息。  查看无效信息：在此管理员可查看被设为无效的信息，并可以将其设置为正 常。 4) 公告管理  添加公告：此功能供管理员添加一条公告。以便发布到BBS系统中。 193 发布公告：管理员可在此管理已发布的公告或发布新公告。 5) 上传管理 经过授权的用户可以在BBS系统上上传文件，用于佐证或者其他特殊需求。 允许上传的文件包括：  图片：管理员可在此管理用户在BBS系统中上传的图片。  Flash：管理员可在此管理用户在BBS系统中上传的flash。  视频文件：管理员可在此管理用户在BBS系统中上传的视频文件。  音频文件：管理员可在此管理用户在BBS系统中上传的音频文件。  其他文件：管理员可在此对用户所上传到BBS系统中的文件进行管理，这些 文件有可能是压缩文件或脚本文件。 6) 系统管理  参数设置：在这里，管理可重置坛论的一些属性、参数，以满足当前的需求。  用户查看：管理员可在此查看BBS系统中的所有用户信息。  用户签名审核：管理员在此审核BBS系统中所有用户的签名。  指定版主：给BBS系统指定一位管理者，管理者可以是用户也可以是管理员。 5.2.9.2.10 个人增值服务 在平台采集、整合各类居民健康信息的基础上，可考虑针对于居民个人的增 值服务，包括健康门户短信接口、健康提醒及健康分析报告等。个人增值服务需 要卫生专业人员对已采集居民健康信息进行梳理、分析健康知识，进而给出专业 的分析或指导意见，因此建议在区域卫生信息平台建设比较成熟的时候推进此服 务，并需考虑相应的运营模式。 1、 健康门户短信接口 居民可通过短信方式，订阅主动获取感兴趣的健康咨询、健康小常识及法律 法规信息等，系统也可根据居民的健康状况主动发布相关的健康指导知识。 2、 健康提醒 居民登录公众健康信息服务门户后，门户主动提醒居民查看健康分析报告。 并根据健康分析报告，结合医学经验给出健康提醒和建议。 1943、 健康分析报告 公众健康信息服务门户依托区域卫生信息平台的居民健康档案进行数据分 析，依据居民各自健康状况，得出其相应健康分析报告供参考。如针对慢病、妇幼 等特殊人群或疾病高危人群：依据其健康档案信息，分析健康状况，并提出合理 建议。 5.3 医院前置软件系统 本期开发实施的医院前置系统，将要实现如下功能： （1） 数据采集管理：实现数据采集过程中的监控、交换传输策略配置、日志等 功能。 （2） 数据映射和转换：实现对从医院端业务系统中抽取的源数据根据数据交 换中心确定的数据标准的要求，进行数据的检查、合并、拆分、汇总等处理。 （3） 数据交换标准化控件：实现嵌入客户端应用的数据交换控件，要求支持 服务或消息等方式。 （4） 服务集成、消息集成：实现交换节点间采用服务调用或消息传送的方式 完成彼此间数据的发送和接收。 （5） 数据上传和下载管理（支持数据加密）：实现数据双向交换、异步/同步传 送以及数据传输过程中的加密、解密和完整性。 1955.3.1 功能流程 说明：  医院系统接入机构按照数据接口标准中的相关数据接口准备数据， 然后使用转换程序按照相关XSD描述生成XML，并调用CA中心提供 的签名程序对XML签名并生成含签名值的XML后，使用文档注册程序 把含签名的XML注册在前置机。  前置机首先会验证文档签名，签名通过后还会验证XML结构和部分 信息是否符合接口描述要求，如通过后返回机构文档注册程序成功标志 表明此文档顺利提交，否则返回失败及失败原因，医院接入机构文档注 册程序接收到错误信息后，根据错误信息代码及描述，对文档或数据重 新处理后再次提交，直到成功。 196 区域平台数据中心获得数据后，进行相关解析、验证、清洗等处理，如 果发现数据错误会进行数据反馈，正确的数据将保存至对应的数据库中 5.3.2 设计思路 为了实现电子病历共享及业务联动的目标，需要在武汉全市加强对所属医院 临床信息系统的建设力度。对已经建立了比较完备的数字化医院着重于进一步提 升应用集成、成本核算、临床辅助医疗决策的水准。对于尚未建立数字化医院系 统的医院，以实现本项目的上述目标为契机，部署配置统一采购的相关业务子系 统，促进医院数字化程度的水准，提高医疗服务质量和效率，改善就医环境。这些 相关业务子系统是以医生工作站和电子病历为重点的CIS（临床信息管理系统）、 LIS（实验室信息管理系统）、RIS（医学影像检查报告信息系统）、PACS（影像图像 储存和传输管理系统）等。 另就市级信息中心而言，需要针对各级联网医院进行信息系统改造与接口建 设，配合数据中心完成如下内容： 1. 对医院内HIS与CIS、LIS各子系统尚未实现数据内部交换的医院，实施最 为基本的能够对就诊患者、医生等基本对象的数据接口交换。即先尽快 完善HIS-LIS-RIS-CIS之间的内部接口。 2. 解决医院内部对市民一卡通、医保卡、社保卡、新农合卡或身份证号作为 就诊全过程对患者个人在各个功能子系统中的唯一索引机制。就诊卡、 医保卡、社保卡和新农合卡的使用是根据就诊患者在就诊（门诊或住院） 时挂号或入院登记时由患者自行依据条件选用的。身份证号是作为候选 的可能并不唯一的身份识别编号，通常在住院登记时可以获得。市民一 卡通是指将在武汉所辖范围内统一了编码规则，不会导致重复的磁卡。 3. 增加将有关数据提交上传武汉市卫生数据中心的流程和功能。  门急诊就诊过程（含诊断、处方、收费等）、实验室检验结果、住院病 案系统内容提交上传。  卫生资源信息提交上传。 1974. 对于已经提交上传的数据，若发生了不得不修改的情况，需要按照修改 的标识再次上传。 5. 完成健康记录浏览器的嵌入改造。 1986.项目需求 4-标准规范设计 标准规范体系的建设目标是通过标准规范的建立和实施，消除卫生领域信息 化建设中存在的“信息孤岛”现象，集中整合辖区范围内各医疗、卫生机构和卫 生职能部门的数据信息资源，并在此基础上，统一构建面向区域内医疗、卫生机 构的数据采集、整合共享；全面提升区域内卫生信息化管理服务水平。 在信息资源整合的过程中，标准化还能确保卫生信息系统与相关机构的互联 互通和信息共享。同时也能使信息化建设的投入资源得到充分利用，加快建设步 伐。另外，业务上的标准化还可以从业务的角度让所有的信息交换的参与者之间 在业务数据的定义、共享方面达成一致。 目前在卫生行业的范畴内，已建设有大量的信息化系统，这些系统即相互独 立又互相关联，系统之间的数据共享与交换成为推进信息化进程的瓶颈。与此同 时，由于各个医院采用不同的HIS、CIS、LIS、RIS、PACS等系统，要完成数据采集就 必须约定各个系统数据交换的标准。必需站在整体的高度，充分考虑与其它系统 以及后继系统之间的信息关联，设计好相互之间的信息接口。信息标准是信息化 建设的基础工作和信息交换与共享的基本前提。数据规范、指标代码体系、接口 标准都应该遵循国家和行业规范要求。 标准化建设，是卫生信息化建设的基础工作，也是进行信息交换与共享的基 本前提。在本次项目的建设中，必须强调“统一规范、统一代码、统一接口”；必 须规范卫生各领域信息化建设的基本功能、业务流程、数据模型和数据编码等信 息标准，逐步满足信息化建设的需要。 我们在本次项目的建设中，将充分满足招标文件对标准规范建立的要求，在 信息资源整合的过程中强调标准化，确保卫生信息系统内部及相关机构的互联互 通和信息共享。同时使投入信息化建设的资源得到充分利用，加快建设步伐。另 外，业务上的标准化将可以从业务的角度让所有的信息交换的参与者之间在业务 199数据的定义、共享方面达成一致的意见。 标准规范的建设是一个系统工程，也是一个需要延续的工作，本期项目就标 准化工作，建设内容主要包含： 标准化文档 （一）系统功能规范 ： 1 《基于电子病历的医院信息平台系统功能规范》 2 《武汉市级区域卫生信息平台功能规范》 3 《武汉市区两级卫生信息平台功能规范》 （二）平台接入指南 4 《武汉市市级区域卫生信息平台服务接入指南及评估标准》 （三）居民健康卡补充规范 5 《武汉市居民健康卡补充规范》 （四）分类和编码标准 6 《武汉市市级区域卫生信息平台数据元值域代码标准》 （五）数据交换标准 7 《武汉市市级区域卫生信息平台数据交换接口标准规范》 （六）信息共享标准 8 《武汉市电子病历和检验检查结果共享规范》 （七）业务和管理规范 9 《武汉市双向转诊业务实施规范》 10 《武汉市公众健康服务门户实名制认证规范》 详细的标准文档，请参考附件。 2007.项目需求 5-非功能性需求 7.1 用户界面规范 网站页面要求设置简洁、大方，网站LOGO需要结合武汉市特点进行设计，页 面各功能块标题醒目、图片美观，需建立 登陆模块、信息发布模块、挂号、预约和互动模块。网站必须公开管理单位的 联系方式和地址，方便群众反馈意见和建议，做到定时更新、定期建设，实现与居 民之间良好的沟通和互动。 7.2 运行环境 核心数据库服务器： 数据库： Oracle 11G 操作系统： SUSE Linux Server 10 WEB服务器： 中间间： Websphere 7 操作系统： SUSE Linux Server 10 应用服务器： 操作系统： Windows2008 应用软件： CA应用服务 IBM Message Break IBM Cognos 10 数据交换前置机： 数据库： MS_SQL2008 操作系统： Windows2008 2017.3 性能需求 系统软件技术指标如下：  系统平均无故障时间应大于1万小时；  系统故障恢复时间为：小故障1小时内恢复，大故障6小时内恢复；  系统处理能力下降到20%的时间每年应小于20分钟；  在98%的时间内系统处理能力均大于90%；  系统同时可接入的查询数应大于1000；  数据传输、处理应有检验、核对功能和较强的纠错能力；  内部数据查询应对不同的人员设定不同的权限级别，每人只能查询 与自己有关的数据；  终端响应速度：<3～5秒；  峰值响应速度：<10～15秒  在不考虑网络带宽的前提下，当1000用户同时操作平台数据时，下传 患者基本信息必须在1秒内完成，调阅病案信息必须在3秒内完成，调 阅检验信息必须在5秒内完成，调阅影像信息必须在10秒内完成。 7.4 性能需求 7.4.1 数据精确度 按照严格的数据格式输入，否则系统不给予响应；查询时要保证查全率，所 有包含查询关键字的记录都应能查到。 7.4.2 运行效率 开发的软件系统应能达到特定的运行速度；能达到数据的浏览、各种处理、 查询统计等日常工作的响应要求，且该速度需要依赖硬件能力；能整体提高业务 处理的工作效率。 202本系统运行时，对系统硬件资源的利用率要合理，避免占用过多系统硬件资 源，避免过于频繁的硬盘访问等，提高整体运行速度。 7.4.3 响应速度 系统对于涉及数据量不大的用户操作可以进行感觉及时的响应，对常规操作 要求软件没有明显的停滞。 对网络流量予以事先估计，根据硬件能力限制网络会话的最大数目，保证网 络服务质量。 7.4.4 异常处理 系统的正确性是指系统本身无错误，它能在未来的软硬件环境下正确地完成 所期望的数据输入、管理、查询、信息处理、信息输出以及辅助管理等各项功能。 系统的健壮性是指在不合理的操作（如：命令错误、输入超界数据、所提供的 参数不合理等）情况下系统给出错误信息后转到预先规定好的错误处理程序处理 运行。 系统软件设计、开发时，要求对各种可能存在的数据错误、操作错误、输入错 误、各个组件之间信息交换中出现的错误等予以充分估计，并分析和罗列错误种 类和范围。 7.5 安全性需求 本项目在建设过程中对整体安全性的需求如下： 1. 数据调阅对安全的需求  身份认证的需求；  角色授权的需求；  责任认定的需求； 2032. 应用系统对安全的需求  单点登录；  统一授权；  应用审计； 3. 数据库对安全的需求  访问控制；  数据备份/恢复；  日志管理； 7.6 标准化需求 7.6.1 异构系统的需求 由于各个医院采用不同的HIS、CIS、LIS、RIS、PACS、CHSS的系统。要完成数据 采集就必须约定各个系统数据交换的标准。 7.6.2 数据标准管理的需求 数据标准描述了在设定背景下使用的数据的预期含义和可接受的表示形式。 数据含义的一致性对数据在直接应用和二次使用者之间的共享非常关键，数据开 发的大量工作是数据标准的制定，以保证从不同数据采集系统获取的数据的可比 性和一致性。如果不需要共享，就没有必要进行数据标准化；一旦需要共享数据， 就必须保证数据的所有用户都能清晰地理解数据的含义，无论数据采用何种收集 方式和储存在何处。  避免数据定义的重复和限制数据定义变异 过多的变异可导致数据无效或阻碍其有效性。当卫生信息在不同机构和系统 之间交换时，数据标准提供了限制这种变异的一个途径，使各种来源的数据能够 204互相协同。  降低数据开发的成本 数据标准提供了解决特定问题的途径，相关用户可以直接使用而不用自己从 头做起。数据标准为所有机构提供了一个通用的、一致的平台，因此，有利于本地 和国家成果的复用。 7.6.3 权限分析 1. 普通用户：不同类型的卫生信息标准的使用对象可以对数据元进行浏览 和查找，如卫生信息的采集者、信息系统和数据库的设计者、卫生信息的 使用者。 2. 授权用户：拥有卫生局授权的用户可以对数据元进行著录操作，用于提 交和注册新的数据元。 3. 数据元管理员：用于对数据元的审核。 4. 注册机构：负责将管理员审核通过的数据元进行标准化，可以使数据元 标准化或者使数据元失效。 7.7 运维需求 为了保证项目的顺利实施和发挥它的作用，系统运维是很重要的一个方面： 7.7.1 保障系统稳定高效运行 保障系统的正常运行、减少问题出现、问题实时处理、系统优化，将是维护 工作中主要工作内容，  减少问题出现 武汉区域卫生信息平台是一个庞大而复杂的系统，涉及的技术多而 且细，故障点多，给维护工作带来很大的困难。高效的维护是在故障发 205生之前，找到问题、解决问题隐患，而不是在问题出现之后去解决，规避 问题将是维护工作难点，是维护工作的重要内容。 系统的运行过程中，通过日常的监测工具、定期的系统检测，丰富的 工程师维护经验，对系统中可能出现的问题进行提前排查，排除系统中存 在的问题隐患，避免事故的发生。  问题实时处理 系统运行中，问题随时可能出现，快速、优质的处理问题，避免问 题的扩大， 将损失降低到最小，保障系统应用的继续进行，是对维护队 伍工作能力、素质高低的考验，也是维护工作的主要工作内容。 对系统中发生的问题进行实时处理，对重大事故做到及时汇报，提交 相关的故障报告，对技术难点不能及时解决的问题反映至公司，调配相关 各类资源，全力保障故障的处理。  系统优化 系统升级和调试阶段，会有一部分功能设计和系统的实际应用有一 定的出入，通过实际业务的调研、系统的进一步使用，尽早的发现这些设 计中考虑不周全的地方，通过实践进行系统各方面优化，让系统更好的满 足应用，是维护工作中一个必不可少的工作内容。 7.7.2 保障数据的安全和保密 保障系统安全的最终目的是保障数据的安全，而且随着应用的推广，数据的 存储量将会越来越多，对业务的正常开展所起的作用也越来越大，保障数据的安 全和保密，保障院内工作的顺利进行。  数据有效存储、备份 206对日常所采集数据进行有效存储，对重要数据进行多介质、多场所、定期备 份，对备份介质进行专人保管，制定完备的数据备份策略，建立完整、有效的数据 存储、备份管理制度，为院内业务的正常运行提供可靠的保障。  数据快速恢复 定期对存储、备份的数据进行可靠性检测，制定完备的数据恢复操作规范， 一旦出现数据故障，用最快速度恢复数据，保障院内业务的正常运行。  数据保密 建立维护人员安全保密规范，进行操作授权管理；保障数据传输平台的安全 性，保障数据传输过程中无丢失、损坏，系统的使用过程中，对院内数据进行人员 访问权限设定，建立详细、全面数据保密制度。 7.7.3 保障系统安全运行 随着平台的应用不断展开，系统的安全性将是影响系统正常运行的一个关键 性因素。保障系统安全运行，即保障系统内相关的和配套的设备、设施（含网络） 的安全，运行环境的安全，保障信息的安全，建立合理的系统安全管理制度和保 障体系，保障系统功能的正常发挥，以维护系统的安全运行。 2078.项目需求 6-接口需求 根据对本项目所采集数据的分析，接口主要包括16家医院、14个医院（合理 用药系统数据）、8个区卫生局信息平台，涉及到EHR数据标准与信息交换标准、 EMR数据标准与信息交换标准、医疗机构信息系统接入标准等内容。数据接口的 具体内容和接入标准，对应标准规范建设中的医疗资源信息共享标准、卫生管理 信息共享标准、医疗机构信息系统接入标准、区级平台系统接入标准等标准规范 的内容。 8.1 试点机构数据接口 8.1.1 医院端提交数据的方式 医院提交以及中心采集的数据流如下图所示 ： 试 前 中 点 置 备份库 心 单 端 端 位 原 数 原 始 据 始 数 传 数 据 输 据 整 交 提 合 换 交 处 处 理 理 暂存库 内部业务库 前置库 上传库 在具备运作条件的前提下，医院提交数据的方式为定时批量式的。定时批量 208式提交采集数据将包含除部分字典数据外的其他全部采集内容。 定时批量式地提交采集数据，要求医院内部信息系统自动生成数据并定时批 量提交到前置机中约定的发送文件缓存区的相应数据表中。特别需要说明的是： 医院内部信息系统在编制提交采集数据的程序逻辑时，不要将提交采集数据的操 作逻辑嵌入到医院内日常医疗业务流程中，即不要将提交采集数据成功与否作为 日常医疗业务流程是否可继续流转的必要条件。而作为一个单独的处理程序逻辑 予以定时单独运作。 在部署前置机时会建立数据库管理系统，并预先创建各数据表的表结构。这 些预先建立的数据表分为两类：发送文件缓存区和接收文件缓存区，所有的表根 据功能的不同向医院内相关信息系统开放不同的读写权限。在提交数据时，医院 信息系统需要按照数据采集时点要求，定时批量的将生成的采集数据填入对应的 数据表内。 由医院提交到前置机发送文件缓存区的采集数据，由部署在前置机中的医院 端数据交换平台自动进行整合、上传等一系列工作。对发送文件缓存区内的存储 空间释放工作，也将由数据交换平台在完成了上传之后的若干时间之后自动进行 医院端提交数据的程序，要确保支持按时间段和业务域提交数据的功能，要 确保在断电或断网的情况下，支持数据重传的功能。 8.1.2 前置端数据反馈与处理 前置端由万达部署数据质量控制应用，用户分为两类：医院数据接口厂商和 医院数据质量控制专人。其中数据自检提供给医院数据接口厂商，自行调用此功 能，对上传到数据接口中的各类业务数据，进行数据情况自检。通过前置端数据 质控应用系统，可以查看自检的结果，包括如下信息：  数据自检应用是否通过  按照“数据提供单位”，“数据接口表名称”进行分类汇总。各数据 提供单位各数据接口表所插入数据的，记录总量、校验通过记录量，校 验异常记录量、校验严重错误量、校验警告错误量等 209 对各类校验严重错误、校验警告错误进行分类展示。在提示存在相应 异常错误的记录总量的同时，对部分错误记录的相关信息进行摘录汇 总  对具体某个校验严重错误、校验警告错误相关的错误提示记录进行详 细展示。 生成的处理日志保存在前置端的数据接入区中，且只保留最后一次的数据 质量自检结果。这样有利于接入单位针对接口程序进行调试，直到符合数据上传 的要求。 医院数据质量控制专人负责每天对本单位数据上传情况进行巡检，牵头上传 数据问题的解决。通过前置机端数据质控应用系统，可以查看如下信息：  按照“数据提供单位”，“数据接口表名称”进行分类汇总。各数据提 供单位各数据接口表所插入数据的，记录总量、校验通过记录量，校验 异常记录量、校验严重错误量、校验警告错误量等  对各类校验严重错误、校验警告错误进行分类展示。在提示存在相应 异常错误的记录总量的同时，对部分错误记录的相关信息进行摘录汇 总  对具体某个校验严重错误、校验警告错误相关的错误提示记录进行详 细展示。  根据前置机核心区域中所保存的历史数据，依照指定业务发生时间、 指定接口数据表或数据域这两类参数进行数据重新发送。  备份数据恢复、已有数据清除。 根据前置机端数据质控应用系统提供的功能，能够帮助医院数据质控专人快 速了解数据上传的情况、问题的锁定和问题的解决。 8.1.3 中心端数据反馈和处理 市区域卫生信息平台通过中心端的数据质控应用，将把采集数据的处理结果 通过系统的内部网站向医院发布，医院也可以到中心端数据质控相应的页面中对 210处理结果进行查询。发布的处理反馈结果包括如下信息：  日期、时间、处理的数据表、提交数据条数、提交处理成功数据条数、未成 功处理数据条数。  未成功处理数据的内容和未成功的原因。 医院需要根据处理反馈结果查找原因，在解决了存在的故障之后，对未成功 的数据再次进行提交操作。 8.1.4 数据交换形式说明 目前阶段，全国的卫生信息化在区域级大型规模的联网项目建设方面仍旧处 于起步阶段，国家层面已发布的规范标准仍有不健全的地方，而且，即便对于已 发布的有关说法实际上大多仍处于书面阶段，可行性尚未经过项目实施的验证。 作为项目建设首要的是实现整体上的业务目标，以此为前提，尽可能逐步向国际 行业的规范靠拢，同时也为形成本地行业的规范标准作出探索并打下基础。 为此，在目前项目实施阶段，对于各接入单位向市级中心提交共享用诊疗文 档的技术方式，本规范界定了三种方式供各接入单位根据各自的实际情况作出最 适合的选择。市级中心端可以根据各接入单位作出的选择而进行针对性处理，目 的是尽可能为各接入单位提交共享用诊疗文档提供方便。 8.1.4.1 全XML文档格式 参考HL7 CDA国际行业规范的思路，按照国际行业对诊疗文档通常的处理方 式，将文档归为“文档头”与“文档体”两个部分。文档头（注册类信息）包括服 务对象身份标识、地点、时间、文档内容类型等以可分析计算为主数据信息。文档 体包含的是文档详细内容，其中采用代码化填报的则可进行计算，否则属于可阅 读的，采用格式化文本文字填报的则可进行基于文字内容的搜索。 此方式是指，各接入单位提交给市级中心供共享用诊疗文档的文档头与文档 体均采用XML的格式。 2118.1.4.2 全数据库中间表方式 当前的现实情况是，实际上各级各类医疗卫生信息系统之间通常仍旧是采用 数据库中间表来进行数据交互的。这种方式对于诸多服务商在实施上是比较方便 的，理解上是比较容易的。但其缺点是对内容的可扩展性和灵活性会具有相当大 的局限性。如果有接入单位对本规范推荐的数据库中间表在内容和格式上认为有 其个性化调整要求的，可以直接提出，我们可以进行针对性的适应性调整。 当接入单位采用推荐的数据库中间表格式进行文档提交，则不必再将各个文 档按照文档头+文档体的方式进行信息化处理，有关的文档头信息将可以由市级 中心端进行归理和抽取。 8.1.4.3 XML文档格式与数据库中间表混用方式 指并不是全部采用数据库中间表，也不是全部采用XML文档格式，而是对于 文档头采用XML文档格式，但文档体的内容采用数据库中间表，或者是相反，即 文档头采用数据库中间表，文档体采用XML格式。相对来说，由于文档体的内容 比较灵活，如果采用XML格式则在应对将来的灵活变化上更加有利。文档头的内 容相对比较确定，灵活变化的可能性相当小，所以即便采用数据库中间表也无妨 对于文档头采用数据库中间表的推荐格式，本规范暂不进行界定，待有接入单位 提出比较明确的意向后可以增补。 8.1.5 接口数据集概述 本接口数据集主要包括业务运营数据集、临床诊疗记录数据集、合理用药数 据集、基础字典数据集。业务运营相关数据是指医院在医疗服务主营业务方面的 业务量、业务收入数据。临床诊疗记录相关数据主要包括服务对象信息、就诊事 件信息、诊疗报告等。合理用药预警及管理系统将从各医疗机构采集药品的生产 配送、使用机构以及患者的用药信息。基础字典相关数据包括医院科室字典、医 护人员字典、明细项目字典等。 2128.1.5.1 业务运营数据集 业务运营相关数据是指医院在医疗服务主营业务方面的业务量、业务收入数 据。这些数据将仅被用于计算绩效报表中的指标。依据目前区域医疗卫生数据中 心提出的对医院业务运营统计分析的需求，所采集的医疗主营业务数据集中在医 疗机构的业务收入和业务量上，并且在此基础上经统计分析得到绩效方面指标值 需要采集的数据被划分为6个中间表，分别为：挂号、诊疗收费、入院登记、 出院登记、在/出院结算、以及手术记录，分别对应医院内HIS中的相关业务表。 对于具有异地联网分院（分部）的，但统合其分院数据一并填报的情况，依据 管理部门对业务统计的需求，可通过填报医疗机构代码将分院的数据加以区分。 8.1.5.2 临床诊疗记录数据集 临床诊疗记录相关数据在数据逻辑上共可分为三类，共九个对象。第一类：服 务对象信息。目前包括患者基本信息。第二类：就诊事件信息。目前包括门诊就诊 信息和住院就诊信息这两个对象。第三类：诊疗报告。目前包括实验室检验报告、 医学影像检查报告、住院病案首页主体报告、手术明细报告、诊断明细报告、出院 小结报告这六个对象。 上述九个对象之间的关系在下图中以黄色箭头表示。图中箭头表达的“1:1” 表示必有且仅有一个关联关系；“1:0..1”表示可有一个或无任何关联关系。 213（1）各类报告、门诊就诊信息、住院就诊信息必须关联到且仅可关联到某一患 者，关联的属性（外键）是“卡号+卡类型”。 （2）各类报告可以分别关联到某一门诊就诊信息或住院就诊信息。“可以” 的含义是尽可能做到关联，但确实无法关联也无妨。中心将根据时间、地点、患者 等数据自动进行匹配与整合，尽可能予以相互关联。 无法满足上述关联规则的数据将不会被中心整合归入患者个人的临床诊疗 档案库提供共享调阅。 各对象内数据表之间的关系如下图。 214临床诊疗病史相关数据的采集内容共有 16个数据库表组成。上述每一矩形 块是前述的一个对象，每一矩形块内的表是表述该对象属性的数据库表。每一对 象的属性可由一个或多个数据库表表述。各对象之间的关联关系如前所述。每一 对象内的数据库表之间的关系如上图中的线条箭头表达。 （1）实验室检验报告的对象中，检验结果指标表、细菌结果、药敏结果这三个 表必须与实验室检验报告表头相互关联。 （2）门诊就诊信息的对象中，门诊处方明细表、门诊收费明细表必须与门诊就 诊记录表相互关联。 （3）住院就诊信息的对象中，住院医嘱明细表、住院收费明细表必须与住院就 诊记录表相互关联。 其他的各个对象都由单一的数据库表来表述。 注意，在关联关系中，必须在顾及对象内各表之间的关联关系同时顾及对象 之间表与表的相互关系。例如，实验室检验报告必须与患者基本信息相互关联， 等等。 8.1.5.3 合理用药数据集 合理用药预警及管理系统将从各医疗机构采集药品的生产、配送、使用机构 215以及患者的用药信息。数据表之间的关联关系如下图所示： 药品库存信息 药品消耗信息 药品明细字典表 药品入库信息 药品入库明细信息 8.1.5.4 基础字典数据集 基础字典数据集包括： 1. 医院科室字典表 2. 医护人员字典表 3. 明细项目字典 4. 明细项目对照字典表 5. 标本字典表 6. 检验指标字典表 7. 检查类型字典表 具体的接口数据集： 参考附件：《武汉市区域卫生信息平台医疗服务数据接口标准》 8.2 与现有系统的接口 8.2.1 对接市突发公卫应急指挥系统 本项目建设将使应急指挥中心有效获取方方面面的信息，在突发公共卫生事 件发生时，更好地发挥应急指挥的决策作用，系统接口主要有以下几个方面：  采集医院卫生资源信息 216提供医院端的卫生资源信息，在疫情和突发公共卫生事件等重大危害时期， 支持医疗资源统一调度、院前急救、医疗救治、过程跟踪与反馈等医疗救治信息 服务和管理职能。  集成诊疗档案调阅 在应急指挥系统中集成诊疗档案查询插件，支持应急指挥系统及时从市级平 台进行调阅，了解居民的基本信息、疾病既往史、健康危险因素等信息，为应急处 置突发公共卫生事件（如：医疗救治）提供参考依据。 8.2.2 对接市局OA 系统 汉市卫生局已在市局内部署了OA系统，覆盖了市局的日常办公。本次建设 的目标是：为OA系统提供平台上建设模块的功能链接，完善OA中供个人日常使 用的功能集合。主要提供给OA的平台功能包括：  市民电子病历共享系统 场景1网上办公：在相应的公众健康服务门户支持的情况下，居民在实名登 记的前提下，通过网络提交申请。平台将申请业务数据交换到内网OA系统，由 OA系统在查询居民的健康档案和电子病历后进行处理，并将处理结果反馈回到 公众健康服务平台，并反馈给申请发出者。 场景2日常医患纠纷处理：在处理患者投诉时，卫生行政部门通过 OA处理 时，也可随时查询患者在医院的诊疗情况，便于迅速、准确的处理日常医患纠纷。  医疗业务分析系统 场景3日常办公管理：在为工作人员个人提供一个综合的个性化的OA环境 时，其中的功能既有自身已建设的功能，也可将其他各类与个人工作相关的卫生 统计报表嵌入或链接汇集进来，形成供个人日常使用的功能集合，以支持个人工 作任务的提示与办理、个人日程的安排、相关工作的移交等。 场景4行政审批：与平台上的医疗业务分析系统对接，方便采集如医政管理 等涉及到需要行政审批的统计分析业务数据，支持整合在 OA系统中完成领导审 217批流程，从而便于集中办公，提高行政效率。 8.2.3 对接省级预约系统 目前湖北省正拟建全省的网上预约服务系统。系统还没有上线，所以没有办 法进行对接。 我们可以链接武汉市已经覆盖面很广的“健康之路”。 8.2.4 对接家庭健康档案 1、 家庭健康档案系统现状： a) 前期已收集了武汉市较多的个人健康档案； b) 目前处于维护阶段，但马上将对其做较大的改动，工作量相当于重新 开发； c) 预计新系统今年内启动开发，工期为一年； 2、 卫生平台与家庭健康档案系统数据同步方式； a) 平台初始导入目前所有“个人健康档案”数据； b) 后期增量数据同步方式，经初步商议方式为：家庭健康档案系统每天 定时检索增量数据，将其封装为txt或excel文件，传输到平台指定的 FTP目录，由平台读取并导入； 3、 上海易可思-(家庭健康档案系统的软件服务商)需要提供： a) 确认家庭健康档案系统使用的数据库类型； b) 与个人健康档案数据相关的数据库表字典； 8.2.5 对接新农合系统 对接内容：在试点范围内通过采集农村居民就诊时的诊疗档案和结算信息， 一方面通过信息共享和互联互通，扩大我市城乡居民健康的服务范畴，提高我市 农民的整体健康水平，切实让农民受益于卫生信息化的建设成果。此项待定。居 218民健康卡与新农合系统对接尚待商榷。 2199.附件 （1）《武汉市医疗卫生科学数据标准化工作指南》 （2）《武汉市卫生局智慧医疗信息系统标准规范体系》 （3）《武汉市级区域卫生信息平台建设规范》 （4）《武汉区级区域卫生信息平台建设规范》 （5）《武汉市基于电子病历的医院信息平台功能规范》 （6）《电子病历与检验检查共享规范》 （7）《武汉市公众健康服务门户实名制认证规范》 （8）《武汉市双向转诊业务实施规范》 （9）《武汉市级区域卫生信息平台服务接入指南及评估标准》 （10）《武汉市区域卫生信息平台医疗服务数据接口标准》 （11）《武汉市区域卫生信息平台数据元值域代码标准》 （12）《武汉市居民健康卡管理办法》 （13）《武汉市居民健康卡试点项目建设方案》 （14）《武汉市卫生局智慧医疗信息系统（市级卫生信息平台一期）系统集成实施 方案》 220