《等级医院资料》第九章运维管理(1).pdf

《《等级医院资料》第九章运维管理(1).pdf》由会员分享，可在线阅读，更多相关《《等级医院资料》第九章运维管理(1).pdf（27页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、 8819 运维管理 9 运维管理 9.1 医院 IT 环境分析 9.1 医院 IT 环境分析 9.1.1 信息技术发展给医院带来的挑战 9.1.1 信息技术发展给医院带来的挑战 随着时代的发展和中国的入世， 医院信息化管理已成为衡量医院管理水平的标准之一，信息化管理已逐渐进入医疗卫生领域。根据中国卫生部的数据，目前全国有超过 90%的医院在信息化建设方面有不同程度的投入，有 40%的大中型医院尤其重视信息化建设，投入力度更大。即便如此，与信息化投入占医院总收入 2%4%的国际惯例相比，中国医院差距甚大，平均仅有 0.1%左右。 不同于别的行业，医院信息化不能止步于内部应用。按照目前国内外普遍

2、认同的划分方法，医院信息化一般要经历三个阶段：以人财物为中心的医院管理信息系统、以病人为中心的临床信息系统、以社区服务为中心的局域医疗卫生服务体系。 这些综合信息管理系统建立确保了医院信息化建设的正常开展， 但如此多的系统如何有效管理成为医疗信息化的新课题， 只有让众多综合信息系统良好运行才能保障医院正常提供各项医疗服务。随着 IT 技术的高速发展，医院信息化建设从基础网络建设，应用系统建设，逐步进入了一个应用和网络融合发展，网络和应用系统复杂度和规模不断成熟和扩大的时期，迫切需要通过有效地科学的管理，通过充分发挥历年建设的 IT 基础设施的作用，体现出 IT 技术能够推动组织的对外服务水平，

3、不断提升服务质量从而为医院带来巨大效益。 9.1.2 医院 IT 环境的复杂性及其问题 9.1.2 医院 IT 环境的复杂性及其问题 目前我国的医疗信息化正处在立足于医院管理信息系统， 并向以病人为中心的临床信息系统发展的阶段，临床信息系统系统仍是行业内关注医疗信息化时的重点。在 882过去十年里，在卫生部等领导机构的支持下，我国医疗行业的 CIS 系统建设已经步入了一个以开发采用 C/S 结构或 B/S 结构和 GUI 界面为主要标志的阶段。 而对于大部分医院而言，由于资金、信息化认知等众多原因，医院信息化建设并没有进行整体和长期的发展规划， 而是有着随医院医疗业务的不断发展和医疗信息化技术

4、的不断进步，逐步增加、逐步完善医院信息化的特点。这就导致了医院信息化环境日趋复杂。以下问题是医院 IT 环境日趋复杂的直观体现： 1）计算机和网络等各类基础设施来自于多年来各种项目的建设, 其资源信息分散，记录不完整，难以随时了解每台设备的各种详细信息，如使用、维修保修情况。众多的软件系统为多年来逐步实施，有自己研发的、所在地医保配套的、软件公司开发的，多种多样，具体应用分布分散，较难实现对各信息系统的运行状况进行全面统计、分析、判断。管理人员很难及时、全面地了解 IT 资源使用情况，系统管理决策能力不足。 2）没有明确的职责分工。对于大型信息管理系统，都不可能只由某一个人进行维护， 而在多人

5、组成的维护团队中， 由于没有明确的职责分工， 每个人好像什么都管，又好像什么都不管。没有人对问题进行跟踪，出了问题到最后可能是谁都不管。 3）没有制定维护优先级制度。在遇到一些问题集中发生时，没有合理地设定一个问题优先级，往往按照先后顺序来响应，对一些后发生而相对重要的事情，可能会延误。 4）统计信息反馈不及时。不能及时得到详实的统计信息，每个人各自记各自的，书写不规范，难免有遗漏，并造成统计困难。 5）无法进行故障的分析和预测。由于没有对故障进行记录和分类，无法对已发生的故障进行分析， 不能采取措施避免同类故障的再次发生， 更不能发现潜在的故障。 6）对维护人员的工作没办法量化，也就无法进行

6、合理的考核。无法衡量维护人员的绩效，无法评估在系统维护中的投入产出情况。 7）没有维护数据库，信息无法及时保存和共享。由于没有对维护知识和经验进 883行整理和共享，使得故障处理方法只由当时的维护人员掌握，相同的故障由不同的人员处理时还是从头开始，降低了工作效率。若关键岗位人员离职会影响工作的正常进行。 9.1.3 医院业务对于 IT 环境的依赖 9.1.3 医院业务对于 IT 环境的依赖 医院业务与其他行业相比， 具备其特殊性。 临床业务的开展直接与 “人命” 相关。随着医院业务和医疗信息化的不断发展，大部分医院实现了通过电子分诊、电子发药等 IT 系统开展医疗业务。利用这些业务系统，有效地

