HK1186547A - Metadata tagging system for a diabetes management system of devices - Google Patents

Description

Metadata tag system for diabetes management system of device

Technical Field

The present disclosure relates generally to medical devices and, more particularly, to a system for tagging metadata to data communicated between devices in a diabetes management system.

Background

Medical devices are often used as diagnostic and/or therapeutic devices in diagnosing and/or treating a medical condition of a patient. For example, a blood glucose meter is used as a diagnostic device to measure blood glucose levels of patients with diabetes. An insulin infusion pump is used as a treatment device to administer insulin to patients with diabetes.

Diabetes mellitus (commonly referred to as diabetes) is a chronic condition in which a person has elevated blood glucose levels caused by a deficiency in the body's ability to produce and/or use insulin. There are three main types of diabetes. Type 1 diabetes can be autoimmune, genetic, and/or environmental and usually affects children and young adults. Type 2 diabetes accounts for 90-95% of the cases of diabetes and is associated with obesity and physical inactivity. Gestational diabetes is a form of glucose intolerance diagnosed during pregnancy and usually self-disappears after delivery.

In 2009, at least 2 million people worldwide had diabetes according to the world health organization. In 2005, it was estimated that 110 million people died from diabetes. The incidence of diabetes is rapidly increasing and it is estimated that the number of deaths from diabetes doubles between 2005 and 2030. In the united states, nearly 2 thousand 4 million americans suffer from diabetes and an estimated 25% of the elderly aged 60 years and older are affected. Central prediction of disease control and prevention: 1 of 3 americans born after 2000 will develop diabetes during their life. National diabetes information exchange center estimates: diabetes costs in the united states alone at 1320 billion dollars per year. Without treatment, diabetes can lead to serious complications such as heart disease, stroke, blindness, kidney failure, amputation, and death associated with pneumonia and influenza.

Diabetes is managed primarily by controlling the glucose level in the bloodstream. This level is dynamic and complex, and is influenced by a number of factors including the amount and type of food consumed and the amount of insulin in the blood (which mediates transport of glucose across cell membranes). Blood glucose levels are also sensitive to exercise, sleep, stress, smoking, travel, illness, menses, and other psychological and lifestyle factors unique to individual patients. The dynamic nature of blood glucose and insulin, as well as all other factors affecting blood glucose, generally requires that people with diabetes predict blood glucose levels. Thus, treatments in the form of insulin, oral medications, or both may be scheduled to maintain blood glucose levels within an appropriate range.

Management of diabetes is time consuming for patients due to the need to constantly obtain reliable diagnostic information, follow prescribed therapy, and manage lifestyle on a daily basis. Typically, diagnostic information (e.g., blood glucose) is obtained from a capillary blood sample with a lancing device and then measured with a handheld blood glucose meter. Interstitial glucose levels can be obtained from a continuous glucose sensor worn on the body. The prescribed therapy may include insulin, oral medication, or both. Insulin may be delivered using a syringe, an ambulatory infusion pump, or a combination of the two. In the case of insulin therapy, determining the amount of insulin to be injected may require forecasting the dietary composition of fat, carbohydrates and proteins, as well as the effects of exercise or other physiological states. Management of lifestyle factors (e.g., weight, diet, and exercise) can significantly affect the type and effectiveness of treatment.

Management of diabetes involves a large amount of diagnostic and prescription data acquired in a number of ways: from a medical device; from a personal care device; from a patient record log; from laboratory tests; and recommendations from health care professionals. The medical devices include the patient's own bG meter, continuous glucose monitor, portable insulin infusion pump, diabetes analysis software. Each of these systems generates and/or manages a large amount of diagnostic and prescription data. The personal care device includes a weight scale, a blood pressure cuff, an exercise machine, a thermometer, and weight management software. The patient record log includes information related to meals, exercise, and lifestyle. Laboratory test results include HbA1C, cholesterol, triglycerides, and glucose tolerance. The healthcare professional recommendations include prescriptions, diets, test plans, and other information related to the patient's treatment.

