电子病历的管理方法、服务器及计算机存储介质与流程

文档序号:17188843发布日期:2019-03-22 21:45阅读:315来源:国知局
电子病历的管理方法、服务器及计算机存储介质与流程

本申请涉及区块链技术领域,尤其涉及一种电子病历的管理方法、服务器及计算机存储介质。



背景技术:

病历是医务人员对患者疾病的发生、发展、转归,进行检查、诊断、治疗等医疗活动过程的记录,也是对采集到的资料加以归纳、整理、综合分析,按规定的格式和要求书写的患者医疗健康档案。

随着信息技术的发展,如今各个医院开始采用电子病历方法记录用户的就诊信息,电子病历是用电子设备(计算机、健康卡等)保存、管理、传输和重现的数字化的病人的医疗记录,取代手写纸张病历,可以节省纸张,存储归档更为方便。但是,目前的电子病历存储在用户看病的医院的档案库,若用户更换医生尤其是转院治疗时,不便于重新提供历史病历,之前的病历通常也无效了,造成历史病历信息的资源浪费。



技术实现要素:

本申请实施例提供一种电子病历的管理方法、服务器及计算机存储介质,可以实现电子病历的分享和传输,提高电子病历的管理安全性。

第一方面,本申请实施例提供了一种电子病历的管理方法,应用于服务器,该方法包括:

接收来自需求方的信息获取请求,所述信息获取请求携带需求方身份标识和病历标识;

根据所述需求方身份标识判断所述需求方是否具备存储有电子病历的区块链的访问权限;

若确定所述需求方具备所述区块链的访问权限,则在所述区块链中获取与所述病历标识对应的目标电子病历,向所述需求方发送所述目标电子病历;

生成所述需求方的信息获取记录,存储在所述区块链中。

作为一种可能的实施方式,所述在所述区块链中获取所述病历标识对应的目标电子病历之前,所述方法还包括:

在检测到所述目标电子病历设置有预设获取规则时,按照所述预设获取规则验证所述需求方是否具备所述目标电子病历的访问权限;

若所述需求方具备所述目标电子病历的访问权限,则触发所述在所述区块链中获取所述病历标识对应的目标电子病历的步骤。

作为一种可能的实施方式,所述按照所述预设获取规则验证所述需求方是否具备所述目标电子病历的访问权限包括:

向所述需求方发送第一验证请求,以使所述需求方根据所述第一验证请求发出所述目标电子病历的验证密码;

接收来自所述需求方的所述验证密码,验证所述验证密码与所述目标电子病历的预设密码是否匹配;

若所述验证成功,则触发所述在所述区块链中获取所述病历标识对应的目标电子病历的步骤包括:

若所述验证密码与所述目标电子病历的预设密码匹配,则触发所述在所述区块链中获取所述病历标识对应的目标电子病历的步骤。

作为一种可能的实施方式,所述预设获取规则包括请求确认规则,所述按照所述预设获取规则验证所述需求方是否具备所述目标电子病历的访问权限包括:

向所述目标电子病历的拥有者发送确认请求,所述确认请求包括所述需求方的身份信息,以使所述拥有者对所述需求方的身份信息进行验证;

若接收到来自所述拥有者的验证通过信息,则所述需求方具备所述目标电子病历的访问权限。

作为一种可能的实施方式,所述验证通过信息包括允许访问时间周期,则在所述若接收到来自所述拥有者的验证通过信息,则所述验证成功之后,所述方法还包括:

将所述需求方记入所述拥有者的访问白名单中,以使已记录在所述访问白名单中的需求方在所述允许访问时间周期内能够获取所述目标电子病历。

作为一种可能的实施方式,所述向所述目标电子病历的拥有者发送确认请求之后,所述方法还包括:

若接收到来自所述拥有者的第一拒绝请求,向所述需求方发送验证失败信息,所述验证失败信息用于提示所述需求方未通过所述拥有者的验证,不能获取所述目标电子病历。

作为一种可能的实施方式,所述向所述目标电子病历的拥有者发送确认请求之后,所述方法还包括:

