医院统一支付平台建设项目方案建议书.doc

《医院统一支付平台建设项目方案建议书.doc》由会员分享，可在线阅读，更多相关《医院统一支付平台建设项目方案建议书.doc（153页珍藏版）》请在三一办公上搜索。

1、变 更 记 录序号修改内容页号修改人修改日期12345678910注：对该文件内容增加、删除或修改均需填写此变更记录，详细记载变更信息，以保证其可追溯性。目 录XX湖南省分行医院实施案例41.引言61.1.项目背景61.2.建设目标61.3.实施范围61.4.名词解释72.系统功能简介92.1.系统概述92.1.1.XX医院系统现状分析92.1.2.解决现有问题的主要技术方法102.1.3.产品定位112.1.4.XX医院统一支付平台先进性112.1.5.设计目标122.1.6.系统特点132.2.系统功能152.2.1.功能概述152.2.2.诊疗卡充值及缴费162.2.3.退款172.2.

2、4.统一对账192.2.5.薪资发放212.2.6.对外付款213.技术方案243.1.系统架构243.1.1.技术架构图243.1.2.网络拓扑253.1.3.系统架构说明263.1.4.系统的灵活性273.1.5.系统稳定性313.1.6.系统安全体系353.1.7.开发流程完整433.1.8.源代码及文档473.2.支付业务模块构成483.2.1.平台整体模块结构483.2.2.平台技术功能层483.2.3.平台业务功能层513.3.应用设计说明533.3.1.业务处理应用533.3.2.支付系统业务规则管理533.3.3.业务公共控制管理543.3.4.日终处理应用553.3.5.业务

3、监控应用563.4.统一支付平台功能563.4.1.统一对账及异常处理563.4.2.业务处理公共流程功能583.4.3.服务控制管理593.4.4.日志管理593.5.综合运营管理平台603.5.1.分层管理603.5.2.日常运维管理603.5.3.数据管理603.5.4.综合运营管理平台部分功能展示613.6.版本管理653.6.1.版本管理概述653.6.2.版本发布流程663.6.3.系统与CVS的整合803.6.4.系统与ClearCase的整合803.6.5.系统对其它配置管理工具的支持813.6.6.应用系统部署方式813.7.运维管理方案823.7.1.过程定义833.7.2

4、.角色定义与职责853.7.3.流程描述873.8.XX医院统一支付平台方案优势994.系统部署及实施方案1014.1.应用系统配置1014.1.1.业务处理平台AFA1014.1.2.通讯前置AFE1024.2.应用系统性能1034.2.1.业务处理平台性能1034.2.2.通讯前置处理性能1054.3.应用系统软、硬件配置及部署方案1064.3.1.设计容量1064.3.2.性能要求1064.3.3.系统综合部署架构1074.3.4.软、硬件配置清单一览表1084.4.网络部署方案1104.4.1.设备部署说明1114.4.2.设备型号建议1235.技术平台1255.1.业务处理平台125

5、5.1.1.系统架构1255.1.2.功能特点1275.1.3.架构特性1295.1.4.渠道及公共信息管理1325.1.5.对账处理1365.2.外联前置1375.2.1.系统架构1375.2.2.主要功能说明1425.3.综合运营管理平台1516.项目计划1536.1.里程碑计划1536.1.1.项目时间安排表1536.2.资源管理计划1596.2.1.项目开发环境资源需求计划1596.3.问题管理计划1596.3.1.未解决问题沟通1596.3.2.登记未解决问题1606.3.3.问题上报流程1606.3.4.问题反馈流程1606.3.5.业务及技术问题提出及反馈流程1606.4.配置管

6、理计划1616.4.1.文档管理1616.4.2.文档的版本控制方法1626.4.3.软件分布及源代码版本控制管理1626.4.4.应用配置管理1636.4.5.后台应用配置管理1646.4.6.信息交流1646.4.7.数据安全1646.4.8.责任1656.5.变更控制计划1656.5.1.变更控制总述1656.5.2.变更处理流程图1666.5.3.变更处理流程描述1676.5.4.登记事件1676.5.5.争议解决1676.6.培训计划1676.7.实施沟通计划1686.7.1.沟通要求1686.7.2.沟通方法1696.7.3.沟通手段1737.服务与技术支持承诺1757.1.关于服