There is a need for a handheld device for aggregating, manipulating, managing, presenting and communicating diagnostic and prescription data from medical devices, personal care devices, patient record information, biomarker information and record information in an efficient manner. The handheld device may improve the care and health of a person with diabetes, so that the person with diabetes may live an extended life and reduce the risk of complications from diabetes.

Furthermore, in order to efficiently manage the care and health of patients, means for reliably managing data records from other medical devices are required. As the system of devices communicating with each other becomes more complex, technical problems arise in attempting to keep data records consistent, especially when the patient has the ability to manually enter and edit the records. Accordingly, a system for tagging records with metadata to ensure unique metadata tags is described herein. Based on the metadata tag scheme, data records transmitted between devices can be kept consistent, and confusion of data can be avoided.

The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

Disclosure of Invention

In one aspect of the disclosure, a diabetes management system with a reliable data management scheme is disclosed herein. The diabetes management system includes a plurality of devices, each device performing a different function related to treatment of diabetes of a patient and having a device identifier identifying a type of the device. Each device generates a data record related to a function of the device, and each device includes a metadata generator configured to generate a metadata tag for the data record generated by the device. The metadata tag includes a device identifier of the corresponding device, a record identifier, and a source identifier indicating whether the record was originated by a person or by a device. The system also includes a diabetes management device in electronic communication with the plurality of devices, wherein the diabetes management device is configured to manage records received from the plurality of devices. When a first device of the plurality of devices generates a new record to be transmitted to the diabetes management device, the metadata generator of the first device generates a new unique record identifier and a new metadata tag based on the new unique record identifier and the device identifier of the first device, and the first device propagates the new record and the new metadata tag to a second device.

In a second aspect of the disclosure, a diabetes management system with a reliable data management scheme, the system comprising: a first device performing a first function related to treatment of diabetes and having a first device type identifier associated therewith; and a diabetes management device in communication with the first device. The first device has associated therewith the following: a) a record generation module that generates a record related to the first function or to an operational status of the first device; b) a metadata generator to generate a new metadata tag to tag the record, wherein the new metadata tag includes the first device type identifier, a record identifier that is a unique value associated with a first record, and a source identifier indicating whether the record was originated by a person or the first device; and c) a communication interface that allows the first device to communicate with a communication interface of the diabetes management device, wherein, when the first device is to transmit the record to the diabetes management device, the first metadata generator generates the new metadata tag, and a communication module transmits the record and the new metadata tag to the diabetes management device. The new metadata tag is associated with the record for the duration of the record.

Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the disclosure.

Drawings

The present disclosure will become more fully understood from the detailed description and the accompanying drawings, wherein:

FIG. 1 shows a patient and a treating clinician;

FIG. 2 shows a patient with a Continuous Glucose Monitor (CGM), a portable durable insulin infusion pump, a portable non-durable insulin infusion pump, and a diabetes manager;

FIG. 3 illustrates a diabetes care system in a system used by a patient and a clinician to manage diabetes;

FIG. 4 shows a high level diagram of a diabetes care system architecture in the system;

FIG. 5 illustrates components of a system of devices configured to communicate data records and corresponding metadata tags with one another; and

FIG. 6 illustrates an example of data records and metadata tags transmitted throughout the system of the diabetes treatment device.

Detailed Description

Referring now to FIG. 1, a person 100 with diabetes and a healthcare professional 102 are shown in a clinical setting. People with diabetes include people with metabolic syndrome, pre-diabetes, type 1 diabetes, type 2 diabetes, and gestational diabetes, and are collectively referred to as patients. Healthcare providers for diabetes are diverse and include nurses, nurse practitioners, physicians, and endocrinologists, and are commonly referred to as clinicians.

