WO2020151308A1 - 医疗记录权限管理方法、装置、可读存储介质及服务器 - Google Patents

医疗记录权限管理方法、装置、可读存储介质及服务器 Download PDF

Info

Publication number
WO2020151308A1
WO2020151308A1 PCT/CN2019/116643 CN2019116643W WO2020151308A1 WO 2020151308 A1 WO2020151308 A1 WO 2020151308A1 CN 2019116643 W CN2019116643 W CN 2019116643W WO 2020151308 A1 WO2020151308 A1 WO 2020151308A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
authorization
level
authority
tree
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.)
Ceased
Application number
PCT/CN2019/116643
Other languages
English (en)
French (fr)
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.)
Ping An Technology Shenzhen Co Ltd
Original Assignee
Ping An Technology Shenzhen 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 Ping An Technology Shenzhen Co Ltd filed Critical Ping An Technology Shenzhen Co Ltd
Publication of WO2020151308A1 publication Critical patent/WO2020151308A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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

Definitions

  • This application belongs to the field of computer technology, and in particular relates to a medical record authority management method, device, computer non-volatile readable storage medium and server.
  • the medical records generated during the patient’s medical treatment are of great significance to the patient’s subsequent further diagnosis and treatment and medical research conducted by medical institutions.
  • these medical records are also part of the patient's personal privacy, and their privacy needs to be ensured to prevent criminals from obtaining these medical records, which will adversely affect patients.
  • Existing technologies often focus on only one aspect, and it is difficult to take into account the openness and privacy of these medical records at the same time.
  • the embodiments of the present application provide a medical record authority management method, device, computer non-volatile readable storage medium and server to solve the problem that the prior art is difficult to simultaneously consider the openness and privacy of medical records .
  • the first aspect of the embodiments of this application provides a medical record authority management method, which is applied to a blockchain system composed of various terminal devices, and the blockchain system is used to store and manage medical records
  • Each terminal device serves as a node of the blockchain system, and the method may include:
  • An authorization request sent by a first node is received, the authorization request includes a medical record identifier, the identity of the first node, the identity of the second node, and the authority level of the second node, where the first node is Any node in the blockchain system, and the second node is any node in the blockchain system except the first node;
  • the authority level of the first node is the first authority level
  • the identity of the second node and the authority level of the second node are added to the tree authorization information, and the second node is used as A child node of the first node
  • the first authority level is the authority level for viewing target medical records and authorizing other nodes to view the target medical records
  • the target medical records are stored in the blockchain system
  • the authority level of the first node is the second authority level, sending an authorization failure message to the first node, where the second authority level is the authority level for viewing the target medical record.
  • the second aspect of the embodiments of the present application provides a medical record authority management device, which is applied to the above-mentioned blockchain system, and the device may include a module for implementing the steps of the above-mentioned medical record authority management method.
  • the third aspect of the embodiments of the present application provides a computer non-volatile readable storage medium, which is applied to the above-mentioned blockchain system, and the computer non-volatile readable storage medium stores computer readable instructions.
  • the computer-readable instructions are executed by the processor, the steps of the medical record authority management method are realized.
  • the fourth aspect of the embodiments of the present application provides a server, which is applied to the above-mentioned blockchain system, and includes a memory, a processor, and computer-readable instructions stored in the memory and running on the processor, When the processor executes the computer-readable instructions, the steps of the above medical record authority management method are implemented.
  • the embodiment of the application has the beneficial effect that the embodiment of the application controls the disclosure range of medical records within a limited range composed of various layers of trust chains, and ensures that the privacy of patients is not obtained by criminals.
  • the medical records are shared among controllable trust nodes, so as to take into account the openness and privacy of these medical records.
  • Figure 1 is a schematic diagram of a blockchain system in an embodiment of the application
  • Figure 2 is a schematic diagram of tree authorization information
  • FIG. 3 is a schematic flowchart of a method for managing medical records in an embodiment of the application during authorization
  • FIG. 4 is a schematic flow chart of a medical record management method in an embodiment of the application when the authorization is cancelled;
  • Figure 5 is a schematic diagram of deauthorizing a node in the tree authorization information
  • FIG. 6 is a schematic flowchart of a medical record management method in an embodiment of the application when the modification is authorized
  • Figure 7 is a schematic diagram of modifying authorization to a node in tree authorization information
  • FIG. 8 is a schematic flowchart of a medical record management method in an embodiment of the application considering authorization conflicts when performing authorization
  • Figure 9 is a schematic diagram of the first handling situation when authorization conflicts
  • Figure 10 is a schematic diagram of the second processing situation when authorization conflicts
  • FIG. 11 is a structural diagram of an embodiment of a medical record authority management device in an embodiment of the application.
  • FIG. 12 is a schematic block diagram of a server in an embodiment of this application.
  • the embodiments of the present application are applied to a blockchain system composed of various terminal devices.
  • the blockchain system is used to store and manage medical records, and each terminal device serves as a node of the blockchain system.
  • Figure 1 shows a schematic diagram of the blockchain system.
  • Each medical institution and individual users can register in the system. When medical institutions or individual users register in the system, they first send a registration request to the server through terminal devices such as mobile phones, tablet computers, or desktop computers.
  • the registration request may include, but is not limited to, the type of registration, identification and related information. Supporting documents, etc.
  • the type of registration can be divided into two types: medical institution registration and individual user registration.
  • the identification can be the business license number or business management registration number of the medical institution
  • the relevant certification documents can be the medical institution A scanned copy of the business license or a scanned copy of the business administration registration, etc.
  • the identification can be the user’s ID number or medical insurance card number, etc.
  • the relevant certification document can be a scanned copy of the user’s ID card or Scanned copy of medical insurance card, etc.
  • the server will assign an identity certificate (which can be divided into two types: institutional identity certificate and personal identity certificate) and keys for the registrant.
  • the terminal device used by the medical institution or individual user becomes a node of the blockchain system.
  • the medical personnel of the medical institution After the medical personnel of the medical institution have diagnosed the patient (including but not limited to B-ultrasound, CT, X-ray or nuclear magnetic resonance and other test items), they can use the terminal equipment designated by the medical institution (one of the blockchain systems Node) upload the corresponding medical records (including but not limited to basic patient information, medical films, reports, etc.) to the server, and the server stores them in the blockchain system to ensure their security and prevent them from being tampered with possibility. After the medical records are stored in the blockchain system, only the medical institution that uploaded the materials and the patients themselves have the authority to view them.
  • the patient initiates a medical record viewing request to the server through his terminal device (a node in the blockchain system), and the medical record viewing request carries his Personal identity certificate and key signature.
  • the server verifies the personal identity certificate and key signature. If the verification is successful, it will open the blockchain access service interface to the patient’s terminal
  • the device can read its own medical records stored in the blockchain system by calling the blockchain access service interface, and display it to the patient for viewing.
  • the viewing process of a medical institution is similar, but it should be noted that there may be many medical personnel in a medical institution, but not everyone has the authority to view the patient’s medical records. Therefore, when medical personnel pass the medical
  • the terminal device designated by the institution is used to view medical records in the name of the medical institution
  • the terminal device of the medical institution will first confirm its authority. For example, the account of the medical staff can be used to confirm the medical staff’s access to the terminal equipment. Identity and check the permission table to determine whether it has permission to view the patient’s medical records.
  • the terminal equipment of the medical institution When the terminal equipment of the medical institution confirms that the current medical staff has the authority to view the patient’s medical records, it initiates a medical record viewing request to the server.
  • the medical record viewing request carries its institutional identity certificate and key signature, and the server is receiving After receiving the medical record viewing request, verify the identity certificate and key signature of the institution. If the verification is successful, open the blockchain access service interface for it, and the terminal equipment of the medical institution can access the service by calling the blockchain The interface reads the patient's medical record stored in the blockchain system and displays it to current medical personnel for viewing.
  • the patient also has the authorization to view the medical records to other medical institutions or individual users.
  • authorized to a medical institution it can be authorized to the entire medical institution or only to one of the medical institutions. Or a few specific medical personnel.
  • Patient A initiates an authorization request on the authorization chain to authorize a report or a report within a period of time to doctor B in medical institution H.
  • the authorization request carries its personal identity certificate and key signature.
  • the server verifies the personal identity certificate and key signature. If the verification is successful, it adds viewing authority to the medical institution H , And send this authorization notification to the terminal equipment of the medical institution H. After receiving the authorization notification, the terminal equipment of the medical institution H adds the authorization to the aforementioned authorization table.
  • Doctor B logs in to the terminal equipment of medical institution H and requests to view the medical records of patient A.
  • the terminal equipment of medical institution H queries the authority table to determine whether he has the authority to view the medical records of patient A. If it is found that doctor B has the authority to view patients A's permission for medical records will send a notification to the server.
  • the server queries the corresponding authorization record in the authorization chain, and if the authorization record is found, it will feed back a successful query message to the terminal equipment of the medical institution H.
  • the terminal device of medical institution H initiates a medical record viewing request to the server.
  • the medical record viewing request carries its institution identity certificate and key signature.
  • the server checks the identity of the institution in it. The certificate and the key signature are verified. If the verification is successful, the blockchain access service interface will be opened.
  • the terminal equipment of the medical institution H can read and store in the blockchain system by calling the blockchain access service interface Patient A's medical records.
  • the terminal device of medical institution H analyzes the read medical records, and displays the final result to doctor B for review.
  • the patient can also initiate a cancellation request on the authorization chain at any time to cancel the previous authorization. After the authorization is cancelled, the previously authorized medical institution or individual user will not be able to view the patient's medical records.
  • this embodiment of the application provides a method for managing medical record authority using a hierarchical authorization mode.
  • the patient to which the medical record belongs has the highest authorization level, and the terminal device used is the entire authorization
  • the first-level node of the system the first-level node can authorize other users and medical institutions, and the users and medical institutions authorized by the first-level node serve as the second-level nodes of the entire authorization system.
  • the first-level node can select the authorization level when authorizing the second-level node.
  • two types of authorization modes are provided.
  • the first type of authorization is full authorization, and authorized users and medical institutions have The first level of authority can not only view the above medical records, but also further authorize other users and medical institutions.
  • the second type of authorization is partial authorization.
  • the authorized users and medical institutions have the second level of authority and can view the above medical records. However, it is not possible to continue to authorize other users and medical institutions. Users and medical institutions authorized by the second-level nodes serve as the third-level nodes of the entire authorization system. Among them, when the second-level node authorizes the third-level node, it can also continue to select the authorization level.
  • the specific authorization method is similar to the above content, and will not be repeated here. Repeating the authorization process of the upper-level nodes above to the next-level nodes can finally form the tree-shaped authorization information as shown in FIG.
  • the tree-shaped authorization information records the authorization level relationship between the nodes, and The authority level of each node, where the node represented by a circle is the node that obtains the first authority level, and the node represented by the square is the node that obtains the second authority level.
  • the medical record authority management method may specifically include the following process in which one node authorizes another node:
  • Step S301 Receive an authorization request sent by the first node.
  • the authorization request includes a medical record identifier, the identity of the first node, the identity of the second node, and the authority level of the second node, and the first node is any of the blockchain systems A node, and the second node is any node in the blockchain system except the first node.
  • Step S302 Determine the tree-shaped authorization information corresponding to the medical record identifier in the preset authority information record.
  • the authorization information record stores the tree authorization information corresponding to each medical record identifier, and each medical record identifier has unique tree authorization information corresponding to it. According to the medical record identifier included in the authorization request, that is, The tree authorization information corresponding to the authorization information record can be determined.
  • Step S303 Query the authority level of the first node in the tree authorization information according to the identity of the first node.
  • step S304 is performed, and if the authority level of the first node is the second authority level, step S305 is performed.
  • the first authority level is the authority level for viewing the target medical record and authorizing other nodes to view the target medical record
  • the second authority level is the authority level for viewing the target medical record
  • the target medical record is the The medical record corresponding to the medical record identifier stored in the blockchain system.
  • Step S304 Add the identity of the second node and the authority level of the second node to the tree authorization information, and use the second node as a child node of the first node.
  • the authority level of the first node is the first authority level, it can further authorize other nodes to view the target medical record, so its authorization request will be approved by the server, and the server will identify the identity of the second node And the authority level of the second node is added to the tree authorization information, and the second node is used as a child node of the first node. At this time, the second node also has a corresponding authority level.
  • Step S305 Send an authorization failure message to the first node.
  • the authority level of the first node is the second authority level, it does not further authorize other nodes to view the target medical record, so its authorization request will be rejected by the server, and the server will send it an authorization failure message , Inform it that it does not have the authority to further authorize other nodes to view the target medical record.
  • the parent node of the superior can cancel the authorization of its child nodes of all levels at any time.
  • the medical record authority management method may further include the following process in which one node cancels the authorization of another node:
  • Step S401 Receive an authorization cancellation request sent by the first node.
  • the authorization cancellation request includes the medical record identification, the identification identification of the first node, and the identification identification of the second node.
  • Step S402 Determine tree authorization information corresponding to the medical record identifier in the authority information record.
  • step S402 is similar to the process of step S302, and the specific process can refer to the foregoing content, which will not be repeated here.
  • Step S403 Determine whether the second node is a child node of the first node according to the tree authorization information.
  • step S404 is executed, and if the second node is not a child node of the first node, step S405 is executed.
  • Step S404 Delete the second node and each child node of the second node from the tree authorization information.
  • the second node is a child node of the first node
  • the first node can cancel the authorization of the second node. Therefore, the authorization cancellation request will be approved by the server, and the server will The second node and each child node of the second node are deleted from the tree authorization information. At this time, the second node and each child node of the second node will no longer have the corresponding authority level and cannot View the target medical record.
  • Step S405 Send an authorization cancellation failure message to the first node.
  • the medical record authority management method may further include the following process of a node to modify and authorize another node:
  • Step S601 Receive a modification authorization request sent by the first node.
  • the modification authorization request includes the medical record identification, the identification identification of the first node, the identification identification of the second node, and the authorization modification type.
  • Step S602 Determine tree authorization information corresponding to the medical record identifier in the authority information record.
  • step S602 is similar to the process of step S302, and the specific process can refer to the foregoing content, which will not be repeated here.
  • Step S603 Determine whether the second node is a child node of the first node according to the tree authorization information.
  • step S604 is executed, and if the second node is not a child node of the first node, step S605 is executed.
  • Step S604 Modify the authority level of the second node according to the authorized modification type.
  • the first node can modify the authorization to the second node, so its modification authorization request will be approved by the server, and the server will follow the authorization
  • the modification type modifies the authority level of the second node.
  • the authorization modification type is the first modification type
  • the authority level of the second node is modified to the first authority level
  • the authorization modification type is the second modification type
  • the Each child node of the second node is deleted from the tree authorization information, and the authority level of the second node is modified to the second authority level.
  • node 1 changes the authorization to node 3 and changes the first permission level of node 3 to the second permission level
  • node 3 still has the permission to view medical records, but cannot continue to other users
  • the sub-nodes at all levels under it will lose the right to view medical records, that is, the sub-nodes at all levels under node 3 will be deleted from the authorization tree structure.
  • the result is shown in Figure 7. .
  • Step S605 Send a modification authorization failure message to the first node.
  • the medical record authority management method may further include the following process in which one node authorizes another node in consideration of authorization conflicts:
  • Step S801 Receive an authorization request sent by the first node.
  • Step S802 Determine the tree-shaped authorization information corresponding to the medical record identifier in the preset authorization information record.
  • Step S803 Query the authority level of the first node in the tree authorization information according to the identity of the first node.
  • step S801 to step S803 is similar to the process from step S301 to step S303, and the specific process can refer to the foregoing content, which will not be repeated here.
  • step S804 If the authority level of the first node is the first authority level, step S804 and subsequent steps are executed, and if the authority level of the first node is the second authority level, step S807 is executed.
  • Step S804 Determine whether the second node is already in the tree authorization information.
  • step S805 If the second node is already in the tree authorization information, step S805 and subsequent steps are executed, and if the second node is not in the tree authorization information, step S806 is executed.
  • Step S805 Determine whether the level of the first node is higher than the level of the third node according to the tree authorization information.
  • the third node is a parent node of the second node.
  • step S806 is performed, and if the level of the first node is lower than or equal to the level of the third node, step S807 is performed.
  • Step S806 Change the second node to a child node of the first node, and adjust the authority level of the second node according to the authorization request.
  • node 1 if node 1 authorizes node 7 again, there is a conflict with node 4’s authorization to node 7. At this time, since node 1 has a higher level than node 4, take node 1’s authorization as If the authorization level of node 1 to node 7 is the second level of authority, node 7 still has the authority to view the above-mentioned medical records, and it has changed from a third-level node to a second-level node, but it cannot continue to access other users and medical institutions When authorized, the sub-nodes of node 7 at all levels lose their viewing rights to the above-mentioned medical records, that is, the sub-nodes at all levels of node 7 will be deleted from the authorization tree structure. The result is shown in FIG. 9.
  • node 1 grants node 7 the first permission level
  • node 7 still has the permission to view the above-mentioned medical records, and it has changed from a third-level node to a second-level node, and node 7 can continue to access other users and medical institutions
  • the sub-nodes at all levels under node 7 make corresponding changes accordingly, and the result is shown in Figure 10.
  • Step S807 Send an authorization failure message to the first node.
  • step S807 is similar to the process of step S305, and the specific process can refer to the foregoing content, which will not be repeated here.
  • each medical record is set up with corresponding tree-shaped authorization information
  • the tree-shaped authorization information records the authorization level relationship between each node and the authority level of each node.
  • nodes with the first level of authority can view medical records and authorize other nodes to view medical records, that is, they have both viewing and authorized permissions
  • nodes with the second level of authority can only view medical records, that is, only View permissions but not authorized permissions.
  • a node with authorization authority can grant related authority (first authority level or second authority level) to other nodes it trusts according to actual conditions, and add new trusted nodes to the tree authorization information.
  • the disclosure scope of medical records is controlled within a limited range composed of various layers of trust chains, and the medical records of patients are placed in controllable trust nodes on the premise that the privacy of patients is not obtained by criminals. Sharing between them, so as to take into account the openness and privacy of these medical records.
  • FIG. 11 shows a structural diagram of an embodiment of a medical record authority management device provided in an embodiment of the present application.
  • a medical record authority management device may include:
  • the authorization request receiving module 1101 is configured to receive an authorization request sent by the first node, the authorization request including the medical record identifier, the identity of the first node, the identity of the second node, and the authority of the second node grade;
  • the tree-shaped authorization information determining module 1102 is used to determine the tree-shaped authorization information corresponding to the medical record identifier in a preset authorization information record, and the tree-shaped authorization information records the authorization level relationship between various nodes, And the authority level of each node;
  • the authority level query module 1103 is configured to query the authority level of the first node in the tree authorization information according to the identity of the first node;
  • the first processing module 1104 is configured to, if the authority level of the first node is the first authority level, add the identity of the second node and the authority level of the second node to the tree authorization information,
  • the second node is used as a child node of the first node, and the first authority level is the authority level for viewing target medical records and authorizing other nodes to view the target medical records.
  • the second processing module 1105 is configured to send an authorization failure message to the first node if the authority level of the first node is the second authority level, and the second authority level is the authority level for viewing the target medical record .
  • the medical record authority management device may further include:
  • a modification authorization request receiving module configured to receive a modification authorization request sent by the first node, the modification authorization request including the medical record identification, the identification identification of the first node, and the identification identification of the second node And the type of authorized modification;
  • the first judgment module is configured to judge whether the second node is a child node of the first node according to the tree authorization information
  • a third processing module configured to modify the authority level of the second node according to the authorized modification type if the second node is a child node of the first node;
  • the fourth processing module is configured to send a modification authorization failure message to the first node if the second node is not a child node of the first node.
  • the third processing module may include:
  • a first modification unit configured to modify the authority level of the second node to the first authority level if the authorized modification type is the first modification type
  • the second modification unit is configured to, if the authorized modification type is the second modification type, delete each child node of the second node from the tree-shaped authorization information, and change the authority level of the second node Modified to the second permission level.
  • the medical record authority management device may further include:
  • the authorization cancellation request receiving module is configured to receive the authorization cancellation request sent by the first node, and the authorization cancellation request includes the medical record identification, the identification identification of the first node, and the identification identification of the second node ;
  • a fifth processing module configured to delete the second node and each child node of the second node from the tree authorization information if the second node is a child node of the first node;
  • the sixth processing module is configured to send an authorization cancellation failure message to the first node if the second node is not a child node of the first node.
  • the medical record authority management device may further include:
  • the second judgment module is used to judge whether the second node is already in the tree authorization information
  • the third judgment module is configured to judge whether the level of the first node is higher than the level of the third node according to the tree authorization information if the second node is already in the tree authorization information, the The third node is the parent node of the second node;
  • the seventh processing module is configured to, if the level of the first node is higher than the level of the third node, change the second node to a child node of the first node, and perform processing according to the authorization request The authority level of the second node is adjusted;
  • the eighth processing module is configured to send an authorization failure message to the first node if the level of the first node is lower than or equal to the level of the third node.
  • FIG. 12 shows a schematic block diagram of a server provided by an embodiment of the present application. For ease of description, only parts related to the embodiment of the present application are shown.
  • the server 12 may include: a processor 120, a memory 121, and computer-readable instructions 122 stored in the memory 121 and running on the processor 120, such as executing the aforementioned medical records Computer readable instructions for rights management methods.
  • the processor 120 executes the computer-readable instructions 122 to implement the steps in the foregoing medical record authority management method embodiments, or the processor 120 executes the computer-readable instructions 122 to implement the foregoing device embodiments
  • the computer-readable instructions 122 may be divided into one or more modules/units, and the one or more modules/units are stored in the memory 121 and executed by the processor 120.
  • the one or more modules/units may be a series of computer-readable instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer-readable instructions 122 in the server 12.
  • the processor 120 may be a central processing unit (Central Processing Unit, CPU), it can also be other general-purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc.
  • the general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like.
  • the storage 121 may be an internal storage unit of the server 12, such as a hard disk or a memory of the server 12.
  • the memory 121 may also be an external storage device of the server 12, for example, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), or a Secure Digital (SD) card equipped on the server 12, Flash memory card Card) etc. Further, the storage 121 may also include both an internal storage unit of the server 12 and an external storage device.
  • the memory 121 is used to store the computer-readable instructions and other instructions and data required by the server 12.
  • the memory 121 may also be used to temporarily store data that has been output or will be output.
  • Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory.
  • Volatile memory may include random access memory (RAM) or external cache memory.
  • RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous chain Channel (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Storage Device Security (AREA)

Abstract

一种医疗记录权限管理方法、装置、计算机非易失性可读存储介质及服务器。所述方法应用于由各个终端设备组成的区块链系统中，所述区块链系统用于对医疗记录进行管理，每个终端设备均作为所述区块链系统的一个节点，所述方法接收第一节点发送的授权请求（S301）；在预设的权限信息记录中确定与所述医疗记录标识对应的树状授权信息（S302）；根据所述第一节点的身份标识在所述树状授权信息中查询所述第一节点的权限等级（S303）；若为第一权限等级，将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中，并将所述第二节点作为所述第一节点的子节点（S304）；若为第二权限等级，则向所述第一节点发送授权失败消息（S305）。

Description

医疗记录权限管理方法、装置、可读存储介质及服务器
本申请要求于2019年1月24日提交中国专利局、申请号为201910068139.2、发明名称为“医疗记录权限管理方法、装置、可读存储介质及服务器”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请属于计算机技术领域，尤其涉及一种医疗记录权限管理方法、装置、计算机非易失性可读存储介质及服务器。
 背景技术
患者就医过程中所产生的医疗记录，对于该患者后续的进一步诊治，以及医疗机构进行医学研究均具有重要意义，为了充分发挥这些医疗记录的作用，需要保证这些医疗记录具有一定的开放性，以保证相关人员及机构可以通过合法方式获得这些医疗记录。但是，另一方面，这些医疗记录也是患者个人隐私的一部分，需要保证其私密性，以防不法分子获取这些医疗记录从而对患者产生不良的影响。现有技术中往往只侧重于其中的一个方面，难以同时兼顾这些医疗记录的开放性以及私密性。
 技术问题
有鉴于此，本申请实施例提供了一种医疗记录权限管理方法、装置、计算机非易失性可读存储介质及服务器，以解决现有技术难以同时兼顾医疗记录的开放性以及私密性的问题。
 技术解决方案
本申请实施例的第一方面提供了一种医疗记录权限管理方法，所述方法应用于由各个终端设备组成的区块链系统中，所述区块链系统用于对医疗记录进行存储和管理，每个终端设备均作为所述区块链系统的一个节点，所述方法可以包括：
接收第一节点发送的授权请求，所述授权请求中包括医疗记录标识、所述第一节点的身份标识、第二节点的身份标识以及所述第二节点的权限等级，所述第一节点为所述区块链系统中的任意一个节点，所述第二节点为所述区块链系统中除所述第一节点之外的任意一个节点；
在预设的权限信息记录中确定与所述医疗记录标识对应的树状授权信息，所述树状授权信息中记录了各个节点之间的授权层级关系，以及各个节点的权限等级；
根据所述第一节点的身份标识在所述树状授权信息中查询所述第一节点的权限等级；
若所述第一节点的权限等级为第一权限等级，则将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中，并将所述第二节点作为所述第一节点的子节点，所述第一权限等级为查看目标医疗记录以及授权其它节点查看所述目标医疗记录的权限等级，所述目标医疗记录为在所述区块链系统中存储的与所述医疗记录标识对应的医疗记录；
若所述第一节点的权限等级为第二权限等级，则向所述第一节点发送授权失败消息，所述第二权限等级为查看所述目标医疗记录的权限等级。
本申请实施例的第二方面提供了一种医疗记录权限管理装置，应用于上述区块链系统中，所述装置可以包括用于实现上述医疗记录权限管理方法的步骤的模块。
本申请实施例的第三方面提供了一种计算机非易失性可读存储介质，应用于上述区块链系统中，所述计算机非易失性可读存储介质存储有计算机可读指令，所述计算机可读指令被处理器执行时实现上述医疗记录权限管理方法的步骤。
本申请实施例的第四方面提供了一种服务器，应用于上述区块链系统中，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时实现上述医疗记录权限管理方法的步骤。
 有益效果
本申请实施例与现有技术相比存在的有益效果是：本申请实施例将医疗记录的公开范围控制在一个由各层信任链构成的有限范围内，在保证患者的隐私不被不法分子获取的前提下将其医疗记录在可控的信任节点间进行共享，从而同时兼顾这些医疗记录的开放性以及私密性。
 附图说明
图1为本申请实施例中一种区块链系统的示意图；
图2为树状授权信息的示意图；
图3为本申请实施例中一种医疗记录管理方法在进行授权时的示意流程图；
图4为本申请实施例中一种医疗记录管理方法在进行取消授权时的示意流程图；
图5为对树状授权信息中某一节点取消授权的示意图；
图6为本申请实施例中一种医疗记录管理方法在进行修改授权时的示意流程图；
图7为对树状授权信息中某一节点修改授权的示意图；
图8为本申请实施例中一种医疗记录管理方法在进行授权时考虑授权冲突情况的示意流程图；
图9为授权产生冲突时第一种处理情况的示意图；
图10为授权产生冲突时第二种处理情况的示意图；
图11为本申请实施例中一种医疗记录权限管理装置的一个实施例结构图；
图12为本申请实施例中一种服务器的示意框图。
 本发明的实施方式
本申请实施例应用于由各个终端设备组成的区块链系统中，所述区块链系统用于对医疗记录进行存储和管理，每个终端设备均作为所述区块链系统的一个节点。图1所示为即为所述区块链系统的示意图，各个医疗机构及个人用户均可在该系统中进行注册。当医疗机构或者个人用户在该系统中进行注册时，首先通过手机、平板电脑、或者台式机等终端设备向服务器发送注册请求，在该注册请求中可以包括但不限于注册类型，身份标识及相关证明文件等等。
其中，注册类型可以分为医疗机构注册及个人用户注册两种，对于医疗机构而言，身份标识可以为该医疗机构的营业执照号码或者工商管理登记号码等等，相关证明文件可以为该医疗机构的营业执照扫描件或者工商管理登记扫描件等等，对于个人用户而言，身份标识可以为该用户的身份证号码或者医保卡号码等等，相关证明文件可以为该用户的身份证扫描件或者医保卡扫描件等等。经后台核对无误后，服务器会为注册者分配身份证书（可分为机构身份证书及个人身份证书两种）及密钥。在注册完成之后，医疗机构或个人用户所使用的终端设备即成为所述区块链系统的一个节点。
医疗机构的医疗人员在对患者进行过诊断（包括但不限于B超、CT、X线或者核磁共振等检测项目）后，可以通过医疗机构指定的终端设备（所述区块链系统中的一个节点）将相应的医疗记录（包括但不限于患者基本信息、医疗胶片以及报告等）上传至服务器中，服务器将其存储至所述区块链系统中以保证其安全性，杜绝其被篡改的可能性。当医疗记录被存储至所述区块链系统中之后，只有上传材料的医疗机构以及患者本人才有权限对其进行查看。
现以患者本人的查看医疗记录的过程为例进行说明：患者通过其终端设备（所述区块链系统中的一个节点）向服务器发起医疗记录查看请求，在该医疗记录查看请求中携带了其个人身份证书以及密钥签名，服务器在接收到该医疗记录查看请求后，对其中的个人身份证书以及密钥签名进行验证，若验证成功，则对其开放区块链访问服务接口，患者的终端设备可以通过调用该区块链访问服务接口读取存储在所述区块链系统中本人的医疗记录，并展示给患者查看。
医疗机构的查看过程与之类似，但需要注意的是，一般在一个医疗机构中可能会有众多的医疗人员，但不是所有人都有权限查看该患者的医疗记录，因此，当医疗人员通过医疗机构指定的终端设备以该医疗机构的名义去查看医疗记录时，医疗机构的终端设备会首先对其权限进行确认，例如，可以通过该医疗人员登录终端设备时使用的账号来确认该医疗人员的身份，并通过查询权限表来确定其是否有查看该患者医疗记录的权限。
当医疗机构的终端设备确认当前医疗人员具有查看该患者医疗记录的权限时，即向服务器发起医疗记录查看请求，在该医疗记录查看请求中携带了其机构身份证书以及密钥签名，服务器在接收到该医疗记录查看请求后，对其中的机构身份证书以及密钥签名进行验证，若验证成功，则对其开放区块链访问服务接口，医疗机构的终端设备可以通过调用该区块链访问服务接口读取存储在所述区块链系统中该患者的医疗记录，并展示给当前医疗人员查看。
进一步地，患者还具有将医疗记录的查看权限授权给其它的医疗机构或者个人用户，其中，在授权给医疗机构时，既可以授权给整个医疗机构，也可以仅授权给该医疗机构中的一个或几个具体医疗人员。
现以患者将医疗记录的查看权限授权给其它医疗机构的某一具体医疗人员为例进行详细说明：
1、患者A在授权链上发起一个授权请求，将某报告或一段时间内的报告授权给医疗机构H中的医生B。在该授权请求中携带了其个人身份证书以及密钥签名，服务器在接收到该授权请求后，对其中的个人身份证书以及密钥签名进行验证，若验证成功，则为医疗机构H添加查看权限，并向医疗机构H的终端设备发送这一授权通知，医疗机构H的终端设备在接收到授权通知后，将该授权添加入前述授权表中。
2、医生B登录医疗机构H的终端设备，请求查看患者A的医疗记录，医疗机构H的终端设备查询权限表来确定其是否有查看患者A医疗记录的权限，若查询到医生B具有查看患者A医疗记录的权限，则发送通知至服务器。
3、服务器在授权链中查询相应的授权记录，若查询到授权记录，则反馈查询成功的消息至医疗机构H的终端设备。
4、医疗机构H的终端设备向服务器发起医疗记录查看请求，在该医疗记录查看请求中携带了其机构身份证书以及密钥签名，服务器在接收到该医疗记录查看请求后，对其中的机构身份证书以及密钥签名进行验证，若验证成功，则对其开放区块链访问服务接口，医疗机构H的终端设备可以通过调用该区块链访问服务接口读取存储在所述区块链系统中患者A的医疗记录。
5、医疗机构H的终端设备对读取的医疗记录进行解析，并将最终结果展示给医生B查看。
患者将医疗记录的查看权限授权给其它个人用户的过程与之类似，此处不再赘述。
患者还可以随时通过在授权链上发起取消授权请求，对之前的授权进行取消操作，授权取消后，之前被授权的医疗机构或者个人用户将无法查看到患者的医疗记录。
针对以上所述的区块链系统，本申请实施例提供了一种采用层级的授权模式的医疗记录权限管理方法，医疗记录所属的患者本人拥有最高的授权层级，其使用的终端设备作为整个授权体系的一级节点，一级节点可以对其它用户及医疗机构进行授权，得到一级节点授权的用户及医疗机构作为整个授权体系的二级节点。其中，一级节点在对二级节点进行授权时，可以对授权等级进行选择，在本实施例中提供了两类授权模式，第一类授权为完全授权，得到授权的用户及医疗机构拥有第一权限等级，不仅可以查看上述医疗记录，还可以进一步对其它用户及医疗机构进行授权，第二类授权为部分授权，得到授权的用户及医疗机构拥有第二权限等级，可以查看上述医疗记录，但无法继续对其它用户及医疗机构进行授权，得到二级节点授权的用户及医疗机构作为整个授权体系的三级节点。其中，二级节点在对三级节点进行授权时，也可以继续对授权等级进行选择，具体的授权方式与上述内容类似，此处不再赘述。不断重复以上的上一级节点对下一级节点的授权过程，最终可以形成如图2所示的树状授权信息，所述树状授权信息中记录了各个节点之间的授权层级关系，以及各个节点的权限等级，其中，使用圆形表示的节点为得到第一权限等级的节点，使用方形表示的节点为得到第二权限等级的节点。
如图3所示，所述医疗记录权限管理方法具体可以包括以下所述的一个节点对另一个节点进行授权的过程：
步骤S301、接收第一节点发送的授权请求。
所述授权请求中包括医疗记录标识、所述第一节点的身份标识、第二节点的身份标识以及所述第二节点的权限等级，所述第一节点为所述区块链系统中的任意一个节点，所述第二节点为所述区块链系统中除所述第一节点之外的任意一个节点。
步骤S302、在预设的权限信息记录中确定与所述医疗记录标识对应的树状授权信息。
在所述权限信息记录中存储着与各个医疗记录标识对应的树状授权信息，每个医疗记录标识均有唯一的树状授权信息与之对应，根据所述授权请求中包括的医疗记录标识即可在所述权限信息记录中确定与其对应的树状授权信息。
步骤S303、根据所述第一节点的身份标识在所述树状授权信息中查询所述第一节点的权限等级。
若所述第一节点的权限等级为第一权限等级，则执行步骤S304，若所述第一节点的权限等级为第二权限等级，则执行步骤S305。
所述第一权限等级为查看目标医疗记录以及授权其它节点查看所述目标医疗记录的权限等级，所述第二权限等级为查看所述目标医疗记录的权限等级，所述目标医疗记录为在所述区块链系统中存储的与所述医疗记录标识对应的医疗记录。
步骤S304、将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中，并将所述第二节点作为所述第一节点的子节点。
若所述第一节点的权限等级为第一权限等级，则其可以进一步授权其它节点查看所述目标医疗记录，因此其授权请求将得到服务器的认可，服务器会将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中，并将所述第二节点作为所述第一节点的子节点，此时，所述第二节点也具有了对应的权限等级。
步骤S305、向所述第一节点发送授权失败消息。
若所述第一节点的权限等级为第二权限等级，则其并没有进一步授权其它节点查看所述目标医疗记录的权限，因此其授权请求将被服务器拒绝，服务器将会向其发送授权失败消息，告知其并不具备进一步授权其它节点查看所述目标医疗记录的权限。
进一步地，上级的父节点可以随时对其各级子节点取消授权。如图4所示，所述医疗记录权限管理方法还可以包括以下所述的一个节点对另一个节点进行取消授权的过程：
步骤S401、接收所述第一节点发送的取消授权请求。
所述取消授权请求中包括所述医疗记录标识、所述第一节点的身份标识以及所述第二节点的身份标识。
步骤S402、在所述权限信息记录中确定与所述医疗记录标识对应的树状授权信息。
步骤S402的过程与步骤S302的过程类似，具体过程可参照前述内容，此处不再赘述。
步骤S403、根据所述树状授权信息判断所述第二节点是否为所述第一节点的子节点。
若所述第二节点为所述第一节点的子节点，则执行步骤S404，若所述第二节点不是所述第一节点的子节点，则执行步骤S405。
步骤S404、将所述第二节点以及所述第二节点的各个子节点从所述树状授权信息中删除。
若所述第二节点为所述第一节点的子节点，则所述第一节点可以取消对所述第二节点的授权，因此其取消授权请求将得到服务器的认可，服务器会将所述第二节点以及所述第二节点的各个子节点从所述树状授权信息中删除，此时，所述第二节点以及所述第二节点的各个子节点将不再具有对应的权限等级，无法查看所述目标医疗记录。
如图2所示，若节点1取消对节点3的授权，则节点3及其下的各级子节点均丧失对医疗记录的查看权限，也即节点3及其下的各级子节点将从该授权树状结构中被删除，结果如图5所示。
步骤S405、向所述第一节点发送取消授权失败消息。
若所述第二节点不是所述第一节点的子节点，则所述第一节点无法取消对所述第二节点的授权，因此其取消授权请求会被服务器拒绝，服务器将会向其发送取消授权失败消息，告知其并不具备取消所述第二节点的授权的权限。此时，所述第二节点仍然具有原有的权限等级。进一步地，上级的父节点可以随时对其各级子节点修改授权。如图6所示，所述医疗记录权限管理方法还可以包括以下所述的一个节点对另一个节点进行修改授权的过程：
步骤S601、接收所述第一节点发送的修改授权请求。
所述修改授权请求中包括所述医疗记录标识、所述第一节点的身份标识、所述第二节点的身份标识以及授权修改类型。
步骤S602、在所述权限信息记录中确定与所述医疗记录标识对应的树状授权信息。
步骤S602的过程与步骤S302的过程类似，具体过程可参照前述内容，此处不再赘述。
步骤S603、根据所述树状授权信息判断所述第二节点是否为所述第一节点的子节点。
若所述第二节点为所述第一节点的子节点，则执行步骤S604，若所述第二节点不是所述第一节点的子节点，则执行步骤S605。
步骤S604、按照所述授权修改类型对所述第二节点的权限等级进行修改。
若所述第二节点为所述第一节点的子节点，则所述第一节点可以修改对所述第二节点的授权，因此其修改授权请求将得到服务器的认可，服务器将按照所述授权修改类型对所述第二节点的权限等级进行修改。
具体地，若所述授权修改类型为第一修改类型，则将所述第二节点的权限等级修改为所述第一权限等级；若所述授权修改类型为第二修改类型，则将所述第二节点的各个子节点从所述树状授权信息中删除，并将所述第二节点的权限等级修改为所述第二权限等级。
如图2所示，若节点1更改对节点3的授权，将对节点3的第一权限等级修改为第二权限等级，则节点3仍然具有对医疗记录的查看权限，但无法继续对其它用户及医疗机构进行授权，其下的各级子节点均丧失对医疗记录的查看权限，也即节点3其下的各级子节点将从该授权树状结构中被删除，结果如图7所示。
步骤S605、向所述第一节点发送修改授权失败消息。
若所述第二节点不是所述第一节点的子节点，则所述第一节点无法修改对所述第二节点的授权，因此其修改授权请求会被服务器拒绝，服务器将会向其发送修改授权失败消息，告知其并不具备修改所述第二节点的授权的权限。此时，所述第二节点仍然具有原有的权限等级。特殊地，当出现授权冲突的情况时，以最高层级的节点的授权为准。如图8所示，所述医疗记录权限管理方法还可以包括以下所述的考虑授权冲突情况的一个节点对另一个节点进行授权的过程：
步骤S801、接收第一节点发送的授权请求。
步骤S802、在预设的权限信息记录中确定与所述医疗记录标识对应的树状授权信息。
步骤S803、根据所述第一节点的身份标识在所述树状授权信息中查询所述第一节点的权限等级。
步骤S801至步骤S803的过程与步骤S301至步骤S303的过程类似，具体过程可参照前述内容，此处不再赘述。
若所述第一节点的权限等级为第一权限等级，则执行步骤S804及其后续步骤，若所述第一节点的权限等级为第二权限等级，则执行步骤S807。
步骤S804、判断所述第二节点是否已在所述树状授权信息中。
若所述第二节点已在所述树状授权信息中，则执行步骤S805及其后续步骤，若所述第二节点不在所述树状授权信息中，则执行步骤S806。
步骤S805、根据所述树状授权信息判断所述第一节点的层级是否高于第三节点的层级。
所述第三节点为所述第二节点的父节点。
若所述第一节点的层级高于所述第三节点的层级，则执行步骤S806，若所述第一节点的层级低于或等于所述第三节点的层级，则执行步骤S807。
步骤S806、将所述第二节点变更为所述第一节点的子节点，并按照所述授权请求对所述第二节点的权限等级进行调整。
如图2所示，若节点1又对节点7进行了授权，与节点4对节点7的授权产生了冲突，此时，由于节点1比节点4的层级更高，则以节点1的授权为准，若节点1授权给节点7的是第二权限等级，则节点7仍然具有对上述医疗记录的查看权限，且从三级节点变为了二级节点，但无法继续对其它用户及医疗机构进行授权，节点7其下的各级子节点均丧失对上述医疗记录的查看权限，也即节点7其下的各级子节点将从该授权树状结构中被删除，结果如图9所示。若节点1授权给节点7的是第一权限等级，则节点7仍然具有对上述医疗记录的查看权限，且从三级节点变为了二级节点，且节点7可以继续对其它用户及医疗机构进行授权，节点7其下的各级子节点随其做相应的变更，结果如图10所示。
步骤S807、向所述第一节点发送授权失败消息。
步骤S807的过程与步骤S305的过程类似，具体过程可参照前述内容，此处不再赘述。
综上所述，本申请实施例为每份医疗记录均设立与其对应的树状授权信息，在所述树状授权信息中记录了各个节点之间的授权层级关系，以及各个节点的权限等级，其中，拥有第一权限等级的节点可以查看医疗记录以及授权其它节点查看医疗记录，即既有查看的权限又有授权的权限，而拥有第二权限等级的节点只可以查看医疗记录，即仅有查看的权限而没有授权的权限。拥有授权权限的节点可以根据实际情况将相关权限（第一权限等级或第二权限等级）授予其所信任的其它节点，将新的受信任节点添加入所述树状授权信息中。通过这样的授权层级关系，将医疗记录的公开范围控制在一个由各层信任链构成的有限范围内，在保证患者的隐私不被不法分子获取的前提下将其医疗记录在可控的信任节点间进行共享，从而同时兼顾这些医疗记录的开放性以及私密性。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
对应于上文实施例所述的一种医疗记录权限管理方法，图11示出了本申请实施例提供的一种医疗记录权限管理装置的一个实施例结构图。
本实施例中，一种医疗记录权限管理装置可以包括：
授权请求接收模块1101，用于接收第一节点发送的授权请求，所述授权请求中包括医疗记录标识、所述第一节点的身份标识、第二节点的身份标识以及所述第二节点的权限等级；
树状授权信息确定模块1102，用于在预设的权限信息记录中确定与所述医疗记录标识对应的树状授权信息，所述树状授权信息中记录了各个节点之间的授权层级关系，以及各个节点的权限等级；
权限等级查询模块1103，用于根据所述第一节点的身份标识在所述树状授权信息中查询所述第一节点的权限等级；
第一处理模块1104，用于若所述第一节点的权限等级为第一权限等级，则将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中，并将所述第二节点作为所述第一节点的子节点，所述第一权限等级为查看目标医疗记录以及授权其它节点查看所述目标医疗记录的权限等级，所述目标医疗记录为与所述医疗记录标识对应的医疗记录；
第二处理模块1105，用于所述第一节点的权限等级为第二权限等级，则向所述第一节点发送授权失败消息，所述第二权限等级为查看所述目标医疗记录的权限等级。
进一步地，所述医疗记录权限管理装置还可以包括：
修改授权请求接收模块，用于接收所述第一节点发送的修改授权请求，所述修改授权请求中包括所述医疗记录标识、所述第一节点的身份标识、所述第二节点的身份标识以及授权修改类型；
第一判断模块，用于根据所述树状授权信息判断所述第二节点是否为所述第一节点的子节点；
第三处理模块，用于若所述第二节点为所述第一节点的子节点，则按照所述授权修改类型对所述第二节点的权限等级进行修改；
第四处理模块，用于若所述第二节点不是所述第一节点的子节点，则向所述第一节点发送修改授权失败消息。
进一步地，所述第三处理模块可以包括：
第一修改单元，用于若所述授权修改类型为第一修改类型，则将所述第二节点的权限等级修改为所述第一权限等级；
第二修改单元，用于若所述授权修改类型为第二修改类型，则将所述第二节点的各个子节点从所述树状授权信息中删除，并将所述第二节点的权限等级修改为所述第二权限等级。
进一步地，所述医疗记录权限管理装置还可以包括：
取消授权请求接收模块，用于接收所述第一节点发送的取消授权请求，所述取消授权请求中包括所述医疗记录标识、所述第一节点的身份标识以及所述第二节点的身份标识；
第五处理模块，用于若所述第二节点为所述第一节点的子节点，则将所述第二节点以及所述第二节点的各个子节点从所述树状授权信息中删除；
第六处理模块，用于若所述第二节点不是所述第一节点的子节点，则向所述第一节点发送取消授权失败消息。
进一步地，所述医疗记录权限管理装置还可以包括：
第二判断模块，用于判断所述第二节点是否已在所述树状授权信息中；
第三判断模块，用于若所述第二节点已在所述树状授权信息中，则根据所述树状授权信息判断所述第一节点的层级是否高于第三节点的层级，所述第三节点为所述第二节点的父节点；
第七处理模块，用于若所述第一节点的层级高于所述第三节点的层级，则将所述第二节点变更为所述第一节点的子节点，并按照所述授权请求对所述第二节点的权限等级进行调整；
第八处理模块，用于若所述第一节点的层级低于或等于所述第三节点的层级，则向所述第一节点发送授权失败消息。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置，模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
图12示出了本申请实施例提供的一种服务器的示意框图，为了便于说明，仅示出了与本申请实施例相关的部分。
在本实施例中，所述服务器12可以包括：处理器120、存储器121以及存储在所述存储器121中并可在所述处理器120上运行的计算机可读指令122，例如执行上述的医疗记录权限管理方法的计算机可读指令。所述处理器120执行所述计算机可读指令122时实现上述各个医疗记录权限管理方法实施例中的步骤，或者，所述处理器120执行所述计算机可读指令122时实现上述各装置实施例中各模块/单元的功能。
示例性的，所述计算机可读指令122可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器121中，并由所述处理器120执行，以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令段，该指令段用于描述所述计算机可读指令122在所述服务器12中的执行过程。
所述处理器120可以是中央处理单元（Central Processing Unit，CPU），还可以是其它通用处理器、数字信号处理器（Digital Signal Processor，DSP）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现场可编程门阵列（Field-Programmable Gate Array，FPGA）或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器121可以是所述服务器12的内部存储单元，例如服务器12的硬盘或内存。所述存储器121也可以是所述服务器12的外部存储设备，例如所述服务器12上配备的插接式硬盘，智能存储卡（Smart Media Card, SMC），安全数字（Secure Digital, SD）卡，闪存卡（Flash Card）等。进一步地，所述存储器121还可以既包括所述服务器12的内部存储单元也包括外部存储设备。所述存储器121用于存储所述计算机可读指令以及所述服务器12所需的其它指令和数据。所述存储器121还可以用于暂时地存储已经输出或者将要输出的数据。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，所述的计算机可读指令可存储于一计算机非易失性可读取存储介质中，该计算机可读指令在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink） DRAM（SLDRAM）、存储器总线（Rambus）直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。
以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (20)

  1. 一种医疗记录权限管理方法，其特征在于，所述方法应用于由各个终端设备组成的区块链系统中，所述区块链系统用于对医疗记录进行存储和管理，每个终端设备均作为所述区块链系统的一个节点，所述方法包括：
    接收第一节点发送的授权请求，所述授权请求中包括医疗记录标识、所述第一节点的身份标识、第二节点的身份标识以及所述第二节点的权限等级，所述第一节点为所述区块链系统中的任意一个节点，所述第二节点为所述区块链系统中除所述第一节点之外的任意一个节点；
    在预设的权限信息记录中确定与所述医疗记录标识对应的树状授权信息，所述树状授权信息中记录了各个节点之间的授权层级关系，以及各个节点的权限等级；
    根据所述第一节点的身份标识在所述树状授权信息中查询所述第一节点的权限等级；
    若所述第一节点的权限等级为第一权限等级，则将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中，并将所述第二节点作为所述第一节点的子节点，所述第一权限等级为查看目标医疗记录以及授权其它节点查看所述目标医疗记录的权限等级，所述目标医疗记录为在所述区块链系统中存储的与所述医疗记录标识对应的医疗记录；
    若所述第一节点的权限等级为第二权限等级，则向所述第一节点发送授权失败消息，所述第二权限等级为查看所述目标医疗记录的权限等级。
  2. 根据权利要求1所述的医疗记录权限管理方法，其特征在于，还包括：
    接收所述第一节点发送的修改授权请求，所述修改授权请求中包括所述医疗记录标识、所述第一节点的身份标识、所述第二节点的身份标识以及授权修改类型；
    在所述权限信息记录中确定与所述医疗记录标识对应的树状授权信息，并根据所述树状授权信息判断所述第二节点是否为所述第一节点的子节点；
    若所述第二节点为所述第一节点的子节点，则按照所述授权修改类型对所述第二节点的权限等级进行修改；
    若所述第二节点不是所述第一节点的子节点，则向所述第一节点发送修改授权失败消息。
  3. 根据权利要求2所述的医疗记录权限管理方法，其特征在于，所述按照所述授权修改类型对所述第二节点的权限等级进行修改包括：
    若所述授权修改类型为第一修改类型，则将所述第二节点的权限等级修改为所述第一权限等级；
    若所述授权修改类型为第二修改类型，则将所述第二节点的各个子节点从所述树状授权信息中删除，并将所述第二节点的权限等级修改为所述第二权限等级。
  4. 根据权利要求1所述的医疗记录权限管理方法，其特征在于，还包括：
    接收所述第一节点发送的取消授权请求，所述取消授权请求中包括所述医疗记录标识、所述第一节点的身份标识以及所述第二节点的身份标识；
    在所述权限信息记录中确定与所述医疗记录标识对应的树状授权信息，并根据所述树状授权信息判断所述第二节点是否为所述第一节点的子节点；
    若所述第二节点为所述第一节点的子节点，则将所述第二节点以及所述第二节点的各个子节点从所述树状授权信息中删除；
    若所述第二节点不是所述第一节点的子节点，则向所述第一节点发送取消授权失败消息。
  5. 根据权利要求1至4中任一项所述的医疗记录权限管理方法，其特征在于，在将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中之前，还包括：
    判断所述第二节点是否已在所述树状授权信息中；
    若所述第二节点已在所述树状授权信息中，则根据所述树状授权信息判断所述第一节点的层级是否高于第三节点的层级，所述第三节点为所述第二节点的父节点；
    若所述第一节点的层级高于所述第三节点的层级，则将所述第二节点变更为所述第一节点的子节点，并按照所述授权请求对所述第二节点的权限等级进行调整；
    若所述第一节点的层级低于或等于所述第三节点的层级，则向所述第一节点发送授权失败消息。
  6. 一种医疗记录权限管理装置，其特征在于，所述装置应用于由各个终端设备组成的区块链系统中，所述区块链系统用于对医疗记录进行管理，每个终端设备均作为所述区块链系统的一个节点，所述装置包括：
    授权请求接收模块，用于接收第一节点发送的授权请求，所述授权请求中包括医疗记录标识、所述第一节点的身份标识、第二节点的身份标识以及所述第二节点的权限等级，所述第一节点为所述区块链系统中的任意一个节点，所述第二节点为所述区块链系统中除所述第一节点之外的任意一个节点；
    树状授权信息确定模块，用于在预设的权限信息记录中确定与所述医疗记录标识对应的树状授权信息，所述树状授权信息中记录了各个节点之间的授权层级关系，以及各个节点的权限等级；
    权限等级查询模块，用于根据所述第一节点的身份标识在所述树状授权信息中查询所述第一节点的权限等级；
    第一处理模块，用于若所述第一节点的权限等级为第一权限等级，则将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中，并将所述第二节点作为所述第一节点的子节点，所述第一权限等级为查看目标医疗记录以及授权其它节点查看所述目标医疗记录的权限等级，所述目标医疗记录为在所述区块链系统中存储的与所述医疗记录标识对应的医疗记录；
    第二处理模块，用于所述第一节点的权限等级为第二权限等级，则向所述第一节点发送授权失败消息，所述第二权限等级为查看所述目标医疗记录的权限等级。
  7. 根据权利要求6所述的医疗记录权限管理装置，其特征在于，还包括：
    修改授权请求接收模块，用于接收所述第一节点发送的修改授权请求，所述修改授权请求中包括所述医疗记录标识、所述第一节点的身份标识、所述第二节点的身份标识以及授权修改类型；
    第一判断模块，用于根据所述树状授权信息判断所述第二节点是否为所述第一节点的子节点；
    第三处理模块，用于若所述第二节点为所述第一节点的子节点，则按照所述授权修改类型对所述第二节点的权限等级进行修改；
    第四处理模块，用于若所述第二节点不是所述第一节点的子节点，则向所述第一节点发送修改授权失败消息。
  8. 根据权利要求7所述的医疗记录权限管理装置，其特征在于，所述第三处理模块包括：
    第一修改单元，用于若所述授权修改类型为第一修改类型，则将所述第二节点的权限等级修改为所述第一权限等级；
    第二修改单元，用于若所述授权修改类型为第二修改类型，则将所述第二节点的各个子节点从所述树状授权信息中删除，并将所述第二节点的权限等级修改为所述第二权限等级。
  9. 根据权利要求6所述的医疗记录权限管理装置，其特征在于，还包括：
    取消授权请求接收模块，用于接收所述第一节点发送的取消授权请求，所述取消授权请求中包括所述医疗记录标识、所述第一节点的身份标识以及所述第二节点的身份标识；
    第五处理模块，用于若所述第二节点为所述第一节点的子节点，则将所述第二节点以及所述第二节点的各个子节点从所述树状授权信息中删除；
    第六处理模块，用于若所述第二节点不是所述第一节点的子节点，则向所述第一节点发送取消授权失败消息。
  10. 根据权利要求6至9中任一项所述的医疗记录权限管理装置，其特征在于，还包括：
    第二判断模块，用于判断所述第二节点是否已在所述树状授权信息中；
    第三判断模块，用于若所述第二节点已在所述树状授权信息中，则根据所述树状授权信息判断所述第一节点的层级是否高于第三节点的层级，所述第三节点为所述第二节点的父节点；
    第七处理模块，用于若所述第一节点的层级高于所述第三节点的层级，则将所述第二节点变更为所述第一节点的子节点，并按照所述授权请求对所述第二节点的权限等级进行调整；
    第八处理模块，用于若所述第一节点的层级低于或等于所述第三节点的层级，则向所述第一节点发送授权失败消息。
  11. 一种计算机非易失性可读存储介质，所述计算机非易失性可读存储介质存储有计算机可读指令，其特征在于，所述计算机非易失性可读存储介质应用于由各个终端设备组成的区块链系统中，所述区块链系统用于对医疗记录进行存储和管理，每个终端设备均作为所述区块链系统的一个节点，所述计算机可读指令被处理器执行时实现如下步骤：
    接收第一节点发送的授权请求，所述授权请求中包括医疗记录标识、所述第一节点的身份标识、第二节点的身份标识以及所述第二节点的权限等级，所述第一节点为所述区块链系统中的任意一个节点，所述第二节点为所述区块链系统中除所述第一节点之外的任意一个节点；
    在预设的权限信息记录中确定与所述医疗记录标识对应的树状授权信息，所述树状授权信息中记录了各个节点之间的授权层级关系，以及各个节点的权限等级；
    根据所述第一节点的身份标识在所述树状授权信息中查询所述第一节点的权限等级；
    若所述第一节点的权限等级为第一权限等级，则将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中，并将所述第二节点作为所述第一节点的子节点，所述第一权限等级为查看目标医疗记录以及授权其它节点查看所述目标医疗记录的权限等级，所述目标医疗记录为在所述区块链系统中存储的与所述医疗记录标识对应的医疗记录；
    若所述第一节点的权限等级为第二权限等级，则向所述第一节点发送授权失败消息，所述第二权限等级为查看所述目标医疗记录的权限等级。
  12. 根据权利要求11所述的计算机非易失性可读存储介质，其特征在于，还包括：
    接收所述第一节点发送的修改授权请求，所述修改授权请求中包括所述医疗记录标识、所述第一节点的身份标识、所述第二节点的身份标识以及授权修改类型；
    在所述权限信息记录中确定与所述医疗记录标识对应的树状授权信息，并根据所述树状授权信息判断所述第二节点是否为所述第一节点的子节点；
    若所述第二节点为所述第一节点的子节点，则按照所述授权修改类型对所述第二节点的权限等级进行修改；
    若所述第二节点不是所述第一节点的子节点，则向所述第一节点发送修改授权失败消息。
  13. 根据权利要求12所述的计算机非易失性可读存储介质，其特征在于，所述按照所述授权修改类型对所述第二节点的权限等级进行修改包括：
    若所述授权修改类型为第一修改类型，则将所述第二节点的权限等级修改为所述第一权限等级；
    若所述授权修改类型为第二修改类型，则将所述第二节点的各个子节点从所述树状授权信息中删除，并将所述第二节点的权限等级修改为所述第二权限等级。
  14. 根据权利要求11所述的计算机非易失性可读存储介质，其特征在于，还包括：
    接收所述第一节点发送的取消授权请求，所述取消授权请求中包括所述医疗记录标识、所述第一节点的身份标识以及所述第二节点的身份标识；
    在所述权限信息记录中确定与所述医疗记录标识对应的树状授权信息，并根据所述树状授权信息判断所述第二节点是否为所述第一节点的子节点；
    若所述第二节点为所述第一节点的子节点，则将所述第二节点以及所述第二节点的各个子节点从所述树状授权信息中删除；
    若所述第二节点不是所述第一节点的子节点，则向所述第一节点发送取消授权失败消息。
  15. 根据权利要求11至14中任一项所述的计算机非易失性可读存储介质，其特征在于，在将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中之前，还包括：
    判断所述第二节点是否已在所述树状授权信息中；
    若所述第二节点已在所述树状授权信息中，则根据所述树状授权信息判断所述第一节点的层级是否高于第三节点的层级，所述第三节点为所述第二节点的父节点；
    若所述第一节点的层级高于所述第三节点的层级，则将所述第二节点变更为所述第一节点的子节点，并按照所述授权请求对所述第二节点的权限等级进行调整；
    若所述第一节点的层级低于或等于所述第三节点的层级，则向所述第一节点发送授权失败消息。
  16. 一种服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，其特征在于，所述服务器应用于由各个终端设备组成的区块链系统中，所述区块链系统用于对医疗记录进行存储和管理，每个终端设备均作为所述区块链系统的一个节点，所述处理器执行所述计算机可读指令时实现如下步骤：
    接收第一节点发送的授权请求，所述授权请求中包括医疗记录标识、所述第一节点的身份标识、第二节点的身份标识以及所述第二节点的权限等级，所述第一节点为所述区块链系统中的任意一个节点，所述第二节点为所述区块链系统中除所述第一节点之外的任意一个节点；
    在预设的权限信息记录中确定与所述医疗记录标识对应的树状授权信息，所述树状授权信息中记录了各个节点之间的授权层级关系，以及各个节点的权限等级；
    根据所述第一节点的身份标识在所述树状授权信息中查询所述第一节点的权限等级；
    若所述第一节点的权限等级为第一权限等级，则将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中，并将所述第二节点作为所述第一节点的子节点，所述第一权限等级为查看目标医疗记录以及授权其它节点查看所述目标医疗记录的权限等级，所述目标医疗记录为在所述区块链系统中存储的与所述医疗记录标识对应的医疗记录；
    若所述第一节点的权限等级为第二权限等级，则向所述第一节点发送授权失败消息，所述第二权限等级为查看所述目标医疗记录的权限等级。
  17. 根据权利要求16所述的服务器，其特征在于，还包括：
    接收所述第一节点发送的修改授权请求，所述修改授权请求中包括所述医疗记录标识、所述第一节点的身份标识、所述第二节点的身份标识以及授权修改类型；
    在所述权限信息记录中确定与所述医疗记录标识对应的树状授权信息，并根据所述树状授权信息判断所述第二节点是否为所述第一节点的子节点；
    若所述第二节点为所述第一节点的子节点，则按照所述授权修改类型对所述第二节点的权限等级进行修改；
    若所述第二节点不是所述第一节点的子节点，则向所述第一节点发送修改授权失败消息。
  18. 根据权利要求17所述的服务器，其特征在于，所述按照所述授权修改类型对所述第二节点的权限等级进行修改包括：
    若所述授权修改类型为第一修改类型，则将所述第二节点的权限等级修改为所述第一权限等级；
    若所述授权修改类型为第二修改类型，则将所述第二节点的各个子节点从所述树状授权信息中删除，并将所述第二节点的权限等级修改为所述第二权限等级。
  19. 根据权利要求16所述的服务器，其特征在于，还包括：
    接收所述第一节点发送的取消授权请求，所述取消授权请求中包括所述医疗记录标识、所述第一节点的身份标识以及所述第二节点的身份标识；
    在所述权限信息记录中确定与所述医疗记录标识对应的树状授权信息，并根据所述树状授权信息判断所述第二节点是否为所述第一节点的子节点；
    若所述第二节点为所述第一节点的子节点，则将所述第二节点以及所述第二节点的各个子节点从所述树状授权信息中删除；
    若所述第二节点不是所述第一节点的子节点，则向所述第一节点发送取消授权失败消息。
  20. 根据权利要求16至19中任一项所述的服务器，其特征在于，在将所述第二节点的身份标识以及第二节点的权限等级添加入所述树状授权信息中之前，还包括：
    判断所述第二节点是否已在所述树状授权信息中；
    若所述第二节点已在所述树状授权信息中，则根据所述树状授权信息判断所述第一节点的层级是否高于第三节点的层级，所述第三节点为所述第二节点的父节点；
    若所述第一节点的层级高于所述第三节点的层级，则将所述第二节点变更为所述第一节点的子节点，并按照所述授权请求对所述第二节点的权限等级进行调整；
    若所述第一节点的层级低于或等于所述第三节点的层级，则向所述第一节点发送授权失败消息。
PCT/CN2019/116643 2019-01-24 2019-11-08 医疗记录权限管理方法、装置、可读存储介质及服务器 Ceased WO2020151308A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910068139.2A CN109871712B (zh) 2019-01-24 2019-01-24 医疗记录权限管理方法、装置、可读存储介质及服务器
CN201910068139.2 2019-01-24

Publications (1)

Publication Number Publication Date
WO2020151308A1 true WO2020151308A1 (zh) 2020-07-30

Family

ID=66918033

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/116643 Ceased WO2020151308A1 (zh) 2019-01-24 2019-11-08 医疗记录权限管理方法、装置、可读存储介质及服务器

Country Status (2)

Country Link
CN (1) CN109871712B (zh)
WO (1) WO2020151308A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113626793A (zh) * 2021-07-15 2021-11-09 中国信息通信研究院 健康认证方法、系统、装置、设备及可读存储介质
CN113780802A (zh) * 2021-09-07 2021-12-10 杭州天宽科技有限公司 运维服务可视化管理系统
CN113806411A (zh) * 2021-09-18 2021-12-17 王剑 医疗产品信息的查询方法、存储方法及相关装置
US11562025B2 (en) 2018-04-18 2023-01-24 Palantir Technologies Inc. Resource dependency system and graphical user interface
CN116153451A (zh) * 2023-04-18 2023-05-23 中国人民解放军总医院 基于数据处理的收治病种分析系统
US11775898B1 (en) * 2019-10-04 2023-10-03 Palantir Technologies Inc. Resource grouping for resource dependency system and graphical user interface

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109871712B (zh) * 2019-01-24 2022-10-14 平安科技（深圳）有限公司 医疗记录权限管理方法、装置、可读存储介质及服务器
CN110445840B (zh) * 2019-07-09 2020-07-03 北京健网未来科技有限公司 一种基于区块链技术的文件存储和读取的方法
CN110445771B (zh) * 2019-07-19 2022-07-08 平安科技（深圳）有限公司 基于区块链的交互记录取证方法、装置、介质及服务器
CN111222126B (zh) * 2019-12-27 2022-07-19 陈强 一种基于区块链技术的医疗身份认证系统
CN113094760B (zh) * 2020-01-08 2026-04-14 北京奇虎科技有限公司 关系网络及其实现方法和装置
CN111292088A (zh) * 2020-01-21 2020-06-16 杭州趣链科技有限公司 一种基于区块链的多级授权方法、系统、设备和存储介质
CN111814176A (zh) * 2020-05-29 2020-10-23 上海申铁信息工程有限公司 一种基于区块链的数据访问权限控制方法和装置
CN112214789A (zh) * 2020-09-03 2021-01-12 长沙通诺信息科技有限责任公司 伦理数据处理方法、区块链网络及电子设备
CN112487484A (zh) * 2020-12-15 2021-03-12 深圳壹账通智能科技有限公司 区块链网络中节点权限的动态配置方法、装置
CN113094656A (zh) * 2021-03-08 2021-07-09 海信集团控股股份有限公司 一种访问控制的终端设备、服务器及方法
CN113079154B (zh) * 2021-03-29 2021-12-31 北京深思数盾科技股份有限公司 密钥授权使用方法、电子设备及计算机可读存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105488431A (zh) * 2015-11-30 2016-04-13 布比（北京）网络技术有限公司 区块链系统权限管理方法和装置
CN106453435A (zh) * 2016-12-21 2017-02-22 中国人民解放军72537部队 一种基于区块链的数据共享授权方法
CN107391944A (zh) * 2017-07-27 2017-11-24 北京太云科技有限公司 一种基于区块链的电子病历共享系统
CN108229962A (zh) * 2018-01-04 2018-06-29 众安信息技术服务有限公司 基于区块链的权限管理方法及系统
WO2018119585A1 (zh) * 2016-12-26 2018-07-05 深圳前海达闼云端智能科技有限公司 区块链的权限控制方法、装置、系统及节点设备
CN109871712A (zh) * 2019-01-24 2019-06-11 平安科技（深圳）有限公司 医疗记录权限管理方法、装置、可读存储介质及服务器

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10178105B2 (en) * 2016-02-22 2019-01-08 Bank Of America Corporation System for providing levels of security access to a process data network
US10720232B2 (en) * 2016-04-13 2020-07-21 Accenture Global Solutions Limited Distributed healthcare records management
CN106534097B (zh) * 2016-10-27 2018-05-18 上海亿账通区块链科技有限公司 基于区块链交易的权限管制方法及系统
JP6547079B1 (ja) * 2016-12-23 2019-07-17 深▲セン▼前▲海▼▲達▼▲闥▼▲雲▼端智能科技有限公司Ｃｌｏｕｄｍｉｎｄｓ （Ｓｈｅｎｚｈｅｎ） Ｒｏｂｏｔｉｃｓ Ｓｙｓｔｅｍｓ Ｃｏ．， Ｌｔｄ． 登録・認可方法、装置及びシステム
US11190525B2 (en) * 2017-08-18 2021-11-30 Cloudminds (Shanghai) Robotics Co., Ltd. Blockchain system and permission management method thereof
CN108416226B (zh) * 2018-02-26 2020-07-14 深圳智乾区块链科技有限公司 区块链的权限管理方法、装置及计算机可读存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105488431A (zh) * 2015-11-30 2016-04-13 布比（北京）网络技术有限公司 区块链系统权限管理方法和装置
CN106453435A (zh) * 2016-12-21 2017-02-22 中国人民解放军72537部队 一种基于区块链的数据共享授权方法
WO2018119585A1 (zh) * 2016-12-26 2018-07-05 深圳前海达闼云端智能科技有限公司 区块链的权限控制方法、装置、系统及节点设备
CN107391944A (zh) * 2017-07-27 2017-11-24 北京太云科技有限公司 一种基于区块链的电子病历共享系统
CN108229962A (zh) * 2018-01-04 2018-06-29 众安信息技术服务有限公司 基于区块链的权限管理方法及系统
CN109871712A (zh) * 2019-01-24 2019-06-11 平安科技（深圳）有限公司 医疗记录权限管理方法、装置、可读存储介质及服务器

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HONG XX LIBRARY: "Non-official translation: Here Are All the Classifications of Blockchain, It Is Worth Collecting!", 15 June 2018 (2018-06-15), CN, pages 1 - 3, XP009522414, Retrieved from the Internet <URL:https://www.360doc.com/content/18/0615/23/29551465_762751970.shtml> *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11562025B2 (en) 2018-04-18 2023-01-24 Palantir Technologies Inc. Resource dependency system and graphical user interface
US11775898B1 (en) * 2019-10-04 2023-10-03 Palantir Technologies Inc. Resource grouping for resource dependency system and graphical user interface
US12306815B2 (en) 2019-10-04 2025-05-20 Palantir Technologies Inc. Resource grouping for resource dependency system and graphical user interface
US12386802B2 (en) 2019-10-04 2025-08-12 Palantir Technologies Inc. Column lineage for resource dependency system and graphical user interface
CN113626793A (zh) * 2021-07-15 2021-11-09 中国信息通信研究院 健康认证方法、系统、装置、设备及可读存储介质
CN113780802A (zh) * 2021-09-07 2021-12-10 杭州天宽科技有限公司 运维服务可视化管理系统
CN113780802B (zh) * 2021-09-07 2024-03-19 杭州天宽科技有限公司 运维服务可视化管理系统
CN113806411A (zh) * 2021-09-18 2021-12-17 王剑 医疗产品信息的查询方法、存储方法及相关装置
CN116153451A (zh) * 2023-04-18 2023-05-23 中国人民解放军总医院 基于数据处理的收治病种分析系统

Also Published As

Publication number Publication date
CN109871712B (zh) 2022-10-14
CN109871712A (zh) 2019-06-11

Similar Documents

Publication Publication Date Title
WO2020151308A1 (zh) 医疗记录权限管理方法、装置、可读存储介质及服务器
US12261852B2 (en) Systems and methods for managing digital identities
US11501007B2 (en) Personal data ecosystems
US20220198419A1 (en) System and method for managing payments for accessing patients&#39; information
US20190333031A1 (en) System, method, and computer program product for validating blockchain or distributed ledger transactions in a service requiring payment
CN110929293B (zh) 一种基于区块链的美容数据存储系统
US11526955B2 (en) Protocol-based system and method for establishing a multi-party contract
Ghayvat et al. Sharif: Solid pod-based secured healthcare information storage and exchange solution in internet of things
AU2017315345A1 (en) Blockchain-based mechanisms for secure health information resource exchange
US10586299B2 (en) HIPAA-compliant third party access to electronic medical records
BRPI0806465A2 (pt) provisão de represaentações de identidade digital
US12609837B2 (en) Technologies for auditing and maintaining access to protected data
Dias et al. Blockchain for access control in e-health scenarios
US20200388357A1 (en) Shared revocation ledger for data access control
KR102686822B1 (ko) Ｄｓａｒ 기반 개인정보동의 관리 서비스 제공 시스템
JP2026513158A (ja) ブロックチェーンに裏付けられた認証情報を使用したセキュアユーザ情報のためのポータブルアクセスポイント
US20220301376A1 (en) Method and System for Deployment of Authentication Seal in Secure Digital Voting
CN113496040B (zh) 个人数据生态系统
CN116257824A (zh) 一种越权校验方法、装置及电子设备
Poschen et al. A threat-driven design of a data-trustee infrastructure for medical data
US20260046291A1 (en) System and method for multi level, user controlled verification and context specific credential sharing
Sharma SHARIF: Solid Pod based Secured Healthcare Information Storage and Exchange Solution
HK1262699A1 (zh) 用於管理数字身份的系统和方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19911714

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 12/11/2021)

122 Ep: pct application non-entry in european phase

Ref document number: 19911714

Country of ref document: EP

Kind code of ref document: A1