基于公众号的智慧病历应用系统及方法与流程

本申请涉及数据处理技术领域，尤其涉及基于公众号的智慧病历应用方法、装置及计算机可读介质。

背景技术：

患者去医院看病，医院可以通过医疗系统记录和管理患者的就诊记录，还能通过医疗系统记录医院的药物、病房等资源的利用情况。医疗行业的发展直接关系到人们的生活质量，然而医疗行业的发展不仅需要医疗技术的推进，还需要医疗系统的进一步完善。

现有技术中，患者需要进行看病预约、病历查询、影像资料获取，可以通过微信公众号的形式进行获取，但是现有技术中存在一个弊端，如果要获取某医院看病的病历资料，只能在其医院的微信公众号进行获取，而不能从其他医院的微信公众号进行获取，因此，不利于使用也不方便，因此，微信公众号的使用效率较低。而对于平台类的看病平台，可以跨医院进行预约，但是病历数据保密性较强，相互医院之间并不能共享，同样不利于使用。

技术实现要素：

本申请实施例提供一种基于公众号的智慧病历应用系统及方法，用于解决通过微信公众号形式实现跨医院之间不能进行病历数据共享的问题，提升了数据安全性的同时，提升用户使用效率。

在一个实施例中的基于公众号的智慧病历应用系统，包括：

医疗终端，用于采集病历数据，并将采集的所述病历数据上传至内网服务器；

内网服务器，用于存储所述医疗终端上传的所述病历数据，并将所述病历数据发送至堡垒云服务器；

堡垒云服务器，用于接收并存储所述内网服务器发送的所述病历数据，在检测到推送指令的情况下，将根据所述病历数据和所述推送指令生成的推送数据以公众号形式发送给用户终端，并通过禁止协议禁止向所述内网服务器发送数据。

在本申请提供的实施例中，所述内网服务器包括第一内网服务器和第二内网服务器；

所述第一内网服务器用于存储所述医疗终端上传的病历数据，并将所述病历数据发送至第二内网服务器；

所述第二内网服务器用于备份所述第一内网服务器发送病历数据，并将所述病历数据发送至所述堡垒云服务器；

所述第二内网服务器包括第二内网指定服务器，所述堡垒云服务器只接收所述第二内网指定服务器发送的病历数据。

在本申请提供的实施例中，所述第一内网服务器还用于对所述病历数据进行处理；第二内网服务器还用于在所述第一内网服务器处理所述病历数据超负荷的情况下，对所述病历数据进行并发处理。

在本申请提供的实施例中，在将根据所述病历数据和所述推送指令生成的推送数据通过公众号形式发送给用户终端，还包括：

设置公众号公网服务器，将所述堡垒云服务器的数据经过解密操作后，发送至所述公众号公网服务器，以便将推送数据通过公众号形式发送给用户终端。

在本申请提供的实施例中，所述设置公众号公网服务器，将所述堡垒云服务器的数据经过解密操作后，发送至所述公众号公网服务器，以便将推送数据通过公众号形式发送给用户终端，包括：

设置堡垒云服务器与所述公众号公网服务器的加密验证过程；

处理用户在用户终端推送过来的查询消息，所述查询消息为xml格式；

提取该xml格式的查询消息，并将该消息通过加密验证过程透发至堡垒云服务器；

所述堡垒云服务器判断该查询消息的权限，若满足预设条件，则将查询结果发送至公众号公网服务器，以使所述公众号公网服务器推送数据至所述用户终端。

在本申请提供的实施例中，所述设置堡垒云服务器与所述公众号公网服务器的加密验证过程，包括：

设置多个参数的字典序排序，所述多个参数包括令牌token、时间戳timestamp及随机数nonce；

将所述多个参数拼接成一个字符串进行sha1加密；

将加密后的字符串与预先设置的数字签名进行比对，若比对成功则验证成功，否则验证失败。

在本申请提供的实施例中，处理用户在用户终端推送过来的查询消息，所述查询消息为xml格式，包括：

使用get函数获取所述用户终端推送的查询消息，所述查询消息通过post方式推送，所述查询消息中包含用户姓名、id、消息创建时间及查询内容，所述查询消息为xml格式。

