统一支付平台，作为区域内医疗卫生服务的支付中心，统一管理区域内的医疗支付应用、支付通道，规范区域医疗支付应用体系，为区域医疗卫生服务提供支付能力支撑，实现区域内的居民健康服务多样化支付方式按需选择，区域内健康服务便捷支付；实现区域内医疗支付统一管理，提高管理机构效能；以支付驱动区域内的医疗服务资源、资金资源的融合与金融服务资源的引入，优化支付供给，驱动区域医疗卫生服务体系良性发展。

居民健康卡作为区域内的居民健康身份识别共享介质，在就医过程与区域内健康管理中，涉及与多机构、多入口、多应用的对接。

医疗场景下的支付方式、支付入口、支付渠道多种多样，各家医疗卫生机构就医支付也存在差异，且目前更聚焦院内就医支付场景，如自助服务终端缴费、人工窗口缴费和手机移动端应用缴费。因而，区域医疗支付环境将更加复杂，建设压力将更大。

通过建立统一的支付平台，综合各系统、机构、应用的统一接入；基于电子健康卡应用，综合区域内医疗卫生场景下的支付能力支撑，健全区域内医院交易数据，区域内交易数据的统计分析与交易监管，为加强区域医院综合管理提供决策依据。

通过平台标准架构建设，实现从区域内多个医疗卫生机构到单个医疗卫生机构业务场景中的电子健康卡支付应用的统一管理，以及多个医疗卫生机构的标准接入、规范管理，高效复制，快速覆盖。

统一支付平台系统架构见图6-17。

构建支撑区域医疗卫生机构的两级平台架构，区域统一支付平台对接区域应用（系统），集成区域支付通道；院内搭建平台前置系统（或建设二级平台）对接院内应用（系统），与区域统一支付平台打通，实现院内与区域信息通道的互联互通。

统一支付平台采用面向服务架构（Service-Oriented Architecture，SOA），通过功能服务组件和业务服务接口方式，实现灵活的业务功能扩展和业务接入。核心服务组件（业务组件、支付组件、消息组件）采用服务注册和统一路由控制方式进行分布式部署，通过路由规则的灵活配置实现组件异常和高负载情况下的无缝处理接管和负载均衡控制，数据库采用分层分级部署，实现软件系统“双机”控制的容灾备份处理。

业务集成采用的消息中间件基础框架，实现统一的消息路由管理和消息跟踪机制。作为各种患者入口应用与院内系统间的信息交换和业务协同平台，实现信息的安全、标准化集成交换，业务接口的适配等，在数据传输处理过程中通过消息队列机制按照特定的顺序来处理保证了数据的可靠性、并发性。支持多种接口协议方式，支持HTTP（hyperText transport protocol）、Web Service、TCP/IP（transmission control protocol/internet protocol）、存储过程等接口的协议及数据格式的多样化，便于第三方应用快速接入和授权管控，实现了应用与院内系统之间的业务分离，减轻应用系统访问内院系统的压力保障系统的运行稳定性、安全性。

支付集成主要以各种支付通道（支付宝、微信、移动医保、电子优惠券、银联在线、银行卡支付等）的统一集成接入医疗场景（挂号缴费、处方缴费、检查检验缴费、住院预交金等）为核心能力，根据不同的应用场景提供不同的支付SDK。应用系统将订单信息发送到统一支付平台，统一支付平台通过对数据签名加密后，根据分配的各家机构商户编号区分并支付到各家医疗机构，完成医疗卫生机构交易结算和账务管理，如：订单交易统计分析、账务统计分析、自动对账及单边账处理等，通过报表、统计图等方式展示订单信息和对账信息。

针对第三方业务应用的统一支付能力组件签名授权调用，交易过程中的数据进行加密传输，交易记录加密存储和冗余备份，业务及交易数据分级隐私保护，以及交易异常及单边账产生后的及时预警和后处理机制。各渠道商接入的管控，监控渠道商接入平台数据交互中的一些异常行为，例如重复请求攻击、数据篡改等。建立整体系统部署的防网络攻击安全机制，一旦发现异常行为立即采取开关控制接入。

