医保支付平台项目建设方案Word格式文档下载.docx

医保支付平台项目建设方案Word格式文档下载.docx

《医保支付平台项目建设方案Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《医保支付平台项目建设方案Word格式文档下载.docx（10页珍藏版）》请在冰豆网上搜索。

为了防止系统较高的交易频次和事后审核大批量数据进行批处理降低实时结算整体性能，影响几百万参保人实时刷卡结算，事前就诊管理系统和事后审核监督系统与医保结算系统相互独立建设，各个部分内容单独设计考虑，在技术架构设计上实现相互分离。

4.1.1.3系统安全规划

安全性要求与医保结算系统同等级，要求在医保定点机构接入的状况下，确保数据传输、交易以及数据发布的安全，同时由于在全省范围统一使用和访问省级集中的医保支付平台，因此在应用访问层面、网络层面需要确保系统安全。

4.1.1.4原有系统数据采集接口

依托人力资源和社会保障业务专网和市、县数据中心，在现有的信息系统上，对原有医疗机构的数据进行实时采集，通过中间库进行实时汇总和上报，确保数据的及时性和可靠性。

4.1.1.5审核监督系统

依托人力资源和社会保障业务专网和市、县数据中心，在现有医保服务信息系统基础上，扩展建设某医保审核监督系统并实现有机衔接，对参保人日常就医行为进行事后审核分析。

制定基本医疗保险服务监控规则，逐步扩大“机审”功能，实现对就医购药信息的自动筛选和分析、疑点问题发现与核实处理等稽核管理，在各类医疗服务行为发生环节实现对所涉参与方进行全面监控。

4.1.1.6完善医保结算系统的事中控制

完善医保结算系统，实现医疗费用结算过程的事中控制，实现结算过程中确定规则的监控管理。

4.1.2总体设计原则

本项目建设将遵循人社部监控审核系统和医保支付平台的功能建设要求，在项目总体框架下，从本项目的建设要求出发，结合实际业务的需要，充分利用信息化技术，对本项目进行全方面的设计。

4.1.2.1遵循标准、规范建设

为保证整个工程建设的规范性和可管理性，本项目需建设一套标准规范体系，在建设实施中应严格按照相关标准规范组织建设实施，尤其是针对应用系统设计，将统一遵循应用开发与集成的规范，保证本项目应用建设的规范性和可集成性。

其中医疗服务监控规则的制定，需要在完全符合国家、部、省各相关文件要求的基础上，进行科学的、本地化的适当扩充。

4.1.2.2先进性和成熟性

医保支付平台设计要充分体现“恰当”耦合的特点，满足“金保工程”建设的要求。

把科学的管理理念和先进的技术手段紧密结合起来，提出先进合理的业务流程，真正做到紧扣医疗服务监控业务未来发展方向。

系统应运用先进成熟的技术手段和标准化产品，确保系统具有较高性能、较强的生命力，有长期的使用价值，符合未来的发展趋势。

4.1.2.3经济性和实用性

信息系统性能优良，价格合理，具有较好的性能价格比，帮助用户节省投资，做到物有所值；

设计应面向实际、注重实效，坚持实用、经济的原则，应充分合理利用原有设备和信息资源，应用软件应考虑用户的操作习惯，为用户提供友好的操作界面以及丰富的联机帮助，全面提升系统的实用性和经济性。

4.1.2.4可扩展性和易维护性

设计时应充分考虑医保支付平台在未来若干年内的发展趋势，具有一定的前瞻性，并充分考虑系统升级、扩容、扩充和维护的可行性。

并针对本系统涉及数据量大的特点，充分考虑如何大幅度提高业务处理的响应速度以及统计汇总的速度和精度。

根据业务管理的需要，所有的应用都是在当时的业务格局下规划的，由于业务可变化的特点，如监管数据的增加、监管方法调整、审批流程的更新等变化，导致应用的调整，就要求应用能够在尽量减少程序变动的前提下方便的进行扩展，在扩展的同时又不影响已有功能的正常使用，对此，在系统技术架构上要考虑采用方便扩展的技术框架。

4.1.2.5灵活性和兼容性

设计时应充分考虑医保支付平台的灵活要求，随用户需求的改变而及时调整，通过合理的模块划分及参数规则灵活配置，实现应用软件对业务变更或软件技术发展的灵活适应能力。

