HK1178991A - System and method for determining drug administration information - Google Patents

Description

System and method for determining drug administration information

The application is a divisional application of an invention patent application with an application date of 2006, 12/4 and an application number of 200680052471.0, entitled "system and method for determining drug administration information".

Cross reference to related applications

This application claims priority from U.S. patent application No.11/297,733, filed on 8/12/2005, the disclosure of which is incorporated herein by reference in its entirety.

Technical Field

The present invention relates generally to techniques for determining drug administration information (drug administration information), and more particularly to systems for determining insulin administration information based on user input of user-related feed forward information.

Background

There are many diabetes control devices that are configured to recommend or automatically administer insulin boluses of different types, different quantities, and/or different dosing intervals based on a certain amount of feed forward information provided by the user. It is desirable to simplify the content and minimize the amount of feed forward information that is required to be provided by the user in determining the bolus information.

Disclosure of Invention

The invention may comprise one or more of the features defined in the appended claims, and/or one or more of the features described below, and combinations thereof. A system for determining drug administration information may include an input device for user input of feed forward information having a first parameter component and a second parameter component, and a data storage device and a processor. The data storage device may have stored therein a map that associates values of the first and second parameters with drug administration information. The processor may be responsive to user input of the feed forward information to determine corresponding drug administration information from the mapping.

The system may further comprise a display unit. The processor may be configured to display at least a portion of the corresponding medication administration information on the display unit. The processor may be configured to control the display unit to display a graphical user interface having a first axis defined by values of a first parameter and a second axis defined by values of a second parameter. The graphical user interface may be used for user input of feed forward information in the form of a single user selection of a corresponding pair of first and second parameter values.

The graphical user interface may include a touch responsive interface for a single user selection of a corresponding pair of the first and second parameter values.

The graphical user interface may define a grid-type user interface for individual user selection of pairs of first and second parameter values that are discrete from one another. Alternatively, the graphical user interface may define a continuous function of the values of the first and second parameters.

The drug may be a blood glucose lowering drug. For example, the drug may be insulin. The input means may be arranged for user input of feed forward information in the form of meal information having a first parameter component corresponding to the carbohydrate content of the meal and a second parameter component corresponding to the expected speed of overall glucose absorption from the meal by the user. The input device may include a display unit and the processor may be configured to control the display unit to display a graphical user interface having a first axis defined by carbohydrate content values and a second axis defined by expected speed values for total glucose absorption from a meal by a user. The graphical user interface may be used for user input of feed forward information in the form of a single user selection of a corresponding pair of carbohydrate content and expected speed values.

The processor may be arranged to control the display unit to display the carbohydrate content values in the form of a direct estimate of carbohydrate weight. Alternatively, the processor may be arranged to control the display unit to display said carbohydrate content value in the form of a meal size value. Alternatively still, the processor may be configured to control the display unit to display the carbohydrate content value in the form of a meal size value relative to a reference meal size.

The processor may be arranged to control the display unit to display the expected speed value in the form of a meal duration. Alternatively, the processor may be arranged to control the display unit to display the expected speed value in the form of a meal duration relative to a reference meal duration. Still alternatively, the processor may be arranged to control a display unit to display the expected speed value in the form of a total glycemic index value.

The processor may be configured to control the display unit to display a graphical user interface having a first axis defined by values of carbohydrate content and a second axis defined by values of expected speed of overall glucose absorption from the meal by the user. The graphical user interface may be used for user input of feed forward information in the form of user selection of corresponding pairs of carbohydrate content and expected speed values. The processor may be arranged to control the display unit to display the expected speed values in the form of a fat amount, a protein amount and a carbohydrate amount, and to display the carbohydrate content values in the form of meal size values for each of the fat amount, protein amount and carbohydrate amount. The graphical user interface may be used for user input of feed forward information in the form of user selection of meal size values in terms of fat amount, meal size values in terms of protein mass, and meal size values in terms of carbohydrate amount. Alternatively, the processor may be arranged to control the display unit to display the meal size values in the form of a fat amount, a protein amount and a carbohydrate amount relative to reference meal size values in terms of fat, protein and carbohydrate amounts, respectively.

The input means may be arranged for user input of additional feed forward information in the form of training information. In this case, the data storage device may have stored therein an additional mapping that associates the training information with the correction information, and the processor may be responsive to user input of the training information to correct the corresponding administration information based on the correction information determined by the additional mapping.

The input means may be arranged for user input of additional feed forward information in the form of user stress information. In this case, the data storage device may have stored therein an additional map associating the user stress information with the correction information, and the processor may be responsive to user input of the user stress information to correct the corresponding administration information in accordance with the correction information determined by the additional map.

The input means may be arranged for user input of additional feed forward information in the form of user disease information. In this case, the data storage device may have stored therein an additional map associating the user disease information with the correction information, and the processor may be responsive to user input of the user disease information to correct the corresponding medication administration information based on the correction information determined by the additional map.

The input means may be arranged for user input of additional feed forward information in the form of user menstrual cycle information. In this case, the data storage device may have stored therein an additional map associating the user menstrual cycle information with the correction information, and the processor may be responsive to user input of the user menstrual cycle information to correct the corresponding medication administration information in accordance with the correction information determined by the additional map.

The processor may be configured to monitor for user acceptance and rejection of the occurrence of the medication administration information determined from the mapping and determine whether the system is acceptable for use by the user based at least in part on the user acceptance and rejection of the occurrence of the medication administration information, the processor may be configured to further determine whether the system requires recalibration based at least in part on the user acceptance and rejection of the occurrence of the medication administration information.

The system may further comprise means for input of user feedback information. The processor may be configured to monitor user feedback information and determine whether the system is acceptable for use by a user based at least in part on the user feedback information. If the processor determines that the system is acceptable for use by the user, the processor may be configured to further determine whether the system requires recalibration based at least in part on the user feedback information.

The system may further comprise means for input of health care professional feedback information. The processor may be configured to monitor the healthcare professional feedback information and determine whether the system is acceptable for use by the user based at least in part on the healthcare professional feedback information. If the processor determines that the system is acceptable for use by the user, the processor may be configured to further determine whether the system requires recalibration based at least in part on the healthcare professional feedback information.

The system may further comprise at least one model-based function responsive to the measurement of one or more user conditions to estimate another user condition different from the one or more user conditions described above. The processor may be configured to monitor the at least one model-based function and determine whether the system is acceptable for use by a user based at least in part on the at least one model-based function. If the processor determines that the system is acceptable for use by a user, the processor may be configured to further determine whether the system requires recalibration based at least in part on the at least one model-based function.

A method of determining drug administration information may include receiving a single user input of feed forward information, wherein the feed forward information includes user-specific values for a first parameter and a second parameter. The method may further include associating the first and second parameters with administration information.

The method may further comprise displaying at least a portion of the administration information on a display unit.

Associating the first and second parameters with the medication administration information may comprise processing the first and second parameters using a mapping arranged to map the first parameter value and the second parameter value to the respective medication administration information.

The input means for receiving a single user input of the feed forward information may comprise receiving a single user input of the feed forward information through a graphical user interface, wherein the graphical user interface may have a first axis defined by a first parameter value and a second axis defined by a second parameter value.

The drug may be a blood glucose lowering drug. For example, the drug may be insulin. The first parameter may correspond to the carbohydrate content of the meal and the second parameter may correspond to an expected speed of overall glucose absorption from the meal by the user.

The first parameter value may be displayed on the graphical user interface in the form of a carbohydrate weight. Alternatively, the first parameter value may be displayed in the graphical user interface in the form of a meal size value. Still alternatively, the first parameter value may be displayed on the graphical user interface in the form of a meal size value relative to a reference meal size.

The second parameter value may be displayed on the graphical user interface in the form of a meal duration value. Alternatively, the second parameter value may be displayed on the graphical user interface in the form of a meal duration relative to a reference meal duration. Still alternatively, the second parameter value may be displayed in the graphical user interface in the form of a total glycemic index value.

The values of the second parameter component may be displayed on the graphical user interface in the form of a fat amount, a protein amount and a carbohydrate amount. The value of the first parameter component may be displayed on the graphical user interface in the form of meal size values for each of the fat amount, the protein amount and the carbohydrate amount. The first parameter value may be displayed on the graphical user interface in the form of a meal size value for each of the fat amount, the protein amount, and the carbohydrate amount relative to a reference meal size value for each of the fat amount, the protein amount, and the carbohydrate amount, respectively.

In embodiments where the first parameter corresponds to the carbohydrate content of the meal and the second parameter corresponds to the expected speed of overall glucose absorption from the meal by the user, the method may further comprise receiving a single user input of additional feed forward information including user training information, and modifying the dosing information in accordance with the user training information. Alternatively or additionally, the method may further include receiving a single user input of additional feed forward information including user stress information and modifying the drug administration information based on the user stress information. Alternatively or additionally still, the method may further include receiving a single user input of additional feed forward information including user disease information and modifying the drug administration information based on the user disease information. Alternatively or additionally still, the method further includes receiving a single user input of additional feed forward information including user menstrual cycle information and modifying the drug administration information based on the user menstrual cycle information.

The method may further include monitoring for the occurrence of user acceptance or rejection of the medication administration information determined from the mapping, and determining whether the system is acceptable for use by the user based at least in part on the occurrence of user acceptance and rejection of the medication administration information. If the method is acceptable for use by a user, the method may further include the following: determining whether a recalibration of the method is required based at least in part on the occurrence of user acceptance and rejection of the administration information.

The method may alternatively or additionally include monitoring user feedback information that is different from the feed forward information and determining whether the method is acceptable for use by the user based at least in part on the user feedback information. If the method is acceptable for use by a user, the method may further include the following: determining whether a recalibration of the method is required based at least in part on the user feedback information.

The method may alternatively or additionally include monitoring healthcare professional feedback information and determining whether the method is acceptable for use by the user based at least in part on the healthcare professional feedback information. If the method is acceptable for use by a user, the method may further include the following: determining whether a recalibration of the method is required based at least in part on the healthcare professional feedback information.

The method may alternatively or additionally include defining at least one model-based function that estimates other user conditions different from the one or more user conditions in response to measurements of the one or more user conditions, and determining whether the method is acceptable for user use based at least in part on the at least one model-based function. If the method is acceptable for use by a user, the method may further include the following: determining whether a recalibration of the method is required based at least in part on the at least one model-based function.

A method of determining patient compliance for a graphical user interface configured to allow a patient to select feed forward information from which to determine drug administration information may be provided. The method may include collecting patient-related information relating to an event defined as any of a number of feed forward information and corresponding drug administration information. The method may further comprise processing said collected patient-related information to determine whether one or more regular patterns in the patient-related information can be identified, which may allow for an acceptable prediction of an appropriate value of said drug administration information based on a corresponding category of said feed forward information. If one or more regular patterns in the patient-related information can be identified, the method may further include processing the collected patient-related information to determine whether the number of feed forward information categories can be reduced. If the number of feed forward information categories can be reduced, the method can further include reducing the number of feed forward information categories.

The step of processing the collected patient-related information to determine whether one or more regular patterns in the patient-related information can be identified may include classifying the patient-related information according to at least one variable of the patient-related information and aggregating the patient-related information over all remaining variables of the patient-related information. The step of processing the collected patient-related information to determine whether one or more regular patterns in the patient-related information can be identified may further comprise calculating a variable coefficient for the patient-related information relating to the at least one variable. The step of processing the collected patient-related information to determine whether one or more regular patterns in patient-related information can be identified may further comprise determining that the patient-related information classified by at least one variable allows for an acceptable prediction of an appropriate value of drug administration information based on a corresponding category of the feed forward information if a coefficient of variation of the patient-related information related to the at least one variable does not exceed a maximum coefficient of variation. Processing the collected patient-related information to determine whether one or more regular patterns in the patient-related information can be identified may further comprise performing the following steps if a coefficient of variation of the patient-related information related to the at least one variable exceeds a maximum coefficient of variation: classifying the patient-related information according to at least one variable of the patient-related information and according to at least another variable of the patient-related information, and aggregating the patient-related information over all remaining variables of the patient-related information, calculating a variate coefficient of the patient-related information relating to the at least one variable and the at least another variable, and determining that the patient-related information classified with the at least one variable and the at least another variable allows an acceptable prediction of an appropriate value of the drug administration information based on the kind of the corresponding feed forward information, if the variate coefficient of the patient-related information relating to the at least one variable and the at least another variable does not exceed a maximum variate coefficient. Processing the collected patient-related information to determine whether one or more regular patterns in the patient-related information can be identified may further comprise performing the following steps if any of the coefficients of the variables of the patient-related information relating to the at least one variable and the at least one further variable exceeds a maximum coefficient of the variables: the classifying, calculating and determining steps are performed using the iterative preferred set of patient-related information until all of the corresponding number of coefficients of the variable do not exceed the maximum coefficient of the variable.

The step of processing the collected patient-related information to determine whether the number of categories of feed forward information can be reduced may comprise determining a merging scheme for all categories of feed forward information. The step of processing the collected patient-related information to determine whether the number of categories of feed forward information can be reduced may further comprise analyzing the respective merging scenarios to determine whether feed forward categories can be merged according to the merging scenarios. The step of processing the collected patient-related information to determine whether the number of categories of feed forward information can be reduced may further comprise selecting an optimal merging scenario from the various merging scenarios having feed forward categories that can be merged. The step of processing the collected patient-related information to determine whether the number of categories of feed forward information can be reduced may further comprise merging feed forward categories according to an optimal merging scheme. The step of processing the collected patient-related information to determine whether the number of categories of feed forward information may be reduced may comprise performing the determining, analyzing, selecting and combining steps for each of one or more regular patterns in the patient-related information.

The method may further include pre-screening the patient to determine if the patient is an acceptable candidate for the graphical user interface. The method may further comprise performing the collecting step, the two processing steps and the reducing step only if the patient is an acceptable candidate for the graphical user interface.