During a healthcare consultation, the patient 100 typically shares a variety of patient data with the clinician 102, including blood glucose measurements, continuous glucose monitoring data, the amount of insulin infused, the amount of food and beverages consumed, exercise schedules, and other lifestyle information. Additional patient data may be obtained by clinician 102, including measurements of HbA1C, cholesterol levels, triglycerides, blood pressure, and body weight of patient 100. The patient data may be recorded manually or electronically on the handheld diabetes management device 104, diabetes analysis software executing on a Personal Computer (PC) 106, and/or a web-based diabetes analysis site (not shown). The clinician 102 may analyze the patient data manually or electronically using diabetes analysis software and/or a web-based diabetes analysis site. After analyzing the patient data and checking the patient 100 for compliance with the previously prescribed therapy, the clinician 102 may decide whether to modify the therapy for the patient 100.

Referring now to fig. 2, the patient 100 may use a Continuous Glucose Monitor (CGM) 200, a portable durable insulin infusion pump 202 or a portable non-durable insulin infusion pump 204 (collectively referred to as insulin pumps 202 or 204), and a handheld diabetes management device 104 (hereinafter referred to as diabetes manager 104). The CGM 200 uses a subcutaneous sensor to sense and monitor the amount of glucose in the blood of the patient 100 and transmits a corresponding reading to the handheld diabetes management device 104.

The diabetes manager 104 performs various tasks including measuring and recording blood glucose levels, determining the amount of insulin to be administered to the patient 100 via the insulin pump 202 or 204, receiving patient data via a user interface, archiving patient data, and the like. The diabetes manager 104 periodically receives a reading from the CGM 200 indicative of the insulin level in the blood of the patient 100. The diabetes manager 104 transmits instructions to the insulin pump 202 or 204, and the insulin pump 202 or 204 delivers insulin to the patient 100. Insulin may be delivered in a single dose, which increases the amount of insulin in the blood of the patient 100 by a predetermined amount. Furthermore, insulin may be delivered in a scheduled manner in the form of a basal dose, which maintains a predetermined insulin level in the blood of the patient 100.

Referring now to FIG. 3, a diabetes management system 300 used by the patient 100 and the clinician 102 includes one or more of the following devices: a diabetes manager 104, a Continuous Glucose Monitor (CGM) 200, an insulin pump 202 or 204, a mobile device 302, diabetes analysis software on a PC 106, and other healthcare devices 304. The diabetes manager 104 is configured as a system hub and communicates with the devices of the diabetes management system 300. Alternatively, the insulin pump 204 or the mobile device 302 may act as a system hub. Communication between the various devices in the diabetes management system 300 can be performed using a wireless interface (e.g., bluetooth) and/or a wired interface (e.g., USB). The communication protocols used by these devices may include protocols conforming to the IEEE 11073 standard as extended using the Guidelines provided by Continua Health Alliance Design Guidelines. In addition, the patient 100 and clinician 102 may exchange information using a Health record system (e.g., Microsoft ® Health valve and Google ™ Health).

The diabetes manager 104 can receive blood glucose readings from one or more sources (e.g., from the CGM 200). The CGM 200 continuously measures the blood glucose level of the patient 100. The CGM 200 periodically communicates the blood glucose level to the diabetes manager 104. The diabetes manager 104 and the CGM 200 communicate wirelessly using a proprietary Gazell wireless protocol developed by Nordic Semiconductor, Inc.

In addition, the diabetes manager 104 includes a Blood Glucose Meter (BGM) and a port (neither shown) for communicating with the BGM. The port may receive a blood glucose measurement strip 306. The patient 100 places a blood sample or other bodily fluid on the blood glucose measurement strip 306. BGM analyzes a sample and measures blood glucose levels in the sample. The blood glucose level measured from the sample and/or the blood glucose level read by the CGM 200 may be used to determine the amount of insulin to be administered to the patient 100.

The diabetes manager 104 communicates with the insulin pump 202 or 204. The insulin pump 202 or 204 can be configured to receive instructions from the diabetes manager 104 for delivering a predetermined amount of insulin to the patient 100. In addition, the insulin pump 202 or 204 can receive other information, including meal and/or exercise schedules for the patient 100. The insulin pump 202 or 204 can determine the amount of insulin to be administered based on the additional information.