在本申请提供的实施例中，所述堡垒云服务器判断该查询消息的权限，若满足预设条件，则将查询结果发送至公众号公网服务器，包括：

所述堡垒云服务器将所述查询消息中的id进行权限匹配，获取所述id对应的权限；

当所述权限通过验证后，将所述查询结果发送至所述公众号公网服务器。

在本申请提供的实施例中，所述将所述查询消息中的id进行权限匹配，包括：

根据所述查询消息中的id，获取所述id对应的角色role参数；

遍历所述堡垒云服务器遍历集合中的所有角色，判断所述id对应的角色是否与所述所有角色中其中任一个角色匹配；

若是，判断当前匹配的角色权限是否为数据收发权限，若是，确认所述查询消息通过验证。

在本申请提供的实施例中的基于公众号的智慧病历应用方法，包括：

通过医疗终端采集病历数据，并将采集的所述病历数据上传至内网服务器；

通过内网服务器存储所述医疗终端上传的所述病历数据，并将所述病历数据发送至堡垒云服务器；

通过堡垒云服务器接收并存储所述内网服务器发送的所述病历数据，在检测到推送指令的情况下，将根据所述病历数据和所述推送指令生成的推送数据发送给用户终端，并通过禁止协议禁止向所述内网服务器发送数据。

在本申请提供的实施例中，所述内网服务器包括第一内网服务器和第二内网服务器；

所述通过内网服务器存储所述医疗终端上传的所述病历数据，并将所述病历数据发送至堡垒云服务器，包括：

通过所述第一内网服务器存储所述医疗终端上传的所述病历数据，并将所述病历数据发送至第二内网服务器；

通过所述第二内网服务器备份所述第一内网服务器发送所述病历数据，并将所述病历数据发送至所述堡垒云服务器；

所述第二内网服务器包括第二内网指定服务器，所述堡垒云服务器只接收所述第二内网指定服务器发送的病历数据。

在本申请提供的实施例中，所述堡垒云服务器在检测到推送指令的情况下，将根据所述病历数据和所述推送指令生成的推送数据发送给用户终端，包括：

所述堡垒云服务器在检测到推送指令的情况下，根据所述病历数据和所述推送指令生成推送数据，将所述推送数据发送至通信服务器，通过所述通信服务器将所述病历数据发送至所述用户终端。

上述基于公众号的智慧病历应用系统及方法，可以通过医疗终端采集病历数据，并将病历数据上传到内网服务器进行存储。内网服务器可以将病历数据发送到堡垒云服务器，通过堡垒云服务器实现与外网设备的通信，同时通过公众号形式展现给用户终端。一方面，以病人为中心，将该病人不同医院的病历数据进行整合，方便用户通过公众号形式使用。另一方面，通过堡垒云独有的数据保密机制，确保不同医院数据无法进行暴力破坏，从而保证了数据的安全性与私密性。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍。

图1为一个实施例中基于公众号的智慧病历应用系统的结构示意图。

图2为另一个实施例中基于公众号的智慧病历应用系统的结构示意图。

图3为一个实施例中基于公众号的智慧病历应用方法的流程示意图。

图4为一个实施例中电子设备的流程示意图。

具体实施方式

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

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

图1为一个实施例中基于公众号的智慧病历应用系统的结构示意图。本实施例中的基于公众号的智慧病历应用系统包括医疗终端102、内网服务器104和堡垒云服务器106。具体的：

医疗终端102，用于采集病历数据，并将采集的所述病历数据上传至内网服务器104；内网服务器104，用于存储所述医疗终端上传的所述病历数据，并将所述病历数据发送至堡垒云服务器106；堡垒云服务器106，用于接收并存储所述内网服务器发送的所述病历数据，在检测到推送指令的情况下，将根据所述病历数据和所述推送指令生成的推送数据通过公众号形式发送给用户终端，并通过禁止协议禁止向所述内网服务器发送数据。