7、减少了患者的等待时间，加速了患者的就医流程，在一定程度上缓解就医难的问题。实施电子档案也为区域医疗信息的共享互认提供了条件，为缓解看病贵提供了解决问题的基础，依靠网络与电子系统作业，提高了工作效率，帮助病人节省了各个环节的等待时间。在此基础上，医院对网络与业务系统的安全、稳定运行提出了更高的要求。如果业务中断或暂停将会造成非常严重的后果， 因此医院最为核心关注的问题之一就是如何保障医院临床业务的 724 小时不间断、稳定的运行。随着医疗业务的不断扩展，医院信息系统越来越复杂，医疗业务对信息系统的依赖程度也越来越紧密，信息系统的任何波动，都会直接影响到业务的正常开展；信息系统如果崩溃，对于医疗业

8、务的影响将是致命的。因此，如何清晰的掌握系统的运行情况，把可能出现的故障消灭在萌芽状态，通过科学规范的管理保证医院信息网络的稳定运行， 为医院的核心业务提供可靠的技术支持服务，让业务部门满意，同时让医院信息部门的工作人员从忙于救火的角色中解脱，这是医院信息部门面对的问题。 基于上述分析，作为医院临床业务的 IT 支撑环境运维管理是医院信息化建设、管理过程中非常关键的问题。同时由于 IT 技术的发展以及医院 IT 环境的日趋复杂，导致医院 IT 运维管理的难度远远高于其他行业。 8849.2 建立医院信息平台的运维管理体系9.2 建立医院信息平台的运维管理体系 9.2.1 医院信息平台运维管理体

9、系的建设要求 9.2.1 医院信息平台运维管理体系的建设要求 IT 产业和信息化应用已经步入了深化、整合、转型和创新的关键时期，信息技术与信息系统对医院组织形态、治理结构、管理体制、运作流程的影响日益深化；医院对信息技术和信息系统的依赖性在日益加强；信息系统的安全、管理、风险与控制成为日益突出的问题；IT 与业务应用的融合，是未来发展的核心；信息化应用的关键是持续性、创造价值、风险与控制、整合、绩效管理。在这种发展时期，各种目光都聚焦在治理、审计、服务管理、风险与控制、安全等领域。这些领域正在为 IT 产业和信息化开辟新的天地， 成为 IT 产业和信息化在健康规范的轨道上运行的制度保障。 各个

10、医院都希望自己的 IT 系统能够 58 或 724 小时不间断运行，从而确保其上所承载的医疗业务系统正常使用。 为了保证 IT 基础设施整体全天候无故障运行的目标，需要构成这些系统的各软、硬件设施都能发挥其应有的作用。建立统一技术、统一管理的 IT 服务管理平台和统一的运维管理机制，透过规范化的管理流程和运维组织模式，实现对 IT 基础设施的集中监控和对 IT 资源的合理使用，为业务系统提供端到端的 IT 服务，从而提高 IT 服务管理质量和运维服务质量。从实际工作来看，我们认为主要应从以下三点来保障系统的无故障运行： 网络不断网络不断： 网络在 IT 系统中作为数据的载体， 保证医疗业务数据

11、向每个角落的延伸和可达性，网络的中断将直接影响医疗业务的正常运行，因此网络的畅通是医疗业务正常进行不可或缺的必要条件之一。 系统不瘫系统不瘫： 作为底层基础设施， 医疗业务系统同时担当着承载医疗业务和运行业务的重任，系统的正常与否也直接影响着业务的运行，所以保障医疗业务系统不瘫也是医疗业务正常进行不可或缺的必要条件之一。 数据不丢数据不丢：数据是记录医疗业务的核心资料，在医疗业务的进行中，确保数据的完整和有效性是 IT 管理的核心目标，数据的丢失将导致医疗业务造成重大损失。 8859.2.2 医院信息平台运维管理体系的搭建方法 9.2.2 医院信息平台运维管理体系的搭建方法 医疗行业信息化运维

12、管理需求和其他行业类似，同样是业务系统和 IT 基础设施的管理和服务。 医院信息平台运维管理体系的搭建， 总体上来说， 应遵循下面的步骤： 1）确定体系内容。 2）结合医院信息化运维现状和医疗资源约束条件或规划目标，形成重点突出、切实可行的管理策略。 3）定期回顾医疗业务的发展，持续改善。 9.2.2.1 建立医院信息平台运维管理体系的传统法 9.2.2.1 建立医院信息平台运维管理体系的传统法 传统法从组织、制度、技术三个维度展开： 1）组织上根据医院业务和发展战略进行针对性调整。传统按职能进行团队划分的模式都要求组织架构进行相应变革，要求根据流程进行角色安排，如一二三线技术支持等。总体目的

