CN115274085A - 网络诊疗费用结算方法、装置、平台、设备及介质 - Google Patents

Abstract

本申请公开了一种涉及网络诊疗费用结算方法、装置、平台、设备及介质，其方法包括：响应于结算指令，从所述MQ集群拉取与所述结算指令对应的目标医生的待结算数据，其中所述待结算数据是由各所述业务系统发送到MQ集群的；读取预设的所述目标医生的的结算配置参数，所述结算配置参数包括：结算方式、收入类型、收入发放方式；根据所述结算方式、所述收入类型息以及所述待结算数据，生成所述目标医生的收入发放信息；根据所述收入发送信息，按照配置的收入发放方式对所述目标医生的收入进行发放。本申请通过使用消息队列方式，实现系统之间的解耦，易于扩展，能够调动线上问诊医生的积极性，有利于互联网医疗的良性发展。

Description

网络诊疗费用结算方法、装置、平台、设备及介质

技术领域

本申请涉及线上医疗技术领域，具体一种涉及网络诊疗费用结算方法、装置、平台、设备及介质。

背景技术

收入是一种劳动和获得的报酬，这种劳动包括但不限于体力劳动，脑力劳动，服务咨询等。收入的发放规则繁多，无论是医疗行业，或者其他的行业，都存在佣金收入的结算及发放。

而互联网医疗，代表了医疗行业新的发展方向，有利于解决中国医疗资源不平衡和人们日益增加的健康医疗需求之间的矛盾，得到卫生部积极引导和支持。医生线上问诊后应取得相应的回报收入，但可能存在医生看不到具体每笔收入明细，收入发放审核流程过长导致医生收入发放不及时；过于繁琐流程及某些模糊的收入导致线上问诊医生的积极性不高，这种情况不利于互联网医疗的良性发展，因此亟需一种方式来弥补这一不足，提高医生线上医疗的粘度及积极性。

在现有技术中，网络诊疗费用结算方法通常是通过dubbo接口直接调用的形式，实现业务系统与结算系统之间的直接连接，在此过程中，如若出现网络抖动、被调用方系统在发布应用等情况，会出现调用失败，导致数据丢失。

需要说明的是，上述说明仅作为背景示例，而不必然的成为现有技术。

发明内容

针对上述问题，本申请实施例提供了一种网络诊疗费用结算方法、装置、平台、设备及介质，通过消息队列的方式来实现业务数据的获取，对数据的生产方及消费方进行解耦，保证数据的安全性、完整性。

第一方面，本申请实施例提供了一种网络诊疗费用结算方法，所述方法通过网络诊疗费用结算平台实现，所述结算平台包括若干个业务系统、MQ集群、结算系统，各所述业务系统和所述结算系统分别通信连接所述MQ集群；

所述方法用于所述结算系统，所述方法包括：

响应于结算指令，从所述MQ集群拉取与所述结算指令对应的目标医生的待结算数据，其中所述待结算数据是由各所述业务系统发送到MQ集群的；

读取预设的所述目标医生的的结算配置参数，所述结算配置参数包括：结算方式、收入类型、收入发放方式；

根据所述结算方式、所述收入类型息以及所述待结算数据，生成所述目标医生的收入发放信息；

根据所述收入发送信息，按照配置的收入发放方式对所述目标医生的收入进行发放。

第二方面，本申请实施例还提供了一种网络诊疗费用结算装置，所述装置用于结算系统，所述装置包括：

拉取单元，用于响应于结算指令，从所述MQ集群拉取与所述结算指令对应的目标医生的待结算数据，其中所述待结算数据是由各所述业务系统发送到MQ集群的；

读取单元，用于读取预设的所述目标医生的的结算配置参数，所述结算配置参数包括：结算方式、收入类型、收入发放方式；

生成单元，用于根据所述结算方式、所述收入类型息以及所述待结算数据，生成所述目标医生的收入发放信息；

发放单元，用于根据所述收入发送信息，按照配置的收入发放方式对所述目标医生的收入进行发放。