可以理解的是，上述实施例中，医疗终端可以分布在不同医院，包括中心医院、下属医院及各县、乡级医院；内网服务器和堡垒云服务器可作为不同医院共享的服务器。医疗终端可以是与医生交互用于输入患者就诊记录的终端，还可以是用于录入药品资源管理数据的终端，还可以是记录病房占用情况的终端，在此不做限定。也即医疗终端用于采集病历数据，病历数据一般是指医院运作过程中所产生的数据，可以但不限于是患者就诊数据、药品资源数据、病房资源数据等，患者的就诊数据可以包括临床影像数据，比如患者的放射、超声、内镜、检验、心电、病理和手术录像等。通过医疗终端输入病历数据，服务器可以对病历数据进行存储和管理。病历数据可以是结构化数据或者非结构化数据，可以分布式存储在服务器上。

例如，医疗终端可以输入一个查看病历数据的请求到服务器，然后服务器再根据医疗终端的请求查询相应的输入，并返回给医疗终端进行查看。医疗终端还可以输入删除病历数据的请求，服务器接收到该删除请求之后，就对该删除请求所指示的病历数据进行删除操作。

在本申请提供的实施例中，用于管理病历数据的服务器包括内网服务器和堡垒云服务器。其中，内网服务器分别与医疗终端、堡垒云服务器相连，内网服务器可以直接接收医疗终端上传的病历数据。内网服务器在接收到病历数据之后，会将接收到的病历数据进行存储。医疗终端可以对内网服务器存储的病历数据进行修改、查询、删除等操作。

需要说明的是，这里的内网服务器和医疗终端相连，医疗终端可以部署在不同医院的不同科室。由于内网服务器不能被外网访问，所以在部署内网服务器的时候，可以以医院为单位，针对每一个医院部署一个或多个内网服务器。同一个医院部署的医疗终端可以连接到该医院的内网服务器。

在本申请提供的实施例中，堡垒云服务器与内网服务器相连，堡垒云服务器用于与医院外界的设备通信，以保证内网服务器的安全。具体的，内网服务器和堡垒云服务器是单向的，内网服务器可以向堡垒云服务器发送数据，但是堡垒云服务器无法向内网服务器发送数据。在其中一个实施例中，堡垒云服务器可以通过硬件或软件的禁止协议来禁止向内网服务器上发送数据，不限于此。

内网服务器可以定时向堡垒云服务器发送数据，也可以不定时地向堡垒云服务器发送数据。例如，当内网服务器上新增的病历数据超过一定的数据量时，向堡垒云服务器推送新增的病历数据，或者当内网服务器的运行负载比较小的时候，向堡垒云服务器推送病历数据，在此不做限定。

堡垒云服务器在接收到内网服务器发送的病历数据之后，会将接收到的病历数据进行存储，以防止病历数据的丢失。堡垒云服务器可以与外网设备进行通信，例如，患者可以通过患者终端向堡垒云服务器发送数据查询请求，堡垒云服务器查询到相应的数据之后发送给患者终端。院外专家也可以通过专家终端向堡垒云服务器发送请求，堡垒云服务器根据该请求处理后得到的数据再返回给专家终端。堡垒云服务器还可以主动向用户终端发送数据。

可见，堡垒云服务器可以在检测到推送指令的情况下，根据病历数据生成推送数据。该推动指令可以是外网设备发送的，也可以是内网服务器发送的，还可以是堡垒云服务器在设备触发条件的情况下满足触发条件时自动生成的，在此不做限定。

在本发明实施例中，所有与用户终端交互的入口都是医院的微信公众号而不是app。目前很多app都实现了预约超声或放射检查的功能，但是这些预约是需要院内有处方权的医生审批的；本发明实施例提供的系统则通过公众号处理的是不同医院的院内门诊和住院科室超声或放射检查的单子处理量，从数量和性质上有本质的区别。科室开出的单子会与院内pacs做对接，以简易的流程来改善就医体验。

本发明实施例中，将通过设置公众号公网服务器，将堡垒云服务器的数据经过解密操作后，发送至所述公众号公网服务器，以便将推送数据通过公众号形式发送给用户终端。现有技术中，堡垒云服务器处于私网领域，而公众号服务器是第三方提供的、直接面向用户端的公网服务器，因此，如何打通私网和公网，并保证数据的安全与私密性将会是一个难题，也是与传统的微信公众号后台开发的区别。

上述的公众号建立与发送接收流程，具体为：