The insulin pump 202 or 204 can also transmit data to the diabetes manager 104. The data may include the amount of insulin delivered to the patient 100, the corresponding delivery time, and the pump status. The diabetes manager 104 and the insulin pump 202 or 204 can communicate using a wireless communication protocol (e.g., bluetooth). Other wireless or wired communication protocols may also be used.

In addition, the diabetes manager 104 can communicate with other healthcare devices 304. For example, other healthcare devices 304 may include a sphygmomanometer, a weight scale, a pedometer, a fingertip pulse oximeter, a thermometer, and the like. The other healthcare device 304 obtains the personal health information of the patient 100 and transmits the personal health information of the patient 100 to the diabetes manager 104 via a wireless, USB, or other interface. The other healthcare devices 304 use a communication protocol compliant with ISO/IEEE 11073 extended using the guidelines from Continua ® Health Alliance. The diabetes manager 104 can communicate with other healthcare devices 304 using interfaces including bluetooth, USB, and the like. Further, the devices of the diabetes management system 300 can communicate with each other via the diabetes manager 104.

The diabetes manager 104 can communicate with the PC 106 using a Bluetooth, USB, or other interface. The diabetes management software running on the PC 106 includes an analyzer-configurator that stores configuration information for the devices of the diabetes management system 300. The configurator has a database for storing configuration information for the diabetes manager 104 and other devices. The configurator may communicate with the user through a computer screen in a standard web or non-web application. The configurator transmits the user-approved configuration to the devices of the diabetes management system 300. The analyzer obtains data from the diabetes manager 104, stores the data in a database, and outputs the analysis results through a computer screen in a standard web page or non-web based application.

The diabetes manager 104 can use bluetooth to communicate with the mobile device 302. The mobile device 302 may comprise a cellular telephone, PDA, or pager. The diabetes manager 104 can send the message to an external network through the mobile device 302. The mobile device 302 can transmit a message to an external network based on a request received from the diabetes manager 104.

Referring now to FIG. 4, the diabetes manager 104 includes a Blood Glucose Measurement (BGM) module 400, a communication module 402, a user interface module 404, a user interface 406, a processing module 408, a memory 410, and a power module 412. The BGM module 400 includes a blood glucose measurement engine that analyzes samples provided by the patient 100 on the blood glucose measurement strip 306 and measures the amount of blood glucose in the samples. The communication module 402 includes a plurality of radios that communicate with different devices of the diabetes management system 300. The user interface module 404 interfaces the diabetes manager 104 to various user interfaces 406 that the patient 100 can use to interact with the diabetes manager 104. For example, the user interface 406 can include keys, switches, a display, a speaker, a microphone, a Secure Digital (SD) card port, a USB port, etc. of the diabetes manager 104 (not shown).

The processing module 408 processes data received from the BGM module 400, the communication module 402, and the user interface module 404. The processing module 408 uses a memory 410 for processing and storing data. The memory 410 may include volatile and non-volatile memory. The processing module 408 outputs data to the user interface 406 and receives data from the user interface 406 via the user interface module 404. The processing module 408 outputs data to and receives data from the devices of the diabetes management system 300 via the communication module 402. The power module 412 provides power to the components of the diabetes manager 104. The power module 412 includes a rechargeable battery. The battery may be recharged using an adapter plugged into a wall outlet. The battery may also be charged via the USB port of the diabetes manager 104.

FIG. 5 illustrates a diabetes manager 500 and a plurality of devices, each device performing a different function related to the treatment of diabetes of a patient. These devices include a CGM 540, an insulin pump 520, and a PC 530. However, it is contemplated that the system may include more or fewer devices. The diabetes manager 500 includes a plurality of communication interfaces 502, 504, and 506 that receive data records from the plurality of devices. Depending on the transmitting device, the received data record may include a metadata tag. The metadata tag is additional data stored with the data record that provides additional information to the data management module 516. A metadata item is a set of contiguous bytes within a data record that assign values to attributes of the data record. The metadata tag includes a device identifier of the device that generated the data, a record identifier, and a source identifier indicating whether the record was initiated by the patient, by the device, or by a third party. An exemplary structure of a metadata tag with exemplary metadata items is provided below:

