CN115460228A - 一种医疗数据的访问控制方法及系统 - Google Patents

一种医疗数据的访问控制方法及系统 Download PDF

Info

Publication number
CN115460228A
CN115460228A CN202110556901.9A CN202110556901A CN115460228A CN 115460228 A CN115460228 A CN 115460228A CN 202110556901 A CN202110556901 A CN 202110556901A CN 115460228 A CN115460228 A CN 115460228A
Authority
CN
China
Prior art keywords
medical
authorization
party
certificate
requested
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110556901.9A
Other languages
English (en)
Inventor
邱锋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hunan Network Technology Co ltd
Original Assignee
Hunan Network Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hunan Network Technology Co ltd filed Critical Hunan Network Technology Co ltd
Priority to CN202110556901.9A priority Critical patent/CN115460228A/zh
Publication of CN115460228A publication Critical patent/CN115460228A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • General Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

本申请公开一种医疗数据的访问控制方法及系统，该方法和系统结合分布式的数据确权、授权机制来实现医疗数据的访问控制，确保了医疗数据在产生和流通环节只有授权对象(授权的请求方，如授权的医生)能够访问和使用被请求方(如，患者)的医疗数据，并且，通过将医疗数据从应用业务分离出来，由私有云向请求方(如，医生)通过独立信道加密传输，从传播途径上避免了应用获取到患者医疗数据，从而，基于本申请方案，可解决互联网医疗应用场景下用户医疗数据及隐私保护的问题。

Description