7、务费用的承诺1757.2.关于知识产权的承诺1757.3.维护服务支持承诺1757.4.培训承诺1767.5.其他升级维护承诺1777.5.1.统一支付平台系统与操作系统的升级相兼容1777.5.2.变更管理和版本控制177附录1：技术服务商-赞同公司资质178ISO9001证书178CMMI认证- 179 -信息产业部软件开发资质等级证书- 180 -高新技术企业证书- 181 -金融平台证书（字符终端系统）182金融交易处理系统（AB前端系统）183赞同新网点平台184监控系统（CAMAS）185通讯前置(通讯交换平台)186金融业务软件（中间业务平台）187企业信用等级证书188附录2：

8、统一支付平台实施案例一览表189平安银行统一支付平台三期项目189上海银行新上海支付结算综合业务系统191黑龙江农村信用社统一支付平台项目193江西省农村信用社统一支付平台项目195锡州农村银行网上支付跨行清算系统197北京农村商业银行境内外币支付系统199福建海峡银行网上支付跨行清算系统维护201苏州银行跨行统一支付平台项目203江苏江南农村商业银行统一支付平台系统、二代支付系统项目205北京银行京银互联支付平台二期项目技术服务合同207大连银行支付平台系统软件开发209珠海华润银行支付平台项目211东莞银行支付平台213附录3：中南大学XX医院统一支付平台XX补充承诺215XX湖南省分行医

9、院实施案例XX湖南省分行多年来重点支持全省医疗卫生行业发展。近年来，全力支持全省医疗机构信息化建设，并走在省内同业前端。到目前为止，共已支持30多家医院上线“诊疗卡”和“移动医院”项目，得到了省市卫生系统和各医院的一直好评。 同时，积极响应和参与省、市卫计委“社保卡”、“居民健康卡”的发行工作，并对各医院“社保卡”和“健康卡”的使用环境进行建设，实现了全省首家医院（湘潭市第一医院）社保卡在诊疗机具上的应用。截至目前，我行投入省、市医院“诊疗卡”等信息化建设项目金额逾1亿多元，我行与省属和长沙市属医院业务合作份额在同业占比达70%。因此，我行对医院信息化建设等合作方面积累了丰富的经验，并由此锻炼

10、出了一支专业、贴心的服务团队，为贵院支付平台的建设和维护提供了有力保障。XX省内“诊疗卡”、“移动医院”项目合作名单序号医院名称1长沙医学院附属医院2长沙市中医医院(长沙市第八医院)3长沙市中心医院4长沙市口腔医院5长沙市第一医院6长沙市第四医院7长沙市第三医院8岳阳市二人民医院9永州职业技术学院附属医院10永州市中医院11永州市妇幼保健院12益阳医专附属医院13湘潭市中医院14湘潭市中心医院15湘潭市第一人民医院16湘潭市第二人民医院17湘南学院附属医院18南华大学附属南华医院19南华大学附属第一医院20娄底市中医院21娄底市妇幼保健院22娄底第二人民医院23湖南中医药高等专科学校附属第一医

11、院24湖南旺旺医院25湖南省肿瘤医院26湖南省永州市中心医院27湖南省人民医院28湖南省结核病防治所29湖南省妇幼保健院30湖南省儿童医院31郴州市中医医院1. 引言1.1. 项目背景随着智能移动终端技术和移动支付的快速发展，人们享受到了新的支付方式带来的便利。在现代医院，门诊自助设备、互联网挂号等方式的普及，很大程度上解决了人工柜台排长队的问题，但病友依然没有能够体验到随时随地充值缴费带来的便捷。为了方便病友随时随地处理充值缴费，减少人工操作窗口流程，实现XX医院移动自助支付的快速建设，XX医院提出建设统一支付平台，实现自助充值、自助支付、自动对账、统一管理，搭建统一的支付平台服务运营系统架

12、构，真正意义实现医院支付的“电子货币”，为病友提供高效方便的支付平台，进而实现现代化医院的发展蓝图。1.2. 建设目标XX医院统一支付平台建设的总体目标是：立足XX原有缴费系统的成功经验，引入先进的支付平台管理理念和技术，进一步丰富系统功能，提高结算效率，拓宽服务范围，加强运行监控，完善灾备系统，降低人工运营成功，建设适应未来发展和管理需要的、功能更完善、架构更合理、技术更先进、管理更便捷的现代化信息支付管理体系。1.3. 实施范围XX医院支付平台旨在建设一套完整的支付、退款、对账、清算的系统，同时搭建一个便于开发、运维和管理的支付清算服务架构，包括但不限于以下功能：（1）多渠道缴费支付：1）