Metadata tag{

data_record_type;

device_identifier;

record_identifier;

source_identifier;

time_stamp;

last_modification;

checksum;

}

as discussed, the diabetes manager 500 communicates with the plurality of devices such that data records are transferred from the devices to the diabetes manager 500 and from the diabetes manager 500 to the devices. The diabetes manager 500 manages treatment of diabetes of the patient in dependence on data received from the various devices. Therefore, a problem arises when data received from more than one source is inconsistent with the received data. Furthermore, a reliable way to resolve such inconsistencies is needed, as medical decisions can be derived from the received data.

For example, the patient may input via the user interface 512: a first amount of insulin is delivered at a specific time. However, insulin pump 520 may transmit a record indicating that a second amount of insulin was delivered at the same time. The diabetes manager 500 needs to be able to determine the source of inconsistent records and know which record the future decision will be based on in the future. The metadata tags discussed above provide a solution to these problems. As will be described below, each device has associated with it a metadata generator that generates metadata to allow the data management module 516 to manage data records received from various sources.

Exemplary insulin pump 520 is comprised of a pump data generator 524, a metadata generator 526, and a communication interface 522. The pump data generator generates records relating to the administration of insulin to the patient and records relating to the operating state of the insulin pump 520. Insulin pump 520 may also have a user interface that allows the patient to enter additional data related to the administration of insulin to the patient. Accordingly, the pump data generator 524 may also be configured to generate data records relating to patient-entered data.

The metadata generator 526 of the insulin pump generates metadata tags for data records that are transmitted to another device (e.g., the diabetes manager 500). When the pump data generator 524 generates a new pump data record, the metadata generator 526 receives a request to generate a metadata tag. The metadata tag may be a data structure with predefined metadata items. The predefined metadata items may include device, record and source identifiers as well as timestamps, last modified times and cyclic redundancy checks or checksums. The device identifier is a static value indicating the identity of the pump. The device identifier is a string of bits representing a numerical value, a character value, or a combination of both. In some embodiments, the device identifier is an unsigned 32 bit value that uniquely identifies the device from all other devices in the plurality of devices. Further, the device identifier may be a universal identifier for a particular type of pump, a pump-specific brand, unique to a particular pump, or a combination thereof.

The record identifier is a value generated by the metadata generator 526. This value should be a new value whenever the metadata generator 526 generates a record identifier. Thus, in some embodiments, the metadata generator 526 implements a counter that is incremented each time a new record is generated. For example, the first record generated by the pump data generator 524 will have record identifier 1. The following record will have record identifier 2 and so on. The record identifier may also include a character value. In some embodiments, the record identifier is an unsigned 32 bit value that the device will not regenerate for any subsequent records it generates. It is contemplated that other means of generating a record identifier may also be implemented. The device identifier and the record identifier together constitute a unique number for the record, regardless of the device that generated the data record.

The metadata generator 526 also generates a source identifier indicating whether the recording was initiated by the pump or by a person. This may be a one-bit flag, or may also indicate whether the record was generated by the patient or by a third party (e.g., a clinician).

The metadata generator 526 may also populate the metadata tag with additional metadata items, including a timestamp and the time of the last modified record. It should be appreciated that the time of the last modified record may be initially set equal to the timestamp, and another device may change the value of the time of the last modified record. It should be noted that the time may be a relative or absolute time. The metadata generator may also include a metadata entry indicating what type of record it is (e.g., an insulin pump record or an insulin pump error record).

The metadata generator 526 may also calculate a checksum value using a predetermined function. The checksum is a function of the values in the data record. The validity of the data record may later be verified by applying a predetermined function to the stored data record and comparing the result with the received checksum.