若接收到来自所述拥有者的第二拒绝请求,则将所述需求方记入所述拥有者的访问黑名单中,所述访问黑名单用于管理禁止获取所述拥有者的电子病历的用户。

第二方面,本申请实施例提供了一种服务器,包括:传输模块、身份验证模块、获取模块和生成模块,其中:

所述传输模块,用于接收来自需求方的信息获取请求,所述信息获取请求携带需求方身份标识和病历标识;

所述身份验证模块,用于根据所述需求方身份标识判断所述需求方是否具备存储有电子病历的区块链的访问权限;

所述获取模块,用于若确定所述需求方具备所述区块链的访问权限,则在所述区块链中获取与所述病历标识对应的目标电子病历;

所述传输模块还用于,向所述需求方发送所述目标电子病历;

所述生成模块,用于生成所述需求方的信息获取记录,存储在所述区块链中。

第三方面,本申请实施例还提供了一种服务器,包括:处理器、输入设备、输出设备和存储器,所述处理器、输入设备、输出设备和存储器相互连接,其中,所述存储器用于存储计算机程序,所述计算机程序包括程序指令,所述处理器被配置用于调用所述程序指令,执行如第一方面及其任一种可能的实施方式所述的方法。

第四方面,本申请实施例提供了一种计算机存储介质,所述计算机存储介质存储有计算机程序,所述计算机程序包括程序指令,所述程序指令当被处理器执行时使所述处理器执行上述第一方面及其任一种可能的实施方式的方法。

本申请实施例通过接收来自需求方的信息获取请求,上述信息获取请求携带需求方身份标识和病历标识,根据上述需求方身份标识判断上述需求方是否具备存储有电子病历的区块链的访问权限,若确定上述需求方具备上述区块链的访问权限,则在上述区块链中获取与上述病历标识对应的目标电子病历,向上述需求方发送上述目标电子病历,生成上述需求方的信息获取记录,存储在上述区块链中,可以实现电子病历的分享和传输,提高电子病历的管理安全性。

附图说明

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

图1是本申请实施例提供的一种电子病历的管理方法的流程示意图;

图2是本申请另一实施例提供的一种电子病历的管理方法的流程示意图;

图3是本申请实施例提供的一种服务器的结构示意图;

图4是本申请实施例提供的另一种服务器的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。在本文中提及“实施例”意味着,结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例,也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是,本文所描述的实施例可以与其它实施例相结合。

基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象,而不是用于描述特定顺序。此外,术语“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

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

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

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

区块链的特性有开放、共识、去中心、去信任、透明、双方匿名、不可篡改以及可追溯等。其中,开放与透明意为任何人都可以参与到区块链网络,每一台设备都能作为一个节点,每个节点都允许获得一份完整的数据库拷贝。节点基于一套共识机制,通过竞争计算共同维护整个区块链。任一节点失效,其余节点仍能正常工作。其中,去中心化与去信任意为区块链由众多节点共同组成一个端到端的网络,不存在中心化的设备和管理机构。节点之间数据交换可以通过数字签名技术进行验证,无需互相信任,只要按照系统既定的规则进行,节点之间不能也无法欺骗其他节点。其中,透明与双方匿名意为区块链的运行规则是公开的,所有的数据信息也是公开的,因此每一次数据传输或者访问等都对所有节点可见。由于节点与节点之间是去信任的,因此节点之间无需公开身份,每个参与的节点都是匿名的。

具体的,区块链可以利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算方式。因此,区块链技术不可篡改的特性从根本上改变了中心化的信用创建方式,有效提高了数据的不可更改性以及安全性。其中,由于智能合约使得所有的条款编写为程序,这些条款可在区块链上自动执行,保证了当存在触发智能合约的条件时,区块链能强制根据智能合约中的内容执行,且不受任何外力阻挡,从而保证了合约的有效性和执行力,不仅能够大大降低成本,也能提高效率。区块链上的各个节点都有相同的账本,能够确保账本记录过程是公开透明的。区块链技术可以实现了一种点对点的、公开透明的直接交互,使得高效率、大规模、无中心化代理的信息交互方式成为了现实。