遵循居民健康相关建设标准及规范，遵循地方卫生健康委建设要求，遵循金融支付相关规范，结合区域具体情况，多层面考虑，优先打好业务和技术基础，充分考虑医疗场景下的电子健康卡的功能及应用，规范设计支付过程的业务信息流，标准化、规范性处理资金归集，并为后续丰富应用扩展的便捷、高效实现提供支撑。

平台基于互联网开放与互联的特性，将“互联网+医疗服务”融合，可灵活对接基于区域的健康应用及院内系统，集成多种支付通道，供外部应用灵活调用，支撑医疗健康业务场景中的支付能力打通，实现区域医疗健康多支付方式使患者按需选择。

从支付安全和金融安全角度出发，设置交易安全机制和风险防控机制；基于医疗场景的特殊性，部署网络安全机制，包括内外网防火墙部署；涉及支付的交易的验密以及交易过程中的敏感信息脱敏，充分保障系统安全与用户的信息安全。遵照金融安全标准，通过第三方权威专业检测机构支付应用安全测试。

在数据库系统和网络系统的多层管理和安全体系控制下，采用服务注册和统一路由控制方式进行核心服务组件分布式部署，通过路由规则的灵活配置，实现组件异常和高负载情况下的无缝处理接管和负载均衡控制；业务组件、消息框架、数据库分层分级部署，实现软件系统“双机”控制和消息框架的容灾备份处理。

针对区域医疗健康业务变化需求，系统遵循可扩展性设计原则，采用具有良好可扩展性的数据交换平台和消息中间件，能够灵活适应将来系统功能变化要求。

统一支付平台为商户提供多样化的服务内容，减少商户接入、维护支付结算服务时面临的成本支出，提高商户支付结算系统运行效率，并收取增值收益的支付服务，主要包含以下内容：

外部应用系统统一接入、管理，包括区域电子建卡管理应用系统、区域健康移动应用（APP、支付宝、微信）及其他第三方应用等。

统一支付平台为每个用户建立个人虚拟账户，并与电子健康卡一一绑定，该个人虚拟账户下可以建立多个二级业务账户，如：预充值账户、信用账户、绑定医保账户、绑定商业健康保险账户、金融支付账户、积分账户等，通过各种类型的账户绑定与优先级设置，在各医疗支付场景下，按个人不同用户属性，实现灵活的组合支付能力。

实现接入的医疗卫生机构服务渠道管理，细分窗口、自助终端、移动应用等多个服务渠道，并可独立为每个商户服务渠道进行支付能力配置；通过商户账户管理，可为各个商户服务渠道设定资金归集规则；可为商户提供通过支付平台完成支付的电子对账单，便于各医疗卫生机构进行对账处理。

集成多种支付金融渠道支付能力，用户按需选择，包括金融机构、支付宝、微信、医保、商保等支付通道统一管理，并提供统一的支付网关供应用调用，完成医疗场景下的支付业务，并可按需配置，按各医疗机构的业务场景和对应的金融支付通道进行管理，根据医疗机构的不同需求灵活配置所需要的支付方式。

对商户的订单信息进行查询、统计、分析管理，接入统一支付平台的外部应用产生的订单集中分类别进行展示，可按照时间周期、订单状态来查询。提供退费交易的查询，以及退费的审核处理流程，对需要退费交易的订单进行处理。

财务对账管理，提现每日自动对账，包括完成支付渠道与统一支付平台的对账，通过被动或主动的方式将对账单提供给各医疗机构，并提供异常账处理机制，以及财务报表输出。

实现区域内线上医保移动结算支付的标准规范接入，提供基于线上医保支付的统计分析与其他辅助功能。

统一支付平台主要提供区域内居民医疗支付的能力支撑。居民可通过区域支付应用领取/绑定电子健康卡，获取待缴的预约挂号费用单、挂号费用单或门诊处方单信息后，通过区域支付应用调用统一支付平台来完成支付，同时区域统一支付平台集成多种支付方式供第三方应用调用，用户可按需选择。满足居民跨医疗机构就诊的结算需求，实现区域内居民就医统一支付，提高区域医疗支付体验。