a.设置堡垒云服务器与所述公众号公网服务器的加密验证过程，其中，加密验证过程可以为：设置多个参数的字典序排序，所述多个参数包括令牌token、时间戳timestamp及随机数nonce；将所述多个参数拼接成一个字符串进行sha1加密；将加密后的字符串与预先设置的数字签名(digitalsignature)进行比对，若比对成功则验证成功，否则验证失败；

b.处理用户在用户终端推送过来的查询消息，查询消息为xml格式，其中，在确定url地址正确性的前提下，可以采用公众号常用的get函数获取用户终端推送的查询消息，为了规范操作，查询消息具备xml格式，并通过post方式推送，查询消息中包含用户姓名、id、消息创建时间及查询内容，查询内容可以为获取病历、获取影像资料等；

c.提取该xml格式的查询消息，并将该消息通过加密验证过程透发至堡垒云服务器，其中，在获取到查询消息后，需要提取xml格式中的各类参数信息，具体可通过微信开发者sdk框架提供的controller函数进行xml格式的提取；

d.堡垒云服务器106判断该查询消息的权限，若满足预设条件，则将查询结果发送至公众号公网服务器，以使公众号公网服务器推送数据至所述用户终端，其中，堡垒云服务器可通过查询消息中的id进行权限匹配，并获取所述id对应的权限，堡垒云服务器可根据获取角色role的方式进行权限验证，角色是在权限处理中的一种常用技术，不同id可以具备同一个角色，一个id也可以具备不同的角色，不同角色在角色集合中的分配到的权限是不同的，以本发明实施例为例，可以分为禁止获取任何资料、获取病历资料、获取影像资料、获取医生信息等不同的权限，根据相应的权限进行不同的分配操作。具体地，根据所述查询消息中的id，获取所述id对应的角色role参数；遍历所述堡垒云服务器遍历集合中的所有角色，判断所述id对应的角色是否与所述所有角色中其中任一个角色匹配；若是，判断当前匹配的角色权限是否为数据收发权限，若是，确认所述查询消息通过验证；当所述权限通过验证后，将所述查询结果发送至所述公众号公网服务器。

另，本发明实施例中，还可以根据当前院内门诊和住院科室超声或放射检查的单子处理量，通过神经网络模型预测未来处理量，并将所述未来处理量以公众号的形式发送给用户终端。其中，通过神经网络模型预测未来处理量，具体可以为：

本发明实施例中，将当前处理量，医院平均处理时间及医生人数作为张量数据，输入到预测计算网络。预测计算网络采用卷积神经网络和非线性回归分析算法，网络结构包含三个卷积层，分别提取上述三类输入参数的特征，其后紧跟若干全连接网络。系统利用历史采集到的参数数据进行模型训练。

系统通过利用当前处理量数据输入预测计算网络，然后通过训练学习算法计算未来工作时长y与多变量(即输入参数x)之间的关系，从而获得训练一个网络模型y＝f(x)。然后利用当前采集到的数据进行非线性回归分析，计算出节点预测工作时长，即利用当前的输入参数x，输入到训练网络模型y＝h(x)，回归计算出预测的工作时长y。

考虑用户各自的痛点，智慧病历ris不但解决院内的医技流程，也可以为区域医疗提供远程检查的绿色通道。中心医院的设备得到区域内充分的利用，也节省了下属医院购买大型检查设备的资源。此外，可以为外部挂号app提供服务号的认证api，成为一个小程序来启动，共享医院的现有公众号。

上述基于公众号的智慧病历应用系统及方法，可以通过医疗终端采集病历数据，并将病历数据上传到内网服务器进行存储。内网服务器可以将病历数据发送到堡垒云服务器，通过堡垒云服务器实现与外网设备的通信，同时通过公众号形式展现给用户终端。一方面，以病人为中心，将该病人不同医院的病历数据进行整合，方便用户通过公众号形式使用。另一方面，通过堡垒云独有的数据保密机制，确保不同医院数据无法进行暴力破坏，从而保证了数据的安全性与私密性。

在本申请提供的另一个实施例中，如图2所示，所述内网服务器104包括第一内网服务器1040和第二内网服务器1042；所述第一内网服务器1040用于存储所述医疗终端上传的病历数据，并将所述病历数据发送至第二内网服务器1042；所述第二内网服务器1042用于备份所述第一内网服务器1040发送病历数据，并将所述病历数据发送至所述堡垒云服务器106；所述第二内网服务器包括第二内网指定服务器，所述堡垒云服务器只接收所述第二内网指定服务器发送的病历数据。