本申请实施例主要可以应用于区块链节点服务器,又称区块链服务器,而作为区块链节点服务器的类型有很多,可以是传统服务器、大型存储系统、台式电脑、笔记本电脑、平板电脑、掌上电脑、智能手机、便携式数字播放器、智能手表以及智能手环等等。其中,区块链节点服务器为根据共识机制确定的区块链网络中的其中一个服务器。应理解,由于区块链是一个去中心化的分布式数据库,所以每次处理数据都需要选出区块链网络中的其中一个服务器作为执行者来处理数据。而每次选取服务器的规则便是共识机制,本申请实施例中共识机制可以是工作量证明机制(proofofwork,pow)、股权证明机制(proofofstake,pos)、瑞波共识机制(rippleconsensus)以及授权股权证明机制(delegatedproofofstake,dpos)等,在此不作限定。本申请实施例中,终端设备包括但不限于带通讯功能的设备、智能手机、平板电脑、笔记本电脑、台式电脑、便携式数字播放器、智能手环以及智能手表等。

为了能够更好地理解本申请实施例,下面将对应用本申请实施例的方法进行介绍。

请参见图1,是本申请实施例提供的一种电子病历的管理方法的示意流程图,本方法可以应用于上述区块链服务器,如图1所示该方法可包括:

101、接收来自需求方的信息获取请求,上述信息获取请求携带需求方身份标识和病历标识。

其中,上述需求方指需要获取电子病历的一方,具体可以理解为可以与区块链服务器通信的任何终端设备,或者为其他区块链节点服务器。本申请实施例中需求方对应的拥有者,指的是上传电子病历进行共享的一方,上传的电子病历可以存储在区块链服务器中,根据前述对区块链的介绍可知,电子病历存储在区块链中,不可篡改和可追溯意为每个甚至多个节点对数据库的修改无法影响其他节点的数据库,除非能控制整个网络中超过51%的节点同时修改,这是几乎不可能发生的,保障了电子病历的安全性。

上述需求方可以是医院或者保险公司,在可选的实施例中也可以是个人用户,同时,上述拥有者也可以通过终端设备在区块链中随时获取自己的电子病历。需求方可以通过终端设备发起上述信息获取请求,区块链服务器可以接收需求方的信息获取请求。

其中,上述信息获取请求携带需求方身份标识和病历标识,该病历标识用于识别该信息获取请求需要获取的对象,即可以通过该病历标识确定需要获取的目标电子病历,可以为电子病历编号,即在区块链中存储的每一份电子病历都有唯一的用于管理的编号。上述需求方身份标识可以理解为某用户的用户信息,可以为用户姓名、用户账号或者身份证号等,也在接收到来自需求方的信息获取请求之后可以执行步骤102。

102、根据上述需求方身份标识判断上述需求方是否具备存储有电子病历的区块链的访问权限。

在接收到上述信息获取请求之后,区块链服务器可以首先判断上述需求方在区块链中是否具备存储有电子病历的区块链的访问权限,具体的,可以对上述需求方进行身份认证,确认上述需求方可以访问该区块链,再执行后续步骤。其中,上述身份认证方式可通过面部识别、密码验证或者其他有效证件验证完成,比如,若个人用户(可以是目标电子病历的所有者也可以不是)想通过终端设备获取目标电子病历,则需要该用户登录自己的用户账号,区块链服务器可以获取该用户的身份信息,比如使用该用户账号注册时存储的个人基本信息,确认该用户可以访问区块链,才能获取到目标电子病历。若上述需求方的身份认证通过,则在该区块链中具备上述访问权限,区块链服务器可以向上述需求方提供目标电子病历查看。

若上述需求方不具备上述访问权限,不执行步骤103,可以执行步骤104。

可选的,上述访问权限也可以是在账号注册时通过身份认证后获得的,即在该区块链中的智能合约可以规定了通过指定验证的账号可以获得上述访问权限,即能够访问该区块链,获取区块链中共享的各种信息。