电子健康卡线上使用，可通过区域健康应用（APP、微信、支付宝等），领取和绑定电子健康卡，同时，还可直接在区域健康应用上选择医院并进行预约挂号、处方缴费等业务，并完成线上支付。见图6-18。

采用统一的可扩展标记语言（Extensible Markup Language，XML）以数据格式或者标准的Form表单格式进行数据的传递。

XML使用一系列简单的标记描述数据，而这些标记可以用方便的方式建立。XML文档定义方式有：文档类型定义（Document Type Definition，DTD）和XML Schema。XML使用DTD文档类型定义来组织数据；格式统一，跨平台和语言，早已成为业界公认的标准。XML是标准通用标记语言（SGML）的子集，非常适合WEB传输。XML提供统一的方法来描述和交换独立于应用程序或供应商的结构化数据。

Form表单即表单标签，包含了处理表单数据所用CGI（Common Gateway Interface）程序的URL（Uniform Resource Locator）以及数据提交到服务器的方法。

统一采用HTTP或HTTPS协议和Web Service接口。

HTTP是超文本传输协议的缩写，它用于传送WWW（World Wide Web，万维网）方式的数据，关于HTTP协议的详细内容请参考RFC2616。HTTP协议采用了请求/响应模型。Web Service即Web服务，它是一种跨编程语言和跨操作系统平台的远程调用技术。

见表6-4。

见图6-19。

每一个应用厂商独立的加密密钥，每一个业务接口在数据传输的过程中均进行数据签名加密处理。

采用消息摘要算法第五版（Message Digest Algorithm MD5）加密，为计算机安全领域广泛使用的一种散列函数，用以提供消息的完整性保护。该算法的文件号为RFC 1321（R.Rivest，MIT Laboratory for Computer Science and RSA Data Security Inc. April 1992）。

MD5以512位分组来处理输入的信息，且每一分组又被划分为16个32位子分组，经过了一系列的处理后，算法的输出由四个32位分组组成，将这四个32位分组级联后将生成一个128位散列值。

支付流程中数据安全验证：

（1）请求方在请求时，将请求信息中的敏感数据（比如交易金额，交易账号等）使用对称密钥加密，然后使用自身的私钥对整个请求信息进行签名运算，将得到的签名附在请求信息的最后一起发送给接收方；

（2）接收方接收到请求信息后首先进行请求方接入权限验证，验证请求方的合法性；

（3）合法性验证完成后，在进行签名验证，使用请求方的公钥对请求信息最后的签名进行验证，只有签名验证通过，才能进入下个步骤；

（4）在签名验证完成后，使用对称密钥对请求信息中的敏感数据进行解密，在进行随后的业务处理；

（5）在支付流程中，统一支付平台还需要实现防重放攻击的功能，保证之前已经处理过的请求不能被重复处理，防止重复扣费。

在数据库保存数据时，对敏感数据进行加密处理后，再保存到数据库中。针对某些个人隐私数据（比如账户密码，个人身份信息等）使用非可逆算法进行加密后，再保存到数据库中，保证及时数据库被攻击或泄露时，个人隐私数据不会被盗取；为确保系统的整体安全性，统一支付平台需参照金融标准通过第三方专业检测机构的权威检测认证。

统一支付平台需要对接各金融交易系统、区域的医保系统，也需要与各个商业健康保险公司进行互联互通，同时，需要通过医疗卫生专网向各级医疗卫生机构提供接入访问，需要通过互联网向线上应用提供调用，因此，需对部署提出更高的要求以确保网络安全。

1．通过VLAN划分和网络配置，将统一支付平台部署在高安全级别的DMZ区，以确保网络互通情况下的高网络安全性；

2．直接面向互联网访问的区域，与DMZ区间部署类似于网闸的高网络安全设备；

3．与各支付通道网络，采用专网或虚拟VPN确保安全连接，且与交易系统前置间需部署防火墙或安全网关；

4．在客户端与服务器之间建立安全的信息传输通道，通过公开网络进行数据传输时，应进行双向认证；

5．使用高版本的SSL/TLS协议。