第三方面，本申请实施例还提供了一种网络诊疗费用结算平台，所述结算平台包括多个业务系统、MQ集群、结算系统，各所述业务系统和所述结算系统分别通信连接所述MQ集群，其中，所述结算系统部署有上述的网络诊疗费用结算装置；

所述业务系统用于响应于所述目标医生的医生终端发送的多个结诊操作，获取多个问诊订单信息，将所述多个问诊订单信息进行汇总，生成所述待结算数据，并根据所述待结算数据发送至所述MQ集群；

所述MQ集群用于接收并存储各所述业务系统发送的医生的待结算数据，并响应于各所述业务系统的拉取指令，将所述待结算数据发送至所述结算系统。

第四方面，本申请实施例还提供了一种电子设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行上述任一的方法。

第五方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行上述任一的方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本申请基于MQ集群设计了一种网络诊疗费用结算平台，各业务系统作为MQ集群的消息生产者，结算系统作为MQ集群的消息消费者；且在结算系统中允许工作人员对网络诊疗费用的各种结算配置参数进行配置，医患基于业务系统进行诊疗，业务系统根据医患之间的诊疗行为生成待结算数据，当对医生的诊疗费用进行结算的时候，从MQ集群中拉取由业务系统发送到MQ集群的待结算数据，并根据所述结算方式、所述收入类型息以及所述待结算数据，生成所述目标医生的收入发放信息，根据所述收入发送信息，按照配置的收入发放方式对医生收入的一键发放。本申请通过使用消息队列方式，实现系统之间的解耦，易于扩展，同时解决传统dubbo接口调用出现的数据丢下情况，保证了数据的安全性以及可靠性；且实现了对医生线上诊疗费用的一键发放，费用发放及时，能够调动线上问诊医生的积极性，有利于互联网医疗的良性发展。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了现有技术中的一种网络诊疗费用结算平台的结构示意图；

图2示出了根据本申请的一个实施例的网络诊疗费用结算方法的流程示意图；

图3示出了根据本申请的一个实施例的网络诊疗费用结算平台的结构示意图；

图4示出了根据本申请的另一个实施例的网络诊疗费用结算方法的流程示意图；

图5示出了根据本申请的一个实施例的网络诊疗费用结算装置的结构示意图；

图6为本申请实施例中一种电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1示出了现有技术中的一种网络诊疗费用结算平台的结构示意图，从图1可以看出，图1示出的网络诊疗费用结算平台100包括多个业务系统110和结算系统120，各业务系统110与结算系统120通信连接，可通过dubbo接口调用形式进行数据交换，系统之间接口强依赖，存在数据丢失情况，例如被调用系统发布，网络抖动等，导致数据安全性以及完整性差，导致医生诊疗费用发放不及时。

图2示出了根据本申请的一个实施例的网络诊疗费用结算方法的流程示意图，从图2可以看出，本申请至少包括步骤S110～步骤S140：

步骤S210：响应于结算指令，从所述MQ集群拉取与所述结算指令对应的目标医生的待结算数据，其中所述待结算数据是由各所述业务系统发送到MQ集群的。

本申请的方法可通过本申请提供的网络诊疗费用结算平台实现，图3示出了根据本申请的一个实施例的网络诊疗费用结算平台的结构示意图，从图3可以看出，网络诊疗费用结算平台300包括若干个业务系统310、MQ集群320、和结算系统330，各业务系统310和结算系统330分别通信连接MQ集群320；各业务系统310和结算系统330与MQ集群320之间通过消息队列(Message Queue，MQ消息)的方式进行数据交互。

消息队列(MQ)是分布式系统中重要的组件，其通用的使用场景可以简单地描述为：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。消息队列主要解决了应用耦合、异步处理、流量削锋等问题。当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等集群，在本申请中所述的MQ集群可以为上述集群中的任意一种，优选为RocketMQ集群。

在网络诊疗费用结算平台300中，业务系统310作为MQ集群320的消息生产者，结算系统330作为MQ集群320的消息消费者。

