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

A method of merging data from one database into another database uses metadata identifiers to indicate the type of data. One of the databases can be stored on a medical device, and the other of the databases can be stored on a computer. When transferring data from the first database to the second database, the metadata identifiers are used to identify and merge common data types.

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.

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 ACCU-CHEK®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 ACCU-CHEK® Active, ACCU-CHEK® Aviva, ACCU-CHEK® Compact, ACCU-CHEK® Compact Plus, ACCU-CHEK® Integra, ACCU-CHEK® Go, ACCU-CHEK® Performa, ACCU-CHEK® Spirit, ACCU-CHEK® D-Tron Plus, and ACCU-CHEK® Voicemate Plus, all provided by Roche Diagnostics or divisions thereof.

FIG. 1depicts a computer, generally indicated by numeral10, and a medical device, generally indicated by numeral12. Computer10may be any type of computer capable of running software. In the depicted embodiment, computer10is a laptop computer. In addition, computer10includes receiver14. Receiver14may be connected to computer10in any suitable manner, such as through a USB connection, for example.

For purposes of the present example, computer10includes a hard drive (not shown) capable of storing data in a conventional manner. The software stored in the memory of computer10generally allows computer10to communicate with device12. In embodiments, the software allows computer10to communicate with device12by way of receiver14. In embodiments, the software installed on computer10may 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.

Device12may be any suitable medical device capable of communicating with the software stored on computer10, such as a blood glucose meter, for example. Device12includes a dynamic memory, thereby allowing the device12to store and save various types of data. For example, as device12is 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 device12. Furthermore, device12may allow a user to add additional data to the memory that is not measured directly by device12, such as the weight of the patient, for example. In general, the data stored in the memory of device12may be stored in a database in the memory of device12.

In the present example, the software executed by computer10is configured to allow computer10to communicate with device12by way of receiver14. The communication between device12and receiver14may occur in any suitable manner. For example, device12and receiver14may communicate wirelessly, such as via infrared signals or via radio frequency signals. In embodiments, device12may communicate with receiver14in 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 device12may communicate directly with computer10, in a suitable manner. For example, device12may communicate with computer10in a wireless manner or non-wireless manner without the utilization of receiver14.

Generally, once a connection between computer10and device12has been established, the data stored in the database of device12may be downloaded onto computer10. The user may initiate the download process, or in embodiments, the download process may occur automatically.

FIG. 2is a schematic that represents the databases in the memory of computer10and device12. InFIG. 2, numerals20,22,24,26represent different sets of various types of data stored in the memory of computer10. Similarly, numerals30,32,34,36represent different fields, or sets, of various types of data stored in the memory of device12. Specifically, the memory of computer10includes data relating to blood glucose measurements of a patient, represented by numeral20, weight measurements of a patient, represented by numeral22, the type of insulin taken by a patient, represented by numeral24, and the amount of insulin taken by a patient, represented by numeral26. The memory of device12includes data associated with the blood glucose measurements of a patient, represented by numeral30, the height measurements of a patient, represented by numeral32, the type of insulin taken by a patient, represented by numeral34, and the amount of insulin taken by a patient, represented by numeral36.

It should be noted that the names identifying the data stored in computer10and device12may 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 computer10and the manufacture of device12. 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 computer10, but a health care provider may select the name “insulin type”24to represent the data stored on computer10that is associated with the type of insulin utilized by the patient after the provider has purchased the software installed on computer10. Similarly, a patient may select the name “insulin”34to represent the data stored in device12relating 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 data26associated with the amount of insulin being utilized by the patient.

Referring still toFIG. 2, each field of data20,22,24,26stored within computer10includes a metadata identifier, or unique global identifier, represented by numerals20′,22′,24′,26′ respectively. Similarly, each field of data30,32,34,36stored within device12includes a metadata identifier, represented by numerals30′,32′,34′,36′, respectively. The metadata identifiers20′,22′,24′,26′,30′,32′,34′,36′ may be associated with the data20,22,24,26,30,32,34,36in any suitable manner. Generally, identical types of data have identical metadata identifiers. For example, the metadata identifier20′ assigned to the blood glucose data20stored on computer10is identical to the metadata identifier30′ assigned to the blood glucose data30stored on device12. Similarly, the metadata24′ associated with insulin type data24stored on computer10is identical to the metadata34′ associated with the insulin type data34stored on device12, even though the data fields24,34have different names. It should noted that in embodiments, the data fields24,34may have originally had identical names, but the names of the data fields24,34may have been changed at a later time.