13、支持多种线上线下缴费渠道接入2）便捷支付方式（直连银行、银联和第三方支付等）3）支持参数化管理渠道功能和支付方的运行状态（2） 安全便捷的退款（3） 统一对账针对目前医院已经实现的自助和Pos缴费充值功能，前期的建设可以考虑不纳入支付平台，但是可以在把对账、差错处理等非联机的功能，统一到支付平台，这样方便财务管理，账务核对。（4） 运营和管理通过统一支付平台的建设，主要提升以下几方面：1）提高良好的客户体验度；2）提供良好的数据管理和分析能力；3）提高运行稳定性、可扩充性;4）实时风险预警、监控，及时有效规避资金等支付风险5）灵活管理方式，系统参数化配置本项目，我们将立足于统一支付平台产品，结

14、合XX医院的实际情况，投入充足的资源，确保院方统一支付平台建设稳步进行。1.4. 名词解释AFAAgree Financial Architecture， 金融业务开发运行平台，又称特色（中间）业务处理平台，简称AFA。AFEAgree Front-End，面向金融应用的通讯前置，又称通讯前置（外联前置），简称AFE或ACE。SOAService Oriented Architecture，面向服务的架构体系，是目前最流行的架构体系；它为企业的IT架构提供了充分的灵活性和标准性，以适应市场的快速变化并降低成本。2. 系统功能简介2.1. 系统概述2.1.1. XX医院系统现状分析业务面临问题：

15、l 现有自助和pos大多是定点建设的，资源有限，不能灵活、快速地解决病友的需求；l 柜面设置相对较少，投入工作人员较多，运营成本高，效率低，病友等待时间长，来回奔波；l 所有的退款均在柜面以现金方式进行，工作人员工作压力大，医院对现金依赖过高，病友也有比较大的资金风险；技术面临问题：l IT技术架构的规划问题 原有系统IT技术架构的定位问题 采用何种技术架构实现支付业务系统并保持其持续发展能力和对业务的支持能力l 技术面临的变化和问题 多种开发方式，导致开发效率低、成本高、软件可复用性差、应用软件可靠性差 技术及系统管理混乱，多种应用系统、多种版本、多种技术 如何灵活、快速开发新产品和服务l

16、系统的部署和运维管理问题 应用系统越来越多，安全性、可靠性和稳定性要求极高 运维管理人员的素质要求不断提高，同时人员数量要求也越来越多。 系统运维参数性变化不够灵活，无法快速响应支付方式创新。2.1.2. 解决现有问题的主要技术方法XX医院在未来统一支付平台的建设过程中可遵循“横向整合、纵向集中”的设计思想解决上述问题，具体方法如下：l 统一技术架构，面向未来发展 可灵活的进行总分行应用系统整合优化 保证技术平台的持续发展 降低系统成本 方便部署和运维管理l 统一应用平台，统一开发和运维管理模式 提高应用的开发和维护效率 灵活、快速响应新业务需求，开发新产品l 采用面向服务的架构，实施SOA化

17、改造，减少应用变化对系统的影响 前端与后台的分离 通讯与应用的分离 数据与应用的分离 服务与应用的分离2.1.3. 产品定位 多个支付渠道的集中整合，降低系统部署和运维成本； 进一步完善全院的IT架构奠定基础，方便银行系统和第三方支付系统对接，采用SOA化设计思想，为相关应用系统提供统一服务接口； 提高系统运行稳定性，确保每日支付业务的正常进行； 技术架构可灵活扩展，支持未来新支付应用系统建设，方便新支付系统和新业务的灵活、快速和高质量开发； 减少金融机构和第三方系统变化引起的变动，保证支付系统稳定性； 面向现代化医院支付体系蓝图，建立合理的电子信息化支付体系； 减少线下流程，达到资金结算、退

