Source: https://patents.google.com/patent/US9760679B2/en
Timestamp: 2019-05-21 13:27:20
Document Index: 500617422

Matched Legal Cases: ['§119', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'application No. 61']

US9760679B2 - Data synchronization between two or more analyte detecting devices in a database - Google Patents
Data synchronization between two or more analyte detecting devices in a database Download PDF
US9760679B2
US9760679B2 US13/984,809 US201113984809A US9760679B2 US 9760679 B2 US9760679 B2 US 9760679B2 US 201113984809 A US201113984809 A US 201113984809A US 9760679 B2 US9760679 B2 US 9760679B2
US13/984,809
US20140067421A1 (en
Brittany K. Bradrick
2011-02-11 Priority to US201161442063P priority Critical
2011-12-21 Application filed by Abbott Diabetes Care Inc filed Critical Abbott Diabetes Care Inc
2011-12-21 Priority to US13/984,809 priority patent/US9760679B2/en
2011-12-21 Priority to PCT/US2011/066422 priority patent/WO2012108936A1/en
2013-11-20 Assigned to ABBOTT DIABETES CARE INC. reassignment ABBOTT DIABETES CARE INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WINKLER, TODD, GOPAL, Mani, BRADRICK, Brittany K., DUNN, TIMOTHY C., BERNSTEIN, DANIEL M., DAVIS, ERIC, HAYTER, GARY A.
2014-03-06 Publication of US20140067421A1 publication Critical patent/US20140067421A1/en
2017-09-12 Publication of US9760679B2 publication Critical patent/US9760679B2/en
Pursuant to 35 U.S.C. §119(e), this application claims priority to U.S. Provisional Patent Application No. 61/442,063 filed on Feb. 11, 2011, the disclosure of which is herein incorporated by reference in its entirety.
This application is related to U.S. Provisional Application No. 61/442,085 filed on Feb. 11, 2011; U.S. Provisional Application No. 61/486,117 filed on May 13, 2011; U.S. Provisional Application No. 61/442,092 filed on Feb. 11, 2011; U.S. Provisional Application No. 61/485,840 filed on May 13, 2011; U.S. Provisional Application No. 61/442,093 filed on Feb. 11, 2011; and U.S. Provisional Application No. 61/442,097 filed on Feb. 11, 2011, the disclosures of which are all incorporated herein by reference in their entirety and for all purposes.
The present invention relates to analyte measurement systems. More specifically, the present invention relates to a means for preserving data integrity and uniquely identifying patient data received from multiple sources.
One tool used in diabetes management is an analyte meter. An analyte meter is typically used to measure the blood glucose level of a user based on a sample of blood. The process of using an analyte meter is not complicated, and is often performed several times a day. First, the user inserts an analyte test strip into a test strip port of the meter. The user then lances her finger to obtain a small sample of blood. The blood sample is then placed onto the analyte test strip, and the meter analyzes the blood sample. The meter then typically displays a blood glucose level from the analysis.
In today's budget conscious health care world there is intense pressure to deliver improved outcomes in cost conscious ways. One way to accomplish this goal in the realm of diabetes care is to more effectively use blood glucose (BG) data and other biometric data collected from patients to make effective therapy and lifestyle suggestions. To effectively collect and analyze data, the patient must comply with prescribed BG (or other biometric) testing protocols. There is also a need for providing a means for easily collecting and communicating data.
What is needed is a means for collecting data, preserving data integrity, and uniquely identifying patient data received from multiple sources.
Presented herein is an analyte measurement system. The analyte measurement system includes one or more handheld analyte meters and/or measurement devices and a means for collecting data, preserving data integrity, and uniquely identifying patient data received from multiple sources. For example, provided herein is a means to uniquely identify patients and their data when the data is collected from one or more measurement devices. By providing a way to allow the patients to use multiple sources to collect data, the system described herein provides patients with more flexibility, which should encourage better compliance to protocols. Further, by having a way to uniquely identify patients' data without requiring a patient to only use one analyte meter, for example, data can be centralized and analysis can be done with more assurance that all of the patient's data is being considered in the analyses.
In addition, the methods discussed herein consider ease-of-use. By providing easy to use systems, patients are more likely to comply with testing protocols.
Finally, these methods also keep in mind data integrity. When multiple meters are used, the likelihood of a meter being lost or stolen increases. The systems proposed allow patients to maintain multiple meters without excessive risk to patient privacy as it relates to medical data (i.e.; HIPAA requirements). The methods guarantee that the data coming from any particular meter is from the patient the meter was assigned to, and therefore protects the patient's privacy.
FIG. 1 provides a front-side view of handheld analyte measurement device in accordance with one embodiment presented herein.
FIG. 2 is a flowchart illustrating one embodiment presented herein.
FIG. 3 is a continuation of the flowchart from FIG. 2.
FIG. 4 is a flowchart illustrating another embodiment presented herein.
FIG. 1 provides a front-side view of handheld analyte measurement device, such as an analyte meter 102, in accordance with one embodiment presented herein. In one embodiment, analyte meter 102 includes a test strip port 104, a display unit 106, and at least one control button 108. In practice, an analyte test strip (or sensor) is inserted into test strip port 104 in order to conduct an analyte test; for example, a blood glucose reading or a blood ketone reading. Meter 102 includes software (as described below) to analyze the sample placed on the test strip, and the results of the analysis are typically displayed to the user via display unit 106. The user may also use control button 108 to provide appropriate instructions to meter 102.
In one embodiment, meter 102 includes one or more diabetes management software applications. The integration of software applications with meter 102 provides an opportunity to augment traditional glucose and/or ketone readings to provide more useful information and feedback to patients and doctors. As such, meter 102, with loaded software applications, can be part of a robust therapy management system. The software applications can be factory pre-loaded, or installed by the user or health care provider after first use by the user.
Analyte meter 102 may further include one or more internal or external communication modules. The communication module(s) may be used to receive and/or transmit data and/or program instructions. The communication module(s) may also download software applications from one or more servers. In one embodiment, the communication module is used to communicate with one or more external devices; such as, for example, a central server or central database, a medication (drug) deliver device; a cellular phone; a laptop computer; a mobile device, such as a PDA, iPhone, iPad, tablet computer, etc.; a desktop computer; an analyte meter; and/or another analyte measurement system. In one embodiment, the communication module can be configured for wireless communication to an external device. Wireless communication may be provided by, for example, but not limited to, radio frequency (RF) communication (e.g., Radio-Frequency Identification (RFID), Zigbee communication protocols, WiFi, infrared, wireless Universal Serial Bus (USB), Ultra Wide Band (UWB), Bluetooth® communication protocols, and cellular communication, such as code division multiple access (CDMA) or Global System for Mobile communications (GSM).
The methods described in this disclosure depend on the collection of identifying information by a central database, server(s), or “cloud.” For the scenarios provided below, the following are assumed: 1) a centralized server or database exists that can be accessed by the user through multiple conduits (e.g., a web-based database accessible from any internet enabled PC, cell phone, tablet PC, etc.); 2) the analyte meter contains a unique identifier (e.g., serial number); and 3) the conduits used to upload data from the analyte meter to the central database are uniquely identifiable (e.g., via a MAC address or calling phone number). The following scenarios are considered below: 1) the patient has multiple analyte meters in multiple locations (e.g., at home, office, gym, etc.); 2) the patient's BG readings are sometimes taken at a hospital or clinic, where there is sanctioned use of the meters by multiple patients; 3) the patient is given multiple meters that are re-used by the clinic, to take home; 4) multiple patients share a single meter (e.g., a husband borrows wife's meter); and 5) a meter is lost or stolen and an attempt to use the meter is made by an unauthorized user.
As used herein, the term “device” is intended to include multiple analyte meters (either discreet or continuous blood glucose meters), wired- or wireless-equipped biometric measurement devices (e.g., blood pressure measurement devices), or any other medical devices. In some cases, the device may act as a data hub such that it contains not just glucose measurement data, but also other biometric data (e.g., blood pressure data, weight, pulse rate, etc.) that has been manually or automatically entered into the device or communicated to the device. The methods described herein provides a way to uniquely identify the patient regardless of which device is used and to associate the uploaded data with that patient. The following section describes the various ways in which this unique identification can be done.
1) Barcode, RFID, or Fingerprint Method.
In one embodiment, the device may include a fingerprint reader to identify the patient. In another embodiment, the device may include a barcode or other optical reader that identifies the patient via a handheld identifier tag. In another embodiment, the device may include an RFID reader that identifies the patient via a RF card/tag kept by the patient. Identifiers or RF cards/tags may be made small enough to fit on a key chain, in a wallet, or in a carrying case that contains the patient's device, lancets, and/or test strips. In one embodiment, the patient is not allowed to take an analyte reading without first making contact (physical or electrical) between the device and identifier (or taking a fingerprint reading). The identifier used at the time of the analyte reading may be attached to each said reading. Thus each reading uniquely identifies itself to the patient. As long as the patient only uses devices that require the identifier, all of their data will be uniquely identifiable and can be aggregated to a central location. Devices may be programmed to accept only one single identifier (or fingerprint), to enforce no sharing of the device, or multiple identifiers to allow sanctioned re-use of devices. In the case where only a single identifier is allowed, the device will have to be paired with the identifier on first use.
2) Association of Devices and Conduit Devices with a Patient.
The first time a patient uploads data, either directly to a PC or cellphone, or to the internet via a PC or cellphone conduit, the identifiers (MAC addresses, serial numbers, etc.) of the device and data conduit are collected. At the time a patient is registered, a Patient Record is established in the database system and the Patient Record includes “Secondary ID information” (that may be used to confirm a patient's identity without communicating their full name). This Secondary ID Information includes information such as SSN, DOB, zip code, mother's maiden name, etc. A patient may also be assigned a unique identifier (and optionally a password) at the time of registration. The next time the aggregating database sees the same analyte device or conduit it may assume that it is the same patient “returning” with more data (or may provide a verification prompt). When the aggregating system does not recognize the device and/or conduit devices, it can ask if the patient is a returning patient (or simply ask the patient to identify themselves using Secondary Information (to minimize patient privacy issues). If the patient is a returning patient, they could be asked for their unique ID and password, and/or other Secondary ID Information or identifiers to confirm their identity. An unrecognized patient would have to be registered in the system before they could access the system. Once the patient identity has been confirmed, the new device and/or data conduit identifiers can be added to their record. This scenario is illustrated in the flowchart in FIGS. 2 and 3.
Another aspect of this invention is that a unique patient ID, generated by the central database, can be stored in the device software and in communication software in the conduit as part of the registration process—this communication software can be loaded into the conduit by the device the first time it is attached or loaded from the web or other communication network at an address specified by the device. This way the unique patient ID format can be controlled by the central database and uniqueness can be guaranteed. When the data is uploaded, the unique patient ID is included twice in the upload stream, by the device software and by software in the conduit (communication driver), and extracted by the central database for data association. When the unique patient ID from the device is not recognized, or that from the conduit are not recognized, the new device or conduit proceeds to a registration protocol, as described above. Other means to perform this function can be contemplated, such as having the conduit software check the device for matching patient IDs and sending a flag to the central database if they do not match.
For multiple patients using the same conduit, the communication driver would need to maintain multiple unique patient IDs and some additional patient information (such as first name), including security information such as a password, to deal with the situation where new devices are introduced. When a new device is detected and multiple unique patient IDs are stored in the communication driver, it would need to request the user to select from the list patient information associated with the stored unique patient IDs.
Process flows are provided below—these are in terms of a device attached via wire to a PC connected to the internet; however, the general method is similar for other connection methods such as 3G cellular connection, or pager network based communication.
An example registration process flow is as follows: a) register unique patient ID on website—patient provides additional security information; b) Connect new device to new PC—device installs communication driver on PC (communication driver has instructions to upload data from device to web address automatically when device is attached); and c) upon completion of the registration process, website downloads unique patient ID to device and communication driver.
An example upload process flow is as follows: a) attach device to PC, upload begins automatically as driven by communication driver; b) device and communication driver both place unique patient ID in data stream; and c) central database recognizes and matches both unique patient IDs and stores data associated with this ID.
An example upload process flow where a new device is introduced is as follows: a) attach new device to PC with existing communication driver; b) device places a null character in the unique patient ID field of the data stream; c) the communication driver detects the mismatch of the unique patient ID with any of its stored IDs and requests the user to identify the unique patient ID based on associated patient information and/or security information; d) upon proper confirmation, the communication driver downloads the unique patient ID to the new device and includes the unique patient ID in the device field of the data stream sent to the central database; and e) central database recognizes and matches both unique patient IDs and stores data associated with this ID. For configurations where the upload conduit may not have a user interface, the security confirmation could be provided through the device UI.
An example upload process flow where a new PC is introduced is as follows: a) attach device to a new PC—device installs communication driver on PC (communication driver has instructions to upload data from device to web address automatically when device is attached); b) device loads unique patient ID into communication driver; c) device and communication driver both place unique patient ID in data stream; and d) central database recognizes and matches both unique patient IDs and stores data associated with this ID.
3) Shared Device in the Context Where Patient May Have Multiple Analyte Devices.
This scenario expands on the case above. This scenario adds in the case where a patient uses a device that other patients may also use between upload operations (i.e., the analyte data in the device may come from more than one patient with each upload cycle). This scenario could occur in a home setting for example where a device may be shared by several people. In this case, it is necessary for the system to have positive knowledge of the source of each analyte measurement. The flowchart in FIG. 4 provides a method in accordance with such an embodiment.
4) Patient Information Entered into the Device.
This scenario envisions the hospital setting where devices may be used for multiple patients sequentially, but not concurrently. Whenever a new patient will be using a device, information identifying the patient can be entered into the device and associated with the data when it is sent to the aggregating device. Patient data need only be entered once until the device is given to a new patient.
5) Shared Device with Self-Modifying Serial Number.
This scenario envisions a device given to a patient in a clinic in order to take home. The device may not be as sophisticated as a hospital device and therefore there may not be a way for the patient to enter any identifying information. Whenever the device is given to a new patient, a monotonically increasing identifier is added to the devices log. This can be made to happen at the clinic by having a function built into the device for initializing a new patient. This function increments the identifier and puts it in the log. Subsequently each record in the log is identified by the device's serial number, monotonically increasing identifier, and record ID. The monotonically increasing identifier can be said to be part of the device's serial number, so each time the aggregating database sees a new device serial number, it knows to ask if this is a new patient. It is assumed that the aggregating database software is running on a platform that can more easily handle user input, such as a cell phone, tablet, or PC.
6) Lost or Stolen Device.
The analyte device may be lost or stolen. In order to guarantee data integrity, it is important that data entered by an unauthorized user not get assigned to the patient to whom the device was assigned, nor can the unauthorized user view the original patient's data. When the unauthorized user tries to upload the data to the central database, the database will detect that the conduit (PC, cellphone, tablet, etc.) is different than what was used by that patient before. The database software determines this because it has linked device ID, conduit, and patient data in its database. The database software will issue a pre-arranged challenge question to the user (e.g., What is your mother's maiden name?). If the challenge is answered successfully, the database accepts the data from the device, otherwise the data from that device is rejected and viewing of previous data is blocked. Furthermore, the system can be configured to only allow uploading when the device is connected to a limited set of data conduits.
Another aspect of this invention provides for synchronization of data between devices. For instance, if a patient utilized two different devices, it would be useful to have the data from one device additionally stored on the other. As such, when the patient examines their data on one device, they may get a complete picture of their analyte measurements. Another example is a patient who has a device and a cellphone that accepts manual analyte reading entries (presumably from a separate device). The two devices could synchronize using well established synchronization techniques (common with PDAs). They could synchronize periodically over a wireless channel such as Bluetooth. They could synchronize when connected via a wired channel. A preferred method is that they could synchronize during upload of data to a central database. The central database would be aware of multiple devices of compatible data-types and would perform a difference of its stored data (after upload) from predefined period of time and download the difference to the device to be stored. Variations of this synchronization scheme can be contemplated.
Another aspect of this invention deals with the possibility that identical data may come through different conduits—such as a device that can upload both through a PC and through a cellular channel. To mitigate “double counting” of readings, additional data of a particular data-type would be ignored (that is, not stored) by the central database if data of that data-type already existed with the exact same timestamp. Alternatively, the data in this situation may be stored but flagged as duplicate. As such, data processing (or preprocessing) routines would need to take the flagged duplicate data into account as needed.
Though this invention description may focus on blood glucose devices, the techniques described apply to all devices that may be used to upload patient analyte data or other patient data to a central database, such as cell phones, tablet PC's, a dedicated communication router (e.g., via Bluetooth from the device and via cellular to the internet), etc., where the data may be aggregated with these devices from manual input, and/or wired or wireless communication from a measurement device or other intermediate storage devices. This invention can also apply to any device used to measure patient data, such as continuous glucose (CG) devices, blood pressure (BP) measurement devices, height-scales, and the like.
In another embodiment, there is provided mechanisms to enforce system configuration requirements. Electronic system update configuration requirements can be enforced using key codes that are incorporated in the communication messages sent between system components. Key codes are primarily available for access by a PC (or any other electronic device). The codes may be used as a convenient book keeping tool to manage which version of the device may function with a specific version of a PC application using a particular serial command. For instance, a serial command may include a two byte key code where in the original system the PC application will issue a value of code=00 when it sends the command to a device. The original version of the device can be designed with a serial command function that will accept commands with code with a range of 00 to 0F. In this way, if another version of the device has an updated serial command that allows a code range of 00 to 1F, then the original PC application version will still work with this updated device, along with newer versions of the PC application that have codes in this range (in regards specifically to this particular serial command). If an updated PC application is not intended to work with the first device version but only the second device version, then the code for the PC application should be set between 10 to 1F. If the updated device is not intended to work with the original PC application, then the code for the device could be set to 10 to 1F.
Another application for the key code mechanism has a key code included in the pairing message exchange between the device and a drug delivery device, in the same fashion as described above for device serial commands access primarily by PC applications. Here the unique feature is that the key code only needs to be included in a pairing message in order to enforce all communication restrictions between versions of device and the drug delivery device, since they may not communicate (other than for pairing attempts) unless they are paired. This allows full control over which device versions will work with which drug delivery device versions.
The same effect could be used by just changing the command name or format. For instance, a device could be designed to accept serial commands with names $acona, $aconb, and $aconx, and the PC application could issue $aconb. Also, the device could be designed to accept a serial command with three parameters and with five parameters. However, the key code technique is much more convenient and easier to manage.
In some embodiments, the analyte measurement systems disclosed herein may be included in and/or integrated with, a medication delivery device and/or system, e.g., an insulin pump module, such as an insulin pump or controller module thereof, or insulin injection pen. In some embodiments the analyte measurement system is physically integrated into a medication delivery device. In other embodiments, an analyte measurement system as described herein may be configured to communicate with a medication delivery device or another component of a medication delivery system. Additional information regarding medication delivery devices and/or systems, such as, for example, integrated systems, is provided in U.S. Patent Application Publication No. US2006/0224141, published on Oct. 5, 2006, entitled “Method and System for Providing Integrated Medication Infusion and Analyte Monitoring System”, and U.S. Patent Application Publication No. US2004/0254434, published on Dec. 16, 2004, entitled “Glucose Measuring Module and Insulin Pump Combination,” the disclosure of each of which is incorporated by reference herein in its entirety. Medication delivery devices which may be provided with analyte measurement system as described herein include, e.g., a needle, syringe, pump, catheter, inhaler, transdermal patch, or combination thereof. In some embodiments, the medication delivery device or system may be in the form of a drug delivery injection pen such as a pen-type injection device incorporated within the housing of an analyte measurement system. Additional information is provided in U.S. Pat. Nos. 5,536,249 and 5,925,021, the disclosures of each of which are incorporated by reference herein in their entirety.
The embodiments presented herein provide further advantages such as: the ability to upgrade strip port modules as new test strip technologies evolve; the ability to clean or sterilize a strip port module; and the ability to allow users to replace strip port modules without returning the entire measurement system to the manufacture.
Embodiments of the invention relate to components of a continuous monitoring system that may be replaceable. In one embodiment, the interface between the sensor and the transmitter may become contaminated. The transmitter or sensor control unit, for example, may have an interface with the sensor that has been molded to form a barrier between the transmitter's contacts and circuitry internal to the transmitter. This allows the transmitter's contacts to be washed without damaging the transmitter's circuitry. Alternatively, the contacts may be included in a replaceable port that can be replaced as needed. Similarly, the interface on the sensor may be molded to form a barrier to contamination or be replaceable.
Analyte test strips for use with the present devices can be of any kind, size, or shape known to those skilled in the art; for example, FREESTYLE® and FREESTYLE LITE™ test strips, as well as PRECISION™ test strips sold by ABBOTT DIABETES CARE Inc. In addition to the embodiments specifically disclosed herein, the devices of the present disclosure can be configured to work with a wide variety of analyte test strips, e.g., those disclosed in U.S. patent application Ser. No. 11/461,725, filed Aug. 1, 2006; U.S. Patent Application Publication No. 2007/0095661; U.S. Patent Application Publication No. 2006/0091006; U.S. Patent Application Publication No. 2006/0025662; U.S. Patent Application Publication No. 2008/0267823; U.S. Patent Application Publication No. 2007/0108048; U.S. Patent Application Publication No. 2008/0102441; U.S. Patent Application Publication No. 2008/0066305; U.S. Patent Application Publication No. 2007/0199818; U.S. Patent Application Publication No. 2008/0148873; U.S. Patent Application Publication No. 2007/0068807; U.S. patent application Ser. No. 12/102,374, filed Apr. 14, 2008, and U.S. Patent Application Publication No. 2009/0095625; U.S. Pat. No. 6,616,819; U.S. Pat. No. 6,143,164; U.S. Pat. No. 6,592,745; U.S. Pat. No. 6,071,391 and U.S. Pat. No. 6,893,545; the disclosures of each of which are incorporated by reference herein in their entirety.
In one embodiment, the analyte measurement system may be configured to measure the blood glucose concentration of a patient and include instructions for a long-acting insulin dosage calculation function. Periodic injection or administration of long-acting insulin may be used to maintain a baseline blood glucose concentration in a patient with Type-1 or Type-2 diabetes. In one aspect, the long-acting medication dosage calculation function may include an algorithm or routine based on the current blood glucose concentration of a diabetic patient, to compare the current measured blood glucose concentration value to a predetermined threshold or an individually tailored threshold as determined by a doctor or other treating professional to determine the appropriate dosage level for maintaining the baseline glucose level. In one embodiment, the long-acting insulin dosage calculation function may be based upon LANTUS® insulin, available from Sanofi-Aventis, also known as insulin glargine. LANTUS® is a long-acting insulin that has up to a 24 hour duration of action. Further information on LANTUS® insulin is available at the website located by placing “www” immediately in front of “.lantus.com”. Other types of long-acting insulin include Levemir® insulin available from NovoNordisk (further information is available at the website located by placing “www” immediately in front of “.levemir-us.com”. Examples of such embodiments are described in US Published Patent Application No. US2010/01981142, the disclosure of which is incorporated herein by reference in its entirety.
Exemplary analyte monitoring systems that may be utilized in connection with the disclosed analyte measurement system include those described in U.S. Pat. No. 7,041,468; U.S. Pat. No. 5,356,786; U.S. Pat. No. 6,175,752; U.S. Pat. No. 6,560,471; U.S. Pat. No. 5,262,035; U.S. Pat. No. 6,881,551; U.S. Pat. No. 6,121,009; U.S. Pat. No. 7,167,818; U.S. Pat. No. 6,270,455; U.S. Pat. No. 6,161,095; U.S. Pat. No. 5,918,603; U.S. Pat. No. 6,144,837; U.S. Pat. No. 5,601,435; U.S. Pat. No. 5,822,715; U.S. Pat. No. 5,899,855; U.S. Pat. No. 6,071,391; U.S. Pat. No. 6,120,676; U.S. Pat. No. 6,143,164; U.S. Pat. No. 6,299,757; U.S. Pat. No. 6,338,790; U.S. Pat. No. 6,377,894; U.S. Pat. No. 6,600,997; U.S. Pat. No. 6,773,671; U.S. Pat. No. 6,514,460; U.S. Pat. No. 6,592,745; U.S. Pat. No. 5,628,890; U.S. Pat. No. 5,820,551; U.S. Pat. No. 6,736,957; U.S. Pat. No. 4,545,382; U.S. Pat. No. 4,711,245; U.S. Pat. No. 5,509,410; U.S. Pat. No. 6,540,891; U.S. Pat. No. 6,730,200; U.S. Pat. No. 6,764,581; U.S. Pat. No. 6,299,757; U.S. Pat. No. 6,461,496; U.S. Pat. No. 6,503,381; U.S. Pat. No. 6,591,125; U.S. Pat. No. 6,616,819; U.S. Pat. No. 6,618,934; U.S. Pat. No. 6,676,816; U.S. Pat. No. 6,749,740; U.S. Pat. No. 6,893,545; U.S. Pat. No. 6,942,518; U.S. Pat. No. 6,514,718; U.S. Pat. No. 5,264,014; U.S. Pat. No. 5,262,305; U.S. Pat. No. 5,320,715; U.S. Pat. No. 5,593,852; U.S. Pat. No. 6,746,582; U.S. Pat. No. 6,284,478; U.S. Pat. No. 7,299,082; U.S. Patent Application No. 61/149,639, entitled “Compact On-Body Physiological Monitoring Device and Methods Thereof”, U.S. patent application Ser. No. 11/461,725, filed Aug. 1, 2006, entitled “Analyte Sensors and Methods”; U.S. patent application Ser. No. 12/495,709, filed Jun. 30, 2009, entitled “Extruded Electrode Structures and Methods of Using Same”; U.S. Patent Application Publication No. US2004/0186365; U.S. Patent Application Publication No. 2007/0095661; U.S. Patent Application Publication No. 2006/0091006; U.S. Patent Application Publication No. 2006/0025662; U.S. Patent Application Publication No. 2008/0267823; U.S. Patent Application Publication No. 2007/0108048; U.S. Patent Application Publication No. 2008/0102441; U.S. Patent Application Publication No. 2008/0066305; U.S. Patent Application Publication No. 2007/0199818; U.S. Patent Application Publication No. 2008/0148873; U.S. Patent Application Publication No. 2007/0068807; US patent Application Publication No. 2010/0198034; and U.S. provisional application No. 61/149,639 titled “Compact On-Body Physiological Monitoring Device and Methods Thereof”, the disclosures of each of which are incorporated herein by reference in their entirety.
In one embodiment, the graphical user interface includes a menu which in turn includes a plurality of selectable menu items. As a user navigates through the menu, e.g., by highlighting or scrolling through individual menu items, a menu item that is either unreadable or incomprehensible to the user could cause the user to pause over a menu item to be selected. In one embodiment, a choice can be presented to the user, e.g., using a dedicated physical button on an input unit, or a soft key on the menu, that offers further explanation of the item to be selected without actually selecting the item. For example, the graphical user interface can be configured such that after a pre-determined period of time a soft key offers an explanation of the menu item to be selected, e.g., by displaying a soft key with the word “MORE”, “ADDITIONAL INFORMATION”, “EXPAND”, “MAGNIFY”, “HELP” or a variation thereof displayed thereon.
A variety of analytes can be detected and quantified using the disclosed analyte measurement system. Analytes that may be determined include, for example, acetyl choline, amylase, bilirubin, cholesterol, chorionic gonadotropin, creatine kinase (e.g., CK-MB), creatine, DNA, fructosamine, glucose, glutamine, growth hormones, hormones, ketones (e.g., ketone bodies), lactate, oxygen, peroxide, prostate-specific antigen, prothrombin, RNA, thyroid stimulating hormone, and troponin. The concentration of drugs, such as, for example, antibiotics (e.g., gentamicin, vancomycin, and the like), digitoxin, digoxin, drugs of abuse, theophylline, and warfarin, may also be determined. Assays suitable for determining the concentration of DNA and/or RNA are disclosed in U.S. Pat. No. 6,281,006 and U.S. Pat. No. 6,638,716, the disclosures of each of which are incorporated by reference herein in their entirety.
Various terms are described to facilitate an understanding of the invention. It will be understood that a corresponding description of these various terms applies to corresponding linguistic or grammatical variations or forms of these various terms. It will also be understood that the invention is not limited to the terminology used herein, or the descriptions thereof, for the description of particular embodiments. Merely by way of example, the invention is not limited to particular analytes, bodily or tissue fluids, blood or capillary blood, or sensor constructs or usages, unless implicitly or explicitly understood or stated otherwise, as such may vary.
The detailed description of the figures refers to the accompanying drawings that illustrate an exemplary embodiment of an analyte measurement system. Other embodiments are possible. Modifications may be made to the embodiment described herein without departing from the spirit and scope of the present invention. Therefore, the following detailed description is not meant to be limiting.
Certain embodiments presented herein relate to electrical interfaces in measurement devices. Measurement devices often have electrical interfaces that allow them to electrically connect with another device or apparatus and perform an analysis of an analyte. A device that measures blood glucose levels, for example, includes electrical interfaces that allow the device to measure the blood glucose level from a small blood sample.
1. A diabetes management method, comprising:
registering a patient to a diabetes management system by registering a unique patient ID on a website, wherein the patient provides security information;
connecting an analyte measurement device to a personal computer, wherein the analyte measurement device installs a communication driver on the personal computer, and wherein the communication driver has instructions to automatically upload data from the analyte measurement device to the website when the analyte measurement device is attached to the personal computer; and
upon completion of the registration process, the website downloading the unique patient ID to the analyte measurement device and the communication driver,
wherein the instructions to automatically upload data from the analyte measurement device to the website comprises:
placing the unique patient ID in a data stream to be transmitted to a central database, the central database configured to aggregate data from multiple analyte measurement devices according to a stored patient ID;
recognizing and matching, by the central database, the received unique patient ID with the stored patient ID;
associating, by the central database, the uploaded data with the stored patient ID; and
storing the uploaded data in the central database.
2. A diabetes management method, comprising:
attaching a first analyte measurement device to a personal computer with a communication driver;
the first analyte measurement device placing a null character in a unique patient ID field of a data stream;
the communication driver detecting a mismatch of the null character in the unique patient ID field with any of its stored IDs;
the communication driver requesting the user to identify a unique patient ID based on associated patient information or security information;
upon proper confirmation, the communication driver downloading the unique patient ID to the first analyte measurement device and including the unique patient ID in the device field of the data stream sent to a central database, the central database configured to aggregate data from multiple analyte measurement devices according to a stored patient ID; and
the central database recognizing and matching the received unique patient ID with the stored patient ID; and
the central database storing data associated with the unique patient ID.
performing, by the central database, a differential comparison of the received data associated with the unique patient ID from the first analyte measurement device with stored data associated with the unique patient ID received from a second analyte measuring device; and
downloading the differential data to the first analyte measurement device.
4. The method of claim 2, further comprising calculating an insulin dosage based on the stored data associated with the unique patient ID and communicating instructions to a medication delivery device to deliver the calculated insulin dosage.
US13/984,809 2011-02-11 2011-12-21 Data synchronization between two or more analyte detecting devices in a database Active 2033-04-25 US9760679B2 (en)
US201161442063P true 2011-02-11 2011-02-11
US13/984,809 US9760679B2 (en) 2011-02-11 2011-12-21 Data synchronization between two or more analyte detecting devices in a database
PCT/US2011/066422 WO2012108936A1 (en) 2011-02-11 2011-12-21 Data synchronization between two or more analyte detecting devices in a database
US20140067421A1 US20140067421A1 (en) 2014-03-06
US9760679B2 true US9760679B2 (en) 2017-09-12
ID=46638885
US13/984,809 Active 2033-04-25 US9760679B2 (en) 2011-02-11 2011-12-21 Data synchronization between two or more analyte detecting devices in a database
US15/684,456 Pending US20170351817A1 (en) 2011-02-11 2017-08-23 Data synchronization between two or more analyte detecting devices in a database
US (2) US9760679B2 (en)
WO (1) WO2012108936A1 (en)
WO2014024107A2 (en) * 2012-08-06 2014-02-13 Koninklijke Philips N.V. Method and apparatus for the real time annotation of a medical treatment event
US20060040402A1 (en) 2003-08-01 2006-02-23 Brauker James H System and methods for processing analyte sensor data
US20090253970A1 (en) 2008-04-04 2009-10-08 Eran Bashan System for optimizing a patient's insulin dosage regimen
US20100222648A1 (en) 2006-03-24 2010-09-02 Glucotel Scientific Inc. Diabetes smartphone
US20100312577A1 (en) 2004-06-04 2010-12-09 Abbott Diabetes Care Inc. Diabetes Care Host-Client Architecture and Data Management System
US20100313105A1 (en) 2009-06-04 2010-12-09 Abbott Diabetes Care Inc. Method and System for Updating a Medical Device
US20110015511A1 (en) 2008-12-23 2011-01-20 Roche Diagnostics Operations, Inc. Systems and methods for optimizing insulin dosage
US20110119080A1 (en) 2009-11-19 2011-05-19 Abbott Diabetes Care Inc. Method and system for analyte data transmission and report generation
WO2012108939A1 (en) 2011-02-11 2012-08-16 Abbott Diabetes Care Inc. Feedback from cloud or hcp to payer or patient via meter or cell phone
WO2012108940A1 (en) 2011-02-11 2012-08-16 Abbott Diabetes Care Inc. Analytics and data mining in cloud following upload of analyte data via gsm or cdm
2011-12-21 WO PCT/US2011/066422 patent/WO2012108936A1/en active Application Filing
2011-12-21 US US13/984,809 patent/US9760679B2/en active Active
2017-08-23 US US15/684,456 patent/US20170351817A1/en active Pending
US20110125530A1 (en) 2001-04-02 2011-05-26 Abbott Diabetes Care Inc. Central server system for collecting patient health condition management data
Barker, "A Practical Introduction to the Bootstrap Using the SAS System," SAS Conference Proceedings, Paper PK02, 17 pages (2005).
Benton and Krishnamoorthy, "Performance of the Parametric Bootstrap Method in Small Sample Interval Estimates," Adv & Appl in Stat 2(3):269-285 (2002).
Nathan et al., "Translating the A1C Assay Into Estimated Average Glucose Values" Diabetes Care 31(8):1473-1478 (2008).
The Diabetes Control and Complications Trial Research Group, "The Effect of Intensive Treatment of Diabetes on Development and Progression of Long-Term Complications in Insulin-Dependent Diabetes Mellitus" N Engl J Med 329(14):977-986 (1993).
US20140067421A1 (en) 2014-03-06
US20170351817A1 (en) 2017-12-07
WO2012108936A1 (en) 2012-08-16
EP2644088B1 (en) 2017-01-18 Analyte testing method and device for diabetes management
CN103619255B (en) 2016-11-02 Devices, systems and methods associated with the analyte monitoring device thereof and a binding means
CN101610718B (en) 2013-10-02 Device and method for automatic data acquisition and/or detection
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BERNSTEIN, DANIEL M.;HAYTER, GARY A.;DUNN, TIMOTHY C.;AND OTHERS;SIGNING DATES FROM 20130828 TO 20131113;REEL/FRAME:031642/0549