若上述需求方具备上述访问权限,可以执行步骤103。

103、在上述区块链中获取与上述病历标识对应的目标电子病历,向上述需求方发送上述目标电子病历,向上述需求方发送上述目标电子病历。

具体的,在上述需求方具备上述访问权限时,区块链服务器可以获取上述信息获取请求中的病历标识。在区块链中登记的拥有者在上传电子病历到区块链中时,可以分配上述病历标识(例如用户id),以方便管理和识别身份,通过上述病历标识可以确定对应的拥有者,查找到该用户的电子病历(一个用户账号可以有一份或者多份电子病历,可以通过编号进行区分)。在区块链中可以将病历标识与电子病历的对应关系以表格的形式存储,因此可以在已获得上述病历标识的情况下,根据上述病历标识与电子病历的对应关系,快速查找到该病历标识对应的电子病历,即目标电子病历。在获取到上述目标电子病历之后,可以向需求方发送包含上述目标电子病历的目标数据。

可选的,上述目标电子病历的病历数据可以为包含目标电子病历的压缩包,传输上述压缩后的数据可以提高数据传输速度,节省带宽。

104、生成上述需求方的信息获取记录,存储在上述区块链中。

具体的,在每一次有需求方对目标电子病历进行获取时,都可以生成信息获取记录,即将本次需求方对目标电子病历的查询记录存储在区块链中,上述信息获取记录可以包括需求方的身份信息、上述信息获取请求的发起时间、还可以记录获取结果,比如获取成功、获取失败(以及获取失败的原因)等信息。以公开化的方式,可以便于查看有哪些用户获取过该目标电子病历,进一步提高了电子病历的安全性。

本申请实施例通过接收来自需求方的信息获取请求,上述信息获取请求携带病历标识,判断上述需求方在区块链中是否具备访问权限,若上述需求方在上述区块链中具备访问权限,在上述区块链中获取上述病历标识对应的目标电子病历,再向上述需求方发送包含上述目标电子病历的目标数据,并且生成所述需求方的信息获取记录,存储在所述区块链中,可以实现电子病历的分享和传输,提高电子病历的管理安全性。

请参阅图2,图2是本申请实施例公开的另一种电子病历的管理方法的流程示意图,图2是在图1的基础上进一步优化得到的,如图2所示,该电子病历的管理方法包括如下步骤:

201、接收来自需求方的信息获取请求,上述信息获取请求携带需求方身份标识和病历标识。

202、根据上述需求方身份标识判断上述需求方是否具备存储有电子病历的区块链的访问权限。

203、在检测到上述目标电子病历设置有预设获取规则时,按照上述预设获取规则验证上述需求方是否具备上述目标电子病历的访问权限。

具体的,上述拥有者在上传电子病历之后,可以设置电子病历的预设获取规则,一般而言如前述方法,在该区块链中注册并通过验证的节点都可以访问区块链中的电子病历,且每次访问记录可查;而拥有者还可以对该电子病历进行加密(可以设置密码),需求方在获取目标电子病历时,若该电子病历是加密的,需要正确输入密码才能查看该电子病历。

可选的,上述预设获取规则可以包括密码访问规则,步骤203可包括:

向上述需求方发送第一验证请求,使上述需求方提供所述目标电子病历的验证密码;

接收来自上述需求方的上述验证密码,验证上述验证密码与上述目标电子病历的预设密码是否匹配;

若上述验证密码与上述目标电子病历的预设密码匹配,则触发步骤204。

具体的,在接收到来自需求方的信息获取请求之后,查找到目标电子病历,但是可以先不将其提供给需求方,而是向目标电子病历的拥有者发送上述第一验证请求,使拥有者先验证上述需求方身份,比如要求上述需求方提供目标电子病历的验证密码,区块链服务器可以接收来自上述需求方的上述验证密码,验证该验证密码是否正确,即拥有者预设的密码是否匹配,比如数字密码形式,或者使用公钥(publickey)与私钥(privatekey)进行加密和解密。若使用数字密码,当输入的验证密码与预设密码完全相同即匹配。而公钥和私钥是通过一种算法得到的一个密钥对(即一个公钥和一个私钥),公钥是密钥对中公开的部分,私钥则是非公开的部分。公钥通常用于加密会话密钥、验证数字签名,或加密可以用相应的私钥解密的数据。通过这种算法得到的密钥对能保证在世界范围内是唯一的。使用这个密钥对的时候,如果用其中一个密钥加密一段数据,必须用另一个密钥解密。比如用公钥加密数据就必须用私钥解密,如果用私钥加密也必须用公钥解密,否则解密将不会成功,可以进一步提高信息安全性。