The metadata identifiers20′,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 measurements20,30may be established at the factory during the production of the software utilized by computer10and device12. 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 toFIG. 2, double arrow40represents the communication between computer10and device12. The communication represented by arrow40may occur when a user is downloading data from device12onto computer10.

As computer10receives, for example, the data30relating to blood glucose measurements from device12, the computer10compares metadata identifier30′ to the metadata identifiers20′,22′,24′,26′ present within the database resident in the memory of computer10. In the present example, the metadata identifier30′ matches metadata identifier20′, since both of the metadata identifiers20′,30′ refer to the same type of data. Accordingly, the data relating to blood glucose measurements30present within the memory of device12is merged with the data relating to blood glucose measurements20present within the memory of computer10. The merging of the data20,30may be accomplished in any suitable manner. Once the blood glucose measurements30have been merged with the blood glucose measurements20, the data relating to the blood glucose measurements30stored on device12may be deleted from device12.FIG. 3illustrates the memory of the computer10and the device12following the above described process.

Computer10will continue to compare the metadata identifier as additional data is downloaded. Note that in the present example, computer10does not include metadata that corresponds to the metadata identifier32′. Accordingly, the data representative of the height of the patient32is copied from device12onto computer10as a new data field. The data32may then be deleted from device12, thereby leaving the memory of computer10and device12configured as depicted inFIG. 4. In embodiments of the invention, data32may not be copied onto computer10and may continue to reside on device12.

The type of insulin utilized by the patient is stored on device12in data field34. Metadata identifier34′ identifies the data34in device12. Accordingly, computer10compares metadata identifier34′ to the metadata identifiers20′,22′,24′,26′,32′ present within the memory of computer10in order to determine if computer10has a type of data corresponding to insulin34. In the present example, metadata34′ corresponds to metadata24′, as both types of metadata24′,34′ identify data relating to the type of insulin being taken by the patient. It should be noted that the metadata identifiers24′,34′ are identical even though the data identifiers24,34have different names. Accordingly, as shown inFIG. 5, the insulin data34may be combined with the insulin type data24in computer10, and insulin data34may be deleted from device12.

With reference still toFIG. 5, device12again sends metadata identifier36′ to computer10. Computer10compares metadata identifier36′ with all of the metadata identifiers20′,22′,24′,26′,32′ stored in the memory of computer10. In the present example, metadata identifier36′ corresponds to metadata identifier26′. It should be noted that the data36corresponding to metadata identifier36′ has a different name than the data26corresponding to metadata identifier26′. Since metadata36′ corresponds to metadata26′, however, the data represented by data field36is copied into the data field26. Once the data36has been copied into the field26, the data in field36may be deleted from device12.

It should be noted that since the software running on computer10utilizes the metadata identifiers20′,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 computer10and/or device12after the computer10and device12have been shipped from the factory. As the users add new data types to the memory, the software on the computer10and device12assigns a suitable metadata identifier to the data field. The computer10and device12may generate the metadata identifier in any suitable manner.

In embodiments of the invention, the user of the computer10may create a data field configured to store a specific type of data, and the user of device12may create a data field configured to store the same specific type of data. For example, with respect toFIG. 7, the user of computer10may create a user defined data field to record the blood pressure of the patient. In the depicted embodiment, numeral50represents the blood pressure field of data on computer10, and numeral50′ represents the metadata identifier of the blood pressure data50on computer10. Similarly, a user may create a field of data capable of storing blood pressure measurements on device12. In the depicted embodiment, numeral52represents the blood pressure field of data on device12, and numeral52′ represents the metadata identifier of the blood pressure data52on device12. For purposes of the present example, it is assumed that the user entered different blood pressure data of the same type on computer10and device12.

Once the link40is established between computer10and device12, in a manner similar to that described above, computer10will compare metadata identifier52′ to the metadata identifiers20′,22′,24′,26′,32′,50′ stored in the database of computer10. In this example, since the data fields50,52for the blood pressure data on the computer10and device12were created independent of each other, the respective metadata identifiers50′,52′ are not identical. Thus, during the download process, the user may manually instruct the computer10to consider the metadata identifiers50′,52′ as being identical since the identifiers identify the same type of data. Accordingly, the computer10combines data52with data50, and data52is deleted from device12. Thus, computer10, when queried to display blood pressure data, will display all data associated with metadata identifiers50′,52′. In addition, going forward, computer10will automatically associate metadata identifier52′ with metadata identifier50′. Thus, in the future, when device12is linked to computer10and computer10receives metadata identifier52′ from device12, computer10will associate data field52with data field50, in a manner described above.

It should be noted that the computer10is also capable of uploading data onto device12. 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.

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.