18、款等业务的实效性要求；2.1.4. XX医院统一支付平台先进性1. 先进的前瞻性。先进的总体设计、编程实现及方便维护。2. 业务的统一性。统一的业务操作及处理模式，统一的业务管控。3. 足够的安全性，良好的使用性，界面友好，操作直观方便、速度快、功能全面。4. 充分的健壮性，合理设计尽量减少人为差错，避免因操作不当而发生灾难性后果。5. 与周边系统接口规范，可扩充性强，并能很好地接入第三方产品。6. 良好的兼容性，采用开放的系统和开放的技术，采用开放的体系结构。7. 灵活性，IT架构灵活，适用未来的变化。8. 支付安全性，支持支付报文的各种加密方法，保证关键数据安全。9. 性能保障，支持大用量

19、，大交易吞吐，大数据量，多并行数据库存储，并保持较短的反映时间。较高的数据完整性和安全性并能确保7*24系统可用性。2.1.5. 设计目标1. 实现基于统一、开放的基础技术平台，可实现有效的交易运行引擎、通讯交换管理、业务监控、数据库管理、信息统计等基础功能。2. 系统功能模块化管理，系统间松耦合，支持功能灵活、高效、安全的拓展。3. 采用SOA化的设计思想，能够对各银行、银联、第三方支付渠道提供标准统一、种类丰富的支付接入服务功能，可以方便实现服务的定制扩充。4. 无论是业务、技术上，实现最大化的参数配置管理，如流程控制，规则管理等，实现业务功能灵活、快速、安全的开发实现，提供统一的集成化图

20、形开发工具。5. 业务操作界面友好统一，包括业务发起处理、业务接收处理、清算、对账处理等，都统一由图形柜面系统发起。6. 整合多种支付渠道为前提，涵盖支付、退款、统一灵活对账和清算。2.1.6. 系统特点l 强大的交易交换功能，各个系统间的联系枢纽XX医院统一支付平台系统是交易系统的中间层，提供统一的内部交易报文交换规范（XML或类XML），实现各种类（8583、定长报文、分隔符报文、可变分隔符、XML、TAG、NATP等）交易报文规范的相互转换，支持SOCKET、NATP、SOAP、HTTP、HTTPS、MQ、Tuxedo、JMS、JMX、CICS、FTP等通讯协议，短连接、长连接、单工/双

21、工等通讯模式，具备交易流程组合、路由、转发等能力，并拥有完善的交易一致性控制，成为连接各个系统间的通讯枢纽。l 强大、简单的二次开发能力，方便新业务的拓展支付平台系统，能够帮助技术人员顺利开发新的业务子系统。系统适应性强、配置灵活、使用方便，较好地解决了综合应用前置面临的众多接入和外联系统需求复杂的问题。全图形化工具的使用，做到配置灵活、提高系统的可配置度，使配置开发过程快捷简单，同时对所有的可配置资源加以有效的控制和管理，做到活而不乱。l 统一、简单、完整的管理系统所要纳入的多种业务应用复杂，需要提供一个统一的管理操作环境，提供日常维护操作、账务处理、批量业务处理、查询报表服务等中心业务管理

22、功能，并对所有的操作能进行有效稽核和监控。l 整合业务服务，提供跨支付应用系统的平台级服务将已有的各个支付应用模块联系来形成完善的统一支付系统，提供给客户、操作人员和管理人员以一体化的移动服务感受。l 高性能、高可靠、高安全由于支付平台系统担当的重要角色，高性能、高可靠、高安全是系统追求的主要目标之一，支付平台系统从三个方面着手提高系统的以上特性：针对大业务量的情况，硬件上采用高性能小型机或者高档PC服务器，并采用双机热备或集群容错系统，以提高系统的性能及可靠性。由于业务是处于一个动态发展的过程之中，由于业务的发展，可能造成原有系统不能适应，为了尽可能保护院方硬件投资，综合应用前置系统可以集群

23、方式构建，系统具备负载平衡能力，维护人员也可以进行有效的管理、配制资源。从软件设计上，系统高度灵活，不同交易模块可以相互组合，具备二次开发能力，在同一台机器上，一项交易处理过程，各个交易模块相互之间的调用尽可能处于同一进程内，提高了系统性能与可靠性。l 面向决策分析的统计报表系统的统计报表可以向决策分析者提供以下三方面数据：l 各种支付渠道接入的统计数据对系统记录的各种支付渠道、移动终端设备、柜面、自助和pos设备、人员访问系统的时间、频度、处理效率等进行统计，为决策分析者更好的了解各类支付渠道的运作状态提供可比的数据信息。l 各种支付业务的统计数据对医院已接入的的各种支付业务数据进行统计分析