可选的,上述预设获取规则可以包括请求确认规则,步骤203可包括:

向上述目标电子病历的拥有者发送确认请求,上述确认请求包括上述需求方的身份信息,以使上述拥有者对上述需求方的身份信息进行验证;

若接收到来自上述拥有者的验证通过信息,则上述需求方具备上述目标电子病历的访问权限。

具体的,用户可以将自己的电子病历设置为需要用户确认后才能获取的模式,若拥有者通过需求方的确认请求,用户可以在终端设备上进行交互操作,以通过拥有者的终端设备向区块链服务器发送上述验证通过信息,则区块链服务器允许该需求方获取目标电子病历进行查看。

可选的,若接收到来自上述拥有者的第一拒绝请求,向上述需求方发送验证失败信息,上述验证失败信息用于提示上述需求方未通过上述拥有者的验证,不能获取所述目标电子病历。

具体的,若拥有者拒绝本次确认请求,用户可以在终端设备上进行交互操作,以通过拥有者的终端设备向区块链服务器发送上述第一拒绝请求,则验证失败,该需求方不能获取上述电子病历,可以执行步骤205。

其中,上述确认请求可以包括上述需求方的身份信息,比如需求方姓名、需求方公司名称、需求方的信用等级和/或需求方有效证件信息等,便于上述拥有者判断是否将目标电子病历分享给上述需求方。

进一步可选的,该方法还包括:若接收到来自上述拥有者的第二拒绝请求,则将上述需求方记入上述拥有者的访问黑名单中,上述访问黑名单用于管理禁止获取上述拥有者的电子病历的用户。

具体的,若拥有者拒绝本次确认请求,用户可以选择将该次请求访问目标电子病历的需求方设置为黑名单,以便于不再接受或者说直接拒绝其之后的确认请求。用户可以在终端设备上进行交互操作,通过该终端设备向区块链服务器发送上述第二拒绝请求,则验证失败,该需求方不能获取上述电子病历,可以执行步骤205,以及区块链服务器中可以建立并存储各个拥有者的访问黑名单,在该黑名单中的账户将被禁止访问该拥有者的电子病历,和/或该拥有者的个人信息等。在接收到来自上述第二拒绝请求之后,区块链服务器可以将该需求方记入该拥有者的访问黑名单中,禁止该需求方获取该拥有者的电子病历。拥有者可以对自己的访问黑名单进行管理,比如可以增加或者删除其中的用户,更改其对电子病历的访问权限。

可选的,上述验证通过信息可以包括允许访问时间周期;上述方法还可以包括:

将上述需求方记入上述拥有者的访问白名单中,以使已记录在上述访问白名单中的需求方在上述允许访问时间周期内能够获取上述目标电子病历。

在向目标电子病历的拥有者发送确认请求时,还可以由拥有者选择访问时间周期,即在本次拥有者通过本次确认请求之后,区块链服务器能接收到来自拥有者的验证通过信息,获取其中的访问时间周期,其中,上述访问时间周期可以是拥有者在接收到上述确认请求时选择的时间周期,也可以是在这之前预存的。然后,区块链服务器可以将上述需求方记入上述拥有者的访问白名单中。区块链服务器中可以建立并存储各个拥有者的访问黑名单,在该白名单中的账户可以在规定的时间内(比如上述访问时间周期内)不需要通过拥有者的确认就能直接获取拥有者的电子病历。即上述需求方能够在上述访问时间周期内都能获取目标电子病历,不用再次向拥有者发起验证,节省了验证步骤,提高了处理效率。

