Patent Application
20200384190
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.
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.
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.
The above and/or other aspects and advantages of embodiments of the invention will be more readily appreciated from the following detailed description, taken in conjunction with the accompanying drawings, of which:
Throughout the drawing figures, like reference numbers will be understood to refer to like elements, features and structures,
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 to
The medical device 12 can be a wearable device or a patient-carried device. The medical device 12 can have an integrated user interface as its controller 14, or the medical device can be configured to he controlled by a separate controller device such as a wireless controller 14 as shown in
For example, the medical device 12 can 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 device 12 can 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 IDD 12 is part of a system 10 that 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 device 12 can 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) 14 is used to program the body-worn IDD to deliver a daily basal insulin rate and meal-time insulin amount to the patient. The WC 14 also provides status information of the IDD 12 as well as notifications to the user. The body-worn IDD 12 stores 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 system 10 is the wireless communication between the WC 14 and IDD 12, which enables the IDD 12 to provide the feedback to the WC 14 and for the user to control their insulin delivery by the IDD 12 wirelessly via the WC 14 in a simple and discrete way.
In the illustrated embodiment shown in
In the illustrated embodiment shown in
With continued reference to
The LCD with capacitive touch screen 24 serves 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 screen 24 detects (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.,
The WC 14 radio frequency (RF) interface with the IDD 12 is, 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 system 10, the WC 14 and IDD 12 communicate 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 WC 14 communicates with the IDD 12 while the IDD is adhered to the body in open air. The WC 14 is the central device or master, and the IDD 12 is the peripheral device or slave. Whenever the WCMP 30 wants to send information to the IDD 12 or retrieve information from the IDD 12, it does so by interacting with the WCCP 32, which in turn, communicates with the IDD 12 across the BLE link via the respective RF circuits 38 and 54.
With continued reference to
The Event Dispatcher 80 is 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 Dispatcher 80 calls each Controller (a) whenever there is an Event to be processed or (b) whenever an interrupt has occurred while the WCMP 30 is idle. When the Event Dispatcher 80 sees that the Event Queue 82 is 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 Controller 86 may 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 Controller 96 described below.
With reference to
The Critical Data Controller 88 is 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 Controller 98 is responsible for maintaining the processor 30 in the lowest-possible power mode, retriggering a watchdog timer, adjusting the processor clock speed for normal and low-power modes, and putting the processor 30 into a low-power sleep mode.
Notifications are special conditions that need to be brought to the user's attention. The Notification Controller 94 looks 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 Controller 94 may activate/deactivate various peripherals to cause audible, visual, or tactile feedback to the user. The Notification Controller 94 may generate additional events as required to cause other subsystems to take additional actions.
The User Inputs Controller 84 observes actions taken by the user via the button(s) 28, the touch screen 24, and so on, and generates events that indicate the action that has occurred. The User Inputs Controller 84 generally does not know anything about what touches or gestures are allowed by the current screen or what any of these actions mean to the WC 14.
The Display Controller 86 handles the graphical user interface touch screen display 24 and is responsible for displaying screens to the user and emitting system events (e.g., to the Event Queue of the WCMP 30) based on user interaction with the user interface 24. For example, the Display Controller 86 displays user interface screens, emits events based on user input events (e.g., generated by a User Inputs Controller 84 such as wake button 28 events), emits events based on user inputs generated by a touch screen interface 24, 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 Controller 92 (IDDC) in
More specifically, after sending a command, the IDD Controller 92 waits for a response and, when received, it processes the application-layer response content. The IDD Controller 92 has no knowledge of the transport-layer and IPC-layer of the messages or the physical interface between the WCMP 30 and the WCCP 32. The IDD Controller 92 is aware that the WCCP 32 is expected to send a response to every command it receives from the WCMP 30. The IDD Controller 92 is also responsible for background communication tasks such as getting WCCP 32 status and IDD 12 status periodically, getting IDD bolus data after a bolus ends, and getting IDD log data prior to deactivation.
The IDD Controller 92 functional 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 Controller 92 manages 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 Controller 86 exists 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 Controller 86 contains 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 to
The Swipe to Unlock Button 204 is 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 screen 24 hardware and corresponding WCMP 30 software. It is to be understood that the Swipe to Unlock Button 204 can be oriented elsewhere within the area of screen 202 and in a different orientation (e.g., vertical or diagonal versus horizontal). Further, the button 204's active area can be rectangular or other shape. In any event, the slide/swipe field of the Swipe to Unlock button 204 can have static arrows 206 in the button 204 area or adjacent to the button 204 area on the touch screen 24 that 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 Controller 86 as 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 button 204 nor any part of the Swipe to Unlock screen 202 has any moving image corresponding to the user's finger input. As stated above, the WCMP 30 software is configured to detect when an area of the display 24 designated as representing a “button” (e.g., Swipe to Unlock Button 204) 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 button 204 and similar swipe/slide buttons can be configured by the WCMP 30 to require a tactile or capacitive input over a selected percentage of the button 204 area within a designated period of time before an inputted swipe gesture is recognized as valid.
With reference to block 102 in
The unlock confirm screen 208 is transitioned to the home screen 200 (
When the OK button 216 is pressed (block 108 in
The Swipe to Start screen 218 is similar to the Swipe to Unlock screen 202 in that a Swipe to Start button 220 is 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 button 220 can be oriented elsewhere within the area of screen 218 and in a different orientation (e.g., vertical or diagonal versus horizontal). Further, the button 220's active area can be rectangular or other shape. In any event, the slide/swipe field or area of the Swipe to Start button 220 can have static arrows 222 in the button 220 area or adjacent to the button 220 area on the touch screen 24 that 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 Controller 86 as 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 button 220 nor any part of the Swipe to Start screen 218 has any moving image corresponding to the user's finger input. As stated above, the WCMP 30 software is configured to detect when an area of the display 24 designated as representing a “button” (e g., Swipe to Start button 220) has been pressed or has received a designated gesture (e.g., swipe), and to generate an internal event that allows the WCMP 30 software to respond to the button press or gesture.
With reference to block 108 in
The Confirm Start screen 224 is transitioned by the WCMP 30 to a Delivery screen 228 (
With continued reference to blocks 116, 118 and 120 in
In accordance with embodiments of the present invention and with reference to
After the Confirm Start button 226 is successfully pressed, a Delivery screen 228 (
For example, upon generation of the Delivery screen 228, the background gradient image 230 can constitute the majority of the area of the display 24 area relative to the background image 248. The WCMP 30 can 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 screen 228 can be updated such that 10 pixels are overwritten once every update cycle from a background gradient color (e.g., gray as shown in
In addition to background gradient image 230 transitions described above, the display 24's controller (e.g., WCMP 30) can periodically update a progress indicator 232 while a bolus is being delivered. For the progress indicator 232 (e.g., a ring 232 with notch 250 as shown in
The rotations of the progress ring 232 and the background gradient image 230 transitions can be based on different criteria such as by amount of medicament delivered as reported from the IDD 12 to the WC 14 via status messages as described in connection with
When the background gradient image 230 transitions are based on amount of medication delivered, status messages from the IDD 12 to the WC 14 can be used, that is, status messages from the IDD 12 to the WCMP 14 allow the WCMP to command the Display Controller 86 to change the level 234 of the background gradient image 230 relative to the background image 248 (e.g., by overwriting a selected number of pixels based on a selected number of medication dose increments reported by the IDD 12 has having been delivered).
More specifically, as shown in
Background gradient image 230 and progress ring 232 transitions based on feedback of insulin units delivered can be accomplished with a sufficiently fast processor; otherwise, the background gradient image 230 and progress ring 232 can be transitioned by user discernible increments throughout duration of delivery, whereby the background gradient image 230 transitions repeat top to bottom incremental level 234 changes or vice versa bottom to top incremental level 234 changes. For example, as shown in
In addition, thickness of progress ring can be changed in the same manner. For example, the WCMP 30 can generate a progress ring 232 that thickens based on feedback of amount delivered from the IDD 12 if the microcontroller 30 is a sufficiently fast processor; otherwise, thickening of the progress ring 232 in user discernible increments throughout duration of delivery and repeat ring thickening increments (e.g., make ring 232 thin again, or flash beginning of a new ring 232 that 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 ring 232, in increments based on delivery progress or timing. Thus, a notch 250 in the ring 232 would not be needed to discern degree of rotation to indicate progress.
The rotation of the progress ring 232 can be changed or transitioned during the delivery of medication faster relative to the transition of the level indicator 234 to better assist a user to discern that delivery is in progress, even when the level indicator 234 has 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 various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.
Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may he represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), flash memory, Read Only Memory (ROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in the remote station, Electronic medical device, a server, or a combination thereof. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.
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.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US18/23725 | 3/22/2018 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62478227 | Mar 2017 | US | |
| 62478182 | Mar 2017 | US |
