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

变更记录序号修改内容页号修改人修改日期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.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. 业务监控应用 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. 角色定义与职责 853.7.3. 流程描述 873.8. XX医院统一支付平台方案优势 994. 系统部署及实施方案 1014.1. 应用系统配置 1014.1.1. 业务处理平台AFA 1014.1.2. 通讯前置AFE 1024.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. 业务处理平台 1255.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. 配置管理计划 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. 关于服务费用的承诺 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：统一支付平台实施案例一览表 189平安银行统一支付平台三期项目 189上海银行新上海支付结算综合业务系统 191黑龙江农村信用社统一支付平台项目 193江西省农村信用社统一支付平台项目 195锡州农村银行网上支付跨行清算系统 197北京农村商业银行境内外币支付系统 199福建海峡银行网上支付跨行清算系统维护 201苏州银行跨行统一支付平台项目 203江苏江南农村商业银行统一支付平台系统、二代支付系统项目 205北京银行京银互联支付平台二期项目技术服务合同 207大连银行支付平台系统软件开发 209珠海华润银行支付平台项目 211东莞银行支付平台 213附录3：中南大学XX医院统一支付平台XX补充承诺 215

XX湖南省分行医院实施案例XX湖南省分行多年来重点支持全省医疗卫生行业发展。近年来，全力支持全省医疗机构信息化建设，并走在省内同业前端。到目前为止，共已支持30多家医院上线“诊疗卡”和“移动医院”项目，得到了省市卫生系统和各医院的一直好评。同时，积极响应和参与省、市卫计委“社保卡”、“居民健康卡”的发行工作，并对各医院“社保卡”和“健康卡”的使用环境进行建设，实现了全省首家医院（湘潭市第一医院）社保卡在诊疗机具上的应用。截至目前，我行投入省、市医院“诊疗卡”等信息化建设项目金额逾1亿多元，我行与省属和长沙市属医院业务合作份额在同业占比达70%。因此，我行对医院信息化建设等合作方面积累了丰富的经验，并由此锻炼出了一支专业、贴心的服务团队，为贵院支付平台的建设和维护提供了有力保障。XX省内“诊疗卡”、“移动医院”项目合作名单序号医院名称1长沙医学院附属医院2长沙市中医医院(长沙市第八医院)3长沙市中心医院4长沙市口腔医院5长沙市第一医院6长沙市第四医院7长沙市第三医院8岳阳市二人民医院9永州职业技术学院附属医院10永州市中医院11永州市妇幼保健院12益阳医专附属医院13湘潭市中医院14湘潭市中心医院15湘潭市第一人民医院16湘潭市第二人民医院17湘南学院附属医院18南华大学附属南华医院19南华大学附属第一医院20娄底市中医院21娄底市妇幼保健院22娄底第二人民医院23湖南中医药高等专科学校附属第一医院24湖南旺旺医院25湖南省肿瘤医院26湖南省永州市中心医院27湖南省人民医院28湖南省结核病防治所29湖南省妇幼保健院30湖南省儿童医院31郴州市中医医院引言项目背景随着智能移动终端技术和移动支付的快速发展，人们享受到了新的支付方式带来的便利。在现代医院，门诊自助设备、互联网挂号等方式的普及，很大程度上解决了人工柜台排长队的问题，但病友依然没有能够体验到随时随地充值缴费带来的便捷。为了方便病友随时随地处理充值缴费，减少人工操作窗口流程，实现XX医院移动自助支付的快速建设，XX医院提出建设统一支付平台，实现自助充值、自助支付、自动对账、统一管理，搭建统一的支付平台服务运营系统架构，真正意义实现医院支付的“电子货币”，为病友提供高效方便的支付平台，进而实现现代化医院的发展蓝图。建设目标XX医院统一支付平台建设的总体目标是：立足XX原有缴费系统的成功经验，引入先进的支付平台管理理念和技术，进一步丰富系统功能，提高结算效率，拓宽服务范围，加强运行监控，完善灾备系统，降低人工运营成功，建设适应未来发展和管理需要的、功能更完善、架构更合理、技术更先进、管理更便捷的现代化信息支付管理体系。实施范围XX医院支付平台旨在建设一套完整的支付、退款、对账、清算的系统，同时搭建一个便于开发、运维和管理的支付清算服务架构，包括但不限于以下功能：（1）多渠道缴费支付：1）支持多种线上线下缴费渠道接入2）便捷支付方式（直连银行、银联和第三方支付等）3）支持参数化管理渠道功能和支付方的运行状态安全便捷的退款统一对账针对目前医院已经实现的自助和Pos缴费充值功能，前期的建设可以考虑不纳入支付平台，但是可以在把对账、差错处理等非联机的功能，统一到支付平台，这样方便财务管理，账务核对。运营和管理通过统一支付平台的建设，主要提升以下几方面：1）提高良好的客户体验度；2）提供良好的数据管理和分析能力；3）提高运行稳定性、可扩充性;4）实时风险预警、监控，及时有效规避资金等支付风险5）灵活管理方式，系统参数化配置本项目，我们将立足于统一支付平台产品，结合XX医院的实际情况，投入充足的资源，确保院方统一支付平台建设稳步进行。名词解释AFA – AgreeFinancialArchitecture，金融业务开发运行平台，又称特色（中间）业务处理平台，简称AFA。AFE – AgreeFront-End，面向金融应用的通讯前置，又称通讯前置（外联前置），简称AFE或ACE。SOA – ServiceOrientedArchitecture，面向服务的架构体系，是目前最流行的架构体系；它为企业的IT架构提供了充分的灵活性和标准性，以适应市场的快速变化并降低成本。系统功能简介系统概述XX医院系统现状分析业务面临问题：现有自助和pos大多是定点建设的，资源有限，不能灵活、快速地解决病友的需求；柜面设置相对较少，投入工作人员较多，运营成本高，效率低，病友等待时间长，来回奔波；所有的退款均在柜面以现金方式进行，工作人员工作压力大，医院对现金依赖过高，病友也有比较大的资金风险；技术面临问题：IT技术架构的规划问题原有系统IT技术架构的定位问题采用何种技术架构实现支付业务系统并保持其持续发展能力和对业务的支持能力技术面临的变化和问题多种开发方式，导致开发效率低、成本高、软件可复用性差、应用软件可靠性差技术及系统管理混乱，多种应用系统、多种版本、多种技术如何灵活、快速开发新产品和服务系统的部署和运维管理问题应用系统越来越多，安全性、可靠性和稳定性要求极高运维管理人员的素质要求不断提高，同时人员数量要求也越来越多。系统运维参数性变化不够灵活，无法快速响应支付方式创新。\解决现有问题的主要技术方法XX医院在未来统一支付平台的建设过程中可遵循“横向整合、纵向集中”的设计思想解决上述问题，具体方法如下：统一技术架构，面向未来发展可灵活的进行总分行应用系统整合优化保证技术平台的持续发展降低系统成本方便部署和运维管理统一应用平台，统一开发和运维管理模式提高应用的开发和维护效率灵活、快速响应新业务需求，开发新产品采用面向服务的架构，实施SOA化改造，减少应用变化对系统的影响前端与后台的分离通讯与应用的分离数据与应用的分离服务与应用的分离产品定位多个支付渠道的集中整合，降低系统部署和运维成本；进一步完善全院的IT架构奠定基础，方便银行系统和第三方支付系统对接，采用SOA化设计思想，为相关应用系统提供统一服务接口；提高系统运行稳定性，确保每日支付业务的正常进行；技术架构可灵活扩展，支持未来新支付应用系统建设，方便新支付系统和新业务的灵活、快速和高质量开发；减少金融机构和第三方系统变化引起的变动，保证支付系统稳定性；面向现代化医院支付体系蓝图，建立合理的电子信息化支付体系；减少线下流程，达到资金结算、退款等业务的实效性要求；XX医院统一支付平台先进性先进的前瞻性。先进的总体设计、编程实现及方便维护。业务的统一性。统一的业务操作及处理模式，统一的业务管控。足够的安全性，良好的使用性，界面友好，操作直观方便、速度快、功能全面。充分的健壮性，合理设计尽量减少人为差错，避免因操作不当而发生灾难性后果。与周边系统接口规范，可扩充性强，并能很好地接入第三方产品。良好的兼容性，采用开放的系统和开放的技术，采用开放的体系结构。灵活性，IT架构灵活，适用未来的变化。支付安全性，支持支付报文的各种加密方法，保证关键数据安全。性能保障，支持大用量，大交易吞吐，大数据量，多并行数据库存储，并保持较短的反映时间。较高的数据完整性和安全性并能确保7*24系统可用性。设计目标实现基于统一、开放的基础技术平台，可实现有效的交易运行引擎、通讯交换管理、业务监控、数据库管理、信息统计等基础功能。系统功能模块化管理，系统间松耦合，支持功能灵活、高效、安全的拓展。采用SOA化的设计思想，能够对各银行、银联、第三方支付渠道提供标准统一、种类丰富的支付接入服务功能，可以方便实现服务的定制扩充。无论是业务、技术上，实现最大化的参数配置管理，如流程控制，规则管理等，实现业务功能灵活、快速、安全的开发实现，提供统一的集成化图形开发工具。业务操作界面友好统一，包括业务发起处理、业务接收处理、清算、对账处理等，都统一由图形柜面系统发起。整合多种支付渠道为前提，涵盖支付、退款、统一灵活对账和清算。系统特点强大的交易交换功能，各个系统间的联系枢纽XX医院统一支付平台系统是交易系统的中间层，提供统一的内部交易报文交换规范（XML或类XML），实现各种类（8583、定长报文、分隔符报文、可变分隔符、XML、TAG、NATP等）交易报文规范的相互转换，支持SOCKET、NATP、SOAP、HTTP、HTTPS、MQ、Tuxedo、JMS、JMX、CICS、FTP等通讯协议，短连接、长连接、单工/双工等通讯模式，具备交易流程组合、路由、转发等能力，并拥有完善的交易一致性控制，成为连接各个系统间的通讯枢纽。强大、简单的二次开发能力，方便新业务的拓展支付平台系统，能够帮助技术人员顺利开发新的业务子系统。系统适应性强、配置灵活、使用方便，较好地解决了综合应用前置面临的众多接入和外联系统需求复杂的问题。全图形化工具的使用，做到配置灵活、提高系统的可配置度，使配置开发过程快捷简单，同时对所有的可配置资源加以有效的控制和管理，做到活而不乱。统一、简单、完整的管理系统所要纳入的多种业务应用复杂，需要提供一个统一的管理操作环境，提供日常维护操作、账务处理、批量业务处理、查询报表服务等中心业务管理功能，并对所有的操作能进行有效稽核和监控。整合业务服务，提供跨支付应用系统的平台级服务将已有的各个支付应用模块联系来形成完善的统一支付系统，提供给客户、操作人员和管理人员以一体化的移动服务感受。高性能、高可靠、高安全由于支付平台系统担当的重要角色，高性能、高可靠、高安全是系统追求的主要目标之一，支付平台系统从三个方面着手提高系统的以上特性：针对大业务量的情况，硬件上采用高性能小型机或者高档PC服务器，并采用双机热备或集群容错系统，以提高系统的性能及可靠性。由于业务是处于一个动态发展的过程之中，由于业务的发展，可能造成原有系统不能适应，为了尽可能保护院方硬件投资，综合应用前置系统可以集群方式构建，系统具备负载平衡能力，维护人员也可以进行有效的管理、配制资源。从软件设计上，系统高度灵活，不同交易模块可以相互组合，具备二次开发能力，在同一台机器上，一项交易处理过程，各个交易模块相互之间的调用尽可能处于同一进程内，提高了系统性能与可靠性。面向决策分析的统计报表系统的统计报表可以向决策分析者提供以下三方面数据：各种支付渠道接入的统计数据对系统记录的各种支付渠道、移动终端设备、柜面、自助和pos设备、人员访问系统的时间、频度、处理效率等进行统计，为决策分析者更好的了解各类支付渠道的运作状态提供可比的数据信息。各种支付业务的统计数据对医院已接入的的各种支付业务数据进行统计分析，为决策分析者更清楚地了解各类支付渠道对院方的贡献情况提供帮助。操作风险控制根据相关要求进行支付业务操作风险控制系统功能功能概述XX医院建设统一支付平台后，我院的合作银行或第三方支付公司可以方便快捷地接入到我院系统，在直连银行开户的病友，可直接通过直连银行提供的服务完成缴费充值功能；非直连银行可以通过银联、银行代理或者第三方支付公司的支付通道完成缴费充值；实现实时的资金结算在建设统一支付平台后，利用医院现有的开户行，不完全与一家银行捆绑，各家直连银行之间是平等竞争关系，医院可以主动根据支付平台的推广情况，及银行的服务能力，调整直连银行的服务功能。医院可在建设统一支付平台后，利用平台对外支付功能，拓展院内其他系统的支付结算需求，例如代发工资、对外付款等。诊疗卡充值及缴费业务说明针对已经注册并绑定诊疗卡的用户，通过查询待缴费信息订单，可过院方已开通的支付渠道实时进行充值缴费。业务流程异常处理医院HIS缴费超时，登记异常，自动/手动处理查询支付结果，进一步做后续或失败处理发送金融机构记账超时，登记异常，可发起人工查询缴费结果退款业务说明根据退款请求，将退款的金额实时返还客户。退费方式退现金，包括诊疗卡内余额退现金以及缴费退现金；退回诊疗卡，不涉及资金结算；退回卡，通过卡充值缴费的，可原卡退回；退回第三方支付账户，通过第三方支付账户充值缴费的，可退回原账户；退款规则窗口退款：窗口可退所有渠道的充值缴费；自助退款：只能退诊疗卡余额资金，并且只能退回绑定的银行卡；App退款：绑定了诊疗卡和同名银行卡的用户，可用app的退款功能将诊疗卡余额退回；业务流程异常处理医院HIS退费超时，登记异常自动/手动处理查询支付结果，进一步做后续或失败处理。请求金融机构退费超时，登记异常。可发起人工查询退款结果。统一对账业务说明对账的目的是在医院方和支付方双方产生不一致的账务流水时，按照既定的业务业务标准，有效、及时、安全处理资金流水，进而达到账务清算目的。业务规则集中：多个支付方统一对账，对账操作不分散，对账过程可实时监控，对账结果集中展现灵活：支持自动对账、可设定对账流程，可设定多样化对账规则准确：生成准确对账结果文件，并可根据对账文件进行相应差错处理，保证对账结果数据的准确有效；完整：在整个对账过程，除了对账和差错处理，还可以准确获取当日各银行可结转的资金，监测当日资金的划款结果。业务流程对账机制薪资发放业务说明依据院方提供的工资支付清单，院方通过统一支付平台对接的银行服务接口自动发放工资至指定员工账户。业务流程异常处理如行方工资回单未返回，院方可发起回单申请。文件格式非法，则依据业务规则重新制定或忽略单条继续处理。对外付款业务说明院方财务部门业务人员需向供应商支付的款项（如药品、医疗器材），可通过获取XX医院内部系统的付款指令向对应银行发出支付申请，主动支付货款。业务流程异常处理院方记账超时，调用异常处理，自动或手动抹帐。与银行/第三方支付通讯超时，发起查询或日终对账。技术方案系统架构技术架构图说明：上图所示的整体系统架构中IT架构主要包括：展现层、接入负载层、服务业务层、数据层级系统层五个部分。网络拓扑医院内部系统跟支付平台交互，可通过医院内部局域网现有的通讯方式连接。统一支付平台跟银行、银联或第三方支付实现系统交互时，支付平台直接通过外联支付网关与医院院外系统进行信息交互。系统架构说明整个支付平台（系统）采用集中部署模式，分为支付业务处理平台和支付网关（外联交换系统）两个主要部分和配套的监控管理系统，功能分工如下：支付网关（外联交换系统）：负责直连银行、银联、第三方支付等支付系统的接入，以及报文通讯协议和报文结构的转换，统一通讯通讯协议和报文结构转发支付业务处理平台进行业务处理。支付业务处理平台：负责各类应用的业务逻辑处理、数据库操作和主机接口处理，实现各类支付业务的处理，如缴费充值、退费、清算对账、第三方支付等。提供各类组件，并封装成服务，为各种支付业务流程提供服务。支付平台的业务流程引擎和规则引擎通过对业务规则的定义和业务流程的建模和执行，把业务组件层提供的各种服务按照实际业务需要串接起来，从而灵活地统一调度和管理的服务和流程。监控管理。以可视化的方式通过图形化的图表和工具实现对整个支付平台的远程管理、集中管理，并实时地监控整个支付系统的流程和服务状况。系统的灵活性分层架构统一支付平台采用松耦合的分层架构设计，由负责业务处理的业务平台、负责第三方接入的外联前置组成，各分层之间分工明确，接口标准开放。从整个系统来看，主要分为交易处理层、数据处理层、内联通讯层、渠道整合层、中间业务处理层（AFA和AFE）和第三方接入层。从综合大前置角度来看，包括了内联通讯层（ESB）、中间业务处理层（AFA）和外联通讯层（AFE）。统一支付平台层上集中部署各种应用系统，重点关注业务逻辑的实现。外联通讯层即外联前置关注第三方系统的接入，主要处理通信协议转换、报文解析、消息路由等。通过松耦合分层化的架构，实现了应用与通讯的分离、应用与数据的分离，为整个系统提供了高扩展性、高灵活性的支持。系统独立在统一支付平台中，业务处理平台、外联前置两个组成产品功能独立，均能够独立部署。各个不同的系统（平台）互相独立，业务处理平台（AFA）、外联前置（AFE）都可以实现独立部署、集群部署等。开放协议整个系统构建在SOA的系统架构之上，遵循开放的、标准化的SOAP协议。在功能性方面，系统支持以下标准协议：传输（Transport）：WebSphereMQ、JMS、HTTP/HTTPS、电子邮件、文件、FTP、Socket服务通信协议（ServiceCommunicationProtocol）：XML、SOAP服务描述（ServiceDescription）：XMLSchema、XMLDTD、WSDL、COBOLCopybook、C结构体在普通模式下，系统支持的以下报文类型：定长报文有类型定长报文定分隔符报文变分隔符报文ISO8583报文XML报文HTTP报文循环报文分支报文子报文混合报文其它报文在普通模式下，系统支持的通讯协议：Socket短连接C端Socket短连接S端Socket长连接C端Socket长连接S端带校验的长连接WebServiceHTTP协议FTP协议JMSMQMQ(非JMS)中间件协议（CICS、Tuxedo、EJB）其它通讯协议系统稳定性异常恢复机制业务处理平台具有独立的、可靠的异常恢复机制，能够保障在异常情况下（包括宕机、大范围异常、消息大量丢失），系统能够快速恢复，并且在恢复后数据不丢失并能够继续正常工作。业务处理平台使用可靠的数据库机制，业务数据均存储在数据库中，即使在出现故障的情况下，系统能保证数据不丢失，并在系统恢复正常后，能够继续进行业务处理。故障隔离机制业务处理平台可以实现业务系统的故障隔离，将故障业务的影响减少到最小。服务进程池可以分组管理使用，不同的应用使用不同的进程组。应用之间可隔离的服务进程，可以屏蔽个别异常进程对平台的影响，相对于线程池为可靠、高效，进程可动态增加，以动态调整均衡资源。业务交易运行在独立的进程空间中，不同业务交易之间进行了隔离，屏蔽了交易间的互相影响。应用之间可隔离的消息队列，很好的保护了应用本身的数据区。健康监测机制在业务处理平台中，能对自身系统以及所有接入企业服务总线的系统进行健康检测，当某系统出现故障时，能及时告警，并根据事先设定的策略处理故障。业务处理平台中有一个健康监测服务，可以根据用户策略自动运行或人工启动。它可以对自身系统以及所有接入企业服务总线的系统内部进行回路测试，以监测这些系统是否能够正常工作。当某系统出现故障，回路不能够正常完成，健康监测服务就会根据事先设定的策略进行故障处理。宕机容错机制容错的目的是为了保证数据永不丢失和系统永不停机。从上图上可以看出，为了保证数据的不丢失，采用智能磁盘阵列；为了保证用不停机，数据库服务器采用双机热备方案。另外，在中间（特色）业务层和通信层（外联/内联）采用集群也是一种宕机容错策略，当集群中的某台机器发生宕机后，负载均衡（硬件/软件）会自动将后续的请求转发到其他正常运行的服务器，从而保证系统的不间断运行，提高系统的健壮性。数据备份及恢复业务处理平台提供系统参数、应用参数、系统数据、应用数据、系统日志、应用日志、进程的备份、清理和恢复机制，防止各种可能的问题造成损失，应对应用程序提供失效保护。数据备份数据中心定期定时备份业务现场：对数据备份及其存储介质的保管设立专门的岗位。数据备份方式为：场地内增量式冷备份。数据备份周期取决于：业务数据的流量和业务数据的重要性，因此将随系统运行情况灵活调整数据备份周期。数据备份周期为：每月执行一次完全备份，每周执行一次差分备份，每天执行一次增量备份。对保存数据备份的存储介质（磁盘/磁带/光盘/硬盘），应统一编码，并存放在专门的保密箱/柜中。在《数据备份记录》中给出：备份方式、备份内容、原数据的存储路径、备份数据存储介质的标识、备份起止时间、备份者。数据恢复数据中心在恢复业务现场时，应遵循以下原则：对数据恢复设立专门的岗位，亦可与数据备份岗位合并。数据恢复时要首先经主管部门批准，并有安全管理人员在场。数据恢复前应通知相应业务部门的事件处理人员。若需要业务部门参与（如模拟重演某个时段的业务处理），则数据中心应为相应的业务部门提供详细的操作流程，双方协同完成数据恢复。在《数据恢复记录》中给出：恢复原因、恢复内容、原数据的存储路径、备份数据存储介质的标识、恢复起止时间、恢复者、批准者。支持热部署<系统支持在线热部署功能，系统本身的更新部署不需要停机>业务处理平台支持在线热部署，对于程序脚本、配置文件和报文修改发布后即时生效。当有新开发的交易或者对已有交易作优化和修改后需要部署上线时，业务处理平台实现即发布即使用，平台本身无需重启即可实现交易发布使用的目的。系统安全体系整体安全要求随着医院信息化程度越来越高，伴随而来的安全问题也日益突出，尤其是随着网络规模的不断扩大，网络应用项目越来越丰富，涉及到的人员越来越来越庞杂，部署策略越来越繁琐，整个系统变得越复杂，医院面对的安全风险也越来越大。如何有效地降低安全风险、降低安全成本，安全的策略显得尤为重要。医院的内部办公系统是关键业务系统，需要系统不间断运行。即使发生短暂的业务中断，也会导致难以估量的经济和名誉损失。现有网络资源很难通过灵活有效的策略调整实现业务与网络的充分融合，例如早期医院网络已经很难支撑门诊系统对可靠性、PACS系统对高性能的要求，医院用户对新业务部署的体验感不佳，新业务的部署面临巨大管理压力；网络平台缺乏智能性，无业务识别能力，不能对关键业务应用提供端到端的高质量数据传输的有效保证，医院通常采用的设备升级、链路带宽升级等简单方式使得网络建设、运营、管理成本大幅度上升，而网络资源的利用率却在大幅度下降。目前在网络安全所面临着几大问题主要集中在如下几点： 来自互连网的黑客攻击 来自互联网的恶意软件攻击和恶意扫描 来自互联网的病毒攻击 来自内部网络的P2P下载占用带宽问题 来自内部应用服务器压力和物理故障问题 来自内部网络整理设备监控管理问题 来自数据存储保护的压力和数据安全管理问题 来自内部数据库高级信息如何监控审计问题 来自内部客户端桌面行为混乱无法有效管理带来的安全问题网络安全要求稳定性医疗行业是关系到病人生命安危的重要行业，医院的各种应用系统和基础设备都要保证超高的稳定性，系统的稳定性（7*24稳定、可靠、持续运行）是投入运行的医疗系统的生命线。同时，对于门诊等重要区域，由于门诊收费是患者进入医院的第一站，稳定的网络系统建设是医院各种应用系统开展的根本保障，是降低医院目前出现的“三长一短”问题的根本性措施。高性能作为临床信息系统最为重要的PACS系统的应用其在传输患者的放射图像信息时，需要消耗大量的网络传输带宽，随着医院信息化的发展，堆积如山的胶片、病例档案都没有了，但是网络上数据量却在急剧增长。海量存储和数据浏览就成为必须解决的问题。在计算机中一页文字资料仅占几千字节(Kb)，而一张数字化的X线片将产生上百万字节(Mb)的信息量，这就是所谓“兆字节问题”。防泄密医院的内部信息主要是以病人的病例、处方和医嘱等信息为主，而医院是有义务保障病人的信息安全，保证病人的病例、处方和医嘱信息不被没有必要的部门或人员查看，同时也要保证信息不能外传。因此，如何保证整个系统的保密性、完整性、可用性、可审核性也是医院信息系统安全性的一部分。可管理性随着医院信息化建设的深入发展，医院应用服务的不断开展，数据中心作为医院的各种应用系统的“大脑”，需要保障极高的稳定性和可靠性，为医院的各种应用服务提供持续不断的数据传输服务。通过合理的数据中心规划，提升医院应用服务“大脑”的稳定性和可靠性，各种应用服务提供不间断的数据响应需求。随着网络规模的不断扩大，网络覆盖范围的不断延伸，网络设备数量和种类也在不断的增加。需要通过有效的网络流量和网络故障监控，及时有效的发现网络中存在的各种故障和隐患，以便能够通过及时的故障处理，有效的排出网络故障，降低网络使用风险，确保各种业务的正常开展。同时，先进的网络管理，不仅可以极大的降低医院信息中心的网络维护和管理难度，对于HUB和非网管设备在医院内部的受控使用，可以有效的内部网络的安全风险，提升医院内部网络系统的可靠性。桌面终端安全要求分析传统医疗桌面运维的特点，普遍存在以下几个问题：第一：桌面终端多而杂，维护难度大，故障恢复慢，影响医生工作效率：由于医院系统建设的特点，各科室、各区域各院区的IT建设时间及情况均会出现不同程度的差异，桌面终端往往采购一次就换一批型号，随着时间的迁移，终端类型多而杂，仅终端配件的维护就消耗IT部门大量的时间。与此同时

