U.S. patent application number 16/209302 was filed with the patent office on 2019-04-04 for architecture for field upgrade of a health monitoring system.
The applicant listed for this patent is ASCENSIA DIABETES CARE HOLDINGS AG. Invention is credited to Steven Charlton, Jun Chen, Lin Chen, Qiang Fu, Igor Gofman, Steven B. Harris, Paul L. Inman, Gary J. Johnson, Qiong Li, Harris Lieber, Derek Lok, Tony Nguyen, Paul M. Ripley, Gregory Stefkovic, Hoi-Cheong Steve Sun.
Application Number | 20190103176 16/209302 |
Document ID | / |
Family ID | 39711897 |
Filed Date | 2019-04-04 |
![](/patent/app/20190103176/US20190103176A1-20190404-D00000.png)
![](/patent/app/20190103176/US20190103176A1-20190404-D00001.png)
![](/patent/app/20190103176/US20190103176A1-20190404-D00002.png)
![](/patent/app/20190103176/US20190103176A1-20190404-D00003.png)
![](/patent/app/20190103176/US20190103176A1-20190404-D00004.png)
![](/patent/app/20190103176/US20190103176A1-20190404-D00005.png)
![](/patent/app/20190103176/US20190103176A1-20190404-D00006.png)
![](/patent/app/20190103176/US20190103176A1-20190404-D00007.png)
![](/patent/app/20190103176/US20190103176A1-20190404-D00008.png)
![](/patent/app/20190103176/US20190103176A1-20190404-D00009.png)
![](/patent/app/20190103176/US20190103176A1-20190404-D00010.png)
View All Diagrams
United States Patent
Application |
20190103176 |
Kind Code |
A1 |
Charlton; Steven ; et
al. |
April 4, 2019 |
ARCHITECTURE FOR FIELD UPGRADE OF A HEALTH MONITORING SYSTEM
Abstract
An architecture allows individual system components to be
developed and tested individually, i.e., as distinct modules, and
to be subsequently combined through standardized electrical and
communication interfaces. Any combination of these modules can be
implemented to form different products that provide any number of
functions, such as an integrated system for monitoring a health
condition and/or delivering a medication. The architecture also
provides an approach for dynamically updating the product and
offering its users the latest generation of technology even after
the users have already purchased the product. In particular, the
embodiments employ the communication interfaces to also provide
connection to a remote network that can update or upgrade the
product's software when the product is out in the field.
Inventors: |
Charlton; Steven; (Osceola,
IN) ; Chen; Jun; (Warren, NJ) ; Chen; Lin;
(Hopewell Junction, NY) ; Fu; Qiang; (Briarcliff
Manor, NY) ; Gofman; Igor; (Croton-on-Hudson, NY)
; Harris; Steven B.; (Briarcliff Manor, NY) ;
Johnson; Gary J.; (Lagrangeville, NY) ; Inman; Paul
L.; (Nyack, NY) ; Li; Qiong; (Tappan, NY)
; Lieber; Harris; (White Plains, NY) ; Lok;
Derek; (Mohegan Lake, NY) ; Nguyen; Tony;
(Hopkinton, MA) ; Ripley; Paul M.; (Nanuet,
NY) ; Stefkovic; Gregory; (Mahopac, NY) ; Sun;
Hoi-Cheong Steve; (Mount Kisco, NY) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
ASCENSIA DIABETES CARE HOLDINGS AG |
Basel |
|
CH |
|
|
Family ID: |
39711897 |
Appl. No.: |
16/209302 |
Filed: |
December 4, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15270780 |
Sep 20, 2016 |
10176888 |
|
|
16209302 |
|
|
|
|
14607631 |
Jan 28, 2015 |
9471098 |
|
|
15270780 |
|
|
|
|
12129570 |
May 29, 2008 |
8978026 |
|
|
14607631 |
|
|
|
|
60932286 |
May 30, 2007 |
|
|
|
61012721 |
Dec 10, 2007 |
|
|
|
61012718 |
Dec 10, 2007 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G16H 20/17 20180101;
G06Q 30/02 20130101; G06F 8/65 20130101; H04L 69/329 20130101; G16H
10/60 20180101; G16H 40/63 20180101; H04L 29/06 20130101; G06F 1/16
20130101; A61B 5/14532 20130101; G06Q 50/24 20130101; G06F 8/71
20130101; G16H 40/40 20180101; G06Q 50/22 20130101; G06F 1/266
20130101; G06F 16/22 20190101; G06F 13/4081 20130101; G06F 1/1605
20130101; G06F 13/385 20130101; G06F 16/182 20190101; G06F 8/61
20130101; H04L 29/08072 20130101 |
International
Class: |
G16H 10/60 20180101
G16H010/60; G06F 16/22 20190101 G06F016/22; G06F 8/71 20180101
G06F008/71; G06F 1/16 20060101 G06F001/16; G06F 13/38 20060101
G06F013/38; G06F 1/26 20060101 G06F001/26; G06F 8/65 20180101
G06F008/65; G16H 40/63 20180101 G16H040/63; G16H 40/40 20180101
G16H040/40; A61B 5/145 20060101 A61B005/145; G06F 13/40 20060101
G06F013/40 |
Claims
1-17. (canceled)
18. A system for managing healthcare data for a user, comprising: a
first module circuit providing a first function, the first module
circuit being a blood glucose meter configured to generate one or
more measurements of a blood glucose concentration of the user, the
blood glucose meter including: a sensor-receiving module disposed
within a housing configured to receive a test sensor therein; a
reaction-detection system disposed within the housing, the
reaction-detection system being configured to be coupled with the
test sensor received within the housing to detect a reaction caused
by a blood sample being received by the test sensor; and at least
one processor that executes program instructions to determine a
glucose concentration of the blood sample based at least in part on
the detected reaction; a second module circuit providing a second
function, the second module circuit being a global positioning
system (GPS) unit configured to generate GPS data associated with
each of the one or more measurements; and a central circuit
controlling the first module circuit and the second module circuit,
the central circuit being configured allow the first module circuit
to communicate with the second module circuit.
19. The system of claim 18, wherein the second module circuit is
configured to generate location data indicative of a location of
the user.
20. The system of claim 19, wherein the second module circuit is
configured to analyze the location data to determine movement of
the user.
21. The system of claim 20, wherein the determined movement of the
user includes exercise of the user.
22. The system of claim 20, wherein the determined movement of the
user includes a distance traveled by the user and a speed of the
user.
23. The system of claim 19, wherein the second module circuit
periodically generates the location data once per time period.
24. The system of claim 23, wherein the time period is about 150
seconds.
25. The system of claim 18, wherein the second module circuit is
configured to generate a plurality of sets of GPS data and
correlate each set of GPS data with a respective one of the one or
more measurements.
26. The system of claim 25, wherein each set of GPS data includes
location data associated with the respective measurement and a
timestamp associated with the respective one measurement.
27. The system of claim 26, wherein the location data associated
with the respective one measurement includes location data for a
first time period occurring prior to the respective one
measurement.
28. The system of claim 27, wherein the location data associated
with the respective one measurement includes location data for a
second time period occurring after the respective one
measurement.
29. The system of claim 26, wherein the first module circuit is
configured to identify a first set of measurements of the one or
more measurements falling within an acceptable range, and a second
set of measurements of the one or more measurements generated in
accordance with a predefined schedule.
30. The system of claim 29, wherein the first module circuit is
configured to analyze the location data and the time stamp
correlated with each of the measurements in the first set of
measurements to identify activities of the user related to the
measurements falling within the acceptable range.
31. The system of claim 29, wherein the first module circuit is
configured to analyze the location data and the time stamp
correlated with each of the measurements in the second set of
measurements to identify activities of the user related to the
measurements generated in accordance with the predefined
schedule.
32. The system of claim 25, wherein the first module circuit is
configured to analyze the sets of GPS data to identify activities
of the user associated with desirable measurements of the one or
more measurements.
33. The system of claim 32, wherein the desirable measurements
include measurements falling within an acceptable range,
measurements generated in accordance with a predefined schedule, or
both.
34. The system of claim 32, wherein the first circuit is configured
to plan future activities for the user based on the identified
activities associated with the desirable measurements.
35. The system of claim 25, wherein the first module circuit is
configured to analyze the sets of GPS data to automatically record
exercise data associated with each of the one or more
measurements.
36. The system of claim 25, wherein the first module circuit is
configured to record data related to a diet of the user and a
medication regimen of the user.
37. The system of claim 36, wherein the first module circuit is
configured to create a schedule for obtaining future measurements
of the blood glucose concentration of the user based on at least
(i) the plurality of sets of GPS data and (ii) the data related to
the diet of the user and the medication regimen of the user.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional
Application No. 60/932,286, filed May 30, 2007, U.S. Provisional
Application No. 61/012,721, filed Dec. 10, 2007, and U.S.
Provisional No. 61/012,718, filed Dec. 10, 2007, the contents of
which are incorporated entirely herein by reference.
FIELD OF THE INVENTION
[0002] The present invention relates generally to a method and
system for developing healthcare devices. More specifically, the
method and system of the present invention provides an architecture
that allows any combination of modules with different functions to
be easily assembled to form an integrated system for monitoring a
health condition and/or delivering a medication. In addition, the
method and system provides an architecture that allows the modules
to be updated dynamically during operation in the field.
BACKGROUND OF THE INVENTION
[0003] The quantitative determination of analytes in body fluids is
of great importance in the diagnoses and maintenance of certain
physiological conditions. For example, individuals with diabetes
frequently check the glucose level in their bodily fluids. The
results of such tests can be used to regulate the glucose intake in
their diets and/or to determine whether insulin or other medication
needs to be administered.
[0004] Diagnostic systems, such as blood-glucose systems, may
employ a meter or instrument to calculate the glucose value in a
blood sample from an individual. Such instruments operate by
measuring an output, such as current or color, from a reaction with
the glucose in the sample. The test results typically are displayed
and stored by the meter. Basic systems allow the user to access the
test results directly from the meter via a keypad or other
interactive component.
[0005] Other diagnostic systems, however, provide more advanced
functionality to allow a user to process and manage test results.
For example, some systems allow a user to load test results from a
blood-glucose meter onto a processing device, such as a
conventional desktop personal computer (PC), and to process and
display the results with a data-management application. However,
using the processing power of PC technology to organize results
from a blood-glucose meter is just one example of how diagnostic
systems provide more functionality by incorporating different
technologies into a diagnostic process.
[0006] Although integrating different technologies and functions
may yield highly sophisticated and extremely useful diagnostic
systems, the introduction of such systems into the marketplace is
slowed by current approaches to product design and development in
the industry. For example, current approaches to the design of
multi-function products employ complicated system architectures
that interconnect the variety of functional elements via distinct
and non-standard techniques. Accordingly, a functional element must
be developed with the specific final product and the other
functional elements in mind. In other words, the complex
architecture results in dependencies between functional elements,
and thus does not allow each element to be developed independently
and/or in parallel. As such, the development process requires more
time as more components are added and complexity is increased.
[0007] In addition, although the final integrated product may
provide the features and advantages of a variety of technologies,
the rapid pace of change in these technologies may outdate the
final product before the final product is introduced to the market,
particularly because product development takes such a long time. In
other words, current approaches to product development make it
difficult to ensure that the users of the product have the latest
generation of technology. Where the cost of integrated products may
be relatively high due to the greater amount of functionality,
consumers may find less justification in purchasing such products
when their technology may become quickly outdated.
[0008] In view of the foregoing, there is a need for design and
development approaches that simplify the process of combining
different technological components into a single product while
meeting the high quality standards for medical devices. In
particular, there is a need for an approach that simplifies
interfaces between components and therefore permits different
combinations of components to be easily and reliably integrated
regardless of the number of components. Moreover, there is a need
for an approach that allows the final product to be dynamically and
continuously updated to offer its users the most current
technology.
SUMMARY OF THE INVENTION
[0009] The embodiments described herein address the needs
identified above by providing an architecture that allows
individual system components to be developed and tested
individually, i.e., as distinct modules, and to be subsequently
combined through standardized electrical and communication
interfaces. Any combination of these modules can be implemented to
form different products that provide any number of functions, such
as an integrated system for monitoring a health condition and/or
delivering a medication.
[0010] Although the architecture makes it more feasible to shorten
a product's development cycle and to introduce the product to
consumers more quickly, the embodiments also provide an approach
for dynamically updating the product and offering its users the
latest generation of technology even after the users have already
purchased the product. In particular, the embodiments employ the
communication interfaces to also provide connection to a remote
network that can update or upgrade the product's software when the
product is out in the field. This process is known as a field
upgrade.
[0011] Because the interfaces and communication protocols are
designed to facilitate connection between different components and
the rest of the system, the embodiments also provide functionality
that ensures that unauthorized individuals or devices cannot
connect with the system and compromise the security of data, such
as personal medical information, which may be collected, stored,
and handled by the system. With this underlying security
functionality, particular technologies, such as wireless
communication, can be implemented as components of medical
diagnostic systems without concern over unauthorized access to
personal information.
[0012] In addition, due to the important medical functions
associated with the assembled product, embodiments employ
validation procedures to ensure that any data transferred to the
product, for example, during field upgrade, does not corrupt the
data or the software stored by the product and that the product
continues to operate as expected.
[0013] Still other aspects, features, and advantages of the present
invention are readily apparent from the following detailed
description, by illustrating a number of exemplary embodiments and
implementations, including the best mode contemplated for carrying
out the present invention. The present invention is also capable of
other and different embodiments, and its several details can be
modified in various respects, all without departing from the spirit
and scope of the present invention. Accordingly, the drawings and
descriptions are to be regarded as illustrative in nature, and not
as restrictive. The invention is to cover all modifications,
equivalents, and alternatives falling within the spirit and scope
of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] FIG. 1A illustrates a diagram of an architecture according
to aspects of the present invention.
[0015] FIG. 1B illustrates a diagram of another architecture
according to aspects of the present invention.
[0016] FIG. 2A illustrates an example security measure that can be
employed by an architecture according to aspects of the present
invention.
[0017] FIG. 2B illustrates another example security measure that
can be employed by an architecture according to aspects of the
present invention.
[0018] FIG. 2C illustrates a further example security measure that
can be employed by an architecture according to aspects of the
present invention.
[0019] FIG. 2D illustrates yet another example security measure
that can be employed by an architecture according to aspects of the
present invention.
[0020] FIG. 3 illustrates an example diabetes-management system
employing an architecture according to aspects of the present
invention.
[0021] FIG. 4 illustrates another diagram of an architecture
according to aspects of the present invention.
[0022] FIG. 5 illustrates an example of a diagnostic system
employing an architecture according to aspects of the present
invention.
[0023] FIG. 6 illustrates another example of a diagnostic system
employing an architecture according to aspects of the present
invention.
[0024] FIG. 7 illustrates yet another example of a diagnostic
system employing an architecture according to aspects of the
present invention.
[0025] FIG. 8 illustrates a field-upgradeable architecture
according to aspects of the present invention.
[0026] FIG. 9 illustrates an example for employing a field upgrade
according to aspects of the present invention.
DESCRIPTION OF ILLUSTRATED EMBODIMENTS
[0027] The embodiments described herein provide a system
architecture that allows individual system components, or modules,
to be developed and validated independently (as distinct modules)
and subsequently combined through standardized electrical and
communication interfaces. The standardized interfaces facilitate
the combination and configuration of these modules to form
different products that provide any number of functions. While the
architecture can be used to form a fixed combination of components,
the approach also permits reconfigurable or expandable combinations
where different components may be easily removed or added to the
system. In addition, as described further below, the architecture
provides an approach for dynamically updating the modules after
they have been integrated into the product.
[0028] FIG. 1A illustrates a conceptual diagram of a modular
architecture according to aspects of the present invention. As
shown in FIG. 1A, a modular architecture system 1 includes central
engine 10 that is connected to a plurality of modules 30A, 30B,
30C, and 30D, each of which provides a functionality for a health
monitoring and delivery system. The central engine 10 enables the
modules 30A, 30B, 30C, and 30D to work as an effective system. For
example, the central engine 10 allows information to be
communicated between the modules 30A, 30B, 30C, and 30D. For
example, module 30D may be a computing device with software that
processes data received from the other modules 30A, 30B, and 30C
via the central engine 10. As FIG. 1A further illustrates,
interface elements 22A, 22B, 22C, and 22D of the central engine 10
connect with respective interface elements 24A, 24B, 24C, and 24D
to establish communications between the central engine 10 and the
modules 30A, 30B, 30C, and 30D. The interfaces may provide wired,
i.e. physical, and/or wireless communications. Advantageously, the
centralized organization of the interface architecture facilitates
the integration of modules 30A, 30B, 30C, and 30D, which can be
developed and tested separately from each other. Moreover, although
the interface elements 22A, 22B, 22C, and 22D of the central engine
10 do not have to follow the same communications protocol, the
interface elements 22A, 22B, 22C, and 22D can employ the most
widely-used standard protocols so that the central engine 10 is
more likely to be compatible with a given module.
[0029] Although the modules 30A, 30B, 30C, and 30D of FIG. 1A may
all communicate information with each other, it is contemplated
that a module connected to the central engine 10 does not have to
communicate with all of the other modules. Indeed, a module may be
communicatively isolated from any, including all, of the other
modules. For example, the nature of data and/or software on a
particular module may be highly sensitive, so the module may be
isolated from the other modules to enhance the security and/or
integrity of the data.
[0030] In one embodiment, the central engine 10 is implemented on a
mother board, while each module is separately implemented on a
daughter board. The daughter boards are standardized so that they
may connect to a single mother board to be integrated with the
system. In other words, specific interfaces with boards
corresponding to other modules do not have to be developed each
time a new module is implemented. Due to this standardized
approach, using commercial off-the-shelf (COTS) hardware for the
mother and daughter boards becomes more feasible. Advantageously,
using COTS hardware requires less development time than an
application-specific integrated circuit (ASIC) approach.
[0031] In some embodiments, the mother board and the daughter
boards may physically reside on separate circuit boards. In other
embodiments, the mother board and the daughter boards may all be
physically integrated onto the same circuit board. In further
embodiments, the mother board and a combination of daughter boards
may be physically integrated onto the same circuit board, while
other daughter boards reside on separate circuit boards. Moreover,
in some embodiments, the mother board and the daughter boards,
whether on the same circuit boards or not, may all be disposed in
the same housing, or casing. Meanwhile, in other embodiments, some
or all of the daughter boards may be disposed in one or more
housings separate from the mother board's housing. In general, the
components of embodiments may be subject to varying degrees of
physical integration regarding assembly on different circuit boards
or within different housings, etc. To accommodate this variation in
physical configuration, more than one interface type may be
required to connect the daughter boards to the mother board, but as
discussed previously, the interfaces between the central engine and
the modules do not have to follow the same communications protocol.
The interface elements associated with the mother board can employ
the most widely-used standard protocols so that the central engine
is more likely to be compatible with a given module.
[0032] The centralized architecture using standardized interfaces
facilitates the development of compatible modules. When adding
functionality to the system, integration with the architecture is
easily achieved by employing a compatible interface element.
Moreover, the new module can be developed independently of the
other modules, because only a single interface with the central
engine 10 is required. In other words, even if the new module must
communicate with other modules in the system, the new module does
not have to be designed for a direct connection with the other
modules, so the communications configuration of the other modules
is not a significant design consideration for the new module.
Accordingly, the ability to independently develop additional
modules that easily connect with the central engine 10 enables
systems employing this architecture to be flexible and
reconfigurable. For example, such a system can be expanded with new
modules or upgraded with new versions of existing modules.
[0033] Although FIG. 1A illustrates an embodiment with the single
central engine 10 connected to modules 30A, 30B, 30C, and 30D, the
central engine 10 in some embodiments may also connect to a
secondary central engine 40 as illustrated in FIG. 1B. As shown in
FIG. 1B, the central engine 10 is connected to modules 30A, 30B,
and 30C via corresponding interface elements 22A/24A, 22B/24B, and
22C/24C. Meanwhile, the central engine 40 is connected to modules
60A, 60B, and 60C via corresponding interface elements 52A/54A,
52B/54B, and 52C/54C. As with the modules 30A, 30B, and 30C, the
modules 60A, 60B, and 60C may be developed independently of the
other modules according to a modular architecture that only
requires a single interface with the central engine 40. As further
illustrated in FIG. 1B, the central engine 10 may be connected to
the central engine 40 via interface elements 22D and 52D. Like the
other interface elements, the interface elements 22D and 52D may
provide wired, i.e. physical, or wireless communications. In some
embodiments, the central engine 10 assumes a host function for the
central engine 40. For example, if the central engine 10 connects
to the central engine 40 according to universal serial bus (USB)
communication protocol, standard USB requires a host-slave
relationship between the two systems.
[0034] In the embodiment of FIG. 1B, the central engine 10 may
access the functionalities provided by the modules 60A, 60B, and
60C, and conversely, the central engine 40 may access the
functionalities provided by the modules 30A, 30B, and 30C. Even
though the resulting combination may function like a single central
engine connected to all six modules 30A, 30B, 30C, 60A, 60B, and
60C, the central engines 10 and 40 may be developed separately. As
such, the development of a set of modules can be advantageously
organized into separate subsets. For example, medical diagnostic
systems may include critical medical devices, such as a
blood-glucose meter, as well as other types of devices, such as a
heart rate monitor. The critical medical devices may require very
rigorous product validation during development and may be subject
to government regulations. Meanwhile, the other types of devices
may not require the same type or same level of validation. As such,
modules involving critical medical devices may have very different
timelines and guidelines for product development compared to the
other types of health care devices. Thus, in this case, it may be
advantageous to organize the modules into two product development
groups. In addition, every time a product involving critical
medical devices is redeveloped or updated to include new features,
government regulations may require revalidation of the product even
if the new features may be relatively minor. For example, if a
heart rate monitor is added to a central engine that is already
connected to a blood-glucose meter, the entire system may have to
be revalidated at great cost and effort, even though the new
modules is a less critical health care device. However, the central
engine connected to the blood-glucose meter can remain unchanged if
the central engine already has the capability to connect to a
secondary central engine that in turn is connected to the heart
rate monitor. In other words, deploying new modules involving other
health care devices and other features through the secondary
central engine provides a way to expand the overall product without
changing the architecture associated with the primary central
engine. Moreover, any validation of the architecture associated
with the secondary central engine may be conducted without
affecting the architecture associated with the primary central
engine.
[0035] Although an advantage of the architectures described herein
is the ease by which new modules can interface with the system and
establish communications and data exchange, issues relating to the
security of personal medical data have discouraged using highly
compatible communication technologies with medical devices, such as
personal testing devices that measure and store health data. To
address these issues, embodiments according to aspects of the
present invention provide functionality that helps to ensure that
unauthorized individuals or devices cannot connect with the system
and compromise the security of any personal medical information.
The central engine 10 may be responsible for providing security
measures. Alternatively or additionally, a component or module with
special security functions may be employed to promote system
security. With such security functionality, particular
technologies, such as wireless communication, can be implemented as
components of medical diagnostic systems without heightened concern
over unauthorized access to personal information.
[0036] FIGS. 2A-D illustrate examples of security techniques that
may be employed by an architecture according to aspects of the
present invention. As shown in FIG. 2A, the central engine 10 may
prompt the user for a user ID and password, personal identification
number (PIN), or other authentication information, when a module 30
attempts to interface with the central engine 10 or to access data
through the system. The module 30 is only allowed connection or
data access if the response to the security prompt corresponds with
authentication information stored at the system. For example, the
module 30 may be a PC executing a data-management program that
uploads test data from a blood-glucose meter connected to the
central engine 10. When the program attempts to communicate through
an interface connection or tries to access data, the user must
submit a user ID and password. The authentication information may
be entered through a user interface, e.g. a keypad or keyboard, on
the PC or the central engine 10. If the module 30 is used
frequently to access data through the central engine 10, the user
may find it inconvenient to enter authentication information
repeatedly. Thus, some embodiments may allow a user to set a time
period (from zero to infinity) between authentications from the
particular module 30. The central engine 10 records a unique
identifier, e.g. device ID, for module 30 to keep track of the time
period. For instance, a security prompt may be required if the
specified time, e.g. one day, has passed since the last
authentication. Alternatively, the user may stop all further
security prompts from occurring after the first authentication. In
this alternative case, the first authentication acts as a
registration with the central engine 10 to permit all future access
from the module 30.
[0037] As shown in FIG. 2B, a unique identifier, e.g. device ID,
for module 30 may be registered with the central engine 10. This
unique identifier may be entered by the user or recorded when the
authentication process shown in FIG. 2A is completed for the first
time. Alternatively, registration of the module 30 may be achieved
through an initial, e.g. factory, set-up process. In this
alternative case, registration of additional modules may be
prohibited after the initial set-up, thereby fixing the number of
modules in the system. When the module 30 subsequently attempts to
connect or access data, the central engine 10 automatically
recognizes the module 30 and permits access.
[0038] In the embodiments of FIGS. 2A and 2B, the module 30 is
authenticated or registered in a one-way process. In other words,
the central engine 10 is not required to be authenticated or
registered with the module 30. In contrast, as shown in FIG. 2C,
both the central engine 10 and the module 30 are required to be
registered with each other. Matching of unique identifiers for the
pair is required before any communication takes place between the
central engine 10 and the module 30. This pair matching is
particularly applicable to wireless communication between two
devices. The process prevents intentional unauthorized access, and
also prevents interference between two different systems. For
example, if a user is in a setting, such as a hospital or clinic,
where others are using similar wireless analyte-testing devices,
such as blood-glucose meters, pair matching prevents another
person's blood-glucose meter from accidentally communicating with
the user's diagnostic system and providing the wrong data.
[0039] Data security may also be enhanced by using encrypted data
during communications, as shown in FIG. 2D. This is also
particularly applicable to wireless communications, so that any
intercepted data will be unreadable. The data encryption may be
achieved by using private encryption keys.
[0040] Data security may be further enhanced by ensuring that all
data is stored by the central engine 10 within memory in the
architecture and is not transferred to any connected modules. Thus,
a user may, for example, use a public computer to interface with
the system and no data will be transferred to the public computer
for others to access.
[0041] FIG. 3 provides a non-limiting example of a
diabetes-management system 100 that can be formed from the
architecture approach described herein. The diabetes-management
system 100 is advantageous to those individuals who are actively
involved in monitoring and recording measurements of their blood
glucose concentrations and/or other analytes of interest.
[0042] As shown in FIG. 3, the diabetes-management system 100
includes a blood-glucose meter (BGM) 310, a continuous glucose
monitoring (CGM) module 320, an insulin-delivery device 330, and a
computing device 370, which may include diabetes data management
software 375. The modules 310, 320, 330, and 370 are combined, as
described further below, using the architecture approaches
described herein to provide health monitoring and delivery
functions for the diabetes-management system 100. In particular,
the BGM 310 provides point-in-time measurements of blood-glucose
concentrations in blood samples; the CGM module 320 provides
continuous measurements of blood-glucose concentration; and the
insulin-delivery device 330 delivers insulin to the user.
[0043] In addition, the computing device 370 executes the software
375 to receive data from the modules 310, 320, and 330 and provides
advanced data processing and management capabilities. The computing
device 370 may be selected from a variety of processing devices,
such as desktop or laptop personal computers (PCs), handheld or
pocket personal computers (HPCs), compatible personal digital
assistants (PDAs), and smart cellular phones. The processing
devices may employ a variety of operating systems and
configurations. For example, if the computing device 370 is a
desktop or laptop personal computer, the operating system may be a
version of Microsoft.RTM. Windows.RTM.. Alternatively, if the
computing device 370 is a PDA, the operating system may correspond
with those of PALM.RTM. handhelds from Palm, Inc., or
Blackberry.RTM. devices from Research in Motion Limited. In
general, computing device 370 includes a processor that is capable
of receiving and executing any number of programmed
instructions.
[0044] The data-management software 375 on the computing device 370
may be a collection of programs or computer code that receives and
processes data measured by the modules 310 and 320, for example.
The software 375 processes and/or displays this input in a manner
that is desired by the user. This information may be used by, for
example, a user, home care provider (HCP), and/or a physician. The
measured data from the modules 310 and 320 may include, for
example, the concentration of glucose and/or other analytes in a
person's blood or other bodily fluid. Advantageously, the software
375 can provide the advanced displays and data processing that may
be required by a user who tests multiple times a day (e.g., about
six to about ten times a day). For example, the software 375 may
include a product similar to WINGLUCOFACTS.RTM. Diabetes Management
Software available from Bayer HealthCare LLC (Tarrytown, N.Y.). As
such, the software 375 may provide a complete tool kit that
receives and stores test results from a blood-glucose measurement
system, receives and stores other testing information such as test
times and meal markers, tracks test results in an electronic
logbook, calculates averages and provides statistical analysis of
outlier test results, summarizes and provides feedback on the test
results, provides a customizable graphical user interface, displays
user-friendly charts and graphs of the test results, tracks test
results against user-specific target ranges, provides predictive
analysis, and/or sends data to healthcare professionals via fax,
email, etc. As described previously, data security is enhanced if
the software 375 does not upload data from the modules 310 and 320
to the computing device 370 and the data is always stored within a
single central storage device.
[0045] As described further below, the use of software or
programmed instructions is not limited to the computing device 370.
Moreover, the use of embodiments of the present invention are not
using the particular modules 310, 320, 330, and 370. FIG. 4
illustrates a broader system diagram with other modules 300. For
instance, as FIG. 4 illustrates, an A1.sub.C module 340, which
monitors glucose control over time, may also be used in a
diabetes-management system. The modules 300 also include other
health monitor modules 350, such as blood pressure and heart rate
monitors. Indeed, modules 300 may measure and/or record health data
that do not require analyte testing, such as temperature
measurements, blood pressure measurements, heart rate measurements,
breathing measurements for chronic obstructive pulmonary disease
(COPD) analysis, weight measurements for analyzing Lasix use, and
the like. In further systems, other utility device modules 360 may
include training modules, connectivity modules providing further
connection to other systems, and other modules that improve or
enhance a user's experience with the system. For example, it is
contemplated that entertainment or media modules such as game
modules or music player modules may be combined with the systems
described herein. Providing entertainment features, for example,
may encourage patients, particularly young patients, to keep the
diagnostic systems with them wherever they go, so that health
conditions, such as diabetes, can be monitored regularly.
Furthermore, in some systems, the architecture may also employ open
source code so that additional custom or specialized modules may be
developed by users or third parties for integration with the
architecture described herein. Accordingly, an endless variety of
modules providing any type of functionality may be employed.
[0046] As shown in FIG. 3, the system 100 includes a central engine
110, such as a digital engine, for the architecture and enables the
modules 300 to be easily and effectively combined. For example, the
central engine 110, the BGM 310, the CGM module 320, and the
insulin-delivery device 330 can be effectively combined to create
an artificial pancreas. Alternatively, the central engine 110, the
BGM 310, and the CGM 320 can be combined to form a CGM with an
embedded BGM unit. Or as a further example, the central engine 110,
the BGM 310, and the insulin-delivery device 330 can be combined to
form a pump controller with an embedded BGM unit.
[0047] Referring again to FIG. 4, the central engine 110 may
include a processor 112 and a power management element 114. The
processor 112 is capable of receiving and executing any number of
programmed instructions, and may be a microcontroller,
microprocessor, digital signal processor, or the like. The
programmed instructions to be executed by the processor 112 may be
embedded or may be retrievable from a storage device 250, a
connected module 300, or another source such as an Internet
website. The processor 112 centrally manages communications with
the modules 300. In some cases, the processor 112 may also execute
software that handles the operation of some modules 300. Moreover,
the processor 112 may give the modules 300 access to common
resources or features such as the user interfaces 220 described
further below.
[0048] Power management element 120 distributes power from a power
supply to the processor 112 as well as modules 300 that do not have
their own power source. The power management system 114, for
example, may be configured to enter a standby mode to minimize
power use when the system is idle. Additionally, if a rechargeable
battery is employed, the power management system 114 may also
handle the recharging of the battery.
[0049] As also shown in FIG. 4, the central engine 110 is connected
to input/output interfaces 200, which can be divided into two
different categories: communication interfaces 210 and user
interfaces 220. The communication interfaces 210 govern the
exchange of data between the central engine 110 and the modules
300. In general, the communication interfaces 210 can accommodate
wired and/or wireless communications. Wired communications include,
for example, communications by universal serial bus (USB)
connection. Wireless communications include, for example,
radio-frequency (RF) links (e.g., a short-range RF telemetry),
infrared (IR) links, and/or Wi-Fi. Some known RF technologies, for
example, include Bluetooth.RTM. wireless technologies, Zigbee,
Z-Sense.TM. technology, FitSense, and BodyLAN.TM. system. It is
understood that other communication technologies, or protocols, may
be employed.
[0050] Referring again to FIG. 3, a wired, or physical, connection
212 exists between the central engine 110 and the computing device
370 while a wireless connection 214 exists between the central
engine 110 and each of the CGM module 320 and the insulin-delivery
device 330. It is noted that the BGM 310 is assembled with the
central engine 110 in the housing 101. As such, the interface
between the central engine 110 and the BGM 310 involves a wired
connection (not shown). Indeed, as FIG. 3 illustrates, the modules
300 may be combined in any suitable arrangement in relation to the
central engine 110 and to other modules 300 Like the BGM 310, some
modules 300 may be assembled with the central engine 110 within the
same housing, while other modules 300 may be provided in separate
housings and arranged remotely from the central engine 110. It is
also contemplated that in addition to other configurations
described herein, some modules 300, having the form of circuit
components, for example, may be assembled on the same printed
circuit board assembly (PCBA) as circuit components for the central
engine 110 with a circuit connection providing the interface
210.
[0051] FIG. 5 illustrates a further example of a connection between
the central engine 110 and a module 300, namely the BGM 310. Unlike
FIG. 3, the BGM 310 of FIG. 5 is not disposed in a housing 101 with
the central engine 110, but the description provided with reference
to FIG. 5 is equally applicable to the configuration in FIG. 3.
[0052] Referring to FIG. 5, the BGM 310 with a test sensor 316 is
illustrated. The test sensor 316 is configured to receive a fluid
sample which is analyzed using the BGM 310. Analytes that may be
analyzed include glucose, lipid profiles (e.g., cholesterol,
triglycerides, LDL and HDL), microalbumin, hemoglobin A1.sub.C
fructose, lactate, or bilirubin. It is contemplated that other
analyte information may be determined (e.g., analyte
concentrations). The analytes may be in, for example, a whole blood
sample, a blood serum sample, a blood plasma sample, other body
fluids like ISF (interstitial fluid) and urine, and non-body
fluids.
[0053] The test sensor 316 includes a fluid-receiving area for
receiving a sample of body fluid. For example, a user may employ a
lancet or a lancing device to pierce a finger or other area of the
body to produce the blood sample at the skin surface. The user may
then collect this blood sample by placing the test sensor 316 into
contact with the sample. The fluid-receiving area may contain a
reagent which reacts with the sample to indicate the concentration
of an analyte in the sample.
[0054] The test sensor 316 may be an electrochemical test sensor.
An electrochemical test sensor typically includes a plurality of
electrodes and a fluid-receiving area that contains an enzyme. The
fluid-receiving area includes a reagent for converting an analyte
of interest (e.g., glucose) in a fluid sample (e.g., blood) into a
chemical species that is electrochemically measurable, in terms of
the electrical current it produces, by the components of the
electrode pattern. The reagent typically contains an enzyme such
as, for example, glucose oxidase, which reacts with the analyte and
with an electron acceptor such as a ferricyanide salt to produce an
electrochemically measurable species that can be detected by the
electrodes. It is contemplated that other enzymes may be used to
react with glucose such as glucose dehydrogenase. In general, the
enzyme is selected to react with the desired analyte or analytes to
be tested so as to assist in determining an information related to
an analyte (e.g. analyte concentration) of a fluid sample. If the
concentration of another analyte is to be determined, an
appropriate enzyme is selected to react with the analyte.
[0055] Alternatively, the test sensor 316 may be an optical test
sensor. Optical test sensor systems may use techniques such as, for
example, transmission spectroscopy, diffuse reflectance, or
fluorescence spectroscopy for measuring the analyte concentration.
An indicator reagent system and an analyte in a sample of body
fluid are reacted to produce a chromatic reaction, as the reaction
between the reagent and analyte causes the sample to change color.
The degree of color change is indicative of the analyte
concentration in the body fluid. The color change of the sample is
evaluated to measure the absorbance level of the transmitted
light.
[0056] Some commercially available test sensors that may be used by
the embodiments described herein include those that are available
commercially from Bayer HealthCare LLC (Tarrytown, N.Y.). These
test sensors include, but are not limited to, those used in the
Ascensia.RTM. CONTOUR.RTM. blood glucose monitoring system, the
Ascensia.RTM. BREEZE.RTM. and BREEZE.RTM.2 blood glucose monitoring
system, and the Ascensia.RTM. Elite.RTM. and Elite.RTM. XL blood
glucose monitoring system. It is contemplated that other test
sensors, in addition to the ones listed above, may be incorporated
into the methods and systems of the present invention.
[0057] As illustrated in FIG. 5, the BGM 310 receives and engages
the test sensor 316. The BGM 310 includes a reaction-detection
system for measuring the concentration of analyte for the sample
collected by the test sensor 316. For example, the
reaction-detection system may include contacts for the electrodes
to detect the electrochemical reaction for an electrochemical test
sensor. Alternatively, the reaction-detection system may include an
optical detector to detect the chromatic reaction for an optical
test sensor. To calculate the actual concentration of analyte from
the electrochemical or chromatic reaction measured by the
reaction-detection system and to generally control the procedure
for testing the sample, the BGM 310 employs at least one processor
312, which may execute programmed instructions according to a
measurement algorithm. Data processed by the processor 312 may be
stored in a memory 313. Furthermore, the BGM 310 may have a user
interface 315 that includes a display, which, for example, may be a
liquid-crystal display. Pushbuttons, a scroll wheel, touch screens,
or any combination thereof, may also be provided as a part of the
user interface 315 to allow a user to interact with the BGM 310.
The display typically shows information regarding the test results,
the testing procedure and/or information in response to signals
input by the user.
[0058] Although the BGM 310 can store test results and provide a
user interface 315 to display test results, the data-management
software 375 on the computing device 400 provides more advanced
functionality for managing, processing, and displaying test results
and related information. Therefore, the test-related data collected
by the BGM 310 can be communicated via the central engine 110 to
the computing device 370 for use with the data-management software
375. As shown in FIG. 5, the BGM 310 includes a BGM interface
element 311 that enables the BGM 310 to connect with the central
engine 110 via the engine interface element 111. Furthermore, the
central engine 110 is connected to the engine interface element 116
which in turn is connected to computer interface element 376 of
computing device 370. The BGM interface element 311, the computer
interface element 376, and the engine interface elements 111 and
116 may employ the interface technologies described above to make
the devices compatible and enable the appropriate data connections.
For example, engine interface 111 and BGM interface 311 may connect
via Bluetooth.RTM. wireless, while the engine interface 111 may
connect to the computer interface 376 through a connection to a USB
port. Thus, it is readily seen that although the BGM 310 and the
computing device 370 may not have compatible interfaces, the
architecture of FIG. 5 enables data to be exchanged between them.
Moreover, it is also readily contemplated that the development of
the BGM 310 can be accomplished without regard to direct
compatibility with USB interface of the computing device 370.
[0059] As discussed previously, the central engine 110 has the
power management 114 which may include a power supply that is
rechargeable via the connection with the computing device 370 or
some other power source. When the central engine 110 and the BGM
310 are connected, a rechargeable battery can be recharged via
power management 314.
[0060] As described previously, the BGM 310 in FIG. 5 employs at
least one processor 312, which may execute programmed instructions.
Moreover, the BGM 310 may have a user interface 315, which includes
a display to present information to the user, as well as
pushbuttons, a scroll wheel, touch screens, or any combination
thereof to enable interaction by the user. With such components,
the BGM 310 generally controls the whole procedure for testing the
sample and calculates the test results. Indeed, the description
provided with reference to FIG. 5 generally explains how the test
results already calculated by the BGM 310 may be subsequently
shared with other modules such as the computing device 370.
However, it is contemplated that the processor 112 of the central
engine 110 can also provide a wider range of functions. In fact, it
is further contemplated that the processing in a health monitoring
and delivery system can be distributed among the components,
including the central engine 110, in varying manners.
[0061] For example, FIG. 6 illustrates a sensor-receiving module
380 that requires other components to handle substantially all of
the processing. Like the BGM 310, the sensor-receiving module 380
is configured to receive a test sensor 316. However, the
sensor-receiving module 380 does not have a processor to manage the
testing procedure or to calculate test results. In addition, the
sensor-receiving module 380 has no user interface to communicate
with the user. In general, the sensor-receiving module 380 is
designed to merely receive a test sensor 316 and to provide an
interface element 381 for physical connection to the rest of the
diagnostic system. As a result, analysis of the test sample on the
test sensor 316 is only possible when the sensor-receiving module
380 connects with a device that has a processor to analyze the
sample via the interface element 381.
[0062] As shown in FIG. 6, the interface element 381 of the
sensor-receiving module 380 is connected to the interface element
111, which in turn is connected to the digital sensor 110. It is
noted that the connection between the sensor-receiving module 380
and the central engine 110 may require a host function, such as the
USB host function, to be employed by the central engine 110. In one
embodiment, the digital sensor 110 is also connected to the
interface element 376 of the computing device 370. The interfaces
between the sensor-receiving module 380, the central engine 110,
and the computing device 370 may employ any of the interface
technologies, such as USB or Bluetooth.RTM. technology, described
above. Accordingly, the computing device 370 can execute software
377 to control the procedure for testing a sample and calculating
the test results in a manner similar to the processor 312 on BGM
310 in FIG. 5. In operation, the sensor-receiving module 380, the
central engine 110, and the computing device 370 are connected as
shown in FIG. 6. The test sensor 316 is used to collect a fluid
sample, such as a blood sample. If, for example, the test sensor
316 is an electrochemical test sensor, the sensor-receiving module
380 system may include electrical contacts to receive the
electrical signal from the electrochemical reaction that occurs
between the sample and the reagent on the test sensor 316. The
connection between the sensor-receiving element 380 and the central
engine 110 is connected to the circuit containing the electrical
sensors so that the central engine 110 receives the electrical
signal from the electrochemical reaction. This signal can then be
passed to the computing device 370 to process the signal and
determine the test results using a measurement algorithm. The user
interface on the computing device 370 can be used to display the
test results or to receive instructions from the user.
[0063] It is understood that other techniques may be employed to
communicate a signal from the sensor-receiving module 380. For
example, a test sensor 316 may be an optical test sensor and the
sensor-receiving system 380 may include an optical detector to
detect a chromatic reaction. If the sensor-receiving module 380
requires any power to receive or process a signal from the test
sensor 316, the power can be drawn through its connection with the
central engine 110.
[0064] Alternatively, in another embodiment, the computing device
370 is not employed in the system, so that the sensor-receiving
module 380 is only connected to the central engine 110 as shown in
FIG. 7. As such, the test result calculations are completed by the
processor 112 of the central engine 110 and the test results are
displayed on a user interface connected to the central engine 110.
As shown in FIG. 7, a user interface 115 may be incorporated into
the housing 101.
[0065] The measurement software 253 for controlling the test
process and determining the results may be available through the
storage device 250 as illustrated in FIG. 7. As illustrated in FIG.
4, the storage device 250 corresponds with another type of
input/output interface 200. The storage device 250 may be a flash
memory device, such as a universal serial bus (USB) flash drive or
a memory card. USB flash drives are also known as thumb drives,
handy drives, flash sticks, or jump drives. Memory cards may have a
variety of formats, including PC Card (PCMCIA), CompactFlash (CF),
SmartMedia (SM/SMC), Memory Stick (MS), Multimedia Card (MMC),
Secure Digital Card (SD), xD-Picture Card (xD), Intelligent Stick
(iStick), ExpressCard, or some variation thereof. Flash memory
devices may employ non-volatile memory so that the software
associated with the measurement software 253 may be retained in the
storage device 250 even when the storage device 250 receives no
power. In some embodiments, the memory in the storage device 250
may include execute-in-place (XIP) memory, such as NOR flash
memory, so that the measurement software 253 stored on the memory
can be executed directly. It is also contemplated that the storage
device 250 may employ other storage media, such as floppy disk or
optical disc (CD, DVD, Blu-ray disc).
[0066] The storage device 250 may be assembled with the central
engine 110 in the housing 101, as shown in FIG. 7, or it may be
connected to the central engine 110 in a manner similar to an
external module (e.g., module 300). Particularly in the latter
case, the storage device 250 may interface with a communications
interface 210 and connect to the central engine 110. The interface
enables data communications between the storage device 250 and the
central engine 110 and permits the measurement software 253, or any
other software, to be used with central engine 110. In particular,
the storage device 250 has an interface element that is compatible
with an interface element 210. In some embodiments, the
storage-device interface element physically engages the interface
element 210 to form a serial hardware interface. For example, the
storage device 250 may be a USB flash drive, and the storage-device
interface element may be a USB connector that is received into a
USB port, which acts as the communications interface element 210
for the central engine 110.
[0067] As a further example, the storage device 250 may be a Secure
Digital (SD) memory card with a series of contacts that act as the
interface element, and the communication interface 210 may be an
expansion slot that receives the contacts of the memory card. In
this example, the central engine 110 and the storage device 200 may
comply with SDIO (Secure Digital Input Output) interface
specifications. It is contemplated that other memory card formats
having different interface specifications may be employed. However,
having an SDIO is advantageous because many hosts such as PDAs,
HPCs and smart cellular phones include an expansion slot that is
SDIO compatible.
[0068] As the central engine 110 in FIG. 7 is filling the role of
the computing device 370 in the example of FIG. 6, higher-powered
processing devices may be required. For example, some embodiments
may employ handheld or pocket personal computers (HPCs), compatible
personal digital assistants (PDAs), or smart cellular phones. As
discussed above, these processing devices may employ a variety of
operating systems and configurations. For example, if the computing
device 370 is a PDA, the operating system may correspond with those
of PALM.RTM. handhelds from Palm, Inc., or Blackberry.RTM. devices
from Research in Motion Limited. Advantageously, PALM.RTM.
handhelds and Blackberry.RTM. devices provide a portable device
with enough processing power to reliably execute advanced data
management software for results collected from the sensor-receiving
module 380. Moreover, such devices provide rich user interfaces
that provide advanced graphical display capabilities. In addition,
because these handheld devices connect to external networks, such
as the Internet, new software or software upgrades/patches can be
readily installed. Furthermore, the connection to the
telecommunications network enables test results to be easily
transmitted to doctors and other healthcare professionals for
monitoring or evaluation. Because many consumers already carry
these or similar devices, many users of a diagnostics system, such
as a diabetes-management system, would conveniently incorporate the
system in devices they already own and carry regularly.
[0069] Because embodiments may employ many different types of
modules 300 that may be situated on different types of hardware,
the communication interfaces 210 generally have to accommodate more
than one type of communication technology, or protocol. However, to
minimize the number of communication interfaces 210 while providing
the widest range of compatibility between the central engine 110
and the various modules 300, the communication interfaces 210 can
employ widely-used and standardized interface technologies, such as
USB or Bluetooth.RTM. technology. Preferably, the communication
interfaces 210 employ technologies that minimize the amount of
configuration required to establish communication between a module
300 and the central engine 110. Indeed, some communication
technologies, such as USB connectivity, provide plug-n-play (PnP)
capability. In these embodiments, the module 300 is physically
connected, for example, through a conventional USB port. Then in
response, the central engine 110 immediately recognizes the module
300 and establishes immediate communication with the module
300,
[0070] The communication interfaces 210 not only provide
communication between modules 300, but they also enable secure
communication with external networks. As such, embodiments may
employ a connection to an external network to download updates,
upgrades, or additions to the software in the central engine and/or
the modules 300 when the product is out in the field. In other
words, the embodiments may provide field upgradeable software
functions. Advantageously, embodiments allow the user to update any
software/firmware in the integrated system, e.g., software for the
central engine 110 and/or the modules 300, by using program files
provided by, or purchased from, the manufacturer or an authorized
third party. Existing system software can be updated or patched
with newer versions, or new software may be added to the system,
without requiring the user to contact the manufacturer or third
party for direct assistance. The new software allows the user to
customize and/or expand the functionality of the system. In some
cases, a product may be essentially converted to a new product.
Field upgrades make the latest product features available to users
who have already purchased a product. Moreover, field upgrades
making existing product compatible with other newly released
accessories or devices. For example, in a diabetes-management
system, if the BGM 310 uses a test sensor to test blood for blood
glucose concentration, and the BGM manufacturer develops a new test
sensor that improves accuracy or test time, embodiments would allow
the user to upgrade the firmware in the device so that the BGM 310
is capable of reading the new test sensor.
[0071] The central engine may manage aspects of the field upgrade
validation in combination with a download engine. The download
engine, described further below, can receive system components from
a server, e.g., the field upgrade server, the external network via
a communication interface and deliver the system components for
validation and deployment. Additionally or alternatively, the
server on the external network can manage aspects of the field
upgrade process.
[0072] In addition, due to the important medical functions
associated with the modules 300, embodiments employ validation
procedures before employing the new software or configuration
information to ensure that any field upgrade does not corrupt the
data or the software stored by the product and that the product
continues to operate as expected. For example, check-sum routines
may be employed to confirm that data or software has been
successfully downloaded in its entirety. For example, the central
engine 110 may validate downloads according to an associated data
update file (DUF) or other component that ensures that the software
has been successfully downloaded. For additional data security, the
field upgrade process may employ data encryption/decryption.
[0073] In an example embodiment illustrated in FIG. 9, once a
connection is established with a field upgrade server in an
appropriate external network (act 502), an available field upgrade
is identified for an existing system component, e.g., new software
or configuration information, (act 504). The connection to the
server may be triggered automatically when a connection to the
network may be established, or a user may manually initiate
communication with the field upgrade server. To identify an
available field upgrade, the central engine or the server may
employ a version management program to determine which system
components in the architecture are compatible with, and can be
replaced by, newer or different versions stored on the field
upgrade server. The new system component is then downloaded from
the field upgrade server to a memory, i.e., data storage area, that
is separate from the memory area storing the existing system
component. An area of memory may be specifically dedicated for
field upgrade operations. In other words, the existing system
component is retained, rather than deleted or written over at least
until validation is complete. The new system component is validated
with a system check (act 508), and if the download has been
successful and the system operates properly, the new system
component is deployed for regular system operation. Thus, if the
field upgrade fails, the previous version of the system component
is still available and provides a recovery or restore option. The
new system component is removed with a failed field upgrade. In
some embodiments, the new version may replace the previous version
in memory after the new version is validated. In other embodiments,
the one or more previous versions are retained even after
validation and users may have the option to restore one or more
previous versions of a system component if an older version is
preferred.
[0074] An example embodiment is described with reference to FIG. 8.
In the embodiment of FIG. 8. the diabetes-management system 400 may
include modules 402, 403, 404, and 405 which collect fluid samples.
The digital engine 406 controls each module, user interface 413,
memory 407, and the download engine 408. Download engine 408
provides an interface between one of the communication modules,
digital engine 406, and memory 407. The communications modules may
include USB interface 409 which provides, for example,
communication between a computing device USB port and the system
401. The communication module may also include a Bluetooth
interface 410 which provides wireless communication between the
system 400 and a computing device, cell phone, and/or other devices
capable of communicating with the system 400. Furthermore, a Wi-Fi
interface 411 provides communication between a wireless network and
the system 400. Additionally, the Ethernet interface 411 provides
communication between a local area network and the system 400. Each
communication module can be used to upgrade/update the meter's
software in the field upon the user's direction. The following
features may also be downloaded per user request: new firmware for
new functions; new firmware to update the behavior of current
system functions; user interface language; screen updates and
customization; games and other standalone applications; gauges; and
other software or configuration settings/updates.
[0075] For example, the user interface may communicate in many
languages, but all the data required for those languages does not
have to be stored locally, as users may download language files as
required to customize the operation of their systems. In addition,
users can customize the appearance of the user interface display by
installing custom pictures to display on the screen or by
downloading display layouts made available by a manufacturer or an
authorized third party. Furthermore, users can customize the
behavior of the system by installing standalone applications (such
as games) that can run on the system processor and be played when
the system 400 is not being used to analyze body fluids. Users can
also customize system behavior by installing software that changes
the way body fluid analysis results are displayed, as results may
be presented as digital readouts, simulated analog gauges,
qualitative feedback, etc.
[0076] Referring again to FIG. 4, the input/output interfaces 200
also include user interfaces 220, which generally allow the modules
300 to display information, such as test results, to the user. The
modules 300 may transmit such information to the central engine 110
via communication interfaces 210, and the central engine 110 may in
turn present the information on the display interfaces 220.
Although centralized handling of communications may be preferred,
the modules 300, in some cases, may interface directly with the
display interfaces 220. As shown in FIG. 2, the display interfaces
may include graphic liquid crystal display (LCD) or organic
light-emitting diode (OLED), segment LCD or OLED, MP4 playback, or
the like.
[0077] In addition, the input/output interfaces 200 may allow
information to be communicated to and from the user via audio
signals. For example, the input/output interfaces 200 may include a
speech synthesizer, MP3 playback, or the like, for communicating
audio information to a user. Additionally, the input/output
interfaces 200 may also include a speech recognition mechanism to
receive audio information from a user.
[0078] Furthermore, the user interfaces 200 may allow the user to
input information or instructions into the system. For example, the
user may be required to respond to simple prompts or make menu
selections to guide one of the modules 300 during operation. Or as
a further example, the user may want to enter instructions to
retrieve information, such as test results, and to present the
information on the display interfaces 220. Mechanisms for providing
input, for example, may include a keypad, a touch screen, a thumb
wheel, or the like.
[0079] As shown in FIG. 7, a user interface 115 may be incorporated
into the housing 101 in which the central engine 110 and
corresponding communication interfaces 210 are assembled. As such,
the housing 101 may form a portable device 101 for a health
monitoring and delivery system. As discussed previously with
reference to FIG. 3, some modules 300, such as the BGM 310, may be
incorporated into the device, while other modules, such as CGM 320
and the insulin delivery module 330, may be externally connected to
the portable device 101 through the communication interfaces 210.
The modules 300 connected to the digital engine 310 have access to
the interface
[0080] Systems employing the architecture support various types of
electronic networks and communications. Modules 300 may be
employed, for example, to provide cellular activity. Other
embodiments, alternatively or additionally, may employ global
positioning system (GPS) technology, which has become widely
accessible to civilian applications such as road navigation, people
tracking, and timing services. With the technology becoming more
and more mature, the cost of integrating this technology into
consumer products and medical device has been significantly
reduced. UPS receiver chipsets are currently available on market
and can be easily integrated with consumer or medical device to
provide information on device location, velocity and Universal
time. As such, GPS may be provided to enhance the functionality of
a system employing architecture to form an integrated system for
monitoring a health condition and/or delivering a medication.
[0081] With GPS, a diabetes-management system, for example, can
provide additional information associated with glucose tests.
Accurate timestamps and locations can be associated with readings.
The erroneous timestamps generated by conventional meters have been
the source of confusion and difficulty when readings from multiple
meters are downloaded and merged into one database file, or
uploaded to computers or web servers that do not have their local
time in sync with the meters. Patient movement and exercise can be
tracked automatically, facilitating patient logging effort
tremendously. The data may include distance and speed. This
information can be used for patient daily activity planning for
exercise, diet, medication and blood glucose test frequency, etc.
It also enables comprehensive analysis of correlation between
reading patterns and daily activities Furthermore, patients can be
located in emergencies.
[0082] The additional timing, location and physical activity
information obtained with UPS, combined with logged diet,
medication information, can assist the diabetes-management system
to make more accurate predictions on patients' daily blood glucose
patterns. The diabetes-management system can make real-time daily
activity recommendations that will help them to control their blood
glucose levels in the prescribed range. The system can then remind
patients to take the right number of tests daily at the right
moments.
[0083] Accordingly, GPS may be employed to synchronize a system's
device's real time clock (RTC) to UMT with high precision so that
glucose readings can be associated with correct timestamp. As power
for the GPS functionality may be a consideration, the GPS receiver
may only need to be activated once a day or a week depending on the
device crystal quality. Assuming that each time the GPS consumes
0.175 mAhr power (calculated based on Xemics XE1600 receiver using
Trimble chipsets), and the device takes a GPS measurement once a
day, 63.9 mAhr is consumed in a year for the GPS related
calculation which is roughly about 10-20% of a regular cell phone
battery capacity.
[0084] As discussed previously, some portable embodiments of an
integrated monitoring/delivery system may connect with a computing
device 370 for advanced data management. This situation provides
the opportunity for applying the NAVSYS GPS recorder model
(TrackTag) to the portable device to track patient movement and
activity. Because a GPS recorder simply takes snapshots of
satellite signals without processing them, a significant amount of
power can be saved. Assume the device takes a GPS snapshot once
every 150 sec, then in one year this GPS recorder only consumes
about 280 mAhr, which is roughly about <50% of a regular cell
phone battery capacity. If the device can stop taking snapshots at
night then further energy can be preserved. The trade off in using
the TrackTag approach is the required amount of on-device memory
required. Every snapshot takes about 15 kbyte, so at the above
snapshot rate, there will be about 200,000 snapshot per year which
requires about 3 Gbyte memory. Of course, once GPS data is
downloaded from the device to computer and processed, the device
memory can be freed up and reused. It seems that one Gbyte memory
may support 4 months of location tracking for the portable device.
Using modern flash memory technology, one Gbyte device memory can
be easily accommodated.
[0085] The GPS functionality may be a built-in central function. In
a more modular example, however, the GPS functionality may be
provided by a connected module, i.e. a detachable GPS receiver.
Indeed, if the GPS receiver module has its own memory to store time
and position information, then the GPS may not need to be connected
all the time with the DM device. The GPS receiver may be connected
with the system once a day or one every few days depending on how
often the device clock needs to be synchronized and also on the
availability of GPS receiver memory. Advantageously, the use of a
detachable GPS receiver module minimized the impact on
hardware/software design of the central engine 110 and other
aspects of the system. Moreover, power management is
facilitated.
[0086] While the invention is susceptible to various modifications
and alternative forms, specific embodiments and methods thereof
have been shown by way of example in the drawings and are described
in detail herein. It should be understood, however, that it is not
intended to limit the invention to the particular forms or methods
disclosed, but, to the contrary, the intention is to cover all
modifications, equivalents and alternatives falling within the
spirit and scope of the invention.
* * * * *