24、，为决策分析者更清楚地了解各类支付渠道对院方的贡献情况提供帮助。l 操作风险控制根据相关要求进行支付业务操作风险控制2.2. 系统功能2.2.1. 功能概述XX医院建设统一支付平台后，我院的合作银行或第三方支付公司可以方便快捷地接入到我院系统，在直连银行开户的病友，可直接通过直连银行提供的服务完成缴费充值功能；非直连银行可以通过银联、银行代理或者第三方支付公司的支付通道完成缴费充值；实现实时的资金结算在建设统一支付平台后，利用医院现有的开户行，不完全与一家银行捆绑，各家直连银行之间是平等竞争关系，医院可以主动根据支付平台的推广情况，及银行的服务能力，调整直连银行的服务功能。医院可在建设统一支付

25、平台后，利用平台对外支付功能，拓展院内其他系统的支付结算需求，例如代发工资、对外付款等。2.2.2. 诊疗卡充值及缴费2.2.2.1. 业务说明针对已经注册并绑定诊疗卡的用户，通过查询待缴费信息订单，可过院方已开通的支付渠道实时进行充值缴费。2.2.2.2. 业务流程2.2.2.3. 异常处理l 医院HIS缴费超时，登记异常，自动/手动处理查询支付结果，进一步做后续或失败处理l 发送金融机构记账超时，登记异常，可发起人工查询缴费结果2.2.3. 退款2.2.3.1. 业务说明根据退款请求，将退款的金额实时返还客户。2.2.3.2. 退费方式l 退现金，包括诊疗卡内余额退现金以及缴费退现金；l

26、退回诊疗卡，不涉及资金结算；l 退回卡，通过卡充值缴费的，可原卡退回；l 退回第三方支付账户，通过第三方支付账户充值缴费的，可退回原账户；2.2.3.3. 退款规则l 窗口退款：窗口可退所有渠道的充值缴费；l 自助退款：只能退诊疗卡余额资金，并且只能退回绑定的银行卡；l App退款：绑定了诊疗卡和同名银行卡的用户，可用app的退款功能将诊疗卡余额退回；2.2.3.4. 业务流程2.2.3.5. 异常处理l 医院HIS退费超时，登记异常自动/手动处理查询支付结果，进一步做后续或失败处理。l 请求金融机构退费超时，登记异常。可发起人工查询退款结果。2.2.4. 统一对账2.2.4.1. 业务说明对

27、账的目的是在医院方和支付方双方产生不一致的账务流水时，按照既定的业务业务标准，有效、及时、安全处理资金流水，进而达到账务清算目的。2.2.4.2. 业务规则l 集中：多个支付方统一对账，对账操作不分散，对账过程可实时监控，对账结果集中展现l 灵活：支持自动对账、可设定对账流程，可设定多样化对账规则l 准确：生成准确对账结果文件，并可根据对账文件进行相应差错处理，保证对账结果数据的准确有效；l 完整：在整个对账过程，除了对账和差错处理，还可以准确获取当日各银行可结转的资金，监测当日资金的划款结果。2.2.4.3. 业务流程2.2.4.4. 对账机制2.2.5. 薪资发放2.2.5.1. 业务说明

28、依据院方提供的工资支付清单，院方通过统一支付平台对接的银行服务接口自动发放工资至指定员工账户。2.2.5.2. 业务流程2.2.5.3. 异常处理l 如行方工资回单未返回，院方可发起回单申请。l 文件格式非法，则依据业务规则重新制定或忽略单条继续处理。2.2.6. 对外付款2.2.6.1. 业务说明院方财务部门业务人员需向供应商支付的款项（如药品、医疗器材），可通过获取XX医院内部系统的付款指令向对应银行发出支付申请，主动支付货款。2.2.6.2. 业务流程2.2.6.3. 异常处理l 院方记账超时，调用异常处理，自动或手动抹帐。l 与银行/第三方支付通讯超时，发起查询或日终对账。3. 技术方