The method may further include creating a mapping that maps the patient-selectable categories of feed forward information to corresponding drug administration information, and implementing the mapping with the graphical user interface.

The method may further include monitoring for the user's acceptance or rejection of the occurrence of the medication administration information determined from the mapping, and determining whether the graphical user interface is acceptable for use by the user based at least in part on the user's acceptance and rejection of the occurrence of the medication administration information. If the graphical user interface is acceptable for use by a user, the method may further comprise the steps of: determining whether the graphical user interface requires recalibration based at least in part on the occurrence of user acceptance and rejection of the medication administration information.

The method may alternatively or additionally include monitoring user feedback information other than the feed-forward information and determining whether the graphical user interface is acceptable for use by the user based at least in part on the user feedback information. If the graphical user interface is acceptable for use by a user, the method may further comprise the steps of: determining whether the graphical user interface requires recalibration based at least in part on the user feedback information.

The method may alternatively or additionally include monitoring healthcare professional feedback information and determining whether the graphical user interface is acceptable for use by the user based at least in part on the healthcare professional feedback information. If the graphical user interface is acceptable for use by a user, the method may further comprise the steps of: determining whether the graphical user interface requires recalibration based at least in part on the healthcare professional feedback information.

The method may alternatively or additionally include defining at least one model-based function, estimating another user condition in response to a measurement of one or more user conditions, the condition being different from the one or more user conditions described above, and determining whether the graphical user interface is acceptable for user use based at least in part on the at least one model-based function. If the graphical user interface is acceptable for use by the user, the method may further include: determining whether a recalibration of the graphical user interface is required based at least in part on the at least one model-based function.

The event defined with the feed forward information may be a meal ingested by the patient and the medication may be a blood glucose lowering medication. The events defined by the feed forward information may further include training experienced by the patient. Alternatively or additionally, the events defined with the feed forward information may further include the pressure experienced by the patient. Alternatively or additionally, the events defined with the feed forward information may further include a disease experienced by the patient. Alternatively or additionally, the event defined with the feed forward information may further include the menstrual cycle of the patient.

The event defined with the feed forward information may be a training event experienced by the patient and the drug may be a hypoglycemic drug.

The event defined with the feed forward information may be a stress event experienced by the patient and the drug may be a hypoglycemic drug.

The event defined with the feed forward information may be a disease event experienced by the patient, and the drug may be a hypoglycemic drug.

The event defined with the feed forward information may be a menstrual event experienced by the patient, and the drug may be a hypoglycemic drug.

Drawings

The present invention will be better understood and other objects of the invention, in addition to those set forth above, will become more clearly apparent in view of the following detailed description of the invention. The detailed description makes reference to the accompanying drawings, in which:

FIG. 1 is a block diagram of one exemplary embodiment of a system for determining medication administration information.

Fig. 2 illustrates an embodiment of a graphical user interface for inputting meal-related information to the system of fig. 1.

Fig. 3 illustrates another embodiment of a graphical user interface for inputting meal-related information to the system of fig. 1.

Fig. 4 illustrates another embodiment of a graphical user interface for inputting meal-related information to the system of fig. 1.

Fig. 5 illustrates another embodiment of a graphical user interface for inputting meal-related information to the system of fig. 1.

Fig. 6 illustrates yet another embodiment of a graphical user interface for inputting meal-related information to the system of fig. 1.

Fig. 7 illustrates another embodiment of a graphical user interface for inputting meal-related information to the system of fig. 1.

Fig. 8 is an embodiment illustrating a software algorithm executable by the system of fig. 1 for determining medication administration information based on user input of meal information entered using one of the graphical user interfaces of fig. 2-7.

FIG. 9 is a table illustrating one embodiment of a map that associates user input of meal information provided in the form of carbohydrate content, e.g., meal size, and expected absorption of sugar and duration, e.g., meal duration, with corresponding administration information.

Fig. 10 is a flow chart of an exemplary method for determining patient or user compliance using a graphical user interface of the kind shown in fig. 2-7.

Fig. 11 is an extension of the flowchart of fig. 10.

Fig. 12 is an extension of the flow chart of fig. 10 and 11.

Fig. 13 is a table illustrating one embodiment of a patient log for collecting patient-related information in accordance with the method shown in fig. 10-12.

Fig. 14A-14K are exemplary histograms of certain patient-related information versus insulin bolus doses classified according to various methods of one embodiment of the statistical analysis step in the method of fig. 10.

FIG. 15 is a flow diagram of an exemplary embodiment of a continuous learning method.

Detailed Description

For the purposes of promoting an understanding of the principles of the invention, reference will now be made to a number of exemplary embodiments illustrated in the attached drawings and specific language will be used to describe the same. It is understood that in this document, the terms "user" and "patient" are used interchangeably.

Referring now to fig. 1, a block diagram of one exemplary embodiment of a system 10 for determining medication administration information is shown. In the illustrated embodiment, the system 10 includes an electronic device 12 having a processor 14 in data connection with a memory unit 16, an input device 18, a display 20, and a communication input/output unit 24. The electronic device 12 may be provided in the form of a general purpose computer, a central server, a Personal Computer (PC), a laptop or notebook computer, a Personal Digital Assistant (PDA) or other handheld device, an external infusion pump, a blood glucose meter, an analytical sensing system, or the like. The electronic device 12 may be configured to operate in accordance with one or more commonly used operating systems, including, for example, but not limited to, windows, linux, and Mac OS and embedded OS such as QNX, eCOS, WinCE, and palm OS, and may be configured to process data in accordance with one or more commonly used internet protocols, such as, but not limited to, NetBios, TCP/IP, and AppleTalk. In any case, the electronic device 12 forms part of a fully closed-loop, semi closed-loop, or open-loop diabetes control system, examples of which are described below. In the illustrated embodiment, the processor 14 is microprocessor-based, although the processor 14 may alternatively be formed from one or more general-purpose and/or application-specific circuits and operate as described below. In the illustrated embodiment, the memory unit 16 includes sufficient memory capacity to store data, one or more software algorithms executed by the processor 14, and other data. The memory unit 16 may include one or more conventional memories or other data storage devices.

The input device 18 may be used in a conventional manner to input and/or modify data. In the illustrated embodiment, the display 20 is also included for viewing information related to the operation of the device 12 and/or the system 10. The display may be a conventional display device including, but not limited to, a Light Emitting Diode (LED) display, a Liquid Crystal Display (LCD), a Cathode Ray Tube (CRT) display, or the like, for example. Alternatively or additionally, the display 20 may be or include an audible display configured to convey information to a user, other person, or other electronic system having audio recognition capabilities via one or more coded patterns, vibrations, synthesized voice responses, or the like. Alternatively or additionally, the display 20 may be or include one or more tactile indicators configured to display tactile information that may be recognized by a user or others.

In one embodiment, the input device 18 may be or include a conventional keyboard or keypad for entering alphanumeric data into the processor 14. The keyboard or keypad may include one or more keys or buttons arranged with one or more tactile indicators to enable a user with poor eyesight to find and select the appropriate one or more keys and/or to enable a user to find and select the appropriate one or more keys in poor lighting conditions. Alternatively or additionally, the input device 18 may be or include a conventional mouse or other conventional pointing device for selecting information represented on the display 20. Alternatively or additionally, the input device 18 may include a display 20 configured as a Graphical User Interface (GUI). In this embodiment, the display 20 may include one or more selectable inputs that the user may select by contacting the appropriate portion of the display 20 with an appropriate tool. Alternatively or additionally, the input device 18 may include a plurality of switches or keys that may be activated by a user to select corresponding operating features of the device 12 and/or the system 10. Alternatively or additionally, the input device 18 may be or include voice activated circuitry responsive to voice commands to provide corresponding input data to the processor 14. In any case, the input device 18 and/or display 20 may be included within the electronic device 12 or separate from the device, as indicated by dashed lines 22A and 22B.

In certain embodiments, the system 10 may include a number, N, of medical devices 26₁－26_NWhere N may be any positive integer. In such embodiments, the one or more medical devices 26₁－26_NEither of which may be implanted in the user's body, externally connected to the user's body (e.g., such as an infusion pump), or separate from the user's body. Alternatively or additionally, one or more of the medical devices 26₁－26_NMay be mounted to the electronic device 12 and/or may be part of the electronic device 12. In the illustrated embodiment, the plurality of medical devices 26₁－26_NEach arranged to pass through a corresponding number of wireless communication links 28₁－28_NCommunicate wirelessly with the communication I/O unit 24 of the electronic device 12. The wireless communication may be unidirectional or bidirectional. Forms of wireless communication used include, but are not limited to, Radio Frequency (RF) communication, redExternal (IR) communication, WiFi, RFID (inductive connection) communication, acoustic communication, capacitive signal (via a conductor), current signal (via a conductor) or the like. In any of the situations described, the electronic device 12 and the plurality of medical devices 26₁－26_NEither of which contains the usual circuitry for managing the wireless communication circuitry. Alternatively or additionally, one or more medical devices 26₁－26_NMay be configured to communicate with the electronic device 12 via one or more intervening, commonly serially or parallelly configured, hardware connections. The one or more medical devices 26₁－26_NEach of which may include any one or more of a conventional processing unit, a conventional input/output circuit and/or device, and one or more suitable data and/or program storage devices.

In certain embodiments, the system 10 may alternatively or additionally include a remote device 30, as shown in the dashed box in FIG. 1. The remote device 30 may include a conventional processor 32 that may be the same as or similar to the processor 14, a conventional memory or other data storage unit 34, a conventional input device 36 that may be or include any one or more of the input devices described above with respect to the input device 18, a conventional display unit 38 that may be or include any one or more of the display units described above with respect to the display unit 20, and conventional communication I/O circuitry 40. The remote device 30 may be configured to communicate with the electronic apparatus 12 via any conventional wired or wireless communication interface 42, which may be or include any of the communication interfaces or links described above.

The system 10 shown in fig. 1 is, or forms part of, a fully closed-loop, semi closed-loop, or open-loop diabetes control device of the type commonly used. In connection therewith, the system 10 requires a user input of a certain amount of feed forward information from which the system 10 determines at least part of the insulin bolus administration information. The insulin tablet administration information may be or include, for example, insulin tablet dosage, tablet type (e.g., standard or fast acting such as Regular, Lispro, etc.), insulin tablet administration (delivery) time, number or interval (e.g., single administration, multiple divided administrations, consecutive administrations, etc.), and the like. Examples of user-provided feed forward information may be or include, for example and without limitation, user blood glucose concentration, information about meals or snacks that have been ingested, are being ingested, or are to be ingested at some future time, user training information, user stress information, user illness information, information about the user's menstrual cycle, and the like. In any case, the system 10 includes a drug delivery mechanism for delivering a controlled amount of a drug, such as insulin, glucagon, hormone, or the like, and/or providing alternative action treatment recommendations to the user via the display 20, such as carbohydrate intake, training, and the like. The system 10 may be provided in any type of conventional configuration, and examples of some of the configurations described herein will be presented. It is to be understood, however, that the following examples are provided for the purpose of illustration only and should not be construed as limiting in any way. Other possible applications of a fully closed-loop, semi closed-loop, or open-loop diabetes control arrangement will occur to those skilled in the art and any such other applications are contemplated by the present disclosure.

In a first exemplary application of the system 10, the electronics 12 are provided in the form of a conventional insulin pump configured to be worn outside the body of the user and further configured to controllably administer insulin to the body of the user. In this example, a plurality of medical devices 26₁－26_NOne or more implanted sensors and/or sensing technologies may be included to provide information about the physiological condition of the user. Examples of such implanted sensors may include, but should not be limited to, a glucose sensor, a body temperature sensor, a blood pressure sensor, a heart rate sensor, one or more biomarkers configured to acquire one or more physiological states of the body, such as HBAIC, or similar devices. In applications involving implanted glucose sensors, the system 10 may be a fully closed loop system operating in a conventional manner to automatically monitor blood glucose and administer insulin appropriately to maintain blood glucose at a desired levelAnd (4) horizontal. A plurality of medical devices 26₁－26_NOne or more sensors or sensing systems and/or sensing technologies external to the user's body may alternatively or additionally be included to provide information about the physiological condition of the user. Examples of such sensors or sensing systems may include, but should not be limited to, a glucose decomposition sensor/meter, a body temperature sensor, a blood pressure sensor, a heart rate sensor, one or more biomarkers configured to obtain one or more physiological states of the body, such as HbA1c, or the like. In applications that include an external blood glucose sensor, the system 10 may be a closed-loop, semi-closed-loop, or open-loop system that operates in a conventional manner to administer the appropriate insulin based on the blood glucose information provided by the user therein. Any of the information provided by the above-described sensors and/or sensing techniques may be communicated to the system 10 using any one or more of the usual wired or wireless communication techniques. In the present exemplary application, a remote device 30, which may also be in the form of a handheld or other portable electronic device, is provided to transmit information to and/or receive information from the electronic device 12.

In a second exemplary application of the system 10, the electronic device 12 is provided in the form of a handheld remote device, such as a PDA or other handheld device. In this example, the plurality of medical devices 26₁－26_NIncluding at least one commonly implanted or externally worn drug pump. In one embodiment of the present example, the insulin pump is configured to controllably administer insulin to the body of the user. In this embodiment, the insulin pump is configured to wirelessly transmit information regarding insulin delivery to the handheld device 12. The handheld device 12 is configured to monitor insulin delivery by the pump and may be further configured to determine and recommend insulin bolus doses, carbohydrate intake, training, and the like. The system 10 may or may not be configured to allow wireless transmission of information from the handheld device 12 to the insulin pump in this embodiment.

