1、XX市XX局医联体平台项目可行性研究报告项目编号：某市级智慧医联体平台项目可行性研究报告目录第 1 章项目概述51.1项目名称51.2项目建设单位及负责人51.3项目建设背景51.4项目建设目标、规模、周期71.5项目建设内容8第 2 章现状及必要性分析102.1卫生信息化建设102.2存在问题与差距分析122.3项目建设的必要性14第 3 章系统需求分析173.1用户需求分析173.2业务需求分析183.3数据交换需求213.4系统安全需求223.5关联系统和接口需求223.6系统非功能需求24第 4 章项目总体设计框架284.1设计原则和策略284.2总体技术路线294.3总体设计框架392、第 5 章项目总体设计方案445.1业务应用系统体系445.2平台支撑系统体系615.3患者服务集群1495.4医务协同服务集群1545.5综合管理服务集群206第 6 章信息资源规划及资源库建设2486.1信息资源建设原则2486.2信息资源总体规划2496.3数据资源库设计2496.4数据管理272第 7 章标准体系建设2747.1集团卫生行政及管理标准2747.2卫生信息交换标准2747.3卫生数据编码规范275第 8 章系统运行支撑环境设计2778.1机房建设2778.2网络系统方案2818.3平台规划设计2838.4存储设计2938.5平台前置设备2958.6系统软件设计295第 93、 章安全系统设计3029.1信息系统安全等级定级3029.2信息安全设计3049.3信息系统安全管理方案317第 10 章环保、消防和节能设计31910.1环境影响分析31910.2环境保护措施31910.3消防措施32010.4职业安全卫生32010.5节能分析320第 11 章项目采购方案32311.1采购范围32311.2采购方式32311.3采购组织方式324第 12 章项目建设与运行管理32512.1项目建设管理组织机构32512.2项目建设的实施策略32812.3项目运维服务331第 13 章项目实施进度计划33413.1项目实施工期33413.2项目实施计划33413.3项目成功4、的关键因素分析33513.4项目进度保障措施335第 14 章人员配置与培训计划33614.1技术力量和人员配置33614.2业务人员培训计划33714.3技术人员培训计划33914.4培训组织与实施341第 15 章效益与风险分析34315.1社会效益和社会效益34315.2项目风险分析及其对策347第 16 章项目投资概算总表357VXX市XX局医联体平台项目可行性研究报告第 1 章 项目概述1.1 项目名称XXX医联体平台项目1.2 项目建设单位及负责人项目建设单位：XXX（以下简称“市XX局”）建设单位负责人：项目负责人：1.3 项目建设背景近年来，为加快推进医疗卫生事业发展，构建完善5、的城乡一体化的医疗卫生信息化体系，国家各级政府先后出台了多项政策，大力支持医疗信息化建设。国家卫生计生委、国家中医药管理局在2013年11月以国卫规划发201332号印发的关于加快推进人口健康信息化建设的指导意见，要求在2020年前，建成互联互通四级信息平台，实现六大业务应用、业务协同和信息共享。这对区域医疗信息化的规划有了明确的时间要求。国务院办公厅在2015年5月发布国务院办公厅关于城市公立医院综合改革试点的指导意见，要求城市公立医院构建基层首诊、双向转诊、急慢分治、上下联动的分级诊疗模式，加强医联体医疗卫生信息平台建设，推进医疗信息系统建设应用。中共中央、国务院在2016年10月印发“健6、康中国2030”规划纲要，提出人口健康信息服务体系建设，全面建成统一权威、互联互通的人口健康信息平台，规范和推动“互联网+健康医疗”服务，创新互联网健康医疗服务模式，持续推进覆盖全生命周期的预防、治疗、康复和自主健康管理一体化的国民健康信息服务。国务院于2016年12月印发的“十三五”深化医药卫生体制改革规划中，提出了：“十三五”期间，要在分级诊疗、现代医院管理、全民医保、药品供应保障、综合监管等5项制度建设上取得新突破，同时统筹推进相关领域改革。国家卫生计生委于2017年1月印发的“十三五”全国人口健康信息化发展规划中要求：大力加强人口健康信息化和健康医疗大数据服务体系建设，推动政府健康医疗7、信息系统和公众健康医疗数据互联融合、开放共享，消除信息壁垒和孤岛，着力提升人口健康信息化治理能力和水平，大力促进健康医疗大数据应用发展，探索创新“互联网+健康医疗”服务新模式、新业态。同时，广东省以及XX市也出台了相应的政策文件，支持地区医疗卫生信息化事业。广东省人民政府关于促进和规范健康医疗大数据应用发展的实施意见（粤府办201712号）提出：建成统一权威、互通共享的省、市、县三级XX局医联体平台，连接各级各类医疗卫生机构，强化公共卫生、医疗服务、医疗保障、药品供应、综合管理等应用信息系统数据采集、集成共享和业务协同；加快改造升级以电子病历为核心的医疗卫生机构信息系统，减少重复投入，提高信息8、化建设效率，加强医疗卫生机构信息系统互联互通成熟度、电子病历系统应用水平评测，提高电子病历应用水平；实现健康医疗数据在平台汇集、业务事项在平台办理、健康决策依托平台支撑，全面深化健康医疗大数据应用；研制推广数字化健康医疗智能设备，促进健康医疗智能装备产业升级；整合线上线下资源，建立“互联网+健康医疗”服务、支付和信用、健康管理与促进体系，推广网上医院、掌上医院、云医院等新型网络医院建设模式，发展互联网医院。整合医联体医疗卫生服务资源，构建协同发展的医疗卫生服务体系。加快全民健康信息化建设，建设市、县（市、区）XX局医联体平台，联结各级各类医疗卫生机构，实现互联互通、信息共享、业务协同；建设集医9、学影像、病理诊断等为一体的市级健康数据中心；加快分级诊疗信息体系建设，规范优化基层信息化服务，实现及时更新、动态管理、综合利用，提高基层医疗卫生服务水平；大力发展智慧医疗健康服务，大力推动“互联网+医疗”，推动云计算、大数据、物联网、移动互联网等现代信息技术与健康服务的深度融合，发展智慧医疗，创新健康服务模式，改善就医环境，提高就医感受。加快推进人口健康信息的数字化、网络化、智能化共享；加快推进医疗卫生云平台及数据中心建设，建立互联互通、高效统一的医疗卫生云平台和信息资源共享环境，实现医疗卫生业务互联互通与协同和食品药品领域的智能监管；积极推动移动互联网医疗服务发展，实现各级医疗服务、医疗保障10、与公共卫生服务的信息共享与业务协同。这一系列的政策，明确了国家、广东省、XX市医疗卫生发展方向，强调了建设XXX医联体平台的必要性和紧迫性，并清晰地指出家庭医生 、共享电子病历、共享检验检查报告等为医联体医疗信息化的建设重点。1.4 项目建设目标、规模、周期1.4.1 建设目标以搭建医联体医疗服务云平台，实现医联体内标准、统一、共享的电子病历、检验检查报告为出发点，充分利用云计算、大数据、物联网、移动互联网等信息技术，构建互通共享的市级XX局医联体平台，连接各级各类医疗卫生机构，建设和完善公共卫生、医疗服务、医疗保障、药品管理、综合管理、决策分析等应用信息系统，实现全民健康信息的业务协同和共享11、，形成覆盖全人口、全生命周期的全民健康信息服务体系。项目建设具体目标包括：1、以医疗卫生信息系统为基础，人口健康信息为核心，整合医疗机构医疗信息资源，形成基于人口基本信息、电子病历等信息资源为一体的医疗卫生信息化核心体系。2、统筹完善公共卫生、医疗服务、药品管理、医疗保障、综合管理六大业务领域应用系统，实现各业务领域应用系统的互联互通、资源整合、信息共享与业务协同。实现市内跨区域、跨机构、跨部门的卫生信息互联互通，实现医院之间、医院与基层医疗机构之间互联互通，实现公卫业务与医疗业务的互联互通。3、依托大数据进行多角度、多维度的应用分析，开展医疗质量情况监管、疾病预防控制监管、医疗卫生机构绩效考12、核监管、基本药物运行情况监管等，为管理者提供精细化管理决策支持、疾病与疫情监测等服务；为医务人员提供临床辅助决策、精准诊疗与个性化治疗、分析提醒等服务；为居民提供全生命周期的健康档案、自我健康管理、健康预测与预警等服务。4、基于“互联网+”，整合线上线下资源，大力推进互联网健康咨询、网上预约分诊、移动支付和检查检验结果查询、随访跟踪、健康管理等服务应用，实现互联网与医疗健康服务深度融合，大幅提升医疗服务水平，改善医疗环境，缓解医患关系，为全体居民提供优质、便捷、高效、公平的基本医疗和健康服务。1.4.2 建设规模本项目建设覆盖XXX全部医疗卫生机构，建设规模上具有业务全覆盖、机构全覆盖、人群全13、覆盖和生命周期全覆盖的特点。在业务层面，涵盖全医联体公共卫生、医疗服务、医疗保障、药品管理、综合管理六大业务领域； 1.4.3 建设周期项目总建设周期预计为12个月，包括项目整体需求调研、需求分析、概要设计、详细设计、数据库设计等工作，以及完成软件开发及相关接口实施工作；完成设备安装、部署；完成各系统测试及试运行；完成项目整体验收。1.5 项目建设内容整合XXXX局医疗机构信息资源，构建互通共享的市级XX局医联体平台，连接各级各类医疗卫生机构，建设和完善公共服务、公共卫生、医疗服务、医疗保障、药物管理、综合管理等应用信息系统，实现全民健康信息的业务协同和共享，形成覆盖全人口、全生命周期的全民健14、康信息服务体系。具体建设内容如下：（一）建设XX局医联体平台建设XX局医联体平台，包括统一门户、数据资源目录管理、数据采集与交换管理、数据整合、数据利用、业务协同、注册服务、主索引服务、电子证照、统一支付、数据挖掘、统计分析等功能的建设。（二）整合联通全市各项纵向业务系统纵向应用系统包括公共服务、医疗服务、公共卫生、医疗保障、药物管理、综合管理。将应用系统与XX局医联体平台进行集成，实现XX局医联体平台的数据共享与交换，实现数据单点采集，多点共享，业务协同。（三）建设医联体健康大数据中心医联体健康大数据中心建设具体包括整合全医联体患者健康档案数据库、电子病历数据库等大数据库，并涵盖病案首页数据15、库和卫生资源数据库（包括共享目录数据库和基层医疗卫生、公共卫生、药物管理、中医药等业务数据库）建设，为各业务系统服务，实现数据整合、清洗、分析和交换共享，实现全市全民健康大数据的开发和利用。（四）建设安全体系建立涵盖基础设施安全、应用安全、网络安全、数据安全、管理安全的一体化信息安全防护体系。（五）建设标准体系标准体系规范的建设包括总体标准、应用功能规范、数据规范、应用支撑规范、信息基础设施规范、安全规范、管理规范等 7 个组成部分，其中市、县区域全民健康信息平台接口标准、业务系统接口标准，同时涵盖国家电子病历和居民健康档案等标准规范。第 2 章 现状及必要性分析2.1 卫生信息化建设2.1.16、1 垦区内医疗机构信息化现状目前，XXX在职职工2.5万多人，下属医疗机构共22家。为了加强垦区医疗卫生单位信息化建设的统一规范管理，会组织一些相关培训，例如垦区医疗单位信息化数据管理培训班在中心医院举办。但全垦医疗机构，还存在各家医疗机构的信息系统标准不统一，各医疗机构间的患者信息、电子病历信息、检验检查信息、接诊信息不能共享，与医院外的业务系统无联动等问题。XX中心医院在护理病历、临床路径、抗菌药物、体检等系统建设方面存在缺失，临床的纵深应用存在短板。部分医疗机构的系统应用功能不够全面，所有医疗机构的移动医疗应用均未完成建设。部分医疗机构电子病历系统未完全实现结构化，没有建立起以电子病历为17、核心的全面的数字化医院信息平台，无法满足医院业务要求和医联体卫生信息化的需求，还需要更深入的信息化建设第 365 页2.1.2 公共卫生信息化现状由于XX市目前市级公共卫生信息管理系统尚未建设完整，部分公共卫生信息系统（妇幼保健等）使用省统筹建设的垂直系统，这部分建设需待与市级公共卫生信息管理系统同步完善。妇幼条线：没有XX市独立的妇幼系统，使用广东省的垂直系统。计划免疫条线：省统一招标后， 2017年进行升级。但存在问题较多。主要包括软件功能不完善，网速较慢，数据丢失，系统运转不流畅，模块不完整，目前暂处试运行阶段。此外，计免系统目前没有整合到基层卫生系统里，无法实现业务联动和协同。疾控中心18、：没有XX市独立的疾控系统，使用国家疫情直报系统。肿瘤/传染病条线：没有市独立的系统，使用广东省的垂直系统。慢病条线：没有市独立的系统，使用广东省的垂直系统。120急救：120急救是目前XX市公共卫生体系中，信息化建设比较先进的条线。目前120急救中心已经构建了120调度系统，构建城乡一体化XX地区急救网络体系。动态调度为主，动态调度与静态调度相结合。2017年6月上线MPDS急救优先分级调派系统和互联急救APP系统，主要包括数字程控交换子系统、数字录音子系统、急救受理信息系统、地理信息子系统、急救优先指挥调度子系统、120联动子系统等。2017年6月份与26家网络医院实现了联动联调成功。1219、0互联急救APP，对空巢老人进行关爱服务，解决老龄化社会的难题。实现了全市紧急医疗救治的统一指挥按照国家总体规划要求，2020年前各省、市需自主建设公共卫生系统，实现分级上传，因此，需要建设完整的公共卫生信息系统。2.1.3 基础网络情况建设现状目前全市建成3条卫生信息化专网。(一)电信计生专网。联通200多个点，实现县级数据向市级汇聚，市级向省级汇聚。此外该网还承担政务外网和互联网功能。（二）电信医保专网。联通基层医疗机构专线。联通180多个点。（三）移动基层卫生信息专网。基层医疗卫生机构专用网络。2.2 存在问题与差距分析2.2.1 医院信息化现状与差距垦区各医疗机构信息化发展不平衡，各医20、疗机构之间信息化建设水平存在一定的差异。医院的级别越高，信息化建设投入和医院的信息化发展程度也越高。2.2.1.1 缺乏信息化顶层设计医院信息化建设中由于缺乏战略规划，没有充分考虑业务部门的需求，没有对医院业务流程进行专门的梳理和优化，导致应用系统对业务支持的灵活性差，业务部门人员感觉使用不方便，最终导致信息系统不能有效落实医院的发展战略。现有的信息系统均采取烟囱式的建设与部署模式，信息化水平较高的医院普遍存在几十个独立子系统，除数据库以外基础设施的共享很少的情况。医院的各个信息系统都是独成体系，根据各块业务的需求进行开发，虽然满足了当前业务，但从医院整体和长期发展来看，系统结构老化，稳定性和21、扩展性较差。现有的信息系统缺乏统一的核心数据模型与信息共享，大多数医院的信息系统涉及十多家不同开发商的不同数据模型设计，很难达到垦区各医疗机构间互连互通。2.2.1.2 系统瓶颈缺乏医院信息化的整体规划，随着IT需求的“焦点漂移”，导致信息系统与业务的匹配度降低。系统应用架构长时间没有重构导致新时期医院需求无法满足。同时打补丁式发展过程，使得系统架构的健壮性、稳定性逐步下降。系统发展过程中各模块采取了单兵作战的模式。各模块间仅考虑了业务流程中的数据传递，没有考虑整体的信息整合，数据与信息的利用不高（其中包括面向管理者的数据分析/管理/决策，面向医务人员的患者就诊信息回顾与临床辅助，面向患者的医22、疗信息服务）。系统长期没有进行更新、升级，导致应用系统的响应速度、稳定性降低。目前信息系统由医院自行进行集成，缺乏统一的数据标准、信息标准及集成标准的规划。2.2.1.3 功能缺陷目前，垦区绝大多数医院信息系统没有统一的用户管理与安全认证，导致系统界面集成困难，用户重复登录。缺乏全院的数据标准规范，各业务系统的数据标准不一致。大多数医院临床系统应用缺失，电子病历结构化水平不高。目前未建立全院的临床数据中心，医护人员无法通过统一视图查询患者的诊疗资料。移动医疗信息化系统建设普遍空白。信息系统对医护人员的辅助、提醒功能缺乏，未能发挥信息化的作用。缺乏数据二次分析、利用的途径和手段。对临床科研缺乏有23、效的信息化数据分析支持。缺乏全面的运营管理、决策支持应用，不能满足管理层的管理需求。以建设业务系统作为重点，缺乏面向数据分析利用的信息平台的建设投入。管理人员、医护人员对信息化的满意度不高。IT基础设施缺乏统一集中管理，老化问题突出。2.2.1.4 信息化基础问题信息化建设缺乏明确的建设目标和整体规划，信息化建设以满足业务需求为主，导致采取打补丁的发展模式。缺乏统一的应用支撑平台，信息孤岛、烟囱问题突出。信息化建设力量较弱，绝大多数医院的IT部门人员较少。业务部门对信息化建设的参与度不够。信息化投入偏低，医院普遍反映信息化建设投入经费不足。信息化的投资偏重于硬件，软件投资的比例不高。2.3 项24、目建设的必要性2.3.1 完成“十三五”期间卫生信息化发展任务的基础人口健康信息化和健康医疗数据是国家信息化建设及战略资源的重要内容，是深化医药卫体制改、建设健康中国的重要撑。“十三五”全国人口健康信息化发展规划指出：到2017年，覆盖公共卫、计划育、医疗服务、医疗保障、药品供应、业管理、健康服务、数据挖掘、科技创新等全业务应系统的口健康信息和健康医疗数据应用服务体系初具规模，实现国家口健康信息平台和32个省级（包括新疆生产建设兵团）平台互联互通，初步实现基本医保全国联网和新农合跨省异地就医即时结算，基本形成跨部门健康医疗数据资源共共享的良好格局；到2020年，基本建成统权威、互联互通的人口健25、康信息平台，实现与人口、法人、空间地理等基础数据资源跨部门、跨区域共享，医疗、医保、医药和健康各相关领域数据融合应取得明显成效；统筹区域布局，依托现有资源基本建成健康医疗数据国家中及区域中，100个区域临床医学数据示范中心，基本实现城乡居民拥有规范化的电健康档案和功能完备的健康卡；加快推进健康危害因素监测信息系统和重点慢病监测信息系统建设，传染病动态监测信息系统医疗机构覆盖率达到95%；覆盖全人口、全命周期的健康信息服务体系基本形成，口健康信息化和健康医疗数据应发展在实现享有基本医疗卫服务中发挥显著作。2017年10月，广东省印发广东省全民健康信息综合管理平台项目工作方案，方案要求：建设全民健26、康信息综合管理平台，包括统一门户、数据资源目录管理、数据采集与交换管理、数据整合、数据利用、业务协同、注册服务、主索引服务、电子证照、统一支付、地理信息管理（GIS）服务、数据挖掘、统计分析等功能 的建设。2.3.2 改变垦区医疗机构卫生信息化薄弱基础的重要举措建立垦区医联体平台系统，使得垦区内各医疗机构共享患者基本信息、电子病历、检验检查报告，将极大地提高垦区医疗机构的信息化水平、医疗服务水平，患者的信任度。2.3.3 解决群众看病难看病贵的具体操作平台看病难、看病贵是目前国内三大民生问题之一，十七届五中全会强调，在推动经济发展方式加快转变中，着力保障和改善民生，加快医疗卫生事业改革发展，加27、大五项重点改革力度，建立和完善基本药物制度，加快公立医院改革试点，使人民群众切实受惠。建立基本药物制度是一项重大的制度创新，是缓解群众看病难看病贵问题的有效途径。在医疗卫生信息化建设中的医疗物联网是通过信息传感设备，按照约定的协议，把任何物品与互联网连起来，进行信息交换和通讯，以实现智能化识别、定位、跟踪、监控和管理的一种网络。区域内药品供应链系统的建立使基层卫生服务机构实行基本药物零差率销售、采购和配送工作，构建零差率的区域药品采购、配送、结算平台，降低成本提高效率，从源头上解决群众看病贵的问题。卫生信息系统通过信息平台的建设，建立起一套有效的监管、考评、奖惩机制，有效利用全医联体内医疗资源28、。信息化技术也极大的降低了各医疗机构的日常管理成本，提高了工作效率，使更先进的管理模式的实施成为可能解决群众看病难的问题提供了有力的保障。通过多种信息化技术手段，实现基于移动端的患者服务平台对患者从诊前、诊中、诊后进行全方位发服务。通过远程信息化手段，实现远程会诊、双向转诊真正的落到实处。第 3 章 系统需求分析3.1 用户需求分析3.1.1 医疗机构需求为了提高医疗质量和提供更合适的治疗方案，希望获得更多的病人医疗信息，包括：医生可以调阅到当前患者的历次诊疗信息，及当前患者相关家属的健康信息，能够查询个人健康档案与患者在其他医院的就诊资料。医生在为患者诊治时可以获得治疗安全警示、药物过敏警示29、重复检验/检查提示，有效减少医疗事故发生、降低重复检查费用。在进行远程会诊时，所有专家都可以调阅到当前患者的检查报告、医学影像。全市范围内病人检验单,检查报告的共享和互认。此外，医院希望减少信息重复录入的工作量，可从电子病历中自动获取并提交疾病控制、妇幼保健、精神卫生等公共卫生业务单位或部门需要的数据和信息。3.1.2 居民需求随着经济的发展，患者迫切需要享受更高品质的医疗卫生服务，及时获取有效的医药保健信息，提高生活质量。这种需求主要体现在以下几个方面：可及的卫生服务：通过提高医疗机构的医疗服务质量和服务效率，降低医疗成本，有效缓解“看病贵”的状况。通过XX局医联体平台，医院开展专家门诊预30、约、远程咨询会诊、转诊、转检、慢性病跟踪监控等服务，使居民就医更方便。建立医联体共享健康档案，实现健康信息共享，改变城乡居民的就医观念，逐步实现“小病在社区,大病在医院”，有效缓解“看病难”的状况。优质的卫生服务：居民在进行诊疗时，可以让就诊医生查阅自己的健康档案及诊疗信息，从而使就诊医生更好的为自己服务，并可以通过治疗安全警示、药物过敏警示等有效减少医疗事故，并可对不必要的检验/检查进行提示，逐步缓解“看病贵”的问题。连续的健康信息：按照标准，收集整理各卫生机构的健康信息，建立居民贯穿整个生命周期健康档案，群众可以查询自己的健康资料，或使用全医联体统一的标识在各医疗机构中进行就诊，享受便捷的31、全方位的疾病诊治、医疗咨询、健康教育、医疗保健等健康服务。从而进行自我医疗管理、制定自我疾病防范及维护自己的健康档案信息。全程的健康管理：医联体内各医疗机构可运用卫生信息平台为患者提供主动的、人性化的健康服务，一方面为患者提供方便、快捷、全面、科学的健康服务和保障。另一方面将有助于增强患者的健康保健意识，极大地提高居民的健康水平与生活质量。3.1.3 医务人员需求为了提高医疗质量和提供更合适的治疗方案，希望获得更多的病人健康信息，包括：医生可以调阅到当前患者的历次诊疗信息，及当前患者相关家属的健康信息，能够查询个人健康档案与患者在垦区其他医院的就诊资料。医生在为患者诊治时可以获得治疗安全警示32、药物过敏警示、重复检验/检查提示，有效减少医疗事故发生、降低重复检查费用。在进行远程会诊时，所有专家都可以调阅到当前患者的检查报告、医学影像。全医联体范围内病人检验单,检查报告的共享和互认。3.2 业务需求分析3.2.1 医疗服务3.2.1.1 提高医疗服务质量的需要健康档案应具有高亮显示潜在病患患者，将及时提醒随访医生及时关注其的健康状况，极大的提高了患者健康状况的依赖心理，能较大程度的提高医疗服务质量。3.2.1.2 节省患者支出，缓解群众看病贵问题的需要促进基本公共卫生服务逐步均等化，通过基于网络的信息技术，为每个人建立一个健康档案，实际上就能够实现个体化程度上的健康管理，患者个人的健33、康资料，像儿童出生的情况、疫苗接种、中老年人慢性病的情况、医联体内各医院的就诊记录，以及诊断治疗的重要的记录，如CT、核磁、X线的检查、影像学的资料都可以建立在这个档案当中。这样无论是在医联体内那家医院就医，医生马上就可以知道患者病史，避免了很多重复的医学检查，既提高了效率，也节省了患者支出。3.2.1.3 有效、合理利用医疗资源的需要在医联体内不同机构之间开展的有效、持续的患者服务与医疗管理，通过建立患者健康档案共享，促进医联体内卫生服务机构之间形成业务联动、优势互补、疾病诊治连续化管理的机制，最终实现小病在社区，大病进医院，康复回社区的就医格局。实行医联体内各医院联合与合作，建立分级诊疗和34、双向转诊制度，探索开展社区首诊制试点，由社区卫生服务机构逐步承担大中型医院的一般门诊、康复和护理等服务。实现双向转诊的重要一点就是信息共享与沟通，这有赖于信息化建设。没有电子病历、健康档案等基础信息，信息化支撑转诊可谓无源之水，只有有了基础信息，才能够说得上转诊时各医疗机构之间信息共享，才能谈以此实现提高质量降低费用的目的，实现医联体医疗资源的合理利用。3.2.1.4 用例分析实验室检验结果共享实验室检验结果共享业务的主要参与者及其需开展的业务如下：原接诊医生：办理转院申请。专科医生：接收转入病人，查阅检验结果以及病人既往病史，对病人进行治疗。下表是对场景描述，通过对现在使用的流程、使用XX局35、医联体平台后的流程进行对比，对有平台后的益处进行分析。实验室检验结果共享情景描述场景：张三腹部疼痛已经持续几周了，身体状况日益衰弱。由于诊断不明，他的医生建议他进行一系列的化验检查并让他去专科医生那里就诊。无XX局医联体平台检验结果通过传真或者快递送到专科医生处。专科医生查看检验报告。专科医生与张三会面，询问张三既往病史，从而判断是否有其他因素引起疾病。由于未能精确地查明原因，专科医生建议做进一步检查以查明病因。使用XX局医联体平台张三的原接诊医生，办理转院申请。专科医生接收张三转入。通过XX局医联体平台，直接获得检查结果专科医生查阅检验结果以及张三既往病史发现数年前的情况对当前病情可能产生影36、响。专科医生就此和张三回顾情况，以确认一些细节。根据这些临床证据和问诊情况，专科医生做出诊断，并开出治疗处方。益处节省递送检查结果所需的时间和金钱。提供完善的资料使得医生能够做出明确的大部分诊断。医疗卫生人员不再仅仅依靠患者的无重点的回忆和一些补充信息，而是可以直接获取精确和完善的历史信息。提供完整的信息提高了快速准确诊断的可能性。3.2.2 药品管理随着“公立医院全部取消药品加成”政策的大力推进，代表着医疗机构在本质上不再参与药品交易，只是作为医疗服务中药品使用的权威专业机构。让药品回归市场化竞争，让公立医疗机构回归提升医疗服务的内涵式发展。根据国务院关于完善公立医院药品集中采购工作的指导意37、见（国办发20157号）、国务院办公厅关于全面推开县级公立医院综合改革的实施意见（国办发201533号）、国务院办公厅关于印发深化医药卫生体制改革2017年重点工作任务的通知（国办发201732号）等文件精神，落实各级政府对医改工作的工作部署，规范药品流通秩序、完善药品价格形成机制、强化卫生信息化建设，建立规范化、集约化的药品（含医用耗材）供应保障体系，结合本地药品管理和信息化建设现状，制定本方案。为提升药品生产供应保障的市场化、规模化、智能化、阳光化水平，同时对政府监管工作提出了新的、更高的要求。基于药品管理平台建设，从整个药品生产供应体系层面着手，用现代信息化技术手段可以实现“实时、动态、38、精准”的监管，从而推动公立医院药品采购、物流配送、临床应用等全过程管理信息化，推进医药现代物流向公立医院延伸，支持公立医院建设智慧药房，降低药品供应成本，提高运营效率。需要以现代物流与信息技术为支撑，建立涵盖药品采购、供应、配送、仓储、销售、使用、监管等环节的一体化管理平台，解决目前药品管理信息化水平低的问题，推动药品物流服务的专业化发展，逐步规范药品流通秩序，不断提升用药安全水平，有效控制药品管理成本，积极稳妥地落实医改任务。3.3 数据交换需求数据交换平台既可交换医联体内各医疗机构之间的各种信息；另一方面又可实现对业务数据的统一管理，提供各系统的数据共享，既能充分支撑各业务的正常运转，也能39、为医保系统及各政府部门、社会公众提供高速、可靠的服务，同时还可利用数据仓库进行数据挖掘，为领导进行全垦区卫生宏观管理提供有效的决策支持。根据信息交换技术对安全性，开放性和灵活性等技术特性的需求，信息交换平台应解决同构和异构数据交换问题。在目前各医疗机构单位中，医疗机构信息化建设并不是从零开始，许多单位已有了自己的业务系统，其采用的硬件、平台、数据库和应用不尽相同，信息交换平台必须全面解决异构平台、异构数据库之间的信息交互问题，充分保护各个单位已有投资和历史数据。通过数据共享交换平台，可达到如下目标：消除数据冗余；能够在不同系统间进行数据转换和传递；支持不同数据格式和通信协议。通过医疗机构信息交40、换平台可以与直属重点医院、120急救数据中心、其它医院信息系统连接，实现医疗卫生信息资源的共享。通过医疗机构信息交换平台实现医疗机构与外部相关，如公安局、民政局、社保局、药检局等政府部门的信息交换和信息共享。可以考虑流行的Web Service技术，采用XML作为信息交换的标准，通过消息传递进行数据的交换，在交换过程中能对消息进行加密、审计、能监控和管理不同应用系统之间通信，解决在异构数据系统之间进行数据集成和共享的问题。3.4 系统安全需求本期项目的建设将充分考虑链路专网安全、网络安全、信息安全等方面的安全保密性，以保证系统安全。要求项目建设参照计算机信息系统安全保护等级划分准则（GB17841、59）达到安全等保三级。3.5 关联系统和接口需求3.5.1 省级平台数据交互接口需求为满足国家卫健委及广东省卫健委数据上报的要求，减少数据重复录入的麻烦，需要系统满足按照规定的格式，从业务系统中自动生成报表，手动或定时的发送报表的需求，上报的数据涵盖以下几个方面: 疾病预防控制数据信息 妇幼保健数据信息 精神卫生数据信息 卫生监督数据信息 医疗卫生统计信息等3.5.2 市级平台信息交互接口需求信息平台的最重要的价值在于信息的共享，平台需要考虑到以后建立更高一级人口健康信息平台的需要，以及与其他同级医疗系统的互动。这就要求平台以服务的形式开放业务服务接口，满足如下的功能： 患者电子健康档案的共42、享 区域间信息调阅、查询和打印 区域间医疗业务协同3.5.3 支付接口与银行、银联、支付宝等接口，实现移动支付功能。3.5.4 血站接口与血站信息管理系统连接，获取血液库存、献血者和使用者档案信息；3.5.5 妇幼信息系统接口与妇幼信息系统对接，获取人口出生信息和妇女儿童保健档案，为基层医疗机构随访提供数据，为卫生服务措施提供信息，为统计监管提供数据来源；3.5.6 计划免疫系统接口与计划免疫系统对接，疫苗接种不只有基层医疗机构提供服务，二级医疗机构也要提供疫苗接种服务，通过与计划免疫系统对接，完善基层计划免疫档案，为免疫统计监管提供数制依据。3.5.7 卫生监督系统接口与卫生监督管理信息系统43、对接，获取公共卫生、传染病、食品安全、医疗质量、医疗行为等统计监管数据。3.5.8 民政系统的接口信息平台从民政系统获取女性人群的婚姻信息，并将划定年龄段的已婚女性作为孕产妇保健预备管理对象。从民政系统获取残疾人群信息，在健康档案的建设中，为该类人群建立残障专项档案、提供残疾康复管理。提供人口死亡医学证明的签发数据，与民政系统实现数据互联互通。提供低收入者、贫困人口的档案与民政系统对接，获取低收入者、贫困人口的档案。获取优抚对象（现役军人、残疾军人、复员军人、退伍军人、烈士遗属、因公牺牲军人遗属、病故军人遗属、现役军人家属）的档案，为优抚对象医疗服务提供基础数据。获取五保户的档案，为五保户人员44、医疗服务提供基础数据。3.5.9 公安系统的接口信息平台从公安系统获取全员人口信息、出生人口信息、户口迁入人口信息，触发新增人群（出生、户口迁入）的健康档案建档工作。可从公安系统获取户口迁出的人口信息，触发户口迁出人群所对应的健康档案的封存和转档。3.6 系统非功能需求3.6.1 性能需求分析性能符合行业内比较通行的“2-5-10原则”： 系统业务响应时间小于2秒，判为优秀，用户对系统感觉很好； 系统业务响应时间在2-5秒之间，判为良好，用户对系统感觉良好； 系统业务响应时间在5-10秒之间，判为及格，用户对系统感觉一般； 系统业务响应时间超过10秒，判断为不及格，用户无法接受系统的响应速度，45、认为系统已经失去响应，而选择离开这个页面，或者发起第二次请求。考虑到类似系统的使用，需要对系统用户的操作响应时间综合考虑，在内部系统中尤其重要，由于外部系统的变动因素比较复杂，因此仅考虑内部系统使用情况： 病人就诊记录的查询时间：在限定时间范围的情况下，不大于10秒 病人主索引匹配：根据定义的匹配条件，不大于10秒 资源查询：不大于10秒3.6.2 安全需求分析3.6.2.1 身份认证安全需求XX局医联体平台必须实现安全的身份认证体系，主要包括 医疗卫生机构的身份认证 医护人员和卫生管理人员身份认证 居民身份认证，多身份的唯一索引认证 医联体内医疗卫生系统间的用户身份互认机制以上身份认证的安全46、需求将使系统间的集成与交互得到安全保证。3.6.2.2 数据认证需求医联体内医疗卫生机构间要真正实现系统的互联互通，数据的集成共享，则必须解决医联体内医疗卫生数据的认证需求，主要包括 基础医疗卫生数据认证 LIS检验数据认证 PACS影像数据认证 电子病历数据认证 处方数据认证 其它医疗卫生数据认证解决以上数据认证将解决医联体内各种医疗卫生数据的相互集成与共享，实现面对各级医疗卫生机构提供统一的数据界面，为医联体内患者提供统一的、有效的医疗卫生数据，有效的降低患者的医疗费用。3.6.2.3 数据安全管理需求医联体内信息的集成共享，必须有相应的数据安全管理机制保证，主要包括 数据标准化安全管理 47、数据加密传输 数据加密存储 数据日志管理 其它数据安全策略医联体内医疗卫生信息化数据的安全管理需求，将有效的促进区域内医疗卫生数据安全体系建设。3.6.2.4 数据备份安全需求数据是整个信息化架构的成本核心，是存储的内容和灵魂，是医联体医疗卫生应用得以支撑的关键性数据，必须保证数据的安全，因此平台的建设必须充分考虑数据备份的安全措施，数据库设置预定的备份策略进行本地备份，有条件的可做异地备份。3.6.2.5 隐私保护需求医联体内医疗卫生数据涉及到各医疗机构和卫生管理机构的数据，也涉及到患者的医疗健康数据，这些数据的存储、使用都必须按用户级别授权使用，以保证医疗卫生数据的隐私受到保护。3.6.348、 办公网络安全需求按照信息安全等级保护管理办法、计算机信息系统安全保护等级划分准则等国家有关信息安全技术安全策略、法规、标准和管理要求进行，以风险评估和需求分析为基础，坚持适度安全、技术与管理并重、分级与多层保护和动态发展等原则，保证网络与信息安全与服务的有效性。信息安全管理体系建设将覆盖所有与健康云建设相关的信息安全管理规章制度、应用安全、系统安全、网络安全和物理安全等方面的内容。3.6.3.1 医联体内网与外网之间的数据交换外网接入区边界部署防火墙和防病毒安全网关作为基本的安全防护措施，前置服务器区域与平台内部网络中间部署安全隔离与信息单向导入系统（单向网闸）。其中一台安全隔离与信息单向导49、入系统实现平台内部数据传输至前置服务器区域，另外一台安全隔离与信息单向导入系统实现前置服务器数据传输至平台内部服务器。采用安全隔离与信息单向导入系统，实现平台内部业务系统与外网之间的物理隔离和单向数据传输，并对出入的数据进行格式检查和数据过滤。单向入的格式数据，由单向光闸主动从源服务器上拉数据，并主动向目标服务器推送数据。3.6.3.2 医联体内网与专网之间的数据交换专网单位接入区边界部署防火墙和防病毒安全网关作为基本的安全防护措施。单位访问平台业务通过虚拟IP访问，由负载均衡分配响应的服务资源，简化数据交换过程。第 4 章 项目总体设计框架4.1 设计原则和策略XXX医联体平台初步设计的原则50、和策略如下：先进性：所采用的设备产品和软件不仅成熟而且能代表当今世界的一流技术水平。开放性：XXX医联体平台应是一个开放的平台，应提供标准的数据通信接口协议，网络接口，系统和应用软件接口，具有良好的灵活性和可扩展性，兼容性好，应用软件可移植性强；可维护性好，系统生命周期长。标准化和模块化：集成系统的总体结构须是标准化和模块化的，满足通用性和可替换性，既可使不同厂商的设备综合在同一个系统中，得到高度的信息共享，又可使系统在日后能进行方便的扩充。安全性：在保证数据安全性的前提下，要求实现严格的网络等级操作权限和不同对象的查询范围。可靠性：要采用各种措施建造一个高可靠性系统。可采用冗余设计，可用性群51、集，共享数据群集等保证系统具有高可靠性。重要的实时性要求高的联动应在现场或控制层面实现集成，实时性要求不是特别高的信息在管理层实现共享集成。可管理性：集成系统的可管理性，表现在支持网络监视和控制两方面能力，能监视控制到网络主要设备；网络管理标准化。经济性：系统设计要从系统目标和用户需求出发，经过充分论证，选择合理的方案和适合的软硬件产品。前瞻性和可扩展性：对未来的系统的集成有预留设计，以便前期工程和后继先进技术的衔接，保持系统的先进性。高效率：提高系统实时响应与控制能力、服务器响应数据库请求的能力和网络的吞吐能力，满足通信的传输速率和带宽要求，是系统高效率的体现。4.2 总体技术路线4.2.152、 基于面向服务的SOA架构设计根据调研得知，XX市各级医疗机构使用的医疗卫生信息系统各不相同，如何让众多的异构系统有效方便地集成已成为卫生信息化建设亟待突破的一项技术难点。采用SOA架构设计，主要是完成各种异构系统间消息的传输、转换、过滤与路由，通过服务总线（Service Bus）和服务或流管理器来连接服务和提供服务请求的路径。流管理器处理定义好的执行序列或服务流将按照适当的顺序调用所需的服务来产生最后的结果。在消息交换服务总线(Message Bus)上再增加服务注册中心(Portal)，以及系统运行监控系统（Monitor），与业务系统连接的适配器，就构成了以消息为基础，以面向服务为导向53、的整个医院信息系统接口模型，从而实现对医院各种异构系统之间的集成。如下图所示：图4.2.1-1 面向SOA架构的异构系统间系统集成流程图采用SOA架构设计，不仅符合.NET和J2EE等成熟技术框架，而且也符合XML技术数据传输格式的规范。另外，它不仅是一套完整的管理信息系统应用组合，更是一个敏捷应对客户需求的技术环境，向医院提供一个统一的应用门户，可根据不同客户的管理需求和流程特点，或同一客户在不同时间的需求与流程变化，实现快速灵活的个性化定制，从而实现国际技术体系与国内应用特点的完美结合。采用SOA架构设计的集成平台信息交互方式如下图如示：图4.2.1-2 集成平台交互图SOA架构技术与传统54、的点对点接口模式有着本质的区别，具体对比如下：表格 接口融合模式比较项目传统接口整合模式基于平台整合方式整合目标系统间的数据交换整体信息化整合整合内容信息交换、流程整合信息交换、流程整合、数据整合、数据利用维护难易度难容易系统间关联度紧耦合松耦合可扩展性低高数据集成度分散集中系统效率低高运行成本高低4.2.2 采用先进的技术架构4.2.2.1 三层(多层)架构软件系统采用三层（多层）分布式体系结构。三层（多层）分布式体系结构既可以满足用户个性化需求以及系统安全性等方面的需要，又能保持系统核心架构的稳定性。一个三层（多层）架构的系统如下图所示：图4.2.2.1-1 平台三层架构图4.2.2.2 55、消息总线ESB数据交换服务总线ESB是整个XXX医联体平台的技术核心，ESB通常采用面向服务的体系结构。该服务保证在一个异构的环境中实现信息稳定、可靠的传输，屏蔽掉用户实际中的硬件层、操作系统层、网络层等相对复杂、烦琐的界面，为用户提供一个统一、标准的信息通道，保证用户的逻辑应用和这些底层平台没有任何关系，最大限度地提高用户应用的可移植性、可扩充性和可靠性。提供一个基于应用总线的先进应用整合理念，最大限度地减少应用系统互联所面临的复杂性。系统的实现维护都相对简单，保证每一个应用系统的更新和修改都能够实时地实现；同时当新的应用系统出现时能够简便的纳入到整个IT环境当中，与其它的应用系统相互协作，56、共同为用户提供服务。4.2.2.3 数据交换技术面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。4.2.2.4 WEB SERVICEWeb service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。可以用任何语言，在任何平台上写Web service ，并通过Web service标准对57、这些服务进行查询和访问。Web service平台提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。它易于建立和易于分析外，并且与平台无关。WEB服务( WEB Service)是目前采用的非常流行的系统互联技术，它有两个主要用途：将多个系统整合到一起；将功能函数(function)作为组件提供给远程调用。Web服务已被业界广泛接受用来解决复杂的问题和跨多个平台与系统的分布式过程。它使不同系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现58、“基于WEB无缝集成”的目标。Web服务通过使用基于标准的协议如SOAP、WSDL和UDDI以及标准组的开发工作实现了这一点。4.2.2.5 基于J2EE选用J2EE作为主要系统的框架，并以它为基础搭建整个技术架构平台。J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE是一个标准，而不是一个现成的产品。J2EE将组成一个完整企业级应用的不同部分纳入不同的容器(Container)，每个容器中都包含若干组件(这些组件是需要部署在相应容器中的)，同时各种组件都能使用各种J2EE Service/API。J2EE容器包括：Web容器服务器端容器、59、EJB容器、Applet容器客户端容器和Application Client容器。通过这四个容器，J2EE能够灵活地实现前面描述的企业级应用的架构。采用J2EE体系结构可以用来满足卫生信息系统高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE降低了开发费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持Enterprise JavaBeans，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。J2EE方案的实施可显著地提高系统的可移植性、安全性、可伸缩性、负载平衡和可重用性。4.2.2.6 基于HTMLHTML5技术是最新的超文本标记语60、言，它有以下几个优势：1、网络标准HTML5本身是由W3C推荐出来的，它的开发是通过谷歌、苹果，诺基亚、中国移动等几百家公司一起酝酿的技术，这个技术最大的好处在于它是一个公开的技术。换句话说，每一个公开的标准都可以根据W3C的资料库找寻根源。另一方面，W3C通过的HTML5标准也就意味着每一个浏览器或每一个平台都会去实现。2、多设备跨平台用HTML5的优点主要在于，这个技术可以进行跨平台的使用。比如你开发了一款HTML5的游戏，你可以很轻易地移植到UC的开放平台、Opera的游戏中心、Facebook应用平台，甚至可以通过封装的技术发放到App Store或Google Play上，所以它的跨61、平台非常强大，也是大多数人对HTML5有兴趣的主要原因。3、自适应网页设计很早就有人设想，能不能“一次设计，普遍适用”，让同一张网页自动适应不同大小的屏幕，根据屏幕宽度，自动调整布局（layout）？2010年，Ethan Marcotte提出了“自适应网页设计”这个名词，指可以自动识别屏幕宽度、并做出相应调整的网页设计。这就解决了传统的一种局面网站为不同的设备提供不同的网页，比如专门提供一个mobile版本，或者iPhone / iPad版本。这样做固然保证了效果，但是比较麻烦，同时要维护好几个版本，而且如果一个网站有多个portal（入口），会大大增加架构设计的复杂度。4、即时更新传统客户62、端每次都要更新，很麻烦。可是更新HTML5就好像更新页面一样，是马上的、即时的更新。4.2.2.7 基于XMLXML允许开发者建立他们的属于自己的保存信息的标记结构。XML解析语法是非常明确，而且是一种广泛应用的工具，它能从在各种各样的环境中XML文件使获得知识，在Unicode基础的基础上建立XML使它更容易建立使国际化文件，XML代表Extensible Markup Language（eXtensible Markup Language的缩写，意为可扩展的标记语言）。XML是一套定义语义标记的规则，这些标记将文档分成许多部件并对这些部件加以标识。它也是元标记语言，即定义了用于定义其他与特63、定领域有关的、语义的、结构化的标记语言的句法语言；XML主要有三个要素：Schema（模式）、XSL（eXtensible Stylesheet Language可扩展样式语言）和XLL（eXtensible Link Language可扩展链接语言）。Schema规定了XML文档的逻辑结构，定义了XML文档中的元素、元素的属性以及元素和元素的属性之间的关系，它能够帮助XML的解析器校验XML文档标记是否合法；XSL是用来规定XML文档表现形式的语言，同CSS类似；XLL则进一步地扩展了当前Web上已有的简单链接。4.2.2.8 个人唯一标识为了实现自然人数据的采集，以及和其他子系统，卫生系统64、网络之外的系统的联系，简化行政管理手段，提高系统效率，降低系统费用，就需要实施统一标识系统。采用统一标识，将可以快速确定一个个体，并通过此号码在最小数据标准集中获得其基本信息，以及相关在其他系统中所存储的数据信息，可以以此查找到其所有的相关信息，如：临床病历、社区健康档案、血液记录等等。本项目依托身份证作为居民唯一标识的介质，而内部唯一标识号可按照系统规则自由定义，每个系统完成个人唯一编码后由数据中心给予验证，如果重复则给予回退，如果发现同一个体采用了不同标识，则系统通过模糊检索如姓名，性别，年龄等信息找出类似个体如果确认则将新个体与原标识进行唯一匹配，从而保证个人标识的唯一性和延续性。4.265、.2.9 遵循IHE ITI规范近几年的研究表明，HL7规范解决了卫生医疗信息化中的互联问题。IHE的目的在于解决医疗行业中软硬件间的沟通问题，为信息的整合提供流程导向的标准架构，它从一个高层次定义和规范了不同医疗信息系统在不同医院和不同部门间相互连接和集成的问题，给医疗卫生的信息流程和工作流程带来了规范化的文档指引。目前，IHE解决互操作性的一组规范包括PIX(病人ID交叉索引)、XDG(跨机构文档共享)、XDS-I(跨机构图像信息文档共享)等一系列规范，已经成为医学信息共享标准的基础规范。该规范得到世界各国医疗行业人士的公认，国际上许多的国家和地区的基于该规范设计本土区域医疗卫生信息系统的66、体系结构。基于健康档案的XX局医联体平台已从多个方面着手遵守IHE ITI规范：一是从长远的角度来考虑，病人信息的共享问题；二是考虑系统整合和数据信息共享的需求，遵循国际标准的，解决医疗卫生信息区域化再次产生资源的共享和互操作上的不便；三是遵循统一的标准化的框架来指引信息的共享流程，打破了各地区相互孤立的“信息孤岛”现象。随着软件工程技术的发展，以Web service为基础的SOA架构已经走向成熟，以其优良的可扩展、互操作、可复用的优势在各类软件系统的研发中逐步占据重要地位。根据医联体卫生网络平台的分布式综合应用特点，采用SOA的架构，应用了Web Services等计算机前沿技术。系统遵循67、IHE ITI规范，探索工作流模式的研究、基于IHE PIX的病人ID交叉索引技术等应用。4.2.3 虚拟化及云计算技术4.2.3.1 虚拟化技术应用虚拟化技术通过整合服务器减少资金开销，通过自动化减少运营开销，同时通过减少计划内和计划外停机来最大限度减少收入损失。具有如下优点：自动资源调配和部署：组合可重用组件中的新应用，仅需几分钟即可完成部署，无需花费数周的时间。自动化运营管理：使用专用工具高效运行您的云计算环境，以优化性能、确保安全性，并在用户发现潜在的问题之前就修复它们。可用性、灾难恢复和合规性：交付要求严苛的 SLA、保护您的数据，并验证针对相关策略和法规的合规性。IT 成本可见性：68、智能规划容量，优化资源分配，并发展完整的 IT 计费模型。全面的可延展性：自定义您的环境、集成第三方解决方案，并与云服务实现互操作。l 服务器虚拟化当今的x86服务器的体系结构使其在同一时间只能运行一个操作系统。通过抽象化物理硬件的操作系统和应用资源，服务器虚拟化摆脱了x86服务器传统的一对一体系结构模式，实现了更加经济高效、更敏捷、更简单服务器环境。借助服务器虚拟化，多个操作系统能够以虚拟机方式运行在一个物理服务器上，每个虚拟机均可访问底层服务器计算资源。服务器虚拟化释放出了当今x86服务器的强大潜能。目前，大多数服务器的容量利用率不足15%；不但效率非常低下，而且还导致了服务器数量剧增并增69、加了复杂性。提供全面的服务器虚拟化平台，可实现以下成效： 服务器资源利用率提升80%； 资金和运营成本节省50%之多； 10：1或更高的服务器整合率。l 存储虚拟化存储虚拟化是软件定义的存储层的一部分，必须在不添置存储硬件的前提下改善性能和空间效率。它必须支持快速调配，以便这种高性能、高空间效率存储能够像如今的虚拟机一样快速启动并投入使用。它必须提供以虚拟机为中心的存储管理模式，这种模式对于在虚拟环境中承担更多存储管理任务的虚拟管理员来说必须非常直观。此外，它还必须与虚拟化管理程序平台集成，以发挥熟悉的本地工作流的优势。存储虚拟化是多种功能的结合体，可为需要在虚拟化部署中处理、管理和优化的物理70、存储资源提供一个抽象层。存储虚拟化技术提供了一种可从根本上更有效地管理虚拟基础架构存储资源的方法，使您的组织能够： 大幅提高存储资源利用率和灵活性； 无论采用何种存储拓扑，均可简化操作系统修补过程并减少驱动程序要求； 增加应用的正常运行时间并简化日常操作； 利用并完善现有的存储基础架构。4.2.3.2 云计算服务云计算主要分为三种服务模式，而且这个三层的分法重要是从用户体验的角度出发的：IaaS层：Infrastructure as a Service，基础设施即服务，这层的作用是提供虚拟机或者其他资源作为服务提供给用户。属于基础设施，比如网络光纤，服务器，存储设备等。IaaS平台虚拟化技术主71、要实现了对底层物力资源的抽象，使其成为一个个可以被灵活生成、调度、管理的基础资源单位。而要将这些资源进行有效的整合，从而生成一个可统一管理、灵活分配调度、动态迁移、计费度量的基础服务设施资源池，并向用户提供自动化的基础设施服务，业务服务管理平台负责将资源封装成各种服务，以方便易用的方式对外提供给系统管理。PaaS层：Platform as a Service，平台即服务，这层的作用是将开发平台作为服务提供给用户。在Issa上的一层集成的操作系统，服务器程序，数据库等。SaaS层：Software as a Service，软件即服务，这层的作用是将应用作为服务提供给客户。4.2.4 医疗业务协72、同服务创新设计本项目的医疗业务协同服务主要包括流程协同管理、数据协同管理、业务规划管理，支持跨异构业务系统之间、跨不同业务操作人员之间实现多样化、灵活快捷的交互以及全面有效的业务沟通，可加快业务流程的执行；支持业务路径管理，从而提升业务运转效率，提高服务质量和服务水平。本项目的业务协同功能设计，具备以下关键特性：（1）覆盖全生命周期的流程管理业务流程管理（BPM）提供了一种通过服务来抽象/组合业务流程的方法，和面向服务的架构（SOA）是互补的技术，SOA提供了面向技术领域的底层服务基础设施，而BPM提供了面向业务领域的业务编排和流程管理。通过全面的流程管理工具，可以实现业务流程在建模，仿真，开73、发，测试，运行，管理，监控，变更，优化等逐个业务环节的灵活服务编排和流程管理能力。（2）兼容多样化的业务场景由于业务需求和现实业务环境的复杂性，流程管理工具需要复杂环境的适应性，需要全面支持不同的业务场景。需要提供强大的系统集成能力，便于和外部的业务系统进行业务联动，实现面向系统的业务流程自动化执行；需要提供快速的任务表单生成器和友好的人工交互界面，便于在业务流程过程中友好的实现系统和人员，不同人员之间进行业务沟通；需要提供灵活多样的文档管理能力，便于在业务处理的各个环节，承载结构化和非结构化数据，实现业务信息被充分表述。4.3 总体设计框架4.3.1 总体逻辑架构XXX医联体平台总体逻辑架构74、图如下所示： 图4.3.1-1 总体逻辑架构XXXX局医联体平台整体系统架构设计，采用行业内主流的技术架构，并以国家相关标准为指导。通过进行关键需求分析，从而构建XXXX局医联体平台整体建设的系统架构，包括各系统的交互接口设计，规范数据和服务标准。1、构建全集团统一的XX局医联体平台，涵盖集团医疗卫生管理机构、集团下所有医院的基本医疗服务及公共卫生服务、运营管理、监督管理业务；2、搭建医联体级数据交换平台，实现临床诊疗、公共卫生服务和医疗卫生机构运营管理相关信息的交换与共享，进行业务与管理数据的挖掘与分析；平台和卫生计生系统外社保、民政、财政、公安等部门信息系统的数据共享；3、建立全集团统一的75、健康档案、电子病历、卫生计生资源数据仓库，基于患者主索引实现相关信息的整合和跨地区共享和交换。平台总体采用多层构架，应用平台符合开放性、流行的网络技术和标准，构造完整的多层架构应用体系。XXXX局医联体平台采用以市级为单位集中模式部署，因此应采用SOA开发框架。（一）基础网络传输层基础网络传输层是指支撑XXXX局医联体平台的硬件设备和网络平台，其是XXXX局医联体平台运行的基础，包括云平台、主机及机房资源、运行环境系统软件和业务网络等。业务网络为XXXX局医联体平台应用运行提供网络环境。按XXXX局医联体平台业务应用运行的网络安全要求，平台运行的网络包括：运营商专网、电子政务外网、互联网、VP76、N等。（二）基础云服务平台云平台、主机及机房资源、运行环境系统软件等为XXXX局医联体平台应用及数据提供计算能力、数据存储、信息传输等资源支撑。采用虚拟化技术，需基于服务器、存储和网络设备构建资源池，在资源池上通过资源的管理、调度和镜像管理实现系统的各种高级功能，包括计算层面的系统负载均衡和虚拟机高可用，存储层面的镜像复制和冗余。（三）系统支撑层应用支撑层提供一些公共平台或服务来支撑上层业务应用系统，是构建整个全民健康业务系统的核心和关键。数据交换系统平台主要是实现XXXX局医联体平台的数据存储，需要解决数据存储的结构、模型、内容、数据库管理软件的选型等。数据交换系统平台所提供资源包括电子健康77、档案、电子病历、综合管理库、索引库等。主要用于支撑跨部门、医院的全患者健康信息数据共享、业务协同与监管、大数据应用与分析以及全患者健康惠民服务。应用支撑平台基于分布式多层构架和组件技术构建，具有跨领域和通用性的特质。平台兼顾稳定性、伸缩性、安全性、可扩展性、平台兼容性以及效率等方面的要求，并充分考虑未来长远发展的需要，保证系统完整性，保护用户投资，做到统一标准、统一交换、统一管理、统一认证、互联互通和资源共享。公共平台或服务还应具有良好的可扩展性：提供上层业务应用系统所必须的接口，以保证将来开发的应用系统能够基于应用支撑平台之上进行构建。应用支撑层所提供的服务包括注册服务、主索引服务、全程健康78、档案调阅服务等。同时满足全民健康信息跨部门、跨医院的数据交换和协同应用；实现基于服务的信息资源共享交换；提供基于卫生医疗行业数据规范的业务信息采集，并对外部系统提供数据共享服务，以及数据采集、加工、转换处理、质量控制的数据集成功能。（四）业务应用体系应用层主要是XXXX局医联体平台的统一门户、包括但不仅限于：管理门户，医联体服务门户，卫生资源管理系统，药品供应与保障管理系统，处方流转系统，移动随访系统，中医药管理系统。（五）服务集群用户主要包括公众、行政管理人员、医疗机构业务工作人员等，构建全程患者健康惠民服务集群、医务工作者业务协同服务集群、综合管理服务集群。（六）安全保障体系XXX医联体平79、台的安全可分为技术层面的安全和管理层面的安全两个部分。技术层面的安全主要包括应用安全、数据安全、系统安全、网络安全、物理安全等，其中应用安全是系统业务安全防护体系的核心。管理层面的安全主要包括安全组织及人员保证、安全管理制度、安全技术规范、安全考核及监督等内容。安全保障体系是从物理安全到应用安全保障整个平台的正常运营。作为系统安全组件，必须保证数据信息的安全性和保密性。保证系统在运营过程中管理的各种资料的信息安全；保证系统与其它相关系统信息交换过程的安全；保证系统业务管理体系的安全。整个系统的安全遵循国家标准信息系统安全等级保护定级指南（GB/T22240-2008）三级标准有关要求。（七）运80、维保障体系基于XXX医联体平台规模庞大、承载服务多样、技术架构复杂、网格服务安全需求高、系统扩展性和可用性要求高等因素，主管部门建立统一运行服务体系，制定服务标准和规范，为各业务部门提供响应及时、安全可靠的运维服务，确保平台稳定可靠运行。（八）标准规范体系标准规范体系是XXXX局医联体平台中必须遵循和管理的数据标准，是系统运行和应用的数据基础。标准规范组件遵循原国家卫生计生委和广东相关标准规范，由基础类标准、数据类标准、技术类标准和管理类标准等组成。4.3.2 总体功能结构XXXX局医联体平台系统主要为管理机构和决策层、卫生业务管理机构和管理层提供全市范围内的综合信息管理服务。业务应用系统服务81、体系和三大服务集群，是在XX局医联体平台的基础上搭建的，包括公共卫生服务、行业机构服务、公共卫生管理服务、综合管理服务等应用系统服务体系及全程患者健康惠民服务集群、医务工作者业务协同服务集群、综合管理服务集群。业务应用系统服务体系和三大服务集群体系的建设提高了医疗业务质量和效率，为医院行政监督管理和决策分析提供帮助。统一和规范各医疗机构信息化建设的标准，实现医院信息的标准化和集成化，以及全医联体的数据共享交换。4.3.3 总体网络架构本项目新建的XXX医联体平台采用新搭建的医联体医疗专网，连接XX局中心医院、二级医院和XX局基层医院，实现数据信息互联互通，统一网络业务。4.3.4 数据中心架构82、本项目数据中心主要分为DMZ区、远程助诊区、信息交换区、数据服务区、影像数据区。通过网闸进行内、外网交互。图4.3.4-1 数据中心总体架构图第 5 章 项目总体设计方案5.1 业务应用系统体系本体系是医联体平台的业务应用系统部分，包括但不仅限于：管理门户，医联体服务门户，卫生资源管理系统，药品供应与保障管理系统，处方流转系统，移动随访系统，中医药管理系统。5.1.1 管理门户5.1.1.1 医疗卫生业务门户医疗卫生业务门户主要面向医联体内医务工作者，根据用户权限，为其提供其权限范围内的业务功能的集成门户，使其能通过门户获取其业务范围内的信息，完成业务操作。面向医务工作者的应用系统，通过提取相83、关业务应用系统的部分功能或业务数据到在门户做集中展示，并根据不同的业务权限，对不同应用对象建立不同的信息调阅统一视图，主要包括： 历次就诊记录。显示患者在全医联体内的历次就诊记录，包括就诊医院、就诊时间、就诊类型、诊断等。 检查报告。显示患者在就诊期间所做检查的结果，并可以查看详细的检查报告。检查报告可以集成B超、X光、放射、CT等所有的检查结果。 检验报告。显示患者在就诊期间所做检验的记录，并可查看详细的检验报告，对任一定量结果的历史变化趋势进行分析。 药敏信息。药敏信息集中显示医师分管患者的药品过敏信息，帮助医师在下达医嘱时了解患者药敏史。 医疗文档。显示患者在历次就诊期间的文档记录。 临84、床知识管理。提供临床疾病知识库、临床医技知识管理、医院知识管理、医学文献资料推送等功能。5.1.1.2 患者健康门户公众健康服务门户是通过门户把与患者服务相关的应用系统、数据资源和互联网资源统一集成，根据患者使用特点和角色的不同，将各种服务和信息、知识等内容集成到一个个性化窗口中的功能强大的系统平台。它不仅仅局限于建立一个网站，提供一些医疗服务信息，更重要的是要求能实现多业务系统的集成、能对用户的各种要求做出快速响应。患者健康服务门户利用网页、短信、微信、APP等诸多渠道为患者提供相应的应用延伸服务，包括患者电子病历查询、健康档案查询、网上预约挂号等。系统需要通过患者注册后，才能获取登录资格。85、系统采用患者健康卡、密码结合动态密码的组合方式登录。同时提供隐私权限选择，开放部分或全部内容给责任医生、家庭成员查看。5.1.2 医联体服务门户在医联体卫生医疗信息共享平台上提供可被各医疗机构应用的医联体服务门户，为终端用户提供基于医疗卫生业务即时通讯、平台访问服务。医联体服务门户的目标是建立一个用户友好的环境，在该环境下授权的医疗卫生人员可以方便地访问数据共享与交换平台中保存的客户相关数据。医联体服务门户具有以下功能和特点：v 健康档案浏览器的显示窗口嵌入。v 健康档案可以引用所被嵌入的应用程序的验证机制，直接通过医疗卫生机构注册的映射完成验证。v 健康档案调阅的认证和Consent是直接通86、过中心的服务完成，与所嵌入的应用程序的配置无关。v 医联体服务门户可以引用应用程序的当前病人信息，通过个人注册读取相关记录。v 可以通过共享交换平台来搜索、访问病人的全面的医疗记录。v 医联体服务门户可以对病人医疗记录进行重新排序、归类等工作，但不能直接更新医疗记录。v 所有调阅信息是通过中心的服务得到，不能直接调阅所嵌入的应用程序的本地数据。v 高度集成医疗卫生信息服务，通过平台，根据实际要求配置推送信息服务。部署架构如下图：图5.1.2-1 部署构架图应用样例如下图：图5.1.2-2 应用样例图5.1.3 卫生资源管理系统图5.1.3-1 资源管理系统模块图支持集团中心对全医联体卫生信息实87、施进行全面管理。该系统应具有全方位、多功能、组合式的特点，面向各个医院行政管理部门，提供包括政务管理、决策支持、办公信息、防疫信息、监督信息、药品采购信息、公众信息等的综合管理。5.1.3.1 医疗资源数据获取途径通过医联体医疗资源统计途径获得，包括全医联体内医疗机构的信息，在册医生、护士、医技人员、专家等相关信息，各种医疗设备、医疗设施，医学情报、数字图书馆等知识资源，以及配合电子地图系统的区域地理信息等。从全医联体统一的卫生统计软件、HIS系统、人事管理系统、设备管理等系统中获取。医疗资源数据采集方式：1、自动采集：已经存在信息系统或很方便构建信息系统的相关资源数据可通过自动方式采集。2、88、手工采集：对于无法通过自动方式获得的信息则通过手工录入方式维护到数据中心。5.1.3.2 医疗资源主要数据 卫生机构基本情况：包括基本信息、床位、职工构成、建筑物、设备、资产负债、年收入支出等； 人力资源基本信息：个人基本信息、专业情况、执业情况、专业培训等； 卫生机构设备信息：购置日期、价格、使用寿命、年检查治疗标本数（人次）等； 卫生机构运营情况：专科特长、等级、分科床位数、医疗卫生服务情况等； 诊所、卫生所、医务室、社区卫生服务站的运营情况； 全医联体范围内各科重点专家基本信息和联系办法； 各医院排班情况； 各医院分科床位动态使用情况； 各医院手术室使用情况 血站和大医院各型血液库存情况89、； 重要物资，药品、材料的库存情况； 急救车辆调度信息； 其他医疗资源信息。5.1.4 药品供应与保障管理系统药品供应与保障管理系统，对接药品采购信息平台数据，实现对医联体内药品信息查询、药品临床使用审查管理、合理用药信息查询、合理用药统计分析、药品全流程跟踪和药品（耗材）采购使用联动应用协同。5.1.4.1 药品信息查询提供基本药物信息查询服务，通过基本药物的电子监管码查询基本药物的信息包括：药品品目、药品名称、药品生产厂商（中药材标明产地）、药品剂型、药品规格、药品批号、药品生产日期、药品有效期、药品批准文号、药品供货单位、药品数量、药品价格、药品购进日期。5.1.4.2 药品临床使用审查90、管理5.1.4.2.1 药物过敏史审查在获取患者既往过敏药物信息的基础上，提示患者用药处方中是否存在可能导致类似过敏反应的药品。5.1.4.2.2 老年人用药审查根据患者年龄，提示处方中是否存在老年人应禁忌或慎用的药品。5.1.4.2.3 儿童用药审查根据患者年龄，提示其处方中是否存在儿童应禁忌或慎用的药品。5.1.4.2.4 妊娠期妇女用药审查提示当患者为妊娠期妇女时，其处方药品中是否存在不适合妊娠期妇女使用的药品。5.1.4.2.5 哺乳期妇女用药审查提示当患者为哺乳期妇女时，其处方药品中是否存在不适合哺乳期妇女使用的药品。5.1.4.2.6 药品超计量审查对所有药品的单次量、单日量进行审91、查。5.1.4.2.7 给药途径审查对处方所开的实际用药途径进行审查。5.1.4.3 合理用药信息查询5.1.4.3.1 药物咨询提供药物基本信息查询，查询范围是药品临床使用指南信息库提供的所有药品信息。5.1.4.3.2 药物相互作用与配伍问题提供药品临床使用指南信息库中的药物相互作用和配伍问题的查询功能。5.1.4.3.3 适应症查询根据诊断和病生理状态选择药物，根据诊断名称检索出与治疗该疾病相关的药品，同时对儿童、老年、孕妇、哺乳期妇女、肝功能不全、肝功能严重不全、肾功能不全、肾功能严重不全的禁慎用药的药品进行提示。5.1.4.3.4 抗生素分类及禁慎用症根据抗生素的类别，列出该类别下的92、抗生素药品，同时对儿童、老年、孕妇、哺乳期妇女、肝功能不全、肝功能严重不全、肾功能不全、肾功能严重不全的禁慎用药的药品进行提示。5.1.4.3.5 肝、肾功能不全用药量调整肝、肾功能不全用药量调整的相关查询，针对肝功能不全、肾功能不全患者，提供用药剂量调整方法。5.1.4.3.6 FDA妊娠期药物分类FDA妊娠期药物安全级别查询，从而了解药品对妊娠期间妇女的危害性。5.1.4.3.7 抗菌药物指导原则与相关查询查询根据国家卫健委颁发的抗菌药物临床应用指导原则概括出来的抗菌药、病原微生物、感染疾病三者之间的对应关系。5.1.4.3.8 检验值与诊断临床检验查询，输入一个检验结果，可以提示相应的临93、床意义。5.1.4.3.9 常用医学公式提供多种常用医学公式，涉及心脏学、儿科、血液学、神经学、肺脏学、肾脏学、管理学、动脉血气分析、妇产科、营养体液及电解质科目。简便实用、操作方便。5.1.4.3.10 中药用药禁忌查询提供中药用药禁忌相关知识的查询。5.1.4.3.11 用药指南用药科普知识查询，提供合理用药方面的科普知识。5.1.4.3.12 相关医药法律法规提供合理用药相关的法律法规，供医生、药师进行查询。5.1.4.4 药品全流程跟踪5.1.4.4.1 药品采购信息跟踪药品采购信息总览；药品采购信息查询（按订单基本信息、订购药品、订单处理状态查询）；药品采购情况排名（按订购药品的数量94、同一药品的订购单价、按要求送达的时间排名）。药品采购的跟踪记录信息包括：药品采购订单基本信息：订单编号、订单日期、要求送达时间、订购医院、订购操作人等；订购药品的信息：药品名称、类型、单价、数量等；订单处理信息：订单的处理状态和预计送达时间。5.1.4.4.2 药品入库、储存信息跟踪药品入库信息总览；药品入库信息查询（按入库基本信息、药品信息、财务信息查询）。药品入库的跟踪记录信息包括：入库记录：入库时间、操作人、药品数量、采购订单编号、物流配送编号等；药品信息：药品名称、类型、数量、批次等；财务记录：采购款项结算信息。药品库存信息总览；药品库存信息查询（按入库基本信息、药品信息查询）；药品95、库存预警，针对药品有效时间（即将失效的药品）、库存数量(库存数量低于库存下限或高于库存上限的药品)，予以预警提示。药品（疫苗）储存的跟踪记录信息包括：库存基本信息：入库时间、操作人、药品数量、采购订单编号、物流配送编号、入库单号等；药品（疫苗）信息：药品（疫苗）名称、类型、数量、批次等；储存记录：药品储存位置、储存环境、药品损耗记录、辅助损耗记录等。5.1.4.4.3 药品使用信息跟踪普通药物使用信息跟踪普通药物使用情况总览；普通药物使用情况查询（按药品信息、患者信息、药品使用基本信息查询）；按照药品种类，统计药品使用的频率次数、最大使用量的药品名，并进行排名并预警。普通药物使用的跟踪记录信息96、包括：药品使用基本信息：开药医师、开药机构、开药科室、执行者、审核者、开药时间等；药品信息：药品名称、剂型、规格、类型等；患者信息：患者姓名、年龄、性别、就诊号、就诊类型等抗菌药物使用信息跟踪抗菌药物使用情况总览；抗菌药物使用情况查询（按药品信息、患者信息、药品使用基本信息查询）；按照抗菌药物种类，统计抗菌药物的使用频率次数、最大使用量的抗菌药物名称，进行排名并预警。抗菌药物使用的跟踪记录信息包括：药品使用基本信息：开药医师、开药医师职称、开药机构、开药科室、执行者、审核者、开药时间等；药品信息：药品名称、剂型、规格、类型、抗菌药物级别等；患者信息：患者姓名、年龄、性别、就诊号、就诊类型等。毒97、麻精药物使用信息跟踪毒麻精药物使用情况总览；毒麻精药物使用情况查询（按药品信息、患者信息、药品使用基本信息查询）；按照毒麻精药物种类，统计毒麻精药物的使用频率次数、最大使用量的毒麻精药物名称，进行排名并预警。毒麻精药物使用的跟踪记录信息包括：药品使用基本信息：开药医师、开药医师职称、开药机构、开药科室、执行者、审核者、开药时间等；药品信息：药品名称、剂型、规格、类型、毒麻精药物类型等；患者信息：患者姓名、年龄、性别、就诊号、就诊类型等。基本药物使用信息跟踪基本药物使用情况总览；基本药物使用情况查询（按药品信息、患者信息、药品使用基本信息查询）；按照药品种类，统计药品使用的频率次数、最大使用量的98、药品名，并进行排名并预警。基本药物使用的跟踪记录信息包括：药品使用基本信息：开药医师、开药机构、开药科室、执行者、审核者、开药时间等；药品（疫苗）信息：药品（疫苗）名称、剂型、规格、类型等；患者信息：患者姓名、年龄、性别、就诊号、就诊类型等。重复用药情况跟踪重复用药情况总览；重复用药情况查询（按药品信息、患者信息、药品使用基本信息查询）；按照不同维度（时间、医院、科室）统计重复用药情况，进行排名并预警。重复用药的跟踪记录信息包括：药品使用基本信息：开药医师、开药机构、开药科室、执行者、审核者、开药时间等；药品（疫苗）信息：重复用药药品（疫苗）名称（多个）、剂型（多个）、规格（多个）、类型（多个99、）、主要成分等；患者信息：患者姓名、年龄、性别、就诊号、就诊类型等。药物过敏情况跟踪药物过敏情况查询（按药品信息、患者信息、过敏信息、药物使用基本信息查询）；按照不同维度（时间、医院、科室）统计药物过敏情况，进行排名并预警。药物过敏的跟踪记录信息包括：药品使用基本信息：开药医师、开药机构、开药科室、执行者、审核者、用药时间等；过敏基本信息：过敏症状、过敏症状出现时间等；药品（疫苗）信息：药品（疫苗）名称、剂型、规格、类型等；患者信息：患者姓名、年龄、性别、就诊号、就诊类型等。药物禁忌情况跟踪药物禁忌情况总览；药物禁忌情况查询（按药品信息、患者信息、药品使用基本信息查询）；按照不同维度（时间、医100、院、科室）统计药物禁忌情况，进行排名并预警；药物禁忌的跟踪记录信息包括：药品使用基本信息：开药医师、开药机构、开药科室、执行者、审核者、用药时间等；药物禁忌信息：药物禁忌症状、药物禁忌原因、禁忌症状出现时间等；药品信息：禁忌药品名称（多个）、剂型（多个）、规格（多个）、类型（多个）等；患者信息：患者姓名、年龄、性别、就诊号、就诊类型等。5.1.5 处方流转系统医院外流处方信息共享，指将医院的处方信息、院外终端的药品进销存流通信息、医保药品的自费信息或医保药品统筹结算信息等通过电子化的方式，共享到一个信息系统平台，患者可以凭医院处方在院外药店自由购买药品，医保药品同时还可以报销。5.1.5.1 101、互联网电子处方在实体医院基础上，运用互联网技术提供安全适宜的医疗服务，允许注册或者备案的执业医师在线开展部分常见病、慢性病复诊，允许掌握患者病历资料后在线开具部分常见病、慢性病处方。5.1.5.2 接入服务机构支持医疗卫生机构、符合条件的第三方机构搭建互联网信息平台，开展远程医疗、健康咨询、健康管理等服务。5.1.5.3 互联网医疗服务为居民在线提供健康咨询、慢性病随防、延伸处方、健康管理等服务。还在这种模式中导入医保支付政策，引导网络诊疗的氛围形成；明确提出建设处方流转信息，推进处方信息共享，打破医疗机构信息孤岛；重视“社会力量”，指明处方外流方向是：推广处方流转平台，发展配送中心，支持医院102、药品生产流通企业、药店、符合条件的第三方机构共同参与处方流转、药品物流配送。鼓励社会力量建设和运营药事服务平台，为基层医疗卫生机构、居民提供审方、合理用药咨询和精简处方等社会化药事服务。）推广智慧药房，鼓励医院处方外配、信息共享，改造传统药品保障流程，为患者提供“一站式”药事服务。5.1.5.4 与零售药房对接处方流转系统将医药企业、零售药房、医院药房等资源进行整合形成中央大药房，利用云计算技术与XXX医联体平台对接，在较大的范围内为各层医疗机构提供优质药品的输送，有助于实现医疗资源的均衡，进而有效缓解医药分离后出现的门诊量剧增、药房库存不足等问题。中央大药房的建立一方面可以大大降低基层医疗103、机构药房建设的投入，能够将优质的药品输送到基层医疗机构，统一了药品目录，规范了药品项目编码，及时更新库存信息，实现医疗药品信息共享与互通；另一方面也为医保报销、药品监控提供了更便捷的手段和大数据支持。中央大药房的建立还有利于实现处方信息的电子流转，规范处方药品的应用与流通，进一步保障人群用药安全，并促进医改政策落实，创新医疗服务模式。用户可以自主选择在医院药房取药、到指定的附近零售药房取药，也可以选择通过线上药店快递药品。5.1.5.5 对接第三方物流平台处方流转系统对接第三方物流平台，运用理论和需求链理论，融入向供应商和药房双向高度集成的药品物流模式。系统平台通过物流服务外包实现向供应商集成104、，通过取消药库，利用第三方合作药企、药店和医院药房资源通过系统平台进行各药品配送服务，实现区域药品配送信息共享，完成整个由开方、计费、自动识别到配发药的全过程。患者可通过系统应用端，看查到药品的订单信息、发票信息、发货信息，清晰展示物流配送信息。5.1.6 移动随访系统系统按照国家公共卫生基本服务规范罗列出10大块的功能。首页模块清晰、界面友好方便。主体通过居民的健康档案来进行随访，自动创建随访计划，增加提醒机制让医生无后顾之忧。首页还明确显示当前在访的居民，可随时进行居民的切换，操作很便捷。移动随访包中包括额温枪，血压计，血氧仪，血糖仪，心电仪，尿常规，身份证读卡器，平板电脑。5.1.6.1105、 健康档案健康档案是患者身份的主体，有档案才可随访，此处提供查询档案和新建档案。可通过在线查询或者直接通过读取身份证进行档案的查询和新建。5.1.6.2 健康体检使用新兴的蓝牙设备连接pad，为居民提供多项体征检测。使用蓝牙无缝连接，一键连接自动显示结果，亦可连接蓝牙打印机打印体检结果。也可查看体检记录详情。5.1.6.3 0-6岁儿童健康管理对垦区内的儿童进行年龄区间内的随访，重点询问和观察生长发育情况，并填写表格，特别注重缺陷多胎可进行多次访视，提供良好的健康指导，维护儿童健康成长。也可查看儿童的随访记录进行更好的干预指导。5.1.6.4 孕产妇健康管理对垦区内常住的孕产妇进行阶段性的随访106、，重点进行健康状况评估、营养保健指导，后期进行心理、自我监护等，并填写相关表格，特别注重高危孕产妇的访视，促进胎儿正常生长分娩。功能包括新建随访表、创建专项卡、查看随访记录。5.1.6.5 老年人健康管理对65岁及以上的老人进行随访，重点进行体格评估、健康生活指导，并填写相关表格，重点关注慢性病老人的情况。功能包括新建随访表、创建专项卡、查看随访记录、4项生理评估。5.1.6.6 慢性病患者健康管理对35岁以上的慢性病患者（高血压和糖尿病）进行随访，重点进行健康评估，后根据评估结果进行相应的健康生活指导，达到控制病情的目的。功能包括新建随访表、创建专项卡、查看随访记录。5.1.6.7 严重精神107、障碍患者管理对严重精神障碍患者进行随访，重点进行精神状态机危险性评估，对症治疗，进行康复指导，达到控制病情的目的。功能包括新建随访表、创建专项卡、查看随访记录。5.1.6.8 肺结核患者管理对肺结核患者进行随访，重点进行居住环境及状态的评估，对家属进行防治传教，督促服药及分类干预。功能包括新建随访表、创建专项卡、查看随访记录。5.1.6.9 突发公卫事件报告主要是对传染病以及突发性公卫事件进行上报。及时上报，有助于加快病情的控制。5.1.6.10 健康教育及监管主要是对健康教育活动及监管活动的登记。增加健康知识和健康视频的文章和视频传教，利于工作的开展，促进居民的身心健康。5.1.6.11 预108、防接种对垦区内的儿童进行预防接种，按照月龄进行相应疫苗的接种，关注儿童的健康成长。功能包括新建预防接种卡、新建接种记录、新建接种异常反应记录，查看接种记录，查看儿童疫苗免疫程序表。5.1.6.12 家庭医生签约医生对常驻居民进行签约服务，随后按照国家规定的公共卫生服务规范的13项服务内容对居民进行随访以及体检等服务，切实关注一般人群和特殊人群的健康。5.1.7 中医药管理系统打造医联体整合的辅助开方、实时会诊、移动复诊、影像共享、检验共享、双向转诊、电子病历共享等信息服务应用体系。通过规范的IT管理，形成一套统一规范的数据建设规范、安全管理规范、接口标准规范等，有助于后续进一步的功能扩展以及延109、伸。平台通过提供标准的中药处方数据库、症候采集标准数据库、中药饮片数据库等，不仅可以辅助医生收集临床症候，进一步快速开出标准的中药处方，并且可以支持在线跨院专家实时会诊。同时通过接口中心，调用外部系统接口，快速获取更多有价值的信息。5.1.7.1 辅助开方中医辨证论治智能辅助系统利用“一个中心”、“两个结合”、“三重诊断”、“四条路径”科学理论进行辅助开方。精选历代医家留下经典名方、验方，利用互联网与人工智能技术，针对临床常见病、多发病，依据中医辨证论治理论，以现代医学疾病和中医辨证论治为切入点，协助医生快速、精准、安全、科学开具中药处方。一个中心：以辨证论治为中心两个结合：中西医结合、辨病辨110、证相结合三重诊断：西医疾病诊断、中医疾病诊断、中医辨证分型诊断四条路径：西医疾病辨证开方、中医疾病辨证开方、方剂检索开方、症候群语义识别辨证开方5.1.7.2 实时会诊实时会诊包括院内会诊、医联体内会诊以及移动会诊。院内会诊即为申请医院内中医科医生辅助其他科室医生进行中医处方会诊；医联体内会诊为向医联体内专家申请会诊；移动会诊即为医院向移动端在线的专家申请会诊。会诊过程中，开方医生与会诊医生可以即时沟通，共享开方医生已开具的中药处方，同时会诊双方可以修改处方内容，修改的内容可实时同步给另一方。平台通过集成即时通讯模块，确保开方医生与会诊医生可实现语音、图片、文字的即时沟通，减少开方医生和患者在111、面诊时等待会诊的时间。5.1.7.3 移动复诊开展“互联网+”中医医疗服务，开展远程医疗、健康咨询、健康管理服务，促进医院、医务人员、患者之间的有效沟通。运用互联网技术提供安全适宜的中医医疗服务，在线开展部分常见病、慢性病复诊。医师掌握患者病历资料后，开展在线开具部分常见病、慢性病处方。构建覆盖诊前、诊中、诊后的线上线下一体化中医医疗服务模式，拓展医疗服务空间和内容。居民通过关注微信公众号，填写个人信息，即可选择医生复诊。复诊过程中，医生可以手动开出中药处方，也可调用标准处方库开处方，开出的处方可自动计算价格。居民直接通过微信即可支付药费。如果居民勾选了中药代煎、配送的服务，则处方可以自动流转112、至药事服务平台，进行后续药事审方、抓药、煎药等流程。5.1.7.4 药事服务药事服务平台通过整合医院、厂家、代煎中心、患者、中药房、物流等多方资源，能够实现区域化药品供应、生产、订购产业链智能化，中药处方开方、审方、分发、代煎、配送流程智能化。医院提出中药药品需求清单，同时中药生产厂家提供供应药品清单及价格，平台实现供应关系分配后，在签订了三方协议的前提下，厂家供药，医院打款，过程中平台监督药品配送跟踪以及订单货款的回款跟踪、发票开取过程跟踪。最后所有过程中的数据能够进行统计汇总，生成药品订单统计结果。医生通过HIS系统开出的中医诊疗处方，当患者选择了自动代煎后，即可通过分发引擎匹配最佳的审方113、药剂师资源及代煎中心资源。审方药剂师在审方之前必须经过国家级资质认证及人脸识别保证该审方者是有资质的药剂师本人。同时药剂师审方需要经过手写签名来保证法律有效性。只有通过药剂师审核的处方才能流转到代煎中心进行煎药配送等后续流程。5.2 平台支撑系统体系平台支撑系统体系包括但不仅限于：机构管理，用户管理，目录服务，订阅服务，注册服务，居民主索引（EMPI），全程健康档案服务，医疗卫生信息共享和协同服务，区域医疗业务数据整合和调用服务，数据交换服务，数据采集，外部接口。5.2.1 机构管理提供医联体内所有医疗卫生机构的综合目录的管理。相关机构包括二三级医院、社区卫生服务中心、妇幼保健院等。平台为每个114、机构分配唯一的标识，可以解决医疗卫生服务机构唯一性识别问题，从而保证在维护患者健康信息的不同系统中使用统一的规范化标识符。同时也满足平台、医疗卫生机构服务的互联互通要求。机构采用两级维护方式，XXX负责对接入平台的各机构进行维护，机构内部的组织单元由机构内部的系统管理员进行配置。5.2.2 用户管理5.2.2.1 用户与用户组管理用户定义：系统的最终使用者是用户，因此必须建立用户的鉴别机构，登记用户的身份信息。在系统中定义可登录的用户操作系统是系统安全管理所必须步骤，也是人与系统的接口。根据两级机构的维护模式，机构内部的系统管理员由XXX信息中心进行维护，机构内部的人员由机构指定的系统管理员进115、行维护。用户组定义：为了本系统适用于分散式权限管理，加入了用户组的概念，是指一群用户的集合。方便权限管理用户组也可以委派角色，当用户被加入用户组时自动对用户的所在用户组拥有的角色进行了委派。为了便于分散式权限管理系统同时还支持对部分组的权限进行下发方式处理，授权特定的用户对用户组的用户权限进行管理。5.2.2.2 角色管理角色是指一个组织或任务中的工作或位置，它代表了一种资格、权利和责任。我们用ROLES表示一个角色集合。角色是用户权限的基础。用户可以扮演多个角色。将某一角色授予某一用户时，该用户就具体此角色拥有的权限，一个用户可以同时拥有多个角色。5.2.2.3 隐私与权限管理XXX医联体平116、台的数据交换基础平台需要提供完善的隐私与访问权限管理，本项目中的数据涉及患者健康情况隐私，医疗机构运转数据隐私等，本设计方案包含了数据使用时的统一身份认证，统一权限管理等，同时也包括系统软件和应用软件应具有访问控制功能，包括用户登录访问控制、角色权限控制、目录级安全控制、文件属性安全控制等；系统软件(包括操作系统，数据库等)和应用软件等应定期进行完全备份，系统软件配置修改和应用软件的修改应及时备份，并做好相应的记录文档；及时了解系统软件和应用软件厂家公布的软件漏洞并进行更新修正；应用软件的开发应有完整的技术文档，源代码应有详尽的注释；使用基于PKI-CA体系的数字证书实现各业务应用系统的用户身117、份验证、数字签名等功能。v 身份认证基础设施整个系统的基础，平台整合了数字证书，用户密码模式，动态口令卡，手机动态密码，指纹等多种身份认证模式，并支持接入各地的CA机构。v 应用安全管理基于多种身份认证模式对涉及医联体医疗卫生安全要素的统一管理，要包括统一身份管理、医疗卫生角色管理、卫生信息资源管理、医疗卫生授权管理等。v 应用安全中间件基于身份认证基础设施和应用安全管理平台，将医疗卫生安全应用以独立中间件服务的方式提供给医院，社区等医疗卫生信息系统使用，从而完成统一的电子健康信息网络安全应用平台的构建。这些中间件主要包括关于身份认证服务的中间件、关于数据安全服务的中间件、关于医疗行为审计服务118、的中间件。v 统一身份认证数字证书认证中心(Certificate Authority，CA)主要负责产生、分配并管理所有参与网上交易的个体所需的身份认证数字证书。每一个数字证书都与上一级的数字签名相关联，最终通过一个安全链追溯到一个已知的并被广泛认为安全、权威、足以信赖的机构。电子交易的各方都必须拥有合法的身份，即由CA中心签发的数字证书，在交易的各个环节，交易的各方都需检验对方数字证书的有效性，从而解决用户的信任问题。在本系统建设中，可直接利用市级或省级数字认证中心已有的CA中心的身份识别基础设施。通过卫生数据中心平台，各应用系统调用各种中间件，方便地实现医联体卫生网络系统统一的身份管理与119、授权管理。v 采用PKI加密基于健康档案的患者健康信息综合管理平台采用加密技术来保护敏感信息的传输，保证信息传输中的安全性。在一个加密系统中，信息使用加密密钥加密后，得到的密文传送给接收方，接收方使用解密密钥对密文解密得到原文。目前主要有两种加密体系：秘密密钥加密和公开密钥加密。v 数字签名的应用在基于健康档案的健康信息综合管理平台建设过程中涉及到电子健康档案和电子病历的传输和共享，因此我们需要采用电子签名技术来保证电子健康档案系统的安全性和不可抵赖性。通过医联体卫生数据中心平台，医院的医生可通过调用身份认证(可采用数字证书或指纹模式)、数字签名、数据加密等服务将电子病历上载到卫生数据中心中共120、享，卫生数据中心可对电子病历信息资源共享的机制进行设置与管理，其他医院医生则通过调用身份认证(可采用数字证书或指纹模式)、方问控制、数据解密等服务对电子病历进行调阅，病人也可通过卫生服务网站调用身份认证(可采用手机动态密码方式)、访问控制、数据解密等服务对自己的电子病历进行远程查询，从而实现医联体内电子病历的安全共享和访问，为电子病历法律化奠定技术基础。图5.2.2.3-1 平台数字签名系统结构图1、 安全模型在数据共享交换平台中权限管理至关重要，不同的用户具有不同的权限，使用不同的信息路由路径，对各应用节点的接口调用进行身份验证。这样保证了系统的安全性、可靠性和稳定性。系统应从不同的角度进行121、相应的权限管理，功能权限指对接入平台的各个应用以及功能服务的访问权限；数据集权限即数据项权限，是指用户对传输中的信息各数据项的访问权限；管理范围及记录权限，是作为共享数据信息内容的访问权限。当用户所具有的信息，符合通过管理范围设定出的特殊匹配条件时，允许用户访问相应管理范围所规定信息内容；权限方案允许用户导出和导入。便于权限管理信息的分发和设定；用户还可对自己相应的权限信息进行打印。所有使用用户都被看做客户端，这些客户端访问系统的目的是获取某些资源，系统在接收到客户端的访问请求时，首先会对用户的身份进行检验，判断是否是合法用户，如果检验通过，系统继续根据访问控制列表来获取该用户对哪些资源具有访122、问权限，通过定义一组系统角色，然后对这些角色进行授权，再将用户和角色对应起来实现的。在确定了用户对授权资源的访问权限后，系统还得确定用户的访问控制范围。由于在LDAP服务器中，数据以目录信息树的形式进行存储的，所以我们不仅需要知道用户可以访问哪些分支（访问控制列表确定），还需要确定用户这些分支的可访问深度，这就是用户的访问控制范围所要确定的内容。在进行了这些判断之后，系统就可以找到用户所要查找的资源，并以条目结果集的方式返回给客户端，然后客户端就可以直接和LDAP数据库交互，进行各种操作了。内部功能实现过程如下：图5.2.2.3-2 流程示意图外部调用过程如下：图5.2.2.3-3 目录服务体123、系结构设计XXX数据中心应用目录服务技术将用户群(提供数据和访问数据单位、人员等)和现有资源情况按照主题目录的方式纳入到目录服务中，这样用户通过命名、描述和指定系统范围内的用户和资源，从而简化通信与管理，做到通过简单的搜索查找资源及其他用户，帮助管理人员收集和控制相关的信息，并可以使他们全面地审视这些信息。2、 CA方案设计建立CA体系，实现身份鉴别与抗抵赖性。系统应具有如下功能： 用户管理：用户在CA系统内的注册、注销。只有注册的用户可以使用系统的证书、密钥管理服务，RA系统管理员负责用户在PKI系统中的注册、注销。 证书管理：用户证书的申请、发放、发布、和撤销。注册的用户可以向系统提交证书124、申请，经过RA管理员确认后，再提交到CA系统，由CA管理员为用户发放证书。CA发放的证书通过RA发布到LDAP目录服务系统。用户也可以向系统提交证书撤销申请，经过RA管理员确认后，再提交到CA系统，由CA管理员产生CRL。用户的证书申请和证书撤销申请也可以由RA直接产生。 密钥管理：用户密钥的产生、备份、恢复系统可以为用户产生密钥对，并备份必要的密钥，当用户丢失密钥时，可以由系统恢复有关密钥，防止重要信息无法解密。系统必须满足： 与用户的具体应用无关，对系统原有功能和效率影响较小； 符合国际标准，具有良好的互操作性； 所签发的数字证书可以用于SSL协议和S/MIME协议； 与各种支持SSL和S125、/MIME的浏览器和邮件客户软件，如Microsoft Internet Explorer、Microsoft Outlook和Netscape Navigator、Netscape Messenger等兼容； 与各种支持SSL的Web服务器，如Microsoft Internet Information Server、Domino、Netscape Enterprise Server等兼容； 高度的安全性； 支持CA分层结构，便于扩展系统结构； 完全采用Web作为管理界面和用户界面，易于使用。3、 访问控制设计访问控制是控制不同用户对信息资源的访问权限，确保主体对客体的访问只能是授权的，未经126、授权的访问是不允许的，其操作也是无效的，对用户尽可能提供细粒度的控制。考虑到内部网络系统结构上的划分，我们从四个层次上考虑访问控制：虚拟局域网（VLAN）、操作系统、数据库、应用系统。各个层次的作用及实现技术各不相同，用来保护相应的安全领域。 VLAN：内部网络中的网络设备及服务器，由于其应用特点，为了安全，可以限制在特定网络中只能供某一些特殊用户使用资源，所以还必须对内部网络（局域网）进行划分，并对划分的网络进行访问控制的设置。 操作系统（NT 或 Unix）本身已具有一定的访问控制功能，如用户的创建与删除、访问控制权限的设置等等，但由于操作系统本身存在的问题及管理上的问题，要实现严格的访问127、控制还会有许多问题。 数据库：定义用户安全级别和数据信息的安全属性，定义如下访问规则：用户只可以读安全属性不高于他的安全级别的数据；用户只可以向安全属性不低于其本身安全级别的数据对象中写入。 应用系统：按照用户口令字方式，给采用采用模块授权和组织授权分离的模式。如有可能可结合采用智能卡方式。4、 身份管理设计一个完整的身份管理解决方案包括以下组件： 可伸缩的、安全并且符合标准的目录服务，用于存储和管理用户信息。 用户供应框架，可以连接到不同的系统（如数据库、操作系统、目录服务、应用等），建立起用户身份和不同的系统帐号之间的对应关系，建立起统一的身份管理视图。 委托管理模型和应用程序，使身份管理128、系统的管理员可以将访问权有选择地授予应用程序的管理员或直接授予终端用户。一个能够支持不同需求的适当的安全模型（用户接口模型）是非常关键的。 目录集成平台，使数据中心能够将身份管理目录与原有或应用的特定目录相连，实现目录间的用户信息同步以及虚拟目录应用等机制。 用于用户认证/授权的运行时模型和应用程序。特别的，考虑到整个技术支撑平台采用SOA架构以及Web服务的方式来搭建，因此，提供用于管理SOA架构中的Web元件、Java对象、门户Portlet以及Web服务接口等的统一认证授权管理模型和平台是其中设计的重点。5、 患者隐私管理为了保证电子健康信息共享的同时实现对患者隐私的保护，平台必须对电子129、健康信息提供权限管理机制。电子健康信息的权限管理根据医生、管理者、患者等不同的角色进行权限管理，权限管理按等级实现个人级、文件类别级、文件级、患者自定义保护级四级保护机制。“用户名密码验证码”认证通过“用户名密码验证码”的方式对用户进行认证，软键盘进行密码的输入，用户名与验证码通过键盘输入。用户密码经过HASH处理后，保存到数据库中，保证了密码的安全性。在某些信息系统应用中（如：电子病历、医疗文书等），在需要电子签名的地方，还应辅以电子密钥技术进行加密传输识别，来保证信息的安全、可靠和唯一性。图5.2.2.3-4 患者隐私管理目标 患者本人可以访问自己主观与客观的医疗数据，不能访问其它人的主观130、与客观的医疗数据； 医护人员对客观医疗数据的访问在满足访问规则的条件下才能访问，否则拒绝访问； 医护人员对主观医疗数据的访问需要经数据产生机构授权，同时满足客户医疗数据访问规则才能进行访问，否则拒绝访问； 管理人员可以直接对客户医疗数据进行访问； 管理人员对数据主观数据的访问需要数据产生机构进行授权。访问控制实现流程图5.2.2.3-5 访问控制流程图关系作用的时效性：是指操作人员最近一次给患者医疗的时间是否与系统定义的直接查看患者信息的有效时间作对比，如果在有效时间范围内，则可以直接查看患者客观医疗数据；验证码时效性：当操作人员输入了输入码后，在系统规则的有效时间范围内查询患者信息时，则不需131、要重复输入输入码，如果超过系统规则，则提示需要重新输入密码；验证码：验证码是一个广义的说法，如果是全市统一就诊卡，验证号可以理解为就诊卡号，如果通过终端用户输入密码的形式，验证码可以理解为用户密码。6、 授权服务设计授权服务系统在信任服务系统基础上，为应用提供资源的授权管理及访问控制服务。授权管理服务系统以PKI技术为基础，对资源的访问授权由资源的管理者来进行控制分配。资源管理者通过授权管理服务系统为资源使用者分配资源访问权限，并加以签名。应用系统核验资源使用者的访问权限，达到资源安全访问的目的。集团中心以集中式授权服务模式统一管理在业务面上运行的主要应用与资源，采用分布式授权服务模式由各地管132、理可供共享的资源。基于角色的授权管理功能，定义各种用户角色。支持不同角色的用户访问受保护的患者健康信息，同时保证这些信息的保密性和安全性，提供机制来记录对该类信息的访问，并能产生记录报表。授权流程图5.2.2.3-6 授权流程访问控制当用户请求访问患者信息时，信息共享平台中的访问控制引擎根据用户请求访问的信息类型，医患关系和患者的类型等信息来定义访问控制的规则。访问控制的规则和相应的处理结果如下表：检测项操作没有权限Deny患者是VIP，用户有合法的医患关系或角色BTG合法的医患关系Allow合法的角色Allow其他BTG或Denyv Allow 允许访问v Deny 不允许访问v Break133、 The Glass(BTG) 在特殊情况下，用户需要越界访问患者健康信息，则将用户的请求记录到安全审计日志，并允许访问。例如，如果病人在此医院有就诊记录任何在此医院的医生能够查阅数据。但此医院的护士只能在住院期间查阅数据。如果此医生曾经对病人作过治疗与记录，不管这个病人现在那个医院，此医生仍可查阅病人信息。患者信息授权流程图5.2.2.3-7 患者信息授权流程5.2.3 目录服务整个数据中心系统建立统一的目录服务，管理集团卫生信息网络接入的各医疗机构及人员信息；目录服务中优先采用LDAP（Light Directory Access Protocol，轻量级目录访问协议）技术。通过命名、描述134、和指定系统范围内的用户和资源，从而简化通信与管理，做到通过简单的搜索查找资源及其他用户，帮助管理人员收集和控制相关的信息，并可以使他们全面地审视这些信息。本期目标至少要把用户群(提供数据和访问数据机构、人员等)和现有资源情况纳入到目录服务中。通过机构/用户管理可以规范用户对集成平台的使用行为，根据用户的组织机构设置相应的用户组和对应的用户。用户管理应该能够对用户进行全面的管理，包括用户组的增加、修改和删除；用户的增加、修改和删除；用户与用户组之间的对应；以及其于角色的权限管理安全可靠的密码管理功能。 信息模型在LDAP中信息以树状方式组织，在树状信息中的基本数据单元是条目，而每个条目由属性构成135、，属性中存储有属性值；LDAP中的信息模式，类似于面向对象的概念，在LDAP中每个条目必须属于某个或多个对象类（Object Class），每个Object Class由多个属性类型组成，每个属性类型有所对应的语法和匹配规则；对象类和属性类型的定义均可以使用继承的概念。每个条目创建时，必须定义所属的对象类，必须提供对象类中的必选属性类型的属性值，在LDAP中一个属性类型可以对应多个值。 在LDAP中把对象类、属性类型、语法和匹配规则统称为Schema，在LDAP中有许多系统对象类、属性类型、语法和匹配规则，这些系统Schema在LDAP标准中进行了规定，同时不同的应用领域也定义了自己的Sche136、ma，同时用户在应用时，也可以根据需要自定义Schema。这有些类似于XML，除了XML标准中的XML定义外，每个行业都有自己标准的DTD或DOM定义，用户也可以自扩展；也如同XML，在LDAP中也鼓励用户尽量使用标准的Schema，以增强信息的互联互通。在Schema中最难理解的是匹配规则，这是LDAP中为了加快查询的速度，针对不同的数据类型，可以提供不同的匹配方法，如针对字符串类型的相等、模糊、大于小于均提供自己的匹配规则。 命名模型LDAP中的命名模型，也即LDAP中的条目定位方式。在LDAP中每个条目均有自己的DN和RDN。DN是该条目在整个树中的唯一名称标识，RDN是条目在父节点下的137、唯一名称标识，如同文件系统中，带路径的文件名就是DN，文件名就是RDN。 功能模型在LDAP中共有四类10种操作：查询类操作，如搜索、比较；更新类操作，如添加条目、删除条目、修改条目、修改条目名；认证类操作，如绑定、解绑定；其它操作，如放弃和扩展操作。除了扩展操作，另外9种是LDAP的标准操作；扩展操作是LDAP中为了增加新的功能，提供的一种标准的扩展框架，当前已经成为LDAP标准的扩展操作，有修改密码和StartTLS扩展，在新的RFC标准和草案中正在增加一些新的扩展操作，不同的LDAP厂商也均定义了自己的扩展操作。 安全模型LDAP中的安全模型主要通过身份认证、安全通道和访问控制来实现。 138、身份认证 在LDAP中提供三种认证机制，即匿名、基本认证和SASL（Simple Authentication and Secure Layer）认证。匿名认证即不对用户进行认证，该方法仅对完全公开的方式适用；基本认证均是通过用户名和密码进行身份识别，又分为简单密码和摘要密码认证；SASL认证即LDAP提供的在SSL和TLS安全通道基础上进行的身份认证，包括数字证书的认证。 通讯安全 在LDAP中提供了基于SSL/TLS的通讯安全保障。SSL/TLS是基于PKI信息安全技术，是目前Internet上广泛采用的安全服务。LDAP通过StartTLS方式启动TLS服务，可以提供通讯中的数据保密性、139、完整性保护；通过强制客户端证书认证的TLS服务，同时可以实现对客户端身份和服务器端身份的双向验证。 访问控制 虽然LDAP目前并无访问控制的标准，但从一些草案中或是事实上LDAP产品的访问控制情况，我们不难看出：LDAP访问控制异常的灵活和丰富，在LDAP中是基于访问控制策略语句来实现访问控制的，这不同于现有的关系型数据库系统和应用系统，它是通过基于访问控制列表来实现的，无论是基于组模式或角色模式，都摆脱不了这种限制。 在使用关系型数据库系统开发应用时，往往是通过几个固定的数据库用户名访问数据库。对于应用系统本身的访问控制，通常是需要建立专门的用户表，在应用系统内开发针对不同用户的访问控制授权140、代码，这样一旦访问控制策略变更时，往往需要代码进行变更。总之一句话，关系型数据库的应用中用户数据管理和数据库访问标识是分离的，复杂的数据访问控制需要通过应用来实现。 而对于LDAP，用户数据管理和访问标识是一体的，应用不需要关心访问控制的实现。这是由于在LDAP中的访问控制语句是基于策略语句来实现的，无论是访问控制的数据对象，还是访问控制的主体对象，均是与这些对象在树中的位置和对象本身的数据特征相关。 在LDAP中，可以把整个目录、目录的子树、制定条目、特定条目属性集或符合某过滤条件的条目作为控制对象进行授权；可以把特定用户、属于特定组或所有目录用户作为授权主体进行授权；最后，还可以定义对特定141、位置（例如IP地址或DNS名称）的访问权。5.2.4 订阅服务订阅服务包括警报/通知服务及发布/订阅服务两大部分功能。订阅服务属于共享平台的通讯交换层，是企业服务总线（HSB）功能的一部分。其系统架构如图所示：图5.2.4-1 订阅服务交互模型发布订阅采用主动服务可以将“适合”的信息在“适当”的时间以“适当”的方式传递到“适当”的人手里，从而提高管理决策的准确性和及时性。它是基于事件系统之上的一种通信方式。在分布式事件系统中，交互模型为订阅者提供能够对某事件或某类事件感兴趣的能力，同时，发布者可将订阅者感兴趣的事件随时通知给订阅者。生产者在 HSB上发布消息，消费者从该软件总线上订阅它们感兴趣142、的信息。发布订阅服务根据不同订阅者提供的订阅条件来快速地对发布者发布的消息进行匹配，并把匹配的结果主动送达给订阅了该消息的订阅者。它的主要组件包括：v 请求代理客户的发布和订阅消息由它包装成相应的请求对象，然后传递给请求代理处理。v 过滤引擎基于XML的消息过滤引擎，它通过把用户的订阅条件组合成一个有共享前缀的非确定有限状态自动机NFA，并能对XML文档提供结构和内容相结合的消息过滤机制。v 事件服务提供事件检测、触发和分发功能。采用通知机制的分布式事件服务。当有一个新的消息到来时，通过调用消息过滤引擎将满足条件的消息进行处理后，再把结果传送给订阅者。v 路由服务当网络出现异常情况时，如果当前143、代理服务器不可用，路由服务可寻找网络中另一个可用的代理服务器。5.2.5 注册服务注册服务包括对个人、医疗卫生人员、医疗卫生机构、医疗卫生术语的注册管理服务，系统对这些实体提供唯一的标识。针对各类实体形成各类注册库（如个人注册库、医疗卫生机构注册库等），每个注册库都具有管理和解决单个实体具有多个标识符问题的能力。注册库保有一个内部的非公布的标识符。5.2.5.1 个人注册服务个人注册服务是指在医联体管辖范围内，形成一个个人注册库，个人的健康标识号、基本信息被安全地保存和维护着，提供给人口健康信息综合管理平台所使用，并可为医疗就诊及公共卫生相关的业务系统提供人员身份识别功能。个人注册库主要扮演着144、两大角色。其一，它是唯一的权威信息来源，并尽可能地成为唯一的个人基本信息来源，用于医疗卫生信息系统确认一个人是某个居民或患者。其二，解决在跨越多个系统时用到居民身份唯一性识别问题。个人注册服务是人口健康信息综合管理平台正常运行所不可或缺的，以确保记录在健康档案中的每个人被唯一地标识，他们的数据被一致地管理且永不会丢失。该注册服务主要由各医院、社区和公共卫生机构来使用，完成居民的注册功能。5.2.5.2 医疗卫生人员注册服务医疗卫生人员注册库，是一个单一的目录服务，为本医联体内所有卫生管理机构的医疗服务提供者，包括全科医生、专科医生、护士、实验室医师、医学影像专业人员、疾病预防控制专业人员、妇幼145、保健人员及其他从事与患者健康服务相关的从业人员，系统为每一位医疗卫生人员分配一个唯一的标识，并提供给平台以及与平台交互的系统和用户所使用。该功能的基本流程为，各医院、社区医院提供所辖医疗卫生人员基础信息给医政，医政完成审核并将这些医疗卫生人员信息在平台上给予注册。5.2.5.3 医疗卫生机构注册服务通过建立医疗卫生机构注册库，提供本医联体内所有医疗机构的综合目录，相关的机构包括二三级医院、社区卫生服务中心/乡镇卫生院、妇幼保健所等。系统为每个机构分配唯一的标识，可以解决患者所获取的医疗卫生服务场所唯一性识别问题，从而保证在维护居民健康信息的不同系统中使用统一的规范化的标识符，同时也满足健康信息146、综合管理平台层与下属医疗卫生机构服务点层的互联互通要求。5.2.5.4 医疗卫生术语和字典注册服务建立术语和字典注册库，用来规范医疗卫生事件中所产生的信息含义的一致性问题。术语可由平台管理者进行注册、更新维护；字典既可由平台管理者又可由机构来提供注册、更新维护。5.2.5.5 健康档案存储服务健康档案存储服务是一系列存储库，用于存储健康档案的信息。根据健康档案信息的分类，健康档案存储服务分为七个存储库：个人基本信息存储库、主要疾病和健康问题摘要存储库、儿童保健存储库、妇女保健存储库、疾病控制存储库、疾病管理存储库以及医疗服务存储库。5.2.6 居民主索引（EMPI）EMPI居民标识服务提供了一147、种在医疗卫生企业（医院、诊所、医师办公室等等）之间相互共享引用患者标识的方式。其中患者标识交叉引用管理器负责从各个标识源中收集病人标识，并对表示同一患者的标识进行映射，并为各标识域提供被引用的居民标识。这组信息包含了该患者记录在不同应用系统中的标识，这些标识可能不同，但实际上表示同一患者实体。由于患者在不同医院或不同应用系统中使用的标识不一样的，当用户从应用系统中选择一个病人时，平台会访问企业病人标识服务，在那里维护了各个系统中对于该病人的标识映射。平台为所选择的人员查询出所有应用系统各自对应的病人标识，然后将这些信息更新到流程自动化管理服务器的公共内容共享区域中，这样每个被通知到的应用系统可148、以获得自己系统所对应的病人标识，从而进行后续的操作。EMPI采集患者的索引信息，包括患者姓名、身份证、家庭地址及患者在各医院的就诊关键记录信息。 图5.2.6-1 EMPI体系结构示意图5.2.6.1 自动链接EMPI索引库的建立需要定义决定EMPI ID的关键属 性以及自动链接规则。EMPI ID关键属项在数据采集时对能否自动链接的决定优先级是不同的，按照优先级的等级分为一级和二级，一级的优先级高于二级。分类情况如下：一级：姓名、证件号码、个人电脑号、社保卡号二级：出生日期、性别、地址自动链接的标准值说明：序号数据项处理方法1一致取值都不为空且完全相等；或者15位的身份证号码可以正确地转换为149、相应的18位号码。2兼容同一字段，对比一个为有效值，另一个为空；或者两个都为空。3不一致同一字段，对比值不为空，值也不相等。4匹配度同一字段，两个值之间的相似度。EMPI ID自动链接判断流程如下所示：图5.2.6.1-1 EMPI自动链接流程示意图自动链接的各种规则组合如下表所示：EMPI数据采集自动链接规则姓名身份证号码个人电脑号社保卡号出生日期性别住址第一种场景：姓名、身份证、社保卡号、个人电脑号、都不为空一致一致一致一致兼容或不一致或一致兼容或不一致或一致兼容或不一致或一致第二种场景：证件号码为空一致兼容一致兼容或不一致或一致兼容或不一致或一致兼容或不一致或一致一致一致兼容兼容或不一致150、或一致兼容或不一致或一致兼容或不一致或一致第三种场景：个人电脑号为空一致一致兼容或一致兼容或不一致或一致兼容或不一致或一致兼容或不一致或一致一致兼容或一致一致兼容或不一致或一致兼容或不一致或一致兼容或不一致或一致第四种场景：社保卡号为空一致兼容或一致一致兼容或不一致或一致兼容或不一致或一致兼容或不一致或一致一致一致兼容或一致兼容或不一致或一致兼容或不一致或一致兼容或不一致或一致第五种场景：身份证与医保卡为空一致一致兼容或一致兼容或不一致或一致兼容或不一致或一致兼容或不一致或一致一致兼容或一致一致兼容或不一致或一致兼容或不一致或一致兼容或不一致或一致第六种场景：身份证、个人电脑号、社保卡都为空一151、致一致一致匹配度达90%同一患者在不同的时间就诊时登记时由于各种原因，如患者填写信息不正确或操作员录入错误等原因可能导致信息的不一致性，如果是这种情况，EMPI系统对患者做自动链接时会进行不一致性处理。序号数据项处理方法1性别保留不一致性，方便不一致性纠错2出生日期保留不一致性，方便不一致性纠错3血型保留不一致性，方便不一致性纠错4民族保留不一致性，方便不一致性纠错5籍贯保留不一致性，方便不一致性纠错6国籍保留不一致性，方便不一致性纠错7家庭住址信息匹配度达90%认为同一信息8工作单位信息匹配度达90%认为同一信息9个人电脑号不一致，则链接时为新的数据10医疗保险号不一致，则链接时为新的数据1152、1监护人信息匹配度达90%认为同一信息5.2.6.2 数据采集患者在医院机构就诊时，患者资料被保存在各医疗机构的系统中，为了收集患者基本信息，EMPI需要提供对外服务接口，医疗机构各系统在相应的业务功能点调用EMPI提供的Web Service数据采集接口，实现对患者信息的采集功能。数据采集的信息分为以下几种类别：l 患者基本信息：姓名、性别、出生日期、证件类型、证件号码、血型、籍贯、民族、国籍、婚姻状况、职业l 监护人信息：监护人关系类型、监护人名称、监护人地址、监护人证件类型、监护人证件号码、监护人邮证编码、监护人联系电话l 工作单位信息：工作单位名称、工作单位地址、邮政编码、联系人名称、153、联系电话l 家庭信息：家庭地址、联系人姓名、联系电话、邮政编码l 保险机构信息：个人电脑号、社保卡号、医疗保险类别、医疗保险机构l 医疗机构信息：病历号、医院系统、医疗机构数据采集接口能处理以下三种情况的患者信息：l 通过数据采集接口采集的信息是错误数据l 通过数据采集接口采集的数据在EMPI中不存在l 通过数据采集接口采集的数据在EMPI中已经存在5.2.6.3 新患者数据信息注册医疗机构系统中的新患者信息，需要通过EMPI的新患者数据信息注册导入到EMPI库中。医疗机构系统将新患者信息通过EMPI提供的相应的接口发送到EMPI库。EMPI通过验错机制和冲突检测机制对新患者信息进行处理。如果154、新数据信息属于EMPI中没有的患者信息，那么将新的患者信息存储，对应新产生的唯一的EMPI编码。如果是信息和EMPI库中的相应数据信息符合链接规则，那么将其链接成一条数据。对于错误和冲突新患者信息，将其设置相应的标志位存储，进入相应的错误和冲突列表，等待EMPI管理中进行操作。最后返回处理结果对应的标志状态编码到医疗机构系统。 图5.2.6.3-1 新患者数据信息注册5.2.6.4 EMPI的使用由于服务消费方的系统平台环境的差异性等因素，EMPI将通过Web Service对外提供服务。EMPI具有广泛的使用者，各个医院系统都可以通过EMPI提供的接口使用EMPI来检索相关的患者用户信息。在155、EMPI返回的信息中，将包括患者标识符信息集合。通过这些标识符信息，可以进行医院的信息交互，从而达到信息共享的目的。医疗机构各系统通过调用EMPI提供的Web Service数据查询接口，进行患者的检索，返回患者的基本信息、患者的住址信息集合和在各个子系统中的标识符的集合。数据查询条件，包括EMPI编号、患者姓名、证件号、个人电脑号、医保号、生日、性别、医疗机构子系统编号、患者编号。数据查询结果：l 患者基本信息：EMPI编号、患者姓名、证件类型、证件号码、医保类型、医保号、个人电脑号、出生日期、性别、血型。l 住址信息：家庭地址、联系电话、邮件联系地址、邮政编码、地区编码l 患者标识符信息：156、医疗子系统编码、患者编码5.2.6.5 EMPI的管理和维护EMPI中存储着大量的患者信息，需要对其进行管理和维护，对于在数据采集时所检测到的冲突数据，需要及时的进行处理，另外错误数据也需要进行修改，还有一些无用数据需要进行清理，以保障EMPI高质量的对外Web Service服务。EMPI还提供友好的分类管理页面，管理冲突、错误等。查询功能提供详细的多条件查询功能，包括各字段查询条件与患者类型等。通过查询能进行数据的分类管理，查找到所关注的患者数据。从而对相关的患者信息进行相应的处理。查看、修改功能通过查询，可以查看选择的相应患者，对患者信息进行修改。修改提交数据将通过验错机制来检测数据格式157、与内容的合法性，以及通过冲突检测机制来进行来测试所修改的数据是否与EMPI库中已有数据相冲突，从而保证修改的正确性。合并功能EMPI库中，同一患者具有两个不同EMPI编号的数据信息，需要进行手动的合并操作，合并信息将包括所有的患者基本信息和患者在医疗子系统标识符等。将为合并后的患者信息重新创建唯一的EMPI编号，原来参与合并操作的患者信息将作废。此患者将对应一条EMPI 编号。取消冲突功能由于错误的源数据，或有误的修改操作，可能会导致不同的患者之间产生冲突。对于不同的患者之间的冲突需要进行取消冲突操作。取消冲突将删除相冲突的两条患者冲突记录。拆分功能自动链接中潜在着错误链接，在合并操作中也会有158、可能出现误操作等。拆分操作就是为了将这些共享同一EMPI编号的不同患者数据信息分离开。将数据信息分别拆分到两条记录中，并允许进行患者基本信息的修改。拆分后的数据通过验错机制和冲突检测机制来进行效验保证拆分正确性。归档/取消归档功能由于数据陈旧，为了提高整体的搜索性能等，需要对此类系统中不再使用的数据进行归档操作。归档的数据将不再参与合并拆分等操作。取消归档则是对归档数据进行的反向操作，将其返回到可用状态。取消归档的数据也需要进行数据的错误效验和冲突检测。作废/取消作废功能错误的采集，以及误操作等产生的错误记录需要对记录进行作废操作。作废类似操作类似与归档，但是不同的是，作废操作的对象是错误非法159、患者信息等，而归档操作的对象是正常状态的。5.2.7 全程健康档案服务全程健康档案服务用于处理患者健康信息综合管理平台内与数据定位和管理相关的复杂任务。该服务包括相关的索引信息，这些索引链接不同存储服务所保存的数据到一个特定的个人、医疗卫生人员、医疗卫生机构或者可以实时获取这些数据的服务点。全程健康档案服务负责分析来自外部资源的信息，并恰当地保存这些数据到存储库中，可以反向地响应外部医疗卫生服务点的检索、汇聚和返回数据。全程健康档案服务也知道其他患者健康信息综合管理平台可能在客户端保存的附加数据，也能够对那些患者健康信息综合管理平台转发数据请求，并合并返回数据和本地信息。反过来，全程健康档案服160、务也能响应来自其他患者健康信息综合管理平台的信息请求。全程健康档案服务是平台系统架构的核心组件。该服务负责实现平台互联互通性规范，还可能使用由患者健康信息综合管理平台内提供的组件和服务同其他人口健康信息综合管理平台互动来完成某一项事务。在某种意义上，全程健康档案服务是患者健康信息综合管理平台的核心。通常，数据更新事务可能需要或不需要使用全程健康档案服务，许多数据更新事务希望能直接分派到特定的注册目录、健康档案存储服务。这样的数据更新事务例子包括：处方药品域系统传来的新药品的调配事件，或者来自实验室检验机构的应用系统发送给患者健康信息综合管理平台的新检验结果，或者来自医院的PACS应用系统发送给161、患者健康信息综合管理平台的诊断成像结果集。另一方面，所有到患者健康信息综合管理平台中访问数据的事务希望由全程健康档案服务进行处理。全程健康档案服务是患者健康信息综合管理平台中唯一一个知晓所有的事务和业务逻辑以及数据访问规则的部件，所以它可以围绕任何数据主题汇集出真正的全程和综合的健康档案视图。5.2.7.1 索引服务索引服务全面掌握患者健康信息综合管理平台所有关于患者的健康信息事件，包括患者何时、何地、接受过何种医疗卫生服务，并产生了哪些文档。索引服务主要记录两大类的信息，一是医疗卫生事件信息，另一为文档目录信息。患者健康信息综合管理平台用户在被授权的情况下，可以通过全程健康档案服务提供的索引162、服务从基本业务系统查看某患者的健康事件信息，以及事件信息所涉及的文档目录及摘要信息。再结合健康档案数据存储服务可以实现文档信息的即时展示，使用户更多的了解患者既往的健康情况，为本次医疗服务提供相应的辅助参考作用。5.2.7.2 业务服务这个组件由处理健康档案数据访问事务的服务组成。这些服务被组合在一起建立一个以处理和管理这些健康档案访问事务的场景。这是患者健康信息综合管理平台内协调和执行事务的唯一地点，其中需要涉及患者健康信息综合管理平台里的多个服务和系统、或需要访问其他患者健康信息综合管理平台的事件。这一组件中的服务管理着患者健康信息综合管理平台中事务的全局性表示、编排流、响应组装、业务规则163、应用以及与患者健康信息综合管理平台的各类其他系统或服务的数据访问。业务联动的众多需求则需要本业务服务组件来配合实现。包括的主要服务组件有：1. 组装服务一个平台互联互通规范的执行可能包括调用不同的组件生成多个结果集。组装服务将把这些结果集一起组合成一定输出格式。这些服务将使用组合模板的方式来实现这些功能。2. 编排服务这些服务管理注册、存储和提取，更重要的是各类处理流程的编排协同。编排服务是驱动事务执行的引擎。它知道服务产生的步骤，知道怎样为了触发和管理每一步并行或串行实现而调用服务。3. 业务规则服务业务规则服务组件是由细颗粒的验证和逻辑处理规则对象的采集器，它在运行期间进行组合以执行适用于164、正在被处理的特定类型的平台互联互通性事务的业务逻辑。这些业务规则可以被硬编码（指作为程序代码）进入域业务组件或者可以通过业务规则服务动态的使用。4. 标准化服务这些服务是在平台互联互通性执行的语境中被调用以转换成不同形式下描述的数据。典型地，这个服务常用于应用标准，把特定的输入串修改成符合标准化基础的编码串。数据的格式和实质含义都可以转换。特殊的逻辑和编码表常用于完成这种转化。5. 数据质量服务用于跟踪和监控人口健康信息综合管理平台里的数据质量。因为人口健康信息综合管理平台的数据是用于研究、监测和进行临床决策的，跟踪人口健康信息综合管理平台内部信息质量水平的能力是一个必须的特性。这些服务能用于165、支持人工数据质量评估处理，将来甚至发展到完全自动的数据质量指标评估。例如：某些指标可以从监控应用业务逻辑算法的结果中得到。5.2.7.3 数据服务这些服务为健康档案业务服务提供功能性的支持，以执行正确的数据访问过程和与不同的注册服务、存储服务、业务管理或辅助决策服务交互所需的转换。通常，全程健康档案服务可以与平台内部组件相互作用。它依赖于基于标准的通信机制，并使用交换层来执行这种相互作用，或者使用更为直接或私有化的接口机制来访问或更新数据到任何一种注册服务、存储服务。数据服务用在两个场景里：记录和获取健康档案数据的在线业务场景，加载和管理健康档案存储库和注册信息的管理功能场景。数据服务所包含的166、主要服务组件有：1. 复制服务在现有的患者健康信息综合管理平台内的系统或数据库之间提供数据复制功能。2. 数据仓库服务 数据仓库服务管理从不同的存储库中抽取和插入数据，经过抽取、转换和装载等加工处理后，提供生成患者健康信息综合管理平台范围内使用的各种数据分析利用资源。3. 键值管理服务当数据访问来自不同数据源时，会出项这样的情况，即某个主索引键或次索引键在源系统间不唯一或不存在。键值管理服务将在健康档案存储库插入和更新操作期间生成和管理这些键值。4. 数据访问服务为不同的注册库、电子健康记录系统或辅助服务相关的数据访问过程的正确调用提供支持。它存储着有关数据结构和调用过程的元数据，以在运行I-167、IPs的语境中或数据维护类型过程中执行存储库的操作。5.2.7.4 事务处理根据对事物的调用和处理，全程健康档案服务将配置成协调处理所有的“列表”和“获取”事务。对于任何这些事务，将建立管理这些事务的语境，将知晓如何调用一个特定的编排流，并指导编排流的执行，允许在实现这些事务时调用适当的服务。典型的调用包括：1、 调用个人、医疗卫生人员和医疗卫生机构注册服务来鉴别每个实体，并且在它们的使用过程中获得人口健康信息综合管理平台内部标识符；2、 通过交换层服务去调用许可、加密、数字签名、访问控制、匿名访问或其他任何服务，这些服务用于对事务的实现施加适当的控制；3、 调用平台定位服务，以确定特定居民的168、特定事务在不同区域存储服务可能有数据的情况下，需要查询其他哪些人口健康信息综合管理平台；4、 调用存储服务来执行特定平台互联互通规范时访问或获取数据；5、 通过交换层服务将子事务代理调用到存有客户相关数据的其他人口健康信息综合管理平台中；6、 通过交换层服务为正在执行的平台互联互通规范传递一个组合响应。为了担当处理健康档案数据访问事务的核心，全程健康档案服务必须有能力建立健康档案的完整视图。全程健康档案服务中的索引服务提供这一能力。当全程健康档案服务处理事务时必须依赖索引服务，索引服务可以了解在健康档案里存有哪些数据，并知道这些数据在参与到人口健康信息综合管理平台中的众多系统里的位置。当全程健169、康档案服务是索引服务所有者时，在索引服务里全程健康档案服务也会提供一套特定的事务来管理、维护和使用索引数据。集中处理复杂的复合事务时，全程健康档案服务是一个事务处理层，侧重于处理复杂的混合事务，这些事务需要得到一个多域或多平台的信息视图。希望大多数患者健康信息综合管理平台数据访问事务获得这类能力，因为来自于注册服务、访问和同意管理服务、并且常常一个或多个存储服务的数据必须结合在一起才能实现一个请求。本质上，希望到达人口健康信息综合管理平台的更新或“PUT”事件对于单一的域是特定的并被限制在处理该域的一个数据存储服务组件范围内。5.2.8 医疗卫生信息共享和协同服务医疗卫生信息共享和协同服务基于170、健康档案存储服务，提供医疗卫生机构之间的信息共享服务和业务协同服务。根据健康档案信息的分类和服务需要，医疗卫生信息共享和协同服务分为七个域：个人基本信息域、主要疾病和健康问题摘要域、儿童保健域、妇女保健域、疾病控制域、疾病管理域以及医疗服务域。这些域又可以进一步细分为若干个子域，例如医疗服务域可以分为诊断信息域、药品处方域、临床检验域、医学影像域。5.2.8.1 共享与协同信息域5.2.8.1.1 个人基本信息域个人基本信息域对外提供个人基本信息共享服务。5.2.8.1.2 主要疾病和健康问题摘要域主要疾病和健康问题摘要域是患者健康信息综合管理平台中的一个核心部件，它将所有与个人健康相关基础摘171、要信息进行汇集、存储、并对外提供服务。主要疾病和健康问题摘要域在患者健康信息综合管理平台中主要包含以下内容：血型、过敏史、慢病信息等，这些的摘要信息汇集不是从某个基础业务系统中单独获取，而是从众多的基础业务系统中抽取汇集而成。摘要域的主要服务方式是为医疗卫生人员提供一种通用的、及时的、可信的调阅服务，为医疗卫生人员在进行医疗卫生服务时能够及时、快捷的了解患者基础健康信息提供一种技术支撑。5.2.8.1.3 儿童保健域儿童保健域用于维护及管理医联体内妇幼机构、社区卫生服务中心/乡镇卫生院、儿童医院、幼托机构等机构所产生的儿童保健数据及提供的儿童保健服务。数据主要包括出生医学证明、新生儿疾病筛查、172、出生缺陷监测、体弱儿童管理、儿童健康体检、儿童死亡管理等数据。儿童保健域数据体现了数据间的联动性，如根据出生医学证明可以触发新生儿随访服务。5.2.8.1.4 妇女保健域妇女保健域用于维护及管理医联体内妇幼机构、社区卫生服务中心/乡镇卫生院、助产医院等机构所产生的妇女保健数据及提供的妇幼保健服务。数据主要包括妇女婚前保健、妇女病普查、孕产妇保健服务及高危管理、产前筛查与诊断、孕产妇死亡报告等数据。妇女保健数据体现了数据间的联动性，如妇女在三级医院发现自己怀孕后，需要三级医院将怀孕数据及时传送到妇女所在的社区卫生服务中心/乡镇卫生院及区妇幼保健所，由社区卫生服务中心/乡镇卫生院的防保医生提供产前173、保健服务，社区服务中心也需将此产前保健数据传送给妇女生产医院，生产医院将妇女产前检查、分娩数据传送回社区卫生服务中心/乡镇卫生院，社区卫生服务可获知妇女分娩并及时上门进行产后访视服务。5.2.8.1.5 疾病管理域疾病管理域用于维护和管理医联体内各医疗机构所产生的疾病管理数据及各种服务。数据主要包括高血压病例管理、糖尿病病例管理、肿瘤病例管理、精神分裂症病例管理、老年人健康管理、成人健康体检。数据着重体现了过程性及联动性，即医联体内各个医疗机构（医院、社区卫生服务中心/乡镇卫生院）形成紧密的卫生业务联动，如某社区居民在市级三级医院发现糖尿病，需要市级三级医院马上形成糖尿病管理报告卡，并将报告卡174、数据传送到居民所在的社区卫生服务中心/乡镇卫生院，社区卫生服务中心/乡镇卫生院的防保医生进行上门确认及随访。5.2.8.1.6 医疗服务域医疗服务域是用于临床信息共享和医疗业务协同的，包括诊断信息域、药品处方域、临床检验域、临床检查域和医学影像域。1. 诊断信息域诊断信息域系统也被称为临床诊断信息系统。临床诊断信息系统记录患者的临床表现和诊断信息，提供完整的诊断记录，并为医生开处方和医技医嘱提供支持服务。区域卫生信息平台诊断信息域服务支持用户通过药品处方或医技医嘱提取患者临床表现和诊断并进行显示。2. 药品处方信息域药品处方域系统也被称为药物信息系统。药物信息系统记录处方和药物治疗信息，提供完175、整的患者用药记录，并为医师开处方和调配药物提供决策支持服务。患者健康信息综合管理平台药品处方域服务支持用户通过药品处方域存储服务提取患者临床数据并显示。3. 临床检验信息域临床检验信息域系统也被称为区域实验室信息系统，是一个管理患者检验申请单和向临床医师发布患者检验结果的区域系统。在不同的卫生管理区域，实验室域系统可采取各种不同的形式和规模。关键在于要将浏览检验结果的解决方案与为了获得结果而涉及的与医嘱信息相关的一系列支持数据的解决方案的区别开来。可以汇总化验结果及伴随数据（如之前的医嘱），这样可以向医疗卫生人员提供结果汇总信息视图。在最简单的状态下，检验域系统会自动从源系统中采集检验相关事件176、，如申请、标本、检验结果，并且允许基于标准消息查询这些数据以提取其中的任何信息。更先进的解决方案除提供这些基本功能外，也将支持流程自动化和申请及结果生成状态的管理，同时也会以一个更加积极的方式与源系统交互，生成警告和通知，以加快处理。检验信息域服务通过基于标准的消息与产生和管理申请的实验室系统进行交互，同时也与系统中用以产生结果的采样和检测机构进行交互。换句话说，实验室机构内的医师用户和实验技师用户使用其本地信息系统解决方案进行其工作。这些应用系统，通过与信息平台相连接，能把关键相关结果数据发布或提升到患者的电子健康记录中。4. 医学影像域（扩展）医学影像域用于维护和管理医学影像的医嘱和结果信177、息，医学影像检查是健康档案的一个重要组成部分。大容量图像和其他二进制文件的管理和高效传输的技术要求是使得这部分服务独立成域的原因。该服务允许集中获取和共享大型分布式网络中符合DICOM 的对象。这些网络包括在医院或诊断中心实施的图像归档及通讯系统（PACS）以及产生图像的诊断设备。通常情况下，与医学影像检查相关的数据有两部分，一份用于说明概要结论的书面报告和影像。影像可以采取不同的形式，如视频或声音，但多数时候会采取一张或多张影像的形式。无论是书面报告，还是用来达成结论的关键影像都可从数据中心服务中获得。这里讨论的影像图像是典型的业务流程的最终结果，这些业务流程都开始于创建一个由临床医师为进行178、某一类型检查开立的医嘱。在数据中心域中，医嘱将被表现为一套支持某一图像诊断结果的数据，因此，可作为客户电子健康记录的一部分。其他类型的二进制对象也可由数据中心域处理。实际例子包括：来自一个远距离会议的与临床有关的患者健康记录视频流剪辑，或任何来自不同设备（心电图，呼吸监视器等等）的数字流数据。提供快捷、方便以满足存取大型图片或其他类型流对象的功能是一个挑战。人口健康信息综合管理平台数据中心域服务支持用户查询数据中心域存储库中患者的临床数据并显示出来。集中管理的索引服务，作为全程健康档案服务的一部分，在记录患者接受医疗服务的场所和类型的数据中心信息上发挥了重要作用。当最终用户访问一个影像（或其他179、对象）以供浏览时，这个索引机制是DI域服务工作的核心。5.2.8.2 共享文档管理引擎5.2.8.2.1 共享文档组装任何医疗活动必定产生一个或多个与 EHR 有关的文档，但这类业务文档并不是与 EHR 一一对应的、同构的。它需要平台的专门服务解析和映射（Parser/Map/Rebuilder），才能转换成 EHR 文档。因此，必须有一个可以实现文档重构的引擎/适配器（Engine/Adaptor）。5.2.8.2.2 共享文档解析共享文档解析可以将共享文档转换为其它 XML 文档、XHTML 输出或简单的文本。这通常是通过将每个文档元素转换为 HTML 元素来完成的。由于 XML 标签是用180、户定义的，浏览器不知道如何解释或呈现每个标签，因此必须提供共享文档的解析服务。5.2.8.2.3 共享文档验证共享文档验证是对系统交换中使用的共享文档进行相应的格式及内容的验证，以保证共享文档的正确性，验证的内容去年包括.必须以 XML 声明开头、必须拥有唯一的根元素、标签必须与结束标签相匹配、元素对大小写敏感、所有的元素都必须关闭、所有的元素都必须正确地嵌套、必须对特殊字符使用实体等。5.2.9 区域医疗业务数据整合和调用服务5.2.9.1 患者基本信息库患者基本信息库主要业务数据包括：患者基本信息，患者扩展信息和专用信息。患者基本信息患者基本信息是指在医联体平台内患者基本信息库中唯一标识一181、位区内居民的信息，一般来说，它包含了那些不大会发生变化的，能够对患者身份起识别作用的人口学信息。主要的数据字段包括：档案号、姓名、性别、出生日期、证件号码、证件类别、婚姻状况、出生地、民族、国籍。档案号是居民基本信息关键字段，它是医疗信息整合平台为每一个可能的居民建立的一个内部唯一索引号。证件号码和证件类型是用来确定居民身份的有效手段，这里可以是身份证、军官证、护照等有效证件。患者扩展信息患者扩展信息主要包括一些患者容易发生变化的信息，一个人可能会有多条扩展信息。具体数据包括：电话号码、工作单位、单位电话、单位邮编及地址、户口地址、户口地址邮编、联系人姓名、联系人关系、联系人地址、联系人邮编、182、联系人电话。5.2.9.2 患者身份识别患者分类情况目前XX市内二、三级医院和社区卫生服务中心/乡镇卫生院的就诊患者大致分类如下： 持有社保卡或医保卡的本区患者； 没有社保卡和医保卡的本区患者； 没有社保卡和医保卡的外地患者。卡分类情况XX市内各医院以患者结算时所用的磁卡或IC卡作为患者在就医过程中的身份识别标志。卡号是卡的唯一标识号，患者可能持不同的磁卡或IC卡来就诊，卡包括以下几种： 医保卡：磁卡，出现在社保卡之前，逐步被社保卡取代，但一些人员可能长期使用。 社保卡：IC卡，本区患者在就诊时最为常用。 医院内部的就诊卡：磁卡，各医院发放给无（包括未带）医保卡或社保卡的患者，一般只能在本医院183、内部使用。除社保卡和医保卡之外，其他磁卡和IC卡之间没有关联关系。目前除社区卫生服务中心/乡镇卫生院以外，均没有强制与身份证进行关联。正是由于以上情况，才会出现如下问题： 由于区内不同医院发放的就诊卡号可能重复，导致一个卡号在全区的范围内可能对应多个患者。场景分析通过调研可知，在XX市患者就诊的用卡情况可能出现如下四个场景：1. 持卡人员始终持一种卡（社保卡或医保卡）就医这是最常见的一个场景，由于社保卡号（医保卡号）和市民一一对应，因此不存在身份唯一性问题。随着持社保卡（医保卡）人员的扩大，越来越多的XX市居民就诊时将归入这一场景。患者因失落社保卡/医保卡而补办了新的社保/医保卡，也属于本场景184、。由于社保卡补办时的卡号保持不变，因此不影响身份识别问题。补办医保卡时医保卡的卡号与原卡号不同，当补办的号上传到中心端后，将产生一个新的档案号。理想情况：新医保卡号对应的档案号应该与老医保卡号对应的档案号合并，从而解决身份识别问题。2. 持卡人员持两种卡以上（社保卡或医保卡或内部就诊卡）就医原持医保卡，后持社保卡就医。u 当既有医保卡又有社保卡参保人员使用了社保卡就医后，该参保人的医保卡自动封存，即出现本场景。u 理想情况：该患者的医保卡号所对应档案号应该与其社保卡号所对应档案号合并。u 设想方案：应从医保局或社保卡中心收集社保卡号和医保卡号的对应关系表。社保卡/医保卡和就诊卡交替使用（包括无185、卡人员成为有卡人员）u 理想情况：社保/医保卡所对应的档案号应与该患者使用的医院内部就诊卡所对应的档案号在中心进行合并。不同医院的就诊卡交替使用（参见场景四）。3. 无卡人员（主要指外地患者）始终持一张医院内部就诊卡就医无社保/医保卡人员以往就医时办过一张某医院的内部就诊卡，当其再次使用该就诊卡到该医院就诊时，即本场景。当该卡号信息上传到中心端后，将会在数据库中查到该卡号，身份统一。4. 无卡人员（主要指外地患者）持两张以上医院内部就诊卡就医在同一家医院办理两张以上内部就诊卡；在两家以上不同的医院办理了内部就诊卡。理想情况：对应于同一患者的多张内部就诊卡对应的数据中心端的档案号应合并。解决方案186、患者身份识别问题是否能够得到妥善地解决，取决于各类卡所能容纳的患者基本信息是否准确。社保卡和医保卡所涉及的患者信息在社保/医保中心有集中管理，其数据的准确性是有可靠保障的；但是医院就诊卡其本身只包含卡号信息，与此相关联在患者就诊过程中可能采集到的患者基本信息包括姓名、性别、年龄等基本信息，有些医院可能会采集到身份证信息，如XXXX街道卫生服务中心在为患者办理医院就诊卡时明确要求患者提供身份证，但是这些信息不排除在采集、录入的过程中发生偏差的可能性，这会导致数据的不完整，其可靠性不高。患者身份的识别，需要通过各类卡所能涵盖的患者基本信息进行卡间的关联，如果卡所采集的信息质量不高，会对卡间关联的成187、功率、准确性造成很大的影响。针对这种情况，需要制定详尽的措施在数据采集的源头控制数据的质量，再通过一定的技术手段尽可能排除这种信息不一致所造成的干扰。结合XX市实际情况，本期项目建设中先对持社保卡、医保卡就诊的患者相关信息进行采集。目前在XX市社保卡、医保卡患者占全区就诊患者的大多数，其覆盖面较大，这种方式在保证项目受益面的前提下保证本期项目的顺利实施。同时可在此基础之上制定相应的医院就诊卡患者信息采集规范，控制数据采集质量，为后期与社保卡、医保卡之间的关联奠定基础。社保卡、医保卡在全市范围内其卡号唯一，均可作为患者的唯一身份标识，本期项目仅限于社保卡、医保卡患者范围时可以避免上文中所提到的一188、个卡号对应多个患者的情况。针对患者就诊卡的管理，可考虑让医院在上传医院就诊卡号时，同时上传该医院的代码，这样就可以避免一个卡号对应多个患者的情况出现。5.2.9.3 卫生数据整合卫生数据整合涵盖了医疗业务、临床信息和疾病预防控制信息的整合。在本方案中，医疗业务、临床信息与疾病预防控制信息是采用一体化的方式来采集和整合的。具体来说，整个医疗业务、临床信息与疾病预防控制信息是从两个维度来贯串的，横向维度是“人”，纵向维度是“时间”。“人”具体来说就是就诊患者基本信息，所有的医疗业务、临床数据与疾病预防控制信息都与患者唯一索引关联。“时间”具体来说就是就诊患者每次的就诊行为，一次就诊对应一个就诊流水189、号。所有的医疗业务、临床数据与疾病预防控制信息都与就诊流水号关联。这样患者的任何一次挂号、化验、以及今后的收费、处方、医学影像等均可唯一定位。本项目建设的医疗业务、临床数据和疾病预防控制数据主要包括：患者检验履历信息、实验室检验报告信息、双向转诊信息、基于临床信息的公共卫生监测信息等。库中各业务数据可以按照人的视角和临床的视角有两种不同的表关联关系视图。5.2.9.4 关联关系图基于人的视角关联关系图由于就诊履历部分、检验履历部分、检验结果部分的各表都需要患者基本信息部分的患者信息表中的患者卡号和卡类型作为主索引，因此在就诊履历部分、检验履历部分、检验结果部分的各表中出现的卡号和卡类型都必须在190、患者信息表中有对应的持该卡和卡类型的患者的记录。基于人的视角（卡号和卡类型）各表之间的关联关系如下图所示：图5.2.9.4-1 卡号和卡类型关联关系图由于就诊记录表是就诊履历的主表，患者的一次门诊或住院就会形成就诊记录表中的一条记录，因此，检验履历、检验结果部分的各表都必须和就诊履历部分的主表就诊记录表中的就诊流水号和医疗机构代码相关联。即，上述各表中出现的就诊流水号也必须出现在就诊记录表中。基于临床视角（就诊流水号和医疗机构代码）各表之间的关联关系如下图所示：图5.2.9.4-2 就诊流水号和医疗机构代码关联关系图5.2.9.5 患者就诊履历信息业务描述由于医院的就医过程和治疗手段相对复杂，191、因此将一次就诊的过程中数据串连起来，对于实现临床数据共享和管理上的要求都具有参考价值。就诊履历的数据为结构化数据，将为今后各种社会卫生范围内的统计分析提供数据基础。主要功能描述如下： 中心就诊履历数据表的建立患者在市XX局管辖范围内的任何一家医院就诊后，医院的HIS系统将生成该患者的就诊履历信息，这些就诊信息通过“就诊流水号”作为主线串联起来。医院每天将产生的就诊履历信息，上传到数据中心。 中心就诊履历数据的调阅当中心端就诊履历数据表建立了以后，如果患者曾经在市XX局管辖范围内的任何一家医院间就过诊，当该患者再次到范围内的某一家医院就诊时，医生就可以查询到该患者以往在区内的就诊履历。主要业务数192、据患者就诊履历本期主要为患者的就诊记录，表示患者一次门诊或住院过程中的信息。具体数据包括：就诊流水号，医疗机构代码，卡号，卡类型，患者姓名，患者属性，就诊类型，就诊科室编码，就诊科室名称，就诊（住院）开始日期，就诊（入院）诊断编码，就诊（入院）诊断说明，修改标志，密级。就诊流水号和医疗机构代码共同组成就诊记录的主键。一次就诊的完整过程由一个作为联合主键的“就诊流水号医疗机构代码”予以标示。5.2.9.6 患者检验履历信息业务描述患者检验履历主要描述了患者在做完一次化验后拿到的报告单中的基本信息，包括患者检验时间、检验医院和检验项目等信息，是患者一次检验的汇总信息。患者检验履历对医生诊断病人有很193、大的参考价值，可以减少重复检验，提高诊疗服务质量。患者检验履历和下文即将描述的实验室检验报告信息共同构成了实验室检验报告中心库，其主要功能如下：区域实验室检验报告中心库的建立医院端LIS系统在检验报告单生成以后，把数据写入医院前置机，前置机定时将实验室检验报告数据通过数据交换平台上传到区卫生数据中心库中。检验报告的数据分为两个层次：检验履历数据和检验结果数据。每一张报告单必须有唯一的id来标识（检验报告单号），但由于中心库的数据来自于各家医院，为了防止医院间的报告单号有重复，我们还要求上传医疗机构代码，从而能区分出不同医院的不同检验报告单。另外，为了让检验履历表和就诊履历关联起来，还应当在检验194、履历数据中加入就诊流水号。最后，为了满足管理需求，还应该加入相应的管理数据，以便系统日后统计分析使用，管理数据应包括：医生信息（申请者、检验者、审核者）、科室信息、设备信息（仪器名称、仪器代码）。为了实现跨医院诊疗数据的交换共享，还必须解决业务数据进行编码标准化的问题。因此，前置机上必须设立标准字典表，包括医疗机构代码表、医院科室代码表、标本代码表、仪器代码表、检验指标代码表、结果异常提示代码表。前置机上的数据交换平台应该根据这些代码表作代码转换，然后把标准化的数据上传中心库。检验报告单的数据应该是结构化的，如果医院目前也具有非结构化的数据（例如pdf文件形式的报告单），也应该以附件的形式上传195、。实验室检验报告的调阅中心端建立了检验报告库后，即可进行检验履历和检验结果的调阅。医生在医院的医生工作站给出查询条件（如：患者卡号，查询时间段等）并发出查询请求，查询指令将提交给区卫生数据中心。中心系统根据医院提交的查询条件在数据库中进行查询，并将查询结果返回到医生工作站并显示给医生查看。这样有利于医生快速、准确地掌握患者的以往病史，进而有利于医生对患者的病情作出准确的判断。主要业务数据患者检验履历在本期项目中主要描述了患者在做完一次化验后拿到的报告单中的信息。检验履历数据包括：医疗机构代码，报告日期，检验报告单号，就诊流水号，医院名称，医嘱序号，卡号，患者姓名，性别，年龄，申请人，报告人，审196、核人，申请科室，病区，床号，打印日期，申请日期，采集日期，报告日期，报告备注，标本代码，报告单类别编码，报告单类别，密级代码，修改标志，PDF文件链接。其中医疗机构代码、报告日期、检验报告单号唯一标识了一份检验报告。在上述字段中，“pdf文件链接”主要是针对某些医院会将检验报告单制作成pdf文件（也有可能使其它格式的文件），该文件样式是该医院特定的，在作展示的时候，可以最大程度的还原检验报告单的原样。该字段并不是必须得，如果医院并无这样的文件，那就也就不用上传。5.2.9.7 检查报告履历信息业务描述通过建立检查报告中心库，来实现检查报告在各医院间的共享。医生通过调阅患者历次的报告，对病情的诊197、断可以起到辅助参考的作用；通过调阅患者历次的报告也可以减少患者的不必要重复检验检查。患者在XXX管辖范围内的任何一家医院就诊后，医院的PACS系统将生成该患者的检查报告信息，这些检查报告信息通过患者检验履历串联起来。医院每天将产生的检查履历信息上传到区数据中心。当数据中心检查报告数据表建立了以后，如果患者曾经在市XX局管辖范围内的任何一家医院间就过诊，当该患者再次到范围内的某一家医院就诊时，医生就可以查询到该患者以往在区内的检查报告信息。主要业务数据检查报告部分涉及到的数据包括三部分：检查影像、检查所见、诊断结果。1) 检查影像检查影像作为检查单中基本的内容一般以DICOM文件存档，视频卡采集198、类以JPEG文件图片存档，通过“医院编码、检查报告单号、报告日期”字段与“检查报告单表”关联。其内容应为结构化数据。包括：检查指标流水号，医疗机构代码，检查报告单号，报告日期，检查人，审核人，医保收费代码，检查类别，检查项目，检查部位，设备编码，仪器编号，仪器名称。2) 检查所见医生通过医疗专业显示屏阅片，通过相关阅片辅助工具，如进行调整窗宽窗位、测量尺等，把影像所见的内容或数据，详细描述出来，并存档。3) 诊断结果医生通过对影像所见，得出的诊断结果。5.2.9.8 患者双向转诊记录业务描述转诊发生在转出医院和转入医院之间。转出医院与转入医院之间必须根据约定的业务流程来管理转诊业务。也可以设立199、专门的转诊中心来审定批准病人各类检查（物流）、病人费用、门诊还是住院、治疗还是康复、检查还是治疗、是否需要第三方参与（病人移送、专家会诊）等。双向转诊系统必须能够支撑转出医院和转入医院之间，或转出医院、转诊中心和转入医院之间转诊业务的管理；必须支持统一挂号。主要的业务需求包括转诊计划的设定和转诊的相关审批。双向转诊系统通过区内数据交换平台，不仅可以实现社区卫生服务机构与大中型医院之间居民健康档案、患者病案信息和检验/检查信息的交换与共享，还可以实现社区卫生服务机构与大中型医院之间医疗服务的联动。主要业务数据患者转诊的主要业务数据信息包括三个部分： 转诊单信息转诊单信息主要指患者的转诊申请相关信200、息，包括：门诊号、社保/医保卡号、病人姓名、性别、年龄、转诊日期、转入医院、经治医生、审核医生、转出医院、转出时间、状态、病史摘要、初步诊断、转诊目的。 医院转诊资源信息医院转诊资源信息：包括医院实时挂号信息、医院综合介绍、科室情况，专家（姓名、性别、门诊时间、人数）、医生情况、可预约时间、普通门诊挂号信息、专家门诊挂号信息、特需门诊挂号信息等。 患者临床信息包括在XX市卫生数据中心中共享的所有患者临床信息。主要指患者基本信息、患者检验履历信息（包括患者历次检验的清单情况）、实验室检验报告（包括检验报告、检验指标、细菌结果、药敏结果）。5.2.9.9 公共卫生监测信息基于临床信息的公共卫生监测201、预警信息主要为市XX局、区疾病预防控制中心搭建针对全区的疾病、症状的监测、分析、预警平台，各医院公共卫生预警监测数据在通过前置机上传至平台后，通过中心端应用实现对全区公共卫生情况的监测。公共卫生监测预警信息在本期项目中需要及时上报的信息包括：患者症状信息、患者基本信息和患者实验室检验信息1、 患者症状信息包括9类主要症候群症状信息，常规监测目标症状其内容如下： 全身症候群发热1、低热、中等热度、高热、超高热、寒战、乏力、全身疼痛； 呼吸系统症候群鼻塞、咽痛、咳嗽、咳痰、胸痛、呼吸困难、咯血； 消化系统症候群恶心、呕吐、腹痛、腹胀、腹泻、里急后重、便秘、纳差、便血、脱水； 神经系统症候群头晕、头202、痛、意识障碍、烦躁、抽搐； 皮疹症候群斑疹、丘疹、水疱疹、脓疱疹、焦痂溃疡； 出血症候群瘀点、瘀斑、鼻衄、牙龈出血； 肉毒杆菌毒素中毒症候群口干、语言障碍、吞咽困难、无力、面色潮红、视力模糊、复视； 肝科症状厌油、肝区不适、肝肿大、巩膜黄染、尿黄； 其他症状无尿2 、少尿、多汗、结膜充血、颈胸充血、腰痛、眼眶痛、淋巴结肿大。其中1用户在选择“发热”症状时，必须在“低热”、“中等热度”、“高热”、“超高热”之中选择一项；2“无尿”、“少尿”选项互为排斥，选择其中一项，则另一项不可选。2、 患者基本信息包括患者信息，主要涉及患者的姓名、性别、身份证件、出生日期、民族、籍贯、职业、联系方式等基本资料203、。3、 患者实验室检验信息主要涉及实验室检验中最终形成的结果报告。涵盖如下内容： 血液常规检验报告红细胞计数、血红蛋白测定、血小板计数、白细胞计数、淋巴细胞（百分比、绝对值）、单核细胞（百分比、绝对值）、中性粒细胞（百分比、绝对值）、嗜酸粒细胞（百分比、绝对值）、嗜碱粒细胞（百分比、绝对值）等； 肝功能检验报告总胆红素、直接胆红素、间接胆红素、谷丙转氨酶、谷草转氨酶、总蛋白、白蛋白等； 肾功能检验报告内生肌酐清除率、血尿素氮、血肌酐、血红蛋白和红细胞数、尿比重等； 尿液检验报告比重、酸碱度、白细胞、亚硝酸盐、蛋白质、葡萄糖、尿胆原、胆红素、潜血等； 粪便检验报告颜色、性状、镜检红细胞、镜检脓细204、胞、上皮细胞、潜血试验、粪胆红素试验、寄生虫等；其他实验室检验报告。5.2.10 数据交换服务5.2.10.1 数据交换需求分析数据交换概括的说可分为三方面：一是需要将医院前置机采集到的相关数据上传到数据中心；二是需要将从医院前置机上传的相关临床数据进行合理性校验并存储到数据中心，并根据数据特点进行适当转换、管理和分发；三是需要医院内部系统对存储在数据中心的临床数据进行调阅。5.2.10.1.1 信息交换场景5.2.10.1.1.1 中心端交换场景5.2.10.1.1.1.1 中心端请求医院端服务在这种场景下，中心端作为一次交换发起方，向一个特定的医院发起一次服务调用的请求，此服务调用可能是信205、息查询服务也可能是预约服务。当医院端作为服务提供者角色接收到此服务请求后进入医院端的服务处理程序，在医院端的服务处理程序执行完服务后，则把服务结果信息作为回复的消息反馈给中心端。5.2.10.1.1.1.2 中心端采集医院端数据中心端数据采集是由医院端按要求将数据以主动的方式把数据送交给中心端。医院端主动发现自己需要上报的新数据，如果有新的数据就主动向中心端发送采集到的数据，这种方式会减少无谓的数据在网络上的传输，提高数据传送的效率。5.2.10.1.1.2 医院端交换场景5.2.10.1.1.2.1 医院通过中心请求其它医院服务医院间的数据交换多数是因为医院因协作为患者提供更好的医疗服务而发206、生的，例如双向转诊所涉及的转院预约、院间调档等，这些交换的特点是具有一定的服务性，通常是由服务的请求医院向被请求医院发起一次数据交换。对于本期项目所涉及的临床检验信息，为了集中监控和统计医院间的相互服务的情况，以及为了减少医院间请求服务的复杂性，通常建议采用通过请求中心端的服务代理的方式执行医院间的数据交换。5.2.10.1.1.2.2 医院直接请求其它医院服务医院直接请求其它医院的服务通常发生在中心端提供的服务不可用或者需要传递的数据内容很大为了降低网络压力的情况下。对于中心端的服务如果不可用的情况，医院端可以采用等待服务可用后再次发送或者因为服务需求的紧迫性而可以选择直接请求其它医院的服务207、。通常推荐采用前一种方式，因为后一种方式会给系统管理上带来一定的复杂性。5.2.10.1.1.2.3 数据定期报送中心医院的一些医疗资源信息，特别是医生和大型设备信息需要定期报送给市XX局数据交换中心，通过定期报送形成医生和设备的共享。医疗资源采用定期报送的方式主要是考虑到这类信息相对病患的就诊、化验等信息变动的频率比较低。为了能够合理的使用网络及计算资源，需要把那些有共享需求，更新频率较低的信息统一收集汇总，在合适的时间定期报送。5.2.10.1.1.2.4 查阅患者他院特定类型诊疗信息医院在为一个病患提供诊疗时可能需要参考一下该病患在其它医院的近期的化验结果。因此，医院端需要提供查询某个病208、患在其它医院的诊疗信息的功能。通过这个功能的使用可以完成当前医院的医生查看病患在他院的诊疗信息。5.2.10.1.1.2.5 查阅患者某时间段内所有诊疗信息这种情况是对“查阅患者他院特定类型诊疗信息”的一种需求的扩展。当医生在诊断时无法确定希望查阅他院的具体名称时，或者无法确定病患在他院的诊疗类型时，都可能需要查阅病患在某时间段内的所有诊疗信息。5.2.10.2 数据交换难点分析5.2.10.2.1 对异构数据源的整合医院端采用的数据库管理系统不统一，主要有ORACLE、SQL Server、DB2等；另外，各医院向数据交换中心提供数据的文件格式不一样，多数采用数据库文件格式提供，个别采用文本209、格式提供。这种数据源方面存在的异构性是数据交换中心从各医院获取数据面临的首要的障碍。当然，异构性的障碍还不仅仅是从医院端获取数据，数据交换中心发布给医院的数据的写入、数据交换中心发送给医院的数据查询都将面临多种类型的数据源的问题。在本方案中，对于异构数据源的整合采用的设计是在医院部署一个数据整合平台完成医院的异构数据源的统一接入，然后数据交换中心的数据整合平台与各个医院间基于整合后的统一的数据源完成数据采集、发布等功能。在这种设计中，有下面几个特点：第一、消除了数据交换中心需要直接面临各个医院的异构数据源的压力。数据交换中心将把更多任务投放到对收集的数据的汇总处理方面；第二、降低了医院接入的成210、本。通过在医院部署的数据整合平台提供统一的接入服务，医院可以容易的把各种异构的数据源，例如：数据文件、 Oracle、SQL Server、DB2等集成到医院的数据整合平台。5.2.10.2.2 数据的可靠传输目前医院和数据交换中心的网络带宽有限，而医院和数据交换中心间需要交换的数据量非常大。在本方案中采用在医院端实现业务数据增量鉴别的技术确保在网络上传输增量的数据的方式完成医院与数据交换中心间大量业务数据的可靠汇总、发布。同时，还对增量数据进行传输前的压缩。通过这两种方式可以很大程度的减少网络上传输的数据量。同时，本方案在传输数据时采用消息队列的机制实现医院和数据交换中心间的数据的可靠传送。211、基于消息的机制可以采用发送/确认的模式，对于因为各种因素（网络暂时不可用等）引起的消息丢失，进行重新发送。5.2.10.2.3 元数据驱动的数据库管理数据交换中心建立的各种数据库，包括：主题库、各类业务操作型数据库等必须依据XXX的各类数据标准进行建设。在数据标准中，主要有代码类标准、数据元标准、数据资源的标准。在数据中交换中心的数据库的设计和创建时必须考虑到如何使用这些代码、数据元、数据类资源。另外，对于数据交换中心的各类的主题或者业务操作型库表及其字段定义必须确保含义、格式的准确和统一，实现一数一源的目标，从而确保数据交换中心各类数据的质量。本方案的设计是由统一的元模型控制数据交换中心各类212、库表的创建、维护。用户对统一元模型的管理侧重在业务角度的定义。在统一元模型中包含代码、数据元、数据资源等基本要素。元模型的注册和维护通过资源目录提供的服务功能完成，通过存储映射服务可以完成元模型到物理数据库的迁移和同步。5.2.10.2.4 合理的数据分布和数据交换体系架构数据交换中心的内容成份比较复杂，包括了各医院上报历史数据、汇总整合形成的主题数据、基本业务与协同业务数据等多种用途的不同数据分类。而数据交换中心本身的建设重点就是对数据的采集、整合与使用，合理的数据分布、良好的数据库规划将更好地发挥数据交换中心的作用，提高工作效率。在资源目录库与运行配置库的运行与数据管理规范的作用下，根据数213、据用途将数据交换中心分为历史库、主题数据库、业务操作数据库。数据分布与交换体系架的设计关键在于，建立合理的数据整合与处理平台。我们通过建立包括数据查询、数据存取、数据发布、数据接入、数据采集、数据传输等功能的数据整合平台，实现数据交换中心与医院的数据交换与共享。通过建立包括数据抽取、数据转换、数据加载等功能的数据处理平台，实现数据交换中心对各种数据的转换处理。5.2.10.2.5 数据处理方式的灵活支持各医院提供给数据交换中心的数据格式方面不是很统一。有数据结构方面的不统一的问题，也有数据编码方面的不统一。另外，各医院提供的数据在格式、质量方面也存在一些差异，例如：多余空格，日期表示格式等。但214、是，数据在进入各个主题库前必须完成统一才能确保主题库是可信赖的、高质量的数据库。本方案在设计时为数据处理提供丰富的内置功能支持。例如：如排序、合并、联合、过滤、转换、修改、字段检查、聚合等。另外，通过使用运行环境管理系统中的数据管理部分提供的代码管理服务，数据处理还可以对各个医院的数据中采用不同的代码编码进行自动的转换处理。代码管理中提供了不同的编码方案间的对照关系，因此自动的代码转换就可以使用这种对照关系完成自动代码转换。5.2.10.2.6 集成的运行环境管理数据交换中心各项功能的正常运行离不开完善的管理。数据交换中心需要管理的内容比较广，包括连接各个医院的数据整合的管理、对来自医院的数据215、的处理管理、数据管理、维护统一元模型的资源目录管理以及运行管理。在这些管理对象中，有很多管理是平台工具所提供的用户界面完成的，同时，数据交换中心还存在多个平台工具的情况；有些是定制开发的系统，例如：资源目录管理。管理人员面向这么多套管理功能界面时，很多时候会迷失方向。本方案为这种多样化的管理内容提供一套统一的管理系统。该系统采用封装各类管理功能的方法实现一个统一的管理界面，简化管理人员的使用。5.2.10.3 数据交换平台设计5.2.10.3.1 数据传输服务数据传输服务为系统间特别是异构的系统间的应用整合提供通讯基础。本系统设计有如下特点： 支持点对点通讯。消息发送应用可以向定点的目标系统发216、送消息。 支持点对多点通讯。消息发送应用可以同时向多个目标系统发送消息。 支持同步发送模式。消息发送应用可以以同步的方式向目标系统发送消息，这种模式保证消息发送完成后才将应用控制权交给消息发送应用。 支持异步发送模式。消息发送应用以异步的方式向目标系统发送消息，这种模式下，消息发送指令执行后立即将应用的控制权交给消息发送应用。 支持请求/响应消息交互模式。请求响应模式是远程服务调用中一种最基本的模式，消息收发功能提供了对这种模式的支持，消息发送者可以发送完请求消息后获取目标系统对请求消息的处理结果消息。 支持通知消息交互模式。通知消息交互模式是消息应用向目标系统执行信息公告的交互模式，目标系统217、接收到通知类型的消息可以根据业务需求自行处理。 支持回执消息交互模式。回执的交互模式要求消息的收到方在收到消息后给发送方一个收到确认消息,以保证数据传输的可靠性。 支持消息携带附件发送。一个消息可以携带任意数量和大小的附件进行发送，对于大附件，消息收发会自动进行文件切割发送和收到数据组装的工作，方便消息收发应用对大数据的交换处理。 支持丰富的消息连接器类型。连接器是系统互联部分的重要服务，通过它系统外界进行通讯的通道。连接器管理可以让管理人员自定义各种类型的连接器，并且在系统中注册这些连接器。对于已有的连接器也可以根据实际的环境变化进行动态的删除和参数调整。系统支持的连接器类型包括：socke218、t，ftp,smtp，jms，vm，file，soap等。下面针对XX市数据中心交换平台实际需求对数据传输提供的服务进行详细说明：5.2.10.3.1.1 支持多种数据传输模式在医疗信息系统中，数据格式通常和业务的需求紧密相连，例如，疾病信息的格式。在建立“信息孤岛”的时期，对于同样种类的业务信息，例如：个人基本信息，不同的“孤岛”描述的方式也不相同。这种多样性的数量几乎和“信息孤岛”的数量相同，即每个系统所使用的数据格式有可能不同，各系统可能使用不同的数据库或数据文件格式。在数据交换中这个层面正式表达真正数据的层面，必须提出一种机制可以让来自不同的“孤岛”上的数据相互理解。本信息交换平台支持219、对异构数据的传输及整合，无论各应用系统使用何种数据库，如Oracle、sql server、sybase、DB2等，均能按照统一文件格式进行交换，通过信息交换平台，可将多种类型的数据进行整合。在这种设计中，有下面几个特点：第一、消除了数据交换中心需要直接面临各个医疗卫生单位的异构数据源的压力。数据交换中心将把更多任务投放到对收集的数据的汇总处理方面；第二、降低了前置端接入的成本。通过在各医疗机构部署的数据整合平台提供统一的接入服务，医院可以容易的把各种异构的数据源，例如：数据文件、 Oracle、SQL Server、SYBASE、DB2等集成到医院的数据整合平台。同时，平台支持一对一、一对多220、等多种传输模式，支持订阅/发布模式的数据传输，数据订约/发布机制能够有效支持基于数据变动的应用整合，提供了强大的事件发布能力。可以将中心数据库中数据的变化动态以XML的格式发送到消息队列，由医院前置端的应用进行接收和处理。5.2.10.3.1.2 支持传输优先级控制系统提供传输优先级设置功能。一般说来，数据根据所产生的实际先后顺序来进行交换，系统通过数据源及消息路由优先级设置，来实现对数据传输优先级的控制。数据交换中心管理端用户控制台可根据数据的紧急情况设置数据的传输优先级，信息交换平台能够根据数据的优先级以手工设置的方式来安排交换次序；同时数据交换的消息路由都是独立的线程调度，可以调整线程的221、优先级，以达到整个数据传输的灵活多变。5.2.10.3.1.3 支持自定义传输队列控制系统提供自定义传输队列配置功能。数据交换中心管理端可根据数据文件大小， 数据优先级，将不同的数据传输、转换过程划分为多个队列，队列间及队列内每个转换过程均可制定触发时间，实现负载均衡的高效传输。5.2.10.3.1.4 支持数据的安全传输功能数据在传输过程中进行加密、解密、以保证数据安全。本方案数据加密技术主要体现在以下几方面： 机密性：确保数据的保密性。机密性通常是使用加密实现的。可以使用加密算法（使用加密密钥）将明文转换为密文，并使用相应的解密算法将密文转换回明文。对称加密算法使用相同的密钥进行加密和解密222、，而非对称算法则使用公钥/私钥对； 数据完整性：确保数据免受意外或者故意（恶意）的修改。完整性通常是由消息身份验证代码或哈希值提供的。哈希值是从数据序列导出的固定长度的数值。哈希值用于验证通过非安全通道传送的数据的完整性。可以将收到的数据的哈希值与传送时数据的哈希值进行比较，以确定数据是否被篡改； 身份验证：保证数据来自某一方。数字证书用于提供身份验证。数字签名通常应用于哈希值，因为这些值比它们所代表的源数据小得多； 按照加密方法的不同，可分为对称加密和非对称加密，平台支持主流的对称加密算法（包括：AES、DES、3DES、Blowfish、CAST5、CAST6、IDEA、RC2、RC5、R223、C6、Rijndael等）和非对称加密算法（RSA），本系统提供用户根据不同场景（性能、加密强度、安全性等）的选择自由度。5.2.10.3.1.5 支持数据的可靠传输功能本方案采用为数据传输提供了安全、可靠的解决办法。在数据交换中心和各医疗卫生机构间传输数据使用的是消息队列技术。它的一些基本特点如下： 支持节点间数据传递服务的容错性。节点间可能因为网络或者系统的原因造成数据交换服务暂时不可用，系统能够根据一定的策略尝试服务的请求，当重新获取服务后可以把系统中断期间发出的信息重新发送； 支持传递数据的安全。对于安全可从网络层、会话层和消息层全方面支持。网络层支持安全网络传输协议。会话层采用基于用224、户名和密码的方式建立安全会话。消息层采用数字证书完成对所有消息的加密和签名； 支持节点间大对象数据传递。对于大对象数据，系统采用数据分割和组装的方式完成对大数据在节点间的传递；5.2.10.3.2 数据转换服务数据转换是指对从医院端业务系统中抽取的源数据根据数据交换中心确定的数据标准的要求，进行数据的检查、合并、拆分、汇总等处理，保证来自不同系统、不同格式的数据的一致性和完整性，并按要求装入目标数据库。数据转换主要完成由于以下原因造成的数据不一致性问题： 源数据系统同中心数据库在模型上的差异性； 源数据系统平台不一致：数据源可能包括基于不同平台数据库的数据； 源数据系统中采用的代码编码方案与目225、标数据系统中的代码编码方案的差异性； 源数据结构的不一致：有些数据源由于历史的原因，导致同一个表在不同的时期数据结构不一致； 源数据定义不规范导致错误数据； 对数据的约束不严格，导致无意义数据； 存在重复记录等。由于需整合的各应用系统的不同，可能会存在大量的转码工作。根据实际情况，数据转换工作一般会在以下几个环节中具体实现： 在抽取过程中进行数据处理； 使用异步数据加载，以文件的方式处理； 在数据加载过程中进行数据处理； 进入数据仓库以后再进行数据处理。采用在数据抽取过程中进行数据转换时，必须考虑抽取的性能以及对业务系统性能的影响；采用异步数据加载需要以文件方式处理时，必须充分考虑中间磁盘的存226、储量以及整个流程的协调性工作，以及大量的非SQL语句的编程；采用在数据加载过程中进行数据转换时，必须考虑加载性能。根据XX市数据中心交换平台建设的实际需求，在数据转换方面的特点体现在以下几个方面：5.2.10.3.2.1 可靠的数据转换功能数据转换采用映射转换的方式，对输入的数据按照一定的映射规则进行数据结构、数据值的修改。在结构的转换中数据项的数量可能缩小，也可能扩大。对于数据项缩小的情况来说，就是指从输入的数据项中挑选了部分数据项，分别作为输出的数据结构中的数据项，同时可以在数据项对应关系的基础上进行简单的数据值改动操作，这些改动通常可以包括：常量化、函数调用、前缀、后缀。同时在转换过程中227、，对转换中的每个步骤进行控制，一旦产生出错的情况,允许用户自定义各种处理策略，出错后允许用户手工纠错并继续执行，在转入完毕后如发现严重的错误允许对上次的操作进行回滚操作，以此来保证数据转换的可靠性。5.2.10.3.2.2 高效的数据转换功能系统在数据转换的各阶段对其进行预先处理，如在进行数据抽取时，对数据进行质量监控，尽可能降低非法数据造成的影响；以异步方式进行数据加载，使整个系统协调工作，优化资源配置，以此来提高数据转换的效率；此外，系统还通过对语句的自动优化来提升数据转换的效率等。5.2.10.3.2.3 可测试的数据转换功能系统提供数据转换单元测试框架，用户可以模拟真实环境来转换进行跟228、踪和调试,使其达到可测试目的。5.2.10.3.3 数据处理服务数据交换中心的数据库是按照统一的数据标准建立的，是面向各家医疗卫生机构信息共享的业务需要而设计的，它和各个医疗卫生机构提供的数据在结构上和数据质量方面还是存在一定的差异的。数据处理服务设计的主要功能目标是对来自各个医疗卫生机构的数据进行抽取、转换最后存储到数据中心目标库中。本系统数据处理服务主要体现在以下几个方面：5.2.10.3.3.1 支持智能建库功能本系统基于SOA 架构而构建，具备易部署、易管理和易使用的特点，对于系统所要扩展的服务达到热插拔的效应。对于新增业务系统，只需通过信息交换平台管理控制界面，将新增业务系统的数据结229、构表填入即可，而无需重新手工建库。5.2.10.3.3.2 支持数据备份功能信息交换平台所采集的业务数据来自各医疗卫生机构业务系统，其数据库管理系统有多种类型，常见的有Oracle、DB2、Sybase、MSSQLServer等。数据交换中心需要对整合后数据进行备份，一方面可通过常规方式对中心数据库进行本地或异地备份，另一方面，系统支持将中心数据加载到各类异构数据库中，如中心为Oracle，将其数据备份到某sql server数据库中。此外，可通过配置特定消息路由的方式将各类异构数据库定期交换到备份数据库中，以此满足数据备份存储多样化需求。5.2.10.3.3.3 支持数据一致性信息交换平台支230、持多个异构数据库的数据同步操作，平台提供增量数据（或更新数据）多系统间的同步，以达到多系统间的数据一致性。5.2.10.3.4 运行管理服务数据交换中心的正常运行需要管理支撑，管理要完整、高效。运行管理服务包括的主要内容有数据整合的管理、数据管理、数据处理管理、数据监控管理、资源目录管理、运行管理等，结合XX市卫生数据中心交换平台实际需求，在运行管理方面特色功能体现如下几点：5.2.10.3.4.1 支持远程监控功能系统提供远程监控功能，远程用户可以通过浏览器访问信息交换平台系统运行控制台，从而掌握系统运行各类型能指标，如数据交换频率、所交换数据统计、系统运行所消耗的硬件资源等情况。并对在系统231、出现异常情况的时候，能够及时提供报警信息。在系统出现异常情况的时候， 可通过如下方式进行报警： 系统内部自动报警，一旦登录到本系统，报警信息通过登录首页提示用户系统异常信息； Email方式，系统与邮件系统连接，将报警信息发送到特定信箱； 手机短信方式，通过与手机短信平台连接，将报警信息以手机短信的方式发送给用户； Log方式，以系统日志的方式进行报警信息提示。5.2.10.3.4.2 支持远程配置管理功能系统提供远程配置管理功能。用户通过浏览器或其他客户端工具访问系统配置管理界面，可查看各节点的网络以及应用的状态，并可对节点的应用进行管理，如启动、停止或重启节点上安装的应用。此外，可对系统各232、类运行参数进行配置，如数据交换频率、业务表之间关系配置、数据路由规则等。5.2.10.3.4.3 支持事件管理功能对于系统运行过程中所产生的信息，如消息的开始发送时间、发送完毕时间、建立连接的时间等等，系统以事件的方式反馈给用户。用户可以通过分析事件消息的内容，对系统运行情况进行判断，同时在系统出现异常情况的时候，能够通过事件功能及时提供报警信息。5.2.10.3.4.4 支持可视化自定义业务流程功能本系统中流程自定义是指采用可视化流程模型来描述复杂数据交换过程，并且在流程活动中内置支持多种类型的内置服务，例如：消息收发、数据处理、服务调用等。整个建模支持可视化工具建模，同时对于正在交换的流程233、可以监控。对流程中的各个环节均可调用本地系统的各种服务或其他系统提供的各种服务，每个环节均允许人工的进行干预，流程每次的运行过程均可通过流程监控的可视化来进行监控和管理。在本系统中，对于流程的启动支持下面几种方式： 定时启动。这种情况是数据交换流程自主按时启动的方式。 外部事件触发。这种情况通常是由外部发生的事件引发数据交换的流程启动。通常外部事件可以是业务系统完成一笔业务、某个数据文件到达目的地、收到某个邮件等。这些事件可以根据类型不同触发不同的流程，这个是通过定义事件处理规则完成。 手工启动。由用户选择目标数据交换流程完成数据交换流程的启动。这种情况通常用在某种临时任务、数据迁移任务等方面234、。5.2.10.3.4.5 支持生命周期管理功能系统支持生命周期管理功能。对所交换的每份数据文件均可定义生命周期，若数据文件如在生命周期内未发送成功，则信息交换平台会将未发送成功的原因和结果反馈给用户，并可手工再次发送。对于处于生命周期内的数据文件，信息交换平台将会自动的根据重发策略设置来处理各种异常的情况（如断电、网络不通等）。5.2.10.3.4.6 支持服务的易部署、易管理和易使用本系统部署简单，只需通过将文件（一般为war包）拷贝到指定目录即可运行，或通过web方式来发布应用；易管理体现在数据交换中心及所有交换节点可以通过统一的界面来进行管理，可在此界面上进行各种管理操作，如设置交换频235、率、改变节点连接状态、配置业务表对应关系等，并可以通过统一的管理界面，可实现对系统运行性能指标的监控；此外，本系统通过友好的人机界面设计，实现系统操作的人性化。5.2.10.3.4.7 支持完整日志功能系统提供完备的日志服务，来支撑对交换和处理的数据的性能及质量的分析需求。日志的范围通常涉及到数据在数据交换中心和各医疗卫生机构间采集的日志、数据交换中心执行数据归并、转换、加载等日志。平台几乎对所有的数据处理、移动提供日志，并且有些日志还包括多种级别，例如：数据转换日志，可以设置仅记录转换的摘要信息，或者同时记录转换的明细日志，并能够对数据的传输、访问路径进行跟踪，以检查此数据交换的历史痕迹。另236、外，日志的存活期也是可以配置的，有些日志需要保存半年，有些一个月。对日志的管理主要的目标是实现数据交换中心运行的效率和过程可观测程度间的一个平衡。观测程度高意味着需要更精细的日志服务，同时也增加了计算资源和存储资源在日志数据方面的投入。5.2.10.3.4.8 提供二次开发接口子系统系统具有良好的扩展性，支持其他应用系统的开发接口，实现多系统之间的松散耦合，可为医疗卫生业务的多个系统提供信息交换平台，同时也可为其他业务系统提供数据交换服务。5.2.10.4 数据交换平台功能5.2.10.4.1 功能目标定位本交换产品的功能目标如下： 为用户和上层应用提供统一的数据访问视图和数据处理。采用逻辑数237、据格式定义屏蔽数据的实际存储实现，采用逻辑数据来源定义屏蔽数据的具体物理位置，实现数据透明访问。 为现有应用服务提供服务包装功能。现有应用服务的实现技术存在多样性的情况，通过规范的应用服务包装可以将现有应用服务接入各种业务协作和数据交换的系统，完成数据共享和服务协作。 为上层应用提供统一的消息收发服务。采用统一消息收发接口和传输适配器相结合的方式，实现了多种消息传输协议的可插拔和并行运行支持，极大的保证了系统的开发性，易于和其它各类系统实现互联互通。 为用户解决复杂的数据交换和处理提供易用的、可扩展的解决方案。通过可视化的数据处理规则定义、数据交换流程模型定义、事件处理规则定义等，可以快速完成238、一个交换的过程创建和部署。5.2.10.4.2 系统架构图5.2.10.4.2-1 产品技术架构从技术架构的角度，本交换产品包括了管理服务、运行服务和监控服务三大部分。管理服务是面向信息资源集成平台管理员所提供的服务功能，它由消息集成、数据集成、服务集成和流程集成中相关的管理服务联合组成。运行服务是面向其它系统或者相关业务操作人员提供的服务功能。运行服务的对象主要是参与交换的其它系统，例如：一个前置机上的前置库、文件目录，一个交换中心的中心库等。操作人员使用运行服务主要是在一些数据交换流程中有些人工参与的地方，例如：人工的数据比对。监控服务是面向信息资源集成系统管理人员提供的监控信息资源集成过239、程的功能。它分别由消息集成、数据集成、服务集成和流程集成中监控相关的功能组成。本交换产品的技术架构图中的系统互联部分是由运行服务中部分功能实现的，而这些功能分别来自消息集成、数据集成和服务集成中的与系统连接相关的功能联合完成。本交换产品在设计和开发中遵循各类标准规范，保持系统具有足够的开放性。这些标准规范涵盖了系统互联、管理、安全、数据等方面。5.2.10.4.3 消息集成服务消息集成是应用整合的基础，消息传送为系统间特别是异构的系统间的应用整合提供通讯基础。消息传送的功能包括：消息收发、消息安全、消息地址、消息路由、消息转换等。 支持点对点通讯。消息发送应用可以向定点的目标系统发送消息。 支240、持点对多点通讯。消息发送应用可以同时向多个目标系统发送消息。 支持同步发送模式。消息发送应用可以以同步的方式向目标系统发送消息，这种模式保证消息发送完成后才将应用控制权交给消息发送应用。 支持异步发送模式。消息发送应用以异步的方式向目标系统发送消息，这种模式下，消息发送指令执行后立即将应用的控制权交给消息发送应用。 支持请求/响应消息交互模式。请求响应模式是远程服务调用中一种最基本的模式，消息收发功能提供了对这种模式的支持，消息发送者可以发送完请求消息后获取目标系统对请求消息的处理结果消息。 支持通知消息交互模式。通知消息交互模式是消息应用向目标系统执行信息公告的交互模式，目标系统接收到通知类241、型的消息可以根据业务需求自行处理。 支持回执消息交互模式。回执的交互模式要求消息的收到方在收到消息后给发送方一个收到确认消息。 支持消息携带附件发送。一个消息可以携带任意数量和大小的附件进行发送，对于大附件，消息收发会自动进行文件切割发送和收到数据组装的工作，方便消息收发应用对大数据的交换处理。 支持丰富的消息连接器类型。连接器是系统互联部分的重要服务，通过它系统外界进行通讯的通道。连接器管理可以让管理人员自定义各种类型的连接器，并且在系统中注册这些连接器。对于已有的连接器也可以根据实际的环境变化进行动态的删除和参数调整。目前本交换产品支持的连接器类型包括：socket，ftp,smtp，jm242、s，vm，file，soap等。5.2.10.4.4 服务集成服务集成是交换节点间采用服务调用的方式完成彼此间数据的发送和接收的过程。在服务集成中服务调用仅指具有远程能力的服务调用，例如：xml-rpc、web services、ejb、dcom、corba等。在这些服务调用的技术中，大部分要求调用的客户端采用的技术与服务提供端的技术相同，例如：必须采用J2EE技术的客户端调用EJB，采用dcom的客户端调用dcom服务端程序等。这种限制对于在不同技术的系统间采用服务调用方式完成系统互联产生了很大的障碍。由此，也产生了相关的技术屏蔽这种技术的差异，其中xml-rpc和web services 243、是可以使用的两种方案，而web services因为其相关协议和规范的不断发展而逐渐成为一个主要的解决异构系统间服务调用的方案。5.2.10.4.5 数据集成服务数据集成是完成对分布在网络上的各种数据提供统一访问和处理的功能，它主要包括提供统一访问的数据网格服务和面向复杂处理的数据处理服务。另外，作为支撑模块在数据集成中还包括元数据访问的服务。主要的功能特点如下： 提供丰富的元数据服务功能。元数据注册管理是为多个系统间基于统一服务接口实现联合查询或者数据交换提供的基础管理服务。注册管理的内容是元数据的注册管理，元数据种类包括代码、数据元和数据类资源。数据元注册管理了信息资源数据最小单元，代码作244、为数据元管理中的一个部分定义了数据的取值。数据类资源注册管理了信息资源的基本含义、信息资源的内容格式内容等。 支持灵活的数据采集服务。数据采集是数据网格中的一项重要功能，是实现异构来源数据集成和共享的重要手段。数据采集主要是将某一个数据资源在一个数据源中的全部或部分数据，抽取并输出到另一个数据源中。这两个数据源可以是在同一个数据网络节点上的，也可以是不同数据网络节点上的；可以是同一种类型的数据源，也可以是不同类型。数据网格的数据采集支持大部分类型的关系数据库和文件。 支持数据转换。映射转换服务是对输入的数据按照一定的映射规则进行数据结构、数据值的修改。在结构的转换中数据项的数量可能缩小，也可能245、扩大。对于数据项缩小的情况来说，就是指从输入的数据项中挑选了部分数据项，分别作为输出的数据结构中的数据项，同时可以在数据项对应关系的基础上进行简单的数据值改动操作。这些改动通常可以包括：常量化、函数调用、前缀、后缀。 支持数据分发。数据输出是指将系统中的数据输出到外部系统的过程。数据输出中的数据来源可以来自：内存变量、数据库、文件系统等。数据输出的目的地可以是本地/远程文件、关系数据库、XMLDB、邮件系统、输出消息路由器、消息队列/主题、web服务等。5.2.10.4.6 流程集成服务在本交换产品中流程集成服务是指采用统一流程模型语言描述复杂数据交换过程，并且在流程活动中内置支持本交换产品中246、多种类型的内置服务，例如：消息收发、数据处理、服务调用等。整个建模支持可视化工具建模，同时对于正在交换的流程可以监控。在本交换产品中对于流程的启动支持下面几种方式： 定时启动。这种情况是数据交换流程自主按时启动的方式。 外部事件触发。这种情况通常是由外部发生的事件引发数据交换的流程启动。通常外部事件可以是业务系统完成一笔业务、某个数据文件到达目的地、收到某个邮件等。这些事件可以根据类型不同触发不同的流程，这个是通过定义事件处理规则完成。 手工启动。由用户选择目标数据交换流程完成数据交换流程的启动。这种情况通常用在某种临时任务、数据迁移任务等方面。5.2.11 数据采集5.2.11.1 医院数据247、采集方式医院数据采集是建立各医院之间的临床诊疗信息共享机制的基础。进而可以实现医院之间临床诊疗信息的共享。本期项目中主要实现临床检验信息、双向转诊信息和基于临床信息的公共卫生监测数据的采集，这些数据均在各医院内部系统中产生。5.2.11.1.1 医院端数据的产生诊疗业务涵盖门诊类业务和住院类业务。门诊类业务是指：普通门诊、急诊，专家门诊，特需门诊，专科门诊；住院类业务是指：普通住院、急诊观察，特需住院。患者是指获得医疗服务的人，包括使用XX市社会保障卡，包括中小学生学籍卡、医保磁卡、干保卡等就诊人员以及使用医院就诊卡的就诊人员。对于门诊类业务和住院类业务，诊疗的流程、诊疗数据的产生来源及产生顺248、序见以下两图（其中蓝色标记部分为本期项目所需要采集的信息）：图5.2.11.1.1-1 门诊类流程及各环节产生的数据图5.2.11.1.1-2 住院类流程及各环节产生的数据基于临床信息的公共卫生监测数据主要来源于医院门急诊在诊疗过程中对患者症状信息的采集，其数据产生过程参见门诊类数据产生流程。双向转诊主要涉及到两家医院就诊流程的衔接，一般发生在医院门急诊，其流程与各环节产生数据如下图所示（其中蓝色标记部分为本期项目所需要采集的信息）：图5.2.11.1.1-3 诊疗转诊流程图5.2.11.1.2 医院端数据的提交数据中心的医疗和临床数据（本期项目中主要涵盖患者基本信息、患者检验履历和检验结果信249、息）、双向转诊数据和基于临床的公共卫生监测数据（本期主要为症状监测信息）来自于各联网医院在日常业务中采集的信息，并经过整理后提交数据中心。以上数据都来源于临床诊疗过程，在下文中以“诊疗信息”统称这些采集上来的数据。医院向数据中心系统提交诊疗信息的解决方案原理图如下：图5.2.11.1.2-1 数据上传技术通道图5.2.11.1.2-2 数据上传的路径与方式根据所采集数据性质的不同在具体技术实现上可以有两种不同的触发方式：时间触发与事件触发。时间触发主要是针对实时性要求不高的大量数据的交换。在本项目中，一般患者的基本信息和检验数据对共享的实时性要求不是很高，一般在患者下次就诊（通常情况下会间隔一250、天）或在网上查询时才会产生共享需求。这种情况占数据交换的大部分比重。基于其业务要求，考虑到实时性对网络和中心端的负载，可以采用定义一定的数据交换运行计划而周期性的完成其数据的采集，如每天下午18:00开始至次日上午7:00，划分时段由各社区卫生服务中心/乡镇卫生院和各医院轮流定时上传本日（或前日，具体根据用户实际情况定制）所有发生的病患检验信息。这种方式将上传数据集中在非工作时段，从而保障了本系统内关键实时业务在工作时段的高效运作，例如：医生在白天为病患就诊时调阅患者在他院的检验信息、医生在健康档案中调阅患者在区内医院的检验信息、双向转诊的数据流转以及基于临床信息的公共卫生监测预警信息的上报。251、针对时间触发的数据采集，数据的提交具体在技术实现上可以有两种方式实现各级医院向XXX医联体平台卫生数据中心提交患者诊疗信息（患者基本信息、检验履历信息和实验室检验报告）。5.2.11.1.3 主要方案要求医院软件开发商按照约定的数据内容和格式编制数据提交例行作业，定时将需要提交的数据分类整理完毕，形成数据库表的数据记录，插入前置机上部署的上传数据缓冲区的数据库表中。利用数据库机制保障上传数据的唯一性、完整性、格式准确性。5.2.11.1.4 备选方式由医院根据数据采集要求开放需要采集的数据库表，由数据交换平台软件自动根据数据库表数据的变化情况采集，定时上传数据。上述两种方式均不会涉及到影响医院252、内诊疗诊断业务流程的运转，在技术上属于采用了松耦合手段（所谓松耦合的方式是指对原有的业务流程和原有的医院软件功能不发生影响或变动要求）。对于比较敏感的诊疗信息，一般可设置上传的定时频度为若干小时一次。对于非敏感的诊疗数据，一般可设置上传的定时频度为每日一次。事件触发主要是针对实时性要求高的具体业务所涵盖的数据。本项目中主要包括双向转诊和基于临床信息的公共卫生监测预警四项主要业务。事件触发方式直接由医生工作站发起，利用前置机的数据交换平台医院端与中心端所搭建的数据交换通道即时完成触发业务的反馈。针对基于临床信息的监测预警数据上传的业务反馈由卫生数据中心完成，而双向转诊则需要通过数据交换平台所搭建253、的通道获得指定医院的反馈从而完成信息的即时交互。上传时若由对原先已经上传的数据记录进行变更的情况，则需要在字段的相应标识位上予以标识。对上传数据中采用编码方式表达的字段内容，由于各个医院的编码表达方式有所不同，为此需要进行对编码的翻译转换。对此的实现方式由中心系统部署的数据交换平台依据医院设置的代码字典加以实现。5.2.11.2 医疗业务数据采集5.2.11.2.1 患者基本信息的获取方式患者基本信息可以采用从医院挂号或入院登记时从社保卡中读取患者基本信息，收集集中成为共享资源。但需要逐步收集（因为居民不一定成为就诊患者）。从管理部门角度考虑，还可以从其他三个方面获取居民基本信息：首先，考虑与254、医疗机构病案系统交换数据；其次，考虑与XX市的实有人口库交换数据；第三是健康档案中的居民基本信息。5.2.11.2.2 患者就诊履历的获取方式对于患者档案数据，可以与全员人口数据库进行数据交换，形成患者档案。具体采集内容主要包括患者基本信息、患者的就诊记录、健康档案记录，即为患者一次门诊或住院过程中的信息，其中包含了挂号记录信息、入院记录信息。5.2.11.2.3 双向转诊数据的获取方式双向转诊数据包含两类数据：1、转诊资源数据：主要包括各转诊协议医院间门急诊挂号资源（如专家号、科室号等）。转诊资源数据需要直接从医院HIS系统中获取，并根据医院端挂号资源的更新即时更新中心端信息。2、转诊单信息255、：该信息伴随着双向转诊事件产生，是各转诊协议医院实现患者转入转出的凭证。转诊单信息按照XX市医疗机构定向转诊单要求，采集患者的基本信息、在转出医院的病史、诊断以及转诊建议等内容。5.2.11.3 PACS数据采集5.2.11.3.1 概述区域项目影像检查数据采集接口规范建立目标在于便于各家医院的PACS、RIS或MIIS数据的上传，以实现中心端影像资源的共享。建立统一的对影像检查的影像资料及报告数据收集的规范，使影像、报告及报告数据形成一个有机整体。同时在病人基本信息的收集方面使区域项目在数据的完整性和多样性方面得到丰富。在未上传其他业务资料的情况下，区域项目影像检查数据可以通过病人基本信息关256、联得以应用。同时由于数据的完整性得于提高，则上级管理部门可以作出正确的统计、分析，为有效利用影像检查资源提供数据参考。5.2.11.3.2 数据上传流程图5.2.11.3.2-1 数据上传流程图各医院PACS/RIS系统，将对应检查的相关信息上传至前置服务器。按检查信息表、检查收费明细表、报告信息表填写要求上传数据至前置机。病人经过影像检查后，按照第四章技术规格总则中技术要求将影像上传至前置服务器。在前置机检查信息表中找到对应Study的注册信息后，将影像注册信息上传至中心端服务器。如果未找到对应的注册信息，则前置机会等待5日，每日进行一次数据校验，直至数据检验确认数据完整后再将影像注册信息上257、传至中心端服务器。5日后数据仍未上传则前置机将数据删除，并作日志记录；病人检查报告完成后，按照技术要求将报告封装成DICOM文件后上传至前置服务器，同时将检查报告的数据上传至前置机报告信息表。前置机检查信息表中找到对应注册信息后，将影像注册信息上传至中心端服务器。如果未找到对应的注册信息，则前置机会等待5日，每日进行一次数据校验，直至数据检验确认数据完整后再将报告数据上传至中心端服务器。5日后数据仍未上传则前置机将数据删除，并作日志记录；中心端服务器接收数据成功后，向数据中心进行注册。如果数据中心已有该病人基本信息，则进行检查信息的注册。如果数据中心仍未有该病人的基本信息，则向数据中心进行该病258、人基本信息的注册及检查信息的注册；可以与就诊流水号关联起来的影像、报告数据，在医院终端可以通过检查关联调阅。不能与就诊流水号关联起来的影像、报告数据，在医院终端可以通过病人关联查询到历史影像检查数据。5.2.11.3.3 数据变更流程图5.2.11.3.3-1 数据变更流程图医院端系统更新或删除已上传的数据，则需要进行数据修改操作；向前置机的患者信息表、检查信息表、检查收费明细表、报告信息表写入相应的记录。在写入数据时，注意需要作的操作与标志的正确匹配： 1：正常、2：修改、3：撤销。向前置机上传对应的影像或报告；前置机在对数据进行校验，如果数据内容正确匹配则上传至中心端，如果不能正确匹配，则259、将错误记录写入错误记录表。5.2.11.3.4 统计数据上传流程图5.2.11.3.4-1 统计数据上传流程图医院端将对应设备及设备编码对应字典表上传至前置机的设备代码字典表（ZD_SBDM）。如果有变更则需要正确填写对应的标志；每日医院端向前置机设备检查人次日报表（TJ_SBJC）填报对应设备的检查人次；每日医院端向前置机设备报告完成人次日报表（TJ_SBBG）填报对应设备的报告完成人次；5.2.11.3.5 技术标准总则为了使新建医院PACS/MIIS系统以及原已建设PACS系统的医院能顺利通过中心平台实现与其它联网医院对影像类业务数据交换共享的目标，需要对医院上传到前置服务器的影像进行统260、一管理，使其按照规范实现与医院外部的业务数据交换共享。要求的具体内容如下：1、 PACS/MIIS对外共享的图像和诊断报告（上传到前置服务器的影像和诊断报告）中有关病人对外的唯一标识符(Patient ID)必须使用区域项目统一约定的患者唯一索引。2、 对医院外部提供交换共享的DICOM图像和诊断报告必须包含病人的姓名（汉字、汉语拼音或英文字符串）、出生年月日和性别。3、 PACS/MIIS图像显示工作站必须能同时显示病人在某医院（或科室）内的唯一标识符(Patient ID)以及区域项目约定的患者唯一索引。4、 PACS/MIIS对外图像通信必须提供DICOM Storage SCU/SCP261、 和 DICOM Query/Retrieval (Patient Root/Study Root) SCU/SCP 、DICOM WADO SCP通信服务，并能定时向数据中心发送DICOM 图像。5、 PACS/MIIS应提供IHE XDS-I 成像数据源角色（Imaging Document Source Actor）对外图像信息注册发布功能。6、 PACS/MIIS应提供IHE XDS-I 成像数据使用角色（Imaging Document Consumer Actor）对数据中心图像查询提取功能。7、 XDS-I的功能参见标书要求，具体实现的方式、范围及时间依据总集成商的要求开展。8、262、 PACS/MIIS在实施和提供图像共享运行过程中，厂商应能按招标方要求对共享的DICOM图像某些参数或图像输入输出的通信流程在一定时间段内进行调整。9、 PACS/MIIS应按照数据中心统一规范的接口要求和数据格式要求实现对影像检查报告的发布、查阅使用。5.2.11.3.6 数据标准1、 影像数据标准遵循DICOM 3.0标准，允许key Image标注；允许Presentation Statement对象；2、 诊断报告依DICOM标准中PDF对象封装标准，以独立的一个series出现；该series的modality定为“REPORT”类型；对于同一个检查（StudyUid相同）下面的多263、份报告可以以多个序列（series）的形式出现或以同一序列下的多个图像（image）的形式出现，在只有报告没有检查影像的情况下，报告以独立的一次检查出现。同时报告的数据内容作为注册信息的一部分到影像业务前置机进行注册。3、 在符合DICOM3.0标准的前提下，对影像数据中若干Tag位的定义与要求作如下说明：Tag位的定义及要求Tag特别定义与要求(0010,0020)Patient ID项目规定的病人唯一索引号(0010,0010)Patient NameDICOM数据格式要求，非空(0010,0040)Patient SexDICOM数据格式要求，非空(0010,0030)Patient B264、irthDICOM数据格式要求，非空病人唯一索引号说明：项目规定的病人唯一索引指的是数据采集场景中规定的社保卡、医保卡、卡号，对于医院的自费就诊卡及其他类型的就诊卡，使用“医疗机构代码就诊卡卡号”作为唯一索引；5.2.11.3.7 影像类业务专业特殊性要求及其他内容1、质控要求所有上传的影像及诊断报告格式与内容应符合相应质控中心的质控要求。2、影像类业务n 由放射科室（普放、CT、MR、PET、DSA等）、超声科、内镜中心及病理科等影像科室所产生的影像数据及诊断报告在条件具备的情况下均应上传。n 与诊断报告无关的后处理、三维重建数据不上传；为诊断意见专门做的后处理数据应该上传；各影像设备产生动265、态影像数据也暂时不上传。n 由体检业务所产生的影像数据和干保相关影像数据暂不上传。必要时的诊断报告修改，在内容修改完毕后，保持Series UID, Image UID等UID不变上传。5.2.11.4 LIS数据采集本期建设的临床数据采集主要包括患者检验履历、实验室检验报告。5.2.11.4.1 检验数据的提交流程实验室检验通常的现状业务流程如下图。图5.2.11.4.1-1 检验数据提交流程图医院向数据中心提交患者检验履历、实验室检验报告的业务环节对上述通常的业务流程不造成影响或变动。仅增加一个自动定时的作业环节，向医院前置机约定的目录中归档检验报告。流程如下图：图5.2.11.4.1-2266、 归档流程图5.2.11.4.2 检验数据的提交方案具体在技术实现上可因数据提交的触发方式不同而有不同的解决方案：1、时间触发两种方式：以时间触发方式的检验数据采集可以有两种方式实现医院向数据中心提交实验室检验报告。第一种方式是主选方式：由医院本地的LIS系统将已经完成检验的报告汇总，定时批量将约定了格式的报告放入部署在医院的前置机规定目录中。此方式通过编制应用软件并按自动例程运行定时执行即可。第二种方式是备选方式：由医院向部署在医院的前置机用户开放LIS系统中检验报告数据库表，并且用一个字段的值标识该报告已可归档。由前置机自动判别报告可归档标识后，将相应的数据自动采集上传。上述两种方式均不会267、涉及到影响医院内诊疗诊断业务流程的运转，在技术上属于采用了松耦合手段（所谓松耦合的方式是指对原有的业务流程和原有的医院软件功能不发生影响或变动要求）。报告提交数据中心的时点以时间触发方式在医院LIS系统获得结果以便于交换的需求在时间要求上并不迫切，考虑到数据提交对医院内部系统、卫生网络和数据中心端的负载，建议在医院业务脱离繁忙期之时从各联网医院按照预定义策略依次提交数据。数据提交策略需要充分考虑全区各家医院实际情况，根据数据产生的数据量、敏感程度和医院繁忙程度制定，可以一日一次，也可以一日多次。2、事件触发事件触发方式在本项目中主要是指因双向转诊而导致的患者转入医院对转出医院检验数据的调阅，由268、于存在数据的产生和数据的调阅是在同一天（即患者在一天之内完成在转出医院和转入医院的就诊）的情况，时间触发的方式不能保证检验数据在医院间的流转，故需要以事件触发来主动促进数据的交互。数据的提交由医院内部信息系统发起，其主动将双向转诊相关检验数据推送到医院前置机及时告知前置机事件相关数据已经产生。部署于医院的前置机获取数据后立即通过数据交换通道提交数据中心，由数据中心完成数据的分发。5.2.11.4.3 检验数据的采集内容具体内容为文本文字形式。业务上的数据组织患者检验履历与实验室检验报告之间存在关联关系，患者检验履历实验室检验报告为1：N关系。1、患者检验履历（单项）：报告流水号、取单号、患者唯269、一索引号、处理日期、检验单样本号、病人姓名、性别、年龄、报告人、审核人、临床诊断、申请病区、申请科室、床号、申请医生、打印日期、申请日期、采集日期、报告日期、报告备注、标本类别、报告单类型、医院代码。2、实验室检验报告（多项）：报告流水号、检测项目、检测项目、检测结果、仪器名称、值域范围、计量单位、异常提示、打印顺序。5.2.11.4.4 检验数据的编码转换由数据中心按照医疗检验的业务规则，建立功能软件，将所有的相关检验项目编制成为数据字典。在医院前置机上，各医院可以按照本医院的内部数据处理编码规则一次性设置这些项目的分类代码、名称代码、正常值范围（也可以提交数据中心管理人员，由管理人员代为设270、置）。医院提交数据时需要按照自己已设置的编码规则规整数据。前置机根据字典将医院上报内容适时自动转换成为统一的标准代码后在数据中心归档。5.2.11.5 基于临床信息的公共卫生监测数据采集基于临床信息的公共卫生监测数据按照XX市疾病预防控制中心要求，由门急诊医生在对患者进行诊治时填写并上报。其症状部分数据采集内容按照XX市疾病预防控制中心要求定制，主要包括9类症候群共59种症状信息。具体内容如下：症候群分类常规监测目标症状全身症候群发热1低热中等热度高热超高热寒战乏力全身疼痛呼吸系统症候群鼻塞咽痛咳嗽咳痰胸痛呼吸困难咯血消化系统症候群恶心呕吐2腹痛腹胀腹泻3里急后重便秘纳差便血脱水神经系统症候群271、头晕头痛意识障碍烦躁抽搐皮疹症候群斑疹丘疹水疱疹脓疱疹焦痂溃疡出血症候群瘀点瘀斑鼻衄牙龈出血肉毒杆菌毒素中毒症候群口干语言障碍吞咽困难无力面色潮红视力模糊复视肝科症状厌油肝区不适肝肿大巩膜黄染尿黄其他症状无尿4少尿多汗结膜充血颈胸充血腰痛眼眶痛淋巴结肿大说明：l 1 用户在选择“发热”症状时，必须在“低热”、“中等热度”、“高热”、“超高热”之中选择一项；l 2 用户在选择“呕吐”症状时，必须填写额外信息，其内容包括症状持续时间（多少天）、频率（一天几次），以及呕吐物性状（食物、水样、米泔样、血水样）、量（多、少）、方式（喷射状、恶心、先泻后吐、先吐后泻、吐泻同时）；l 3 用户在选择“腹泻”272、症状时，必须填写额外信息，其内容包括症状持续时间（多少天）、频率（一天几次），以及粪便性状（稀便、水样、米泔样、洗肉水样、大块粘膜、粘液血便、脓血便、粘液、鲜血便、其他）、量（多、少）、方式（里急后重、通畅、失禁、绞痛）；l 4 “无尿”、“少尿”选项互为排斥，选择其中一项，则另一项不可选。5.2.12 外部接口5.2.12.1 与省级数据交换系统的接口与省级数据交换管理系统进行对接，需要交换的数据包括：获取健康档案数据；上报信息，向国家、省公共卫生直报系统上报的信息；省管理机构监管的医疗机构的业务服务信息；调阅其他市级平台的居民健康档案、电子病历等信息；提供本区域内的居民健康档案、电子病历等273、信息；共享交换居民MPI主索引消息。5.2.12.2 与妇幼信息系统接口与妇幼信息系统对接，获取人口出生信息和妇女儿童保健档案，为基层医疗机构随访提供数据，为卫生服务措施提供信息，为统计监管提供数据来源；5.2.12.3 与市级卫生信息系统的接口与市级卫生信息系统，如疾控实验室管理系统，实现数据共享与交换。5.2.12.4 与血站系统的接口与血站信息管理系统对接，获取血液和血液制品库存、用血记录、献血者和使用者档案信息。5.2.12.5 与卫生监督系统接口与卫生监督管理信息系统对接，获取公共卫生、传染病、食品安全、医疗质量、医疗行为等统计监管数据。5.2.12.6 与计划免疫系统接口与计划免疫274、系统对接，疫苗接种不只有基层医疗机构提供服务，二级医疗机构也要提供疫苗接种服务，通过与计划免疫系统对接，完善基层计划免疫档案，为免疫统计监管提供数制依据。5.2.12.7 与公安系统的接口人口健康信息综合管理平台从公安系统获取户籍档案、出生人口信息、户口迁入人口信息，触发新增人群（出生、户口迁入）的健康档案建档工作。可从公安系统获取户口迁出的人口信息，触发户口迁出人群所对应的健康档案的封存和转档。5.2.12.8 与民政系统的接口人口健康信息综合管理平台从民政系统获取女性人群的婚姻信息，并将划定年龄段的已婚女性作为孕产妇保健预备管理对象。从民政系统获取残疾人群信息，在健康档案的建设中，为该类人275、群建立残障专项档案、提供残疾康复管理。提供人口死亡医学证明的签发数据，与民政系统实现数据互联互通。提供低收入者、贫困人口的档案与民政系统对接，获取低收入者、贫困人口的档案。获取优抚对象（现役军人、残疾军人、复员军人、退伍军人、烈士遗属、因公牺牲军人遗属、病故军人遗属、现役军人家属）的档案，为优抚对象医疗服务提供基础数据。获取五保户的档案，为五保户人员医疗服务提供基础数据。5.2.12.9 与二级以上医院信息系统的标准接口XXXX局医联体平台与二级以上医院对接，包括与医院信息系统的对接、与健康档案系统对接等。与医院信息系统的对接：与各级医院信息系统（HIS）进行对接，接入共享医疗信息，实现双向转276、诊、医疗协同等业务。包括：门诊医生处方、门诊病历、门诊治疗信息、住院病案首页、检查报告、检验结果、住院病程记录、住院病历、住院医嘱、住院护理记录、住院病人出院评估、健康检查报告。健康档案的对接：参加上述医疗机构管理信息系统中关于健康档案的共享使用和调阅描述。人口健康信息综合管理平台通过MPI主键索引卡与各医疗机构进行对接，实现数据共享与交换，将居民就诊及住院等信息传送到区域平台，以便进行监督管理、绩效考核、统计查询等。二级及以上医院需要根据区域平台的接入标准，实现内部诊疗卡与区域平台MPI主键索引卡的对接关联，医院通过该索引卡与区域平台对接，同时医院内部既可以通过原有的诊疗卡进行就诊等看病流程277、，也可以用主键索引卡进行就诊等看病流程。5.2.12.10 与120系统的接口对接120系统接口，采集急救医疗单位信息，救护车辆GPS定位，查阅派单与救护执行情况，实现指挥调度协同。5.2.12.11 与基层医疗机构应用系统接口与基层医疗机构应用系统进行对接，实现双向转诊、医疗协同等业务，需要交换的数据包括：医疗服务信息、基本公共卫生服务信息、电子健康档案信息、机构运营及绩效数据、管理指标数据。医疗机构可以通过共享交换平台调阅基层医疗机构应用系统的健康档案信息，同时，系统支撑平台中健康档案存储服务、全程健康档案服务、健康档案共享服务等核心服务，为二级以上医院健康档案的使用及管理提供了基础的系统278、支撑。因此，通过支撑平台健康档案服务和共享交换平台数据交换服务，医疗卫生管理机构及二级以上医院能够实现健康档案的管理和使用。5.2.12.12 在线支付接口与银联、第三方支付平台对接，实现平台支付、移动支付、第三方支付等在线支付方式，为患者提供移动终端缴费的功能，方便群众。5.3 患者服务集群患者服务集群包含但不仅限于：“互联网+医疗”服务，统一支付服务，健康档案及家庭医生签约服务，公共卫生服务。5.3.1 “互联网+医疗”服务5.3.1.1 互联网问诊患者通过互联网实现线上问诊服务，可以通过网上提交相关的病症问题，由医生通过平台提供医疗服务解答。同时医生可以通过互联网向患者提供诊疗服务，医生279、在线详细询问患者病情病史，查看必要的检验检查报告，并给出诊治方案。在线问诊主要以复诊和会诊为主，已经去医院就诊过的患者，把后续的康复和治疗放在互联网上解决；下级医院和医生遇到处理困难的病例时，可以通过互联网向上级医院的医生发起会诊请求，得到上级专家的诊疗意见。5.3.1.2 智能导诊针对患者提供就医导诊的互联网服务，主要是提供给患者安全、可靠、权威的就医指导意见，保障居民合理、有序、安全的就医。具体功能包括：医疗机构介绍（包括医院简介、医生简介、科室简介、人均费用/平均住院日/手术费指标等）、医生检索（提供按照医院、专家、症状、疾病等不同条件检索查 找医生）、就医体验与评价（查看居民在医疗机构280、就诊的就医体验和对医疗机构、医生的评价）、就医推荐（根据推荐 规则，如距离、热度（如就诊人次）、历史评价等，推荐就医医疗机构或医生）。1）实现患者自助、正确的导诊，提高挂号窗口的速度；2）降低患者挂错号、重复挂号的机率，提高导诊效率；3）降低导诊台医护人员的工作量，提高工作效率；4）降低因导诊台护士专业水平参差不齐而引发培训难得问题；5）提高患者对医院的满意度，减少不必要的医患矛盾；6）提高服务效率，改善服务环境；7）提高医院的品牌宣传，提升医院的知名度；5.3.1.3 预约服务提供医联体平台各机构的各类预约服务，包括病人预约和机构、科室间预约。请求和修改跨越大量服务点的操作预约、会诊预约、检281、查预约和其他医疗就诊预约。检查中心向各级医疗机构开放共享检查设备资源，建立基于互联网的医技检查预约平台，提供检查资源共享与检查协同服务，各级医疗机构可在线帮助患者预约检查中心的医技检查项目，患者按时直接到检查中心缴费检查，检查完毕报告返回给申请医生和患者，实现检查报告和医学影像的共享和互认，从而提升检查中心的设备利用率，提高各级医疗机构特别是基层医疗机构的诊断能力。5.3.1.4 检验检查报告查询广大居民可以通过XXX医联体平台提供的门户网站、手机APP等多种途径，查询近日在区域内医院进行的检验检查报告。具体功能包括：报告提醒、报告查询、报告定制与推送。5.3.1.5 门诊费用查询广大居民可以282、通过XXX医联体平台提供的门户网站、手机APP等多种途径，查询近日在区域内医院进行的门诊费用清单。5.3.1.6 住院费用查询广大居民可以通过XXX医联体平台提供的门户网站、手机APP等多种途径，查询近日在区域内医院进行的住院费用清单。5.3.2 统一支付服务提供覆盖主流在线支付机构（基本/商业医疗保险、银行、第三方支付平台）的统一支付服务。具体功能包括：用户管理（个人用户、接入机构用户、 黑名单）、个人用户实名制认证管理、接入机构资质管理、促销管理、积分管理、综合分析等。1、支持支付业务产品化，能够为第三方提供代理支付服务，实现结算运营中心从成本中心向利润中心的转变。2、利用专业化的集中处理283、提升支付业务处理效率，降低支付成本。统一收款、付款、对账流程，提高自动化、智能化水平统一科目，减少支付相关的内部科目设置3、提升对支付业务的跟踪监测能力，为业务管理、风险管控及客户服务提供便利。4、便于应对不断变化的内外部环境，提升支付业务的灵活性与适应性，满足市场的需要。5、独立的支付平台能够快速地响应不断变化的内外部环境，集中进行系统升级改造。5.3.3 健康档案及家庭医生签约服务5.3.3.1 家庭医生签约服务面向社区、乡镇居民，通过门户网站、手机 APP 等多种途径，预约家庭医生上门服务、查询服务记录、在线健康咨询。具体功能包括：家庭医生签约服务申请与服务签订、个人及家庭就诊记录的查询284、和推送、家庭医生上门服务记录的查询和推送、居民健康咨询回复信息的查询和推送、健康常识及惠民活动信息的发布、社区医生信息的发布。5.3.3.2 健康档案查询居民通过互联网、自助服务等多种途径，依据电子居民健康卡等进行身份实名安全认证与有效授权，实现对居民电子健康档案的查询。具体功能包括：居民可查询个人自身的就诊记录、检验检查结果、公共卫生服务记录、授权查询规则等。5.3.4 公共卫生服务5.3.4.1 医疗信息分级公开针对政府文件、部门规章、医疗卫生资源分级向公众公开，分为主动公开、依申请公开两类。具体功能包括：信息分级规则库、信息发布。5.3.4.2 病人膳食指南为术后患者提供出院后的膳食指导285、，明确不同疾病、不同身体状况的饮食规则，避免常见的饮食误区，提供有针对 性的个性化膳食指导以及对特定人群开展指导。具体功能包括：膳食设置检索、膳食知识库、膳食推荐与评价。5.3.4.3 中医治未病服务为居民提供高可及性的疾病预防和常见疾病高危因素等知识，提供疾病预防保健指南、各时节多发疾病预防知识、简易验方、公共卫生常识等多种健康知识，力求降低常见疾 病发病率、增加疾病康复成功率，从而实现降低医疗支出、 促进全民健康的目标。具体功能包括：预防保健机构注册与审核、预防保健机构信用管理、“治未病”各类健康干预服务数据采集等、“治未病”数据分析与决策支持系统。5.3.4.4 慢病管理面向居民通过门户286、网站、手机 APP 等多种途径，提供针对高血压、型糖尿病等慢性病的信息查询和信息推送服务。具体功能包括：慢病监护、随访评估信息、健康体检信息、健康状况信息、健康宣教和日常护理知识等。5.3.4.5 精神疾病管理面向居民通过门户网站、手机 APP 等多种途径，提供针对各种精神疾病的信息查询和信息推送服务。具体功能包括：就诊记录信息、随访评估信息、健康体检信息、日常心理健康和护理知识等。5.3.4.6 接种免疫服务通过免疫接种服务记录在区域内的共享和互认，为儿童提供跨定点机构的接种服务，加强免疫接种服务过程中的信息对称，为居民提供免疫接种服务提醒和相关知识。具体功能包括：免疫接种服务提醒、接种记录287、查询、跨区免疫接种服务、接种知识定制与推送、接种档案记录。5.3.4.7 用药服务面向居民和社区医生提供合理用药与安全用药知识查询服务。针对艾滋病、结核病、高血压、糖尿病、精神疾病等需要长期服药的疾病，面向妇女、儿童、老年人等特定人 群提供规范用药提醒服务。具体功能包括：药品信息查询、规范用药提醒等。5.3.4.8 健康教育为全市居民提供健康教育服务，包括普及性教育和针对特定目标人群（如慢病、精神疾病、传染病、妇女儿童、老年人等）的精准教育，并对教育效果做出评价。健康促进与教育业务在各级健康教育专业机构、基层医疗卫生机构、医院、专业公共卫生机构之间协同联动，以健康教育专业机构为龙头，各机构主动288、参与，共同做好健康促进与教育工作，并实现信息共享。具体功能包括：资源库管理、信息推送服务、健康教育服务登记、健康教育评价。健康危险因素和健康素养水平监测系统、健康科普资源库、个性化健康教育和健康干预工具、健康教育效果评价等。5.4 医务协同服务集群医务协同服务集群包含但不仅限于：双向转诊，区域PACS系统，区域LIS系统，区域病理系统，区域心电系统，多学科联合会诊（MDT）。5.4.1 双向转诊由于基层医疗机构在设备和技术条件方面的限制，对一些无法确诊及危重的病人转移到上一级的医疗机构进行治疗，上一级医院对诊断明确、经过治疗病情稳定转入恢复期的病人，确认适宜者，将重新让患者返回所在辖区社区卫生289、机构进行继续康复治疗，不占用上级医疗机构的资源。形成“小病在社区、大病进医院、康复回社区”的就医新格局，达到医疗资源的合理利用目标。下级医院将超出本院诊治范围的患者或在本院确诊、治疗有困难的患者转至上级医院就诊；反之，上级医院将病情得到控制、情况相对稳定的患者转至下级医院继续治疗、康复。双向转诊信息系统主要功能是实现病人在医疗机构（包括医院、社区卫生服务中心、诊所）之间实现转诊业务，实现病人的门诊病历、住院医嘱、住院病历和病案等信息共享。5.4.1.1 转诊申请提供转诊申请模块以供各医疗机构嵌入在医生工作站中，实现转诊申请单的填写和提交，选择需要转诊的医疗机构进行转诊，由基层医疗机构发起向上级290、机构的转诊为上转，由市级医院发起向基层医疗机构的转诊为下转。填写转诊申请单的内容包含转诊医疗机构名称，初步诊断，转诊原因，预约时间，填写完成的申请单连同转诊患者的转出医院的相关电子病历信息一同，通过患者健康信息综合管理平台提交到相应的上级医院。5.4.1.2 上转审核转诊单提交由被申请单位进行审核，转诊审核由市级医院的医生登录到转诊系统进行操作，主要功能是对提交的转诊申请单进行审核，根据接诊医生排班情况（转门诊）或科室病床情况（转住院）予以确认转诊时间。系统根据转诊的科室进行分类显示，并提供批量审核的功能。审核完成后，反馈回执。对于未通过审核的申请单进行说明和建议。5.4.1.3 转诊执行患者291、凭回执单号直接到；转入医院的预约中心进行确认和接收。医生开始根据系统的提示将患者引导至相应的门诊或住院接诊。5.4.1.4 下转确认下转确认主要是对上级医疗机构的转出申请的接收处理。在居民转回到社区卫生服务机构时，医生能够通过获取其在上级医院的电子病历信息，以便提供更有针对性和科学性的康复服务。对于上级医院转出的申请单，还需填写结论信息。5.4.1.5 转诊查询实现对双向转诊的主题性分析，对单位及科室按日、月、年方式统计报表，对个人按月、年方式统计报表；支持图形化展示，支持查询、打印和导出报表数据。5.4.1.6 与外部系统接口转诊申请的卫生信息系统将患者在医院期间进行的门诊、住院、检验、检查292、等诊疗数据上传到区域平台以供接收医院调阅；当患者在（转诊）接收医院完成就医后，相关的诊疗记录信息上传到区域平台，让提出转诊申请的医疗卫生机构调阅。5.4.2 区域PACS系统5.4.2.1 与医院HIS及EHR系统的整合区域影像数据交换系统与HIS及EHR系统的整合是影像检查流程实现无纸化管理的重要基础。两套系统之间的连接效果直接影响医院的工作效率。因此，在系统整合过程中需要系统之间共同合作、共同协商，制定统一的接口标准，以保证两个系统的连接是合理的、高效的。并且，随着医院管理的日益提高，影像系统、HIS系统、EHR系统，以及系统的接口方案都应随医院的要求而不断改进、优化，与时俱进。影像/HI293、S/EHR的整合，同样遵循以DICOM、HL7等国际标准为基础，利用IHE定义的技术框架，根据本公司的在众多类似项目实施经验，结合医院的实际情况，实现与医院HIS、EHR的协同运行。接口原则均以符合HL7及IHE要求进行HIS、EHR整合，特别在IHE 影像与报告的WorkFlow（SWF/RWF）上，可以完整地与HIS、EHR进行整合。但考虑到部份情况，因此也提供其它整合方式。HL7/IHE以外的整合与HIS整合的内容与方法如下表所示：整合项目使用标准备注申请单下传数据库连结；Remote Server Call；Windows File Sharing；FTP当HIS新增患者检查数据时，由294、中间程序将记录直接下载到数据库，或透过Remote Server Call下载到数据库，或是透过文件共享、FTP方式取得数据。退费下传数据库连结当HIS针对患者检查单退费时，由中间程序将记录直接下载到数据库，注销原来的检查数据。预约下传数据库连结；Remote Server Call当HIS新增患者预约数据时，由中间程序将记录直接下载到数据库，或透过Remote Server Call方式，将记录下载到数据库。预约取消下传数据库连结当HIS取消患者预约数据时，由中间程序将记录直接下载到数据库，注销原来的预约数据。划价下传数据库连结当HIS完成患者检查单划价时，由中间程序将记录直接下载到数据库。295、报到上传数据库连结当PACS/MIIS完成患者报到程序时，由中间程序将记录直接写入HIS数据库。报到取消上传数据库连结当PACS/MIIS取消患者报到程序时，由中间程序将记录直接写入HIS数据库，注销原来的报到数据。预约确认上传数据库连结当PACS/MIIS确认患者预约检查单时，由中间程序将记录直接写入HIS数据库。预约确认取消上传数据库连结当PACS/MIIS取消患者预约检查数据时，由中间程序将记录直接写入HIS数据库，注销原来的排程数据。检查项目修正上传数据库连结当PACS/MIIS修改患者检查单的检查项目时，由中间程序将记录直接写入HIS数据库，修正原来检查单上的检查项目。检查报告上传数296、据库连结；Remote Server Call由中间程序将报告直接写入HIS数据库，或透过Remote Server Call方式，将报告写入数据库。患者基本资料下传数据库连结；Remote Server Call当HIS新增患者基本数据时，由中间程序将记录直接下载至数据库，或透过Remote Server Call下载至数据库。未知患者改挂/合并数据库连结当HIS要将患者的临时病历号改为正式号时，或是要将重复挂号的患者前后病历号码合并成一笔时，HIS提供交易数据，由中间程序下载至数据库，修正数据。使用者账号异动数据库连结当HIS的使用者账号名称或密码改动，HIS提供交易数据，由中间程序下载至297、数据库，修正数据。诊间调片执行命令行参数；TCP/IP信息交换诊间HIS计算机按下快捷键，透过TCP/IP信息交换，自动启动该诊间计算机的PACS Viewer，并取回该患者的影像显示在屏幕上。病房护士站调片数据库连结病房护理站的使用者点选某一护理站，程序向HIS取得该护理站的病床信息，显示在屏幕上，再由使用者选取某病床，自动启动Viewer，取回该患者的影像显示在屏幕上。接口标准实现与影像检查互联的科室内、全院的基础信息、检查科室的门诊收费审核、门诊住院医嘱费用确认、门诊住院检查申请、检查预约结果、检查报告数据及影像等业务信息和管理信息的整合与共享的标准接口开发，主要包括：l HIS端数据交298、换接口开发(收费记录、基本信息、检查申请)；l 影像系统及其它医技信息系统端数据交换接口(检查预约结果、医嘱费用确认、影像调阅构件、检查报告)；l 影像系统及其它医技信息系统端数据交换接口(医嘱费用确认、影像调阅控件、检查报告)。按照上述的接口标准，在医院现有的信息系统基础上，通过与HIS、EHR的整合，实现业务流程以及管理控制功能的应用整合，具体实现流程如下：图5.4.3.1-1 区域影像工作流程图接收门急诊收费记录；l 审核门急诊收费，实现可执行检查的控制；l 接收门急诊检查申请，并可与预约、登记功能自动连接；l 接收住院检查申请，并可与预约、登记功能自动连接；l 预约结果返回住院医生工作299、站、护士工作站提供检查预约查询；l 处理已完成的门诊住院申请的检查的费用确认，并将结果返回住院医嘱处理系统、门诊收费系统，以便控制门诊退费、住院计费；l 将检查结果报告数据返回门急诊、住院医生工作站、住院护士工作站、门诊服务台系统，以供这些系统调阅，并提供报告的基本查询功能；l 将检查结果影像图片返回门急诊、住院医生工作站，以供这些系统调阅，并提供图像的基本查询、浏览、处理功能；l 检查科室间可以互相调阅影像图片片源、检查报告；l 医生可以根据病人唯一的编号调阅该病人以往的各类影像资料。5.4.2.2 与数据中心健康档案平台的整合XX市区域影像交换系统将涉及到与数据中心基于健康档案的区域卫生系300、统进行数据交互与信息的统一发布。为此，需要建立一个对影像检查事件或报告的登记接口。对于各类医院上传提交的影像类业务的数据，需要影像类业务向非影像类业务提交对影像检查事件或报告的注册（以下称为“登记”），建立一个统一的对患者诊疗事件（或称为“患者诊疗履历”）的登记，便于医院端按照统一的入口调阅患者的诊疗档案。5.4.2.2.1 对影像检查事件的注册流程图5.4.3.2.1-1 影像检查注册流程图中心索引库的注册接口只对影像业务中心库开放。5.4.2.2.2 对影像检查事件的注册方式设置影像注册表。该数据表放置在健康档案业务的数据库中，健康档案业务提供存储过程作为接口供影像业务调用，以便在此表内注301、册数据。5.4.2.3 医院PACS/RIS系统部署遵循标准规范对于医学影像诊断报告主要包括放射学影像（X光、CT、MR、超声等）诊断、病理图像及核医学影像诊断报告组成，在国际上这些报告都是以HL7.2.5（ORU信息）或HL7.3.0 CDA文件格式进行传输交换。我国医疗信息标准化发展迟缓，至今未能形成统一的影像诊断报告交换格式（RISHIS或HISHIS）。而国内各医院使用不同厂商提供的RIS、HIS及PACS进行临床诊断与报告书写，因此对这些诊断报告的共享交换造成很大障碍。国际上对不同影像诊断报告一般采用不同专业编码进行分类，如放射学以ACR（American College of Ra302、diology）Code编码对部位和诊断结论进行分类；而病理科一般采用SNOMED进行分类编码。现在各国政府（欧洲、美国及南韩和日本等国）在进行由政府牵头成立区域健康信息组织（RHIO）建设电子健康记录系统（Electronic Healthcare Record，简称EHR）。而国际集成医疗健康企业（Integrating the Healthcare Enterprise，简称IHE）组织依据当今各国家发展EHR所涉及的不同医疗机构（医院或医疗服务提供者）共享交换同一病人在不同医疗机构的各种病历信息，分别颁布了医疗文档（以文本为主）共享技术架构规范IHE XDS（Cross-Enterpr303、ise Document Sharing）和医疗影像信息（图像和相应的诊断报告）共享技术架构规范IHE XDS-I（Cross-Enterprise Document Sharing for Images）。这些医疗共享交换技术规范除继续使用DICOM、HL7（V.2.5，V.3.0）等医疗信息标准外，还引入电子商务全球化标准ebXML（国际OASIS制定技术规范）作为跨医疗机构共享交换通信标准。对医院PACS/RIS的功能要求广东省卫健委发布的医学影像管理软件功能规范文件在政府网站上可以下载。该文件对医院的PACS/RIS的功能提出了概要要求，本方案书不对其中的内容予以重复。对医院新部署PA304、CS/RIS的考虑由于本市的医院PACS/RIS系统已经由若干家厂商实施，如要实施对尚未建立PACS/RIS系统的医院根据需要新增部署时，建议考虑提出以下要求：n 采用分布存储、分级管理、集中服务等存储管理机制；将医院层面应用和科室应用有机结合。n PACS/RIS各个系统要求完全遵循目前国际通用的DICOM3.0标准和IHE流程规范，整个系统具有高安全性、高可靠性、较高的兼容性和可持续扩展性，便于与第三方产品的互联和通讯。n 图像调阅速度，应以最大容量的 CR/DR图像为准， 5秒以内即可查询，并研究提供可以缩短临床科查询速度的方案。n PACS/RIS系统是为一体化设计，全中文系统。n 应305、全面实现与当前医院内HIS的连接，能够与HIS系统的医生工作站无缝整合（HIS厂商与PACS/RIS厂商均按照国际标准或在医院同意的情况下协商接口方式）。n PACS应确保充分的经济性，在满足应用设计要求及未来5年内医院发展规划的情况下，提供最佳安全方案及性价比。n 构建PACS/RIS网络时，维护当前的网络环境，确保医院的HIS系统与PACS/RIS之间不发生任何冲突并可高效实现信息相互传递和资源共享。n 要求与区域影像系统交换数据，能够按系统影像类业务对医院的流程要求，采集、提交、下载展示图像数据。并可实施持续性的变更维护。对原医院PACS/RIS的适应性修改要求由于本项目建立的对影像图像306、文件的传输交换是跨医院的，为此，需要对于这些业务中的有关流程发生调整，依据DICOM标准规范要求，各医院使用的PACS系统都应提供DICOM以下基本通信接口或服务：n DICOM Storage SCU/SCP（C-Store SCU/SCP）；n DICOM Storage Commit SCU（N-Action/N-Event SCU）；n DICOM Query/Retrieval（PatientRoot）SCP（C-Find/C-Move SCP）；n DICOM Query/Retrieval（StudyRoot）SCP（C-Find/C-Move SCP）。在上述基础上，需要产品供307、应商进行相关业务的适应性更改或追加。（1） 与HIS的相关功能相结合，按照协议的接口方式和内容，增加定时提交患者医学影像检查报告和影像图像文件的功能。（2） 按照协议的接口方式和内容，增加向系统前置机发送请求调阅患者影像类资料的功能。（3） 增加在医生工作站前端提示可对患者从系统发送调阅影像类资料需求的功能。（4） 按照协议的接口方式和内容，增加展示患者从其他医院调阅的影像类诊疗资料的功能。（5） 根据医院的需求，增加将展示的影像类诊疗资料下载本地医院PACS保存，下载本工作站保存的功能。5.4.2.4 影像文件共享交换系统与医院PACS接口实施方式本项目使用IHE XDS-I架构接口方式实施308、交换系统与医院PACS的接口共享交换、图像备份、远程助诊等应用（Applications）各种DICOM通信服务，ebXML通信（查询/提取），发布/注册服务，通用服务Common Services医疗字典分类服务，安区监控服务等DICOMDIMSE、IHE Transactions，SOAP消息消息通信总线（Message Bus）PACS/MIIS/CISPACS/MIIS/CISPACS/MIIS/CIS图像数据源系统/单元医院1医院2医院n1、图像数据源系统/单元；包含提供共享交换影像文件（信息）各医院的PACS/MIIS，影像设备，或多媒体电子病历存储系统。2、消息通信总线（Mess309、age Bus）：主要指用于对DICOM DIMSE（DICOM Information Message Service Elements）消息、IHE技术框架文件定义的各种事件处理（Transactions）消息、及ebXML所用的SOAP(Small Object Access Protocol)消息通信总线。3、通用服务（Common Services）：包括常用各种DICOM通信服务（C-Store SCU/SCP、C-Move SCU/SCP、C-Find SCU/SCP等），ebXML提交发布（Submitting）、（Registration）、查询（Query）、提取（Retr310、ieval）服务，及IHE事件处理（Transactions）服务等。4、应用（Applications）：支持图像共享交换、备份、远程助诊等。各系统单元功能如下：1、病人基本信息跨医院主索引（PIX）：主要提供对共享注册的病人信息进行验证、唯一性确认，和对病人在不同医院的识别号通过某种机制进行关联。它的注册输入信息包括：病人基本信息（姓名、出生年月日、性别），病人（由医院、医保或社保分配）识别号（Patient ID），病人识别号发放单位（医院、医保或社保）编码Issuer ID。在使用时，输入病人在某医院识别号（Patient ID）和该医院编码Issuer ID，则返回病人全局唯一识别号311、（Global Patient UID）。该系统（PIX）将由XXX制订需求，影像类业务及非影像类业务承建商共同完成。2、影像信息注册中心（XDS -I Registry ）系统：主要对共享交换的影像文件（信息资料）的元数据（Meta Data）进行中心注册发布管理，为用户提供影像信息查询服务。它主要以ebXML RIM( Registry Information Model )为信息模型管理元数据，而且参照放射影像编码标准（ACR Code）和疾病分类国际标准（ICD -10）对其进行分类，并使用基于这些分类的病人疾病影像文件虚拟文件夹（Virtual Folder，简称：VF）方法对其进行312、管理。3、影像（系列）报表/报告存储池（XDS-I Repository）系统：它主要是将由图像数据源（XDS I Source 或XDS-I Source Agent）提交的DICOM图像系列报( Manifest )或诊断报告及相应的元数据（Meta Data）集进行解析存储，并将元数据转发到影像信息注册中心系统（XDS-I Registry ）进行注册发布。4、影像信息（文件）存储源（XDS-I Source）和其代理节点XDS-I Source Agent：它主要接收各医院需要共享的图像文件系列并产生相应的图像系列报表 (Manifest)和对应的共享发布元数据集（DocEntry M313、eta Data 和Submission Meta Data），将报表和元数据集通过ebXML上传提交到影像（系列）信息报表存储池系统（XDS-I Repository），同时无损压缩暂存（或长期存储）共享图像，并通过DICOM安全通信协议（基于SSL/TLS DICOM 通信）传输到中心备份系统（XDS-I Source M）。用户依据查询到的图像报表可以从相应的XDS-I Source （或Source Agent）中提取存储的图像数据。5、影像信息（文件）使用者（XDS-I Consumer）或其网关（XDS-I Consumer Gateway）：它主要从影像信息注册中心系统（XDS-314、I Registry）中查询（ebXML Query）到病人共享的影像文件注册索引信息，并从影像（系列）信息报表存储池系统（XDS-I Repository）中提取到相应的图像系列报表（Manifest）文件或诊断报告，并解析报表内容（提取图像系列UID及存放地点），然后通过DICOM Retrieval （C-Move）或WADO（Web Access DICOM Persistent Object）从影像信息（文件）存储源（XDS-I Source）或其代理节点（XDS-I Source Agent）获取图像。一般放射影像诊断工作站使用DICOM C-Move，而医生工作站使用WADO或基315、于Web的http协议方式提取图像。 各医院PACS应提供以下DICOM通信标准接口和服务：n DICOM Storage SCU/SCP（C-Store SCU/SCP）；n DICOM Storage Commit SCU（N-Action/N-Event SCU）；n DICOM Query/Retrieval（PatientRoot）SCP（C-Find/C-Move SCP）；n DICOM Query/Retrieval（StudyRoot）SCP （C-Find/C-Move SCP）。 各医院PACS应与对应的图像分布存储代理节点系统进行DICOM通信互认确定设置（IP Add316、ress，Port No.，AE）。PACS每天定时（如夜间12点）将需要共享的图像以DICOM Storage 通信方式提交给图像分布存储代理节点系统，并进行DICOM Storage Commit 确认；或允许图像分布存储代理节点系统定时以DICOM Query/Retrieval 方式查询/提取图像。 各医院PACS图像显示工作站和医生（Web）图像浏览工作站应与图像查询/提取网关进行DICOM通信互认确定设置（IP Address，Port No.，AE）。PACS图像显示工作站如果支持DICOM通讯，则不需要增加软件模块。医生（Web）图像浏览工作站则可以将控件直接下载到本机中，不需317、要专门进行安装。关于影像检查报告交换共享设计方案对于影像检查报告的交换共享，由于其内容容量大小有限，可以按照检查文字报告方式进行集中管理，按照非影像类业务的流程方式和接口提供各医院调阅。国际IHE （Integrating Healthcare Enterprise）组织2005年所公布的针对医学图像和诊断报告共享交换文件（Cross-Enterprise Document Sharing for Images, 简称XDS-I）提出了对图像和诊断报告进行统一共享交换的技术框架（Technical Framework）技术规范（XDS-I Profile）。因此，从长远的角度，在医院的PACS/RIS形成了一定气候的情况下，可以逐步将影像检查报告纳入此规范。上述技术规范的共享交换信息对象及CDA文档构造如下。XDS Submission Set Meta Data内容界定表：条目内容（属性）可选方式来源共享发布者（医院、医生等）必须图像发布者角色（内科、放射科等）必须图像文档（图像）病理分类属性必须ACR Code，ICD-10私密性必须PACS/RIS产生时间必须图像事件类型（CT或MR扫描）必须图像图像（文档）格式必