29、案3.1. 系统架构3.1.1. 技术架构图说明：上图所示的整体系统架构中IT架构主要包括：展现层、接入负载层、服务业务层、数据层级系统层五个部分。3.1.2. 网络拓扑医院内部系统跟支付平台交互，可通过医院内部局域网现有的通讯方式连接。统一支付平台跟银行、银联或第三方支付实现系统交互时，支付平台直接通过外联支付网关与医院院外系统进行信息交互。3.1.3. 系统架构说明整个支付平台（系统）采用集中部署模式，分为支付业务处理平台和支付网关（外联交换系统）两个主要部分和配套的监控管理系统，功能分工如下：l 支付网关（外联交换系统）：负责直连银行、银联、第三方支付等支付系统的接入，以及报文通讯协议和

30、报文结构的转换，统一通讯通讯协议和报文结构转发支付业务处理平台进行业务处理。l 支付业务处理平台：负责各类应用的业务逻辑处理、数据库操作和主机接口处理，实现各类支付业务的处理，如缴费充值、退费、清算对账、第三方支付等。提供各类组件，并封装成服务，为各种支付业务流程提供服务。 支付平台的业务流程引擎和规则引擎通过对业务规则的定义和业务流程的建模和执行，把业务组件层提供的各种服务按照实际业务需要串接起来，从而灵活地统一调度和管理的服务和流程。 l 监控管理。以可视化的方式通过图形化的图表和工具实现对整个支付平台的远程管理、集中管理，并实时地监控整个支付系统的流程和服务状况。3.1.4. 系统的灵活

31、性3.1.4.1. 分层架构统一支付平台采用松耦合的分层架构设计，由负责业务处理的业务平台、负责第三方接入的外联前置组成，各分层之间分工明确，接口标准开放。从整个系统来看，主要分为交易处理层、数据处理层、内联通讯层、渠道整合层、中间业务处理层（AFA和AFE）和第三方接入层。从综合大前置角度来看，包括了内联通讯层（ESB）、中间业务处理层（AFA）和外联通讯层（AFE）。统一支付平台层上集中部署各种应用系统，重点关注业务逻辑的实现。外联通讯层即外联前置关注第三方系统的接入，主要处理通信协议转换、报文解析、消息路由等。通过松耦合分层化的架构，实现了应用与通讯的分离、应用与数据的分离，为整个系统提

32、供了高扩展性、高灵活性的支持。3.1.4.2. 系统独立在统一支付平台中，业务处理平台、外联前置两个组成产品功能独立，均能够独立部署。 各个不同的系统（平台）互相独立，业务处理平台（AFA）、外联前置（AFE）都可以实现独立部署、集群部署等。3.1.4.3. 开放协议整个系统构建在SOA的系统架构之上，遵循开放的、标准化的SOAP协议。在功能性方面，系统支持以下标准协议：l 传输（Transport）：WebSphere MQ、JMS、HTTP/HTTPS、电子邮件、文件、FTP、Socketl 服务通信协议（Service Communication Protocol）：XML、SOAPl

33、服务描述（Service Description）：XML Schema、XML DTD、WSDL、COBOL Copybook、C结构体在普通模式下，系统支持的以下报文类型：l 定长报文l 有类型定长报文l 定分隔符报文l 变分隔符报文l ISO8583 报文l XML 报文l HTTP 报文l 循环报文l 分支报文l 子报文l 混合报文l 其它报文在普通模式下，系统支持的通讯协议：l Socket短连接C端l Socket短连接S端 l Socket长连接C端l Socket长连接S端l 带校验的长连接l WebServicel HTTP 协议l FTP 协议l JMS MQl MQ (非

34、 JMS )l 中间件协议（CICS、Tuxedo、EJB）l 其它通讯协议3.1.5. 系统稳定性3.1.5.1. 异常恢复机制业务处理平台具有独立的、可靠的异常恢复机制，能够保障在异常情况下（包括宕机、大范围异常、消息大量丢失），系统能够快速恢复，并且在恢复后数据不丢失并能够继续正常工作。业务处理平台使用可靠的数据库机制，业务数据均存储在数据库中，即使在出现故障的情况下，系统能保证数据不丢失，并在系统恢复正常后，能够继续进行业务处理。3.1.5.2. 故障隔离机制业务处理平台可以实现业务系统的故障隔离，将故障业务的影响减少到最小。 服务进程池可以分组管理使用，不同的应用使用不同的进程组。

