一种对账系统及相应计算机设备

技术领域

本申请涉及数据处理系统领域，尤其涉及一种对账系统及相应计算机设备。

背景技术

随着我国医疗保险(以下简称医保)体系日益健全、参保覆盖范围扩大、支付比例提高，医院应收医疗款中由医保给付金额比例增大，医疗保险统筹金项目增加并细化。由于医保回款实行总额预付和实时结算两种处理方式，给医院实际工作中医保回款的账务处理和对账增加了难度。为保证医院流动资金的及时回收，需要医院应收医疗款账目完整清楚，规范日常账务处理及医保回款对账。

现有对账系统采用传统的B/S架构，单服务器数据库性能低，并且在后续系统持续升级时需要花费一定时间重启服务，影响了客户的使用与后台进程的运行。此外，现有对账系统的数据采集多采用接口调用模式，如果发生了业务的变更，原接口无法使用，需要投入大量研发资源进行整改。具体地，现有对账系统存在下述不足：

1)智能对账系统与HRP(Hospital Resource Planning，医院资源规划)系统或者HIS(Hospital Information System，医院信息系统)系统的数据库服务都部署在一个服务器上，出现数据库性能瓶颈；

2)对账原始数据量大，加入数据分析相关功能后出现性能瓶颈，影响了其他功能应用；

3)HIS收费数据、第三方支付平台数据、医保数据、对账数据，这些来源的数据管理随着使用的加深趋向混乱；

4)收费与支付数据有时候通过中间数据库互通，有时候通过接口调用传输相关的数据，从而导致对账系统与HIS系统、第三方支付系统接口调用关系杂乱；

5)对账系统给其他系统(如：财务、银医、现金等)提供接口，渐渐地越改越大，包含了很多本来不属于它的逻辑，应用边界模糊，功能归属混乱；

6)系统后期二开、部署、运维难度很大，即便仅仅一个小需求的整改，也需要整个对账系统一起发布。为了减少发布可能产生的问题影响和系统后台业务停顿的影响，需要在凌晨特定时间点进行系统更新发布。

发明内容

为了克服现有技术中存在的不足，本发明提供一种对账系统及相应计算机设备，其使能解决系统运行的瓶颈问题，提高资源的利用率和对账速度，且部署、测试、发布和维护更简单。

在第一方面，本发明提供一种对账系统，包括：

调度微服务，用于管理对账系统的定时任务的调度；

HIS微服务，用于响应于调度微服务的调用，从医院信息系统HIS下载HIS账单；

医保微服务，用于响应于调度微服务的调用，对审核的医保账单进行解析，及根据预设的相应对账数据匹配规则对医保账单和HIS账单进行实时对账；响应于对账成功，将相应数据形成财务的应收账款；响应于对账失败，将相应数据形成差异数据。

在实施例中，对账系统还包括第三方微服务，用于响应于调度微服务的调用，从第三方系统下载第三方账单，及根据预设的相应对账数据匹配规则对第三方账单和HIS账单进行实时对账；响应于对账成功，将相应数据形成财务的应收账款；响应于对账失败，将相应数据形成差异数据。

在实施例中，对账系统还包括日切微服务，用于响应于HIS微服务或第三方微服务的调用，对HIS账单或第三方账单的数据进行清洗和归集。

在实施例中，对账系统还包括服务注册模块，用于将所述对账系统的各个微服务注册到服务器容器中并形成微服务注册池，通过容器管理每个微服务的生命周期。

在实施例中，对账系统还包括服务发现模块，用于响应于客户端发送请求，从本地缓存找寻调取的微服务；响应于从本地获取不到，刷新微服务注册池并同步到本地缓存。

在实施例中，对账系统还包括异常处理模块，用于响应于微服务处理异常，将异常微服务的当前处理任务加入消息队列；定时触发消息队列中的处理任务的执行；响应于消息队列中的处理任务执行失败，对失败次数计数；响应于失败次数大于阈值，通知有关人员并取消消息队列中的相应处理任务。