In an alternative embodiment of the present example, the handheld device 12 is configured to control the administration of insulin to the user by determining an insulin administration command and sending the command to the insulin pump. The insulin pump, in turn, is configured to receive the insulin delivery command from the handheld device 12 and deliver insulin to the user in accordance with the command. In this embodiment, the insulin pump may or may not further process the insulin pump commands provided by the handheld unit 12. In any event, the system 10 will typically be configured in this implementation to allow wireless transmission of information from the insulin pump back to the handheld device 12, thereby allowing monitoring of the operation of the pump. In any of the embodiments of the present example, the system 10 may further include one or more implanted and/or external sensors of the type described in the previous examples. In the present exemplary application, a remote device 30, in the form of, for example, a PC, PDA, laptop or notebook computer, or the like, may also be included and configured to transmit information to and/or receive information from the electronic device 12.

Those skilled in the art will recognize other possible applications of a fully closed-loop, semi closed-loop, or open-loop diabetes control arrangement using at least some of the components of the system 10 shown in FIG. 1. For example, the electronic device 12 may be provided in the form of a PDA, laptop, notebook, or personal computer in one or more of the above examples, which is configured to communicate with the medical device 26₁－26_NAt least one of the medical devices is an insulin delivery system to monitor and/or control the administration of insulin to the user. As another example, the remote device 30 may be configured to communicate with the electronic device 12 and/or one or more of the medical devices 26₁－26_NCommunicate to control and/or monitor the administration of insulin to the patient and/or transmit one or more software programs and/or data to the electronic device 12. The remote device 30 may be located in a care provider's office or other remote location, and communication between the remote device and any component of the system 10 may be accomplished via an intranet, the internet (e.g., world wide web), a cellular, telephone modem, RF, or other communication link. Any one or more of the conventional onesAn internet protocol may be used for this communication. Alternatively or additionally, any commonly used mobile content delivery system, such as Wi-Fi, WiMAX, Short Message System (SMS), or other commonly used messaging models, may be used to allow communication between the devices comprising system 10. In any event, any such other applications are contemplated by the present disclosure.

Generally, blood glucose concentrations in the human body vary due to one or more external influences such as diet and training, and also due to various physiological reactions such as stress, disease, menstrual cycle, and the like. For people with diabetes, such changes may necessitate monitoring the patient's blood glucose levels and administering insulin or other blood glucose altering drugs, such as lowering or raising blood glucose, as needed to maintain the person's blood glucose concentration within a desired range. In any of the above examples, the system 10 is thus configured to determine, based on a certain amount of user-specific information, an appropriate amount, type, and/or timing of insulin or other blood glucose altering medication to administer in order to maintain normal blood glucose levels without causing hypoglycemia or hyperglycemia. In certain embodiments, the system is configured in a conventional manner to control one or more external (e.g., subcutaneous, transcutaneous or extradermal) and/or implantable insulin pumps to automatically inject or otherwise provide the appropriate amount and type of insulin to the body of the user in the form of one or more insulin tablets. In further embodiments, the system 10 is conventionally configured to display or otherwise notify the user of the appropriate amount, type and/or timing of insulin in the form of an insulin recommendation. In this embodiment, conventional hardware and/or software forming part of the system 10 allows the user to receive a suggested amount, type and/or timing of insulin or to reject the suggestion. If accepted, in one embodiment, the system 10 automatically injects or otherwise provides one or more appropriate amounts and types of insulin in the form of insulin tablets into the user's body. If, on the other hand, the user rejects the insulin recommendation, the usual hardware and/or software forming part of the system 10 allows the user to manually enter the number, type and/or timing of insulin boluses without going through the system 10. The system 10 is then configured in a conventional manner to automatically inject or otherwise provide the user-specified quantity, type and/or timing of insulin in the form of one or more insulin boluses into the user's body. Alternatively, the appropriate amount and type of insulin corresponding to the insulin recommendation displayed by the system 10 may be manually injected or orally administered into the user. However, it will be appreciated that the system 10 may alternatively or additionally be configured in a similar manner to determine, recommend and/or administer other types of medications to the patient.

As just described, the system 10 operates to determine and recommend or administer to a patient an appropriate amount of insulin or other hypoglycemic agent in the form of one or more insulin tablets. In determining the appropriate amount of insulin, the system 10 requires at least a portion of the information relating to one or more external responses and/or various physiological responses associated with the patient. For example, if the patient is about to ingest, is ingesting, or has recently ingested a meal or snack, the system 10 generally requires a portion of the information associated with the meal or snack to determine the appropriate number, type, and/or timing of one or more meal compensation tablets. When a person ingests food in the form of a meal or snack, the person reacts by absorbing the sugar in the meal or snack over time. For the purposes of this document, the intake of any food may be referred to below as a "meal," and the term "meal" herein includes traditional meals, such as breakfast, lunch, and dinner, as well as snack, beverage, and the like in between.

The general shape of the human body's sugar absorption profile rises after ingestion of a meal, peaks at some measurable time after the meal, and then falls thereafter. The speed of the absorption profile, i.e., the rate from start to finish, for any one sugar will typically vary from day to day for a human, with meal composition, meal type or time (e.g., breakfast, lunch, dinner or snack), and/or depending on one or more other factors, and may also vary from day to day in otherwise identical meal environments. Generally speaking, the feed forward information associated with the meal intake information provided by the patient to the system 10 should include, explicitly or implicitly, an estimate of the carbohydrate content of the meal or snack corresponding to the amount of carbohydrates that the patient is about to ingest, is ingesting, or has recently ingested, as well as an estimate of the speed at which the patient is taking all of the sugar from the meal.

An estimate of the amount of carbohydrate that a patient will ingest, is ingesting, or has recently ingested may be provided by the patient in any of a variety of forms. Examples include, but are not limited to, direct estimates of carbohydrate weight (e.g., in grams or other common weight measure), an amount of carbohydrate relative to a reference amount (e.g., dimensionless), an estimate of meal or snack size (e.g., dimensionless), and an estimate of meal or snack size relative to a reference meal or snack size (e.g., dimensionless). Patient input of carbohydrate content for other forms of meals or snacks will occur to those skilled in the art, and any such other form is contemplated by the present disclosure.

An estimate of the speed at which the patient absorbs all of the sugar from the meal may similarly be provided by the user in any of a number of forms. For example, for a particular value of the expected rate of overall glucose absorption, the glucose absorption profile obtains the rate of meal ingestion by the patient. In another example, the rate at which the patient absorbs all of the sugar from the meal also includes the duration from when the person ingests the meal to the peak sugar absorption for the meal that the person ingests, which includes the duration of the meal that the patient ingests. The rate of total sugar absorption can thus be expressed in the form of meal rate or duration. Examples of expected speed parameters for total sugar absorption in this case may include, but are not limited to, estimated blend parameters corresponding to meal speed or duration (e.g., time units), blend parameters corresponding to meal speed or duration relative to a reference meal speed or duration (e.g., dimensionless), or the like.

As another example of providing an estimate of the expected speed parameter of overall sugar absorption, the shape and duration of the sugar absorption profile may be mapped to the composition of the meal. Examples of expected speed parameters for total sugar absorption in this case may include, but are not limited to, estimates of fat mass, protein mass, and carbohydrate amount (e.g., in grams) in coordination with carbohydrate content estimates in the form of meal size or relative meal size, estimates of fat mass, protein mass, and carbohydrate amount relative to reference amounts of fat, protein, and carbohydrate in coordination with carbohydrate content estimates in the form of meal size or relative meal size, and estimates (e.g., dimensionless) of a total glycemic index value for a meal or snack, where for purposes of this document the term "total glycemic index" is defined as a parameter that classifies a meal or snack by the speed at which a meal or snack causes an increase in blood glucose in a human. Thus, for example, a meal or snack with a low glycemic index produces a slow blood glucose rise, while a meal or snack with a high glycemic index produces a fast blood glucose rise. An exemplary measure of the overall glycemic index may be, but is not limited to, the ratio of carbohydrates absorbed from a meal over a particular time, such as 2 hours, to a reference value, such as from pure sugar or white bread. Other forms of user input for the expected rate of overall glucose absorption from the meal by the patient, and/or other forms of expected shape and duration of the glucose absorption profile for use, will occur to those of ordinary skill in the art, and any such other forms are contemplated by the present disclosure.

The system 10 illustratively includes a graphical user interface for a patient (user) to enter meal related information having a first parameter component and a second parameter component. The graphical user interface is illustratively displayed on the display unit 20 of the electronic device 12, but may alternatively or additionally be displayed on the display unit 38 of the remote device 30. The processor 14 is arranged to control the display unit 20 to display a graphical user interface on the electronic device 12 in a conventional manner. Alternatively or additionally, the processor 32 may be arranged to control the display unit 38 to display the graphical user interface on the remote device 30 in a conventional manner. User input to the graphical user interface may be provided in any one or more of the usual forms. Examples include, but are not limited to, one or more buttons or keys provided on the input devices 18 and/or 36 of the respective devices 12 and/or 18, a touch screen of the display units 20 and/or 38, one or more conventional click mechanisms, or the like.

The first parameter component of the patient (user) input of meal related information illustratively corresponds to the amount or content of carbohydrates of a meal that the patient is about to ingest, is ingesting, or has recently ingested, and the second parameter component illustratively corresponds to the expected rate at which the patient absorbs all of the sugars from the meal. Referring to fig. 2, an exemplary embodiment of the graphical user interface 50 for user input of meal intake information is shown. In the exemplary embodiment, the graphical user interface 50 is a grid-type user interface having one grid axis defined by carbohydrate content in the form of meal size and another grid axis defined by the expected rate of overall glucose absorption from the meal by the patient in the form of meal duration. The meal size grid axis defines three different meal size or quantity values in the form of "small", "medium" and "large" indicators, and the meal duration grid axis similarly defines three different meal duration values in the form of "slow", "medium" and "fast" indicators. The grid-type graphical user interface 50 provides for a single user selection of carbohydrate content and expected speed of overall sugar absorption information regarding the meal that the patient is about to ingest, is ingesting, or has recently ingested. As used herein, the term "single user selection" is defined as a selection made by a user. It will be appreciated that the systems and methods described herein are not limited to a single user, and that the systems and methods described in this document may be applied to a single user or multi-user platform, as is more appropriate. In any case, in the illustrated example, the user has selected a meal related input indicating that the meal that the patient is about to ingest, is ingesting, or has recently ingested is a large meal that will, or has been ingested over a medium meal duration. In general, the terms "bulk," "medium," and "low" are intended herein to encompass any common measure of meal size, such as, but not limited to, meal size or quantity in any particular unit of weight, volume, etc.

Referring to fig. 3, another exemplary embodiment of a graphical user interface 52 for user input of meal intake information is shown. In the illustrated embodiment, the graphical user interface 52 is a grid-type user interface having one grid axis defined by carbohydrate content in the form of meal size relative to a reference meal size and another grid axis defined by the expected rate of overall glucose absorption from the meal by the patient in the form of meal duration relative to a reference meal duration. The meal size grid axis defines three different meal size values in the form of "below normal", "above normal" indicators, and the meal duration grid axis similarly defines three different meal duration values in the form of "shorter than normal", "longer than normal" indicators. The grid-type graphical user interface 52 provides for a single user selection of carbohydrate content and expected speed of overall sugar absorption information regarding the meal that the patient is about to ingest, is ingesting, or has recently ingested. In the illustrated example, the user has selected a meal related input indicating that the meal that the patient is about to ingest, is ingesting, or has recently ingested is less than a normal meal and the meal duration is about the same as a normal meal duration. In general, the terms "more" or "less" herein are intended to encompass any commonly used measure of meal size relative to a specified "normal" meal size, such as, but not limited to, meal size or quantity in any specified unit of weight, capacity, etc.

Referring to fig. 4, another exemplary embodiment of a graphical user interface 54 for user input of meal intake information is shown. In the illustrated embodiment, the graphical user interface 54 is a grid-type user interface having one grid axis defined by carbohydrate content in the form of meal size and another grid axis defined by expected speed of overall sugar absorption in the form of fat amount, protein amount, and carbohydrate amount of the meal. The graphical user interface 54 thus requires three separate selections to be entered by the user, as compared to the single input associated with the embodiment shown in and described with reference to fig. 1 and 2. As briefly introduced above, this amount of fat, protein and carbohydrate will be mapped to the expected rate at which the patient absorbs all of the sugar from the meal. The meal size grid axis defines three different meal size values in the form of "small", "medium", "large" indicators. The grid-type graphical user interface 54 is used for user selection of carbohydrate content and expected speed of overall sugar absorption information regarding meals that the patient is about to ingest, is ingesting, or has recently ingested. In the illustrated example, the user has selected a meal related input indicating that the meal that the patient is about to ingest, is ingesting, or has recently ingested has a high amount of fat, a moderate amount of protein, and a high amount of carbohydrates. In general, the terms "large," "medium," and "small" are intended herein to encompass any commonly used measure of meal size, including, for example, but not limited to, meal size or quantity in any particular unit of weight, volume, etc. used.

In general, any desired functional relationship may be used in the present embodiment to map the three meal component amounts to corresponding meal speed or meal duration values. An exemplary functional relationship may be, but should not be limited to, assigning equal weights to the three meal composition components, calculating percentages of the three user-specific meal composition values, assigning equally spaced thresholds to two demarcation points between the three meal size values, namely 33% and 66%, and then comparing the percentages of the three meal composition values to the threshold percentage values to determine meal speed. Using the example shown in fig. 4, the small, medium and large components are assigned values of 1, 2 and 3, respectively. The percentage of fat is thus 3/8 or 37.5%, the percentage of protein is 2/8 or 25%, and the percentage of carbohydrate is 3/8 or 37.5%. Thus the percentages of fat and carbohydrate are both moderate and the percentage of protein is low, resulting in a moderate to moderate slow mixed meal speed.

