TECHNICAL FIELDEmbodiments of the subject matter described herein relate generally to medical devices, and more particularly, embodiments of the subject matter relate to facilitating patient operation of a medical device.
BACKGROUNDInfusion pump devices and systems are relatively well known in the medical arts, for use in delivering or dispensing an agent, such as insulin or another prescribed medication, to a patient. A typical infusion pump includes a pump drive system which typically includes a small motor and drive train components that convert rotational motor motion to a translational displacement of a plunger (or stopper) in a reservoir that delivers medication from the reservoir to the body of a user via a fluid path created between the reservoir and the body of a user. Use of infusion pump therapy has been increasing, especially for delivering insulin for diabetics.
Control schemes have been developed that allow insulin infusion pumps to monitor and regulate a user's blood glucose level in a substantially continuous and autonomous manner. However, regulating blood glucose level is still complicated by variations in a user's individual insulin response and daily activities (e.g., exercise, carbohydrate consumption, bolus administration, and the like) in conjunction with variations associated with the devices or components used to implement continuous glucose monitoring and related controls, and potentially other factors that may contribute to variations, uncertainty, or otherwise impair accuracy or reliability. Since many of the variables influencing glucose regulation and control may often be dynamically or periodically changing, some user involvement with the infusion pump may be desirable to achieve the desired performance and outcomes.
Modern devices may incorporate or support any number of potential features as well as utilizing various user interface(s), which may be unique to a particular device. Therefore, it is desirable for device manufacturers to provide additional consumer education. Traditionally, product manuals or guides documenting the various aspects of the device were provided. For some users, printed documentation can be disfavored and neglected. At the same time, due to regulatory requirements or other concerns, medical devices may not be as equipped as other computer devices for providing consumer education features electronically. Though customer service or other manufacturer support may be available by phone or email, many users tend to find invoking such services to be time consuming and inconvenient. Accordingly, there is a need to provide consumer education in a manner that is simple, convenient, and efficient to enable maximizing device performance for optimal patient outcomes.
BRIEF SUMMARYMedical devices and related systems and operating methods are provided. An exemplary method of interactively providing guidance facilitating operation of a medical device involves identifying, at a computing device communicatively coupled to the medical device, a user objective associated with the medical device, obtaining, at the computing device from the medical device, user interface status information corresponding to a current state of a user interface of the medical device, and providing, on a display associated with the computing device, guidance information influenced by the user interface status information and the user objective. Subsequently, updated user interface status information for the infusion device responsive to a user input with respect to the infusion device may be provided to the computing device, with the guidance information being dynamically updated in response to the updated status information.
In another embodiment, an apparatus for a medical device is provided. The medical device includes a display to provide one or more graphical user interface displays, a user interface element to receive a user input, a data storage element to maintain settings information, a communications interface communicatively coupled to a network, and control module coupled to the display, the user interface element, the data storage element, and the communications interface. The control module is configurable to transmit the settings information and status information characterizing a state of the display to an auxiliary device via the network, and in response to the user input, automatically push updated status information characterizing an updated state of the display responsive to the user input to the auxiliary device via the network.
Another embodiment of a method of facilitating operation of an infusion device to deliver a fluid influencing a physiological condition to a body of a user involves identifying, at a computing device communicatively coupled to the infusion device, an objective associated with the infusion device. obtaining, at the computing device from the infusion device via a network, current user interface status information for the infusion device, and generating, at the computing device, a guidance graphical user interface display comprising a sequence of one or more user actions with respect to the infusion device for achieving the objective based at least in part on the current user interface status information.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
BRIEF DESCRIPTION OF THE DRAWINGSA more complete understanding of the subject matter may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures, which may be illustrated for simplicity and clarity and are not necessarily drawn to scale.
FIG. 1 depicts an exemplary embodiment of a patient guidance system;
FIG. 2 is a flow diagram of an exemplary interactive guidance process suitable for use with the patient guidance system ofFIG. 1 in one or more exemplary embodiments;
FIGS. 3-8 depict a sequence of graphical user interface displays that may be presented in conjunction with the interactive guidance process ofFIG. 2 in one embodiment;
FIGS. 9-10 depict another sequence of graphical user interface displays that may be presented in conjunction with the interactive guidance process ofFIG. 2 in another embodiment;
FIG. 11 depicts an exemplary embodiment of an infusion system;
FIG. 12 depicts a plan view of an exemplary embodiment of a fluid infusion device suitable for use in the infusion system ofFIG. 11;
FIG. 13 is an exploded perspective view of the fluid infusion device ofFIG. 12;
FIG. 14 is a cross-sectional view of the fluid infusion device ofFIGS. 12-13 as viewed along line14-14 inFIG. 13 when assembled with a reservoir inserted in the infusion device; and
FIG. 15 is a block diagram of an exemplary medical device suitable for use in conjunction with the interactive guidance process ofFIG. 2 in accordance with one or more exemplary embodiments.
DETAILED DESCRIPTIONThe following detailed description is merely illustrative in nature and is not intended to limit the embodiments of the subject matter or the application and uses of such embodiments. As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any implementation described herein as exemplary is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary or the following detailed description.
Exemplary embodiments of the subject matter described herein are implemented in conjunction with medical devices, such as portable electronic medical devices. Although many different applications are possible, the following description focuses on embodiments that incorporate a fluid infusion device (or infusion pump) as part of an infusion system deployment. For the sake of brevity, conventional techniques related to infusion system operation, insulin pump and/or infusion set operation, and other functional aspects of the systems (and the individual operating components of the systems) may not be described in detail here. Examples of infusion pumps may be of the type described in, but not limited to, U.S. Pat. Nos. 4,562,751; 4,685,903; 5,080,653; 5,505,709; 5,097,122; 6,485,465; 6,554,798; 6,558,320; 6,558,351; 6,641,533; 6,659,980; 6,752,787; 6,817,990; 6,932,584; and 7,621,893; each of which are herein incorporated by reference. That said, the subject matter described herein can be utilized more generally in the context of overall diabetes management or other physiological conditions, and the subject matter described herein is not limited to any particular type of medication or medical device being utilized.
Generally, a fluid infusion device includes a motor or other actuation arrangement that is operable to linearly displace a plunger (or stopper) of a reservoir provided within the fluid infusion device to deliver a dosage of fluid, such as insulin, to the body of a user. Dosage commands that govern operation of the motor may be generated in an automated manner in accordance with the delivery control scheme associated with a particular operating mode, and the dosage commands may be generated in a manner that is influenced by a current (or most recent) measurement of a physiological condition in the body of the user. For example, in a closed-loop operating mode, dosage commands may be generated based on a difference between a current (or most recent) measurement of the interstitial fluid glucose level in the body of the user and a target (or reference) glucose value. In this regard, the rate of infusion may vary as the difference between a current measurement value and the target measurement value fluctuates. For purposes of explanation, the subject matter is described herein in the context of the infused fluid being insulin for regulating a glucose level of a user (or patient); however, it should be appreciated that many other fluids may be administered through infusion, and the subject matter described herein is not necessarily limited to use with insulin.
Exemplary embodiments described herein generally relate to systems and methods of interactively providing guidance information pertaining to a medical device for review or action by a user on an auxiliary device, such as a computer, a smartphone, or the like, to help facilitate the configuration or operation of various features of a medical device. As described in greater detail below, the auxiliary device identifies or otherwise determines the user's objective associated with the medical device, such as, for example, what the user wants to accomplish using the medical device, what aspect of the medical device the user has questions about, or the like. The auxiliary device also obtains, from the medical device, status information that characterizes, describes, or otherwise corresponds to a current state of a user interface of the medical device. In this regard, the user interface status information may indicate a current graphical user interface (GUI) displayed on a display of the medical device and a current selection or position of a user input element on the display. Based on the current user interface status information and the user's objective, the guidance information indicative of the user actions for accomplishing the user's objective is determined and presented or otherwise provided on a display associated with the auxiliary device for review by the user. In this regard, the user may concurrently view the guidance information for accomplishing the objective presented on the auxiliary device while interacting with the medical device in accordance with the guidance information.
In exemplary embodiments, the auxiliary device and the medical device are paired over a communications network, so that the medical device may upload, push, or otherwise transmit updated user interface status information to the auxiliary device substantially in real-time in response to a user input or other interaction with the medical device. In response to obtaining indication of the updated state of the user interface of the medical device, the guidance information presented on the auxiliary device is dynamically updated to reflect how the user input influenced the user actions for accomplishing the user's objective from the updated user interface state. Thus, as the user navigates through various menus or GUI display screens on the medical device, the guidance information on the auxiliary device may be dynamically updated substantially concurrently, allowing the user to move back and forth across displays seamlessly.
In one or more embodiments, the auxiliary device also obtains operational settings or other device configuration information from the medical device to provide guidance information consistent with the current device setup or other user- or patient-specific configurations. For example, if the user's objective is to administer a bolus using the infusion device, the operational settings information obtained by the auxiliary device may indicate that a bolus wizard feature of the infusion device has not been setup, in which case the guidance information may provide instructions for how to configure or setup the bolus wizard. Conversely, when the operational settings information indicates the bolus wizard feature has been setup and is currently enabled, the guidance information may provide instructions for utilizing the bolus wizard. In this regard, for device features or modes that require specific user inputs, patient-specific parameters, or other actions before they are enabled or operable, the guidance information may instruct the user for configuring and enabling such features. At the same time, by virtue of obtaining the settings information, the provided guidance information does not pertain to device features or operating modes that the user has not enabled, configured, or otherwise activated. Thus, the user may be provided only with guidance information pertinent to both the current device configuration and the user's objective. As such, providing potentially non-pertinent or non-actionable information is avoided, which improves the user experience.
FIG. 1 depicts an exemplary embodiment of apatient guidance system100. Thepatient guidance system100 includes aninfusion device102 communicatively coupled to anauxiliary device106 via anetwork110. As described in greater detail below in the context ofFIGS. 2-10, theauxiliary device106 supports anapplication108 that generates and provides guidance information on a display associated with theauxiliary device108 that includes instructions or other indication of user actions for accomplishing an objective associated with theinfusion device102 based on that objective and the current user interface status for theinfusion device102 received via thenetwork110. In the illustrated embodiment, theinfusion device102 is also communicatively coupled to asensing arrangement104 to obtain measurement data indicative of a physiological condition in the body of a patient, such as sensor glucose measurement values. For example, in one or more exemplary embodiments, theinfusion device102 operates autonomously to regulate the patient's glucose level based on the sensor glucose measurement values received from thesensing arrangement104.
Theauxiliary device106 represents an electronic device capable of communicating with theinfusion device102 viacommunications network110. In exemplary embodiments, thenetwork110 is realized as a Bluetooth network, a ZigBee network, a wireless local area network (WLAN), or another suitable personal area network or local area network (LAN). That said, in other embodiments, theinfusion device102 and theauxiliary device106 may communicate via a direct communications interface, such as a wire, cable, infrared, or some other short range communications medium. Depending on the embodiment, theauxiliary device106 may be realized as any sort of electronic device capable of communicating with theinfusion device102 vianetwork110, such as a mobile telephone, a smartphone, a laptop or notebook computer, a tablet computer, a desktop computer, a personal digital assistant, or the like. For purposes of explanation, but without limitation, theauxiliary device106 may alternatively be referred to herein as a client device. Theclient device106 includes or is coupled to a display device, such as a monitor, screen, or another conventional electronic display, capable of graphically presenting data and/or information. Theclient device106 also includes or is otherwise associated with a user input device, such as a keyboard, a mouse, a touchscreen, or the like, capable of receiving input data and/or other information from the user of theclient device106.
In one or more embodiments, a user, such as the patient, the patient's doctor or another healthcare provider, or the like, manipulates theclient device106 to execute aclient application108 that communicates with theinfusion device102 via thenetwork110 using a networking protocol. Theclient application108 supports establishing a communications session with theinfusion device102 on thenetwork110 and receiving data and/or information from theinfusion device102 via the communications session. In this regard, theinfusion device102 may execute or otherwise implement a corresponding application or process that supports establishing the communications session with theclient application108. Theclient application108 generally represents a software module or another feature that is generated or otherwise implemented by theclient device106 to support the processes described herein. In such embodiments, theclient device106 includes a processing system and a data storage element (or memory) capable of storing programming instructions for execution by the processing system, that, when read and executed, cause processing system to create, generate, or otherwise facilitate theclient application108 and perform or otherwise support the processes, tasks, operations, and/or functions described herein. Depending on the embodiment, the processing system may be implemented using any suitable processing system and/or device, such as, for example, one or more processors, central processing units (CPUs), controllers, microprocessors, microcontrollers, processing cores and/or other hardware computing resources configured to support the operation of the processing system described herein. Similarly, the data storage element or memory may be realized as a random access memory (RAM), read only memory (ROM), flash memory, magnetic or optical mass storage, or any other suitable non-transitory short or long term data storage or other computer-readable media, and/or any suitable combination thereof.
In one or more embodiments, theinfusion device102 and theclient device106 establish an association (or pairing) with one another over thenetwork110 to support subsequently establishing a peer-to-peer communication session between theinfusion device102 and theclient device106 via thenetwork110. For example, in accordance with one embodiment, thenetwork110 is realized as a Bluetooth network, wherein theinfusion device102 and theclient device106 are paired with one another (e.g., by obtaining and storing network identification information for one another) by performing a discovery procedure or another suitable pairing procedure. In this regard, the pairing information obtained during the discovery procedure allows either of theinfusion device102 or theclient device106 to initiate the establishment of a secure peer-to-peer communication session via thenetwork110. Some examples of an infusion device pairing with a client device are described in United States Patent Application Publication Nos. 2015/0057807 and 2015/0057634, which are incorporated by reference herein in their entirety.
In one or more exemplary embodiments, theclient application108 is configured to store or otherwise maintain an address and/or other identification information for aremote device114 on anothernetwork112. In this regard, thesecond network112 may be physically and/or logically distinct from thenetwork110, such as, for example, the Internet, a cellular network, a wide area network (WAN), or the like. Theremote device114 generally represents a computing device that includes or otherwise implements asupport application116 configured to receive or otherwise obtain the current user interface status information for theinfusion device102 and the current user objective from theclient application108 and present the information to another user operating theremote device114 for analysis. For example, theremote device114 may be utilized by customer service personnel to provide customer support in the event the patient or user of theclient device108 is having difficulty accomplishing his or her objective with respect to theinfusion device102, as described in greater detail below in the context ofFIG. 2. Theremote device114 may reside at a location that is physically distinct and/or separate from theinfusion device102, such as, for example, at a facility that is owned and/or operated by or otherwise affiliated with a manufacturer of theinfusion device102.
It should be appreciated thatFIG. 1 depicts a simplified representation of apatient guidance system100 for purposes of explanation and is not intended to limit the subject matter described herein in any way. For example, in various embodiments, one or more of thedevices102,104,106,114 may be absent from thepatient guidance system100. Additionally, whileFIG. 1 depicts asingle sensing arrangement104, in practice, embodiments of thepatient guidance system100 may include multiple different sensing arrangements, which may be configured to sense, measure, or otherwise quantify any number of conditions or characteristics. For example, multiple instances of aglucose sensing arrangement104 may be deployed for redundancy or other purposes (e.g., averaging or other statistical operations). In other embodiments,additional sensing arrangements104 may be deployed to measure different physiological conditions of the patient, such as, for example, the patient's heart rate, oxygen levels, or the like.
FIG. 2 depicts an exemplaryinteractive guidance process200 suitable for implementation by a patient guidance system to provide guidance to a patient or user to facilitate desired operation of a medical device, such asinfusion device102. The various tasks performed in connection with theinteractive guidance process200 may be performed by hardware, firmware, software executed by processing circuitry, or any combination thereof. For illustrative purposes, the following description refers to elements mentioned above in connection withFIG. 1. In practice, portions of theinteractive guidance process200 may be performed by different elements of thepatient guidance system100, such as, for example, theinfusion device102, thesensing arrangement104, theclient device106, theclient application108, theremote device114 and/or thesupport application116. It should be appreciated that theinteractive guidance process200 may include any number of additional or alternative tasks, the tasks need not be performed in the illustrated order and/or the tasks may be performed concurrently, and/or theinteractive guidance process200 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the tasks shown and described in the context ofFIG. 2 could be omitted from a practical embodiment of theinteractive guidance process200 as long as the intended overall functionality remains intact.
Theinteractive guidance process200 begins by determining or otherwise identifying an objective associated with operation of the medical device (task202). In this regard, theclient application108 identifies what the patient or user of theclient device106 is trying to accomplish or achieve using theinfusion device102 or what feature or aspect of theinfusion device102 is of interest to the patient. For example, theclient application108 may generate or otherwise provide a GUI display that allows the patient to select, input, or otherwise indicate what the patient's objective is. In one embodiment, theclient application108 generates a list of selectable GUI elements, where each of the GUI elements corresponds to a different objective, as described in greater detail below in the context ofFIG. 3.
In other embodiments, theclient application108 may determine what the patient's objective is based on the current state of theinfusion device102. For example, when the patient manipulates theclient device106 to initiate or open theclient application108, theclient application108 may establish a communications session with theinfusion device102 via thenetwork110, obtain information characterizing the current device state from theinfusion device102 via thenetwork110, and then determine a likely patient objective based on the current device state. In this regard, if there is an active alert or notification presented to generated by theinfusion device102, theclient application108 may determine the patient's objective is to resolve or understand the current alert or notification. As another example, if the delivery of fluid by theinfusion device102 is suspended, theclient application108 may determine the patient's objective is to enable or resume delivery. It should be noted that are numerous different potential device statuses and corresponding objectives that may be determined based thereon, and the subject matter described herein is not limited to any particular example described herein.
In other embodiments, theclient application108 may determine what the patient's objective is based on a GUI element selected within theclient application108. For example, theclient application108 may include a selectable GUI element for activating a help feature, and thereby indicate a patient objective indicative of a desire to obtain explanatory information or other help understanding the GUI display currently presented by theinfusion device102.
Theinteractive guidance process200 continues by obtaining status information indicative of the current state of the display on the medical device, the current state of the user input element(s) associated with the medical device, and the current operational settings or configuration of the medical device (tasks204,206,208). In this regard, theclient application108 receives or otherwise obtains, from theinfusion device102 via thenetwork110, information or data that indicates, identifies, or otherwise describes the current screen, menu, or other GUI display presented on theinfusion device102. Theclient application108 also receives or obtains information that indicates or identifies the state of a user input selection (or a mouse, icon, or other graphical representation thereof) on the screen, menu, or other GUI display presented on theinfusion device102. Theclient application108 may also obtain information pertaining to preceding user inputs or the sequence of user input selections made prior to performing theinteractive guidance process200. Additionally, theclient application108 obtains settings or configuration data stored or otherwise maintained onboard theinfusion device102 pertaining to the various modes, features, or other patient-specific or patient-configurable operations supported by theinfusion device102. In this regard, the current device settings information may indicate the modes or features supported by theinfusion device102 that have been enabled, activated, or configured, which modes or features supported by theinfusion device102 that have been disabled or deactivated, which patient-specific control parameters, variables, or other patient settings for which values have been defined, entered or otherwise provided, and which patient-specific control parameters, variables, or other patient settings for which no values are maintained by theinfusion device102.
Based on the user's objective, the current user interface status, and the current device settings, theinteractive guidance process200 generates or otherwise provides a guidance GUI display on the auxiliary device that indicates or otherwise explains how the user can achieve the objective given the current user interface status and the current device settings (task210). For example, the guidance GUI display on theclient device106 may provide one or more instructions or actions that the user can take from the current GUI display on theinfusion device102 given the current state of the user input(s) associated with theinfusion device102 and the current infusion device settings. In this regard, the guidance information provided by theapplication108 on theclient device106 is consistent with (or context-sensitive to) both the current infusion device operational settings and the current patient-specific settings maintained by theinfusion device102, while also being context-sensitive with respect to the user interfaces of theinfusion device102 to reflect the current GUI display on theinfusion device102 and current state of user interaction with respect to that GUI display on theinfusion device102. In other words, the guidance information is not incompatible or inconsistent with current settings maintained by theinfusion device102, and is also not incompatible or inconsistent with the current user interface status of theinfusion device102.
After initially providing guidance information, theinteractive guidance process200 continues by monitoring or otherwise waiting for changes in the user interface state of the medical device, an in response to a change in the user interface state, theinteractive guidance process200 receives or otherwise obtains updated user interface status information from the medical device and dynamically updates the guidance information to reflect the change in user interface state (tasks210,212,214). In this regard, as the patient or other user interacts with the user interface element(s) associated with theinfusion device102 to navigate through or change the GUI display presented on theinfusion device102, the corresponding updated status information characterizing the state or location of the user input element(s) associated with theinfusion device102 as well as the current display state of theinfusion device102 is automatically provided to theclient application108. For example, in one embodiment, a process or application on theinfusion device102 that supports the communication session with theclient application108 automatically pushes updated user interface status information to theclient application108 whenever a new user input is received or whenever the GUI display on theinfusion device102 changes. Thus, theclient application108 automatically obtains the updated user interface status information substantially in real-time and dynamically refreshes or updates the GUI display on theclient device106 to reflect the current situation on theinfusion device102, for example, by providing updated instructions or actions that the user can take to achieve the original objective (e.g., task202) from the updated GUI display on theinfusion device102 in response to intervening user input(s) associated with theinfusion device102 after the preceding guidance GUI display was originally provided.
In exemplary embodiments, as described in greater detail below in the context ofFIGS. 4-8, the loop defined bytasks210,212,214 and216 repeats to dynamically update the guidance GUI display on theclient device106 substantially in real-time as the patient or user interacts with theinfusion device102 until the original objective is accomplished. In this regard, once theapplication108 determines that the updated user interface status corresponds to the user objective being accomplished (e.g., when the user has performed all the actions or instructions provided by the guidance GUI display and the display on theinfusion device102 corresponds to the intended destination GUI display at the end of the sequence of instructed user actions), theclient application108 may update the GUI display on theclient device106 to reflect the objective being achieved or to revert back to a default or initial GUI display associated with the client application108 (e.g., a home page or other landing page).
Still referring toFIG. 2, in accordance with one or more embodiments, theinteractive guidance process200 may identify or otherwise determine when remote assistance or other supplementary feedback is desired by the user, and in response, transmits, uploads, or otherwise provides the user objective and status information to a remote device for analysis (tasks218,220). For example, the guidance GUI display provided by theclient application108 on theclient device106 may include a GUI element that is selectable or otherwise manipulable to initiate a customer support communications session with a customer support application118 on aremote device114. In this regard, theclient application108 may store or otherwise maintain an address and/or other identification information for theremote device116 on thesecond network112 to support establishing a secure communications session over thenetwork112 for uploading or otherwise transmitting information characterizing the current user objective, the current state of the display on theinfusion device102, the current state of the user input element(s) associated with theinfusion device102, and the current settings or configuration of theinfusion device102. In some embodiments, theclient application108 may be adapted to allow the user of theclient device106 to input or otherwise provide questions that the user would like answered or otherwise explain the user's perception of the current situation and/or what the user would like to accomplish. Additionally, in some embodiments, theclient application108 may include a GUI element (e.g., a button or the like) that enables the user of theclient device106 to initiate a telephone call, a video call, or the like with a user of theremote device116.
The customer support application118 on theremote device116 is configured to generate or otherwise provide a GUI display on theremote device116 that allows a remote user (e.g., a customer service specialist or the like) to review and analyze the current situation at theinfusion device102 and provide corresponding feedback back to the user of theclient device106 to facilitate achieving the user's objective with respect to theinfusion device102. For example, the user of theremote device116 may input or otherwise provide a textual explanation or feedback regarding the current status at theinfusion device102 relative to the current user objective via the support application118 and then select or otherwise manipulate a GUI element of the support application118 to transmit the feedback back to theclient application108 via the communications session over thenetwork112. In this regard, theinteractive guidance process200 may update the guidance GUI display based on feedback received from the remote device (task222). For example, theclient application108 may generate or otherwise provide the feedback received from thesupport application116 on the guidance GUI display in lieu of the previously presented guidance information or on a separate GUI display (e.g., a pop-up window).
In some embodiments, the support session may be dynamically updated in a similar manner as described above in the context of the loop defined bytasks210,212,214 and216. In such embodiments, updated status information from theinfusion device102 may be automatically pushed or uploaded to the support application118 on theremote device116 by the client application108 (e.g.,tasks214,220), thereby enabling the user at theremote device116 to monitor the state of theinfusion device102 substantially in real-time as the user interacts with theinfusion device102 and responds to the feedback from theremote device116. As needed, the user of the support application118 may provide updated feedback or guidance to theclient application108, which, in turn is presented on the client device106 (e.g., tasks220,222).
FIGS. 3-8 depict an exemplary sequence of GUI displays that may be presented on an infusion device302 (e.g., infusion device102) and a paired auxiliary device306 (e.g., client device106) having a guidance application (e.g., client application108) supporting theinteractive guidance process200 ofFIG. 2 executing thereon. As described in greater detail below in the context ofFIGS. 12-13, theinfusion device302 includes a display326 (e.g., display1226) anduser input elements332,334 (e.g.,user interface elements1232,1234) that allow a user to navigate and interact with the GUI displays presented on thedisplay326. Theclient device306 also similarly includes a display having aguidance GUI display308 generated by theclient application108 presented thereon.
Referring toFIG. 3 with continued reference toFIGS. 1-2,FIG. 3 depicts a scenario where theinfusion device302 is presenting the main orprimary GUI display304 for the infusion device302 (e.g., the “Home Screen”). For example, themain GUI display304 may include standard graphical icons for the current date, time, and other physical device status information (e.g., battery level, network connectivity, fluid remaining in the reservoir, and the like) along with graphical representations of the current state of the physiological condition in the body of the user based on measurement data received from a sensor (e.g., sensing arrangement104). The user of theclient device306 may manipulate the user input elements of thedevice306 to initiate, execute, or otherwise open theclient application108, which, in turn, establishes a communications session with theinfusion device302 and obtains status information describing the current state of the display326 (e.g., the currently displayed GUI display304), the current state of theuser input elements332,334 (including the location of a pointer, mouse, or other user election on or within the currently displayed GUI display304), and the current settings stored or maintained by theinfusion device302 for the various modes or features supported by theinfusion device302 and any customizable or patient-specific parameter values. Based on thecurrent GUI display304 on theinfusion device302 corresponding to the home screen, theclient application108 may generate aninitial GUI display308 that enables a user to input or otherwise provide indication of his or her objective with respect to theinfusion device302. In this regard, theinitial GUI display308 may include alist310 of potential objectives that are selectable by the user.
Referring now toFIG. 4, in response to the user selecting an objective312 indicative of a desire to consume a meal (or administer a corresponding meal bolus), theclient application108 accesses the current device settings information obtained from the infusion device302 (e.g., task208) to verify or otherwise determine whether a bolus wizard feature has been configured or enabled by the user, and in response to determining that the current device setting information indicates the bolus wizard is not configured or enabled, theclient application108 generates aguidance GUI display408 that enables the user to input or otherwise provide indication of whether he or she would like to configure and enable the bolus wizard or whether he or she would like to bolus manually.
Referring now toFIG. 5, in response to selection of aGUI element412 for configuring the bolus wizard, theclient application108 revises the user objective to enabling the bolus wizard on theinfusion device302 and then generates an updatedguidance GUI display508 including a list or sequence of actions for the user to take using theinput elements332,334 of theinfusion device302 to achieve the objective of enabling the bolus wizard feature. In this regard, the updatedguidance GUI display508 includes alist510 of user actions ordered sequentially for reaching the bolus wizard setup screen(s) from the “Home Screen.” Theguidance GUI display508 indicates whichuser input elements332,334 on theinfusion device302 should be actuated or manipulated by the user, the ordered sequence in which thoseuser input elements332,334 should be actuated, and the number of times a givenuser input element332,334 should be actuated before moving on to anotheruser input element332,334 or the next action of the sequence. Agraphical indicia512 is also presented on thelist510 at the location of the entry for the step in the sequence that the user currently needs to perform. Additionally, entries that have been performed may be graphically deemphasized to reflect their performance and further indicate, to the user, where the user resides within the sequence of actions. As illustrated, the first entry in thelist510 for navigating to the “Home Screen” is graphically deemphasized to reflect the current display status of thedisplay326 and indicate, to the user, where the user resides within the sequence of actions.
Referring now toFIGS. 6-8, in response to a user manipulating auser input element332,334 of theinfusion device302, updated user interface status information is automatically pushed from theinfusion device302 to theclient application108 on theclient device306 for dynamically updating the GUI display. For example, referring toFIG. 6 with reference toFIG. 5, in response to the user actuating the center button on thedirectional pad334 when the HomeScreen GUI display304 is presented, theinfusion device302 updates thedisplay326 to present the MainMenu GUI display604 and automatically provides updated status information to theclient application108 on theclient device306 that indicates the center button on thedirectional pad334 was actuated and that the MainMenu GUI display604 is currently presented. In response to the updated user interface status information, theclient application108 dynamically generates an updatedguidance GUI display608 that reflects the updated user interface status. For example, the second entry in thelist510 for navigating to the “Main Menu” is graphically deemphasized to reflect the current display status of thedisplay326 and the location of thegraphical indicia512 on thelist510 is updated indicate that the user is now on the third entry within the sequence of actions. Additionally, the entry for navigating to the “Main Menu” is updated to reflect a different user action or differentuser input element332,334 for reverting back to the preceding GUI display. Thus, theguidance GUI display608 on theclient device306 corresponds to the state of theGUI display604 that is concurrently being presented on thedisplay326 of theinfusion device302, thereby allowing the user to divert his or her attention seamlessly from thedisplay326 of theinfusion device302 to theguidance GUI display608 on theclient device306 and back to theinfusion device302, while the dynamic updating of thegraphical indicia512 and other guidance information allows the user to keep track of real-time progress on theinfusion device302 when viewing theclient device306.
Referring toFIG. 7 with reference toFIG. 6, in response to the user manipulating thedirectional pad334 to navigate through the MainMenu GUI display604, theinfusion device302 automatically provides updated user interface status information to theclient application108 that indicates the current userinput selection location704 within the MainMenu GUI display604. In response to the updateduser input state704, theclient application108 dynamically generates an updatedguidance GUI display708 that reflects a decreased number of user actions with respect to thedirectional pad334 for achieving the user's objective from the currentuser input state704. For example, after the user has actuated the down direction of thedirectional pad334, the third entry in thelist510 for navigating to the “Options Menu” is updated (relative to guidance GUI display608) to reflect that the user only needs to actuate the down direction of thedirectional pad334 three more times instead of the original number of six to reach the “Options Menu” from thecurrent selection location704 of “Audio Options” within the Main Menu.
Referring toFIG. 8 with reference toFIG. 7, as the user manipulates thedirectional pad334 to reach the “Options Menu” within the MainMenu GUI display604, theinfusion device302 automatically provides updated user interface status information to theclient application108. In response to the updated userinput selection location804 corresponding to the “Options Menu,” theclient application108 dynamically generates an updatedguidance GUI display808 to reflect a different user action. For example, after the user has actuated the down direction of thedirectional pad334 six times, the third entry in thelist510 for navigating to the “Options Menu” is updated (relative to guidance GUI displays508,608,708) to reflect that the user only needs to actuate the center button of thedirectional pad334 to navigate from the MainMenu GUI display604 to the Options Menu GUI display. Once the center button is actuated, the third entry in thelist510 for navigating to the “Options Menu” is graphically deemphasized to indicate that the user is now on the fourth entry within the sequence of actions as well as being updated to reflect a different user action or differentuser input element332,334 for reverting back to the preceding MainMenu GUI display604 from the Options Menu GUI display in a similar manner as described above. The position of thegraphical indicia512 within thelist510 is also updated to horizontally align with the fourth entry in thelist510. It should be noted that if the user actuates the down direction of thedirectional pad334 an excessive amount of times and passes the “Options Menu” within the MainMenu GUI display604, the third entry in thelist510 for navigating to the “Options Menu” is updated (relative to guidance GUI displays508,608,708) to reflect that the user only needs to actuate the up direction of thedirectional pad334 to navigate to the Options Menu GUI display. In this manner, the likelihood of the user proceeding to an incorrect GUI display may be reduced.
FIGS. 9-10 depict another exemplary sequence of GUI displays that may be presented on theclient device306 in concert with theinfusion device302 and theinteractive guidance process200 ofFIG. 2. Referring toFIG. 9, in a similar manner as described above in the context ofFIGS. 3-4, in response to the user selecting an objective312 indicative of a desire to consume a meal (or administer a corresponding meal bolus), theclient application108 accesses the current device settings information obtained from the infusion device302 (e.g., task208) to verify or otherwise determine whether a bolus wizard feature has been configured or enabled by the user. In the illustrated embodiment, in response to determining that the current device settings indicate the bolus wizard is configured and enabled, theclient application108 generates a guidance GUI display908 that enables the user to input or otherwise provide indication of whether he or she would like to utilize the bolus wizard or whether he or she would like to bolus manually.
Referring now toFIG. 10, in response to selection of aGUI element912 for using the bolus wizard, theclient application108 generates an updatedguidance GUI display1008 to reflect the user objective of using the bolus wizard. In this regard, the updatedguidance GUI display1008 includes alist1010 of user actions ordered sequentially for using the bolus wizard. In this regard,FIG. 10 depicts a scenario after the user has navigated from the HomeScreen GUI display304 to the MainMenu GUI display604, with the first entry in thelist1010 for navigating to the “Home Screen” and the second entry in thelist1010 for navigating to the “Main Menu” being graphically deemphasized to reflect the current state of thedisplay326 in concert with the position of thegraphical indicia512 being updated based on the updated userinput selection location1004 to indicate the user is on the third entry in thelist1010. As illustrated, thelist1010 of actions presented on theguidance GUI display1008 instructs the user how to further navigate from the Main Menu GUI display to the Bolus Menu GUI display, into the Bolus Wizard GUI display, and from there, what inputs the user should provide and the order in which the user should provide them to achieve delivery of a bolus of fluid using the bolus wizard feature.
While the above examples describe enabling or using a feature of theinfusion device102,302, as described above, in other embodiments, theinteractive guidance process200 may be similarly employed for resolving active alerts, alarms, notifications, or other aspects of theinfusion device102,302. For example, when the initially obtained device status information indicates an active alert, theclient application108 may automatically determine the patient's objective is to resolve or understand the current alert or notification and provide a corresponding guidance GUI display that explains the sequence of user actions that may be taken to resolve the alert. That said, the guidance GUI display may also include one or more GUI elements that allow the user to change or modify the user objective from what was automatically determined by theclient application108 based on the current display status information. In a similar manner, if delivery of fluid by theinfusion device102,302 is suspended or some other default operating mode is inoperable or disable, theclient application108 may automatically determine the patient's objective is to enable or resume that particular operating mode and provide a corresponding guidance GUI display, which, in turn, may be modified or changed by the user if desired. In yet other embodiments, the when the patient's objective is to obtain general help or explanatory information regarding the GUI display currently presented by theinfusion device102, theclient application108 may provide a guidance GUI display that depicts a real-time representation of the GUI display that the pump is currently presenting with callouts, interactive labels, or the like describing what each GUI element on the pump GUI display means or does or other explanatory information regarding the current pump GUI display. Additionally, although not illustrated inFIGS. 3-10, some embodiments of theclient application108 may include a selectable GUI element outside of the list of user actions that allows the user of theclient device106,306 to initiate a remote support session as described above in the context ofFIG. 2.
FIG. 11 depicts one exemplary embodiment of aninfusion system1100 suitable for use with thepatient guidance system100 ofFIG. 1 in conjunction with theinteractive guidance process200 ofFIGS. 2-10. Theinfusion system1100 includes, without limitation, a fluid infusion device (or infusion pump)1102 (e.g.,infusion device102,302), a sensing arrangement1104 (e.g., sensing arrangement104), a command control device (CCD)1106, and acomputer1108, which could be realized as any one of thecomputing devices106,114,306 described above. For example, in one embodiment, theCCD1106 is realized as aclient device106,306 and thecomputer1108 is realized asremote device114. The components of aninfusion system1100 may be realized using different platforms, designs, and configurations, and the embodiment shown inFIG. 11 is not exhaustive or limiting. In practice, theinfusion device1102 and thesensing arrangement1104 are secured at desired locations on the body of a user (or patient), as illustrated inFIG. 11. In this regard, the locations at which theinfusion device1102 and thesensing arrangement1104 are secured to the body of the user inFIG. 11 are provided only as a representative, non-limiting, example. The elements of theinfusion system1100 may be similar to those described in U.S. Pat. No. 8,674,288, the subject matter of which is hereby incorporated by reference in its entirety.
In the illustrated embodiment ofFIG. 11, theinfusion device1102 is designed as a portable medical device suitable for infusing a fluid, a liquid, a gel, or other agent into the body of a user. In exemplary embodiments, the infused fluid is insulin, although many other fluids may be administered through infusion such as, but not limited to, HIV drugs, drugs to treat pulmonary hypertension, iron chelation drugs, pain medications, anti-cancer treatments, medications, vitamins, hormones, or the like. In some embodiments, the fluid may include a nutritional supplement, a dye, a tracing medium, a saline medium, a hydration medium, or the like.
Thesensing arrangement1104 generally represents the components of theinfusion system1100 configured to sense, detect, measure or otherwise quantify a condition of the user, and may include a sensor, a monitor, or the like, for providing data indicative of the condition that is sensed, detected, measured or otherwise monitored by the sensing arrangement. In this regard, thesensing arrangement1104 may include electronics and enzymes reactive to a biological or physiological condition of the user, such as a blood glucose level, or the like, and provide data indicative of the blood glucose level to theinfusion device1102, theCCD1106 and/or thecomputer1108. For example, theinfusion device1102, theCCD1106 and/or thecomputer1108 may include a display for presenting information or data to the user based on the sensor data received from thesensing arrangement1104, such as, for example, a current glucose level of the user, a graph or chart of the user's glucose level versus time, device status indicators, alert messages, or the like. In other embodiments, theinfusion device1102, theCCD1106 and/or thecomputer1108 may include electronics and software that are configured to analyze sensor data and operate theinfusion device1102 to deliver fluid to the body of the user based on the sensor data and/or preprogrammed delivery routines. Thus, in exemplary embodiments, one or more of theinfusion device1102, thesensing arrangement1104, theCCD1106, and/or thecomputer1108 includes a transmitter, a receiver, and/or other transceiver electronics that allow for communication with other components of theinfusion system1100, so that thesensing arrangement1104 may transmit sensor data or monitor data to one or more of theinfusion device1102, theCCD1106 and/or thecomputer1108.
Still referring toFIG. 11, in various embodiments, thesensing arrangement1104 may be secured to the body of the user or embedded in the body of the user at a location that is remote from the location at which theinfusion device1102 is secured to the body of the user. In various other embodiments, thesensing arrangement1104 may be incorporated within theinfusion device1102. In other embodiments, thesensing arrangement1104 may be separate and apart from theinfusion device1102, and may be, for example, part of theCCD1106. In such embodiments, thesensing arrangement1104 may be configured to receive a biological sample, analyte, or the like, to measure a condition of the user.
In various embodiments, theCCD1106 and/or thecomputer1108 may include electronics and other components configured to perform processing, delivery routine storage, and to control theinfusion device1102 in a manner that is influenced by sensor data measured by and/or received from thesensing arrangement1104. By including control functions in theCCD1106 and/or thecomputer1108, theinfusion device1102 may be made with more simplified electronics. However, in other embodiments, theinfusion device1102 may include all control functions, and may operate without theCCD1106 and/or thecomputer1108. In various embodiments, theCCD1106 may be a portable electronic device. In addition, in various embodiments, theinfusion device1102 and/or thesensing arrangement1104 may be configured to transmit data to theCCD1106 and/or thecomputer1108 for display or processing of the data by theCCD1106 and/or thecomputer1108.
In some embodiments, theCCD1106 and/or thecomputer1108 may provide information to the user that facilitates the user's subsequent use of theinfusion device1102. For example, theCCD1106 may provide information to the user to allow the user to determine the rate or dose of medication to be administered into the user's body. In other embodiments, theCCD1106 may provide information to theinfusion device1102 to autonomously control the rate or dose of medication administered into the body of the user. In some embodiments, thesensing arrangement1104 may be integrated into theCCD1106. Such embodiments may allow the user to monitor a condition by providing, for example, a sample of his or her blood to thesensing arrangement1104 to assess his or her condition. In some embodiments, thesensing arrangement1104 and theCCD1106 may be used for determining glucose levels in the blood and/or body fluids of the user without the use of, or necessity of, a wire or cable connection between theinfusion device1102 and thesensing arrangement1104 and/or theCCD1106.
In one or more exemplary embodiments, thesensing arrangement1104 and/or theinfusion device1102 are cooperatively configured to utilize a closed-loop system for delivering fluid to the user. Examples of sensing devices and/or infusion pumps utilizing closed-loop systems may be found at, but are not limited to, the following U.S. Pat. Nos. 6,088,608, 6,119,028, 6,589,229, 6,740,072, 6,827,702, 7,323,142, and 7,402,153, all of which are incorporated herein by reference in their entirety. In such embodiments, thesensing arrangement1104 is configured to sense or measure a condition of the user, such as, blood glucose level or the like. Theinfusion device1102 is configured to deliver fluid in response to the condition sensed by thesensing arrangement1104. In turn, thesensing arrangement1104 continues to sense or otherwise quantify a current condition of the user, thereby allowing theinfusion device1102 to deliver fluid continuously in response to the condition currently (or most recently) sensed by thesensing arrangement1104 indefinitely. In some embodiments, thesensing arrangement1104 and/or theinfusion device1102 may be configured to utilize the closed-loop system only for a portion of the day, for example only when the user is asleep or awake.
FIGS. 12-14 depict one exemplary embodiment of a fluid infusion device1200 (or alternatively, infusion pump) suitable for use as aninfusion device102,302,1102 described above in the context ofFIGS. 1-11. Thefluid infusion device1200 is a portable medical device designed to be carried or worn by a patient (or user), and thefluid infusion device1200 may leverage any number of conventional features, components, elements, and characteristics of existing fluid infusion devices, such as, for example, some of the features, components, elements, and/or characteristics described in U.S. Pat. Nos. 6,485,465 and 7,621,893. It should be appreciated thatFIGS. 12-14 depict some aspects of theinfusion device1200 in a simplified manner; in practice, theinfusion device1200 could include additional elements, features, or components that are not shown or described in detail herein.
As best illustrated inFIGS. 12-13, the illustrated embodiment of thefluid infusion device1200 includes ahousing1202 adapted to receive a fluid-containingreservoir1205. Anopening1220 in thehousing1202 accommodates a fitting1223 (or cap) for thereservoir1205, with the fitting1223 being configured to mate or otherwise interface withtubing1221 of aninfusion set1225 that provides a fluid path to/from the body of the user. In this manner, fluid communication from the interior of thereservoir1205 to the user is established via thetubing1221. The illustratedfluid infusion device1200 includes a human-machine interface (HMI)1230 (or user interface) that includeselements1232,1234 that can be manipulated by the user to administer a bolus of fluid (e.g., insulin), to change therapy settings, to change user preferences, to select display features, and the like. The infusion device also includes adisplay element1226, such as a liquid crystal display (LCD) or another suitable display element, that can be used to present various types of information or data to the user, such as, without limitation: the current glucose level of the patient; the time; a graph or chart of the patient's glucose level versus time; device status indicators; etc.
Thehousing1202 is formed from a substantially rigid material having a hollow interior1014 adapted to allow anelectronics assembly1204, a sliding member (or slide)1206, adrive system1208, asensor assembly1210, and a drivesystem capping member1212 to be disposed therein in addition to thereservoir1205, with the contents of thehousing1202 being enclosed by ahousing capping member1216. Theopening1220, theslide1206, and thedrive system1208 are coaxially aligned in an axial direction (indicated by arrow1218), whereby thedrive system1208 facilitates linear displacement of theslide1206 in theaxial direction1218 to dispense fluid from the reservoir1205 (after thereservoir1205 has been inserted into opening1220), with thesensor assembly1210 being configured to measure axial forces (e.g., forces aligned with the axial direction1218) exerted on thesensor assembly1210 responsive to operating thedrive system1208 to displace theslide1206. In various embodiments, thesensor assembly1210 may be utilized to detect one or more of the following: an occlusion in a fluid path that slows, prevents, or otherwise degrades fluid delivery from thereservoir1205 to a user's body; when thereservoir1205 is empty; when theslide1206 is properly seated with thereservoir1205; when a fluid dose has been delivered; when theinfusion pump1200 is subjected to shock or vibration; when theinfusion pump1200 requires maintenance.
Depending on the embodiment, the fluid-containingreservoir1205 may be realized as a syringe, a vial, a cartridge, a bag, or the like. In certain embodiments, the infused fluid is insulin, although many other fluids may be administered through infusion such as, but not limited to, HIV drugs, drugs to treat pulmonary hypertension, iron chelation drugs, pain medications, anti-cancer treatments, medications, vitamins, hormones, or the like. As best illustrated inFIGS. 13-14, thereservoir1205 typically includes areservoir barrel1219 that contains the fluid and is concentrically and/or coaxially aligned with the slide1206 (e.g., in the axial direction1218) when thereservoir1205 is inserted into theinfusion pump1200. The end of thereservoir1205 proximate theopening1220 may include or otherwise mate with the fitting1223, which secures thereservoir1205 in thehousing1202 and prevents displacement of thereservoir1205 in theaxial direction1218 with respect to thehousing1202 after thereservoir1205 is inserted into thehousing1202. As described above, the fitting1223 extends from (or through) theopening1220 of thehousing1202 and mates withtubing1221 to establish fluid communication from the interior of the reservoir1205 (e.g., reservoir barrel1219) to the user via thetubing1221 andinfusion set1225. The opposing end of thereservoir1205 proximate theslide1206 includes a plunger1217 (or stopper) positioned to push fluid from inside thebarrel1219 of thereservoir1205 along a fluid path throughtubing1221 to a user. Theslide1206 is configured to mechanically couple or otherwise engage with theplunger1217, thereby becoming seated with theplunger1217 and/orreservoir1205. Fluid is forced from thereservoir1205 viatubing1221 as thedrive system1208 is operated to displace theslide1206 in theaxial direction1218 toward theopening1220 in thehousing1202.
In the illustrated embodiment ofFIGS. 13-14, thedrive system1208 includes amotor assembly1207 and adrive screw1209. Themotor assembly1207 includes a motor that is coupled to drive train components of thedrive system1208 that are configured to convert rotational motor motion to a translational displacement of theslide1206 in theaxial direction1218, and thereby engaging and displacing theplunger1217 of thereservoir1205 in theaxial direction1218. In some embodiments, themotor assembly1207 may also be powered to translate theslide1206 in the opposing direction (e.g., the direction opposite direction1218) to retract and/or detach from thereservoir1205 to allow thereservoir1205 to be replaced. In exemplary embodiments, themotor assembly1207 includes a brushless DC (BLDC) motor having one or more permanent magnets mounted, affixed, or otherwise disposed on its rotor. However, the subject matter described herein is not necessarily limited to use with BLDC motors, and in alternative embodiments, the motor may be realized as a solenoid motor, an AC motor, a stepper motor, a piezoelectric caterpillar drive, a shape memory actuator drive, an electrochemical gas cell, a thermally driven gas cell, a bimetallic actuator, or the like. The drive train components may comprise one or more lead screws, cams, ratchets, jacks, pulleys, pawls, clamps, gears, nuts, slides, bearings, levers, beams, stoppers, plungers, sliders, brackets, guides, bearings, supports, bellows, caps, diaphragms, bags, heaters, or the like. In this regard, although the illustrated embodiment of the infusion pump utilizes a coaxially aligned drive train, the motor could be arranged in an offset or otherwise non-coaxial manner, relative to the longitudinal axis of thereservoir1205.
As best shown inFIG. 14, thedrive screw1209 mates withthreads1402 internal to theslide1206. When themotor assembly1207 is powered and operated, thedrive screw1209 rotates, and theslide1206 is forced to translate in theaxial direction1218. In an exemplary embodiment, theinfusion pump1200 includes asleeve1211 to prevent theslide1206 from rotating when thedrive screw1209 of thedrive system1208 rotates. Thus, rotation of thedrive screw1209 causes theslide1206 to extend or retract relative to thedrive motor assembly1207. When the fluid infusion device is assembled and operational, theslide1206 contacts theplunger1217 to engage thereservoir1205 and control delivery of fluid from theinfusion pump1200. In an exemplary embodiment, theshoulder portion1215 of theslide1206 contacts or otherwise engages theplunger1217 to displace theplunger1217 in theaxial direction1218. In alternative embodiments, theslide1206 may include a threadedtip1213 capable of being detachably engaged withinternal threads1404 on theplunger1217 of thereservoir1205, as described in detail in U.S. Pat. Nos. 6,248,093 and 6,485,465, which are incorporated by reference herein.
As illustrated inFIG. 13, theelectronics assembly1204 includescontrol electronics1224 coupled to thedisplay element1226, with thehousing1202 including atransparent window portion1228 that is aligned with thedisplay element1226 to allow thedisplay1226 to be viewed by the user when theelectronics assembly1204 is disposed within the interior1014 of thehousing1202. Thecontrol electronics1224 generally represent the hardware, firmware, processing logic and/or software (or combinations thereof) configured to control operation of themotor assembly1207 and/ordrive system1208. Whether such functionality is implemented as hardware, firmware, a state machine, or software depends upon the particular application and design constraints imposed on the embodiment. Those familiar with the concepts described here may implement such functionality in a suitable manner for each particular application, but such implementation decisions should not be interpreted as being restrictive or limiting. In an exemplary embodiment, thecontrol electronics1224 includes one or more programmable controllers that may be programmed to control operation of theinfusion pump1200.
Themotor assembly1207 includes one or moreelectrical leads1236 adapted to be electrically coupled to theelectronics assembly1204 to establish communication between thecontrol electronics1224 and themotor assembly1207. In response to command signals from thecontrol electronics1224 that operate a motor driver (e.g., a power converter) to regulate the amount of power supplied to the motor from a power supply, the motor actuates the drive train components of thedrive system1208 to displace theslide1206 in theaxial direction1218 to force fluid from thereservoir1205 along a fluid path (includingtubing1221 and an infusion set), thereby administering doses of the fluid contained in thereservoir1205 into the user's body. Preferably, the power supply is realized one or more batteries contained within thehousing1202. Alternatively, the power supply may be a solar panel, capacitor, AC or DC power supplied through a power cord, or the like. In some embodiments, thecontrol electronics1224 may operate the motor of themotor assembly1207 and/ordrive system1208 in a stepwise manner, typically on an intermittent basis; to administer discrete precise doses of the fluid to the user according to programmed delivery profiles.
Referring toFIGS. 12-14, as described above, theuser interface1230 includes HMI elements, such asbuttons1232 and adirectional pad1234, that are formed on a graphic keypad overlay1231 that overlies akeypad assembly1233, which includes features corresponding to thebuttons1232,directional pad1234 or other user interface items indicated by the graphic keypad overlay1231. When assembled, thekeypad assembly1233 is coupled to thecontrol electronics1224, thereby allowing theHMI elements1232,1234 to be manipulated by the user to interact with thecontrol electronics1224 and control operation of theinfusion pump1200, for example, to administer a bolus of insulin, to change therapy settings, to change user preferences, to select display features, to set or disable alarms and reminders, and the like. In this regard, thecontrol electronics1224 maintains and/or provides information to thedisplay1226 regarding program parameters, delivery profiles, pump operation, alarms, warnings, statuses, or the like, which may be adjusted using theHMI elements1232,1234. In various embodiments, theHMI elements1232,1234 may be realized as physical objects (e.g., buttons, knobs, joysticks, and the like) or virtual objects (e.g., using touch-sensing and/or proximity-sensing technologies). For example, in some embodiments, thedisplay1226 may be realized as a touch screen or touch-sensitive display, and in such embodiments, the features and/or functionality of theHMI elements1232,1234 may be integrated into thedisplay1226 and theHMI1230 may not be present. In some embodiments, theelectronics assembly1204 may also include alert generating elements coupled to thecontrol electronics1224 and suitably configured to generate one or more types of feedback, such as, without limitation: audible feedback; visual feedback; haptic (physical) feedback; or the like.
Referring toFIGS. 13-14, in accordance with one or more embodiments, thesensor assembly1210 includes aback plate structure1250 and aloading element1260. Theloading element1260 is disposed between the cappingmember1212 and abeam structure1270 that includes one or more beams having sensing elements disposed thereon that are influenced by compressive force applied to thesensor assembly1210 that deflects the one or more beams, as described in greater detail in U.S. Pat. No. 8,474,332, which is incorporated by reference herein. In exemplary embodiments, theback plate structure1250 is affixed, adhered, mounted, or otherwise mechanically coupled to thebottom surface1238 of thedrive system1208 such that theback plate structure1250 resides between thebottom surface1238 of thedrive system1208 and thehousing cap1216. The drivesystem capping member1212 is contoured to accommodate and conform to the bottom of thesensor assembly1210 and thedrive system1208. The drivesystem capping member1212 may be affixed to the interior of thehousing1202 to prevent displacement of thesensor assembly1210 in the direction opposite the direction of force provided by the drive system1208 (e.g., the direction opposite direction1218). Thus, thesensor assembly1210 is positioned between themotor assembly1207 and secured by the cappingmember1212, which prevents displacement of thesensor assembly1210 in a downward direction opposite the direction ofarrow1218, such that thesensor assembly1210 is subjected to a reactionary compressive force when thedrive system1208 and/ormotor assembly1207 is operated to displace theslide1206 in theaxial direction1218 in opposition to the fluid pressure in thereservoir1205. Under normal operating conditions, the compressive force applied to thesensor assembly1210 is correlated with the fluid pressure in thereservoir1205. As shown,electrical leads1240 are adapted to electrically couple the sensing elements of thesensor assembly1210 to theelectronics assembly1204 to establish communication to thecontrol electronics1224, wherein thecontrol electronics1224 are configured to measure, receive, or otherwise obtain electrical signals from the sensing elements of thesensor assembly1210 that are indicative of the force applied by thedrive system1208 in theaxial direction1218.
FIG. 15 depicts an exemplary embodiment of amedical device1500 suitable for use as theinfusion device102,302,1102,1200 in conjunction with theinteractive guidance process200 ofFIGS. 2-10. The illustratedmedical device1500 includes, without limitation, acontrol module1502, acommunications interface1504, adisplay device1506, auser interface1508, and a data storage element (or memory)1510. Thecontrol module1502 is coupled to thecommunications interface1504, thememory1510, thedisplay device1506, and the memory1006, and thecontrol module1502 is suitably configured to support the operations, tasks, and/or processes described herein. It should be understood thatFIG. 15 is a simplified representation of amedical device1500 for purposes of explanation and is not intended to limit the subject matter described herein in any way.
Thecommunications interface1504 generally represents the hardware, circuitry, logic, firmware and/or other components of themedical device1500 that are coupled to thecontrol module1502 and configured to support communications sessions between themedical device1500 and an auxiliary device (e.g.,devices106,306,1106) via a network (e.g., network110). In this regard, thecommunications interface1504 may include or otherwise be coupled to one or more transceiver modules capable of supporting wireless communications. In other embodiments, thecommunications interface1504 may be configured to support wired communications to/from the auxiliary device.
Thedisplay device1506 may be realized as any sort of electronic display capable of graphically displaying information or other data associated with operation of themedical device1500 under control of thecontrol module1502. Theuser interface1508 generally includes one or more user input devices configured to allow a patient or other user to interact with themedical device1500 and the GUI displays presented on thedisplay device1506. Depending on the embodiment, theuser interface1508 may include or be realized as one or more of the following user input devices: a keypad, touchpad, keyboard, mouse, touch panel (or touchscreen), joystick, knob, line select key or another suitable device adapted to receive input from a user, such as a microphone, audio transducer, audio sensor, or another audio input device.
Thecontrol module1502 generally represents the hardware, circuitry, logic, firmware and/or other component of themedical device1500 configured to determine dosage commands for operating medical device1500 (e.g., by operating an actuation arrangement to deliver fluid to the body of a patient) and perform various additional tasks, operations, functions and/or operations described herein. For example, in exemplary embodiments,control module1502 implements or otherwise executes an application that supports establishing communications sessions with a guidance application on an auxiliary device and automatically pushing or uploading status information, settings information, and the like to the guidance application asynchronously or in another substantially real-time manner. Depending on the embodiment, thecontrol module1502 may be implemented or realized with a general purpose processor, a microprocessor, a controller, a microcontroller, a state machine, a content addressable memory, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. In this regard, the steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in firmware, in a software module executed by thecontrol module1502, or in any practical combination thereof. In exemplary embodiments, thecontrol module1502 includes or otherwise accesses the data storage element ormemory1510, which may be realized using any sort of non-transitory computer-readable medium capable of storing programming instructions for execution by thecontrol module1502. The computer-executable programming instructions, when read and executed by thecontrol module1502, cause thecontrol module1502 to implement or otherwise generate the guidance communications application and perform tasks, operations, functions, and processes described herein.
In exemplary embodiments described herein, thememory1510 may also store or otherwise maintain settings information for themedical device1500 including, but not limited to, data indicating which modes or features of themedical device1500 have been configured, data indicating which modes or features of themedical device1500 have not been configured, data indicating which modes or features of themedical device1500 are enabled or activated, data indicating which modes or features of themedical device1500 have been disabled or deactivated, variables, parameters, or other values that have been programmed, configured, entered, or otherwise established for use by a particular mode or feature of themedical device1500, and any patient-specific variables, parameters, or other values that have been programmed, configured, entered or otherwise established for use by a particular mode or feature of themedical device1500. In this regard, the settings information may include configuration data for an operating mode of themedical device1500, configuration data for a feature of themedical device1500, or values or data for other patient-specific settings, parameters, or variables. For example, for an infusion device, the settings information could include a value for a basal rate, a patient-specific insulin sensitivity factor, a patient-specific insulin-to-carbohydrate ratio, a patient-specific total daily insulin requirement, or the like.
As described above in the context ofFIGS. 2-10, in exemplary embodiments, in response to establishing a communications session with an auxiliary device via thecommunications interface1504, the control module1502 (or the guidance communications application executing thereon) is configured to identify or otherwise obtain status information characterizing the current state of thedisplay device1506 and theuser interface1508 and the settings information stored by thememory1510 and transmit the settings information and the status information to the auxiliary device via the communications session. Thereafter, in response to receiving a user input via theuser interface1508, thecontrol module1502 automatically identifies or obtains updated status information characterizing the updated state of thedisplay device1506 and theuser interface1508 responsive to the user input and automatically pushes, uploads, or otherwise transmits the updated status information to the auxiliary device, which, in turn, allows the auxiliary device to dynamically update any guidance information presented to a user at the auxiliary device. For example, as described above, the guidance information may include a sequence of one or more user actions with respect to theuser interface1508 for operating themedical device1500 to deliver a bolus of fluid, configuring or enabling an operating mode or feature of the medical device1500 (e.g., a closed-loop operating mode, a bolus wizard feature, or the like), programming patient-specific variables, parameters, or other settings into themedical device1500, and/or the like, with the sequence of user actions being dynamically updated to reflect or distinguish those user actions that have already been performed.
For the sake of brevity, conventional techniques related to glucose sensing and/or monitoring, glucose regulation, communications networks, sessions, and security, graphical user interfaces, menus and navigation thereof, and other functional aspects of the subject matter may not be described in detail herein. In addition, certain terminology may also be used in the herein for the purpose of reference only, and thus is not intended to be limiting. For example, terms such as “first”, “second”, and other such numerical terms referring to structures do not imply a sequence or order unless clearly indicated by the context. The foregoing description may also refer to elements or nodes or features being “connected” or “coupled” together. As used herein, unless expressly stated otherwise, “coupled” means that one element/node/feature is directly or indirectly joined to (or directly or indirectly communicates with) another element/node/feature, and not necessarily mechanically.
While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. For example, the subject matter described herein is not necessarily limited to the infusion devices and related systems described herein. Moreover, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope defined by the claims, which includes known equivalents and foreseeable equivalents at the time of filing this patent application. Accordingly, details of the exemplary embodiments or other limitations described above should not be read into the claims absent a clear intention to the contrary.