可选的,拥有者还可以设置电子病历的公开时间,即在公开时间内可以由可访问区块链的其他节点获取查看,在公开时间之外的时间电子病历可以保密,即仅供用户自己可查,使电子病历的管理方式更灵活。

若上述验证成功,可以执行步骤204;若上述验证不成功,不执行步骤204,可以执行步骤205。

204、在上述区块链中获取上述病历标识对应的目标电子病历,向上述需求方发送上述目标电子病历。

205、向上述需求方发送验证失败信息,上述验证失败信息用于提示上述需求方未通过上述拥有者的验证,不能获取上述目标电子病历。

在上述需求方未通过验证的情况下,区块链服务器可以向上述需求方发送上述验证失败信息,以提示上述需求方未通过上述拥有者的验证,不能获取上述目标电子病历。可选的,在上述需求方接收到上述验证失败信息之后,可以再次向拥有者申请访问,即发起上述确认请求。

206、生成上述需求方的信息获取记录,存储在上述区块链中。

其中,上述步骤201、步骤202、步骤204和步骤206可以分别参考图1所示实施例的步骤101-步骤104中的具体描述,此处不再赘述。

本申请实施例适用于对用户私密信息的管理,尤其适用于对用户的电子病历的管理。实际应用中,通过区块链服务器身份认证的用户均可以访问区块链中共享的电子病历,或者,根据不同的电子病历所有者的设置进行验证从而获取该电子病历,且每次获取记录可查,整个过程公开、公正,在提高了电子病历的安全性的同时,便于利用电子病历资源,比如用户从一个医院出院后,电子病历可以选择上传至区块链中,在之后的就医过程中,即使不在同一家医院仍然能够获取到自己的历史电子病历,方便进行就诊,该电子病历也可以应用于保险理赔等方面,作为一种凭证。

本申请实施例通过接收来自需求方的信息获取请求,上述信息获取请求携带需求方身份标识和病历标识,根据上述需求方身份标识判断上述需求方是否具备存储有电子病历的区块链的访问权限,在检测到上述目标电子病历设置有预设获取规则时,按照上述预设获取规则判断上述需求方是否具备上述目标电子病历的访问权限,若具备,在上述区块链中获取上述病历标识对应的目标电子病历,再向上述需求方发送上述目标电子病历,若不具备,可以向上述需求方发送验证失败信息,上述需求方不能获取上述目标电子病历,同时可以生成上述需求方的信息获取记录,存储在上述区块链中,可以实现电子病历的分享和传输,提高电子病历的管理安全性。

请参见图3,图3是本申请实施例提供的一种服务器的结构示意图,该服务器300包括传输模块310、身份验证模块320、获取模块330和生成模块340,其中:

上述传输模块310,用于接收来自需求方的信息获取请求,上述信息获取请求携带需求方身份标识和病历标识;

上述身份验证模块320,用于根据上述需求方身份标识判断上述需求方是否具备存储有电子病历的区块链的访问权限;

上述获取模块330,用于若确定上述需求方具备上述区块链的访问权限,则在上述区块链中获取与上述病历标识对应的目标电子病历;

上述传输模块310还用于,向上述需求方发送上述目标电子病历;

上述生成模块340,用于生成上述需求方的信息获取记录,存储在上述区块链中。

可选的,上述身份验证模块320还用于,在获取模块330上述区块链中获取上述病历标识对应的目标电子病历之前,在检测到上述目标电子病历设置有预设获取规则时,按照上述预设获取规则验证上述需求方是否具备上述目标电子病历的访问权限。

可选的,上述预设获取规则包括密码访问规则,上述身份验证模块320具体用于:

通过传输模块310向上述需求方发送第一验证请求,以使上述需求方根据上述第一验证请求发出上述目标电子病历的验证密码;

通过传输模块310接收来自上述需求方的上述验证密码,验证上述验证密码与上述目标电子病历的预设密码是否匹配;

若上述验证密码与上述目标电子病历的预设密码匹配,则触发获取模块330执行上述在上述区块链中获取上述病历标识对应的目标电子病历的步骤。

