数据库系统整改对医院信息化系统的影响.docx

数据库系统整改对医院信息化系统的影响
目录刖百1
1 .医院信息化建设之系统1.数据库系统整改类型5
1.1 .数据库软件版本升级6
1.2 .数据迁移6
2. 3.参数及环境的变更6
1. 4.数据类型的修改和重定义6
2. 5.历史数据归档7
3. 6.访问优化性整改7数据库系统整改测试7
3.1. 整改目标测试8
3.2. 功能测试8
3.3. .性能测试8
3. 4.平安测试9刖三
数据库系统整改是指对数据库系统的软硬件运行环境进行调整的过程。数 据库系统在其生命周期过程中都会经历大大小小的整改，对业务的影响大小不 一，通常情况下都需要关闭业务后进行。对于连续性要求极高的医院信息化系 统，数据库系统整改影响较大，这就要求整改过程要做充分的准备，并且进行 有效的测试和确认，还要有可行的回退机制。
1.医院信息化建设之系统
我国的医疗信息化建设已经初具规模，后续还有非常大的开展建设空间。 国内医院的数字化建设进程以区域卫生信息平台、国家卫生信息化"3521工 程”框架提出的基于电子健康档案、电子病历和三级信息平台的居民健康卡工 作为中心正在加速推进，市场中逐渐成长了一些服务于医院信息建设为主软件第1页共9页 品牌，(品牌略，防止广告之嫌)从一线城市到乡镇卫生院，医院数字化程度 不断提高。
新医改方案中，中央政府正式提出建设城乡居民基本医疗卫生保健制度的 四梁八柱架构，新医改政策不仅明确了未来的目标和方向，最为重要的是每一 个环节都对信息技术的应用提出了更高要求，包括建立实用共享的医药卫生信 息系统，逐步实现互联互通；以建立居民健康档案为重点，构建乡村和社区卫 生信息网络平台；以医院管理和电子病历为重点，推进医院信息化建设。
以下是信息化建设中所涉及各的比拟常用软件模块，在以适应自身开展为 前提，酌情选择。
1 .门急诊医生工作站系统
2 .病区医生工作站系统
3 .住院护士工作站
4 .电子病历(EMR)系统
5 .实验室信息系统(LIS)
6 .心电图信息系统
7 .超声影像信息系统
8 .手术麻醉信息系统
9 .重症监护信息系统
10 .放射科信息系统(RIS)
11 .病理科信息系统
12 . PACS 系统
13 .临床决策支持系统(临床路径)
14 .门急诊导医系统
15 .门急诊挂号系统
16 .门急诊划价收费系统
17 .门诊分诊系统
18 .门诊输液管理系统
19 .门诊采血管理系统
20 .住院病人入，出，转管理系统
21 .药库管理系统第2页共9页
22 . PI VAS
23 .门急诊药房管理系统
24 .住院药房管理系统
25 .制剂管理系统
26 .药品会计系统
27 .护理信息系统
28 .病案管理系统
29 .医疗统计系统
30 .人事工资管理系统
31 .会计核算系统
32 .经济核算系统
33 .固定资产管理系统
34 .物资材料管理系统
35 .医疗管理与质量监控系统
36 .医院办公自动化系统
37 .医学文献管理系统
38 .数字化图书馆
39 .远程医疗（教育）系统
40 .门诊医技系统
41 .门急诊留观管理系统
42 .住院医技系统
43 .移动医生工作站
44 .移动护士工作站
45 .合理用药咨询系统
46 .药品配液系统
47 .门诊一卡通管理
48 .门急诊划价收费系统
49 .物资管理系统
50 .设备与固定资产管理系统
51 .物价管理系统第3页共9页
52 .物价公示系统
53 .本钱核算系统
54 .绩效考核系统
55 .薪酬管理系统
56 .血库管理系统
57 .院感管理系统
58 .营养膳食管理系统
59 .供应室管理系统
60 .医务科管理系统
61 .护理管理系统
62 .病人随访管理系统
63 .门急诊应急系统
64 .医疗统计系统
65 .院长综合查询系统
66 .患者满意度评测系统
67 .系统维护管理系统
68 .医疗保险接口系统
69 .病案管理系统接口
70 .医院信息集成平台接口系统
71 .科教管理系统
72 .财务系统集成
73 .掌上医院
74 .数字签名系统
75 .医保控费系统
76 .数据仓库及数据挖掘展示
77 .GIS信息展现系统
78 .卫生资源管理（绩效考核）
79 .疾病上报系统
80 .患者公众服务
81 .预算管理系统第4页共9页
82 .消毒供应管理系统
83 .客户关系管理系统
84 .婴儿防盗系统
85 .床边患者服务系统
86 .医疗废弃物管理系统
87 .输血管理系统
88 .血透管理系统
89 .中医临床研究分析系统
90 .中医辅助诊疗系统
91 .中医特色治疗管理系统
92 .名老中医经验传承系统
93 .内镜管理系统
94 .手术视教系统
95 .阳光用药系统
96 .单病种管理系统
97 .停车场管理系统
98 .门禁管理系统
99 .视频监控系统
100 .网络运维系统
101 .机房环境监控系统2.数据库系统整改类型
对于数据库系统整改的分类可以按停机时间长短来分类，如需要超过半小 时停机的整改，还有需要半小时以上的整改；也可以按改动的大小来分类；也 可以根据整改的具体类别来区分，本文侧重介绍数据库系统的整改具体类别。 一般来说数据库系统的整改可分为数据库软件版本升级，服务器和存储割接导 致的数据迁移，数据库参数、操作系统参数及其他配置参数的变更，数据类型 的修改和重定义，历史数据归档，访问优化性整改六大局部。
第5页共9页
2.1. 数据库软件版本升级
作为最常见的数据库系统变更类型，数据库软件版本的升级是最为典型 的，通常来说软件版本的升级影响最大，不可预知的因素最多，需要的测试工 作量最大，回退的难度也是最大的。一般来说如果不是特别的需求，都不会轻 易变更数据库系统软件的版本，只有当数据库软件已经超过官方支持期限而且 又遇到很多bug而必须升级，或者是应用软件的升级需要数据库软件也要进行 升级时才进行数据库版本的升级。数据软件版本的升级需要进行严格的测试并 且选择停机时间最短的数据迁移方式，对于实施方的技术要求较高，一般情况 下是作为工程形式由第三方公司进行。
2. 2.数据迁移
数据库系统在使用生命周期过程中可能需要进行屡次的数据迁移。数据迁 移的原因很多，如数据库软件版本的升级就可能造成数据迁移，最常见的是由 于服务器和存储割接造成的数据迁移。一般来说由数据库软件版本的升级造成 的数据迁移可以归为第一种类型，而我们常见的由于服务器和存储割接造成的 数据迁移如果不涉及数据库软件版本和操作系统平台的变化，其实施难度还是 要小于前一种的。此类的数据迁移最需要关注的是数据迁移的时间，如何减小 停机时间是考虑的关键。
3. 3.参数及环境的变更
数据库系统在使用生命周期过程中经常会遇到数据库参数或者操作系统参 数以及其所在的环境的变更，例如将数据库参数修改成更大的值以优化性能， 修改操作系统的参数以优化内存和I/O性能，增加数据库的组件模块等。此类 的修改通常变更难度较小，而且回退也最为容易。
3.4. 数据类型的修改和重定义
数据类型的修改和重定义在数据库系统的使用过程中非常常见，尤其是应 用系统还在完善过程中及应用升级都会需要。对于数据类型的修改和重定义大 多都可以在线进行，不需要系统停机，有时仅需要暂停局部受影响的业务。通 常情况下此类修改由应用开发商负责测试和实施，医院信息科需要对其进行监 督，要求其必须在测试环境上进行全部的修改和重定义测试，只有经过确认后第6页共9页
才能在正式环境进行变更，千万不能因为修改的动作小而放任应用开发商自行 处理变更。
3.5. 历史数据归档
当医院的数据库系统经过五年乃至更长时间的使用后，会沉淀很多历史的 数据，这局部历史数据通常情况下访问的次数相对已经很小，如果不进行迁移 就会因为数据库过于庞大而影响表的访问效率。对于影像系统此问题更为突 出，由于存储空间缺乏而面临必须归档的局面。但由于国家法律对医院病史病 案及病人影像图片的保存时间有要求，又不能直接删除掉历史数据，这时候需 要必要的手段进行历史数据的归档。对于历史数据的归档，在数据库层面和存 储硬件层面有很多成熟的技术方案可供参考。通常医院数据库系统的历史数据 归档需要作为一个单独的工程实施。对于仅将个别表的数据进行归档的需求， 作为日常的普通变更来实施时，也要注意归档数据的方式方法和经过严格的测 试，防止对生产系统造成不必要的影响。
2. 6.访问优化性整改
当数据库系统的访问出现性能瓶颈时，可能需要对数据库进行访问优化性 整改。对于数据库系统的性能调优，在第三节已经有详细的介绍。当性能调优 的方案是决定要对数据库的数据结构，数据分布及数据库的优化器进行调整 时，会需要用到访问优化性整改。通常包括表重建，索引重建，表的统计信息 收集和执行计划调整等。此类整改由性能调优的方案提出方提出并实施。对于 此类整改必须要在测试环境上进行测试，确认整改可以到达改善和提高数据访 问效率，并且需要衡量整改需要的停机时间可以接受后才能在生产数据库中进 行优化性整改。
3.数据库系统整改测试
所有的数据库系统整改严格上来说在正式环境上部署前都需要进行测试工 作。测试目的就是为了早发现，早处理。很多数据库系统在整改后出现的问题 90%可以在测试中发现，但测试工作却很容易被忽视或者是走过场。整改测试 的步骤通常包括测试环境准备和测试过程。对于如何进行测试的方法、工具、 样本和次数，要根据数据库整改的类型和目标来决定。这里主要介绍测试的思 路，数据库系统的整改测试包括整改目标测试，功能测试，性能测试和平安测第7页共9页 试四局部。测试环境的搭建通常来说需要与生产数据库相同的数据库版本和操 作系统版本。对于割接和迁移类整改来说软件版本与生产库不同，测试环境等 同于以后的正式环境。从正式的数据库系统中导入需要测试的数据，根据测试 的目标大小决定，有可能是全库的数据，也有可能只是一张表，也有可能不需 要生产的数据，只需要一个无数据的环境。
3.1. 整改目标测试
在完成了数据的准备之后可以开始测试工作，首先要进行的是整改目标测 试。这项测试主要是测试数据库整改方案的可行性和效果。只有此项测试能够 实现后才说明数据库整改方案具备初步的可行性。测试的每个步骤都需要整改 参与的各方进行效果确认并且生成记录。在通过了整改目标测试后，初步的整 改方案已经形成雏形。
3.2. 功能测试
接下来的测试主要是检验数据库系统在整改后的表现，以确保数据库系统 整改产生的影响在可以接受的范围内。功能测试主要是检测数据库系统的可用 性，包括数据库的可连接性，数据库的高可用性以及应用功能的可用性。其中 应用功能的可用性是测试的关键环节，应用测试需要组织业务人员对所有的应 用业务功能做全体测试，确保及时的发现和修正应用功能的问题，从而可以避 免和减少整改上线后遇到的问题。
3. 3.性能测试
数据库系统的性能测试是检验新的数据库系统是否能承当上线后的压力。 通常性能测试需要借助测试工具，目前市面上有许多的类似工具。
1 .数据库事务处理压力测试数据库的事务处理能力是衡量一个新的数据 库系统的性能的关键指标。比方能够检验数据库的事务处理能力的压力，关键 性的指标是每秒传输的事物处理个数(transac-tions per second, TPS)。
2 .数据库连接数压力测试对于数据库的连接数压力测试是检验数据库系 统在上线后是否能够承当0前的连接业务量的关键指标，同时也对连接数的上 限作出预测。这项测试可以通过专业级测试软件来进行模拟，不过此类软件是 需要付费的。也可以编写一个小程序模拟反复连接数据库来实现。
第8页共9页
3 .业务模拟压力测试业务模拟压力测试是通过数据库操作来检验数据库 的响应能力，包括I/O响应速度，数据插入速度等。这项测试可以通过创立一 张数据库表，然后往里面插入数据来检测插入速度。通过创立数据文件来检测 I/O速度。也可以利用专业级测试软件来进行模拟真实的业务操作，检验新的数 据库系统在应用业务压力下的表现。
3.4.平安测试
平安测试主要检验数据库系统是否存在平安漏洞以及进行预防性措施。通 常这项需要第三方监理机构来进行，如果条件不成熟也可以使用专业的漏洞扫 描工具或者聘请专家检测。数据库及操作系统漏洞扫描测试，检测数据库和操 作系统是否存在严重的平安漏洞，通过专业的漏洞扫描工具或者聘请专家检测 来发现，提前补上平安漏洞；检测数据库及操作系统用户及角色权限，对新数 据库及操作系统的用户口令进行管理，配置密码长度，有效期和复杂度要求 等，关闭和禁用不经常使用的用户账号；检查数据库及操作系统的用户权限是 否过大，回收超时使用范围的权限；同时考虑是否需要翻开数据库审计，对数 据库中的操作行为进行记录，如果医院内已经使用其他的平安设备和软件，如 堡垒机、防火墙和准入系统，可以与新搭建好的数据库系统进行平安联动配 置，一来是为了提高平安性，二来也是为了防止平安设备影响数据库的正常运 行。
第9页共9页