具体的，通过第一内网服务器与医疗终端实现数据通信，接收第一内网服务器发送的病历数据，同时第一内网服务器可以对接收到的病历数据进行存储。第二内网服务器实现对病历数据的备份，第一内网服务器接收到病历数据之后，可以将接收到的病历数据发送给第二内网服务器进行备份，以保证病历数据的安全性，防止病历数据的丢失。

第二内网服务器可以与堡垒云服务器进行通信，通过第二内网服务器想堡垒云服务器发送病历数据。进一步地，第二内网服务器可以包括第二内网指定服务器，堡垒云服务器只接收第二内网指定服务器发送的病历数据，不能接收其他设备发送的病历数据，以保证数据通信的安全性。

在本申请提供的一个实施例中，所述第一内网服务器还用于对所述病历数据进行处理；第二内网服务器还用于在所述第一内网服务器处理所述病历数据超负荷的情况下，对所述病历数据进行并发处理。

其中，第一内网服务器可以对病历数据进行处理。例如，对病历数据进行压缩处理，或者通过病历数据进行深度学习等，不限于此。当第一内网服务器处理病历数据超负荷的情况下，可以通过第二内网服务器进行并发处理。通过第二内网服务器进行并发处理，可以分担第一内网服务器处理病历数据的压力，提高数据处理的效率。

在本申请提供的一个实施例中，堡垒云服务器106向用户终端108推送数据的步骤具体可以包括：所述堡垒云服务器106在检测到推送指令的情况下，根据所述病历数据和所述推送指令生成推送数据，将所述推送数据发送至通信服务器，通过所述通信服务器将所述病历数据发送至所述用户终端108。

用户终端和堡垒云服务器之间可以通过第三方的通信服务器来实现。例如，用户终端可以安装可实现通信的应用程序(app，application)，该应用程序作为用户发起请求的接口，用户终端可以将用户发起的请求发送给通信服务器，通过通信服务器实现与堡垒云服务器的通信。具体的，该应用程序可以是如微信公众号、支付宝等实现社交通信的应用程序，不限于此。

可以理解的是，用户终端通过第三方平台实现与堡垒云服务器的通信时，需通过第三方平台的通信服务器进行数据交互。堡垒云服务器可以主动向用户终端推送数据，用户终端也可以主动向堡垒云服务器发起获取数据的请求。在一种应用场景下，专家医生可以和患者通过微信公众号提供的聊天接口进行对话，当专家医生或患者想查看病历数据的时候，就可以发起获取病历数据的请求。

具体的，所述堡垒云服务器还用于接收通信服务器发送的推送指令，其中，所述推送指令是所述通信服务器根据数据请求生成的，所述数据请求是所述用户终端发送给所述通信服务器的，所述推送指令中包括所述用户终端的用户标识；则堡垒云服务器向用户终端推送数据的步骤包括：所述堡垒云服务器获取与所述推送指令中包含的用户标识相关联的目标医院标识，获取所述目标医院标识对应的病历数据作为推送数据，将所述推送数据发送至所述通信服务器，通过所述通信服务器将所述病历数据发送至所述用户终端，其中，所述堡垒云服务器上存储的所述病历数据与医院标识对应，所述医院标识用于标记生成上传病历数据的医疗终端所在的医院。

在一个实施例中，可以预先建立用户和医院的关联关系，例如用户注册自己的用户标识，若患者用户去某个医院就诊过，就将该用户的用户标识和该医院的医院标识建立关联。这样堡垒云服务器就可以主动地向用户标识对应的用户终端主动推送相关联的医院的推送数据。可以减少用户终端主动请求获取数据时，集中访问堡垒云服务器以造成堡垒云服务器的压力过大。

