SYSTEM AND METHOD FOR OPERATING CONTROLLER OF DELIVERY DEVICE HAVING SWIPE AND TAP TO CONFIRM FEATURE

A medical device controller is provided that avoids unintended user inputs and unwanted medical device operation(s). A controller sends display commands to a graphical user interface (GUI) display to generate a first screen having a swipe field with no moving icons that prompts a user to initiate a designated operation by the medical device. When a valid swipe gesture is inputted, the controller generates a second screen with confirm button that requires a valid user press before the controller undertakes the designated operation, the controller generating and sending a command for the designated operation to the medical device when the controller determines that a valid user press has been inputted to the confirm button. The controller also sends commands to generate a status screen that transitions a rotating progress ring symbol and level indicator in accordance with a selected event to clearly indicate the status of medical device operations.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention relates to medical device controller displays, and more particularly to a medical device controller display that avoids unintended user inputs and corresponding unwanted medical device operation(s) such as inadvertent entry of a command via a button on the device controller's graphical user interface. The present invention also relates to a medical device controller display that clearly indicates to a user the status of the medical device or progress of selected medical device operations.

Description of Related Art

Demand for on-body medical devices (e.g., wearable infusion pumps) and body area network (BAN) medical devices (e.g., handheld blood glucose meters, smart phones with diabetes management apps, and wireless controllers for on-body devices) has been increasing along with an increase in patients' and healthcare providers' desire for better and more convenient patient management of medical conditions such as diabetes. A number of design criteria for user interfaces on on-body medical devices and BAN medical devices should be considered. For example, people who are managing a medical condition using an on-body or BAN device may be suffering a degree of vision, tactile, and/or cognitive impairment. Accordingly, a need exists for a user interface for a medical device that is easy to use, even when the user has some degree of impairment. For example, a need exists for a medical device with display features that are easy to see and understand to clearly indicate to the user the status of the medical device or progress of selected medical device operations, and/or safety features to avoid unintended operations from inadvertent button presses.

SUMMARY OF THE INVENTION

The above and other problems are overcome, and additional advantages are realized, by illustrative embodiments of the present invention.

In accordance with aspects of illustrative embodiments of the present invention, a medical device controller user interface is provided that includes display features that are easy to see and understand to clearly indicate to the user the status of the medical device or progress of selected medical device operations.

For example, it is an aspect of illustrative embodiments of the present invention to provide a system for delivery of a medication to a patient's body, comprising: a device configured to deliver a medication to a patient's body; a controller connected to a medical device and configured to control delivery of medication from the medical device to a patient's body; and a graphical user interface (GUI) display connected to the controller and configured to receive user inputs and provide data relating to the user inputs to the controller and to generate display screens in response to display commands from the controller. The controller is configured to send display commands to the GUI display to generate a first screen having a swipe field over which a user's finger is swiped to receive a user finger swipe gesture and having no moving icons related to the user finger swipe gesture, the swipe field being displayed to prompt a user to initiate a designated operation by the medical device; to send display commands to the GUI display to generate a second screen when the controller has determined from data, which relates to the user finger swipe gesture and is received from the GUI display, that the user finger swipe gesture has traversed a selected amount of the swipe field and in a designated direction along the swipe field to be recognized by the controller as a valid swipe gesture; and to generate and send a command for the designated operation to the medical device when the controller determines that a valid user press has been inputted to a confirm button on the second screen. When the designated operation is delivery of the medication and the controller determines a valid user press has been inputted to a confirm button on the second screen, the controller is configured to command the medical device to initiate delivery of the medication to the patient, and to generate a delivery status screen via the GUI display, the delivery status screen comprising a rotating progress ring symbol and a level indicator, the controller transitioning each of the rotating progress ring symbol and the level indicator in accordance with a selected event related to the delivery of the medication.

In accordance with aspects of illustrative embodiments of the present invention, the user press in the confirm button must occur within a selected time interval after display of the second screen is initiated on the GUI display to be recognized by the controller as a valid user press.

In accordance with aspects of illustrative embodiments of the present invention, the first screen displays alphanumeric screen identifying information indicating the first screen is a swipe to start delivery screen for the controller, and graphical information indicating the designated direction of the valid swipe gesture. For example, the graphical information comprises a series of static arrows pointing in the designated direction of the valid swipe gesture.

In accordance with aspects of illustrative embodiments of the present invention, the controller is configured to send a display command to the GUI display to display a third screen that is a locked screen having a swipe field over which a user's finger is swiped to receive a user finger swipe gesture and having no moving icons related to the user finger swipe gesture, the swipe field being displayed to prompt a user to initiate unlocking the locked screen. In addition, the controller is configured to generate and send display commands to the GUI display to generate a fourth screen when the controller has determined from data, which relates to the user finger swipe gesture and is received from graphical user display, that the user finger swipe gesture has traversed a selected amount of the swipe field and in a designated direction along the swipe field to be recognized by the controller as a valid swipe gesture; and generate and send a command to the GUI display for generating a fifth unlocked screen allowing a designated operation when the controller determines that a valid user press has been inputted to a confirm button on the fourth screen.