13、就是提升医疗工作效率，改进医疗业务的管理效果。 2）在医院制度维度上，要梳理运维工作的管控点、分析点，从而制订相关的制度进行行为约束。制订制度一定要考虑可操作性和可考核性，只有通过结合考核的制度才可能真正落实。因此在实现的操作中，可选择一些“制度点” ，逐步推进。 3）技术维度大体上有技术规范的制订、运维支撑体系的建立这两个方面。 技术规范主要针对运维客体（如医院信息技术人员、应用服务器、数据库、操作系统等等） ，建立诸如备份流程、双机管理、开发规范等技术标准。而运维支撑体系则是通过医院信息化系统来固化医疗业务流程，提升医疗流程效率。 9.2.2.2 建立医院信息平台运维管理体系的 PPT 法

14、 9.2.2.2 建立医院信息平台运维管理体系的 PPT 法 在医院信息平台的运维管理过程中，其底层的基础为 IT 服务管理。IT 服务管理主要包含三个层面：人（医院 IT 运维人员） 、流程（医院就诊流程，检验流程，检查流程，付费流程等） 、技术（网络技术、操作系统技术等） 。如下图所示 图9-1 IT服务管理的核心组成部分 ? 人员 People 是指医院需要清晰定义 IT 支持人员的角色职责，明确人员的技能等级，进行 IT部门内部的梯队建设。IT 支持人员的素质与质量最终决定了整个 IT 服务管理实施的质量。 ? 流程 Process 是指业务流程是一个逻辑群组的活动，有规律地为医生、护

15、士以及管理者提供可重复性的业务功能；有明确的流程目标;能达到预期的效果；流转结果可度量； ITIL是成熟的流程模型，医院能通过流程来实践这些最佳实现方式。 ? 技术 Technology 是指有效的技术手段，可以保证医院做到： 监控 IT 系统（如 HIS、LIS、PACS、EMR、财务系统、OA 系统等）的可用性以及实时性能；监控医院网络中心实现 SLA 要求的质量；配置管理，并跟踪 IT 系统配置的变化；诊断，快速定位问题原因并对症下药；预测与预防，预测资源的使用情况，并能采取相关的预防措施；提供仪表盘，以可视化的方式展现医院 IT 服务模型、IT 服务报表与指标、网络拓扑等，让领导更方便

16、地了解 IT 系统现状，并做出决策。 8869.2.2.3 建立医院信息平台运维管理体系的要素法 9.2.2.3 建立医院信息平台运维管理体系的要素法 以下是搭建医院信息平台运维管理体系的五要素法： 图 9-2 组成运维服务管理体系的 5 个要素的详细组成及其相互作用 9.2.3 医院信息平台的运维管理体系架构 9.2.3 医院信息平台的运维管理体系架构 图 9-3 医院信息平台的运维管理体系架构 887 888? 医院信息平台 IT 基础设施 此部分为医院信息平台运维管理的最基础环节，同时也是所有 IT 服务的最核心对象。主要包括主机系统（终端、服务器、操作系统） 、存储系统（DAS/NAS

17、/SAN 等） 、网络环境（基础网络，内外网环境、Internet 等） 、安全环境（防火墙、IDS/IPS、流量控制、防毒防攻击等） 、业务系统（HIS/LIS/PACS/EMR 等）中间件、数据库环境以及各种设备及系统的配置参数。 ? 日常运维管理的核心内容 主要是指基于 CMDB(配置管理数据库)进行 IT 环境的事件、问题、变更、发布、配置等服务行为进行统一的管理。为了能够保障上述服务行为的有效执行，必须从两个方面进行保障：全面的监测体系、流程控制。 ? 日常运维管理的目标 通过有效的运维管理实现医院信息化的三大目标：保障 IT 系统的稳定运行及效率、从容应对各类紧急事件、合理的 IT

18、 系统架构设计。 9.2.4 医院信息平台的基础设施管理 9.2.4 医院信息平台的基础设施管理 随着信息化建设的推进， 为了让凝聚了巨大人力物力投入的信息基础设施发挥出其效益，保障整个信息系统的平稳可靠运行，需要有一个可从整体上对包括服务器、网络，存储，安全等组件在内的 IT 基础设施环境进行综合管理的平台，并能够提供业务系统运行异常的实时告警和进行图形化问题定位，性能趋势分析和预警，能够基于关键业务系统的角度，以业务重要性为导向进行事件处理和通知。 医院信息平台是一个包括了众多软件，硬件技术，涉及多厂家产品，从网络、安全、存储、计算到中间件和应用的复杂异构环境。而且随着信息建设的深入和持续

