1、智慧医院信息管理系统方案建议书目录第1章 平台技术方案31.1 软件系统方案31.2 系统架构291.3 系统功能结构分析及系统功能结构图341.4 系统业务流程分析及系统流程图371.5 组件设计501.6 数据模型601.7 安全机制791.8 部署与负载831.9 技术架构861.10 关键技术931.11 软件技术标准及规范1071.12 国内医院信息化建设状况及发展趋势1101.13 项目需求分析113第2章 售后服务内容及措施1162.1 免费维护期1162.2 维护费用1162.3 系统维护与技术支持方法1162.4 我公司服务体系概述117第3章 培训计划1213.1 系统培训2、1213.2 培训地点与环境1213.3 培训材料与手册1213.4 培训计划1213.5 培训课程分解1213.6 应用程序培训(针对各系统具体操作员)122第4章 实施方案与计划1234.1 实施总体规划1234.2 项目实施组织1294.3 软件测试与试运行1294.4 管理体系1324.5 项目过程控制方案1414.6 沟通管理1554.7 需求管理1624.8 质量管理1734.9 风险管理217第1章 平台技术方案 1.1 软件系统方案1.1.1 项目背景本项目要求在遵循卫生部及山东省卫生厅相关规范和标准的前提下，围绕电子病历全面建设临床信息系统、医学影像传输与存储系统、检验信息系3、统、体检系统、电子病历管理系统、医院智能决策支持系统、医疗行为监管系统等，改善医院就医环境，保障医疗质量，控制医疗费用，提高服务和管理水平；推进医院信息系统的互联互通和数据共享，并为实现医疗信息区域共享、远程医疗、双向转诊打下基础。实现建立以电子病历为中心的信息系统，医院信息化要求以电子病历为核心，围绕与电子病历相关的医疗业务和管理业务，促进信息资源在临床医疗和运营管理中的高效利用，在医院内不同业务系统之间实现统一集成、资源整合和高效运转，以及在区域范围支持实现以患者为中心的跨机构医疗信息共享和业务协同服务，要求建立以患者电子病历的信息采集、存储和集中管理为基础，连接临床信息系统和管理信息系统4、的医院信息平台。基于电子病历的医院信息平台建设，有利于提高医疗服务质量和效率、预防和减少医疗差错、控制和降低医疗费用，缓解“看病难，看病贵”问题。1.1.2 需求分析指导思想及基本原则中共中央国务院关于深化医药卫生体制改革的意见、“2010年全国卫生工作会议工作报告，坚持以人为本、以病人为中心的理念，依托现代科技及计算机信息处理技术，为广大患者及医院临床、管理提供全方位的信息服务。医院信息系统建设是一项复杂的系统工程，具有工程实施周期长，各类业务流程关联度高，新业务需求频繁，技术更新周期短，相关技术标准持续扩充等特点，必须坚持整体设计、系统集成、分步实施、突出重点、使用高效的原则，将实用性与前5、瞻性相结合，以相关国际、国家、行业为标准为基础，开发实用、先进、可扩充的信息系统。总体目标和主要任务我们将医院的建设目标定位为：严格按照卫生部关于医院能力建设技术方案标准对中心机房、HIS建设，逐步布署PACS、建立信息平台，在规定的时间内达到符合乃至高于二级甲等医院信息化建设水平。1 医院服务、业务、管理流程全部数字化；2 流程参与对象的数字化表达；3 引进以新一代电子病历为核心的临床信息系统，如影像归档传输系统、实验室信息系统、手术麻醉信息系统等等；4 通过建立全成本核算平台和绩效考核模型，实现医院数字化经营管理；5 通过医院信息平台，实现医院内部各系统、医保、新农合、各类合作医疗的数据交6、互，与区域平台、居民健康档案的数据共享。建立患者身份识别、医院各类业务角色及员工、临床业务等主索引数据库，实现单点登入平台和医患沟通门户系统；1.1.3 可行性分析1.建设现状医疗卫生行业是知识密集型行业。医疗过程专业性强，是一种知识型劳动，对信息和处理工具的需求具有专业化、知识化和智能化的特点。医学科学的复杂性和多变性决定了医疗信息化的实施难度比其他行业更加困难，无论是技术、管理、信息标准等问题都非常棘手，同时医疗和社保的互联互通涉及多个部门，是个系统问题，需要多方协调。同时，医院现有的业务流程很难改变，一方面积习难改，另一方面对医院的影响巨大，属于结构性的调整。随着医疗市场的发展，为了应对7、日益激烈的市场竞争，医院开始从管理为中心逐步转向以病人为中心。越来越多的医院开始专注于改善医院的医疗服务质量、提高医护质量、提高医学治疗的效率和水平，方便病人就诊，同时加强医院内部管理，提高效率，降低成本，以提高医院竞争力。在这样背景下我国掀起了的数字化医院建设热潮。医院数字化是目前国家卫生信息化的重点之一,也是国内医院现代化建设新兴的热点。数字化医院依靠现代化的医疗技术和信息技术改进医疗服务质量、医院管理水平、业务运作效率的面向目标的远景。实现数字化医院的驱动力源于医院持续提高医疗服务质量、改善医院的运营绩效的业务需求和管理需求，以达到提高服务质效、改进管理、增加市场份额、降低医院运行成本、8、医疗服务成本和增加现金节余的目标。2.建设过程中存在的问题在信息化建设中，由于受经验不足，技术更新，医疗政策调整，经营环境变化等因素的影响，容易出现一下问题：l 缺少总体规划和统一标准，各子系统采用了不同厂商的产品，容易出现“信息孤岛”问题。l 医院决策者、科室和患者对医院管理、业务和服务提出了更新更高的需求，对原系统的扩展能力提出了新的挑战，针对原系统的更新改造，可能会带来原系统资源无法再利用等问题。l 外部环境的改变，如医院与医保管理部门、卫生主管部门之间的协同及数据交换越来越频繁，对原系统的适应性也提出了挑战。l 软件公司由于技术、经济等原因，缺乏可持续发展的能力，可能无法为医院提供长期9、有效的技术支持，导致医院难以完成后续的信息化建设需求，影响医院的发展。3政策要求当前，世界已进入信息时代，信息技术的发展，不仅提高了人们的工作和生活效率，也改变了人们的生产和生活方式。在2006-2020年国家信息化发展战略中，党中央、国务院将信息化工作提升到我国现代化建设全局的战略高度，明确提出信息化是全面建设小康社会、构建社会主义和谐社会和建设创新型国家的迫切需要和必然选择。在卫生领域则要求统筹规划电子病历应用发展，促进医疗、医药和医保机构的信息共享和业务协同，满足医疗体制改革的要求。新出台的中共中央国务院关于深化医药卫生体制改革的意见（中发号）明确要求：“建立实用共享的医药卫生信息系统，10、以医院管理和电子病历为重点，推进医院信息化建设，积极推广“一卡通”。”随着社会的进步和人类的发展，现代化建设是医院建设的总体方向，而医院信息化建设是医院现代化的必经之路。计算机化的医院信息系统是建设现代化医院的必不可少的基础设施和十分重要的技术支撑平台。最近卫生部出台的关于改进公立医院服务管理方便群众看病就医的若干意见则明确要求各级卫生行政部门和医疗机构：“坚持“以病人为中心”，三级医院与社区卫生服务机构和基层医院建立分工协作关系，做好医院向社区卫生服务机构以及医院间的预约转诊服务。加快医院信息化建设，合理配置和利用医疗资源，逐一解决影响缩短平均住院日的各个瓶颈环节，减少患者预约检查、院内会诊11、检查结果等方面的等候时间。利用现代电子信息技术，逐步建立病理远程诊断和会诊系统，逐步解决县医院病理诊断问题，保障重大疾病规范化诊疗的基础质量。”国务院医药卫生体制五项重点改革2010年度主要工作安排要求：建立公立医院与城乡基层医疗卫生机构的分工协作机制，加强人员培训交流和业务指导，探索建立社区首诊、双向转诊等分级诊疗制度。4. 医院信息化发展趋势医疗界目前正面临着一个前所未有的变革时期，能否适应和对正在发生的变革做出主动和快速的反应，对每个医院将来的生存和发展至关重要。目前，规划决策社区化、管理职能分离化、信息管理自动化、管理手段法制化、管理人员职业化成为医院管理发展趋势。因此，把先进的信息12、技术应用到医院的营运和管理已成为国际医疗界的一个必然发展趋势，主要表现在以下几个方面：l 信息化重心开始转向临床为核心，以病人为中心。l 更多医院开始尝试医院管理和电子病历的应用。l 医院信息化向集成化发展，在医院内部实现各子系统间的信息集成、共享，同时与疫病上报、银行、医保等外部系统间的集成，实现病人信息的快速传输和共享。l 无线医疗开始在医院中应用。l 医院信息化开始更关注信息安全问题，医院信息系统的高可靠性、高稳定性和安全性是头等大事，需要做好防病毒，容灾备份工作。l 医院信息化开始向区域化发展。l 医院信息化发展趋向于标准化，比如现在正使用的HL7,DICOM3,ICD-10等。1.113、.4 设计原则 1. 先进性原则在技术上采用业界先进、成熟的软件开发技术，面向对象的设计方法，可视化的、面向对象的开发工具。采用先进的J2EE跨平台的B/S多层架构及微软的MTS架构，确保数据存储、事物处理、用户界面等层次的独立性和强大的集成功能，通过RFID、条码、无线等技术提高医疗服务质量和效率。选用代表发展方向并领先3-5年主流硬件设备，使整个系统达到当今的先进水平，并有较长的生命周期。2.面向用户原则医院信息系统功能满足用户的要求是开发工作的出发点和归宿。在成熟的产品上提供客户化定制方法及工具以满足业务特点。相关应用遵循统一的应用架构原则，以确保整体运行效率与成本。注重网络的应用和服务14、功能。3.信息安全原则系统一旦应用，其可靠性及安全性至关重要。软件方面必须有备用系统及应急系统。在系统功能上要保证病人医疗信息的私有性，通过诸如防火墙、门户管理、数据加密、IP过滤、加密信道等方式确保系统的物理安全、运行安全、信息安全。并能有效地保护、管理和控制网络的各种资源，有较强地容错和故障恢复能力，有较强地防泄密、防病毒、防雷击等防范措施。对于外部接口也必须采用严格的权限控制，防止篡改和破坏。4.可扩展性原则医院和社区自身条件及其外界环境是不断发展变化的。产品从应用到设计不能只满足已知需求的处理能力和性能，应该尽可能不受限制的考虑扩展处理能力，尤其是要考虑与合作业务的关系，延伸业务生命周15、期。采用开放式体系架构，使系统具备较强的动态适应性。硬件采用开放式、标准化结构，符合规范，易于扩充。选择互换性强、兼容性好的网络设备，以便在增加、减少或更换设备时，不会带来任何破坏性或高昂的代价。5.规划性原则医院信息化建设是一个动态的进程，是一个比较复杂的系统工程，不可能一上马就达到国际水平，更不可能一步到位。因此，在方案中体现了系统建设与医院当前业务及未来业务的协调同步，应考虑到医院的近期、中期及长期的发展。具有统一规划、分步实施、不断完善、逐步升级的能力。在现有投资条件下，合理安排，实事求是，量力而行，在先进、实用的前提下，使有限投资尽快产生最大效益。6 一体化集成原则围绕医院信息化建设16、的总体目标，汲取各家所长，为我所用。医院信息化建设是一个复杂的系统工程，通常依靠一家IT公司很难顺利完成，必须把多家各有特色的产品和功能集成在一起。摒弃传统的点对点集成方式，采用最为先进的集成平台（EAI）技术来实现不同系统之间的数据共享与互操作，消除“信息孤岛”。7 标准化原则对于标准化采用引用和开发相结合的原则，关注国际信息化标准化的发展，等同等效应用国际标准如：HL7、CDA、IHE、DICOM等，遵循各种卫生行业标准如：中国医院信息系统数据集，病历书写基本规范等，支持统一的计算机技术和网络互联标准如XML、WEBSERVICE、JMS等。通过使用标准的语义和编码，支持规范的医疗信息分类17、和语义理解，如ICD10等。8 电子病历为核心原则以电子病历为核心，整合临床及其辅助系统的医疗应用体系。充分体现“病人为中心”的策略，支持面向病人和临床诊疗、优化业务流程，确保病人的医疗信息能够准确、全面、及时的获得及表达。其他应用必须支持以病历为中心的应用架构，建立全院范围的病人主索引管理，保证各类临床信息的关联准确性。1.1.5 建设目标1.整体目标依照2009年中共中央 国务院关于深化医药卫生体制改革的意见中关于加强县级医院能力建设的要求，以及卫生部2010年县医院能力建设项目信息化建设技术方案、基于电子病历的医院信息平台建设技术解决方案（1.0版）、陈竺部长在2011年全国卫生工作会议18、上的工作报告：奋发努力，开创卫生事业科学发展新局面文件精神，以及山东省卫生信息系统“服务民生、统一规划、集成开发、共建共用”的建设思路，在遵循山东省省市两级卫生信息交换平台相关规范和标准的前提下，围绕电子病历全面建设临床信息系统、医学影像传输与存储系统、检验信息系统、体检系统、电子病历管理系统、医院智能决策支持系统、医疗行为监管系统等，改善医院就医环境，保障医疗质量，控制医疗费用，提高服务和管理水平；推进医院信息系统的互联互通和数据共享，并为实现医疗信息区域共享、远程医疗、双向转诊打下基础。2.医院预期管理目标：2.1提高效率，优化就医流程通过对原有管理模式的改革重组和流程优化和再造，在使医院19、的管理模式变革为计算机网络管理模式之外，也使医院各个业务部门都在一种“分工均衡、责任明确、联系加强、效率提高”的良好工作状态下运行。以提高效率，优化就医流程。2.2减少医疗差错通过在数字化医院系统中普遍使用各种经过权威认证的第三方知识库系统，在线实时提示医生各种信息，以减少各种临床差错发生。作为医院的医疗质量管理部门，通过使用联机的信息系统，也能将其发现的医疗差错及时通知相关医务人员，这样，在医院内部的医疗质量管理就从原来手工操作时期的终末控制变为信息化之后的实时在线监控。2.3提高服务质量使用数字化医院信息系统后，由于加强了物资和库存管理，大大减少了药品、物资的积压和浪费，减少了库存及流动资20、金占用，从而降低了医院成本，节约和充分利用了医院现有资源。另外，通过对“搭车开药”、“人情处方”等进行了有效遏制，院内的“跑冒滴漏”现象绝迹。患者在整个诊疗过程中收费明细清晰，计费准确，提高了医疗收费透明度，使患者对医院服务质量提高更满意。2.4为临床医疗人员提供业务支撑随着信息化的发展，数字化医院信息系统渗透到医院的各个科室和部门。例如：在现代化的医院中，临床检验实验室、医疗技术相关科室（如心电图、病理、胃肠镜）、医学影像科室（如放射科、B超室等）越来越离不开信息系统。LIS（实验室信息管理系统）、PACS（医学影像传输与存储系统）已成为数字化医院信息系统中必不可少的内容。在本项目中，临床信21、息系统在提供给临床医护人员作为日常工具使用之外，还承担着更高级的科研分析功能，通过进行结构化电子病历的检索统计、数字影像的三维重建、临床用药统计及效果分析，临床医护人员能进行基本的科学研究。2.5提高医院核心竞争力实现数字化医院之后，规范了医疗业务行为，优化就诊流程，提高工作效率，缩短患者的就诊时间和治疗时间，通过医疗质量监控，降低医疗差错概率，最终的目的是大大提高医院的管理及诊疗水平，促进医院核心竞争力的提高。2.6方便患者就医和降低医疗费用 实现数字化医院之后，患者可享受到更透明、便利、高效、优质、低廉的医疗服务。患者可在充分了解医院的医疗资源分布情况后及时预约诊疗；通过手机短信发布平台、22、诊疗卡等方式，患者可及时查询到自己的检查检验结果、体检报告结果，方便患者就医。通过数字化医院的建立，医生可以获得过去患者完整的病历，甚至是患者在其他医院的病历及各种检查结果，这样就减少了不必要的重复检查，能有效降低患者费用，同时，医生通过网络调取患者的居民健康档案，充分了解患者过去的健康状况，有利医生诊治。另一方面，随着医学影像存储与传输系统的普遍使用，胶片费等材料费用可以被节省下来，也进一步降低了患者的费用。1.1.6 建设方案11.11.21.311.11.21.31.1.1.1.2.1.3.11.11.21.322.12.22.3系统总体应用框架根据国内医院信息化的现状及发展趋势，结合方23、案设计原则及信息化实现目标。在应用架构上重点考虑总体规划，提供丰富基础信息管理模块，深化扩展医院的临床信息系统、经营管理系统、集成应用及其他服务管理模块。保证医院的信息化的基础管理、临床管理齐头并进，实现国内设计领先、业务领先、架构领先、技术领先的信息系统。整体应用架构主要分为六大部分，以基础管理信息服务为主的HIS管理系统，以医疗信息管理为主线的临床信息系统、以财务核算、成本核算、预算管理为主线的医院经营管理系统、以医疗统计分析和运营评价分析为主线的决策支持系统（部分系统可作为医疗信息系统建设长远规划的一部分），以提供区域医疗信息服务及共享的区域协同医疗系统，以及用于完成各应用系统信息集成的24、集成平台服务。1. HIS（MIS）管理系统HIS管理系统是整个医院信息系统建设的基础。本方案重点考虑其应用的深度与广度。主要包括普遍应用的模块，诸如门诊挂号、门诊收费、分诊、ADT管理、医技计费、住院收费、输液室管理、医嘱收费等管理等子系统，深化物流管理部分主要包括药房、药库、配剂中心、设备、物资、高值耗材、供应室、血库等子系统。扩展辅助管理部分主要包括预约中心、科研教学、医院感染、OA、病人关系管理等。各子系统除了具备自己的业务特点外，同时系统间还有一定的业务逻辑关系。如门诊挂号、收费、门诊药房等模块共同完成了门诊病人从挂号、收费、取药的流程。同时，HIS管理系统为医疗工作提供间接服务，其25、数据的准确性与完整性将直接影响临床信息系统、经营管理系统、决策支持系统应用的质量。2. 临床信息管理系统临床信息系统是以提高医疗质量及医疗工作效率为目的的病人医疗信息采集、存储、处理、传输系统，是为医疗工作提供直接服务。该系统主要分为两大部分，一部分是直接为临床科室医护人员服务的现场临床信息系统，如：门诊医生工作站、住院医生工作站、护理信息系统、移动医护工作站、护理部管理系统、临床路径管理等。另一部分是为辅诊服务的非现场临床信息系统，如：LIS系统、PACS系统、监护系统、病理、内镜、放疗、医学知识库咨询（用药咨询等）、营养膳食等系统。这些CIS系统是建立完整电子病历的基础，是以电子病历应用为26、核心进行构建。通过电子病历系统将这些不同临床信息内容以个人为中心按照分类和事件顺序组织为一个整体，并采用一致的标准（CDA）方式进行结构化存储。3. 经营管理信息系统医院经营管理信息系统是从满足医院经营管理的需要出发，以实现最佳社会效益和经济效益为目标，将医疗经营过程中的一系列经济业务活动集成化设计的综合管理系统。它涵盖了成本核算（科室成本核算、项目成本核算、病种成本核算）、绩效考核、预算与控制、会计核算、薪酬管理、奖金分配等内容。系统将搭建一个多层次的横向联系，纵向相接的管理网络，构建起整个医院的以预算管理为主线、以会计核算为中心、以成本核算为基础、以医院经营决策为目标、以绩效考核为保障、以27、薪酬管理来体现，将医院的人流、财流、物流和信息流高度集成的综合运营管理平台，其中的大部分收入信息可直接来源于HIS系统。4. 决策支持系统医院决策支持系统是医院信息系统处理的末端环节，主要是从医院信息系统中加工处理出有关医院管理的医、教、研和人、财、物分析决策信息，为各级管理者决策提供管理决策依据。主要分为两大部分，一部分是运营决策支持，包括运营分析评价、运营趋势分析、投资预测、财务分析、合作伙伴策略等子系统。其数据主要来源于HIS和医院经营管理系统。另一部分是医疗决策支持，包括临床知识库、科研支持分析、病案质量分析、医疗统计分析、临床业务分析等子系统。其数据主要来源于HIS和临床管理系统。由28、于基础业务数据量非常庞大，因此通过数据仓库技术对其进行抽取、转换、加载，逐步实现多维分析、动态分析、预定义报表为主的应用，支持医院构建自己的指标体系分析。5. 区域协同医疗系统区域协同医疗信息系统的目的是使辖区内各级医疗机构、社区卫生服务机构构成一个和谐的整体，实现各机构之间信息共享和医疗协作，是医院信息系统的横向联结和向社区医疗服务的纵向延伸。 主要包括病人主索引管理PIX系统、协同医疗服务系统（双向转诊、医技协作）、区域医疗文档共享系统（文档注册、文档调阅）等。在机构内由协同医疗客户端采集相关数据，通过协同医疗服务系统将相关信息上传到区域医疗信息中心。6. 集成平台EAI医院信息系统中的各29、个系统关注于不同的领域，彼此之间又有很多交叉，因此系统必须具备较强的与异构系统的集成能力。建立一个灵活的、具有整合能力的、扩展性良好的医疗集成平台可以有效的解决这一问题，通过EAI实现医疗信息的传递和共享，达到从数据、应用、流程、服务、界面等多层次的完整集成。提供多种适配器来实现各种数据格式的接收与发送，通过平台的集成代理服务实现数据路由、格式转化，映射等功能。通过基础服务功能诸如工作流管理、规则引擎、主索引服务、安全访问等提高系统的灵活性和扩展性。通过术语交互规范（HL7、术语统一、XML）服务等将交互数据进行标准化处理，降低外部系统接口复杂度，通过管理服务对集成过程进行存储和监控。1.1.30、7 总体业务流程及接口逻辑医院信息化的不同应用系统有各自的业务主线及应用特点，但其应用边界并不能准确清晰的定义，因为对于一个医疗业务活动，其产生的信息往往涉及到各个应用系统的不同方面。根据各个系统在病人整个就诊过程中所起的作用，可以看出，各个系统之间不是相互独立的，相互之间在流程及数据上均有一定的关系。主要体现在通过医疗管理系统来产生病人的基本信息、就诊信息、资源信息。而临床管理系统从医疗管理系统中获取这些信息后，就可以对病人进行相应的医疗活动（治疗、手术、护理、检查、检验等），而通过这些医疗活动信息又对应产生了相应的费用信息、药品卫材消耗信息、资源使用信息。通过费用记录信息和消耗信息又产生了31、运营管理所需的数据来源，进而形成运营决策信息。这些信息可以通过信息交换平台进行整合，通过统一的安全管理和标准体系建设来保证各系统应用的独立性和共享信息的准确性。如下图所示：1.1.8 临床信息系统（CIS）产品方案业务需求基于电子病历的临床信息系统不仅仅是对单个医疗业务的简单电子化，而应当是以病人为中心，覆盖医院所有医疗业务的综合性信息系统。基于电子病历的临床信息系统至少需要提供以下三个业务域的基本业务支撑n 门（急）诊业务需求门急诊业务用例图用例需求描述参与角色挂号预约自动生成出诊信息提供窗口、预约、网上等多种方式挂号业务生成门诊就诊记录病人，其他身份登记建立患者的唯一主索引支持多种标识手段32、的模糊查询提供远程预约服务分诊建立、维护候诊队列支持自动和手工分诊支持患者报到与否，支持多医师出诊模式支持语音叫号和大屏幕显示方式书写处方计算机辅助书写药品处方，提供打印处方合理用药咨询及处方审查支持电子处方后续的计价和发药流程申请检查检验录入电子申请，自动传送到医技科室直接预约及查看申请状态及时获取并阅读电子报告申请治疗下达手术申请或治疗通知单查看预约和执行情况体检体检预约体检数据录入体检报告生成，给出健康评估书写病历根据病历规范书写门诊病历自动将患者及医疗信息载入门诊病历支持电子签名及自动留痕实现门诊病历的自动质控知情告知管理知情同意数，保证不可篡改和抵赖管理就诊实现就诊的管理，包括叫号，33、待诊，诊毕等医生直接预约病人复诊执行输液输液皮试结果登记，据此执行处方及发药自动核对输液病人信息和药品信息完整记录输液的全过程书写护理记录书写一般、特殊、手术等护理记录计费n 病区诊疗业务需求用例需求描述参与角色管理入出转入院信息采集、预约登记等管理病区内病人床位，分配医疗组入科、出科、转科操作办理病人的出、转院手续下医嘱书写长期和临时医嘱提供用药咨询，辅助医生合理用药实现医嘱查对制度记录医嘱执行情况提供床边记录操作申请检查检验下达检查检验申请，同门诊申请手术录入手术申请，直接传递到手术室及时查对申请的预约安排情况记录院感实现院内感染的上报和登记提供对出院病人的院感登记质控实现传染卡、死亡卡的34、登记管理查看医疗记录按周查看病人的基本医疗记录（生命体征，病历摘要，各种申请，医嘱记录等）申请用血填写用血申请，传递给血库打印用血申请，实现医护双方签字自动生成对应用血医嘱使用临床路径路径的制定全程记录路径的执行过程支持执行中路径的变化，并提供完整的记录临床路径使用率和治愈率的统计写病历准确及时地书写病历实现各种检查，病人登记信息等的自动载入支持病历电子签名和修改留痕知情告知同门诊重症监护通过设备直接采集病人体征信息提供反应病情变化的各种图表提供诊疗方案和医疗过程控制支持对病情和医疗措施的评价功能生命体征采集人工采集并记录病人体征数据通过监护设备自动采集书写护理记录完整、准确地记录护理操作提供35、各种评估和支持护理计划的制定计费提供当前病人费用信息的详细查询支持欠费管理n 医疗服务支撑业务需求用例需求描述参与角色接收申请接收门诊和住院检查、检验、病历等申请支持条码打印预约登记提供自动预约和手工预约分配反馈预约登记情况支持全院级预约中心业务制作报告自动或手工生成电子报告，支持多媒体提供电子报告的查询，实现全院信息互通采集数据集成各种设备，直接采集数据手术麻醉记录术前提交申请，制定计划术中详细记录，同时提取监护设备数据术后生成麻醉记录单感染监测监测患者体液，自动生成警告，定时提醒通过预测模型量化感染程度，给出风险等级合理用药医嘱和处方审核药品信息查询毒麻药品质控临床决策支持通过电子病历，推36、理出可能的诊断提出医疗、饮食、运动等计划输血管理血库核实申请，完成发血操作管理血制品的入出和质量管理。病案编目对于患者出院病历完成病历进行病案登记、病案编目、疾病、手术编码病案质控按照科室和全院质控规则对病历进行质控检查，实现全生命周期电子病历质控，并且按照三级质控进行病历整改管理，最后按照评分标准进行病历评级。业务框架临床信息系统是整个医院信息系统中非常重要的一个部分。它是相对面向管理的信息系统而言的，指以病人信息的采集、存储、展现、处理为中心，为临床医护人员和医技科室的医疗工作服务的信息系统。临床信息系统主要包括: 医生工作站系统、护理信息系统、检验信息系统（LIS）、放射信息系统（RIS37、）、手术麻醉信息系统、重症监护信息系统、医学图像管理系统（PACS）等等。临床信息系统是一个复杂的企业级联机事务处理系统，涉及业务范围广泛而复杂，由一家供应商/公司提供全部临床信息系统的可能性不大，也就是说临床信息系统可能会是由多个不同供应商提供的子系统集成来满足临床业务的需求临床信息系统的主要目标是支持医院医护人员的临床活动，收集和处理病人的临床医疗信息，丰富和积累临床医学知识，并提供临床咨询、辅助诊疗、辅助临床决策，提高医护人员的工作效率，为病人提供更多、更快、更好的服务接口逻辑n A：从临床支持系统获得病人的影像信息，检查化验信息等，可以浏览报告，也可以实现数据上的直接集成。向临床支持系38、统下达影像检查医嘱（申请），检查/检验医嘱（申请）等信息同时需要向医院的计费系统。临床系统药品和耗材的数量和费用信息传到HIS.n B：从HIS系统获得病人就诊/入院信息。并且向HIS系统传递病人就诊转态，用药处方/检查医嘱/治疗医嘱/护理医嘱/用药记录等信息，所有的病人计费信息由HIS系统完成，可以随时查询HIS的费用信息。n C：将病人临床信息如人口统计学信息、诊断、费用、传递到病人管理系统中，病人客户关系管理系统将全面分析病人信息。n D：决策分析系统将需要从CIS系统抽取决策分析所需的信息，比如各种专家系统，临床路径支持等。1.1.9 管理信息系统（HIS）产品方案业务需求现代化的医院39、管理信息系统，不仅仅是简单的计费系统，而应当是以病人为中心，覆盖医院所有医疗活动和运营活动的综合性信息系统。HIS系统不是一个简单的管理系统，它融合了医院的管理思想、各部门的业务经验，以及对计算机技术的恰当应用。其使用要满足三大方面的需求。n 医院管理需求：解决手工不能解决或难以解决的问题。一方面建立起能够反映医院医疗和经济状况的体系，并使之常规化，另一方面要直接改善医院的管理服务，例如提供医疗数量、质量指标完成情况、医疗动态情况（病人流动情况、床位占用情况）、病人预约、收费管理、无纸化申请、诊疗活动发生地计价等。n 使用者需求：系统直接用户所关心的是功能是否对其业务有直接的支持，操作是否方便40、响应是否及时。因此系统必须具备具体应用、具体业务特点的支持方式。例如：病人主索引登记时、提供自动按设定条件查询，防止重复；病人ADT管理时，提供护士熟悉的病人一览卡；在药库管理时提供自动产生采购计划；医嘱执行时自动产生收费信息等。n 系统维护人员需求：HIS系统作为一个联机事务系统，要求7*24小时不间断运行。象门诊收费等系统，因此绝对不允许发生数据丢失或业务中断，因此必须具备稳定可靠的灾备方法。 业务框架HIS系统内部的业务系统较多，贯彻HIS系统的两条主线是病人信息线和费用信息线。有的局部系统位于一条线上，有的同时位于两条线上。例如：病房、医技科室等同时位于病人信息和费用信息这两条线上。41、n 病人信息线：病人信息的核心是电子病历，而HIS系统则在医疗活动各个环节中提供了病人的主索引标识信息、就诊动态信息。相关系统包括挂号、分诊、入出院登记、病案编目等n 费用信息的核心是经济核算，是在病人诊治活动背后发生的。病人的费用信息分布于各个业务系统中。包括门（急）诊收费、住院病人收费、药品管理、器械管理等。理想的计费模式是哪里发生费用哪里计价。接口逻辑n 接口A：从外部支付系统（医保、保险公司）获得病人支付信用和状态；并且与外部系统进行病人支付结算。n 接口B：将病人就诊信息传送到CIS系统；并从CIS系统中获取病人临床诊断的状态医嘱信息。n 接口C：从临床支持系统获得检查、检验、手术的42、划价信息，并且将收费状态返回临床支持系统n 接口D：将临床活动产生的药品、耗材使用信息传送到物流管理系统，并从物流系统中获取库存、出库信息。n 接口E：将收费产生的会计信息传递到财务系统；并获取财务系统最新的收费标准、收费项目定义。n 接口F：决策支持系统从HIS系统中抽取、汇总、转化分析所需信息。n 接口G：与区域医疗系统共同完成病人的双向转诊、医技协作等功能。1.2 系统架构1.2.1 项目建设重难点分析1.2.2 科学合理的做好总体规划随着IT技术和医疗卫生行业的发展，医院信息系统在建设中如何保护以前的投资和以后的投资，如何保证监测指标、业务流程、业务规则、业务规模变化时，整个系统具备良43、好的适应性，是整个项目建设中面临的重要的问题。当今社会是一个信息量大爆炸的时代，信息化发展日新月异，因此，巴南区人民医院医院信息系统在规划时必须有足够的前瞻性，要保证整个系统架构不仅可以满足当前系统的建设需求，还可以满足未来系统的扩展需求。我公司根据多年信息化建设经验，并结合信息化建设的发展趋势，认为可以归结为两方面的内容：一方面是项目建设的方法论是否是科学先进；另一方面是否在项目初期的规划中考虑到以后的发展。因此在本项目中我们引入面向对象、面向组件、面向服务等软件设计方法，采用分层的方法来规划和设计系统，在每一层次均采用集群技术，确保系统无单点故障并保证系统的可扩展性。同时按照国际业界通用的44、RUP方法进行系统建设，减少项目风险，降低项目实施成本，减少系统维护工作。1.2.3 体现“以病人为中心”的中心思想在病人健康保健、医疗过程中，病人希望得到得到医疗机构对自身健康的全程关注、希望享受良好、便捷的医疗服务、维持可接受的费用和医疗保障。以病人为中心是医疗改革的目标，也是我们系统设计的目标。医疗机构（医院）、医生、政策制定部门（卫生行政部门），都围绕病人为中心进行考虑，为病人提供健康管理、医疗服务、医疗保险服务。从广义的角度看，医院信息系统建设是通过信息的处理过程，协调医疗政策制定部门、医疗机构、医生与病人的服务关系。下图展示了四者之间的关系。图以病人为中心从狭义的角度，与病人医疗服45、务接触最直接的部门是医疗机构。巴南区人民医院医院信息系统设计也就是从医疗机构的角度来为患者提供快捷、安全、公开的医疗服务。以病人为中心的设计思想在本系统中主要考虑医疗价格公开、提高医疗质量、增加医疗服务满意度三个方面来体现。医疗价格公开是为了增加收费透明度，减少不必要的纠纷。图以病人为中心1.2.4 采用先进的系统架构模式多层次的应用体系架构系统应用结构的科学、合理将是系统升级、维护、扩展等方面的关键，是医院信息化可持续发展的关键。采用平台化、模块化的应用体系结构，保证系统的开放性，能够比较容易的实现应用及技术升级；保证系统的高可靠性及易维护性；遵循高实用性的原则，保证当前的业务需求和合理的业46、务扩展。我公司公司采用J2EE、XML、组件等先进应用技术，多层结构设计思路，提供大量的易用的基础组件、提高业务应用的开发效率，降低开发的难度。使用开发工具可以快速地搭建出我们的业务系统，而使用管理控制台使得对各种运行期对系统的维护变得异常的方便。并且在软件的软件可重用性、灵活性、可扩展性等方面提供支持。图多层次的应用体系架构系统在开放性、可重用性、可扩展性、敏捷性、可靠性、安全性的保障医院信息系统是一个对MC性要求非常高的系统，即要求系统具备开放性、可重用性、可扩展性、敏捷性、可靠性、安全性。要使系统具备MC性，系统平台是关键。MC性工程要求系统的任何一个环节都不能出现“单点故障”，即交换机47、防火墙、Web服务器、数据库服务器，每一个环节都要有两个或两个以上实例做集群。这进而要求系统所选择的产品及所开发的应该必须支持集群式部署模式。当然，构筑一个具备MC性的大型系统不是单纯地依靠选择最佳产品就可以完成。MC性系统的建设来源于以下三方面：1. 一系列为业界所公认的，经过大量实践证明是最佳的软硬件产品。2. 对系统理应具备的MC性的全方位解决方案。3. 来自于构筑实绩的经过实际验证的技术。有了上述三方面的积累，即可形成安全稳定的系统构筑平台。构筑平台采用多单元体系结构组织。虽然系统的形态多种多样，但从处理模型角度可以将共同部分分成几个模式。着眼于系统的处理形态，根据模式进行分类得到的48、结果称为系统模型。另外，定义单元作为系统模型的构成要素，单元的组合就构成系统模型。系统模型是通过对成功的系统构筑进行模式区分而积累出来的，在一定程度上能够重复利用。系统开放性、可重用性、可扩展性、敏捷性、可靠性、安全性需要从系统总体架构上全面考虑。1.2.5 患者唯一身份识别目前国内到多数三甲医院的医院信息化建设中存在多个软件系统并存的现象，每个软件系统都有一个患者基本信息库，这就造成系统间患者基本信息不一致，或者重复录入，而且患者基本信息不能永久保存。将病人整个诊疗过程为主线，病人诊疗信息需要在时间、空间上保持连续，具体分析如下所述：1. 在不同时段，病人在院就诊的身份类别可能会发生变化，如49、由自费转变为医保、有单位转变为自费/医保等等类型情况，病人信息可能在此期间发生了变化，相对医院信息化管理角度则出现了病人信息不一致的情况。2. 在院内存在不同厂商的业务系统，应用于不同部门，各个系统中的病人信息也不尽相同，从医院信息化管理角度出现了病人信息在各个系统间不能统一。3. 在集团化医院中，总院、分院、社区等都存在相同病人的就诊资料，但这些资料的属地不同，有些资料（影像资料、病例资料）需要分属地存储。病患是整个业务系统的核心，每一个病患都可以通过一个唯一的病患号和集中管理的病患主数据记录来识别。这个唯一的病患主数据记录集中了所有与该识别号有关的信息，为医院的个性化管理提供了数据基础。150、.2.6 多元化的信息渠道随着信息技术的高速发展，提供了从多种信息技术渠道获取信息的方式。例如PDA、MCA、网站、短信、邮件等。本系统可以采用多种渠道进行业务处理的模式，充分利用这些信息技术渠道，有利于业务更加高效、便捷的开展监察业务。1.3 系统功能结构分析及系统功能结构图医院信息系统必须符合卫生部2002年颁布的医院信息系统基本功能规范、有关国际标准、国家标准、行业标准和软件工程规范。信息分类编码应符合我国法律、法规、规章及有关规定，对已有的国际标准、国家标准、行业标准及卫生部卫生信息标准的数据字典，应采用相应的有关标准，不得自定义。使用允许用户扩充的标准，应严格按照相关标准的编码原则扩51、充。图系统总体功能结构图系统设计应体现“以病人为中心、以医疗信息为主线”的设计思想，采用主流信息技术与方法，真正达到医院信息管理学的要求。最大限度满足实际工作的需要，支持联机事务处理，支持科室信息汇总分析与收支经济核算，支持医院领导对医疗动态与医疗质量的宏观监督与控制，HIS软件以现行医院体系结构、管理方式和管理程序为基准，充分考虑各业务层次、各管理环节数据处理的实用性，支持医院业务流程再造。用户接口和操作界面设计尽可能考虑人体结构特征及视觉特征，界面力求美观大方，操作界面力求简捷实用。满足医院门、急诊信息管理；住院病人信息管理、药品管理、病案管理、财务核算管理；后勤管理、行政管理等实际工作需52、要；综合查询及辅助决策支持等方面实现计算机数字化的需求，做到在全院内信息、数据高度共享、实现医院管理的现代化。系统能随时适应医疗卫生体制改革政策的需要。合理设计与部署数据库系统，深层次的挖掘信息系统内的数据，便于临床医学的管理与研究，提高医院的医疗服务水平。对医疗资源利用情况分析，人群需要估计及分析，提高医院资源的利用率，使医院的收入水平不断提高。建立合理有效的病人就诊流程，简化病人就诊过程，方便病人看病。建立合理有效的医院部门之间的服务流程，简化医院内外信息的传递过程，具备较强的数据接口能力和先进的内容交换方式，避免信息的二次录入，达到数据共享目标，提高医院的工作效率。建立合理有效的医院资源53、控制体系、医疗质量控制体系，支持医疗服务成本的控制与监督。建立标准的医疗诊疗规范，支持电子签名、留痕修改、多级审核等系统与信息安全模式，有效地控制与合理的评估医疗过程质量与服务质量，确保应用安全与数据安全。采用多种方式、媒体、手段为医护人员工作和病人服务提供支持，并能够不断延伸。有效利用医院信息系统数据，提升并有所创新医院的教学、科研和内部培训工作。1.4 系统业务流程分析及系统流程图1.4.1 总体业务流程分析图 Error! No text of specified style in document.1系统总体流程如上图所示，病人在院就诊过程描述如下：病人A到门诊处，挂号，然后就真，如果54、无需住院，则凭处方（有门诊医生站则用电子处方）划价缴费，然后到门诊药房取药或者做检查检验预约。如果需要住院治疗，则从门诊转到住院科室登记并缴纳预交金，再由护士工作站判断进行入科，医生诊疗后下达医院，并由护士通知摆药或进行处方取药、手术检查检验申请、预约，同时计算机进行后台自动计价。预交金不够时，通知缴费。然后由药师进行摆药治疗。病人治愈/死亡/需转科、院时，由医生通知出院，病人凭此到收费处结账，获得同意后到护士站办理出院手续，然后出院。由于医院业务流程复杂，需要根据实际需求进行分析和梳理，为了更好的参与应用软件功能设计，先将医院几个主要流程简要阐述，包括门诊业务流程、住院业务流程、检验业务流程55、和检查业务流程这四大核心医疗业务流程。1.4.2 一卡通服务流程分析以病人门诊就诊为例，在门诊住院部、急救中心、体检中心间病人持卡门诊就医模式，具体处理模式如下图所示：病人持卡就医模式示意图居民健康卡应具备如下功能：1. 发卡：HIS系统记录病人基本信息，在系统中将卡号与病人关联，并实时把病人信息、卡信息记录上传至数据中心。2. 补卡：按病人提供的身份证明，从数据中心实时调出系统中的数据，将病人信息与新卡卡号做关联，并实时把病人信息、卡信息记录上传至数据中心。3. 挂号：按照病人提供的一卡通，如本地HIS没有卡号信息（跨院就诊或首次就诊等），将从数据中心实时调取病人基本信息，将之返回到本地HI56、S系统。4. 就诊：支持病人持一卡通到医生工作站就诊。5. 检验检查：支持病人持一卡通到各类检验检查工作站做登记、就诊。6. 缴费：支持病人持一卡通到收费处缴费。7. 历史就诊记录查询：支持病人持一卡通从数据中心调阅该病人历史就诊信息。1.4.3 门诊业务流程分析传统医院的门诊业务流程烦琐，主要体现在以下几个方面：整个就诊过程为了非诊疗环节，患者来回奔波频繁，做多项检查更是如此；长龙排队等待现象严重;候诊秩序比较混乱，影响医师工作；诊室的隐密性有待加强；意外情况(收款员录入错误，药品无库存，检查时需要加项目等)加重了患者来回奔波和排队的苦恼；未提供预约机制，加重了患者就诊等待时间，“三长一短”57、现象一直比较严重，甚至到院后无法挂到号就诊的患者也比较常见。因此医院医院信息化从建立之初起就需要考虑信息模式下的流程优化问题，通过数字化建设结合医院的实际情况实现对门诊业务流程优化，充分利用资源减少业务压力，达到优化流程，改善秩序，提高质量的目的。根据业务分析，建议运用就诊卡和医保卡优化的业务流程设计如下图：门诊业务流程如上图所示，医院在使用就诊卡建立的“一卡通”业务系统形成了一种全新的门诊就诊流程，通过分诊台分散挂号，各医技科与药房直接支付，取药处设置座位和大屏幕，输液自动打印座位和瓶签，为患者提供各种预约机制，等离子或液晶大屏幕信息公示，设置自助服务机器等措施，这些都减少了患者来回奔波的次58、数和排队等待的时间，减轻了门诊压力，提高了门诊的容量和工作效率，改善了就诊秩序和诊疗环境，提高了医院的服务水平与服务质量，方便了患者就诊，使整个门诊业务流程焕然一新，更加的人性化，智能化。 卡管理窗口：医院将需建立专门的卡管理窗口，该窗口可以是银行设立的窗口，也可是银行授权给医院的业务窗口，主要完成新就诊卡的发放，银行帐户的绑定，取消绑定，银行帐户的建立，存款，取款，挂失，更换等卡管理服务业务。 候诊护士站（护士分诊台）：护士站可刷卡后自动挂号支付后打印候诊小票使患者进入候诊状态，护士站收到挂号信息后运用排队叫号系统负责候诊队伍的调整和呼叫。呼叫可以用计算机接大屏幕显示器和语音呼叫器，进行自动59、的候诊提示和呼叫。 门诊医生诊室：门诊医生站在完成所有诊疗工作后发出诊疗结束信号，通过计算机网络将结束标志传到候诊室，候诊呼叫系统自动消除此患者的显示，同时呼叫下一个患者，诊室的门眉设置一个单行的LED显示正在就诊的病人。就诊完毕后若患者就诊卡有绑定帐户则可直接到药房取药或到医技科室检查检验，若无则必须先到收费处执行收费后再去取药或做检查检验。门急诊的诊室均为“私密性诊室”，即采用“一室、一医、一患、一站（医生工作站）”的诊室；医生可以在诊室查看患者LIS、PACS的报告；同时利用合理用药系统监控医生处方的开立。 门诊药房： 收到网络传来的医生的处方，系统自动打印配药清单，药剂师根据配药单配药60、，配完后标上已配好，系统通过电子候药系统在大屏幕自动上提示患者到窗口取药，患者刷就诊卡扣减银行帐户金额，确认取走药品后，大屏幕自动清除该患者的取药提示。 医技科室：通过大屏幕通知病人的检查顺序，患者刷就诊卡后调出医技单进行检验检查执行，确认后扣减银行帐户金额。检查完毕后由大屏幕通知病人取结果报告，同时结果报告传到各诊间。 挂号收费处：医院的挂号收费窗口主要处理不愿绑定银行帐户患者的挂号与收费业务。预约挂号：患者可通过就诊卡提前预约挂号，预约的方式可采用现场预约，电话预约，手机短信预约，网上预约等多种手段。 信息公示屏幕：在门诊大厅或各楼层，可利用等离子或液晶大屏幕进行专家，诊号情况，健康知识等61、信息的公示和播放。 触摸屏导医: 在门诊大厅或各楼层摄制触摸屏导医台，为患者提供各种信息的自助查询。1.4.4 住院业务流程分析图住院业务流程图如上图所示，医院的住院各种服务将全面数字化，提供床位的预约服务、住院期间一卡通的服务、电子申请单、电子报告及影像资料查询等。医院可设置高技术护士站、病人对讲系统等。所有病人入院后佩带病情检测跟踪器，一旦病情出现问题即自动提示医生、护士。从各种电脑化医疗设备中获取的资料储存在中心化电脑系统中，然后在适当的时间，将信息有效地传输给适当的人，不发生任何延误。由于与互联网相连，将医生的办公系统医院门户集成在一起，医生在办公室里就可通过电子信息将病人收住院，使病62、人省略了在侯诊区等待和医生书写所化的时间，直接进入病房。医生也可采用手持电脑进行查房，开的医嘱会受到自动检查以避免可能存在的配伍禁忌。医生开的各检查单自动传到护工和检查科室，由护工按时护送检查，各个科室的各种检查实现共享不会重复做。检验采用全条码的工作流程，使整个流程更加的顺畅，快捷，更加智能化和自动化。医生运用电子病历系统很少化时间用计算机填表格、写病史和等待检查结果，因而可节省15%的时间，可以看更多的病人。护士不再每天花2至3小时填写图表，全部由计算机系统自动完成。病床带有与互联网相接的显示屏，即可以上网，也可与医生或家人进行视讯交谈。1. 入院登记：可以通过一卡通检索病人的在院基本信息63、，这样患者的门诊就诊信息就可以同住院信息相关联；入院患者的来源可以是门诊、急诊或是其他，门诊的患者可以由医生诊室申请入院，急诊可以由医生诊室或是急诊留观室申请转入；入院类别可以是自费、医保等，支付方式可以现金、银联刷卡等；同时可以为操作员提供病人历史住院信息查询，以便将本次入院记录同以往的在院历史记录关联起来，能够更好地为病人提供医疗服务。2. 住院收费：完成在院病人的欠费管理、退费审核、费用记账、结算及发票打印，其中欠费管理同科室的欠费管理相结合，为管理、监控提供可靠保证；退费控制可以更加完善医院退费处理流程；能够应对特殊情况，如婴儿和产妇，特殊需求病人等。3. 病房护士：完成病房管理，如病64、人的管理，重危、护理级别、转科、请假、交班统计等。医嘱审核与医嘱分解，并实施医嘱后处理如医嘱单、输液卡、瓶签、口服单等；日常费用管理如记账及退费申请；检验条码打印、LIS、PACS的报告查询4. 住院医生：实电子医嘱、电子病历、电子申请、入院申请，进行LIS报告、PACS的报告及影像、历史医嘱的查询，同时合理用药、数字签名等技术的嵌入将提高医疗质量及信息安全。5. 住院药房：完成住院科室日常的摆药、手术摆药、科室常备药等。日常药品管理业务、财务核算等。6. 医技科室：患者进行检验、检查执行，检查完毕后结果报告传到各住院医生站。手术麻醉：由病房医生开出手术申请，然后做手术安排、麻醉安排，手术时根65、据要求做好术前准备，手术结束后做手术登记、手术计费。1.4.5 VIP服务流程分析为了满足医院就诊的特殊人群（一般指医院的VIP客户、特殊人群）的诊疗需要，可以在医院建立特诊服务中心进行就诊。特诊服务对医疗服务有着更高的要求，其意味着更加便捷，更加人性化，更加优质的医疗服务。在数字化建设中，结合特诊业务的实际情况，本着“以人为本”的服务理念，秉承“优质优价”的服务原则，以优雅舒适的环境，先进的医疗设备及技术精湛的医护队伍，提供专家级的、高质量的特殊医疗服务，提供全方位，多层次，高质量、高效率、方便周到的“一条龙”诊疗服务。特诊中心的流程如下:VIP服务流程图如上图所示，VIP业务采用宾馆模式的66、医疗就诊流程和消费模式。前台接待前来的患者进行登记，护士安排患者指定的医生为其诊治，当医生发出的所有医嘱信息(如检验，检查，取药等)都传到护士站由护士代办，患者只需坐在休息室接受各种优质周到的服务，患者出院前自己亲自或由护士代其在结帐处对本次的消费一并结算(可用现金或信用卡)后即可出院。患者可以电话，手机短信的形式与特诊中心预约，且可预约到哪天几点几分前来就诊，需要哪个医生都可选择，特诊中心的各种诊疗资料都以电子的形式存放在网上，授权医生和自己本人都可随时查询。1.4.6 检验业务流程分析LIS是一套高效的管理驱动器，有效的提高实验室样本处理效率和质量水平。系统的独立性和集成性，使其成为HIS67、系统的重要组成部分。其主要功能是将检验的实验仪器传出的检验数据经分析后，生成检验报告，通过网络存储在数据库中，使医生能够方便、及时的看到患者的检验结果，从现在的应用来看，LIS已经成为现代化医院管理中必不可少的一部分。LIS系统完全建立在以“病人为中心，以检验业务处理为基础，以提高环节管理水平为目标”的系统总体设计思想上，通过对医院管理信息化的过程优化医疗与管理流程，促进医院检验科的管理和职能工作管理再进新的阶段。对住院和门诊的检验工作流程描述如下：住院病人的检验工作流程1) 临床科室发出检验申请后，LIS系统可将该病人的历史检验先送来作诊断参考；2) 科室申请预约工作站接收到HIS系统中的申68、请预约信息，对病人进行预约、申请、划价、收费、申请单确认；根据检验项目的类别生成条码（包含病人病历号、医嘱记录号、年月日时分秒）、提示检体容器种类（以各种颜色区别）、采集检体的容量与要求；（同时具备生成打印识别条码方式和识别定制条码方式）；收费按物流节点分段（采样时收容器费用，检验科收样确认后收检验费）3) 临床科室发出检验申请后，系统可将该病人的历史检验报告先送来作诊断参考；4) 科室申请预约工作站接收到HIS系统中的申请预约信息，对病人进行预约、申请、申请单确认；5) 检验工作站收到确认申请单后，无须做任何病人信息输入工作，对病人进行检验数据采集；6) 检验工作站中书写检验报告，在书写报告69、过程中，可获得HIS中病人病历、医嘱、检查结果等信息，供书写报告参考，完成后自动送到临床科室；7) 临床医生在医生工作站中直接查阅LIS报告，无须退出系统；8) 可以记录病人的检查状态（登记、检查、报告），并能随时提供HIS系统调用。门诊病人的检验工作流程。1) 门诊挂号；门诊医生工作站开检验申请单（电子及手写申请单），并能与HIS有机结合；2) 病人通过电子或手写申请单在门诊收费室收费、盖章，影像登记工作站可调阅HIS收费情况；3) 临床科室发出检验申请后，系统可将该病人的历史检验报告先送来作诊断参考；4) 科室申请预约工作站接收到HIS系统中的申请预约信息，对病人进行预约、申请、申请单确认70、；根据检验项目的类别生成条码（包含病人病历号、医嘱记录号、年月日时分秒）、提示检体容器种类（以各种颜色区别）、采集检体的容量与要求；（同时具备生成打印识别条码方式和识别定制条码方式）；收费按物流节点分段（采样时收容器费用，检验科收样确认后收检验费）5) 检验工作站收到确认申请单后，无须做任何病人信息输入工作，对病人进行检验数据采集；6) 检验工作站接收到检验数据后，自动将检验数据送往管理服务器，并根据申请单将检验数据送往该病人所属的存贮设备；对设备提供的原始信息进行保留（包括仪器状态、分析情况的信息等），以备在医疗投诉中提供客观证据7) 检验工作站中书写检验报告，在书写报告过程中，可获得HIS71、中病人病历、医嘱、检查结果等信息，供书写报告参考，完成后自动送到临床科室；在结果审核中提供以往项目的历史结果回顾（常规3次，也可自定义次数，建议多次在本地实现，以免影响网络速度）；对特殊项目检查（如糖耐量试验）具有多次实验结果自动整合并可回顾（多次耐量曲线与正常耐量曲线的比较）；检验结果的可修改（但每次的修改必须记录修改人和时间）；自动校验每一结果是否合理（如回顾比较、是否=0、是否超生理极限等8) 临床医生在医生工作站中直接查阅LIS报告，无须退出系统；9) 可以记录病人的检查状态（登记、检查、报告），并能随时提供HIS系统调用。1.4.7 检查业务流程分析医学图像诊断在现代医疗活动中占有相72、当大的比重。借助可视化技术的不断发展，现代医学已越来越离不开医学影像信息，在临床诊断、医学科研等方面正发挥着极其重要的作用。现代医学影像的快速发展，各种数字化医学影像设备的出现极大地方便了医生的诊断。医学图像信息是多样化的，如B超扫描图像、彩色多普勒超声图像、核磁共振（MRI）图像、CT图像、X线透视图像，各种电子内窥镜图像，显微镜下病理切片图像等。随着医学诊断可视化技术的深入发展，人们正在不断努力，寻求更清晰、更有诊断价值的高质量医学图像。大量医院在过去十多年间，引进了大批进口的先进医学图像设备，对提高诊断水平，加强对医院等级管理起到了积极的作用。由于资金的困扰及仪器设计水平限制，大多数医学73、图像设备都没有考虑图像的储存和传输功能，充其量配置一部打印机或X光胶片作图像记录。医生的诊断是通过对仪器屏幕图像或胶片进行肉眼观察，凭个人的经验所进行分析和诊断，其诊断结论往往主观成分较多。与此同时所产生的大量的影像资料对医院的管理提出了更高的要求。传统的胶片备份、人工管理的方法，需要较大的存储空间，消耗资金和管理人员，而且存在着资料丢失、查找困难、保存时间短等问题。这种方法已经远远不能满足现代化医院迅速增长的业务要求，迫切需要一种自动化的影像管理系统来代替它。传统的胶片备份方式使先进数字医疗设备所生成的数字影像无法长期保存和再现，设备得不到充分的利用。同时，随着社会的发展，医院之间、医生之间74、的交流越快越多。一些疑难杂症经常需要多名专家进行会诊；典型病例是实习和进修医生学习的最佳参考资料；作为病人重要诊断资料的影像检查结果需要共享。正常情况下影像诊断流程如上图所示，对住院和门诊的影像工作流程描述如下：住院病人的影像工作流程。1) 临床科室发出影像检查申请后，PACS系统可将该病人的历史影像、检验先送来作诊断参考；2) 科室申请预约工作站接收到HIS系统中的申请预约信息，对病人进行预约、申请、划价、收费、申请单确认；3) 采集工作站收到确认申请单后，可自动在PACS系统中获得病人的历史影（像），供对照诊断使用；4) 影像采集工作站收到确认申请单后，无须做任何病人信息输入工作，对病人进75、行影像、检验数据采集；5) 对于支持WORKLIST的DICOM设备，可将申请单直接送到影像设备本身，在影像设备中无须做任何病人信息输入工作，直接安排影像采集，采集后的影像自动送往影像工作站；6) 对于不支持WORKLIST的影像设备，需要在设备中输入病人的基本信息，安排影像采集工作，采集后的影像送往该设备的影像工作站； 7) 影像工作站接收到影像后，自动将影像送往影像管理服务器，并根据申请单将影像送往该病人所属各级存贮设备；8) 影像工作站中书写诊断报告，在书写报告过程中，可获得HIS中病人病历、医嘱、检查结果等信息，供书写报告参考，完成后自动送到临床科室；9) 临床医生在医生工作站中直接查76、阅影像、报告，无须退出系统，在HIS系统医生工作站软件系统中直接浏览影像、处理影像、阅读诊断报告等；10) 可以记录病人的检查状态（登记、检查、报告），并能随时提供HIS系统调用。门诊病人的影像工作流程。11) 门诊挂号；门诊医生工作站开检查申请单（电子及手写申请单），并能与HIS有机结合；12) 病人通过电子或手写申请单在门诊收费室收费、盖章，影像登记工作站可调阅HIS收费情况；13) 临床科室发出影像检查申请后，系统可将该病人的历史影像报告先送来作诊断参考；14) 科室申请预约工作站接收到HIS系统中的申请预约信息，对病人进行预约、申请、申请单确认；15) 采集工作站收到确认申请单后，可自77、动在PACS系统中获得病人的历史影像数据，以便对照诊断使用；16) 采集工作站收到确认申请单后，无须做任何病人信息输入工作，对病人进行影像、检验数据采集；17) 对于支持WORKLIST的DICOM设备，可将申请单直接送到影像设备本身，在影像设备中无须做任何病人信息输入工作，直接安排影像采集，采集后的影像自动送往影像工作站；18) 对于不支持WORKLIST的影像设备，需要在设备中输入病人的基本信息，安排影像采集工作，采集后的影像送往该设备的影像工作站；19) 工作站接收到影像后，自动将影像数据送往管理服务器，并根据申请单将影像送往该病人所属的存贮设备；20) 工作站中书写诊断报告，在书写报告78、过程中，可获得HIS中病人病历、医嘱、检查、检验结果等信息，供书写报告参考，完成后自动送到临床科室；门诊医生在医生工作站中直接查阅影像、报告，无须退出系统，在HIS系统医生工作站软件系统中直接浏览影像、阅读诊断报告等。1.5 组件设计1.42.41.5.1 COM+ 组件服务COM组件应用“COM 应用程序”只是个术语，指为了协同工作而开发的多组 COM 组件。在传统的 COM 应用程序中，要安装组件，必须先在注册表中配置各项，这样组件才能够运行。通常用 Regsvr32 实用程序完成这项工作。使用 COM+，当组件配置为 COM+ 应用程序时，可自动执行注册工作，当然COM 组件仍可使用 R79、egsvr32 实用程序在 Windows 2003中注册，并作为“未配置组件”存在于 COM+ 环境中，这些组件运行时，会利用 COM+ 供运行分布式 COM+ 应用程序的基本结构的一部分。 COM+ 应用程序由一个或多个 COM 组件组成。“COM 类”是一个或多个接口的已命名的具体实现。类通过它的“接口”，提供一组称为“方法”的相关功能。“COM 对象”是 COM 类的一个实例。“COM 组件”是可创建 COM 对象的二进制单位代码（包括打包和注册代码）。 COM 类是用 CLSID 标识的（有时也用 ProgID）。接口是规定了一种契约的一组相关功能，它包括名称、接口签名、接口语义及调80、度缓冲格式。接口用 IID 标识。接口语法是在 IDL 和/或类型库中定义的。类的接口应划分为各种可管理的、内聚的方法集。切记，接口是不可改变的，COM 契约规定不可对其加以修改。任何修改（如添加方法）均需定义新接口才能进行。 应用程序编程人员使用 COM+ 编写各种组件，并将其集成在一起，成为应用程序；而系统管理员的任务通常是安装、部署和配置 COM+ 应用程序及其组件。一般情况下，开发人员会将已进行部分配置的 COM+ 应用程序提供给系统管理员。然后，管理员就可以针对一个或多个特殊环境自定义应用程序（例如，通过在应用程序群集的角色和服务器名称中添加用户帐户）。典型的管理任务包括： n 在执81、行管理任务的机器上安装已进行部分配置的 COM+ 应用程序。 n 提供具体环境的属性，例如角色成员和对象池大小。 n 设置 COM+ 应用程序运行的身份（Windows 2000 用户帐户）。 n 重新导出已完全配置好的 COM+ 应用程序。 n 创建应用程序代理（如果将远程访问应用程序的话）。 针对具体环境完全配置好应用程序后，管理员即可将其部署在测试和/或产品机器上。这包括将完整的、已配置的 COM+ 应用程序安装在一台或多台机器中。 下图为C/S/S结构中间件在MTS管理下的部署运转情况。COM+ 安全角色安全角色可模拟并实施 COM+ 应用程序的访问控制规则。角色是指为了确定对应用程序82、资源的访问权限，而为应用程序定义的用户类别。开发人员将角色（符号式用户类别）分配给应用程序，也就潜在地将其分配给了应用程序内的精细结构 - 包括组件、接口、方法或专用应用程序资源。然后，这些角色分配即用于确定哪些用户类别拥有访问应用程序内的哪些元素的权限。 如果应用程序使用基于角色的安全措施，那么每次调用应用程序时，均会检查调用者的角色成员身份。如果调用者不属于对该项目拥有访问权限的角色，调用将会失败。调用者对应用程序或其资源的访问权限，是严格按照调用者所属角色中定义的限制条件授予他们的。 将 Windows 2003 用户帐户和组填充到为应用程序定义的角色中。在执行应用程序的安全规则过程中，83、这是个至关重要的阶段。给用户分配的角色必须正确代表用户可能会通过应用程序访问的数据和资源与用户之间的关系。 将用户填入角色的最好方法是使用 Windows 2003 组。首先，将用户帐户分配给适当的组，然后确保将该组分配给适当的角色。用 Windows 2003 组填充角色，使得更易于管理大量用户。 在企业计算环境中，常常很难有效跟踪每个用户在组织内的职位，也很难确定如何将用户的职位映射到每个应用程序所特有的基于角色的安全规则。随着用户、管理员和应用程序数量的增加，这项任务也变得越来越复杂。最易于扩展的解决方案是将用户组分配给 COM+ 应用程序角色。 可以使用组件服务管理工具，在应用程序安装84、期间初步分配角色，也可以在应用程序使用期间，对角色成员身份进行任何必要的更改。1.5.2 B/S应用服务B/S结构系统应用B/S（Browser/Server）结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，主要事务逻辑在服务器端（Server）实现。以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握、成本也是较低的。它是一次性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式（比如LAN, WAN, Intern85、et/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全 。系统的总体结构分为浏览器端和服务器端。浏览器端提供了一个客户操作界面，服务器端完成具体的请求处理，并将处理结果返回给浏览器端。服务器端内部又分为两层：高层是请求接收层，底层是请求处理层，包括监听线程、处理线程、监测线程和数据库操作线程。浏览器端负责人机交互：n 接收用户的输入，对用户的输入进行分析检查，若输入有错，则在本地消除；若输入没有错误，则把对用户输入的分析结果作为请求传给服务器端高层。n 显示由服务器端高层传来的运行结果。服务器端负责业务逻辑处理：n 请求接收层由于浏览器与服86、务器之间使用标准HTTP协议传输数据，所以在服务器端专设一个请求接收层，用于接收从浏览器传来的请求，并将请求处理结果发送给浏览器。n 请求处理层本层负责处理请求接收层传来的客户请求，并将请求结果传递给请求接收层。处理过程如下：监听线程接收请求的类型，根据请求的类型调用相应的处理线程完成请求处理。将监听线程与处理线程分开的好处是可以充分利用操作系统中的多道处理能力，可以并发甚至并行地处理请求。处理线程首先接收请求接收线程传来的参数，然后进行处理，根据请求的不同性质，可能还需要调用数据库操作线程以完成请求处理，最后将请求处理结果直接返回给请求接收层。监听线程还要负责系统故障处理及恢复。本层使用Ja87、va应用程序(application)构造，用Java线程实现监听线程、处理线程、监测线程和数据库操作线程。servlet与监听线程/处理线程之间使用socket通信，处理线程与数据库操作线程之间使用管理通信。监听线程是主线程，在系统初始化期间，它创建主数据库操作线程和系统管道，以及其它所需资源，并将管道和信号量等资源分配给数据库操作线程，同时创建socket，并在socket上等待连接；在系统运行期间，它负责动态创建处理线程，以及根据并发的请求数量动态创建新的数据库操作线程。处理线程分为不同类型，每种类型负责处理一种或几种相关类型的请求，处理线程的种类数量依据系统功能多寡而定，处理线程完成处88、理后自动终止。监测线程负责监测和撤销新创建的数据库操作线程。应用系统的展现层通过组件方式嵌入到主程序框架中，逻辑层通过对业务的分割形成不同的业务逻辑组件。例如CIS系统组件框架如下图所示：下图为医嘱业务处理的组件示意图：下图为服务器端的应用部署管理界面B/S架构角色管理在B/S架构中，角色的权限验证是保证系统信息安全的关键技术。对所有的系统访问人员分配一定的角色，即一定的访问权限将最大限度地保证系统信息的安全性。Struts是当前Web应用系统开发中最为流行的框架之一，本方案利用Struts框架实现对系统用户角色的验证，通过将JSP页面映射为一个特定的权限，一个系统访问人员映射为一个或多个角色89、，从而实现了角色权限的验证。利用Struts框架实现角色权限验证的同时隐藏了系统的文件组织结构，更好地保证了系统信息的安全性。基于Struts框架的Web系统中，实质上就是在JSP Model2的基础上实现的一个MVC框架。在此框架中，模型由实现业务逻辑的JavaBean或EJB组件构成，控制器由AetionServlet和Action来实现，视图由一组JSP文件构成。在应用中，Action充当用户请求和业务逻辑处理的适配器。业务逻辑由JavaBean或EJB 来完成。当Action-Servlet控制器收到用户请求后，会把请求转发到一个对应的Action实例。如果这个实例不存在，控制器会首先90、创建它，然后调用这个Action实例的execute()方法。Action的execute()方法返回AetionForward对象，它封装了把用户请求再转发给其他Web组件的信息。ActionServlet决定把用户请求转发给Action对象时需要一些描述用户请求路径和Action映射关系的配置信息。系统的运行的流程如下： 首先，服务器根据接受到的客户端请求进行过滤：属于Struts处理范围的请求被自动提交给Struts控制器处理，否则按照一般的方式作出响应。例如用户是进行登录操作的，系统将用户名和密码写入服务器端的session，用于以后的角色权限判断，并通过Struts-config.x91、ml配置文件找到一个预先指定的JavaBean来自动接收客户端请求中包含的表单数据，然后将用户的登录请求发给指定的一个ActionBean进行处理，AetionBean通过调用相应的JavaBean进行处理后，将会返回一个封装了下一目标页面信息的ActionForward对象给控制器AetionServlet。最终ActionServlet根据ActionForward对象信息，查找配置文件中的映射信息，将原客户HTTP请求再次转发到相应的视图JSP页面，最后发送响应回客户端。在系统的配置中，将Action和特定的页面相映射，在数据库的存储中，将Action和特定权限相映射，从而实现了特定页面92、与权限的映射，并将各个不同角色的访问权限进行了设置，最终实现了用户角色对页面访问的权限控制。1.5.3 SOA分析与设计方法针对系统的特点和政策决策的业务目标，采用面向服务技术架构（SOA, Service-Oriented Architecture）分析与设计方法、遵循统一性、抽象性、符合性及业务驱动、可迭代的设计原则完成项目的分析、设计和开发。基于SOA的分析构架技术分析方法与步骤如下：1. 确定业务目标和系统建设目标。2. 了解业务及相关角色。3. 了解实现业务功能的关键业务流程；并根据信息技术要求，提出基于现有业务流程和业务流程的重构思想优化业务流程。4. 确定符合业务目标和系统建设目93、标的业务需求以获得业务功能。5. 将功能实现分解为服务构件，并整合各业务的构件，形成公关服务构件和专用服务构件。6. 进行系统的构架设计。7. 提出或确定系统硬件环境和平台。1.5.4 采用面向对象的技术面向对象方法(Object-Oriented Method)是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，简称OO (Object-Oriented)方法，是建立在“对象”概念基础上的方法学。对象是由数据和容许的操作组成的封装体，与客观实体有直接对应关系，一个对象类定义了具有相似性质的一组对象。而每继承性是对具有层次关系的类的属性和操作进行共享的一种方式。所谓面向对象就是94、基于对象概念，以对象为中心，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。1.5.5 采用组件的技术目前,在软件开发领域，一场新的革命正在悄悄兴起，这是由日趋成熟的组件技术引发的。组件技术将以前所未有的方式提高软件产业的生产效率,这一点已逐步成为软件开发人员的共识。传统的Client/Server结构、群件、中间件等大型软件系统的构成形式,都将在组件的基础上重新构造。组件技术使近二十年来兴起的面向对象技术进入到成熟的实用化阶段。在组件技术的概念模式下,软件系统可以被视为相互协同工作的对象集合,其中每个对象都会提供特定的服务,发出特定的消息,并且以标准形式公布出来,95、以便其他对象了解和调用。组件间的接口通过一种与平台无关的语言IDL(Interface Define Language)来定义,而且是二进制兼容的,使用者可以直接调用执行模块来获得对象提供的服务。基于组件的开发具有如下特点：1. 应用程序由各自独立的组件组成，这些组件的开发和部署保持相对的独立性，而且很可能是由不同的团队开发和部署的；2. 通过仅对这种应用程序的某些组件进行升级，从而对其进行小幅度的升级；3. 组件可以在不同应用系统之间共享，因此可对它们复用，体高系统开发效率和质量；4. 尽管并非与基于组件完全密不可分，但基于组件的应用程序倾向于分布式结构。5. 在系统的建设中，我们抽象出系统96、中基本组件，从而提高系统的质量和开发效率。6. 提供了界面友好的规则引擎，用户可以通过配置规则而方便地改变业务流程。7. 用户可以根据需要按角色组合和配置组件。1.6 数据模型1.12.51.6.1 HL7标准指导下的系统建模Health Level Seven（HL7）是为了达到让不同医疗机构或同一医疗机构中的不同单位的数据得以相互无碍的传输所提出的医疗相关数据的传输标准。目的在提高数据之运用率与加强整合分析应用，藉以提高服务质量，并降低医疗成本。2000年，HL7组织发布了HL7最新的3.0版本标准，与2.x版本的设计方式不同，HL7 v3.0的主体设计采用了从上而下、面向对象的构架。它的97、中枢部分参考信息模型RIM（Reference Information Model）定义了包括100多个类和800多个属性定义，RIM深入定义了涵盖HL7所有数据的各个对象类之间的映射关系。它给出的是一个灵活的HL7结构，而不仅仅是对数据进行详细定义。这些特性使得HL7 3.0能够真正成为可描述的和可测试的医疗信息技术标准。v3版本在模型的方法论上有了质的变化，它不再只是定义消息格式来实现系统之间的信息交换，而且还利用面向对象的方法，将医疗服务中的各种实体和行为进行了高度的抽象，实现了消息交换的语法模型到语义模型的转换。它的RIM模型将医疗服务领域的所见所得抽象成为实体、角色、参与、动作、动作98、关联等五个对象，事实上，这种抽象可以描述医疗服务领域外的其它各种业务，说明这种高度的抽象模型的适用性和高度可扩展性。HL7 V3的主要组成部分包括HL7消息定义、RIM、RMIM、DMIM。RIM过于基础和抽象，本身并无法直接对医疗数据建模有指导意义，真正有价值的是在RIM基础上的，RIM在各个具体Domain上的应用：RMIM（Refined Message Information Model）和DMIM（Domain Message Information Model）。RMIM是一个面向描述的模型，而不是临床信息系统需要的面向业务流程处理的模型，是以性能和业务可实现性为代价换取可扩展性。99、基于以上的理解，为了设计面向业务流程处理的临床数据模型，我们通过转换、简化和扩展三个步骤将RIM中通用域、管理信息域和医疗临床信息域的RMIM和DMIM中有用信息提取出来，从而形成自己的应用系统模型具体工作步骤如下：1.6.2 整体信息模型根据信息化建设的内容，我们可以将各类医疗业务信息和管理信息抽象为如下的信息模型。1.6.3 临床系统信息模型总体架构临床信息系统的整体上是以电子病历为核心，医疗过成中产生的所有文档记录包括申请，报告，执行记录，知情同意，医疗和护理文书等全部被看作是电子病历的一个组成部分。一个病人的电子病历由其历次的就诊记录构成，每一次就诊记录由本次发生的所有医疗和护理文档组100、成，每个文档包括文档头和文档体构成，文档体根据组织格式分为结构化和非结构化的，文档体由不同的片段组成，文档片段则由各种临床描述构成，通过电子病历可以得到病人医疗过程的完整记录。文档头：描述了文档的所属机构，保管者，作者，数据录入者等人员机构信息，同时包括不属于文档体的一些医疗观察等内容文档体：包括各种文档片段临床描述：对病人就诊过程的所有医疗活动进行的描述，不仅包括文字，图象，而且包括多媒体等全部描述资料。 就诊就诊模型描述了病人就诊的基本信息，包括门急诊和住院。就诊信息主要由病人基本信息，就诊信息两部分组成。就诊是整个信息模型的基础，病人在院发生的所有医疗活动都将以此为基础记录，通过就诊记录101、可用直接查找到病人的本次就诊的所有医疗记录内容。病人信息描述了病人的基本信息，包括人口统计学信息，个体标识，危险因素，联系人，邮政及电信地址，在院注册内容等信息。其中个人信息是病人作为一个社会实体的基本信息，病人在院注册信息描述的是病人在本院登记的与就诊相关的信息，一个病人可以产生多次就诊记录。就诊信息描述了病人一次就诊情况，包括就诊场所，接诊医疗人员，转科信息，床位信息，医保及资金账户等内容。与病人信息比较，就诊信息是每次就诊病人在院登记信息。医嘱及临床路径医嘱及临床路径模型描述了医师在医疗活动中下达的医学指令，具体包括两部分内容即医嘱和临床路径。医嘱是医生在医疗活动中直接下达的医学指令,包102、括的内容有完整的医嘱信息，相关的各种申请，医嘱执行记录，医嘱产生的费用等。各与医嘱相关的申请及报告的详细内容不在此模型中描述，在各相关部分详细描述。临床路径是医院的一种遵循询证医学的标准化治疗模式与治疗程序，临床路径的最终执行主要落实到医嘱和其他一些护理记录上。模型中描述的信息主要包括临床路径的组成，应用记录，对应的医嘱等。 用药用药模型主要描述病人就诊中的用药信息，包括用药申请和用药记录两部分内容。用药模型以药品信息为基础，申请和记录都不再存储额外的药品信息内容。用药申请描述医嘱和处方等相关的用药信息，其描述的主要是医生下达的医疗制定涉及药品的部分，下达医疗指令相关的各种临床诊疗结果作为参考103、，同时对于不规则频率的用药也有具体的描述。用药记录描述药品的使用记录，对应为医嘱和处方的执行记录信息。医疗观察医疗观察模型描述临床上可测量的医疗活动，描述其申请和报告结果。具体包括检查检验的申请和报告，还包括诊断、过敏反应等信息。观察申请主要指检查申请和检验申请，其组成部分包括申请需要描述的临床表现，严重程度，参照标准等内容。观察申请通过自身的引用实现观察项目的具体描述，同时对于住院病人观察申请会产生相应的医嘱。检验申请还包括样本内容。观察报告检查检验的报告。观察报告包含了临床表现，严重程度，参考标准等报告需要的具体内容，检验报告还包括样本和使用试剂的内容。观察报告和申请一样通过自身的引用实现104、报告项目的具体描述，观察报告与观察申请存在对照关系。诊断和过敏反应作为一个单独的对象描述了临床诊断和过敏反应的内容，其包括了一些备注信息的描述。 手术及治疗手术治疗描述的试临床上的医疗操作，模型中将医疗操作分为了手术和治疗两部分，由于他们包含的信息项基本一直所以采用相同的模型来描述。手术治疗模型同观察申请一样也包括申请和治疗结果记录两部分。手术治疗申请指医生开出的治疗类申请单，具体内容包括相关的诊断，观察报告，申请人信息，临床诊断，相关材料申请等，申请对象主要记录了操作的部位，方法，时间等。手术治疗申请同昨自身的引用实现申请项目的详细描述。住院病人的手术治疗申请会产生对应的医嘱手术治疗事件描述105、了医疗操作的结果，具体包括执行人，相关的系列结果，附加的医疗观察描述等内容。手术治疗事件通过自身的引用实现各结果间的前后顺序和相互关系，它与手术治疗申请间存在对照关系。 材料供应材料供应模型主要描述了材料的供应情况，这里指的材料包括常用的物资、耗材、血液制品、设备等。供应申请包括的内容主要有相关人员、机构、服务提供场所、材料信息等。供应申请的产生主要来自手术治疗，也包括一些非医疗操作产生的需求。 预约预约模型描述的是在日常的医疗活动中对医院各种资源，包括人、场地、物资、设备的等的预约申请及安排。该模型可以涵盖整个医疗过程的各种医疗活动比如检查项目、检验项目、手术治疗、就诊等等。预约模型的核心在106、于将医疗资源的使用划分成为不同的时间片，然后有制定资源的维护人员根据医疗人员的申请合理安排，最佳地保持整个医院资源的最大使用率。预约模型提出了预约计划的概念，不仅支持对单个资源的预约，而且支持对多种资源的综合预约，预约的时间也支持不同的时间点，从而将一个病人的一次复杂的多资源预约系统地管理起来，实现了整个预约数据的统一描述。 代码系统代码系统描述了模型所用到的代码表结构。代码表由代码分类和基本代码表组成，代码分类标识代码表内容的分类如疾病、性别、国家等，基本代码表包含了代码表的基本属性如编码，名称，描述，拼音码，自定义码等。不同的代码表往往具有自己特定的属性，所以对于有特定属性的代码表可以从基107、础代码表派生出来增加自己的属性。采用统一的代码系统有力于代码的统一管理，同时也为模型中的引用提供了便利。权限在系统中发生的事情，抽象的说都是某个主体(subject)在某个资源(resource)上执行了某个操作(operation)。所谓权限管理，就是在这条信息传递路径中加上一些限制性控制。权限系统由四部分组成即资源、权限、角色、用户，资源泛指一切需要由权限管理的对象。权限系统的设计原则是用户扮演角色，角色拥有权限，权限决定资源是否可用访问。 1.6.4 管理信息系统模型总体架构描述了以“病人为中心”的医院管理信息系统的总体模型。医院管理信息系统的整体上是以病人为中心为核心，在整个医疗过程中108、产生的挂号，分诊，收费，入院，出院，费用管理，结算等医院医疗活动及其相关的药品，物资，财务，人员管理等运营活动全部被看作是医院管理系统的组成部分。注册挂号挂号模型描述了病人挂号的基本信息。挂号信息主要由病人基本信息，挂号信息两部分组成。挂号是整个信息模型的起点，通过挂号记录可用直接查找到病人的历次门诊期间的所有医疗记录内容。病人信息描述了病人的基本信息，包括人口统计学信息，个体标识，危险因素，联系人，邮政及电信地址，在院注册内容等信息。其中个人信息是病人作为一个社会实体的基本信息。挂号信息描述了病人一次挂号的情况，包括就诊科室，就诊大夫，就诊时间，医保及资金账户等内容。挂号信息是每次就诊病人的109、门诊登记信息。一个病人可以产生多次挂号记录。费用管理费用管理模型描述了病人在院期间的费用信息。费用信息是由病人在院期间的医疗活动所产生，贯穿着整个信息模型。病人入院后所发生的所有医疗活动均与费用信息有着关联。费用明细与病人一次具体的医疗活动相关联，包括费用的借方和贷方信息，货币价值等内容。一次医疗活动可以有多条费用明细。与费用相关的还有病人的帐户信息，包括了病人的预交费用，账单明细，医保帐户等内容。入院管理 入院模型描述了病人入院的基本信息。入院信息主要由病人基本信息，入院信息两部分组成。入院是住院医疗的起点，病人入院后所发生的所有医疗活动都将以此为基础记录，通过入院记录可用直接查找到病人的历110、次住院期间的所有医疗记录内容。病人信息描述了病人的基本信息，包括人口统计学信息，个体标识，危险因素，联系人，邮政及电信地址，在院注册内容等信息。其中个人信息是病人作为一个社会实体的基本信息。入院信息描述了病人一次入院的情况，包括就诊科室，就诊大夫，转科信息，床位信息，入院诊断，医保及资金账户等内容。与病人信息比较，入院信息是每次就诊病人的在院登记信息。一个病人可以产生多次入院记录。出院管理出院模型描述了病人出院的基本信息。出院信息主要由出院信息，结帐信息两部分组成。出院是住院医疗的终点，病人出院代表本次在院期间的所有医疗活动结束，同时结算医疗活动产生的所有费用。通过出院记录可以统计病人的转归情111、况及病人在院期间的所有费用信息。出院信息描述了病人的出院信息，包括出院诊断，出院转归，出院时间，出院科室等信息。结帐信息描述了病人在院期间的结算情况，包括费用明细，费用的归属，结帐帐单，资金帐户，医保等内容。一个病人一次入院可以产生多次结帐记录，但只能有一次出院记录。药品物资管理药品物资管理模型描述了医院物流的基本信息。主要由供求方信息，物品信息，流向信息三个部分组成。药品、物资是病人在院期间的医疗活动的物质基础，是医院管理中人财物的重要组成部分。供求方信息描述了供求方的基本信息，包括科室信息，库房信息，供应商，厂商等信息。而供求方的角色是可以互相转换的，比如库房对于科室来说是供方，对于供应商112、来说是求方。物品信息描述了物品的基本属性，包括物品类别，特性，厂商，价格等内容。流向信息描述了物品的流向信息，主要包括物品信息，库房信息，科室信息，病人信息，流动方向，价格等信息。流向信息也记录了物品和医疗活动内在的关系。1.7 安全机制1.12.61.7.1 物理层面物理安全主要是指机房和办公场地的安全性。主要应考虑以下方面。1. 物理位置的选择：机房和办公场地应选择在具有防震、防风和防雨等能力的建筑内，避免设在建筑物的高层或地下室，以及用水设备的下层或隔壁。2. 物理访问控制：机房出入口有身份鉴别设备或机制，进入机房人员有有关方面的授权并专人陪同。3. 防盗窃和防破坏4. 防雷击5. 防火113、6. 防水和防潮7. 防静电8. 温湿度控制9. 电力供应10. 电磁防护1.7.2 网络层面网络安全服务主要包括：通用安全服务、访问控制服务、加密服务、安全审计服务。在网络层次提供的隐私和安全服务在网络安全建设中，应该考虑如下几个方面的安全保护措施：1. 网络基础架构安全：该部分包括网络结构的设计和容量，网络设备和关键设施的安全保护和使用审计等。2. 网络安全控制：该部分包括网络访问控制，网络入侵防御等主要控制措施，即首先保证网络访问行为合理可控，然后再对网络中的一些非法行为进行识别和阻挡。3. 网络安全控制措施部署：在网络中需要部署防火墙及其他访问控制措施、网络入侵防御和检测设备，安全控制114、措施在信息系统中的部署方式如下图所示：信息系统网络层次安全部署示意图4. 可用性保护的考虑:为了保障网络的可用性，接入网络进行安全保护的防火墙和网络入侵防御设备必须具有失效开放、失效关闭、断电保护等机制。同时，在非对称路由环境下，安全设备需要支持对网络会话的安全检测和入侵阻断。1.7.3 主机系统层面1. 系统漏洞管理系统：系统漏洞管理重点在于IT资产的发现和管理、漏洞评估、补救管理和策略评估结果。发现资产并评估资产的重要性，并且能够前瞻性地处理和识别漏洞；并实施基于资产的补救措施，评估并报告安全策略的符合性。2. 系统安全保护：系统安全保护重点在于通过附加于被保护系统之上的安全软件或补丁程序115、，对系统已知及未知的弱点进行保护，对蠕虫、病毒、木马等恶意代码进行防范。当由于某些关键系统之上应用软件兼容性或变更管理的原因导致无法应用补丁程序的时候，也需要考虑对关键系统的安全保障措施。3. 身份鉴别和安全审计：应对登录系统的用户进行身份标识和鉴别，并且其身份标识应具有不易被冒用的特点。登录失败时，可采取结束会话、限制非法登录次数和自动退出等措施；同时应该对系统操作进行审计，内容包括重要用户行为、系统资源的异常使用和重要系统命令的使用等系统内重要的安全相关事件；审计记录应包括事件的日期、时间、类型、主体标识、客体标识和结果等；应保护审计记录，避免受到未预期的删除、修改或覆盖等。1.7.4 应116、用层面1. 系统允许医院建立自己的安全级别，安全部门和安全人员，并制订系统的安全机制，系统级控制、安全组级控制、用户级别控制；2. 每个功能、界面、菜单、工作流的访问权限可以按用户和用户的角色定义；3. 用户登陆可以与Windows系统集成，减少登陆系统的时间，登陆信息有用户、密码和位置；4. 患者的重要数据和临床信息可以被保护，只有主治医生和他授权的其它临床医护人员才有权利看到。5. 各个子系统，尤其是窗口业务系统（如门诊挂号、门诊收费、住院收费）等必须具有单机应急系统，以便在网络或服务器出现故障时，能够快速切换到单机系统上，保证业务正常运转。此外，单机系统应具有将应急数据上传到主机数据库的117、功能，还应支持从主机数据库同步字典、配置等信息。（在应急系统方案中详细阐述）。1.7.5 数据层面在数据安全层面，主要需要考虑数据丢失和数据泄漏两个方面的威胁。1. 建立完善的备份策略：通过建立双机热备或数据库服务器群集机制满足系统7*24小时的不间断运行。还应建立磁盘、磁带全备份、增量备份机制。2. 通过中间层组件访问数据库，避免客户端直接访问数据库，一方面可以对客户端采集数据进行校验，减少错误数据产生，另一方面也可以保证数据库访问安全性。3. 防信息泄漏技术通过对安全域内部敏感信息输出的各种方式进行控制，通过部署防信息泄漏类技术在所有的客户端实现数据保护，并完成统一管理；通过数据保护客户端118、对用户的网络行为进行检测，阻断数据泄漏行为；通过数据保护客户端对具体应用进行检测，阻断数据泄漏行为；通过客户端程序，有效的审计各类数据调用行为，并记录全部用户行为； 4. 对接入计算机的各类外置设备进行控制，防止机密信息通过这类外接设备发生泄漏；针对网络打印机、U盘等各类高危外设的使用进行审计并记录；一旦发现非法使用，可以第一时间阻断数据泄漏行为；5. 磁盘和数据加密：包括文件加密、整盘加密以及移动介质加密等。文件加密类技术用于防御攻击者窃取存储于文件中的数据，目的是保障文件中存储数据的安全。整盘加密类技术通过对整盘数据进行整体加密来实现数据保密，目的是在数据整盘存储层面保障数据安全。移动介质119、加密类技术通过对U盘等移动介质进行加密处理，防止意外丢失造成的数据泄漏。1.8 部署与负载负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 负载均衡有两方面的含义：首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。 多层应用架构可以将大量的业务逻辑处理放在逻辑中间层中，而逻辑层在物理上可以部署在多台应用服120、务器上，这样可以保证根据业务量的大小合理的将不同的应用业务系统部署在不同的服务器上，同时可以用F5或application center等软硬件方式进行负载均衡，达到更佳的应用效果。1.22.71.8.1 C/S/S架构的部署与负载三层结构客户机/服务器系统中，数据计算和数据处理集中在中间层部件中。而三层结构系统能够实现分布计算功能。具体地说，可以根据需要把各个部件分别或重复地分布在不同的计算机上，使整个系统的工作量平衡分配到网络中。下图为三层结构中间件物理部署运转示意图。1.8.2 B/S架构的部署与负载1 集群概念：集群(Cluster)是一组计算机节点的集合，它们作为一个整体向用户提供一121、组网络资源。一个理想的集群对用户是透明的。用户由单一入口访问集群的资源，从来不会意识到集群中的节点。在用户看来，集群是一个系统，而非多个计算机系统。集群还应该支持随意增加和减少集群系统的节点，而这同样不会影响到用户的访问。2 集群分类：习惯上，把集群分为高可用(High Availability，简称HA)集群和高性能计算(High Perfermance Computing，简称HPC)集群两类。HA集群的核心是防止单点失效，这一般是通过失败转移来实现的，即在一个节点失效后由另一个节点接替服务。不丢失用户状态。HA集群的其他主要特性还包括负载均衡、session同步等。我们使用的数据库的双机122、热备和Oracle的RAC都属于HA集群。HPC集群采用并行计算技术提供超大规模计算和存储能力，多数超级计算机都是HPC集群。这不是我们关注的集群。集群有2种架构。一是客户端拦截器(Client-side interceptor)架构，一是负载均衡器(Load balancer)架构。客户端拦截器架构适于用C/S结构，负载均衡器架构适用于B/S结构。3 我们采用的集群架构：我们采用的是负载均衡器架构的HA型集群。负载均衡器架构由负载均衡器和n个集群节点组成。每个节点是一个Jboss服务器实例。负载均衡器是全局唯一的前置机， 全部用户请求都发到负载均衡器，由其转发到各节点。当负载均衡器发现一个节123、点失效后，会将请求转发到另一个节点上，从而保证服务得以延续。负载均衡器同时负责加权静态负载均衡调度。其部署及负载均衡架构图如下：1.9 技术架构1.9.1 多层应用架构本次信息化建设采用多层体系架构，这种结构是将数据库应用分成三个逻辑单元，每个单元一般是运行在相互连接的计算机上，通过计算机网络互相共享数据和通信。三个单元分别是：1 展现层主要完成数据显示、录入等用户界面的功能，一般采用标准的Windows GUI、Netscape或IE浏览器。 2 应用层包括Web Server 和Application Server。Web Server负责管理HTML文档的存储和传送以及与浏览器的连接。 124、Application Server集中管理业务规则和Web Server与RDBMS的数据交换，也叫做数据代理。 3 数据层提供数据的存储和管理功能，如SQL SERVER、ORACLE、SYBASE等。 方案同时涵盖C/S/S与B/S两大体系架构，其中C/S/S体系架构主要针面向管理的MIS系统的应用，比如门诊收费、住院收费、挂号等。采用浏览器模式的B/S应用主要针对临床信息系统、经营管理系统和决策支持系统，比如电子病历、临床信息系统、护理信息系统、决策支持系统等。1.9.2 C/S/S技术架构本方案中的HIS部分管理信息系统的底层设计采用国际主流计算机技术N-tier（多层结构），相比于125、以前的C/S(客户端/服务器)两层模式，更适应基于Internet技术进行开放性扩展应用，并且大大提高了事务处理能力。由中间件处理应用系统的业务逻辑，客户端程序只处理界面的显示；由中间件与数据库通讯，客户端因为不需要与数据库通讯，所以不需要安装数据库的客户端程序和数据库驱动程序，可以使客户端程序变得更小，更快；中间件可以有多个并且可以安装在不同的计算机上，将处理工作分散开来，改善性能。方案中的C/S/S架构采用Microsoft 的 DNA（Distributed Internet Information Architecture）技术是以 MTS/COM+ 为基础的，辅以 ASP/MSMQ 126、等的一整套集成在 Windows 2003中的分布式应用开发技术。以 MTS/COM+ 提供事务服务，用 DCOM/RPC 进行分布对象间通讯，用 ASP 进行 Web 应用开发，用 MSMQ 提供消息通讯。其架构框架如图MTS是一个中间件，运行和管理业务层组件，负责最底层的工作，接收、连接、安全、同步、线程调度、内容和队列等。ActiveX 是Microsoft OLE技术的扩展。已成为一个行业标准。它们是部件化程序设计的技术基础。COM是Component Object Model的缩写。它是ActiveX之间交互数据的接口。使用DCOM，可以实现部件和部件之间、应用程序和部件之间在网络位127、置上的透明。即应用程序无需知道每个部件在网络中的位置，就能调用它们。1.9.3 结合RIA的B/S技术架构本方案中的临床信息管理系统是基于J2EE平台，结合RIA(富客户端应用程序)的B/S架构的产品。通过建立Hibernate+Spring和EJB的统一框架ESF，用来支持不同规模的企业应用。事务管理和持久化机制方面采用了SPIRNG框架或EJB框架。在WEB Browser端通过FLEX实现复杂的人机交互界面,其可以通过多种通讯方式实现与JAVA应用，甚至是.NET应用的方便整合。业务流程的定制及管理上采用工作流和规则引擎实现，具体采用的技术为JBPM及JBoss Rules,报表服务采用128、比较成熟的JasperReport。基于J2EE的B/S技术架构主要由以下几部分组成：1. 通过公司自主研发的Hibernate+Spring和EJB的统一框架ESF，可支持将来产品在不同规模企业上的使用。该框架可以同时支持Hibernate和EJB实现的持久化，切换过程全部采用外部配置，不需要修改任何代码。实现了程序的灵活性和代码的唯一性。2. 事务管理方面采用了SPIRNG框架或EJB框架。两者对事务的管理都默认采用外部配置管理的方式，同时他们也支持在代码级上实现对事务的控制，是目前JAVA领域内首选的两种事务管理方式。3. 持久性管理方面采用HIBERNATE框架或EJB框架实现，EJB129、采用新的3.0规范，不仅因为该规范简单明了而且在性能的提升上也是2.0所无法比拟的。同时EJB3由于有Hibernate的介入，所以与Hibernate在持久化机制和API上都存在很大的相通性。4. 在B/S结构中复杂显示逻辑及人机交互采用RIA实现，具体的技术采用FLEX实现。FLEX是目前在RIA领域JAVA架构最好的选择，其可以通过多种通讯方式实现与JAVA应用，甚至是.NET应用的方便整合。5. 业务流程的定制及管理上采用工作流和规则引擎实现，具体采用的技术为JBPM及JBoss Rules6. 报表服务方面采用比较成熟的第三方报表服务，具体采用的是开源的JasperReport通过采130、用B/S技术架构，可使临床信息系统具有如下技术优势：1. 可扩展：采用业务总线方式来设计，各模块在总线上可以动态插拔。2. 灵活定制：采用工作流来管理整个业务，实现流程的动态配置规划。各模块可以根据实施具体情况独立配置。3. 低耦合：采用ORM技术，降低了与数据库的耦合度。可以支持多种关系型数据库的应用。4. 可伸缩：同时支持轻量级和重量级架构，可以在不需要改动程序的情况下自动适应大、中、小型企业应用。5. 可靠性：采用的技术都有大量成功案例，在业界都是首选的技术框架或方案。1.9.4 采用面向服务的SOA架构业务共享系统整体设计需要灵活的适应各业务场景变化及新增需求快速响应及扩展、设计以业务131、角色驱动的系统模型、提供给不同工作岗位、相同岗位不同工作内容的人员的个性化服务需求。采用开放的先进的IT领域的SOA技术标准，具备易部署、易管理和易使用的特点，各系统通过发布和获取服务来对外提供信息和获取信息。共享系统本身基于面向服务的组件模型的设计思想，同时具备了动态化的特征，系统模块的增加、删除、启动、停止都是可被动态的进行管理的，同时也包括系统模块的配置也可动态进行修改的。图 2基于ESB的SOA架构SOA架构的原理:基于SOA 原理,将不同的职责封装成不同的服务。服务构成了SOA的功能块，能被发布并且被其他应用程序所使用。在一个SOA 架构下，客户端应用程序使用业务功能的服务而不是直接132、调用业务对象的函数。服务层向客户端提供封装了业务逻辑的黑盒子。SOA的两个不同的层级EHR平台提供的服务是符合标准和规范的，这表示在RHIN 范围的任何一个终端系统都可以以规范的方式使用这些服务。另一个不同层级的SOA设计存在于RHIN平台内部，RHIN 在完成LRS 功能、HIAL 服务和其他注册管理服务时要对业务逻辑进行封装。SOA架构的意义:采用采用开放的应用系统架构技术面向服务的体系架构（SOA），可以使得区域卫生信息平台具有更好的灵活性、开放性和可重用性。SOA是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行133、定义的，可以独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在不同平台中的服务可以以一种统一和通用的方式进行交互。SOA架构是一种松耦合的服务架构，能够满足异构系统之间的信息交换，具有良好的灵活性，能够灵活的适应未来业务的发展变化；具有较好的可重用性，能够较好的保护现有投资，并且支持业务过程的持续改进。基于SOA架构，医院卫生信息交换层（Health Information Access Layer, HIAL）实现了院内卫生信息平台的通讯总线服务和通用服务功能。医院卫生信息集成平台是服务的提供者，也是服务的请求者。各应用系统也开放了服务，可用来满足区域卫生信息集成平台或者其他应用系统134、对于该应用系统的信息传递和共享需求。通过服务的方式，各应用系统与区域卫生信息平台之间实现了信息的传递与共享。1.9.5 ASP与SaaS模式 SaaS 是Softwareasaservice（软件即服务）的简称，它与“ondemand software”（按需软件)，the application service provider(ASP，应用服务提供商)，hosted software(托管软件)所具有相似的含义。它是一种通过Internet提供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂135、商支付费用，并通过互联网获得厂商提供的服务。对于部分RHIN 的POS 应用，如社区卫生中心，家庭用户等，可以考虑使用SaaS模式。用户不用再购买软件，无需对软件进行维护，RHIN 平台在向客户提供互联网应用的同时，也提供软件的离线操作和本地数据存储，让用户随时随地都可以使用其定购的软件和服务。对于RHIN 的许多应用来说，SaaS 是采用先进技术的最好途径。在这种模式下，用户不再象传统模式那样花费大量投资用于硬件、软件、人员，而只需要支出一定的服务费用，通过互联网便可以享受到相应的硬件、软件和维护服务，享有软件使用权和不断升级。1.10 关键技术MIDAS技术方案中的HIS管理信息系统产品通136、过使用DELPHI7开发工具实现了产品三层技术架构。MIDAS（multi-tierdistributedapplicationservicessuite），即多层分布式应用服务组件，是Delphi用来开发多层应用系统的中介透明引擎，具有在客户端无需任何数据库工具便可以读取远程数据，具有网络通信量小、多线程、数据库自动约束及平衡负载的特点。客户端程序主要由TClientDataSet和DCOMConnection组件组成，用于连接远程应用服务器.应用服务器主要由远程数据模块（RemoteDataModule）和封装了逻辑的企业对象组成.通过RemoteData-Module实现IAppServ137、er接口，并为客户端提供DCOM连接方式.其基本结构及DELPHI的具体实现如下图所示。系统中程序执行过程如下所示：运行时先启动服务器应用程序，这时用户启动客户端程序，并从中获得IAppServer接口.远程数据模块是一个双重接口的自动化服务器，它封装了应用程序服务器的对象和接口，当采用DCOM 协议通信时，它就是一个COM/DCOM自动化服务器，TDataSet即是远程数据模块中的DCOM查询对象.首先，用户向应用程序服务器提出数据请求，应用程序服务器收到请求后从远程数据库服务器检索并获取数据，并按照一定的规则将数据封装打包后传输给客户端程序；客户端程序收到数据封包后，进行数据包的分解，然后138、显示或进行处理.用户对数据进行更新后，将数据连同数据变更日志一起封装成数据包，上传到应用程序服务器申请更新数据，应用程序服务器收到客户端程序的申请后，就向远程数据库服务器申请更新数据，如果出错，譬如在用户提出请求以后和数据更新以前，其他的应用程序已经对记录进行了修改，这时候应用程序服务器就把出错的记录返回给客户端。轻重量级统一框架结构ESF统一框架基于EJB3，SPRING，HIBERNATE三种主要的技术，我们通过对比三者的异同点，创建了自己的模型，经过我们搭建的一个实例的测试，证明确实是可行的。理论基础：事务都可以采用声明式的管理，并且事务的模型基本一致，查询语言虽然不同，但是基本的语法标139、准是一致的，对数据的持久操作，缓存方式也有非常大的相似性，EJB3提供的新的注释声明方式可以EJB是建立在POJO的基础上，Hibernate，SPRING使用的也是POJO，EJB3注释方式的声明允许POJO继承其他的类，实现其他接口。FLEX 传统的WEB应用程序在人机交互能力方面的弱势始终是许多系统无法采用WEB方式的关键因素。以FLEX技术为代表的RIA技术的出现完美的解决了这一制约因素。通过使用FLEX，我们可以实现操作人员与WEB界面的良好人机交互，大部分以前只有在C/S模型下才能完成的复杂交互现在在WEB方式下可以很好的完成了。FLEX服务器可以做为一个JAVA的WEB应用插入到140、我们的WEB应用程序中，在程序运行时完成对FLEX程序的动态编译和运行支持FLEX提供了与JAVA之间无缝的集成，同时提供了多种与JAVA对象交互的方式，非常适合J2EE开发的WEB应用程序。下图为FLEX应用程序框架：HibernateHibernate是一个免费的开源Java包，它使得与关系数据库打交道变得十分轻松，就像您的数据库中包含每天使用的普通Java对象一样，同时不必考虑如何把它们从神秘的数据库表中取出（或放回到数据库表中）。它使开发人员可以专注于应用程序的对象和功能，而不必担心如何保存它们或稍后如何找到它们。Hibernate惟一需要做的就是创建一份XML“映射文档”，告诉Hib141、ernate希望能够保存在数据库中的类，以及它们如何关联到该数据库中的表和列，然后就可以要求它以对象的形式获取数据，或者把对象保存为数据。SPRINGSpring是一个轻量级容器，它所带的包装器使许多不同的服务和框架更易于使用。轻量级容器接受任何JavaBean，而不是只接受特定类型的组件。Spring框架却提供了一种高效地构建和汇编Java应用程序的方法，以及多种服务的抽象。尽管Spring支持多种服务，但是它最受关注也是最出色的特性是杰出的分层和封装。与EJB一样，Spring的中心组件是一个容器；而且Spring框架也同样提供对核心J2EE服务的访问。但是这就是它们仅有的相似之处了。EJ142、B为了更容易地开发分布式的面向对象的商业系统，在1998年3月，产生了EJB规格说明书。该规格说明书和实现它的应用程序服务器已经在很大程度上实现了这个目标。同时EJB3的规范也将在近期发布。规则引擎JBoss Rules 的前身是Codehaus的一个开源项目叫Drools。最近被纳入JBoss门下，更名为JBoss Rules，成为了JBoss应用服务器的规则引擎。Drools是为Java量身定制的基于Charles Forgy的RETE算法的规则引擎的实现。具有了OO接口的RETE,使得商业规则有了更自然的表达。报表服务JasperReports是一个功能强大的Java开源报表工具，可以在143、各种Java应用中使用它的主要目标是用来帮助以简单灵活的方式来创建面向页面、可以被打印的文档。JasperReport的优点就是使用简单，输出方式多样。Jasperreport提供了一个可视化开发工具即iReport。在我们的实际开发中将采用iReport来设计报表，然后才有JsperReport作为报表引擎来展示报表。XML技术1.2.2.1.2.2.2.3.2.4.2.5.2.6.2.7.可扩展标记语言（Extensible Markup Language，XML）XML提供了一种标记内容的方式，可以添加关于数据用途的信息。信息使用 XML 存储之后，用称为解析器的应用程序就能够可靠地提取144、相关信息，并根据不同的需要进行处理。XML 可用于各种不同的应用程序，但其实质是：XML 是一种表示数据的方式。XML 包括验证或者确认的能力、文档结构和文档（在某种意义上的）内容。验证文档有助于防止数据与期望具有特定结构的应用程序进行交互时出现问题，当 XML 与非 XML 的遗留系统交互时这一点尤其有用。最初的 XML 1.0 推荐标准包括对文档类型定义（Document Type Definitions，DTD）的支持，DTD 提供了一些验证能力。W3C XML Schemas 扩展了这种功能，并提供了一种更加类似 XML 的语法。XML 封装的数据常见的处理方式是通过使用可扩展样式表语145、言转换（Extensible Stylesheet Language Transformations，XSLT），通过使用 XSLT 定义对 XML 文档进行操作，以生成特定的结果。这种动态转换信息的能力允许从单个源文档产生多种输出，无论输出到不同的数据库还是输出到不同的浏览器。元数据管理技术元数据体系是一种用来描述数字化信息资源，特别是网络信息资源的基本特征及其相互关系，从而确保这些数字化信息资源能够被计算机及其网络系统自动辨析、分解、提取和分析归纳(即所谓机器可理解性)的一整套编码体系。它由各种应用范围的元数据组成。所谓元数据是一组描述数据本身基本特征和属性的数据，又称为“数据的数据”。从146、本质上说，元数据是一种数据结构标准，它提供了一种框架体系和方法来描述、表征数字化信息的基本特征，并通过一套通用的编码规则，将来源各异的数字化资源归纳到一个标准的体系中。元数据的成分至少要包含：标识符、存取文献所要求的硬件、软件与操作系统；脱机文献(如CD-ROM等)的形体描述；编码标准与版本；数字文献的迁移史与其预期效果；有助于确定数字文献真实性的数据；版权管理信息以及版本与日期等。数据集是指由按照数据元所形成的若干数据记录所构成的集合。医药卫生领域的数据集主要可以归纳为三个方面：其一是信息发布类统计数据集，其二是业务系统建设类的基本数据集，其三是为满足特定目的收集整理制作的数据集。健康档案相147、关卫生服务基本数据集是指与健康档案（特定目的）特定的卫生服务活动或干预措施（特定主题）相关，在其进行信息记录时所必须采用的、基本的数据元集合，且其内容限定于特定卫生服务活动所使用的卫生服务活动记录表单。与健康档案相关的每一个卫生服务活动（或干预措施）均对应一个基本数据集。基本数据集标准规定了数据集中所有数据元的唯一标识符、名称、定义、数据类型、取值范围、值域代码表等数据元标准，以及数据集名称、唯一标识符、发布方等元数据标准。信息采集技术信息采集技术指的是，对网络上各种信息源（数据库、网页等），可以自动、定时地从系统指定的多个应用中把它上面的某些栏目、列表中的内容下载，对这些信息的数据结构进行简148、单分析后，设置相应的采集规则，然后这些信息进行收集、整理、归类，建立索引，并保存到数据库中，支持自动分类、编目，分类的目的是数据便于管理，便于统计分析。其核心功能是对指定的信息源进行定向周期性检索，检查收录最新内容，并下载、建立索引、按照用户定义的组织方式进行存储管理。具体包括数据库转换技术、元搜索技术、网络雷达技术、内容提取技术。BPM技术BPM是一种理解、定义、自动化以及改善业务的技术。BPM关注的是业务流程级别的应用集成。从另外一个方面来看，也可以将BPM看成是工作流（Workflow）技术和应用集成（EAI)的结合。传统的工作流应用程序需要人来参与对文档的操作。而在EAI集成环境中，应149、用程序被连接起来，可以不需要人的干预就可以实现协作。BPM则把这两种技术组合起来。其目标是：1优化业务流程，以获得更好的操作效率以及较低的成本2使用较少的IT资源来获得快速的流程变更能力。BPM可以帮助用户对复杂的和重要的业务流程建模，以及发布、运行和管理这些流程。分布式服务框架分布式服务框架通过UDDI和WSIF，实现WebService的注册和管理，支持多种形式的服务实现，如本地Java类、EJB、JMS，等等。通过动态的服务加载和部署。为外部用户和工作引擎提供透明的服务调用机制。它具有以下功能：l 管理服务的提供者的信息。l 服务注册和管理l 定义服务总线的接受端口，屏蔽掉消息传输的协议150、区别。l 定义总线的服务端口，提供统一的调用形式。UDDI标准是通过四种核心的信息模型来描述一个Web服务、Web服务提供者以及其他的有关Web服务的信息，这几种核心信息模型由XMLSchema定义。使用XML是因为它提供了平台无关的数据描述并很自然的描述了数据的层次关系。而选择XMLSchema是因为它支持丰富的数据类型，便捷的描述方式及其按信息模型对数据进行验证的能力。这四种信息模型分别是：商业实体信息(Business Entity)、服务信息(Business Service)、绑定信息(Binding Template)和技术模型(T Model)。它们的层次关系如图所示。图 3信息151、模型层次关系图四种信息模型的具体意义如下：商业实体信息（Business Entity）。即发布服务信息的商业实体的详细信息，包括企业名称、关键性的标识、可选的分类信息和联络方法等。服务信息（Business Service）即一组特定的技术服务的描述信息。是对Web服务的技术和商业描述。Business Service是Business Entity的子结构。绑定模板（Binding Template）即关于Web服务的入口点和相关技术规范的描述信息。调用一个服务所需要的信息（包括规范描述的指针和技术标识）是在Binding Template结构中定义的。技术模型（T Model）即Web服152、务或分类法的规范描述信息，也就是关于调用规范的元数据，包括Web服务名称、注册Web服务的企业信息和指向这些规范本身的URL指针等。在服务框架里，我们使用WSIF（WebService统一调用框架）技术，可以对用不同协议实现的服务按照一致的方式进行调用。WebService技术该方案涉及许多专业化应用，需要对多应用系统的进行集成，用一体化的方案给予解决，形成一个相对完整而有效的体系。WebService是一个可互操作的分布式应用程序的新平台，它定义了应用程序如何在Web上实现互操作性。用任何的语言，在任何平台上写WebService，只要通过WebService标准就可以对这些服务进行查询和访153、问，形成一个开放的共享体系，使系统既有良好的可扩展性。WebService的主要组成：图 4 WebService构成XML和XSD：可扩展的标记语言(XML)是WebService平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。W3C制定的XMLSchema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web154、Service平台就是用XSD来做为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个WebService时，为了符合WebService标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。SOAP：简单对象访问协议(SOAP)提供了标准的RPC方法来调用WebService。可以用WebService写成一系列的C函数，并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。WS155、DL：WebService描述语言(WSDL)就是一个基于XML的语言，用于描述WebService及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。一些最新的开发工具既能根据你的WebService生成WSDL文档，又能导入WSDL文档，生成调用相应WebService的代码。WebService的主要目标是跨平台的可互操作性。为了达到这一目标，WebService完全基于XML（可扩展标记语言）、XSD（XMLSchema）等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。将来，许多应用程序都会利用WebService，156、把当前基于组件的应用程序结构扩展为组件WebService的混合结构，可以在应用程序中使用第三方的WebService提供的功能，也可以把自己的应用程序功能通过WebService提供给别人。两种情况下，都可以重用代码和代码背后的数据。土地资源信息系统作为一套先进的网络资源系统采用WebService是一种必然，充分体现其先进性、时代性和超前意识。信息交换技术信息交换技术，是数据流转共享平台的应用集成中间件的核心关键技术之一，解决跨多系统之间根据相互关系和访问需求建立有序的信息交换流程的问题。集成技术在不同系统之间就可以构筑一个相互进行数据汇集的环境。但来自不同系统和不同数据源的信息，具有完全157、不同的属性。集成实现了数据间的转换和格式处理，但实际的信息需要在不同系统之间进行有序、受控的流动，实现真正意义的交换。交换过程可以实现不同的交换策略，在数据流转共享平台中任意系统之间可以实现主动发送、请求/应答、订阅/发布交换模式，并通过路由控制对实现交换网络中的节点相互提供对方所需要的数据信息。可靠通信技术可靠通信技术是数据流转共享平台中消息中间件的数据可靠保障的核心技术。为交换节点之间的数据传输提供通信通道，平台提供当前主流的消息队列的可靠通信技术。能够实现：基于可靠队列的通信机制；提供传输可靠性保障：不错、不漏、不重的传输机制；支持可靠队列，队列持久性保障；支持断点续传、网络容错，在系统158、运行故障前提下保障数据可靠；支持消息点对点模式和发布/订阅模式消息传输，JMS接口和消息传输扩展能力；支持应用的实时、定时、主动、被动模式，实现同步/异步消息通信手段，实现数据流转共享平台多种交换模式的通信支持；支持数据高效率传输，保障综合平台通信性能，适应网络传输速率，提供透明压缩传输功能，提供通信服务端集群与均衡负载能力，有效应对多客户端大并发需求，屏蔽性能瓶颈；支持复杂消息传输模式，可以直接对文件进行传输，支持数据流转共享平台对文档系统的专业化处理；通信作为数据流转共享平台运行核心，具有细粒度的管理监控能力。需要提供网络适应性部署、事件机制部署以及本地和远程的通信状态实时监控能力。完善的159、管理监控手段同时支持对系统的性能调优和运行瓶颈定位，保障系统健康运行。ETL技术ETL指的是Extract-Transform-Load的缩写，即数据抽取、转换、装载的过程，作为数据整合共享的核心和灵魂，能够按照统一的规则集成并提高数据的价值，是负责完成数据从数据源向目标数据源转化的过程，是实施数据整合共享的重要步骤。如果说数据共享的实现方式是一座大厦的设计蓝图，数据是砖瓦的话，那么ETL就是建设大厦的过程。在整个项目中最难部分是用户需求分析和模型设计，而ETL规则设计和实施则是工作量最大的，约占整个项目的60%80%，这是国内外从众多实践中得到的普遍共识。ETL是数据抽取（Extract）、160、转换（Transform）、清洗（Cleansing）、装载（Load）的过程，是构建目标数据库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据交换标准，将数据加载到目标数据库中去。实现ETL，首先要实现ETL转换的过程。它可以集中地体现为以下几个方面：空值处理可捕获字段空值，进行加载或替换为其他含义数据，并可根据字段空值实现分流加载到不同目标库。规范化数据格式可实现字段格式约束定义，对于数据源中时间、数值、字符等数据，可自定义加载格式。拆分数据依据业务需求对字段可进行分解。例，主叫号861084613409，可进行区域码和电话号码分解。验证数据正确性可利用查找161、及拆分功能进行数据验证。例如，主叫号861084613409，进行区域码和电话号码分解后，可利用查找返回主叫网关或交换机记载的主叫地区，进行数据验证。数据替换对于因业务因素，可实现无效数据、缺失数据的替换。门户式架构门户（Portal）架构是基于Web的，以“应用整合”和“消除信息孤岛”为最终目的，提供单点登录、内容聚合、个性化门户定制等功能的综合信息系统。完整的Portal通常由Portal服务器、Portlet容器、Portlet构成。Portal服务器是容纳Portlet容器，支持Portlet呈现的普通或者特殊Web服务器。Portal服务器通常会提供个性化设置、单点登录、内容聚合、信162、息发布、权限管理等功能，支持各种信息数据来源，并将这些数据信息放在网页中组合而成，提供个性化的内容定制，不同权限的浏览者能够浏览不同的信息内容。通过门户平台，把各种应用系统、数据资源和互联网资源统一集成到通用门户之下，根据每个用户使用特点和角色的不同，形成个性化的应用界面，并通过对事件和消息的处理传输把用户有机地联系在一起。简单的说，门户平台为特定的用户用高度个性化的方式，交互访问相关信息、应用软件、以及商业流程的软件平台。通过建立门户平台，组织各种结构化、非结构化的信息和规范的操作方式，但是不同权限的信息内容。SSL技术本项目将采用OpenSSL做为本系统安全支撑，目前为止，OpenSSL的163、算法已经非常完善，对SSL2.0、SSL3.0以及TLS1.0都支持。OpenSSL采用C语言作为开发语言，这使得OpenSSL具有优秀的跨平台性能，这对于广大技术人员来说是一件非常美妙的事情，可以在不同的平台使用同样熟悉的东西。OpenSSL支持Linux、Windows、BSD、Mac、VMS等平台，这使得OpenSSL具有广泛的适用性。SSL协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商及服务器认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的私密性。通过以上叙述，SSL协议提供的安全信道有以下三个特性：数据的保密性信息加密就是把明码的输入文件用加密算法转换成164、加密的文件以实现数据的保密。加密的过程需要用到密匙来加密数据然后再解密。没有了密钥，就无法解开加密的数据。数据加密之后，只有密匙要用一个安全的方法传送。加密过的数据可以公开地传送。数据的一致性加密也能保证数据的一致性。例如：消息验证码（MAC），能够校验用户提供的加密信息，接收者可以用MAC来校验加密数据，保证数据在传输过程中没有被篡改过。安全验证加密的另外一个用途是用来作为个人的标识，用户的密匙可以作为他的安全验证的标识。SSL是利用公开密钥的加密技术（RSA）来作为用户端与服务器端在传送机密资料时的加密通讯协定。1.11 软件技术标准及规范11.11.21.31.11.1 主要技术指标C/165、S/S架构B/S架构数据库SQL SERVER（32位和64位）OracleSQL SERVER、DB2、Oracle系统架构平台基于DCOM的N-Tier结构基于J2EE B/S结构开发工具DELPHI6.0、DELPHI7.0 JAVA、FLEX 版本控制工具SourceSafe CASE工具 ROSE，PD BUG管理工具bugzilla 操作系统Windows2000、WindowsXP、Vista 自主工具报表生成器、查询生成器1.11.2 主要性能指标运行矩阵可接受界屏转换 （ 90%界屏转换（= 3秒 且 5秒鼠标点击） 5%在线更新业务反应时间 （ 90%在线更新业务反应时间（166、 5 秒） 5%在线单一项目查询/列表业务反应时间（ 90%在线单一项目查询/列表业务反应时间（ 10 秒） 5%在线分析/报告反应时间 （ 90%在线分析/报告反应时间（ 30 秒） 99.9%1.11.3 支持的标准、协议及规范1. 中华人民共和国国家标准计算机软件质量保证计划规范 GB/T 12504-1990 2. 卫生部2002年版和 、中华人民共和国执业医师法、医疗机构管理条例、电子病历基本规范、中华人民共和国计算机信息系统安全保护条例、电子签名法、卫生系统电子认证服务管理办法（试行）、电子病历基本架构与数据标准（试行）、处方管理办法（试行）、麻醉药品、精神药品处方管理规定、临床路167、径管理指导原则等3. 符合中国医院信息系统数据集规范4. HL7通信协议: Health Level Seven（HL7）是为了达到让不同医疗机构或同一医疗机构中的不同单位的数据得以相互无碍的传输所提出的医疗相关数据的传输标准。5. IHE规范：IHE(Integrating the Healthcare Enterprise)是RSNA和HIMSS定期发布、修订和更新的一套技术文档，在文档中定义了一整套基于现行的医学标准集，实现医院信息化环境中工作流及功能集成目标的机制和规范。6. DICOM标准: DICOM是由ACR和NEMA联合推出的医学数字图像存储与通信标准，已发展成为医学影像信息学168、领域的国际通用标准。DICOM标准的推出与实现，大大简化了医学影像信息交换的实现，推动了远程放射学系统、图像管理与通信系统（PACS）的研究与发展，并且由于DICOM的开放性与互联性，使得与其它医学应用系统（HIS、RIS等）的集成成为可能。7. ICD-10：国际疾病分类编码。8. SNOMED：（Systematized Nomenclature of Medicine）医学系统命名法，是当前国际上广为使用的一种临床医学术语标准。9. 数据字典：编制及使用的各种信息分类编码字典219个。选用国际标准、国家标准和卫生部有关标准共55个、系统编制并被卫生部采用为标准的数据字典共45个。【1】计169、算机信息系统安全保护等级划分准则（GB 17859-1999） 【2】卫生部健康档案基本架构与数据标准（试行）（卫办发200946号） 【3】卫生部关于印发卫生系统电子认证服务管理办法（试行）的通知（卫办发2009125号） 【4】卫生部电子病历基本架构与数据标准（试行）（卫办发2009130号） 【5】卫生部中医电子病历基本规范（试行）（国中医药发201018号） 【6】卫生部电子病历系统功能规范（试行）（卫医政发2010114号） 【7】卫生部基于电子病历的医院信息平台建设技术解决方案（1.0版） 【8】卫生部基于居民健康档案的区域医疗信息平台建设指南（试行） 【9】卫生部健康档案元数据标170、准（试行） 【10】卫生部电子病历元数据集（试行） 【11】卫生部临床检验结果互操作规范（试行） 【12】卫生部医院信息系统（HIS）基本功能规范2002版 【13】疾病分类代码标准 （ICD-10） 【14】卫生部标准WS/T102-1998，临床检验项目分类与代码 【15】医药行业标准YY0252-1997，化学药品（原料、制剂）分类与代码 【16】HL7（美国医疗服务信息网络通讯协议）3.0/2.4版 【17】SNOMED国际系统医学术语全集3.5版 【18】ICPC（国际初级保健信息标准） 【19】CPT（美国医院临床操作服务分类编码和术语标准）【20】X12N（美国医疗保险业电子数据171、交换标准） 【21】LOINC、HHCC、ICIDH等1.12 国内医院信息化建设状况及发展趋势1.12.1 建设现状医疗卫生行业是知识密集型行业。医疗过程专业性强，是一种知识型劳动，对信息和处理工具的需求具有专业化、知识化和智能化的特点。医学科学的复杂性和多变性决定了医疗信息化的实施难度比其他行业更加困难，无论是技术、管理、信息标准等问题都非常棘手，同时医疗和社保的互联互通涉及多个部门，是个系统问题，需要多方协调。同时，医院现有的业务流程很难改变，一方面积习难改，另一方面对医院的影响巨大，属于结构性的调整。随着医疗市场的发展，为了应对日益激烈的市场竞争，医院开始从管理为中心逐步转向以病人为中172、心。越来越多的医院开始专注于改善医院的医疗服务质量、提高医护质量、提高医学治疗的效率和水平，方便病人就诊，同时加强医院内部管理，提高效率，降低成本，以提高医院竞争力。在这样背景下我国掀起了的数字化医院建设热潮。医院数字化是目前国家卫生信息化的重点之一,也是国内医院现代化建设新兴的热点。数字化医院依靠现代化的医疗技术和信息技术改进医疗服务质量、医院管理水平、业务运作效率的面向目标的远景。实现数字化医院的驱动力源于医院持续提高医疗服务质量、改善医院的运营绩效的业务需求和管理需求，以达到提高服务质效、改进管理、增加市场份额、降低医院运行成本、医疗服务成本和增加现金节余的目标。1.12.2 建设过程中173、存在的问题在信息化建设中，由于受经验不足，技术更新，医疗政策调整，经营环境变化等因素的影响，容易出现一下问题：l 缺少总体规划和统一标准，各子系统采用了不同厂商的产品，容易出现“信息孤岛”问题。l 医院决策者、科室和患者对医院管理、业务和服务提出了更新更高的需求，对原系统的扩展能力提出了新的挑战，针对原系统的更新改造，可能会带来原系统资源无法再利用等问题。l 外部环境的改变，如医院与医保管理部门、卫生主管部门之间的协同及数据交换越来越频繁，对原系统的适应性也提出了挑战。l 软件公司由于技术、经济等原因，缺乏可持续发展的能力，可能无法为医院提供长期有效的技术支持，导致医院难以完成后续的信息化建设174、需求，影响医院的发展。1.12.3 政策要求当前，世界已进入信息时代，信息技术的发展，不仅提高了人们的工作和生活效率，也改变了人们的生产和生活方式。在2006-2020年国家信息化发展战略中，党中央、国务院将信息化工作提升到我国现代化建设全局的战略高度，明确提出信息化是全面建设小康社会、构建社会主义和谐社会和建设创新型国家的迫切需要和必然选择。在卫生领域则要求统筹规划电子病历应用发展，促进医疗、医药和医保机构的信息共享和业务协同，满足医疗体制改革的要求。新出台的中共中央国务院关于深化医药卫生体制改革的意见（中发号）明确要求：“建立实用共享的医药卫生信息系统，以医院管理和电子病历为重点，推进医院175、信息化建设，积极推广“一卡通”。”随着社会的进步和人类的发展，现代化建设是医院建设的总体方向，而医院信息化建设是医院现代化的必经之路。计算机化的医院信息系统是建设现代化医院的必不可少的基础设施和十分重要的技术支撑平台。最近卫生部出台的关于改进公立医院服务管理方便群众看病就医的若干意见则明确要求各级卫生行政部门和医疗机构：“坚持“以病人为中心”，三级医院与社区卫生服务机构和基层医院建立分工协作关系，做好医院向社区卫生服务机构以及医院间的预约转诊服务。加快医院信息化建设，合理配置和利用医疗资源，逐一解决影响缩短平均住院日的各个瓶颈环节，减少患者预约检查、院内会诊、检查结果等方面的等候时间。利用现代176、电子信息技术，逐步建立病理远程诊断和会诊系统，逐步解决县医院病理诊断问题，保障重大疾病规范化诊疗的基础质量。”国务院医药卫生体制五项重点改革2010年度主要工作安排要求：建立公立医院与城乡基层医疗卫生机构的分工协作机制，加强人员培训交流和业务指导，探索建立社区首诊、双向转诊等分级诊疗制度。1.12.4 医院信息化发展趋势医疗界目前正面临着一个前所未有的变革时期，能否适应和对正在发生的变革做出主动和快速的反应，对每个医院将来的生存和发展至关重要。目前，规划决策社区化、管理职能分离化、信息管理自动化、管理手段法制化、管理人员职业化成为医院管理发展趋势。因此，把先进的信息技术应用到医院的营运和管理已177、成为国际医疗界的一个必然发展趋势，主要表现在以下几个方面：l 信息化重心开始转向临床为核心，以病人为中心。l 更多医院开始尝试医院管理和电子病历的应用。l 医院信息化向集成化发展，在医院内部实现各子系统间的信息集成、共享，同时与疫病上报、银行、医保等外部系统间的集成，实现病人信息的快速传输和共享。l 无线医疗开始在医院中应用。l 医院信息化开始更关注信息安全问题，医院信息系统的高可靠性、高稳定性和安全性是头等大事，需要做好防病毒，容灾备份工作。l 医院信息化开始向区域化发展。l 医院信息化发展趋向于标准化，比如现在正使用的HL7,DICOM3,ICD-10等。1.13 项目需求分析1.13.1178、 指导思想及基本原则中共中央国务院关于深化医药卫生体制改革的意见、“2010年全国卫生工作会议工作报告，坚持以人为本、以病人为中心的理念，依托现代科技及计算机信息处理技术，为广大患者及医院临床、管理提供全方位的信息服务。医院信息系统建设是一项复杂的系统工程，具有工程实施周期长，各类业务流程关联度高，新业务需求频繁，技术更新周期短，相关技术标准持续扩充等特点，必须坚持整体设计、系统集成、分步实施、突出重点、使用高效的原则，将实用性与前瞻性相结合，以相关国际、国家、行业为标准为基础，开发实用、先进、可扩充的信息系统。1.13.2 总体目标和主要任务打造具有国内领先水平的数字化样板示范医院，实现医疗179、业务、管理流程的渠成数字化，优化临床业务流程、强化医疗服务质量，提升医疗业务水平，提高医疗服务效率，杜绝医疗差错事故，增强患者满意度和归属感，不断改进与完善绩效考核模型，提高医院数字化经营管理水平，增强医院综合竞争实力，使之成为本地区区域医疗平台的数字医疗核心。1 医院服务、业务、管理流程全部数字化；2 流程参与对象的数字化表达；3 引进以新一代电子病历为核心的临床信息系统，如影像归档传输系统、实验室信息系统、手术麻醉信息系统等等；4 通过建立全成本核算平台和绩效考核模型，实现医院数字化经营管理；5 通过集成平台，实现医院内部各系统、医保、新农合、各类合作医疗的数据交互，与区域平台、居民健康档180、案的数据共享。建立患者身份识别、医院各类业务角色及员工、临床业务等主索引数据库，实现单点登入平台和医患沟通门户系统；6 完成医院的无线网覆盖，构建移动医疗平台和移动医疗系统；7 构建医学和管理数据仓库、数学模型，实现医学研究、医院管理智能化。1.13.3 规划内容及实现目标本规划建设项目分为六部分：系统集成平台、基础业务平台、临床业务系统、移动医疗平台、辅助业务系统、决策支持平台。系统集成平台：实现医院内部各系统、医院外部接口（如区域医疗平台、居民健康档案、医保、新农合、各类合作医疗等）的数据交互、各类标准集（如HL7、CDA、DICOM等）的本地化，建立患者身份识别、医院各类业务角色及员工、181、临床业务等主索引数据库，实现单点登入平台和医患沟通门户系统。主要目标是降低各系统间数据交互成本，为电子病历系统提供标准化、医学知识库、智能判别的支撑。基础业务平台：更换医院现有HIS，包括：医院总院的门诊部分（含分诊叫号系统及就诊信息发布平台）、住院部份、药品部分、医技部分、物资设备、血液透析管理、接口部分等，以及各分院的HIS平台升级、实现总院与分院间的双向转诊及信息整合。主要目标是优化就医流程、提高医疗服务质量和效益，缩短患者门诊就医时间，节约患者就医成本，控制医保费用超支、改善业务收入结构。通过新的软硬件系统平台，提升电脑业务的性能和处理能力，彻底解决系统响应慢和运行不稳定问题。其中门诊182、部分的主要内容是医疗卡业务，包括发卡系统、预付费系统、自主终端系统等等。临床业务系统：主要包括影像归档传输系统、实验室信息系统、手术麻醉信息系统、重症监护信息系统、电子病历系统。主要目标是临床业务的数字化，提高临床数据的利用价值和共享度。通过规范临床诊疗路径，降低医疗成本，缩短患者平均住院日，提高病床使用率和周转次数。提供医疗质量控制、过度医疗监管手段，提高临床及科研病历质量，减少临床工作人员完成病历时间，为区域平台和居民健康档案建设打下坚实的基础。移动医疗平台：主要包括无线网建设、移动医疗业务及接口建设。主要目标是将医疗业务流程延伸到患者身边，打造真正以病人为中心的临床信息系统。辅助业务系统183、：主要包括全成本核算系统、绩效管理系统、OA系统、医患关系系统（含统一呼叫中心）、体检系统、病案统计系统等。主要目标是实现数字化医疗服务和医院数字化经营管理。决策支持平台：主要包括构建各类医学数据库、临床业务及管理数据仓库、医院数据挖掘平台、临床辅助诊疗系统、医院业务及管理决策系统等。主要目标是通过建立和优化各类临床业务数学模型，为临床、科研、教学服务，提升电子病历的智能化水平，如临床路径最优诊疗方案的筛选、合理用药监测和预警、医院诊疗疾病谱的演变规律研究等。通过建立和优化管理数学模型，支撑医院数字化经营管理运作。通过挖掘成本核算数据，明确医院业务增长点和滞后环节，以此为基础，调整优化绩效考核184、模型，利用医院门户平台，实现展示每个部门、每个员工的绩效考核结果，形成奖优罚劣的正向激励机制。第2章 售后服务内容及措施众所周知，最优的售后服务是项目成功的保证，根据用户的实际情况，作出切合实际的项目售后服务计划，是用户关注的焦点。优质的售后服务一直是我公司国际公司信守的服务宗旨。2.1 免费维护期免费维护期自工程完成并验收合格签字次日开始计算。免费维护期为2年。2.2 维护费用免费维护期外，系统维护和升级总费用按年计算，计算方法：1) 免费维护期后的每一年的维护费，为投标总费用的10%；2.3 系统维护与技术支持方法2.3.1 免费维护期和有偿维护期内的维护内容和技术支持方式1) 我公司国际185、公司保证软件产品的技术支持服务保证期为2年，免费维护期过后，签订技术售后服务合同，软件售后服务费用按照双方协议价格收取。技术保证期自系统竣工验收双方签字之日起计算。2) 免费维护期和有偿维护期内需求的修改和系统的完善。3) 按照ISO的要求为用户提供售后服务，充分保证售后服务的及时、准确、标准和高效。4) 在医院设立技术支持中心，保证在系统上线后2年免费维护期和有偿维护期内，至少1人现场技术支持；提供724小时服务。保证在免费维护期和有偿维护期内做到：1) 8小时工作时间内：3分钟现场响应，1小时内给予解决；2) 8小时工作时间外：5分钟电话响应，45分钟现场响应，并在到达现场后1小时内给予解186、决。涉及软件的生命周期中如软件自身缺陷、系统故障、系统宕机或由于医院紧急业务处理等非常原因引起的软件修改需求（如果不修改要引起医院业务处理系统中断、医院会出现经济损失等严重情形），将在到达现场后1小时内给予解决。5) 验收合格后1年内宕机次数少于2次，宕机恢复时间： 1小时6) 北京我公司国际公司保证在验收合格后5年内无条件免费升级为最新版本。7) 北京我公司国际公司承诺提供技术支持工具，开放技术平台，以利于用户专业人员的维护。8) 以上保修期内服务内容包括标书所有我公司国际公司提供的产品和技术。9) 定期巡检、每年2次；北京我公司国际公司同贵院协商定期巡检的时间，如果医院方没有计划要求，公司187、方将在系统正式运行后，每半年的第一个月定期巡检一次；10) 程序BUG修改：程序BUG修改自发现后2个有效工作日内完成；11) 需求业务变更：业务变更属于系统需求变更的范畴，首先由贵院提出流程修改的方案和具体理由，院方提供用户需求说明书，软件开发部设计组将根据医院方提出的要求，进行系统的分析设计，在系统设计说明书中阐述可行性解决方案和设计报告，包括流程更改后对现有系统产生的影响，系统设计说明书经双方确认无误后，公司安排开发人员修改或开发应用程序，经测试通过并得到贵院确认后，正式进行应用程序的发布和运行。一般地，需求提出后，2个有效工作日内给出开发计划。2.3.2 非有偿维护期服务内容和方式免费188、维护期后，如果贵院不愿意购买投标人的维护，投标人将提供以下技术服务：1) 远程技术支持维护，主要是针对数据库出现问题时使用的，通过远程拨号的方式，直接访问医院方的数据库系统，对数据库出现的问题远程解决。2) 724小时电话热线服务，现场响应时间4小时。2.4 我公司服务体系概述多年来，我公司集团本着“求实为本、至诚至信”的经营原则，本着“诚信、快捷、专业、理性”的服务原则，与广大用户建立了广泛、良好的合作伙伴关系。我公司国际公司深知，只有客户的成功才有我们的成功，客户满意与否是衡量我公司国际人服务质量的唯一标准，和我公司国际产品（包括众多优秀的软件产品和行业整体解决方案）一样。我公司国际服务是189、集团战略发展的重点，服务先行是我公司国际客户交流和市场推广的重要策略，服务制胜是我公司国际和我公司国际客户双赢的重要法宝。服务对象我公司国际公司发展之初就定位于为行业用户提供计算机系统和应用软件的整体解决方案。与我公司国际软件产品和我公司国际系统集成解决方案一致，我公司国际服务的对象是国内外企业、事业单位和政府部门，我公司国际的一切产品和服务都是为了满足行业用户日益提高的信息技术相关需求。质量方针、经营原则和服务宗旨我公司国际服务体系的质量方针是“精心设计、优质服务、科学管理、追求最佳”，在这一方针的指导下，优质服务贯彻到集团每个项目、每个产品、每个部门、每个员工。多年来,我公司国际公司本着“190、求实为本、至诚至信”的经营原则，本着“诚信、快捷、专业、理性”的服务宗旨，与广大客户建立了广泛、密切、共同发展的合作伙伴关系，客户的成功使我公司国际服务品牌DHC 在国内IT行业和主要应用领域树立了良好的形象。基本结构我公司国际服务体系包括服务运营体系、服务资源体系和服务质量体系。其中，服务运营体系中系统维护和售后服务业务通过了HP金牌合作伙伴的银牌服务第三方认证；服务资源体系汇集了国内最优秀的专业技术和管理人员，从人力、物力、财力各方面保证服务运营和客户满意；服务质量体系和集团的软件产品开发、系统集成整体解决方案的设计和实施业务一起通过了ISO9001国际质量管理体系第三方认证，服务质量的监191、督管理得到了许多客户的广泛参与和支持，有力保障了我公司国际服务能力的稳定和提高。服务资源保障我公司国际公司设有客户服务中心，负责调动集团内部所有服务资源（包括技术、管理人员、设备、备件、必要的流动资金等），组建专题服务项目组，以满足用户对服务的需求。客户服务中心：客户服务的核心部门，负责客户服务资源的调配，负责售后服务的接洽、项目立项、设计、组织、实施，负责公司服务热线的7X24小时监听，负责公司服务项目跟踪。客户服务中心实行7X24值守制度。客户服务中心分别在北京本部、广州、南京、成都分部设备件中心。集成技术支持中心/系统集成技术支持部：负责我公司国际服务的集成网络技术实施和技术支持。技术委192、员会：技术支持中心内部交叉设置政府、电信、金融、医疗等十个重要的行业应用技术委员会，负责行业应用的建议和解决方案的研发、评审、改进；网络技术小组：交叉设置CISCO、IBM、HP等九个网络技术小组，负责各类主要技术的跟踪和服务的现场实施；技术实验室：对于主流的网络产品和技术，专门设立技术实验室，由于网络模拟、设计确认和人员培训。软件研究院：负责我公司国际软件服务的咨询和实施。下设软件测试中心、质量配置管理中心和办公自动化、ERP、电信、金融、医疗、电子商务等十个专业软件项目部。各地办事处和技术支持中心：负责相关区域和周边地区我公司国际服务的初期咨询、简单服务实施、用户关系协调工作。目前，除西藏193、台湾之外，我公司国际已在全国各主要省市设立了办事处和技术支持中心。外部顾问团：负责大型、复杂的系统集成、软件开发项目和相关服务的咨询、规划、管理工作。目前；外部顾问16人，其中副教授以上专家10人。质量管理部：负责服务质量体系的维护和改进；负责我公司国际服务项目的质量跟踪和监督；负责客户满意的调查和分析；负责我公司国际服务水平的持续提高。应用软件的售后服务方式与方法我公司国际公司在应用软件的售后服务流程业务处理方面给出下列三种处理方式：故障处理，业务变更和产品升级，售后服务方法包括电话支持，远程支持与现场支持服务三种方法。第3章 培训计划3.1 系统培训项目团队将为医院指派的用户提供培训和知194、识转移，使用户学会测试系统和操作系统、掌握各种不同的模块功能。3.2 培训地点与环境所有培训和知识转移的地点将在医院内进行，语言媒介为中文。医院须提供所有的培训和知识转移所需要的环境： 培训课室已经安装操作系统的个人计算机硬件/工作站 培训和知识转移工作站和个人计算机技术支持3.3 培训材料与手册项目团队将提供培训材料和文档硬拷贝给所有参与培训的用户。将在培训前提交培训材料和文档。3.4 培训计划我们建议逐步进行培训和知识转移并且与项目实施不同的阶段紧密的连接。这方式将使用户能有效地使用系统执行他们的工作。培训对象是信息科和不同的部门的主要用户，目的是训练他们能应用有关的模块来运作。除此，他们195、将协助测试工作和对将来医院新员工给予培训。我们也将为医院信息科提供有关技术上的培训。以确保医院技术人员能了解系统技术上的细节。为了使项目能成功实施，医院的用户应积极地参与每一个阶段的培训。在正常规划外的培训，我们可以提供其他附加收费的培训项目。3.5 培训课程分解我们提供的培训课程如下： 课程项目理想每班课程人数所需课程次数1用户培训- 模块的特征、功能、使用1052技术人员- 工具/平台的安装和使用513- 软件的使用和维护514- 系统设计理念313.6 应用程序培训(针对各系统具体操作员) 该阶段的主要目的是使计算机室的系统管理员及各业务科室的操作人员能够掌握CHIS系统，并且能够充分理196、解CHIS系统(当前版本)所包含的范围及所实现的功能及业务流程，同时也有助于院方提出及相应的客户化需求。需要院方配合的主要工作：1、 建立实验室环境2、 确定各子系统管理人员3、 确定参加培训人员 原则上要求参训人员全脱产培训。可根据院方具体情况，做适当的调整，如：只要求计算机室系统管理员参加培训，或只要求第一批试运行站点的操作员专人全脱产学习，在以后的培训中，可以由计算机室系统管理员进行教授，由我公司国际技术人员进行协助。此种方法有较多好处，如语言障碍问题可以得到解决,同时也使各系统管理员可以较快的掌握相应系统，对以后工作的开展有较大好处。4、 整理汇总客户化需求培训期间及实施期间，院方注意197、保留实验室环境，继续对操作人员进行培训和模拟运行，以达到预期的培训效果，使其能够对系统不适应医院工作模式的部分提出修改需求，由计算机室的工作人员进行汇总、整理，然后转交我方进行分析，作出相应的客户化修改。第4章 实施方案与计划4.1 实施总体规划4.1.1 项目实施阶段规划根据医院信息化建设的规划要求以及项目设计的功能模块和接口情况，医院项目实施计划分为三个阶段实施，经双方协商确认可根据实际情况调整。整体项目实施计划在180天内完成，项目启动时间由双方协商后确定。本项目分为三个阶段（180天内完成）：第一阶段在合同签订生效后90天内完成主要医疗业务模块（包含门诊挂号、收费、住院入出转、住院医生198、工作站、住院电子病历、医保政策查询、医保接口、合理用药、护士工作站、药品管理）系统、手术室、检验科LIS系统等系统在该科室内的统一部署。第二阶段在在45天内完成物资设备、供应室、院感传染病管理、院长查询、病案统计、医院运营管理等系统及各系统间接口调试工作，并最终完成基础HIS和临床系统的部署工作。第三阶段在在45天内完成医院信息平台等系统及各系统间业务联调工作，并最终完成整体项目的验收工作。4.1.2 项目实施计划医院的信息化建设项目实施分为以下几个过程：l 项目准备过程：完成项目启动前的各种准备工作，并最终形成项目实施计划。l 项目启动会：主要目的是双方达成对项目的充分认识，了解双方需配合准199、备的相关事项，和工作方式，并达到动员的目的。l 建立实验室环境：建立字典准备及应用软件调试及培训所需的软硬件环境。l 数据准备：数据字典是各应用系统正常运行的基础，其准备的充分与否将直接l ，的时间安排的时间影响上线进度的快慢，以及各应用系统运行的正确性和稳定性。该过程主要目标是建立系统所需的各种基础字典。l 需求调研：需求调研的目的是为了充分了解客户的需求，经双方确认后形成客户化需求调研备忘录，在此基础上进行系统业务调整，以求最大程度地满足客户业务流程的合理化和个性化。l 需求分析和客户化过程：完成双方在客户化需求调研备忘录中约定的系统业务调整。l 软件调试过程：对客户化后的程序进行调试，保200、证客户化后的程序正常运行。l 应用培训过程：培训计算机室的系统管理员及相关科室的业务骨干能够掌握CHIS系统，并且能够充分理解CHIS系统(当前版本)所包含的范围及所实现的功能及业务流程。能够正确操作和使用CHIS系统相关模块。l 系统运行环境建立过程：建立系统运行所必需的软件和硬件环境。l 系统上准备过程：完成上线前的准备过程，确保上线的安全性和稳定性。l 系统上线稳定过程：跟踪上线系统的运行，对于出现的问题快速响应，保证客户业务的平稳运行，最大限度地降低系统上线带来的各种风险。l 系统阶段性验收：对相应的系统上线后运行阶段性验收，按阶段对合同执行情况进行总结，并最终得到客户对我方履行合同情201、况的认可。及时总结项目实施过程中的经验教训，以利于下一阶段工作的开展。l 系统总体验收：系统总统实施完成，根据合同条款进行验收。系统转入运营维护状态。4.1.3 项目实施计划表序号内容第1月里程碑1第2月第2 月里程碑2第3月第3月里程碑3第4月里程碑41成立信息化项目组2模拟环境搭建3系统流程演示，需求调研4前期准备；人员培训5用户测试及上线评估6流程确定、培训及需求处理7HIS管理系统的科室应用8电子病历、LIS和PACS等系统上线 9二次需求开发全部上线10项目后续跟踪及现场验收4.1.4 医院信息化项目设施中的重点l 详细功能调研与前期准备方法工程师在项目现场建立标准程序运行环境，院方202、为每个功能模块选定一名精通医院业务的人员，项目工程师针对系统提供的每个功能进行详细讲解、演示系统的业务实现方法、对业务人员提出的问题进行答疑；共同记录业务人员提出的问题，并形成需求备忘录提交公司技术部门。l 数据准备数据字典是各应用系统正常运行的基础，其准备的充分与否将直接影响上线进度的快慢，以及各应用系统运行后是否顺利。因此，院方应对数据准备阶段的工作给予足够的重视及支持，安排专人负责联系、协调、组织各相关人员，共同完成此项工作。数据准备开始前，我公司将派专职工程师到医院，就各个字典的内容及准备方法进行初步培训。医院要积极配合，组织相关人员来学习。具体人员，根据上线子系统而定。用户根据自己院203、里的情况，一切重新开始，准备一套适合自己医院、符合现有软件需要的数据。此过程可分为三个阶段：a.数据采集阶段：这个阶段主要是手工采集数据。部分字典内容多而繁杂，采集起来所需时间长，占用人力大，需要耐心认真的对待。在数据采集阶段，有以下几点注意事项：首先，负责各字典的数据采集的人员应是今后字典的直接维护人员，并对字典内容有确切把握的，以保证字典内容的准确性与完整性。例如：职工主索引由人事部门来完成，医嘱项目字典应由护理部与各科室协作完成等。其次字典在分别数据采集完成后，还应将几份数据放在一起进行整体检查，去除那些重复的数据项目，并尽可能多的将遗漏数据补充完整。第三，要根据该字典数据结构的要求，对204、数据进行初步整理，使其符合要求。最后，对于采集来的数据要编排整理，保留完整，以备将来检查核对用。需要特别指出的是，因从事数据采集的人员与下一步数据录入人员极有可能不是同一人，因此，在书写时，请注意工整明了。b.数据录入阶段:数据录入可从医院中挑选有初步计算机知识、打字速度快、准确率高的人员来做，以提高效率，但可能会因该人员对自己录入的数据内容不了解或因数据书写不规范而产生一些错误。在录入过程中，将不断与相应数据采集人员进行交流；也可请数据采集者来录入，发现错误好及时更正，并能够随时处理那些仍然在变化的数据，为将来的维护使用工作打下基础。数据录入的工具可直接选用系统软件，也可通过其它方法，我们的205、工程师会根据实际情况为用户提出最佳方案，并对用户进行培训。因参加数据录入的人员较多，程度不一，数据录入工作完成后，应由专人根据数据采集手稿来检查核对，发现不正确或不准确的地方要及时更正。c.数据验收阶段:用户将核对后的数据发往我公司，由工程部的工程师检查数据是否满足系统的要求，有需要修改则及时通知用户作相应改动。此次检查主要是针对数据的结构及编码规则，对于数据具体含义的正确性是用户把关。至此，数据准备工作完成。l 软件客户化代码修改与扩充方法：一、非现场修改（1） 项目经理提交医院的信息需求,将需求放到公司的FTP服务器上相应的医院客户化工作需求目录中（2） 公司技术支持部门有专人负责各家医院206、的需求响应及分发工作,每2小时进行需求文件的刷新工作（3） 技术支持部负责该项目的工程师接到分发的需求的后,立刻针对该医院的需求与项目经理形成医院信息系统需求备忘录并和项目管理部一起讨论，形成具体的软件修改方案（4） 项目经理将具体软件修改方案与医院进行协商后,将修改时间反馈到技术支持部,技术支持部在规定时间内完成修改.（5） 技术支持工程师对其进行客户化代码修改和测试，完成后提交到FTP服务器中的项目客户化完成目录中由项目工程师进行功能需求现场测试与验证，验证通过后交用户培训使用。二、现场修改（6） 技术支持部人和工程实施人员同时在医院项目实施现场,对医院提出的需求进行现场分析,与医院一起制207、定解决方案,在规定时间内完成客户化修改工作（7） 修改后的程序在医院正式运行以后,将及时回传到总部,便于公司对医院的所用软件版本的管理与控制,保证医院使用软件的统一性。4.2 项目实施组织4.3 软件测试与试运行4.3.1 软件测试 对院方要求：1、 准备好试运行所需条件其中包括：确定各站点；为各站点配备所需的软硬件设备；建好网络环境；确定各站点主要负责人；建立试运行管理制度。1、 督试运行执行情况，以确保达到预期效果。测试运行期间应采用双轨制，即原有工作方式保持不变，同时要利用CHIS系统进行工作。两方面的工作应保持一致。尤其不应忽视CHIS系统的正常使用，否则很难达到系统测试的目标。该过程208、的主要目标为：（1） 做的检查培训效果纠正操作错误。（2） 建立将CHIS正常运行所需的各部门的协调关系。检查数据字典准备的正确性，发现错误及时修改。在此期间，计算机室需要协调工作较多。首先由于采用的双轨制，相应科室的工作量会加大，容易造成各科室的抵触情绪。另外，在发现最初准备的数据字典有误或不足时，需及时要求原来负责此工作的人员进行修正。我方项目负责人员本期主要任务： 2、 检查相关数据，调试应用程序，确保系统正常运转。具体内容是将院方已准备好的数据字典导入数据库中，并进行检查，确认其符合运行的要求，如发现问题应协助院方进行修改，然后进行各系统的运行测试，在运行正常并且各方面条件都已具备的情209、况下开始试运行。3、 解决试运行过程中的各种技术问题,保证试运行工作顺利进行4.3.2 系统首批站点试运行 对院方要求：1、准备好运行所需条件;确定各站点主要负责人；2、建立运行管理制度。继续进行培训，为下一批试运行准备条件。我方项目负责人员本期主要任务：1、核查相关数据，调试应用程序，确保系统正常运转。2、解决运行中的各种技术问题，保证工作顺利进行，并为下一阶段做好准备。系统次批站点试运行1、准备好试运行所需条件。2、监督试运行执行情况，以确保达到预期效果。3、继续进行培训工作，为下一批试运行做好准备。系统次批站点正式运行 1、准备好运行所需条件;确定各站点主要负责人；2、继续进行培训，为下210、一批试运行准备条件。4.3.3 正式上线保障与质量控制保证概述将在系统开发过程中加入足够的质量控制，以确保交付系统的质量如工作声明所述。交付系统须达到（但不限于）最佳的：功能性、可用性、可靠性和（速度）性能。此外，交付系统须达到：可维护性、可支持性和可扩展性。将提供适当的（开发/测试）环境。在开发应用系统时必须在开发环境下进行。当开发完成及单元测试后才提升到测试环境。需求调研和设计阶段将确保需求说明和提议的设计能满足要求和医院业务过程需要。项目队员与医院员工交流，以审查和确保收集的需求和设计的功能完整性。单元测试满足需求说明书中定义的应用系统过程和系统功能。为特定的业务过程设计的各系统模块操作211、正确。包括系统设置、报告制作、界面等。解决所有经确认的重要缺陷。系统集成测试将负责提供在系统集成测试阶段所需要的工具和测试设备。将负责安装系统集成测试环境。保证：系统作为一集成体操作并执行所有的程序。满足医院所有的业务需求，完成所有的系统功能。解决所有经确认的严重系统缺陷。用户验收测试将负责整个系统测试环境的安装、支持、及管理。将负责提供适当的测试策略和方法来验证功能、使用性、可靠性、运行性能、负载能力和可扩充性。将确保使用正确的测试方法和方式进行测试。将需负责（但不限于）以下用户验收测试活动：提供测试脚本、测试数据、测试工具、设备以及有一定技能的人力资源。为测试者提供简短的介绍。协助测试并随212、时提供支持。协调修改需求并管理问题与结论记录。修正在用户验收测试发生的错误、问题或缺陷并完成重新测试。 保证：医院业务处理过程和系统使医院业务能够成功运作，且用户能够完成所需完成的工作。在规定的时间段内递交验收测试计划和结果。解决所有经确认的错误。要达到在系统集成阶段医院和达成的验收测试标准。项目组将和医院相关的人员一起评估用户验收测试签收标准。医院保留最后的签收决定权。如果系统没有按验收标准正确地运行，则认为是系统测试失败。将在规定的时间内解决问题。上线准备将确保所实施整个系统的所有功能完整安装，设置完毕。系统安装前，同时确保检查和测试所有的应用模块。系统递交后，正式投入运行前，安排系统示范213、给医院授权签收人以确认递交的系统满足以前定义的系统规范。系统性能/耐压测试将组织系统性能和耐压测试以确保递交安装的系统符合规范书中所定义的系统性能标准。系统性能测试包括但不限于以下：运行系统能完成日常的业务处理和业务流量。进行耐压测试，能完成处理繁忙时间的业务和流量。执行其他相关的业务处理以测试系统的性能。4.4 管理体系我公司已经通过CMMI4认证，同时拥有ISO9001:2008国际质量认证、ISO/IEC 27001:2005国际信息安全管理体系认证，引进国际先进的国际CMMI管理理念，坚持“以人为本、共同发展”的企业理念，经过多年来实际工程的磨练，培养并且引进了一批成熟的技术设计人员和214、项目管理人员，因此在开发过程中我们将严格遵循CMMI规范和ISO9001认证体系，并在项目全生命周期内严格遵循ISO/IEC27001信息安全管理体系，针对项目特点进行分析，制定严格的项目管理体系，从人员的组成、职能分工、汇报流程、项目过程控制等做到层层控制，通过流程的控制和监管来减少我们的开发风险，为客户提供优良的软件产品。质量管理包括质量要素、各要素需要达到的目标以及在开发过程中必须采取的措施。质量要求要素定义:l 正确性在预定环境下，软件满足设计规格说明及用户预期目标的程度。它要求软件没有错误。l 可靠性系统按照设计要求，在规定时间和条件下不出故障，持续运行的程度。l 效率为了完成预定功215、能，软件系统所需的计算机资源的多少。l 完整性为了某一目的面保护数据，避免它受到偶然的，或有意的破坏、改动或遗失的能力。l 可使用性对于一个系统，用户学习、使用及为系统准备输入和解释输出所需工作量的大小。l 可维护性为满足用户新的要求，或当环境发生了变化，或运行中发现了新的错误时，对一个已投入运行的软件进行相应诊断和修改所需工作量的大小。l 可测试性测试软件以确保其能够执行预定功能所需工作量的大小。l 灵活性修改或改进一个已投入运行的软件所需工作量的大小。l 复用性一个软件（或软件的部分）能再次用于其它应用（该应用的功能与软件或软件部件的所完成功能有联系）的程度。l 质量目标在设计开发过程中，216、必须注意以下要求，以保证软件的质量达到目标。l 正确性系统的功能要满足用户的要求，在预定环境下能够完成预期的功能。因此，必须明确的了解用户的需求。在需求确定方面，应通过深刻的理解运营系统及了解其发展趋势，建立模型并分析，广泛了解其他系统的特长，并总结以往的经验教训的基础上，确定出需求并通过与用户的交流最终确定。在需求的表达方面，强调以全面、精确、细致、易于理解的方式表达，可能需要以多种形式，比如：功能描述、数据描述、数据流图、系统说明等。l 可维护性遵从统一的规范，包括命名规范、界面规范、编程风格；编码应具有良好的可读性，注释完整清晰；避免复杂的逻辑判断条件，易读，易测试；编码应尽量简练，逻辑217、简单；保存异常信息与错误日志以便于调试与分析；降低模块之间的耦合度，增强模块内的内聚。l 可用性用户容易理解和使用该功能；响应时间快，操作方便，提高用户工作效率；提示信息简洁准确。l 可靠性具有异常捕获功能并提供异常处理与恢复功能。l 效率尽量降低系统资源的开销；查询语句要充分考虑到索引；减少与数据库的不必要的交互。l 灵活性，易于扩展充分考虑到各地的不同的环境，通过参数设置使其易于适应不同的要求。l 完整性、安全性保证相关的数据一致性；考虑数据的存取权限。l 文档完善按文档要求完成相关文档。l 质量审核审查制度对于每一阶段的文档及软件产品都应交付给质量保证部门，由审查小组按质量要求严格审查。218、l 审查内容文档：开发计划、用户需求规格说明、概要及详细设计文档、技术文档、用户手册等，详细要求见文档计划。评审文档是否规范，表达清晰，有实用价值。设计方案：是否达到设计目标。应用程序：是否达到质量目标和符合设计目标。l 审查流程项目组按计划准备好交付的产品及文档；交付质量保证部门，组织评审；完成评审，发现错误报告；发现错误的返工；复查返工问题是否已解决。4.4.1 遵循CMMI4级认证体系在开发过程中我们将严格遵循CMMI4级规范，通过流程的控制和监管来减少我们的开发风险，为客户提供优良的软件产品。 在具体的开发过程中，我公司软件过程专家们结合国际标准严格定义了我们自己的开发管理体系。软件过219、程体系OSPM模型是一个集开发流程和技术于一体的过程模型，把技术和软件过程融为一体，它们相辅相成，不可分割，相互作用。它融入CMMI、ISO、RUP、UML、设计模式、测试、需求、分析、设计的流程和技术，将流程及实际的开发工作（包括开发方法、技术、文档、评估、质量）结合为一个整体，将开发技术完全融入到开发工作过程中。OSPM是用例驱动和以构架为中心的，这是OSPM的两个关健点。这使得软件过程开发产品有明显的技术影响。用例驱动使得在每个阶段都能回顾一下为用户实际上做了什么，从而使开发人员能确保系统满足用户的真正需要。在OSPM模型体现了几个特点：u 强调开发管理体系的专业、实际、高效三者的结合。220、只有专业才能开发高质量的软件，只有实际才能符合我们的开发环境，也才能达到高效。u 基于受控迭代原理，逐步清晰、完善。做到平滑的管理体系过渡。u 各个环节（流程）只有接受上一流程的合格输入才可以进行工作，对自己所从事的流程及环节负责。这样，可以起到各环节相互监督、沟通及可跟踪性。如下图所示： u 把错误放在每一个环节（里程碑）发现和解决，而不是将问题都暴露在测试和使用阶段，确保每一环节的输入、输出是合格的，起到相互监督的作用。做好每个里程碑的Review及评估。u 采用面向对象的分析设计方法，本系统的软件设计和开发完全采用了面向对象(ObjectOriented)技术，系统分析和设计采用UML（221、Unified Modeling Language）可视化建模技术，严格按照面向对象分析(OOA)、面向对象设计（OOD）进行设计开发。利用组件构造应用系统是指利用软件的可重用部分或软件组件来组装应用系统。类似于用机器零件装配机器。一个软件组件可以由单一或多个子组件构成。组件间通过组件的接口进行通信及功能上的调用、重用，这样从而实现整个应有系统。它允许我们可以只同时对一个或几个模块进行设计和开发，不必同时展开所有应用系统的开发工作。在一部分应用系统的开发工作已完成后再开发另外的模块；由于采用了组件化的开发，各应用系统及其内部组件的职责和功能明确，对它们的整合、扩展、升级的工作将变得容易、方便。222、4.4.2 遵循ISO9001：2008国际质量认证体系启动会议 其中第一层文件是公司的总体质量方针和目标、职责划分和总体质量保证体系框架。第二层文件中定义了软件生产中的各类过程、环节和流程，规定了各开发部门必须遵守的制度和规范。第三层文件中则包含了完成上述软件生产所必需的文档模版、表等辅助性内容。公司按照ISO9001：2008最新标准的要求建立了质量体系，质量体系贯穿软件产品与软件项目及系统集成项目的各个阶段。公司的质量体系用文件的形式明确规定，并依据质量体系文件的规定有效地贯彻执行。公司的质量体系强调在设计开发过程中保证质量优于在过程结束后发现问题，防止问题的发生优于问题发生后依靠纠正和223、预防措施来解决。与质量管理有关的各个部门应用系统有序的方法编写质量体系文件，质量体系文件应清楚明确地规定质量体系要素、需求和预防措施。下图为公司在软件生产过程中主要的工作活动，其中每一项工作活动都必须按照ISO9001：2008质量体系文件的规定执行，都会产生相应的符合规定的软件文档和记录。4.4.3 遵循ISO/IEC 27001：2005 国际信息安全管理体系ISO/IEC27001 国际信息管理标准国际标准的目的是提供建立、实施、运作、监控、评审、维护和改进信息安全管理体系（ISMS）的模型。采用ISMS应是一个组织的战略决定。组织ISMS的设计和实施受业务需求和目标、安全需求、应用的过224、程及组织的规模、结构的影响。上述因素和他们的支持系统预计会随事件而变化。希望根据组织的需要去扩充ISMS的实施，如，简单的环境是用简单的ISMS解决方案。下图为基于ISMS的PDCA模型。数据准备 图 ISO/IEC 27001信息管理体系计划(建立ISMS)根据组织的整体策略和目标，建立与管理风险相关的ISMS策略、目标、过程和程序，改进信息安全达到期望的结果。实施(实施和运行ISMS)实施和运作ISMS的策略、控制措施和程序。检查(监控和审核ISMS)针对于ISMS策略、目标、实践经验进行评估、测量，并报告结果给管理层评审。改进(维护和改进 ISMS)根据内部ISMS审核、管理评审的结果及225、其他相关信息，采取纠正和预防措施，实现ISMS的持继改进。该国际标准鼓励采用过程的方法建立、实施、运作、监控、评审、维护和改进一个组织的ISMS的有效性。一个组织必须识别和管理许多活动使其有效地运行。通过利用资源和管理，将输入转换为输出的活动，可以被认为是一个过程。通常，一个过程的输出直接形成了下一个过程的输入。组织内过程体系的应用，连同这些过程的识别和相互作用及管理，可以称之这“过程的方法”。在本国际标准中，信息安全管理的过程方法鼓励用户强调以下方面的重要性：a) 了解组织信息安全需求和建立信息安全策略和目标的需求；b) 在组织的整体业务风险框架下，通过实施及运作控制措施管理组织的信息安全风226、险；c) 监控和评审ISMS的执行和有效性；d) 基于客观测量的持续改进。该国际标准采用了“计划-实施-检查-改进”（PDCA）模型去构架全部ISMS流程。图1显示ISMS如何输入相关方的信息安全需求和期望，经过必要的处理，产生满足需求和期望的产品信息安全输出。我公司国际始终遵循ISO/IEC 27001：2005国际信息安全管理体系，针对信息化工程的全生命周期实施持续改进的信息安全管理策略，以保障在整个工程中的信息安全。4.5 项目过程控制方案实施是以用户需求和技术方案为蓝图，进行全面开发建设以至整个工程建成投入运行的全过程。因此，要确保应用系统工程的成功实施，一定要组织安排好实施计划。作为227、承接过多项全国性的大型软件项目的我公司，在项目的规划、管理、实施、协调和人员配备等方面积累了相当的经验，有着一大批具有丰富项目开发经验的软件工程师和项目管理人员。并且设有专门的技术支持服务组。我公司实施CMMI十年来，组织的软件过程得到了规范和提升，项目的管理和控制能力得到了有效的提高，质量意识也得到了增强，同时积累了丰富的CMMI实施经验。这些宝贵的财富为我们切实提高组织的软件过程能力和产品的质量提供了坚实的保证。目前我们所有项目均严格按照CMMI4的要求从事软件的开发和管理活动。在项目实施过程中，需要信息化领导小组及各科室领导给予相应的合作。我公司作为本项目的承建方，负责有关的项目管理和软228、件系统的开发、测试和支持维护工作。双方将在项目启动前各自委派一名全职的项目经理共同管理本项目，我公司的项目经理负责项目的实施，信息化小组的项目经理负责所有双方的配合工作，双方的项目经理将是双方沟通的桥梁。双方愿意在项目的实施过程中积极配合，并认真完成双方的责任和义务，以保证项目的顺利执行。在项目执行期间任何一方对另一方提出的问题应尽快给出回应。为避免项目不必要的延误，卫生局信息中心与我公司举行会谈的请求由双方即刻安排。有关人员尤其是业务人员主动介入有关需求分析、开发设计、编码及测试阶段的所有工作，并及时对交付的文档和源码进行评审和确认。完好的需求对于项目的成功执行而言是至关重要的。“需求分析”229、阶段的输出产品为需求规格说明书，开发方和客户方对此进行评审和确认后。经过确认的需求需要纳入基线进行严格管理，在项目过程中任何对需求的变更需要按照基线变更流程进行。我公司承诺在系统设计、开发、测试及试运行阶段投入足够的经验丰富的系统分析员和软件开发人员，并保证参与人员的稳定性，此外，视项目的具体情况和客户要求，我公司可以随时增加人员。在系统推广及运行阶段，我公司将提供后续的支持，包括培训、维护等。针对整个项目组织开发设计，我公司有一套严密的管理流程和管理计划，从而保障每一个项目都能严格按照标准进行正常上线运行。4.5.1 项目管理制度l 决策制度决策内容包括以下几个原则： 项目经理首先决策原则对230、于该系统开发实施过程的日常工作，一般由项目经理加以决策，然后提交给联合领导小组和顾问专家组，如果没有任何一方提出异议，则该决定生效，如有异议应以书面方式表达。 最高权力机构准则联合领导小组是系统实施过程中的最高决策机械，对重大问题具有决策权。 决策书面准则一切决策应有书面文件，并且在联合领导小组和项目经理处同时备案。l 交流制度 问题及早提出准则对各小组承担责任的工作，必须及时发现不能恰当完成的因素，并及时向项目经理或有关责任人书面报告，否则不能恰当完成任务的责任在于任务的承担人。 及时澄清准则对所承接的工作，如没有拒绝，则代表接受人已经完全了解工作环境、工作结果要求等多个要素。如果在呈交结果231、时，与任务要求有出入，则不可以以任何理由解释责任，失败责任在接受人。因此，接受人应及时与任务分派人澄清任务的全部因素。 提醒道义准则所有实施小组成员，如发现项目进展隐患，应及时向项目经理或其他人员提醒，同时项目经理向联合领导小组提醒。不提醒是没有道义的。提醒可以以书面或口头方式。提醒时也要注意不要追究相关人员的后续工作（因为工作安排有各自的计划与方式）。 周例会每周五下午，由项目总经理组织在现场的相关实施小组成员参加周例会。总结上周工作，形成项目周报。项目周报的内容包括：上周工作进展报告、本周工作计划、本周任务分派报告等。 月例会每月的第一个星期五，由项目经理组织联合领导小组指定人员召开项目例232、会，总结这段时间的工作，会后形成会议纪要、项目月报，呈交联合领导小组及各成员。 问题的提交系统开发与实施过程中，涉及到开发问题的由问题发现人填写问题单并尽快提交到直属领导处，再由其根据问题内容及时分发或报送，即转入审批与确认。 审批与确认审批或确认人在收到问题后的三个工作日内向提出人给出书面回复。 报告体系报告格式遵循项目经理工作指南及项目管理规范。l 问题与争议管理方法 问题及早报告原则对于一个问题，问题发起人必须在问题发生的三日之内，向直属负责人提交报告。问题没有及早报告，导致的项目影响，由延误报告人承担。 报告方式报告方式应尽量采用书面形式或邮件方式，如报告人认为口头报告即可，可以采用口233、头报告，但是如果口头报告没有使问题得以解决，则视同报告人没有作报告。 争议管理在实施过程中，任何不能达成一致的观点均为争议，争议应立即向项目的项目经理或下辖直属负责人呈报，重大争议并报联合领导小组。重大争议应由可以协调争议各方的机构加以裁决，并对裁决承担责任。争议裁决人由联合领导小组选择。争议的最高仲裁机构为联合领导小组组长。如联合领导小组仍不能达到一致意见，则遵循“谁决策，谁承担”原则，决策失误给对方和项目带来的损失应由决策方承担。l 失误管理制度失误可能是多方面的，失误的及早发现是项目成功的基本保障。对失误的严肃性是实施管理的基本要素。因此，每个实施参与成员均要给予极大重视。对以下各个事件234、，必须做出失误分析。 计划有重大改动； 经费有较大变化； 质量不符； 进度不符； 成果不符； 其它重大事件。项目经理或下属实施小组负责人应每月给出失误分析报告，并有每一失误的详细分析报告，此报告应提交相关人员。如果失误分析报告看不出系统实施有重大影响，而实际确有重大问题的，则追究直属负责人的职责，造成重大损失的还要追究项目经理的责任。l 工作管理制度系统实施的管理对象主要有： 目标； 任务； 资源； 质量； 成果； 进度。这些要素通过项目组的工作加以实现，因此对项目组成员的工作管理是及早发现问题，它是落实责任与激励的主要依据，因此工作管理制度必须全面执行。工作管理制度的具体对象为各项目机构和成235、员承担的工作。每个实施目标可分解成各阶段目标，每一阶段目标由一个或多个任务（可带子任务）去完成。工作管理是对工作目标及相关任务、已分派任务、待分配任务、疑难事项等进行管理。疑难事项应立即提交项目经理或下辖直属负责人，项目经理应持有疑难事情管理清单，清单的重大变化必须立即提交联合领导小组。4.5.2 需求分析阶段首先需要经双方协调，形成需求调研计划及需求调研大纲，确定准备工作、需求调研的内容、方法方式以及人员和日程安排等内容，经双方同意后按此计划开始调研。调研正式开始前项目开发组应检查所有必要的准备工作已经圆满完成。项目开发组根据调研中工程实际系统需求，编写并向工程领导小组提交符合ISO9001236、：2008规范要求的系统需求分析报告，并由”工程项目组评审，不合格的部分进一步完善调研；评审通过后由双方共同签署评审意见，并正式生效。对于软件生产过程而言，需求阶段是整个过程中最重要的阶段，需求分析成果的好坏将直接导致项目的成功与否，因此合作双方在此阶段多投入是值得的。而且一旦评审通过并生效，则需求报告将成为系统的设计、开发、测试、实施试运行和项目验收的基本依据之一，因此原则上用户需求将不再因为其它因素的改变而变更，如需进行此种变更，需经双方项目负责人协商确定。4.5.3 总体设计阶段项目开发组通过对系统的功能、运行和性能要求加以分析，产生一个高层次的系统结构、软件结构、接口和数据格式的设计，237、并向工程领导小组提交系统设计报告（其中包括数据库设计），并由工程组织评审并签署评审意见。对其中评审不合格的部分进一步完善和重新策划，评审通过后由双方共同签署评审意见，并正式生效，作为后续软件开发和测试的基础。该报告内容的变更由双方的现场实施负责人、技术负责人进行交流即可确定，并需向工程领导小组汇报。l 总体设计报告（1）需求规定：说明对本系统的主要的输入输出项目、处理的功能性能要求；（2）运行环境：说明对本系统的运行环境（包括硬件环境和支持环境）的规定；（3）基本设计概念和处理流程：说明本系统的基本设计概念和处理流程，尽量使用图表的形式；（4）结构：用一览表及框图的形式说明本系统的系统元素（各238、层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系；（5）功能需求与程序的关系；（6）业务处理权限分析；（7）尚未解决的问题：说明在概要设计过程中尚未解决而设计者在系统完成之前必须解决的各个问题。l 系统概要设计书（1）需求规定：说明对本系统的主要的输入输出项目、处理的功能性能要求；（2）运行环境：说明对本系统的运行环境（包括硬件环境和支持环境）的规定；（3）基本设计概念和处理流程：说明本系统的基本设计概念和处理流程，尽量使用图表的形式；（4）结构：用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要239、说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系；（5）功能需求与程序的关系；（6）业务处理权限分析；（7）尚未解决的问题：说明在概要设计过程中尚未解决而设计者在系统完成之前必须解决的各个问题。l 数据库设计说明书基础设计I、标识符和状态：联系用途，详细说明用于唯一地标识该数据库的代码、名称或标识符，附加的描述性信息亦要给出。如果该数据库属于尚在实验中、尚在测试中或是暂时使用的，则要说明这一特点及其有效时间范围；II、使用它的程序：列出将要使用或访问此数据库的所有应用程序，对于这些应用程序的每一个，给出它的名称和版本号；III、约定：陈述一个程序员或一个系统分析员为了能240、使用此数据库而需要了解的建立标号、标识的约定，例如：用于标识数据库的不同版本的约定和用于标识库内各个文卷、记录、数据项的命名约定等；IV、专门指导：向准备从事此数据库的生成、从事此数据库的测试、维护人员提供专门的指导，例如将被送入数据库的数据的格式和标准、送入数据库的操作规程和步骤，用于产生、修改、更新或使用这些数据文卷的操作指导；V、支持软件：简单介绍同此数据库直接有关的支持软件，如数据库管理系统、存储定位程序和用于装入、生成、修改、更新数据库的程序等。说明这些软件的名称、版本号和主要功能特性，如所用数据模型的类型、允许的数据容量等。列出这些支持软件的技术文件的标题、编号及来源。结构设计I、241、概念结构设计：说明本数据库将反映的现实世界中的实体、属性和它们之间的关系等的原始数据形式，包括各数据项、记录、系、文卷的标识符、定义、类型、度量单位和值域，建立本数据库的每一幅用户视图；II、逻辑结构设计：说明把上述原始数据进行分解、合并后重新组织起来的数据库全局逻辑结构，包括所确定的关键字和属性、重新确定的记录结构和文卷结构、所建立的各个文卷之间的相互关系，形成本数据库的数据库管理员视图；III、物理结构设计：建立系统程序员视图，包括：a数据在内存中的安排，包括对索引区、缓冲区的设计；b所使用的外存设备及外存空间的组织，包括索引区、数据块的组织与划分；c访问数据的方式方法。IV、运用设计a.242、数据字典设计：对数据库设计中涉及到的各种项目，如数据项、记录、系、文卷、模式、子模式等一般要建立起数据字典，以说明它们的标识符、同义名及有关信息。在本节中要说明对此数据字典设计的基本考虑；b.安全保密设计：说明在数据库的设计中，将如何通过区分不同的访问者、不同的访问类型和不同的数据对象，进行分别对待而获得的数据库安全保密的设计考虑。4.5.4 详细设计阶段项目开发组在系统设计报告的基础上，对功能和性能要求进一步加以分析和细化并且把软件的详细设计文档化，向工程领导小组提交系统详细设计报告，并由工程项目组组织评审并签署评审意见。对其中评审不合格的部分进一步完善和重新策划，评审通过后由双方共同签署评243、审意见，并正式生效，作为后续软件开发和测试的基础。该报告内容的变更由双方的现场实施负责人、技术负责人进行交流即可确定，并需向工程领导小组汇报。系统详细设计书程序系统的结构用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间的层次结构关系。各程序设计说明l 程序描述：给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且，还要说明本程序的特点（如是常驻内存还是非常驻？是否子程序？有无覆盖要求？是顺序处理还是并发处理等）；l 功能：说明该程序应具有的功能，可采用IPO图（即输入一处理一输出图）的形式；l 性能：说明对该程序的全部性能要求，包括对精度、灵活性244、和时间特性的要求；l 输入项：给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。数量和频度、输入媒体、输入数据的来源和安全保密条件等等；l 输出项：给出对每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围，输出的形式、数量和频度，输出媒体、对输出图形及符号的说明、安全保密条件等等；l 流程逻辑：用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程；l 接口：用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式，说明与本程序相直接关联的数据结构（数据库、数据文卷）；l 存储分配：245、根据需要，说明本程序的存储分配；l VVI、限制条件：说明本程序运行中所受到的限制条件；l VVII、测试计划：说明对本程序进行单体测试的计划，包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定；l VVIII、尚未解决的问题：说明在本程序的设计中尚未解决而设计者在软件完成之前应解决的问题。功能函数说明书包括变量名、变量初值、功能、函数名、参数、如何调用、备注、注意事项等。以系统分析为基础，进行详细的说明，列出哪个功能涉及多少个函数，以便以后程序员修改、接手和扩展。4.5.5 系统开发阶段根据前面的设计结果，由双方的现场实施负责人、技术负责人讨论确定246、详细的开发计划，并向工程领导小组提交项目开发计划；工程领导小组对项目开发计划进行审查，由双方签字后正式生效，并将作为软件开发阶段的项目管理和监控依据，项目开发小组要严格据此计划控制项目进度，按时向工程领导小组汇报工作进展。为了使用户能够及时获知项目的进展情况，公司开发小组需要每周向工程相关领导提交项目客户周报，项目用户项目组可以随时对公司的工作情况进行检查。软件每一功能模块完成后，需根据系统详细设计报告规定的内容，由公司开发人员根据ISO9001：2008质量保证体系的规定制定测试计划，对软件进行功能测试、性能测试，填写测试问题卡，并进行测试总结编制测试总结报告，对测试所发现的问题进行追踪修改247、和确认测试，直到彻底修改完成并对其它模块没有任何影响。4.5.6 开发计划书项目开发过程中，我们将制定详细的开发计划书，以下为计划书中的内容：（1）系统开发进度表；（2）阶段划分(必须包含“需求分析”、“系统设计”和“测试”阶段)；（3）项目组织和管理计划；（4）数据测试原则和目标；（5）数据迁移和系统切换方案；（6）技术支持计划。4.5.7 质量保证计划书（1）各阶段的进入条件；（2）各阶段的输入；（3）各阶段的输出（可见的工作结果，其中“需求分析”和“系统设计”阶段必须编写需求分析报告和设计说明书，“测试”阶段必须编写测试报告）；（4）对各阶段输出的评价方法。4.5.8 系统实施和试运行阶248、段首先需要经双方交流协调，形成项目实施计划，确定现场实施的准备工作、人员和日程安排、培训计划、阶段目标等内容，经双方负责人签字后生效，按此计划开始现场实施。正式开始现场实施前项目开发组应检查所有必要的准备工作是否已经完成。现场工作首先要进行软件在服务器端的安装和调试，包括数据库中各类对象的生成，初始化数据，原有系统的重要数据的转换导入，前后台软件的安装，配置参数调整等工作；完成后需向工程维护人员提交数据库安装目录，软件安装方法文件，并协助工程用户进行软件安装。软件安装完成并确认可在工程正常运行后，开始相关业务人员的培训；在培训开始之前需要由双方协商形成培训计划，明确培训环境、条件及方式，参加人249、员，课程课时等详细内容，由双方现场实施负责人签字后生效，并分别开始着手准备，在既定时间内完成。培训过程中由公司工程师提供培训考勤记录，培训应该脱产、集中、封闭进行，并要求所有参加人每日必须两次考勤；培训完成后由双方共同进行培训总结，针对培训效果确定是否达到目标，是否再增加培训课程；对以上内容工程用户项目组须进行必要的考核和奖惩，公司培训工程师有权对参加培训人员进行客观评价。培训顺利完成后将开始软件在试点部门试用，公司将向工程用户项目组提交编译后的前后台软件，软件使用操作手册，软件功能清单，这两种文档将详细描述软件的使用过程，软件所包含的全部系统功能模块。软件试用期内工程用户项目组的主要工作是根250、据软件功能清单所列的系统功能模块，检查公司所提交的软件是否满足系统需求分析报告、系统设计报告的规定，列出未完成及含有较严重、明显错误的模块清单形成软件问题及修改记录并提交给公司继续完善；此段时间可以对软件的细节性问题进行测试、验证，但主要精力还是应放在模块级功能的检查上，如果所有模块都已开发并可以进入试运行，其设计方法、技术可行性也都能够满足最终软件的需要，则工程各相关业务负责人、现场实施负责人需要签署各子系统的软件交付书，表明软件已在现场安装、调试、培训完成，基本可以进入软件试运行；此后在软件功能模块一级上不应再发生大的变化，如需要修改功能模块设计，则需由双方项目负责人协商解决。试运行期内工251、程负责组织针对软件功能清单所列的系统功能模块进行现场的系统测试，包括新旧两套系统并行工作一段时间进行验证，使每个功能模块都得到基本确认；对于其中发现的问题和软件的细节性修改意见，需以软件问题及修改记录的书面形式提交给公司；公司修改完成后立即提交到现场，工程负责组织立即对软件进行确认回归测试，如验证问题已修改需要在软件问题及修改记录中予以说明。通过试运行及修改后证明已经基本完成的模块，工程用户项目组应组织相关的业务负责人在软件功能清单中逐项确认。4.5.9 项目验收阶段在试运行期内系统存在一定的细节性问题是工程项目不可避免的问题，特别是随着用户应用的逐渐深入，此类需求会逐级提出，此类问题不属于系252、统的致命性错误；因此当试运行期内所发现的真正的“问题和错误”收敛到一定数目以下时，各业务子系统经过一段时间的并行工作新系统已基本可靠，就可以切换到正式运行阶段，开始正式运行。正式运行后，由工程提出验收要求，双方共同制定项目验收计划，组成项目验收小组，共同进行项目验收。此时公司将向项目用户提交验收的各类文档，包括对系统开发过程进行总结的项目总结，项目技术报告，最终的完整的数据库字典等。验收工作将由本项目组织的专家组对”工程进行全面的验收和鉴定，并出具项目验收小组领导签字的项目验收报告，并签署验收意见，公司在此过程中将全程参与，在现场进行验收前的维护工作。4.5.10 系统正式运行及维护阶段公司承253、诺对工程软件提供服务保证期，在保证期内提供免费的软件升级和维护服务；在保证期外，公司继续为工程的维护提供技术支持，对于软件升级提供优惠服务。维护期的具体工作方式请见售后服务承诺部分，所有维护工作，包括软件出现问题修改、细节性功能的增强，项目用户都要以软件问题及修改记录的书面形式提交给公司，修改完成后工程应组织相关的业务负责人进行确认，并在软件功能清单中说明；如遇紧急情况可事后补齐。4.5.11 各阶段辅助文档现场工作日程安排计划，在实施中的各阶段，对于所发生的需要在现场进行较长时间工作的情况，如果在需求调研计划、项目开发计划、项目实施计划、培训计划等工作计划中未包含，则需要在工作开始前双方共同254、制订好现场工作日程安排计划，并严格据此执行，需要双方现场实施负责人签字生效。现场工作周报，在现场实施工作中，为了把阶段性的工作任务具体落实完成，需要合作双方每周一之前由公司实施工程师与用户组共同制定本周的工作计划，给出每个工作日上、下午的工作内容，以及双方的准备工作。计划制定完成后项目用户项目组向所有相关部门和领导发布，开始执行；实施中双方互相监督按照原计划开展工作；周五时双方负责人共同对本周计划执行情况进行总结，对原计划填写工作总结，详细描述各项计划的完成情况，未完成的部分应写明未完成原因和责任归属，必要时双方协商一起进行加班处理，力争按时完成；对于不能按时完成的必须调整到下周计划中进行。用255、户项目报告，对于实施中各阶段较长时间不在用户现场进行的，或项目处于用户试运行、维护期的情况，为了使项目用户能够及时获知项目的进展情况和公司开发小组的工作情况，公司将在开发阶段每周向工程相关领导提交此报告，维护期内每月至少提交一次。阶段评估报告，实施中当某一阶段性目标实现后，公司将对该阶段双方联合开发组的工作情况进行总结，编写该报告并向工程领导小组提交，及时总结经验教训，为下阶段工作打好基础。4.5.12 实施过程提交文档详见“项目里程碑及成果物计划”章节。4.6 沟通管理为确保工程建设各单位内外部不同层次之间、职能之间相互沟通、协调，促进工作高效、有序地进行，有必要建立规范的沟通管理机制，制定256、高效的沟通程序、方法和内容。4.6.1 问题管理问题管理工作实施的组织由甲方、项目管理组和项目分包单位等机构组成。甲方参与工程重大问题评估；评审工程问题应对计划和方案。乙方负责问题发现、解决和监控；并定期监控各分包单位问题管理情况；对重大问题定期向甲方汇报。项目经理负责识别项目中存在的问题，并对问题进行分析，制定问题解决方案；并在实施过程中负责问题监控，定期向项目联席管理会汇报，对重大问题应立即上报。项目成员参与问题识别、分析以及应对计划的实施。1) 问题管理的内容从问题的来源看可分为：业务、质量、管理、技术、资源、预算等类型。针对不同类型的问题采用不同的管理方法：l 业务问题和管理问题，解决257、此类问题主要以会议的方式。组织甲方、项目管理组相关人员进行讨论并记录达成一致的解决方案。l 技术问题发生时，技术经理和技术骨干须对问题进行分析解决，必要时须邀请专家委员会协同分析和解决问题，并对解决方案和解决过程进行记录。l 质量问题包括“过程”和“工作成果”两方面的问题。“工作成果”的质量问题通过评审和测试的方法发现，由项目经理和质量经理负责跟踪这类质量问题的解决。“过程”质量问题通过质量保证人员的日常检查发现，与项目组达成共识后。l 资源问题和预算问题，贯穿整个工程的各个阶段，由甲方、项目管理组定期分析，根据最新情况进行资源和预算的分配。2) 问题的优先级分类本项目的问题按优先级进行管理，258、分为高、中、低三个级别。l 高级别是指如果不立即处理将影响项目里程碑的达成、影响项目预算或给工程带来重大隐患的问题。高级别问题必须立刻处理。l 中级别问题是重要但不紧急的问题，无需立即停止正在进行的工作。需要制定有效的解决方案，在问题级别上升前予以处理。l 低级别问题一般是对项目目标达成不存在明显的影响。低级别问题应该在高级别问题和中级别问题都已经解决时才开始处理。3) 问题的汇报与上升机制问题管理要求做到以下几点： l 防患于未然，防止问题演化为危机。问题管理强调“从危机管理到问题管理”，并不是要取代危机管理，而是要以危机管理为主转向以问题管理为主，做到“以防为主，防消结合”； l 甲方、项259、目管理组和分包单位定期进行问题分析（如例会、里程碑或日常工作中），找出问题的根本原因。各项目/单位指派专人对问题进行收集、整理，并记录到问题管理表中。并定期随周报、月报、里程碑报告或事件驱动逐级上报。l 问题管理流程采取逐级汇报机制，问题发现方内部无法解决的问题，需要及时上报，由上级单位协助解决。问题汇报的流程为：项目分包单位乙方甲方。4) 问题的分析与解决问题发现后，各级单位应组织相关人员进行问题分析，对问题的影响范围进行评估，并将影响范围记录到问题管理列表中。l 对于高级别的技术问题须组织专家技术委员会参与问题分析和定位。问题定位后，由问题负责人及相关人员制定应对方案，由甲方评审、批准后实260、施。l 对于高级别的管理问题须甲方、项目管理组、项目分包单位进行问题定位后，由问题负责人及相关人员制定应对方案，由甲方评审、批准后实施。l 中级别的问题由项目管理组、项目分包单位进行问题定位后，由问题负责人及相关人员制定应对方案，由项目管理组评审、批准后实施。l 低级别的问题由项目分包单位进行问题定位后，由问题负责人及相关人员制定应对方案，并组织整改。4.6.2 会议机制项目的实施过程中，交流活动非常重要，需要制定会议与交流计划，项目成员时刻不忘交流的显得很必要。本项目是，以甲方和项目管理组、项目承担单位共同工作特征。因此如何能够在事前明确交流的手段、方法的计划就成为至关重要的关键。交流的共通261、的场合是召开会议，为进行在最合适的时机，在必要的相关人员全体参加基础上的信息传达，适当的频度下，集中对象成员召开各种会议。具体会议内容形式记录在下表中。通过会议、进度报告、评估、答疑、报告/联络，定期/随时展开交流。交流内容以保留于文档事项为原则。以决策、信息共享、进度管理为目的召开以下会议。1) 会议种类会议种类召开进度对象成员目的甲乙双方联席会议毎月第个周一(14:00)甲乙双方联席会议成员、项目经理、其他相关人员项目进度报告质量管理和信息共有事前资料：进度报告书、评审记录、课题表、联络表成果物：议事录定例会议毎周三(10:00)项目管理组、项目经理、子项目负责人各项目组向管理组的进度报告262、对问题点的理解对变更的全体决定事前资料：进度报告书、评审记录、课题表、联络表成果物：议事录、评审记录、进度表任务分配毎周次以上随时每个任务任务内的进度管理对问题点的理解对变更管理和变更课题的决定成果物作成事前资料：任务内资料等成果物：会议记录、进度报告书、课题表、评审记录、计划表质量保证会议毎月第1周一(联席会议后)毎月第3周一(14:00)问题点的报告和对策进度监查和理解度的确认事前资料进度报告书、review记录、课题表、计划表、联络表成果物议事录、review记录进度监查毎月次项目管理组、甲方负责人、项目负责人乙方项目实施的状况的监查问题点的报告和对策事前资料：进度报告书、评审记录、课题263、表、计划表、联络表成果物：议事录、评审记录里程碑会议各阶段完成时在里程碑评审项目管理组各阶段的完成的判断事前资料：进度报告书、评审记录、课题表、计划表、联络表成果物：议事录、评审记录系统试运行表11 会议种类2) 会议规则如果有事前资料，在会议以前3日向出席者分发。议事录是当日编制、次日向出席者分发，成果物是2日以内编写完成分发。分别保管于规定的场所。对议事录有变更、追加时，对分发者进行追加变更依赖，会议决定尽可能在会议当日决定。3) 评审对象和实施对象物时期相关资料评审实施实施项目管理计划书议事录、评审记录项目管理组评审完成后，提交甲方评审需求规格说明书/方案设计书需求规格说明书、纸面制作的264、设想运用、要求式样书、提案书项目技术团队、外部技术专家编制过程中，提交项目技术团队中间评审；技术团队评审完成后，提交技术专家评审；完成后向提交甲方进行最终评审软件设计书/项目实施方案软件设计书、项目实施方案、会议记录、评审记录项目技术团队、外部技术专家编制过程中，提交项目技术团队中间评审；技术团队评审完成后，提交技术专家评审；完成后向提交甲方进行最终评审详细设计书/项目实施详细方案详细设计书、会议记录、评审记录项目技术团队、项目技术团队进行中间评审；项目负责人进行最终评审测试用例测试用例、评审记录项目技术团队、项目管理组项目技术团队进行中间评审；项目管理组进行最终评审验收测试方案甲方、项目管理265、组、项目组项目组进行中间评审；乙方进行中间评审；甲方进行最终评审操作手册乙方项目技术团队进行中间评审；项目管理组进行最终评审制作测试计划书项目管理组评审完成后，提交甲方评审项目验收表12 会议评审对象和实施4.6.3 报告机制交流的另一种非常正式的形式是报告，通过提交报告，让项目相关干系人了解项目进展、存在问题、风险，以便于进行项目信息共享。1) 报告内容本项目的报告包括以下内容：交流形式成果物备注进度报告时间表、进度报告书对各任务每周实行次质量保证报告质量保证检查结果对各任务每周实行次测试报告测试结果对各任务每周实行次报告/联络报告、Email认为Email对最终成果物的内容产生影响时，Em266、ail文件（以Email形式）保存变更申请变更申请审批表、变更管理清单记入变更管理中口头其他联络票、会议记录将认为重要的内容，另行编写联络票或会议纪要表13 报告内容2) 报告规则项目编写要求发送时间、形式备注进度报告项目负责人的进度报告以中文写成毎周一中午前通过Email发送相关任务各项目小组对进度进行确认后，在定例会议作进度报告报告/联络联络票、Email作成联络票、Email作成向管理团队提交变更申请变更申请审批表、变更管理清单变更申请发生时向管理团队提交相关利害团体管理信息安全表14 报告规则3) 报告的邮件规则单位名称+种类种类有以下几种类型：l 报告 报告书的提出或调查结果的报告l267、 联络 联络事项l 商谈 商讨事项（要回答）l 检讨 检讨资料、检讨事项的分配等l 确认 确认事项（要回答）l 问题询问 对问题的提出（要回答）l 评审的 对资料评审的请求（要回答）（要回答）的场合下，必须追加回答期限，格式：YYMMDD邮件形式：用TXT形式（不可用HTML形式）附件：用ZIP压缩 （重要的文档需增设密码）4.7 需求管理需求是用户为了达到某个目标而解决某个问题时所必需的一种软件能力，是系统或系统组件为满足某个合约、标准、规格说明或其他正式文档所必须达到或拥有的软件能力。需求工程描述了不同层次的基于计算机的系统或产品特征。需求相关活动包括：需求获取，需求分析与建模，需求建立，268、需求确认，需求管理。 需求可以划分为业务需要、用户需求、系统需求三个层面，其中系统需求又可以细分为功能需求、非功能需求、质量需求和约束条件等。(1) 业务需要(Business needs)：是从业务、市场和管理角度反映企业或客户对系统的高层次目标要求；(2) 用户需求（User Requirement)：是描述了用户通过本软件产品必须完成的任务，一般是用户协助提供。(3) 功能需求(Functional Requirement)：是应用软件所必须实现的软件功能，使操作者(用户)能够通过操作应用系统完成他们必须完成的任务，从而满足业务需要；(4) 非功能需求(Non-Functional Re269、quirement)：描述系统展现给用户的行为和执行的操作等，包括应用系统必须遵从的标准、规范、协议，以及容量、性能、安全性、易用性、可维护性、可扩展性要求等。针对建设目标，以及具有大型及复杂项目管理的特征，在遵循标准软件工程过程理论基础上，该项目需求建模过程如下图所示。具体需求定义及管理过程将以业务需要、用户需求、系统需求、需求跟踪、需求变更管理、质量要素为章节展开描述。 相关利害团体管理信息安全 图 需求管理需求是整个应用系统建设中最首要的内容，完整准确、稳定的需求是整体项目实施的基准，也是最后检验项目是否达到预期业务目标的基准。为在项目策划、实施过程中有效控制需求变更及管理需求，该项目建270、立统一的组织和接口来统一管理需求及需求变更，医院方建立需求管理机构并任命需求负责人，统一协调需求调研、需求确认、需求变更提出、需求跟踪等事项，我公司项目管理组由项目经理作为需求入口、出口负责人统一协调管理需求开发、需求变更、需求确认、需求跟踪等活动。4.7.1 业务需要为保证该医院信息系统建设项目能够始终与业界先进的技术和行业应用保持一致，强化项目范围（需求）的科学化、透明化管理，降低业务需求变化风险，医院业务需求分析、总体设计、形成医院信息系统建设总体设计方案过程，以及甲乙双方职责如下表所示。序号关键过程/活动输出说明职责矩阵甲方乙方分包1项目总体建设目标、需求提出建设目标、业务需求由医院负271、责提出项目总体建设目标、业务需求负责参与NA2业务需求分析、总体设计总体设计方案由甲乙双方共同组织相关业务专家、技术专家经过多方论证和评审，编制形成项目总体设计方案负责负责NA3编制总集成任务书总集成任务书由医院编制总集成任务书，描述整个工程所需交付的产品和服务，包括但不限于：项目范围描述、工作任务描述、战略计划等负责参与NA4.7.2 用户需求用户需求的提出、获取以及用户需求规格说明书是项目成败的核心和关键因素。用户需求直接成为后续需求分析、系统需求基线形成、系统测试、乃至最终交付系统的基础。需求获取是通过一定的活动或方式从客户、业务部门及管理部门收集到他们对系统所能提供的业务支持和功能支持272、的要求。该项目用户需求获取、用户需求规格说明书形成、确认过程，及甲乙双方职责如下表所示。相关利害团体管理信息安全 序号关键过程/活动输出说明职责矩阵甲方乙方分包1用户需求获取计划编制用户需求获取方法、计划由甲方负责编制用户需求获取计划，计划中应包括需求调研方法、工具、过程，详细的调研工作计划，乙方参与该过程负责参与NA2用户需求整理业务场景、业务规则、（输出）实例由甲方负责组织各业务部门进行用户需求整理，包括业务整体流程、流程每个环节的输出、业务规则、要求（含质量特性），乙方协助负责参与NA3编写用户需求规格说明书用户需求规格说明书由甲方组织业务、技术专家根据用户需求整理情况编写；乙方负责指导273、并提供方法、模板负责指导NA4用户需求规格说明书确认用户需求规格接收报告由乙方对用户提交的用户需求规格说明书进行接收确认，甲方进行业务指导、讲解，可以是说明会的方式指导负责NA表16 用户需求表4.7.3 系统需求需求调研、获取、用户需求确认完成后，进入到需求分析、建模过程，需求分析是对获取的用户需求通过需求建模方法（结构化或者是面向对象）进行进一步转化为系统需求，按照功能需求、非功能性需求分层次、渐近式进行细化、确认工作。通过与用户的不断交互，并得到用户的确认，形成系统需求规格说明书、最终生成系统需求基线的过程。是承担单位项目管理组进行项目预算和项目计划制定的基础，是后续系统设计、系统开发、274、测试的输入和基础。需求分析建模以及系统需求管理过程如下表所示：关键过程/活动输出说明职责矩阵甲方乙方分包1需求分析过程、方法、模板、工具、工作计划制定需求分析过程、需求分析建模方法、模板、工作计划乙方项目经理组织相关业务专家、技术专家组成核心组，根据用户需求规格要求，选择适合的需求分析建模方法、过程、模板、工具，并根据项目总体建设目标要求编写详细的系统需求分析工作计划，该计划需得到甲方的审核和批准参与负责NA2执行需求分析建模工作功能建模、数据建模、行为建模系列图、功能矩阵、非功能性需求识别列表、异常功能处理要求、测试要点由乙方项目经理组织核心组，按照需求分析工作计划、规范、模板开展相关需求分275、析建模活动，形成相关工作成果；甲方积极配合乙方工作，进行确认、业务指导、提供资料等工作参与负责NA3编写系统需求规格说明书系统需求规格说明书由乙方核心组根据需求建模成果编写系统需求规格说明书NA负责NA4系统需求规格说明书评审与确认系统需求规格说明书验收报告由甲方对乙方提交的系统需求规格说明书进行评审与确认，已方配合相关评审工作。甲方需审批通过后签署系统需求规格说明书验收报告，后续如有用户需求变更需由甲方需求负责人统一审批统一提交乙方，按照需求变更流程处理负责参与NA5需求基线生成需求基线通过甲方审批和验收的系统需求规格说明书按照配置管理流程，由甲乙双方配置管理员进行基线审计后，生成需求基线，276、未来需求基线变更按照基线变更流程处理负责负责6分包方案及任务书编制分包方案及任务书由乙方根据系统需求分析成果，进行分包方案及分包总体计划的制定，确定分包项目范围NA负责NA相关利害团体管理信息安全表17 系统需求表在整个需求定义过程中，甲方业务人员和乙方需求分析人员之间必须有良好的交互机制，才能保证需求的质量。（1） 对需求分析人员来讲，要：l 使用符合用户语言习惯的表达方式：需求讨论应集中于业务需要和任务，故要使用业务术语而非计算机的行业术语l 了解业务及目标：通过与用户交流来获取用户需求，才能更好地了解业务任务和怎样才能使系统更好地满足用户的需要l 向用户解释说明需求工作结果：可以使用图表277、作为文字性需求说明的补充，并向用户作详细解释l 尊重用户的意见l 向用户提供对需求及系统实施的一些建议l 对需求变更提供真实可信的评估，包括影响、成本和得失等。（2） 对用户(需求提供者)来讲，应该：l 向需求分析人员详细讲解业务l 清楚地说明并完善需求l 准确而详细地说明需求，避免模糊性和不准确性l 从多个解决方案中及时地作出选择和决定l 尊重需求分析人员的需求可行性及成本评估l 划分需求优先级别l 积极参与评审需求文档，并提供改进建议l 有需求变更时要立即联系甲方需求负责人，并遵照需求变更流程处理需求变更4.7.4 需求跟踪需求跟踪的目的是建立与维护“需求设计编程测试”之间的一致性，确保所278、有的工作成果符合用户需求。需求跟踪有两种方式：（1） 正向跟踪。检查系统需求规格说明书中的每个需求是否都能在后继工作成果中找到对应点。（2） 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在系统需求规格说明书中找到出处。正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。需求跟踪矩阵保存了需求与后继工作成果的对应关系。矩阵单元之间可能存在“一对一”、“一对多”或“多对多”的关系。在项目的整个开发、实施过程中，跟踪每项需求的状态是需求管理的一个重要的方面，通过周期性报告需求项的各状态类别以及各状态类别在整个需求中所占的百分比来改进项目的监控工作。状态279、的跟踪包括状态的定义和状态变更、统计，目的是了解项目是如何达到和完全验证所有批准的需求。根据该医院信息化建设项目规模大的特点，为使需求管理方式统一并易于实施，本项目采用逆向跟踪策略，以需求覆盖的方式进行跟踪。需求跟踪过程及职责如下表所示。鉴于未来需求多管理难，建议需求管理使用相关需求管理工具进行管理。关键过程/活动输出说明职责矩阵甲方乙方1建立业务需求矩阵业务需求矩阵甲方需求负责人指定专人负责建立及跟踪业务需求矩阵，主要通过概要设计结束后形成的功能矩阵是否覆盖了业务需求来进行跟踪，在上线接收测试环节跟踪测试用例是否覆盖了业务需求，在接收测试跟踪测试结果覆盖了业务需求负责参与2建立功能矩阵功能矩280、阵由乙方负责建立及维护功能矩阵，功能矩阵需与业务矩阵建立关联关系，从功能视图看到的是功能对业务需求的覆盖率；分包方项目经理指定专人参与该功能矩阵维护；甲方需求负责人定期审核需求覆盖情况审核负责3建立需求矩阵覆盖关系功能矩阵由分包方项目经理或其指定需求负责人对其承接范围的功能矩阵中功能被代码实现覆盖建立关联关系，对集成/系统测试用例对功能/业务覆盖建立关联关系；乙方负责跟踪与协调功能矩阵关联关系的建立；甲方定期审核需求覆盖情况审核负责4需求状态跟踪需求实现状态跟踪报告甲方负责建立项目过程管理工具，乙方及分包方使用该工具对需求实现各环节状态进行管理及跟踪，使得甲方很方便的跟踪到每个需求完成进度及状281、态；需求跟踪状态至少包括如下状态：已分析、已设计、已实现、子系统已测试、子系统已发布、已系统测试、已上线审核负责相关利害团体管理信息安全表18 需求跟踪表4.7.5 需求变更管理既定的需求基线在项目实施过程中可能因业务环境变化等原因出现变更，为了保证项目实施的相对稳定性，对影响项目计划的变更，需要制定出处理变更的规范的、统一的方法和流程，估算出因变更引起的相应的资源、费用和时间的变化以及变更确立后，变更的发布、执行和流程质量的控制。1) 需求变更控制委员会（CCB）需求变更一般由“变更控制委员会(CCB)”进行决策管理，做出决定是否可以将建议的需求变更付诸应用。该项目变更控制委员会分两级管理机282、制：相关利害团体管理信息安全 级别CCB组织构成职责说明一级医院联席会议成员及受邀的技术专家、管理专家审批由医院提出的需求变更、乙方及分包方提出但乙方不能审批的需求变更，并跟踪需求变更执行情况；根据需求变更影响确定CCB成员，小需求变更由和乙方需求接口负责人审批。没有经过CCB审批的需求变更不能提交给乙方项目经理或者分包方项目经理二级乙方CCB乙方项目管理组、受邀的相关技术专家、管理专家审批由乙方提出的需求变更，审批分包方提出的需求变更（无影响的小变更除外）；同时由项目经理跟踪需求变更执行情况。未经过CCB审批的需求变更不能提交分包方项目经理表19 需求变更管理表2) 需求变更处理流程本项目中283、的需求变更需要根据提出变更的单位和变更的影响范围进行逐级审批处理。（1） 分包项目组、项目承担单位、甲方均可以根据当前项目实施过程中存在的需求变化或者新业务需求，提出需求变更请求；（2） 需求变更的影响分析，从技术角度分析应包括对接口、系统架构、代码、外购组件、相关技术文档等的影响；从管理角度分析应包括：工作量、进度、质量、人员、经费、应用效果、风险等；综合以上分析进而决定变更修改范围，或者决策是否变更。（3） 项目组提出需求变更请求和负责需求变更的实施。l 项目经理和质量经理分析本项目组的工作范围变更影响范围和程度，向项目承担单位项目经理提出需求变更请求；l 承担单位项目经理根据需求变更等级284、提交CCB审批通过后，组织更改被批准的需求规格说明书及其他需要修订的文档（含技术类和管理类），并提交CCB跟踪变更执行情况；l 承担单位及子项目的项目经理和质量经理均需将审批通过的更新需求及其他相关文档纳入项目基线管理，并按照变更后的文档进行项目实施。（4） 项目承担单位处理需求变更。l 项目承担单位项目经理分析需求变更的影响程度 ，判断是否可以在项目承担单位内部处理，或者判断是否可以由某个子项目解决或组织多个子项目协同解决；l 如果项目承担单位无法处理的重大需求变更，向甲方CCB提交需求变更申请；l 如果能够在项目承担单位内部解决，项目承担单位CCB批准需求变更申请，通知相关项目组执行变更，285、并通报报甲方需求负责人。（5） 甲方处理需求变更。l 甲方需求负责人收集整理项目重大需求变更或者是由甲方提出的需求变更；l 甲方视变更影响，提交CCB审批，重大需求变更由甲方组织专家咨询委员会对变更中涉及的业务需求、技术方案、设计规格、项目进度、项目预算等方面进行评审；l 通过评审的需求变更，由乙方项目经理协调乙方项目组或者是各子项目执行变更。（6） 接口关系管理表在项目的总体需求确定后，由项目管理组技术经理负责，识别各分项目间或分项目内部各模块间的接口，建立接口关系管理表，并进行跟踪。接口关系的管理可作为项目关联性关系管理的一种辅助方式，也可以在项目发生需求或其它变更时，为变更分析提供参考。286、在项目实施过程中，有需求变更发生时，依据接口管理表很容易识别变更影响的各项目。4.7.6 需求质量要求由于需求规格在项目生命周期中具有：开发者与用户间事实上的技术合同书，设计与编码、测试验收目标系统的基础等重要作用，该项目高质量需求规格要求如下：(1) 完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。(2) 正确性：每一项需求都必须准确地陈述其要开发的功能。(3) 可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。(4) 必要性：每一项需求都应把用户真正所需要的和最终系统所需遵从的标准记录下来。(5) 优先级划分：给287、每项需求分配一个实施优先级以指明它在系统中所占的分量，不要把所有的需求都看作同等重要。(6) 无二义性：对所有需求说明的读者都只能有一个明确统一的解释，尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本等。(7) 可验证性：检查一下每项需求是否能通过设计测试用例或其它的验证方法(如演示、检测等)来确定系统是否确实按需求实现了。(8) 可修改性：需求变更时，要相应修订需求规格说明书，这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在需求规格说明书中出现一次。这样更改时易于保持一致性288、。另外，使用目录表、索引和相互参照列表方法将使需求规格说明书更容易修改。(9) 可跟踪性：应能在每项需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段的叙述。4.8 质量管理项目质量管理过程包括保证项目满足预先规定的各项要求所需的实施组织的活动。本项目质量管理工作包括评审管理、测试管理、质量保证等方面的工作。4.8.1 评审管理评审按评审内容分类，分为管理评审和技术评审。其中：l 管理评审的目标是确认项目的规范执行状况和质量、进度、成本状况，明确项目中所存在的管理类问题，并讨论对策，以确保项目各阶段的目标按289、计划完成。l 技术评审是对工程和项目各阶段重要的技术成果物或技术风险等进行评审，主要的技术成果物如：设计方案、实施方案、代码、测试用例等。目的是尽早发现问题并提出解决对策，确保工程目标顺利达成。管理评审中的计划评审在进度管理章节中描述，里程碑评审在项目验收章节中描述。本章节主要针对技术评审进行说明。1) 技术评审组织技术评审采用分层逐级评审方式。技术评审贯穿工程始终。（1） 子项目内部技术评审由子项目技术经理组织，相关成员参与讨论。重点功能模块的技术评审须邀请项目承担单位技术架构部参与评审；（2） 子项目承担单位内部涉及跨子项目的技术评审或重点子项目的技术评审，由子项目承担单位技术架构部组织，290、各子项目技术经理和技术骨干参与讨论，重要技术评审须邀请专家咨询委员会参与评审；（3） 各承担单位之间涉及跨子项目的技术评审或重点项目的技术评审，由主要责任方的技术架构部组织，涉及到的子项目技术经理和技术骨干参与讨论，重要技术评审须邀请专家咨询委员会参与评审；（4） 集成项目相关的技术评审由甲方技术架构部组织，各子项目承担单位技术架构部和重点项目技术经理参与讨论，重要技术评审须邀请专家咨询委员会参与评审。技术评审分为正式评审和非正式评审：（1） 正式评审包括评审和审查，是正式的、结构化的过程。正式评审要求以会议形式进行，参加评审会议的人员必须要事先进行准备，对于评审问题和评审结论必须以文档化的形291、式进行记录在评审准备表中。重大技术方案和技术构架的评审必须以正式评审会议的形式进行。（2） 非正式评审包括轮查和走查。不需要以会议的形式进行，由作者将工作成果副本发给评审人，评审人检查审阅工作成果，提出其中的错误，作者收集整理他们的意见并进行修正。2) 技术评审对象技术评审对象包括技术成果物评审和技术风险评审。主要评审对象如下图：相关利害团体管理信息安全 图 评审管理表技术成果物评审包括技术方案评审和代码评审。技术方案主要包括需求说明书、设计方案、技术标准和测试用例等。子项目技术方案评审由子项目技术经理负责组织相关人员进行正式评审。总集成技术方案评审由总集成单位项目管理技术架构部负责组织相关人292、员进行正式评审。代码评审则可以采取轮查或走查的方式进行评审。技术风险评审贯穿项目立项和实施阶段。技术风险的类别包括：需求开发、需求管理、综合技术、开发能力、包括设计、编程和测试。工程技术风险评审由项目组负责定期以会议的形式，组织专家咨询委员会、各承担单位项目管理组技术架构部和技术经理等相关人员对实施过程中遇到的技术问题进行识别、分析和解决。3) 技术评审步骤技术评审包括评审准备、执行评审以及评审跟踪。（1） 技术评审准备l 评审组织者确定评审参加人员，并准备好相关的材料。确定评审的时间、地点和内容；l 评审通知和材料发放，应尽量提前以便给评审人预留充足的准备时间。非正式评审应至少提前3天发给评293、审员，正式评审则提前一周发给评审员；l 评审员应该在评审会前认真阅读这些材料，将发现的问题记录在评审准备表上并提交给评审组织者。（2） 执行评审对于正式评审：l 会议时间一般不应超过3小时；l 会议中主要进行问题的确认与分析，听取专家的意见，详细记录专家提出的每一个错误；l 当评审有了明确的结论后，评审组织者做出总结，确保没有歧义后可以结束本次评审。如果本次评审没有通过，必须安排再次评审并决定再次评审的时间；l 评审结束时，指定问题的跟踪人。跟踪人按照评审记录跟踪问题情况，确认问题已经得到澄清（确定是否是问题）。对于非正式评审：l 作者完成工作成果后，发给参与评审的相关人员；l 评审人根据评审294、要求和自身的经验，指出工作成果中存在的错误；l 作者收集整理他们的意见，并对工作成果进行修改。（3） 跟踪返工l 评审组织者需对评审后续工作进行跟踪；l 作者必须根据评审报告的记录进行错误修改；l 如评审中发现错误较多，需要修改大部分内容，则须再度评审。作者完成修改工作后进行二次评审；l 若不需要再度评审，则由作者和跟踪人一起检查所做的更改，跟踪人记录修改结果和数据，并签字表示通过。4) 技术评审质量要求（1） 评审工作量比例l 评审工作量应占整个项目管理工作量的1/3或以上；l 需求评审、设计评审、代码评审工作量应占各阶段工作量的1/3或以上； l 技术评审工作量应占评审工作量的2/3或以上295、。（2） 成果质量准则l 评审准备过程发现的缺陷数应是评审会上发现缺陷数的2倍以上；l 技术文档评审应至少发现的缺陷密度（3个/页）；l 代码评审应至少发现的缺陷密度（10个/KLOC）。（3） 评审覆盖率l 需求、设计和测试用例评审的覆盖率要达到100%；代码评审的覆盖率不应少于30%。对于重点功能模块和关键算法的代码评审应为100%。4.8.2 测试管理测试是质量管理过程的重要组成部分，在本项目的开发编码实施中，通过测试进行质量控制，保证项目的最终质量。本项目的测试分为子项目组内部测试和项目总体集成与测试。如下图所示：相关利害团体管理信息安全图 测试管理表1) 子项目内部测试子项目内部测试296、包括测试策划、测试设计和测试实施三个阶段。其中测试实施分为单元测试、集成测试和系统测试三个环节。重点功能模块必须认真完成单元测试、集成测试和系统测试每一测试环节；对于一般功能模块可根据需要对某一个测试环节进行重点测试。子项目内部测试流程如下图：相关利害团体管理信息安全图 测试管理表测试策划相关活动，包括：（1） 根据子项目需求规格说明书制定测试方案，测试方案中应明确测试范围、测试策略、质量目标、报告机制和内容以及各里程碑阶段点的出口标准和时间等；（2） 根据测试方案制定测试计划，测试计划应包括测试管理工作和测试实施工作。在确保合理配置资源的前提下，测试计划按照前紧后松的原则进行编制。测试计划中297、各任务项应合理衔接、统筹兼顾、减少交叉，任务安排要保持连续、均衡。（3） 依据量化度量指标，确定子项目测试相关的目标，确定后体现在测试计划中，并按阶段进行细化。主要的质量指标有BUG密度、测试用例密度、测试用例执行率和测试用例通过率。l BUG密度=发现BUG数/有效代码行100%，单位：个/KL；l 测试用例密度=测试用例总数/有效代码行100%，单位：个/KL；l 测试用例执行率=已执行测试用例数/测试用例总数100%；l 测试用例通过率=测试实施通过的用例数/测试用例总数100%；（4） 测试方案、测试计划和子项目质量目标均由质量经理编写制定，子项目组进行评审，通过后提交到项目承担单位项298、目管理组 质量管理部审批。测试设计相关活动，包括：（1） 根据测试计划，遵照测试用例设计指南编写测试用例，测试用例应依据需求、概要设计和详细设计编写，保证测试用例的可读性、可执行性和合理性；（2） 白盒测试用例由开发人员编写，技术经理进行评审，主要对功能是否符合需求进行验证；黑盒测试用例由测试人员编写，质量经理进行评审，主要对功能执行结果进行验证。对于重点功能模块的测试用例需经过项目承担单位项目管理组质量管理部进行评审；（3） 测试用例包括用例编号、测试项目、测试标题、重要级别、预置条件、输入、操作步骤和预期结果八大要素。其中重要级别分四个，S级：保证系统安全功能、重要特性、实际使用频率非常高299、的用例；高级：保证系统基本功能、重要特性、实际使用频率比较高的用例；中级：非核心业务功能但使用频率较高的用例；低级：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。编写测试用例时使用相应的测试用例模板。（4） 测试数据要在测试实施前准备完成，应确保数据是经过验证并且可以重复利用的。另外，每次发布新的被测版本时，应当做好前一个版本的数据库备份。而在执行测试用例或性能测试之前，也应当做好数据备份和数据恢复方案。（5） 测试环境的准备，按照计划的测试环境内容部署测试环境，具体包括各种软件、硬件和测试数据等。测试环境要独立于开发环境。测试实施主要包括单元测试、内部集成测试和内部系统测试300、。其中：（1） 单元测试是在开发过程中进行的测试活动，对各功能模块与其他部分相隔离的情况进行测试，由开发人员和测试人员共同完成。l 开发人员对于完成的编码进行单元白盒测试，按照程序内部的结构测试程序，验证其内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。l 测试人员对开发人员测试通过的，并已提交的功能模块进行单元黑盒测试，主要验证每个程序执行结果是否正确，同时根据需求验证功能覆盖率。l 单元测试完成标准是：单元测试用例执行率为100%、级别为高的测试用例全部执行通过、测试用例的最后通过率达到90%、BUG关闭数达到90%以上。l 质量经理根据单元测301、试质量目标进行单元测试阶段质量评价，并负责编写里程碑报告发送子项目组及项目承担单位项目管理组。（2） 集成测试是在单元测试完成的基础上进行的，将所有独立的已被验证通过的功能模块，按照概要设计要求进行组装并测试，确认模块之间接口的正确性。l 测试人员采用自底向上的方式，将通过单元测试的程序按层次逐个组装和测试；l 采用独立的测试环境（与研发环境隔离）开展集成测试，并保证达到质量目标。l 内部集成测试完成标准是：n 集成测试用例执行率为100%；n 级别为高的测试用例全部执行通过；n 测试用例的最后通过率达到要求；n 发现BUG数达要求；n BUG关闭数达到要求。具体指标要求见版本发布判定报告。l302、 测试过程中发现的BUG进行统一管理，并对BUG进行返测。并且按问题的严重程度进行管理；l 质量经理根据前期制定的集成测试阶段质量目标进行质量评价，并负责编写里程碑报告发送子项目组和项目承担单位项目管理组。（3） 子项目内部系统测试是对开发过程中的设计和实施的最后复查，验证功能和性能及其它特性是否与需求一致。子项目内部系统测试应从功能流程、性能、强度、数据处理、外部接口、恢复性、安全性、可安装性和可靠性等方面进行重点验证。l 通过模拟业务流程进行测试，充分考虑实际运用的特征，保证子项目全流程的稳定运行；通过自动化工具模拟多种正常负载和超负载场景，对子项目的各项性能指标进行测试；l 通过系统测试303、验证新系统对于相关软件和硬件环境的兼容性；l 内部系统测试完成标准是：n 系统测试用例执行率为100%；n 级别为高的测试用例全部执行通过；n 各功能模块的测试用例通过率达到要求；n 最近4周平均每周的新BUG数达到要求；n 总BUG发现数达到要求n BUG关闭数达到要求；n 不存在致命的BUG。具体指标要求见版本发布判定报告。l 系统测试出的BUG提交到统一管理平台上，测试人员对修改后的BUG进行返测；l 质量经理根据系统测试阶段质量指标进行检验，并编写里程碑报告提交给项目承担单位项目管理组质量管理部。（4） 质量经理每周根据测试情况编写测试周报，汇报子项目质量和测试实施进度。2) 项目总体304、测试项目总体测试是由承担单位根据总体架构、总体设计等，对各子项目已完成的功能间的接口进行测试，并验证功能的正确性以及全部功能集成后是否达到预期功能目标。项目总体测试分为核心功能模块集成测试和项目总体测试。具体流程如下图： 相关利害团体管理信息安全 表35 测试管理表核心功能模块集成测试，包括：（1） 承担单位项目管理组组建项目总体测试组，项目总体测试组由各核心功能模块子项目组的测试骨干组成；（2） 测试人员根据总体概要设计方案编写测试用例。由承担单位项目管理组组织进行测试用例评审，需要专家咨询委员会参与； （3） 承担单位负责对已完成的核心功能模块进行集成和测试，并搭建新的实施环境，逐一将各功305、能模块进行部署，并完成测试；（4） 核心功能模块测试需关注各接口的运行情况以及组合后的实施效果，保证各功能模块的相互连通与相互操作。项目总体核心功能模块测试组需要提前设计验证数据和验证流程，逐一部署并进行功能验证，尤其需要验证多各功能模块交叉运用的实施效果；（5） 核心功能模块测试还需根据特定的业务流程验证项目核心装备的效果。本项目是面向医疗领域多个方面的装备系统，各方面的业务流程也不尽相同，因此需提前设计并组织编写验证各典型业务流程的测试设计书和相关数据；（6） 核心功能模块测试的工作进度和风险，是承担单位、项目总体核心功能模块测试组和项目管理组质量管理部需要重点关注的部分。承担单位应协调各306、子项目的关系，及时定位发现的BUG，并进行修改；（7） 承担单位项目管理组质量管理部严格按照测试计划进行进度监控，收集、分析各种质量数据，如case执行率、BUG发现数、BUG严重程度分类分析等，并编写质量报告；（8） 项目总体核心功能模块测试经理编制测试总结报告，提交给承担单位项目管理组；（9） 承担单位项目管理组质量管理部根据质量报告和测试总结报告，编写版本发布判定报告，并提交给医院。项目总体测试，包括：（1） 所有的子项目全部开发完成后并已验收，由承担单位项目管理组组建总体测试组，项目总体测试组由各子项目承担单位的测试骨干组成；（2） 项目总体测试质量经理制定测试方案和测试计划，测试人员307、进行测试用例的编写，承担单位项目管理组质量管理部负责组织评审；（3） 项目总体功能模块间接口集成测试，需关注在各个模块连接起来时，穿越模块接口的数据是否会丢失；一个模块的功能是否会对另一个模块的功能产生不利的影响；各个子功能组合起来，能否达到预期要求的父功能；全局数据结构是否有问题；单个模块的误差累积起来，是否会放大，从而达到不能接受的程度；（4） 完成功能模块间接口连接测试后，总集成测试组对项目总体进行系统测试，将项目作为一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，进行一系列的组装测试和确认测试。包括业务流程测试、性能测试、易用性测试、兼308、容性测试、安装测试、恢复测试、安全性测试七个测试类型；（5） 对于在测试实施中发现的问题，总集成子项目组投入足够的技术人员分析问题和确定问题发生的原因，并组织协调相关研发子项目进行解决。重大技术问题需组织专家咨询委员会参与讨论和分析。项目总体系统测试类型，主要包括：（1） 业务流程测试通过模拟最终用户工作流程进行测试，充分考虑实际运用的特征，对各个组成部分进行完整的业务流程测试，以保证项目系统全流程的稳定运行。测试人员还需注意与其他现有系统的运行是否产生冲突，同时保证与其它相关辅助系统进行有机地衔接，实现信息共享和传递，另外实现各种资源被集中、高效的管理，达到充分的共享。（2） 性能测试通过自309、动化工具模拟多种正常负载和超负载场景，对各项性能指标进行测试。通过模拟最终用户在实际中运用的特征，对系统进行性能测试，其目的都是为了保证整个业务流程高效运行，消除冗余，突破瓶颈。本项目是面向医疗领域多个方面的装备系统，各方面的性能指标也不尽相同，因此，需要提前设计并组织编写验证各典型业务流程的性能指标的测试设计书和相关验证数据，准备所需测试工具。如负载测试工具LoadRunner、性能测试工具WAS、性能测试和分析工具Weblode等。（3） 易用性测试主要是对功能的易用性、用户界面合理性和辅助系统的操控性等进行验证。保证舒适地和高效地与交互过程。（4） 兼容性测试兼容性测试验证包括对硬件的依310、赖程度，其他软件的依赖程度和已有系统之间的兼容等。硬件兼容性测试需要确认以下几点：最低配置是否能够满足系统运行的需要；在推荐配置下系统是否响应速度；考察软件对运行硬件环境有无特殊说明；为了满足不同的使用需求，软件系统能否运行在多种硬件配置环境下，并且系统功能和性能都能满足设计需求；打印机兼容性的测试对于操作系统、办公软件、网站和其他打印功能比较重要的软件来说，都是不可缺少的；对机型的要求和对CPU、内存、硬盘的要求，其他还包括对RAID的支持、对SCSI的支持等。需根据实际情况确定测试范围及测试方法。软件兼容性测试包括：与操作系统的兼容性，测试内容不仅包括安装，还需对关键流程进行检查；与数据库311、的兼容性，数据库兼容性测试要点有完整性测试、应用系统测试、性能测试；与中间件的兼容，中间件兼容性的测试通常情况下是指对不同版本、不同补丁包的兼容性；与浏览器的兼容性等。（5） 安装测试测试人员充分模拟运用场景的特征，和运行设备及网络连接的实际情况，部署设备并安装调试各平台。通过检测来验证安装、升级、卸载是否正常、是否会影响或潜在影响操作系统的正常工作，确保各平台运转流畅，从而保证系统的安装成功。测试人员在完成安装测试后，需编写系统安装手册和用户说明书，以用于示范推广。（6） 恢复测试验证系统从软件或硬件失败中恢复的能力。（7） 安全性测试验证各功能模块间数据存储、数据传输、接口的安全性问题，验312、证保护机制是否能够保护不受非法的侵入和使用。如需安全性测试工具，需提前进行准备。（8） 数据处理测试由于数据处理在程序中的重要位置，对完成专门特性的数据处理测试是必要的，包括数据采集、合并、转移、坏数据剔除和数据解释功能等。承担单位项目管理组质量管理部严格按照测试计划进行进度监控，收集、分析各种质量数据，并编写质量报告。质量经理负责编写测试报告。承担单位项目管理组质量管理则根据质量报告和里程碑报告，写版本发布判定报告，并提交给医院。3) 回归测试回归测试是未通过测试的程序在变更后，通过重复执行原先的测试用例验证原有功能是否正确。回归测试目的验证变更部分的正确性和对变更需求的符合性；以及验证原有313、的，正确的功能、性能和其他规定的要求，证明修改后的程序仍然满足规定的需求。回归测试有两方面的内容：验证更改后是否达到了预期的更改要求；证明修改对原有功能、性能没有损害。当项目各测试阶段的程序变更或发现BUG并修复后，都须进行回归测试。回归测试步骤具体如下：（1） 根据变更范围，选择适用的测试用例，如果时间、人员等比较充裕则选择原先所有测试用例；（2） 如果变更范围大，原先的测试用例不能满足变更后的范围，则有质量经理组织编写新的测试用例；（3） 执行测试用例；（4） 检查测试结果：（5） 将每个测试结果同所期望的结果比较，并记下任何差异；（6） 对不正确的测试结果，重新修改重复第3步和第4步，直314、到测试结果正确；（7） 无论任何时候程序有变更或被修改，重复步骤3和4。具体回归测试参见测试规程。4.8.3 质量保证质量保证活动的目的是监控项目和子项目的实施过程是否符合既定的计划、标准和规则。1) 项目过程质量保证项目过程质量保证活动通过建立整体的质量管理制度和总体质量目标，组织相关培训，为子项目过程质量保证提供管理依据和指导方针。项目过程质量保证工作包括：制定项目质量管理制度、确定质量目标、组织质量管理培训，指派质量保证人员等。具体活动见下图：相关利害团体管理信息安全图 质量保证表制定项目质量管理制度，即项目质量管理制度参照CMMI-DEV、ISO等国际先进的管理模型，结合项目实际情况制定。对子项目承担单位质量管理提供指导和参考。确定质量目标，即：（1） 甲方负责制定项目总体质量目标；（2） 承担单位项目管理组根据总体质量目标制定子项目的质量目标。组织质