一种医疗数据的访问控制方法及系统
技术领域
本申请属于互联网医疗应用技术领域，尤其涉及一种医疗数据的访问控制方法及系统。
背景技术
随着移动互联网的普及以及互联网医疗应用的蓬勃发展，越来越多的患者开始尝试体验远程问诊、在线购药等服务，互联网医疗需求呈爆发式增长，互联网医院以及相关初创企业大量涌现。
然而，在方便患者快捷获取医疗资源和服务的同时，也带来了患者医疗数据以及隐私被应用厂商滥用的风险和安全隐患。当前通过互联网医疗应用(以下简称“应用”)进行远程问诊的过程中，通常会需要患者上传其医疗数据(包括但不限于病历、影像、检测报告等)，并通过应用转发给医生查阅，以便医生能够进行诊断。但是，由于应用本身能够搜集到这些医疗数据，从而难以避免会存在泄露和滥用患者个人医疗数据的风险。
因此，如何通过技术手段，来确保在互联网医疗应用场景下患者医疗数据仅用于必要的诊断过程，而不被泄露或者在患者不知情的情况下被用于商业目的，成为本领域亟需解决的技术问题。
发明内容
有鉴于此，本申请公开一种医疗数据的访问控制方法及系统，用于解决互联网医疗应用场景下用户医疗数据及隐私保护的问题。
具体技术方案如下：
一种医疗数据的访问控制方法，应用于医疗数据的访问控制系统，所述系统包括：请求方、被请求方、医疗卫生机构、医疗认证授权系统、区域医疗公有云、医疗机构私有云、区域医疗数据终端、医疗应用系统；所述方法包括：
被请求方确认是否授权请求方访问其医疗数据，在确认授权的情况下，向所述医疗认证授权系统请求授权凭证，并将所述医疗认证授权系统签发的授权凭证通过所述医疗应用系统返回给请求方；
请求方接收授权凭证，并将授权凭证发送给所述区域医疗数据终端；
所述区域医疗数据终端向所述医疗认证授权系统请求所述请求方的身份证书，并在所述请求方操作确认后，获得所述请求方的身份证书；
所述区域医疗数据终端向所述区域医疗公有云发起数据请求，所述数据请求中包括所述授权凭证和请求方的身份证书；
所述区域医疗公有云根据所述授权凭证中的被请求方信息确定至少一个目标医疗机构私有云，并向所述至少一个目标医疗机构私有云发送所述数据请求；
所述至少一个目标医疗机构私有云验证所述授权凭证和所述请求方的身份证书，若验证通过，根据所述授权凭证中的被请求方信息，查找对应的目标医疗数据，并通过加密通道将目标医疗数据传输给所述区域医疗公有云；
所述区域医疗公有云将至少一个目标医疗机构私有云通过加密通道传输的目标医疗数据返回给所述区域医疗数据终端；
所述区域医疗数据终端通过解密通道向请求方展示所述目标医疗数据。
可选的，上述方法在所述被请求方确认是否授权请求方访问其医疗数据之前，还包括：
当请求方需访问被请求方的目标医疗数据时，请求方通过所述医疗应用系统向被请求方请求授权。
可选的，所述医疗认证授权系统包括：医疗认证服务，和请求侧与被请求侧的医疗认证授权客户端；所述医疗应用系统包括：医疗应用服务，和请求侧与被请求侧的医疗应用客户端；
所述请求方通过所述医疗应用系统向被请求方请求授权，包括：
所述请求方在请求侧的医疗应用客户端通过所述医疗应用服务向被请求侧的医疗应用客户端请求授权；
所述医疗认证授权系统签发授权凭证，包括：
被请求侧的医疗认证授权客户端根据本地存放的所述被请求方的第一私钥签发授权凭证，并将授权凭证返回给被请求侧的医疗应用客户端；
所述将所述医疗认证授权系统签发的授权凭证通过所述医疗应用系统返回给数据请求方，包括：
被请求侧的医疗应用客户端通过所述医疗应用服务将所述授权凭证返回给请求侧的医疗应用客户端；
所述区域医疗数据终端向所述医疗认证授权系统请求所述请求方的身份证书，包括：
所述区域医疗数据终端向请求侧的医疗认证授权客户端请求所述请求方的身份证书。
可选的，所述区域医疗公有云根据所述授权凭证中的被请求方信息确定至少一个目标医疗机构私有云，包括：
所述区域医疗公有云从所述授权凭证中获得被请求方ID，并根据被请求方ID查询相对应的目标医疗机构私有云；
所述至少一个目标医疗机构私有云验证所述授权凭证和所述请求方的身份证书，包括：
所述至少一个目标医疗机构私有云从所述授权凭证中获得请求方ID和被请求方ID，根据请求方ID和被请求方ID分别从所述医疗认证服务获取请求方和被请求方的身份信息；根据被请求方身份信息中的第一公钥验证所述授权凭证，根据请求方身份信息中的第二公钥验证所述请求方的身份证书。
可选的，所述至少一个目标医疗机构私有云根据所述授权凭证中的被请求方信息，查找对应的目标医疗数据，并通过加密通道将所述目标医疗数据传输给所述区域医疗公有云，包括：
所述目标医疗机构私有云从授权凭证中获取被请求方ID，并从请求方的身份证书中获取请求方的第二公钥；
所述目标医疗机构私有云根据被请求方ID查找对应的目标医疗数据；
所述目标医疗机构私有云生成一会话秘钥，利用会话秘钥对所述目标医疗数据进行加密，得到加密后的目标医疗数据，并利用所述第二公钥对所述会话秘钥进行加密，得到加密后的会话秘钥；
所述目标医疗机构私有云将加密后的目标医疗数据和加密后的会话秘钥返回给所述区域医疗公有云。
可选的，所述区域医疗数据终端通过解密通道向请求方展示所述目标医疗数据包括：
所述区域医疗数据终端在接收到加密的所述目标医疗数据和加密的会话秘钥后，调用请求侧的医疗认证授权客户端，以使请求侧的医疗认证授权客户端利用存储的请求方的第二私钥对加密后的会话秘钥进行解密，得到会话秘钥；
所述区域医疗数据终端利用会话秘钥对加密后的目标医疗数据进行解密，得到目标医疗数据，并向请求方展示。
可选的，在所述区域医疗公有云根据所述授权凭证中的被请求方信息确定至少一个目标医疗机构私有云之前，还包括：
所述区域医疗公有云验证所述授权凭证和所述请求方的身份证书；
若验证通过，则触发根据授权凭证中的被请求方信息确定至少一个目标医疗机构私有云，并向所述至少一个目标医疗机构私有云发送所述数据请求的步骤；若验证未通过，则停止向医疗机构私有云请求数据。
可选的，在所述请求方通过所述医疗应用系统向被请求方请求授权之前，还包括：
请求方与被请求方分别通过所述医疗认证授权系统进行身份注册及认证，以得到用于登录所述医疗应用系统的身份信息；
当被请求方在医疗卫生机构产生医疗数据时，医疗卫生机构对产生的医疗数据进行确权处理。
可选的，所述请求方与被请求方分别通过所述医疗认证授权系统进行身份注册及认证，包括：
请求方、被请求方分别在其对应侧的医疗认证授权客户端向医疗认证服务进行身份注册；
请求方、被请求方分别在其对应侧的医疗应用客户端登录医疗应用服务；
医疗应用服务验证登录的请求方、被请求方是否为在医疗认证服务注册的合法用户，在验证通过时，为请求方、被请求方分别创建应用内部账号，并将为请求方创建的应用内部账号与请求方在医疗认证服务注册的请求方ID进行绑定，将为被请求方创建的应用内部账号与被请求方在医疗认证服务注册的被请求方ID进行绑定；
所述当被请求方在医疗卫生机构产生医疗数据时，医疗卫生机构对产生的医疗数据进行确权处理，包括：
被请求方产生医疗数据后，医疗卫生机构向医疗认证服务请求所述被请求方的身份信息并验证；
验证通过后，将被请求方的身份信息中的被请求方ID作为医疗数据的所有者标识信息，并将医疗数据及其所有者标识信息记录至所述医疗卫生机构对应的医疗机构私有云；
医疗卫生机构将所述被请求方ID及所述医疗机构私有云的标识信息同步至区域医疗公有云进行存储。
一种医疗数据的访问控制系统，包括：请求方、被请求方、医疗卫生机构、医疗认证授权系统、区域医疗公有云、医疗机构私有云、区域医疗数据终端、医疗应用系统；其中：
所述被请求方，用于确认是否授权请求方访问其医疗数据，在确认授权的情况下，向所述医疗认证授权系统请求授权凭证，并将所述医疗认证授权系统签发的授权凭证通过所述医疗应用系统返回给请求方；
所述请求方，还用于接收授权凭证，并将授权凭证发送给所述区域医疗数据终端；
所述区域医疗数据终端，用于：向所述医疗认证授权系统请求所述请求方的身份证书，在所述请求方操作确认后，获得所述请求方的身份证书；并向所述区域医疗公有云发起数据请求，所述数据请求中包括所述授权凭证和请求方的身份证书；
所述区域医疗公有云，用于根据所述授权凭证中的被请求方信息确定至少一个目标医疗机构私有云，并向所述至少一个目标医疗机构私有云发送所述数据请求；
所述至少一个目标医疗机构私有云，用于验证所述授权凭证和所述请求方的身份证书，若验证通过，根据所述数据请求中的被请求方信息，查找对应的目标医疗数据，并通过加密通道将所述目标医疗数据传输给所述区域医疗公有云；
所述区域医疗公有云，还用于将至少一个目标医疗机构私有云通过加密通道传输的目标医疗数据返回给所述区域医疗数据终端；
所述区域医疗数据终端，还用于通过解密通道向请求方展示所述目标医疗数据。
由以上方案可知，本申请公开的医疗数据的访问控制方法及系统，结合分布式的数据确权、授权机制来实现医疗数据的访问控制，确保了医疗数据在产生和流通环节只有授权对象(授权的请求方，如授权的医生)能够访问和使用被请求方(如，患者)的医疗数据，并且，通过将医疗数据从应用业务分离出来，由私有云向请求方(如，医生)通过独立信道加密传输，从传播途径上避免了应用获取到患者医疗数据，从而，基于本申请方案，可解决互联网医疗应用场景下用户医疗数据及隐私保护的问题。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1是本申请实施例提供的请求方、被请求方进行身份注册的注册逻辑示意图；
图2是本申请实施例提供的医疗数据确权流程的逻辑示意图；
图3是本申请实施例提供的医疗数据的访问控制方法的一种流程示意图；
图4是本申请实施例提供的数据授权与访问流程的逻辑示意图；
图5是本申请实施例提供的医疗数据的访问控制方法的另一种流程示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请公开了一种医疗数据的访问控制方法及系统，用于通过将医疗数据与应用业务分离，采用集中式身份注册认证，分布式数据确权、授权，来实现对用户医疗数据的访问控制，确保医疗数据只能够被获得授权的对象访问到，从而解决互联网医疗应用场景下用户医疗数据及隐私保护的问题。
本申请实施例提供的医疗数据的访问控制方法，可适用于医疗数据的访问控制系统中，以下首先对本申请方法适用的医疗数据的访问控制系统进行说明。
上述的医疗数据的访问控制系统包括：请求方、被请求方、医疗卫生机构、医疗认证授权系统、区域医疗公有云、医疗机构私有云、区域医疗数据终端、医疗应用系统。
其中，在医疗数据的授权与访问流程中，该系统各组成部分至少具备以下功能：
上述请求方，用于在需访问被请求方的目标医疗数据时，通过医疗应用系统向被请求方请求授权；
上述被请求方，用于确认是否授权，在确认授权的情况下，向医疗认证授权系统请求授权凭证，并将医疗认证授权系统签发的授权凭证通过医疗应用系统返回给请求方；
上述请求方，还用于接收授权凭证，并将授权凭证发送给区域医疗数据终端；
上述区域医疗数据终端，用于：向医疗认证授权系统请求上述请求方的身份证书，在请求方操作确认后，获得请求方的身份证书；并向区域医疗公有云发起数据请求，该数据请求中包括上述的授权凭证和请求方的身份证书；
上述区域医疗公有云，用于根据授权凭证中的被请求方信息确定至少一个目标医疗机构私有云，并向该至少一个目标医疗机构私有云发送上述数据请求；
上述至少一个目标医疗机构私有云，用于验证所述授权凭证和所述请求方的身份证书，若验证通过，根据数据请求中的被请求方信息，查找对应的目标医疗数据，并通过加密通道将该目标医疗数据传输给区域医疗公有云；
上述区域医疗公有云，还用于将至少一个目标医疗机构私有云通过加密通道传输的目标医疗数据返回给区域医疗数据终端；
上述区域医疗数据终端，还用于通过解密通道向请求方展示目标医疗数据。
以下继续对上述系统的各组成部分进行更为详细的说明。
其中：
(一)请求方、被请求方
请求方、被请求方可分别为互联网医疗应用场景中的医生和患者。
(二)医疗认证授权系统
医疗认证授权系统，主要用于对患者和医生(本申请实施例中，可统称为“用户”)进行身份认证并生成身份标识，另外还用于生成并验证患者对医生的数据访问授权凭证。
该医疗认证授权系统由医疗认证服务和认证授权客户端组成。
其中，医疗认证服务由一个或者多个独立的服务节点提供，主要用于用户身份信息的注册、查询和管理等。各服务节点由国家监管部门授权单位独立运营，拥有独立的域名地址，并能够向互联网提供服务。
认证授权客户端进一步细分为请求侧(对应“医生侧”)的医疗认证授权客户端与被请求侧(对应“患者侧”)的医疗认证授权客户端，主要用于生成PKI(PublicKeyInfrastructure，公钥基础设施)公私钥对，并生成和验证用户身份证书以及数据访问授权凭证。该医疗认证授权客户端可以以独立应用程序的形式运行在用户侧。实施中，可选的，也可以将医疗认证授权客户端中用于验证用户身份证书及授权凭证的功能模块独立出来形成基础运行库，并嵌入到其它云端服务中，以便于这些云端服务实现相关功能。
优选的，上述的用户身份信息，可以仅包含各类可公开的匿名信息，该匿名信息包括但不限于用户的姓氏或代号、身份类型(患者、医生)、上述用于身份认证的公钥等，以用于在不透露用户身份的情况下对用户进行身份验证，其中，同一份用户信息中可以包含多个公钥，以支持用户多个设备同时使用的情况。此外，针对医生，其身份信息还可以包括医生执业信息，医生执业信息进一步包括但不限于主要执业机构、医师级别、执业证书编号等。
用户身份信息通过注册流程，存放在医疗认证服务的服务节点上。可选的，在医疗认证服务的服务节点中，用户身份信息采用结构化的格式进行存储和传输，包括但不限于基于常见的JSON(JavaScriptObjectNotation，JavaScript对象表示法)格式、RDF(ResourceDescriptionFramework，资源描述框架)格式。
用户的身份证书(简称“证书”)，主要用于用户身份的验证，可采用包括但不限于基于X.509标准的自签名数字证书来实现。其中，该证书的内容包括但不限于用户(请求方“医生”、被请求方“患者”)的用户ID(Identity document，身份证标识号)、数字签名(证书机构的私钥对用户公钥的签名)与对应用户的公钥、有效期。该证书的生成采用现有业界标准(包括但不限于X.509标准，在此不做赘述)。该证书的验证分为两步，首先采用上述业界标准对证书本身进行密码学验证(私钥签名、公钥验证的标准验证流程)，然后对其公钥的真实性进行二次验证，该二次验证的过程可采用WebID-TLS协议标准实现，具体包括：根据证书内的用户ID获取到用户身份信息，比对身份信息中的公钥和证书中的公钥是否一致，若一致则验证通过，否则，若不一致，则验证未通过。
上述的数据访问授权凭证，简称“授权凭证”，主要用于在医生请求访问患者的医疗数据时，由患者向医生授权，以允许医生访问其医疗数据。授权凭证的内容包括但不限于患者ID、医生ID、数字签名(利用患者私钥所作的签名)、有效期。授权凭证的验证分为两步，首先根据患者ID获取到患者身份信息，然后根据患者身份信息中的公钥对数字签名进行验证，可采用现有业界标准的数字签名验证方法实现，包括但不限于RSA数字签名算法、ECDSA数字签名算法等。
(三)医疗卫生机构
医疗卫生机构，包括但不限于医院、第三方检验中心、区域影像中心等。
(四)医疗机构私有云
每一医疗卫生机构对应有相应的医疗机构私有云(可简称为“私有云”)，以作为医疗卫生机构的私有数据中心。
私有云由若干服务模块组成，包括但不限于医疗数据存储管理模块、智能网关模块。其中，智能网关模块将参与授权过程，主要用于对医疗数据的访问控制。
患者在某个医疗卫生机构所产生的医疗数据，与其身份信息绑定，并在绑定后，将医疗数据及其所属的患者身份信息存放于该医疗机构的私有数据中心即医疗机构私有云中，医疗机构私有云中的医疗数据可被取得患者授权的对象访问，该对象既可以是本机构的医生，也可以是其它机构的医生。
(五)区域医疗公有云
区域医疗公有云(可简称“公有云”)，是为规划区域内各医疗卫生机构提供协同医疗所需的信息基础设施的云服务平台。
各家医疗卫生机构对应的私有云通过互联网专线接入到公有云，以用于安全地分发医疗数据。公有云将为接入的各个私有云分配唯一标识，本申请实施例将为私有云分配的唯一标识称为“私有云ID”。
(六)区域医疗数据终端
区域医疗数据终端(可简称为“数据终端”)，是指医生专用的客户端软件或者包含医疗数据查询功能的硬件设备，该终端通过互联网公网或者专线接入到公有云。
数据终端与各个私有云之间，通过公有云作为桥梁建立起独立于应用(即“医疗应用系统”)的传输信道，医疗数据只能通过该信道传输，并最终呈现给医生。数据终端通过与医疗认证授权客户端直接通信(包括但不限于进程内调用、本机进程间通信)获得医生的身份证书，以作为发起数据请求的身份凭证。
(七)医疗应用系统
医疗应用系统，是指第三方医疗应用业务的支撑系统，主要由医疗应用服务和请求侧与被请求侧的医疗应用客户端组成，请求侧的医疗应用客户端也可称为医生应用客户端(简称“医生端”)，被请求侧的医疗应用客户端也可称为患者应用客户端(简称“患者端”)。
基于上述的访问控制系统，在对请求方进行基于授权的医疗数据访问控制之前，需首先执行以下的预处理流程：
1、请求方、被请求方的注册认证流程
请求方与被请求方分别通过医疗认证授权系统进行身份注册及认证，以得到用于登录医疗应用系统的身份信息。
参见图1，该注册认证流程具体包括：
11)请求方、被请求方分别在其对应侧的医疗认证授权客户端向医疗认证服务进行身份注册。
被请求侧的医疗认证授权客户端为被请求方(患者)生成公私钥对：第一公钥+第一私钥，并将第一私钥安全存放在本地，之后，向医疗认证服务发起被请求方的身份信息注册请求。优选的，该请求中携带身份类型(患者)、第一公钥，拟创建的账号及密码，以及可公开的匿名个人信息如姓氏、代号等，以用于身份验证，但个人信息不限于上述的几种，实施中，可根据实际需求拓展配置，例如，还可以包括但不限于用户(患者)姓名、手机号码、身份证号及身份证正反面照片等。医疗认证服务响应于接收到的注册请求，将进行一系列认证处理，包括但不限于手机号码认证、个人实名认证。认证通过后，为被请求方创建账号、身份信息、用户ID，并向被请求侧的医疗认证授权客户端返回用户ID。其中，账号主要用于查询用户ID，新增、删除或者替换现有的公钥，以支持多设备使用，以及解决私钥丢失或者盗用等安全问题。
相类似，请求侧的医疗认证授权客户端为请求方生成公私钥对：第二公钥+第二私钥，并将第二私钥安全存放在本地，之后，向医疗认证服务发起请求方的身份信息注册请求。相比于被请求方，请求方的注册请求中还进一步包括医师执业执照等信息，医疗认证服务在响应于接收到的注册请求进行认证处理时，针对医生身份注册还需要进行执业医师资格认证。认证通过后，为请求方(医生)创建账号、身份信息、用户ID，并向请求侧的医疗认证授权客户端返回用户ID。
需要说明的是，为了便于区分以及便于引用，本申请实施例将被请求侧的医疗认证授权客户端为被请求方(患者)生成的公私钥称为第一公钥、第一私钥，将请求侧的医疗认证授权客户端为请求方生成的公私钥称为第二公钥、第二私钥，因此，本申请实施例针对公私钥的“第一”、“第二”的相关描述或限定，并不要求或者暗示公私钥相互之间需要具备“第一”、“第二”的关系或者顺序。
12)请求方(医生)、被请求方(患者)分别打开其对应侧的医疗应用客户端进行登录。
该医疗应用客户端首先与对应侧的医疗认证授权客户端直接通信，并由后者利用存储在本地的私钥签发一个身份证书(请求侧的医疗认证授权客户端为请求方即医生签发身份证书，被请求侧的医疗认证授权客户端为被请求方即患者签发身份证书)，并返回给对应侧的医疗应用客户端。然后，医疗应用客户端再向医疗应用服务发起登录请求，请求需要携带上一步生成的身份证书。
13)医疗应用服务验证登录的请求方、被请求方是否为在医疗认证服务注册的合法用户，并在验证通过时，为请求方、被请求方分别创建应用内部账号，并将为请求方创建的应用内部账号与请求方在医疗认证服务注册的请求方ID进行绑定，将为被请求方创建的应用内部账号与被请求方在医疗认证服务注册的被请求方ID进行绑定。
具体的，医疗应用服务首先根据身份证书(请求侧的身份证书、被请求侧的身份证书)携带的用户ID获取到对应用户(请求侧、被请求侧)的身份信息，然后利用身份信息对其身份证书进行验证。验证通过后，为对应用户(请求侧、被请求侧)创建应用内部账号，并且绑定相对应的用户ID(请求侧、被请求侧的用户ID)。
2、医疗数据确权流程
当被请求方(患者)在医疗卫生机构产生医疗数据时，医疗卫生机构对产生的医疗数据进行确权处理。
参见图2，该医疗数据确权流程具体包括：
21)被请求方(患者)在医疗卫生机构通过检查等诊疗手段，产生医疗数据；
22)被请求方打开对应侧的医疗认证授权客户端，供医疗卫生机构访问以获得被请求方的身份证书；
23)被请求方确认后，医疗卫生机构获得身份证书；
24)医疗卫生机构向医疗认证服务请求被请求方的身份信息，并验证身份证书，验证通过后将其中的被请求方ID作为该医疗数据的所有者标识信息，并将医疗数据及其所有者标识信息记录至医疗卫生机构对应的医疗机构私有云；
25)医疗机构将该被请求方的ID及对应的私有云ID同步给公有云进行记录，以作为索引信息，方便后续查询过程中快速定位被请求方的医疗数据所在的医疗机构私有云。
接下来，继续基于上述访问控制系统，描述本申请的医疗数据的访问控制方法的实现过程。
参见图3，提供了本申请中医疗数据的访问控制方法的流程示意图，该方法具体可通过以下的处理过程实现：
步骤301、被请求方确认是否授权请求方访问其医疗数据，在确认授权的情况下，向医疗认证授权系统请求授权凭证，并将医疗认证授权系统签发的授权凭证通过医疗应用系统返回给请求方。
在互联网医疗应用场景中，当请求方(医生)需访问被请求方(患者)的医疗数据时，请求方需首先通过被请求方的授权，只有通过授权，请求方才有权限访问被请求方的医疗数据。
在一种实施方式中，当需访问被请求方的目标医疗数据时，请求方可以通过医疗应用系统向被请求方请求授权。请结合参见图4提供的数据授权与访问流程的处理逻辑，请求方(医生)具体可在请求侧的医疗应用客户端通过医疗应用服务向被请求侧(患者侧)的医疗应用客户端请求授权。
但不限于上述的实施方式，在本申请的其它实施方式中，被请求方也可以不以收到请求方的授权请求为前提，而是主动授权请求方访问其医疗数据。
在向请求方授权时，被请求侧的医疗认证授权客户端具体根据本地存放的被请求方的第一私钥签发授权凭证，并将授权凭证返回给被请求侧的医疗应用客户端。之后，被请求侧的医疗应用客户端通过医疗应用服务将授权凭证返回给请求侧的医疗应用客户端。
所签发的授权凭证的内容包括但不限于患者ID、医生ID、数字签名(利用患者私钥所作的签名)、有效期等信息。
步骤302、请求方接收授权凭证，并将授权凭证发送给区域医疗数据终端。
请求方通过将授权凭证发送给区域医疗数据终端，而启动数据查询过程。
步骤303、区域医疗数据终端向医疗认证授权系统请求该请求方的身份证书，并在请求方操作确认后，获得请求方的身份证书。
区域医疗数据终端具体向请求侧的医疗认证授权客户端请求该请求方即医生的身份证书。
步骤304、区域医疗数据终端向区域医疗公有云发起数据请求，该数据请求中包括上述的授权凭证和请求方的身份证书。
步骤305、区域医疗公有云根据授权凭证中的被请求方信息确定至少一个目标医疗机构私有云，并向该至少一个目标医疗机构私有云发送上述的数据请求。
其中，区域医疗公有云具体从授权凭证中获得被请求方ID(即患者ID)，并根据被请求方ID，从预先记录的一系列患者ID与医疗机构私有云ID的对应关系集合中查询相对应的目标医疗机构私有云。
步骤306、至少一个目标医疗机构私有云验证上述的授权凭证和请求方的身份证书。
具体的，每一目标医疗机构从授权凭证中获得请求方ID和被请求方ID，并分别根据请求方ID和被请求方ID从医疗认证服务获取请求方和被请求方的身份信息，进而根据被请求方身份信息中的第一公钥验证授权凭证，根据请求方身份信息中的第二公钥验证请求方的身份证书。
步骤307、若验证通过，上述至少一个目标医疗机构私有云根据数据请求中的被请求方信息，查找对应的目标医疗数据，并通过加密通道将目标医疗数据传输给区域医疗公有云。
若验证通过，表示请求方是经过授权的合法对象，此种情况下，目标医疗机构私有云从数据请求包含的授权凭证中获取被请求方ID(患者ID)，从数据请求包含的请求方的身份证书中获取请求方(医生)的第二公钥，进而根据被请求方ID查找对应的目标医疗数据，并随机生成一个用于对目标医疗数据进行加密的会话秘钥，该会话秘钥为基于对称加密算法生成的秘钥，所述的对称加密算法采用业界标准，包括但不限于AES(AdvancedEncryption Standard，高级加密标准)算法。
在此基础上，目标医疗机构私有云利用会话秘钥对查找得到的目标医疗数据进行加密，得到加密后的目标医疗数据，并利用请求方(医生)的第二公钥对所述会话秘钥进行加密，得到加密后的会话秘钥，后续该会话秘钥只能由请求侧的医疗认证授权客户端存放的第二私钥(医生的私钥)解密。
之后，目标医疗机构私有云将加密后的目标医疗数据和加密后的会话秘钥返回给区域医疗公有云。
反之，若验证未通过，表示请求方并非是经过授权的合法对象，则目标医疗机构私有云拒绝查找对应的目标医疗数据，相应避免了非授权对象的非法访问，保护了患者隐私。
步骤308、区域医疗公有云将至少一个目标医疗机构私有云通过加密通道传输的目标医疗数据返回给区域医疗数据终端。
如果目标医疗机构私有云的数量为多个，区域医疗公有云对多个目标医疗机构私有云通过加密通道传输的目标医疗数据进行汇总，并将汇总后的目标医疗数据返回给区域医疗数据终端。
步骤309、区域医疗数据终端通过解密通道向请求方展示目标医疗数据。
区域医疗数据终端在接收到区域医疗公有云返回的加密目标医疗数据和加密会话秘钥后，调用请求侧的医疗认证授权客户端，以使请求侧的医疗认证授权客户端利用存储的请求方的第二私钥对加密后的会话秘钥进行解密，得到会话秘钥；在此基础上，区域医疗数据终端利用会话秘钥对加密后的目标医疗数据进行解密，得到目标医疗数据，并向请求方展示。
由以上方案可知，本申请实施例公开的医疗数据的访问控制方法及系统，结合分布式的数据确权、授权机制来实现医疗数据的访问控制，确保了医疗数据在产生和流通环节只有授权对象(授权的请求方，如授权的医生)能够访问和使用被请求方(如，患者)的医疗数据，并且，通过将医疗数据从应用业务分离出来，由私有云向请求方(如，医生)通过独立信道加密传输，从传播途径上避免了应用获取到患者医疗数据，从而，基于本申请方案，可解决互联网医疗应用场景下用户医疗数据及隐私保护的问题。
可选的，在一实施例中，参见图5提供的医疗数据的访问控制方法流程图，本申请公开的医疗数据的访问控制方法，在步骤305之前还可以包括：
步骤501、区域医疗公有云验证上述的授权凭证和请求方的身份证书，若验证通过，转至执行步骤306；若验证未通过，转至执行步骤502。
与目标医疗机构私有云验证授权凭证和请求方的身份证书的过程相同，区域医疗公有云具体从授权凭证中获得请求方ID和被请求方ID，并分别根据请求方ID和被请求方ID从医疗认证服务获取请求方和被请求方的身份信息，进而根据被请求方身份信息中的第一公钥验证授权凭证，根据请求方身份信息中的第二公钥验证请求方的身份证书。
步骤502、停止向医疗机构私有云请求数据。
若验证通过，表示请求方是经过授权的合法对象，从而可转至执行步骤306，以继续后续的目标医疗数据查询与反馈过程，实现请求方对被请求方医疗数据的访问。反之，若验证未通过，表示请求方并非是经过授权的合法对象，此种情况下，直接停止向医疗机构私有云请求数据，以避免未授权对象对患者医疗数据的非法访问。
可选的，实施中，针对医疗数据的访问控制过程，还可以生成相应的医疗数据访问授权记录，并进行存储，以达到防篡改、可追溯的目的。
本实施例通过在区域医疗公有云对授权凭证和请求方的身份证书进行验证，并基于验证结果对请求方进行医疗数据的访问控制，可有效杜绝黑客攻击直接打到各私有云的现象发生。
综上所述，本申请实施例公开的医疗数据的访问控制方法及系统，相比于现有技术，至少具备以下优势：
1)通过集中式的身份注册认证获得匿名身份信息，结合分布式的数据确权、授权机制来实现访问控制，确保了医疗数据在产生和流通环节只能被授权对象访问和使用；
2)将医疗数据从应用业务分离出来，由私有云向医生通过独立信道加密传输，从传播途径上避免了第三方应用获取到患者医疗数据，同时，尊重了患者和医疗机构对于医疗数据的所有权；
3)在确保医疗数据及隐私安全的同时，支持大多数互联网医疗应用场景，包括跨院诊疗、远程协同诊疗等。
4)通过患者授权，医生可以合法、方便地查看该患者在多家医疗机构中的医疗数据，可以有效提高诊断准确率和诊疗效率；
5)医疗数据访问授权记录具备防篡改、可追溯的作用，便于监管；
6)只对医疗机构现有的信息基础设施做少量改动即可实施，不会大幅提升医疗机构运营成本。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
为了描述的方便，描述以上系统或装置时以功能分为各种模块或单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
最后，还需要说明的是，在本文中，诸如第一、第二、第三和第四等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种医疗数据的访问控制方法，其特征在于，应用于医疗数据的访问控制系统，所述系统包括：请求方、被请求方、医疗卫生机构、医疗认证授权系统、区域医疗公有云、医疗机构私有云、区域医疗数据终端、医疗应用系统；所述方法包括：
被请求方确认是否授权请求方访问其医疗数据，在确认授权的情况下，向所述医疗认证授权系统请求授权凭证，并将所述医疗认证授权系统签发的授权凭证通过所述医疗应用系统返回给请求方；
请求方接收授权凭证，并将授权凭证发送给所述区域医疗数据终端；
所述区域医疗数据终端向所述医疗认证授权系统请求所述请求方的身份证书，并在所述请求方操作确认后，获得所述请求方的身份证书；
所述区域医疗数据终端向所述区域医疗公有云发起数据请求，所述数据请求中包括所述授权凭证和请求方的身份证书；
所述区域医疗公有云根据所述授权凭证中的被请求方信息确定至少一个目标医疗机构私有云，并向所述至少一个目标医疗机构私有云发送所述数据请求；
所述至少一个目标医疗机构私有云验证所述授权凭证和所述请求方的身份证书，若验证通过，根据所述授权凭证中的被请求方信息，查找对应的目标医疗数据，并通过加密通道将目标医疗数据传输给所述区域医疗公有云；
所述区域医疗公有云将至少一个目标医疗机构私有云通过加密通道传输的目标医疗数据返回给所述区域医疗数据终端；
所述区域医疗数据终端通过解密通道向请求方展示所述目标医疗数据。
2.根据权利要求1所述的方法，其特征在于，在所述被请求方确认是否授权请求方访问其医疗数据之前，还包括：
当请求方需访问被请求方的目标医疗数据时，请求方通过所述医疗应用系统向被请求方请求授权。
3.根据权利要求2所述的方法，其特征在于，所述医疗认证授权系统包括：医疗认证服务，和请求侧与被请求侧的医疗认证授权客户端；所述医疗应用系统包括：医疗应用服务，和请求侧与被请求侧的医疗应用客户端；
所述请求方通过所述医疗应用系统向被请求方请求授权，包括：
所述请求方在请求侧的医疗应用客户端通过所述医疗应用服务向被请求侧的医疗应用客户端请求授权；
所述医疗认证授权系统签发授权凭证，包括：
被请求侧的医疗认证授权客户端根据本地存放的所述被请求方的第一私钥签发授权凭证，并将授权凭证返回给被请求侧的医疗应用客户端；
所述将所述医疗认证授权系统签发的授权凭证通过所述医疗应用系统返回给数据请求方，包括：
被请求侧的医疗应用客户端通过所述医疗应用服务将所述授权凭证返回给请求侧的医疗应用客户端；
所述区域医疗数据终端向所述医疗认证授权系统请求所述请求方的身份证书，包括：
所述区域医疗数据终端向请求侧的医疗认证授权客户端请求所述请求方的身份证书。
4.根据权利要求3所述的方法，其特征在于，所述区域医疗公有云根据所述授权凭证中的被请求方信息确定至少一个目标医疗机构私有云，包括：
所述区域医疗公有云从所述授权凭证中获得被请求方ID，并根据被请求方ID查询相对应的目标医疗机构私有云；
所述至少一个目标医疗机构私有云验证所述授权凭证和所述请求方的身份证书，包括：
所述至少一个目标医疗机构私有云从所述授权凭证中获得请求方ID和被请求方ID，根据请求方ID和被请求方ID分别从所述医疗认证服务获取请求方和被请求方的身份信息；根据被请求方身份信息中的第一公钥验证所述授权凭证，根据请求方身份信息中的第二公钥验证所述请求方的身份证书。
5.根据权利要求4所述的方法，其特征在于，所述至少一个目标医疗机构私有云根据所述授权凭证中的被请求方信息，查找对应的目标医疗数据，并通过加密通道将所述目标医疗数据传输给所述区域医疗公有云，包括：
所述目标医疗机构私有云从授权凭证中获取被请求方ID，并从请求方的身份证书中获取请求方的第二公钥；
所述目标医疗机构私有云根据被请求方ID查找对应的目标医疗数据；
所述目标医疗机构私有云生成一会话秘钥，利用会话秘钥对所述目标医疗数据进行加密，得到加密后的目标医疗数据，并利用所述第二公钥对所述会话秘钥进行加密，得到加密后的会话秘钥；
所述目标医疗机构私有云将加密后的目标医疗数据和加密后的会话秘钥返回给所述区域医疗公有云。
6.根据权利要求5所述的方法，其特征在于，所述区域医疗数据终端通过解密通道向请求方展示所述目标医疗数据包括：
所述区域医疗数据终端在接收到加密的所述目标医疗数据和加密的会话秘钥后，调用请求侧的医疗认证授权客户端，以使请求侧的医疗认证授权客户端利用存储的请求方的第二私钥对加密后的会话秘钥进行解密，得到会话秘钥；
所述区域医疗数据终端利用会话秘钥对加密后的目标医疗数据进行解密，得到目标医疗数据，并向请求方展示。
7.根据权利要求1-6任一项所述的方法，其特征在于，在所述区域医疗公有云根据所述授权凭证中的被请求方信息确定至少一个目标医疗机构私有云之前，还包括：
所述区域医疗公有云验证所述授权凭证和所述请求方的身份证书；
若验证通过，则触发根据授权凭证中的被请求方信息确定至少一个目标医疗机构私有云，并向所述至少一个目标医疗机构私有云发送所述数据请求的步骤；若验证未通过，则停止向医疗机构私有云请求数据。
8.根据权利要求3所述的方法，其特征在于，在所述请求方通过所述医疗应用系统向被请求方请求授权之前，还包括：
请求方与被请求方分别通过所述医疗认证授权系统进行身份注册及认证，以得到用于登录所述医疗应用系统的身份信息；
当被请求方在医疗卫生机构产生医疗数据时，医疗卫生机构对产生的医疗数据进行确权处理。
9.根据权利要求8所述的方法，其特征在于，所述请求方与被请求方分别通过所述医疗认证授权系统进行身份注册及认证，包括：
请求方、被请求方分别在其对应侧的医疗认证授权客户端向医疗认证服务进行身份注册；
请求方、被请求方分别在其对应侧的医疗应用客户端登录医疗应用服务；
医疗应用服务验证登录的请求方、被请求方是否为在医疗认证服务注册的合法用户，在验证通过时，为请求方、被请求方分别创建应用内部账号，并将为请求方创建的应用内部账号与请求方在医疗认证服务注册的请求方ID进行绑定，将为被请求方创建的应用内部账号与被请求方在医疗认证服务注册的被请求方ID进行绑定；
所述当被请求方在医疗卫生机构产生医疗数据时，医疗卫生机构对产生的医疗数据进行确权处理，包括：
被请求方产生医疗数据后，医疗卫生机构向医疗认证服务请求所述被请求方的身份信息并验证；
验证通过后，将被请求方的身份信息中的被请求方ID作为医疗数据的所有者标识信息，并将医疗数据及其所有者标识信息记录至所述医疗卫生机构对应的医疗机构私有云；
医疗卫生机构将所述被请求方ID及所述医疗机构私有云的标识信息同步至区域医疗公有云进行存储。
10.一种医疗数据的访问控制系统，其特征在于，包括：请求方、被请求方、医疗卫生机构、医疗认证授权系统、区域医疗公有云、医疗机构私有云、区域医疗数据终端、医疗应用系统；其中：
所述被请求方，用于确认是否授权请求方访问其医疗数据，在确认授权的情况下，向所述医疗认证授权系统请求授权凭证，并将所述医疗认证授权系统签发的授权凭证通过所述医疗应用系统返回给请求方；
所述请求方，还用于接收授权凭证，并将授权凭证发送给所述区域医疗数据终端；
所述区域医疗数据终端，用于：向所述医疗认证授权系统请求所述请求方的身份证书，在所述请求方操作确认后，获得所述请求方的身份证书；并向所述区域医疗公有云发起数据请求，所述数据请求中包括所述授权凭证和请求方的身份证书；
所述区域医疗公有云，用于根据所述授权凭证中的被请求方信息确定至少一个目标医疗机构私有云，并向所述至少一个目标医疗机构私有云发送所述数据请求；
所述至少一个目标医疗机构私有云，用于验证所述授权凭证和所述请求方的身份证书，若验证通过，根据所述数据请求中的被请求方信息，查找对应的目标医疗数据，并通过加密通道将所述目标医疗数据传输给所述区域医疗公有云；
所述区域医疗公有云，还用于将至少一个目标医疗机构私有云通过加密通道传输的目标医疗数据返回给所述区域医疗数据终端；
所述区域医疗数据终端，还用于通过解密通道向请求方展示所述目标医疗数据。
CN202110556901.9A 2021-05-21 2021-05-21 一种医疗数据的访问控制方法及系统 Pending CN115460228A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110556901.9A CN115460228A (zh) 2021-05-21 2021-05-21 一种医疗数据的访问控制方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110556901.9A CN115460228A (zh) 2021-05-21 2021-05-21 一种医疗数据的访问控制方法及系统