In accordance with aspects of illustrative embodiments of the present invention, the third screen displays alphanumeric screen identifying information indicating the first screen is a swipe to unlock screen for the controller, and graphical information indicating the designated direction of the valid swipe gesture. For example, the graphical information comprises a series of static arrows pointing in the designated direction of the valid swipe gesture.

In accordance with aspects of illustrative embodiments of the present invention, the fifth unlocked screen is a start delivery screen configured to allow a user to enter at least one of a request to deliver a dose of medication and an inputted amount of medication, and to require the user to enter a valid press of an button to confirm that delivery of medication is desired.

In accordance with aspects of illustrative embodiments of the present invention, a device for controlling the delivery of a medication to a patient's body, comprises: a controller connected to a medical device and configured to control delivery of medication from the medical device to a patient's body; a user interface connected to the controller and configured to receive user inputs and provide data relating to the user inputs to the controller; and a display connected to the controller and configured to generate display screens. The controller is configured to command the medical device to initiate delivery of the medication to the patient in response to a user input via the user interface, and to generate a delivery status screen via the display in response to the user input. The delivery status screen comprises a rotating progress ring symbol and a level indicator. The controller transitions each of the rotating progress ring symbol and the level indicator in accordance with a selected event related to the delivery of the medication.

In accordance with aspects of illustrative embodiments of the present invention, the controller and the medical device exchange messages, the medical device advising the controller of status of completion of the delivery of the medication, and the controller using the status of completion as the selected event for transitioning each of the rotating progress ring symbol and the level indicator. For example, the status of completion can comprise number of units of the medication delivered to the patient's body. Further, the controller can rotate the progress ring symbol a selected number of degrees corresponding to a selected change in the units of the medication delivered to the patient's body. The progress ring symbol can comprise at least one of a notch along its circumference or a gradient in the thickness of the progress ring symbol to facilitate user discernment of rotation of the progress symbol. The controller can change the level indicator relative to a background image on the display a selected amount corresponding to a selected change in the units of the medication delivered to the patient's body.

In accordance with aspects of illustrative embodiments of the present invention, the controller determines status of completion of the delivery of the medication based on a timer initiated at the initiation of the delivery of the medication, the controller using the amount of time elapsed indicated by the timer as the selected event for transitioning each of the rotating progress ring symbol and the level indicator. For example, the controller rotates the progress ring symbol a selected number of degrees corresponding to the amount of time elapsed indicated by the timer. The progress ring symbol can comprise at least one of a notch along its circumference or a gradient in the thickness of the progress ring symbol to facilitate user discernment of rotation of the progress symbol. The controller can change the level indicator relative to a background image on the display a selected amount corresponding to the amount of time elapsed indicated by the timer. Further, the controller can rotate the progress ring symbol at a rate that transitions the progress ring symbol faster than the changes in the level indicator.

In accordance with aspects of illustrative embodiments of the present invention, the controller is separate from the medical device and connected thereto via wireless communications. For example, the user interface and the display are configured in a graphical user interface (GUI) device. In addition, the GUI device can be on the controller.

In accordance with aspects of illustrative embodiments of the present invention, a user interface is provided that avoids unintended user inputs and corresponding unwanted medical device operation(s), such as inadvertent entry of a command via a button on the device controller's graphical user interface.

For example, it is an aspect of illustrative embodiments of the present invention to provide a device for controlling the delivery of a medication to a patient's body, comprising a controller connected to a medical device and configured to control delivery of medication from the medical device to a patient's body; and a graphical user display connected to the controller and configured to receive user inputs and provide data relating to the user inputs to the controller and to generate display screens in response to display commands from the controller. The controller is configured to send display commands to the graphical user display to generate a first screen having a swipe field over which a user's finger is swiped to receive a user finger swipe gesture and having no moving icons related to the user finger swipe gesture. The controller is configured to generate a second screen when it has determined from data, which relates to the user finger swipe gesture and is received from graphical user display, that the user finger swipe gesture has traversed a selected amount of the swipe field and in a designated direction along the swipe field to be recognized by the controller as a valid swipe gesture, the swipe field being displayed to prompt a user to initiate a designated operation by the medical device. The second screen comprises a confirm button that requires a valid user press before the controller undertakes a designated operation, the controller generating and sending a command for the designated operation to the medical device when the controller determines that a valid user press has been inputted to the confirm button.

In accordance with aspects of illustrative embodiments of the present invention, the user press in the confirm button must occur within a selected time interval after display of the second screen is initiated on the graphical user display to be recognized by the controller as a valid user press.

In accordance with aspects of illustrative embodiments of the present invention, the first screen displays alphanumeric screen identifying information indicating the first screen is a swipe to unlock screen for the controller, and graphical information indicating the designated direction of the valid swipe gesture. For example, the graphical information comprises a series of static arrows pointing in the designated direction of the valid swipe gesture.

In accordance with aspects of illustrative embodiments of the present invention, the first screen displays alphanumeric screen identifying information indicating the first screen is a swipe to start delivery screen for the controller, and graphical information indicating the designated direction of the valid swipe gesture. For example, the graphical information comprises a series of static arrows pointing in the designated direction of the valid swipe gesture.

