Patent Publication Number: US-8112390-B2

Title: Method and system for merging extensible data into a database using globally unique identifiers

Description:
FIELD OF THE INVENTION 
     The present invention relates to a method of merging data from multiple databases into a single database. Specifically, the present invention relates to utilizing globally unique identifiers in the databases to distinguish between different types of data. 
     BACKGROUND OF THE INVENTION 
     Merging data contained in a plurality of databases is known. The databases may include fields of data defined by a name identifier. In some cases, different databases may contain different types of data identified by the same name identifier. When a user selects the data fields to be merged in the combined database, the fields having the same name identifier from the separate databases may be combined into a single data field, even if those fields represent different types of data. 
     SUMMARY OF THE INVENTION 
     An embodiment of the invention comprises a method of transferring a first set of data from a first database to a second database. The method includes the steps of comparing a metadata identifier assigned to a first set of data to a plurality of metadata identifiers associated with the second database; and combining the first set of data in the first database with a set of data in the second database having the same metadata identifier. 
     Embodiments of the invention further include the step of adding the first set of data to the second database if the metadata identifier does not match the plurality of metadata identifiers in the second database. The method may include the step of configuring a portion of the first database to store the first set of data. The metadata identifier is assigned to the first set of data when a user creates the first set of data. The method may include the step of configuring a portion of the second database to store a set of data of the same type as the first set of data in the first database. 
     In embodiments of the invention, the first database is stored on a device, and the second database is stored on a computer. In embodiments, the first database is stored on a first computer, and the second database is stored on a second computer. 
     An embodiment of the invention comprises a method for combining at least one subset of a set of data comprising a first database with a set of data comprising a second database. The method includes the steps of assigning a metadata identifier to each subset of data comprising the first database; assigning a metadata identifier to at least one subset of data comprising the second database; comparing each metadata identifier of the first database with each metadata identifier of the second database; and combining a subset of data of the first database with the second database if the metadata identifier of the first database is the same as the metadata identifier of the second database. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The above-mentioned and other features of this invention, and the manner of attaining them, will become more apparent and the invention itself will be better understood by reference to the following description of embodiments of the invention taken in conjunction with the accompanying drawings, wherein: 
         FIG. 1  depicts an example of an embodiment of a system utilizing the present invention; and 
         FIGS. 2 through 7  depict schematic diagrams illustrating embodiments of the present invention utilizing the system depicted in  FIG. 1  for exemplary purposes. 
     
    
    
     Although the drawings represent embodiments of various features and components according to the present invention, the drawings are not necessarily to scale and certain features may be exaggerated in order to better illustrate and explain the present invention. The exemplifications set out herein illustrate embodiments of the invention, and such exemplifications are not to be construed as limiting the scope of the invention in any manner. 
     DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION 
     For the purposes of promoting an understanding of the principles of the invention, reference will now be made to the embodiments illustrated in the drawings, which are described below. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. The invention includes any alterations and further modifications in the illustrated devices and described methods and further applications of the principles of the invention, which would normally occur to one skilled in the art to which the invention relates. Moreover, the embodiments were selected for description to enable one of ordinary skill in the art to practice the invention. 
     Concepts described below may be further explained in one of more of the co-filed patent applications entitled HELP UTILITY FUNCTIONALITY AND ARCHITECTURE U.S. Ser. No. 11/999,906, METHOD AND SYSTEM FOR GRAPHICALLY INDICATING MULTIPLE DATA VALUES U.S. Ser. No. 11/999,853, SYSTEM AND METHOD FOR DATABASE INTEGRITY CHECKING U.S. Ser. No. 11/999,856, METHOD AND SYSTEM FOR DATA SOURCE AND MODIFICATION TRACKING U.S. Ser. No. 11/999,888, PATIENT-CENTRIC HEALTHCARE INFORMATION MAINTENANCE U.S. Ser. No. 11/999,874, EXPORT FILE FORMAT WITH MANIFEST FOR ENHANCED DATA TRANSFER U.S. Ser. No. 11/999,867, GRAPHIC ZOOM FUNCTIONALITY FOR A CUSTOM REPORT U.S. Ser. No. 11/999,932, METHOD AND SYSTEM FOR SELECTIVE MERGING OF PATIENT DATA U.S. Ser. No. 11/999,859, METHOD AND SYSTEM FOR PERSONAL MEDICAL DATA DATABASE MERGING U.S. Ser. No. 11/999,772, METHOD AND SYSTEM FOR WIRELESS DEVICE COMMUNICATION U.S. Ser. No. 12/999,879, METHOD AND SYSTEM FOR SETTING TIME BLOCKS U.S. Ser. No. 11/999,968, METHOD AND SYSTEM FOR ENHANCED DATA TRANSFER U.S. Ser. No. 11/999,911, COMMON EXTENSIBLE DATA EXCHANGE FORMAT U.S. Ser. No. 11/999,871, METHOD OF CLONING SERVER INSTALLATION TO A NETWORK CLIENT U.S. Ser. No. 11/999,876, METHOD AND SYSTEM FOR QUERYING A DATABASE U.S. Ser. No. 11/999,912, METHOD AND SYSTEM FOR EVENT BASED DATA COMPARISON U.S. Ser. No. 11/999,921, DYNAMIC COMMUNICATION STACK U.S. Ser. No. 11/999,934, SYSTEM AND METHOD FOR REPORTING MEDICAL INFORMATION U.S. Ser. No. 11/999,878, METHOD AND SYSTEM FOR ACTIVATING FEATURES AND FUNCTIONS OF A CONSOLIDATED SOFTWARE APPLICATION U.S. Ser. No. 11/999,880, METHOD AND SYSTEM FOR CONFIGURING A CONSOLIDATED SOFTWARE APPLICATION U.S. Ser. No. 11/999,894, METHOD AND SYSTEM FOR DATA SELECTION AND DISPLAY U.S. Ser. No. 11/999,896, METHOD AND SYSTEM FOR ASSOCIATING DATABASE CONTENT FOR SECURITY ENHANCEMENT U.S. Ser. No. 11/999,951, METHOD AND SYSTEM FOR CREATING REPORTS U.S. Ser. No. 11/999,951, METHOD AND SYSTEM FOR CREATING USER-DEFINED OUTPUTS U.S. Ser. No. 11/999,905, DATA DRIVEN COMMUNICATION PROTOCOL GRAMMAR U.S. Ser. No. 11/999,770, HEALTHCARE MANAGEMENT SYSTEM HAVING IMPROVED PRINTING OF DISPLAY SCREEN INFORMATION U.S. Ser. No. 11/999,855, and METHOD AND SYSTEM FOR MULTI-DEVICE COMMUNICATION U.S. Ser. No. 11/999,866, the entire disclosures of which are hereby expressly incorporated herein by reference. It should be understood that the concepts described below may relate to diabetes management software systems for tracking and analyzing health data, such as, for example, the A CCU -C HEK®  360° product provided by Roche Diagnostics. However, the concepts described herein may also have applicability to apparatuses, methods, systems, and software in fields that are unrelated to healthcare. Furthermore, it should be understood that references in this patent application to devices, meters, monitors, pumps, or related terms are intended to encompass any currently existing or later developed apparatus that includes some or all of the features attributed to the referred to apparatus, including but not limited to the A CCU -C HEK ® Active, A CCU -C HEK ® Aviva, A CCU -C HEK ® Compact, A CCU -C HEK ® Compact Plus, A CCU -C HEK ® Integra, A CCU -C HEK ® Go, A CCU -C HEK ® Performa, A CCU -C HEK ® Spirit, A CCU -C HEK ® D-Tron Plus, and A CCU -C HEK ® Voicemate Plus, all provided by Roche Diagnostics or divisions thereof. 
       FIG. 1  depicts a computer, generally indicated by numeral  10 , and a medical device, generally indicated by numeral  12 . Computer  10  may be any type of computer capable of running software. In the depicted embodiment, computer  10  is a laptop computer. In addition, computer  10  includes receiver  14 . Receiver  14  may be connected to computer  10  in any suitable manner, such as through a USB connection, for example. 
     For purposes of the present example, computer  10  includes a hard drive (not shown) capable of storing data in a conventional manner. The software stored in the memory of computer  10  generally allows computer  10  to communicate with device  12 . In embodiments, the software allows computer  10  to communicate with device  12  by way of receiver  14 . In embodiments, the software installed on computer  10  may be ACCU-CHEK® 360° software manufactured by Roche Diagnostics. Although the software is described herein for operation on a computer (e.g., desktop, laptop or tablet), it should be understood that the principles of the invention may be embodied in software for operation on various devices, including but not limited to personal digital assistants (“PDAs”), infusion pumps, blood glucose meters, cellular phones, or integrated devices including a glucose measurement engine and a PDA or cellular device. 
     Device  12  may be any suitable medical device capable of communicating with the software stored on computer  10 , such as a blood glucose meter, for example. Device  12  includes a dynamic memory, thereby allowing the device  12  to store and save various types of data. For example, as device  12  is utilized to measure exemplary physiological information in patients, such as the blood glucose levels of patients, and the measured values may be saved in the memory of the device  12 . Furthermore, device  12  may allow a user to add additional data to the memory that is not measured directly by device  12 , such as the weight of the patient, for example. In general, the data stored in the memory of device  12  may be stored in a database in the memory of device  12 . 
     In the present example, the software executed by computer  10  is configured to allow computer  10  to communicate with device  12  by way of receiver  14 . The communication between device  12  and receiver  14  may occur in any suitable manner. For example, device  12  and receiver  14  may communicate wirelessly, such as via infrared signals or via radio frequency signals. In embodiments, device  12  may communicate with receiver  14  in a non-wireless manner utilizing a direct connection, such as that which may be established using a suitable cord and plug combination, for example. It should be noted that in embodiments, the device  12  may communicate directly with computer  10 , in a suitable manner. For example, device  12  may communicate with computer  10  in a wireless manner or non-wireless manner without the utilization of receiver  14 . 
     Generally, once a connection between computer  10  and device  12  has been established, the data stored in the database of device  12  may be downloaded onto computer  10 . The user may initiate the download process, or in embodiments, the download process may occur automatically. 
       FIG. 2  is a schematic that represents the databases in the memory of computer  10  and device  12 . In  FIG. 2 , numerals  20 ,  22 ,  24 ,  26  represent different sets of various types of data stored in the memory of computer  10 . Similarly, numerals  30 ,  32 ,  34 ,  36  represent different fields, or sets, of various types of data stored in the memory of device  12 . Specifically, the memory of computer  10  includes data relating to blood glucose measurements of a patient, represented by numeral  20 , weight measurements of a patient, represented by numeral  22 , the type of insulin taken by a patient, represented by numeral  24 , and the amount of insulin taken by a patient, represented by numeral  26 . The memory of device  12  includes data associated with the blood glucose measurements of a patient, represented by numeral  30 , the height measurements of a patient, represented by numeral  32 , the type of insulin taken by a patient, represented by numeral  34 , and the amount of insulin taken by a patient, represented by numeral  36 . 
     It should be noted that the names identifying the data stored in computer  10  and device  12  may be generated in any suitable manner. For example, the names of the different types of data may be selected at the factory, during the manufacture of the software stored on computer  10  and the manufacture of device  12 . In addition, some fields of data may be named either by a health care provider monitoring a patient, or by the patient himself. For instance, in the depicted example, the “blood glucose” data field may be added to the database during manufacture of the computer  10 , but a health care provider may select the name “insulin type”  24  to represent the data stored on computer  10  that is associated with the type of insulin utilized by the patient after the provider has purchased the software installed on computer  10 . Similarly, a patient may select the name “insulin”  34  to represent the data stored in device  12  relating to the type of insulin utilized by the patient. It should be noted that in the present example, the health care provider has used the title “insulin” to represent the data  26  associated with the amount of insulin being utilized by the patient. 
     Referring still to  FIG. 2 , each field of data  20 ,  22 ,  24 ,  26  stored within computer  10  includes a metadata identifier, or unique global identifier, represented by numerals  20 ′,  22 ′,  24 ′,  26 ′ respectively. Similarly, each field of data  30 ,  32 ,  34 ,  36  stored within device  12  includes a metadata identifier, represented by numerals  30 ′,  32 ′,  34 ′,  36 ′, respectively. The metadata identifiers  20 ′,  22 ′,  24 ′,  26 ′,  30 ′,  32 ′,  34 ′,  36 ′ may be associated with the data  20 ,  22 ,  24 ,  26 ,  30 ,  32 ,  34 ,  36  in any suitable manner. Generally, identical types of data have identical metadata identifiers. For example, the metadata identifier  20 ′ assigned to the blood glucose data  20  stored on computer  10  is identical to the metadata identifier  30 ′ assigned to the blood glucose data  30  stored on device  12 . Similarly, the metadata  24 ′ associated with insulin type data  24  stored on computer  10  is identical to the metadata  34 ′ associated with the insulin type data  34  stored on device  12 , even though the data fields  24 ,  34  have different names. It should noted that in embodiments, the data fields  24 ,  34  may have originally had identical names, but the names of the data fields  24 ,  34  may have been changed at a later time. 
     The metadata identifiers  20 ′,  22 ′,  24 ′,  26 ′,  30 ′,  32 ′,  34 ′,  36 ′ may be generated in any conventional manner. In the present example, the metadata identifiers are created by the application. As discussed above, certain types of data including the data field and the associated name, such as blood glucose measurements  20 ,  30  may be established at the factory during the production of the software utilized by computer  10  and device  12 . Other types of data, such as the type of insulin utilized by the patient, may be configured for storage in the database by either the patient or the health care provider. 
     With respect to the pre-set data types that originate from the factory, pre-set metadata identifiers may be utilized to identify the pre-set data types. This understanding may hold true in later versions of the software, thereby allowing a specific pre-set data type to utilize an identical metadata identifier in multiple versions of the software and in different products. Generally, the metadata identifiers generated for data types originating at the factory are consistent for all deployments of software and devices. For example, in previous versions of the software a specific metadata identifier may be associated with measurements relating to blood glucose levels in a patient. Going forward, in each new version of software or each new version of medical device in production, the measurements relating to blood glucose level of a patient are associated with the same metadata identifier. Accordingly, later versions of the software will be capable of identifying various types of data utilized in earlier versions of the software or in older devices. The metadata identifiers created by the software or the device, after each has left the factory, are generally not repeated. 
     With reference still to  FIG. 2 , double arrow  40  represents the communication between computer  10  and device  12 . The communication represented by arrow  40  may occur when a user is downloading data from device  12  onto computer  10 . 
     As computer  10  receives, for example, the data  30  relating to blood glucose measurements from device  12 , the computer  10  compares metadata identifier  30 ′ to the metadata identifiers  20 ′,  22 ′,  24 ′,  26 ′ present within the database resident in the memory of computer  10 . In the present example, the metadata identifier  30 ′ matches metadata identifier  20 ′, since both of the metadata identifiers  20 ′,  30 ′ refer to the same type of data. Accordingly, the data relating to blood glucose measurements  30  present within the memory of device  12  is merged with the data relating to blood glucose measurements  20  present within the memory of computer  10 . The merging of the data  20 ,  30  may be accomplished in any suitable manner. Once the blood glucose measurements  30  have been merged with the blood glucose measurements  20 , the data relating to the blood glucose measurements  30  stored on device  12  may be deleted from device  12 .  FIG. 3  illustrates the memory of the computer  10  and the device  12  following the above described process. 
     Computer  10  will continue to compare the metadata identifier as additional data is downloaded. Note that in the present example, computer  10  does not include metadata that corresponds to the metadata identifier  32 ′. Accordingly, the data representative of the height of the patient  32  is copied from device  12  onto computer  10  as a new data field. The data  32  may then be deleted from device  12 , thereby leaving the memory of computer  10  and device  12  configured as depicted in  FIG. 4 . In embodiments of the invention, data  32  may not be copied onto computer  10  and may continue to reside on device  12 . 
     The type of insulin utilized by the patient is stored on device  12  in data field  34 . Metadata identifier  34 ′ identifies the data  34  in device  12 . Accordingly, computer  10  compares metadata identifier  34 ′ to the metadata identifiers  20 ′,  22 ′,  24 ′,  26 ′,  32 ′ present within the memory of computer  10  in order to determine if computer  10  has a type of data corresponding to insulin  34 . In the present example, metadata  34 ′ corresponds to metadata  24 ′, as both types of metadata  24 ′,  34 ′ identify data relating to the type of insulin being taken by the patient. It should be noted that the metadata identifiers  24 ′,  34 ′ are identical even though the data identifiers  24 ,  34  have different names. Accordingly, as shown in  FIG. 5 , the insulin data  34  may be combined with the insulin type data  24  in computer  10 , and insulin data  34  may be deleted from device  12 . 
     With reference still to  FIG. 5 , device  12  again sends metadata identifier  36 ′ to computer  10 . Computer  10  compares metadata identifier  36 ′ with all of the metadata identifiers  20 ′,  22 ′,  24 ′,  26 ′,  32 ′ stored in the memory of computer  10 . In the present example, metadata identifier  36 ′ corresponds to metadata identifier  26 ′. It should be noted that the data  36  corresponding to metadata identifier  36 ′ has a different name than the data  26  corresponding to metadata identifier  26 ′. Since metadata  36 ′ corresponds to metadata  26 ′, however, the data represented by data field  36  is copied into the data field  26 . Once the data  36  has been copied into the field  26 , the data in field  36  may be deleted from device  12 . 
     It should be noted that since the software running on computer  10  utilizes the metadata identifiers  20 ′,  22 ′,  24 ′,  26 ′,  30 ′,  32 ′,  34 ′,  36 ′ to actually identify the different data types, the different data types may be identified by any name. Thus, in embodiments of the invention, users may add additional data fields to the computer  10  and/or device  12  after the computer  10  and device  12  have been shipped from the factory. As the users add new data types to the memory, the software on the computer  10  and device  12  assigns a suitable metadata identifier to the data field. The computer  10  and device  12  may generate the metadata identifier in any suitable manner. 
     In embodiments of the invention, the user of the computer  10  may create a data field configured to store a specific type of data, and the user of device  12  may create a data field configured to store the same specific type of data. For example, with respect to  FIG. 7 , the user of computer  10  may create a user defined data field to record the blood pressure of the patient. In the depicted embodiment, numeral  50  represents the blood pressure field of data on computer  10 , and numeral  50 ′ represents the metadata identifier of the blood pressure data  50  on computer  10 . Similarly, a user may create a field of data capable of storing blood pressure measurements on device  12 . In the depicted embodiment, numeral  52  represents the blood pressure field of data on device  12 , and numeral  52 ′ represents the metadata identifier of the blood pressure data  52  on device  12 . For purposes of the present example, it is assumed that the user entered different blood pressure data of the same type on computer  10  and device  12 . 
     Once the link  40  is established between computer  10  and device  12 , in a manner similar to that described above, computer  10  will compare metadata identifier  52 ′ to the metadata identifiers  20 ′,  22 ′,  24 ′,  26 ′,  32 ′,  50 ′ stored in the database of computer  10 . In this example, since the data fields  50 ,  52  for the blood pressure data on the computer  10  and device  12  were created independent of each other, the respective metadata identifiers  50 ′,  52 ′ are not identical. Thus, during the download process, the user may manually instruct the computer  10  to consider the metadata identifiers  50 ′,  52 ′ as being identical since the identifiers identify the same type of data. Accordingly, the computer  10  combines data  52  with data  50 , and data  52  is deleted from device  12 . Thus, computer  10 , when queried to display blood pressure data, will display all data associated with metadata identifiers  50 ′,  52 ′. In addition, going forward, computer  10  will automatically associate metadata identifier  52 ′ with metadata identifier  50 ′. Thus, in the future, when device  12  is linked to computer  10  and computer  10  receives metadata identifier  52 ′ from device  12 , computer  10  will associate data field  52  with data field  50 , in a manner described above. 
     It should be noted that the computer  10  is also capable of uploading data onto device  12 . Generally, this would occur in a manner similar to that described above, wherein the device would compare the metadata identifier of the newly received data with the metadata identifiers of the data stored on the device before determining whether the newly received data was new data or intended to be combined with data already present on the device. 
     Although the software is described herein for operation on a computer (e.g., desktop, laptop or tablet), it should be understood that the principles of the invention may be embodied in software for operation on various devices, including but not limited to personal digital assistants (“PDAs”), infusion pumps, blood glucose meters, cellular phones, or integrated devices including a glucose measurement engine and a PDA or cellular device. 
     In addition to blood glucose values, exemplary physiological information includes A1c values, Albumin values, Albumin excretion values, body mass index values, blood pressure values, carbohydrate values, cholesterol values (total, HDL, LDL, ratio) cheatinine values, fructosamine values, HbA1values, height values, insulin dose values, insulin rate values, total daily insulin values, ketone values, microalbumin values, proteinuria values, heart rate values, temperature values, triglyceride values, and weight values. 
     The invention is described herein with reference to healthcare data management software, and more particularly, with reference to diabetes management software, although the invention may be applied, generally, to data management systems in fields unrelated to healthcare management. 
     While the invention is described herein with reference to medical devices, and more particularly, with reference to diabetes management devices, the invention is applicable to any data obtained from any device. 
     While this invention has been described as having an exemplary design, the present invention may be further modified within the spirit and scope of this disclosure. This application is therefore intended to cover any variations, uses, or adaptations of the invention using its general principles. Further, this application is intended to cover such departures from the present disclosure as come within known or customary practice in the art to which this invention pertains.