Patent Application
20090150377
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.
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.
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.
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:
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.
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 (Atty Docket: ROCHE-P0033), METHOD AND SYSTEM FOR GRAPHICALLY INDICATING MULTIPLE DATA VALUES (Atty Docket: ROCHE-P0039), SYSTEM AND METHOD FOR DATABASE INTEGRITY CHECKING (Atty Docket: ROCHE-P0056), METHOD AND SYSTEM FOR DATA SOURCE AND MODIFICATION TRACKING (Atty Docket: ROCHE-P0037), PATIENT-CENTRIC HEALTHCARE INFORMATION MAINTENANCE (Atty Docket: ROCHE-P0043), EXPORT FILE FORMAT WITH MANIFEST FOR ENHANCED DATA TRANSFER (Atty Docket: ROCHE-P0044), GRAPHIC ZOOM FUNCTIONALITY FOR A CUSTOM REPORT (Atty Docket: ROCHE-P0048), METHOD AND SYSTEM FOR SELECTIVE MERGING OF PATIENT DATA (Atty Docket: ROCHE-P0065), METHOD AND SYSTEM FOR PERSONAL MEDICAL DATA DATABASE MERGING (Atty Docket: ROCHE-P0066), METHOD AND SYSTEM FOR WIRELESS DEVICE COMMUNICATION (Atty Docket: ROCHE-P0034), METHOD AND SYSTEM FOR SETTING TIME BLOCKS (Atty Docket: ROCHE-P0054), METHOD AND SYSTEM FOR ENHANCED DATA TRANSFER (Atty Docket: ROCHE-P0042), COMMON EXTENSIBLE DATA EXCHANGE FORMAT (Atty Docket: ROCHE-P0036), METHOD OF CLONING SERVER INSTALLATION TO A NETWORK CLIENT (Atty Docket: ROCHE-P0035), METHOD AND SYSTEM FOR QUERYING A DATABASE (Atty Docket: ROCHE-P0049), METHOD AND SYSTEM FOR EVENT BASED DATA COMPARISON (Atty Docket: ROCHE-P0050), DYNAMIC COMMUNICATION STACK (Atty Docket: ROCHE-P0051), SYSTEM AND METHOD FOR REPORTING MEDICAL INFORMATION (Atty Docket: ROCHE-P0045), METHOD AND SYSTEM FOR ACTIVATING FEATURES AND FUNCTIONS OF A CONSOLIDATED SOFTWARE APPLICATION (Atty Docket: ROCHE-P0057), METHOD AND SYSTEM FOR CONFIGURING A CONSOLIDATED SOFTWARE APPLICATION (Atty Docket: ROCHE-P0058), METHOD AND SYSTEM FOR DATA SELECTION AND DISPLAY (Atty Docket: ROCHE-P0011), METHOD AND SYSTEM FOR ASSOCIATING DATABASE CONTENT FOR SECURITY ENHANCEMENT (Atty Docket: ROCHE-P0041), METHOD AND SYSTEM FOR CREATING REPORTS (Atty Docket: ROCHE-P0046), METHOD AND SYSTEM FOR CREATING USER-DEFINED OUTPUTS (Atty Docket: ROCHE-P0047), DATA DRIVEN COMMUNICATION PROTOCOL GRAMMAR (Atty Docket: ROCHE-P0055), HEALTHCARE MANAGEMENT SYSTEM HAVING IMPROVED PRINTING OF DISPLAY SCREEN INFORMATION (Atty Docket: ROCHE-P0031), and METHOD AND SYSTEM FOR MULTI-DEVICE COMMUNICATION (Atty Docket: ROCHE-P0064), 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
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.
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
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
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.
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
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
With reference still to
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
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.