Once the metadata tag is generated, the communication interface 522 of the insulin pump 520 can transmit the pump data record and the metadata tag to a communication interface of another device, such as the communication interface 502 of the diabetes manager 500.

The PC 530 generates patient data. As described above, the PC 530 executes diabetes analysis software. The software may receive input from a patient or other device (e.g., the diabetes manager 500). Based on the various data, the PC data generator 534 will generate a PC data record.

When generating a PC data record, metadata generator 536 of PC 530 will generate a metadata tag in a manner similar to that of metadata generator 526 of insulin pump 520. The metadata generator 536 will provide metadata items for the metadata tag including a device indicator (i.e., a value indicating that the PC generated the data record), a record identifier, and a source identifier. The metadata generator 536 may implement a counter similar to the counters described above. Notably, the PC and insulin pump (or any other device) may generate metadata tags whose record identifiers have equal values, since the device identifiers in each metadata tag will be different. The metadata tag may also include a metadata entry indicating a timestamp, a field indicating a time of last modification, a record type indicator, and a checksum.

After the PC data records and corresponding metadata tags have been generated, the communication interface 532 of the PC 530 communicates the PC data records to the corresponding communication interface 504 of the diabetes manager 500.

Some devices do not have the computational resources necessary to generate metadata tags. For example, CGM 540 may lack the resources to generate a metadata tag each time CGM 540 transmits a CGM measurement. In these embodiments, the CGM 540 monitors the glucose level of the patient and transmits CGM measurements without any metadata. The CGM data generator generates a CGM data record indicating the CGM measurement or operating condition of the CGM, and the communication interface of the CGM 542 transmits the CGM data record to the corresponding communication interface 506 of the diabetes manager 500. However, the proxy metadata generator 508 residing on the diabetes manager 500 generates metadata tags corresponding to the CGM data records. The proxy metadata generator 508 generates metadata tags in the manner described above. The proxy metadata generator 508 will associate the device identifier of the CGM 540 and will implement a separate counter for generating the record identifier of the CGM data record. Since the CGM 540 does not have a user interface, all records will be classified as machine-generated. The time stamp provided to the metadata tag may be the time when the CGM data record is received. Although the lack of computational resources is cited as a reason for including the proxy metadata generator 508, the decision need not be based on the computational resources of the transmitting device.

The diabetes manager 500 also generates data records. For example, the example diabetes manager 500 includes a user interface 510 and a Blood Glucose Monitor (BGM) 516, both of which may generate data records. BGM 516 generates BG data records. The user interface 510 receives patient input for generating a patient data record. The metadata generator 504 of the diabetes manager receives instructions from the user interface 510, the BGM 516, or any other data generation component of the diabetes manager 500. The metadata generator 514 generates metadata tags with metadata items that indicate the device identifier, record identifier, and source identifier of the diabetes manager 500. If the data record originates from the user interface 510 based on input from the patient, the source identifier may indicate that the patient data record is human-generated. If the BGM 516 generates a data record based on the automated bG readings, the source identifier may indicate that the BGM data record is machine-generated. Additional metadata items may also be recorded in the metadata tag, such as record type, timestamp, time of last modification, and checksum.

The data management module 516 receives data records from various data sources and stores the data records in the data store 518 of the diabetes manager 500. One or more databases may be stored on the data store 500. The data management module 516 uses the data records and corresponding metadata tags to generate or modify entries in the database.

The example data management module 516 is also configured to resolve conflicts between two data records. To resolve the conflict, the data management module 516 complies with a set of predetermined rules for resolving data conflicts. An exemplary rule is: machine-generated records take precedence over human-generated values. For example, in the above example, the patient and insulin pump may provide two different values for the amount of insulin delivered at a particular moment in time. In this case, the data management module 516 will enter a machine-generated value in the database entry unless there is an error indication, e.g., the checksum value in the metadata does not match the checksum value calculated based on the values in the data records. Another exemplary rule is: later modifications of the record take precedence over earlier entered modifications. For example, if the patient enters meal information indicating that he has consumed 500 carbohydrates at breakfast and then later changes the value to 800, the later value is stored in the database, it is contemplated that the data management module 516 may implement other rules to maintain data consistency throughout the device system.