医疗终端在上传病历数据的时候，会同步上传医院标识，然后与医院标识关联存储。这样就可以知道病历数据对应是由哪一间医院所产生的。具体的，所述堡垒云服务器上存储的所述病历数据与医院标识对应。则堡垒云服务器向用户终端推送数据的步骤具体可以包括：所述堡垒云服务器获取所存储的病历数据的数据量，在所述数据量大于阈值的情况下生成推送指令；所述堡垒云服务器在检测到推送指令的情况下，获取所述数据量与所述阈值的差值，根据所述差值确定删除等级，根据所述删除等级相关联的医院标识从所述病历数据中获取推送数据，并将所述推送数据发送至通信服务器，通过所述通信服务器将所述病历数据发送至所述用户终端；在所述堡垒云服务器接收到所述通信服务器发送的删除指令的情况下，删除所述堡垒云服务器上存储的所述删除指令所指示的病历数据，其中，所述删除指令是由所述用户终端在接收到所述推送数据的情况下发送给所述通信服务器的。

在一个实施例中，堡垒云服务器可以实时统计存储的病历数据的数据量，当存储的病历数据的数据量大于阈值的时候，说明堡垒云服务器上存储的病历数据过量，这时可以生成一个推送指令，指示堡垒云服务器向用户终端发送推送数据。具体的，由于堡垒云服务器上存储了很多个医院的病历数据，因此堡垒云服务器可以根据数据量与阈值的差值来决定删除哪些病历数据。

在本申请提供的其中一个实施例中，可以根据数据量有阈值的差值来确定删除等级，然后根据预先建立的删除等级与医院标识的关联关系确定该删除等级所关联的医院标识，然后获取该医院标识对应的病历数据作为推送数据发送用户终端。在推送数据的时候，也可以将生成的推送数据发送给医疗标识相关联的用户标识所在的用户终端。

用户终端在接收到推送数据之后，会向堡垒云服务器返回一个删除指令，用于指示堡垒云服务器将已接收的数据进行删除。这样可以减少堡垒云服务器的存储压力。

在本申请提供的一个实施例中，堡垒云服务器向用户终端推送数据的步骤具体可以包括：所述堡垒云服务器在检测到推送指令的情况下，获取所述数据量与所述阈值的差值，根据所述差值确定删除等级，根据所述删除等级相关联的医院标识对所述病历数据生成第一权重；所述堡垒云服务器获取所存储的病历数据的生成时间，根据所述生成时间生成所述病历数据的第二权重；所述堡垒云服务器根据所述第一权重和第二权重从所述病历数据中获取推送数据，并将所述推送数据发送至通信服务器，通过所述通信服务器将所述病历数据发送至所述用户终端。

也即，堡垒云服务器在删除病历数据的时候，可以考虑医院标识和生成时间等两个因素。预先将医院分成不同的等级以表示医院所产生的病历数据的重要性，从而根据医院标识得到病历数据的第一权重。另外，可以根据病历数据的生成时间得到病历数据的第二权重，由第一权重和第二权重获得需要推送的推送数据。堡垒云服务器实时检测病历数据的数据量，向用户终端推送数据之后删除，可以保证堡垒云服务器的高效运行，防止资源被过度占用。

图3为一个实施例中的基于公众号的智慧病历应用方法，包括：

步骤302，通过医疗终端采集病历数据，并将采集的所述病历数据上传至内网服务器；

步骤304，通过内网服务器存储所述医疗终端上传的所述病历数据，并将所述病历数据发送至堡垒云服务器；

步骤306，通过堡垒云服务器接收并存储所述内网服务器发送的所述病历数据，在检测到推送指令的情况下，将根据所述病历数据和所述推送指令生成的推送数据以公众号形式发送给用户终端，并通过禁止协议禁止向所述内网服务器发送数据。

本实施例提供的基于公众号的智慧病历应用方法，可以通过医疗终端采集病历数据，并将病历数据上传到内网服务器进行存储。内网服务器可以将病历数据发送到堡垒云服务器，通过堡垒云服务器实现与外网设备的通信。一方面，通过堡垒云服务器与外网设备进行通信，分担了内网服务器的运行压力，提高了运行效率。另一方面，禁止堡垒云服务器向内网服务器发送数据，保证了内网服务器的安全性，提高了医疗系统的安全性。

在一个实施例中，所述内网服务器包括第一内网服务器和第二内网服务器；所述通过内网服务器存储所述医疗终端上传的所述病历数据，并将所述病历数据发送至堡垒云服务器，包括：通过所述第一内网服务器存储所述医疗终端上传的所述病历数据，并将所述病历数据发送至第二内网服务器；通过所述第二内网服务器备份所述第一内网服务器发送所述病历数据，并将所述病历数据发送至所述堡垒云服务器；所述第二内网服务器包括第二内网指定服务器，所述堡垒云服务器只接收所述第二内网指定服务器发送的病历数据。