In accordance with aspects of illustrative embodiments of the present invention, the designated operation indicated by the first screen is a swipe to unlock screen for the controller, and the controller generates a third screen when a valid user press is recognized in the second screen, the third screen being configured to allow a user to enter at least one of a request to deliver a dose of medication and an inputted amount of medication, and to require the user to enter a valid press of an button to confirm that delivery of medication is desired. Further, the controller can generate a fourth screen when a valid press is recognized of the button to confirm that delivery of medication is desired, the fourth screen having a swipe field over which a user's finger is swiped to receive a user finger swipe gesture and having no moving icons related to the user finger swipe gesture. The controller is configured to generate a fifth screen when it has determined from data, which relates to the user finger swipe gesture and is received from graphical user display, that the user finger swipe gesture has traversed a selected amount of the swipe field and in a designated direction along the swipe field to be recognized by the controller as a valid swipe gesture. The fifth screen comprises a confirm button that requires a valid user press before the controller undertakes a designated operation, the controller being configured to command the medical device to deliver medication in response to user input to the fifth screen. The fourth screen can remain displayed by the graphical user display and the fifth screen is not generated when the controller determines that either the user finger swipe gesture has not traversed a selected amount of the swipe field or was in a direction along the swipe field other than the designated direction.

In accordance with aspects of illustrative embodiments of the present invention, the first screen remains displayed by the graphical user display and the second screen is not generated when the controller determines that either the user finger swipe gesture has not traversed a selected amount of the swipe field or was in a direction along the swipe field other than the designated direction.

In accordance with aspects of illustrative embodiments of the present invention, the designated operation can be one of unlock the controller, and command the medical device to deliver medication.

Additional and/or other aspects and advantages of the present invention will be set forth in the description that follows, or will be apparent from the description, or may be learned by practice of the invention. The present invention may comprise a medical device controller and methods for operating same having one or more of the above aspects, and/or one or more of the features and combinations thereof. The present invention may comprise one or more of the features and/or combinations of the above aspects as recited, for example, in the attached claims.

Throughout the drawing figures, like reference numbers will be understood to refer to like elements, features and structures,

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Reference will now be made in detail to embodiments of the present invention, which are illustrated in the accompanying drawings. The embodiments described herein exemplify, but do not limit, the present invention by referring to the drawings.

In accordance with illustrative embodiments of the present invention, a medical device controller with a user interface is provided that realizes a number of advantages comprising, but not limited to, ease of use such as display features that are easy to see and understand to clearly indicate to the user the status of the medical device or progress of selected medical device operations, while avoiding inadvertent user inputs for unintended device operations.

Reference is now made toFIGS. 1 through 13, 14A and 14B, wherein an illustrative medication delivery system10is shown having a medical device12and a controller14with display24, which is a graphical user interface such as a liquid crystal display (LCD) with touch screen. It is to be understood that, although the example display24is shown and described in connection with the controller14, the display features described here in accordance with example embodiments of the present invention can be provided in a display provided on a medical device, or on a smart phone or other device with display that is used on conjunction with a medical device.

The medical device12can be a wearable device or a patient-carried device. The medical device12can have an integrated user interface as its controller14, or the medical device can be configured to he controlled by a separate controller device such as a wireless controller14as shown inFIG. 1. In the illustrated embodiment, the medical device12is controlled by a wireless controller14, but it is to be understood that aspects of the present invention apply to a medical device12with an integrated user interface and display24, or a separate controller device14with a user interface and display24whereby the medical device12may or may not have a display24.

For example, the medical device12can be a disposable insulin delivery device (IDD) for single patient use that is configured for continuous subcutaneous delivery of insulin at set and variable basal (24-hour period) rates and bolus (on-demand) doses for the management of patients with Type 2 Diabetes Mellitus (T2DM) requiring insulin therapy. It is to be understood, however, that the medical device12can be any on-body medical device (e.g., wearable infusion pump, continuous glucose meter) or body area network (BAN) medical device (e.g., handheld blood glucose meter, smart phone with medical condition management apps, or wireless controller for on-body device).

The IDD12is part of a system10that is an advanced insulin delivery system for use by patients with Type 2 Diabetes Mellitus (T2DM). It is configured for 24-hour-a-day use in all environments typically inhabited by the target users. It is configured for the patient user to wear the IDD for a period of three days (up to 84 hours). It has four (4) main functions: delivering user-set daily basal insulin rate; delivering user-set bolus insulin amount; delivering manual bolus insulin dose(s); and generating system status and notifications. The system addresses an unmet need for many Type 2 patients on multiple daily injections (MDI) requiring discreet, simple and cost effective insulin delivery alternative to the traditional complex insulin pump. It is to be understood, however, that the medical device12can be used to deliver any type of fluid and is not limited to insulin delivery or to T2 diabetes treatment regimens.