19、优化和发展，这个复杂庞大的基础设施，还会随之不断进行演进，在产品，技术和网络结构，业务关系上不断发生变化。因此，要求针对该环境进行管理的系统具有良好的可扩展性，能够将下层网络的复杂度有效的通过抽象屏蔽起来，向上层应用和运维流程开放稳定的接口。 8899.2.4.1 医院信息平台的运维管理系统设计原则 9.2.4.1 医院信息平台的运维管理系统设计原则 从综合 IT 监控管理技术的发展来看，有以下几个关键的选择指标是在进行方案构建和产品选择的时候需要重点考虑的： ? 可视化能力 可视化能力 建设 IT 运行监控中心的一个关键用途是与大屏幕监控中心配套，实现最佳的展示效果，体现信息化的建设水平和理

20、念高度。因此可视化的效果如何，动态呈现的能力如何，就成为系统和方案选型中的一个核心考虑要素。 ? 业务建模能力 业务建模能力 作为每个组织的 IT 维护工作，都有自己的核心业务。这些核心业务具有不同的重要性、组成结构，服务于特定的部门和用户。我们关注其不同的运行指标，这些个性化的管理需求，能否快速的，通过图形化的建模方式加以实施，并迅速在管理视图上得到反应，是非常重要的一个维度。 尤其需要避免的，是为了跟随组织的业务变化和 IT 系统演进，而大量的定制和重复开发，往往带来难以接受的实施周期和后续成本。 因此，系统可配置性如何，图形化的业务系统架构和监测体系建模功能如何，需要着重考虑。 ? 实施

21、周期 实施周期 目前有大量的 IT 运维流程管理产品，囊括了从综合监测到业务流程管理的所有方面， 这些产品都集成了许多流程组件、 工作台组件、 知识库组件等。 但是我们知道，流程是一个个性化非常强的东西。 每个组织都有自己独特的 IT 管理体系和业务流程。简单的一次性照搬产品化流程系统，容易给我们带来削足适履的麻烦；长期而言可能带来很长的学习曲线和调整，并导致实施和维护成本的上升。 而我们实施运维管理系统的目的，无非是为了更好的提升核心业务的维护质量，围绕这个目标，能否有一个有效，清晰，简洁的管理机制，并可以与逐步建设的工作 890流程通过 SOA 架构方便的集成，是从实际部署来看，成功率更高

22、，更容易产生效果的建设思路。 ? 设备兼容性 设备兼容性 要简化管理。首先，要能够全面的管理各种基于 IP 的信息化基础设施，这是一个基础。 因此， 系统要能够兼容国内各种主流的软硬件产品， 包括网络设备， 服务器，应用，中间件和环境等。要具有比较良好的网络层和链路层自动发现能力，具有自动发现主流应用和中间件的能力。从而最大化的降低管理人员对管理信息的维护工作量。 ? 体系结构的开放性 体系结构的开放性 当前 IT 管理环境中，SSO 单点登录和与流程管理工作系统，门户等应用的集成，成为常见的需求，而当前最佳的集成方式，就是基于 SOAP 协议的 Web Service 接口，通过规范标准的接

23、口定义，就可以实现与其他主流门户和流程系统的集成。在集成能力上，因此也是关注的一个重点。 9.2.4.2 医院信息资源统一监控平台系统架构及技术实现 9.2.4.2 医院信息资源统一监控平台系统架构及技术实现 9.2.4.2.1 系统逻辑架构 9.2.4.2.1 系统逻辑架构 从软件体系结构角度看，系统可以分为以下四层： 数据采集与代理：数据采集与代理：本层由各种协议适配器构成， 向上层提供统一的接口访问管理协议栈（SNMP/CMIP/TL1 等） ，获取管理信息（包括事件信息、日志信息、性能信息和拓扑信息等）,并在初始发现时作为驱动模块构建信息模型。 数据汇聚：数据汇聚：对底层数据采集的数据

24、进行统一的描述，组织为管理信息库。向上提供一个统一的管理语义和调用接口。使得各个业务模块面对统一的数据模型，使得对资源的管理方式一致并处于单一的可控路径下，方便对资源进行权限管理，互斥访问等操作，使得面向事务的并发管理成为可能。 数据处理层：数据处理层：专注于管理业务的实现，不再关心底层协议的差异性。响应前台应 891用的请求，完成数据查询，处理等功能； 数据展现层：数据展现层：前台界面，从数据处理层得到数据加以显示。是管理员与网络管理系统的接口。 9.2.4.2.2 架构设计思路 9.2.4.2.2 架构设计思路 按照功能需求规格来决定主要软件模块的划分。将整个软件系统分为四层：数据采集层，

25、 数据抽象层， 数据处理层和数据表现层； 每一层的功能依托于下一层的实现，一般不作跨越功能层次的调用。 利用分布式总线实现各个模块之间的通信。模块之间通过接口，利用消息总线进行互操作。 总体设计上先决定功能模块，然后按照功能模块设计其服务接口；按照功能模块特点和数据流量以及流向决定其部署方式和通信方式；按照性能需求和对移植性、开发强度的综合考虑决定中间件和对象服务的选型。 9.3 医院信息化平台的 IT 服务管理 9.3 医院信息化平台的 IT 服务管理 信息技术基础设施库(ITIL)作为 IT 服务管理(ITSM)最佳实践的事实标准， 成为了解及衡量 IT 服务价值的重要渠道。在医疗行业中，