Referring to fig. 5, another exemplary embodiment of a graphical user interface 56 for user input of meal intake information is shown. In the illustrated embodiment, the graphical user interface 56 is a grid-type user interface having one grid axis defined by carbohydrate content in the form of meal size relative to a reference meal size, and another grid axis defined by the expected rate at which the patient absorbs all sugar from the meal in the form of fat amount, protein amount, and carbohydrate amount of the meal. As with the graphical user interface 54, the graphical user interface 56 thus requires three separate selections to be entered by the user, as compared to the single input associated with the embodiment shown in and described with reference to FIGS. 1 and 2. The user-specific fat, protein and carbohydrate amounts will be mapped to corresponding meal speed or meal duration values using any desired functional relationship between the two as just described. The meal size grid axis defines three different meal size values in the form of "below normal", "normal" and "above normal" indicators. The grid-type graphical user interface 56 is used for user selection of carbohydrate content and expected speed of overall sugar absorption information regarding the meal that the patient is about to ingest, is ingesting, or has recently ingested. In the illustrated example, the user has selected a meal related input indicating that the meal that the patient is about to ingest, is ingesting, or has recently ingested has a normal fat amount, a normal protein amount, and a less than normal carbohydrate amount. In general, the terms "above" and "below" in this context are intended to encompass any commonly used measure of meal size relative to a particular "normal" meal size, including, for example and without limitation, meal size or quantity in any particular unit of weight, volume, etc. used.

Referring to fig. 6, another exemplary embodiment of a graphical user interface 58 for user input of meal intake information is shown. In the illustrated embodiment, the graphical user interface 58 defines a continuous function of carbohydrate content, provided as carbohydrate content by weight (grams or other common weight units), and the expected rate at which the patient absorbs all of the sugar from the meal, provided as a total glycemic index (dimensionless). Alternatively, the graphical user interface 58 may define a numerical display that is a discrete function of the carbohydrate content provided in the form of carbohydrate content and the expected rate of sugar absorption provided in the form of a total glycemic index. In either case, the carbohydrate and/or total glycemic index parameters may alternatively be expressed in the graphical user interface 60 in the form of "high", "medium", and "low", which terms are described above, or in the form of "above normal", "normal", and "below normal", which terms are described above. Any number of dots, dashed lines, solid lines, or any other type of grid lines may alternatively or additionally be added to the graphical user interface 58 to increase the discrimination between carbohydrate content and the overall glycemic index value on the interface 58. In any case, the graphical user interface 58 provides for a single user selection of carbohydrate content and expected speed of sugar absorption information regarding the meal that the patient is about to ingest, is ingesting, or has recently ingested. In the illustrated example, the user has selected a meal related input indicating that the meal that the patient is about to ingest, is ingesting, or has recently ingested has a carbohydrate weight of about 50 grams and a total glycemic index value of about 62.

Referring to fig. 7, another exemplary embodiment of a graphical user interface 60 for user input of meal intake information is shown. In the exemplary embodiment, the graphical user interface 60 defines a continuous function of the carbohydrate content provided in the form of meal size and the expected speed at which the patient draws total sugar from the meal provided in the form of meal duration. The meal size axis defines three different meal size values in the form of "small", "medium" and "large" indicators, and the meal duration axis similarly defines three different meal duration values in the form of "slow", "medium" and "fast" indicators. The continuous-type graphical user interface 60 is used for a single user selection of carbohydrate content and expected speed of overall sugar absorption information regarding the meal that the patient is about to ingest, is ingesting, or has recently ingested. Any number of dots, dashed lines, solid lines, or any other type of grid lines may alternatively or additionally be added to the graphical user interface 60 to increase the discrimination between meal size and meal duration values on the interface 60. In the illustrated example, the user has selected a meal related input indicating that a meal that the patient is about to ingest, is ingesting, or has recently ingested is between a moderate and large amount and is ingested for a meal duration between slow and moderate.

It will be noted that although the various examples of graphical user interfaces depicted in fig. 2-7 are illustrated as being displayed on display unit 20 of electronic device 12, any of the graphical user interfaces may alternatively or additionally be displayed on display unit 38 of remote device 30. The display unit 20 in fig. 2-7 is further controlled by the processor 14 to display the current date and time in the upper right corner of the display unit 20. It will be appreciated that processor 14 may alternatively be configured to control display unit 20 in a conventional manner to display more or less information about system 10, the user, and/or other desired information. It will be further appreciated that the various graphical user interfaces shown in and described with reference to fig. 2-7 are provided as examples only, and that various combinations of any one or more of the examples shown in fig. 2-7, as well as graphical user interfaces for input of other carbohydrate content and sugar absorption shape, speed, and/or duration information, may alternatively or additionally be employed.

Referring now to fig. 8, a flow diagram of one exemplary embodiment of a software algorithm 100 for determining medication administration information using the system 10 of fig. 1 based on user input of meal intake information is shown. The software algorithm 100 will be described as being executed by the processor 14 of the electronic device 12, however the software algorithm 100 may alternatively or additionally be executed by the processor 32 of the remote device 30. The algorithm 100 begins at step 102 and the processor 14 is operated to monitor the Graphical User Interface (GUI) for user input of meal intake information at step 104. The graphical user interface may take the form of any one or any combination of the exemplary graphical user interfaces shown in fig. 2-7 and described herein with reference to fig. 2-7, or may alternatively take the form of other user inputs for meal-related carbohydrate content and the expected rate at which the patient absorbs total sugar from the meal.

Following step 104, the algorithm 100 proceeds to step 106 where the processor 14 operates to determine whether a complete user input to the GUI has been detected. For example, in embodiments having a single-input graphical user interface, the processor 14 may be operable to determine when a complete user input to the GUI has occurred when the user has selected a single input to the graphical user interface at step 106. In embodiments having a multiple-input graphical user interface, on the other hand, the processor 14 may be operative to determine when a complete user input to the GUI has occurred when the user has selected all of the user selectable inputs to the GUI. In any case, if the processor has not detected a complete user input to the GUI at step 106, execution of the algorithm 100 loops back to perform step 104. If, on the other hand, processor 14 detects at step 106 that a complete user input to the GUI has occurred, execution of the algorithm proceeds to step 108 where processor 14 operates to identify the GUI input at the time and date and store the date and time marked GUI input in a database contained within memory or data storage unit 16 and/or 34. Steps 104 and 106 may illustratively further comprise a timing mechanism configured to direct the algorithm 100 to a particular step or state if the user does not provide complete user input to the GUI within a particular time period.

In the exemplary embodiment, algorithm 100 is set under the following assumptions: the user enters meal-related information just prior to ingesting the meal so that the date and time stamp may generally represent the date and time at which the meal was actually consumed. Step 108 may illustratively be adapted to further provide the user with the ability to adjust the time and/or date associated with the date and time stamp GUI input prior to entering the information into the database. This optional feature provides the user with the ability to enter meal intake information into the GUI after ingestion of a meal, and then change the date-stamped time and/or date from the current time and/or date to reflect the actual or estimated previous time and/or date of ingestion of the meal. For example, in this manner, a meal compensation tablet may be determined and administered or recommended after a meal has been ingested. This optional feature also provides the user with the ability to enter meal intake information into the GUI prior to ingesting a meal, e.g., sufficiently long before a meal, so that the date and/or time stamp in step 108 does not generally represent the actual time and/or date that the corresponding meal was consumed, and then change the time and/or date stamp from the current time and/or date to reflect an estimated future time and/or date at which the meal may be ingested. However, it will be appreciated that in any event the algorithm 100 should further include one or more steps that allow the processor 14 to appropriately adjust the user input to the GUI for determining the meal compensation bolus so that the rate at which the patient absorbs all of the sugar from the meal accounts for the time elapsed between ingestion of the meal and the subsequent input of the meal-related user input to the GUI, or the time delay between the input of the meal-related user input to the GUI and the subsequent ingestion of the meal. It will be apparent to those skilled in the art that the steps including one or more of the above will be applied mechanically.

Although not shown in fig. 8, the algorithm 100 or other independently executed algorithm may further include one or more steps that allow the user to modify previously entered meal-related information and/or associated time and/or date stamp information, or to append new and/or possibly more accurate information to previously entered meal-related information and/or associated time and/or date stamp information. This optional feature provides the user with the ability to modify the above data in the event that the meal related information is entered, for example, prior to or during meal intake, to subsequently reflect any deviation in actual meal intake from the expected or estimated meal intake at the time of information entry. For example, a predetermined meal may be skipped or delayed, more or fewer meals may have actually been consumed compared to a previous estimate, and/or the composition of the meal may have changed from a previous estimate.

Following step 108, the processor 14 is operated at step 110 to map the user input of meal intake information to the GUI to corresponding insulin delivery information. The memory or data storage unit 16 and/or 34 illustratively has stored therein a map correlating feed-forward user-entered meal information with insulin delivery amounts. The mapping may be provided in any conventional form, examples of which include, but are not limited to, one or more graphs, charts, tables, equations, or the like. An exemplary embodiment of the map 130 is shown in fig. 9 and is provided in the form of a table that maps carbohydrate content in the form of meal speed and expected speed of overall glucose absorption from the meal by the patient in the form of meal duration to meal compensation bolus information. In the embodiment shown in fig. 9, the meal compensation bolus information may be or include any one or more of a total number X of insulin boluses to be administered to the user, a quantity or number Y (e.g., in international units) of each of the insulin boluses to be administered, a time Δ T spaced between each of the insulin boluses to be administered, and a time I at which a first one of the plurality of insulin boluses is to be administered. Those skilled in the art will appreciate that other insulin dosing schedules may be used to define the mapping relating feed-forward user-entered meal information to insulin delivery rates, and any such other insulin dosing schedules are envisioned by the present disclosure.

Referring again to fig. 8, in an exemplary embodiment, the processor 14 is thereby operative to map 110 the user input of meal intake information to the GUI to insulin delivery information using the general type table shown in fig. 9. It will be appreciated that the processor 14 may alternatively or additionally use different table coordinate axis values consistent with carbohydrate content and the expected speed of overall glucose absorption from the meal by the patient, and/or use one or more other commonly used mapping techniques to map user-specific meal intake information to corresponding insulin bolus administration information. Although the insulin bolus administration information is described with reference to fig. 9 as constituting meal compensation boluses, including any one or more of the total number X of insulin boluses to be administered to the user, the quantity or number Y (e.g., in international units) of each of the insulin boluses to be administered, the time Δ T spaced between each of the insulin boluses to be administered, and the time I at which the first of the plurality of insulin boluses is to be administered, it will be further appreciated that the insulin bolus administration information may alternatively or additionally include one or more correction bolus doses, i.e., insulin bolus doses not related to a meal, and in any case may include more or less information than shown in fig. 9.

Execution of the algorithm 100 proceeds from step 110 to step 112, wherein in the illustrated embodiment, the processor 14 is operable to control the display unit 20 and/or the display unit 38 to display at least a portion of the insulin delivery information determined in step 110 in the form of an insulin bolus recommendation. Next at step 114, the processor 14 is operated to determine whether the user accepts or rejects the insulin bolus recommendation displayed at step 112. In an exemplary embodiment, the processor 14 is operative to perform step 114 by first displaying user selectable graphical "accept" and "decline" indicators along with the insulin bolus recommendation, and then monitoring the indicators to determine which of the two indicators was selected by the user. In an alternative embodiment, the "accept" and "reject" buttons or keys may form part of the input device 18 and/or 36, and are used in this embodimentIn an embodiment processor 14 is operative to perform step 114 by monitoring the buttons or keys to determine which of the two is selected by the user. Those skilled in the art will recognize other common techniques for implementing step 114, and any such other common techniques, as may be envisioned by the present disclosure. Step 114 may illustratively further comprise a timing mechanism configured to direct the algorithm 100 to a particular step or state if the user does not accept or decline the suggestion displayed in step 112. In any event, if the processor 14 determines in step 114 that the user accepts the insulin bolus recommendation displayed in step 112, the processor 14 is thereafter operated to transmit 116 the insulin bolus recommendation to the medical device 26 formed by the processor 14, the processor 32, and/or one or more of the plurality of constituent medical devices 26₁－26_NOne or more insulin delivery algorithms executed by processor circuitry of a portion of any of the above provide the recommended insulin bolus information. Processor 14, processor 32, and/or one or more of the constituent medical devices 26₁－26_NThe processor circuit of a portion of any of which is then operative to control automatic administration of one or more insulin boluses to the user in accordance with insulin bolus information recommended by conventional electronically controlled insulin administration devices, such as implanted, subcutaneous, transcutaneous and/or transcutaneous insulin infusion pumps, as directed by any of the one or more insulin administration algorithms. Alternatively, the user, healthcare professional, or other individual may manually administer the one or more insulin tablets via a conventional injection pen or other conventional manual administration mechanism in accordance with the recommended insulin tablet information. Thereafter at step 118, the processor 14 is operated to date and time stamp the recommended insulin bolus information and enter the date and time stamped recommended insulin bolus information into a database contained in the memory or data storage unit 16 and/or 34.