The Wireless Controller (WC)14is used to program the body-worn IDD to deliver a daily basal insulin rate and meal-time insulin amount to the patient. The WC14also provides status information of the IDD12as well as notifications to the user. The body-worn IDD12stores and administers insulin to the patient subcutaneously. The IDD sends feedback to the patient via the WC if it detects issues (e.g., low volume in the reservoir, low battery). An important function supported by communication software in the system10is the wireless communication between the WC14and IDD12, which enables the IDD12to provide the feedback to the WC14and for the user to control their insulin delivery by the IDD12wirelessly via the WC14in a simple and discrete way.

In the illustrated embodiment shown inFIG. 14A, the IDD12has a microcontroller60configured to control a pumping mechanism52, wireless communication with the WC14(e.g., via an RF circuit54having a match circuit and antenna), and pump operations. The IDD has a bolus button(s)64for manual delivery of medication in addition to programmed delivery of medication. The pumping mechanism52comprises a reservoir76for storing a fluid medication (e.g., insulin) to be delivered via a cannula68to the patient wearing the IDD, and a pump72for controllably delivering designated amounts of medication from the reservoir through the cannula. The reservoir76can be filled via a septum78using a syringe. The IDD has a manual insertion mechanism66for inserting the cannula68into a patient; however, the processor60can be configured to operate an optional drive circuit to automate operation of the insertion mechanism66to deploy the cannula68into the patient. Further, the IDD12can be optionally provided with a fluid sensor74or a pressure sensor70. An LED62can be operated by the microcontroller60to be on or flash during one or more pump operations such as during reservoir priming, for example. The IDD12is powered by a battery and regulator as indicated at58. When initializing the IDD12(e.g., powering on to begin pairing with the WC12), the bolus button(s)64can be configured as wake-up button(s) that, when activated by the user, causes the IDD12to wake from a power conserving shelf mode.

In the illustrated embodiment shown inFIG. 14B, the WC14is implemented as a dual microprocessor component having: 1) a WC Main Processor (WCMP)30, and a WC Communications Processor (WCCP)32. The WCMP30is connected to the user interface (UI) components such as the LCD display with touch screen24, one or more buttons28, LED indicator26, and the like. The WCCP32is connected to radio frequency (RF) components38(e.g., an antenna and a match circuit) and is mainly responsible for the WC14's wireless communication with the IDD12. The two processors30,32communicate with each other through a serial peripheral interface (SPI). The two processors30,32can also interrupt each other through two interrupt pins, M_REQ_INT and S_REQ_INT. It is to be understood that the WC14can also be configured as a single processor device.

With continued reference toFIG. 14B, the WC14is designed to be non-field serviceable (i.e. no parts to be inspected, adjusted, replaced or maintained by the user), except for replaceable alkaline batteries34for power. A non-volatile memory (e.g., FLASH memory)36is provided in the WC to store delivery and status data received from the IDD12such as delivery dates and times and amounts.

The LCD with capacitive touch screen24serves as the visual interface for the user by rendering visual and graphical outputs to the user (e.g., system information, instructions, visual notices, user configurations, data outputs, etc.), and by providing a visual interface for the user to enter inputs (e.g., device operation inputs such as IDD pairing and set up and dosing, and configuration parameters, and so on). The WC display with capacitive touch screen24detects (at least) single-touch gestures over its display area. For example, the touch screen is configured for recognizing user tactile inputs (tap, swipe, and button press), allowing for navigation within UI screens (e.g.,FIGS. 2 through 13, among others) and applications. The touch screen24aids in executing specific system functionalities (i.e. IDD12setup and pairing with the WC14, insulin dosing, providing user with dosing history, and IDD deactivation and replacement with another IDD, and so on) through specific user interactions. The WC14can also include a button28such as a device wake-up button that, when activated by the user, causes the WC14to wake from a power conserving sleep mode. The WC14can also have an LED26to indicate low battery status (e.g., indicate low battery state when there is 12 hours or less of usage remaining).

The WC14radio frequency (RF) interface with the IDD12is, for example, based on a Bluetooth Low Energy or BLE-based communication protocol, although other wireless communication protocols can be used. In the medication delivery system10, the WC14and IDD12communicate wirelessly within a distance of up to 10 feet or approximately 3 meters, utilizing the ISM band from 2400 MHz to 2480 MHZ spectrum. The WC14communicates with the IDD12while the IDD is adhered to the body in open air. The WC14is the central device or master, and the IDD12is the peripheral device or slave. Whenever the WCMP30wants to send information to the IDD12or retrieve information from the IDD12, it does so by interacting with the WCCP32, which in turn, communicates with the IDD12across the BLE link via the respective RF circuits38and54.

FIG. 15illustrates a software architecture for the WC14in accordance with an illustrative embodiment of the present invention that comprises an Event Dispatcher80, and a number of Controllers (e.g.,90and92), and an Event Queue or FIFO82for storing events emitted by the Controllers. It is to be understood, however, that other software architecture can be used for the WC including architecture that does not employ an Event Dispatcher80or the Controllers illustrated inFIG. 15.