26、尽管全球存在差异化的应用环境，但是许多医院的 IT 部门都在开始部署 ITIL，来提升 IT 部门服务医院内部各项业务的质量和性价比， 并通过此途径来打造医院的核心竞争力、 提升医院各方面收益。 ITIL 是在这样一个事实被普遍认可的情况下开发出来的， 即组织正日益依赖于 IT 来实现其业务目标，这种目标在医院信息化过程中正在逐步展现。这种逐渐加深的对 IT 的依赖使得组织对与其目标相关的、可以满足客户需求和期望的高质量 IT 服务的需求也越来越强烈。在过去的几年中，人们关注的焦点已经从开发 IT 应用系统转换到对 IT 服务进行统一的管理上来了。在医院中，一个 IT 应用系统(有时是指信息系

27、统)只有在满足以下两点时才会有助于实现医院的目标：第一，该系统可以被医院充分利用；第二，当系统产生故障或需要进行必要的修改时，可以得到维护和 892运营管理的有力支持, 即 IT 系统利用率以及系统运维及故障恢复时间。 现阶段，在整个 IT 产品的生命周期中，运营阶段占了整个时间和成本的约 70至 80，其余的时间和成本花费在产品开发(或采购)上面。医院也是如此，由于IT 环境的复杂，有时甚至要高于这个比例。因此，具有良好效果和效率的 IT 服务管理流程对于 IT 的成功运用是至关重要的。 这些 IT 服务管理流程适用于任何类型的医院，而不论其是大规模的还是小规模的，公立的还是私立的，使用集中

28、的 IT 服务还是非集中的，以及使用内部供应的 IT 服务还是外包 IT 服务。在任何情况下，服务必须具有可靠性、一致性和高质量，并且其成本也应当是可接受的。 IT 服务管理主要涉及对为满足组织需求而定制的 IT 服务的交付和支持。ITIL 被开发出来也是为了系统和一贯地推广得到证明的 IT 服务管理最佳实践。这种方法主要基于服务质量理念和开发有效且高效的流程的理念之上。 基于 IT 基础设施，ITIL 为 IT 部门的所有活动提供了一个通用框架，这些活动是服务交付的一部分。这些活动被划分为不同的流程，当这些流程协同运作时，可以提供一个有效的框架从而可以使得组织的 IT 服务管理更加成熟。 这

29、些流程中的每一个都包括了一项或多项 IT 部门的任务，如服务开发、基础设施管理、服务交付和支持等。这种流程的方法使得有可能独立于组织架构而描述 IT 服务管理最佳实践。 医院信息平台的运维管理过程中，在 IT 基础设施统一管理基础之上，在日常的运维过程中需有一套完善的服务管理体系支撑， 才能够保障医院 IT 信息平台的稳定、可靠、高效运行。为了便于理解和实施，后续将对 IT 服务管理的 6 大组件，包括服务台、事件管理、问题管理、变更管理、发布管理、配置管理等结合医院信息化平台进行简单描述。从而帮助医院建设一套完善的信息化运维服务的管理体系和流程。 事故管理工具事故变更管理事件请求，需求服务台

30、客户调查报告事件管理发布管理发布配置管理变更沟通、更新和权益措施业务、客户、用户问题管理 图 9-4 IT 服务管理体系 9.3.1 服务台 9.3.1 服务台 服务台是 IT 部门与业务部门的单一联系点， 在运营层面上具体实现了 IT 与业务的融合。 IT 与业务在运营层面上的融合具体体现为： IT 要支持业务的持续运作、按照服务级别协议规定排序用户的要求，最大化业务的需求（如同时发生用户不能打印和交换机出现问题影响计费系统时， 服务台必须对二者根据影响程度和紧迫程度按优先级对用户反馈的意见进行排序，确定处理的优先级，以最大化业务的需求） 。 9.3.1.1 服务台的主要职责 9.3.1.1

31、 服务台的主要职责 服务台（Service Desk）及事件管理（Incident Management） ，它的用意在于加重第一线支持的功能， 并赋予它更广泛的角色在使用者第一次通报的时候就实时把问题解决，增加事件解决的比例，让 IT 部门能更专注于医院业务目标的达成，提供高品质的支持，进而提高使用者满意度。服务台是一个功能 (Function) ，它没有严格定义的执行流程，它与多个服务管理流程密切相关，为用户提供与问题、变更、服务级别、发布、配置、 IT 服务持续等管理的接口，它是提供高效率的 IT 营运服务所不可或缺的关键。 893 894服务台的任务包括作为与使用者及顾客的单一联络窗口