在一个实施例中，所述第一内网服务器还用于对所述病历数据进行处理；第二内网服务器还用于在所述第一内网服务器处理所述病历数据超负荷的情况下，对所述病历数据进行并发处理。

在一个实施例中，所述堡垒云服务器在检测到推送指令的情况下，将根据所述病历数据和所述推送指令生成的推送数据发送给用户终端，包括：所述堡垒云服务器在检测到推送指令的情况下，根据所述病历数据和所述推送指令生成推送数据，将所述推送数据发送至通信服务器，通过所述通信服务器将所述病历数据发送至所述用户终端。

在本申请提供的一个实施例中，上述基于公众号的智慧病历应用方法还包括：所述堡垒云服务器接收通信服务器发送的推送指令，其中，所述推送指令是所述通信服务器根据数据请求生成的，所述数据请求是所述用户终端发送给所述通信服务器的，所述推送指令中包括所述用户终端的用户标识；所述堡垒云服务器发送推送数据至所述用户终端的步骤，包括：通过所述堡垒云服务器获取与所述推送指令中包含的用户标识相关联的目标医院标识，获取所述目标医院标识对应的病历数据作为推送数据，将所述推送数据发送至所述通信服务器，通过所述通信服务器将所述病历数据发送至所述用户终端，其中，所述堡垒云服务器上存储的所述病历数据与医院标识对应，所述医院标识用于标记生成上传病历数据的医疗终端所在的医院。

在其中一个实施例中，所述堡垒云服务器上存储的所述病历数据与医院标识对应；所述堡垒云服务器在检测到推送指令的情况下，根据所述病历数据和所述推送指令生成推送数据，将所述推送数据发送至通信服务器，通过所述通信服务器将所述病历数据发送至所述用户终端，包括：通过所述堡垒云服务器获取所存储的病历数据的数据量，在所述数据量大于阈值的情况下生成推送指令；在检测到推送指令的情况下，获取所述数据量与所述阈值的差值，根据所述差值确定删除等级，根据所述删除等级相关联的医院标识从所述病历数据中获取推送数据，并将所述推送数据发送至通信服务器，通过所述通信服务器将所述病历数据发送至所述用户终端；在所述堡垒云服务器接收到所述通信服务器发送的删除指令的情况下，删除所述堡垒云服务器上存储的所述删除指令所指示的病历数据，其中，所述删除指令是由所述用户终端在接收到所述推送数据的情况下发送给所述通信服务器的。

在一个实施例中，所述堡垒云服务器在检测到推送指令的情况下，获取所述数据量与所述阈值的差值，根据所述差值确定删除等级，根据所述删除等级相关联的医院标识从所述病历数据中获取推送数据，并将所述推送数据发送至通信服务器，通过所述通信服务器将所述病历数据发送至所述用户终端，包括：所述堡垒云服务器在检测到推送指令的情况下，获取所述数据量与所述阈值的差值，根据所述差值确定删除等级，根据所述删除等级相关联的医院标识对所述病历数据生成第一权重；获取所存储的病历数据的生成时间，根据所述生成时间生成所述病历数据的第二权重；根据所述第一权重和第二权重从所述病历数据中获取推送数据，并将所述推送数据发送至通信服务器，通过所述通信服务器将所述病历数据发送至所述用户终端。

在本发明实施例中，所有与用户终端交互的入口都是医院的微信公众号而不是app。目前很多app都实现了预约超声或放射检查的功能，但是这些预约是需要院内有处方权的医生审批的；本发明实施例提供的系统则通过公众号处理的是不同医院的院内门诊和住院科室超声或放射检查的单子处理量，从数量和性质上有本质的区别。科室开出的单子会与院内pacs做对接，以简易的流程来改善就医体验。

在其中一个实施例中，堡垒云服务器将通过设置公众号公网服务器，将堡垒云服务器的数据经过解密操作后，发送至所述公众号公网服务器，以便将推送数据通过公众号形式发送给用户终端。现有技术中，堡垒云服务器处于私网领域，而公众号服务器是第三方提供的、直接面向用户端的公网服务器，因此，如何打通私网和公网，并保证数据的安全与私密性将会是一个难题，也是与传统的微信公众号后台开发的区别。

