CN110197708A - A kind of migration of block chain and storage method towards electron medical treatment case history - Google Patents

Abstract

The present invention relates to a kind of migration of block chain and storage method towards electron medical treatment case history, belong to block chain technical field, this method provides a kind of solution of old Data Migration to new block chain network, it can be achieved that from traditional database to the migration and mapping of block chain data in traditional medical electronic health record database (relevant database) and the medical electronics case history block catenary system (non-relational database) that newly constructs.It is the distributed data base system centered on sufferer by the centralized data base system transform centered on hospital-department by carrying out the construction of multiway tree data model to traditional medical database.One aspect of the present invention ensure that integrality and robustness of the data in new and old database migration.On the other hand, it ensure that by the construction to model tree and efficient duration data migration may be implemented.

Description

A blockchain migration and storage method for electronic medical records

technical field

The invention belongs to the technical field of blockchain, and relates to a blockchain migration and storage method for electronic medical records.

Background technique

The blockchain can be traced back to 1991. Haber and Bayeret proposed to use encrypted hash functions and Merkle trees in distributed systems to efficiently and securely record data with timestamps, and to block encrypted data. connected in a chain. Until 2008, Satoshi Nakamoto published an article "Bitcoin: A Peer-to-Peer Electronic Cash System", announcing the birth and large-scale application of the first generation of blockchain technology. The subsequent blockchain technology is a distribution of technologies such as distributed data storage, point-to-point transmission, consensus mechanism and encryption algorithm extracted from Bitcoin, and a smart contract composed of automated script codes for programming and business processing. storage ledger system.

With the continuous application and implementation of blockchain technology in recent years, the combination of blockchain and traditional medical industry has become a mainstream trend. Because the hospital information system HIS (Hospital Information System), a centralized relational database system that traditional medical institutions has already adopted, stores patient information, when building a non-relational storage system such as medical blockchain, it is stored in a relational database. of valuable data cannot be seamlessly migrated to non-relational blockchain storage systems.

Among the existing medical blockchain technologies, most of the technologies or patents start from the overall process of building a medical blockchain, including the design of storage nodes for distributing medical information, the overall functions of the medical blockchain, and the privacy access to electronic medical record information. Control strategy and other aspects of technical description and application. The data migration technology of the blockchain is mostly to migrate the data of the old blockchain to the new version of the blockchain, or to propose a technology for migrating a general relational database to a non-relational database system. As a result, in terms of blockchain medical care, it is difficult to migrate the old electronic medical record information of the traditional hospital database to the blockchain database by using the existing methods. Therefore, the present invention provides a blockchain migration and storage method for electronic medical records.

SUMMARY OF THE INVENTION

In view of this, the purpose of the present invention is to provide a blockchain migration and storage method for electronic medical records, which can automatically construct the existing electronic medical record information in the hospital database into a multi-fork tree model, and through the constructed multi-tree model. The fork tree model converts relational data into semi-structured data and stores it, matches the user information on the existing blockchain, automatically publishes smart contracts, and converts and migrates to the existing blockchain storage system.

To achieve the above object, the present invention provides the following technical solutions:

A blockchain migration and storage method for electronic medical records, extracting the relationship table of electronic medical records in the traditional medical data system to build a multi-tree information model, and constructing the generated multi-tree information model to the relationship table of traditional electronic medical records Data conversion is performed on the non-relational medical record data generated, and the information is matched with the existing user information on the migration blockchain. When the relevant user information is matched, a smart contract is established according to the multi-tree information model and the information parameters sent by the non-relational medical record data, and the non-relational medical record data that has been successfully converted is based on the meta-transaction data structure and new transaction data of the new blockchain. The structure carries out the transaction broadcast of the blockchain, and completes the migration process from the traditional medical data system to the blockchain data system.

Among them, according to the meta transaction data content of the new blockchain, the non-relational medical record data information corresponding to the meta transaction is sequentially integrated into a new transaction data structure with a chain sequence, which is solidified in the entire block and becomes a blockchain data.

Further, the construction of the multi-tree information model includes the following steps:

S11: For the electronic medical record data with multiple relationship tables nested in each other, use the multi-fork tree model to map the structured data relationship table level by level. The root node or child node of the multi-fork tree corresponds to the primary key and foreign key in the relationship table, and The fields (attributes) in the relationship table are corresponding to the multi-leaf nodes.

S12: Obtain the Patient (patient information) table in the electronic medical record relationship table, and use the primary key of the Patient table as the root node of the entire polytree model.

