Computing architecture for assuring the provenance of medication therapy related parameters, and related systems, methods and devices

A mobile computing device for providing medication therapy recommendations includes a secure execution environment having one or more services executing therein. One service of the one or more services is configured to establish a secure user interaction process at the mobile computing device. The mobile computing device includes a normal execution environment having a medication therapy application executing therein. The medication therapy application is configured to determine at least one medication delivery instruction, request confirmation of the delivery instruction using the secure user interaction process, and provide certified medication delivery instructions to a communications interface configured for communication with a medication delivery unit responsive to a confirmation result. The confirmation result is received, at least in part, responsive to the secure user interaction process.

1. 11. A mobile computing device for providing medication therapy recommendations, comprising: a secure execution environment having at least one trusted authentication service that executes therein, the secure execution environment including a secure kernel configured to handle commands and access isolated hardware resources including a processor, memory and device I/O, wherein the at least one trusted authentication service is configured to establish a secure user interaction process at the mobile computing device via a rich operating system different than a mobile operating system of the mobile computing device; a normal execution environment having a medication therapy application executed therein via the mobile operating system, wherein the medication therapy application is configured to: determine at least one medication delivery instruction; responsive to determining at least one medication delivery instruction, send a request for a trusted user confirmation to the at least one trusted authentication service of the mobile computing device, wherein, responsive to receiving the request for the trusted user confirmation, the at least one trusted authentication service is configured to: initiate the secure user interaction process, the process configured to: prevent the normal execution environment from receiving, and allow the secure execution environment to receive, a user input via a user interface of the mobile computing device; while the normal execution environment is prevented from receiving a user input via the user interface, present a request, via the user interface, for a user interaction with the mobile device as a trusted user confirmation that confirms the at least one medication delivery instruction; and responsive to receiving the trusted user confirmation, generate and provide a signature and success message to the medication therapy application, wherein, responsive to receiving the signature and success message, the medication therapy application is configured to provide certified medication delivery instructions to a medication delivery unit; wherein, responsive to receiving the certified medication delivery instructions, the medication delivery unit is configured to: authenticate the signature using one or more cryptographic keys stored on the medication delivery unit; and provide one or more delivery commands to a medication delivery mechanism responsive to successful authentication of the signature.
2. 22. The mobile computing device of claim 1, wherein the medication delivery unit comprises an insulin pump.
3. 33. The mobile computing device of claim 1, wherein the medication delivery unit comprises an insulin pen.

CROSS-REFERENCE TO RELATED APPLICATION
This application claims the benefit under 35 U.S.C. § 119 (e) of U.S. Provisional Patent Application Ser. No. 62/669,250, filed May 9, 2018, the disclosure of which is hereby incorporated herein in its entirety by this reference.


TECHNICAL FIELD
This disclosure generally relates to medication delivery systems, and more specifically, some embodiments relate to a mobile computing device that may setup a secure, trusted, process for a user to confirm medication therapy parameters at the mobile computing device and certify that a medication therapy parameter was confirmed using such a process.
BACKGROUND
Infusion pumps can be used to deliver fluids, such as medications, into a patient's body in a controlled manner and/or upon demand. Infusion pumps can be implanted, transcutaneous, or external. Infusion pumps be programmed to provide a continuous or near continuous deliver of fluid and/or programmed to deliver the fluid according to a control algorithm. Infusion pumps can also be used by a user (e.g., patient, caregiver, or healthcare professional) to deliver boluses of medication upon demand.
There are many different types of infusion pumps, which are used for a variety of purposes and in a variety of environments. Infusion pumps may be capable of delivering fluids in large or small amounts, and may be used to deliver nutrients or medications-such as insulin or other hormones, antibiotics, chemotherapy drugs, and pain relievers. Infusion pumps may operate “open loop” (e.g., operation is at least partially at the discretion of a user), and “closed loop” (e.g., the measuring, adjustment of parameters, and insulin delivery occurs without user intervention, i.e., at the discretion of the control system). Infusion pumps typically have user interfaces right on the infusion pump or come with a specialized remote communication device specifically for that infusion pump, thus the act of programming the infusion pump or requesting a bolus of medication when in public can result in unwanted attention on the patient. Additionally, specialized devices can burden a patient by requiring that the patient carry around an extra device on top of the devices that the user already carries around anyways.



BRIEF DESCRIPTION OF THE DRAWINGS
The purpose and advantages of the various embodiments of the disclosure will be apparent to one of ordinary skill in the art from the detailed description in conjunction with the following appended figures:
FIG. 1 shows an embodiment of an insulin therapy system configured to implement embodiments of the disclosure;
FIG. 2 shows an embodiment of a system architecture configured to implement the trusted authentication services FIG. 1;
FIGS. 3A and 3B show an embodiment where the insulin management application sends an insulin delivery instruction and a signature to the insulin delivery unit;
FIGS. 4A and 4B show an embodiment where the trusted authentication service sends the signature directly to the insulin delivery unit using a trusted communication process;
FIGS. 5A and 5B show an embodiment where the insulin delivery unit requests the signature from the trusted authentication service;
FIG. 6 shows a flowchart of a confirmation process executed in the TEE, according to embodiments of the disclosure;
FIG. 7 shows the insulin therapy system in use by a user, according to embodiments of the disclosure;
FIGS. 8A-8D show exemplary user interfaces for an insulin therapy application that may be used to calculate a bolus, according to embodiments of the disclosure;
FIG. 9A shows a use case where methods, devices, and systems provided herein may only require the TEE to confirm the delivery instruction if the user elects to deliver a bolus other than a recommended bolus, according to an embodiment of the disclosure;
FIG. 9B shows an example of a recommendation provided by the insulin delivery unit to the mobile computing device to bolus in response to a trend toward higher blood glucose levels that may trigger the confirmation process shown in FIG. 9A, according to an embodiment of the disclosure;
FIG. 10 shows a therapy management system where the user interfaces with a wearable device is configured to be taken over by the trusted authentication service, and permit a user to provide confirmation of a bolus dose, according to an embodiment of the disclosure;
FIG. 11 shows an example of a user interface where the user, instead of entering the amount of carbs selects a meal or carbohydrate amount associated with a meal-type that the user entered, according to an embodiment of the disclosure; and
FIGS. 12A and 12B show an embodiment where a trusted authentication service is used to confirm user-specified parameters that would affect medication therapy or medication delivery recommendations, according to an embodiment of the disclosure.