32、， 接收并记录所有使用者的电话，处理使用者相关的事项及抱怨，解决事件或将事件升级请求二线支持，通知使用者及顾客事件状况，并制作相关管理报告。 具体而言，服务台的主要职责是： 1）接受客户请求（可以通过电话、电子邮件和传真等） ； 2）记录并跟踪事故和客户意见； 3）及时通知客户其请求的当前状况和最新进展； 4）根据服务级别协议，初步评估客户请求，尽力解决它们或将其安排给有关人员解决； 5）根据服务级别协议的要求，监督规章制度的执行情况并在必要时对其进行修改； 6）对客户请求从提出直至终止和验证的整个过程进行管理； 7）在需要短期内调整服务级别时及时与客户沟通； 8）协调二线支持人员和第三方支持

33、小组； 9）提供管理方面的信息和建议以改进服务品质； 10）根据用户的反馈发现 IT 服务运作中产生的问题； 11）发现客户培训和教育方面的需求； 12）终止事故并与客户一道确认事故的解决情况。 9.3.1.2 服务台的构建模式 9.3.1.2 服务台的构建模式 1）集中式服务台 集中式服务台是指由一个物理上集中的服务中心统一处理所有的服务请求。 这种 895模式的优点是：降低总体运作成本；管理控制上得到了加强；提高了资源利用率。 该模式最适合于 IT 部门既负责提供服务，又负责为服务提供支持的情形，服务台负责接受、记录、监督和升级所有的服务请求，同时也起业务运作支持的作用。 2）虚拟式服务台

34、 虚拟式服务台，能够不受时间和地点限制提供支持服务。 Web 技术是为实现虚拟服务台提供了很好的技术支持。提供的服务可以包括：服务推广、与使用者及顾客沟通的渠道、提供供货商修正程序下载、已知问题告知、通知注意事项、系统公告、使用手册、常问问题解答、每周每月管理报告，服务指南及知识库查询。目前的工具软件可以提供范例 Web 网站、常见问题解答、报告、通知使用者及顾客状况电子邮件这些功能，甚至能够个人化。 9.3.1.3 评价服务台的关键指标 9.3.1.3 评价服务台的关键指标 （1）电话应答是否迅速（如 90 的呼叫在 X 秒内被应答） ； （2）呼叫是否按时转送给二线支持； （3）是否按时恢

35、复服务； （4）是否及时通知用户目正在实施的变更和将来需要实施的变更； （5）首次修复率。 （6）服务台员工接电话是否有礼貌； （7）用户是否得到预防事故发生的建议。 9.3.1.4 服务台的工作流程 9.3.1.4 服务台的工作流程 电话请求邮件请求传真请求硬件及应用事件网站请求问题识别和登记初始支持解决、恢复关闭调查/诊断解决/恢复解决/恢复调查/诊断服务请求是否解决是否解决是否解决服务请求步骤否是否是否是是 图 9-5 服务台流程 9.3.2 事件管理 9.3.2 事件管理 事件管理（Incident Management）又称突发事件管理，是一个被动型的任务，也就是减少或消除存在或可能

36、存在与 IT 服务中的干扰因素给 IT 服务带来的影响， 以确保用户可以尽快回复自己的正常工作。因此，要将事件（Incidents）记录下来并分类，再分配给适当的专业人员去处理；监控事件的发展；并在事件得到解决后将其终止。 核心设备出现故障，应用系统受到攻击等等，这些突发事件如果发生，信息部门如何处理而不耽误医疗业务开展， 这是需要迫切解决的问题。 建立突发事件管理流程，如核心设备冗余系统，灾备系统、安全防护系统，灾难发生时的紧急起用备用系统等等，才能有效的处理突发事故，把损失和影响降到最低。 医院信息平台的事件管理目标是要在给医疗工作人员和医院正常的业务活动带来最小影响的情况下，尽快回复到正

37、常服务级别。事件管理需要保留事件的有效记录以便能够权衡并改进处理流程， 给其他的服务管理流程提供合适的信息以及正确报告 896 897进展情况。 9.3.2.1 事件管理的流程 9.3.2.1 事件管理的流程 （1）事件检测与记录 事件检测与记录步骤是事件管理流程的起点。该步骤的目的是快速、准确地探测和捕捉所有在 IT 生产环境中发生的错误，并在将来的问题管理流程中帮助确定问题和解决问题。在本步骤中，将收集创建一个事件单所需要的信息，重点是准确、完整地记录必要的信息。 （2）事件分类与初步支持 该步骤包括：为了对医疗工作人员的请求进行分析而进一步收集信息。该步骤的目的是对每个事件进行正确的分类

