Patent Application
20120095313
The present disclosure relates to medical devices used for diabetes care and, more particularly, to extensibility for a system of medical devices used for diabetic care.
Diabetes mellitus, often referred to as diabetes, is a chronic condition in which a person has elevated blood glucose levels that result from defects in the body's ability to produce and/or use insulin. There are three main types of diabetes. Type 1 diabetes usually strikes children and young adults, and may be autoimmune, genetic, and/or environmental. Type 2 diabetes accounts for 90-95% of diabetes cases and is linked to obesity and physical inactivity. Gestational diabetes is a form of glucose intolerance diagnosed during pregnancy and usually resolves spontaneously after delivery.
In 2009, according to the World Health Organization, at least 220 million people worldwide suffer from diabetes. In 2005, an estimated 1.1 million people died from diabetes. Its incidence is increasing rapidly, and it is estimated that between 2005 and 2030, the number of deaths from diabetes will double. In the United States, nearly 24 million Americans have diabetes with an estimated 25 percent of seniors age 60 and older being affected. The Centers for Disease Control and Prevention forecast that 1 in 3 Americans born after 2000 will develop diabetes during their lifetime. The National Diabetes Information Clearinghouse estimates that diabetes costs $132 billion in the United States alone every year. Without treatment, diabetes can lead to severe complications such as heart disease, stroke, blindness, kidney failure, amputations, and death related to pneumonia and flu.
Diabetes is managed primarily by controlling the level of glucose in the bloodstream. This level is dynamic and complex, and is affected by multiple factors including the amount and type of food consumed, and the amount of insulin (which mediates transport of glucose across cell membranes) in the blood. Blood glucose levels are also sensitive to exercise, sleep, stress, smoking, travel, illness, menses, and other psychological and lifestyle factors unique to individual patients. The dynamic nature of blood glucose and insulin, and all other factors affecting blood glucose, often require a person with diabetes to forecast blood glucose levels. Therefore, therapy in the form of insulin or oral medications, or both, can be timed to maintain blood glucose levels in an appropriate range.
Management of diabetes is time-consuming for patients because of the need to consistently obtain reliable diagnostic information, follow prescribed therapy, and manage lifestyle on a daily basis. Diagnostic information, such blood glucose, is typically obtained from a capillary blood sample with a lancing device and is then measured with a handheld blood glucose meter. Interstitial glucose levels may be obtained from a continuous glucose sensor worn on the body. Prescribed therapies may include insulin, oral medications, or both. Insulin can be delivered with a syringe, an ambulatory infusion pump, or a combination of both. With insulin therapy, determining the amount of insulin to be injected can require forecasting meal composition of fat, carbohydrates and proteins along with effects of exercise or other physiologic states. The management of lifestyle factors such as body weight, diet, and exercise can significantly influence the type and effectiveness of a therapy.
Management of diabetes involves large amounts of diagnostic data and prescriptive data acquired in a variety of ways: from medical devices, from personal healthcare devices, from patient-recorded logs, from laboratory tests, and from healthcare professional recommendations. Medical devices include patient-owned bG meters, continuous glucose monitors, ambulatory insulin infusion pumps, diabetes analysis software, and diabetes device configuration software. Each of these systems generates and/or manages large amounts of diagnostic and prescriptive data. Personal healthcare devices include weight scales, blood pressure cuffs, exercise machines, thermometers, and weight management software. Patient recorded logs include information relating to meals, exercise and lifestyle. Lab test results include HbA1C, cholesterol, triglycerides, and glucose tolerance. Healthcare professional recommendations include prescriptions, diets, test plans, and other information relating to the patient's treatment.
Patients with diabetes and their healthcare professionals interact with a variety of medical devices and systems to help manage the disease. For each of these differing types of medical devices, there is a need to aggregate, manipulate, manage, present, and communicate diagnostic data and prescriptive data from multiple data sources in an efficient manner to improve the care and health of a person with diabetes, so the person with diabetes can lead a full life and reduce the risk of complications from diabetes. There is also a need to aggregate, manipulate, manage, present, and communicate such diagnostic data and prescriptive data amongst the different types of medical devices.
When designing an overall system for diabetes management or an application residing on a given medical device in the system, there is a further need to identify and implement extension points in the system to support future growth. The background description provided herein is for the purpose of generally presenting the context of the disclosure.
A handheld medical device is provided that supports system extensibility for diabetes care. The medical device is comprised of an application and a particular data structure that supports diabetes care. The data structure includes: a patient class that has attributes and methods associated with a person receiving medical treatment for diabetes; a patient log class that has a composition relationship with the patient class and attributes and methods that log actions taken by the patient; a treatment plan class that has a composition relationship with the patient class and attributes and methods that define a series of planned actions related to medical treatment of the patient; and an adherence class that has a composition relationship with the patient log class and attributes and methods define relationships between actions planned for the patient and actions taken by the patient. The application instantiates an object from at least one of the patient log class, the adherence class and the treatment plan class and performs a function using the instantiated object.
Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the disclosure.
The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations, and are not intended to limit the scope of the present disclosure. Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.
Referring now to
During a healthcare consultation, the patient 100 typically shares with the clinician 102 a variety of patient data including blood glucose measurements, continuous glucose monitor data, amounts of insulin infused, amounts of food and beverages consumed, exercise schedules, and other lifestyle information. The clinician 102 may obtain additional patient data that includes measurements of HbA1C, cholesterol levels, triglycerides, blood pressure, and weight of the patient 100. The patient data can be recorded manually or electronically on a handheld diabetes management device 104, a diabetes analysis software executed on a personal computer (PC) 106, and/or a web-based diabetes analysis site (not shown). The clinician 102 can analyze the patient data manually or electronically using the diabetes analysis software and/or the web-based diabetes analysis site. After analyzing the patient data and reviewing adherence of the patient 100 to previously prescribed therapy, the clinician 102 can decide whether to modify the therapy for the patient 100.
Referring now to
The diabetes manager 104 performs various tasks including measuring and recording blood glucose levels, determining an amount of insulin to be administered to the patient 100 via the insulin pump 202 or 204, receiving patient data via a user interface, archiving the patient data, etc. The diabetes manager 104 periodically receives readings from the CGM 200 indicating glucose level in the interstitial fluid of the patient 100. The diabetes manager 104 transmits instructions to the insulin pump 202 or 204, which delivers insulin to the patient 100. Insulin can be delivered in a scheduled manner in the form of basal (background) doses, which consists of multiple small doses of insulin to the patient 100 over an extended period (e.g., a day). Additionally, insulin can be delivered in the form of a bolus dose, which delivers a single larger quantity of insulin to the patient 100 to adjust for a particular situation (e.g., eating a meal).
Referring now to
The diabetes manager 104 can receive glucose readings from one or more sources (e.g., from the CGM 200). The CGM 200 continuously measures the glucose level in the abdominal interstitial fluid of the patient 100. The CGM 200 periodically communicates the readings to the diabetes manager 104. The diabetes manager 104 and the CGM 200 communicate wirelessly using a proprietary Gazell wireless protocol developed by Nordic Semiconductor, Inc.
Additionally, the diabetes manager 104 includes a blood glucose meter (BGM) and a port that communicates with the BGM (not shown). The port can receive a blood glucose measurement strip 306. The patient 100 deposits a sample of blood on the blood glucose measurement strip 306. The BGM analyzes the sample and measures the blood glucose level in the sample. The blood glucose level measured from the sample can be used to calibrate the interstitial glucose level from the CGM 200 in order to estimate a BG value from a CGM value. BG values can be used to determine the amount of insulin to be administered to the patient 100.
The diabetes manager 104 communicates with the insulin pump 202 or 204. The insulin pump 202 or 204 can be configured to receive instructions from the diabetes manager 104 to deliver a user-determined amount of insulin to the patient 100. Additionally, the diabetes manager 104 can receive other information including meal and/or exercise schedules of the patient 100 and use these to determine the amount of insulin to administer using insulin pump 202 or 204 based on the additional information.
The insulin pump 202 or 204 can also communicate data to the diabetes manager 104. The data can include amounts of insulin delivered to the patient 100, corresponding times of delivery, and pump status. The diabetes manager 104 and the insulin pump 202 or 204 can communicate using a wireless communication protocol such as Bluetooth. Other wireless or wireline communication protocols can also be used.
In addition, the diabetes manager 104 can communicate with the other healthcare devices 304. For example, the other healthcare devices 304 can include a blood pressure meter, a weight scale, a pedometer, a fingertip pulse oximeter, a thermometer, etc. The other healthcare devices 304 obtain and communicate personal health information of the patient 100 to the diabetes manager 104 through wireless, USB, or other interfaces. The other healthcare devices 304 may use communication protocols compliant with ISO/IEEE 11073 extended using guidelines from Continual® Health Alliance. The diabetes manager 104 can communicate with the other healthcare devices 304 using interfaces including Bluetooth, USB, etc. Further, the devices of the diabetes management system 300 can communicate with each other via the diabetes manager 104.
The diabetes manager 104 can communicate with the PC 106 using Bluetooth, USB, or other interfaces. A diabetes management software running on the PC 106 includes an analyzer-configurator that stores configuration information of the devices of the diabetes management system 300. The configurator has a database to store configuration information of the diabetes manager 104 and the other devices. The configurator can communicate with users through standard web or computer screens in non-web applications. The configurator transmits user-approved configurations to the devices of the diabetes management system 300. The analyzer retrieves data from the diabetes manager 104, stores the data in a database, and outputs analysis results through standard web pages or computer screens in non-web based applications.
The diabetes manager 104 can communicate with the mobile device 302 using Bluetooth. The mobile device 302 may include a cellular phone, a pager, or a personal digital assistant (PDA). The diabetes manager 104 can send messages to an external network through the mobile device 302. The mobile device 302 can transmit messages to the external network upon receiving requests from the diabetes manager 104.
Referring now to
The processing module 408 processes data received from the BGM module 400, the communication module 402, and the user interface module 404. The processing module 408 uses memory 410 for processing and storing data. The memory 410 can include volatile and nonvolatile memory. The processing module 408 outputs data to and receives data from the user interfaces 406 via the user interface module 404. The processing module 408 outputs data to and receives data from the devices of the diabetes management system 300 via the communication module 402. The power module 412 supplies power to the components of the diabetes manager 104. The power module 412 includes a rechargeable battery. The battery can be recharged using an adapter that plugs into a wall outlet. The battery can also be charged via the USB port of the diabetes manager 104.
A domain model has two primary uses. First, a shared domain model insures that stakeholders and developers are thinking about the problem at hand in the same way and using the same terminology. Second, a domain model is used for identifying variability for architecture and design. Since a domain model is expressed in terms of the application area, variability points identified in the model are more likely to have business value. When technical architects and designers are aware of this predicted variability, they are better able to produce designs that will evolve in ways useful to the business. In this disclosure, the diabetes care information management domain model 50 is used to identify business-relevant extension points for a computer-implemented diabetes care system.
First, a discussion is provided to clarify what is meant by extensibility and extension points. There are several meaningful ways to define extensibility. For the purpose of this disclosure, four types of extensibility are specifically defined for software and firmware: design extensible, compile-time extensible, run-time extensible and dynamically extensible.
A particular architecture or design is design extensible relative to a domain concept X if a new variant or member of X can be added to the system without requiring any re-design, where “re-design” is any change that requires a revision any of the system's architecture or high-level design documents. Design extensibility is the simplest version of extensibility. Note that under this definition, requiring a complete system re-build or even substantial code changes is permitted, as is added detailed design documentation for new elements.
A particular architecture or design is compile-time extensible relative to a domain concept X if it is design extensible relative to X and if adding a new variant or member for X can be done by a) adding code for the new member/variant and b) adding code in one place to include the new member/variant and c) recompiling all or part of the system.
A particular architecture or design is run-time extensible relative to a domain concept X if it is design extensible relative to X and if adding a new variant or member for X can be done by building a new module, locating it in a design-specified place, and modifying a manifest or other (non-code) configuration information. Run-time extensibility may require that the system be re-started before the new concept is visible in the system. Note that run-time extensibility does not require compile-time extensibility; these two extensibility methods are mutually exclusive.
For completeness, a definition for dynamic extensibility is included, which is characteristic of service-oriented architectures with service discovery. A particular architecture or design is dynamically extensible relative to a domain concept X if it is design extensible relative to X and if adding a new variant or member for X can be done dynamically while the system remains running.
Extensibility typically requires an explicit representation of the identified concept. In an exemplary embodiment, the diabetes management system 300 is implemented using an object-oriented programming paradigm. In an object-oriented system, the explicit representation will be a class. Such abstractions should be isolated to a component intended for abstractions (i.e., not mixed with implementations). In this disclosure, the class diagrams are defined in accordance with the Unified Modeling Language (UML).
While this disclosure makes reference primarily to an object-oriented programming paradigm, it is readily understood that other types of implementations fall within the scope of this disclosure. For example, the diabetes management system 300 may be implemented using functional designs. In functional designs, the explicit representation will typically be as a structure (record) type, with functions that work on that type isolated to a single module or component. If code that knows about a type is scattered across multiple modules, this is a sign that the given structure is not extensible. In a functional implementation, the header files declaring the structure type and externally-visible functions operating on that type should be isolated. Other types of implementations of the system are also contemplated.
The medication administered class 611 records the administration of medicine to the patient. The medication class 612 is associated with the medication administration class (i.e., each medication administration object has a relationship to a medication object for the medication that was taken by the patient). Supporting new types of medication is an identified extension point. Accordingly, the medication catalog class 613 has a composition relationship with the medication class 612; the medication catalog class 613 does not know anything about the contents of this composition except that they embody the medication concept. Supporting new ways to calculate dosages for a given medication is another identified extension point. Thus, the medication class further includes a method that calculates a dosage of the medication to be administered to the patient (e.g., a bolus insulin dosage calculation).
The physiological state variable entry class 614 refers to an input of a value of a physiological state variable such as blood glucose or a patient's wake/sleep state. Supporting new types of physiological state variables in the system is another identified extension point. Accordingly, the patient class 601 has a composition relationship with the physiological state variable class 610; the patient class 601 does not know anything about the contents of this composition except that they embody the physiological state variable concept. For example, the glycemic index is a measure of how much your blood glucose level swings up and down. Supporting such physiological variables and methods for calculating the same are anticipated in future developments. Extensibility for these types of new variables is supported by defining a new subclass or instance of physiological state variable class 610. Determining the value of a physiological state variable from date in the patient log 602 is a defined extension point. Thus the physiological state variable class 610 further has a method for determining its value at a particular date and time.
The food intake class 616 represents food the patient has consumed. Food intake is associated with a meal object, which aggregates food items. Supporting new types of food in the system is another identified extension point. Accordingly, the food catalog class 618 has a composition relationship with food items; the food catalog class 618 does not know anything about the contents of this composition except that they embody the food item concept. New calculation logic associated with food items is also an identified extension point. For example, the rate at which foods introduce glucose into the bloodstream depends in part on the fat content of the food; new calculation logic for food items could include (but is not limited to) the duration over which the carbohydrate content should be distributed when making predictions.
An important aspect of a treatment plan is the capability to define the conditions that trigger one of the planned actions. A reminder to take a given medication based on the time of day or a reminder to perform a test based on a time interval since a given meal are examples of triggers. Supporting new types of triggers is an identified extension point. Accordingly, the trigger catalog class 708 has a composition relationship with the treatment plan trigger class 706; the trigger catalog class 708 does not know anything about the contents of this composition except that they embody the treatment plan concept. Actions in a treatment plan are instances of the planned action class 704; each such action is associated with a trigger from the trigger catalog. In an exemplary embodiment, the diabetes management system 300 provides run-time extensibility for ne types of triggers in the manger set forth below. New ways to compute trigger conditions are an identified extension point. Thus the trigger class 706 further has a method for determining whether the trigger holds at a particular date and time.
A structured test plan is a particular type of treatment plan defined in the diabetes care domain. For example, a structured test plan may be a series of planned actions for obtaining measurement data from a glucose meter. In addition to a series of planned actions, the structured test plan includes attributes such as an entry criterion, an adherence criterion and an exit criterion. Entry criteria establish the conditions that need to be met prior to obtaining a physiological variable measure from the patient; this corresponds to the trigger class 706. Adherence criteria are used to assess qualitatively whether a planned action was performed. Exit criterian establish the conditions needed to be met prior to exiting the structured test plan.
Adherence information for the patient may be managed using an adherence class 702 as shown in
Extensibility requires that an explicit representation of the extensible concept can be modified in some way that does not impact the design. In object-oriented systems, this is typically done with inheritance or with a container class referencing an interface. In functional systems, this can be done with a union structure or function pointers, or at worst with untyped pointers. Other techniques for changing the explicit representation are also contemplated by this disclosure.
For run-time extensibility, the system needs to be able to access software modules that were not implemented when the system was initially built. In the exemplary embodiment, the system has been implemented on devices which utilize the Microsoft Windows CE operating system. Thus, dynamic link loading is used by the system to access new software modules or libraries. In other computing environments, an interpreter or some other form of remote call may be used to access new software modules at run-time.
With reference to
At system start up, the application will instantiate one or more objects in the Parameter container class by referencing the ‘IParameter’ interface. For example, the application may make use of Parameter X. This new device parameter as defined in the manifest will be validated against the ‘IParameter’ interface. The new device parameter is instantiated as an object in the Parameter container class only if the new device parameter meets the criteria set forth by the interface. In this way, extensibility of new data types may be supported in the system. Instantiating new objects in this manner is one exemplary means of instantiating objects using a single coded list, such as a manifest, in a computer memory. Other means for instantiating objects using a single coded list also fall within the scope of this disclosure.
In an exemplary embodiment, a handheld medical device that supports extensibility for diabetes care would be set up as follows. First, an instance of the patient class with collections (compositions) for patient logs, physiological state variables, and treatment plans is created. Similarly, an instance of the medication catalog, trigger catalog and root capability will be created with collections for medications, treatment plan triggers, and child capabilities, respectively. Base classes for logged actions and adherence would also exist in the default configuration, but may not have instances in the initial (default) setup. Constructs for and the relationships amongst these classes are set forth above. In one implementation, extensibility requirements are enforced through inheritance. For example, all members of the patient object's physiological state variables collection would be derived from a common physiological state variable base class. In addition to those discussed above, it is readily understood that the device may be configured with other classes needed to support the functionality of the device.
The medical device is preferably configured with a meter that measures concentration of glucose in blood or some other type of measurement component (which may be no more than a way for users to manually enter a measurement value). The medical device further includes at least one application that utilizes the class structure. More specifically, the application instantiates an object from at least one of the patient class, the patient log class, the treatment plan class and the adherence class and performs a function using the instantiated objects. In the exemplary embodiment, the application is comprised of computer executable instructions executed by a computer processor in the device. While the extensibility configuration has been described in the context of a single medical device, it is understood that these principles apply to a diabetes management system distributed across multiple devices and/or having multiple software applications.
In another implementation, extensibility requirements are enforced by implementing select classes as container classes referencing an interface as described above. For example, the patient class would have containers for treatment plans and physiological state variables. In this example, a treatment plan interface a physiological state variable interface are also defined in the memory of the device. The treatment plan interface is an abstraction class that specifies the methods and properties that any member of the treatment plans collection must support. As shown in
For purposes of clarity, the same reference numbers will be used in the drawings to identify similar elements. As used herein, the phrase at least one of A, B, and C should be construed to mean a logical (A or B or C), using a non-exclusive logical or. It should be understood that steps within a method may be executed in different order without altering the principles of the present disclosure.
As used herein, the term module may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC); an electronic circuit; a combinational logic circuit; a field programmable gate array (FPGA); a processor (shared, dedicated, or group) that executes code; other suitable components that provide the described functionality; or a combination of some or all of the above, such as in a system-on-chip. The term module may include memory (shared, dedicated, or group) that stores code executed by the processor.
The term code, as used above, may include software, firmware, and/or microcode, and may refer to programs, routines, functions, classes, and/or objects. The term shared, as used above, means that some or all code from multiple modules may be executed using a single (shared) processor. In addition, some or all code from multiple modules may be stored by a single (shared) memory. The term group, as used above, means that some or all code from a single module may be executed using a group of processors. In addition, some or all code from a single module may be stored using a group of memories.
The apparatuses and methods described herein may be implemented by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions that are stored on a non-transitory tangible computer readable medium. The computer programs may also include stored data. Non-limiting examples of the non-transitory tangible computer readable medium are nonvolatile memory, magnetic storage, and optical storage.