本项目的应用系统，从业务角度分析，需要实现监管部门与被监管单位之间的数据共享，尤其是对监管数据的采集利用。

加强信息资源的开发利用，通过加快信息整合、目录体系和交换体系等基础信息系统的建设，促进信息资源的广泛利用，加强监管部门之间的信息资源互联共享。

具体设计方法将采取统筹规划数据共享、统一指标体系、统一数据库管理的办法达到资源的充分整合利用和信息共享。

4.1.2.6及时性和高效性

设计应全局考虑，充分优化库表结构，精准表达业务算法，高标准要求编码质量，在满足医保支付平台平稳运行的前提下，充分考虑用户对应用软件及时响应和高效运转的要求规范性和特殊性。

系统建设必须严格遵循国家、部、省的相关规定。

国家、部、省已有相关规范的，必须按照规范建设。

同时，应兼顾本地业务的实际需求，适当调整、发展系统功能，在规范的基础上形成具有鲜明本地特征的应用系统。

4.1.2.7应用先进、系统稳定

医保监控业务随着监管手段的不断创新，对医疗监控业务信息化也提出了更高的要求，对实时数据的采集、处理、存储和传输，以及多样性的数据服务都提出了挑战。

在系统架构和应用功能上，应当结合本项目所涉及的业务（数据）特点，采用先进的数据传输、处理、存储技术满足日益增长的要求。

同时，由于系统要保证不间断的稳定运行，必然要求所选择的技术手段要有高度的稳定性，不能仅注重技术的先进性，两者在系统建设中要相结合。

4.2系统架构设计

4.2.1总体架构设计

4.2.1.1系统业务功能架构设计

平台采用基于B/S的多层架构体系，并独立于医保结算系统部署。

业务功能架构图如下：

图4-1医保支付平台系统业务功能架构

4.2.1.2系统总体业务逻辑图

平台依照“数据向上集中，审核监管服务集中建设，服务向下应用”的原则，全省各统筹区根据统一的基础数据指标规范，将生产库中的基础数据抽取转换到交换库，并通过同步软件实时将数据复制存放到集中建设的全省资源库中。

系统总体业务逻辑如下图所示：

图4-2系统总体业务逻辑图

4.2.2系统平台架构

收集各医保数据中心以及两定机构的结算数据、诊疗数据等信息，来实现本级和各市（县）的数据统一、审核统一、提醒与调阅统一，原有医保结算系统架构保持不变。

4.2.2.1系统平台（接口）设计

对于结算明细数据上传，由本级和下属市（县、区）的医保结算系统定期以准实时方式将新产生的数据存入一个中间库，再通过数据交换软件从中间库中采集这些数据并同时存入前端人群数据库和后端分析数据库。

其中，为避免对市本级医保结算系统的影响，市本级医保结算系统将通过数据库同步软件以旁路方式将新产生的结算明细数据推送到市医保数据中心的结算明细中间库。

而对于Web调阅，则由医保支付平台通过HTTP协议发送Web调阅请求，再通过各接口访问市数据中心的Web应用服务器，通过WebService调用完成相关业务逻辑，获取Web调阅数据后沿原路、按原方式实时返回给医保支付平台。

4.2.2.2系统扩展性设计

本架构具有很强的伸缩能力。

当业务负载增加后，可以根据需要在不同层次进行水平扩展。

Ø

当增加新的人群后，可以增加新的人群数据库服务器（添加扩展模式），同时需要更新接入路由服务器上的交易路由软件算法。

当单台人群数据库服务器的负载过大时，可将其拆分为两台人群数据库服务器（分裂扩展模式），同时需要更新接入路由服务器上的交易路由软件算法。

当数据交换服务器的负载过大时，可以增加新的数据交换服务器，通过为下属县-市配置连接不同的数据交换服务器，实现客户端分担负载。

当交易应用服务器的负载过大时，可以增加新的交易应用服务器，将其加入交易应用服务器的负载均衡集群。

当Web应用服务器的负载过大时，可以增加新的Web应用服务器，将其加入Web应用服务器的负载均衡集群。

当接入路由服务器的负载过大时，可以增加新的接入路由服务器，将其加入接入路由服务器的负载均衡集群。

4.2.2.3系统云平台设计