38、， 随即在现存的知识库中查询与该事件相匹配的条目。 若没有找到合适的解决方案或变通方法，则该事件需要转派给一线组长，后者根据知识库判断该组员是否能够处理该事件，能够处理的返回该客服组员进行处理。对于不能处理的事件，客服组长判断是属于应用、系统还是设备方向的事件，提交二线组长，由二线组长再根据实际情况分配给一个具有合适技能的事件分析员。 在处理过程中，事件记录员需要根据处理的情况详细记录整个处理过程和结果，记录信息应与实际情况一致。若根据当前已有知识库条目能够解决事件，则在解决完事件后，在事件单中记录和填写故障根源和解决方案。若解决方案比较复杂，还需附上附件。 （3）事件调查和诊断 这个步骤阶段

39、的目标是进行深入的调查，以解决事件。各个技术水平的事件分析员（二线人员）将会参与寻找一个解决方案或变通方案。若事件分析员（二线人员）认为该事件根据知识库条目或其他常规方式能够解决， 则返回一线事件记录员进行解决与恢复。若通过调查和诊断还是不能解决事件，可能需要问题管理流程也参与进来进行更加深入的分析研究。 一线事件记录员应及时跟踪事件的整个处理过程，并适时向用户说明处理情况。 （4）解决和恢复 这个步骤尝试使用解决方案和变通方法来解决事件。某些情况下，需要引入变更管理来批准评估实施步骤。 事件解决完毕后，二线支持人员需要依据解决情况创建知识库条目，并进行等级划分，然后定期对一线人员进行新知识库

40、条目的培训。 （5）事件关闭 这个步骤确保客户对事件的处理情况感到满意。这里分两种情况，若是用户提出的事件，则所有工单关闭前都需要征得用户同意；若是监控发现的事件，则在解决后直接关闭。 （6）监控事件 这个步骤监控目前尚未解决或正在解决的事件，它由事件单创建时开始，在事件单关闭时结束。这个步骤目前基本上是由一线组长人工来执行，只有触发升级策略才会由后台工具发出邮件通知。 9.3.2.2 事件管理的流程图 9.3.2.2 事件管理的流程图 图 9-6 事件管理流程 898 8999.3.3 问题管理 9.3.3 问题管理 问题管理的责任是调查和分析 IT 基础架构和查找事故产生的根本原因。问题管

41、理强调找出事故产生的根源，从而制定恰当的解决方案或防止其再次发生的预防措施。 建立问题管理流程，把存在的问题的现象、问题原因、解决方法记录下来，有利于从根本上解决问题，杜绝同样问题的再次发生。采取主动性问题预防措施，从而能消除或减少信息系统中故障的发生。 在记录问题时，必须对问题进行优先级/影响度分析，以对问题有效分配必要资源和解决时限。问题记录必须有规范的格式，从而在转派或解决过程中能得到有效更新和统一认识。提高解决问题的效率。 9.3.3.1 问题管理的流程 9.3.3.1 问题管理的流程 （1）问题检测与记录 本步骤的主要目的是识别问题（主动或是被动） ，创建问题单以及对问题进行严重等级

42、的判断。 （2）问题分派 这个步骤首先将问题分派给 IT 部门中的分析员，然后这个问题分析员将开始收集数据判断这个问题是否可能解决， 然后该问题分析员对应的业务岗位的支持组组长开始跟踪问题解决的整个流程。 （3）问题调查与诊断 该步骤确定了问题信息的来源，对数据进行分析，找出问题的根本原因。 （4）问题解决 本步骤的目的是为成为“已知错误”的问题提供一个最终的解决方案，或者临时的变通方法，并进行实施。并且需要引入变更管理流程来完成解决方案的实施。 （5）问题关闭 这个步骤确保问题的处理情况令人满意。问题单的信息是正确、完整的，处理过程中的经验能够得到记录以形成可重用的知识。 9.3.2.2 问

43、题管理的流程图 9.3.2.2 问题管理的流程图 图 9-7 问题管理流程 9.3.4 变更管理 9.3.4 变更管理 变更管理是在最短的中断时间内完成基础架构或服务的任一方面的变更而对其进行控制的服务流程。 医院的各种信息系统，由于外部政策的变化和内部发展的需要，各部门在应用过程中根据自身的需要提出各种需求。 因此， 不同时期， 不同考核制度， 不同核算方法，要求信息系统必须根据需要变更。 网络的拓展、 硬件的更新使网络配置系统发生变更。这些变更如果没有记录在案，将会影响下次问题的处理，甚至造成突发事件。因此，建立基于 ITIL 的变更管理和版本管理， 可以确保系统更改后上线的可靠性和准确性

44、。 变更管理流程设计主要考虑下面三方面： 900 9011）变更原因、变更影响、变更紧急度。 2）设计以下主要角色:变更请求者、变更受理者、变更审批者、变更实施者、变更管理流程负责人。 3）确定变更的主要活动和流程，并建立变更实施管理档案。 9.3.4.1 变更管理的流程 9.3.4.1 变更管理的流程 （1）接受变更请求 所有变更请求，都需递交到医疗 IT 部门负责人手中，供评估和批准。 评估变更分类、变更级别等，确定与变更相关的人员，并对常规变更进行实施； （2）变更请求分类和登录 通过分类，确定该变更请求的批准人和领导执行人，并确定是否是紧急变更，紧急变更适用同一流程但将得到快速批准和实