可选的,上述预设获取规则包括请求确认规则,上述身份验证模块320还具体用于:

通过传输模块310向上述目标电子病历的拥有者发送确认请求,上述确认请求包括上述需求方的身份信息,以使上述拥有者对上述需求方的身份信息进行验证;

若通过传输模块310接收到来自上述拥有者的验证通过信息,则上述需求方具备上述目标电子病历的访问权限。

可选的,上述验证通过信息包括允许访问时间周期,上述服务器300还包括名单管理模块350,用于将上述需求方记入上述拥有者的访问白名单中,以使已记录在上述访问白名单中的需求方在上述允许访问时间周期内能够获取上述目标电子病历。

可选的,上述身份验证模块320还具体用于:

若传输模块310接收到来自上述拥有者的第一拒绝请求,通过上述传输模块310向上述需求方发送验证失败信息,上述验证失败信息用于提示上述需求方未通过上述拥有者的验证,不能获取上述目标电子病历。

可选的,上述名单管理模块350还用于:

若传输模块310接收到来自上述拥有者的第二拒绝请求,则将上述需求方记入上述拥有者的访问黑名单中,上述访问黑名单用于管理禁止获取上述拥有者的电子病历的用户。

本申请实施例中的服务器300,服务器300通过接收来自需求方的信息获取请求,上述信息获取请求携带病历标识,判断上述需求方在区块链中是否具备访问权限,若上述需求方在上述区块链中具备访问权限,在上述区块链中获取上述病历标识对应的目标电子病历,再向上述需求方发送包含上述目标电子病历的目标数据,并且生成上述需求方的信息获取记录,存储在上述区块链中,可以实现电子病历的分享和传输,提高电子病历的管理安全性。

请参阅图4,图4是本申请实施例公开的另一种服务器的结构示意图。如图4所示,该服务器400包括处理器401和存储器402,其中,服务器400还可以包括总线403,处理器401和存储器402可以通过总线403相互连接,总线403可以是外设部件互连标准(peripheralcomponentinterconnect,pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture,eisa)总线等。总线403可以分为地址总线、数据总线、控制总线等。为便于表示,图4中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。其中,服务器400还可以包括输入输出设备404,输入输出设备404可以包括显示屏,例如液晶显示屏。存储器402用于存储包含指令的一个或多个程序;处理器401用于调用存储在存储器402中的指令执行上述图1和图2实施例中提到的部分或全部方法步骤。

应当理解,在本申请实施例中,所称处理器401可以是中央处理单元(centralprocessingunit,cpu),该处理器还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor,dsp)、专用集成电路(applicationspecificintegratedcircuit,asic)、现成可编程门阵列(field-programmablegatearray,fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

输入设备402可以包括触控板、指纹采传感器(用于采集用户的指纹信息和指纹的方向信息)、麦克风等,输出设备403可以包括显示器(lcd等)、扬声器等。

该存储器404可以包括只读存储器和随机存取存储器,并向处理器401提供指令和数据。存储器404的一部分还可以包括非易失性随机存取存储器。例如,存储器404还可以存储设备类型的信息。

通过本申请实施例的服务器400,服务器400通过接收来自需求方的信息获取请求,上述信息获取请求携带病历标识,判断上述需求方在区块链中是否具备访问权限,若上述需求方在上述区块链中具备访问权限,在上述区块链中获取上述病历标识对应的目标电子病历,再向上述需求方发送包含上述目标电子病历的目标数据,并且生成所述需求方的信息获取记录,存储在所述区块链中,可以实现电子病历的分享和传输,提高电子病历的管理安全性。

本申请实施例还提供一种计算机存储介质,其中,该计算机存储介质存储用于电子数据交换的计算机程序,该计算机程序使得计算机执行如上述方法实施例中记载的任何一种数据处理的部分或全部步骤。

在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。

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

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

所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储器中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储器中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储器包括:u盘、只读存储器(read-onlymemory,rom)、随机存取存储器(randomaccessmemory,ram)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1