，终端故障恢复慢，也直接影响医生工作效率，使看病难的问题更加突显，不利于医患关系的改善。第二：桌面系统环境多样，各种兼容性问题突显：由于医院内各类IT系统较多，并且IT系统涉及的厂商较多，桌面系统的维护往往要兼顾众多的系统兼容性问题，部署新的系统也需要面临各种顽石（老旧系统）的阻挠。系统的不断臃肿，兼容性的问题日益突显，导致IT系统建设步履艰难，新系统、新技术的推广难度剧增。第三：工作环境人员流动性大，隐私信息、统方信息管理难：医院工作人员流动较大，特别是在一些公共区域，医生门诊办公室、护士工作站等，每天轮岗的人员较多，终端上的数据及各类系统中的患者隐私信息及药方使用信息，容易在终端上留有痕迹或者直接被保存在本地桌面，终端信息安全管理几乎无从着手。第四：终端固定，无法满足医生弹性办公需求：基于工作需求，医生需要在门诊、急诊、住院部、实验室等不同场所上班。传统的PC终端方案，医生办公桌面与终端硬件绑定，工作数据不能随医生漫游，无法满足医生弹性办公的需求。数据安全要求数据保密性数据保密性是指对一些敏感或重要的数据（如客户PIN）利用密码技术进行加密处理，在整个交易过程中不能以明文方式出现，以防止它被未授权者获得。针对XX医院统一支付平台，数据保密性包括以下内容：对用户和平台管理人员密码的加解密及校验。密码传输。交易报文加密。文件加密。数据保密性处理的基本处理流程一般为：1、数据传输前对敏感数据字段，如客户密码等，用工作密钥（PPKEY）进行加密处理。2、数据接收方收到数据后，得到加密数据，使用相应的工作密钥进行解密，或者更换为新的密钥加密。数据完整性数据完整性是指在业务处理过程中必须防止交易数据被意外或人为的修改。通常可以通过计算数据MAC值并增加MAC字段来解决。XX医院统一支付内部支持MAC或DAC校验值的函数接口或安全服务。一般处理流程为：数据传输前对数据包关键字段使用工作密钥（MACKey）进行MAC值计算，将该值存放到数据包预定位置。数据接收方在收到数据后，得到报文数据，同样进行MAC值计算，校验两者是否一致。身份认证身份认证是指任何用户在进入计算机网络或计算机系统之前，必须首先向网络或计算机给出能表明自己身份的鉴别标志，经鉴别核实后方被允许使用系统。XX医院统一支付支持常用身份认证机制来实现接入端的合法身份的认证，以避免接入端的伪造和篡改。XX医院统一支付对所有外部系统在注册时进行用户管理和认证。各外部系统在向通讯前置平台注册时，提交连接用户名（外部系统编号）和用BaseKey（密钥交换密钥）加密过的用户口令，以确定注册用户是否合法，如果合法则同时下发该外部系统的工作密钥数据。或者：一方对双方约定的数据用同一密钥加密，另一方解密校验成功则表示认证通过，然后上级系统下发密钥或者下级系统接收密钥。系统安全要求XX医院统一支付的安全控管服务模块提供完整的金融系统安全控管方案，让所有的应用程序都遵循一致性和符合标准的安全机制，以防止内部人员舞弊及外部非法入侵所造成的损失。用户身份认证所有的用户均需要提供用户ID（UserID）、密码（Password）或者企业ID（CorporateID）来登录系统，以获得所需的服务。本机制可将上述认证数据送入系统主机或根据预设的客户认证策略来进行身分确认，并可提供多种认证方式提供系统来依据服务项目及需求定制设定，诸如用户禁用、上次成功/失败登录时间、密码过期日期及可允许密码错误次数等检查项目及设置，本机制可以与业界安全标准SSL及诸如PKI凭证和动态密码卡等身分认证机制配合使用。方位权限控制可管理用户对特定服务的访问权限，系统人员可提供定制化的服务规则如工作日、节假日…等，并将其对应到所需的服务或服务群组；另外再根据企业安全的控管原则，将用户或用户组对应到相对的服务或服务群组即可，用户只能使用他被授权使用的服务和服务规则。会话控制Session指的是用户从登录某个特定系统到离开系统为止的那段时间，本机制除了可以控管及追踪使用者从开始访问本系统到离开的所有动作外，并可设置用户在闲置一定时间后系统自动退出、同一时间内系统的最大用户数量、最大Session数量、单一用户可使用的Session量等许多安全机制，防止用户仿冒或外部非法侵入。安全审计为了保证系统的安全性，安全控管还包括了模块化的日志机制，除了可用来作系统调试、流量和用户行为分析外，还可监控外部用户的非法入侵行为；在分布式系统架构下，可通过JMS技术将所有的日志集中管理。系统人员可根据需求设置日志的内容如DEBUG、INFO、WARN、ERROR、及FATAL等级别，并可选择性的将日志数据以多种形式输出，如Console、DB、File或JMS等，供事后跟踪和分析使用。应用系统容错要求• 应用隔离不同的应用部署运行在独立的进程空间，拥有独立的监听端口。• 交易隔离每个交易都在独立的进程中运行，进程在进程池中统一管理。• 数据库事务处理逻辑流程支持默认错误处理，在处理中考虑对于数据库事务的处理，保证数据的一致性。• 基于规则引擎的交易自动冲正对于超时或者异常的交易，平台会基于规则引擎来自动完成冲正交易，保证账务的正确性。• 服务监听和进程监控• 定时侦测平台监听• 僵尸进程的检测和自动恢复重启• 应采用异步核心处理机制，可有效避免服务挂起报文加密要求使用通过国家专业部门认可的可靠加密算法配合动态密钥，保证对报文的整体加密的高效率、高可靠性以及高安全性，以取得整体的平衡。XX医院统一支付平台支持多种报文加密及校验算法：DES/Tripl－DESRASRC2/RC4SHAMD5CRC8/CRC16/CRC32MACDAC用户自定义加密算法用户自定义校验算法加密机等硬件加密……消息排重要求XX医院统一支付平台内部应支持消息（交易）重复控制，能有效防止请求方异常情况下的消息（交易）的多次发送，保证系统及帐务的安全可靠。对于重复消息（交易）的处理，用户可以设置成丢弃，也可以自定义处理流程。当设定为自定义流程时，一旦请求方发生重复消息（交易）时，该流程会被自动调起用于处理该重复消息（交易）。对于重复消息（交易）的检测，系统支持多种模式，系统内部支持关键字数据比较，报文MAC校验比较等常用判断方法，同时用户可可以设置自定义判断方法，用于特殊情况下的重复报文检测。开发流程完整系统开发流程统一支付平台具备完善的开发过程、测试、及上线流程及方法。上线流程及方法在版本管理章节介绍。基本介绍下图为描述了从需求到版本的系统开发过程和方法。 系统快速开发过程数据字典差异化分析，增加数据字典项服务接口服务接口数据项增加服务接口增加数据上下文数据上下文映射业务组件新增业务组件开发、注册、发布技术组件新增技术组件开发、注册、发布交易模板新增交易模板开发、注册、发布交易开发修改图形化交易开发修改上传服务器远程调试时上传服务器测试调试本地或远程调试代码，如有问题继续交易开发修改版本入库完成测试后的版本入库通过业务模型开发过程产品模型的差异化分析数据字典、数据结构和服务接口的完善数据字典完善、数据上下文配置、公用数据库表完善产品模型中新技术组件的开发和技术实现流程的实现业务模式、业务规则，参数配置原子流程和组件与银行现有系统的接口对接应用实例的业务流程配置和业务参数配置应用产品的具体开发、测试、验证应用产品的入库管理版本管理及升级方案统一支付平台具备完善的版本管理及升级方案，详细介绍参见版本管理章节所述。源代码及文档承诺提供平台及应用的全部源代码、相关文档及相应程序API。承诺提供平台组件扩展接口和相关组件开发培训。具体关于知识产权的详细承诺参考技术支持与维护中关于知识产权的承诺章节。支付业务模块构成平台整体模块结构支付业务整合平台在整体技术架构下，以基础技术平台和应用开发平台为技术平台，主要分为技术功能层和业务功能层，所有的支付应用系统都属于业务功能层的具体应用系统。每个系统以及今后新的支付应用作为业务功能层中应用层的具体应用系统，复用业务功能层中的业务组件、业务流程和业务模型模板，采用构件式开发模式提高系统开发效率和质量。平台技术功能层平台技术功能层分为渠道整合层、平台基础层和技术组件层三个层次，每层的具体功能和实现方法如下：渠道整合层具体的渠道应用管理，如柜面业务渠道、电子服务渠道、自助渠道等。统一渠道应用的技术体系，通过表现逻辑和渠道业务逻辑分离的方法，统一构建整合的渠道环境。分为渠道接入管理、渠道特有应用逻辑处理、渠道统一接口管理、集中的安全控制和认证管理、管理和统计功能等五个功能模块，具体功能如下：渠道接入管理：负责接入各个不同渠道并产生适合的表现数据，并向渠道服务层提供与渠道特性无关的请求数据；渠道特有应用逻辑处理：符合每个渠道的特点和要求的应用逻辑；渠道统一应用逻辑层：包含着提供给渠道服务层的所有产品，服务，业务规则，事务和客户对象的配置，产品和客户对象提供了统一的、一致的产品和客户信息；如支付业务渠道的统一管理，确定每个渠道开通了那些支付业务产品品种；渠道统一接口管理：为渠道应用逻辑提供统一的对后台服务的访问接口，屏蔽后台系统的复杂性集中的安全控制和认证：负责渠道统一的加密和用户认证，简化系统的安全机制，通过接口调用安全服务平台相关的功能服务。管理和统计功能：负责渠道的配置管理，并提供渠道整合相关数据的各种统计功能平台基础层：提供平台基础的运行功能模块，主要有：平台监听模块：多进程、多线程分组的应用监听；消息管理模块：基于消息队列管理的异步处理模块；服务进程模块：分组服务处理进程模块；流程调度模块：实现基于消息队列的异步服务流程管理；容错处理和监控模块：平台监听、服务进程、消息队列、数据库连接等功能模块监控和服务进程容错处理事物控制模块：交易事物一致性管理；日志管理：提供多级别的日志管理……技术组件层：提供平台通用的技术组件，和具体应用和业务无关；如下述组件：逻辑控制：支持顺序，循环，条件，分支支持内部变量支持表达式运算支持方法：(实现扩展接口)常用字串操作方法XML操作方法数据库操作方法通讯处理方法加解密方法文件传输方法数据字典管理校验控制方法报文处理方法……平台业务功能层平台业务功能层分为应用层、业务流程层、业务组件层和模型层四个层次，每层的具体功能和实现方法如下：应用层：实现具体的支付业务产品，如大额、小额、全国支票影像交换、同城支付等业务流程层：根据支付业务的具体特点，提供下述公用业务流程：账务类查询类对账类清算类批量类管理类凭证管理类手续费管理类……业务组件层： 提供组件库和交易模板，支持快速开发，积累业务模型和产品模型。业务组件库可分为：组件库分层设计平台组件库各客户方特有组件库应用组件库（支付平台具体应用产品专用）客户级组件库分类操作员管理类介质管理类权限管理类支付报文处理类支付渠道管理类支付汇路管理类支付手续费管理类客户信息类查询类账务类流水类对账类清算类……模型层：描述了业务运作的过程，它可以通过一组资源视图展现，如数据视图、流程视图、组件视图等。业务模型可以作为应用产品开发的基础，开发人员可以快速的引用/复制业务模型中的资源，加快开发的速度，具体主要由针对具体业务应用产品的的通用数据模型、业务流程和基于应用的组件库组成，具体如下：数据模型：公用数据字典、公用数据结构、服务接口数据上下文；业务流程：公用业务流程、业务规则参数、交易模板组件库：平台组件、客户方特有组件、应用开发组件；应用设计说明业务处理应用主要是指业务处理平台对各种业务类型的联机或批量事务的业务处理，并且在业务处理过程中，通过业务控制管理的功能，实现业务逻辑的控制以及通过调用或引用支付平台提供的服务和功能统一业务处理模块快速实现业务功能。包括支付、退费系统模块、对账清算模块、系统运维与管理等应用模块。支付系统业务规则管理主要是指对支付、退费等账务类业务处理过程中涉及的业务规则进行定义，业务规则是控制业务流程执行方向，分别说明如下：缴费规则管理：主要是设置充值或缴费的规则，根据诊疗卡信息或者缴费订单信息，与预先配置的处理规则进行匹配，若满足预定规则则按规则处理。退款规则管理：根据退款渠道、退款金额、退款方式等设置退款规则，每笔退款都与业务规则进行匹配，并按照规则设定的路径进行退款；差错处理规则管理：主要是设置日间异常和对账差错的处理规则，根据差错所属支付渠道、差错类型、差错场景、业务状态等信息定义差错后续应该采取的处理流程。业务公共控制管理业务公共控制管理是指统一支付清算服务平台定义了一系列标准的业务控制和检查机制，在业务处理的公共流程中对上述管理维度进行检查。主要包括产品管理、服务管理、业务管理、机构管理、渠道管理、流动性管理、其它业务参数管理：产品管理：对所有支付应用产品以及平台服务产品的基础信息，以及运行信息进行管理，业务发起时检查所属产品的运行状态，当产品正常运行时才可发起相关业务，综合业务运行平台可查询并维护产品基础信息以及产品运行信息。服务管理：对统一支付清算服务平台对外发布的服务接口和功能状态进行管理，维护服务接口信息，维护服务状态信息，当渠道发起业务调用服务接口时对服务状态进行检查，检查服务状态是否开放，并按服务接口信息进行接口映射。综合业务运行平台可维护服务接口信息及服务状态。业务管理：统一支付清算服务