复合就医业务的联合下单方法、装置、系统、设备及介质与流程

1.本技术涉及计算机以及智慧医疗技术领域，具体涉及一种复合就医业务的联合下单方法、装置、系统、设备及介质。

背景技术：

2.随着生活水平的提高，人们对就医体验的追求也越来越高，人们不仅仅满足于传统的挂号就诊的模式，常常还伴有一些其他服务项目，如陪诊服务、住院陪护等等。
3.现有技术中，包括挂号、陪诊、陪护等业务，每条业务线都有单独的系统，相对独立，下单时需要各自下单；若在下单过程中，用户需要多种服务，需要在多个平台进行咨询下单，对于用户而言，下单繁琐、困难，且生成的多个订单整体协调性差，甚至多个订单的时间难以吻合在一起；另一方面，对商家而言，各业务线创单时，收集的用户信息重复率很高，影响客服创单效率，进而影响用户体验。

技术实现要素：

4.本技术实施例针对上述情况，本技术提出了一种复合就医业务的联合下单方法、装置、系统、设备及介质，该方法可通过获取目标患者复合就医业务的多个业务的下单信息，一次性的生成包含多个子订单的复合就医业务的联合订单，节约了下单流程，简化了用户下单的操作，提高了用户体验感受；且提高商家创单效率，克服或者至少部分克服了现有技术的缺陷。
5.第一方面，本技术实施例提供了一种复合就医业务的联合下单方法，包括：
6.获取复合就医业务的多个业务的下单信息，所述下单信息包括基本信息和业务履约信息；
7.根据所述基本信息和所述业务履约信息，生成所述复合就医业务的联合订单，所述联合订单包括一个母订单以及所述母订单下的任意数量的子订单，其中，一个所述子订单对应一项所述业务；
8.对所述母订单和/或子订单中已使用的权益进行核销。
9.第二方面，本技术实施例还提供了一种复合就医业务的联合下单装置，所述装置用于实现上述所述的方法。
10.第三方面，本技术实施例还提供了一种复合就医业务的联合下单系统，所述系统包括通信连接的前端展示单元和后台服务单元；其中，所述后台服务单元部署有上述的复合就医业务的联合下单装置；
11.所述前端展示单元，用于显示所述后台服务单元提供的前端界面，并响应于用户对所述前端界面的操作，将接收的下单信息发送至所述后台服务单元；以及将所述后台服务单元生成的复合就医业务的联合订单显示在前端界面。
12.第四方面，本技术实施例还提供了一种电子设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行上述任一的
方法。
13.第五方面，本技术实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行上述任一的方法。
14.本技术实施例采用的上述至少一个技术方案能够达到以下有益效果：
15.本技术提供了通过获取复合就医业务的多个业务的下单信息，其中在下单信息可包括基本信息和业务履约信息，基本信息可以包括就诊人的身份、年龄等信息，业务履约信息可以包含就诊人可享受的多项权益，如挂号、陪诊、其他协助服务等，然后根据获取到的下单信息，一次性生成所述复合就医业务的联合订单，在联合订单中，包含一个母订单和多个子订单，一个子订单对应着一项权益，母订单用于关联多个子订单，最后，对订单中已经享受的权益进行核销。本技术针对同一用户而言，统一了就诊人信息，各子订单复用一套就诊人信息，方便用户或者客服下单，简化了下单流程、提高下单效率；且在前端界面可根据母订单来展示，将多个业务统一在一个页面展示，方便用户查看，提高用户使用感受；另一方面，对于业务供应商而言，极大程度上降低了接收到的用户信息的重复率，从而显著提高了创单效率。
附图说明
16.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
17.图1示出根据本技术的一个实施例的复合就医业务的联合下单方法的流程示意图；
18.图2示出了根据本技术的一个实施例的复合就医业务的联合下单系统的结构示意图；
19.图3示出了根据本技术的一个实施例的前端界面的示意图；
20.图4示出了根据本技术的一个实施例的复合就医业务的联合下单装置的结构示意图；
21.图5为本技术实施例中一种电子设备的结构示意图。
具体实施方式
22.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
23.以下结合附图，详细说明本技术各实施例提供的技术方案。
24.人们在就医时除了挂号服务，还需要一些其他服务，如陪诊、上门接送、国内外住院协助等等。现有技术中，需要用户或者客服对各个服务分别下单，甚至需要在不同平台下单，如先进行挂号，创建挂号订单，然后在下单陪诊服务，创建陪诊订单，这种方式下单效率低下，多个业务之间对接困难，用户信息重复率很高，影响客服创单效率，进而影响用户体验。
25.对此，本技术提供了一种复合就医业务的联合下单方法，图1示出了根据本技术的一个实施例的复合就医业务的联合下单方法的流程示意图，从图1可以看出，本技术至少包括步骤s110～步骤s130：
26.步骤s110：获取复合就医业务的多个业务的下单信息，所述下单信息包括基本信息和业务履约信息。
27.首先获取目标患者的复合就医业务的多个业务的下单信息，通过整理各个业务线创单时需要的信息，将下单信息归为两大类：基本信息和业务履约信息，比如说、姓名，属于基本信息，挂号时间、陪诊时间信息属于业务履约强相关，属于业务履约所需信息。在本技术的一些实施例中，基本信息可以包括但不限于用户基本信息、权益信息、就诊人信息。
28.在本技术的一些实施例中，所述获取复合就医业务的多个业务的下单信息，包括：显示前端界面，通过所述前端界面接收所述下单信息，所述前端界面包括基本信息控件，和业务履约信息控件；其中，所述基本信息控件包括为用户基本信息子控件、权益信息子控件、就诊人信息子控件；所述业务履约信息控件包括多个权益信息子控件，各所述权益信息子控件是根据业务类型配置的。
29.也就是说，本技术的方法可形成一个复合就医业务的联合下单系统，该系统可从逻辑上实现本技术的方法，复合就医业务的联合下单系统可以部署在b端，也可以部署在c端，以下以部署在c端为例，图2示出了根据本技术的一个实施例的复合就医业务的联合下单系统的结构示意图，从图2可以看出，复合就医业务的联合下单系统200包括后台服务单元210和前端展示单元220，其中，后台服务单元210部署有复合就医业务的联合下单装置(图4)；复合就医业务的联合下单装置用于实现本技术的提供的方法；所述前端展示单元220，用于显示所述后台服务单元提供的前端界面，并响应于用户对所述前端界面的操作，将接收的下单信息发送至所述后台服务单元；以及将所述后台服务单元生成的复合就医业务的联合订单显示在前端界面。
30.需要说明的是，本技术提供的复合就医业务的联合下单系统200可以直接面向个人用户，也可以面向企业用户，企业用户可以配置客服人员，对企业员工进行服务，企业员工作为复合就医业务的联合下单系统200的用户。
31.用户可以在前端界面输入下单信息，复合就医业务的联合下单系统200通过所述前端界面接收所述下单信息，图3示出了根据本技术的一个实施例的前端界面的示意图，在前端界面包括任意数量的用户界面元素或者用户界面ui，这里称为“控件”。在本技术的一些实施例中，前端界面可包括基本信息控件，和业务履约信息控件；其中，所述基本信息控件包括为用户基本信息子控件、权益信息子控件、就诊人信息子控件；所述业务履约信息控件包括多个权益信息子控件，各所述权益信息子控件是根据业务类型配置的。
32.更加具体的，在本技术的一些实施例中，所述用户基本信息子控件的可选项或可填写项包括但不限于：用户id、personid、所属企业、所属机构、用户身份、以及员工等级等等。用户可以在用户基本信息子控件中填写对应的信息，在填写了这些信息中，这些信息即可存储于复合就医业务的联合下单系统200配置的数据库中。
33.后续在下单过程中，用户基本信息子控件通过用户id以及personid(就诊人id，一个用户账号下可以关联多个就诊人)确定用户的基本信息，可查询用户的所属企业、所属机
构、用户身份、员工等级等。所属企业、所属机构、用户身份有助于确定就诊人可以享受的可使用的业务权益。员工等级对应就诊人信息模块的服务级别、用户级别。所述就诊人信息子控件的可选项或可填写项包括不限于：诊人信息、手机号年龄、证件号、以及性别等等。用户可以在就诊人信息子控件中填写对应的信息，在填写了这些信息中，这些信息即可存储于复合就医业务的联合下单系统200配置的数据库中。就诊人信息主要包括就诊人身份信息、手机号、年龄、证件号、性别等信息。一个母单下只需填写一次，各个类型的子订单可复用该部分信息。
34.所述权益信息子控件包括多组一一对应的服务类型元素、可用次数元素、以及添加子订单元素；其中，所述添加子订单元素与所述业务履约信息控件关联，也就是说，当用户点击添加子订单元素是，即可弹出业务履约信息控件下相关的权益信息子控件，以供用户填写。权益信息子控件通过用户id查询到该用户的权益，若权益是限定使用人的，则通过personid可确定该personid下可使用的权益。在权益信息子控件中展示服务类型、权益可用次数以及添加子订单元素，点击添加子订单元素后即弹出业务履约信息控件下的对应的权益信息子控件，即可通过可权益信息子控件创建该服务类型下的业务子订单。
35.所述业务履约信息控件包括多个权益信息子控件，各所述权益信息子控件是根据业务类型配置的。在各个权益信息子控件中主要是填写除了基本信息、就诊人信息以外的业务线履约所需的强相关的信息，比如说vip挂号，需要收集用户的需求医院、需求科室、需求医生、需求号源类型等业务信息。
36.用户或者客服在复合就医业务的联合下单系统200的前端界面中填写上述的信息，进行下单。
37.步骤s120：根据所述基本信息和所述业务履约信息，生成所述复合就医业务的联合订单，所述联合订单包括一个母订单以及所述母订单下的任意数量的子订单，其中，一个所述子订单对应一项所述业务。
38.后台服务单元210在获取到上述的基本信息和业务履约信息后，即可根据这些信息一次性的生成复合就医业务的联合订单。在联合订单中包含一个母订单和任意数量的子订单，需要说明的是，一个子订单(也可称为业务履约单)对应着一项权益，也就是每个业务在一个母单下仅可存在一个有效的履约单，母订单通通常不包含实际的业务，其主要作用是用于关联多个子订单。比如一个联合订单中包含vip挂号子订单，还可以包含就医陪诊子订单，这两个订单是同步生成的，用户可以在前端展示界面中的权益信息子控件中，通过点击添加子订单元素实现。
39.步骤s130：对所述母订单和/或子订单中已使用的权益进行核销。
40.最后，对联合订单中已经享受的权益进行核销，如在目标用户的账号中，vip挂号的权益有3次，本次使用了一次，则对本次已经使用的权益进行核销，即减去本次使用的一次vip挂号权益，还剩2次。
41.另外，前端展示单元220，将所述后台服务单元生成的复合就医业务的联合订单显示在前端界面，这样，对于用户来说，前端界面可根据母定单来展示，将多个业务线统一在一个页面展示，方便用户查看。在另一些实施例中，进一步的，前端界面还能够显示就诊人完整的就医记录，以方便查看。
42.由图1所示的方法可以看出，本技术提供了通过获取复合就医业务的多个业务的
下单信息，其中在下单信息可包括基本信息和业务履约信息，基本信息可以包括就诊人的身份、年龄等信息，业务履约信息可以包含就诊人可享受的多项权益，如挂号、陪诊、其他协助服务等，然后根据获取到的下单信息，一次性生成所述复合就医业务的联合订单，在联合订单中，包含一个母订单和多个子订单，一个子订单对应着一项权益，母订单用于关联多个子订单，最后，对订单中已经享受的权益进行核销。本技术针对同一用户而言，统一了就诊人信息，各子订单复用一套就诊人信息，方便用户或者客服下单，简化了下单流程、提高下单效率；且在前端界面可根据母订单来展示，将多个业务统一在一个页面展示，方便用户查看，提高用户使用感受；另一方面，对于权益业务供应商而言，极大程度上降低了接收到的用户信息重复率，从而显著提高了创单效率。
43.在本技术的一些实施例中，所述基本信息包括用户id和/或personid；所述权益履约信息对应多个业务，所述多个业务具有关联关系；所述根据所述基本信息和所述业务履约信息，生成所述复合就医业务的联合订单，包括：根据所述用户id和/或所述personid，读取目标就诊人的就诊人信息、以及权益履约信息；根据所述权益履约信息，确定所述目标就诊人的多个待下单业务；基于预设的业务单流转规则，根据所述就诊人信息，以及所述多个待下单业务的关联关系，依次对各所述多个待下单业务下单，生成所述复合就医业务的联合订单。
44.母子订单的生成可以根据根据多个业务之间的关系生成，如针对有关联关系的业务，可设置业务单流转规则使各个业务单自动流转，比如说一个母单下存在一个vip挂号单跟一个就医陪诊单，待挂号成功后系统可自动完善就医陪诊单信息，并派单给供应商，不需要客服或者用户等挂号成功后再操作。具体的，可根据所述用户id和/或所述personid，读取目标就诊人的就诊人信息、以及权益履约信息下提交的业务子订单信息；并根据所述权益履约信息，确定所述目标就诊人的多个待下单业务；基于预设的业务单流转规则，根据所述就诊人信息，以及所述多个待下单业务的关联关系，依次对各所述多个待下单业务下单，生成所述复合就医业务的联合订单。如业务单流转规则中限定挂号预先，陪诊服务在后、住院办理服务在最后，可根据这个顺序，依次下单，从而生成复合就医业务的联合订单。这里之所以要设置业务单流转规则是因为，如果挂号不成功，其他子订单即便下单，也是没有意义的，本技术对业务单流转规则不作限定，可根据实际需要设定。
45.在本技术的一些实施例中，在上述方法中，所述权益履约信息对应多个业务，所述多个业务包括一个主业务和至少一个从业务，各所述从业务与所述主业务之间的关联关系为绑定关系；所述基于预设的业务单流转规则，根据所述就诊人信息，以及所述多个待下单业务的关联关系，依次对各所述多个待下单业务下单，包括：根据所述目标就诊人的就诊人信息，生成所述主业务的第一子订单；根据所述目标就诊人的就诊人信息，生成各所述从业务的第二子订单。
46.针对权益绑定售卖、绑定使用的情况，用户或者客服在创单时即可在一个母单下创建多个子订单。比如说住院安排、入院协助、出院协助3个权益绑定售卖，其中住院安排为主业务，入院协助、出院协助为从业务，客服或者用户在看到权益绑定使用的情况下，在一个母单下同时创建住院安排、入院协助、出院协助3个单子，其中，入院协助、出院协助类型的单子可为空单，选中权益即可下单。
47.在本技术的一些实施例中，所述方法还包括：响应于子订单添加操作，在已有母订
单下建立与所述子订单添加操作对应的子订单。
48.针对用户多次进线需要提供不同的服务，则可在一个母单下添加不同类型的子订单。在已有母单的情况下，给用户再创建其他类型的子定单，填写的信息较少，操作简单。
49.图4示出了根据本技术的一个实施例的复合就医业务的联合下单装置的结构示意图，复合就医业务的联合下单装置400可部署于复合就医业务的联合下单系统200包括后台服务单元210，从图4可以看出，复合就医业务的联合下单装置400包括：
50.获取单元410，用于获取复合就医业务的多个业务的下单信息，所述下单信息包括基本信息和业务履约信息；
51.订单生成单元420，用于根据所述基本信息和所述业务履约信息，生成所述复合就医业务的联合订单，所述联合订单包括一个母订单以及所述母订单下的任意数量的子订单，其中，一个所述子订单对应一项所述业务；
52.核销单元430，用于对所述母订单和/或子订单中已使用的权益进行核销。
53.在本技术的一些实施例中，在上述装置中，获取单元410，用于显示前端界面，通过所述前端界面接收所述下单信息，所述前端界面包括基本信息控件，和业务履约信息控件；其中，所述基本信息控件包括为用户基本信息子控件、权益信息子控件、以及就诊人信息子控件；所述业务履约信息控件包括多个权益信息子控件，各所述权益信息子控件是根据业务类型配置的。
54.在本技术的一些实施例中，在上述装置中，所述用户基本信息子控件的可选项或可填写项包括：用户id、personid、所属企业、所属机构、用户身份、以及员工等级；所述权益信息子控件包括多组一一对应的服务类型元素、可用次数元素、以及添加子订单元素；其中，所述添加子订单元素与所述业务履约信息控件关联；所述就诊人信息子控件的可选项或可填写项包括：诊人信息、手机号年龄、证件号、以及性别。
55.在本技术的一些实施例中，在上述装置中，所述基本信息包括用户id和/或personid；所述权益履约信息对应多个业务，所述多个业务具有关联关系；订单生成单元420，用于根据所述用户id和/或所述personid，读取目标就诊人的就诊人信息、以及权益履约信息；根据所述权益履约信息，确定所述目标就诊人的多个待下单业务；基于预设的业务单流转规则，根据所述就诊人信息，以及所述多个待下单业务的关联关系，依次对各所述多个待下单业务下单，生成所述复合就医业务的联合订单。
56.在本技术的一些实施例中，在上述装置中，所述权益履约信息对应多个业务，所述多个业务包括一个主业务和至少一个从业务，各所述从业务与所述主业务之间的关联关系为绑定关系；订单生成单元420，用于根据所述目标就诊人的就诊人信息，生成所述主业务的第一子订单；根据所述目标就诊人的就诊人信息，生成各所述从业务的第二子订单。
57.在本技术的一些实施例中，在上述装置中，订单生成单元420，还用于响应于子订单添加操作，在已有母订单下建立与所述子订单添加操作对应的子订单。
58.需要说明的是，上述的复合就医业务的联合下单装置400可一一实现前述的复合就医业务的联合下单方法，这里不再赘述。
59.图5是本技术的一个实施例电子设备的结构示意图。请参考图5，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(random-access memory，ram)，也可能还包括非易失性存储
器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。
60.处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是isa(industry standard architecture，工业标准体系结构)总线、pci(peripheral component interconnect，外设部件互连标准)总线或eisa(extended industry standard architecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
61.存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。
62.处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成复合就医业务的联合下单装置。处理器，执行存储器所存放的程序，并具体用于执行前述方法。
63.上述如本技术图4所示实施例揭示的复合就医业务的联合下单装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(central processing unit，cpu)、网络处理器(network processor，np)等；还可以是数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field－programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
64.该电子设备还可执行图4中复合就医业务的联合下单装置执行的方法，并实现复合就医业务的联合下单装置在图4所示实施例的功能，本技术实施例在此不再赘述。
65.本技术实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图4所示实施例中复合就医业务的联合下单装置执行的方法，并具体用于执行前述方法。
66.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
67.本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程
图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
68.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
69.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
70.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
71.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
72.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
73.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的同一要素。
74.本领域技术人员应明白，本技术的实施例可提供为方法、系统或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
75.以上所述仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的权利要求范围之内。

技术特征：

1.一种复合就医业务的联合下单方法，其特征在于，包括：获取复合就医业务的多个业务的下单信息，所述下单信息包括基本信息和业务履约信息；根据所述基本信息和所述业务履约信息，生成所述复合就医业务的联合订单，所述联合订单包括一个母订单以及所述母订单下的任意数量的子订单，其中，一个所述子订单对应一项所述业务；对所述母订单和/或子订单中已使用的权益进行核销。2.根据权利要求1所述的方法，其特征在于，所述获取复合就医业务的多个业务的下单信息，包括：显示前端界面，通过所述前端界面接收所述下单信息，所述前端界面包括基本信息控件，和业务履约信息控件；其中，所述基本信息控件包括为用户基本信息子控件、权益信息子控件、以及就诊人信息子控件；所述业务履约信息控件包括多个权益信息子控件，各所述权益信息子控件是根据业务类型配置的。3.根据权利要求2所述的方法，其特征在于，所述用户基本信息子控件的可选项或可填写项包括：用户id、personid、所属企业、所属机构、用户身份、以及员工等级；所述权益信息子控件包括多组一一对应的服务类型元素、可用次数元素、以及添加子订单元素；其中，所述添加子订单元素与所述业务履约信息控件关联；所述就诊人信息子控件的可选项或可填写项包括：诊人信息、手机号年龄、证件号、以及性别。4.根据权利要求1所述的方法，其特征在于，所述基本信息包括用户id和/或personid；所述权益履约信息对应多个业务，所述多个业务具有关联关系；所述根据所述基本信息和所述业务履约信息，生成所述复合就医业务的联合订单，包括：根据所述用户id和/或所述personid，读取目标就诊人的就诊人信息、以及权益履约信息；根据所述权益履约信息，确定所述目标就诊人的多个待下单业务；基于预设的业务单流转规则，根据所述就诊人信息，以及所述多个待下单业务的关联关系，依次对各所述多个待下单业务下单，生成所述复合就医业务的联合订单。5.根据权利要求4所述的方法，其特征在于，所述权益履约信息对应多个业务，所述多个业务包括一个主业务和至少一个从业务，各所述从业务与所述主业务之间的关联关系为绑定关系；所述基于预设的业务单流转规则，根据所述就诊人信息，以及所述多个待下单业务的关联关系，依次对各所述多个待下单业务下单，包括：根据所述目标就诊人的就诊人信息，生成所述主业务的第一子订单；根据所述目标就诊人的就诊人信息，生成各所述从业务的第二子订单。6.根据权利要求1所述的方法，其特征在于，所述方法还包括：响应于子订单添加操作，在已有母订单下建立与所述子订单添加操作对应的子订单。
7.一种复合就医业务的联合下单装置，其特征在于，所述装置用于实现权利要求1～6中任一项所述的方法。8.一种复合就医业务的联合下单系统，其特征在于，所述系统包括通信连接的前端展示单元和后台服务单元；其中，所述后台服务单元部署有权利要求7所述的复合就医业务的联合下单装置；所述前端展示单元，用于显示所述后台服务单元提供的前端界面，并响应于用户对所述前端界面的操作，将接收的下单信息发送至所述后台服务单元；以及将所述后台服务单元生成的复合就医业务的联合订单显示在前端界面。9.一种电子设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行权利要求1～6中任一项所述的方法。10.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行权利要求1～6中任一项所述的方法。

技术总结

本申请涉及计算机以及智慧医疗技术领域，公开了一种复合就医业务的联合下单方法、装置、系统、设备及介质，其方法包括：获取复合就医业务的多个业务的下单信息，下单信息包括基本信息和业务履约信息；根据基本信息和业务履约信息，生成复合就医业务的联合订单，联合订单包括一个母订单以及母订单下的任意数量的子订单，其中，一个子订单对应一项业务；对母订单和/或子订单中已使用的权益进行核销。本申请针对同一用户而言，统一了就诊人信息，各子订单复用一套就诊人信息，方便用户或者客服下单，简化了下单流程、提高下单效率；对于业务供应商而言，极大程度上降低了接收到的用户信息的重复率，从而显著提高了创单效率。从而显著提高了创单效率。从而显著提高了创单效率。