Publications (1)

Publication Number Publication Date
CN115460228A true CN115460228A (zh) 2022-12-09

Family

ID=84295344

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110556901.9A Pending CN115460228A (zh) 2021-05-21 2021-05-21 一种医疗数据的访问控制方法及系统

Country Status (1)

Country Link
CN (1) CN115460228A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115842679A (zh) * 2022-12-30 2023-03-24 江西曼荼罗软件有限公司 一种基于数字信封技术的数据传输方法及系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115842679A (zh) * 2022-12-30 2023-03-24 江西曼荼罗软件有限公司 一种基于数字信封技术的数据传输方法及系统

Similar Documents

Publication Publication Date Title
US10055926B2 (en) Architecture for access management
CN110086608B (zh) 用户认证方法、装置、计算机设备及计算机可读存储介质
CN111316278B (zh) 安全身份和档案管理系统
US11055802B2 (en) Methods and apparatus for implementing identity and asset sharing management
US20230087557A1 (en) System for privacy protection during iot secure data sharing and method thereof
US11030297B2 (en) Systems and methods for device and user authorization
KR102202547B1 (ko) 액세스 요청을 검증하기 위한 방법 및 시스템
RU2602790C2 (ru) Безопасный доступ к персональным записям о состоянии здоровья в экстренных ситуациях
EP3376708A1 (en) Anonymous communication system and method for subscribing to said communication system
JP5992535B2 (ja) 無線ｉｄプロビジョニングを実行するための装置及び方法
CN112565294B (zh) 一种基于区块链电子签名的身份认证方法
CN115803735A (zh) 网络中的数据库访问控制服务
CN112908440A (zh) 健康管理数据共享方法、装置及远程医疗平台
CN114912090A (zh) 一种基于区块链的临床检验结果互认方法及系统
CN115378966A (zh) 一种智慧医疗在线服务系统及智慧医疗在线服务方法
KR102605087B1 (ko) 의료 클라우드 환경에서 환자의 의료 데이터 공유 시스템 및 방법
CN115460228A (zh) 一种医疗数据的访问控制方法及系统
EP3664363B1 (en) Device and method for processing public key of user in communication system that includes a plurality of nodes
JP2000331101A (ja) 医療関連情報管理システム及びその方法
Ibrahim et al. A secure framework for medical information exchange (MI-X) between healthcare providers
KR20210135405A (ko) 원격 상담을 통한 의료 기록 관리 방법
US20240127942A1 (en) Systems and methods for sharing healthcare data with healthcare data processors
Sanzi et al. Identification and Adaptive Trust Negotiation in Interconnected Systems
JP2004102524A (ja) データベースのセキュリティシステム及びセキュリティ方法
Bong et al. Hyperledger Fabric-based Reliable Personal Health Information Sharing Model

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination