医疗电子票据平台部署方案.docxVIP

医疗电子票据平台部署方案 前言 该文档可作为部署方案模板，系统部署方式可根据实际运行环境进行调整。 概述 医疗电子票据平台是集电子票据管理、纸质票据管理、电子票据交付通知管理、电子票据档案管理等若干个子系统组成的全功能管理系统。医疗电子票据管理系统功能符合财政部门票据监管要求，实现院内票据管理、数据核对、档案管理、财务入账。电子票据交付通知的功能优化了患者院内取票流程的同时并实现了患者电子票据云端归集。 部署结构 如上图所示，鉴于在日常医院业务办理场景中，医疗电子票管理平台和医院HIS系统需要频繁的交互，因此将医疗电子票据平台部署在医院的内网。通过内网链路实现和医院HIS系统、财务系统进行交互。同时医疗电子票管理平台将需访问财政的数据通过内外网隔离设备及边界隔离设备交换至外网区，再通过政务外网、专线、互联网等方式实现与财政互联互通。 如上图所示，说明如下： 医疗电子票据平台网络架构分为三层：即Web层、应用层和数据层。 Web层：通过部署Web服务器(Ngnix均衡负载) 或专用硬件服务器负载聚恒设备实现请求分发，医院HIS系统调用Web服务器，由Web服务器进行负载均衡处理分发到医疗电子票据平台；医疗电子票据平台访问Web服务器部署的Nginx反向代理互联网的财政电子票据服务地址和博思票据云地址。实现与财政部门的数据交换和患者取票、票据归集等业务。 应用层：该层为具体的业务逻辑实现层，应用服务器部署主程序（可通过部署多台实现应用群集），缓存协调服务器部署缓存及其他相关组件，签名服务器实现医院单位端的票据签名功能。并通过应用服务器及签名服务器的冗余部署实现关键节点的可靠性保障。 数据层：该层实现了医疗电子票平台两类数据的存储，业务数据存放于关系型数据库（Oracle RAC）中，关系型数据库通过oracle RAC架构实现高可用性，即通过部署两台数据库前端服务器并通过外接存储设备实现数据库群集。电子票板式文件存放于小文件存储服务器中以实现开票单位的票据归集。 部署环境要求 医疗电子票据平台应用服务器都必须建立高可用的集群环境，有异常时可以自动切换运行，保证系统的可靠运行。设备上推荐运行Linux的高性能PC服务器，要求cpu支持64位操作系统，支持虚拟分区技术，各个层次的硬件平台的建设应结合计算机和通讯技术的发展，按照可靠性、实用性、先进性、可扩展性和可管理性原则进行构架，从而支持财政票据系统的顺畅运转，满足不断扩展的业务处理的需求。 经调研该医院年就诊量为400万人/次，根据医疗票据建设经验患者平均就诊一次产生2张票(保守估值)，预计电子票据全面上线后一年将产生800万份电子票，平均一天产生约2万份电子票。按照医院整体业务特点及体量，本方案采用2台应用服务器作为医疗平台的集群环境。 服务器作用 服务名称 用途 网络要求 WEB服务器 反向代理服务、负载均衡服务 访问互联网与财政票据系统对接 映射至医院内网，实现HIS系统接入 缓存、协调服务器 分布式应用程序协调服务 文件系统服务器 存储医疗电子票据版式文件 数据库服务器 存储医疗电子票据平台产生的业务数据 身份认证、签名服务器 数字签名、身份认证 与医疗电子票据平台对接，完成单位签名 网络情况 医疗电子票据平台整体部署在医院内网区。医院业务系统（HIS系统、自助机等）、院内工作人员通过内网实时访问。同时需考虑与财政电子票据系统、博思微信小程序通过互联网对接，可需将WEB服务器部署在医院外网区访问财政票据系统和博思微信小程序在互联网的对接地址，通过部署NGINX实现反向代理互联网地址。医院内网的医疗电子票据平台通过访问WEB服务器对应的NGINX地址来访问财政电子票据系统和博思微信小程序。 数据测算 数据库 医疗电子票据平台中，数据主要分成三类，一类为静态数据类，一类为动态数据类，另外一类为数据库管理系统自身所需的基础数据，如回滚段、临时表空间、日志归档等。静态数据类是指数据在系统初始化完成后数据量变化不是很大，相对保持在一定范围之内，不会随着业务系统的使用而成线性增长，这类数据主要包含系统基础数据配置、用户信息、权限等；动态数据类是指随着业务系统的使用，数据量呈线形增长，该类数据主要包含财政电子票据、财政纸质票据、财政票据明细信息等业务数据；由于数据库系统自身所需的存储空间与数据库系统的环境配置有很大关系，因此这里不做估算。 根据统计，医院年开票量在800百万份左右（包括财政电子票据和机打票据），在系统设计中，每份财政电子票据在系统中存储大约需要20k（包含医疗明细清单数据），按照这个容量来看，业务数据大约需要存储空间大约为： 每年业务数据存储空间 = 800W*20k ≈ 153G 按照系统设计和业务特点，生产系统中按照保留3年的数据的规划，这样，业务数据存储空间大约为