Although the above describes a scenario in which all data records are transmitted to the diabetes manager 500, it should be noted that data records may also be transmitted from the diabetes manager 500 to a device. For example, the diabetes manager 500 can transmit the data record to the PC 530. The PC 530 may also have a data management module that ensures that data records are consistent between the PC 520 and the diabetes manager 500.

Fig. 6 illustrates an example of the transmission of data records and corresponding metadata tags throughout the system of devices. In this example, the CGM 600 and insulin pump 602 transmit CGM data records 610 and pump records 612, respectively, to the diabetes manager 604. As shown, the CGM data record is initially transmitted without a metadata tag, while the pump record has a metadata tag 614. The diabetes manager 604 communicates the CGM data record 610 and the pump record 612 to the PC 606. The diabetes manager 604 has generated a metadata tag 616 on behalf of the CGM 600 to accompany the CGM record 610. It should be noted that the device ID and record ID of both the CGM data record 610 and the pump data record 612 are not altered when transmitted from the diabetes manager 604 to the PC 606. The diabetes manager 606 has also generated a BG data record 618 and a UI record 622, as well as corresponding metadata 620 and 624, respectively. It should be noted that the two records have the same device ID, as both records are generated by the diabetes manager 600.

As used herein, the term "module" may refer to or include a portion of: an Application Specific Integrated Circuit (ASIC); an electronic circuit; a combinational logic circuit; a Field Programmable Gate Array (FPGA); a processor (shared, dedicated, or group) that executes code; other suitable components that provide the described functionality; or a combination of some or all of the above, such as in a system on a chip. The term module may include memory (shared, dedicated, or group) that stores code executed by the processor.

As used above, the term code may include software, firmware, and/or microcode, and may refer to programs, routines, functions, classes, and/or objects. As used above, the term "shared" means: a single (shared) processor may be used to execute some or all code from multiple modules. Further, some or all code from multiple modules may be stored by a single (shared) memory. As used above, the term "group" means: a set of processors may be used to execute some or all code from a single module. In addition, a set of memories may be used to store some or all of the code from a single module.

The apparatus and methods described herein may be implemented by one or more computer programs executed by one or more processors. The computer program includes processor-executable instructions stored on a non-transitory tangible computer-readable medium. The computer program may also include stored data. Non-limiting examples of the non-transitory tangible computer readable medium are nonvolatile memory, magnetic storage, and optical storage.

Claims (17)

1. A diabetes management system having a reliable data management scheme, the system comprising:

-a plurality of devices, each device performing a different function related to treatment of diabetes of a patient and having a device identifier identifying a type of the device, wherein each device generates a data record related to a function of the device, and each device comprises a metadata generator configured to generate a metadata tag for the data record generated by the device, wherein the metadata tag comprises a device identifier of the corresponding device, a record identifier, and a source identifier indicating whether the record was initiated by a person or by the corresponding device;

-a diabetes management device in electronic communication with the plurality of devices, wherein the diabetes management device is configured to manage records received from the plurality of devices;

-wherein when a first device of the plurality of devices generates a new record to be transmitted to the diabetes management device, the metadata generator of the first device generates a new unique record identifier and generates a new metadata tag based on the new unique record identifier and the device identifier of the first device, and the first device propagates the new record and the new metadata tag to a second device.

2. The system of claim 1, wherein when the diabetes management device communicates a record that is communicated to a second device of the plurality of devices, causing a metadata tag generated by the first device to be propagated with the record from the diabetes management device to a third device.

3. The system of claim 1 or 2, wherein the diabetes management device comprises a data management module that manages data records received from the plurality of devices according to a set of predetermined rules.