S13: Map the fields in the relational table to the child nodes of the multi-fork tree.

S14: Determine whether the child node is a foreign key attribute, if the current node is a foreign key attribute, start a new thread, jump to the execution program of the main table to which the foreign key belongs, and repeat steps S12-S14 until there is no unjoined multi-fork tree in the table. The foreign key property of the node.

S15: Traverse all relational nodes, and if all fields in the relational table are added to the mapped polytree, the procedure ends. Otherwise, read the field value not added to the multi-tree node, and repeat step S13.

Further, the data conversion is performed on the relational phenotype data of the traditional electronic medical record by constructing the generated polytree information model, and the generated non-relational medical record data is matched with the existing user information on the migration blockchain. Include the following steps:

S21: Obtain the field data of the Patient relation table mapped by the root node of the multi-tree model.

S22: Generate a polytree data instance according to the structural model of the polytree model, and sequentially read each tuple data in the table from the Patient relation table until the last item to be migrated in the relation table A tuple.

S23: For each piece of tuple data read, start from the data content corresponding to the first field of each tuple, and gradually migrate to the leaf nodes and child nodes instantiated by the multi-tree model, until all The data content corresponding to the last field of the read tuple data is migrated.

S24: For each foreign key field (attribute) corresponding to each tuple data in the read relation table, jump to the foreign key field corresponding to the primary key field according to the previously generated multi-tree model node relationship. In the data relationship table of , read the tuple data in the relationship table corresponding to the foreign key field mapped by the multi-tree model in turn, until it migrates to the bottom leaf node.

S25: For an independent data relationship table that has no direct or indirect connection with the Patient relationship table, according to the polytree modeling method, the primary key in the relationship table is obtained as the root node of the entire polytree model, and the data is migrated in turn.

S26: Match the generated non-relational user medical record data with the relevant user information already existing in the blockchain.

Further, the relevant user information includes the patient's personal information such as the patient's name, ID number, gender, and date of birth in the Patient relationship table; the patient's unique identification data in the traditional electronic medical record data system is the Patient relationship. The primary key information in the table; and the relationship network information composed of guardians or other family members in the Patient relationship table.

Further, the steps for migrating the successfully converted non-relational medical record data to the blockchain include:

S31: Obtain the non-relational data root node and match the existing user information on the blockchain.

S32: If the user information is successfully matched, the returned value of the successful match is passed as a parameter to the smart contract, and the nodes endorse and start to publish the transaction content.

S33: If the user information matching fails, pass the return value of the matching failure and the set validity period as parameters to the smart contract, and the node endorses it but does not publish it, and detects whether there is a matching user information within the contract period.

S34: If the relevant user information is matched within the contract period, step S32 is executed.

S35: If the relevant user information is not matched within the contract period, perform a transaction rollback operation, store it back in the non-relational database, and wait for the execution of step S31.

S36: The medical record data of the published transaction is stored according to the new blockchain according to the meta transaction data structure and the new transaction data structure of the new blockchain.

Further, the blockchain storage data format includes the following information:

The overall data structure of the blockchain is divided into two parts: the block header and the block body. The block header contains the block hash and the previous block hash. The block body contains two different kinds of transaction information, namely meta transaction data and new transaction data.

Among them, meta transaction data is used to describe the information of data attributes, including blockchain version information, multi-tree model load and load length, and import log information. Among them, the version information identifies the version imported into the blockchain at that time. The payload length identifies the size of the data volume of the generated multi-tree model. The model payload identifies the multi-tree model of the generated semi-structured data. The import log records information such as the storage location and data load on the relational database side of the imported data. The new transaction data is used to store the converted medical record data, including the metadata of the electronic medical record relationship table corresponding to the blockchain transaction data, logic time, transaction load and import log. Among them, the metadata represents the metadata information on the relational database side, including functions such as storage location, historical data, and file records. The logical time represents the time when the data is generated on the relational database side, rather than the import time of the blockchain. The logical time represents the patient's medical record results in the blockchain with the normal visit time. The import log records information such as the storage location and data load on the relational database side of the imported data.

Further, the node server includes a block chain index module, a linked list module and a state storage module;

After the smart contract is released, the blockchain framework module calls the linked list module to receive the consensus transaction content, calls the indexing module to index the transaction content, adds a logical time state, and calls the state storage module to store the transaction content. When the state storage module completes the storage, a transaction receipt is generated, and the data conversion module is notified to mark the data. The data conversion module feeds back the storage completion status back to the electronic medical record relationship table to complete the migration process of the entire blockchain.