在实施例中，微服务之间的调用采用远程过程调用RPC调用方式。

另一方面，本发明提供一种计算机设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其中所述处理器执行所述计算机程序时实现根据第一方面的对账系统的功能。

按照本发明，使用微服务架构重构对账系统，按系统的功能特性进行业务划分，每个业务领域抽取实体模型，并聚合成一个一个微服务，每个微服务可独立部署、测试、升级、发布，每个微服务的性能扩展都是按需定制的，最大化合理资源的利用率，避免了混乱；同时为了解决数据库的性能瓶颈，根据微服务的特性进行分库分表，保证所有数据库层相互隔离，由每个微服务自己维护负责，缓解了数据库的压力，使之不再成为系统运行的瓶颈。

结合附图阅读本发明实施方式的详细描述后，本发明的其它特点和优点将变得更加清楚。

附图说明

图1为根据本发明系统的一实施例的框图；

图2为应用本发明的对账系统时的总体架构示意图；

图3为微服务的调用架构示意图；

图4为RPC框架架构图；

图5为异常处理模块工作原理示意图；及

图6为对账数据流转示意图。

为清晰起见，这些附图均为示意性及简化的图，它们只给出了对于理解本发明所必要的细节，而省略其他细节。

具体实施方式

下面参照附图对本发明的实施方式和实施例进行详细说明。

通过下面给出的详细描述，本发明的适用范围将显而易见。然而，应当理解，在详细描述和具体例子表明本发明优选实施例的同时，它们仅为说明目的给出。

图1示出了根据本发明的对账系统的一优选实施例的框图。本发明对对账系统进行微服务改造，首先进行业务抽象，然后根据智能对账的业务逻辑，抽取出公用的业务能力，做成一个一个的公共微服务，大大减少了相同的业务逻辑的代码重复，精简了控制层和表示层的代码，使之更加轻薄、更好维护。在图1所示的实施例中，本发明对账系统100包括：

调度微服务102，用于管理对账系统的定时任务的调度，包括定时任务的执行、变更、日志记录等；

HIS微服务104，用于响应于调度微服务的调用，从HIS系统下载HIS账单。下载后可对HIS账单按收入类型和/或医院实际情况进行初步的账单分解，例如分解成普通门诊账单、住院账单、特需门诊账单等。

医保微服务106，用于响应于调度微服务的调用，对审核的医保账单即收费业务已经结束的账单进行解析，及根据预设的相应对账数据匹配规则对医保账单和HIS账单进行实时对账；如果对账成功，将相应数据形成财务的应收账款；如果对账失败，将相应数据形成差异数据；

日切微服务108，用于响应于HIS微服务的调用，对HIS账单进行原始数据的清洗和数据归集，过滤掉HIS数据中无流水号单据，并按照收入类型转换到相应的处理部门头上，然后存入数据仓库中备用。

在实施例中，对账系统还可包括第三方微服务。在本说明书中，第三方指医院(HIS)和医保之外的第三方。第三方微服务用于响应于调度微服务的调用，从第三方系统下载第三方账单，及根据预设的相应对账数据匹配规则对第三方账单和HIS账单进行实时对账；如果对账成功，将相应数据形成财务的应收账款；如果对账失败，将相应数据形成差异数据。日切微服务108也可响应于第三方微服务的调用，对第三方账单进行原始数据的清洗和数据归集，然后存入数据仓库中备用。根据第三方的不同，第三方微服务可包括一个或多个微服务，例如京医通微服务、聚合支付微服务、POS微服务等。京医通微服务用于京医通账单的下载和对账，聚合支付微服务用于聚合支付平台如恒生芸泰的账单的下载和对账，POS微服务用于银联POS账单的下载和对账。

在实施例中，每一微服务各自具有并维护各自的数据库，实现分库和/或分表，缓解数据库压力。