4. The system of claim 3, wherein the set of predetermined rules includes the following rules: the rule prioritizes data records having a source identifier indicating that the data records are machine-generated over data records having a source identifier indicating that the data records are human-generated.

5. The system of at least one of the preceding claims, further comprising: a continuous blood glucose monitor having a corresponding device identifier, the continuous blood glucose monitor generating and transmitting continuous blood glucose data records to the diabetes management device, wherein the diabetes management device includes a proxy metadata generator that generates a metadata tag on behalf of the continuous blood glucose monitor, wherein the metadata tag includes a device identifier corresponding to a continuous blood glucose meter.

6. The system of at least one of the preceding claims, wherein the first device is one of an insulin pump and a general purpose computer executing diabetes management software.

7. The system of at least one of the preceding claims, wherein the diabetes management device has a blood glucose monitor housed therein, wherein the blood glucose monitor generates a blood glucose record and the diabetes management device includes a metadata generator that generates a metadata tag for the blood glucose record, wherein the device identifier of the metadata tag for the blood glucose record is a device identifier of the diabetes management device.

8. The system of at least one of the preceding claims, wherein a particular metadata tag comprises a checksum value determined using a predetermined function that uses the content of a particular data record at the time of creation as an input, wherein the validity of the particular data record can be verified by calculating a checksum check value using the predetermined function and the content of the particular data record.

9. The system of at least one of the preceding claims, wherein the metadata tag generated by the metadata generator of each device includes a timestamp.

10. A diabetes management system having a reliable data management scheme, the system comprising:

-a first device performing a first function related to the treatment of diabetes and a first device type identifier associated with the first device;

-a diabetes management device in communication with the first device;

wherein the first device has associated therewith:

a) a record generation module that generates a record related to the first function or to an operational status of the first device;

b) a metadata generator to generate a new metadata tag to tag the record, wherein the new metadata tag includes the first device type identifier, a record identifier that is a unique value associated with a first record, and a source identifier indicating whether the record was originated by a person or the first device;

c) a communication interface that allows the first device to communicate with a communication interface of the diabetes management device, wherein the first metadata generator generates the new metadata tag when the first device is to transmit the record to the diabetes management device, and a communication module transmits the record and the new metadata tag to the diabetes management device; and

wherein the new metadata tag is associated with the record for the duration of the record.

11. The diabetes management system of claim 10, wherein the first device is one of an insulin pump and a PC executing diabetes management software.

12. The diabetes management system of claim 10 or 11, further comprising: a continuous blood glucose monitor having a corresponding device identifier, the continuous blood glucose monitor generating and transmitting continuous blood glucose data records to the diabetes management device, wherein the diabetes management device includes a proxy metadata generator that generates a metadata tag on behalf of the continuous blood glucose monitor, wherein the metadata tag includes a device identifier corresponding to a continuous blood glucose meter.

13. The system of at least one of claims 10 to 12, wherein the diabetes management device comprises a data management module that manages data records received from the plurality of devices according to a set of predetermined rules.

14. The system of claim 13, wherein the set of predetermined rules includes the following rules: the rule prioritizes data records having a source identifier indicating that the data records are machine-generated over data records having a source identifier indicating that the data records are human-generated.

15. The system of at least one of the claims 10 to 14, wherein the diabetes management device houses a blood glucose monitor therein, wherein the blood glucose monitor generates a blood glucose record and the diabetes management device includes a metadata generator that generates a metadata tag for the blood glucose record, wherein a device identifier of the metadata tag for the blood glucose record is a device identifier of the diabetes management device.

16. The system of at least one of claims 10 to 15, wherein a particular metadata tag comprises a checksum value determined using a predetermined function that uses the content of a particular data record at the time of creation as an input, wherein the validity of the particular data record can be verified by calculating a checksum check value using the predetermined function and the content of the particular data record.

17. The system of at least one of claims 10 to 16, wherein the metadata tag generated by the metadata generator of each device includes a timestamp.