With continued reference toFIG. 15. a Controller is a bundle of code with a specific responsibility in the WC14. Controllers work together under direction of the Event Dispatcher80to form the WC main application of the WCMP30. Internally, a Controller module can be composed of many objects/functions that use lower-level interfaces and libraries to achieve its goals. The Controllers communicate by emitting events, such as events that have no associated parameters, and other types of events have specific parameters associated with them. Events can be processed in event first-in-first-out (FIFO) order or First-Emitted, First-Dispatched to be more precise, as indicated at82.

The Event Dispatcher80is configured to give processing time to the Controllers such as by operating as a main loop that calls each of the Controllers once per iteration of the main loop. The Event Dispatcher80calls each Controller (a) whenever there is an Event to be processed or (b) whenever an interrupt has occurred while the WCMP30is idle. When the Event Dispatcher80sees that the Event Queue82is empty, it generates an Empty Event Queue Event (EID_NOP). Controllers can use this event to check any hardware they are controlling or ignore it at their discretion. If one or more of the Controllers need to be executed at a periodic rate (e.g. the Display Controller86may need to periodically update a progress indicator while a bolus is being delivered), this will be achieved by using the periodic events generated every 100 mS by the Timer Controller96described below.

With reference toFIG. 15, the Communications Controller90understands the low-level communications protocol (e.g., the SPI between the WCMP30and the WCCP32) and is responsible for handling communications or interactions with the WCCP32. The Timer Controller96is responsible for interactions with various timers employed by the WC14.

The Critical Data Controller88is responsible for managing the critical data that the WC needs to store and for generating checksums, performing reads and writes of ferroelectric random-access memory (FRAM) or other type of memory, for example, and ensuring that the applied protection mechanisms (CRCs, checksums, etc.) will ensure data integrity. The Power Controller98is responsible for maintaining the processor30in the lowest-possible power mode, retriggering a watchdog timer, adjusting the processor clock speed for normal and low-power modes, and putting the processor30into a low-power sleep mode.

Notifications are special conditions that need to be brought to the user's attention. The Notification Controller94looks for notifications that are generated by other Controller modules. When it sees that one has occurred, it handles it in the manner dictated for that notification or notification type. To handle the event, the Notification Controller94may activate/deactivate various peripherals to cause audible, visual, or tactile feedback to the user. The Notification Controller94may generate additional events as required to cause other subsystems to take additional actions.

The User Inputs Controller84observes actions taken by the user via the button(s)28, the touch screen24, and so on, and generates events that indicate the action that has occurred. The User Inputs Controller84generally does not know anything about what touches or gestures are allowed by the current screen or what any of these actions mean to the WC14.

The Display Controller86handles the graphical user interface touch screen display24and is responsible for displaying screens to the user and emitting system events (e.g., to the Event Queue of the WCMP30) based on user interaction with the user interface24. For example, the Display Controller86displays user interface screens, emits events based on user input events (e.g., generated by a User Inputs Controller84such as wake button28events), emits events based on user inputs generated by a touch screen interface24, handles processing events that require display updates and/or screen changes, reads critical data (i.e., settings) and displays to the user, and updates user modified data (i.e., settings) to critical data.

The IDD Controller92(IDDC) inFIG. 15is responsible for application-level interactions with the IDD12and the WCCP32. The IDD Controller92does this by generating commands and sending these to the Communications Controller90. After sending a command, the IDDC92waits for a response from the WCCP32or IDD12and processes the response when received. The IDD Controller92sends messages to the WCCP32in response to events and generates events based on the responses received from the WCCP32. The IDDC92is also responsible for obtaining the status of the WCCP32and IDD12at the appropriate intervals.

More specifically, after sending a command, the IDD Controller92waits for a response and, when received, it processes the application-layer response content. The IDD Controller92has no knowledge of the transport-layer and IPC-layer of the messages or the physical interface between the WCMP30and the WCCP32. The IDD Controller92is aware that the WCCP32is expected to send a response to every command it receives from the WCMP30. The IDD Controller92is also responsible for background communication tasks such as getting WCCP32status and IDD12status periodically, getting IDD bolus data after a bolus ends, and getting IDD log data prior to deactivation.

The IDD Controller92functional responsibilities include, but are not limited to, generate application-layer command events (includes application-layer message content), process application-layer response events, perform sanity checking on the application layer portion of messages, update WC/IDD critical data values, emit bolus record and log data events, and issue periodic IDD status updates. In addition, the IDD Controller92manages application-level command/response messaging to perform: pairing, IDD configuration, IDD priming, IDD activation, changing IDD configuration, bolus delivery and cancellation, maintain and display bolus history, deactivation and unpairing of an IDD, and IDD log retrieval, among other operations.

The Display Controller86exists as a screen manager containing a global event handler and a screen event handler. The screen manager's global processing event function includes the processing of user input events such as touch screen press, release or swipe events. The screen event handler calls a function to determine if the event is associated with an object on the display that requires display or system interaction and then call a “callback” function for that object. Events that are not associated with any object on the display are ignored. The screen manager also handles the LCD backlight by turning it on or off based on the WC wakeup button events.

For example, the Display Controller86contains an internal data structure for each screen containing a list of objects on the screen. If the object has an action associated to it via an event generated by the User Inputs Controller, then a callback function for that object is defined. The following objects have a callback associated with them: (1) button—callback is called if a release or swipe event has been associated with the button; and (2) icon —callback is called if a release event has been associated with the icon.

