线上诊疗数据的处理方法、装置、设备、系统及介质与流程

1.本发明涉及计算机领域，尤其涉及一种线上诊疗数据的处理方法、装置、设备、系统及介质。


背景技术：

2.随着计算机以及互联网技术的发展，用户日常生活中越来越多的线下业务均可以通过互联网实现，例如：购物，购票，诊疗等，有效提高用户处理这些业务的效率和便利性。
3.现有技术中，目前线上诊疗(也称为在线问诊)是通过医院或者其他平台在线上开设问诊通道，由用户通过终端设备中的浏览器，应用程序等客户端进行登录访问，查询对应科室的医生，输入需要咨询的疾病的症状等提交问诊请求，医生也通过终端设备中的浏览器，应用程序等客户端进行登录访问，接收到对应的问诊请求，基于用户输入的疾病的症状等信息进行诊断，并告知用户后续处理方案。若用户需要进一步检查，则需要去相关的医院进行检查检验，用户需要单独通过医院或者检查机构进行检查预约。
4.综上所述，现有的线上诊疗服务功能比较单一，用户就诊过程中需要访问多个平台进行操作，并且线上医生无法获取到用户的检查结果，导致就诊效果和效率较低。目前，现有技术中还没有一种能够为用户提供便利操作，融合在线问诊，检查检验预约以及基于检验结果提供检后服务的技术方案。


技术实现要素：