从图3可以看出，网络诊疗费用结算平台300还包括多个患者终端和医生终端，业务系统310可以理解为面向用户的诊疗系统后台，患者可以通过手机、平板电脑等终端，连接至业务系统进行问诊，在本申请中患者的终端记为患者终端；医生可以可以通过手机、平板电脑等终端，连接至业务系统进行为患者提供诊疗服务，在本申请中医生的终端记为医生终端，该过程会产生医生的诊疗费用，以及对应的诊疗订单信息，存储于对应的业务系统中。

本申请的方法可通过网络诊疗费用结算平台300实现，应用于结算系统330。医生在为患者提供诊疗服务后，医生可执行结诊操作，对应的业务系统在接收到医生的结诊操纵后，确认该次诊疗完成，可以将该过程会产生医生的诊疗费用，以及对应的诊疗订单信息，存储于对应的业务系统中。业务系统可以将这些待结算数据存储于业务系统本地，同时以MQ消息的形式发送至MQ集群320。给医生发放网络诊疗费用通常是按一定周期发放，如按月或者按季度发放，因此，业务系统在获得医生的每次结诊操作后，通常需要按照一定维度对数据进行汇总，如按照姓名、结算周期、平台名称等，将汇总后的数据记为待结算数据。汇总后，待结算数据可以以结算明细的形式展现，包括医生每一次出诊的明细，包括但不限于出诊时间、出诊的级别、产生的费用总计和费用明细等等。

业务系统将待结算数据以MQ消息的形式发送到MQ集群中，该过程可以是实时的，也可以是周期性的。所谓“实时的”可以理解为如果一个医生完成一次结诊，该医生对应的待结算数据就会更新，一旦在业务系统发生更新，在更新后，业务系统就将该医生的待结算数据发送至MQ集群，使其在MQ集群也同步更新。所谓“周期性”可以理解为按照一定时间间隔将其间产生的待结算数据发送至至MQ集群，使其在MQ集群也更新，如每24小时发送一次。

结算系统330在接收到结算指令后，确定与结算指令对应的目标周期以及结算周期，并从所述MQ集群拉取目标医生的待结算数据。

步骤S220：读取预设的所述目标医生的结算配置参数，所述结算配置参数包括：结算方式、收入类型、收入发放方式。

结算系统330允许配置医生的网络诊疗费用的结算配置参数，由于每个医生的职称不同、科室不同、资历不同，导致不同的医生出诊一次的费用也是不同的，在结算系统330上，可以对医生的网络诊疗费用的结算参数进行配置，结算配置参数至少包括但不限于结算方式、收入类型、收入发放方式等一些必要参数，其中，结算方式可以表示结算周期，如月结、季度结；收入类型可以表示费用产生原因，如挂号费用、奖金等；收入发放方式表示按照何种途径发放费用。

这些结算配置参数可以形成医生的结算规则，不同的医生的结算规则可以相同也可以不同，不申请不作限定；相同医生可能在多个业务系统出诊，其在各个业务系统的结算规则也可能是不同的，本申请亦不作限定。

结算配置参数可存储于结算系统330本地，在对医生的网络诊疗费用结算时，可以从结算系统330本地读取，并解析出目标医生的结算配置参数。

步骤S230：根据所述结算方式、所述收入类型以及所述待结算数据，生成所述目标医生的收入发放信息。

对目标医生在目标收起的收入进行计算，并形成收入发放信息。具体的，可根据结算方式以及收入类型，在待结算数据中找到对应的信息，进行计算。其中，收入发放信息可以包括但不限于目标医生的姓名、结算周期、应发放总金额等；

步骤S240：根据所述收入发送信息，按照配置的收入发放方式对所述目标医生的收入进行发放。

按照结算配置参数中指定的目标医生的收入发放方式，对医生的收入进行发放，如发放到目标医生在对应业务系统指定的账户中，后续医生可将其提到自己的银行卡中。