The screen event handler processes events that are of interest to the screen itself such as a timing event to allow the screen to be displayed for a period of time before transitioning to another screen. Each screen has a unique enumeration identifier along with a ScreenCreate and ScreenProcessEvent function or NULL if no process event function is necessary. The transition from screen to screen is done by a call to a ScreenChange function. The global event handler or local event handler can call the ScreenChange function in order to transition to a new screen.

In accordance with an embodiment of the present invention, a combination of plural touch screens having respective inputs is provided to avoid unintended user inputs and corresponding unwanted medical device operation(s), such as inadvertent entry of a command via a button on the medical device controller's graphical user interface.

With reference toFIGS. 2 through 7 and 16, illustrative screen images are generated on a display such as the LCD touch screen24of the WC14. As described above, the WCMP30is programmed to generate screens on the display24in response to various events. For example, if the WC14and the IDD12are paired, and the IDD12has undergone initial setup via the WC14, a home screen200such as that shown inFIG. 4is displayed. When the WC14has not received user input within a selected period of time, the WC14enters a lower power sleep mode to conserve WC power (e.g., backlighting of display is off or reduced). For added protection against inadvertent use of the WC, a Swipe to Unlock screen202as shown inFIG. 2is displayed when the WC14receives a wake-up input (e.g., via button28) while in the sleep mode (block100,FIG. 16). A Swipe to Unlock Button204is provided at the bottom of an unlock swipe screen202.

The Swipe to Unlock Button204is configured to only respond when a left-to-right swipe motion that occurs within the button's active area is recognized as a valid swipe gesture by the touch screen24hardware and corresponding WCMP30software. It is to be understood that the Swipe to Unlock Button204can be oriented elsewhere within the area of screen202and in a different orientation (e.g., vertical or diagonal versus horizontal). Further, the button204's active area can be rectangular or other shape. In any event, the slide/swipe field of the Swipe to Unlock button204can have static arrows206in the button204area or adjacent to the button204area on the touch screen24that are progressively darker shades of color to indicate the direction of swipe gesture needed for user's gesture to be recognized by the screen event handler of the Display Controller86as a valid Swipe to Unlock gesture or event. Other static alphanumeric or graphical indicating a direction for a valid swipe gesture. In any event, neither the Swipe to Unlock button204nor any part of the Swipe to Unlock screen202has any moving image corresponding to the user's finger input. As stated above, the WCMP30software is configured to detect when an area of the display24designated as representing a “button” (e.g., Swipe to Unlock Button204) has been pressed or has received a designated gesture (e.g., swipe), and to generate an internal event that allows the WCMP software to respond to the button press or gesture. For example, the Swipe to Unlock button204and similar swipe/slide buttons can be configured by the WCMP30to require a tactile or capacitive input over a selected percentage of the button204area within a designated period of time before an inputted swipe gesture is recognized as valid.

With reference to block102inFIG. 16, upon recognition of a valid swipe gesture by the Display Controller86of the WCMP30, the graphical user interface (GUI) or touch screen display24is transitioned by the WCMP30to another screen208as shown inFIG. 3, that is, an unlock confirm screen208, which has a Confirm Unlock Button210displayed at the bottom thereof. The screen object (e.g., tap to confirm field210) can be a rectangle or other GUI button shape into which a user press can be input and recognized as a valid input by the screen manager of the Display Controller86, although other shapes for the object210can be used. In other words, the Confirm Unlock Button210responds to a single press and release within the displayed button boundary.

The unlock confirm screen208is transitioned to the home screen200(FIG. 4and block104inFIG. 16) when a user's gesture in the Confirm Unlock Button210is recognized by the Display Controller86of the WCMP30. The home screen200has a Take Food Dose button214that can be depressed when a user wishes to have a bolus delivered. Upon recognition of a user press of the Take Food Dose button214, the WCMP30is configured to generate a Set Food Dose screen212(FIG. 5, block106inFIG. 16). When the user inputs a selected dose (e.g., 25 units) into the Set Food Dose screen212on the display24of the WC14, the WC14communicates the dose to the controller60of the IDD12to set the pump mechanism52accordingly.

When the OK button216is pressed (block108inFIG. 16), the Display Controller86of the WCMP30is configured to cause a Swipe to Start screen218(FIG. 6, block110inFIG. 16) to be generated on the display24, in accordance with another aspect of illustrative embodiments of the present invention.

The Swipe to Start screen218is similar to the Swipe to Unlock screen202in that a Swipe to Start button220is displayed at the bottom of the screen that is configured to only respond to a left-to-right swipe motion recognized as a valid swipe gesture by the touch screen hardware that occurs within the button's active area. It is to be understood that the Swipe to Start button220can be oriented elsewhere within the area of screen218and in a different orientation (e.g., vertical or diagonal versus horizontal). Further, the button220's active area can be rectangular or other shape. In any event, the slide/swipe field or area of the Swipe to Start button220can have static arrows222in the button220area or adjacent to the button220area on the touch screen24that are progressively darker shades of color to indicate the direction of swipe gesture needed for user's gesture to be recognized by the screen event handler of the Display Controller86as a valid Swipe to Start gesture or event. Other static alphanumeric or graphical indicating a direction for a valid swipe gesture. In any event, neither the Swipe to Start button220nor any part of the Swipe to Start screen218has any moving image corresponding to the user's finger input. As stated above, the WCMP30software is configured to detect when an area of the display24designated as representing a “button” (e g., Swipe to Start button220) has been pressed or has received a designated gesture (e.g., swipe), and to generate an internal event that allows the WCMP30software to respond to the button press or gesture.