The beneficial effects of the present invention are: on the one hand, the present invention ensures the integrity and robustness of data in the migration of new and old databases. On the other hand, efficient continuous data migration can be achieved through the construction of the model tree.

Other advantages, objects, and features of the present invention will be set forth in the description that follows, and will be apparent to those skilled in the art based on a study of the following, to the extent that is taught in the practice of the present invention. The objectives and other advantages of the present invention may be realized and attained by the following description.

Description of drawings

In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be preferably described in detail below with reference to the accompanying drawings, wherein:

Fig. 1 is the overall program flow chart of the method for electronic medical record block chain migration and storage according to the present invention;

2 is a flowchart of polytree modeling in the method for electronic medical record blockchain migration and storage according to the present invention;

3 is a data structure diagram of blockchain storage in the method for electronic medical record blockchain migration and storage according to the present invention;

Fig. 4 is the block chain storage data structure diagram in the method for the electronic medical record block chain migration and storage according to the present invention;

5 is a new transaction structure diagram in the block chain storage data structure diagram in the method for electronic medical record block chain migration and storage according to the present invention;

FIG. 6 is an overall structural diagram of the method for the blockchain migration and storage of electronic medical records according to the present invention.

Detailed ways

The embodiments of the present invention are described below through specific specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the drawings provided in the following embodiments are only used to illustrate the basic idea of the present invention in a schematic manner, and the following embodiments and features in the embodiments can be combined with each other without conflict.

Among them, the accompanying drawings are only used for exemplary description, and represent only schematic diagrams, not physical drawings, and should not be construed as limitations of the present invention; in order to better illustrate the embodiments of the present invention, some parts of the accompanying drawings will be omitted, The enlargement or reduction does not represent the size of the actual product; it is understandable to those skilled in the art that some well-known structures and their descriptions in the accompanying drawings may be omitted.

The same or similar numbers in the drawings of the embodiments of the present invention correspond to the same or similar components; in the description of the present invention, it should be understood that if there are terms “upper”, “lower”, “left” and “right” , "front", "rear" and other indicated orientations or positional relationships are based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the indicated device or element must be It has a specific orientation, is constructed and operated in a specific orientation, so the terms describing the positional relationship in the accompanying drawings are only used for exemplary illustration, and should not be construed as a limitation of the present invention. situation to understand the specific meaning of the above terms.

The blockchain system is a tamper-proof, shared digital distributed accounting system. According to the scale and operation mode of the blockchain, it can be divided into public chain, private chain and alliance chain. Each blockchain system contains several nodes, and different transactions can occur between several nodes, thus generating transaction data. The blockchain system determines the consistency of each transaction data through the endorsement mechanism and consensus algorithm, so as to process the transaction data to form ledger data, also known as block data. When the blockchain technology is combined with the medical electronic medical record system, since the blockchain technology uses a non-relational database NoSQL, the traditional medical electronic medical record system often uses a relational database. A relational database is a database that uses a relational model to organize data. The relational model refers to the two-dimensional table model, and a relational database is a data organization composed of two-dimensional tables and the connections between them. Relational databases follow a standardized design to ensure that the design minimizes data redundancy and has a tight relationship structure. A non-relational database refers to a data storage system that does not follow the paradigm structure design, is distributed, and generally does not guarantee the ACID principle. NoSQL is a storage method in which key-value pairs are stored and the structure is not fixed. The original medical electronic medical record system cannot be directly connected to the medical block system to obtain medical record information. Data migration middleware is needed to complete the migration process of medical record information from the medical system to the blockchain. The technical solutions of the embodiments of the present invention relate to relational databases, non-relational databases and blockchain storage technologies.

Fig. 1 is a flow chart of a blockchain migration and storage method for electronic medical records provided by an embodiment of the present invention, which can automatically construct the existing electronic medical record information in the hospital database into a multi-fork tree model, and through the constructed The multi-fork tree model converts relational data into semi-structured data and stores it, matches the user information on the existing blockchain, automatically publishes smart contracts, and converts and migrates to the existing blockchain storage system.

In order to achieve the above object, the present invention provides a data migration method. The relational phenotype data is converted, and the generated semi-structured data is matched with the existing user information on the migration blockchain.

When the relevant user information is matched, a smart contract is established according to the multi-tree information model and the information parameters sent by the non-relational medical record data, and the non-relational medical record data that has been successfully converted is based on the meta-transaction data structure and new transaction data of the new blockchain. The structure carries out the transaction broadcast of the blockchain, and completes the migration process from the traditional medical data system to the blockchain data system.