35、应用之间可隔离的服务进程，可以屏蔽个别异常进程对平台的影响，相对于线程池为可靠、高效，进程可动态增加，以动态调整均衡资源 。业务交易运行在独立的进程空间中，不同业务交易之间进行了隔离，屏蔽了交易间的互相影响。应用之间可隔离的消息队列，很好的保护了应用本身的数据区。3.1.5.3. 健康监测机制在业务处理平台中，能对自身系统以及所有接入企业服务总线的系统进行健康检测，当某系统出现故障时，能及时告警，并根据事先设定的策略处理故障。业务处理平台中有一个健康监测服务，可以根据用户策略自动运行或人工启动。它可以对自身系统以及所有接入企业服务总线的系统内部进行回路测试，以监测这些系统是否能够正常工作。当某

36、系统出现故障，回路不能够正常完成，健康监测服务就会根据事先设定的策略进行故障处理。3.1.5.4. 宕机容错机制容错的目的是为了保证数据永不丢失和系统永不停机。从上图上可以看出，为了保证数据的不丢失，采用智能磁盘阵列；为了保证用不停机，数据库服务器采用双机热备方案。另外，在中间（特色）业务层和通信层（外联/内联）采用集群也是一种宕机容错策略，当集群中的某台机器发生宕机后，负载均衡（硬件/软件）会自动将后续的请求转发到其他正常运行的服务器，从而保证系统的不间断运行，提高系统的健壮性。3.1.5.5. 数据备份及恢复业务处理平台提供系统参数、应用参数、系统数据、应用数据、系统日志、应用日志、进程的

37、备份、清理和恢复机制，防止各种可能的问题造成损失，应对应用程序提供失效保护。3.1.5.5.1. 数据备份数据中心定期定时备份业务现场：对数据备份及其存储介质的保管设立专门的岗位。数据备份方式为：场地内增量式冷备份。数据备份周期取决于：业务数据的流量和业务数据的重要性，因此将随系统运行情况灵活调整数据备份周期。数据备份周期为：每月执行一次完全备份，每周执行一次差分备份，每天执行一次增量备份。对保存数据备份的存储介质（磁盘/磁带/光盘/硬盘），应统一编码，并存放在专门的保密箱/柜中。在数据备份记录中给出：备份方式、备份内容、原数据的存储路径、备份数据存储介质的标识、备份起止时间、备份者。3.1.

38、5.5.2. 数据恢复数据中心在恢复业务现场时，应遵循以下原则：对数据恢复设立专门的岗位，亦可与数据备份岗位合并。数据恢复时要首先经主管部门批准，并有安全管理人员在场。数据恢复前应通知相应业务部门的事件处理人员。若需要业务部门参与（如模拟重演某个时段的业务处理），则数据中心应为相应的业务部门提供详细的操作流程，双方协同完成数据恢复。在数据恢复记录中给出：恢复原因、恢复内容、原数据的存储路径、备份数据存储介质的标识、恢复起止时间、恢复者、批准者。3.1.5.6. 支持热部署业务处理平台支持在线热部署，对于程序脚本、配置文件和报文修改发布后即时生效。当有新开发的交易或者对已有交易作优化和修改后需要

39、部署上线时，业务处理平台实现即发布即使用，平台本身无需重启即可实现交易发布使用的目的。3.1.6. 系统安全体系3.1.6.1. 整体安全要求随着医院信息化程度越来越高，伴随而来的安全问题也日益突出，尤其是随着网络规模的不断扩大，网络应用项目越来越丰富，涉及到的人员越来越来越庞杂，部署策略越来越繁琐，整个系统变得越复杂，医院面对的安全风险也越来越大。如何有效地降低安全风险、降低安全成本，安全的策略显得尤为重要。医院的内部办公系统是关键业务系统，需要系统不间断运行。即使发生短暂的业务中断，也会导致难以估量的经济和名誉损失。 现有网络资源很难通过灵活有效的策略调整实现业务与网络的充分融合，例如早期