With reference to block108inFIG. 16, upon recognition of a valid swipe gesture by the Display Controller86of the WCMP30, the graphical user interface (GUI) or touch screen display24is transitioned by the WCMP30to another screen224as shown inFIG. 7(block110inFIG. 16), that is, an Confirm Start screen224, which has a Confirm Start button226displayed at the bottom thereof. The screen object (e.g., tap to confirm field226) can be a rectangle or other GUI button shape into which a user press can be input and recognized as a valid input by the screen manager of the Display Controller86. In other words, the Confirm Start button226responds to a single press and release within the displayed button226boundary.

The Confirm Start screen224is transitioned by the WCMP30to a Delivery screen228(FIG. 8and block114inFIG. 16) when a user's gesture in the Confirm Start button226is recognized by the Display Controller86of the WCMP30as a valid button press (block112inFIG. 16). Thus, inadvertent activation of the WC to commence a dose is avoided by the generation of a first screen requiring a swipe gesture to request a dose, and generation of a second screen with a confirm button only if the swipe gesture in the first screen is valid, and the requirement of a valid press of a confirm button on the second screen before the controller (e.g., WC14) controls a medical device (e.g., IDD12) to commence delivery of a medication. Inadvertent activation of the medical device to request a dose or open a home screen or open another screen, after a period of inactivity, is likewise avoided by a similar sequence of screens and gestures (e.g., a swipe on a first screen to unlock the device, a transition to a second screen if a valid swipe gesture is entered, and the valid press of a button on the second screen to confirm unlocking the device). In this manner, inadvertent pressure on the WC14's display24(es., a WC being pressed by other items in a user's purse or briefcase or pocket) will not result in inadvertently opening the medical device controller14to an operating screen wherein inadvertent changes to settings or unintended device12operations can occur as a result of the inadvertent pressure on the controller14GUI.

With continued reference to blocks116,118and120inFIG. 16, the WC14is configured to display a Delivery screen (FIGS. 8 through 12) that indicate status of delivery and provides a user with a touch screen button246to cancel delivery, as well as indicate progress of delivery. If the Press to Cancels button246receives a valid user activation, then the WC14communicates a command to the IDD12to stop the pump mechanism52from completing the bolus entered by the unit. Upon completion of medication delivery, the WC14displays an updated home screen200(FIG. 13) with updated dosing information as indicated at244.

In accordance with embodiments of the present invention and with reference toFIGS. 8 through 12, 17A and 17B, a combination of display screen features are provided to clearly indicate to a user the status of the medical device or progress of selected medical device operations.

After the Confirm Start button226is successfully pressed, a Delivery screen228(FIG. 8) is generated by the WCMP30as described above. As illustrated inFIG. 8, the Delivery screen228comprises two different types of delivery progress indicators, that is, a rotating progress ring232, and a level indicator234(e.g., a background gradient image230that transitions as indicated by a transition line234delineating the respective background image248of the screen and the background gradient image230, which can be two respective colors are shades of the same color, or different patterns and so on).

For example, upon generation of the Delivery screen228, the background gradient image230can constitute the majority of the area of the display24area relative to the background image248. The WCMP30can be configured to update or refresh a screen periodically (e.g., every 1 second or other time interval for screen update). For example, the Delivery screen228can be updated such that 10 pixels are overwritten once every update cycle from a background gradient color (e.g., gray as shown inFIGS. 8 through 11) with white or black or other background color that is different from the background gradient color, starting at the top and then down to the bottom of the display. Once less than a selected number of lines from the bottom (e.g. 10 lines) the Delivery screen228remain with the background gradient color (e.g., gray), the process starts over such that the background gradient image230constitutes the majority of the area of the display24area again relative to the background image248. It is to be understood that other types of level indicators232can be used such as a horizontal line on the display24's Delivery screen228that does not involve changing background colors on the display.

In addition to background gradient image230transitions described above, the display24's controller (e.g., WCMP30) can periodically update a progress indicator232while a bolus is being delivered. For the progress indicator232(e.g., a ring232with notch250as shown inFIGS. 8 through 11), can be rotated as indicated by the displacement of the notch250as the screen is updated. This update can be accomplished by the Timer Controller96emitting a corresponding event at a selected required rate.

The rotations of the progress ring232and the background gradient image230transitions can be based on different criteria such as by amount of medicament delivered as reported from the IDD12to the WC14via status messages as described in connection withFIG. 17A, or by time elapsing during delivery as described in connection withFIG. 17B. For example, a background gradient level234can be transition (e.g., decreased or lowered, or vice versa increased or raised, before repeating from the top of bottom of the screen respectively) a selected number of pixels per time increment during delivery.

When the background gradient image230transitions are based on amount of medication delivered, status messages from the IDD12to the WC14can be used, that is, status messages from the IDD12to the WCMP14allow the WCMP to command the Display Controller86to change the level234of the background gradient image230relative to the background image248(e.g., by overwriting a selected number of pixels based on a selected number of medication dose increments reported by the IDD12has having been delivered).

More specifically, as shown inFIG. 17A, a Delivery screen228is displayed (block122). When a user starts a bolus from the WC14and while the bolus is running or being delivered, the WCMP30polls for IDD status periodically from the IDD12by issuing a Get IDD status command (block124). The IDD response to the Get IDD status command indicates the progress of the bolus delivery, including the number of insulin units delivered and if the bolus has completed (block126). The WCMP30can be configured to transition the background gradient image230relative to the background image such as overwrite a selected number of screen lines, and rotate the progress ring232's notch250by a designated number of degrees, based on selected amount of bolus delivered per IDD12response or status message (block128). Upon dose completion (block130), the WC14attempts to retrieve the bolus data by issuing the Get IDD Bolus Data command to the IDD12. An updated home screen200with updated delivery data244(FIG. 12) can be displayed (block132inFIG. 17A).

Background gradient image230and progress ring232transitions based on feedback of insulin units delivered can be accomplished with a sufficiently fast processor; otherwise, the background gradient image230and progress ring232can be transitioned by user discernible increments throughout duration of delivery, whereby the background gradient image230transitions repeat top to bottom incremental level234changes or vice versa bottom to top incremental level234changes. For example, as shown inFIG. 17B, a Delivery screen228is displayed (block140). When a user starts a bolus from the WC14and while the bolus is running or being delivered, the WCMP30determines how much time elapses since the initiation of the bolus using the Timer Controller and status messages from the IDD12indicating whether the bolus delivery is complete (block142). The WCMP30can be configured to transition the background gradient image230by a selected number of pixels based on lapsing of selected time increments (block144). Similarly, the WCMP30can be configured to rotate the progress ring232to transition the notch250by a selected number of degrees based on lapsing of selected time increments (block144). Upon dose completion (block146), the WC14attempts to retrieve the bolus data by issuing the Get IDD Bolus Data command to the IDD12. An updated home screen200with updated delivery data244(FIG. 12) can be displayed (block148inFIG. 17B).

In addition, thickness of progress ring can be changed in the same manner. For example, the WCMP30can generate a progress ring232that thickens based on feedback of amount delivered from the IDD12if the microcontroller30is a sufficiently fast processor; otherwise, thickening of the progress ring232in user discernible increments throughout duration of delivery and repeat ring thickening increments (e.g., make ring232thin again, or flash beginning of a new ring232that is not yet thickened in place of an existing ring, that is, a new ring at original thickness or partial ring at original thickness) and then gradually thicken, or thicken and fill in a partial ring232, in increments based on delivery progress or timing. Thus, a notch250in the ring232would not be needed to discern degree of rotation to indicate progress.

The rotation of the progress ring232can be changed or transitioned during the delivery of medication faster relative to the transition of the level indicator234to better assist a user to discern that delivery is in progress, even when the level indicator234has yet not been transitioned to the next level according to the transitioning criteria used (e.g., a selected number of pixels of display lines per unit delivered or amount of time elapsed since initiation of medication delivery).

It will be understood by one skilled in the art that this disclosure is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. The embodiments herein are capable of other embodiments, and capable of being practiced or carried out in various ways. Also, it will be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless limited otherwise, the terms “connected,” “coupled,” and “mounted,” and variations thereof herein are used broadly and encompass direct and indirect connections, couplings, and mountings. In addition, the terms “connected” and “coupled” and variations thereof are not restricted to physical or mechanical connections or couplings. Further, terms such as up, down, bottom, and top are relative, and are employed to aid illustration, but are not limiting.

The components of the illustrative devices, systems and methods employed in accordance with the illustrated embodiments of the present invention can be implemented, at least in part, in digital electronic circuitry, analog electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. These components can be implemented, for example, as a computer program product such as a computer program, program code or computer instructions tangibly embodied in an information carrier, or in a machine-readable storage device, for execution by, or to control the operation of, data processing apparatus such as a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can he deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network. Also, functional programs, codes, and code segments for accomplishing the present invention can be easily construed as within the scope of the invention by programmers skilled in the art to which the present invention pertains. Method steps associated with the illustrative embodiments of the present invention can be performed by one or more programmable processors executing a computer program, code or instructions to perform functions (e.g., by operating on input data and/or generating an output). Method steps can also be performed by, and apparatus of the invention can be implemented as, special purpose logic circuitiy, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

The above-presented description and figures are intended by way of example only and are not intended to limit the present invention in any way except as set forth in the following claims. It is particularly noted that persons skilled in the art can readily combine the various technical aspects of the various elements of the various illustrative embodiments that have been described above in numerous other ways, all of which are considered to be within the scope of the invention.