Among them, according to the meta transaction data content of the new blockchain, the non-relational medical record data information corresponding to the meta transaction is sequentially integrated into a new transaction data structure with a chain sequence, which is solidified in the entire block and becomes a blockchain data.

The relational database system described in the embodiment of the present invention refers to a database software entity conforming to a relational model applied to a hospital electronic medical record system, including but not limited to commonly used relational databases, such as Oracle, DB2, Microsoft SQL Server and MySQL, etc. database system.

The non-relational database system described in the embodiment of the present invention refers to a non-relational database software entity suitable for alliance chains, including but not limited to commonly used non-relational databases, such as database systems such as MongoDB, redis, HBase, and CouchDB.

Optionally, FIG. 2 is a flowchart of establishing a multi-tree model provided by an embodiment of the present invention. The operation steps are as follows:

Obtain the Patient (patient information) table in the electronic medical record relationship table (S201), and use the primary key of the Patient table as the root node of the entire polytree model. (S202)

Map the fields in the relational table to the child nodes of the multi-fork tree, and get the nodes in the relational table. (S203)

Determine whether the child node is a foreign key attribute (S204), if the current node is a foreign key attribute, start a new thread, jump to the main table execution program to which the foreign key belongs (S207), and repeat S202-S204 until there is no unjoined table in the table. The foreign key property of a polytree node.

Determine the next node (S205), traverse all relational nodes (S206), and end the program if all fields in the relational table are added to the mapped polytree. Otherwise, read the field value not added to the multi-tree node, and repeat S203.

Optionally, for the data migration method, wherein the step of data conversion and user matching includes:

Obtain the field data of the Patient relation table mapped by the root node of the multi-tree model.

Generate a polytree data instance according to the structural model of the polytree model, and sequentially read each tuple data in the table from the Patient relation table until the last element to be migrated in the relation table Group. The tree traversal algorithms for reading multi-tree data include but are not limited to common algorithms, such as: pre-order traversal algorithms, in-order traversal algorithms, and subsequent traversal algorithms.

For each tuple data read, start from the data content corresponding to the first field of each tuple, and gradually migrate to the leaf nodes and child nodes instantiated by the multi-tree model until the read The data content corresponding to the last field of this tuple data has been migrated.

For each foreign key field (attribute) corresponding to each tuple data in the read relation table, jump to the data to which the foreign key field corresponds to the primary key field according to the node relationship of the previously generated multi-tree model In the relational table, the tuple data in the relational table corresponding to the foreign key field mapped by the multi-tree model is sequentially read, until it is migrated to the bottommost leaf node.

For an independent data relationship table that has no direct or indirect connection with the Patient relationship table, according to the multi-fork tree modeling method of claim 2, the primary key in the relationship table is obtained as the root node of the entire multi-fork tree model, and data is migrated in turn.

Match the generated non-relational user medical record data with the relevant user information already existing in the blockchain.

Optionally, the matched relevant user information includes at least the following information:

The patient's name, ID number, gender, date of birth and other personal information of the patient in the Patient relationship table. The patient unique identification data in the traditional electronic medical record data system is the primary key information in the Patient relation table. And the relationship network information composed of guardians or other family members in the Patient relationship table. Among them, the patient's personal information mainly based on name, gender and ID number is used as a strict matching condition, and any condition that does not match the personal information cannot be matched. The relationship network information composed of guardians or other family members in the Patient relationship table can be used as weak condition matching by setting a threshold matching degree. For example, user information with a threshold matching degree above 80% can be matched. By matching the strong condition matching with personal information and the weak condition matching of the relationship network information, the users on the blockchain are matched and pushed, and after the patient users agree to the matching through the web terminal or the app terminal, the data is officially migrated.

Optionally, as shown in FIG. 1 , the steps of migrating the converted non-relational medical record data to the blockchain include:

The acquired non-relational data root node is matched with the existing user information on the blockchain (S103).

If the user information is successfully matched, the returned value of the successful match is passed as a parameter to the smart contract, the smart contract starts to be generated and executed (S104), and the nodes endorse and start to publish the transaction content (S109).

If the user information matching fails, the return value of the matching failure and the set validity period are passed as parameters to the smart contract (S105), the node endorses but does not publish it (S106), and detects whether there is any user information matching within the contract period (S108) ).

If the relevant user information is matched within the contract period, the transaction endorsement is executed, and each node is broadcast to publish the message (S109).

