Verifiable search method for medical block chain data
Technical Field
The invention belongs to the technical field of information, and relates to a verifiable search method for medical block chain data.
Background
The electronic medical record facilitates the medical institution to process and record medical data. Originally, the medical institutions stored the local servers in their respective servers due to their advantages of convenient management, high efficiency and safety, but this resulted in fragmentation of data and was not conducive to data sharing. The cloud server serves as a reliable storage center, and is beneficial to saving local storage cost and data sharing. However, the cloud service centered on the server inevitably causes a single point of failure, so that the correctness and reliability of the medical data cannot be guaranteed.
Since the digital encryption currency bitcoin is invented by the smart card, the bottom layer block chain technology of the digital encryption currency bitcoin enters the public view because of the characteristics of distribution, tamper resistance, transparency, traceability and the like, and the digital encryption currency bitcoin provides a credible environment under the condition that two parties are not credible. Blockchains have been used in a variety of fields, such as energy, financial services, supply chains, and medical care. In the medical field, the shortcomings of traditional and cloud-based electronic medical data systems are well addressed by utilizing these characteristics of blockchain technology. In a medical blockchain system, after patient medical data is stored in a blockchain, most work provides security and privacy protection of the system by adopting access control policies, encryption and other technologies. On this basis, it is necessary to consider how the user arbitrarily searches for a specific type of medical data at his or her will.
In the block chain system, because the data recording mode of the block chain is a linear structure, a method for sequentially traversing and searching is used, namely a complete block chain needs to be traversed during searching. However, as the chain grows, each search takes longer. Sometimes, after searching the entire chain, there is even no data that meets the requirements. Taking Ethereum as an example, since medical data is some extra data uploaded into the blockchain by calling related functions through smart contracts, the extra data is in hexadecimal form in the "input" field in the transaction. When searching for specific types of medical data, on one hand, the blocks need to be searched sequentially in order, then the transaction contents in the blocks need to be searched, and finally the input field in the transaction is decoded to check the related medical data and judge whether the type of the medical data is matched with the type of the medical data searched by the user, which causes low searching efficiency. On the other hand, most of the current blockchain systems support queries for blocks, transactions, account balances, etc., and few have specific types of searches for additional data deposited in the blockchain. Therefore, it is a very important task to design a search mechanism that enables the user to quickly search for medical data on the chain at his or her will.
Disclosure of Invention
In view of the above, an object of the present invention is to provide a verifiable search method for medical blockchain data, which enables a user to search for any type of medical data and improve the search efficiency of the medical blockchain data, while considering both the correctness and reliability of the data.
In order to achieve the purpose, the invention provides the following technical scheme:
a verifiable search method for medical blockchain data specifically comprises the following steps:
s1: the medical institution is responsible for uploading the electronic medical data of the patient to the blockchain;
s2: selecting a non-relational database MongoDB for storage according to the characteristics of mass data in the block chain, and designing a corresponding data structure for the MongoDB according to medical data stored in the block chain;
s3: the medical block chain system stores the medical data in the blocks into a non-relational database after processing;
s4: a user requests a searcher to search medical records, and the searching process comprises client cache, database searching and on-chain searching; firstly, whether relevant data exists or not is searched from a local client cache, and then a medical blockchain system is requested through an intelligent contract to perform database search and blockchain search.
The searching speed of medical data on a block chain is increased by utilizing efficient query of a database and client cache, and the medical data of unprocessed blocks are searched from the chain, so that more comprehensive medical data is searched;
s5: in order to ensure the integrity and reliability of medical data, the medical blockchain system is subjected to data verification, wherein the data verification comprises a database periodic verification stage and a search result verification stage.
Further, in step S1, the rule for uploading the medical data to the blockchain is: firstly, judging the sensitivity of data and encrypting the sensitive data; secondly, judging the size of the data, and correspondingly processing the data with large or small occupied space; and finally, uploading the processed medical data serving as additional extra data to a block chain through an intelligent contract to generate an immutable transaction record, and finally storing the medical data in an input field of the transaction in a hexadecimal form.
Further, in step S1, the correspondingly processing the data with a large or small occupied space specifically includes: storing data (such as CT images) with large occupied space in a local cloud of a medical institution, and only storing hash values and storage positions of data (such as CT images) with smaller occupied space in a chain; the hash value is obtained by splicing and hashing medical data uploaded to the block chain.
Further, step S2 specifically includes: after the medical data in the block chain is imported into the database, in order to facilitate verification in the later period, the information which can position the block transaction and corresponds to each piece of medical data is also extracted into the database. The invention uses a one-to-one embedded document model, one piece of electronic medical data only corresponds to one patient, and four kinds of information are embedded in a main document as a single document through the embedded document model; only one set needs to be operated for adding, deleting, modifying and querying. This is easier to manage and eliminates performance-affecting operations that result from associating four sets. The four kinds of information include patient personal information (patientInfo), hospital information (hospitalInfo), patient medical record information (EMRInfo), and block information (blockInfo).
Further, step S3 specifically includes: the medical blockchain system is responsible for monitoring and maintaining the blockchain and serves as a searching party; meanwhile, medical data contained in each transaction in each block of the block chain is processed and then stored in a designed non-relational database; at this stage, in order to avoid the situation that the work needs to be suspended for some reason, and the blocks need to be processed from the beginning, the invention adds a persistence process.
Further, in step S4, the user requests the searcher to search for a medical record by S { [ t ]1,t2]W } in the form of [ t ]1,t2]Represents a time period for which medical data generation is to be searched, and may be null; w represents a set of keywords to be searched; finally, the searcher returns a search result set, resultSet, as follows:
resultSet={idk,ti,{patientInfok,hospitalInfok,EMRInfok,blockInfok}}
wherein, ti∈[t1,t2]K ∈ 1,2, …, n denotes the kth medical data, n denotes the number of medical data searched; idkId, PatientInfo representing kth medical datakIndicates the personal information, hospitalInfo, contained in the kth medical datakInformation indicating the hospital in which the patient is located in the kth medical data, EMRInfokPatient medical record information, blockInfo, representing kth medical datakAnd the block information of the k-th medical data is shown.
A user inputs a search request s through an intelligent contract and requests a searcher, and the search process is divided into three situations:
client caching: the user searches for data which are not required to be inquired in a local cache in priority each time;
database search: the searcher inquires through the database according to the conditions in the s and returns a corresponding result set;
search on chainRope: due to the fact that a failure occurs in the data storage operation process on the chain or network delay occurs, block chain data can be continuously updated, and therefore the updated data are not processed in time. The searcher will retain the final block height H of the processeWhen receiving the query request of the user, the height of the database is H after the database query is executedeThe +1 block starts the on-chain search.
Further, in step S5, the database periodic verification stage: the medical blockchain system verifies the data in the database periodically (for example, every 1 month) through the blockinformation stored in the database;
the search result verification stage: the medical block chain system pages the search results for the user to browse and check, and performs paging verification on all the results at the same time, so that the waiting time of the user is saved.
Further, in step S5, the two-stage verification specifically includes the following steps:
firstly, acquiring field information corresponding to each piece of medical data from a database, splicing the field information, and then calculating the Hash value H (m) of the field information;
positioning a corresponding transaction position according to the block information corresponding to each piece of medical data;
obtaining storage in trade
And H (m) is reacted with
Comparing, and judging whether the results are the same, wherein,
representing a value obtained by splicing and hashing medical data uploaded to blockchain transactions; if the medical block chain system is different, the tampered data in the database can be replaced according to the id corresponding to the medical data, and in the search result verification stage, original data can be obtained from the transaction and returned to the user;
when a user views medical data such as CT which occupies a large space, the medical data needs to be downloaded from a corresponding medical institution according to an image storage location in the patient medical record information, generate a hash value, compare the hash value with the image hash value in the patient medical record information, and determine whether the medical data is modified.
The invention has the beneficial effects that: the invention can enable a user to search any type of medical data, improve the searching efficiency of the medical block chain data and simultaneously give consideration to the correctness and reliability of the data.
Additional advantages, objects, and features of the invention will be set forth in part in the description which follows and in part will become apparent to those having ordinary skill in the art upon examination of the following or may be learned from practice of the invention. The objectives and other advantages of the invention may be realized and attained by the means of the instrumentalities and combinations particularly pointed out hereinafter.
Drawings
For the purposes of promoting a better understanding of the objects, aspects and advantages of the invention, reference will now be made to the following detailed description taken in conjunction with the accompanying drawings in which:
FIG. 1 is a flow chart of a verifiable search method for medical blockchain data according to the present invention;
FIG. 2 is a system model of a verifiable search mechanism oriented to medical blockchain data according to the present invention;
FIG. 3 is a block transaction structure;
FIG. 4 is a structural design of a database;
FIG. 5 is a block diagram of verifiable search operations.
Detailed Description
The embodiments of the present invention are described below with reference to specific embodiments, and other advantages and effects of the present invention will be easily understood by those skilled in the art from the disclosure of the present specification. The invention is capable of other and different embodiments and of being practiced or of being carried out in various ways, and its several details are capable of modification in various respects, all without departing from the spirit and scope of the present invention. It should be noted that the drawings provided in the following embodiments are only for illustrating the basic idea of the present invention in a schematic way, and the features in the following embodiments and examples may be combined with each other without conflict.
Referring to fig. 1 to 5, the present invention provides a verifiable search method for medical blockchain data, which includes the following steps:
stage one: the medical institution is responsible for uploading the electronic medical data of the patient to the blockchain;
and a second stage: selecting a non-relational database MongoDB for storage according to the characteristics of mass data in the block chain, and designing a corresponding data structure for the MongoDB according to medical data stored in the block chain;
and a third stage: the medical block chain system stores the medical data in the blocks into a non-relational database after processing;
and a fourth stage: the searching speed of medical data on a block chain is increased by utilizing efficient query of a database and client cache, and the medical data of unprocessed blocks are searched from the chain, so that more comprehensive medical data is searched;
and a fifth stage: a data verification mechanism is provided, which is used for regularly verifying medical data in a database and performing paging verification on query results.
As an alternative embodiment, the stage one specifically includes: and (3) uploading medical data.
In the medical institution, a doctor is responsible for diagnosing and treating a patient who has visited before, and generated medical data is uploaded into the blockchain by the medical institution. Since all users joining the medical blockchain system can obtain the on-chain medical data, in order to protect the individual privacy of the patient, it is necessary to determine whether there is sensitive data (e.g., name, phone, etc.) before the medical data is linked up and, if so, to encrypt it. Secondly, due to the limitation of the storage capacity of the block chain, the invention stores data (such as CT images) with large occupied space in the local cloud of the medical institution, and only stores the CT image hash value and the storage position with smaller occupied space in the chain. Then splicing and executing medical data to be uploaded into the block chainGenerating a hash value
Namely, it is
(id | | | patient name | | |. | | doctor id)
Where | represents a splice, and SHA-256 represents a hash function of 256 bits in length.
Finally, the medical institution splices the electronic medical data and the hash value formed by all the data
Uploaded as extra data through the smart contract into the blockchain and stored in hexadecimal form in the input field of the transaction. The block transaction structure and the components of the input field are described in FIG. 3 by taking EtherFang as an example.
As an optional embodiment, the stage two specifically includes: a database design phase.
The electronic medical data includes personal information (patient info), hospital information (hospitalInfo), and medical record information (EMRInfo). After the medical data is processed and stored in the database from the blockchain, in order to verify the correctness and integrity of the medical data, blockinformation (blockInfo) needs to be extracted for locating which transaction the medical data exists in. Typically, these four portions of data are stored in four sets, respectively, and are associated together by a binding id. When inquiring a piece of electronic medical data meeting the condition, the related data in the four sets are displayed through the related id. In this case, query performance can be slow, and all four sets need to operate when data is updated or added. Therefore, the invention uses a one-to-one embedded document model, one piece of electronic medical data only corresponds to one patient, and four kinds of information are embedded in the main document as a single document through the embedded document model. Only one set needs to be operated for adding, deleting, modifying and querying. This is easier to manage, and eliminates operations that affect performance due to associating four sets, and the design structure is shown in fig. 4.
As an optional embodiment, stage three specifically includes:
the medical blockchain system serves as a searching party and is responsible for monitoring and maintaining the blockchain and processing medical data on the chain, and the steps of warehousing and processing the medical data on the chain are as follows:
(1) the medical blockchain system obtains the block number N to be processed and then stores the transactions in the block in a list.
(2) And (4) judging whether the transaction list is an empty list, if so, returning to the step (1), and otherwise, executing the step (3).
(3) All transactions in the list are acquired and steps (4) - (5) are performed with each transaction as a unit.
(4) And acquiring a transaction hash value H, input field in the transaction and the sequence number n of the transaction in the block, and decoding an input field into plaintext data in a JSON format.
(5) And (4) storing key value pairs in the N, the N, the H and the JSON into a non-relational database according to a designed document format, then judging whether unprocessed transactions exist, if so, executing the step (4), and otherwise, returning to the step (1).
In order to avoid the situation that the blocks need to be processed from the beginning due to the fact that a fault occurs or the work needs to be suspended for updating, the embodiment is additionally provided with a persistence process, and the system can be guaranteed to continue processing from the place where the blocks were suspended last time when the system works next time.
As an optional embodiment, stage four specifically includes: and (5) a searching stage. The user wishes to search for medical records by requesting them from a searcher. The search request is s { [ t { [1,t2]W } is present. Wherein, [ t ]1,t2]The time period indicating the generation of the medical data to be searched may be empty. W denotes a set of keywords to be searched. Finally, the searcher returns the search result set, resultSet:
resultSet={idk,ti,{patientInfok,hospitalInfok,EMRInfok,blockInfok}}
wherein, ti∈[t1,t2]K ∈ 1,2, …, n denotes the kth medical data, and n denotes the number of medical data searched.
The user enters s and requests the searcher via the smart contract. The search process is divided into three cases:
client caching: the user will look for the data which is not needed to be inquired in the local cache preferentially in each search.
Database search: and the searcher queries through the database according to the conditions in the s and returns a corresponding result set.
Searching on the chain: due to the fact that a failure occurs in the data storage operation process on the chain or network delay occurs, block chain data can be continuously updated, and therefore the updated data are not processed in time. The searcher will retain the final block height H of the processeWhen receiving the query request of the user, the height of the database is H after the database query is executedeThe +1 block starts the on-chain search.
As an optional embodiment, stage five specifically includes: and (5) a verification stage.
In this mechanism, the blockchain system includes two-way verification in order to ensure the integrity and reliability of the medical data. On the one hand, to periodically verify the database and, on the other hand, to verify the search results. The mechanism supports the return of correct verification results and the correction of tampered medical data in the database.
During the periodic database verification stage, the medical blockchain system verifies the data in the database periodically (e.g., every 1 month). In the search result verification stage, the medical block chain system pages the search results for the user to browse and view, and simultaneously performs paging verification on all the results, so that the waiting time of the user is saved. The two stages of verification are as follows:
first, field information corresponding to each piece of medical data is obtained from a database, and is spliced, and then a hash value of the field information is calculated, that is, h (m) -SHA-256 (id | | patient name | | > | doctor id).
And secondly, positioning a corresponding transaction position according to a blockInfo part corresponding to each piece of medical data.
Obtaining storage in trade
And H (m) is reacted with
And comparing and judging whether the results are the same. If the difference is different, the medical blockchain system can replace the tampered data in the database according to the id corresponding to the medical data, and in the search result verification stage, original data can be obtained from the transaction and returned to the user.
When a user views medical data occupying a large space, such as CT, it is also necessary to download the medical data from a corresponding medical institution according to the image storage location in EMRInfo, generate a hash value, compare the hash value with the image hash value in EMRInfo, and determine whether the medical data has been modified.
Finally, the above embodiments are only intended to illustrate the technical solutions of the present invention and not to limit the present invention, and although the present invention has been described in detail with reference to the preferred embodiments, it will be understood by those skilled in the art that modifications or equivalent substitutions may be made on the technical solutions of the present invention without departing from the spirit and scope of the technical solutions, and all of them should be covered by the claims of the present invention.