If the processor 14 determines in step 114 that the user rejects the insulin bolus recommendation displayed in step 112, the processor 14 is thereafter operated in step 120 to prompt the user to modify the recommended insulin bolus information.In an exemplary embodiment, the processor 14 is operative to perform step 120 by displaying the insulin bolus recommendation in a manner that allows the user to correct any of the recommended insulin bolus information via the graphical user interface, the input devices 18 and/or 36, or via other conventional data input devices, and is also operative to display a graphical "change accepted" advisor selectable by the user when the correction of the recommended insulin bolus information is complete. The processor 14 is then operative to monitor the "accept changes" indicator at step 112. Until the user selects the "accept changes" indicator in step 112, the algorithm 100 returns to performing step 120. The algorithm may further illustratively include one or more conventional steps (not shown) that allow the algorithm 100 to continue execution bypassing step 122 if the user does not select the "accept changes" indicator within a specified time period. In any case, when processor 14 determines at step 122 that the user has selected the "accept changes" indicator, processor 14 is thereafter operated at step 124 to address one or more component medical devices 26, including processor 14, processor 32, and/or one or more of the components of medical device 26₁－26_NOne or more insulin delivery algorithms executed by the processor circuit of a portion of any of the provides modified insulin bolus information. Processor 14, processor 32, and/or one or more component medical devices 26₁－26_NThe processor circuit of a portion of any of these is then operated to control the automatic administration of one or more insulin boluses to the user under the direction of any of the above-described one or more insulin administration algorithms, in accordance with this modified insulin bolus information, by means of conventional electronically controlled insulin administration devices, such as implanted, subcutaneous, transcutaneous and/or extradermal insulin infusion pumps. Alternatively, the user, health care professional, or other institution may manually administer the one or more insulin boluses via a conventional syringe or other conventional manual administration mechanism based on the revised insulin bolus information. Thereafter at step 126, the processor 14 is operated to tag the modified insulin bolus information with a date and time and to assign the date and timeThe labeled modified insulin bolus information is entered into a database contained in memory or data storage unit 16 and/or 34. In an alternative embodiment, steps 116 and 124 of algorithm 100 may be modified in the usual manner to allow the user to manually ignore the recommended insulin bolus information by manually administering one or more insulin boluses. However, in this embodiment, it is desirable to allow the user to enter date and time stamp information, e.g., the number, type, dosage and/or timing of one or more insulin boluses, into the database in steps 118 and 126 in connection with the manual administration of the one or more insulin boluses. In any case, execution of the algorithm 100 returns to step 104 from either of steps 118 and 126.

In an alternative embodiment of the algorithm 100, the steps 112, 116, and 120, 124 may be modified in the usual manner to cause the processor 14 to control the automatic administration of one or more insulin boluses to the user in accordance with the insulin delivery information determined at step 110 under the direction of one or more insulin delivery algorithms. In this embodiment, the insulin delivery information determined in step 110 is thus not displayed or otherwise provided to the user as an insulin bolus recommendation, but instead is automatically administered or otherwise administered to the user by a conventional electronically controlled insulin delivery device, such as an implanted, subcutaneous, transdermal and/or extradermal insulin infusion pump.

The graphical user interface examples shown in fig. 2-7, and the algorithm 100 of fig. 8 for determining drug delivery information based on feed forward information user input through the graphical user interface described above, have been shown herein in context with providing meal intake information to the system 10 from which insulin delivery information is determined. It will be appreciated that similar graphical user interfaces may alternatively or additionally be developed based in whole or in part on one or more other external factors and/or various physiological mechanisms associated with the user. Examples include, but are not limited to, considerations such as direct or indirect one-dimensional or two-dimensional indicators of training, stress, illness, menstrual cycle, and/or the like. As one particular example, a graphical user interface of the type shown in fig. 2-7 may be developed for user input of feed forward information in the form of user training information having one parameter or axis corresponding to relative (e.g., relative to a reference) or actual user training intensity and another parameter or axis corresponding to relative (e.g., relative to a reference) or actual user training duration, or having a single parameter or axis of user training information. As another example, a graphical user interface of the type shown in fig. 2-7 may be developed for user input of feed forward information in the form of user stress having one parameter or axis corresponding to a relative (e.g., with respect to a reference) or actual state or profile of the user stress and another parameter or axis corresponding to a relative (e.g., with respect to a reference) or actual user stress duration, or a single parameter or axis of user stress information. As another example, a graphical user interface of the type shown in fig. 2-7 may be developed for user input of feed forward information in the form of user illness information having one parameter or axis corresponding to a relative (e.g., relative reference) or actual state or distribution of a user's illness and another parameter or axis corresponding to a relative (e.g., relative reference) or actual user illness duration, or having a single parameter or axis of user illness information. As another example, a graphical user interface of the type shown in fig. 2-7 may be developed for user input of feed forward information in the form of user menstrual cycle information having one parameter or axis corresponding to relative (e.g., relative reference) or actual user menstrual levels and another parameter or axis corresponding to relative (e.g., relative reference) or actual menstrual durations, or having a single parameter or axis of user menstrual cycle information. Those skilled in the art will recognize other examples of graphical user interfaces that may be developed based on one or more other external factors and/or various physiological mechanisms associated with the user, and any other examples are contemplated by the present disclosure. In any case, the processor 14 is illustratively operative with any of the above-described graphical user interfaces to date and time stamp events and may additionally allow the time and date stamp to be altered to stamp one or more other external factors and/or various physiological mechanisms associated with the user that occurred in the past or are expected to occur in the future. This feature is also illustratively used to provide the user with the ability to make suggestions of upcoming (e.g., scheduled) event start/end times in order to increase the accuracy of the system and provide an increased level of event consistency.

Graphical user interfaces of the type described above may be used, for example, by themselves to determine the amount, type and/or timing of administration, and/or the recommendation of one or more medications, such as insulin boluses. Alternatively, any of the above-described graphical user interfaces may be used, for example, in conjunction with one or more other graphical user interfaces, to modify the number, type, and/or timing of one or more insulin boluses. As a specific example of the latter case, the system 10 may be operated to first determine and suggest and/or administer one or more insulin boluses based on the meal intake information user input described above using a graphical user interface of the type shown in FIGS. 2-7. One or more additional graphical user interfaces may also be provided for a user to adjust or modify the one or more insulin boluses using modification factors in the form of a fractional factor, an additional offset, and/or a modification function. As one particular example, an additional graphical user interface may be developed for user input of feed forward information in the form of user training information having one parameter or axis corresponding to relative or actual user training intensity and other parameters or axes corresponding to relative or actual user training duration, having a single parameter or axis of user training information, or having a single, user selectable, binary value representing the occurrence or non-occurrence of user training in a particular time window associated with the input data. In this example, the memory or data storage unit 16 and/or 34 includes additional mappings, like the type shown in FIG. 9, that relate the intensity and duration of the user training to the appropriate correction information. The processor 14 then modifies the medication administration information previously determined by the processor 14 in accordance with the meal intake information as a function of the modified information determined by the additional mapping in response to user input of additional feed forward information in the form of user training information. It is to be appreciated that the additional mappings can be provided in any common form, including, for example and without limitation, one or more graphs, plots (plots), formulas, tables, or the like. As another example, an additional graphical user interface may be developed for user input of feed forward information in the form of user stress information having one parameter or axis corresponding to relative or actual user stress state or profile and another parameter or axis corresponding to relative or actual user stress duration, having a single parameter or axis of user stress information, or having a single, user-selectable binary value representing the presence or absence of user stress within a particular time window associated with the input data. In this example, the memory or data storage unit 16 and/or 34 includes additional mappings of the type shown in FIG. 9 that relate the user stress state or profile and duration to the appropriate corrective information. The processor 14 then modifies the medication administration information previously determined by the processor 14 in accordance with the meal intake information as a function of the modified information determined by the additional mapping in response to user input of additional feed forward information in the form of user stress information. It will be appreciated that the additional mapping may be provided in any conventional form, including, but not limited to, one or more graphs, plots, formulas, tables, or the like, for example. As another example, an additional graphical user interface may be developed for user input of feed forward information in the form of user disease information having one parameter or axis corresponding to relative or actual user disease state or distribution and another parameter or axis corresponding to relative or actual user disease duration, having a single parameter or axis of user disease information, or having a single, user-selectable binary value representing the presence and absence of user disease within a particular time window associated with the input data. In this example, the memory or data storage unit 16 and/or 34 includes additional mappings of the type shown in FIG. 9 that relate the user's disease state or distribution and duration to the appropriate revision information. The processor 14 then modifies the medication administration information previously determined by the processor 14 in accordance with the meal intake information as a function of the modified information determined by the additional map in response to user input of additional feed forward information in the form of user disease information. It will be appreciated that the additional mapping may be provided in any conventional form including, but not limited to, one or more graphs, functional graphs, formulas, tables, or the like. As another example, an additional graphical user interface may be developed for user input of feed forward information in the form of user menstrual cycle information having one parameter or axis corresponding to relative or actual user menstrual levels and other parameters or axes corresponding to relative or actual menstrual durations, having a single parameter or axis of user menstrual cycle information, or having a single, user selectable binary value representing the presence or absence of a user menstrual cycle within a particular time window associated with the input data. In this example, the memory or data storage unit 16 and/or 34 includes additional mappings of the type shown in FIG. 9 that associate the degree of menstruation and the duration of menstruation of the user with appropriate correction information. The processor 14 is then responsive to user input of additional feed forward information in the form of user menstrual cycle information to modify the administration information previously determined by the processor 14 in accordance with the meal intake information as a function of the modification information determined by the additional map. It will be appreciated that the additional mapping may be provided in any common form, including, but not limited to, one or more graphs, plots, formulas, tables, or the like, for example. Those skilled in the art will appreciate examples of other graphical user interfaces that may be developed based on one or more other external factors associated with the user and/or various physiological mechanisms, and any other examples are contemplated by the present disclosure.

Whether any one or more of the graphical user interfaces illustrated and described herein are suitable for use by the patient will depend, at least in part, on the individual habits of the patient. For example, whether a graphical user interface relating meal intake information to meal-related insulin delivery information as described above with reference to fig. 2-9 is suitable for use by a patient will depend, at least in part, on the eating habits of the patient. It is therefore desirable to develop one or more suitable graphical user interfaces for any patient based on the patient's habits and taking into account patient adaptability to use any such graphical user interface based on the habits of the patient. In order to reduce the number of inputs provided by the user to the system 10 without compromising the overall level of sugar control, the regularity of the user's eating habits is utilized. It is generally predictable that a person with diabetes typically selects from a relatively limited number of food items and combinations thereof. Whether a graphical user interface of the type illustrated and described herein is suitable for use by an individual typically depends on simplifying the variability of meals or snacks associated with their glycemic impact by exploiting the predictability of the individual's eating habits.

Referring to fig. 10-12, a flow diagram of an exemplary process 150 for determining patient or user suitability using a graphical user interface of the type shown in fig. 2-7 is shown. In an exemplary embodiment, one or more steps of the process 150 are performed manually. Alternatively or additionally, one or more of the remaining steps may be provided in the form of at least one software algorithm stored in a memory unit or data storage device, such as memory unit or data storage unit 16 of electronic device 12 or memory unit or data storage device 34 of remote device 30, and executed by a processor, such as processor 14 of electronic device 12 or processor 32 of remote device 30, in a conventional manner. Still alternatively, the entire process 150 may be provided in the form of one or more software algorithms stored in a memory unit or data storage device, such as memory unit or data storage unit 16 of electronic device 12 or memory unit or data storage device 34 of remote device 30, and executed by a processor, such as processor 14 of electronic device 12 or processor 32 of remote device 30, in a conventional manner.

In the exemplary embodiment, the process 150 is broken down into three processing modules, each of which is separately illustrated in FIGS. 10, 11, and 12, respectively. A first processing module is represented in flow chart form in fig. 10, relating to pre-screening patients for possible suitability using a graphical user interface of the type shown in fig. 2-7, and to collecting patient-related information for the interface in case a decision is made to use the patient suitability of the interface. The second processing module is represented in flow chart form in fig. 11 and involves processing and analyzing the collected patient-related information to determine whether a regular pattern of one or more of these information can be identified that produces an acceptable, i.e., sufficiently accurate, prediction of the appropriate insulin delivery recommendation based on the available feed forward input classifications. A third processing module is represented in flow chart form in fig. 12 and involves analyzing the patient-related information with the goal of reducing the number of feed forward input categories if one or more regular patterns in the information can be identified. Where the process 150 displays a suitable graphical user interface that may be defined based on the recorded eating habits of the patient, the result of the third processing module is a graphical user interface that maps user-selectable feed forward information to insulin delivery information.

Referring to FIG. 10, a flow diagram of one exemplary embodiment of a first processing module of the process 150 is shown. The process 150 begins at step 152 where a determination is made as to whether the patient is an already existing candidate for a graphical user interface of the type shown and described herein. Step 152 will typically be performed by a health care professional and may be assisted by a conventional computer having access to a database of patient records. In any event, if it is determined in step 152 that the patient is an already existing candidate, the algorithm proceeds to step 164. In this case, the patient is an already existing candidate and the healthcare professional has determined that the process 150 should be performed again for that user. If it is additionally determined in step 152 that the patient is not an already existing candidate, the algorithm proceeds to step 154.

In step 154, when there are no existing candidates, a determination is made in a graphical user interface of the type shown and described herein as to whether the patient can be automatically discarded from the pre-screening process. Step 152 will typically be performed by a health care professional and may be assisted by a conventional computer. In general, a patient may be automatically discarded from the pre-screening process if it appears to the healthcare professional that a graphical user interface of the type shown and described herein is appropriate for that particular patient. While the healthcare professional may base the decision on a number of factors, the healthcare professional will typically base the decision at least in part on an examination of the patient's dietary habits, and may also take into account training habits, overall health, patient stress, and the like. As one example in which a particular patient may be abandoned from the prescreening process, the patient should perform a strict and repetitive metered diet and regular training regime. The healthcare professional, after examining the patient's quantitative diet and training status, may determine that it is acceptable to have a graphical user interface of the type shown and described herein that will suit the particular patient, and the pre-screening process may be abandoned accordingly. It will be appreciated that one or more other factors may alternatively or additionally be considered by the healthcare facility in step 154, and thus the examples provided should not be viewed as limiting in any way. In any event, if it is determined in step 154 that the patient may be automatically discarded from the pre-screening process, algorithm execution proceeds to step 164. If instead it is determined in step 154 that the patient may not be automatically discarded from the pre-screening process, the algorithm proceeds to step 156.