DETAILED DESCRIPTION
The following description provides specific details to provide a thorough description of various embodiments of the invention. However, one of ordinary skill in the art will understand that the disclosed embodiments may be practiced without using these specific details. Indeed, the disclosed embodiments may be practiced in conjunction with conventional systems and methods used in the industry. In addition, only those elements helpful to understand and enable one of ordinary skill in the art to practice the disclosed embodiments are described in detail. One of ordinary skill in the art will recognize that some elements not described herein but, using various conventional method components and acts, would be in accord with the embodiments of this disclosure.
The following description may include examples to help enable one of ordinary skill in the art to practice the disclosed embodiments. The use of the terms “exemplary,” “by example,” “for example,” “e.g.,” and “such as” means that the related description is explanatory and though the scope of the disclosure is intended to encompass the recited examples and their legal equivalents. The use of such terms is not intended to limit the scope of an embodiment or this disclosure to the specified components, steps, features, functions, arrangement of components, or the like. Moreover, the use of such terms does not indicate or imply that the related description comprises, or is, a preferred embodiment.
Any drawings accompanying this disclosure are for illustrative purposes only, and no scale is intended unless specifically indicated. Elements common among figures may retain the same numerical designation; however, the similarity in numbering does not mean that the structures or components are necessarily identical in size, composition, configuration, or any other property.
It will be readily understood that the components of the embodiments as generally described herein and illustrated in the drawing could be arranged and designed in a wide variety of different configurations. Thus, the following description of various embodiments is not intended to limit the scope of the present disclosure, but is merely representative of various embodiments. While the various aspects of the embodiments may be presented in drawings, the drawings are not necessarily drawn to scale unless specifically indicated.
As noted, above, specific implementations shown and described are only examples and should not be construed as the only way to implement the present disclosure unless specified otherwise herein. Elements, circuits, and functions may be shown in block diagram form in order not to obscure the present disclosure in unnecessary detail. Block definitions and partitioning of logic between various blocks is/are examples of a specific implementation. It will be readily apparent to one of ordinary skill in the art that the present disclosure may be practiced by numerous other partitioning solutions. For the most part, details concerning timing considerations and the like have been omitted where such details are not necessary to obtain a complete understanding of the present disclosure and are within the abilities of persons of ordinary skill in the relevant art.
Many of the functional units described in this specification may be illustrated, described or labeled as logic, modules, engines, threads, or other segregations of programming code, to more particularly emphasize their implementation independence in accomplishing the features, functions, tasks or steps that are generally described herein. The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be at least partially implemented or performed with a general purpose processor, a special 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.
The functional units may be implemented using software or firmware, stored on a computer-readable storage medium, in system memory, or a combination thereof for execution by various types of processors. Some examples of languages that may be used to write the software include, but are not limited to, an extensible markup language, C, C++, JAVA, MATLAB, MINITAB, EXPRESS, DRAKON, DYNA, PYTHON, MOOSE, and RUBY. The software programs may be further translated into machine language or virtual machine instructions and stored in a program file in that form. The program file may then be stored on or in one or more of the articles of manufacture. Although enabling software might be “written on” a disc, “embodied in” an integrated circuit, “carried over” a communications circuit, “stored in” a memory chip, or “loaded in” a cache memory, it will be appreciated that, for the purposes of this application, the software is referred to simply as being “in” or “on” the computer readable medium. Thus, the terms “in” or “on” are intended to encompass the above mentioned and all equivalent and possible ways in which software can be associated with a computer readable medium.
In the case of a general-purpose computer, these logic and modules may be embodied in software classes and applications executed by processor cores, and while the modules are executing the general-purpose computer may be thought of as a special purpose computer or a specific purpose computer. The logic and modules may also relate to specific purpose hardware, including the firmware and machine code, controlling its operation. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as a thread, object, procedure, or function. Nevertheless, the executable code of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
A module of executable code may comprise a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several storage or memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. Where a module or portions of a module are implemented in software, the software portions are stored on one or more physical devices, which are referred to herein as computer-readable media.
In some embodiments, the software portions are stored in a non-transitory state such that the software portions or representations thereof, persist in the same physical location for a period of time. Additionally, in some embodiments, the software portions are stored on one or more non-transitory storage mediums, which include hardware elements capable of storing non-transitory states and/or signals representative of the software portions, even though other portions of the non-transitory storage mediums may be capable of altering and/or transmitting the signals. Examples of non-transitory storage mediums are flash memory and certain types of random-access memory (RAM). Another example of a non-transitory storage medium includes a read-only memory (ROM) which can store signals and/or states representative of the software portions for a period of time. However, the ability to store the signals and/or states is not diminished by further functionality of transmitting signals that are the same as, or representative of, the stored signals and/or states. For example, a processor may access the ROM to obtain signals that are representative of the stored signals and/or states to execute the corresponding software instructions.
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, such as 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. A general-purpose computer including a processor is considered a special-purpose computer when the general-purpose computer is configured to execute computing instructions (e.g., software code) related to embodiments of the present disclosure.
The embodiments disclosed herein may be described in terms of a process that is depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe operational acts as a sequential process, many of these acts can be performed in another sequence, in parallel, or substantially concurrently. In addition, the order of the acts may be rearranged. A process may correspond to a method, a thread, a function, a procedure, a subroutine, a subprogram, etc. Furthermore, the methods disclosed herein may be implemented in hardware, software, or both. If implemented in software, the functions may be stored or transmitted as one or more instructions or code on computer-readable media. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
Various embodiments described herein may be described as implemented in or by a “computer,” “computing system,” or a “computing platform,” which are to be understood to include at least one non-transitory computer-readable medium and at least one processing unit. In general, the storage medium will store, at one time or another, at least portions of an executable program code, and a processor(s) will execute one or more of the instructions included in that executable program code.
It will be appreciated that the term “executable program code” and the term “software” mean substantially the same thing for the purposes of this description. It is not necessary to the practice of the various embodiments described herein that the storage medium and the processing unit be physically located in the same place. That is to say, it is foreseen that the processor and the memory might be distributed among physical pieces of equipment or even in geographically distinct locations. One of ordinary skill in the art will appreciate that “media,” “medium,” “storage medium,” “computer-readable media,” or “computer-readable medium” as used herein, may include a diskette, a magnetic tape, a digital tape, a compact disc, an integrated circuit, a ROM, a CD, DVD, Blu-Ray, a cartridge, flash memory, a PROM, a RAM, a memory stick or card, or any other non-destructive storage medium useable by computers, including those that are re-writable.
Although some insulin therapy systems have been designed and contemplated that use commercially available smartphones to send delivery instructions and other therapy parameters to insulin infusion pumps (referred to herein as simply an “insulin pump”), these smartphones may also be used to download third-party software of unknown provenance. The third-party software might be malware, render the smartphone susceptible to malware, or otherwise have security holes that renders the smartphone susceptible to cyber threats. Whether malware or buggy software, either might render a smartphone vulnerable to processes that cause it to send incorrect or unintended medication delivery instructions to the infusion pump controller, for example by interfering with calculations related to therapy management, making unauthorized changes to therapy parameters, hijacking the medication delivery instruction process, or causing a smartphone to send erroneous medication delivery instructions.
One way to compensate for the possibility of an erroneous delivery instruction is to have a user confirm a recommendation and delivery amount before it is sent. However, there is still the possibility that malicious software hijacked or interfered with the confirmation process.
Accordingly, there is a need for methods, systems, and devices that enable a mobile computing device that is otherwise able to download third-party software of unknown provenance to provide therapy related instructions (e.g., medication delivery instructions, user-specified therapy parameters, etc., and also referred to herein as “insulin therapy instructions”) to a medication delivery device, where the medication device is assured the instructions were confirmed by a user. Further, in the case of a user confirmation, there is a need for methods, systems, and devices that provide additional confidence that a user, and not a malicious process, confirmed the therapy related instructions.
This disclosure describes, generally, systems and methods to provide a secure, trusted, user driven confirmation process at a mobile computing device for therapy related instructions, and provide assurances to a medication delivery device that receives the therapy related instructions that the instructions were confirmed by a user and, more specifically, were confirmed by user-action at the mobile computing device.
This disclosure also describes, generally, embodiments of computing architectures configured to implement the methods described, above. In some embodiments, computing architectures are configured to provide trusted medication therapy related instructions (e.g., medication delivery instructions, requests to change therapy parameters, etc.) from a mobile computing device (e.g., a smartphone, a tablet, etc.) to a medication delivery device (e.g., an insulin infusion pump). In particular, the computing architectures (and associated techniques, devices, hardware, and systems) enable a user to confirm the therapy related instructions (e.g., an instruction to deliver a bolus of insulin) using a user interface of a mobile computing device (or a wearable device connected to the mobile computing device), and certify (i.e., provide assurances) that a user confirmed a medication delivery instruction.
Some embodiments of computing architectures include a trusted execution environment (TEE) that enables a rich execution environment (REE) that makes available one or more trusted services to a therapy management application executing in an open (i.e., normal) execution environment within the computing architecture.
Using an example of medication delivery instructions determined at a therapy management application at the mobile computing device, a trusted authentication service may receive a request from a therapy management application related to, e.g., a medication delivery instruction intended for a medication delivery unit. In one embodiment, the message may include a text string that is in a format understandable to a user, for example, including a medication dose amount in units familiar to a user. In response to receiving the request, the TEE may take over a user interface and display and present a prompt to a user to confirm the medication delivery instructions. If the user confirms the medication delivery instruction, the trusted authentication service sends a confirmation message to the therapy management application together with a signature (e.g., a message hashed using a private key associated with the trusted service) that certifies the process by which the user confirmed the delivery instruction at the mobile computing device, and, more generally, provides assurances to the medication delivery device that the insulin delivery instruction was confirmed by user action.
The mobile device may send the medication delivery instructions to a medication delivery device (e.g., insulin pump) and a medication delivery controller verifies the signature. In one embodiment, the delivery controller verifies the signature using a previously provisioned public key associated with the TEE at the mobile computing device. Upon verification of the signature, the insulin pump controller executes the medication delivery instruction.
While some therapy related instructions are described herein in terms of a human understandable format (e.g., a dose amount), the delivery instructions that are executed by a control system may be provided such human understandable format (which the control system translates), in the form of a process variable or set-points, a range for a process variable, control actions, or the like. A control system may be configured to adjust its control actions responsive to the process variable or set-points.
While some embodiments and examples described in this disclosure relate to insulin therapies and insulin delivery, one of ordinary skill in the art would appreciate that the principles of the present disclosure are not limited to any specific type of insulin (e.g., rapid acting, long acting, or a mixture of the two), nor limited to insulin delivery or insulin therapy, more generally. One of ordinary skill in the art would also appreciate that the principles of the present disclosure are applicable to medication delivery and medication therapies, more generally.
Further, the embodiments of the disclosure are not limited to a specific type of medication delivery assembly or technique, and medication delivery includes injection type delivery, aerosolized delivery (e.g., inhaled), and intravenous delivery, and includes autonomous (e.g., an infusion-pump based closed-sloop delivery system), semi-autonomous (e.g., an infusion-pump open-loop based delivery system), and fully open loop systems (e.g., insulin pens, insulin inhalers).
FIG. 1 shows an embodiment of an insulin therapy system 100 configured to implement embodiments of the disclosure. An insulin delivery unit 110 is configured to control the automated delivery of insulin by delivery mechanism 120 to a patient 130. The patient 130 may have an optional on-body glucose sensor 140 (such as a continuous glucose monitor or a blood glucose monitor) that periodically provides blood glucose levels of the patient 130 to a delivery controller 116 of the insulin delivery unit 110. The delivery controller 116 may be configured to use the blood glucose levels as well as other environmental information (e.g., pump status, physiological disturbance information, etc.) to continuously make retrospective-based, risk-based, and/or fault-based adjustments for the dosing of insulin at the patient 130 and send control commands 117 to the delivery mechanism based on such adjustments. The insulin delivery unit 110 may be configured for closed-loop autonomous insulin delivery or open-loop semi-autonomous insulin delivery.
In one embodiment, the delivery mechanism 120 may be an infusion pump, and in one embodiment may include an infusion catheter adapted to subcutaneously deliver insulin under the skin of a patent 130 using an infusion set at an infusion site. In other embodiments, an insulin delivery unit can be or also include insulin pens, insulin syringes, and insulin inhalers.
In some embodiments, the blood glucose data based on measurements by the glucose sensor 140 may be provided to an insulin management application 152 executing on a mobile computing device 150 by the insulin delivery unit 110 or directly by the glucose sensor 140. The mobile computing device may be a smartphone or tablet and may be configured for wireless or wired communication with one or more of the insulin delivery unit 110 and glucose sensor 140, for example, by way of a protocol defined according to Wi-Fi, Bluetooth, Bluetooth Low Energy, and Near Field Communication. The insulin management application 152 may be configured to perform bullous determinations based on the received blood glucose data.
The mobile computing device 150 may also include one or more trusted authentication service 154 that, as described below, are configured to provide services to the insulin management application 152.
Calculations and adjustments for automated insulin delivery are described, generally, in U.S. Patent Publication No. 2017/0332952, published Nov. 23, 2017, and entitled “INSULIN DELIVERY SYSTEM AND METHODS WITH RISK BASED SET POINTS,” the entire contents and disclosure of which are hereby incorporated herein by this reference.
In various embodiments, the user 160 and patient 130 may be the same person. However, the disclosure and embodiments described herein are not so limited. The user 160 may be a patient, a care giver, a patent, a clinician, or another medical service provider. The user 160 may also be a software application executing on a computing device or the cloud, which provides a therapy monitoring service.
FIG. 2 shows an embodiment of a system architecture 200 configured to implement the embodiments of trusted authentication services described herein, including the trusted authentication service 154 executing at the mobile computing device 150 of FIG. 1. The system architecture 200 includes a normal execution environment 210 and a rich execution environment (REE) 230. The normal execution environment 210 provides an environment for the therapy management application 212 (e.g., insulin management application 152) and applications of unknown provenance to execute. The mobile operating system 214 also executes within the normal execution environment 210, and the mobile OS kernel 216 provides the therapy management application 212 access to the resources of the execution environment 220, namely, the memory 222, processor 224, and device I/O 225. The device I/O 225 may be coupled to various hardware device components 250, for example, a display, speakers, wireless communication equipment, storage, etc.
The trusted execution environment (TEE) 240 includes a TEE processor 244, TEE memory 242, and TEE device I/O 246 that are isolated from the components of the normal execution environment 220. The TEE processor 244 may be secure cores of a main processor that includes processor 224, a separate microprocessor, or a virtualized instance of a main processor. In various embodiments, the TEE processor 244, TEE memory 242, and TEE device I/O 246 may be isolated from the rest of the system architecture 200, for example, using memory and I/O protection mechanisms supported by hardware.
A secure kernel 238 may be configured to access the TEE 240, and a rich operating system 236 may be configured to make system calls to the secure kernel 238, for example, using an application programming interface of the secure kernel 238. The rich operating system 236 enables further isolation of the TEE 240 and its hardware and software security resources from the mobile operating system 214 and applications executing in the normal execution environment 210. The rich operating system 236 may be part of a rich execution environment 230 that runs on top of the TEE 240, and may include trusted authentication service 232, cryptography service 234, and the secure kernel 238, mentioned above. Various trusted applications may execute in the REE 230, including applications that provide the trusted authentication service 232 and cryptography service 234, as well as other services not shown.
The therapy management applications 212 may access services provided within the REE 230 by way of the REE service(s) API(s) 218. These API's provide a limited interface for the therapy management application 212 to pass messages to, and receive messages from, services executing at the REE 230. The limited interface may be limited in terms of software, and also limited in terms of hardware isolation.
During the assembly of the insulin pump, in a controlled manufacturing environment, a number of cryptographic keys (e.g., private/public key pairs associated with the insulin delivery unit) may be loaded onto the insulin delivery unit 110 that allow the insulin delivery unit 110 to both verify authenticity of messages that it sends/receives and encrypt/decrypt messages that it sends/receives. In one embodiment, cryptographic keys are stored in ROM 112 (e.g., key ROM 112). These keys may be provided to the mobile computing device 150, an insulin management application 152 and/or one or more of the trusted authentication service 232. Further, during a provisioning process, the insulin delivery unit 110 may receive public keys from the mobile computing device and the TEE operating at the mobile computing device 150. In some cases, public/private key pairs may be associated with specific applications, for example, a therapy management application or a trusted authentication service.
Various examples of insulin therapies that incorporate a user confirmation according to a secure confirmation process established by the trusted authentication service implemented by insulin therapy system 100 and system architecture 200 are shown in FIGS. 3A, 3B, 4A, 4B, 5A, 5B, 12A and 12B. The processes may be initiated, for example, after a user indicates a meal, exercise, or another event that might affect a patient's blood glucose levels. By way of a user interface, the user may enter, for example, the number of grams of carbohydrates that the patient intends to eat and estimates about the patient's physiology. In one embodiment, the system may receive an indication that a user requested that the system provide a recommended bolus of insulin to account for the meal (i.e., changes in blood glucose due to the carbohydrate intake), in another embodiment, the system may calculate the recommendation without a user request (e.g., automatically responsive to therapy data received from the insulin delivery unit). The insulin management application 152 calculates insulin delivery instructions, and creates a recommendation(s) based on the instructions. In some embodiments the insulin management application 152 presents the recommendation(s) to the user 160 at a user interface and the user may confirm the recommendation or, if there are options, select an option, at the user interface.
Responsive to the input received at the user interface, the insulin management application 152 sends a request for a trusted user confirmation to the trusted authentication service 154. In one embodiment, the insulin management application 152 requests trusted user confirmation automatically. In another embodiment, the insulin management application 152 requests trusted user confirmation if the user confirmation includes a change to a recommended insulin delivery instructions (e.g., the user provides a different dose amount). The request may include a text string with a dose amount or some other format understandable to a user.
Responsive to the request, the trusted authentication service 154 establishes a secure user interaction process at the mobile computing device 150. In one embodiment, the trusted authentication service 154 exerts control over the display 156 and one or more hardware inputs of the mobile computing device 150, and presents the text string at the display along with instructions for a user action to confirm the instruction that includes manipulating the controlled hardware inputs. In one embodiment, the user may push a hardware button, such as the power button, that is monitored by the trusted authentication service 154 to provide the requested user action. In one embodiment, the confirmation instructions may include a user action conditions. For example, a user action condition may be a timing requirement for the user to manipulate the hardware buttons, such as asserting the power button hardware input for 2 seconds, 5 seconds, 10 seconds. Another user condition may be to assert the power button hardware input using a pattern or code such as long, short, short, long. Another user condition may be to assert the power button hardware input before a timer expires. One of ordinary skill in the art would understand that other hardware inputs may be used in addition to, or as an alternative to, the power button, for example, the volume button or a biometric sensor such as fingerprint sensors that are built into mobile devices and are configured to provide information about biometrics in the form of biometric data.
In one embodiment, the trusted authentication service 154 sends one of a success, time out, or failure message to the therapy management application. If the expected user action is received then the trusted authentication service 154 may generate a signature and return the signature with the success message. In one embodiment, the trusted authentication service 154 may generate the signature by hashing a message, including some or all of the success message, using its private key and/or the public key of the insulin delivery unit 110.
In one embodiment, the trusted authentication service 154 may be configured to provide one or more therapy specific services to the insulin management application 152. For example, in one embodiment, the trusted authentication service 154 may be configured to (or may be configured to call a trusted insulin therapy specific application that is configured to) check that the dose amount in a text string matches a delivery instruction calculated by the insulin management application 152. If the dose amount does not match the delivery instruction, it may be corrected or it may generate a request that the insulin management application 152 resubmit its authentication request.
Upon receiving the success message and signature, the insulin management application 152 provides the delivery instructions and signature to the insulin delivery unit 110. In one embodiment, the insulin management application 152 may communicate the delivery instruction and signature to the insulin delivery unit 110 using a secure communication protocol, and the mobile computing device 150 and insulin delivery unit 110 may include a communication architecture to implement the protocol, such as is described in U.S. patent application Ser. No. 15/431,452, filed Feb. 13, 2017, entitled SECURE COMMUNICATION ARCHITECTURE FOR MEDICAL DEVICES, the entire contents and disclosure of which are hereby incorporated herein by this reference.
If the signature is verified then that confirms to the insulin delivery unit 110 that the delivery instructions received with the signature were confirmed by user action.
FIGS. 3A and 3B show an embodiment of method 300 for sending an insulin delivery instructions and signature to an insulin delivery unit, accordingly to an embodiment. For example, insulin management application 152 sends an insulin delivery instruction and a signature to the insulin delivery unit 110.
At 302 of method 300, insulin management application 152 sends an authentication request to trusted authentication service 154. At 304, trusted authentication service 154 generates a confirmation prompt. At 306, trusted authentication service 154 asserts control over display hardware. At 308, trusted authentication service 154 sends a confirmation prompt to UI at display 156.
At 310, a confirmation prompt is displayed at the display 156 for user 160. At 312, user 160 provides an input response at the UI of display 156. The input response is then provided to trusted authentication service 154.
At 314, trusted authentication service 154 determines whether the input response is approved or denied. If approved, then trusted authentication service creates and sends a signature to insulin management application 152. Alternatively, at 316, if the input response is denied, then trusted authentication service 154 creates and sends an error message 316 to insulin management application 152. At 318, upon receiving a signature from trusted authentication service 154, insulin management application 152 sends delivery instructions to delivery controller 116 of insulin delivery unit 110 (as shown in FIG. 3B).
Referring now to FIG. 3B, at 320, delivery controller 116 requests authentication of the signature from authenticator 114. At 322, authenticator 114 verifies the signature using public key(s) in crypto-key storage 112 (e.g., key ROM 112). At 324, authenticator 114, sends indication to delivery controller 116 that the signature is either verified or not verified (based on the verification process using public key(s)).
At 326, if the instructions are verified by delivery controller 116, then delivery controller 116 adjusts the set points corresponding to the verified instructions. The commands/instructions are then sent to delivery mechanism 120.
At 328, if the instructions are not verified by delivery controller 116, then delivery controller does not adjusts the set points. The commands/instructions are then sent to delivery mechanism 120.
FIGS. 4A and 4B show an embodiment of method 400 for a trusted authentication service sending a signature. For example, trusted authentication service 154 sends the signature directly to the insulin delivery unit 110 using a trusted communication process whereby the trusted authentication service takes over communication equipment of the mobile computing device 150. In one embodiment, the trusted authentication service 154 may send the signature and the delivery instructions. In another embodiment, the trusted authentication service 154 may send the signature and an indication of the delivery instructions that the signature corresponds to, which were sent by the insulin management application 152.
At 402, insulin management application 152 sends an authentication request to trusted authentication service 154. At 404, trusted authentication service 154 generates a confirmation prompt. At 406, trusted authentication service 154 asserts control over display hardware. At 408, trusted authentication service 154 sends a confirmation prompt to UI at display 156.
At 410, a confirmation prompt is displayed at the display 156 for user 160. At 412, user 160 provides an input response at the UI of display 156. The input response is then provided to trusted authentication service 154.
At 414, trusted authentication service 154 determines whether the input response is approved. If approved, then trusted authentication service creates and sends a signature to a trusted authentication service. Additionally, the authentication service takes over communication (COM) equipment.
At 416, trusted authentication service 154 sends a success message to insulin management application. For example, if a confirmation is received via the controlled hardware inputs then the trusted authentication service signs a success message using a private key associated with the trusted authentication service, and sends the signed message to the medication therapy application. At 418, upon receiving a success message from trusted authentication service 154, insulin management application 152 sends delivery instructions to delivery controller 116 of insulin delivery unit 110 (as shown in FIG. 4B).
Now referring to FIG. 4B, at 420, authenticator 114 verifies a signature using public keys stored in key ROM 112. At 422, authenticator 114 stores a verified or not verified signature. At 424, delivery controller 116 requests authentication of instructions. At 426, authenticator 114 sends authentication results based on verified/not verified signature.
At 428, if instructions are verified, delivery controller 116 adjusts set points and sends commands to delivery mechanism 120 (at 430). Alternatively, at 432, if instructions are not verified, then delivery controller 116 does not adjust set points and sends commands to delivery mechanism 120 (at 434).
FIGS. 5A and 5B show an embodiment of method 500 for a delivery device requesting the signature from a mobile device. For example, the insulin delivery unit 110 requests the signature from the trusted authentication service 154 responsive to receiving a delivery instruction from the insulin management application 152. In one embodiment, the signature is stored by trusted authentication service 154 for a limited period of time. If the trusted authentication service 154 does not receiver a request for the signature before the time period expires then it will discard the signature. In one embodiment, the signature is stored by a trusted storage service (not shown) for a limited period of time. If the insulin management application 152 does not receive a request for the signature before the time expires then it instructs the trusted storage service to discard the signature.
At 502, insulin management application 152 sends an authentication request to trusted authentication service 154. At 504, trusted authentication service 154 generates a confirmation prompt. At 506, trusted authentication service 154 asserts control over display hardware. At 508, trusted authentication service 154 sends a confirmation prompt to UX at display 156.
At 510, a confirmation prompt is displayed at the display 156 for user 160. At 512, user 160 provides an input response at the UI of display 156. The input response is then provided to trusted authentication service 154.
At 514, trusted authentication service 154 determines whether the input response is approved. If approved, then trusted authentication service creates and stores a signature to a period of time.
At 516, trusted authentication service 154 sends a success message to insulin management application. At 518, upon receiving a success message from trusted authentication service 154, insulin management application 152 sends delivery instructions to delivery controller 116 of insulin delivery unit 110 (as shown in FIG. 5B).
Now referring to FIG. 5B, at 520, delivery controller requests authentication of instructions. At 522, authenticator requests signature from a trusted authentication service at a mobile device. At 524, a signature is sent to authenticator 114. At 526, authenticator verifies the signature using public key(s). At 528, authenticator 114 sends verified or not verified signature to delivery controller 116.
At 530, delivery controller 116 adjusts set point if instructions are verified and sends commands to delivery mechanism 120 (at 532). Alternatively, at 534 authenticator 114 verifies the signature using public key(s). At 534, delivery controller 116 adjusts set point if instructions are not verified and sends commands to delivery mechanism 120 (at 536).
FIG. 6 shows a confirmation process 600 executed in the TEE, according to embodiments of the disclosure. In operation 602, the medication therapy application requests a REE authentication instance for the REE authentication service via the REE API. A dedication instance is not required, but it may provide additional isolation from other processes executing at the TEE. In operation 604, the REE API sets up a REE authentication instance with the trusted authentication service executing in the TEE. In operation 606, the trusted authentication services creates a prompt based on the delivery instructions or using text provided by the insulin therapy application, such that the prompt presents the insulin delivery instructions in a form understandable by a user. In operation 608, the trusted authentication services takes control of the hardware display and hardware inputs and presents the prompt to the user at the hardware display. In operation 610, the trusted authentication service receives user input at the controlled hardware inputs. In operation 612, if a confirmation is received via the controlled hardware inputs then the trusted authentication service signs a success message using a private key associated with the trusted authentication service, and sends the signed message to the medication therapy application. In operation 614, if no confirmation is received using the controlled hardware input then the trusted authentication service sends an error message to the medication therapy application.
FIG. 7 shows the insulin therapy system 700 in use by a patient/user, according to embodiments of the disclosure. System 700 may include a pump assembly 715 for insulin and a continuous glucose monitor 750. As shown, the continuous glucose monitor 750 is in wireless communication with pump assembly 715. In some cases, a continuous glucose monitor can be in wired communication with pump assembly 715. In some cases not shown, a continuous glucose monitor can be incorporated into an insulin pump assembly. As shown, pump assembly 715 can include a reusable pump controller 720 that forms part of the pump assembly 715. In some cases, reusable pump controller 720 is adapted to determine one or more basal delivery rates. In some cases, continuous glucose monitor 750 can act as a controller adapted to communicate basal delivery rates to pump assembly 715.
Pump assembly 715, as shown, can include reusable pump controller 720 and a disposable pump 730, which can contain a reservoir for retaining insulin. A drive system for pushing insulin out of the reservoir can be included in either the disposable pump 730 or the reusable pump controller 720 in a controller housing 722. Reusable pump controller 720 can include a wireless communication device 747, which can be adapted to communicate with a wireless communication device 754 of continuous glucose monitor 750 and other diabetes devices in the system, such as those discussed below. In some cases, pump assembly 715 can be sized to fit within a palm of a hand 705. Pump assembly 715 can include an infusion set 780. Infusion set 780 can include a flexible tube 782 that extends from the disposable pump 730 to a subcutaneous cannula 149 that may be retained by a skin adhesive patch (not shown) that secures the subcutaneous cannula 784 to the infusion site. The skin adhesive patch can retain the subcutaneous cannula 784 in fluid communication with the tissue or vasculature of the PWD so that the medicine dispensed through flexible tube 782 passes through the subcutaneous cannula 784 and into the PWD's body. The cap device 736 can provide fluid communication between an output end of an insulin cartridge (not shown) and flexible tube 782 of infusion set 780. Although pump assembly 715 is depicted as a two-part insulin pump, one piece insulin pumps are also contemplated. Additionally, insulin pump assemblies used in methods and systems provided herein can alternatively be a patch pump.
Continuous glucose monitor 750 (e.g., a glucose sensor) can include a housing 752, a wireless communication device 754, and a sensor shaft 756. The wireless communication device 754 can be contained within the housing 752 and the sensor shaft 756 can extend outward from the housing 752. In use, the sensor shaft 756 can penetrate the skin 786 of a user to make measurements indicative of the PWD's blood glucose level or the like. In some cases, the sensor shaft 756 can measure glucose or another analyte in interstitial fluid or in another fluid and correlate that to blood glucose levels. In response to the measurements made by the sensor shaft 756, the continuous glucose monitor 750 can employ the wireless communication device 754 to transmit data to a corresponding wireless communication device 747 housed in the pump assembly 715. In some cases, the continuous glucose monitor 750 may include a circuit that permits sensor signals (e.g., data from the sensor shaft 756) to be communicated to the wireless communication device 754. The wireless communication device 754 can transfer the collected data to reusable pump controller 720 (e.g., by wireless communication to the wireless communication device 747). Additionally or alternatively, the system 700 may include another glucose monitoring device that may utilize any of a variety of methods of obtaining information indicative of a PWD's blood glucose levels and transferring that information to reusable pump controller 720. For example, an alternative monitoring device may employ a micropore system in which a laser porator creates tiny holes in the uppermost layer of a PWD's skin, through which interstitial glucose is measured using a patch. In the alternative, the monitoring device can use iontophoretic methods to non-invasively extract interstitial glucose for measurement. In other examples, the monitoring device can include non-invasive detection systems that employ near IR, ultrasound or spectroscopy, and particular implementations of glucose-sensing contact lenses. In other examples, the monitoring device can include detect glucose levels using equilibrium fluorescence detectors (e.g., sensors including a diboronic acid receptor attached to a fluorophore). Furthermore, it should be understood that in some alternative implementations, continuous glucose monitor 750 can be in communication with reusable pump controller 720 or another computing device via a wired connection. In some cases, continuous glucose monitor 750 can be adapted to provide blood glucose measurements for a PWD when in use for the PWD at regular or irregular time intervals. In some cases, continuous glucose monitor 750 can detect blood glucose measurements at least every thirty minutes, at least every fifteen minutes, at least every ten minutes, at least every five minutes, or about every minute. In some cases, continuous glucose monitor 750 can itself determine a basal delivery rate using methods provided herein and communicate that basal rate to the pump assembly 715. In some cases, continuous glucose monitor 750 can transmit blood glucose measurement data to reusable pump controller 720 and reusable pump controller 720 can use methods provided herein to determine a basal delivery rate. In some cases, a remote controller can receive glucose data from continuous glucose monitor 750, determine a basal delivery rate using methods provided herein, and communicate the basal rate to pump assembly 715.
Diabetes management system or insulin therapy system 700 (system 700) may optionally include a blood glucose meter 770 (e.g., a glucose sensor). In some cases, blood glucose meter 770 can be in wireless communication with reusable pump controller 720. Blood glucose meter 770 can take a blood glucose measurement using one or more test strips (e.g., blood test strips). A test strip can be inserted into a strip reader portion of the blood glucose meter 770 and then receive the PWD's blood to determine a blood glucose level for the PWD. In some cases, the blood glucose meter 770 is configured to analyze the characteristics of the PWD's blood and communicate (e.g., via a BLUETOOTH® wireless communication connection) the information to reusable pump controller 720. In some cases, a user can manually input a glucose meter reading. The blood glucose meter 770 can be manually operated by a user and may include an output subsystem (e.g., display, speaker) that can provide the user with blood glucose readings that can be subsequently entered into the controller or user interface to collect the data from an unconnected BGM into the system. The blood glucose meter 770 may be configured to communicate data (e.g., blood glucose readings) obtained to reusable pump controller 720 and/or other devices, such as the mobile computing device 760 (e.g., a control device). Such communication can be over a wired and/or wireless connection, and the data can be used by system 700 for a number of functions (e.g., calibrating the continuous glucose monitor 750, confirming a reading from the continuous glucose monitor 750, determining a more accurate blood glucose reading for a bolus calculation, detecting a blood glucose level when the continuous glucose monitor 750 is malfunctioning).
In some cases, the system 700 can further include a mobile computing device 760 that can communicate with the reusable pump controller 720 through a wireless and/or wired connection with the reusable pump controller 720 (e.g., via a BLUETOOTH® wireless communication connection or a near-field communication connection). In some cases, the mobile computing device 760 communicates wirelessly with other diabetes devices of system 700. The mobile computing device 760 can be any of a variety of appropriate computing devices, such as a smartphone, a tablet computing device, a wearable computing device, a smartwatch, a fitness tracker, a laptop computer, a desktop computer, and/or other appropriate computing devices. In some cases (for example, where the reusable pump controller 720 does not determine a basal delivery rate), the mobile computing device 760 can receive and log data from other elements of the system 700 and determine basal delivery rates using methods provided herein. In some cases, a user can input relevant data into the mobile computing device 760. In some cases, the mobile computing device 760 can be used to transfer data from the reusable pump controller 720 to another computing device (e.g., a back-end server or cloud-based device). In some cases, one or more methods provided herein can be performed or partially performed by the other computing device. In some cases, the mobile computing device 760 provides a user interface (e.g., graphical user interface (GUI), speech-based user interface, motion-controlled user interface) through which users can provide information to control operation of the reusable pump controller 720 and the system 700. For example, the mobile computing device 760 can be a mobile computing device running a mobile app that communicates with reusable pump controller 720 over short-range wireless connections (e.g., BLUETOOTH® connection, Wi-Fi Direct connection, near-field communication connection, etc.) to provide status information for the system 700 and allow a user to control operation of the system 700 (e.g., toggle between delivery modes, adjust settings, log food intake, change a fear of hypoglycemia index (FHI), confirm/modify/cancel bolus dosages, and the like).
Optionally, system 700 may include a bolus administering device 790 (e.g., a syringe, an insulin pen, a smart syringe with device communication capabilities, or the like) through which bolus dosages can be manually administered to a PWD. In some cases, a suggested dosage for a bolus to be administered using the bolus administering device 790 can be output to a user via the user interface of reusable pump controller 720 and/or the user interface of the mobile computing device 760. In some cases, the bolus administering device 790 can communicate through a wired and/or wireless connection with reusable pump controller 720 and/or the mobile computing device 760. In some cases, system 700 can allow users to input insulin deliveries made using a syringe or insulin pen.
In some cases, methods and systems of treating diabetes can include the use of an pump assembly 715 (e.g., an “insulin pump assembly”), which can be used to deliver both a continuous (or semi-continuous) supply of quick acting insulin at a personalized BR and to delivery boluses of the quick acting insulin to make corrections for elevated blood glucose levels or to address consumed carbohydrates. In some cases, methods and systems of treating diabetes can include the use of a continuous glucose monitor 750 (CGM) that can communicate blood glucose data to a controller such as the mobile computing device 760 and/or the reusable pump controller 720 that can automate insulin delivery dynamically to address current or anticipated high or low blood glucose levels. In some cases, methods and systems provided herein can make adjustments to therapeutic parameters based upon the automated insulin deliveries determined using continuous (or semi-continuous) blood glucose data.
In some cases, methods and systems of treating diabetes can include the use of multiple daily injections (MDI) of different types of insulin. For example, MDI can include the injection of long acting insulin at least once a day to cover a baseline insulin requirement and the injection of a quick acting insulin to make corrections or to address consumed carbohydrates.
In some embodiments, the system 700 may include a bolus administering device 790 (e.g., a syringe, an insulin pen, a smart syringe with device communication capabilities using quick acting insulin, or the like) through which bolus dosages can be manually administered to a PWD. As illustrated in FIG. 7, such a bolus administering device may be referred to as an injection based delivery device. In some cases, a suggested dosage for a bolus to be administered using the bolus administering device 790 can be output to a user via the user interface of reusable pump controller 720 and/or the user interface of the mobile computing device 760. In some cases, the bolus administering device 790 can communicate through a wired and/or wireless connection with reusable pump controller 720 and/or the mobile computing device 760. In some cases, system 700 can allow users to input insulin deliveries made using a syringe or insulin pen.
In some embodiments, the system 700 may include a basal administering device 792 (e.g., a syringe, an insulin pen, a smart syringe with device communication capabilities using long acting insulin, or the like) through which basal insulin can be manually administered to a PWD, such as a once per day dose or a twice per day dose. As illustrated in FIG. 7, such a basal administering device may be referred to as an injection based delivery device. In some cases, the amount of basal insulin for a given dose may be determined by the mobile computing device 760. For example, the mobile computing device 760 may display an amount of insulin to be delivered as a daily basal dose. Additionally or alternatively, if the basal administering device 792 includes communication capabilities, the mobile computing device 760 may transmit a message to the basal administering device 792 indicating the amount of basal insulin to be delivered in the dose.
FIGS. 8A-8D show exemplary user interfaces for an insulin therapy application, displayed on device 802 that may be used to calculate a bolus, according to embodiments of the disclosure. In FIG. 8A, a user might indicate the size of a meal, which can be represented as a number of grams of carbohydrates, that the user intends to eat in field 821 in order to request that the system calculate a bolus. Additionally, a user can indicate the current estimated blood glucose (BG) value in field 831. In some cases, field 831 can auto populate based on data received from continuous glucose monitor 750 and/or blood glucose meter 770 or any other suitable glucose sensor. Based on that data, the bolus calculator can indicate a recommended dosage of insulin (in units), and the user can view how that was calculated by viewing the calculation 818. By using toggle switch 851, a user may use a different user interface that provides the user with predetermined meal sizes (811-814) via the user interface, as shown in FIG. 8B. By pressing “NEXT,” the user can be presented with a screen that indicates that device 802 is about to deliver the recommended bolus 881. If the user presses on the recommended bolus 881, the user can adjust this number based on the user's specific preference. By pressing ready 871a, set 871b, go 871c (or other suitable user interaction to indicate a desire to deliver the bolus), the smartphone will send a signal to the TEE to confirm the bolus instruction. FIG. 8D, the TEE overrides the user interface of the smartphone and presents the user with a confirmation screen 880 or popup of the bolus instruction, including the units of insulin to be delivered, so that the user can confirm the intent to deliver that amount of insulin.
FIG. 9A shows a use case where methods, devices, and systems provided herein may only require the TEE to confirm the delivery instruction if the user elects to deliver a bolus other than a recommended bolus. FIG. 9A depicts a method 900 for a TEE to confirm the delivery instruction if the user elects to deliver a bolus other than a recommended bolus. For example, a recommended bolus might not be calculated by the insulin therapy application, but might instead be calculated by the delivery controller at the insulin delivery unit, and a user interaction with the screen of FIG. 8C to deliver the recommended bolus might provide an instruction to the insulin pump to deliver the recommended bolus. In some cases, the use of the TEE to confirm a user instruction to bolus might only be triggered if the amount of the bolus exceeds a threshold or if it is close in time to another bolus event or if the system determines that the bolus is unsafe or unusual.
At 902, delivery controller 116 presents recommended delivery instructions to user 160. At 904, a denial of the recommendation is sent to insulin management application 152. At 906, insulin management application 152 requests a signature from a trusted authentication service at a mobile device. At 908, the trusted authentication service requests confirmation of the denial. At 910, a response of the confirmed denial is received at the trusted authentication service. At 912, upon confirmation, a signature is created and sent with the denial to insulin management application 152. At 914, authentication results with a signature are sent to delivery controller 116. At 916, delivery controller 116 verifies the signature with public key(s). At 918, delivery controller 116 discards the recommended change.
FIG. 9B shows an example of a recommendation 950 provided by the insulin delivery unit to the mobile computing device to bolus in response to a trend toward higher blood glucose levels that may trigger the confirmation process shown in FIG. 9A.
FIG. 10 shows a therapy management system 1000 (similar to insulin therapy system 100) where the user interfaces with a wearable device 1010 is configured to be taken over by the trusted authentication service, and permit a user to provide confirmation of a bolus dose, according to an embodiment of the disclosure.
FIG. 11 shows an example of a user interface 1100 where the user, instead of entering the amount of carbs selects a meal or carbohydrate amount associated with a meal-type that the user entered, according to an embodiment of the disclosure.
This disclosure also describes, generally, methods to increase confidence that a user-specified parameter was confirmed by a user and, indeed, it was a user action that confirmed the user-specified parameter. The embodiments computing architecture, including those shown in FIG. 2 may be configured to implement such methods. A user-specified parameter may be any parameter that may be used by, or affect a parameter used by, a medication therapy application to control medication delivery or make recommendations related to medication delivery or medication therapy, more generally, (e.g., a medication therapy recommendation, or, in the case of insulin therapy, an insulin therapy recommendation). Examples of user-specified parameters include carbohydrate intake, exercise, sleep, changes of dosing information for a previous dose (e.g., changing a previous dose from rapid acting to long acting insulin to correct an error). User-specified parameters may also include physiological parameters, such as insulin sensitivity, age, weight, gender, etc.
FIGS. 12A and 12B show a method 1200 where a trusted authentication service is used to confirm user-specified parameters that would affect medication therapy or medication delivery recommendations. For example, a user-specified parameter may correspond to a change to physiological parameters such as a patient's insulin sensitivity, age, weight, health (e.g., the patient is sick), etc. By way of further example, a user-specified parameter may correspond to a change to a therapy parameter such as a change to a basal rate of insulin.
In one embodiment, the insulin delivery unit may be a closed loop or open loop insulin pump, but in other embodiments it may be other insulin delivery devices that include an output sub-system connected to a display and/or indicators (e.g., LEDs, audio output, etc.), that enable them to make insulin delivery and, more generally, insulin therapy, recommendations, such as a smart insulin pen, a reusable cap adapted to attach to an insulin pen, or a smart accessory that is adapted to attach to an insulin pen or insulin inhaler. In various embodiments, a reusable cap may be reusable, for example, because it is adapted to be releasably attached to an insulin pen and/or associated with an insulin pen and then associated with a different insulin pen.
At 1202, therapy parameters are sent to insulin management application 152. At 1204, insulin management application 152 sends an authentication request to trusted authentication service 154. At 1206, trusted authentication service 154 generates a confirmation prompt. At 1208, trusted authentication service 154 asserts control over display hardware. At 1210, trusted authentication service 154 sends a confirmation prompt to UI at display 156.
At 1212, a confirmation prompt is displayed at the display 156 for user 160. At 1214, user 160 provides an input response at the UI of display 156. The input response is then provided to trusted authentication service 154.
At 1216, trusted authentication service 154 determines whether the input response is approved. If approved, then trusted authentication service creates and sends a signature to insulin management application 152. Alternatively, at 1218, if the input response is denied, then trusted authentication service 154 creates and sends an error message to insulin management application 152. At 1220, upon receiving a signature from trusted authentication service 154, insulin management application 152 sends therapy parameters to delivery controller 116 of insulin delivery unit 110 (as shown in FIG. 12B).
Referring now to FIG. 12B, at 1222, delivery controller 116 requests authentication of the signature from authenticator 114. At 322, authenticator 114 verifies the signature using public key(s) in crypto-key storage 112 (e.g., key ROM 112). At 1224, authenticator 114 retrieves private key(s) from key ROM 112. At 1226, authenticator 114 compares the keys. At 1228, authenticator sends the results to delivery controller 116.
At 1230, if the instructions are verified by delivery controller 116, then delivery controller 116 adjusts the set points corresponding to the verified instructions. At 1232, if the instructions are not verified by delivery controller 116, then delivery controller does not adjusts the set points.
The embodiments described herein may include the use of a special-purpose or general-purpose computer including various computer hardware or software modules, as discussed in greater detail below.
Embodiments described herein may be implemented using computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media that may be accessed by a general-purpose or special-purpose computer. Special-purpose computer is intended to be interpreted broadly and encompasses embedded systems, microcontrollers, application specific integrated circuits, digital signal processors, and general-purpose computers programmed for specific purposes. Segments (e.g., code segment or data segment) may refer to a portion (e.g., address) of memory, virtual memory, or an object file.
By way of example, and not limitation, such computer-readable media may include non-transitory computer-readable storage media including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid-state memory devices), or any other storage medium which may be used to carry or store desired program code in the form of computer-executable instructions or data structures and which may be accessed by a general-purpose or special-purpose computer. Combinations of the above may be included within the scope of computer-readable media.
Computer-executable instructions comprise, for example, instructions and data which cause a general-purpose computer, special-purpose computer, or special-purpose processing device (e.g., one or more processors) to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Any ranges expressed herein (including in the claims) are considered to be given their broadest possible interpretation. For example, unless explicitly mentioned otherwise, ranges are to include their endpoints (e.g., a range of “between X and Y” would include X and Y). Additionally, ranges described using the terms “approximately” or “about” are to be understood to be given their broadest meaning consistent with the understanding of those skilled in the art. Additionally, the terms “approximately” or “substantially” include anything within 10%, or 5%, or within manufacturing or typical tolerances.
Any characterization in this disclosure of something as “typical,” “conventional,” or “known” does not necessarily mean that it is disclosed in the prior art or that the discussed aspects are appreciated in the prior art. Nor does it necessarily mean that, in the relevant field, it is widely known, well-understood, or routinely used.
The features of the various embodiments described herein are not mutually exclusive and can exist in various combinations and permutations, even if such combinations or permutations are not expressly described herein, without departing from the scope of the disclosure. In fact, variations, modifications, and other implementations of what is described herein will occur to one of ordinary skill in the art without departing from the scope of the disclosure. As such, the invention is not to be defined only by the preceding illustrative description, but only by the claims which follow, and legal equivalents thereof.