WO2020000825A1 - 医疗数据处理方法、系统、计算机设备及可读存储介质 - Google Patents
医疗数据处理方法、系统、计算机设备及可读存储介质 Download PDFInfo
- Publication number
- WO2020000825A1 WO2020000825A1 PCT/CN2018/113087 CN2018113087W WO2020000825A1 WO 2020000825 A1 WO2020000825 A1 WO 2020000825A1 CN 2018113087 W CN2018113087 W CN 2018113087W WO 2020000825 A1 WO2020000825 A1 WO 2020000825A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node
- patient
- hospital
- authorization information
- information
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- 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
Definitions
- the present application relates to the field of data processing technologies, and in particular, to a medical data processing method, system, computer device, and readable storage medium.
- each hospital manages and stores the medical records of the patients through its own independent system.
- the embodiments of the present application provide a medical data processing method, system, computer equipment, and readable storage medium.
- the medical data of patients are stored in the medical blockchain, and the information security of medical data is guaranteed. It is flexible enough to meet the higher development needs of the medical field.
- an embodiment of the present application provides a medical data processing method, which is applicable to a medical blockchain.
- the medical blockchain includes a plurality of alliance hospital nodes for storing medical data, and the alliance hospital nodes include a visiting hospital. Node and non-visiting hospital node, the method includes:
- the visiting hospital node uses the patient information to encrypt the medical data
- the visiting hospital node uploads the encrypted medical data to the medical blockchain.
- an embodiment of the present application provides a medical data processing system suitable for a medical blockchain, where the medical blockchain includes multiple alliance hospital nodes for storing medical data, and the alliance hospital nodes include a visiting hospital Node and non-visiting hospital node, the visiting hospital node includes:
- a first obtaining unit configured to obtain medical data of a patient
- a first encryption unit configured to encrypt the medical data using patient information
- the uploading unit is configured to upload the encrypted medical data to the medical blockchain.
- an embodiment of the present application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor.
- the processor executes the computer program, the processor implements the method described in the first aspect. method.
- an embodiment of the present application provides a computer non-volatile readable storage medium, where the computer non-volatile readable storage medium includes a stored program, wherein the computer is controlled when the program runs.
- the device on which the volatile readable storage medium is located executes the method as described in the first aspect above.
- the embodiments of the present application provide a medical data processing method, system, computer equipment, and readable storage medium.
- a medical blockchain including a plurality of affiliated hospital nodes is established, and then the medical data of the patients are encrypted and stored in the medical treatment.
- Blockchain records are used to save medical data. Information cannot be tampered with and can be publicly recognized, which can reduce doctor-patient disputes and transparentize the medical process.
- multiple affiliated hospital nodes can view the patient's medical data in the blockchain through an authorized method, eliminating the need for patients to carry paper medical records to and from various hospitals, providing patients with great convenience for medical treatment.
- FIG. 1 is a flowchart of a medical data processing method according to an embodiment of the present application
- FIG. 2 is a flowchart of another medical data processing method according to an embodiment of the present application.
- FIG. 3 is a flowchart of another medical data processing method according to an embodiment of the present application.
- FIG. 4 is a flowchart of another medical data processing method according to an embodiment of the present application.
- FIG. 5 is a block diagram of a medical data processing system according to an embodiment of the present application.
- FIG. 6 is a block diagram of another medical data processing system according to an embodiment of the present application.
- FIG. 7 is a structural block diagram of another medical data processing system according to an embodiment of the present application.
- FIG. 8 is a structural block diagram of another medical data processing system according to an embodiment of the present application.
- FIG. 9 is a block diagram of a computer device according to an embodiment of the present application.
- the word “if” as used herein can be interpreted as “at” or “when” or “responding to determination” or “responding to detection”.
- the phrases “if determined” or “if detected (the stated condition or event)” can be interpreted as “when determined” or “responded to the determination” or “when detected (the stated condition or event) ) “Or” in response to a test (statement or event stated) ".
- the medical blockchain in the embodiment of the present application includes a plurality of affiliated hospital nodes, and the affiliated hospital nodes include a visiting hospital node and a non-patient hospital node.
- the form of the medical blockchain is an alliance chain, and multiple alliance hospital nodes can share medical data in the medical blockchain.
- the visited hospital node and the non-visited hospital node are for a certain visit of a patient.
- the visiting hospital refers to the hospital that diagnoses and treats the patient at that time, and generates and uploads the medical data of the diagnosis and treatment.
- Non-visiting hospitals refer to hospitals other than the visiting hospitals in the medical blockchain.
- the hospitals joining the medical blockchain should be all regular hospitals that are legal, have a certain size, and have alliance agreements.
- judgment rules can be set to determine whether a hospital is qualified to join the medical blockchain.
- the specific rules are as follows:
- Rule (1) Whether the hospital is legal; it is mainly to check whether the hospital has relevant documents such as the Medical Institution Practice License to determine the legitimacy of the hospital.
- Rule (2) whether the size of the hospital meets the predetermined conditions; generally speaking, a hospital that is too small, such as a small rural medical site with only one doctor, may not meet the scale requirements for joining the medical blockchain.
- Rule (3) Whether the patient information security of the hospital meets the preset requirements; In accordance with the principle of confidentiality of patient information, if the patient information of a hospital is always leaked for no reason, the alliance hospital is not allowed to join the medical blockchain .
- Rule (4) Whether to sign the alliance agreement; after meeting the above conditions, the hospital can sign the alliance agreement, and after signing the alliance agreement, it can join the medical blockchain.
- the medical data may be encrypted, and optionally, the medical data may be medical record information.
- the medical blockchain can also include patient nodes.
- the medical blockchain may further include a judicial institution node.
- the Judiciary Node can view the patient's past medical data after being authorized by the Patient Node. Because various diagnosis and treatment information, such as surgical procedures, diagnostic procedures, and drug information, are stored in the medical blockchain, each patient's medical treatment process is recorded. If a dispute occurs, the judicial agency can reasonably intervene to resolve Medical disputes.
- the medical blockchain in the embodiment of the present application includes a plurality of affiliated hospital nodes, and all medical data of patients are encrypted and stored in the medical blockchain.
- the use of blockchain records to save medical data can be publicly recognized, thereby reducing doctor-patient disputes, and at the same time transparent medical process.
- multiple affiliated hospital nodes can view the patient's medical data in the blockchain through an authorized method, without the need for patients to carry paper medical records between the various hospitals, providing patients with great convenience for medical treatment.
- the embodiments of the present application provide a medical data processing method, which mainly aims at the process of uploading medical data to the blockchain, and the process in which each node in the medical blockchain is authorized to view a patient's medical data Explain.
- the first is the process of uploading medical data:
- the first implementation manner is applicable to a hospital node, and specifically includes:
- a doctor or nurse of the visiting hospital will record the patient's medical data, and the patient can confirm whether the medical data is correct on the spot and confirm the medical data on the patient. Medical data will not be saved until it is correct. Furthermore, as a node of the hospital in the medical blockchain, the medical data after patient confirmation is directly obtained, so that the original medical data can be guaranteed to be correct.
- the patient's medical data needs to be encrypted before the hospital's node uploads the patient's medical data to the medical blockchain.
- the patient information may be encrypted.
- the patient information may include information such as a patient's ID number, medical insurance card number, etc., which can uniquely identify the patient, or a specific password arbitrarily set by the patient.
- each patient can arbitrarily set password information to encrypt their own medical data, but each patient's own medical record data should be guaranteed to be the same password.
- the visiting hospital node generates encrypted medical data into a block, and then uploads the block to the patient's blockchain data in the medical blockchain.
- each block includes:
- the header is used to store the summary information corresponding to the medical data, which mainly includes the patient's personal information, such as information such as an ID number or medical insurance card number that can uniquely identify the patient;
- Subject used to store medical data.
- the hospital node After the hospital node uploads the patient's medical number, other hospital nodes can also share the encrypted medical data. However, although encrypted medical data is stored in each hospital node, to view these data, the authorization of the patient node is needed, that is, the password information of the medical data is required.
- the medical blockchain includes multiple affiliated hospital nodes, and the medical data of patients are all encrypted and stored in the medical blockchain.
- the use of blockchain records to save medical data can be publicly recognized, thereby reducing doctor-patient disputes, and at the same time transparent medical process.
- multiple affiliated hospital nodes can view the patient's medical data in the blockchain through an authorized method, without the need for patients to carry paper medical records between the various hospitals, providing patients with great convenience for medical treatment.
- a second implementation method for uploading medical data is derived, as shown in Figure 2, which is applicable to the hospital node.
- a doctor or nurse of the visit hospital records the medical data of the patient, and after the patient confirms that the medical data is correct, the medical data is encrypted save. Further, as a node in the medical blockchain, the hospital node directly obtains encrypted medical data.
- step 102A For a specific encryption form, refer to step 102A.
- the visiting hospital node generates a block of the encrypted patient's medical data, and then uploads the block to the patient's blockchain data in the medical blockchain.
- the hospital node After the hospital node uploads the patient's medical number, other hospital nodes can also share the encrypted medical data. However, although encrypted medical data is stored in each hospital node, to view these data, the authorization of the patient is needed, that is, the password information of the medical data is required.
- the medical data processing method provided in the embodiment of the present application stores medical data of an encrypted patient in a medical blockchain including a plurality of affiliated hospital nodes.
- a medical blockchain including a plurality of affiliated hospital nodes.
- the use of blockchain records to save medical data information can not be tampered with, can be publicly recognized, thereby reducing doctor-patient disputes, and at the same time transparent medical process.
- multiple affiliated hospital nodes can view the patient's medical data in the blockchain through an authorized method, without the need for patients to carry paper medical records between the various hospitals, providing patients with great convenience for medical treatment.
- any hospital node needs to view the patient's medical data, it must first find the patient's blockchain based on the patient's personal information, such as an ID card or medical insurance card number Data, and then obtain the password information of the patient's medical data in different ways, so that the patient's medical data can be viewed.
- the patient's personal information such as an ID card or medical insurance card number Data
- the hospital node needs to obtain the off-chain permission of the patient: for example, it can contact the patient off-chain to obtain the password information of the patient's medical data, and personal information such as the patient's ID number.
- the visiting hospital will view the patient's medical data.
- the patient's medical data can be viewed through the patient's personal permission.
- the password information can also be set to the patient's fingerprint, iris, and facial features Such as biometrics, through the biometric identification method to further ensure the security of medical data, at this time through the patient's own operation to assist doctors to view medical data.
- the patient node can authorize other nodes (including alliance hospital nodes or judicial institution nodes, etc.) to view their own medical data.
- the authorization process includes the following steps:
- the first is the process of requesting authorization, as shown in Figure 3, including:
- An affiliate hospital node (or a judicial institution node) requesting to view patient medical data:
- the request authorization information may be password information requesting to obtain medical data of a patient, or personal information such as the patient's ID number or medical card number may also be requested.
- an affiliated hospital node (or a judicial institution node) requesting to view the patient's medical data, and digitally sign the request authorization information is to enable the patient node to confirm the identity of the hospital node (or a judicial institution node).
- the patient node After the patient node obtains the digitally signed request authorization information, it first uses the counterparty's public key to verify the request authorization information to determine the identity of the affiliated hospital or judicial authority requesting authorization. After passing the signing, the password information or personal information of the medical data is sent to the counterpart node (that is, the authorization process is performed).
- signing verification refers to verifying the digital signature of the request authorization information, in order to confirm the identity of the digital signature node.
- the public key and the private key are a key pair (that is, a public key and a private key) obtained through an algorithm, and the public key is the public part of the key pair , The private key is the non-public part.
- the public key of each node in the blockchain is well known in the blockchain, and the private key of each node is only known by itself.
- Public keys are often used to encrypt session keys, verify digital signatures, or encrypt data information that can be decrypted with the corresponding private key.
- the key pair obtained by this algorithm can be guaranteed to be unique worldwide. When using this key pair, if one piece of data information is encrypted with one key, it must be decrypted with the other key. For example, if you use the public key to encrypt data, you must use the private key to decrypt it. If you use the private key to encrypt data, you must also use the public key to decrypt it. Otherwise, the decryption will not succeed.
- the authorization process includes:
- the public key of the affiliated hospital node (or the judicial institution node) is used to encrypt the medical data password information or the patient's personal information, and the patient node's own private key is used to encrypt the encrypted password. Digitally sign information or personal information to generate authorization information.
- the encrypted information of medical data or the personal information of patients is encrypted and transmitted in the medical blockchain by asymmetric encryption.
- the public key of the affiliated hospital node (or the judicial institution node) is used to encrypt the password information of the medical data or the patient's personal information. Only the private key of the affiliated hospital node (or the judicial institution node) can be used to decrypt it.
- the encrypted authorization information is broadcast throughout the network, but only the affiliated hospital node (or the judicial institution node) can decrypt the ciphertext and obtain the password information or personal information of the patient's medical data.
- An affiliate hospital node (or a judicial institution node) requesting to view patient medical data:
- authorization information first use the public key of the patient node for signature verification. After the signature is passed, use the private hospital node (or the judicial institution node) 's own private key to decrypt the authorization information, and then obtain the patient's medical data. Password information or patient's personal information.
- the alliance hospital node (or the judicial institution node) obtains the authorization information, it first uses the patient node's public key to verify the signature, confirms the identity of the patient node of the information source, and then uses its own key to pair the ciphertext. After decryption, the password information or personal information of the patient's medical data can be obtained, and then the hospital or the judicial institution node can query other medical data such as the patient's medical history.
- This cipher text authorization method can effectively reduce the public risk of medical data and protect the privacy of patients.
- the visiting hospital node includes:
- the first acquiring unit 31 is configured to acquire medical data of a patient.
- the first encryption unit 32 is configured to encrypt medical data using patient information.
- the uploading unit 33 is configured to upload the encrypted medical data to the medical blockchain.
- the visiting hospital node includes:
- the first processing unit 41 is configured to obtain medical data of the encrypted patient.
- the second processing unit 42 is configured to upload the encrypted medical data of the patient to the medical blockchain.
- the medical blockchain also includes patient nodes,
- Any Alliance Hospital node includes:
- the first signing unit 51 is configured to digitally sign the first request authorization information using the private key of the affiliated hospital node, and send the first request authorization information to the patient node.
- Patient nodes include:
- the second obtaining unit 52 is configured to obtain digitally signed first request authorization information.
- the first signing unit 53 is configured to use the public key of the affiliated hospital node to check the first request authorization information.
- the second encryption unit 54 is used for encrypting the password information of the medical data by using the public key of the affiliated hospital node, and digitally signing the encrypted password information by using the patient node's own private key if it passes the signature verification to generate First authorization information.
- the first sending unit 55 is configured to send the first authorization information to the affiliated hospital node.
- Any Alliance Hospital node also includes:
- the third obtaining unit 56 is configured to obtain first authorization information.
- the first decryption unit 57 is configured to use the public key of the patient node to perform signature verification. After the signature verification is passed, the first authorization information is decrypted using the affiliated hospital node's own private key to obtain the cryptographic information of the medical data.
- the medical blockchain also includes patient nodes and judicial institutions nodes,
- Any Judiciary node includes:
- the second signature unit 61 is configured to digitally sign the second request authorization information by using the private key of the judicial institution node, and send the second request authorization information to the patient node.
- Patient nodes include:
- the fourth obtaining unit 62 is configured to obtain the second request authorization information after the digital signature.
- the second signing unit 63 is configured to use the public key of the judicial institution node to check the second request authorization information.
- the third encryption unit 64 is used for encrypting medical data password information using the public key of the judicial institution node if it passes the signature verification, and digitally signs the encrypted password information using the patient node's own private key to generate Second authorization information.
- the second sending unit 65 is configured to send second authorization information to the judicial authority node.
- Any Judiciary node includes:
- the fifth obtaining unit 66 is configured to obtain second authorization information.
- the second decryption unit 67 is configured to use the public key of the patient node to perform signature verification. After the signature verification is passed, the second authorization information of the alliance hospital node is used to decrypt the second authorization information to obtain the cryptographic information of the medical data.
- the affiliated hospital corresponding to the affiliated hospital node meets at least the following conditions: the hospital size meets the predetermined conditions, the patient information security meets the preset requirements, and the affiliate agreement is signed.
- the medical data processing system encrypts and stores patient medical data in a medical blockchain including multiple affiliated hospital nodes.
- a medical blockchain including multiple affiliated hospital nodes.
- the use of blockchain records to save medical data information can not be tampered with, can be publicly recognized, thereby reducing doctor-patient disputes, and at the same time transparent medical process.
- multiple affiliated hospital nodes can view the patient's medical data in the blockchain through an authorized method, without the need for patients to carry paper medical records between the various hospitals, providing patients with great convenience for medical treatment.
- the computer device includes a memory 71, a processor 72, and a computer program stored in the memory 71 and executable on the processor 72.
- the blockchain includes multiple alliance hospital nodes for storing medical data.
- Alliance hospital nodes include visiting hospital nodes and non-visiting hospital nodes.
- the visiting hospital nodes obtain the patient's Medical data; the visiting hospital node uses the patient information to encrypt the medical data; the visiting hospital node uploads the encrypted medical data to the medical blockchain.
- the medical blockchain further includes a patient node, and when the computer program instructions are loaded and executed by the processor 72, the following steps are also implemented: any affiliated hospital node uses its own private key to perform the first request authorization information Digitally sign and send the first request authorization information to the patient node; the patient node obtains the first request authorization information; the patient node uses the public hospital node's public key to check the first request authorization information; if the check is passed, the patient node Use the public key of the alliance hospital node to encrypt the password information of the medical data, and use the patient node's own private key to digitally sign the encrypted password information to generate the first authorization information; the patient node sends the first authorization information To the affiliated hospital node; the affiliated hospital node obtains the first authorization information; the affiliated hospital node uses the public key of the patient node to perform the signature verification, and after the signature is passed, the affiliated hospital node's own private key is used to decrypt the first authorization information To get password information for medical data.
- any affiliated hospital node uses its own private key
- the medical blockchain further includes a patient node and a judicial institution node.
- any judicial institution node uses its own private key to pair the second The request authorization information is digitally signed, and the second request authorization information is sent to the patient node; the patient node obtains the second request authorization information; the patient node uses the public key of the judicial institution node to check the second request authorization information; if it passes the verification Sign, the patient node uses the public key of the judicial institution node to encrypt the password information of the medical data, and uses the patient node's own private key to digitally sign the encrypted password information to generate the second authorization information; the patient node will The second authorization information is sent to the judicial institution node; the judicial institution node obtains the second authorization information; the affiliated hospital node uses the patient node's public key for signing, and the second hospital's own private key is used to verify the second The authorization information is decrypted to obtain the password information of
- the affiliated hospital corresponding to the affiliated hospital node meets at least the following conditions: the hospital size meets the predetermined conditions, the patient information security meets the preset requirements, and the affiliate agreement is signed.
- the visiting hospital node when the computer program instructions are loaded and executed by the processor 72, the following steps are also implemented: the visiting hospital node generates a block of encrypted medical data, the block includes: a head and a body, and the head is used to store the encrypted The summary information corresponding to the medical data is used to store the encrypted medical data; the hospital node uploads the block to the medical blockchain.
- the embodiment of the present application provides a computer non-volatile readable storage medium suitable for a medical blockchain.
- the medical blockchain includes a plurality of alliance hospital nodes for storing medical data.
- the alliance hospital nodes include a visiting hospital node and For non-visiting hospital nodes, the computer non-volatile readable storage medium stores a computer program.
- the device where the computer non-volatile readable storage medium is located performs the following steps: the visiting hospital node obtains the patient's medical data; The hospital node uses the patient information to encrypt the medical data; the visiting hospital node uploads the encrypted medical data to the medical blockchain.
- the medical blockchain further includes a patient node, and when the computer program runs, controlling the device where the computer non-volatile readable storage medium is located further performs the following steps: any affiliated hospital node uses its own private key pair
- the first request authorization information is digitally signed and the first request authorization information is sent to the patient node; the patient node obtains the first request authorization information; the patient node uses the public hospital node's public key to check the first request authorization information; if After signing, the patient node uses the public key of the alliance hospital node to encrypt the password information of the medical data, and uses the patient node's own private key to digitally sign the encrypted password information to generate the first authorization information; the patient node Send the first authorization information to the affiliated hospital node; the affiliated hospital node obtains the first authorization information; the affiliated hospital node uses the patient node's public key for signing, and after the signing passes, use the affiliated hospital node's own private key pair
- the first authorization information is decrypted to obtain the password information of the medical data.
- the medical blockchain further includes a patient node and a judicial institution node.
- controlling the device where the computer non-volatile readable storage medium is located further performs the following steps: Any judicial institution node uses the judicial institution node's The private request key digitally signs the second request authorization information and sends the second request authorization information to the patient node; the patient node obtains the second request authorization information; the patient node uses the public key of the judicial institution node to perform the second request authorization information Signature verification; if the signature verification is passed, the patient node uses the public key of the judicial institution node to encrypt the password information of the medical data, and uses the patient node's own private key to digitally sign the encrypted password information to generate a second authorization Information; the patient node sends the second authorization information to the judicial authority node; the judicial authority node obtains the second authorization information; the affiliated hospital node uses the patient node's public key for signing, and uses the affiliated hospital node's Decrypting the second authorization
- the affiliated hospital corresponding to the affiliated hospital node meets at least the following conditions: the hospital size meets the predetermined conditions, the patient information security meets the preset requirements, and the affiliate agreement is signed.
- controlling the device where the computer's non-volatile readable storage medium is located further performs the following steps: the visiting hospital node generates encrypted medical data into blocks, the blocks include: the head and the body, the head It is used to store the summary information corresponding to the encrypted medical data, and the main body is used to store the encrypted medical data; the visiting hospital node uploads the block to the medical blockchain.
- the disclosed systems, devices, and methods may be implemented in other ways.
- the device embodiments described above are only schematic.
- the division of the unit is only a logical function division.
- multiple units or components may be combined.
- the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, which may be electrical, mechanical or other forms.
- the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objective of the solution of this embodiment.
- each functional unit in each embodiment of the present application may be integrated into one processing unit, or each of the units may exist separately physically, or two or more units may be integrated into one unit.
- the above integrated unit may be implemented in the form of hardware, or in the form of hardware plus software functional units.
- the above integrated unit implemented in the form of a software functional unit may be stored in a computer-readable storage medium.
- the above software functional unit is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) or a processor to execute the methods described in the embodiments of the present application. Some steps.
- the foregoing storage media include: U disks, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks or compact discs and other media that can store program codes .
Landscapes
- Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Theoretical Computer Science (AREA)
- General Health & Medical Sciences (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- General Physics & Mathematics (AREA)
- Bioethics (AREA)
- Epidemiology (AREA)
- Medical Informatics (AREA)
- Primary Health Care (AREA)
- Public Health (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
一种医疗数据处理方法、系统、计算机设备及可读存储介质,涉及医疗技术领域,适用于医疗数据的管理过程中。通过医疗区块链记录保存医疗数据,信息不可篡改,可以得到公共认可,透明化医疗过程。医疗区块链包括:多个联盟医院节点,用于存储医疗数据,联盟医院节点包括就诊医院节点以及非就诊医院节点。方法包括:就诊医院节点首先获取患者的医疗数据(101A),其次使用患者信息对医疗数据进行加密(102A),然后将加密后的医疗数据上传至医疗区块链(103A)。
Description
本申请要求于2018年06月28日提交中国专利局、申请号为201810688365.6、发明名称为“医疗数据处理方法、系统、计算机设备及可读存储介质”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
本申请涉及数据处理技术领域,尤其涉及医疗数据处理方法、系统、计算机设备及可读存储介质。
目前的医疗领域,每家医院通过各自独立的系统对就诊患者的病历信息进行管理和存储。
这种病历信息的管理和存储模式带来了很大的弊端,一方面来说,患者在不同时期可能会去不同的医院就诊,此时往往需要患者携带纸质病历辗转于各个医院之间,带来了很大的麻烦。另一方面来说,由于每家医院通过各自独立的系统管理和存储病历信息,在发生医患纠纷时,比如患者认为医生的诊治方式发生了错误,医院和患者各自提供病历信息,双方都可以对病历信息进行篡改,导致病历信息的真实可靠性无法保证。
因此目前这种病历信息的存储方式不够安全且缺乏灵活,无法满足医疗领域更高的发展需求。
【申请内容】
有鉴于此,本申请实施例提供了一种医疗数据处理方法、系统、计算机设备及可读存储介质,将患者的医疗数据都存储在医疗区块链中,医疗数据的信息安全得到了保证,且足够灵活,满足了医疗领域更高的发展需求。
第一方面,本申请实施例提供一种医疗数据处理方法,适用于医疗区块链,所述医疗区块 链包括多个用于存储医疗数据的联盟医院节点,所述联盟医院节点包括就诊医院节点以及非就诊医院节点,所述方法包括:
所述就诊医院节点获取患者的医疗数据;
所述就诊医院节点使用患者信息对所述医疗数据进行加密;
所述就诊医院节点将加密后的医疗数据上传至所述医疗区块链。
第二方面,本申请实施例提供一种医疗数据处理系统,适用于医疗区块链,所述医疗区块链包括多个用于存储医疗数据的联盟医院节点,所述联盟医院节点包括就诊医院节点以及非就诊医院节点,所述就诊医院节点包括:
第一获取单元,用于获取患者的医疗数据;
第一加密单元,用于使用患者信息对所述医疗数据进行加密;
上传单元,用于将加密后的医疗数据上传至所述医疗区块链。
第三方面,本申请实施例提供一种计算机设备,包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序,处理器执行计算机程序时实现如上述第一方面所述的方法。
第四方面,本申请实施例提供一种计算机非易失性可读存储介质,所述计算机非易失性可读存储介质包括存储的程序,其中,在所述程序运行时控制所述计算机非易失性可读存储介质所在设备执行如上述第一方面所述的方法。
本申请实施例提供了一种医疗数据处理方法、系统、计算机设备及可读存储介质,首先建立包括多个联盟医院节点的医疗区块链,然后将患者的医疗数据都加密存储在所述医疗区块链中。使用区块链记录保存医疗数据,信息不可篡改,可以得到公共认可,进而减少医患纠纷,同时透明化医疗过程。并且,多个联盟医院节点之间可以通过授权的方式在区块链中查看患者的医疗数据,无需患者携带纸质病历辗转于各个医院之间,为患者提供了大大的就诊方便。
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1是本申请实施例提供的一种医疗数据处理方法流程图;
图2是本申请实施例提供的另一种医疗数据处理方法流程图;
图3是本申请实施例提供的另一种医疗数据处理方法流程图;
图4是本申请实施例提供的另一种医疗数据处理方法流程图;
图5是本申请实施例提供的一种医疗数据处理系统的组成框图;
图6是本申请实施例提供的另一种医疗数据处理系统的组成框图;
图7是本申请实施例提供的另一种医疗数据处理系统的组成框图;
图8是本申请实施例提供的另一种医疗数据处理系统的组成框图;
图9是本申请实施例提供的一种计算机设备的组成框图。
为了更好的理解本申请的技术方案,下面结合附图对本申请实施例进行详细描述。
应当明确,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。
取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地,取决于语境,短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。
应当理解,本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
本申请实施例中的医疗区块链包含多个联盟医院节点,联盟医院节点包括就诊医院节点以及非就诊医院节点。
具体的,该医疗区块链的形式为联盟链,多个联盟医院节点可以共享医疗区块链内的医疗数据。
其中,就诊医院节点和非就诊医院节点,是针对某个患者某次的就诊而言的。
就诊医院指的是当时对患者进行诊治,并生成、上传该次诊治的医疗数据的医院。非就诊医院指的是医疗区块链中除就诊医院之外的其他医院。
具体的,加入医疗区块链的医院应该都是合法、具备一定规模且有联盟约定的正规医院。
在具体的实现过程中,可以通过设置以下判断规则,来确定某个医院是否具有加入该医疗区块链的资格,具体规则如下:
规则(1):医院是否合法;主要是查证医院是否具有《医疗机构执业许可证》等相关证件,来确定医院的合法性。
规则(2):医院规模的大小是否符合预定条件;通常来说规模太小的医院,比如只有一个医生的乡村医疗小站点,可能不符合加入医疗区块链的规模要求。
规则(3):医院的患者信息安全度是否满足预设要求;本着患者信息保密的原则,如果某个医院的患者信息总是被无端泄漏,则该联盟医院不被允许加入医疗区块链。
规则(4):是否签署联盟约定;在符合上述条件后,医院才可以签署联盟约定,签署联盟约定后可以加入医疗区块链。
具体的,医疗数据可以进行加密,并且可选的,医疗数据可以是病历信息。
在一种可选的实施方式中,考虑到患者如果作为医疗区块链中的一个节点存在,在授权其他医院节点查看自己以往的医疗数据的过程中,以通过这种区块链的交互方式来说,将更加方便。因此医疗区块链中还可以包括患者节点。
在一种可选的实施方式中,考虑到近年来医患事故频繁发生,在医疗区块链中还可以包含司法机构节点。司法机构节点在得到患者节点授权后可以查看该患者的以往的医疗数据。因各种诊治信息,比如手术过程、诊断过程、药品信息等各类信息,均存储在医疗区块链中,每个患者的看病过程都有记录,若发生纠纷,司法机构可以合理介入以解决医疗纠纷问题。
本申请实施例中的医疗区块链,包括多个联盟医院节点,将患者的医疗数据都加密存储在医疗区块链中。首先,使用区块链记录保存医疗数据,信息不可篡改,可以得到公共认可,进而减少医患纠纷,同时透明化医疗过程。其次,多个联盟医院节点之间可以通过授权的方式在区块链中查看患者的医疗数据,无需患者携带纸质病历辗转于各个医院之间,为患者提供了大大的就诊方便。
基于上述医疗区块链,本申请实施例提供了一种医疗数据处理方法,主要针对医疗数据上传至区块链的过程,以及医疗区块链中各节点被授权查看某个患者医疗数据的过程进行阐述。
首先是医疗数据的上传过程:
第一种实现方式,如图1所示,适用于就诊医院节点,具体包括:
101A、获取患者的医疗数据。
通常情况下,患者在所就诊的医院结束诊疗之后,该就诊医院的某个医生或护士等人员会记录该患者的医疗数据,并可以由患者现场确认医疗数据是否有误,在患者确认医疗数据无误后,医疗数据才会被保存。进而作为医疗区块链中一个节点的就诊医院节点,直接获取患者确认后的医疗数据,这样可以保证原始医疗数据的正确无误性。
102A、使用患者信息对医疗数据进行加密。
其中,考虑到患者的个人隐私等各种因素,在就诊医院节点上传患者的医疗数据至医疗区块链中前,需要对患者的医疗数据进行加密。具体的可以使用患者信息进行加密,患者信息可以包括患者的身份证号、医保卡号等可以唯一识别患者的信息,或者也可以是患者任意设置的特定密码。
需要说明的是,考虑到医疗区块链的管理方便问题,每个患者可以任意设置密码信息对自己的医疗数据进行加密,但是每个患者自己的全部病历数据应该保证是同一个密码。
103A、将加密后的医疗数据上传至医疗区块链。
具体的,就诊医院节点将加密后的医疗数据生成区块,然后上传至医疗区块链中该患者的区块链数据中。
在一个具体的实施例中,每个区块包括:
头部,用于存储医疗数据对应的摘要信息,主要包括患者的个人信息,比如身份证号或者医保卡号等可以唯一识别患者身份的信息;
主体,用于存储医疗数据。
在就诊医院节点上传患者的医疗数之后,其他医院节点也可以共享加密后的医疗数据。但是,虽然各医院节点中存储有加密后的医疗数据,但是若要查看这些数据,还需要患者节点的授权,也即需要医疗数据的密码信息。
上述申请实施例提供的医疗数据处理方法,医疗区块链包括多个联盟医院节点,将患者的医疗数据都加密存储在医疗区块链中。首先,使用区块链记录保存医疗数据,信息不可篡改,可以得到公共认可,进而减少医患纠纷,同时透明化医疗过程。其次,多个联盟医院节点之间可以通过授权的方式在区块链中查看患者的医疗数据,无需患者携带纸质病历辗转于各个医院之间,为患者提供了大大的就诊方便。
基于第一种实现方式,考虑到对患者的医疗数据加密过程还可以用其他的方法完成,所以衍生出了上 传医疗数据的第二种实现方式,如图2所示,适用于就诊医院节点,包括:
101B、获取加密后患者的医疗数据。
第二种实现方式下,患者在所就诊的医院结束就诊之后,该就诊医院的某个医生或护士等人员会记录该患者的医疗数据,并在患者确认医疗数据无误后,将这些医疗数据加密保存。进而作为医疗区块链中一个节点的就诊医院节点,直接获取加密后的医疗数据。
具体的加密形式可以参见步骤102A。
102B、将加密后患者的医疗数据上传至医疗区块链。
具体的,就诊医院节点将加密后患者的医疗数据生成区块,然后上传至医疗区块链中该患者的区块链数据中。
在就诊医院节点上传患者的医疗数之后,其他医院节点也可以共享加密后的医疗数据。但是,虽然各医院节点中存储有加密后的医疗数据,但是若要查看这些数据,还需要患者的授权,也即需要医疗数据的密码信息。
本申请实施例提供的医疗数据处理方法,将加密后患者的医疗数据存储在包括多个联盟医院节点的医疗区块链中。首先,使用区块链记录保存医疗数据,信息不可篡改,可以得到公共认可,进而减少医患纠纷,同时透明化医疗过程。其次,多个联盟医院节点之间可以通过授权的方式在区块链中查看患者的医疗数据,无需患者携带纸质病历辗转于各个医院之间,为患者提供了大大的就诊方便。
进一步来说,结合前述医疗数据的上传方法流程,若任一医院节点需要查看患者的医疗数据,首先要根据患者的个人信息,比如身份证号或医保卡号等,查找到该患者的区块链数据,然后再通过不同的方式获取患者的医疗数据的密码信息,进而才可以查看患者的医疗数据。
基于上述情况,分为两种方式获取医疗数据的密码信息。
第一种方式,若医疗区块链中的节点都是医院,也即没有患者节点。这种情况下,医院节点需要得到患者的链下许可:比如可以是链下联系患者,进而获取患者的医疗数据的密码信息,以及患者的身份证号等个人信息。考虑到在实际过程中,通常是患者去就医时,就诊医院才会查看患者的医疗数据,此时可以通过患者的当面许可来查看患者的医疗数据。值得附加说明的是,若是通过患者的当面许可来查看患者的医疗数据,则考虑到现有通信技术的发达,避免密码信息被盗用,则密码信息还可以设置为患者的指纹、虹膜、面部特征等生物特征,通过生物特征识别方式来进一步保证医疗数据的安全性,此时通过患者自行操作,来协助医生查看医疗数据。
第二种实现方式,若医疗区块链中患者作为医疗区块链中的一个节点,则患者节点可以授权其他节点(包括联盟医院节点或者司法机构节点等)查看自己的医疗数据。
授权过程包括以下步骤:
首先是请求授权的过程,如图3所示,包括:
请求查看患者医疗数据的某联盟医院节点(或某司法机构节点):
201、使用该联盟医院节点(或该司法机构节点)的自身私钥对请求授权信息进行数字签名,并向患者节点发送请求授权信息。
其中,请求授权信息可以是请求获取患者的医疗数据的密码信息,或者还可以请求该患者的身份证号或医疗卡号等个人信息等。
具体的,请求查看患者的医疗数据的某联盟医院节点(或某司法机构节点),对请求授权信息进行数字签名,是为了使该患者节点能够确认医院节点(或某司法机构节点)的身份。
患者节点:
203、获取数字签名后的请求授权信息,使用该联盟医院节点(或该司法机构节点)的公钥对数字签名后的请求授权信息进行验签。
在该患者节点获取到数字签名后的请求授权信息之后,首先使用对方节点的公钥对请求授权信息进行 验签,以确定请求授权的联盟医院或司法机构的身份。在通过验签之后,再发送自己的医疗数据的密码信息或个人信息至对方节点(即执行授权过程)。
其中,验签指的是对请求授权信息的数字签名进行验证,是为了确认数字签名节点的身份。
需要说明的是,公钥(Public Key)与私钥(Private Key)是通过一种算法得到的一个密钥对(即一个公钥和一个私钥),公钥是密钥对中公开的部分,私钥则是非公开的部分。区块链中每个节点的公钥,在该区块链中是公知的,而每个节点的私钥只有自己可知。公钥通常用于加密会话密钥、验证数字签名,或加密可以用相应的私钥解密的数据信息。通过这种算法得到的密钥对能保证在世界范围内是唯一的。使用这个密钥对的时候,如果用其中一个密钥加密一段数据信息,必须用另一个密钥解密。比如用公钥加密数据信息就必须用私钥解密,如果用私钥加密也必须用公钥解密,否则解密将不会成功。
然后是授权的过程,如图4所示,包括:
患者节点:
204、若通过验签,使用该联盟医院节点(或该司法机构节点)的公钥对医疗数据的密码信息或患者的个人信息进行加密,并使用该患者节点的自身私钥对加密后的密码信息或个人信息进行数字签名,以生成授权信息。
需要说明的是,为了保证医疗数据的安全性,对于医疗数据的密码信息或者患者的个人信息,在医疗区块链中通过非对称加密的方式进行加密传输。使用该联盟医院节点(或该司法机构节点)的公钥对医疗数据的密码信息或患者的个人信息进行加密,只有通过该联盟医院节点(或该司法机构节点)的私钥才能解密,所以虽然加密后的授权信息是全网广播的,但是只有该联盟医院节点(或该司法机构节点)才能解密密文,得到患者的医疗数据的密码信息或个人信息。
205、将授权信息发送给该联盟医院节点(或该司法机构节点)。
请求查看患者医疗数据的某联盟医院节点(或某司法机构节点):
207、获取授权信息,先使用患者节点的公钥进行验签,验签通过后使用该联盟医院节点(或该司法机构节点)的自身私钥对授权信息进行解密,进而得到患者的医疗数据的密码信息或患者的个人信息。
具体的,在该联盟医院节点(或该司法机构节点)获取到该授权信息之后,先使用患者节点的公钥验签,确认信息来源的患者节点身份之后,在使用自身的秘钥对密文进行解密,进而得到患者的医疗数据的密码信息或个人信息,进而医院或者司法机构节点可以查询患者的病历等其他医疗数据。
这种密文授权的方式可以有效降低医疗数据的公开风险,保障了患者的隐私安全。
本申请实施例提供了一种医疗数据处理系统,适用于上述医疗数据上传过程的第一种实现方式,如图5所示,就诊医院节点包括:
第一获取单元31,用于获取患者的医疗数据。
第一加密单元32,用于使用患者信息对医疗数据进行加密。
上传单元33,用于将加密后的医疗数据上传至医疗区块链。
本申请实施例提供了一种医疗数据处理系统,适用于上述医疗数据上传过程的第二种实现方式,如图6所示,就诊医院节点包括:
第一处理单元41,用于获取加密后患者的医疗数据。
第二处理单元42,用于将加密后患者的医疗数据上传至医疗区块链。
可选的是,如图7所示,医疗区块链还包括患者节点,
任一联盟医院节点包括:
第一签名单元51,用于使用该联盟医院节点的自身私钥对第一请求授权信息进行数字签名,并向患者节点发送第一请求授权信息。
患者节点包括:
第二获取单元52,用于获取数字签名后的第一请求授权信息。
第一验签单元53,用于使用该联盟医院节点的公钥对第一请求授权信息进行验签。
第二加密单元54,若通过验签,用于使用该联盟医院节点的公钥对医疗数据的密码信息进行加密,并使用患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第一授权信息。
第一发送单元55,用于将第一授权信息发送给该联盟医院节点。
任一联盟医院节点还包括:
第三获取单元56,用于获取第一授权信息。
第一解密单元57,用于使用患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对第一授权信息进行解密,以得到医疗数据的密码信息。
可选的是,如图8所示,医疗区块链还包括患者节点和司法机构节点,
任一司法机构节点包括:
第二签名单元61,用于使用该司法机构节点的自身私钥对第二请求授权信息进行数字签名,并向患者节点发送第二请求授权信息。
患者节点包括:
第四获取单元62,用于获取数字签名后的第二请求授权信息。
第二验签单元63,用于使用该司法机构节点的公钥对第二请求授权信息进行验签。
第三加密单元64,若通过验签,用于使用该司法机构节点的公钥对医疗数据的密码信息进行加密,并使用患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第二授权信息。
第二发送单元65,用于将第二授权信息发送给该司法机构节点。
任一司法机构节点包括:
第五获取单元66,用于获取第二授权信息。
第二解密单元67,用于使用患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对第二授权信息进行解密,以得到医疗数据的密码信息。
可选的是,联盟医院节点对应的联盟医院至少符合以下条件:医院规模符合预定条件、患者信息安全度满足预设要求以及签署联盟约定。
上述申请实施例提供的医疗数据处理系统,将患者的医疗数据都加密存储在包括多个联盟医院节点的医疗区块链中。首先,使用区块链记录保存医疗数据,信息不可篡改,可以得到公共认可,进而减少医患纠纷,同时透明化医疗过程。其次,多个联盟医院节点之间可以通过授权的方式在区块链中查看患者的医疗数据,无需患者携带纸质病历辗转于各个医院之间,为患者提供了大大的就诊方便。
本申请实施例提供了一种计算机设备,如图9所示,包括存储器71、处理器72以及存储在存储器71中并可在处理器72上运行的计算机程序,适用于医疗区块链,医疗区块链包括多个用于存储医疗数据的联盟医院节点,联盟医院节点包括就诊医院节点以及非就诊医院节点,计算机程序指令被处理器72加载并执行时实现以下步骤:就诊医院节点获取患者的医疗数据;就诊医院节点使用患者信息对医疗数据进行加密;就诊医院节点将加密后的医疗数据上传至医疗区块链。
可选地,医疗区块链还包括患者节点,计算机程序指令被处理器72加载并执行时还实现以下步骤:任一联盟医院节点使用该联盟医院节点的自身私钥对第一请求授权信息进行数字签名,并向患者节点发送第一请求授权信息;患者节点获取第一请求授权信息;患者节点使用该联盟医院节点的公钥对第一请求授权信息进行验签;若通过验签,患者节点使用该联盟医院节点的公钥对医疗数据的密码信息进行加密,并使用患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第一授权信息;患者节点将第一授权信息发送给该联盟医院节点;该联盟医院节点获取第一授权信息;该联盟医院节点使用患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对第一授权信息进行解密,以得到医疗数据的密码信息。
可选地,医疗区块链还包括患者节点和司法机构节点,计算机程序指令被处理器72加载并执行时还实 现以下步骤:任一司法机构节点使用该司法机构节点的自身私钥对第二请求授权信息进行数字签名,并向患者节点发送第二请求授权信息;患者节点获取第二请求授权信息;患者节点使用该司法机构节点的公钥对第二请求授权信息进行验签;若通过验签,患者节点使用该司法机构节点的公钥对医疗数据的密码信息进行加密,并使用患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第二授权信息;患者节点将第二授权信息发送给该司法机构节点;该司法机构节点获取第二授权信息;该联盟医院节点使用患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对第二授权信息进行解密,以得到医疗数据的密码信息。
可选地,联盟医院节点对应的联盟医院至少符合以下条件:医院规模符合预定条件、患者信息安全度满足预设要求以及签署联盟约定。
可选地,计算机程序指令被处理器72加载并执行时还实现以下步骤:就诊医院节点将加密后的医疗数据生成区块,区块包括:头部和主体,头部用于存储加密后的医疗数据对应的摘要信息,主体用于存储加密后的医疗数据;就诊医院节点将区块上传至医疗区块链。
本申请实施例提供了一种计算机非易失性可读存储介质,适用于医疗区块链,医疗区块链包括多个用于存储医疗数据的联盟医院节点,联盟医院节点包括就诊医院节点以及非就诊医院节点,计算机非易失性可读存储介质存储有计算机程序,在计算机程序运行时控制计算机非易失性可读存储介质所在设备执行以下步骤:就诊医院节点获取患者的医疗数据;就诊医院节点使用患者信息对医疗数据进行加密;就诊医院节点将加密后的医疗数据上传至医疗区块链。
可选地,医疗区块链还包括患者节点,在计算机程序运行时控制计算机非易失性可读存储介质所在设备还执行以下步骤:任一联盟医院节点使用该联盟医院节点的自身私钥对第一请求授权信息进行数字签名,并向患者节点发送第一请求授权信息;患者节点获取第一请求授权信息;患者节点使用该联盟医院节点的公钥对第一请求授权信息进行验签;若通过验签,患者节点使用该联盟医院节点的公钥对医疗数据的密码信息进行加密,并使用患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第一授权信息;患者节点将第一授权信息发送给该联盟医院节点;该联盟医院节点获取第一授权信息;该联盟医院节点使用患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对第一授权信息进行解密,以得到医疗数据的密码信息。
可选地,医疗区块链还包括患者节点和司法机构节点,在计算机程序运行时控制计算机非易失性可读存储介质所在设备还执行以下步骤:任一司法机构节点使用该司法机构节点的自身私钥对第二请求授权信息进行数字签名,并向患者节点发送第二请求授权信息;患者节点获取第二请求授权信息;患者节点使用该司法机构节点的公钥对第二请求授权信息进行验签;若通过验签,患者节点使用该司法机构节点的公钥对医疗数据的密码信息进行加密,并使用患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第二授权信息;患者节点将第二授权信息发送给该司法机构节点;该司法机构节点获取第二授权信息;该联盟医院节点使用患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对第二授权信息进行解密,以得到医疗数据的密码信息。
可选地,联盟医院节点对应的联盟医院至少符合以下条件:医院规模符合预定条件、患者信息安全度满足预设要求以及签署联盟约定。
可选地,在计算机程序运行时控制计算机非易失性可读存储介质所在设备还执行以下步骤:就诊医院节点将加密后的医疗数据生成区块,区块包括:头部和主体,头部用于存储加密后的医疗数据对应的摘要信息,主体用于存储加密后的医疗数据;就诊医院节点将区块上传至医疗区块链。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体 工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机装置(可以是个人计算机,服务器,或者网络装置等)或处理器(Processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。
Claims (20)
- 一种医疗数据处理方法,其特征在于,适用于医疗区块链,所述医疗区块链包括多个用于存储医疗数据的联盟医院节点,所述联盟医院节点包括就诊医院节点以及非就诊医院节点,所述方法包括:所述就诊医院节点获取患者的医疗数据;所述就诊医院节点使用患者信息对所述医疗数据进行加密;所述就诊医院节点将加密后的医疗数据上传至所述医疗区块链。
- 根据权利要求1所述的方法,其特征在于,所述医疗区块链还包括患者节点,所述方法还包括:任一联盟医院节点使用该联盟医院节点的自身私钥对第一请求授权信息进行数字签名,并向所述患者节点发送所述第一请求授权信息;所述患者节点获取所述第一请求授权信息;所述患者节点使用该联盟医院节点的公钥对所述第一请求授权信息进行验签;若通过验签,所述患者节点使用该联盟医院节点的公钥对所述医疗数据的密码信息进行加密,并使用所述患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第一授权信息;所述患者节点将所述第一授权信息发送给该联盟医院节点;该联盟医院节点获取所述第一授权信息;该联盟医院节点使用所述患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对所述第一授权信息进行解密,以得到所述医疗数据的密码信息。
- 根据权利要求1所述的方法,其特征在于,所述医疗区块链还包括患者节点和司法机构节点,所述方法还包括:任一司法机构节点使用该司法机构节点的自身私钥对第二请求授权信息进行数字签名,并向所述患者节点发送所述第二请求授权信息;所述患者节点获取所述第二请求授权信息;所述患者节点使用该司法机构节点的公钥对所述第二请求授权信息进行验签;若通过验签,所述患者节点使用该司法机构节点的公钥对所述医疗数据的密码信息进行加密,并使用所述患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第二授权信息;所述患者节点将所述第二授权信息发送给该司法机构节点;该司法机构节点获取所述第二授权信息;该联盟医院节点使用所述患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自 身私钥对所述第二授权信息进行解密,以得到所述医疗数据的密码信息。
- 根据权利要求1所述的方法,其特征在于,所述联盟医院节点对应的联盟医院至少符合以下条件:医院规模符合预定条件、患者信息安全度满足预设要求以及签署联盟约定。
- 根据权利要求1至4任一项所述的方法,其特征在于,所述就诊医院节点将加密后的医疗数据上传至所述医疗区块链,包括:所述就诊医院节点将所述加密后的医疗数据生成区块,所述区块包括:头部和主体,所述头部用于存储所述加密后的医疗数据对应的摘要信息,所述主体用于存储所述加密后的医疗数据;所述就诊医院节点将所述区块上传至所述医疗区块链。
- 一种医疗数据处理系统,其特征在于,适用于医疗区块链,所述医疗区块链包括多个用于存储医疗数据的联盟医院节点,所述联盟医院节点包括就诊医院节点以及非就诊医院节点,所述就诊医院节点包括:第一获取单元,用于获取患者的医疗数据;第一加密单元,用于使用患者信息对所述医疗数据进行加密;上传单元,用于将加密后的医疗数据上传至所述医疗区块链。
- 根据权利要求6所述的系统,其特征在于,所述医疗区块链还包括患者节点,任一联盟医院节点包括:第一签名单元,用于使用该联盟医院节点的自身私钥对第一请求授权信息进行数字签名,并向所述患者节点发送所述第一请求授权信息;所述患者节点包括:第二获取单元,用于获取所述第一请求授权信息;第一验签单元,用于使用该联盟医院节点的公钥对所述第一请求授权信息进行验签;第二加密单元,若通过验签,用于使用该联盟医院节点的公钥对所述医疗数据的密码信息进行加密,并使用所述患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第一授权信息;第一发送单元,用于将所述第一授权信息发送给该联盟医院节点;所述任一联盟医院节点还包括:第三获取单元,用于获取所述第一授权信息;第一解密单元,用于使用所述患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对所述第一授权信息进行解密,以得到所述医疗数据的密码信息。
- 根据权利要求6所述的系统,其特征在于,所述医疗区块链还包括患者节点和司法机 构节点,任一司法机构节点包括:第二签名单元,用于使用该司法机构节点的自身私钥对第二请求授权信息进行数字签名,并向所述患者节点发送所述第二请求授权信息;所述患者节点包括:第四获取单元,用于获取所述第二请求授权信息;第二验签单元,用于使用该司法机构节点的公钥对所述第二请求授权信息进行验签;第三加密单元,若通过验签,用于使用该司法机构节点的公钥对所述医疗数据的密码信息进行加密,并使用所述患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第二授权信息;第二发送单元,用于将所述第二授权信息发送给该司法机构节点;所述任一司法机构节点包括:第五获取单元,用于获取所述第二授权信息;第二解密单元,用于使用所述患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对所述第二授权信息进行解密,以得到所述医疗数据的密码信息。
- 根据权利要求6所述的系统,其特征在于,所述联盟医院节点对应的联盟医院至少符合以下条件:医院规模符合预定条件、患者信息安全度满足预设要求以及签署联盟约定。
- 根据权利要求6至9任一项所述的系统,其特征在于,所述上传单元包括:生成模块,用于所述就诊医院节点将所述加密后的医疗数据生成区块,所述区块包括:头部和主体,所述头部用于存储所述加密后的医疗数据对应的摘要信息,所述主体用于存储所述加密后的医疗数据;上传模块,用于所述就诊医院节点将所述区块上传至所述医疗区块链。
- 一种计算机设备,包括存储器和处理器,所述存储器用于存储包括程序指令的信息,所述处理器用于控制所述程序指令的执行,其特征在于,适用于医疗区块链,所述医疗区块链包括多个用于存储医疗数据的联盟医院节点,所述联盟医院节点包括就诊医院节点以及非就诊医院节点,所述程序指令被所述处理器加载并执行时实现以下步骤:所述就诊医院节点获取患者的医疗数据;所述就诊医院节点使用患者信息对所述医疗数据进行加密;所述就诊医院节点将加密后的医疗数据上传至所述医疗区块链。
- 根据权利要求11所述的计算机设备,其特征在于,所述医疗区块链还包括患者节点,所述程序指令被所述处理器加载并执行时还实现以下步骤:任一联盟医院节点使用该联盟医院节点的自身私钥对第一请求授权信息进行数字签名,并向所述患者节点发送所述第一请求授权信息;所述患者节点获取所述第一请求授权信息;所述患者节点使用该联盟医院节点的公钥对所述第一请求授权信息进行验签;若通过验签,所述患者节点使用该联盟医院节点的公钥对所述医疗数据的密码信息进行加密,并使用所述患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第一授权信息;所述患者节点将所述第一授权信息发送给该联盟医院节点;该联盟医院节点获取所述第一授权信息;该联盟医院节点使用所述患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对所述第一授权信息进行解密,以得到所述医疗数据的密码信息。
- 根据权利要求11所述的计算机设备,其特征在于,所述医疗区块链还包括患者节点和司法机构节点,所述程序指令被所述处理器加载并执行时还实现以下步骤:任一司法机构节点使用该司法机构节点的自身私钥对第二请求授权信息进行数字签名,并向所述患者节点发送所述第二请求授权信息;所述患者节点获取所述第二请求授权信息;所述患者节点使用该司法机构节点的公钥对所述第二请求授权信息进行验签;若通过验签,所述患者节点使用该司法机构节点的公钥对所述医疗数据的密码信息进行加密,并使用所述患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第二授权信息;所述患者节点将所述第二授权信息发送给该司法机构节点;该司法机构节点获取所述第二授权信息;该联盟医院节点使用所述患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对所述第二授权信息进行解密,以得到所述医疗数据的密码信息。
- 根据权利要求11所述的计算机设备,其特征在于,所述联盟医院节点对应的联盟医院至少符合以下条件:医院规模符合预定条件、患者信息安全度满足预设要求以及签署联盟约定。
- 根据权利要求11至14任一项所述的计算机设备,其特征在于,所述程序指令被所述处理器加载并执行时还实现以下步骤:所述就诊医院节点将所述加密后的医疗数据生成区块,所述区块包括:头部和主体,所述头部用于存储所述加密后的医疗数据对应的摘要信息,所述主体用于存储所述加密后的医疗数据;所述就诊医院节点将所述区块上传至所述医疗区块链。
- 一种计算机非易失性可读存储介质,其特征在于,适用于医疗区块链,所述医疗区块链包括多个用于存储医疗数据的联盟医院节点,所述联盟医院节点包括就诊医院节点以及非就诊医院节点,所述计算机非易失性可读存储介质包括存储的程序,其中,在所述程序运行时控制所述计算机非易失性可读存储介质所在设备执行以下步骤:所述就诊医院节点获取患者的医疗数据;所述就诊医院节点使用患者信息对所述医疗数据进行加密;所述就诊医院节点将加密后的医疗数据上传至所述医疗区块链。
- 根据权利要求16所述的计算机非易失性可读存储介质,其特征在于,所述医疗区块链还包括患者节点,在所述程序运行时控制所述计算机非易失性可读存储介质所在设备还执行以下步骤:任一联盟医院节点使用该联盟医院节点的自身私钥对第一请求授权信息进行数字签名,并向所述患者节点发送所述第一请求授权信息;所述患者节点获取所述第一请求授权信息;所述患者节点使用该联盟医院节点的公钥对所述第一请求授权信息进行验签;若通过验签,所述患者节点使用该联盟医院节点的公钥对所述医疗数据的密码信息进行加密,并使用所述患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第一授权信息;所述患者节点将所述第一授权信息发送给该联盟医院节点;该联盟医院节点获取所述第一授权信息;该联盟医院节点使用所述患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对所述第一授权信息进行解密,以得到所述医疗数据的密码信息。
- 根据权利要求16所述的计算机非易失性可读存储介质,其特征在于,所述医疗区块链还包括患者节点和司法机构节点,在所述程序运行时控制所述计算机非易失性可读存储介质所在设备还执行以下步骤:任一司法机构节点使用该司法机构节点的自身私钥对第二请求授权信息进行数字签名,并向所述患者节点发送所述第二请求授权信息;所述患者节点获取所述第二请求授权信息;所述患者节点使用该司法机构节点的公钥对所述第二请求授权信息进行验签;若通过验签,所述患者节点使用该司法机构节点的公钥对所述医疗数据的密码信息进行加密,并使用所述患者节点的自身私钥对加密后的密码信息进行数字签名,以生成第二授权信息;所述患者节点将所述第二授权信息发送给该司法机构节点;该司法机构节点获取所述第二授权信息;该联盟医院节点使用所述患者节点的公钥进行验签,验签通过后使用该联盟医院节点的自身私钥对所述第二授权信息进行解密,以得到所述医疗数据的密码信息。
- 根据权利要求16所述的计算机非易失性可读存储介质,其特征在于,所述联盟医院节点对应的联盟医院至少符合以下条件:医院规模符合预定条件、患者信息安全度满足预设要求以及签署联盟约定。
- 根据权利要求16至19任一项所述的计算机非易失性可读存储介质,其特征在于,在所述程序运行时控制所述计算机非易失性可读存储介质所在设备还执行以下步骤:所述就诊医院节点将所述加密后的医疗数据生成区块,所述区块包括:头部和主体,所述头部用于存储所述加密后的医疗数据对应的摘要信息,所述主体用于存储所述加密后的医疗数据;所述就诊医院节点将所述区块上传至所述医疗区块链。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810688365.6A CN109243553A (zh) | 2018-06-28 | 2018-06-28 | 医疗数据处理方法、系统、计算机设备及可读存储介质 |
CN201810688365.6 | 2018-06-28 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2020000825A1 true WO2020000825A1 (zh) | 2020-01-02 |
Family
ID=65072131
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2018/113087 WO2020000825A1 (zh) | 2018-06-28 | 2018-10-31 | 医疗数据处理方法、系统、计算机设备及可读存储介质 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN109243553A (zh) |
WO (1) | WO2020000825A1 (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114707981A (zh) * | 2020-12-16 | 2022-07-05 | 福州数据技术研究院有限公司 | 一种基于区块链分布式记账的医院联盟间预交金管理方法和系统 |
TWI845966B (zh) | 2021-06-21 | 2024-06-21 | 臺北榮民總醫院 | 數位健康資訊驗證系統及方法 |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110070926A (zh) * | 2019-03-21 | 2019-07-30 | 深圳壹账通智能科技有限公司 | 基于区块链的数据查询方法、装置、设备及可读存储介质 |
CN109979555A (zh) * | 2019-04-09 | 2019-07-05 | 镇江市第一人民医院 | 一种病案数据管理方法 |
WO2020206695A1 (en) * | 2019-04-12 | 2020-10-15 | Hangzhou Nuowei Information Technology Co., Ltd. | System for decentralized ownership and secure sharing of personalized health data |
CN111128322A (zh) * | 2019-12-06 | 2020-05-08 | 北京先通康桥医药科技有限公司 | 基于区块链的医疗数据处理方法、服务器及系统 |
CN111145850A (zh) * | 2019-12-23 | 2020-05-12 | 支付宝(杭州)信息技术有限公司 | 基于区块链的医疗数据查询方法以及装置 |
CN111312378A (zh) * | 2020-02-17 | 2020-06-19 | 吉林大学 | 一种基于区块链的医疗信息有偿共享方法 |
CN111613285A (zh) * | 2020-05-22 | 2020-09-01 | 陕西科技大学 | 一种基于区块链技术的医院患者信息管理系统 |
CN112133396B (zh) * | 2020-09-23 | 2023-02-03 | 深圳平安智慧医健科技有限公司 | 医疗数据共享方法、装置、电子设备及介质 |
CN112422522B (zh) * | 2020-10-28 | 2023-01-20 | 广东工业大学 | 一种基于区块链的医疗数据安全共享方法 |
CN112466425B (zh) * | 2021-01-28 | 2021-04-02 | 北京妙医佳健康科技集团有限公司 | 一种信息处理方法和装置 |
CN112908442A (zh) * | 2021-03-05 | 2021-06-04 | 京东数科海益信息科技有限公司 | 医疗数据共享方法、装置、设备及计算机可读介质 |
CN113270176A (zh) * | 2021-05-19 | 2021-08-17 | 山东起跑线母婴健康管理有限公司 | 一种分娩前后状态信息处理系统 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106354994A (zh) * | 2016-08-22 | 2017-01-25 | 布比(北京)网络技术有限公司 | 处理医疗数据的方法及系统 |
CN106934243A (zh) * | 2017-03-17 | 2017-07-07 | 北京好运到信息科技有限公司 | 一种电子病历管理方法及系统 |
CN107391944A (zh) * | 2017-07-27 | 2017-11-24 | 北京太云科技有限公司 | 一种基于区块链的电子病历共享系统 |
CN107767926A (zh) * | 2017-11-15 | 2018-03-06 | 中国联合网络通信集团有限公司 | 基于区块链的医疗数据管理系统及访问方法 |
CN107785073A (zh) * | 2017-01-22 | 2018-03-09 | 平安医疗健康管理股份有限公司 | 基于区块链的医疗检查结果共享方法、装置和系统 |
CN107819770A (zh) * | 2017-11-15 | 2018-03-20 | 中国联合网络通信集团有限公司 | 基于区块链的医疗信息共享隐私保护方法及装置 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105118004A (zh) * | 2015-08-04 | 2015-12-02 | 上海象形通讯科技有限公司 | 一种电子处方的安全使用方法 |
CN107959663A (zh) * | 2016-10-17 | 2018-04-24 | 孙建松 | 一种利用患者身份信息加密的互联网诊疗系统与方法 |
CN108074629A (zh) * | 2016-11-14 | 2018-05-25 | 阿里巴巴集团控股有限公司 | 健康档案管理系统和方法、用户客户端 |
CN108092982B (zh) * | 2017-12-22 | 2020-10-23 | 广东工业大学 | 一种基于联盟链的数据存储方法及系统 |
-
2018
- 2018-06-28 CN CN201810688365.6A patent/CN109243553A/zh active Pending
- 2018-10-31 WO PCT/CN2018/113087 patent/WO2020000825A1/zh active Application Filing
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106354994A (zh) * | 2016-08-22 | 2017-01-25 | 布比(北京)网络技术有限公司 | 处理医疗数据的方法及系统 |
CN107785073A (zh) * | 2017-01-22 | 2018-03-09 | 平安医疗健康管理股份有限公司 | 基于区块链的医疗检查结果共享方法、装置和系统 |
CN106934243A (zh) * | 2017-03-17 | 2017-07-07 | 北京好运到信息科技有限公司 | 一种电子病历管理方法及系统 |
CN107391944A (zh) * | 2017-07-27 | 2017-11-24 | 北京太云科技有限公司 | 一种基于区块链的电子病历共享系统 |
CN107767926A (zh) * | 2017-11-15 | 2018-03-06 | 中国联合网络通信集团有限公司 | 基于区块链的医疗数据管理系统及访问方法 |
CN107819770A (zh) * | 2017-11-15 | 2018-03-20 | 中国联合网络通信集团有限公司 | 基于区块链的医疗信息共享隐私保护方法及装置 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114707981A (zh) * | 2020-12-16 | 2022-07-05 | 福州数据技术研究院有限公司 | 一种基于区块链分布式记账的医院联盟间预交金管理方法和系统 |
TWI845966B (zh) | 2021-06-21 | 2024-06-21 | 臺北榮民總醫院 | 數位健康資訊驗證系統及方法 |
Also Published As
Publication number | Publication date |
---|---|
CN109243553A (zh) | 2019-01-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2020000825A1 (zh) | 医疗数据处理方法、系统、计算机设备及可读存储介质 | |
US11087021B2 (en) | Secure access to individual information | |
US11025419B2 (en) | System for digital identity authentication and methods of use | |
US10860743B2 (en) | Encryption scheme for making secure patient data available to authorized parties | |
US20200168306A1 (en) | Method and system for sharing electronic medical and health records | |
RU2602790C2 (ru) | Безопасный доступ к персональным записям о состоянии здоровья в экстренных ситуациях | |
US11521720B2 (en) | User medical record transport using mobile identification credential | |
CN111261250A (zh) | 一种基于区块链技术的医疗数据共享方法、装置、电子设备及存储介质 | |
Hupperich et al. | Flexible patient-controlled security for electronic health records | |
US20080028214A1 (en) | Secure flash media for medical records | |
US10893027B2 (en) | Secure access to individual information | |
KR101182086B1 (ko) | 전자처방전 제어 관리 시스템, 병원단말장치, 및 전자처방전을 제어 관리하는 방법 | |
US20220005039A1 (en) | Delegation method and delegation request managing method | |
CN111933292A (zh) | 基于区块链的医联体及医疗数据交互方法和存储介质 | |
JPH09282393A (ja) | 保健医療カードとオンラインデータベースの連携方法 | |
JPH10111897A (ja) | 診療情報共有化方法 | |
CN110418338B (zh) | 可植入医疗设备的轻量级rfid无线认证方法及其系统 | |
CN112398920A (zh) | 一种基于区块链技术的医疗隐私数据保护方法 | |
WO2014201599A1 (zh) | 一种用于信息的认证授权和安全使用的方法与系统 | |
JP2009301131A (ja) | 医療データ管理システム、及び医療データ管理方法 | |
CN111274592B (zh) | 一种基于区块链和生物特征的电子病历系统 | |
CN115547441A (zh) | 一种基于个人健康医疗数据的安全获取方法及系统 | |
KR102531929B1 (ko) | 개인 정보 보안 강화된 블록체인 기반 의료 정보 제공 방법 및 시스템 | |
KR102662521B1 (ko) | Cdm아이디의 상호 대응을 이용한 의료데이터 제공시스템 | |
Bong et al. | Hyperledger Fabric-based Reliable Personal Health Information Sharing Model |
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: 18924846 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 18924846 Country of ref document: EP Kind code of ref document: A1 |