上述的公众号建立与发送接收流程，具体为：

a.设置堡垒云服务器与所述公众号公网服务器的加密验证过程，其中，加密验证过程可以为：设置多个参数的字典序排序，所述多个参数包括令牌token、时间戳timestamp及随机数nonce；将所述多个参数拼接成一个字符串进行sha1加密；将加密后的字符串与预先设置的数字签名(digitalsignature)进行比对，若比对成功则验证成功，否则验证失败；

b.处理用户在用户终端推送过来的查询消息，查询消息为xml格式，其中，在确定url地址正确性的前提下，可以采用公众号常用的get函数获取用户终端推送的查询消息，为了规范操作，查询消息具备xml格式，并通过post方式推送，查询消息中包含用户姓名、id、消息创建时间及查询内容，查询内容可以为获取病历、获取影像资料等；

c.提取该xml格式的查询消息，并将该消息通过加密验证过程透发至堡垒云服务器，其中，在获取到查询消息后，需要提取xml格式中的各类参数信息，具体可通过微信开发者sdk框架提供的controller函数进行xml格式的提取；

d.堡垒云服务器106判断该查询消息的权限，若满足预设条件，则将查询结果发送至公众号公网服务器，以使公众号公网服务器推送数据至所述用户终端，其中，堡垒云服务器可通过查询消息中的id进行权限匹配，并获取所述id对应的权限，堡垒云服务器可根据获取角色role的方式进行权限验证，角色是在权限处理中的一种常用技术，不同id可以具备同一个角色，一个id也可以具备不同的角色，不同角色在角色集合中的分配到的权限是不同的，以本发明实施例为例，可以分为禁止获取任何资料、获取病历资料、获取影像资料、获取医生信息等不同的权限，根据相应的权限进行不同的分配操作。具体地，根据所述查询消息中的id，获取所述id对应的角色role参数；遍历所述堡垒云服务器遍历集合中的所有角色，判断所述id对应的角色是否与所述所有角色中其中任一个角色匹配；若是，判断当前匹配的角色权限是否为数据收发权限，若是，确认所述查询消息通过验证；当所述权限通过验证后，将所述查询结果发送至所述公众号公网服务器。

可以理解的是，图4仅仅示出了电子设备的简化设计。在实际应用中，电子设备还可以分别包含必要的其他元件，包含但不限于任意数量的输入/输出装置、处理器、控制器、存储器等，而所有可以实现本申请实施例的基于公众号的智慧病历应用方法的电子设备都在本申请的保护范围之内。

存储器包括但不限于是随机存储记忆体(randomaccessmemory，ram)、只读存储器(read至onlymemory，rom)、可擦除可编程只读存储器(erasableprogrammablereadonlymemory，eprom)、或便携式只读存储器(compactdiscread至onlymemory，cd至rom)，该存储器用于相关指令及数据。

输入装置用于输入数据和/或信号，以及输出装置用于输出数据和/或信号。输出装置和输入装置可以是独立的器件，也可以是一个整体的器件。

处理器可以包括是一个或多个处理器，例如包括一个或多个中央处理器(centralprocessingunit，cpu)，在处理器是一个cpu的情况下，该cpu可以是单核cpu，也可以是多核cpu。处理器还可以包括一个或多个专用处理器，专用处理器可以包括gpu、fpga等，用于进行加速处理。

存储器用于存储网络设备的程序代码和数据。

处理器用于调用该存储器中的程序代码和数据，执行上述方法实施例中的步骤。具体可参见方法实施例中的描述，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统和方法，可以通过其它的方式实现。例如，该单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。所显示或讨论的相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者通过该计算机可读存储介质进行传输。该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digitalsubscriberline，dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是只读存储器(read至onlymemory，rom)，或随机存储存储器(randomaccessmemory，ram)，或磁性介质，例如，软盘、硬盘、磁带、磁碟、或光介质，例如，数字通用光盘(digitalversatiledisc，dvd)、或者半导体介质，例如，固态硬盘(solidstatedisk，ssd)等。

以上上述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。