In step 156, the healthcare professional performs a pre-screening procedure on the patient to determine whether the patient is likely an acceptable candidate for a graphical user interface of the type shown and described herein. This pre-screening process, although it may include a variety of factors that need to be considered, will typically include various blood glucose affecting events (e.g., meals, stress, etc.) performed on the patient, and how the patient performs the examination of these events (e.g., regular or irregular meal habits, training, insulin treatment, etc.). An exemplary example of a pre-screening procedure that may be performed at step 156 is to have the patient and/or healthcare professional complete a worksheet or questionnaire designed to investigate patient information relevant to the determination of whether the patient is likely to be an acceptable candidate for a graphical user interface of the type shown and described herein. An exemplary questionnaire and/or worksheet may query some or all of the following information:

1. daily and/or weekly meal ordering of the patient,

2. meal size (e.g., by weight),

3. the ingredients of the various meals (e.g., amounts of fat, protein and carbohydrate),

4. the glycemic index of various diets,

5. the dosage regimen of insulin for a dietary event,

6. weekly habits (on a meal or non-meal),

7. the training plan is a plan of training,

8. other lifestyle-related information may be included in the information,

9. using patient preferences for graphical user interfaces of the type shown and described herein,

10. the problem of managing quantity information on a regular basis,

11. the ability and desire of patients to change meals and other habits so that inconsistencies in treatment needs are more acceptable for use of graphical user interfaces of the type shown and described herein.

Information about individual events, such as about individual meals, is considered a data record. Before performing the pre-screening analysis, a minimum number, m, of data records should be collected, where m is the minimum number of data records in any particular pre-screening procedure that are needed to reduce the available results. Similarly, a limit may be imposed on the maximum number of data records, n, where "n" may represent the actual maximum number of records, the number of records beyond which it would not be possible to provide additional information, and/or the number of records beyond which it would not be possible to contribute to the development of one or more patterns that are not currently present in the data.

The pre-screening program may also be used to collect event-specific treatment information, which may include, but should not be limited to, one or more medications that the patient may be currently using, various combinations of the number and intensity of one or more treatments for a given event, and the timing of the treatments. Information regarding the timing of treatment may include, but should not be limited to, one or more of the time of day and/or day of week that treatment is received or performed, physical cycle information such as menstrual cycle, and the like, and the effect of a combination of factors such as exercise or stress on meals and insulin dosage. Those skilled in the art will appreciate other techniques for performing a patient pre-screening procedure in order to determine whether a patient is likely to be an acceptable candidate for a graphical user interface of the type shown and described herein, and are envisioned by the present disclosure.

Following step 156, the healthcare professional evaluates the patient-related information as described in the above example collected in the pre-screening procedure for the patient in step 158 to determine whether the patient is likely to be an acceptable candidate for a graphical user interface of the type shown and described herein. In one embodiment, for example, various entries in a work table and/or questionnaire may be designed to have point values so that a final "score" may be determined for the patient. In this example, whether a patient is an acceptable candidate for a graphical user interface of the type shown and described herein may be determined by comparing the patient's "score" in the questionnaire and/or worksheet to a determined threshold score. In other embodiments, for example, the questionnaire and/or worksheet may be designed as a flowchart or tree structure that guides the healthcare professional through the questionnaire and/or worksheet and ultimately directs the healthcare professional to the conclusion that the patient is or is not an acceptable candidate for a graphical user interface of the type shown and described herein.

Those skilled in the art will appreciate other techniques for evaluating pre-screening questionnaires and/or worksheets, some of which may be performed manually, others with the assistance of a conventional computer, and any such other techniques are contemplated by the present disclosure. In any event, if the health care professional determines in step 158 that the patient is an acceptable candidate for a graphical user interface of the type shown and described herein, process 150 proceeds to step 164. On the other hand, if the health care professional determines in step 158 that the patient is not an acceptable candidate for a graphical user interface of the type shown and described herein, the process 150 proceeds to step 160, where an indication is made that the graphical user interface is not acceptable for use by the patient being evaluated. In embodiments where step 152 and 158 are performed manually by a health care professional, step 160 may be skipped or combined with step 158. However, in embodiments in which any one or more of steps 152-158 are performed with the aid of a computer, step 160 may be performed by displaying an appropriate message via the computer indicating that the graphical user interface is not acceptably usable. Following step 160, the process 150 proceeds to step 162, where the process 150 ends.

From the "YES" branch of steps 152, 154, and 158, process 150 proceeds to step 164, where a graphical user interface of the type shown and described herein is selected and selected having a maximum grid size or number corresponding to the maximum number of user-selectable feed forward inputs on each coordinate axis of the graphical user interface. In general, the maximum grid size or number will depend on a number of factors, including, but not limited to, ease of use, whether the patient will feel comfortable using a graphical user interface having the number of feed forward inputs on each interface axis, how many feed forward inputs may make the patient feel too complicated, and so forth. In one embodiment, for example, the maximum number of grids is five, although the number may be increased or decreased to suit a particular application. There is a maximum number of grids with a value of five, indicating that the carbohydrate content axis and the overall sugar absorption rate axis of the selected graphical user interface will each initially have five user-selectable inputs.

Following step 164, the process 150 proceeds to step 166 where the number of modes PN is set to 1. Thereafter, in step 168, the maximum pattern number, MAXPN, is selected. The number of patterns, PN, as that term is used herein, relates to the number of different elements of the patient-related information that are used to map the user-selectable feed-forward inputs to the corresponding insulin delivery information. For example, if the patient-related information is very regular and repetitive, the graphical user interface may only require a single "meal" mapping that maps user-selectable feed forward inputs to corresponding insulin delivery information for any meal taken at any time on any day of the week. As another example, if the patient-related information is somewhat regular and repetitive, but less regular and repetitive than in the previous example, the graphical user interface may require a plurality of different "meal category" mappings that map user-selectable feed forward inputs to corresponding insulin delivery information, respectively, depending on meal type, such as breakfast, lunch, dinner, or snack. This maximum number of modes, MAXPN, imposes a limit on the number of different elements of patient-related information that can be used to map the user-selectable feed-forward inputs to corresponding insulin delivery information.

Following step 168, the process 150 proceeds to step 170 where information about the patient relating to the event defined by the feed forward input is collected and entered into the database. In one exemplary embodiment, step 166 is performed manually by having the patient maintain a log of events in written or electronic form regarding meal information and the graphical user interface with the maximum grid number. An example of such a log 20, including an example of patient-related information, is shown in fig. 13. In this illustrative example, the maximum grid number is five, so that the carbohydrate content axis and the axis of speed of overall sugar absorption will each have five selectable inputs. In the exemplary log 220 of FIG. 13, the patient enters relevant information prior to the meal or snack, and this relevant information may include, but is not limited to, the patient 'S blood glucose prior to the meal or snack, the meal type or category-e.g., "B" for breakfast, "L" for lunch, "D" for dinner and "S" for snack, estimated carbohydrates ingested (or to be ingested), EIC (e.g., in grams), estimated duration of meal effect, EMED, i.e., estimated duration of the effect of the ingested meal on the individual' S blood glucose level (e.g., in minutes), absolute duration AMD of the meal or snack (e.g., fast F, medium MF, medium M, medium slow MS and slow S), relative duration RMD of the meal or snack (e.g., longer than standard LN, slightly longer than standard SLN, standard N, slightly shorter than standard SSN or shorter than standard SN), absolute meal or snack size, AMS (e.g., large amount L, moderately large ML, moderately M, moderately small MS, or small amount S), relative meal or snack size RMS, (e.g., slightly more than standard LN, slightly more than standard SLN, standard N, slightly less than standard SSN, or less than standard SN), absolute meal size AMSF on fat content items (e.g., small S, moderately small MS, moderately M, moderately large ML, or large L), absolute meal size AMSC on carbohydrate content items (e.g., small S, moderately small MS, moderately large ML, or large amount L), absolute meal size on protein content items, AMSP (e.g., small S, moderately small MS, moderately large M, moderately large amount L), relative meal size on fat, protein, and carbohydrate content items (not shown in figure 13) (e.g., below standard SN, slightly below standard SSN, standard N, slightly above standard SLN, or above standard LN), total glycemic index TGI of the meal or snack, any meal compensation tablets MCB administered prior to the meal or snack (e.g., i.u.), any correction tablets CB administered between meals or snacks (e.g., i.u.), date, time, and the like. Although not specifically shown in fig. 13, other bolus-related information may be included in the log when meal compensation and/or correction boluses are taken over a period of time at smaller doses. In this case, the other bolus-related information may include, for example, but should not be limited to, the number of meal compensation or correction boluses administered, the time between administering boluses, and the time of administering the first bolus. Other information that may be relevant and may accordingly be included in the patient log 220 includes, but is not limited to, the intensity and duration of the pre-meal or bolus training, the stress state (distribution) and duration of the patient prior to the meal or bolus, the extent and duration of the disease of the patient prior to the meal or bolus, menstrual cycle information, such as the extent and duration of menstruation prior to the meal or bolus, and the like. Typically, it is desirable to collect the patient-related information over an extended period of time, such as four weeks for males and at least 6-8 weeks for females, although other lengths of time may alternatively be used.

It will be appreciated that none of the graphical user interfaces shown and described above with reference to fig. 2-7 are useful for all patients. Because habits, personal preferences, and the like typically vary from patient to patient, one or more graphical user interfaces may be appropriate for some patients, but others will be most appropriate for others. The specific information contained in the example log shown in fig. 13 would allow a physician or other diabetes care provider to subsequently select any of the graphical user interface examples shown and described above with respect to fig. 2-7. In the case where fewer graphical user interfaces are available, the information contained in the log example shown in FIG. 13 may similarly be reduced.

In other exemplary embodiments where the event is a meal ingested by the patient, step 170 of the process 150 is performed by having a dietician or other meal planner provide information based on the type, content and time of the specifically planned meal as shown in the example in FIG. 13. In any case, execution of process 150 proceeds from step 170 to step 172, where a determination is made as to whether sufficient patient-related information has been collected for the current number of modes. If so, the process 150 proceeds to "A" of the second processing module, and in step 172, if it is determined that the amount of patient-related information collected for the current pattern number is not yet sufficient, the process 150 returns to step 170.

Like the pre-screening process described above with respect to step 156, a minimum number m of data records should be collected before proceeding to the second processing module, where "m" is the minimum number of data records needed to achieve a useful result. Similarly, a limit is imposed on the maximum number of data records, n, by step 172, where n may represent the actual maximum number of records, the number of records beyond which it would not be possible to provide additional information, and/or the number of records beyond which it would not be possible to contribute to the development of one or more patterns that are not currently present in the data.

Referring now to FIG. 11, a flowchart of one exemplary embodiment of the second processing module of the process 150 is shown. The second processing module begins at step 174 where a series of statistical analyses are performed on the patient-related information collected at step 168 with the goal of finding a starting pattern number that has a significant impact on the user's meal category (i.e., the feed forward information selected by the user). Next, in step 176, it is determined whether the inter-class pattern recognition generated from the statistical analysis is acceptable. If acceptable, the process 150 proceeds to "B" of the third processing module. However, if the inter-class pattern recognition results from the statistical analysis of step 174 are not acceptable, the process 150 proceeds to step 178 where it is determined whether sufficient patient-related information has been collected for the current number of patterns. If not, the process 150 returns to step 170 of FIG. 10. On the other hand, if it is determined in step 178 that sufficient patient-related information has been collected for the current number of patterns, the process 150 proceeds to step 180, where it is determined whether the number of patterns PN is equal to the maximum number of patterns MAXPN. If not, the pattern number PN is incremented in step 182 and the process 150 then returns to step 174. However, if the number of patterns PN is equal to the maximum number of patterns MAXPN, in step 180, the process 150 proceeds to step 184 where an indication is made that the graphical user interface is not usable for the patient being evaluated. In embodiments where the steps 174 and 182 are performed manually by a health care professional, the step 184 may be skipped or combined with the step 182. However, in embodiments in which any one or more of steps 174-182 are performed with the aid of a computer, step 184 may be implemented by the computer displaying a message indicating that the appropriate graphical user interface is not available. Following step 184, the process 150 proceeds to step 186 where the process 150 ends.

An illustrative example of a loop including steps 174-180 in the second processing module includes repeated modeling of a given meal compensation bolus as a function of independent variables (meal type, day of week, selected input grid classification, etc.). This maximum absolute or relative prediction error may then be used as a measure of fitness when compared to a predetermined limit.

Another illustrative example of a loop including steps 174-182 in the second process module is shown in fig. 14A-14K. The examples shown in fig. 14A-14K use a metric in the form of a Coefficient of Variation (CV) as a measure of inter-class pattern recognition for separate tablet reaction forms, and apply the repeated preferred set of patient-related information until the maximum CV does not exceed a predetermined acceptable value. If this state cannot be reached, the grid-type user interface may not be suitable for the user.

To illustrate the steps of FIGS. 14A-14K, consider a reduction of a grid-type graphical user interface of the type shown and described herein to one dimension defining the dietary carbohydrate content in the form of three categories (classifications), such as "below-standard", "standard", and "above-standard". A maximum value Cvmax is then selected (e.g., Cvmax is 10%).

The statistical analysis of the user-relevant information, such as the information shown by way of example in fig. 13, is performed exemplarily in four steps. In step 1, the collected data is sorted by size category ("below standard", "above standard"), which corresponds to aggregating the data among all other variables as shown in FIG. 14A. For each of these classes, its coefficient of variation, CV, is calculated using well-known techniques. If none of the calculated coefficients CV exceeds Cvmax, the user interface is adapted to the user. In this case, the feed forward input to the user interface would in the one-dimensional case be only the meal size for the pending meal, e.g., below the norm, above the norm or norm. For example, the feed forward information to insulin bolus information map of FIG. 9 may thus be a single map that maps the feed forward input values of the meal size selected by the user to corresponding insulin bolus information for any meal taken at any time on any day of the week. In this case, the corresponding insulin bolus information may be, for example, an insulin bolus distribution equal to the average bolus distribution for the user-specific type of meal size using the information from statistical analysis step 1 of fig. 14A.