If the relevant user information is not matched within the contract period, the transaction rollback operation is performed (S107), the data is stored in the non-relational database buffer, and the execution of S103 is awaited.

The medical record data of the published transaction is stored according to the new blockchain according to the meta transaction data structure and the new transaction data structure of the new blockchain.

Optionally, as shown in FIG. 3 is a block chain data structure diagram. The data format for the described blockchain storage includes the following information:

The overall data structure of the blockchain is divided into two parts: the block header and the block body. The block header contains the block hash (S301) and the previous block hash (S302). The block body contains two different transaction information, namely meta transaction data (S303) and new transaction data (S304).

Optionally, as shown in FIG. 4 , a meta-transaction data structure diagram is shown. Meta transaction data is used to describe the information of data attributes, including blockchain version information (S401), multi-tree model load (S403) and load length (S402), and import log information (S404). Among them, the version information identifies the version imported into the blockchain at that time. The payload length identifies the size of the data volume of the generated multi-tree model. The model payload identifies the multi-tree model of the generated semi-structured data. The import log records information such as the storage location and data load on the relational database side of the imported data.

Optionally, as shown in FIG. 5, a new transaction data structure diagram is shown. The new transaction data is used to store the converted medical record data, including the metadata of the electronic medical record relationship table corresponding to the blockchain transaction data (S501), the logical time (S502), the transaction load (S503) and the import log (S504). Among them, the metadata represents the metadata information on the relational database side, including functions such as storage location, historical data, and file records. The logical time represents the time when the data is generated on the relational database side, rather than the import time of the blockchain. The logical time represents the patient's medical record results in the blockchain with the normal visit time. The import log records information such as the storage location and data load on the relational database side of the imported data.

Optionally, as shown in FIG. 6 is an overall structural diagram of the data migration system. The blockchain architecture applied to the migration and storage methods includes, but is not limited to, the commonly used consortium blockchain blockchain platforms. For example: Hyperledger Fabric, Ripple and OpenChain and other consortium chain platforms. Its storage node module should include three types: blockchain index module, linked list module and state storage module.

After the smart contract is released, the blockchain framework module calls the linked list module to receive the consensus transaction content, calls the indexing module to index the transaction content, adds a logical time state, and calls the state storage module to store the transaction content.

When the state storage module completes the storage, a transaction receipt is generated, and the data conversion module is notified to mark the data. The data conversion module feeds back the storage completion status back to the electronic medical record relationship table to complete the migration process of the entire blockchain.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to the preferred embodiments, those of ordinary skill in the art should understand that the technical solutions of the present invention can be Modifications or equivalent replacements, without departing from the spirit and scope of the technical solution, should all be included in the scope of the claims of the present invention.

Claims (7)