45、施。 （3）提交变更请求到变更顾问委员会（CAB）进行评估，确定影响度 医疗信息化部门负责人将根据特定的变更请求成立特定的 CAB，成员包括对该变更的评估和批准提供应有附加价值的技术人员和管理人员。评估工作包括技术可行性，对容量的影响，对现有服务的影响，资源需求等。 （4）批准变更请求 医疗信息化部门负责人确定对该变更请求有批准权的专家参加 CAB，必要时参与评估。评估后该负责人根据判断决定是否批准变更请求。 （5）检查变更计划测试结果，并批准实施 医疗信息化部门负责人确定合适人员主管该变更并参与 CAB， 称为变更主管。变更请求得到评估和批准后，变更主管安排相应资源进行变更的构建开发，然后需

46、 902要对将要实施到医疗业务环境的变更进行测试，并制定实施计划，随后提交测试结果和计划给负责人以获得实施。 负责人必需要确保测试结果和计划都有文档记录和得到签署，并确认变更对医疗业务环境没有影响或影响可以得到控制。这一步骤为变更流程的关键质量检查点。 （6）规划变更请求 变更请求一旦获得批准，它必须根据资源和其他情况进行规划，确定实施日期，分配相应资源，并通知请求人。 （7）协调变更实施（Coordinating the change implementation） 一切就绪后，可以实施变更。建议医院的计算机中心运维组实施相应变更，变更经理监视实施过程，并在必要时进行协调。 （8）更新变更状

47、态 在整个变更过程中，变更的状态从登记，评估，回顾到最后关闭是不同的。变更经理负责更新预先定义好的变更状态。 （9）回顾和关闭 实施变更后，负责人负责从技术和流程角度去回顾变更，该回顾在预先定义好的时间段针对变更单独进行，除确保变更请求得到了预期效果外，也寻找流程的改进机会，如资源计划和实际使用的一致性。确定是否满足了变更目的，有没有副面影响，否则需制定后续行动计划。随后，负责人负责利用预先定义好的结束状态关闭变更请求。 （10）总结汇报 向医院管理层提供流程报表，向医疗工作人员提供变更的相关执行信息。定期向相关小组部门根据流程衡量标准汇报很重要，只有如此，才可以基于现有环境的最新信息，作出进

48、一步的改进建议。 （11）变更会议 负责人负责定期或不定期召开变更会议，以在 IT 内部以及与医疗工作人员就变更管理有一个好的沟通。 在会上， 可以传递如， 最近变更规划， 将要实施变更的信息，也包括对变更流程的反馈和建议等。 （12）变更流程回顾 建议定期回顾变更管理流程以提高效率和效能，在实施变更流程不久之后，可以进行第一次回顾，以确保流程得到正确实施并起到预期目的，发现的问题必须追根溯源并尽快解决。之后，可以定期举行正式的回顾如每三个月。 9.3.4.1 变更管理的流程图 9.3.4.1 变更管理的流程图 图 9-8 变更管理流程 9039.3.5 发布管理 9.3.5 发布管理 发布管

49、理是对经测试后的新增或修改的配置项导入实际运行环境所进行的分发和上线的管理过程；它采用一种项目规划的方法来实施变更，处理变更所涉及的所有技术和费技术方面的是想，即关注变更的实施，而且主要应用于软件方面的发布。 9.3.5.1 发布管理的目标 9.3.5.1 发布管理的目标 发布管理的目标如下： 1）要通过正式的过程来确保医疗业务环境的质量 2）确保软硬件组件的发布经过计划和协调； 3）确保与变更相关的硬件和软件是可追溯的和安全的；只有正确的、经过批准和测试的软硬件版本才能导入实际运作环境； 4）确保每项发布都更新到了配置管理数据库中，并在最终软件库中也得到更新。 9.3.5.2 发布管理的流程

50、图 9.3.5.2 发布管理的流程图 图 9-9 发布管理流程 904 9059.3.6 配置管理 9.3.6 配置管理 配置管理是网络系统基础架构控制中心。也是医院信息系统稳定运行的保障。建立统一完整的配置管理流程及管理范围， 使配置管理流程成为医院信息部门的唯一进行配置管理的功能流程。 建立网络主服务器、网络系统、存储、IT 设备的基础配置信息库。建立相应的流程机制来更新和保持配置信息的完整性和正确性。 配置管理可以为信息系统运行过程中可能产生的突发事件、 疑难问题等提供准确的网络基础架构配置信息，可以帮助技术人员迅速对问题原因进行分析，并确定解决方案。 同时，通过建立配置管理流程，使维护