从图2所述的方法可以看出，本申请基于MQ集群设计了一种网络诊疗费用结算平台，各业务系统作为MQ集群的消息生产者，结算系统作为MQ集群的消息消费者；且在结算系统中允许工作人员对网络诊疗费用的各种结算配置参数进行配置，医患基于业务系统进行诊疗，业务系统根据医患之间的诊疗行为生成待结算数据，当对医生的诊疗费用进行结算的时候，从MQ集群中拉取由业务系统发送到MQ集群的待结算数据，并根据所述结算方式、所述收入类型息以及所述待结算数据，生成所述目标医生的收入发放信息，根据所述收入发送信息，按照配置的收入发放方式对医生收入的一键发放。本申请通过使用消息队列方式，实现系统之间的解耦，易于扩展，同时解决传统dubbo接口调用出现的数据丢下情况，保证了数据的安全性以及可靠性；且实现了对医生线上诊疗费用的一键发放，费用发放及时，能够调动线上问诊医生的积极性，有利于互联网医疗的良性发展。

请再参考图3示出的网络诊疗费用结算平台300，以其中一个业务系统为例，其可以连接多个患者终端和多个医生终端，业务系统可提供前端程序，如APP、小程序等，展示在患者终端和医生终端，患者终端和医生终端通过登录到前端程序实现问诊和诊疗。

患者通过登录前端程序，在线上对医生提供的诊疗服务进行差异性购买，并进行问诊。在医生终端，医生在登录前端程序后可以查看待接诊的患者，并进行问诊解答，在一次问诊结束后，医生需要进行结诊操作，即结诊操作是根据所述患者终端发送至所述业务系统的问诊请求进行问诊后形成的。

业务系统在接收到一次结诊操作，响应于该结诊操作，业务系统获取多个问诊订单信息，问诊订单信息包括不限于患者账号、医生账号、订单号、问诊时间以及费用明细等等。业务系统将所述多个问诊订单信息按照进行汇总，即可生成所述待结算数据，在一些实施例中，为了使得待结算数据更加清晰，业务系统可将其进行预处理，如按照结算方式进行汇总，或者按照收入类型进行分类和汇总等，对此本申请不作限制。

请再参考图3，从图3可以看出，各医生终端还通信连接结算系统330，其中，结算配置参数还包括：收入明细展示参数；所述方法还包括：根据所述目标医生的待结算数据、收入发放信息以及所述收入明细展示参数，生成所述目标医生在目标周期的收入明细，并推送至所述目标医生的医生终端。

现有技术中，通常结算时只生成费用总额，存在医生看不到具体每笔收入明细的情况，为此，结算系统330可以生成目标医生在历史周期或当前周期的收入明细，并推送到目标医生的医生终端，使得医生可以看到在一定的时间范围内相关的收入明细，或者可以看到每月每笔的收入明细。

结算系统300允许对收入明细展示参数进行配置，收入明细展示参数可以包括但不限于可展示多久历史时间内的收入明细、明细项目等等，根据收入明细展示参数进行计算，即可得到目标医生在目标周期的收入明细，并推送至所述目标医生的医生终端，医生即可在医生终端查看。

在本申请的一些实施例中，在上述方法中，所述结算配置参数还包括：收入汇总参数；所述方法还包括：根据所述目标医生的待结算数据以及所述收入汇总参数，生成所述目标医生在目标周期的预估收入金额、冻结金额以及可提现金额，并推送至所述目标医生对应的医生终端。

在医生的账号中，可能存在某些费用不能结算，需要暂时冻结的情况，为此，可设置收入汇总参数，对收入计算方式进行指定。如通过收入汇总参数可以指定未进行结诊操作的问诊订单不能结算，也可以指定奖金多久发放一次等，根据这些参数，可以确定一个目标医生在一个目标周期中，预估收入金额、冻结金额以及可提现金额，可提现金额为预估收入金额的冻结金额差。

在本申请的一些实施例中，在上述方法中，所述结算配置参数还包括：收入冲正参数；所述方法还包括：根据所述目标医生的待结算数据，以及所述收入冲正参数，对所述目标医生的收入进行冲正，并根据冲正结果更新所述目标医生的收入发放信息。

冲正是为系统认为可能交易失败时采取的补救手法。即一笔交易在终端已经置为成功标志，但是发送到主机的账务交易包没有得到响应，即终端交易超时，所以不确定该笔交易是否在主机端也成功完成，为了确保用户的利益，终端重新向主机发送请求，请求取消该笔交易的流水，如果主机端已经交易成功，则回滚交易，否则不处理，然后将处理结果返回给终端。