图2为应用本发明的对账系统时的总体架构示意图，其中应用层是智能对账系统的业务后台管理程序，可向医院财务人员提供上传账单、查看对账结果、查看对账看板等功能，其可基于Chrome/FireFox等浏览器的PC工作。业务层包括微服务中心、调度中心、系统中心和对接中心。

微服务中心包括服务注册模块、服务发现模块、服务路由模块和调用链监控模块。

服务注册模块用于将对账系统的各个微服务注册到服务器容器中并形成微服务注册池，通过容器管理每个微服务的生命周期，可进行微服务注册、同步状态、微服务续约、微服务下线等管理，从而实现系统微服务的可扩展性、提高微服务的稳定性和高可用性。其余的业务微服务如HIS微服务、医保微服务等都是通过该模块注册成微服务发布给其他模块调用。

服务发现模块用于在客户端发送请求时，首先从本地缓存找寻调取的微服务；如果从本地获取不到，刷新微服务注册池并同步到本地缓存，然后再从本地缓存找寻调取的微服务，从而提高运行速度。

服务路由模块用于获取到目标微服务器信息，通过路由发起微服务调用，其中还可加入网关，用于每次调用时进行权限校验。图3示出了微服务的调用架构示意图。

调用链监控模块用于记录请求经过的每个节点，在调用发生异常时，可通过日志排查是哪些微服务出现了问题。

调度中心由调度微服务实现，用于管理对账系统的定时任务如账单下载任务、账单对账任务、日切任务等的调度。根据不同数据的特点可以配置不同的获取策略，以便达到准实时效果。

系统中心用于对用户进行管理，例如权限管理、安全管理、日志管理等，这些管理均可改造和注册成微服务。

对接中心包括上面描述的HIS微服务、医保微服务、第三方微服务(如京医通微服务、聚合支付微服务、POS微服务)等。

基础设施层可基于灵活的基础层部署方式，可以部署到k8s集群，也可部署到单个医院微服务器，并可支持物理机、虚拟机。

由于标准的微服务调用采用RESTful接口调用，内存开销较大。在实施例中，微服务之间的接口调用采用RPC(远程过程调用)调用，微服务可以像调用本地的对象一样调用其它微服务，大大减小内存开销。图4示出了RPC框架架构图。将微服务调用分为客户端和微服务端，A调用B微服务，A是客户端，B是微服务端。注册中心用于管理RPC调用的微服务地址等相关信息，例如可采用Zookeeper开源框架进行微服务地址信息的CURD(创建、更新、读取、删除)操作。调用者发起的请求统一先经过调用模块，再由调用模块进行分发处理，调用前的公共处理业务都在调用模块处理，例如获取服务注册信息、包装客户端的session类。

处理模块封装处理请求的公共业务逻辑，负责调用对应服务器的对应服务。

其中，为了保证客户端请求不会因为微服务器宕机而无法响应，可在发布微服务时增加负载均衡参数，保证发起的请求始终会有一个服务器响应。

对于RPC协议，对调用方A请求的参数以及微服务方B返回的结果对象做序列化和反序列化，序列化结束后交给网络模块进行网络传输。在实施例中，本发明可支持多种序列化协议：JDK、protostuff、fastjosn等。为此，对通信数据包结构重构，增加序列化协议标识，反序列化时根据数据包的序列化协议标识进行反序列化。还可对客户端、微服务端连接增加心跳机制，以节省连接资源。例如，当客户端与微服务端建立连接后，循环执行一个定时任务，如果客户端没有业务请求，则随机等待几秒发送心跳信号，微服务端接收后返回收到，客户端空闲计数器+1，如果空闲计数器大于阈值则表明任务空闲太多，微服务器关闭连接而节省连接资源。

代理：使用动态代理将复杂的远程方法调用细节进行封装，使得程序员在RPC框架时就如使用本地方法一样的方式，本次实现采用JDK的动态代理机制。