40、医院网络已经很难支撑门诊系统对可靠性、PACS系统对高性能的要求，医院用户对新业务部署的体验感不佳，新业务的部署面临巨大管理压力；网络平台缺乏智能性，无业务识别能力，不能对关键业务应用提供端到端的高质量数据传输的有效保证，医院通常采用的设备升级、链路带宽升级等简单方式使得网络建设、运营、管理成本大幅度上升，而网络资源的利用率却在大幅度下降。 目前在网络安全所面临着几大问题主要集中在如下几点： l 来自互连网的黑客攻击 l 来自互联网的恶意软件攻击和恶意扫描 l 来自互联网的病毒攻击 l 来自内部网络的P2P下载占用带宽问题 l 来自内部应用服务器压力和物理故障问题 l 来自内部网络整理设备监控

41、管理问题 l 来自数据存储保护的压力和数据安全管理问题 l 来自内部数据库高级信息如何监控审计问题 l 来自内部客户端桌面行为混乱无法有效管理带来的安全问题 3.1.6.2. 网络安全要求3.1.6.2.1. 稳定性医疗行业是关系到病人生命安危的重要行业，医院的各种应用系统和基础设备都要保证超高的稳定性，系统的稳定性（7*24稳定、可靠、持续运行）是投入运行的医疗系统的生命线。同时，对于门诊等重要区域，由于门诊收费是患者进入医院的第一站，稳定的网络系统建设是医院各种应用系统开展的根本保障，是降低医院目前出现的“三长一短”问题的根本性措施。 3.1.6.2.2. 高性能作为临床信息系统最为重要的

42、PACS系统的应用其在传输患者的放射图像信息时，需要消耗大量的网络传输带宽，随着医院信息化的发展，堆积如山的胶片、病例档案都没有了，但是网络上数据量却在急剧增长。海量存储和数据浏览就成为必须解决的问题。在计算机中一页文字资料仅占几千字节(Kb)，而一张数字化的X线片将产生上百万字节(Mb)的信息量，这就是所谓“兆字节问题”。 3.1.6.2.3. 防泄密医院的内部信息主要是以病人的病例、处方和医嘱等信息为主，而医院是有义务保障病人的信息安全，保证病人的病例、处方和医嘱信息不被没有必要的部门或人员查看，同时也要保证信息不能外传。因此，如何保证整个系统的保密性、完整性、可用性、可审核性也是医院信息

43、系统安全性的一部分。3.1.6.2.4. 可管理性随着医院信息化建设的深入发展，医院应用服务的不断开展，数据中心作为医院的各种应用系统的“大脑”，需要保障极高的稳定性和可靠性，为医院的各种应用服务提供持续不断的数据传输服务。通过合理的数据中心规划，提升医院应用服务“大脑”的稳定性和可靠性，各种应用服务提供不间断的数据响应需求。随着网络规模的不断扩大，网络覆盖范围的不断延伸，网络设备数量和种类也在不断的增加。需要通过有效的网络流量和网络故障监控，及时有效的发现网络中存在的各种故障和隐患，以便能够通过及时的故障处理，有效的排出网络故障，降低网络使用风险，确保各种业务的正常开展。同时，先进的网络管理

44、，不仅可以极大的降低医院信息中心的网络维护和管理难度，对于HUB和非网管设备在医院内部的受控使用，可以有效的内部网络的安全风险，提升医院内部网络系统的可靠性。3.1.6.3. 桌面终端安全要求分析传统医疗桌面运维的特点，普遍存在以下几个问题：第一：桌面终端多而杂，维护难度大，故障恢复慢，影响医生工作效率：由于医院系统建设的特点，各科室、各区域各院区的IT建设时间及情况均会出现不同程度的差异，桌面终端往往采购一次就换一批型号，随着时间的迁移，终端类型多而杂，仅终端配件的维护就消耗IT部门大量的时间。与此同时，终端故障恢复慢，也直接影响医生工作效率，使看病难的问题更加突显，不利于医患关系的改善。第二：桌面系统环境多样，各种兼容性问题突显：由于医院内各类IT系统较多，并且IT系统涉及的厂商较多，桌面系统的维护往往要兼顾众多的系统兼容性问题，部署新的系统也需要面临各种顽石（老旧系统）的阻挠。系统的不断臃肿，兼容性的问题日益突显，导致IT系统建设步履艰难，新系统、新技术的推广难度剧增。第三：工作环境人员流动性大，隐私信息、统方信息管理难：医院工作人员流动较大，特别是在一些公共区域，医生门诊办公室、护士工作站等，每天轮岗的人员较多，终端上的数据及各类