简单理解，冲正就是为了挽救交易出现错误的一种措施，结算系统300允许对收入冲正参数进行配置，通过收入冲正参数可以指定在何种情况下进行冲正，如何冲正。如果医生的交易信息与收入发生差异，可以及时通过结算系统330进行冲正，在冲正之后，需要将原来的收入发放信息进行更新，以保证医生收入的准确性。

图4示出了根据本申请的另一个实施例的网络诊疗费用结算方法的流程示意图，从图4可以看出，本实施例包括：

患者可以通过患者终端可在业务系统购买医生服务，并进行问诊服务咨询。医生可以通过医生终端查看待结诊患者，进行诊疗，诊疗结束后进行结诊操作。

业务系统根据医生的结诊操作，生成待结算数据并发送至MQ集群。

结算系统到MQ集群拉取待结算数据，并进行结算操作，并将结算操作反馈到业务系统。同时，结算系统可生成收入明细、收入总金额、可提现余额等，并反馈得到医生终端。

图5示出了根据本申请的一个实施例的网络诊疗费用结算装置的结构示意图，所述装置500用于结算系统330(图3)，所述装置500包括：

拉取单元510，用于响应于结算指令，从所述MQ集群拉取与所述结算指令对应的目标医生的待结算数据，其中所述待结算数据是由各所述业务系统发送到MQ集群的；

读取单元520，用于读取预设的所述目标医生的的结算配置参数，所述结算配置参数包括：结算方式、收入类型、收入发放方式；

生成单元530，用于根据所述结算方式、所述收入类型息以及所述待结算数据，生成所述目标医生的收入发放信息；

发放单元540，用于根据所述收入发送信息，按照配置的收入发放方式对所述目标医生的收入进行发放。

在本申请的一些实施例中，在上述装置中，所述结算平台还包括若干个医生终端和若干患者终端，各所述医生终端以及各所述患者终端通信连接各所述业务系统，所述待结算数据是所述业务系统根据下述方法生成的：响应于所述目标医生的医生终端发送的多个结诊操作，获取多个问诊订单信息，所述结诊操作是根据所述患者终端发送至所述业务系统的问诊请求进行问诊后形成的；将所述多个问诊订单信息进行汇总，生成所述待结算数据。

在本申请的一些实施例中，在上述装置中，各所述医生终端还通信连接所述结算系统，所述结算配置参数还包括：收入明细展示参数；生成单元530，还用于根据所述目标医生的待结算数据、收入发放信息以及所述收入明细展示参数，生成所述目标医生在目标周期的收入明细，并推送至所述目标医生的医生终端。

在本申请的一些实施例中，在上述装置中，所述结算配置参数还包括：收入汇总参数；生成单元530，还用于根据所述目标医生的待结算数据以及所述收入汇总参数，生成所述目标医生在目标周期的预估收入金额、冻结金额以及可提现金额，并推送至所述目标医生对应的医生终端。

在本申请的一些实施例中，在上述装置中，所述结算配置参数还包括：收入冲正参数；生成单元530，还用于根据所述目标医生的待结算数据，以及所述收入冲正参数，对所述目标医生的收入进行冲正，并根据冲正结果更新所述目标医生的收入发放信息。

需要说明的是，上述的网络诊疗费用结算装置可一一实现前述的网络诊疗费用结算方法，这里不再赘述。

图6是本申请的一个实施例电子设备的结构示意图。请参考图6，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成网络诊疗费用结算装置。处理器，执行存储器所存放的程序，并具体用于执行上述方法。

上述如本申请图5所示实施例揭示的网络诊疗费用结算装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central ProcessingUnit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图5网络诊疗费用结算装置执行的方法，并实现网络诊疗费用结算装置在图5所示实施例的功能，本申请实施例在此不再赘述。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图5所示实施例中网络诊疗费用结算装置执行的方法，并具体用于执行前述方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种网络诊疗费用结算方法，其特征在于，所述方法通过网络诊疗费用结算平台实现，所述结算平台包括若干个业务系统、MQ集群、结算系统，各所述业务系统和所述结算系统分别通信连接所述MQ集群；