为提高微服务整体的可用性和健壮性，本发明对账系统还可包括异常处理模块。异常处理模块的工作如图5所示，在此以HIS微服务异常为例。在HIS微服务自动拉取账单失败时即该微服务处理异常，将HIS微服务的当前处理任务加入消息队列MQ，然后定时触发消息队列中的处理任务的执行，如果消息队列中的处理任务例如拉取账单仍然执行失败，对失败次数计数，在失败次数大于阈值如8次时，短信通知有关人员并取消消息队列中的相应处理任务，改由有关人员手动触发拉取账单。通过MQ消息队列重启失败的微服务，从而重新执行该微服务，提高了可用性和鲁棒性。

图6示出了本发明的对账系统中，HIS账单与医保账单对账、HIS账单与第三方(金融渠道)账单对账时的数据流转示意图。原则上，HIS系统会将每一笔订单都推送到相应的结算支付管理系统如医保结算支付管理系统、第三方结算支付管理系统。对账数据匹配规则可预先设置，也可界面化动态配置，对于HIS系统数据与医保系统数据及HIS系统数据与金融渠道数据，可根据实际情况配置不同的数据匹配规则。在对账时，原则上应以渠道数据为准。

根据对账规则中的设置，经调度微服务定时启动相应的对账模块如医保、异地医保、金融机构等。在此以HIS账单与医保账单的对账为例，将HIS系统推送过来的订单数据和医保对账明细中的支付流水信息进行比对，即按照配置的对账数据匹配规则对医保系统数据与HIS系统数据进行匹配，若出现一方有某一账单而另一方没有，将数据放到对账差异表中；若出现金额/状态不相符的订单，将数据放到对账差异表中。出现在对账差异表中的数据等待人工进行差异核实并处理。如果完全匹配，则将相应数据形成财务的应收账款。财务人员可基于实收账款与应收账款对账。根据结算规则，还可判断医保、金融机构等是否需要出结算单，若已经达到结算周期则汇总交易数据形成结算单流水，并更新订单的结算状态。

在另一实施例中，本发明提供一种计算机设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其中所述处理器执行所述计算机程序时实现结合图1-6所示和所述的对账系统的功能，在此不再赘述。

在此所述的多个不同实施方式或者其特定特征、结构或特性可在本发明的一个或多个实施方式中适当组合。另外，在某些情形下，只要适当，流程图中和/或流水处理描述的步骤顺序可修改，并不必须精确按照所描述的顺序执行。另外，本发明的多个不同方面可使用软件、硬件、固件或者其组合和/或执行所述功能的其它计算机实施的模块或装置进行实施。本发明的软件实施可包括保存在计算机可读介质中并由一个或多个处理器执行的可执行代码。计算机可读介质可包括计算机硬盘驱动器、ROM、RAM、闪存、便携计算机存储介质如CD-ROM、DVD-ROM、闪盘驱动器和/或具有通用串行总线(USB)接口的其它装置，和/或任何其它适当的有形或非短暂计算机可读介质或可执行代码可保存于其上并由处理器执行的计算机存储器。本发明可结合任何适当的操作系统使用。

除非明确指出，在此所用的单数形式“一”、“该”均包括复数含义(即具有“至少一”的意思)。应当进一步理解，说明书中使用的术语“具有”、“包括”和/或“包含”表明存在所述的特征、步骤、操作、元件和/或部件，但不排除存在或增加一个或多个其他特征、步骤、操作、元件、部件和/或其组合。如在此所用的术语“和/或”包括一个或多个列举的相关项目的任何及所有组合。

前面说明了本发明的一些优选实施例，但是应当强调的是，本发明不局限于这些实施例，而是可以本发明主题范围内的其它方式实现。本领域技术人员可以在本发明技术构思的启发和不脱离本发明内容的基础上对本发明做出各种变型和修改，这些变型或修改仍落入本发明的保护范围之内。