In this example, one or more of the calculated coefficients CV in step 1 (FIG. 14A) exceed Cvmax, and the statistical analysis process proceeds to step 2 accordingly. In step 2, the collected data is sorted by size type ("below standard", "above standard") and by meal type or time (breakfast, lunch and dinner), as shown in fig. 14B, which corresponds to aggregating the data over all other components. The coefficient of variation CV is then calculated from the meal size type and the meal type or time. If none of the calculated coefficients exceeds CVmax, the user interface is adapted to the user. The feed forward input to the graphical user interface in this case would be, in the one-dimensional case, a meal size value and a meal type or time value for the pending meal. The feed forward information to insulin bolus information map of FIG. 9 may thus, for example, include three maps, each mapping user-selected feed forward input values of meal size to different corresponding insulin bolus information, the mapping depending on meal type or time, such as breakfast, lunch or dinner. In this case, the corresponding insulin bolus information may be, for example, an insulin bolus distribution equal to the average bolus distribution by meal type or time for the user-specific type of meal size using the information obtained from the statistical analysis of step 2 of fig. 14B.

In this example, one or more of the calculated coefficients CV in step 2 (FIG. 14B) exceed Cvmax, and the statistical analysis process proceeds to step 3 accordingly. At step 3, as shown in fig. 14C and 14D, the collected data is sorted by size type ("below standard", "above standard"), meal type or time (breakfast, lunch and dinner) and type of date (week, weekend), which corresponds to aggregating the data across all other variables. The coefficient of variation is calculated in size type, meal type or type of time and date. If none of the calculated coefficients exceed CVmax, the user interface is suitable for the user. In this case, the feed forward input to the graphical user interface would be, in the one-dimensional case, a meal size value, a meal type or time value, and a date type value for the pending meal. The feed forward information to insulin bolus information map of FIG. 9 may thus, for example, include six maps, each mapping a user-selected feed forward input value of meal size to a different corresponding insulin bolus information, the mapping depending on meal type or time, such as breakfast, lunch or dinner, and also depending on date type, such as week or weekend. In this case, the corresponding insulin bolus information may be, for example, an insulin distribution equal to the average bolus distribution by meal type or time and by date type for the user-specific type of meal size using the information obtained from the statistical analysis of step 3 of fig. 14C and 14D.

In this example, one or more of the coefficients CV computed from step 3 (FIGS. 14C and 14D) exceed CVmax, and the statistical analysis process proceeds to step 4 accordingly. The data collected in step 4 is categorized by size type ("less than standard", "more than standard"), meal type or time (breakfast, lunch and dinner), and date of the week (sunday, monday, etc.), as shown in fig. 14E-14K. The coefficient of variation is calculated as size type, meal type or time and date of the week. If none of the calculated coefficients exceeds CVmax, the user interface is adapted to the user. The feed forward input to the graphical user interface in this case would be, in the one-dimensional case, the meal size value, meal type or time value, and the day of the week value for the pending meal. The feed forward information to insulin bolus information map of FIG. 9 may thus, for example, include 21 maps, each mapping user-selected feed forward input values of meal size to different corresponding insulin bolus information, the mapping depending on meal type or time, such as breakfast, lunch or dinner, and also depending on the day of the week, such as sunday, monday, etc. In this case, the corresponding insulin bolus information may be, for example, an insulin bolus distribution that is equal to the average bolus distribution by meal type or time and also by date of the week using the user specific kind of meal size of the information obtained from the statistical analysis step 4 in fig. 14E and 14K.

In any or all of the above steps, the type of meal or time, date type, and/or date of the week may be automatically determined by the system 10, and thus need not be manually entered into the graphical user interface by the patient. It will be appreciated that while the foregoing example uses a variable coefficient as a metric for the measure of inter-class pattern recognition in the form of a distribution of tablet responses, one or more other common metrics may be used for the statistical analysis performed in accordance with steps 174-82 of FIG. 11.

In embodiments of the user interface in which at least one of its axes represents a (pseudo) continuous input, such as the interfaces shown and described with reference to fig. 6 and 7, a model or series of models of the dose of the meal compensator may be developed. The model or series of models will be a function of various input variables, with one of the user-selected classifications being located on a continuous axis of the user interface. If the model is sufficiently rigid, extrapolation may be used to determine a bolus amount recommendation if the user selects a continuous input value that falls outside the range covered during learning.

Referring now to FIG. 12, a flowchart of one exemplary embodiment of a third process module of the process 150 is shown. If the third block of the process 150 is reached, the second processing block of FIG. 11 successfully determines a pattern of patient-related information from which the user-selected feed forward information can be mapped to corresponding insulin bolus information. The goal of the third processing module is to reduce the number of categories of feed forward inputs that the user selects when possible. In the illustrated embodiment, the third processing module of FIG. 12 achieves this goal by merging adjacent categories of user-selectable feed-forward inputs where appropriate. For example, it may be appropriate to combine the categories of user-selectable inputs for a particular mode into a single category of "standard" as determined by the third processing module of FIG. 12 for both "standard" and "above-standard".

The third processing block begins at step 188 where a counter K is set to 1. Thereafter, in step 190, the Kth pattern element in the generated pattern of the second processing module of FIG. 11 is selected for processing. Then, in step 192, a merging solution for the kth pattern element is generated. As shown by way of example below, step 192 includes identifying various possible cluster merges of user-selectable feed-forward inputs to a particular pattern element that are being processed. Following step 194, a statistical analysis of the patient-related information is performed for each category merging scenario to identify whether any one or more categories can be merged. Then in step 196, the best class merging scheme from the statistical analysis of step 194 is selected based on one or more performance metrics. As used herein, "optimal" is defined as, among the competing policies, applying the cost function to all competing policies by defining an appropriate cost function with appropriate weights, and selecting the policy selected by the policy with the least cost. Additional constraints that must be met in solving the problem of the best-kind merging scheme may also be defined. Examples of such additional restrictions include, but are not limited to, the same kind of grid needed in all K elements of the grid pattern, a combination of entire rows and columns of the kind needed, and the like.

Following step 200, it is determined whether steps 192-198 have resulted in a change, such as a merge, to any of the types of elements of the K patterns. If so, the process proceeds to step 202, where it is determined whether the total number of categories for the current K pattern elements is equal to the minimum desired number MIN of categories, e.g., one or more. If not, the process 150 returns to step 192. If it is determined in step 200 that none of the categories of the K pattern elements have changed, or the total number of categories is equal to the minimum number of categories MIN in step 202, the processing of the K pattern elements has been completed, and the process 150 proceeds to step 204 where it is determined whether K is equal to the total number of pattern elements. If not, then the pattern elements have not all been processed and process 150 proceeds to step 206 where the value of "K" is incremented by 1 and then returns to step 190 to process the next pattern element. When all pattern elements have been processed, step 204 proceeds to step 208 where one or more maps, such as the type shown in FIG. 9, are created that map the user-selectable feed forward input type or combination of types to the corresponding insulin delivery information. The process 150 then stops in step 210, and the graphical user interface and the one or more feed-forward to insulin delivery information mappings established by the process 150 can be implemented in the system 10 and used as described above with reference to FIGS. 2-9 to suggest or administer insulin to the patient based on the user-selectable feed-forward information provided to the interface by the patient.

Examples of patient-related information patterns generated using fig. 14A-14K will be used herein as examples to illustrate the operation of the third processing module of fig. 12. In this example, 21 one-dimensional pattern elements were developed, such as a pattern of meal size for each of the three meal types for each of the seven days of the week. The total number of pattern elements in this example is thus 21 and the outer loop defined by step 206 will be executed 20 times accordingly. The order in which the 21 different pattern elements are processed may be arbitrary, and in this example the first pattern element (K ═ 1) is monday breakfast, followed by monday lunch, monday dinner, tuesday breakfast, and so on. The first execution of step 190 thus selects the Monday breakfast mode element.

For ease of description of this third processing block, the "few", "standard" and "many" feed forward input categories are specified numerical values in the example shown in fig. 14A-14K, such as "few" as 1, "standard" as 2 and "many" as 3. Specifying hyphens between classes as distinguishing merge classes, the three possible class merge schemes obtained from step 192 are thus:

((1，1)，(2，1)，(3，1))

([ 1-2 ], 1), (3, 1)), and

((1，1)，(［2－3］，1))

it corresponds to the breakfast on monday ((less, more, less + more, more) and (less, more + more)).

In one exemplary embodiment, the statistical analysis of each category consolidation scheme is performed by increasing the number of categories in 2 steps in the consolidation scheme until the entire sample distribution along the meal size axis is covered. It may be desirable, although not necessary, to use an equally wide variety. It is also desirable to focus each class on the middle of the sample distribution. Estimating the acceptability of each combining scheme may be accomplished in a number of different ways. In an exemplary embodiment, the difference between the minimum and maximum values and the median value for each category is converted to an increased insulin bolus value. Ultimately, the increased insulin bolus value is converted to a desired difference or percentage to the postprandial glycemic target. These differences or percentages may in turn be compared to one or more predetermined threshold levels to determine whether the sort of merging scheme is acceptable. In an alternative embodiment, multiple hypothetical samples may be extracted from the sample distribution for each class for Monte Carlo simulations. The deviation of each sample from the median value of the class is then processed in the same way as in the previously described embodiment.

The result of step 194 is the identification of all acceptable categories of consolidated solutions based on a statistical analysis of each solution. Step 194 will always result in at least one protocol because the original protocol, e.g., no kind merge ((1, 1), (2, 1), (3, 1)) is included in the analysis. If more than one scenario is formed from step 194, step 196 selects the "best" scenario from the multiple scenarios from step 194 based on one or more performance metrics. For example, the one or more performance metrics may include, but are not limited to, one or any combination of average or median data variation in each scenario, an estimate function associated with each scenario, a desirability of having fewer than all categories, a benefit of reducing the number of categories by one increment, and the like. Those skilled in the art will appreciate other techniques for selecting the "best" of the multiple kinds of merge scenarios from step 194, and such other techniques are contemplated by the present disclosure.

At step 198, the feed forward input categories for Monday breakfast are combined according to the "best" combination scheme determined by step 196. An exemplary result may be the second merging scheme shown above, which may be implemented by merging the "few" and "standard" categories into the "standard" category, so that there are only two "standard" and "many" criteria. In any case, step 202 directs the process 150 back to step 192- "200 until the total number of categories no longer changes, and step 204 directs the process 150 back to step 192-" 202 until all pattern elements, such as until sunday dinner, are processed. The result of the third processing module shown in fig. 12 on the exemplary one-dimensional data set of fig. 14A-14K is user selectable feed forward information displayed to the patient for any meal on any date of the week, which may include one, two or three input categories.

In the previous example, the feed forward input categories are represented by one-dimensional information in the form of meal size, and the total number of input categories is three, such as "small", "standard", and "large". It will be appreciated that in embodiments of a graphical user interface comprising axes of multidimensional information, i.e. a plurality of user selectable feed forward information, the number of category merging schemes increases significantly. The number of species merging schemes similarly increases as the total number of user-selectable feedforward species increases. For example, in an embodiment of a graphical user interface that includes two-dimensional information, such as a meal size axis and a meal speed axis, and four user selectable categories of feed forward information, such as "little," "little, much," "many," and "slow," "medium fast," "fast," along each axis, a possible category merging scheme is (if numerals 1-4 are assigned to the four input values for each axis):

((1，1)，(1，2)，(1，3)，(1，4)，(2，1)，(2，2)，(2，3)，(2，4)，(3，1)，(3，2)，(3，3)，(3，4)，(4，1)，(4，2)，(4，3)，(4，4))；

((1，［1－2］)，(1，3)，(1，4)，(2，［1－2］)，(2，3)，(2，4)，(3，［1－2］)，(3，3)，(3，4)，(4，［1－2］)，(4，3)，(4，4))；

((1，1)，(1，［2－3］)，(1，4)，(2，1)，(2，［2－3］)，(2，4)，(3，1)，(3，［2－3］)，(3，4)，(4，1)，(4，［2－3］)，(4，4))；

((1，1)，(1，2)，(1，［3－4］)，(2，1)，(2，2)，(2，［3－4］)，(3，1)，(3，2)，(3，［3－4］)，(4，1)，(4，2)，(4，［3－4］))；

((［1－2］，1)，(［1－2］，2)，(［1－2］，3)，(［1－2］，4)，(3，1)，(3，2)，(3，3)，(3，4)，(4，1)，(4，2)，(4，3)，(4，4))；

((1, 1), (1, 2), (1, 3), (1, 4), ([ 2-3 ], 1), ([ 2-3 ], 2), ([ 2-3 ], 3), ([ 2-3 ], 4), (4, 1), (4, 2), (4, 3), (4, 4)); and

((1，1)，(1，2)，(1，3)，(1，4)，(2，1)，(2，2)，(2，3)，(2，4)，(［3－4］，1)，(［3－4］，2)，(［3－4］，3)，(［3－4］，4))。

in this case, two rows at one time may be merged to create the merged set of categories.

The patient tunes the system 10 by interacting with the system 10 on a daily basis. It is desirable to use this daily interaction in a "learning" mode to establish a patient-specific history of treatment delivery from which one or more patterns can be extracted for the purpose of updating or re-tuning the graphical user interface described herein, which interaction can be supplemented with additional patient and/or healthcare professional feedback. Herein, learning includes monitoring patient interaction with a graphical user interface and monitoring feedback from the patient and a healthcare professional and adapting operation of the graphical user interface based on information from the monitoring. For purposes herein, learning does not include the initial training process described herein to collect patient-related information and build a graphical user interface from the collected information.

In practice the treatment may vary for any of several reasons. For example, a patient may change his or her lifestyle, such as modifying or introducing daily training habits. As another example, a patient may intentionally or unintentionally change his or her eating habits, such as by consuming a lesser or greater amount of food during a meal and/or snack time. As another example, the patient's short and/or long term weight may change due to training, illness, eating less or more food in the diet, changes in body metabolism, and the like.

Referring to FIG. 15, a flow diagram of one exemplary embodiment of a process 200 for continuous learning of a graphical user interface of the type shown and described herein is shown. The process 200 may be performed by the processor 14, may be performed manually, or may be performed by a combination of manually performed steps and steps performed by the processor 14. However, for purposes of this description, the process 200 may be described as being performed by the processor 14. The process 200 begins at steps 250, 252, 254, and 256, where the processor 14 is operated in a time-sharing mode of operation, or where multiple processors are operated or continuously executing code to monitor patient acceptance or rejection of insulin delivery recommendations generated by the system 10 in embodiments where the system 10 is configured to make such recommendations, to monitor any user input to the system 10 for feedback, to monitor any feedback or other information input to the system 10 by a health care professional, and/or to monitor one or more model-based functions, each of which is responsive to one or more measurements of patient conditions to estimate other patient conditions different from the one or more patient conditions. Any of the monitoring may include storing information. Any such stored information may be evaluated immediately or at a later time and/or may be re-evaluated upon new inputs or updates to the database and/or one or more system control algorithms. Examples of user feedback input to system 10 include, but are not limited to, any of the information shown in FIG. 13, user input to the GUI of the application, and other user-related information such as training, stress, and/or intensity or status of disease, menstrual cycle information, results of one or more monitored physiological states of the user, results of monitored glycemic control of the user-such as the use of HbA1C, and the like. Any of the information may be entered into the system 10 by any of the means described above. Alternatively or additionally, the input devices 18 and/or 36 may include a plurality of dedicated input buttons, keys, or the like that may be color coded or otherwise readily identifiable, which enables a user to input a common or uncommon behavior or condition via a readily identifiable input device. Examples of Health Care Professional (HCP) feedback entered into the system 10 include, but are not limited to, results of tests performed by the health care professional, dietary, training, and/or other lifestyle-related advice or recommendations, results of one or more HCP-monitored physiological conditions, results of HCP-monitored glycemic control, e.g., using HbA1c, and the like. Examples of model-based functions include, but are not limited to, model-based estimates of glucose absorption, insulin usage, and the like based at least in part on blood glucose and/or HbA1c measurements.

In any case, the process 200 proceeds from step 250-. The processor 14 is operative to perform step 258 by processing information that has been provided in steps 250 through 256 over time. For example, if the processor 14 determines that insulin delivery information suggested by the system 10 has been continuously rejected or corrected for a period of time, the processor 14 may be operable to continue the "no" branch of step 258. Similarly, if the processor 14 determines from the feedback information provided by the user, the feedback information provided by the health care provider, and/or the model-based information that one or more operating characteristics of the graphical user interface are discontinuous in the parameters used to determine and define the GUI, the processor 14 may be operated to continue the NO branch of step 258. Other factors to consider and other techniques for determining whether the currently applied GUI is acceptable will occur to those skilled in the art and are contemplated by the present disclosure.

If the processor 14 determines in step 258 that the currently applied GUI is still acceptable, execution of the process 200 proceeds to step 260 where the processor 14 is operated to determine if the currently applied GUI requires any re-correction. In general, one or more of the same considerations used in step 258 may be used by processor 14 in step 260 to make the above-described determination. If the processor 14 determines that the currently applied GUI does not require recalibration, execution of the process 242 returns to performing step 250 along with 256. On the other hand, if in step 260 processor 14 determines that the currently applied GUI requires re-calibration, execution of process 200 jumps to step 152 of process 150 shown and described with respect to FIGS. 10-12. Here, the mapping that relates the user-selectable feed-forward input to the currently applied GUI to the corresponding insulin delivery information may be modified by the processor 14 according to the patient-specific history collected during the repeated execution of the process 200.

If processor 14 determines in step 258 that the currently applied GUI is no longer acceptable, execution of process 200 proceeds to step 262 where processor 14 controls display unit 20 and/or 38 to display a message suggestion to develop another GUI. From step 262, execution of process 200 proceeds to step 264, where processor 14 is operated to prompt the user to respond to the suggestion displayed in step 262. If the user chooses not to accept the suggestion, execution of process 200 returns to step 250-. On the other hand, if the user elects to accept the suggestion displayed in step 262 in step 264, execution of process 200 jumps to step 152 of process 150 shown and described with respect to FIGS. 10-12. Here, the processor 14, user, and/or healthcare professional may select a different GUI or may determine that none of the selectable GUIs is appropriate for use by the patient.

The learning process 200 uses the entered information to build a patient history from which to extract patterns of patient treatment. In embodiments where the process 200 is performed by the processor 14, the processor 14 may be configured to perform the process 200 in the context of normal operation of the system 10. The processor 200 may also be designed to execute synchronously with the system 10 in normal operation.

The learning process 150 may be protocol driven to achieve appropriate variability, which is suitable for obtaining pattern information. Alternatively or additionally, the interaction may be in a free type, where daily activities will be entered along with the treatment. The length of the learning interaction may be designed to be some fixed number of days. Alternatively or additionally, the type of convergence may be applied to identify the end of a particular learning period, such as a constant statistical distribution parameter exceeding a particular threshold.

The learning process 150 can be illustratively applied as a module that works with other therapy recommendation support applications. In this case, the learning process 150 may be used to map the user's personal input to a standardized and quantified therapy, such as insulin dosage. Once quantified and standardized, the suggestion information or command suggestion information may be passed to or incorporated with the third party suggestion support application's input. The learning process 150 may thus be used to directly provide therapy or provide information that may be suggested by a third party for use by a support application, for example, for transmitting infusion information to an attached infusion pump.

Quantifying meals is sometimes difficult for patients. However, the quality of the input to the learning process 150 is a burden on the patient and/or healthcare professional. The limitations of data acceptance in the learning process 150 are thus based on implicit understanding: the data record provided to the learning process 150 represents quality information, which contains new content and additional useful information.

In certain embodiments, the patient will provide the event and the treatment will also be administered. Because the patient may or may not administer the treatment suggested by the system 10, in this case the patient trains the system 10 in terms of how they map the treatment. Changes or modifications to the treatment are expected to be made directly by the patient by skipping the proposed treatment. The learning process 200 in turn provides a statistically distributed content of the total collected information.

The statistical portion of the collected data may be analyzed to provide monitoring information. The data analysis may illustratively be divided into two data sets: (1) the data set occupied by the old data and (2) the data set occupied by the most recent data set. The old data set represents the data distribution when the treatment was last rescheduled. The most recent data set relates to data around a current time window having a time range of, for example, about one month or the like. The two sets of data distributions may then be compared, and the changes found between the two distributions are generally indicative of changes in the patient's lifestyle and/or accumulated changes in treatment-related parameters. This may lead to different options to correct the mapping or treatment. This analysis may be triggered when any new data records are received and/or after a batch of new data records is received. The need to change treatment is based on monitoring statistical properties between the original record set and the new data record.

The regular modification of the insulin information suggested by the system 10 by the patient is typically an indication of (1) insufficient or inadequate learning by the system 10 and/or (2) the inability of the original therapy to meet the current therapy needs. For example, when a patient has experienced a lifestyle change that results in inadequate or incorrect treatment information being suggested by the system 10. The frequency of occurrence of patient overrules (overrates) may thus be used as a trigger for revising the mapping or therapy.

Monitoring of therapy may be enhanced if blood glucose measurements are available to the system. Irregular monitoring may be enhanced using a patient model that may be used to monitor and predict blood glucose levels. The effect of the treatment is included in the patient model. The patient model may be considered individually for a particular patient or may be a suitable demographic model representing patient behavior. This glucose measurement or predicted glucose measurement provides a monitoring module that can indicate that the current treatment is biased and that further specific data is needed to improve the treatment.

The treatment is typically assessed by the patient by checking for deviations from the proposed treatment. If the proposed treatment is regularly amended (overruled), this indicates that the patient's behavior has changed and the GUI should make corrections. The description of the statistics is measured continuously. As the treatment and/or meal input profile changes, it can be used to monitor the changes. Other markers of blood glucose measurement and good glycemic control, such as HbA1c, etc., provide a check on the effectiveness of the treatment.

While the invention has been illustrated and described in detail in the foregoing drawings and description, the same is to be considered as illustrative and not restrictive in character, it being understood that only illustrative embodiments have been shown and described and that all changes and modifications that come within the spirit of the invention are desired to be protected and that while presently preferred embodiments of the invention have been shown and described, it is to be distinctly understood that the invention is not limited thereto but may be otherwise variously embodied and carried out within the scope of the following claims.

Claims (20)

1. A system for determining medication administration information for a user based at least on the user ingesting a meal, the system comprising:

an input device for user input of feed forward information in the form of meal information having a first parameter component corresponding to the carbohydrate content of the meal and a second parameter component corresponding to the expected speed of total glucose absorption from the meal by the user, wherein the meal information is related to a meal to be ingested in the future,

a data storage device having stored therein a mapping associating a first parameter component value and a second parameter component value with administration information,

a processor responsive to user input of the feed forward information to determine corresponding drug administration information from the mapping,

wherein the input device includes a display unit, and wherein the processor controls the display unit to display a graphical user interface,

wherein the graphical user interface has a first axis defined by values of the first parameter component and a second axis defined by values of the second parameter component, the graphical user interface for user input of feed forward information in the form of user selection of corresponding pairs of the first and second parameter components; and

wherein the input device and the processor provide the user with the ability to modify one or more of the time and date stamp information associated with previously entered meal information after actual meal ingestion.

2. The system of claim 1, wherein the graphical user interface comprises a touch-responsive interface and defines a grid-type user interface for user selection of respective first and second parameter component value pairs.

3. The system of claim 1, wherein the graphical user interface defines a continuous function of the first and second parameter components.

4. The system of claim 1, wherein the administration information is related to a hypoglycemic agent or insulin.

5. The system of claim 1, wherein the processor controls the display unit to display the carbohydrate content value through the graphical user interface in a format selected from a direct estimate of carbohydrate weight, a meal size value, and a meal size value relative to a reference meal size.

6. The system of claim 1, wherein the processor controls the display unit to display the expected speed value through the graphical user interface in a format selected from a meal duration value, a meal duration value relative to a reference meal duration, and a total glycemic index value.

7. The system of claim 1, wherein the processor controls the display unit to display the expected speed value in a format including a fat amount, a protein amount, and a carbohydrate amount via the graphical user interface, and to display the carbohydrate content value in a format including meal size values for each of the fat amount, protein amount, and carbohydrate amount.

8. The system of claim 1, wherein the graphical user interface is for user input including feed forward information in a user selected format of a meal size value in terms of fat amount, a meal size value in terms of protein amount, and a meal size value in terms of carbohydrate amount, and wherein the processor controls the display unit to display the meal size values through the graphical user interface in the form of fat amount, protein amount, and carbohydrate amount relative to a reference meal size value in terms of fat, protein, and carbohydrate amounts, respectively.

9. The system of claim 1, wherein the input device is for user input of additional feed forward information including at least one of training information, user stress information, user illness information, and user menstrual cycle information,

wherein the data storage device has stored therein an additional map that associates at least one of the training information, user stress information, user illness information, and user menstrual cycle information with modification information, and,

wherein the processor is responsive to user input of at least one of the training information, user stress information, user illness information, and user menstrual cycle information to modify the corresponding medication administration information in accordance with the modification information determined by the additional mapping.

10. The system of claim 1, wherein the processor is operable to determine whether a complete user input to the graphical user interface has been detected, and wherein the processor is operable to tag the graphical user interface input by time and date, and if the processor detects that a complete user input to the graphical user interface has occurred, to input the graphical user interface input tagged by time and date to a database contained within the data storage device.

11. The system of claim 1, wherein the system provides the user with the ability to append new or more accurate information to previously entered meal information.

12. The system of claim 1, wherein the processor controls the display unit to display at least some of the corresponding medication administration information via the graphical user interface.

13. The system of claim 12, wherein the processor monitors for the occurrence of user acceptance and rejection of the displayed corresponding medication administration information as determined from the mapping and determines whether the system is acceptable for use by the user based at least in part on the occurrence of user acceptance and rejection of the corresponding medication administration information.

14. The system of claim 13, wherein if the processor determines that the system is acceptable for user use, the processor determines whether the system requires recalibration based at least in part on the occurrence of user acceptance and rejection of the administration information.

15. The system of claim 1, further comprising means for user feedback information input, and wherein the processor monitors user feedback information and determines whether the system is acceptable for user use based at least in part on the user feedback information.

16. The system of claim 15, wherein if the processor determines that the system is acceptable for user use, the processor determines whether the system requires recalibration based at least in part on the user feedback information.

17. The system of claim 1, further comprising means for input of healthcare professional feedback information, and wherein the processor monitors the healthcare professional feedback information and determines whether the system is acceptable for use by a user based at least in part on the healthcare professional feedback information.

18. The system of claim 17, wherein if the processor determines that the system is acceptable for use by a user, the processor determines whether the system requires recalibration based at least in part on the healthcare professional feedback information.

19. The system of claim 1, further comprising at least one model-based function responsive to a measurement of one or more user conditions to estimate another user condition that is different from the one or more user conditions, and wherein the processor monitors the at least one model-based function and determines whether the system is acceptable for use by the user based at least in part on the at least one model-based function.

20. The system of claim 19, wherein if the processor determines that the system is acceptable for user use, the processor determines whether the system requires recalibration based at least in part on the at least one model-based function.