医保支付平台采用“云技术”为事前就诊管理系统提供支持，云存储将大量不同类型的存储设备通过软件集合起来协同工作，共同对外提供数据存储服务。

云存储系统具有如下特点：

第一，从功能需求来看，云存储系统面向多种类型的网络在线存储服务。

第二，从性能需求来看，云存储服务首先需要考虑的是数据的安全、可靠、效率等指标，而且由于用户规模大、服务范围广、网络环境复杂多变等特点，也面临更大的技术挑战。

第三，从数据管理来看，云存储系统不仅要提供类似于POSIX的传统文件访问，还要能够支持海量数据管理并提供公共服务支撑功能，以方便云存储系统后台数据的维护。

基于上述特点，云平台整体架构可划分为4个层次，自底向上依次是：

数据存储层、数据管理层、数据服务层以及用户访问层。

云存储平台整体架构如图所示。

图4-3云存储平台整体架构

（1）数据存储层云存储系统对外提供多种不同的存储服务，各种服务的数据统一存放在云存储系统中，形成一个海量数据池。

从大多数网络服务后台数据组织方式来看，传统基于单服务器的数据组织难以满足广域网多用户条件下的吞吐性能和存储容量需求；

基于P2P架构的数据组织需要庞大的节点数量和复杂编码算法保证数据可靠性。

相比而言，基于多存储服务器的数据组织方法能够更好满足在线存储服务的应用需求，在用户规模较大时，构建分布式数据中心能够为不同地理区域的用户提供更好的服务质量。

云存储的数据存储层将不同类型的存储设备互连起来，实现海量数据的统一管理，同时实现对存储设备的集中管理、状态监控以及容量的动态扩展，实质是一种面向服务的分布式存储系统。

（2）数据管理层云存储系统架构中的数据管理层为上层提供不同服务间公共管理的统一视图。

通过设计统一的用户管理、安全管理、副本管理及策略管理等公共数据管理功能，将底层存储及上层应用无缝衔接起来，实现多存储设备之间的协同工作，以更好的性能对外提供多种服务。

（3）数据服务层数据服务层是云存储平台中可以灵活扩展的、直接面向用户的部分。

根据用户需求，可以开发出不同的应用接口，提供相应的服务。

比如数据存储服务、空间租赁服务、公共资源服务、多用户数据共享服务、数据备份服务等。

（4）用户访问层通过用户访问层，任何一个授权用户都可以在任何地方，使用一台联网的终端设备，按照标准的公用应用接口来登录云平台，享受云服务。

4.2.3网络平台架构

4.2.3.1网络平台设计

医保支付平台涉及的用户类型主要包括本级和下属市（县）两类。

在网络层面，也分为两大类，本级接入用户和市（县）接入用户。

在网络层面分别构建不同的功能区域部署相应的设备实现诊疗监管业务。

医保支付平台应同时满足对IT和业务的管理需求，管理人员可以从最终用户的视角了解应用运行状况，然后根据业务需求提供服务水平。

通过管理平台了解基础构架和业务数据的变更将如何影响应用，并采用恰当的手段确保应用的性能和可用性。

最医保支付平台从所有这些相关的地方收集数据，确认问题原因，并用最快的方法解决问题，从而保持业务的平稳运行。

4.2.3.2网络安全设计

按照实时交易优先和故障隔离的原则，在原有数据中心构建相对独立的某医保监管业务功能区域，在该区域部署路由器、交换机、负载均衡以及安全设备实现医保支付平台安全域的构建。

同时考虑医保支付平台的主要业务采用B/S架构，相对原有实时交易的C/S架构，安全漏洞的类型存在较大差异，所以将其作为一个单独的安全域进行管理，整体上按照数据中心等级保护三级的要求统一建设，在医保支付平台安全域网络边界部署防火墙，在服务器前端部署WEB防护等安全设备保证信息系统安全，根据安全域独立的原则，网络审计、数据库审计、入侵检测等是基于网络端口镜像的安全设备，也建议单独部署，实现某医保监管业务数据流和实时交易业务数据流的相对隔离，避免对设备处理转发性能、网络带宽、安全策略的相互影响，同时保证故障隔离。

4.2.3.3硬件需求

为实现各项应用功能，除了部分复用原有的服务器资源和存储资源，还需要为现有的资源池增配服务器，扩充存储容量，以满足业务发展的需要。