CN112133387B - Data migration and storage method and system for case information - Google Patents
Data migration and storage method and system for case information Download PDFInfo
- Publication number
- CN112133387B CN112133387B CN202011309802.2A CN202011309802A CN112133387B CN 112133387 B CN112133387 B CN 112133387B CN 202011309802 A CN202011309802 A CN 202011309802A CN 112133387 B CN112133387 B CN 112133387B
- Authority
- CN
- China
- Prior art keywords
- case
- information
- data
- case information
- field
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
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/20—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for electronic clinical trials or questionnaires
-
- 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
- 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
- G16H15/00—ICT specially adapted for medical reports, e.g. generation or transmission thereof
Landscapes
- Health & Medical Sciences (AREA)
- Engineering & Computer Science (AREA)
- Epidemiology (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Primary Health Care (AREA)
- Public Health (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention relates to a data migration method of case information, which is used for migrating data in a first case report table to a second case report table and comprises the following steps: obtaining first case information data in a first case report table, wherein the first case information data are stored in child nodes of an MPT tree, entry information in the first case information data are stored in a value field, and non-entry information in the first case information data are stored in a metadata field; obtaining second case information data in a second case report table; updating the non-input information in the metadata field in the first case information data by using the non-input information in the second case information data, and generating a second case report table by using the updated first case information data as the second case information data; and performing a hash check process on the second case information data in the second case report table, wherein the hash check process is performed on the value field and the hash check process is not performed on the metadata field.
Description
Technical Field
The invention relates to the technical field of clinical trial research, in particular to a data migration method and system of case information and a storage method and system of case information.
Background
In the course of conducting clinical trial studies, it is necessary to store the collected case information in a storage medium for subsequent calculation and analysis. Currently, different Case Report Forms (CRF) are designed for different clinical trials, wherein a header is used to indicate the specific item name to be entered, such as the name, gender, etc. of the subject. The project name to be recorded in the CRF belongs to non-recorded information, is set according to actual requirements in a design stage, and is fixed after being set; the case content belongs to the entered information, that is, the specific information of the subject is filled in by the user according to the set item name when using the case report form. Case content needs to be entered during different phases of the clinical trial study.
A clinical trial often needs to last for a long period of time, during which dynamic adjustments to the contents of the CRF may be required, such as increasing or decreasing non-entered information, resulting in changes in the CRF version. In this case, it is necessary to migrate the case information data that has been stored originally to a new version of CRF.
Disclosure of Invention
The invention aims to provide a data migration and storage method and a data migration and storage system for efficiently realizing case information data migration.
The present invention has been made to solve the above-mentioned problems, and an aspect of the present invention is a method for transferring case information data, which is used for transferring data in a first case report table to a second case report table, the method including: obtaining first case information data in the first case report table, the first case information data being stored in a child node of an MPT tree, wherein the child node includes a value field in which entered information in the first case information data is stored and a metadata field in which non-entered information in the first case information data is stored; obtaining second case information data in the second case report table, wherein non-input information in the second case information data is different from non-input information in the first case information data; updating the non-input information in the metadata field in the first case information data by using the non-input information in the second case information data, and generating a second case report table by using the updated first case information data as the second case information data; and performing a hash check process on the second case information data in the second case report table, wherein the hash check process is performed on the value field and the hash check process is not performed on the metadata field.
In an embodiment of the invention, the metadata field is located after the value field.
In an embodiment of the present invention, the metadata field is adjacent to the value field.
In an embodiment of the present invention, the child nodes include leaf nodes and branch nodes.
In an embodiment of the invention, the input information comprises case content, and the non-input information comprises a version of a case report table.
The present invention further provides a data storage method for case information to solve the above technical problems, where the case information includes entered information and non-entered information, and the method is characterized by including: storing the case information in a child node of an MPT tree, the child node comprising a value field and a metadata field, wherein the entered information is stored in the value field and the non-entered information is stored in the metadata field; when a hash check process is performed, the metadata field does not participate in the hash check process.
In an embodiment of the invention, the metadata field is located after the value field.
In an embodiment of the present invention, the metadata field is adjacent to the value field.
In an embodiment of the present invention, the child nodes include leaf nodes and branch nodes.
In an embodiment of the present invention, the value field participates in a hash check process.
In an embodiment of the invention, the case information is a case report table, the entered information includes case content, and the non-entered information includes a version of the case report table.
The present invention further provides a case information migration system for solving the above technical problems, which is characterized by comprising a memory, a processor and a computer program stored on the memory and operable on the processor, wherein the processor implements the method when executing the program.
The present invention further provides a case information storage system for solving the above technical problems, which is characterized by comprising a memory, a processor and a computer program stored on the memory and capable of running on the processor, wherein the processor implements the method when executing the program.
The present invention further provides a computer-readable storage medium, which stores a computer program, and the computer program implements the method when executed by a processor.
According to the data migration method, the metadata field is added in the child node of the MPT tree, the input information in the first case information data is stored in the value field of the child node of the MPT tree, the non-input information is stored in the metadata field of the child node of the MPT tree, when the version of the case information data changes, the non-input information in the metadata field is updated, the hash check process is only executed on the value field in the hash check process, and if the case content of the value field does not change, the case content does not need to be copied, so that the credibility check result of the case content of the value field is transmitted to the second case information data, the complexity of data migration is simplified, and the efficiency and the performance of data migration are improved.
Drawings
In order to make the aforementioned objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in detail below, wherein:
FIG. 1A is a schematic diagram of a structural model of a case report table according to an embodiment of the present invention;
FIG. 1B is an example of a display page of a case report form formed from the structural model of FIG. 1A;
FIG. 1C is a schematic view of a structural model of a case report table according to another embodiment of the present invention;
FIG. 1D is an example of a display page of a case report table generated from the structural model of FIG. 1C;
FIG. 2 is a schematic diagram of the structure of an MPT tree;
FIG. 3 is a diagram illustrating the structure of an MPT tree for storing case information according to an embodiment of the present invention;
fig. 4 is an exemplary flowchart of a data migration method of case information according to an embodiment of the present invention.
Detailed Description
In order to make the aforementioned objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in detail below.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention, but the present invention may be practiced in other ways than those specifically described herein, and thus the present invention is not limited to the specific embodiments disclosed below.
As used in this application and the appended claims, the terms "a," "an," "the," and/or "the" are not intended to be inclusive in the singular, but rather are intended to be inclusive in the plural unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that steps and elements are included which are explicitly identified, that the steps and elements do not form an exclusive list, and that a method or apparatus may include other steps or elements.
In the description of the present application, it is to be understood that the orientation or positional relationship indicated by the directional terms such as "front, rear, upper, lower, left, right", "lateral, vertical, horizontal" and "top, bottom", etc., are generally based on the orientation or positional relationship shown in the drawings, and are used for convenience of description and simplicity of description only, and in the case of not making a reverse description, these directional terms do not indicate and imply that the device or element being referred to must have a particular orientation or be constructed and operated in a particular orientation, and therefore, should not be considered as limiting the scope of the present application; the terms "inner and outer" refer to the inner and outer relative to the profile of the respective component itself.
It should be noted that the terms "first", "second", and the like are used to define the components, and are only used for convenience of distinguishing the corresponding components, and the terms have no special meanings unless otherwise stated, and therefore, the scope of protection of the present application is not to be construed as being limited. Further, although the terms used in the present application are selected from publicly known and used terms, some of the terms mentioned in the specification of the present application may be selected by the applicant at his or her discretion, the detailed meanings of which are described in relevant parts of the description herein. Further, it is required that the present application is understood not only by the actual terms used but also by the meaning of each term lying within.
Flow charts are used herein to illustrate operations performed by systems according to embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in the exact order in which they are performed. Rather, various steps may be processed in reverse order or simultaneously. Meanwhile, other operations are added to or removed from these processes.
Fig. 1A is a schematic diagram of a structural model of a case report table according to an embodiment of the present invention. The structural model is used for displaying a front-end display model of the case report, is used for setting the content and format contained in the case report which is finally filled by a user in the design stage, and is irrelevant to the storage structure and the storage mode of the case report. Referring to fig. 1A, assuming that the version of the case report table is v1, the structural model includes three columns of contents, namely "name", "OID", and "type", respectively. Wherein, the "name" refers to the name of the item to be recorded in the case report table of the v1 version, such as name, sex, height, weight; "OID" refers to the english letter abbreviation corresponding to the "name" column; "type" refers to the data type of each item at the time of storage, e.g., String, Dict, Number, etc.
The illustration in fig. 1A is merely an example and is not intended to limit the specific content of the structural model of the case report table. The content to be included in the structural model can be designed according to the needs of an actual clinical trial. For example, the data types may include any data types.
Fig. 1B is an example of a display page of a case report form formed from the structural model of fig. 1A. Referring to fig. 1B, the case report table 101 generated according to the structural model shown in fig. 1A should include the first column of four entry item names, i.e., "name", "sex", "height", "weight", and so on. In the clinical trial, the corresponding case contents of the subject, i.e., "zhang san", "Male", "180 cm", "70 kg", etc., are entered according to the four entry item names. As shown in fig. 1B, the entry item name of the first column is non-entry information, i.e., content which does not need to be entered by the user in actual use. The non-entered information is fixed in the case report form after the structural model design of the case report form is completed. The case content corresponding to the subject input by the entry item name is entry information, that is, content that needs to be entered by the user in actual use.
In some embodiments, version information for the case report form may also be displayed in the display page of the case report form. For example, as shown in fig. 1B, a version v1 of the case report table is displayed in the version display area 110.
Fig. 1C is a schematic view of a structural model of a case report table according to another embodiment of the present invention. The case report table of this embodiment has one row added to it as compared to the embodiment shown in fig. 1A. Assuming that the version of the case report table is v2, in the case report table of version v2, an entry item having a "national name" is added as compared with version v1, the "OID" corresponding to the entry item is "MZ", and the "type" is "Dict".
Fig. 1D is an example of a display page of a case report table generated from the structural model of fig. 1C. As shown in fig. 1D, an entry item of "nationality" that also belongs to non-entry information is added to the header of the first column of the case report table 102. As shown in fig. 1D, the case content corresponding to "nationality" has not been entered in the case report table 102.
In some embodiments, version information for the case report form may also be displayed in the display page of the case report form. For example, as shown in fig. 1D, a version v2 of the case report form is displayed in the version display area 120.
During the clinical trial, the structural model of the case report form may be changed as needed, and the version of the case report form may be changed. For example, the case report table is changed from version v1 shown in fig. 1B to version v2 shown in fig. 1D. In an embodiment of the present invention, an mpt (merkle Patricia tree) tree structure is employed to store case information for a subject. According to the characteristics of the MPT tree structure, when the stored case information is changed such as newly added, modified and deleted, the tree nodes storing the case information execute hash verification again and generate a new root hash (root hash) to reflect the change of data.
When the version of the case report table changes, the case content already recorded in version v1 needs to be migrated to the new version v 2. At this time, the structure of the case report table is changed, for example, an entry item of "nationality" is added, but the remaining case contents are not changed, and the entered case contents are not freely changed. However, according to the characteristics of the MPT tree, since the "ethnic" entry item data is newly added, the tree nodes storing the content are changed, and in order to verify the credibility of the newly added data, the hash verification process performs hash layer by layer on the corresponding MPT tree structure, and finally, the root hash is greatly changed. However, the case content in the case report table of version v2 after data migration is substantially the same as the case content in version v 1. The case contents stored in version v1 have been subjected to hash verification, i.e., plausibility verification, of the MPT tree. However, the root hash of the MPT tree is changed due to the change of the structure of the version v2, so that the credibility verification of the original case content is invalid, which is equivalent to that the credibility verification of the case content in the version v1 cannot be migrated to the new version v 2. The case content of the case report table of version v2 needs to be copied into a new case report table, and credibility verification needs to be performed again, which results in large calculation amount and long time consumption of data migration.
Fig. 2 is a schematic diagram of an MPT tree structure. Referring to fig. 2, the MPT tree includes an extension node 210 (extension node), a branch node 220 (branch node), a first leaf node 230 (leaf node), and a second leaf node 240. Wherein each node comprises a key-value structure, wherein a key field is used for storing a path of data and a value field is used for storing a value of data. For example, in the first leaf node 230, the key field 231 stores the path "5" of the data, and the value field 232 stores the specific value of the data. As shown in fig. 2, the key field 221 in the branch node 220 represents the path of the stored data with 16-ary code, and the value field 222 following the key field stores the specific value of the data. The branch node 220 has a length of 17.
As shown in FIG. 2, the extension node 210 also includes a pair of key fields 211 and a value field 212. Where the key field 211 is used to store the path of the data. The value field 212 is not a specific value for storing data, but a hash value of another node.
As shown in fig. 2, the leaf nodes 230, 240, the branch node 220, and the extension node 210 form a relationship between a child node and a parent node layer by layer. If there is no other node above the extension node 210, the extension node 210 is a parent node as a root node; branch node 220 is a child node of extension node 210; first leaf node 230 and second leaf node 240 are child nodes of limb node 220; branch node 220 is a parent node of first leaf node 230 and second leaf node 240.
The nodes in the MPT tree are connected by hash values, which may be stored in hash value fields of the node structure, which are fields other than keys and values. As shown in fig. 2, the hash value 233 of the first leaf node 230 and the hash value 243 of the second leaf node 240 are both associated with the hash value 223 of the branch node 220 at the upper layer; hash value 223 of branch node 220 is associated with hash value 213 of extension node 210.
When the hash value in the leaf node changes, the hash value of the parent node of the upper layer also changes, and further, the hash value of the parent node of each layer is changed layer by layer upwards until the root node. Therefore, the MPT tree needs to be updated once the values of the child nodes change.
It should be noted that the illustration in fig. 2 is only an example, and is not intended to limit the number of various nodes in the MPT tree, the number of layers, and the position relationship of various nodes. For example, in some embodiments, the extension node as the root node may include a branch node, and the branch node may further include any one of a branch node, an extension node, and a leaf node, thereby forming a multi-level tree structure with multiple nodes at each level.
Fig. 3 is a schematic structural diagram of an MPT tree for storing case information according to an embodiment of the present invention. Referring to fig. 3, the MPT tree includes an extension node 310 (extension node), a branch node 320 (branch node), a first leaf node 330 (leaf node), and a second leaf node 340. The branch node 320 includes, in addition to the key field 321 and the value field 322, a metadata field 324 (Meta), and the metadata field 324 is disposed immediately after the value field 322. The first leaf node 330 includes, in addition to a key field 331 and a value field 332, a metadata field 334 (Meta), which is provided immediately after the value field 332, 334. The second leaf node 340 includes, in addition to the key field 341 and the value field 342, a metadata field 344 (Meta), the metadata field 344 being provided immediately after the value field 342.
The present invention provides a data storage method of case information including entered information and non-entered information according to the structure of an MPT tree shown in fig. 3, the case information being stored in child nodes of the MPT tree, the child nodes including value fields and metadata fields, wherein entered information is stored in the value fields, and non-entered information is stored in the metadata fields; the metadata field does not participate in the hash check process when the hash check process is performed.
Metadata (Meta) refers to information describing data, which is generated according to the logic of the business system, and corresponds to different metadata for different business processes in the clinical trial process.
In some embodiments, the case information is a case report form, the entered information includes case content, and the non-entered information includes a version of the case report form. As shown with reference to fig. 1D, the non-entered information may include a version of the case report table, such as v1 or v2, in addition to the entered items designed into the case report table. The version information may also be displayed in a display page of the case report table, as shown in the version display area 120 in fig. 1D. Of course, the entry item names shown in fig. 1C and 1D may also be included in the non-entry information.
In some embodiments, the child nodes in the data storage method of case information of the present invention include leaf nodes and branch nodes.
Referring to fig. 3, in the data storage method of case information of the present invention, entry information in case information is stored in value fields of child nodes, for example, a value field 322 of a branch node 320, a value field 332 of a first leaf node 330, and a value field 342 of a second leaf node 340. The invention is not limited as to which logging information is stored in which child node. Also, non-entered information is stored in metadata fields, such as metadata field 324 of branch node 320, metadata field 334 of first leaf node 330, and metadata field 344 of second leaf node 340.
In some embodiments, the metadata field is located after the value field, as shown in FIG. 3.
In some embodiments, the metadata field is contiguous with the value field, i.e., no other fields are inserted between the metadata field and the value field, as shown in FIG. 3.
In some embodiments, the metadata field 324 is included only after the value field 322 of the branch node 320.
In some embodiments, the metadata field is included only after the value fields of certain leaf nodes.
In some embodiments, the metadata field is included only after the value fields of all leaf nodes.
In some embodiments, the value fields of all the branch nodes and leaf nodes of the MPT tree are followed by a metadata field.
In an embodiment of the invention, the metadata field does not participate in the hash check process when the hash check process is performed. In conjunction with fig. 1A and 1C, a version of the case report table is stored in a metadata field in the MPT tree.
In an embodiment of the invention, the value field participates in the hash check process when it is performed. In conjunction with fig. 1A and 1C, the case contents entered by the user in the case report table are stored in the value field in the MPT tree. When the case content in the case report table is not changed but only the version is changed, when the MPT tree performs the hash check, since only the related data of the case content participates in the hash check process and the part of data is not changed, the root hash value is not changed, which indicates that the part of data is authentic and can be directly used. There is no need to duplicate the data related to the case content. For clinical trials with huge data volume, the data processing time during data migration can be greatly reduced and the performance of the system can be improved according to the invention.
The invention also comprises a case information storage system, which comprises a memory, a processor and a computer program stored on the memory and operable on the processor, wherein the processor executes the program to realize the case information storage method.
Fig. 4 is an exemplary flowchart of a data migration method of case information according to an embodiment of the present invention. The data migration method is used for migrating data in a first case report table to a second case report table. The data migration method of case information according to the present invention is applicable to the case report tables shown in fig. 1A to 1D and the MPT tree storage structure shown in fig. 3. Therefore, the descriptions corresponding to fig. 1A to 1D and fig. 3 can be used to describe the data migration method of the present invention, and the same descriptions will not be repeated. The data migration method of this embodiment is described below with reference to fig. 1A to 1D, fig. 3, and fig. 4.
Referring to fig. 4, the data migration method of case information of this embodiment includes the steps of:
step S410: obtaining first case information data in the first case report table, the first case information data being stored in child nodes of the MPT tree, wherein the child nodes include a value field in which entered information in the first case information data is stored and a metadata field in which non-entered information in the first case information data is stored.
In some embodiments, the child nodes in this step include leaf nodes and branch nodes.
The first case report table in this step may be the case report table shown in fig. 1A and 1B. The data in the case report table is first case information data including entry information and non-entry information. The first case information data is stored using the MPT tree structure shown in fig. 3. As shown in connection with fig. 3, the entry information in the first case information data is stored in value fields, such as the value field 322 of the limb node 320, the value field 332 of the first leaf node 330, and the value field 342 of the second leaf node 340; the non-entered information in the first case information data is stored in metadata fields, such as metadata field 324 of limb node 320, metadata field 334 of first leaf node 330, and metadata field 344 of second leaf node 340.
In some embodiments, the metadata field is located after the value field.
In some embodiments, the metadata field is contiguous with the value field.
In some embodiments, the entered information includes case content and the non-entered information includes a version of the case report table.
Step S420: second case information data in a second case report table is obtained, and non-entry information in the second case information data is different from non-entry information in the first case information data.
The second case report table in this step may be the case report tables shown in fig. 1C and 1D. Obviously, the non-entered information in the second case report table is different from the non-entered information in the first case information data, the non-entered information of the second case report table includes the entered item of "nationality", and the version of the second case report table is v2, which is different from the version v1 of the first case report table.
In some embodiments, the non-entered information contains only a version of the case report table, and only that version is stored in the metadata field.
It should be noted that the method is not limited to the storage method of the second case information data, and the second case information data may be stored in the structure of the MPT tree or in other manners.
Step S430: and updating the non-entry information in the metadata field in the first case information data by using the non-entry information in the second case information data, and generating a second case report table by using the updated first case information data as the second case information data.
As shown with reference to fig. 1B and 1D, the non-entry information in the first case information data is replaced with non-entry information including "nationality" and version v2 in the second case information data. Since the non-entry information in the first case information data is stored in the metadata field of the MPT tree, the content of the metadata field is updated at this step.
In some embodiments, the non-entered information contains only the version of the case report table, and only the version contents in the metadata field need be modified at this step. At this time, the content of the value field in the first case information data is not changed, and only the content of the metadata field is changed. The first case information data is used as second case information data from which a second case report table can be generated.
Step S440: performing a hash check process on the second case information data in the second case report table, wherein the hash check process is performed on the value field and the hash check process is not performed on the metadata field.
This step can be implemented by not selecting the metadata field as the input value of the hash check process, and only selecting the content of the value field as the input value of the hash check process. Through the step, only when the content of the value field changes, the root hash value can be changed through hash check. If the contents of the value field have not changed, but only the contents of the metadata field, then the root hash value does not change. Equivalently, the credibility of the case content entered in the first case report table is successfully transferred to the second case report table.
According to the data migration method, if the case content of the value field is not changed, the case content does not need to be copied, the credibility verification result of the case content of the value field is transmitted to the second case information data, the calculation amount of data migration is greatly reduced, and the calculation efficiency is improved.
The invention also includes a case information migration system, which includes a memory, a processor and a computer program stored on the memory and executable on the processor, and when the processor executes the program, the case information migration method as described above is implemented.
The present invention also includes a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the case information storage method and the migration method as described above.
When the case information migration method of the present invention is implemented as a computer program, it may be stored in a computer-readable storage medium as a product. For example, computer-readable storage media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips), optical disks (e.g., Compact Disk (CD), Digital Versatile Disk (DVD)), smart cards, and flash memory devices (e.g., electrically Erasable Programmable Read Only Memory (EPROM), card, stick, key drive). In addition, various storage media described herein can represent one or more devices and/or other machine-readable media for storing information. The term "machine-readable medium" can include, without being limited to, wireless channels and various other media (and/or storage media) capable of storing, containing, and/or carrying code and/or instructions and/or data.
Aspects of the present application may be embodied entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or in a combination of hardware and software. The above hardware or software may be referred to as "data block," module, "" engine, "" unit, "" component, "or" system. The processor may be one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), digital signal processing devices (DAPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, or a combination thereof. Furthermore, aspects of the present application may be represented as a computer product, including computer readable program code, embodied in one or more computer readable media. For example, computer-readable media may include, but are not limited to, magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips … …), optical disks (e.g., Compact Disk (CD), Digital Versatile Disk (DVD) … …), smart cards, and flash memory devices (e.g., card, stick, key drive … …).
The computer readable medium may comprise a propagated data signal with the computer program code embodied therein, for example, on a baseband or as part of a carrier wave. The propagated signal may take any of a variety of forms, including electromagnetic, optical, and the like, or any suitable combination. The computer readable medium can be any computer readable medium that can communicate, propagate, or transport the program for use by or in connection with an instruction execution system, apparatus, or device. Program code on a computer readable medium may be propagated over any suitable medium, including radio, electrical cable, fiber optic cable, radio frequency signals, or the like, or any combination of the preceding.
Although the present invention has been described with reference to the present specific embodiments, it will be appreciated by those skilled in the art that the above embodiments are merely illustrative of the present invention, and various equivalent changes and substitutions may be made without departing from the spirit of the invention, and therefore, it is intended that all changes and modifications to the above embodiments within the spirit and scope of the present invention be covered by the appended claims.
Claims (14)
1. A method for migrating data in case information, which is used for migrating data in a first case report table to a second case report table, the method comprising:
obtaining first case information data in the first case report table, the first case information data being stored in a child node of an MPT tree, wherein the child node includes a value field in which entered information in the first case information data is stored and a metadata field in which non-entered information in the first case information data is stored;
obtaining second case information data in the second case report table, wherein non-input information in the second case information data is different from non-input information in the first case information data;
updating the non-input information in the metadata field in the first case information data by using the non-input information in the second case information data, and generating a second case report table by using the updated first case information data as the second case information data; and
performing a hash check process on the second case information data in the second case report table, wherein the hash check process is performed on the value field and the hash check process is not performed on the metadata field.
2. The data migration method of claim 1, wherein the metadata field is located after the value field.
3. The data migration method of claim 2, wherein said metadata field is contiguous with said value field.
4. The data migration method of claim 1, wherein said child nodes include leaf nodes and branch nodes.
5. The data migration method of claim 1, wherein the entered information comprises case content and the non-entered information comprises a version of a case report table.
6. A data storage method of case information, wherein the case information comprises input information and non-input information, the method is characterized by comprising the following steps: storing the case information in a child node of an MPT tree, the child node comprising a value field and a metadata field, wherein the entered information is stored in the value field and the non-entered information is stored in the metadata field; when a hash check process is performed, the metadata field does not participate in the hash check process.
7. The data storage method of claim 6, wherein the metadata field is located after the value field.
8. The data storage method of claim 7, wherein said metadata field is contiguous with said value field.
9. The data storage method of claim 6, wherein the child nodes include leaf nodes and branch nodes.
10. The data storage method of claim 6, wherein the value field participates in a hash check process.
11. The data storage method of claim 6, wherein the case information is a case report form, the entered information includes case content, and the non-entered information includes a version of the case report form.
12. A case information migration system comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method according to any one of claims 1 to 5 when executing the program.
13. A system for storing case information, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method according to any one of claims 6 to 11 when executing the program.
14. A computer-readable storage medium, having stored thereon a computer program which, when executed by a processor, implements the method of any one of claims 1-11.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011309802.2A CN112133387B (en) | 2020-11-20 | 2020-11-20 | Data migration and storage method and system for case information |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011309802.2A CN112133387B (en) | 2020-11-20 | 2020-11-20 | Data migration and storage method and system for case information |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112133387A CN112133387A (en) | 2020-12-25 |
| CN112133387B true CN112133387B (en) | 2021-03-16 |
Family
ID=73852102
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011309802.2A Active CN112133387B (en) | 2020-11-20 | 2020-11-20 | Data migration and storage method and system for case information |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112133387B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108123934A (en) * | 2017-12-06 | 2018-06-05 | 深圳先进技术研究院 | A kind of data integrity verifying method towards mobile terminal |
| CN110471927A (en) * | 2019-08-20 | 2019-11-19 | 浙江大搜车软件技术有限公司 | Metadata acquisition method, apparatus, computer equipment and storage medium |
| CN110942302A (en) * | 2019-11-26 | 2020-03-31 | 深圳前海微众银行股份有限公司 | Block chain certificate revocation and verification method, issuing node and verification node |
| CN111324413A (en) * | 2018-12-14 | 2020-06-23 | 中移（杭州）信息技术有限公司 | Data migration method and data migration management equipment |
| CN111488608A (en) * | 2020-04-08 | 2020-08-04 | 北京瑞策科技有限公司 | Data verification method and device for service data block chain |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109359062A (en) * | 2018-11-02 | 2019-02-19 | 郑州云海信息技术有限公司 | A kind of metadata read buffer method, device and equipment |
| CN110442571A (en) * | 2019-06-28 | 2019-11-12 | 卓尔智联(武汉)研究院有限公司 | A kind of data processing method, device and computer storage medium |
| CN111124541B (en) * | 2019-12-25 | 2023-09-08 | 上海米哈游网络科技股份有限公司 | Configuration file generation method, device, equipment and medium |
-
2020
- 2020-11-20 CN CN202011309802.2A patent/CN112133387B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108123934A (en) * | 2017-12-06 | 2018-06-05 | 深圳先进技术研究院 | A kind of data integrity verifying method towards mobile terminal |
| CN111324413A (en) * | 2018-12-14 | 2020-06-23 | 中移（杭州）信息技术有限公司 | Data migration method and data migration management equipment |
| CN110471927A (en) * | 2019-08-20 | 2019-11-19 | 浙江大搜车软件技术有限公司 | Metadata acquisition method, apparatus, computer equipment and storage medium |
| CN110942302A (en) * | 2019-11-26 | 2020-03-31 | 深圳前海微众银行股份有限公司 | Block chain certificate revocation and verification method, issuing node and verification node |
| CN111488608A (en) * | 2020-04-08 | 2020-08-04 | 北京瑞策科技有限公司 | Data verification method and device for service data block chain |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112133387A (en) | 2020-12-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Harrison | Next Generation Databases: NoSQLand Big Data | |
| CN108399256B (en) | Heterogeneous database content synchronization method and device and middleware | |
| Warren et al. | Big Data: Principles and best practices of scalable realtime data systems | |
| US9607063B1 (en) | NoSQL relational database (RDB) data movement | |
| CN104866497B (en) | The metadata updates method, apparatus of distributed file system column storage, host | |
| US9619492B2 (en) | Data migration | |
| US20220231860A1 (en) | Cryptographic verification of database transactions | |
| US20160117307A1 (en) | Recursive extraction and narration of nested tables | |
| CN103020262B (en) | Data storage method, system and data storage equipment | |
| CN103455589B (en) | Product data moving method under product factory mode, Apparatus and system | |
| CN104376091A (en) | Method and device for recovering deleted data in SQLite | |
| WO2018097846A1 (en) | Edge store designs for graph databases | |
| WO2020082597A1 (en) | Method and device for batch insertion and deletion of b+ tree nodes | |
| JP2009520284A (en) | Access method of XML file data | |
| US20200151582A1 (en) | Ascriptive and descriptive entities for process and translation: a limited iterative ontological notation | |
| US9715514B2 (en) | K-ary tree to binary tree conversion through complete height balanced technique | |
| US20150213151A1 (en) | Defining and transforming entity relationship-xml hybrid data models | |
| CN112133387B (en) | Data migration and storage method and system for case information | |
| US20140279842A1 (en) | Inferring a sequence of editing operations to facilitate merging versions of a shared document | |
| US11663177B2 (en) | Systems and methods for extracting data in column-based not only structured query language (NoSQL) databases | |
| CN110704635B (en) | Method and device for converting triplet data in knowledge graph | |
| US20150088483A1 (en) | Simulated component connector definition and connection process | |
| Baron et al. | Support for the placement of Chilesaurus within Ornithischia: a reply to Müller et al. | |
| CN110795915A (en) | Method, system, equipment and computer-readable storage medium for modifying xml file in batch | |
| CN109299475B (en) | Medical document processing method, device, medium and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |