HK1144660A - Patient information input interface for a therapy system - Google Patents

Description

Patient information input interface for a therapy system

Technical Field

The present invention relates generally to techniques for determining treatment information, such as medications and other treatment information, and more particularly to a system for determining such treatment information from patient input of information characterized by at least one patient event or condition.

Background

There are a variety of medication control arrangements that are configured to suggest or automatically administer medication therapy based on some amount of information provided by the patient. It is desirable to provide a patient-specific interface that a patient may routinely use to provide information that is characteristic of at least one patient event or condition and that uses the provided information to determine a corresponding medication and/or other treatment.

Disclosure of Invention

The invention may comprise one or more of the features recited in the appended claims and/or one or more of the following features and combinations thereof. A method is provided for developing a patient interface for a therapy system that a patient may use to enter information that characterizes at least one patient event or condition and from which therapy information can be determined. The method can comprise the following steps: developing a patient model configured to simulate a patient's physiological response to at least one patient event or condition; collecting patient-specific information related to an actual occurrence of at least one patient event or condition over time (over time); and defining a graphical interface based on the patient model and the collected patient-specific information, the graphical interface mapping information input by the patient that is characteristic of at least one patient event or condition to corresponding therapy information.

The therapy information includes medication therapy information corresponding to one or more medications administered to the patient at some time. The allotted time may be, for example, a current time, a future time, a time determined by analysis, a time determined by an end user, a time window, and so forth. Alternatively or additionally, the treatment information may include proposed carbohydrate intake information corresponding to a recommendation to ingest carbohydrates. Alternatively or additionally, the therapy information may include proposed motion information corresponding to a suggested motion. Alternatively or additionally, the treatment information may include a recommendation to visit a physician.

Defining the graphical interface may include selecting a graphical interface having two input parameters that are characteristic of at least one patient event or condition. Defining the graphical interface may further include defining a solution space (solution space) of the selected graphical interface based on the patient model and based on the collected patient-specific information. Defining the graphical interface may further include defining a mapping for mapping two input parameters characterizing at least one patient event or condition to corresponding therapy information.

The method may further include using the graphical interface to map the information input by the patient that is characteristic of the at least one patient event or condition to corresponding treatment information. The corresponding therapy information may include drug administration information. The method may further include displaying the drug administration information in the form of a suggested dose of the drug. Alternatively or additionally, the method may further comprise controlling the drug dispensing device to dispense at least one quantity of drug to the patient in dependence on the drug dispensing information.

In another embodiment, a method of developing a patient interface for a therapy system is disclosed that a patient may use to input information that characterizes at least one patient event or condition and from which therapy information can be determined. The method comprises the following steps: receiving patient-specific information having input parameters characterizing at least one patient event or condition; identifying which input parameters do not correspond to respective predetermined values provided in the predetermined treatment information; establishing a constraint minimization problem for the identified input parameters; generating a solution space from solving the constraint minimization problem, wherein the solution space defines a relationship between the input parameters and their associated acceptable limits to adjust the patient's physiological response to the desired target response; and implementing the solution space as a patient interface.

A system for developing a patient interface for a therapy system, the patient interface usable by a patient to input information characterizing at least one patient event or condition and from which therapy information can be determined, the system comprising: a database storing therein a patient model configured to simulate a physiological response of a patient to at least one patient event or condition; a first memory configured to store patient-specific information related to an actual occurrence of at least one patient event or condition therein over time; and a graphical interface configured to map patient input from information characterizing at least one patient event or condition to corresponding treatment information according to the patient model and according to the collected patient-specific information.

The system may further include a processor having access to a second memory for storing therein instructions executable by the processor to process the patient's input into a graphical interface of information characterizing at least one patient and generate corresponding therapy information. The system may further comprise a display unit. The second memory further may have stored therein instructions executable by the processor to control the display unit to display the corresponding therapy information. The system may further comprise a manually actuated drug dispensing device. The corresponding therapy information may include at least one drug quantity. The second memory may further have stored therein instructions executable by the processor to control the display unit to display at least one amount of the drug that the patient dispensed with the manually actuated drug dispensing device. The system may further include a blood glucose sensor configured to measure a blood glucose level of the patient and generate a corresponding blood glucose value. The second memory may further have stored therein instructions executable by the processor to determine the at least one drug quantity further as a function of the blood glucose value.

Alternatively or additionally, the system further comprises an electronically controllable drug delivery device configured to deliver at least one drug to the patient. In one embodiment the respective treatment information may comprise at least one quantity of medication and in another embodiment may comprise a dispensing sequence of the medication determined by time and quantity. The second memory may further have stored therein instructions executable by the processor to control the electronically controllable drug dispensing device to dispense at least one quantity of drug to the patient. The system may further include a blood glucose sensor configured to measure a blood glucose level of the patient and generate a corresponding blood glucose value. The second memory may further have stored therein instructions executable by the processor to determine the at least one drug quantity further as a function of the blood glucose value.

The graphical interface may be configured to map at least two parameters input by the patient that are characteristic of at least one patient event or condition to corresponding treatment information.

Drawings

FIG. 1 is a block diagram of one illustrative embodiment of a system for determining treatment information.

FIG. 2 is a flow chart of one illustrative process for developing a patient interface for use with the system of FIG. 1 to enable a patient to input patient-related information from which treatment information may be determined.

FIG. 3 is a schematic diagram showing possible components of an exemplary patient-specific glucose regulation model configured to input patient-specific information characterizing at least one patient-related event or condition.

Fig. 4 is a block diagram illustrating an atrioventricular model of arterial inflow and venous outflow for developing a glucose regulation model to simulate the distribution of glucose concentration and insulin in various organs and body regions.

FIG. 5 is a schematic illustration of the glucose regulation model of FIG. 3 constructed using the several atrioventricular models of FIG. 4 for simulating glucose concentrations in various organs and body regions.

FIG. 6 is a schematic illustration of the glucose regulation model of FIG. 3 constructed using the several atrioventricular models of FIG. 4 for simulating insulin kinetics in various organs and body regions.

FIG. 7 illustrates one embodiment of a graphical patient interface for entering meal-related information into the system of FIG. 1.

FIG. 8 illustrates another embodiment of a graphical patient interface for entering meal-related information into the system of FIG. 1.

FIG. 9 illustrates yet another embodiment of a graphical patient interface for entering meal-related information into the system of FIG. 1.

FIG. 10 illustrates yet another embodiment of a graphical patient interface for entering meal-related information into the system of FIG. 1.

FIG. 11 illustrates yet another embodiment of a graphical patient interface for entering meal-related information into the system of FIG. 1.

FIG. 12 illustrates yet another embodiment of a graphical patient interface for entering meal-related information into the system of FIG. 1.

FIG. 13 is a chart of meal space input parameters used to illustrate the composition of the periphery of an exemplary graphical interface;

FIG. 14 is a plot of insulin bolus quantity versus total meal space η illustrating a solution space resulting from composition of the periphery of the exemplary graphical interface of FIG. 13^A/SA graph of (a).

FIG. 15 is a graph of one of the meal space parameters versus a plurality of discrete inputs;

FIG. 16 is a table illustrating one embodiment of a mapping relating patient input of meal information provided in the form of carbohydrate content, e.g., meal size, desired glucose absorption shape, and duration, e.g., meal duration, to corresponding medication information.

Fig. 17 is a block diagram illustrating the system of fig. 1 implemented in a semi-closed loop drug dispensing system.

Fig. 18 is a flow chart illustrating one embodiment of a software algorithm executable by the system of fig. 1 for determining medication information based on meal information entered by a user using one of the graphical patient interfaces of fig. 7-12.

Detailed Description

For the purposes of promoting an understanding of the principles of the invention, reference will now be made to a number of illustrative embodiments shown in the drawings and specific language will be used to describe the same.

With reference to fig. 1, a block diagram of one illustrative embodiment of a system 10 for determining treatment information is shown. In the illustrated embodiment, the system 10 includes an electronic device 12 having a processor 14 in data communication 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 Data Assistant (PDA) or other handheld device, an external infusion pump, a blood glucose meter, an analyte sensing system, and so forth. Electronic device 12 may be configured to operate in accordance with one or more conventional operating systems including, for example and without limitation, windows, linux, and MacOS, as well as embedded OSs such as QNX, eCOS, WinCE, and palm OS, and electronic device 12 may be configured to process data in accordance with one or more conventional internet protocols, for example and without limitation, NetBios, TCP/IP, and AppleTalk. In the illustrated embodiment, processor 14 is microprocessor-based, although processor 14 may alternatively be comprised of one or more general purpose and/or application specific circuits and be operable as described hereinafter. In the illustrated embodiment, memory 16 includes sufficient capacity to store data, one or more software algorithms executable by processor 14, and other data. Memory unit 16 may include one or more conventional memories or other data storage devices. Alternatively or additionally, the system 10 may include a U3 smart USB device having sufficient capacity to store data and one or more software algorithms executable by the processor 14.

The input device 18 may be used to input and/or modify data in a conventional manner. In the illustrated embodiment, a display 20 is also included for viewing information related to the operation of device 12 and/or system 10. Such a display may be a conventional display device including, for example and without limitation, a Light Emitting Diode (LED) display, a Liquid Crystal Display (LCD), a Cathode Ray Tube (CRT) display, and the like. Alternatively or additionally, the display 20 may be or include an audible display configured to communicate information to a user, another person, or another electronic system having voice recognition capabilities through one or more coding 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 is perceptible to a user or others. A camera for capturing and storing food photographs and/or other photographs is also included.

In one embodiment, the input device 18 may be or include a conventional keyboard or keypad for entering alphanumeric data into the processor 14. Such a keyboard or keypad may include one or more keys or buttons configured with one or more tactile indicators to enable a user with poor eyesight to locate and select the appropriate key or keys and/or to enable a user to locate and select the appropriate key or keys in the event of poor lighting. Alternatively or additionally, the input device 18 may be or include a conventional mouse or other conventional pointing device for selecting information presented 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 selects by touching the appropriate portion of the display 20 with the appropriate tool. Alternatively or additionally, input device 18 may include a plurality of switches or buttons that are activated by a user to select respective operating features of device 12 and/or system 10. Alternatively or additionally, the input device 18 may be or include a voice activated circuit responsive to voice commands to provide corresponding input data to the processor 14. In any case, the input device 18 and/or the display 20 may include the electronic device 12 as shown by dashed lines 22A and 22B or be separate from the electronic device 12.

In one or more embodiments, the system 10 may include N medical devices 26₁-26_NWherein N is any positive integer. In this embodiment, one or more medical devices 26 may be coupled₁-26_NEither implanted in the patient, coupled to the patient's body externally (e.g., such as an infusion pump), or separate or remote from the patient's body. Alternatively or additionally, one or more medical devices 26₁-26_NMounted on electronic device 12 and/or formed as part of electronic device 12. In the illustrated embodiment, a plurality of medical devices 26 are provided₁-26_NAre configured to pass 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. The form of wireless communication used may include, but should not be limited to, Radio Frequency (RF) communication, Infrared (IR) communication, WiFi, RFID (inductive coupling) communication, acoustic communication, capacitive signals (over electrical conductors), current signals (over electrical conductors), and the like. In any such case, the electronic device 12 and the plurality of medical devices 26₁-26_NIncludes conventional circuitry for implementing such wireless communication circuitry. Alternatively or additionally, one or more medical devices 26 may be used₁-26_NConfigured to communicate with electronic device 12 via one or more conventional serial or parallel configured hardwired connections therebetween and/or via one or more other conventional communication hardware, software, and/or firmware.

One or more medical devices 26₁-26_NMay include a conventional processing unit,Conventional input/output circuitry and/or devices, and any one or more suitable data and/or program storage devices. One or more medical devices 26₁-26_NExamples of (b) include, but are not limited to, one or more blood glucose sensors, one or more body temperature sensors, one or more medication delivery devices, and the like. In one or more implementations, in addition to one or more medical devices 26₁-26_NIn addition to or in place of one or more medical devices 26₁-26_NElectronics 12 may include an on-board (on board) analyte sensor in the form of a conventional reader 27 configured to receive a conventional strip or carrier 29. In this embodiment, the strip or carrier 29 is configured to receive a sample of blood or other bodily fluid and insert it into the reader 27. The reader 27 is electrically connected to the processor 14 and, under the control of one or more software algorithms stored in the memory 16, the processor 14 is operable to process the electrical signals generated by the reader 27 to determine at least one characteristic of an analyte contained in a liquid received on the strip or carrier 29. Illustratively, the liquid may be blood, the analyte is blood glucose, and the at least one characteristic of the analyte may include a glucose concentration in the blood. In this embodiment, the analyte sensor is a blood glucose sensor provided in the form of a conventional blood glucose reader 27. In this embodiment, the blood glucose sensor may be a conventional electrochemical or photometric sensor. However, it should be understood that the analyte sensor may alternatively be configured to analyze other liquids, analytes, and/or analyte characteristics. Any of the one or more medical devices 261-26N may include a smart card or biometric for carrying confidential information and/or related medical records.

In some embodiments, system 10 may alternatively or additionally include remote device 30, as illustrated by the dashed line (phantom) in fig. 1. Remote device 30 may include a conventional processor 32, which may be the same or similar to processor 14, a conventional memory or other data storage unit 34, a conventional input device 36, which may be or include any one or more of the input devices described below with respect to input device 18, a conventional display unit 38, which may be or include any one or more of the display units described below with respect to display unit 20, and conventional communication I/O circuitry 40. Remote device 30 may be configured to communicate with electronic device 12 through any conventional wired or wireless communication interface 42, which may be or include any of the communication interfaces or links described hereinabove.

Throughout this document, examples of various structures, processes, and techniques are provided to illustrate and describe the principles of the disclosure. To maintain consistency, these examples are related to diabetes control schedules in which one or more recommended or automatically administered pills of a hypoglycemic drug are the mechanisms illustrated and described for diabetes control, and in particular to meal-related information as illustrated and described patient input information from which one or more recommended or automatically administered insulin pills can be determined. It should be understood that such examples are for illustrative purposes only and should not be construed as being limiting in any way. Rather, it should be understood that this disclosure relates to any treatment system in which the administration of one or more drugs represents only one form of treatment, and that other forms of treatment may alternatively additionally be determined and suggested in accordance with this disclosure. Examples of such other forms of treatment may include, but are not limited to, suggesting exercise, suggesting ingestion of food, such as carbohydrates, suggesting counseling and/or attending a doctor, and so forth. It should also be appreciated that in the context of a diabetes control system, this disclosure contemplates that the recommendation or automatic administration of the hypoglycemic drug therapy is based on patient input of one or more patient-related events and/or conditions rather than meal-related information, or based on patient input of one or more patient-related events and/or conditions in addition to meal-related information. Other examples include, but are not limited to, patient input that characterizes or otherwise confirms patient movement information, patient condition information, the presence of patient-related pressure information, and the like.

In one or more exemplary embodiments, the therapy system 10 of fig. 1 may be or be part of a conventional fully closed-loop, semi-closed-loop, or open-loop diabetes control arrangement. In this embodiment, the system 10 provides feed forward information of some amount of patient input from which the system 10 can determine treatment information in the form of insulin bolus dispensing information and/or other treatment information. Such insulin bolus dispensing information may include, for example, insulin bolus quantity or amount, bolus type (e.g., normal or rapid acting, e.g., regular, insulin lispro (lispro), etc.), dispensing time of insulin bolus, time or interval (e.g., single dispense, multiple discrete dispenses, continuous dispenses, etc.), and so forth. Examples of patient-provided feed-forward information may include, but are not limited to, one or more of patient blood glucose concentration, information related to meals, snack forms or other forms of carbohydrates ingested, being ingested, or ingested at some future time, patient motion information, patient stress information, patient condition information, information related to the patient's menstrual cycle, and the like. In any case, the system 10 may include a conventional drug delivery mechanism for dispensing a quantity of a drug; for example, insulin, glucagon, incretin, and the like, are administered at one or more time instances. Alternatively or additionally, system 10 may be configured to provide treatment recommendations to the user via display 20 that may alternatively be implemented, such as ingesting carbohydrates, exercising, consulting a physician, adjusting and/or taking additional or different medication (time and/or amount), and so forth. Embodiments of the system 10 that are or form a part of a conventional fully closed-loop, semi closed-loop, or open-loop diabetes control arrangement may be provided in any of a variety of conventional configurations. However, it should be appreciated that the following examples are for illustrative purposes only and should not be considered limiting in any way. One of ordinary skill in the art will recognize that other possible implementations of a fully closed-loop, semi-closed-loop, or open-loop diabetes control arrangement, or any other implementation, are contemplated by this disclosure.

In a first particular example implementation of system 10 in the form of a diabetes control system, electronic device 12 is provided in the form of a conventional insulin pump configured to be used with a patientIs worn external to the body of the user and is further configured to controllably deliver insulin to the body of the patient. In this example, a plurality of medical devices 26₁-26_NOne or more implantable sensors configured to provide information related to a physiological condition of a patient may be included. Examples of such implantable sensors include, but are not limited to, glucose sensors, body temperature sensors, blood pressure sensors, heart rate sensors, one or more vital signs configured to capture one or more physiological states of the body, such as HBA 1C, and the like. In implementations including an implantable glucose sensor, the system 10 may be a fully closed loop system operable in a conventional manner to automatically monitor blood glucose and deliver insulin as appropriate to maintain blood glucose at a desired level. A plurality of medical devices 26₁-26_NAlternatively or additionally include one or more sensors or sensing systems external to the user's body and/or sensor technology for providing information relating to the physiological condition of the user. Alternatively or additionally, electronic device 12 may include an on-board glucose meter in the form of a conventional glucose reader 27, for example, as illustrated by the dashed lines in FIG. 1. In any case, examples of such sensors or sensing systems include, but are not limited to, glucose strip sensors/meters, body temperature sensors, blood pressure sensors, heart rate sensors, one or more vital signs configured to capture one or more physiological states of a body, such as HBA 1C, and the like. In implementations including an external glucose sensor, the system 10 may be a closed-loop, semi-closed-loop, or open-loop system operable in a conventional manner to deliver insulin as appropriate based on the glucose information provided thereto by the patient. Information provided by any such sensors and/or sensor technologies may be communicated to system 10 using any one or more conventional wired or wireless communication technologies. In this example implementation, a remote device 30 in the form of a handheld or portable electronic device may also be included that is configured to communicate information to electronic device 12 and/or to communicate information from electronic device 12. Additionally and/or in other embodiments, information is used to provide dosage, timing, and other information for a particular use case. At one isIn an embodiment, such use case information is captured, determined, AND provided, such as, FOR example, by another SYSTEM disclosed in commonly assigned AND pending PCT application having attorney docket number ROP0013PA/37554.19/WP23354, entitled "MEDICAL DIAGNOSIS, THERAPY, AND PROGNOSIS SYSTEM FOR INVOLVING THE THEREOF," serial No. ______, the disclosure of which is incorporated herein by reference in its entirety.

In a second particular example implementation of the system 10 in the form of a diabetes control system, 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, a plurality of medical devices 26₁-26_NIncluding at least one conventional implantable or externally worn drug pump. In one embodiment of this example, the insulin pump is configured to controllably deliver insulin to the body of the user. In this embodiment, the insulin pump is configured to wirelessly transmit information related to insulin delivery to the handheld device 12. The handheld device 12 is configured to monitor the insulin pump delivered by the pump and is further configured to determine and recommend insulin bolus amounts, carbohydrate intake, exercise, and the like. The system 10 is configured in this embodiment with or without wireless information transfer from the handheld device 12 to the insulin pump. In this embodiment, electronic device 12 may or may not include an on-board glucose meter in the form of a conventional glucose reader 27, for example, as illustrated by the dashed lines in FIG. 1.

In an alternative embodiment of this example, the handheld device 12 is configured to control the delivery of insulin to the user by determining an insulin delivery command and communicating the command to the insulin pump. In turn, the insulin pump is configured to receive insulin delivery commands from the handheld device 12 and deliver insulin to the user in accordance with the commands. 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 is typically configured in this embodiment to transmit wireless information from the insulin pump back to the handheld device 12 to thereby monitor pump operation. In this exemplary embodiment, system 10 may further include one or more implantable and/or external sensors of the type described in the previous examples. In this example implementation, a remote device 30, for example in the form of a PC, PDA, laptop, or notebook computer, configured to communicate information to electronic device 12 and/or to communicate information from electronic device 12 may also be included.

One of ordinary skill in the art may recognize other possibilities for implementing a fully closed-loop, semi closed-loop, or open-loop diabetes control arrangement using at least some of the components of the system 10 illustrated in FIG. 1. For example, electronic device 12 may be configured to communicate with one or more medical devices 26 in one or more of the above examples₁-26_NProvided in the form of a communicating PDA, laptop, notebook, or personal computer, at least one of which is an insulin delivery system to monitor and/or control the delivery of insulin to the user. As another example, remote device 30 may be configured to communicate with electronic device 12 and/or one or more medical devices 26₁-26_NCommunicate to control and/or monitor the delivery of insulin to the patient and/or communicate one or more software programs and/or data to the electronic device 12. The remote device 30 may be located in a caregiver's office or other remote location and communication between the remote device and any components of the system 10 is accomplished via an intranet, the internet (e.g., world wide web), a cellular telephone, a telephone modem, RF, or other communication link. Any one or more conventional internet protocols may be used in such communication. Alternatively or additionally, any conventional mobile content distribution system, such as Wi-Fi, WiMAX, Short Message System (SMS), or other conventional information schemes, may be used to provide communication between devices that include system 10. In any event, any other implementation is contemplated by this disclosure. Alternatively or additionally, the drug delivery mechanism may be employed in a conventional implantable or externally wearable drug infusion mechanism, a conventional drug injection mechanism such as a drug injection pen or hypodermic needle, a conventional inhalation mechanism for administering one or more drugs in inhalable form, or the likeOne or more of (a).

The treatment system of fig. 1 is generally operable to determine and recommend and/or administer an appropriate amount of one or more drugs and time in such a form of treatment and or to determine and recommend an alternative therapy or action. In determining any such treatment, the system 10 requires at least some information regarding one or more external influences to which the patient is subjected and/or one or more physiological mechanisms associated with the patient. The one or more external influences may be characterized by an action that is typically voluntarily performed by the patient and may be referred to as one or more "patient events". In the context of a diabetes control system, examples of such patient events include, but are not limited to, ingestion of carbohydrates, performance of physical exercise, and the like. In contrast, one or more physiological mechanisms may be characterized by an involuntary physical state or reaction typically associated with the physiology and/or environment of a patient, and may be referred to herein in the context of a diabetes control system as one or more "patient conditions" or metabolic states, examples of which include, but are not limited to, disease, stress, menstruation, etc. In any event, if the patient is experiencing, or has recently experienced one or more patient events and/or conditions, the system 10 generally requires some information regarding at least one of the patient events or conditions to determine the appropriate treatment. In the context of a blood glucose control system, example treatments may include, but are not limited to, advising or administering some quantity, type, and/or frequency of a hypoglycemic drug such as insulin, advising to ingest carbohydrates, advising one or more exercises, advising to consult and/or visit a doctor, and so forth.

System 10 illustratively includes a graphical interface configured to provide patient (sometimes referred to herein as "user") input in the form of at least one patient event or condition that results in the recommendation and/or administration of one or more medications or other treatments. The graphical interface is illustratively displayed on the display unit 20 of the electronic device 12, and may alternatively or additionally be displayed on the display unit 38 of the remote device 30. Processor 14 is configured to control display unit 20 to display a graphical interface on electronic device 12 in a conventional manner. Alternatively or additionally, processor 32 is configured to control display unit 38 to display a graphical interface on remote device 30 in a conventional manner. User input is provided to the graphical interface in any one or more conventional forms. Examples include, but are not limited to, one or more buttons or keys provided on input devices 18 and/or 36 of respective devices 12 and/or 30, a touch-sensitive screen of display units 20 and/or 38, one or more conventional click mechanisms, and so forth.

Referring to FIG. 2, a flow diagram of one illustrative process 50 for developing a patient interface for use by the system 10 of FIG. 1 to enable a patient to input patient-related information from which therapy information may be determined is shown. It is contemplated that treatment 50 is typically performed by a physician or other health care professional, although the disclosure contemplates that treatment 50 may alternatively be performed by other parties, an example of which is, but is not limited to, a company or other entity specializing in or caring for or treating a disease. It is also contemplated that at least some of process 50 may be performed with the aid of at least one computer, and that process 50 may be performed with the aid of a plurality of different computers, at least some of which may access one or more databases. Examples of such computers include, but are not limited to, electronic device 12, electronic device 30, a conventional networked or non-networked personal laptop or notebook computer, a conventional mainframe computer, etc., which may or may not have access to one or more remote databases via the internet, an intranet, or similar connection. It is further contemplated that the process 50 is performed on a patient-by-patient basis so that the final graphical interface is patient-specific.

The process 50 begins at step 52 where a patient model adapted to model a patient's physiological response to at least one patient event or condition upon which a graphical interface is based is identified at step 52. In one embodiment, the PATIENT model is determined using the SYSTEM described in commonly assigned AND pending PCT application No. ______, entitled "SYSTEM FOR DEGENERATING PATIENT-SPECIFIC THERAPIES BASED ON DYNAMIC MODELING GOF PATIENT PHYSIOLOGY AND METHOD THEREOF," having attorney docket number ROP0012PB/WP23849US AND the disclosure of which is fully incorporated by reference. In the illustrated embodiment, step 52 focuses on determining the structure and patient physiological parameters from a given set of patient-specific data, and is performed by introducing a therapy-specific solution-dependent modeling principle, such as drug administration and/or other therapy solutions. The method can be simplified by considering only dynamic patient events or conditions that would affect a limited set of the models.

Referring to FIG. 3, a patient modeling framework is described in the context of an exemplary diabetes control arrangement that identifies the patient model as a traditional glucose regulation model 70. The glucose regulation model 70 is generally intended to simulate the human body's blood glucose response to a blood glucose influencing event or situation, and the general glucose regulation model 70 is made patient specific by making the model 70 with information corresponding to patient specific physiology as shown in FIG. 3 by the dashed line blocks within the perimeter of the model 70. The glucose regulation model 70 may be simplified by considering only a limited number of dynamic patient events or conditions that may affect the state of the model 70, and an example of such dynamic patient events or conditions is illustrated in FIG. 3. These include, but are not limited to, ingestion of meals 72, snacks, etc. (e.g., ingestion of carbohydrates), exercise 74, patient stress 76, administration of one or more hypoglycemic drugs 75, a patient's disease 78, and one or more other patient events or conditions 80. In the simplest case, the glucose regulation model 70 is configured to consider only one of the dynamic patient events or situations, such as meal 72, as input information, and the model complexity increases when additional dynamic patient events or situations are considered.

In general, step 52 captures the structure of the model, i.e., the dynamics or principles of model operation, and identifies model parameters that are specific to the individual patient and/or that define at least one specific patient event or condition. As part of step 52In turn, patient-specific data from which such structures and parameters of the patient model are determined and defined is collected. In this way, the patient model is adapted to the physiology of the individual patient. Additional resources exist at step 52 for identifying and/or supplementing the identification of the patient model. Examples of such additional resources may include, but are not limited to, published literature, published clinical trial results, experience taken from determining patient models for other patients, and the like. One or more computer accessible databases containing patient model structures and containing relevant links to published documents are available. Exemplary clinical trials from which patient model structures can be determined include, but are not limited to, follow-up studies and the like. In one exemplary embodiment, legacy software, for example, such asSAAMSuch third party software, or some other commercially available software for determining patient model structures and parameters that is used for parameter identification and that additionally provides the underlying structure of the patient model, provides the model parameters and their initial values, and if a bayesian approach is followed provides a so-called "prior", establishes a cost function, selects an appropriate solver, and solves for parameter estimates.

From step 52, the process 50 proceeds to step 54, where the ability of the patient model identified in step 52 to simulate the patient's physiological response to at least one patient event or condition is verified in step 54. Illustratively, this step is accomplished by one or more computer-based simulations, also referred to as specialized test scripts. Illustratively, step 54 may implement one or more of the following: 1) verifying the model at one or more specific operating ranges; 2) understanding the operating space and constraints of the model; 3) providing an estimate of a wrong base model assumption; and 4) utilizing various models and schedules, such as gain schedules, to make changes to the model and/or the patient dynamics over the space of accurately described expected glucose regulation states. In any case, once the patient model is identified and the model parameters are determined/adjusted, step 54 typically includes utilizing the patient model to simulate the problem, analyzing the different operating scripts, and examining the dynamics thereof.

Referring now to fig. 4-6, an exemplary patient model 90 is constructed using a plurality of atrioventricular model blocks 85 that simulate the dispensing of drugs through various organs and regions of the human body. One can construct such a model according to the following references: "applied biopharmaceutics & Pharmacokinetics", Leon shamgel and Andrew b.c.yu; "Pharmacokinetics, Principles and Applications", MehdiBoroujerdi; "A physiologic model of glucose metabolism to design and asset improved insulin therapeutics for diabetes", John Thomas Sorensen, PhD, MIT 1985; "Textbook of word physics, physical bases of exception", Per-OlofAstrand Kaare Rodahl, Hans A. Dahl and Sigmund B. Stromme; "aromatic Endocrine Pancreas", Motoaki Shichiri; "The minimolodela ppoach and determinants of glucose tolerance", Richardbergman and Jennifer C.Lovejoy, Penington Center Nutrition series, Vol.7; and "Feedback control in Anaesthesia" Marcopaolo Derighetti, PhD Switzerland Federal institute of science and technology, Zurich. Consistent with the example common throughout this document, the patient model 90 is configured to simulate the effect of meals, such as carbohydrates, on blood glucose levels. In one embodiment, the model 90 is used to define a patient interface that the patient may use to enter information that characterizes patient events in the form of patient-specific meal input information for a meal that the patient is likely to eat, mapping the information to one or more meal pills of insulin or other glucose-lowering medication. In one illustrative embodiment, the term "likely to eat" means that the solution covers about 70% to about 90% of the various meal types, speeds, and size combinations. The remaining percentage of meal type, speed, and size possibilities are treated as special cases. This special case is typically addressed by the patient by using an appropriate level of warning and managed by additional monitoring with acceptable performance indicia in achieving euglycemia (euglycemia) control. One such generally acceptable marker is, for example, HbA 1C with a typical target value of 6% or less, although this numerical example should not be considered limiting in any way.

In this example, the general mathematical description of the patient model is based on equations (1) and (2) as follows:

Z(t)＝f_z(Z(t)，U(t)，t，θ(t)) (1)

and

Y(t)＝f_y(Z(t)，U(t)，t，θ(t)) (2)

where capital letters represent vectors and lower case letters represent scalars. Function f_zAnd f_yRepresenting the system architecture and thereby simulating the characteristic behavior of a diabetic patient. In the model 90, the state vectors z (t) represent the state of the various compartments of the body, such as, for example, the heart and lungs 94, the brain 96, the intestines 98, the liver 100, the kidneys 102, and the distal tip (periphery)104 as illustrated in fig. 5 and 6, and are physiologically or non-physiologically based. Depending on the requirements of the problem, the status represents glucose, insulin, glucagon, FFA, lactate, GLUT, metabolites injected by different modes such as subcutaneous, intravenous, and/or intestinal. The states included or excluded generally depend on the problem to be solved, the relevance of the problem, the effect of the state on the problem, and so forth. Typically, the state varies as a function of inputs(s), u (t), which represent, for example, endogenous insulin production by the pancreas, endogenous glucose production by the liver, exogenous glucose by intravenous injection, subcutaneous insulin injection, and the like. If the state is not a steady stateThen the state also changes. The parameter θ (t) is typically a time-variable parameter. The output vector y (t) typically represents a physically measurable quantity. However, the output equation typically represents the quantity of interest. Model displays can become very complex and the choice of the final model is a trade-off between complexity, identifiability of parameters, relevant levels of detail, and problem requirements.

Although the structure of the patient model is obtained in many different ways, some of which are described above, the atrioventricular block 85 of fig. 4 is used to simulate the distribution of metabolites in various organs and regions of the body. Referring to the atrioventricular block 85 of fig. 4, the metabolite concentrations can be considered as arterial inflow and venous outflow according to the following equation:

V_B＊dC_BO/dt＝Q_B(C_Bi-C_BO)+PA(C_I-C_BO)+r_SOURCE1-r_SINK1 (3)

and

V_I*dC_I/dt＝PA(C_BO-C_I)-r_SINK2+r_SOURCE2 (4)，

wherein V_BCapillary blood volume, V_IAmount of interstitial fluid, Q_BVolumetric blood flow rate, P_APermeability-regio products, C_BiConcentration of arterial blood solute, C_BOCapillary blood (and venous) solute concentration, C_IConcentration of interstitial fluid, r_SINk1，r_SINk2Red blood cell absorption rate of metabolites, r_Source1，r_Source2Rate of tissue cell production of metabolites across cell membranes. Item V_B*dC_BODt and V_I*dC_IDt represents the accumulation, term Q_B(C_Bi-C_BO) And PA (C)_BO-C_I) Denotes convection, term PA (C)_i-C_BO) Represents diffusion, and the term r_Sink1，r_Sink2，r_Source1And r_Source2Representing a metabolic source and a metabolic pool.

Using the basic atrioventricular block structure illustrated in FIG. 4, a model 90 as shown in FIGS. 5 and 6 is constructed to represent the glucose and insulin concentrations in the various compartments of the body. The state of each module represents the dynamics of the model at any given time t with respect to each input. FIG. 5 shows a schematic diagram of a glucose regulation model 90 for defining glucose concentrations in various organs and other regions of the body. FIG. 6 shows a schematic diagram of a glucose regulation model 90 for defining insulin kinetics in various organs and other regions of the body. In each case, the summation node 92 sums the effects of the atrioventricular blocks, such as the bowel 98, liver 100, kidney 102, distal 104, and brain 96, and provides the summed vector values to the heart and lung atrioventricular blocks 94. The various scalars carried by the output vectors of the heart and lung atrioventricular block 94 are assigned as inputs corresponding to respective ones of the blocks of the intestine 98, liver 100, kidney 102, distal 104, and brain 96 as shown. In the insulin kinetics diagram of fig. 6, the delivery of subcutaneously injected insulin represents the vector input to the heart and lung mass 96.

The output vector y (t) of equation (2) above typically includes physiological quantities such as blood glucose concentration and plasma insulin concentration that simulate a physically measurable quantity such as glucose concentration using a subcutaneous glucose measurement device. The output vector y (t) is typically a function of the state vector Z. The input vectors represent external and internal influences such as dosed insulin, ingested meals, exercise, illness, etc. The entire model 90 represents a particular patient with diabetes.

Referring again to FIG. 2, steps 52 and 54 of process 50 represent the development of a patient model configured to simulate a patient's physiological response to at least one patient event or condition. Following step 54, the process 50 proceeds to step 56 where patient-specific information is collected at a time period related to the actual occurrence of at least one patient event or condition in step 56. Typically, the patient utilizes a manual diary, questionnaire, electronic information recording device, or the like to perform step 56 over an extended period of time, such as one week to several months. Using the example generally used in this document, the patient performs step 56 in a diabetes control system in which a graphical interface maps information characterizing the patient's intake of a meal, such as carbohydrates, to one or more corresponding insulin boluses. In this embodiment, the patient's physician or other health care provider typically instructs the patient to take a particular meal and insulin-related information directly or through pre-programmed instructions on an electronic device such as the device 12 of FIG. 1 for a specified period of time, wherein the protocol for collection is specified. Typically, the patient will record or note the time of the meal, the type of meal, the amount of meal (carbohydrate amount), insulin dispensed before and after the meal, blood glucose measurements taken before and after the meal, and the like. A more detailed list of such information, including optional and/or alternative information, is described in commonly assigned and pending u.s. patent application serial No.11/297,733, entitled "SYSTEM AND METHOD FOR detecting and detecting data and information, the disclosure of which is fully incorporated herein by reference.

After step 56, the process 50 proceeds to step 58 where an appropriate graphical interface (by the user, HCP, or by algorithm) is selected at step 58 that maps patient input characterizing at least one patient event or condition verified at step 54 to treatment information. In one embodiment, the therapy information is medication therapy information corresponding to one or more medications administered to the patient. In other embodiments, the treatment information is proposed carbohydrate intake information corresponding to recommendations for ingesting carbohydrates, recommendations for exercising, recommendations for consulting physicians, and other treatments. Typically, the graphical interface takes the form of a two-dimensional space for defining a characteristic of one patient event or condition along one axis and another characteristic of the patient event or condition along another axis. Again using the example common throughout this document, the step 58 is performed by a doctor or other health care provider in a diabetes control system in which a graphical interface maps information characterizing patient intake of a meal, such as carbohydrates, to one or more corresponding insulin boluses. Typically, a person's glucose concentration is altered due to one or more external influences such as meals and exercise, and also due to various physiological mechanisms such as stress, disease, menstrual cycle, and the like. In people with diabetes, such changes require monitoring of the person's blood glucose levels and administration of insulin or other blood glucose altering drugs, such as glucose lowering or raising, because the person's blood glucose must be maintained within a desired range. The system 10 is thus configured in this example to determine the appropriate amount, type, and/or timing of insulin or other blood glucose altering drug to be administered based on some amount of patient specific information in order to maintain normal blood glucose levels without causing hypoglycemia or hyperglycemia.

When a person ingests food in the form of a meal or snack, the person's body reacts by absorbing glucose from the meal or snack over time. Any food ingested will be referred to hereinafter as a "meal" and the term "meal" thus encompasses traditional meals such as breakfast, lunch, dinner, as well as snack foods, drinks and the like. The general shape of any person's intestinal glucose uptake profile (profile) rises after ingestion of a meal, peaks at some measurable time after the meal, and falls thereafter. The speed of any one intestinal glucose absorption profile, i.e., the rate from start to finish, varies from person to person due to meal composition (e.g., fat, protein, fiber, carbohydrate type, etc.), meal type (e.g., breakfast, lunch, dinner, or snack), or time, and/or according to one or more other factors, and also varies from day to day under otherwise identical meal conditions. Generally, feed forward information relating to such meal intake information provided by the patient to the system 10 explicitly or indirectly includes 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 patient's overall rate of glucose absorption from the meal.

The patient may provide an estimate of the size or amount of an event or condition that the patient is about to experience, is experiencing, or has recently experienced in any of a variety of forms. For example, but not limited to, the patient may provide an estimate of the amount of carbohydrate that the patient is about to ingest, is ingesting, or has recently ingested as a direct estimate of carbohydrate weight (e.g., in grams or other convenient measure), an estimate of the amount of carbohydrate relative to a reference amount (e.g., dimensionless), an estimate of meal or snack size relative to a reference meal or snack size (e.g., dimensionless). Other forms of patient input of the carbohydrate content of a meal or snack will be readily envisioned by those of ordinary skill in the art, and any such other forms are contemplated by this disclosure.

Likewise, the patient may provide an estimate of the speed of an event or condition that the patient is about to experience, is experiencing, or has recently experienced in any of a variety of forms. For example, but not limited to, for a specified value of the desired rate of overall glucose absorption for a meal, the glucose absorption map captures the rate of the patient's meal. As another example, the rate of overall glucose absorption from a meal by a patient also includes the duration between ingestion of the meal by a person and the peak glucose absorption of the meal by a person, which captures the duration of the patient's meal. The rate of overall glucose absorption is therefore expressed in terms of meal speed or duration. Examples of desired rates of overall glucose absorption parameters in this case include, but are not limited to, composite parameters corresponding to estimates of meal speed or duration (e.g., units of time), composite parameters corresponding to meal speed or duration relative to a reference meal speed or duration (e.g., dimensionless), and so forth.

As another example of providing an estimate of the expected speed of the overall glucose absorption parameter, the shape and duration of the glucose absorption map is mapped to the composition of the meal. Examples of desired rates of overall glucose absorption parameters in this case include, but are not limited to, estimates of fat, protein, and carbohydrate amounts (e.g., in grams) in conjunction with carbohydrate content estimates in the form of meal size or relative meal size, estimates of fat, protein, and carbohydrate amounts relative to reference fat, protein, and carbohydrate amounts in conjunction with carbohydrate content estimates in the form of meal size or relative meal size, and estimates of an overall glycemic index (e.g., dimensionless) for a meal or snack, where the term "overall glycemic index" is defined for this document as a parameter that ranks meals and snacks by the rate at which the meal or snack causes a patient's blood glucose to rise. Thus, for example, a meal or snack with a low glycemic index causes a gradual rise in blood glucose, whereas a meal or snack with a high glycemic index causes a rapid rise in blood glucose. One exemplary measure of the overall glycemic index is, but is not limited to, the ratio of carbohydrates absorbed from a meal over a specified period of time, e.g., 2 hours, to a reference value, e.g., from pure sugar or white bread. In general, other forms of providing a user input of a desired overall rate of glucose absorption by a patient from a meal and/or providing a user input of a desired shape and duration of a glucose absorption profile will occur to those of ordinary skill in the art, and any such other forms are contemplated by this disclosure.

The graphical interface in this example illustratively has a first parameter portion and a second parameter portion. In one embodiment of instructing the patient to enter meal-related information, the patient-entered first parameter portion of the meal-related information illustratively corresponds to the amount of carbohydrate or meal content that the patient will immediately ingest, is ingesting, or has recently ingested, and the second parameter portion illustratively corresponds to the desired rate of overall glucose absorption from the meal by the patient. Referring to fig. 7, an exemplary embodiment of such a graphical interface 110 selectable for providing patient input of meal intake information is shown. In the illustrated embodiment, the graphical interface 110 is a grid-type user interface having one grid axis in the form of a meal size defined by carbohydrate content and another grid axis in the form of a meal duration defined by the desired rate of overall glucose absorption by the patient from the meal. The meal size grid axis defines three different meal sizes or magnitudes in the form of "small", "medium", and "large" indicators and the meal duration grid axis likewise defines three different meal duration values in the form of "slow", "medium", and "fast" indicators. The grid-type graphical user interface 110 provides a single user selection of the desired speed of carbohydrate content and overall glucose absorption information related to meals that the patient is about to ingest, is ingesting, and has recently ingested. As used herein, the phrase "single user selection" is defined as a single selection made by a user. It should be clear that the systems and methods described herein are not limited to a single user, but rather that the systems and methods described in this document may be implemented on one or more user platforms. In any case, in the illustrated example, the user selects 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 be or has been ingested for a medium meal duration. In general, the terms "large," "medium," and "small" in this context encompass any conventional measure of meal size, including, for example, but not limited to meal size or quantity, in any specified weight, volume, or the like.

Referring to fig. 8, another exemplary embodiment of a graphical interface 112 selectable for providing user input of meal intake information is shown. In the illustrated embodiment, the grid 112 of the graphical interface is a grid-type user interface having one grid axis in the form of a meal size relative to a reference meal size defined by carbohydrate content and another grid axis in the form of a meal duration relative to a reference meal duration defined by a desired rate of overall glucose absorption by the patient from the meal. The meal size grid axis defines three different meal size values in the form of "less than normal", "normal", and "greater than normal" indicators, and the meal duration grid axis likewise defines three different meal duration values in the form of "less than normal", "normal", and "greater than normal" indicators. The grid-type graphical user interface 112 provides a single user selection of the desired speed of carbohydrate content and overall glucose absorption information related to meals that the patient is about to ingest, is ingesting, and has recently ingested. In an illustrative 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 the same as the normal meal duration. In general, the terms "greater than" and "less than" in this context encompass the use of any conventional measure of meal size, including, for example, but not limited to, meal size or quantity, relative to a specified "normal" meal size, in any specified weight, volume, etc.

Referring to fig. 9, yet another exemplary embodiment of a selectable patient-entered graphical interface 114 for providing meal intake information is shown. In the illustrated embodiment, the graphical interface 114 is a grid-type user interface having one grid axis in the form of meal size defined by carbohydrate content and another grid axis in the form of fat amount, protein amount, and carbohydrate amount of the meal defined by the desired rate of overall glucose absorption. The graphical interface 114 thus requires three separate selections for input by the patient, as compared to the single input associated with the embodiment illustrated and described with reference to fig. 7 and 8. As briefly described above, the fat amount, protein amount, and carbohydrate amount are mapped to a desired rate of overall glucose absorption from a meal by the patient. The meal size grid axis is defined as three different meal size values in the form of "small", "medium", and "large" indicators. The grid-type graphical interface 114 provides the user with a selection of the desired speed of carbohydrate content and overall glucose absorption information relating to meals that the patient is about to ingest, is ingesting, and has recently ingested. In an illustrative 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 of a high fat, moderate protein, and high carbohydrate content. In general, the terms "greater than," "equal to," and "less than" in this context encompass any conventional measure of the size of a meal, including for example, but not limited to, meal size or quantity, in any specified weight, volume, etc.

In general, any desired functional relationship is used to map the three meal components to corresponding meal speed or meal duration values. One exemplary functional relationship may be, but is not limited to, assigning equal weights to the three meal component parts, calculating percentages of the three user-specified meal component values, assigning equally spaced thresholds, such as 33% and 66%, to the two interfaces between the three meal size values, and thereafter comparing the percentages of the three meal component values to the threshold percentage values to determine the meal speed. With the example illustrated in fig. 9, small, medium, and large portions are assigned values of 1, 2, and 3, respectively. The percentage of fat is thus 3/8 or 37.5%, the percentage of protein 2/8 or 25%, and the percentage of carbohydrate 3/8 or 37.5%. The percentages of fat and carbohydrate are thus both moderate, while the percentage of protein is small, which results in a moderate to slower mixed meal speed.

Referring to fig. 10, yet another exemplary embodiment of a selectable patient-entered graphical interface 116 for providing meal intake information is shown. In the illustrated embodiment, the graphical interface 116 is a grid-type user interface having one grid axis in the form of a meal size defined by carbohydrate content relative to a reference meal size and another grid axis in the form of fat amount, protein amount, and carbohydrate amount defined by the desired rate of overall glucose absorption by the patient from the meal. Like graphical interface 114, graphical interface 116 thus requires three separate selections for input by the patient, as compared to the single input associated with the embodiment illustrated and described with reference to fig. 7 and 8. The user-specified amounts of fat, protein, and carbohydrate are mapped to corresponding meal speed or meal duration values using any desired functional relationship therebetween as just described. The meal size grid axes define three different meal size values in the form of "less than normal", "normal", and "greater than normal" indicators. The grid-type graphical user interface 116 provides for user selection of the desired rate of carbohydrate content and glucose absorption information associated with meals that the patient is about to ingest, is ingesting, and has recently ingested. In the illustrated example, the user has selected meal-related inputs 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 "greater than" and "less than" in this context encompass the use of any conventional measure of meal size, including, for example, but not limited to, meal size or quantity, relative to a specified "normal" meal size, in any specified weight, volume, etc.

Referring to fig. 11, yet another exemplary embodiment of a graphical interface 118 selectable for providing user input of meal intake information is shown. In the illustrated embodiment, the graphical interface 118 defines a continuous function of the carbohydrate content provided in terms of carbohydrate content by weight (in grams or other convenient weight) and the desired rate of overall glucose absorption from the meal by the patient provided in terms of the overall glycemic index (dimensionless). Alternatively, the graphical interface 118 can define a numerical display that is a discrete function of the carbohydrate content provided in the form of carbohydrate content and the desired rate of glucose absorption provided in the form of a total glycemic index. In either case, the carbohydrate content and/or the total glycemic index parameter may be alternatively represented in the graphical user interface 60 in the form of the terms "large," "medium," and "small" described above or in the form of the terms "greater than normal," "normal," and "less than normal" described above. Any dotted, dashed, solid, or other type of grid line may alternatively or additionally be superimposed on the graphical user interface 58 to distinguish between carbohydrate content and total glycemic index values on the interface 118. In any case, the graphical interface 118 provides a single user selection of the desired speed of carbohydrate content and glucose absorption information related to meals that the patient is about to ingest, is ingesting, and has recently ingested. In the illustrated example, the user has selected meal related inputs 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. 12, yet another exemplary embodiment of a selectable patient-entered graphical interface 120 for providing meal intake information is shown. In the illustrated embodiment, the graphical interface 120 defines a continuous function of the carbohydrate content provided in the form of the meal size and the expected rate of overall glucose absorption from the meal by the patient provided in the form of the 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 likewise defines three different meal duration values in the form of "slow", "medium", and "fast" indicators. The continuous graphical interface 120 provides a single user selection of the desired speed of carbohydrate content and overall glucose absorption information relating to meals that the patient is about to ingest, is ingesting, and has recently ingested. Any dotted, dashed, solid, or other type of grid line may alternatively or additionally be superimposed on the graphical user interface 120 to distinguish between meal size and meal duration values on the interface 120. In the illustrated example, the user has selected a meal related input indicating that the patient is about to ingest, is ingesting, or has recently ingested a meal that is between medium and large and is ingested for a meal duration between slow and medium.

Further details and examples of graphical interfaces are illustrated and described in commonly assigned and pending U.S. patent application serial No.11/297,733, the disclosure of which is fully incorporated herein by reference.

Referring again to FIG. 2, process 50 advances from step 58 to step 60 where in step 60 the solution space for the graphical interface selected in step 58 is defined based on the resulting patient models from steps 52 and 54 and also based on the patient specific information collected in accordance with step 56. The solution space defines the relationship between the inputs and their associated acceptable limits to adjust the patient's physiological response to the desired target response. Again using the example generally used in the general documentation, the physician or other health care provider may perform step 60 in a diabetes control system in which a graphical interface maps information characterizing patient intake of a meal, such as carbohydrates, to one or more corresponding insulin boluses. In this particular example, the graphical interface is a grid-type interface, such as graphical interface 110 of FIG. 7, defined by two input parameters, meal size and meal speed. However, it should be apparent that any of the graphical interface embodiments illustrated and described herein or other similar graphical interfaces may alternatively be used. In one illustrative embodiment, the solution space for the graphical interface 110 is generally determined in a manner that defines not only the "grid" location, i.e., the division between the different meal sizes and meal speed (duration) inputs, but also the outer boundaries of the graphical interface 110. In any case, it is desirable to define a solution space for the graphical interface 110 to provide for the adjustment of the patient's glucose relative to the target glucose level for a given meal disturbance.

As shown in fig. 7, the meal space is divided into continuous rectangular subspaces. These subspaces represent the range of meal characteristics that can each be iteratively adjusted (accommoded) by ordinary insulin therapy. By defining a solution space for the graphical interface, a subspace of meal information is identified for which fixed meal compensation within the subspace of meal information is acceptable. Further for illustrative purposes, consider the issue of glycemic control with regulation of a physiologically variable glucose concentration g (t), one output sheet in vector Y (t)The element is g (t). Illustratively, the solution space of the graphical interface is thus determined by solving a cost function set as a constraint minimization problem. Such a cost function solves the constraint minimization problem using, for example, the following information: 1) glucose regulation pattern response due to meal challenge; 2) meal stimulation input parameter, eta, of meal size^AAnd meal speed (duration) η^S(ii) a 3) Target blood sugar value g_target(ii) a 4) Output vector y (t), state vector z (t), and input vector u (t) (from equations (1) and (2) above); 5) a weight parameter; and 6) limits on glucose values (e.g., maximum and minimum glucose values) and insulin dosing.

Equation (5) below shows one example of a cost function:

wherein h is a scalar function, and h₀And h_fAre the initial and final cost parameters. This cost function is solved by minimizing J and further requires that the following constraints are satisfied: 1) g is more than or equal to g_min；2)g＜g_max；3)And 4)Wherein "g" is the glucose concentration, g_minIs the lower glycemic limit of euglycemia, g_maxIs the upper glucose limit for euglycemia,is the maximum rate of increase of glucose concentration andis the minimum rate of decrease in glucose concentration. Furthermore, the above constraints are a function of time and the state vector. The meal space is defined by eta subject to^AAnd η^SDefined as follows: 1) eta^A≥η₁ ^A，2)η^A≤η₂ ^A，3)η^S≥η₁ ^SAnd 4) η^S≤η₂ ^SWherein eta^Aε[η₁ ^A，η₂ ^A]And η^Sε[η₁ ^S，η₂ ^S]Are the ranges of parameters where the size (amount) of the meal and the speed (duration) of the meal are expected to vary, respectively. It should be noted that for illustrative purposes is assumed by η^AAnd η^STo characterize intestinal glucose absorption.

The grid size of the graphical interface 110 in fig. 7 is determined using a predictive algorithm that illustratively uses a predictive patient model to future values or states to determine the best or "best" control action until the next computational iteration. The nonlinear model predictive controller is one possible candidate for solving the cost function constraints described above. The nonlinear model controller approach requires explicit controlModels are used to predict future behavior. The method utilizes past input information and determines a control action based on a cost (objective function). The selected method also takes into account future control actions to provide an overall optimal solution. The method is flexible and generalizes to future extensions, such as considering additional inputs or interference without any special handling. Several references covering this topic are: "Stabilizing state feedback design via the movinghorizon method", Kwon, Bruckstein and Kailath, International journal of control, 37, 1983, pages 631-; "Model predictive control: the theoryad practice ", Garcia, Prett and Morari, Automatica, 25, 1989, p.335-348; and "Nonlinear model predictive control of glucose concentration in subjects with type 1 diabetes", RomanHovorka, Valentina Canonico, Ludovic J Chassin, Ulrich Haueter, Massimo Massi-Benedti, Marco Orsini Fedehci, Thomas R Pieber, Helga C Schaller, Lukas Schaupp, Thomas Vering and MalgorzataWilinska, Physiol.Meas.25905-920 in 2004. As described by Romon Hovorka et al, the prediction algorithm using bayesian parameter estimation also compensates for the model prediction method by performing parameter identification using online model adaptation capability. The non-linear prediction algorithm can also be implemented as an open-loop implementation proposed here, typically without loss, with a given meal type (η) for a given set of initial conditions, parameter values, and weight^A，η^S) A meal compensation pill value is determined. A single point solution is thus obtained when building the predictive controller and solving. Further, the solution is not specific to using model prediction methods, but illustrates the intent of the solution. The intent is to determine a single optimal treatment from potentially many allowable solutions.

In this example by η corresponding to the size or amount of the meal^AAnd eta corresponding to meal speed or duration^STo define the total meal space. The parameter η is defined by the patient in accordance with the actual meal related information collected at step 56 of the process 50^AAnd η^SThe range of (1). To define a meal in terms of a graphical interfaceFood space therapeutic solution, eta^AAnd η^SThe range is used to specify the outer circumference or boundary of the graphical interface. This is illustrated graphically in the example of FIG. 13, with FIG. 13 illustrating the dependence on η^AAnd η^SForms the outer circumference 130 of the graphical interface 110. In the illustrated example, the parameter η^AAnd η^SAre divided into small step sizes delta eta^AAnd Δ η^S. The division of the step size depends on the sensitivity of the solution to the step size. For example, for insulin sensitive patients, a small step size is required. It is typically sufficient to divide the entire range into 10 to 15 equidistant segments. However more or less may be required depending on the requirements of the problem. The prediction algorithm is thereafter solved to solve by using a small discrete step size Δ η as illustrated in fig. 13^AAnd Δ η^S"walks" around the circumference 130 covering the meal space. Another possibility for mapping the meal space is to divide the operating range into a grid and thereafter solve the problem as described below on each intersecting grid point. Yet another possibility may include, for example, defining one or more simplified analytical functions containing the treatment solution, and thereafter utilizing the equivalent function as a solution space for determining the treatment solution for each grid (see, e.g., fig. 7-12). More specifically, the constraint minimization problem represented by the above equation (5) is solved twice at each step. To solve for meal compensation bolus quantity, the prediction algorithm uses the following information: 1) eta^AAnd η^S2) cost function (equation (5)); 3) setting all states of the patient model to steady state and insulin delivery to an appropriate basal rate; 4) suppose at time t^M ₀When the meal or snack is eaten, the meal-related pill is defined as I^M _-k1，I^M _-k0，I^M _k1，I^M _k2,., wherein I^M _kiRepresenting meal pills at various times (ki min) relative to the meal time (k0 ═ 0 min). The terms-k 1, -k2, etc. denote times such as minutes relative to ingestion of a meal at time 0. Typically, a series of limited meal insulin pills may be defined. In addition to this, the present invention is,defining pills as multiple fractions of a single meal insulin pill, e.g. 4 pills I considering I^M _-1510%, I of^M ₀70% of I^M ₁₅10% and I of I^M ₆₀10%. However, for illustrative purposes, the simplest case is considered here, e.g. the dispensing of a single meal pill at the time of a meal, i.e. I only^M ₀。

As illustrated in fig. 13, the graphical interface periphery 130 is spanned by overlaying various meal features. For each selected meal characteristic, the predictive algorithm is solved to determine meal-related insulin compensation. The predictive algorithm is set as a constraint minimization problem in which for a given set of weight functions, the relevant constraints are controlled, the system equations with given past, present, and future input excitations (e.g., meal intake, glucose metrics, injected insulin), constraints on the output (e.g., insulin infusion is non-negative, glucose concentration must achieve target glucose or within upper and lower margins, etc.), and constraints on the input (e.g., maximum insulin bolus), equation (5) is written as

Limiting meal-related pills to simple meal pills I in connection with input constraints^M ₀So that the input vector U corresponding to meal insulin is given as U ═ 0I^M ₀ 0 0 ... 0]. Details of various Model Predictive Control (MPC) embodiments are provided in the references listed above.

The allowed solution space is captured by solving two independent minimization problems at each meal feature point illustrated in fig. 13: 1) a minimum value of maximum insulin administration that violates a lower glucose limit; and 2) a maximum value of minimum insulin administration that violates the upper glucose limit. For the first minimization problem, the cost function is established with a small weighting of the control function, which results in little adverse consequences for the control action. This mandates that the lower glucose limit (I) is not violated^M ₀)_maximunFreely use insulin to determine a solution set for the control action. From all the allowable solution sets, the cost function determines the maximum insulin delivery without violating the lower glucose constraint. For the second minimization problem, the cost function is built with a large weighting of the control function, which can lead to large adverse consequences for the control action. This enforces that the upper glucose limit (I) is not violated^M ₀)_minimumThe solution set for the control action is determined using the insulin minimally. The solution set is thus (I)^M ₀)_maximunMinimum sum (I)^M ₀)_minimumAll solutions in between that satisfy the constraints and provide a meal intake η for a given set of parameters and conditions^AAnd η^SAnd (4) controlling blood sugar.

As the predictive algorithm progresses from point to point along the circumference of the graphical interface 110 130 as illustrated in fig. 13, the solution for each point is recorded. An example of one technique for recording such a solution is illustrated in FIG. 14, which FIG. 14 is a mealPill amount to total meal space eta^A/SAnd illustrates knowledge of spatial extrema. It should be appreciated that FIG. 14 may also be represented as a three-dimensional graph in which η is shown^AAnd η^SSeparation, since this point should be cleared in FIG. 14, η^A/SThe representation shows two axes of overlap of the final shared space of interest. Alternatively, from a computational aspect, the solution is retained in memory for further analysis and determination of the grid. For each point along the circumference 130 of the graphical interface 110, a solution is found by systematically changing one parameter at a time. Eta^AAnd η^SIs typically a particular problem. If a knowledge is found, the solution space is saved and the iterative process goes to the next point. If no solution is found, the circumferential point is culled, the iterative process returns to the previous point, and the iterative process continues in a direction perpendicular to the previous direction of movement as illustrated in FIG. 13. In this way, the total meal space η is systematically spanned^A/SAnd determining the meal space eta^A/SOf the solution space. For example, if the above method is represented by a 3D map, the solution space is limited by the upper and lower surfaces, where the solution point forming surfaces are connected by straight lines.

The division of the meal space into grid-like subspaces, such as illustrated in fig. 11, is determined by further analysis of the solution space. The goal is to find a simple contiguous region of solution space. Referring again to FIG. 14, for example, the oval shaped area 136 corresponds to a solution range for a particular point in the meal space, and the solid band 138 corresponds to a common solution subspace that covers the range of the meal space. In one embodiment, the solution space for acceptable treatment is generally a three-dimensional space, where η^AAnd η^SAre the x and y axes and I^M ₀In the vertical z-axis. A similar grid subspace is produced by, for example, the schema (schema), wherein the band 138 not only continuously covers the meal space, but wherein additional constraints are added as needed or as required in view of the desired or required treatment. One of ordinary skill in the art will recognize that more sophisticated or improved policies may be used to further define such as to take into accountOne or more strategies for interior points of space 130 are such grid-like subspaces.

More requirements may be imposed on the solution space extrema illustrated in fig. 14. For example, the upper and lower glucose boundaries provide a minimum to manage the sensitivity of individual patients to parameter variations. Alternatively or additionally, the bands 138 are feasible solutions across the entire selected meal subspace. Still alternatively or additionally, the straight plane traverses the entire subspace so that insulin therapy is adapted to eta^AAnd η^SA subspace. Discontinuities are the natural dividing lines of the meal subspace. Alternatively, the subspace is determined systematically over the entire surface by an iterative algorithm that sets a three-dimensional grid of the solution space, sets an iterative loop to span the three-dimensional space, checks for conditions at each grid intersection, and proceeds to the next feasible solution when the solution fails. As another example requirement, it may be desirable to require a single solution from the band 138 in order to generally recommend or administer a minimum amount of insulin. The method minimizes or at least reduces the likelihood of a hypoglycemic condition. Typically, this example only considers one input, namely meal-related information. One of ordinary skill in the art will recognize that the determination of the graphical interface may be extended to alternative or additional inputs, such as disease, motion, stress, etc., using the same principles just described. However, it should be appreciated that each grid cell may be represented by a single point of treatment that effectively covers the entire grid cell by the above-described method.

Previous methods have been described for a patient parameter in a particular state, such as performing a patient solution when he/she is in a "normal" state (also referred to as an alternative state) as opposed to a stress state. The method is applied in the same way to various parameters and physiological states. Further, the patient model is considered a function of time to account for time-based effects such as day, week, month, seasonal effects, and the like. As examples, women's menstrual status, seasonal effects on meal composition, amount of meal consumed as a function of working and non-working days, and the like.

Once the grid-like graphical interface 110 of this example is sufficiently defined to provide a meal compensation pill strategy that meets euglycemic goals, the patient input must be mapped to a solution. Referring to FIG. 15, for example, one of the meal space parameters, i.e., η, is shown^AOr η^SA graph 140 of discrete user inputs. If the η axis represents η^AAnd η^SThen the parameter may be mapped to any number of discrete user inputs. Thus, the parameter is η₁≤η₂≤η₃≤η₄And is horizontal₁ε[η₁，η₂]And a nominal value eta epsilon [ eta ]₁，η₂]. Typically, this mapping is performed for each of the meal space parameters. In the exemplary graphical interface 110 illustrated in FIG. 7, a meal size parameter, η^SMaps to three discrete user inputs SM, MED, and LG, and maps a meal speed (duration) parameter, η^AMapping to three discrete user inputs SLOW, MED, and FAST. In general, any number of discrete user inputs may be defined, although from a practical standpoint it is desirable to have the goal to make the number of discrete user inputs large enough to distinguish between different parameter ranges that are still small enough to be administered by the patient.

It is contemplated that the solution may also be used to monitor the patient's condition using a patient model. This allows the patient model to correct for model errors using measured patient-specific data taken over a certain period of time. More specifically, the patient model may be used to predict future glucose excursions from current and historical information, and may provide monitoring of the overall system, correction of model errors, determining whether or not the patient model is or continues to be appropriate for the patient or needs more/additional development, setting up and/or predicting alarm conditions such as hypoglycemic and/or hyperglycemic events, and predicting when to dispense the next meal bolus.

Referring again to FIG. 2, process 50 proceeds from step 60 to step 62 where a mapping is defined for mapping patient inputs to the graphical interface to corresponding medication therapy information in step 62. Again using the example common throughout this document, the memory or data storage unit 16 and/or 34 illustratively stores therein a map for correlating the meal information entered by the patient with the amount of insulin delivered. The mapping is provided in any conventional form, examples of which include, but are not limited to, one or more graphs, charts, tables, formulas, and the like. Fig. 16 illustrates an exemplary embodiment of such a mapping 148 and is provided in the form of a table that maps carbohydrate content in the form of meal duration to meal compensation pill information in the form of meal speed and expected speed of overall glucose absorption by the patient from the meal. In the embodiment illustrated in fig. 16, the meal compensation pill information may be or include any one or more of a total number X of insulin pills dispensed to the user, a quantity or number Y (e.g., international units) of each of the plurality of insulin pills dispensed, a time, a delta T between dispensing each insulin pill, and a time I of the first of the plurality of insulin pills to be dispensed. Those skilled in the art will recognize that other insulin dose maps may be used to define a map relating the amount of insulin delivered to the meal information entered by the patient, and that the disclosure contemplates any such other insulin dose maps.

Referring now to fig. 17, a block diagram of one illustrative embodiment of the electronic device 12 of fig. 1 implemented in a semi-closed loop drug dispensing system 150 is shown. The patient represented by block 152 in system 150 is simulated by the patient model developed at steps 52 and 54 of process 50 of figure 2. The insulin delivery device 154 is configured to deliver insulin or one or more other patient glycemic or hypoglycemic drugs to the patient 152. The insulin delivery device 154 is a conventional implantable or externally worn infusion pump, and the dashed lines used to connect the electronic device 12 to the device 154 in this embodiment represent wired or wireless communication paths. Alternatively, the insulin delivery device 154 may be a conventional manually actuated device such as a conventional syringe, insulin pen, or the like, and the dashed lines connecting the electronic device 12 to the device 154 in this case merely represent that the device 154 manually dispenses insulin dispensing suggested by the electronic device 12.

In the embodiment illustrated in fig. 17, the electronic device 12 includes a pill evaluation/adjustment algorithm 200 that receives input from the patient via the graphical interface 20. The patient input to the algorithm 200 is one or more inputs to the graphical interface 20 described herein, and the algorithm 200 is generally operable to determine an appropriate patient treatment from the patient input, an example of which is one or more meals of pills as described herein. It should be appreciated that the evaluation performed by the algorithm 200 is by checking overrides (overrides) for a given therapy and/or taking corrective action in addition to the therapy. Thus, the algorithm takes advantage of the discrepancy between the medication dispense and the order to assess the treatment effect, e.g., achieving a desired blood glucose from the bG metric. In one embodiment, to improve semi-closed loop or closed loop evaluation/adjustment, devices 154 and/or 158 (or 160) communicate dispensing information and/or metric information to algorithm 200.

In the illustrated embodiment, the algorithm 200 may provide its treatment output to the graphical interface 20 for patient review and/or to a conventional pill determination algorithm 156 into which the results of the algorithm 200 are incorporated. Alternatively, the pill evaluation/adjustment algorithm 200 may be incorporated into the pill determination algorithm 156, in which case 100 blocks may be omitted from fig. 17. In any case, the pill determination algorithm 156 may provide information to the graphical interface 20 for display and, as indicated by the dashed arrows extending between the pill determination algorithm 156 and the graphical interface 20 and the insulin delivery device 154, respectively, provide pill dispensing information for control of the insulin delivery device. In some embodiments, the insulin delivery device 154 provides the actual insulin delivery information back to the bolus determination algorithm 156 as indicated by the dashed arrow extending between the two blocks.

In addition to the patient input to the graphical user interface 20, the pill determination algorithm 156 receives blood glucose information from the patient 152 via a blood glucose (bG) sensor. In one embodiment of the system 150, as shown in dashed lines in FIG. 17, the bG sensor 158 may be external to the electronic device 12. In this embodiment, the bG sensor 158 may be a conventional implantable or external bG sensor, or a bG sensor that provides an (on-demand) bG when required. In the case of an external bG sensor, the bG sensor 158 can be any conventional bG sensor including a sensor that provides blood glucose information to the device 12 over a wired or wireless connection or a sensor that analyzes a blood sample and generates a blood glucose reading (e.g., a conventional blood glucose meter) that must be manually entered into the device 12, such as through a keypad or other input device. Alternatively or additionally, the conventional bG sensors 160 can include on-board electronics. In this embodiment, the bG sensor 100 includes a blood analysis device (e.g., a blood glucose meter such as a conventional electrochemical or optical glucose reader) that analyzes a blood sample, determines a corresponding blood glucose value, and provides the blood glucose value to a pill determination algorithm. In any case, the conventional pill determination algorithm 156 is operable to include blood glucose information in determining the amount of pills to be dispensed.

As shown in FIG. 17, the patient 152 is typically subjected to various patient-related events and conditions, some of which include, but are not limited to, any number of meals 72 (including any carbohydrate consumption), patient activities such as exercise 74, patient conditions 78, patient-related stress 76, or other events or conditions 80. As described above, the graphical user interface 20 may be developed to accommodate (accmod ate) any one or more of such patient-related events or conditions and one or more patients, and/or multiple graphical user interfaces may be developed that each accommodate a particular one of a variety of patient-related events or conditions. Alternatively, the device has a mechanical switch, or mechanical knob, or mechanical dial, or selectable software setting that lets the algorithm know the alternate status so that the appropriate treatment parameters can be selected. It is also contemplated that the alternative status may be identified by one or more sensors that are thereafter used in a manual or automatic manner to use the alternative status information to select the appropriate treatment parameters. In any event, in the system 150 illustrated in FIG. 17, the electronic device 12 is operable to consider any one or more such patient-related events or conditions and the patient blood glucose information in determining one or more appropriate treatments. The device 12 thereafter controls the automatic delivery of medication and/or advises the patient of any appropriate treatment including, but not limited to, medication, exercise therapy, advising counseling and/or seeking a health care professional, and the like.

Referring now to fig. 18, a flow diagram of one illustrative embodiment of a pill evaluation/adjustment algorithm 200 for determining medication dosing information based on patient input, such as meal intake information, entered into the graphical interface 20 is shown. The software algorithm 200 is described as being executed by the processor 14 of the electronic device 12 (see fig. 1). The algorithm 200 begins at step 202 and the processor 14 is operable to monitor the Graphical Interface (GI)20 for patient input meal intake information at step 204. The graphical interface 20 may take the form of any one or any combination of the exemplary graphical interfaces illustrated and described herein with respect to fig. 7-12, or alternatively, some alternative form for providing the patient with an input meal-related carbohydrate content and a desired rate of overall glucose absorption by the patient from the meal.

After step 204, the algorithm 200 proceeds to step 206, where the processor 14 is operable to determine whether a complete user input to the graphical interface 20 has been detected in step 206. In embodiments having a single input graphical user interface, for example, the processor 14 may be operable at step 206 to determine when a complete user input to the graphical interface 20 has occurred when the patient has selected a single input to the graphical interface 20. On the other hand, in embodiments having multiple input graphical interfaces 20, the processor 14 is operable to determine when a complete user input to the graphical interface 20 occurs when the user has selected all of the user selectable inputs to the graphical interface 20. In any event, if the processor does not detect a complete patient input to the graphical interface 20 at step 206, execution of the algorithm 200 returns to step 204. On the other hand, if the processor 14 detects at step 206 that a complete patient input to the graphical interface 20 has occurred, execution of the algorithm proceeds to step 208, at which step 208 the processor 14 is operable to time and date stamp the graphical interface 20 input and enter the date and time stamped graphical interface 20 input into a database contained within the memory or data storage unit 16 and/or 34. Steps 204 and 206 may illustratively further include a timeout mechanism configured to direct the algorithm 200 to a specified step or state if the user does not provide complete user input to the graphical interface 20 within a specified period of time.

In the illustrated embodiment, the scheduling algorithm 200 has the expectation that the patient will only enter meal-related information before ingesting the meal so that the date and time stamp generally represents the date and time of the actual meal. Step 208 may illustratively be modified to further provide the patient with the ability to modify the time and/or date associated with the date and time stamped graphical interface 20 entry prior to entering this information into the database. This optional feature provides the user with the ability to enter meal intake information into the graphical interface 20 after ingestion of a meal, and thus modify the time and/or date of the date stamp from the current time and/or date to reflect the actual or estimated last time and/or date that the meal was ingested. In this way, for example, meal compensating pills are determined and dispensed or recommended after a meal has been ingested. This optional feature also provides the patient with the ability to enter meal intake information into the graphical interface 20 prior to ingestion of a meal, e.g., sufficiently prior to a meal, so that the date and/or time stamp of step 208 does not generally represent the actual time and/or date of eating the corresponding meal, and thus the time and/or date stamp is modified from the current time and/or date to reflect the estimated future time and/or date of likely ingestion of a meal. However, it should be understood that the algorithm 200 should in any case further include one or more steps that allow the processor 14 to appropriately modify the user entered input to the graphical interface 20 for use in determining meal compensation pills so that the rate at which the patient absorbs overall glucose from the meal takes into account the time elapsed between ingestion of the meal and subsequent entry of the meal related user input to the graphical interface 20 or the time delay between the entry of the meal related user input to the graphical interface 20 and subsequent ingestion of the meal. The inclusion of these one or more steps is the mechanical movement of a skilled programmer.

Although not shown in fig. 18, the algorithm 200, or another stand-alone algorithm, further includes one or more steps that enable a user to modify or append new and/or perhaps more precise information to previously entered meal-related information and/or associated time and/or date stamp information. This optional feature provides the patient with the ability to modify such data, such as in the case of entering meal-related information before or during ingestion of a meal, or to subsequently reflect any deviation in actual meal ingestion from that expected or estimated at the time the information was entered. For example, a scheduled meal may be skipped or postponed, actually having been eaten more or less than previously estimated, and/or the composition of the meal may be different than previously estimated.

Following step 208, the processor 14 is operable at step 210 to map user (patient) input of meal intake information to the graphical interface 20 to correspond with the insulin delivery information. The memory or data storage unit 16 and/or 34 illustratively stores therein a map correlating the amount of insulin delivered and the time for which the patient is entering meal information, an embodiment of which is illustrated and described herein with respect to fig. 16. However, it should be understood that the processor 14 may alternatively or additionally use different tabular axis values consistent with the carbohydrate content and the desired rate of overall glucose absorption by the patient from the meal, and/or use one or more other conventional mapping techniques for mapping user-specified meal intake information to corresponding insulin bolus delivery information. Although it is described with respect to fig. 16 that the insulin bolus delivery information includes meal compensation pills that include any one or more of a total number X of insulin pills to be dispensed to the user, a quantity or number Y (e.g., international units) of each of the plurality of insulin pills to be dispensed, a time Δ T between dispensing each insulin pill, and a time I at which the first of the plurality of insulin pills to be dispensed. It is further understood that the insulin bolus delivery information may alternatively or additionally include one or more correction bolus amounts, i.e., insulin bolus amounts not associated with meals, and in any event may include more or less information than illustrated in fig. 16.

Execution of the algorithm 200 proceeds from step 210 to step 212, where the processor 14 is operable in the illustrated embodiment to control the display unit 20 and/or the display unit 38 to display at least some of the insulin delivery information determined at step 210 in the form of an insulin bolus recommendation in step 212. Thereafter, at step 214, the processor 14 is operable to determine whether the user accepts or rejects the insulin bolus recommendation displayed at step 212. In one exemplary embodiment, the processor 14 is operable to execute step 214 by displaying user-selectable graphical "accept" and "decline" indicators along with the insulin bolus recommendation and thereafter monitoring the indicators to determine which of the two is selected by the user. In an alternative embodiment, the "accept" and "reject" buttons or keys may form part of the input devices 18 and/or 36, and in this embodiment the processor 14 is operable to perform step 214 by monitoring the buttons or keys to determine which of the two is selected by the user. One of ordinary skill in the art will recognize that this disclosure contemplates other conventional techniques for implementing step 214, as well as any such other conventional techniques. Step 214 illustratively further includes a timeout mechanism configured to direct the algorithm 200 to a specified step or state if the user does not accept or decline the suggestion displayed at step 212. In any event, if the processor 14 determines at step 214 that the user accepted the insulin bolus recommendation displayed at step 212, the processor 14 is thereafter operable at step 216 to provide the recommended insulin bolus information to one or more insulin delivery algorithms, such as the bolus determination algorithm 156 of FIG. 17. In the illustrated embodiment, the bolus determination algorithm 156, upon receiving an insulin recommendation, will dispense the commanded insulin at the appropriate treatment time according to the pump capacity and user settings. For example, some pumps dispense insulin in rapid pulses, and some do so as one injection. With these capabilities, insulin is released according to a profile (profile) in one embodiment. Thereafter at step 218, the processor 14 is operable 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 within the memory or data storage unit 16 and/or 34.

If at step 214 the processor 14 determines that the patient declines the insulin bolus recommendation displayed at step 212, the processor 14 is thereafter operable at step 220 to prompt the user to change the recommended insulin bolus information. In one exemplary embodiment, the processor 14 is operable to execute step 220 by displaying the insulin bolus recommendation in a manner that enables the patient to modify any of the recommended insulin bolus information via the graphical interface 20, the input devices 18 and/or 36, or via some other conventional data input device, and also displays a graphical "change accepted" indicator that is selectable by the user when the modification of the recommended insulin bolus information has been completed. The processor 14 is thus operable at step 222 to monitor for an "accept changes" indicator. Until the user selects the "accept changes" indicator at step 222, the algorithm 200 returns to perform step 220. The algorithm further illustratively includes one or more conventional steps (not shown) that enable the algorithm 200 to continue through step 222 without the user selecting an "accept changes" indicator within a specified period of time. In any event, when the processor 14 determines at step 222 that the user has selected the "accept changes" indicator, the processor 14 is thereafter operative at step 224 to provide the modified insulin bolus information to one or more insulin delivery algorithms, such as the bolus determination algorithm of fig. 17. Thereafter, at step 226, the processor 14 is operable to date and time stamp the modified insulin bolus information and enter the date and time stamped modified insulin bolus information into a database contained within the memory or data storage unit 16 and/or 34. In an alternative embodiment, step 216 of the algorithm 200 can be modified 224 in a conventional manner such that the user can manually override (override) the recommended insulin bolus by manually dispensing one or more insulin boluses. However, in this embodiment, it may be desirable to have the patient enter date and time stamped information, such as the number, type, quantity, and/or timing of the one or more insulin pills, into the database in relation to the manual dispensing of the one or more insulin pills at steps 218 and 226. In any case, execution of the algorithm 200 returns to step 204 from either of steps 218 and 226.

In an alternative embodiment of the algorithm 200, the steps 212 and 220 and 224 are modified in a conventional manner to cause the processor 14 to control the automatic dispensing of one or more insulin boluses to the user under the direction of one or more insulin delivery algorithms based on the insulin delivery information determined at step 210. In this embodiment, the insulin delivery information determined at step 210 is therefore not displayed or otherwise provided to the user as an insulin bolus recommendation, but is instead automatically dispensed or otherwise delivered to the user by a conventional electronically controlled insulin delivery device, such as an implantable, subcutaneous, transdermal and/or transcutaneous insulin pump. The collected information is further synchronized with a centralized database that maintains records for all patients. Information is exchanged using standardized data exchange protocols such as HL7, CDISC. It is also envisioned that the system utilizes proprietary protocols for data exchange.

An example of a graphical user interface for determining drug dosing information from patient related input information through a graphical interface described herein has been in the context of providing the graphical interface with meal intake information from which to determine insulin delivery information. It should be appreciated that similar graphical interfaces may alternatively or additionally be developed based in whole or in part on one or more other patient-related events or conditions, such as one or more external influences and/or various physiological mechanisms associated with the patient. Examples include, but are not limited to, considerations such as explicit or implicit one-dimensional or two-dimensional indicators of motion, pressure, condition, menstrual cycle, and/or the like. Further examples are provided in commonly assigned and pending U.S. patent application serial No.11/297,733, the disclosure of which is incorporated herein by reference. One of ordinary skill in the art will recognize examples of other graphical user interfaces developed in accordance with one or more other external influences and/or various physiological mechanisms associated with the user, and this disclosure contemplates any such other examples. In any case, processor 14 may illustratively operate on date and time stamp event occurrences with any such graphical user interface, and additionally may modify the time and date stamps to identify one or more other external influences and/or various physiological mechanisms associated with the user as occurring in the past or expected to occur in the future. This feature also illustratively allows the user to be provided with functionality that alerts the user of the start/stop times of upcoming (e.g., scheduled) events in order to improve the accuracy of the system and provide an increased level of event compliance.

Whether any one or more of the graphical interfaces illustrated and described herein are suitable for use by a patient will depend, at least in part, on the individual habits of the patient. For example, whether a graphical interface relating meal intake information to meal-related insulin delivery information as described herein is suitable for use by a patient depends at least in part on the patient's eating habits. It is therefore desirable to develop one or more suitable graphical interfaces for any patient based on the patient's habits and to take into account the patient's suitability for using any such graphical interface based on such habits. To reduce the amount of input provided by the user to the system 10 without compromising the overall level of glycemic control, the regularity of the patient's habits is utilized. Thus, whether a meal-related graphical interface, such as the type illustrated and described herein, is suitable for use by an individual typically depends on the ability to streamline the variation of meals or snacks in terms of their glycemic outcome by taking advantage of predictability of the individual's eating habits.

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 thereof have been shown and described and that all changes and modifications that come within the spirit of the invention are desired to be protected.

Claims (22)

1. A method of developing a patient interface for a therapy system, the patient interface being usable by a patient to input information characterizing at least one patient event or condition and from which therapy information can be determined, the method comprising:

providing a patient model configured to simulate a patient's physiological response to at least one patient event or condition;

collecting patient-specific information relating to the actual occurrence of at least one patient event or condition over time; and

a graphical interface is provided based on the patient model and the collected patient-specific information, the graphical interface mapping information input by the patient that is characteristic of at least one patient event or condition to corresponding therapy information.

2. The method of claim 1, wherein the treatment information includes medication treatment information corresponding to one or more medications to be administered to the patient.

3. The method of claim 1, wherein the treatment information includes proposed carbohydrate intake information corresponding to a recommendation to ingest carbohydrates.

4. The method of claim 1, wherein the therapy information includes proposed movement information corresponding to a suggested movement.

5. The method of claim 1, wherein the treatment information includes a recommendation to visit a physician.

6. The method of claim 1, wherein providing a graphical interface comprises selecting a graphical interface having two input parameters characterized by at least one patient event or condition.

7. The method of claim 6, wherein providing the graphical interface comprises defining a solution space for the selected graphical interface based on the patient model and based on the patient-specific information collected according to the protocol.

8. The method of claim 7, wherein providing a graphical interface comprises defining a mapping for mapping two input parameters characterizing at least one patient event or condition to corresponding therapy information.

9. The method of claim 1, further comprising utilizing a graphical interface to map patient input of information characterized by at least one patient event or condition to corresponding therapy information.

10. The method of claim 9, wherein the respective therapy information includes drug administration information.

11. The method of claim 10, further comprising displaying the drug administration information in the form of a suggested time and dosage of the drug.

12. The method of claim 10, further comprising controlling the drug administration device to administer at least one quantity of drug to the patient based on the drug administration information.

13. The method of claim 10, further comprising monitoring a drug administration device that administers at least one amount of drug to the patient based on the drug administration information.

14. A system for developing a patient interface for a therapy system, the patient interface usable by a patient to input information characterizing at least one patient event or condition and from which therapy information can be determined, the system comprising:

a database for storing therein a patient model configured to simulate a physiological response of a patient to at least one patient event or condition;

a first memory configured to store patient-specific information related to an actual occurrence of at least one patient event or condition therein over time; and

a graphical interface configured to map patient-entered information characterizing at least one patient event or condition to corresponding treatment information based on the patient model and based on the collected patient-specific information.

15. The system of claim 14, further comprising a processor having access to a second memory for storing therein instructions executable by the processor to process the patient's input into a graphical interface of information characterizing at least one patient and generate corresponding therapy information.

16. The system of claim 15, further comprising a display unit, wherein the second memory further stores therein instructions executable by the processor to control the display unit to display the corresponding therapy information.

17. The system of claim 16, further comprising a manually actuated drug dispensing device, wherein the corresponding therapy information includes at least one quantity of the drug, and wherein the second memory further has stored therein instructions executable by the processor to control the display unit to display the at least one quantity of the drug that the patient dispensed with the manually actuated drug dispensing device.

18. The system of claim 17, further comprising a blood glucose sensor configured to measure a blood glucose level of the patient and generate a corresponding blood glucose value, and wherein the second memory further has stored therein instructions executable by the processor to determine the at least one drug quantity further based on the blood glucose value.

19. The system of claim 18, further comprising an electronically controllable drug dispensing device configured to dispense at least one drug to the patient, wherein the corresponding therapy information includes at least one drug quantity, and wherein the second memory further stores therein instructions executable by the processor to control the electronically controllable drug dispensing device to dispense the at least one drug quantity to the patient.

20. The system of claim 19, further comprising a blood glucose sensor configured to measure a blood glucose level of the patient and generate a corresponding blood glucose value, and wherein the second memory further has stored therein instructions executable by the processor to determine the at least one drug quantity further based on the blood glucose value at a particular time.

21. The system of claim 14, wherein the graphical interface is configured to map patient input of at least two parameters characterized by at least one patient or condition to corresponding therapy information.

22. A method of developing a patient interface for a therapy system, the patient interface being usable by a patient to input information characterizing at least one patient event or condition and from which therapy information can be determined, the method comprising:

receiving patient-specific information having input parameters characterizing at least one patient event or condition;

identifying which input parameters do not correspond to respective predetermined values provided in the predetermined treatment information;

establishing a constraint minimization problem for the identified input parameters;

generating a solution space from solving the constraint minimization problem, wherein the solution space defines a relationship between the input parameters and their associated acceptable limits to adjust the patient's physiological response to the desired target response; and

a solution space is implemented as a patient interface.