5.本发明实施例提供一种线上诊疗数据的处理方法、装置、设备、系统及介质，提供一种能够为用户提供便利操作，融合在线问诊，检查检验预约以及基于检验结果提供检后服务的技术方案。
6.第一方面，本发明实施例提供一种线上诊疗数据的处理方法，应用于中心服务器，所述方法包括：
7.接收第一终端设备发送的预约信息，所述预约信息中包括已支付的检查订单中的至少一个检查项目的检查机构，患者的身份信息和检查时间；
8.根据所述预约信息，向所述检查机构的服务器发送预约订单，所述预约订单中包括所述患者的身份信息和所述检查时间；
9.接收所述检查机构的服务器返回的预约结果；
10.根据所述预约结果，更新所述至少一个检查项目的预约状态，并向所述第一终端设备返回所述预约结果。
11.在一种具体实施方式中，所述方法还包括：
12.从所述检查机构的服务器获取所述至少一个检查项目对应的检查报告。
13.在一种具体实施方式中，所述方法还包括：
14.接收所述第一终端设备发送的第一查询请求，所述第一查询请求用于获取所述至少一个检查项目的检查报告；
15.根据所述第一查询请求，将所述至少一个检查项目对应的检查报告发送至所述第一终端设备。
16.在一种具体实施方式中，所述方法还包括：
17.接收医生的第二终端设备发送的第二查询请求，所述第二查询请求用于获取所述至少一个检查项目的检查报告；
18.根据所述第二查询请求，将所述至少一个检查项目对应的检查报告发送至所述第二终端设备。
19.在一种具体实施方式中，所述接收第一终端设备发送的预约信息之前，所述方法还包括：
20.接收所述第一终端设备发送的检查订单，所述检查订单中包括至少一个检查项目以及支付信息；
21.生成所述检查订单对应的订单号，并将所述检查订单的订单状态更新为已支付状态。
22.在一种具体实施方式中，所述方法还包括：
23.将所述检查订单中的至少一个检查项目的预约状态设置为待预约。
24.第二方面，本发明实施例提供一种线上诊疗数据的处理方法，应用于第一终端设备，所述方法包括：
25.响应于用户对已支付的检查订单中的至少一个检查项目的预约操作，向中心服务器发送预约信息，所述预约信息中包括所述至少一个检查项目的检查机构，患者的身份信息和检查时间；
26.接收所述中心服务器返回的预约结果，所述预约结果用于指示所述至少一个检查项目是否预约成功；
27.若所述预约结果指示所述至少一个检查项目预约成功，则推送履约提示，所述履约提示用于提醒所述至少一个检查项目已预约成功以及履约方式。
28.在一种具体实施方式中，所述方法还包括：
29.若所述预约结果指示所述至少一个检查项目预约失败，则推送重新预约提示。
30.在一种具体实施方式中，所述响应于用户对已支付的检查订单中的至少一个检查项目的预约操作，向中心服务器发送预约信息之前，所述方法还包括：
31.接收医生的第二终端设备发送的检验单，所述检验单中包括所述医生根据患者的病情信息开具的至少一个检查项目；
32.响应于用户的操作对所述检验单中的至少一个检查项目进行支付，并在支付完成后向所述中心服务器发送检查订单，所述检查订单中包括至少一个检查项目以及支付信息。
33.在一种具体实施方式中，所述接收医生的第二终端设备发送的检验单之前，所述方法还包括：
34.响应于用户提交的问诊操作，向所述第二终端设备发送问诊请求，所述问诊请求中包括患者的病情信息。
35.在一种具体实施方式中，所述方法还包括：
36.向所述中心服务器发送第一查询请求，所述第一查询请求用于获取所述至少一个
检查项目的检查报告；
37.接收所述至少一个检查项目的检查报告。
38.第三方面，本发明实施例提供一种线上诊疗数据的处理方法，应用于第二终端设备，所述方法包括：
39.接收第一终端设备发送的问诊请求，所述问诊请求中包括患者的病情信息；
40.若需要为患者开具检查单，根据用户从多个检查套餐中选定的目标检查套餐生成检查单，所述检查单中包括至少一个检查项目；
41.向所述第一终端设备发送所述检查单。
42.在一种具体实施方式中，所述方法还包括：
43.显示所述患者的病情信息；
44.响应于用户的操作，确定是否需要为所述患者开具检查单。
45.在一种具体实施方式中，所述根据用户从多个检查套餐中获取的目标检查套餐生成检查单，包括：
46.获取并显示多个检查套餐，每个检查套餐对应不同的病情，每个检查套餐包括至少一个检查项目列表，检查机构，每个检查项目的价格，服务区域以及服务类型；
47.获取并显示所述第一终端设备所处的位置信息；
48.响应于所述用户的操作，根据所述用户基于所述位置信息从所述多个检查套餐中选中的所述目标检查套餐，生成所述检查单。
49.在一种具体实施方式中，所述方法还包括：
50.向中心服务器发送的第二查询请求，所述第二查询请求用于获取所述至少一个检查项目的检查报告；
51.接收所述中心服务器返回的所述至少一个检查项目对应的检查报告。
52.第四方面，本发明实施例提供一种线上诊疗数据的处理方法，应用于第三终端设备，所述方法包括：
53.响应于用户的检查套餐创建操作，获取用户配置的多个检查套餐，每个检查套餐包括所述用户选择的至少一个检查项目列表，检查机构，每个检查项目的价格，服务区域以及服务类型；
54.接收第二终端设备发送的检查套餐查询请求；
55.将所述多个检查套餐发送给所述第二终端设备。
56.第五方面，本发明实施例提供一种线上诊疗数据的处理装置，包括：
57.接收模块，用于接收第一终端设备发送的预约信息，所述预约信息中包括已支付的检查订单中的至少一个检查项目的检查机构，患者的身份信息和检查时间；
58.发送模块，用于根据所述预约信息，向所述检查机构的服务器发送预约订单，所述预约订单中包括所述患者的身份信息和所述检查时间；
59.所述接收模块还用于接收所述检查机构的服务器返回的预约结果；
60.处理模块，用于根据所述预约结果，更新所述至少一个检查项目的预约状态；
61.所述发送模块还用于向所述第一终端设备返回所述预约结果。
62.第六方面，本发明实施例提供一种线上诊疗数据的处理装置，包括：
63.发送模块，用于响应于用户对已支付的检查订单中的至少一个检查项目的预约操
作，向中心服务器发送预约信息，所述预约信息中包括所述至少一个检查项目的检查机构，患者的身份信息和检查时间；
64.接收模块，用于接收所述中心服务器返回的预约结果，所述预约结果用于指示所述至少一个检查项目是否预约成功；
65.处理模块，用于若所述预约结果指示所述至少一个检查项目预约成功，则推送履约提示，所述履约提示用于提醒所述至少一个检查项目已预约成功以及履约方式。
66.第七方面，本发明实施例提供一种线上诊疗数据的处理装置，包括：
67.接收模块，用于接收第一终端设备发送的问诊请求，所述问诊请求中包括患者的病情信息；
68.处理模块，用于若需要为患者开具检查单，根据用户从多个检查套餐中选定的目标检查套餐生成检查单，所述检查单中包括至少一个检查项目；
69.发送模块，用于向所述第一终端设备发送所述检查单。
70.第八方面，本发明实施例提供一种线上诊疗数据的处理装置，包括：
71.处理模块，用于响应于用户的检查套餐创建操作，获取用户配置的多个检查套餐，每个检查套餐包括所述用户选择的至少一个检查项目列表，检查机构，每个检查项目的价格，服务区域以及服务类型；
72.接收模块，用于接收第二终端设备发送的检查套餐查询请求；
73.发送模块，用于将所述多个检查套餐发送给所述第二终端设备。
74.第九方面，本发明实施例提供一种服务器，包括：
75.处理器，存储器，通信接口；
76.所述存储器用于存储所述处理器的可执行指令；
77.其中，所述处理器配置为经由执行所述可执行指令来执行第一方面任一项所述的线上诊疗数据的处理方法。
78.第十方面，本发明实施例提供一种终端设备，包括：
79.处理器，存储器，显示器以及通信接口；
80.所述存储器用于存储所述处理器的可执行指令；
81.其中，所述处理器配置为经由执行所述可执行指令来执行第二至第四方面任一项所述的线上诊疗数据的处理方法。
82.第十一方面，本发明实施例提供一种线上诊疗数据的处理系统，包括：
83.中心服务器，患者端的第一终端设备，医生端的第二终端设备以及运营管理端的第三终端设备；
84.所述中心服务器用于执行第一方面任一项所述的线上诊疗数据的处理方法；
85.所述第一终端设备用于执行第二方面任一项所述的线上诊疗数据的处理方法；
86.所述第二终端设备用于执行第三方面任一项所述线上诊疗数据的处理方法；
87.所述第三终端设备用于执行第四方面的线上诊疗数据的处理方法。
88.第十二方面，本发明实施例提供一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现第一至第四方面任一项所述的线上诊疗数据的处理方法。
89.第十三方面，本发明实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时用于实现第一至第四方面任一项所述的线上诊疗数据的处理方法。
90.本发明实施例提供的线上诊疗数据的处理方法、装置、设备、系统及介质，通过中心服务器建立患者端，医生端，运营管理端以及检查机构的服务器之间的数据交互通道，对于普通用户来说，可以通过终端设备上的客户端进行问诊，同时可以根据医生开具的检查单中的至少一个检查项目，直接进行检查预约，医生端也可以通过中心服务器直接从检查机构的服务器获取到患者的检查报告进行后续的诊疗服务。避免了患者需要通过多个平台和系统进行诊疗和预约检查等服务，医生也可以直接获取到检查结果，有效提高就诊操作的便利性以及在线就诊的效率。
附图说明
91.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
92.图1为本发明提供的线上诊疗数据的处理系统的架构示意图；
93.图2为本发明提供的线上诊疗数据的处理系统中各端的功能示意图；
94.图3为本发明提供的线上诊疗数据的处理方法实施例一的流程示意图；
95.图4为本发明提供的线上诊疗数据的处理方法实施例二的流程示意图；
96.图5为本发明提供的线上诊疗数据的处理方法实施例三的流程示意图；
97.图6为本发明实施例提供的检查项目列表示意图；
98.图7为本发明实施例提供的检查套餐列表示意图；
99.图8为本发明实施例提供的检查套餐创建/编辑页面示意图；
100.图9为本发明实施例提供的医生端操作页面示意图；
101.图10a为本发明实施例提供的患者端操作页面示意图；
102.图10b为本发明实施例提供的患者端操作页面示意图；
103.图11为本发明提供的线上诊疗数据的处理装置实施例一的结构示意图；
104.图12为本发明提供的线上诊疗数据的处理装置实施例二的结构示意图；
105.图13为本发明提供的线上诊疗数据的处理装置实施例三的结构示意图；
106.图14为本发明提供的线上诊疗数据的处理装置实施例四的结构示意图；
107.图15为本发明提供的一种服务器的结构示意图；
108.图16为本发明提供的一种终端设备的结构示意图。
具体实施方式
109.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在根据本实施例的启示下作出的所有其他实施例，都属于本发明保护的范围。
110.本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在
这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
111.随着互联网技术的发展，线上诊疗(或在线问诊)是指通过开设线上义诊等通道进行诊疗的活动。线上诊疗能够平衡医疗资源供给，但是线上诊疗有2大问题需要解决：
112.1)，患者很难甄别医生的资质，所以只能作基础性诊断参考。
113.2)，医生对患者的诊断方法受限。无法根据实验室检测、影像检查的结果，进行诊断。所以只能进行复诊和慢性病的问诊。
[0114]“检查检验”是指通过提取自人体的材料进行微生物学、生物化学、血液学、生物物理学等方面的分析，从而为预防、诊断、治疗人体疾病和评估人体健提供依据。当用户线下前往医院进行问诊时，约70％的问诊，都会涉及到检查检验服务。
[0115]
检查检验的服务，由“医院”或“医学检验中心”提供。例如：检验中心可以为医院提供血检、基因检测等。
[0116]
通常服务的方式有3种：上门、到店、自采样。“上门”是指检验中心指派护士上门为用户进行采样等、“到店”是指用户前往检验中心进行采样、“自采样”是指检验中心将采样的器具邮寄给用户，用户采样完成后，回寄给机构。检测检验完成后，机构通常会以短信的方式通知用户前往公众号查看报告。
[0117]
目前“线上就诊”和“检查检验”是独立的两种业务，数据和服务不互通。导致“线上就诊”时医生没有诊断的方法。“检查检验”时没有专业的医生可以提供临床建议。造成两个业务没有合在一起产生1+1>2的原因是没有克服如下问题：
[0118]
(1)、“线上就诊”与“检查检验”数据分离
[0119]
由于“线上就诊”和“检查检验”原本是2个独立发展的业务。因此数据相互独立的。在线问诊没有“检查项目”，也没有“检查项目的可服务区域”；检查检验需要的“医生检查建议”和“患者信息”都来自患者线下给到检查检验机构，且“检查检验结果”，也需要患者线下给到医生。
[0120]
(2)、“线上就诊”与“检查检验”业务分离
[0121]“线上就诊”与“检查检验”的“交易”、“预约”、“复诊”流程是分离的。
[0122]“交易”、“预约”流程：用户在互联网医院进行问诊后，无法在线预约检查检验服务，只能再单独购买，或前往线下医院。
[0123]“复诊”流程：用户线下完成检查检验后，再到互联网医院进行复诊时，无法快速找到之前的医生，也不支持直接把报告发给医生查看。
[0124]
针对现有技术中存在的问题，本发明提供一种系统的将线上就诊和检查检验的数据打通的方案，用户就诊和预约的数据打通，医生开具检查单和查看检查报告的数据打通，提供一种系统的交互方案，方便用户就诊，也方便医生进行诊疗以及后续复诊获取检查数据，避免了通过多个客户端或者多个平台进行手动操作，导致的诊疗效率低下的问题。
[0125]
发明人在对线上就诊的相关系统进行研究的过程中发现，在患者使用的用户端，可以增加与检查机构的数据互通，用户在支付之后能够直接进行检查预约，既可以解决用户侧的操作便利性问题，据此发明人考虑可以在线上就诊的服务器中增加与检查机构的数
据交互接口来实现。对于医生端的操作来说，首先需要支持医生开检验单，提供一种医生开单的系统交互方案，支持医生可以查到互联医院可服务的检查检验项目，并发送给用户。同时还要提供一种用户复诊的系统交互方案，支持“检查检验”机构在完成线下服务后，把报告给到“线上就诊”平台，由线上就诊平台继续为用户提供检后服务，将检查机构与医生端连接起来就可以实现，同样的，考虑可以在线上就诊的服务器与检查机构之间建立数据交互接口来实现。基于上述发明构思，设计了本发明中的线上诊疗数据的处理系统，以及数据处理方案。
[0126]
图1为本发明提供的线上诊疗数据的处理系统的架构示意图，如图1所示，该线上诊疗数据的处理系统至少需要包括：一个中心服务器，用来提供线上就诊的各种服务以及数据的交互；患者端的客户端，医生端的客户端以及运营管理端的客户端，这些客户端均需要运行在智能手机，电脑，平板电脑等终端设备中，以便用户能够进行操作，因此该系统还涉及到多个终端设备(第一终端设备，第二终端设备和第三终端设备)；以及多个检查机构的服务器，这些检查机构的服务器与中心服务器建立数据连接，以便患者在线下进行了检查之后，能够通过中心服务器将检查报告和检查结果传输给医生端以及用户端。
[0127]
图2为本发明提供的线上诊疗数据的处理系统中各端的功能示意图，如图2所示，结合前述图1所示的系统架构可知各个主体的主要功能如下：
[0128]
运营端，也称为运营管理端，进行线上就诊的运营管理人员，可以通过运营端提供的功能对检查机构，检查项目以及检查套餐进行管理，即可以根据不同的疾病类型，或者不同的检查需求，预先进行检查套餐的配置，并将其与对应的检查机构关联起来，为医生开具检查单提供一定的便利。
[0129]
患者端的用户在需要进行线上就诊时，通过患者端提交就诊请求。
[0130]
医生端的医生在获取到及就诊请求之后，可以查询到相关的检查套餐，然后根据患者的病情开具相应的检查单。患者端可以查看医生开具的检查单，并进行支付，预约等功能的操作。
[0131]
对于中心端(也就是中心服务器)可以与医生端，患者端，各个检查机构的系统(也就是图中的运营商系统)以及运营端等进行交互，实现检查单管理，订单管理，预约单管理以及检查机构对接等功能。
[0132]
对于每个检查机构的系统来说，则可以通过中心端获取到不同的患者对应的预约单，然后根据预约单中的数据进行预约，安排线下检查服务，例如可以安排护士上门，在进行线下检查之后，可以将检查报告进行上传。
[0133]
结合上述场景和系统，下面通过几个具体实施例对本发明提供的线上诊疗数据的处理方法的技术方案进行详细说明。
[0134]
图3为本发明提供的线上诊疗数据的处理方法实施例一的流程示意图，如图3所示，该线上诊疗数据的处理方法具体包括以下步骤：
[0135]
s101：响应于用户对已支付的检查订单中的至少一个检查项目的预约操作，向中心服务器发送预约信息。
[0136]
在本步骤中，在患者需要进行就诊时，可以通过患者端提交就诊请求，并在获取到医生开具的检查单之后对相关的检查项目进行支付。在患者端的第一终端设备中，完成之后之后可以对检查项目进行预约，患者或者其他的用户可以根据患者的时间安排，选择合
适的检查时间，在患者端进行预约操作，响应于该操作患者端的第一终端设备向中心服务器发送预约信息，该预约信息中至少包括至少一个检查项目的检查机构，患者的身份信息和检查时间；
[0137]
对于中心服务器来说，则接收第一终端设备发送的预约信息，所述预约信息中包括已支付的检查订单中的至少一个检查项目的检查机构，患者的身份信息和检查时间。
[0138]
s102：根据预约信息，向检查机构的服务器发送预约订单。
[0139]
在本步骤中，中心服务器在收到预约信息之后，根据其中的检查机构，向该检查机构对应的服务器发送预约订单，该预约订单中至少包括所述患者的身份信息和所述检查时间。
[0140]
检查机构的服务器根据接收到的预约订单中的患者的身份信息以及检查时间进行预约，确定预约结果然后返回给中心服务器。该预约结果可指示预约成功或者预约失败。预约结果还可以包括具体的预约失败的原因，例如：如果出现检查时间已经排满等可提示预约失败以及失败的原因，以便患者能够重新进行预约。
[0141]
s103：接收检查机构的服务器返回的预约结果。
[0142]
s104：根据预约结果，更新至少一个检查项目的预约状态，并向第一终端设备返回预约结果。
[0143]
在上述步骤中，中心服务器接收到检查机构的服务器返回的预约结果之后，对本地的检查订单中的该至少一个检查项目的预约状态进行更新记录，以便能够对检查项目进行管理。中心服务器还需要将预约结果返回给患者端的第一终端设备，以便患者能够根据预约结果进行后续处理。
[0144]
对于患者端的第一终端设备来说，则接收所述中心服务器返回的预约结果，所述预约结果用于指示所述至少一个检查项目是否预约成功。
[0145]
s105：若预约结果指示至少一个检查项目预约成功，则推送履约提示。
[0146]
在本步骤中，对于患者端来说，在接收到对至少一个检查项目的预约结果之后，需要对用户进行相关的提醒。具体的，如果预约成功，则通过在图形用户界面中进行显示或者短信等方式推送履约提示。
[0147]
该履约提示用于提醒所述至少一个检查项目已预约成功以及履约方式，例如，如果是上门服务则需要提醒患者注意接待医护人员以及提前要注意的事项，如果是需要患者自行到检查机构进行检查的，则需要提示时间，检查地址以及提前要注意的事项。
[0148]
可选的，在另一种情况下，若所述预约结果指示所述至少一个检查项目预约失败，则推送重新预约提示，提示用户更改时间或者地址等信息重新进行预约。
[0149]
在该实施例的具体实现中，当完成了前述的诊疗过程，并且进行了线下检查之后，检查机构在对患者进行上述至少一个检查项目的检查之后，会得到相应的检查报告。检查机构可以将检查报告上传至对应的服务器中。本方案中，为了实现患者端和/或医护端能够直接获取到检查报告，则需要实现检查机构的服务器与患者端和/或医护端的终端设备之间的数据交互，本发明中则是通过中心服务器实现的，也就是该检查报告应该传输至中心服务器，由中心服务器根据需求向患者端和/或医护端进行提供。因此本实施例还包括以下步骤：
[0150]
s106：从检查机构的服务器获取至少一个检查项目对应的检查报告。
[0151]
在本步骤中，中心服务器可以周期性的向检查机构的服务器发送查询请求，以便检查机构的服务器能够根据该查询请求，将至少一个检查项目的检查报告及时反馈给中心服务器。也可以是检查机构的服务器在获取到至少一个检查项目的检查报告之后，主动将检查报告传输至中心服务器，对此本方案不做限制。
[0152]
可选的，在患者在线下履约进行检查之后，中心服务器从检查机构获取到至少一个检查项目的检查结果之后，患者端和医生端均可以通过查询获取检查报告，具体如下。
[0153]
患者端获取查询报告的步骤：
[0154]
s107：向中心服务器发送第一查询请求。
[0155]
在本步骤中，患者端的第一终端设备发送的该第一查询请求用于获取所述至少一个检查项目的检查报告。对于中心服务器来说，则接收所述第一终端设备发送的第一查询请求。
[0156]
s108：根据第一查询请求，将至少一个检查项目对应的检查报告发送至第一终端设备。
[0157]
在本步骤中，中心服务器接收到第一查询请求之后，根据患者的身份信息和/或检查订单中的至少一个检查项目，将患者对应的至少一个检查项目返回给患者端的第一终端设备，该第一终端设备接收所述至少一个检查项目的检查报告。患者端的第一终端设备还可以通过相应客户端的图形用户界面对该检查报告进行显示。
[0158]
医生端获取查询报告的步骤：
[0159]
s109：向中心服务器发送的第二查询请求。
[0160]
在本步骤中，医生端的第二终端设备在对患者的就诊进行复诊或者需要获取检查结果时，可以根据医生的操作，向中心服务器发送第二查询请求，其中可以包括患者的身份信息和/或至少一个检查项目。该第二查询请求用于获取所述至少一个检查项目的检查报告。
[0161]
中心服务器则接收医生的第二终端设备发送的第二查询请求。
[0162]
s110：根据第二查询请求，将至少一个检查项目对应的检查报告发送至第二终端设备。
[0163]
在本步骤中，医生端的第二终端设备接收所述中心服务器返回的所述至少一个检查项目对应的检查报告。
[0164]
中心服务器接收到第二查询请求之后，根据患者的身份信息和/或至少一个检查项目，将患者对应的至少一个检查项目返回给医生端的第二终端设备，该第二终端设备接收所述至少一个检查项目的检查报告。医生端的第二终端设备还可以通过相应客户端的图形用户界面对该检查报告进行显示，以便医生能够根据检查报告进行后续的诊疗处理。
[0165]
前述实施例提供的线上诊疗数据的处理方法，通过中心服务器建立患者端，医生端，运营管理端以及检查机构的服务器之间的数据交互通道，对于普通用户来说，可以通过终端设备上的客户端进行问诊，同时可以根据医生开具的检查单中的至少一个检查项目，直接进行检查预约，医生端也可以通过中心服务器直接从检查机构的服务器获取到患者的检查报告进行后续的诊疗服务。避免了患者需要通过多个平台和系统进行诊疗和预约检查等服务，医生也可以直接获取到检查结果，有效提高就诊操作的便利性以及在线就诊的效率。
[0166]
图4为本发明提供的线上诊疗数据的处理方法实施例二的流程示意图，如图4所示，在上述实施例的基础上，在患者端进行检查订单中的至少一个检查项目进行预约之前，该线上诊疗数据的处理方法还包括以下步骤：
[0167]
s201：响应于用户提交的问诊操作，向第二终端设备发送问诊请求。
[0168]
在本步骤中，当患者身体状况不佳或者需要进行相关医疗咨询时，家人或者患者自己等用户可以通过第一终端设备中的线上诊疗客户端，选择合适的医生进行问诊，问诊过程中需要输入患者的病情信息。通过第一终端设备向医生的第二终端设备发送问诊请求，所述问诊请求中包括患者的病情信息。
[0169]
在具体实现中，第一终端设备与第二终端设备之间的数据交互可以直接通过端对端通信进行，也可以通过中心服务器进行转发交互，也就是说，第一设备通过中心服务器将问诊请求发送至第二终端设备，对此本方案不做限制。
[0170]
对于第二终端设备，则接收第一终端设备发送的问诊请求。
[0171]
s202：若需要为患者开具检查单，根据用户从多个检查套餐中选定的目标检查套餐生成检查单。
[0172]
在本步骤中，医生端接收到问诊请求之后，将问诊请求中携带的信息进行显示，以使医生能够获取具体的患者的病情信息，确定是否需要给该患者开具检查单，确定后续的治疗方案等。
[0173]
在医生确定要为该患者开具检查单之后，可以从线上就诊系统中提供的检查套餐中直接选择出合适该患者的目标检查套餐，该方案中，为了进一步减轻医生的操作流程，提高问诊效率，可以根据医生所述科室，以及患者的病情信息，向该医生端推送相关的多个检查套餐，以便医生在使用过程中能够快速获取到完备的检查项目。在医生选择出了目标检查套餐之后，在第二终端设备中基于该目标检查套餐生成检查单，该检查单中包括至少一个检查项目。
[0174]
在本方案的一种具体实现中，应理解，医生端的第二终端设备需要根据显示患者的病情信息，并且对于是否要开具检查单，也是由医生确定的，并不是设备确定的，即响应于用户(也就是医生)的操作，确定是否需要为所述患者开具检查单。
[0175]
在本方案的另一种具体实现中，医生端的第二终端设备从运营管理端的第三终端设备处获取并显示多个检查套餐，每个检查套餐对应不同的病情，每个检查套餐包括至少一个检查项目列表，检查机构，每个检查项目的价格，服务区域以及服务类型。然后进一步的获取并显示所述第一终端设备所处的位置信息，以便医生能够选择合适的检查套餐，匹配患者所处的位置，提供相应的服务。最后第二终端设备响应于所述用户的操作，根据所述用户基于所述位置信息从所述多个检查套餐中选中的所述目标检查套餐，生成所述检查单。
[0176]
s203：向第一终端设备发送检查单。
[0177]
在本步骤中，第二终端设备将获取到的检查单发送给患者端的第一终端设备。第一终端设备接收医生的第二终端设备发送的检验单，所述检验单中包括所述医生根据患者的病情信息开具的至少一个检查项目。
[0178]
s204：响应于用户的操作对检验单中的至少一个检查项目进行支付，并在支付完成后向中心服务器发送检查订单。
[0179]
在本步骤中，患者端的第一终端设备在接收到检验单之后进行显示，并显示相关的费用，患者根据实际情况对该至少一个检查项目进行支付。然后所述检查订单中包括至少一个检查项目以及支付信息。
[0180]
第一终端设备在用户对至少一个检查项目进行支付后，将至少一个检查项目以及支付信息发送给中心服务器，中心服务器接收所述第一终端设备发送的检查订单，所述检查订单中包括至少一个检查项目以及支付信息。
[0181]
s205：生成检查订单对应的订单号，并将检查订单的订单状态更新为已支付状态。
[0182]
在本步骤中，中心服务器在接收到检查订单之后，为了方便对检查订单的管理，需要对每个检查订单生成对应的订单号进行标识，并将检查单对应的患者信息等数据进行存储管理，同时对该检查订单的状态进行标识，标识为已支付状态。
[0183]
可选的，s206：将检查订单中的至少一个检查项目的预约状态设置为待预约。
[0184]
进一步的，中心服务器中已经支付了的检查订单的预约状态需要设置为待预约，该待预约状态也可以同步至患者端的第一终端设备中，以便患者能及时了解检查订单的状态，并进行后续预约操作。
[0185]
具体的至少一个检查项目的预约过程参考前述实施例一的过程。
[0186]
图5为本发明提供的线上诊疗数据的处理方法实施例三的流程示意图，如图5所示，在上述任一实施例的基础上，运营管理端可以对检查套餐的进行管理，并在医生要开具检查单时，向医生端提供相应的套餐，为医生提供便利，即在医生选择检查套餐之前，该线上诊疗数据的处理方法还包括以下步骤：
[0187]
s301：响应于用户的检查套餐创建操作，获取用户配置的多个检查套餐。
[0188]
每个检查套餐包括所述用户选择的至少一个检查项目列表，检查机构，每个检查项目的价格，服务区域以及服务类型。
[0189]
在本方案中，为了方便各个医生处理就诊时候的操作，运营管理端的用户可以根据目前的不同的需求，疾病，科室等预先进行检查套餐的创建，预先建立多个检查套餐，可以根据医生的科室以及擅长的疾病针对性的推送给不同的医生端，以便医生在开具检查单的时候可以进行选择。
[0190]
s302：接收第二终端设备发送的检查套餐查询请求。
[0191]
s303：将多个检查套餐发送给第二终端设备。
[0192]
在上述步骤中，医生端的第二终端设备可以响应于医生的操作主动向第三终端设备发送检查套餐查询请求以获取多个检查套餐，也可以是第三终端设备主动的向第二终端设备推送多个检查套餐，对此本方案不做限制。
[0193]
s304：获取并显示多个检查套餐。
[0194]
每个检查套餐对应不同的病情，每个检查套餐包括至少一个检查项目列表，检查机构，每个检查项目的价格，服务区域以及服务类型。
[0195]
s305：获取并显示第一终端设备所处的位置信息。
[0196]
s306：响应于用户的操作，根据用户基于位置信息从多个检查套餐中选中的目标检查套餐，生成检查单。
[0197]
在上述几个步骤中，当医生在处理患者的就诊请求时，医生确定需要开具检查单之后，可以根据从第三终端设备中获取的多个检查套餐以及患者所在的位置信息，综合起
来选择合适该患者进行检查的目标检查套餐。医生端的第二终端设备响应于该选择，生成对应的检查单并在医生的触发下反馈给患者端的第一终端设备。
[0198]
上述各个实施例提供的线上诊疗数据的处理方法，通过中心服务器建立运营管理端，患者端，医生端以及检查机构的服务器之间的数据交互通道，运营管理端可以对各种检查套餐进行管理，并提供给各个医生端，医生根据患者的就诊信息等获取对应的目标检查套餐生成检查单，患者端的用户可以对检查单中的检查项目进行支付，预约，以及线下履约，检查机构将检查报告上传可以传输至中心服务器，中心服务器将检查报告可以提供给医生端以及患者端，为用户提供便利，融合在线问诊，检查预约以及基于检查结果提供检查后的服务，提高就诊效率。
[0199]
结合上述各个实施例中的线上诊疗数据的处理方案，下面通过一种具体的实例对该方案进行举例说明。
[0200]
1、运营管理端——搭建互联网医院检查检验项目库
[0201]
a)定义2个实体：
[0202]
(1)检查检验项目：项目是检查检验的最小单元，由“检查检验项目”构成“检查检验套餐”。例如肝功五项检查检验套餐，会包含“直接胆红素(dbil)”和“血氨(nh3)”项目。每个检查检验项目包含字段：项目名称、项目意义。
[0203]
(2)检查检验套餐：检查检验套餐是一次采样的最小单元。例如“肝功五项”、“血常规”。检查检验套餐包含字段：套餐名称、检查机构信息、价格、检查项目列表、可服务区域、服务类型。
[0204]
可服务区域：是一组地区列表。每个地区采用中国国标编码。地址如：北京市
‑
大兴区
‑
马驹桥。每个检查检验套餐都会有可服务的区域。运营需要在运营端进行维护，以作为后续医生是否可以给患者开此检查检验套餐的依据。
[0205]
服务类型：枚举值一共有2种“上门服务(用户预约护士上门，护士上门采样后，送往机构门店)”和“到店服务(用户前往线下机构，由机构工作人员进行采样)”。不同的服务类型，在患者预约时需要填写的信息不同，且检查机构的履约方式会不同。
[0206]
b)搭建页面，支持运营人员，创建检查检验项目和检查检验套餐
[0207]
在平台的运营人员企业资源计划(enterprise resource planning，简称：erp)系统，增加页面，支持运营人员创建“检查套餐”和“检查项目”。图6为本发明实施例提供的检查项目列表示意图，图7为本发明实施例提供的检查套餐列表示意图，图8为本发明实施例提供的检查套餐创建/编辑页面示意图，上述的各个运营人员可以操作的页面和功能如图6，图7，以及图8所示，其中具体包括的操作有：创建、查看、编辑等。
[0208]
2、医生端——支持医生开检验单
[0209]
a)定义1个实体：“检验单”。
[0210]
检验单是医生在与患者沟通过程中，开出的检查检验单据。医生开单后，患者可以查看此单，并凭此单进行购买、预约、复诊。每个单据包含信息：“检验单唯一id”“开单医生”“开单医生科室”“开单时间”“开单建议”“检查检验套餐列表”“开单地区”“是否购买状态(是/否)”“是否复诊状态(是/否)”。
[0211]
开单医生：开单医生的id和名称。用户后续进行复诊时，系统将优先找此医生，进行复诊。
[0212]
开单科室：开单医生所在的科室，或用户问诊前选择的问诊科室(优先使用后者)。用户后续进行复诊时，若医生不再支持复诊，则会根据此信息，分配新的医生进行复诊。
[0213]
是否购买状态：根据此字段，判断用户是否已购买过检验单中的检查检验套餐。若未购买，则支持患者进行购买，否则支持用户进行使用。
[0214]
是否复诊状态：根据此字段，判断用户是否是首次复诊，若是，则免费。否则需要用户重新购买问诊服务。
[0215]
b)开发h5界面，支持医生开检验单
[0216]
首先，在医生和患者沟通的页面，增加“开检验单”入口。医生点击后，进入检查套餐列表页，向医生展示多个检查套餐。
[0217]
图9为本发明实施例提供的医生端操作页面示意图，如图9所示，“检查套餐列表页”支持医生通过关键词，搜索“检查套餐”。需要注意，检查套餐有地区属性。因此系统会先获取患者的所在地(互联网医院本身具有的流程，在用户发起问诊时填写的患者的地址信息)，并加载当前地区下可服务的检查套餐。医生可以在此页面勾选多个套餐，并进入“开检验单页面”[0218]“开检验单页面”除了支持医生增删改“检查检验套餐”，也要求医生填写“开检验单的原因”，并在“确认”后，正式生成检验单。
[0219]
检验单生产后，会在“医生和患者”沟通的页面中展示。患者可以点击进入“检验单详情页”。
[0220]
3、患者端——查看医生检验单并进行购买、在线预约
[0221]
a)定义订单和预约单2个实体
[0222]
订单：记录用户购买检验单后的信息，包括：购买人、购买套餐列表(本方案中不支持用户删改医生开的检查检验套餐。但若有需要，可以支持用户在购买时进行修改)、购买时选择的到店服务门店、发票等信息。由于一个检验单中的套餐可能是不同检查机构的，所以一个订单中也必然包含不同检查机构的检查检验套餐。
[0223]
预约单：预约单记录用户购买后的一次服务。一个订单可能会包含1个或多个预约单。预约单信息包括：检查检验套餐列表、服务检查机构、预约单状态、是否出报告。其中，预约单状态包括：待预约、预约中、预约成功、预约失败、取消中、取消成功、已采样、已完成。
[0224]
b)开发h5界面，支持患者购买检验单
[0225]
图10a为本发明实施例提供的患者端操作页面示意图，如图10a所示，“开发“检验单页面”，支持患者查看医生开的检验单的详细信息。此页面需要根据“检验单”的是否购买状态，在页面底部展示不同的操作按钮。对与“是否购买状态＝否”的检验单，展示“预约检查检验服务”按钮，点击后跳转到“结算页”。对与“是否购买状态＝是”的检验单，展示“使用检查检验服务”按钮，点击后跳转到“预约详情页”。
[0226]
开发“结算页”，此页面要求用户填写购买人电话。电话根据患者问诊时，填写的信息自动加载。此页面也展示套餐的价格和套餐的服务检查机构。对于“到店服务”的检查检验服务，需要用户在下单前就完成门店列表的选择。因为机构网点较少，需要防止用户下单后，发现检查检验机构距离过远，再退款的情况出现。
[0227]
(检查检验的门店数据来源说明：可以由检查机构通过api接口，以套餐维度同步至平台。也可以由平台在运营端支持运营录入)。
[0228]
用户在结算页提交后，将由中心服务器生成唯一id(即检查订单的订单号)。并等待用户通过微信、银行卡等渠道进行付款。付款完成后，中心端，将根据“检查机构”和“服务类型”拆分侧不同的预约单。(因为不同的检查机构，需要分别预约；不同的服务类型也需要分别预约)。
[0229]
c)开发h5界面，支持患者预约检验服务
[0230]
图10b为本发明实施例提供的患者端操作页面示意图，如图10b所示，开发“预约单信息页”，支持用户查看“订单维度”下的“预约单”信息，并在预约单维度支持用户进行“预约”“改约”“取消”“查看报告”等操作。此页面也承担用户复诊的能力。当用户所有的预约单是“报告已生成状态”，页面中“复诊”按钮高亮，支持用户点击后进行复诊。当用户有预约单未生成报告时。“复诊”按钮非高亮展示，但也支持用户进行点击后进行复诊。
[0231]
开发“预约信息填写页”和“预约单信息详情页”。用户在“预约单信息页”点击“立即预约”按钮，支持跳转到“预约信息填写页”。信息填写页将根据服务类型的不同，展示不同的输入内容。
[0232]
如果是“上门服务”则要求用户填写地址、时间(时间在运营端设置)、检测人信息。如果是“到店服务”则要求用户填写到店时间、检测人信息。
[0233]
用户填写完成后，点击“提交按钮”时，系统会调用检查机构的api接口提交预约。若提交成功，则页面跳转到“预约单信息详情页”，预约单状态由“待预约”修改为“预约中”。等待检查机构返回预约结果。
[0234]
4、中心服务器——患者预约后，将信息同步至检查检验机构的服务器进行履约
[0235]
a)可将检查订单拆分成预约单
[0236]
按照“一个检查机构一种服务”的逻辑，可以将订单拆分成多个预约单。
[0237]
b)检查机构提供api接口，支持平台进行预约、取消预约
[0238]
各检查机构需要提供接口，支持平台输入“检查套餐id”“平台预约单号”。(检查机构需要提前在自己系统维护检测建议套餐id和检查机构自己套餐的关系)。
[0239]
c)平台提供api接口，支持检查机构返回预约结果、取消结果
[0240]
提供接口，支持检查机构输入“预约单号”、“预约/取消结果”、“原因”。当检查机构调用接口后，系统先判断是否预约单号存在，若存在再还需判断状态是否合法。(若预约单状态是“取消中”，则不允许检查机构回传“预约成功”)
[0241]
d)提供api接口，支持检查机构根据“预约单号”回传检查报告
[0242]
提供接口，支持检查机构输入“预约单号”、“报告id列表”、“报告pdf下载链接列表”。当检查机构调用接口后，系统先判断是否预约单号存在，若存在，则进行pdf报告的下载，下载完成后，短信通知用户报告生成。
[0243]
5、患者端——支持用户查看检查检验报告并进行复诊
[0244]
a)所有报告生成后，支持用户复诊
[0245]
用户点击复诊时，先判断预约单“是否已复诊”，若未复诊，则不需要用户再次支付问诊费。若是已复诊，则需要用户支付金额。支付后，系统将根据预约单的“医生”和“科室”信息，找到医生进行复诊。找医生的逻辑：若医生可以提供服务，则找此医生进行问诊。若医生不可提供服务，则找科室下的某个医生，提供服务。若科室不存在，则要求用户填写。
[0246]
本发明提供一种技术方案，将线上问诊和线下检查检验结合，完善互联医院的诊
断手段，通过运营管理端支持运营端创建检查检验项目；通过医生端、患者端功能改造，定义“检验单”单据，支持患者凭此单进行购买、预约、复诊；通过中心服务器和各个检查机构进行交互，实现线下预约线下履约。避免了患者需要通过多个平台和系统进行诊疗和预约检查等服务，医生也可以直接获取到检查结果，有效提高就诊操作的便利性以及在线就诊的效率。
[0247]
图11为本发明提供的线上诊疗数据的处理装置实施例一的结构示意图；如图11所示，该线上诊疗数据的处理装置10包括：
[0248]
接收模块11，用于接收第一终端设备发送的预约信息，所述预约信息中包括已支付的检查订单中的至少一个检查项目的检查机构，患者的身份信息和检查时间；
[0249]
发送模块12，用于根据所述预约信息，向所述检查机构的服务器发送预约订单，所述预约订单中包括所述患者的身份信息和所述检查时间；
[0250]
所述接收模块11还用于接收所述检查机构的服务器返回的预约结果；
[0251]
处理模块13，用于根据所述预约结果，更新所述至少一个检查项目的预约状态；
[0252]
所述发送模块12还用于向所述第一终端设备返回所述预约结果。
[0253]
进一步地，所述处理模块13还用于：
[0254]
从所述检查机构的服务器获取所述至少一个检查项目对应的检查报告。
[0255]
进一步地，所述接收模块11还用于接收所述第一终端设备发送的第一查询请求，所述第一查询请求用于获取所述至少一个检查项目的检查报告；
[0256]
所述发送模块12还用于根据所述第一查询请求，将所述至少一个检查项目对应的检查报告发送至所述第一终端设备。
[0257]
可选的，所述接收模块11还用于接收医生的第二终端设备发送的第二查询请求，所述第二查询请求用于获取所述至少一个检查项目的检查报告；
[0258]
所述发送模块12还用于根据所述第二查询请求，将所述至少一个检查项目对应的检查报告发送至所述第二终端设备。
[0259]
在前述任一实施例的基础上，可选的，所述接收第一终端设备发送的预约信息之前，所述接收模块11还用于接收所述第一终端设备发送的检查订单，所述检查订单中包括至少一个检查项目以及支付信息；
[0260]
所述处理模块13还用于生成所述检查订单对应的订单号，并将所述检查订单的订单状态更新为已支付状态。
[0261]
可选的，所述处理模块13还用于将所述检查订单中的至少一个检查项目的预约状态设置为待预约。
[0262]
本实施例提供的线上诊疗数据的处理装置，用于执行前述任一方法实施例中中心服务器的技术方案，其实现原理和技术效果类似，通过中心服务器建立患者端，医生端，运营管理端以及检查机构的服务器之间的数据交互通道，对于普通用户来说，可以通过终端设备上的客户端进行问诊，同时可以根据医生开具的检查单中的至少一个检查项目，直接进行检查预约，医生端也可以通过中心服务器直接从检查机构的服务器获取到患者的检查报告进行后续的诊疗服务。避免了患者需要通过多个平台和系统进行诊疗和预约检查等服务，医生也可以直接获取到检查结果，有效提高就诊操作的便利性以及在线就诊的效率。
[0263]
图12为本发明提供的线上诊疗数据的处理装置实施例二的结构示意图；如图12所
示，该线上诊疗数据的处理装置20包括：
[0264]
发送模块21，用于响应于用户对已支付的检查订单中的至少一个检查项目的预约操作，向中心服务器发送预约信息，所述预约信息中包括所述至少一个检查项目的检查机构，患者的身份信息和检查时间；
[0265]
接收模块22，用于接收所述中心服务器返回的预约结果，所述预约结果用于指示所述至少一个检查项目是否预约成功；
[0266]
处理模块23，用于若所述预约结果指示所述至少一个检查项目预约成功，则推送履约提示，所述履约提示用于提醒所述至少一个检查项目已预约成功以及履约方式。
[0267]
可选的，在另一种实现方式中，所述处理模块23还用于若所述预约结果指示所述至少一个检查项目预约失败，则推送重新预约提示。
[0268]
可选的，所述响应于用户对已支付的检查订单中的至少一个检查项目的预约操作，向中心服务器发送预约信息之前，所述接收模块22还用于接收医生的第二终端设备发送的检验单，所述检验单中包括所述医生根据患者的病情信息开具的至少一个检查项目；
[0269]
所述发送模块21还用于响应于用户的操作对所述检验单中的至少一个检查项目进行支付，并在支付完成后向所述中心服务器发送检查订单，所述检查订单中包括至少一个检查项目以及支付信息。
[0270]
可选的，所述接收医生的第二终端设备发送的检验单之前，所述发送模块21还用于响应于用户提交的问诊操作，向所述第二终端设备发送问诊请求，所述问诊请求中包括患者的病情信息。
[0271]
可选的，所述发送模块21还用于向所述中心服务器发送第一查询请求，所述第一查询请求用于获取所述至少一个检查项目的检查报告；
[0272]
所述接收模块22还用于接收所述至少一个检查项目的检查报告。
[0273]
本实施例提供的线上诊疗数据的处理装置，用于执行前述任一方法实施例中患者端的第一终端设备的技术方案，其实现原理和技术效果类似，对于普通用户来说，可以通过终端设备上的客户端进行问诊，同时可以根据医生开具的检查单中的至少一个检查项目，直接进行检查预约，提高了就诊过程的便利性和就诊效率。
[0274]
图13为本发明提供的线上诊疗数据的处理装置实施例三的结构示意图；如图13所示，该线上诊疗数据的处理装置30包括：
[0275]
接收模块31，用于接收第一终端设备发送的问诊请求，所述问诊请求中包括患者的病情信息；
[0276]
处理模块32，用于若需要为患者开具检查单，根据用户从多个检查套餐中选定的目标检查套餐生成检查单，所述检查单中包括至少一个检查项目；
[0277]
发送模块33，用于向所述第一终端设备发送所述检查单。
[0278]
可选的，所述线上诊疗数据的处理装置还包括：显示模块，用于显示所述患者的病情信息；
[0279]
所述处理模块32还用于响应于用户的操作，确定是否需要为所述患者开具检查单。
[0280]
在一种具体实施方式中，所述处理模块32具体用于：
[0281]
获取并显示多个检查套餐，每个检查套餐对应不同的病情，每个检查套餐包括至
少一个检查项目列表，检查机构，每个检查项目的价格，服务区域以及服务类型；
[0282]
获取并显示所述第一终端设备所处的位置信息；
[0283]
响应于所述用户的操作，根据所述用户基于所述位置信息从所述多个检查套餐中选中的所述目标检查套餐，生成所述检查单。
[0284]
可选的，所述发送模块33还用于向中心服务器发送的第二查询请求，所述第二查询请求用于获取所述至少一个检查项目的检查报告；
[0285]
所述接收模块31还用于接收所述中心服务器返回的所述至少一个检查项目对应的检查报告。
[0286]
本实施例提供的线上诊疗数据的处理装置，用于执行前述任一方法实施例中医生端的第二终端设备的技术方案，其实现原理和技术效果类似，医生端可以通过中心服务器直接从检查机构的服务器获取到患者的检查报告进行后续的诊疗服务，医生可以直接获取到检查结果，有效提高就诊操作的便利性以及在线就诊的效率。
[0287]
图14为本发明提供的线上诊疗数据的处理装置实施例四的结构示意图；如图14所示，该线上诊疗数据的处理装置40包括：
[0288]
处理模块41，用于响应于用户的检查套餐创建操作，获取用户配置的多个检查套餐，每个检查套餐包括所述用户选择的至少一个检查项目列表，检查机构，每个检查项目的价格，服务区域以及服务类型；
[0289]
接收模块42，用于接收第二终端设备发送的检查套餐查询请求；
[0290]
发送模块43，用于将所述多个检查套餐发送给所述第二终端设备。
[0291]
本实施例提供的线上诊疗数据的处理装置，用于执行前述任一方法实施例中运营管理端的第三终端设备的技术方案，其实现原理和技术效果类似，在此不再赘述。
[0292]
图15为本发明提供的一种服务器的结构示意图。如图15所示，该服务器100包括：
[0293]
处理器111，存储器112，以及通信接口113；
[0294]
所述存储器112用于存储所述处理器111的可执行指令；
[0295]
其中，所述处理器111配置为经由执行所述可执行指令来执行前述任一方法实施例中的中心服务器的技术方案。
[0296]
可选的，存储器112既可以是独立的，也可以跟处理器111集成在一起。
[0297]
可选的，当所述存储器112是独立于处理器111之外的器件时，所述服务器100还可以包括：
[0298]
总线，用于将上述器件连接起来。
[0299]
该服务器用于执行前述任一方法实施例中中心服务器侧的技术方案，其实现原理和技术效果类似，在此不再赘述。
[0300]
图16为本发明提供的一种终端设备的结构示意图。如图16所示，该服终端设备200包括：
[0301]
处理器211，存储器212，显示器213以及通信接口214；
[0302]
所述存储器212用于存储所述处理器的可执行指令；
[0303]
其中，所述处理器211配置为经由执行所述可执行指令来执行前述任一实施例提供线上诊疗数据的处理方法中第一终端设备，第二终端设备或者第三终端设备的技术方案。
[0304]
可选的，存储器212既可以是独立的，也可以跟处理器211集成在一起。
[0305]
可选的，当所述存储器212是独立于处理器211之外的器件时，所述终端设备200还可以包括：
[0306]
总线，用于将上述器件连接起来。
[0307]
该终端设备用于执行前述任一方法实施例中患者端，或者医生端，或者运营管理端的终端设备的技术方案，其实现原理和技术效果类似，在此不再赘述。
[0308]
本发明实施例还提供一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现前述任一实施例提供的中心服务器或者任一终端设备侧的技术方案。
[0309]
本发明实施例还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时用于实现前述任一方法实施例提供的中心服务器或者任一终端设备侧的技术方案。
[0310]
本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
[0311]
最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或对其中部分或全部技术特征进行等同替换；而这些修改或替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。