所述方法应用于所述结算系统，所述方法包括：

响应于结算指令，从所述MQ集群拉取与所述结算指令对应的目标医生的待结算数据，其中所述待结算数据是由各所述业务系统发送到MQ集群的；

读取预设的所述目标医生的的结算配置参数，所述结算配置参数包括：结算方式、收入类型、收入发放方式；

根据所述结算方式、所述收入类型息以及所述待结算数据，生成所述目标医生的收入发放信息；

根据所述收入发送信息，按照配置的收入发放方式对所述目标医生的收入进行发放。

2.根据权利要求1所述的方法，其特征在于，所述结算平台还包括若干个医生终端和若干患者终端，各所述医生终端以及各所述患者终端通信连接各所述业务系统，所述待结算数据是所述业务系统根据下述方法生成的：

响应于所述目标医生的医生终端发送的多个结诊操作，获取多个问诊订单信息，所述结诊操作是根据所述患者终端发送至所述业务系统的问诊请求进行问诊后形成的；

将所述多个问诊订单信息进行汇总，生成所述待结算数据。

3.根据权利要求2所述的方法，其特征在于，各所述医生终端还通信连接所述结算系统，所述结算配置参数还包括：收入明细展示参数；

所述方法还包括：

根据所述目标医生的待结算数据、收入发放信息以及所述收入明细展示参数，生成所述目标医生在目标周期的收入明细，并推送至所述目标医生的医生终端。

4.根据权利要求3所述的方法，其特征在于，所述结算配置参数还包括：收入汇总参数；

所述方法还包括：

根据所述目标医生的待结算数据以及所述收入汇总参数，生成所述目标医生在目标周期的预估收入金额、冻结金额以及可提现金额，并推送至所述目标医生对应的医生终端。

5.根据权利要求3所述的方法，其特征在于，所述结算配置参数还包括：收入冲正参数；

所述方法还包括：

根据所述目标医生的待结算数据，以及所述收入冲正参数，对所述目标医生的收入进行冲正，并根据冲正结果更新所述目标医生的收入发放信息。

6.一种网络诊疗费用结算装置，其特征在于，所述装置用于结算系统，所述装置包括：

拉取单元，用于响应于结算指令，从所述MQ集群拉取与所述结算指令对应的目标医生的待结算数据，其中所述待结算数据是由各所述业务系统发送到MQ集群的；

读取单元，用于读取预设的所述目标医生的的结算配置参数，所述结算配置参数包括：结算方式、收入类型、收入发放方式；

生成单元，用于根据所述结算方式、所述收入类型息以及所述待结算数据，生成所述目标医生的收入发放信息；

发放单元，用于根据所述收入发送信息，按照配置的收入发放方式对所述目标医生的收入进行发放。

7.一种网络诊疗费用结算平台，其特征在于，所述结算平台包括多个业务系统、MQ集群、结算系统，各所述业务系统和所述结算系统分别通信连接所述MQ集群，其中，所述结算系统部署有权利要求6所述的网络诊疗费用结算装置；

所述业务系统用于响应于所述目标医生的医生终端发送的多个结诊操作，获取多个问诊订单信息，将所述多个问诊订单信息进行汇总，生成所述待结算数据，并根据所述待结算数据发送至所述MQ集群；

所述MQ集群用于接收并存储各所述业务系统发送的医生的待结算数据，并响应于各所述业务系统的拉取指令，将所述待结算数据发送至所述结算系统。

8.根据权利要求7所述的结算平台，其特征在于，所述结算平台还包括若干个医生终端和若干患者终端，各所述医生终端以及各所述患者终端通信连接各所述业务系统：

所述患者终端，用于接受问诊请求，并发送至对应的业务系统；

所述医生终端，用于将目标医生根据所述问诊请求完成的多个结诊操作发送至所述业务系统。

9.一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行所述权利要求1～5所述方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行所述权利要求1～5所述方法。

Images