1. a block chain migration and storage method oriented to electronic medical records, it is characterized in that: in the traditional medical data system, extract the electronic medical record relation table to construct a multi-tree information model, by constructing the generated multi-tree information model to The relational phenotype data of the traditional electronic medical record is converted into data, and the generated non-relational medical record data is matched with the existing user information on the migration blockchain; when the relevant user information is matched, according to the multi-tree information model and The information parameters sent by the non-relational medical record data establish a smart contract, and the non-relational medical record data that has been successfully converted is broadcasted on the blockchain according to the meta-transaction data structure and the new transaction data structure of the new blockchain, completing the transformation from the traditional medical data system. Migration process to blockchain data system; Among them, according to the meta-transaction data content of the new blockchain, the non-relational medical record data information corresponding to the meta-transaction is sequentially integrated into a new transaction data structure with a chain sequence, which is solidified in the entire block and becomes blockchain data. 2. The electronic medical record-oriented blockchain migration and storage method according to claim 1, characterized in that: the construction of a polytree information model comprises the following steps: S11: For the electronic medical record data with multiple relationship tables nested in each other, use the multi-fork tree model to map the structured data relationship table level by level. The root node or child node of the multi-fork tree corresponds to the primary key and foreign key in the relationship table. Fork-leaf nodes correspond to fields in the relationship table, that is, attributes; S12: Obtain the patient information table Patient in the electronic medical record relationship table, and use the primary key of the Patient table as the root node of the entire polytree model; S13: Map the fields in the relational table to the child nodes of the polytree; S14: Determine whether the child node is a foreign key attribute, if the current node is a foreign key attribute, start a new thread, jump to the execution program of the main table to which the foreign key belongs, and repeat steps S12-S14 until there is no unjoined multi-fork tree in the table. The foreign key attribute of the node; S15: Traverse all relation nodes, if all fields in the relation table are added to the mapped polytree, end the program; otherwise, read the field values not added to the polytree node, and repeat step S13. 3. The electronic medical record-oriented blockchain migration and storage method according to claim 2, characterized in that: the data conversion is performed on the relational phenotype data of traditional electronic medical records by the polytree information model generated by constructing, Matching the generated non-relational medical record data with the existing user information on the migration blockchain includes the following steps: S21: Obtain the field data of the Patient relation table mapped by the root node of the multi-tree model; S22: generate a polytree data instance according to the structural model of the polytree model, read each tuple data in the table successively from the Patient relation table, until the last tuple to be migrated in the Patient relation table; S23: For each piece of tuple data read, start from the data content corresponding to the first field of each tuple, and gradually migrate to the leaf nodes and child nodes instantiated by the multi-tree model, until all The data content corresponding to the last field of the read tuple data is migrated; S24: For each foreign key field corresponding to each tuple data in the read relation table, that is, an attribute, according to the previously generated multi-tree model node relationship, jump to the foreign key field corresponding to the primary key field to which it belongs. In the data relationship table of , read the tuple data in the relationship table corresponding to the foreign key field mapped by the multi-tree model in turn, until it migrates to the bottommost leaf node; S25: For an independent data relationship table that has no direct or indirect connection with the Patient relationship table, according to the polytree modeling method, obtain the primary key in the relationship table as the root node of the entire polytree model, and migrate the data in turn; S26: Match the generated non-relational user medical record data with the relevant user information already existing in the blockchain. 4. the block chain migration and storage method oriented to electronic medical records according to claim 3, is characterized in that: described relevant user information comprises the patient's personal information in the Patient relation table, namely patient's name, ID number, gender , date of birth; also includes the patient unique identification data in the traditional electronic medical record data system, that is, the primary key information in the Patient relationship table; and the relationship network information formed by guardians or other family members in the Patient relationship table. 5. The block chain migration and storage method for electronic medical records according to claim 1, wherein the step of migrating the successfully converted non-relational medical record data to the block chain comprises: S31: Obtain the non-relational data root node and match the existing user information on the blockchain; S32: If the user information is successfully matched, the returned value of the successful match is passed as a parameter to the smart contract, and the nodes endorse and start to publish the transaction content; S33: If the user information matching fails, pass the return value of the matching failure and the set validity period as parameters to the smart contract, and the node endorses it but does not publish it, and detects whether there is a matching user information within the contract period; S34: If the relevant user information is matched within the contract period, step S32 is executed; S35: If the relevant user information is not matched within the contract period, perform a transaction rollback operation, store it back in the non-relational database, and wait for the execution of step S31; S36: The medical record data of the published transaction is stored according to the new blockchain according to the meta transaction data structure and the new transaction data structure of the new blockchain. 6. The block chain migration and storage method for electronic medical records according to claim 5, wherein the block chain storage data format includes the following information: The overall data structure of the blockchain includes a block header and a block body. The block header contains the block hash and the previous block hash. The block body contains two different transaction information, namely meta transaction data and new transaction data. ; Among them, the meta transaction data is used to describe the information of the data attributes, including the blockchain version information, the multi-tree model load and load length, and the import log information; wherein, the version information identifies the version imported into the blockchain at that time; the load length Identifies the size of the data volume of the generated multi-fork tree model; the model load identifies the multi-fork tree model of the generated semi-structured data; the import log records the storage location and data load on the relational database side of the imported data; the new transaction data is used for Store the converted medical record data, including the metadata, logical time, transaction load and import log of the electronic medical record relationship table corresponding to the blockchain transaction data; wherein, the metadata represents the metadata information on the relational database side, including the storage location, Historical data, file records; logical time represents the time when the corresponding data is generated on the relational database side, non-blockchain import time, logical time represents the patient's medical record results in the blockchain with the normal visit time; import log Record the storage location and data load on the relational database side of the imported data. 7. The electronic medical record-oriented blockchain migration and storage method according to claim 5, wherein the node comprises a blockchain index module, a linked list module and a state storage module; After the smart contract is released, the blockchain framework module calls the linked list module to receive the consensus transaction content, calls the index module to index the transaction content, adds the logical time state, and calls the state storage module to store the transaction content; The module completes the storage, generates a transaction receipt, and notifies the data conversion module to mark the data; the data conversion module feeds back the storage completion status to the electronic medical record relationship table to complete the migration process of the entire blockchain.