交互诊疗信息的方法、系统、设备和计算机可读介质与流程

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.图1是根据本发明实施例的交互诊疗信息的方法的主要流程的示意图；
41.图2是根据本发明实施例的实现交互诊疗信息的系统交互示意图；
42.图3是根据本发明实施例的共享客户端的用户健康档案的流程示意图；
43.图4是根据本发明实施例的交互诊疗信息的交互流程示意图；
44.图5是根据本发明实施例的交互诊疗信息的系统的主要结构的示意图；
45.图6是本发明实施例可以应用于其中的示例性系统架构图；
46.图7是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。
具体实施方式
47.以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
48.现实生活中，用户经常需要问诊。不管疾病是否严重，都比较茫然，直接去大医院耗时较长，并且不知道去什么医院，看什么科室，找哪个医生。当费劲看完一次病以后，又不知道后续怎么安排，身体恢复是否正常。
49.用户问诊多次，线上数据和线下数据无法打通，医生之间的问诊数据无法打通。而且，线上诊疗系统往往是由客服或者护士对接用户，专业能力相比于医生薄弱，许多用户提出的问题无法直接处理，需要专科医生进一步处理。
50.综上，用户与医生多次重复交互诊疗信息，导致信息沟通效率较低。
51.为了解决信息沟通效率较低的技术问题，可以采用以下本发明实施例中的技术方案。
52.参见图1，图1是根据本发明实施例的交互诊疗信息的方法主要流程的示意图，通过全科对应关系和专科对应关系，确保客户端的全科医生和专科医生能够共享用户健康档案。如图1所示，具体包括以下步骤：
53.s101、客户端向客户端的全科医生端发送诊疗请求。
54.参见图2，图2是根据本发明实施例的实现交互诊疗信息的系统交互示意图。图2中包括客户端、全科医生端、服务端、专科医生端和档案服务器。
55.客户端用于与用户交互信息，客户端可以位于电脑端和/或移动终端。作为一个示例，客户端接收用户语音以实现与用户交互信息。作为另一个示例，客户端接收用户的文字输入，以实现与用户交互信息。可以理解的是，用户通过客户端与其他端实现信息交互。
56.在本发明的一个实施例中，客户端包括物联网设备，如：智能手环。物联网设备用于采集用户体征数据，检查用户当前身体状况。
57.全科医生端，用于与全科医生交互信息。专科医生端，用于与专科医生交互信息。类似于客户端，全科医生端接收全科医生语音以实现与全科医生交互信息。专科医生端接收专科医生语音以实现与专科医生交互信息。
58.也就是说，客户端、全科医生端和专科医生端，上述三端均可以通过语音和/或文字的方式交互。而且，上述三端均能够通过电脑和/或移动终端访问。
59.服务端，用于与客户端、全科医生端、专科医生端和档案服务器交互信息。
60.档案服务器用于存储客户端的用户健康档案。其中，用户健康档案不仅包括用户在线上诊疗涉及的健康档案，而且还包括用户在线下诊疗涉及的健康档案。
61.用户在需要与医生交互诊疗信息的情况下，通过客户端向客户端的全科医生端发送诊疗请求。
62.对于每个客户端而言，均对应一个全科医生端，上述客户端与全科医生端的对应关系称为全科对应关系。具体来说，客户端在首次发送诊疗请求的情况下，可以基于诊疗请求中的用户信息为客户端匹配全科医生端，以建立全科对应关系。这样，在诊疗全过程中，客户端始终与对应的全科医生端交互信息，全科医生端为客户端提供完整诊疗。
63.在本发明的一个实施例中，可以采用以下方式为客户端匹配全科医生端。根据诊疗请求中关键词、查找全科医生参数和知识图谱，为用户推荐全科医生，并建立客户端与全科医生端的对应关系。后续涉及诊疗的业务，用户通过客户端和全科医生端实时咨询全科医生。
64.作为一个示例，查找全科医生参数包括以下一种或多种，是否接诊过和用户相似既往史的人；是否接诊过和用户相似家族史的人；结合用户体征数据，是否接诊过相似的人；医生当前工作繁忙状态。
65.s102、全科医生端响应诊疗请求，在确定需要引入专科医生服务的情况下，由服务端通过知识图谱，推荐一个或多个专科医生至全科医生端，供全科医生决策或由全科医生端转发至客户端决策。
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.由客户端决策专科医生，那么需要全科医生端将推荐的一个或多个专科医生转发至客户端。需要说明的是，一方面全科医生端可以转发全部专科医生供客户端决策；另一方面，全科医生端可以转发经剔除的专科医生供客户端决策。这是因为，以全科医生的专业性剔除一部分专科医生，将剩余的专科医生转发至客户端，以确保专科医生的针对性。
93.在本发明的一个实施例中，由全科医生确定专科医生的情况下，服务端接收全科医生端，针对一个或多个专科医生的决策指令；由客户端确定专科医生的情况下，服务端接收全科医生端转发客户端，针对一个或多个专科医生的决策指令。需要说明的是，上述转发至客户端，针对一个或多个专科医生的决策指令中包括全部或部分专科医生。包括部分专科医生是因为全科医生已剔除针对性差的专科医生。
94.s103、全科对应关系中的全科医生端和专科对应关系中的专科医生端，共享客户端的用户健康档案，全科对应关系是由服务端建立的客户端与全科医生端的对应关系，专科对应关系是由服务端建立的客户端与决策后引入专科医生端的对应关系。
95.客户端与客户端的全科医生端具有对应关系，将上述对应称为全科对应关系。即，全科对应关系是由服务端建立的客户端与全科医生端的对应关系。
96.经全科医生端或客户端决策确定专科医生后，服务端建立专科对应关系。即，专科对应关系是客户端与决策后引入专科医生端的对应关系。
97.针对同一个客户端来说，用户健康档案只能对全科对应关系中的全科医生端和专科对应关系中的专科医生端开放。全科对应关系中的全科医生端和专科对应关系中的专科医生端，共享客户端的用户健康档案。对于其他并不属于全科对应关系中的全科医生端，以及不属于专科对应关系中的专科医生端，无权获知客户端的用户健康档案。
98.通过全科对应关系和专科对应关系，限制用户健康档案的访问权限，不仅提高用户健康档案的使用效率，而且提高用户健康档案的安全性。
99.参见图3，图3是根据本发明实施例的共享客户端的用户健康档案的流程示意图，具体包括以下步骤：
100.s301、专科医生端，依据客户端的用户健康档案，向服务端反馈诊疗结果。
101.专科对应关系中的专科医生端，具有访问用户健康档案的权限。继而，专科医生端，依据客户端的用户健康档案，向服务端反馈诊疗结果。
102.在具体实现时，服务端自动占据专科医生的对应时间段，完成线上预约或者线下挂号。服务端可以推送用户健康档案至专科医生，同时全科医生还可以将与用户的沟通情况推送至专科医生。
103.专科医生基于推送的内容，提前了解用户病情，大大加快了沟通效率。用户也无需就相同的问题多次答复。专科医生接诊时，专科医生可以实时查看客户的用户健康档案。完成专科问诊后，专科医生可以更新用户健康档案，并实时同步到档案服务器。
104.专科医生端，依据客户端的用户健康档案，向服务端反馈诊疗结果。服务端作为连接专科医生端与全科医生端的枢纽，一方面与专科医生端交互，以接收并在档案服务器中存储诊疗结果；另一方面与全科医生端交互，以向全科医生端转发诊疗结果。
105.在本发明的一个实施例中，全科对应关系中的全科医生端和专科对应关系中的专科医生端，共享客户端的用户健康档案。共享客户端的用户健康档案包括主动推送用户健
康档案，以及响应于请求查询并发送用户健康档案。
106.用户健康档案存储在档案服务器中，可以采用下述一种方式共享客户端的用户健康档案。
107.档案服务器向全科对应关系的全科医生端和/或专科对应关系中的专科医生端，推送客户端的用户健康档案，以共享客户端的用户健康档案；
108.或，
109.档案服务器接收全科对应关系的全科医生端和/或专科对应关系中的专科医生端查询档案请求，查询并发送客户端的用户健康档案，以共享客户端的用户健康档案。
110.s302、全科医生端，基于客户端的用户健康档案和服务端转发的诊疗结果，向客户端发送治疗分析意见。
111.全科医生端在接收到专科医生的诊疗结果后，结合客户端的用户档案进行分析得到治疗分析意见。向客户端发送治疗分析意见。其中，诊疗结果是专科医生端经服务端转发至全科医生端。
112.在图3的实施例中，全科对应关系中的全科医生端和专科对应关系中的专科医生端，具有获知客户端的用户健康档案的权限，一方面提高沟通效率；另一个方面，保障用户隐私。
113.s104、服务端响应专科医生端的诊疗结果，更新全科对应关系和专科对应关系。
114.服务端在接收到专科医生端的诊疗结果后，响应专科医生端的诊疗结果，更新全科对应关系和专科对应关系。
115.考虑到全科对应关系中的全科医生端，专科对应关系中的专科医生端，才能共享客户端的用户健康档案。在专科医生端已发送诊疗结果的情况下，有可能无需再联系全科对应关系中的全科医生端，专科对应关系中的专科医生端，因此需要更新全科对应关系和专科对应关系。
116.在本发明的一个实施例中，专科医生端的诊疗结果可以是由专科医生端发送的，或是由全科医生端发送的。
117.一种情况，专科医生端在确定诊疗结果后，为了及时更新全科对应关系和专科对应关系，专科医生端可以将诊疗结果直接发送至服务端。
118.另一种情况，专科医生端在确定诊疗结果后，将上述诊疗结果发送至全科医生端，以供全科医生基于诊疗结果确定治疗分析意见。全科医生端接收诊疗结果后，再将诊疗结果发送至服务端。由全科医生端发送诊疗结果，便于全科医生端把关诊疗结果，以触发更新全科对应关系和专科对应关系。
119.在本发明的一个实施例中，全科对应关系并非一成不变，全科对应关系在有效期内保持不变，有效期由客户端的服务权限确定。也就是说，在有效期内，全科对应关系不变，客户使用由同一个全科医生接诊，有利于全面有效为客户提供医疗服务。其中，有效期是由客户端的服务权限确定。作为一个示例，客户购买3年的服务权限。
120.相对于全科对应关系来说，专科对应关系是一次性的。作为一个示例，服务端响应专科医生端的诊疗结果，解除之前建立的专科对应关系。当客户需要再次引入专科医生的情况下，可以优先引入专科对应关系中的专科医生。进而再次建立专科对应关系。那么，由客户端的服务权限确定专科对应关系的建立次数。即，专科对应关系的建立次数，由客户端
的服务权限确定。相应地，客户端的服务权限越高，则专科对应关系的建立次数越多。
121.在本发明的一个实施例中，具体采用以下方式更新全科对应关系和专科对应关系。
122.考虑到，始终由全科对应关系中的全科医生端，直接负责客户端的诊疗请求。没有特殊情况下，全科对应关系保持不变的可能性较大。
123.而对于专科对应关系来说，专科医生是在全科医生确定需要引入专科医生服务的情况下确定的。在用户无需再与专科医生沟通的情况下，为了确保用户健康档案的隐私性和安全性，需要解除客户端与专科医生端的对应关系。此外，在用户和/或全科医生认为需要更换专科医生的情况下，也需要解除客户端与专科医生端的对应关系。
124.那么，更新全科对应关系和专科对应关系，具体可以：保持全科对应关系不变，解除客户端与决策后引入专科医生端的对应关系。
125.在本发明的一个实施例中，为了保障用户健康档案的隐私性和安全性，解除专科对应关系中的专科医生端，无权访问客户端的用户健康档案。
126.作为一个示例，专科对应关系中包括客户端a1和专科医生端c1。服务端响应专科医生端的诊疗结果，更新全科对应关系和专科对应关系。全科对应关系不变，解除客户端a1与专科医生端c1的对应关系。进而，专科医生端c1无权访问客户端a1的用户健康档案，同样的服务端也停止向专科医生端c1推送客户端a1的用户健康档案。
127.在上述实施例中，客户端向所述客户端的全科医生端发送诊疗请求；所述全科医生端响应所述诊疗请求，在确定需要引入专科医生为客户服务的情况下，由服务端通过知识图谱，推荐一个或多个专科医生至所述全科医生端，供全科医生决策或由所述全科医生端转发至所述客户端决策；全科对应关系中的全科医生端和专科对应关系中的专科医生端，共享所述客户端的用户健康档案，所述全科对应关系是由所述服务端建立的所述客户端与所述全科医生端的对应关系，所述专科对应关系是由所述服务端建立的所述客户端与决策后引入专科医生端的对应关系；所述服务端响应所述专科医生端的诊疗结果，更新所述全科对应关系和所述专科对应关系。属于对应关系的医生端能够共享用户健康档案，避免客户与医生多次重复交互诊疗信息，进而提高信息沟通效率。
128.此外，由全科医生全程跟进诊疗信息的交互，大大提高医生工作效率，提高客户满意度。服务端统一管理医生资源，依据客户需要确定全科医生和专科医生，进而提前锁定专家医生号。由全科医生把用户和专科医生串联起来，用户只需与全科医生一人对接，就可以享受多个专科医生的服务。
129.参见图4，图4是根据本发明实施例的交互诊疗信息的交互流程示意图，具体包括以下步骤：
130.图4实施例中的技术方案，是本发明技术方案的一种实现方式，本发明技术方案还包括其他的实现方式。
131.s401、客户端发送诊疗请求。
132.为用户配备智能手环，智能手环与移动终端中的客户端交互信息。用户有医疗服务需要时，通过客户端发送诊疗请求。诊疗请求中包括用户号码。
133.s402、将诊疗请求发送至全科医生端。
134.依据诊疗请求中的用户号码获知用户信息，并查找全科对应关系。若存在全科对
应关系，将用户信息和诊疗请求，发送至全科对应关系中的全科医生端。
135.若不存在全科对应关系，则根据诊疗请求中关键词，结合全科医生参数和知识图谱确定全科医生端，并建立客户端与全科医生端的全科对应关系。然后，将用户信息和诊疗请求，发送至全科对应关系中的全科医生端。
136.s403、全科医生端接诊。
137.全科医生端与客户端沟通，对用户健康问题提供咨询。在咨询过程中，若无需专科医生，在全科医生端填写用户健康档案和治疗分析意见。
138.若需要专科医生协助，则全科医生端客观描述用户的健康情况，并存入用户健康档案。全科医生判断需要线上问诊专科医生，还是线下问诊专科医生。
139.在需要联系专科医生的情况下，全科医生向服务端发送请求，以推荐专科医生。
140.s404、服务端推荐专科医生。
141.服务端依据知识图谱，推荐一个或多个专科医生至全科医生端。
142.s405、全科医生端将推荐的专科医生转发至客户端。
143.通过客户端选择专科医生后，将所选择的专科医生发送至服务端。
144.s406、推送用户健康档案。
145.服务端推送用户健康档案至客户端选择的专科医生端。大大节约了专科医生的时间。用户也无需就相同问题回答多次。
146.服务端自动的占据专科医生的对应时间段，完成线上预约或者线下挂号。
147.s407、专科医生端发送诊疗结果。
148.专科医生通过专科医生端能够看到用户健康档案，进而在指定时间完成客户端的问诊。专科医生可以编辑用户健康档案，实时同步档案服务器，这样通过客户端和签约医生端都能实时看到。
149.s408、更新全科对应关系和专科对应关系。
150.服务端响应专科医生端的诊疗结果，更新全科对应关系和专科对应关系。
151.在图4的实施例中，由全科医生实时监控和解答用户健康问题，大部分问题全科医生都能完成处理，大大减少了流入专科医生诊疗请求。由于全科医生对客户健康情况非常了解，当专科医生接诊时，专科医生可以实时查看客户的整体健康情况。
152.参见图5，图5是根据本发明实施例的交互诊疗信息的系统的主要结构的示意图，交互诊疗信息的系统可以实现交互诊疗信息的方法，如图5所示，交互诊疗信息的系统具体包括：客户端501、全科医生端502、服务端503、专科医生端504和档案服务器505。
153.所述客户端501，用于向客户端的全科医生端发送诊疗请求；
154.所述全科医生端502，响应所述诊疗请求，全科对应关系中的全科医生端，共享所述客户端的用户健康档案，所述全科对应关系是由所述服务端建立的所述客户端与所述全科医生端的对应关系；
155.所述服务端503，用于在确定需要引入专科医生服务的情况下，通过知识图谱，推荐一个或多个专科医生，供全科医生决策或由所述全科医生端转发至所述客户端决策；响应所述专科医生端的诊疗结果，更新所述全科对应关系和所述专科对应关系；
156.所述专科医生端504，用于发送诊疗结果，专科对应关系中的专科医生端，共享所述客户端的用户健康档案，所述专科对应关系是由所述服务端建立的所述客户端与决策后
引入专科医生端的对应关系。
157.在本发明的一个实施例中，所述专科医生端504，依据所述客户端的用户健康档案，向所述服务端反馈所述诊疗结果；
158.所述全科医生端502，基于所述客户端的用户健康档案和所述服务端转发的所述诊疗结果，向所述客户端发送治疗分析意见。
159.在本发明的一个实施例中，档案服务器505，向所述全科对应关系的全科医生端和/或所述专科对应关系中的专科医生端，推送所述客户端的用户健康档案，以共享所述客户端的用户健康档案；
160.或，
161.所述档案服务器505，接收所述全科对应关系的全科医生端和/或所述专科对应关系中的专科医生端查询档案请求，查询并发送所述客户端的用户健康档案，以共享所述客户端的用户健康档案。
162.在本发明的一个实施例中，所述专科医生端504，向所述服务端发送所述诊疗结果；
163.或，
164.所述全科医生端502，向所述服务端发送所述诊疗结果。
165.在本发明的一个实施例中，所述全科对应关系在有效期内保持不变，所述有效期由所述客户端的服务权限确定；
166.所述专科对应关系的建立次数，由所述客户端的服务权限确定。
167.在本发明的一个实施例中，服务端503，具体用于保持所述全科对应关系不变，解除所述客户端与所述决策后引入专科医生端的对应关系。
168.在本发明的一个实施例中，服务端503，具体用于控制所述决策后引入专科医生端，无权访问所述客户端的用户健康档案。
169.图6示出了可以应用本发明实施例的交互诊疗信息的方法或交互诊疗信息的系统的示例性系统架构600。
170.如图6所示，系统架构600可以包括终端设备601、602、603，网络604和服务器605。网络604用以在终端设备601、602、603和服务器605之间提供通信链路的介质。网络604可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
171.用户可以使用终端设备601、602、603通过网络604与服务器605交互，以接收或发送消息等。终端设备601、602、603上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
172.终端设备601、602、603可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
173.服务器605可以是提供各种服务的服务器，例如对用户利用终端设备601、602、603所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、产品信息
‑‑
仅为示例)反馈给终端设备。
174.需要说明的是，本发明实施例所提供的交互诊疗信息的方法一般由服务器605执行，相应地，交互诊疗信息的系统一般设置于服务器605中。
175.应该理解，图6中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
176.下面参考图7，其示出了适于用来实现本发明实施例的终端设备的计算机系统700的结构示意图。图7示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
177.如图7所示，计算机系统700包括中央处理单元(cpu)701，其可以根据存储在只读存储器(rom)702中的程序或者从存储部分708加载到随机访问存储器(ram)703中的程序而执行各种适当的动作和处理。在ram 703中，还存储有系统700操作所需的各种程序和数据。cpu 701、rom 702以及ram 703通过总线704彼此相连。输入/输出(i/o)接口705也连接至总线704。
178.以下部件连接至i/o接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至i/o接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。
179.特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(cpu)701执行时，执行本发明的系统中限定的上述功能。
180.需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。
181.附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代
表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
182.描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括客户端、全科医生端、服务端和专科医生端；其中，这些名称在某种情况下并不构成对其本身的限定，例如，客户端还可以被描述为“用于向客户端的全科医生端发送诊疗请求”。
183.作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：
184.客户端向所述客户端的全科医生端发送诊疗请求；
185.所述全科医生端响应所述诊疗请求，在确定需要引入专科医生服务的情况下，由服务端通过知识图谱，推荐一个或多个专科医生至所述全科医生端，供全科医生决策或由所述全科医生端转发至所述客户端决策；
186.全科对应关系中的全科医生端和专科对应关系中的专科医生端，共享所述客户端的用户健康档案，所述全科对应关系是由所述服务端建立的所述客户端与所述全科医生端的对应关系，所述专科对应关系是由所述服务端建立的所述客户端与决策后引入专科医生端的对应关系；
187.所述服务端响应所述专科医生端的诊疗结果，更新所述全科对应关系和所述专科对应关系。
188.根据本发明实施例的技术方案，客户端向所述客户端的全科医生端发送诊疗请求；所述全科医生端响应所述诊疗请求，在确定需要引入专科医生为客户服务的情况下，由服务端通过知识图谱，推荐一个或多个专科医生至所述全科医生端，供全科医生决策或由所述全科医生端转发至所述客户端决策；全科对应关系中的全科医生端和专科对应关系中的专科医生端，共享所述客户端的用户健康档案，所述全科对应关系是由所述服务端建立的所述客户端与所述全科医生端的对应关系，所述专科对应关系是由所述服务端建立的所述客户端与决策后引入专科医生端的对应关系；所述服务端响应所述专科医生端的诊疗结果，更新所述全科对应关系和所述专科对应关系。属于对应关系的医生端能够共享用户健康档案，避免客户与医生多次重复交互诊疗信息，进而提高信息沟通效率。
189.上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。