Method of pairing therapy devices using shared secrets, and related systems, methods and devices

Systems, methods and devices are described for establishing trusted connections among two or more therapy devices that form, or form part of, a medication therapy system. A medication delivery electronics may include a first communication interface, a connection manager, and a therapy management application. A first communication interface may be configured to establish and communicate over one or more communication links. A connection manager may be configured to generate a candidate shared secret key and provide the shared key to a first therapy device over a first communication link established by a first communication interface. A candidate shared key may be generated responsive to one or more shared secret parameters. A therapy management application may be configured to receive, using the first communication interface, the first therapy related information from the first therapy device over a first trusted communication link established by the first communication interface responsive to acceptance of a candidate shared secret.

TECHNICAL FIELD

Embodiments of this disclosure relate, generally, to medication therapy systems, and more specifically, some embodiments relate to systems and methods for establishing trusted connections among two or more therapy devices that form a medication therapy system.

BACKGROUND

Medication delivery devices are commonly used to deliver medication to the human body, including as part of a medical treatment provided as a therapy for a medical condition. Medication delivery devices such as a transdermal liquid dosing device (e.g., an injection pen), inhalers, and syringes provide a convenient, often reusable means of delivering medication to the human body in fluid or aerosolized form. Infusion pumps also provide a convenient means of delivering medication to the human body in controlled amounts of fluid, and are often used when there is a desire to deliver medication in precisely calculated volumes (large and small) at precise rates and/or intervals. By way of example, medication delivery means may deliver medication intravenously, subcutaneously, arterially, and epidurally (i.e., via the epidural space around the spinal cord). Infusion pumps use a variety of techniques to deliver medication that do not require any or only a limited amount of manual manipulation. By way of example, infusion pumps may use positive displacement (e.g., a peristaltic pump, diaphragm pump, etc.), positive pressure (e.g., a drive system that advances a plunger), reciprocating positive pressure (e.g., plunger pumps that draw medication from a cartridge into a delivery chamber), and more.

One advantage of infusion pumps is that their dimensions may be such that they can be worn “on the body.” For example, on-body infusion pumps are sometimes used for subcutaneous delivery of medication—the infusion pump delivers medication via a subcutaneous cannula, and an adhesive patch secures the pump, cannula and any other elements of the infusion set at the infusion site. The adhesive helps maintain the cannula in fluidic communication with the tissue and/or vasculature of the patient so that medication may be delivered to the patient's body.

Medication delivery devices are sometimes used in combination with other therapy related devices to deliver therapeutic amounts of medication. For example, when a treatment is based, at least in part, on an amount of an analyte in a patient's blood stream. An analyte sensor may be used to detect and/or measure amounts of the analyte and provide analyte data to a user, a medication delivery device, or other therapy related devices. A therapy application may store and analyze the analyte data, plan therapy activities, provide and receive information from users (e.g., via an interface), provide recommendations to users (e.g., via an interface), and, in some arrangements, provide instructions to a medication delivery device for medication delivery.

Medication therapies can exact a toll on users that, due to dangers associated with administering external biologically effective medication (e.g., hormone, analgesics, antibiotics, nutrients, etc.), must track, plan, and calculate amounts of medication delivered. So, therapy applications can be a tremendous boon, and off-load some of the cognitive and emotional burden associated with a medication therapy.

DETAILED DESCRIPTION

In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and in which are shown, by way of illustration, specific example embodiments in which the present disclosure may be practiced. These embodiments are described in sufficient detail to enable a person of ordinary skill in the art to practice the present disclosure. However, other embodiments may be utilized, and structural, material, and process changes may be made without departing from the scope of the disclosure.

Sometimes therapy devices are wirelessly connected to each other to form a therapy system that is configured for medication delivery. For example, an analyte monitoring device may be wirelessly connected to a medication delivery device. While it is common for devices to connect wirelessly to form a system (e.g., a speaker connecting to a media source via BLUETOOTH®), there are specific challenges and concerns that arise in medication delivery, especially ambulatory medication delivery.

For example, for some conditions and therapies, a patient may need to carry an ambulatory medication delivery device (e.g., an infusion pump, injection pen, an inhaler, etc.) with them all times. Even if not necessary, many patients carry their drug delivery devices with them simply for convenience and risk aversion. So, a patient could take an ambulatory medication delivery device loaded with a dangerous medication, literally, anywhere in the world.

Opportunities for mis-delivery and dangerous consequences are higher when patients are being treated by a therapy system that includes a variety of therapy devices communicating with each other. For example, a patient may be treated by a therapy system that includes an analyte monitoring device, a therapy application executing on a mobile device, and a medication delivery device. In a typical operational cycle, the analyte monitoring device sends analyte measurement data to the therapy application. The therapy application performs therapy related analysis, determines changes to a medication therapy regime based on the analyte measurement data, and sends instructions to implement the changes to the medication delivery device. The medication delivery device reconfigures its medication delivery (e.g., dose amount, rate of dosing, etc.) based, at least in part, on the instructions.

If a third-party device (i.e., a therapy device that is not part of the therapy system) connects with any of the therapy devices that form the therapy system, that connection could interfere with the operation of the therapy system. The other device could be part of another therapy system, in which case the connection could interfere with operation of both therapy systems. So, even an inadvertent connection could cause information and instructions to be missed, or erroneous instructions to be sent. Moreover, the third-party device may be a malicious device that intends to capture therapy related information or even hijack operation of the therapy system and interfere with medication delivery (e.g., so called “main-in-the-middle” attacks).

Whether inadvertent or malicious, a misconnection and incorrect operation brings a significant risk of injury and death to users of therapy systems. The risk of an inadvertent or malicious connection are increased if the therapy devices are able to connect to each other and third-party devices using wireless communication links.

As used herein “a connection” and “connected” when used with references to two or more devices means that there is a communication link between two devices. The communication link may be wired, unwired (e.g., using wireless radio-frequency (RF) signals), and combinations thereof. “Connecting” means one or more operations are being taken to establish a communication link or a type of communication link, for example, operations to establish an intermediate communication link, which in turn may be used for performing one or more operations to establish a trusted communication link.

One way to restrict wireless connections is to configure devices to limit at least certain communication to a trusted connection. One of ordinary skill in the art would appreciate a number of ways to establish a trusted connection (when two devices form or have a trusted connection, that is also referred to herein as “pairing” and being “paired”), and one non-limiting example is: discovery, authentication, agreement on a communication protocol, sharing identifiers, agreement on an encryption scheme, and then agreement that the trusted connection is active.

Due to the risk of inadvertent connections and malicious connections, passwords and/or passkeys are often used when establishing trusted connections. For example, a user reads an N-digit code at a first device that is in a pairing mode, and enters the N-digit code at a second device that is in a pairing mode. The second device provides the N-digit code to the first device over a wired or wireless connection. If the first device determines that the displayed N-digit code matches the received N-digit code, then the first device approves the pairing and the first and second devices establish a trusted connection. The N-digit code is an example of a “shared secret,” which is a piece of data, known only to parties involved in setting up the trusted connection. By way of example, a shared secret may be a password, a passphrase, a big number, an array of randomly chosen bytes, and the like. In some cases, both devices will store the shared secret and, periodically, the first device will ask the second device to again provide the shared secret to the first device in order to maintain the trusted connection.

Shared-secrets are effective, but as time passes, the risk that the shared secret will be compromised grows (e.g., a third-party might see the code displayed on the first device). Further, even with a shared secret, there is the risk of a brute force attack on the device where an attacker iterates through candidate passkeys until one is accepted.

Security risks aside, in the case of medication therapies, there are social and privacy drawbacks to current pairing techniques. For example, a user may be embarrassed to look at an analyte monitoring device and program a passkey into a medication delivery device in public because it exposes their health condition to strangers. If the devices are visible, that exposes the user to risk because a malicious actor may observe the user and target the user's devices, including in the manner described above. Further, physically reading a shared secret at the first device and entering it at the second device affects the user experience, and can cause a system that is supposed to reduce cognitive burden on a user to be more burdensome. Finally, the first device that provides the passkey must include a user interface sufficient to present the passkey to a user (e.g., a display, light-emitting-diodes, a speaker).

Accordingly, the inventors of this disclosure see a need for systems, methods, and devices that securely facilitate establishing trusted connections among therapy devices that form medication therapy systems.

FIG.1is a functional block diagram of a therapy system100, which includes at least some therapy devices that are configured to establish trusted connections in accordance with one or more embodiments of the disclosure. Therapy system100is configured, generally, to monitor a patient and deliver therapeutic amounts of medication to the patient. In one or more embodiments, therapy system100includes an analyte monitoring unit102, medication therapy electronics104, a remote therapy management system106, and a medication delivery unit118.

In one or more embodiments, medication therapy electronics104is configured, generally, to analyze therapy related information, provide therapy recommendation to users, and send therapy instructions to medication delivery unit118. Medication therapy electronics104is operatively coupled to medication delivery unit118, and, in one or more embodiments, medication therapy electronics104and medication delivery unit118are components of a medication delivery device. In one embodiment, the medication delivery device may be a “smart” medication delivery device, where the medication therapy electronics104provides processing power related to the therapy as well as the user experience. For example, the medication delivery device may be an infusion pump system that is configured to automatically deliver medication based on control signals determined at the pump system (e.g., at the medication therapy electronics104). By way of further example, the medication delivery device may be an injection pen that is configured to provide therapy recommendations based on detected delivery events and/or physiological information about a patient.

In another embodiment, medication therapy electronics104may be, or be a component of, a first device and medication delivery unit118may be, or be a component of, a second device. The first and second devices may be operatively coupled by a wired or wireless connection. In one embodiment, the connection may be a trusted connection established in accordance with one or more embodiments of the disclosure.

In one or more embodiments, medication therapy electronics104is configured to establish a trusted communication link with one or more therapy related devices, including analyte monitoring unit102and/or medication delivery unit118. In one contemplated process for establishing a trusted communication link with analyte monitoring unit102, medication therapy electronics104is configured to provide a candidate shared secret key116over an intermediate communication link114ato analyte monitoring unit102. In various embodiments, candidate shared secret key116may be a value or string of alpha-numeric characters representative of a candidate shared secret to be validated against a shared secret that is unique to analyte monitoring unit102. In one or more embodiments, shared secrets and candidate shared secrets may be values, strings of alpha-numeric characters, algorithms, or combination thereof. In a contemplated operation of therapy system100candidate shared secret key116is used, but it is specifically contemplated that there may be multiple pairs of therapy related devices within a therapy system that use different unique shared secrets, candidate shared secrets, and candidate shared secret keys to establish trusted connections. In one embodiment, a shared secret may be unique to therapy system100(e.g., a therapy system identifier, algorithm, or combination thereof), and so the same shared secret, candidate shared secret, and candidate shared secret key may be used to establish trusted communication links between some or all of the therapy devices that comprise therapy system100.

Turning back to the example ofFIG.1, in one or more embodiments, medication therapy electronics104provides candidate shared secret key116responsive to shared secret parameters that it requests and receives from remote therapy management system106over communication network108. If analyte monitoring unit102accepts candidate shared secret key116, or more specifically, if the analyte monitoring unit102verifies the candidate shared secret based, at least in part, on the candidate shared secret key116, then a trusted communication link is established between analyte monitoring unit102and medication therapy electronics104.

In one embodiment, establishing a trusted communication link includes recording at both devices that intermediate communication link114ais a trusted communication link. In another embodiment, intermediate communication link114ais ended and a new communication link114bis established with trusted communication characteristics (e.g., protocol, encryption, etc.). In various embodiments, the trusted communication link114bmay use the same or different communication equipment (e.g., transceivers configured for BLUETOOTH®, ZIGBEE®, NFC, etc.) as intermediate communication link114a.

In various embodiments, medication therapy electronics104may be configured to communicate over intermediate communication link114aand trusted communication links,114bas well as over communication network108, and may include equipment for several types of communication.

In one or more embodiments, remote therapy management system106may execute on one or more computer servers remote from one or more other therapy devices, such as the medication therapy electronics104, analyte monitoring unit102, and medication delivery unit118. The other therapy related devices may be carried with a user, while the remote therapy management system106operates remotely and provides services to devices within the therapy system100.

In one embodiment, medication therapy electronics104sends a shared secret parameters request112to remote therapy management system106. Remote therapy management system106receives shared secret parameters request112and sends response110. Response110may include, for example, the requested shared secret parameters or a denial message denying the request112. Medication therapy electronics104generates candidate shared secret key116responsive to shared secret parameters in the response110.

Analyte monitoring unit102is configured to receive candidate shared secret key116, and sends an acceptance or rejection message (not shown) over intermediate communication link114aresponsive to candidate shared secret key116.

FIG.2is a flowchart of a process120for establishing a trusted communication among therapy devices, in accordance with one or more embodiments of the disclosure. In operation121, a candidate shared secret is generated responsive to one or more shared secret parameters. In operation122, the candidate shared secret key is provided to a therapy device over an intermediate communication link. Candidate shared secret key is representative of one or more candidate shared secrets at a therapy device. In operation123, a trusted communication link is established with a therapy device responsive to the therapy device accepting a candidate shared secret. In various embodiments and as described more fully herein, a candidate shared secret may be validated based, at least in part, on a candidate shared secret key. The trusted communication link is configured to enable communication of therapy related information from the first therapy device, so, in operation124, first therapy related information is received from the first therapy device over the trusted communication link.

FIG.3Ais a functional block diagram of medication therapy electronics104, in accordance with one or more embodiments of the disclosure. Medication therapy electronics104includes a connection manager131, a shared secret key calculator133, a therapy management application137, and a user interface138. Medication therapy electronics104also includes a network communication interface130and a therapy communication interface136.

Connection manager131is configured, generally, to manage establishing one or more communication links with therapy related devices, including, for example, trusted and untrusted (e.g., intermediate) communication links. Connection manager131is configured to use network communication interface130to send shared secret parameter requests112from remote therapy management system106(FIG.1), send one or more shared secret parameters132to shared secret key calculator133for processing, and to send candidate shared secret keys134from shared secret key calculator133. Connection manager131is configured to receive candidate shared secret key134and provide candidate shared secret key134to a therapy related device (e.g., analyte monitoring unit102ofFIG.1) via therapy communication interface136.

In one or more embodiments, network communication interface130may be configured to send requests to, and receive response messages from, remote therapy management system106(FIG.1) over one or more networks, which may include, at least in part, the Internet. By way of example and not limitation, network communication interface130may be configured for wireless network communication (e.g., an IEEE 802.11 standard), cellular network communication (e.g., 3G, 4G LTE, 5G, CDMA, GSM etc.), microwave network communication, and combinations thereof.

Therapy communication interface136may be configured for personal, local, and/or wide-area network communication with a related therapy device. By way of example, and not limitation, therapy communication interface136may be configured for BLUETOOTH communication (including BLUETOOTH Low Energy (BLE)), NFC (near field communication), WiFi, ZIGBEE, IrDA (infrared data association), wireless USB (universal serial bus), combinations thereof, and more.

Shared secret key calculator133is configured to receive shared secret parameters132and provide candidate shared secret key134. In one or more embodiments, shared secret key calculator133is configured to generate candidate shared secret key134responsive to shared secret parameters132and one or more secret operations. In one embodiment, shared secret key calculator133may be pre-configured to perform secret operations, and in another embodiment shared secret key calculator133may perform secret operations responsive to secret operation instructions that are included with the shared secret parameters132.

In various embodiments, one or more shared secret parameters and/or secret operations may be a contemplated shared secret.

FIG.3Bshows a flow chart of a shared secret calculation process140, in accordance with one or more embodiments of the disclosure. Secret operations143are performed responsive to a pre-defined component141and a variable component142. In one embodiment, pre-defined component141may be a unique identifier that is associated with the therapy related device with which a trusted communication link is being established. By way of example, unique identifier may be a serial number that is associated with the therapy related device at manufacture or an identifier generated by a remote therapy system. Variable component142may be non-static, that is, it may change each time the shared secret calculation process140is performed. By way of example, variable component142may be time-based—e.g., a time (e.g., “4:28:09”) or calculated using a specific time (e.g., “4:28:09”→4×28×09=1008). If calculated using a specific time, that time may be stored (e.g., in a time stamp format) and sent with the candidate shared secret key134.

In one embodiment, pre-defined component141and variable component142are both received by shared secret key calculator133(seeFIG.3A) as part of shared secret parameters132. In another embodiment, shared secret key calculator133may be include a variable component calculation module (e.g., a clock circuitry, calculation circuitry, random number generator, etc.) configured to generate variable component142.

In one or more embodiments, secret operations143may be a one-way function configured to obfuscate its input parameters (e.g., pre-defined component141and variable component142). Secret operations143may be performed using pre-defined component141and variable component142. In one embodiment, each of pre-defined component141and variable component142may be a parameter of secret operations143. In another embodiment, secret operations143may use a post-processed parameter that is based, at least in part, on pre-defined component141and variable component142(e.g., a combination of the two parameters using concatenation, exclusive OR, multiplication, etc.).

In one or more embodiments, secret operations143is a hashing function, shared secret parameters132is a hash key, and candidate shared secret key134is a hash. Shared secret key calculator133is configured to generate the hash by hashing the hash key using the hashing function. By using both the pre-defined component141and variable component142, a correct candidate shared secret key134is harder to recover illicitly without knowing how the variable component affects secret operations143.

In one or more embodiments, therapy management application137(seeFIG.3A) may be configured, generally, to receive therapy related information (e.g., analyte measurements), and provide one or more of therapy recommendations and therapy instructions. User interface138may be configured to provide therapy recommendations generated by therapy management application137to a user and receiver user input. In one or more embodiments, user interface138may be a graphical user interface presentable at a display operably coupled to medication therapy electronics104(seeFIG.1), that is configured to present therapy recommendations and/or therapy related information to a user. By way of example, and not limitation, therapy related information may include notifications, alarms, alerts, combinations thereof, and more. Therapy recommendations may include one or more of changes to medication dosing parameters, recommended bolus doses, recommended correction doses, dietary recommendations (e.g., to eat), physiological recommendations (e.g., sleep or exercise) and more. User input may include approvals, acknowledgements, dismissals, information about therapy relevant events, physiological information, parameters for medication therapies, and more.

FIG.4shows a flowchart of a process150for establishing a trusted communication link with another therapy related device, in accordance with one or more embodiments of the disclosure. In one or more embodiments, operations of process150may be performed at medication therapy electronics104(seeFIG.1), and is one contemplated operation of medication therapy electronics104. In operation151, remotely stored shared secret parameters are requested from a remote therapy management system. In one embodiment, shared secret parameters are received in a reply message from the remote therapy system. If the remote therapy management system rejects the request or fails to find the requested shared parameters, a reply message may be received indicating that the request was rejected or the system failed. In operation152, a candidate shared secret key is generated responsive to received one or more shared secret parameters and at least one shared secret operation. The shared secret parameters may be a unique identifier, and, in one embodiment, may include a variable component as described in this disclosure. Shared secret operations may be locally stored or may be remotely stored and received with the shared secret parameters. In operation153, a candidate shared secret key is provided to the therapy related device. The candidate shared secret key may be provided over an intermediate communication link. By way of example, the intermediate communication link may be an untrusted communication link, a temporary communication link used for establishing a trusted communication link, or a combination thereof. In operation154, a trusted communication link is established with the therapy related device responsive to an acceptance of a candidate shared secret. The trusted communication link enables receipt of therapy related information from the therapy related device.

FIG.5shows a functional block diagram of remote therapy management system106, in accordance with one or more embodiments of the disclosure. Remote therapy management system106is configured, generally, to manage records related to therapy system100(seeFIG.1) and monitor aspects of operation of therapy system100and therapeutic delivery of medication more generally. In one or more embodiments, remote therapy management system106is configured to monitor and manage therapy system100responsive to one or more therapy related policies162. Therapy related policies162may include, for example, restrictions on the number and kinds of therapy related devices that may be part of therapy system100, as well as physical and operational requirements (e.g., security, updates, etc.) for therapy related devices that may be part of therapy system100.

In one or more embodiments, remote therapy management system106may include a parameters request manager166, a therapy system policy enforcer163, therapy system records161, and therapy related policies162.

Therapy system policy enforcer163may be configured, generally, to enforce therapy related policies162. More particularly, therapy system policy enforcer163may be configured to enforce therapy related policies162related to forming medication therapy systems from a group of therapy related devices, and more specifically still, to establishing trusted communication links among therapy related devices. So, when a therapy related device requests shared secret parameters, therapy system policy enforcer163may be configured to determine whether establishing a trusted communication link would violate one or more therapy related policies162. For example, if the requesting therapy related device is attempting to establish a trusted communication link with an analyte monitoring unit, therapy system policy enforcer163may be configured to reject the request if the therapy system records161indicate that the requesting therapy related device already has an active trusted communication link with another, different, analyte monitoring unit. By way of another example, if the requesting therapy related device is attempting to establish a trusted communication link with an analyte monitoring unit, therapy system policy enforcer163may be configured to reject the request if the therapy system records161indicate that the analyte monitoring unit already has an active trusted communication link with another, different, therapy related device or has reached a maximum number of active trusted communication links with other, different, therapy related devices. By way of yet another example, if the requesting therapy related device is attempting to establish a trusted communication link with an analyte monitoring unit, therapy system policy enforcer16may be configured to reject the request if the requesting therapy related device and the other therapy related device are not compatible. For example, therapy related policies162may describe lists of compatible types of devices (or, conversely, lists of incomputable devices), and if the requesting therapy related device and the other therapy related device are not compatible then therapy system policy enforcer16may be configured to reject the request.

In the contemplated example ofFIG.5, if therapy system policy enforcer163determines that the trusted communication link would not violate one or more of therapy related policies162, then it may retrieve the shared secret parameters responsive to group identifiers165, therapy system records161, and the policy determination. Therapy system policy enforcer163may provide the shared secret parameters164to parameters request manager166, which in turn may generate and send a reply message to the requesting therapy related device, and the reply message may include shared secret parameters164. If the request is rejected or fails (e.g., because no relevant therapy system records161may be found responsive to group identifiers165), then the reply message may indicate the rejection or failure.

Therapy system records161may include records stored in a database that are related to one or more medication therapy systems. Therapy system records161may describe therapy related devices that form a medication therapy system, including identifiers, type of devices, patient information, insurance information, provider information, and more.

FIG.6is a flowchart of a process170for enforcing policies for establishing trusted communication links among therapy devices, in accordance with one or more embodiments of the disclosure. In one or more embodiments, operations of process170may be performed at remote therapy management system106, and is one contemplated operation of remote therapy management system106. In operation171, a request for shared secret parameters is received. The request may be received from a first therapy device that is attempting to establish a trusted communication link with a second therapy device. In operation172, a reply message is sent responsive to the request for shared secret parameters. The contents of the reply message may be selected responsive to one or more therapy system policies and/or searches of therapy system records, and may include, for example, shared secret parameters or a denial message. The therapy system policies and therapy system records may be managed at one or more databases. Therapy system policies may describe restrictions that apply to therapy devices and groups of therapy devices. Therapy system records may describe individual therapy devices and groups of therapy devices that form medication therapy systems.

FIG.7is a functional block diagram of analyte monitoring unit102, in accordance with one or more embodiments of the disclosure. Analyte monitoring unit102is configured, generally, to measure analyte levels in blood samples and send the measurements to therapy related devices that, together with analyte monitoring unit102, may be part of a medication therapy systems. One or more embodiments of analyte monitoring unit102may include a monitoring unit connection manager181, a monitoring unit communication interface183, and analyte sensors184.

Monitoring unit communication interface183is configured, generally, to send and receive messages to and from other therapy related devices, for example, over trusted and/or untrusted communication links. In one or more embodiments, messages sent by monitoring unit communication interface183may include one or more of analyte measurement information received from analyte sensors184, and status information about analyte monitoring unit102(e.g., battery life, component health, etc.). Monitoring unit communication interface183may also be configured to send and receive messages related to establishing trusted communication links with other therapy related devices.

Monitoring unit connection manager181is configured, generally, to manage establishment of trusted communication links with other therapy related devices. Monitoring unit connection manager181may include or have access to primary shared secrets182stored at analyte monitoring unit102. In a contemplated operation of analyte monitoring unit102, when a therapy device attempts to establish a trusted communication link with analyte monitoring unit102, monitoring unit connection manager181is configured to validate a candidate shared secret responsive to candidate shared secret key186and primary shared secrets182.

In one or more embodiments, primary shared secret manager187is configured to generate and provide primary shared secret parameters182to monitoring unit connection manager181. In one embodiment, primary shard secret manager187stores one or more primary shared secret parameters that it provides to connection manager181. In one contemplated operation, the primary shared secret parameters may include a unique identifier (e.g., a string of alpha numeric characters), a decryption key, and an encrypted string (e.g., cyphertext) that was generated based, at least in part, on the unique identifier, an encryption algorithm corresponding to the decryption algorithm, and an encryption key. Connection manager181may decrypt the encrypted string using the decryption algorithm and the candidate shared secret key186. In a contemplated operation, if the decrypted string matches the unique identifier than that is indicative that a candidate shared secret matches a primary shared secret of the analyte monitoring unit102. The primary shared secret may be a unique identifier, a hash function, or both.

In another embodiment, primary shared secret parameters182may be a primary shared secret key generated by primary shared secret manager187. Primary shared secret manager187may perform secret operations with a unique identifier to generate a primary key, and provide the primary key to connection manager181to compare the primary key to candidate shared secret key186. In a case where candidate shared secret key186matches the primary key then that is indicative that the primary secret operations and primary shared secret parameters are the same as the ones used to generate candidate shared secret key186. For example, the secret operations performed at primary shared secret manager187may be the same hashing function or other one-way function performed at shared secret key calculator133(seeFIG.3A). In a case where candidate shared secret key186does not match a primary key, then any of the secret operations and shared secret parameters may be different than those used to generate candidate shared secret key186.

Any suitable technique known by one of ordinary skill in the art may be used by monitoring unit connection manger181to perform comparisons described herein. For example, a symbol-to-symbol comparison, bit-to-bit comparison, converting to an integer (e.g., if they are strings) and comparing integer values, and the like.

FIG.8is a flowchart of a process190for establishing trusted communication links with a therapy device, in accordance with one or more embodiments of the disclosure. In one or more embodiments, operations of process190may be performed at analyte monitoring unit102(seeFIG.1and/orFIG.7). In operation191, an intermediate communication link is established with a therapy device that is attempting to establish a trusted communication link. In operation192, a request for a shared secret is sent to the therapy device over the intermediate communication link. In operation193, a candidate shared secret key is received from the therapy device over the intermediate communication link. In one embodiment, a countdown is implemented and if the candidate shared secret key is not provided within a certain amount of time, the request “times out” and a candidate shared secret is automatically rejected. This avoids a problem whereby the requesting therapy device is waiting in an active intermediate mode, which may happen if the requesting therapy device fails to receive shared secret parameters from a remote therapy management system. In operation194, a candidate shared secret is validated responsive to a primary shared secret. In various embodiments, the primary shared secret or values indicative of it may be stored or calculated locally. In operation195, a trusted communication link is established with the requesting therapy device responsive to the comparison. For example, if a candidate shared secret matches a primary shared secret then an acceptance message is provided to the requesting therapy device. If a candidate shared secret does not match a primary shared secret then a rejection message is provided to a requesting therapy device. Once the trusted communication link is established, therapy related information may be sent between therapy devices. For example, analyte monitoring unit102may send analyte measurement data326to a therapy related device that includes without limitation medication therapy electronics104.

One or more embodiments relate, generally, to a process for establishing trusted connections that may be performed by therapy devices using shared secrets stored or determined locally, and systems and devices for accomplishing the same.

FIG.9is a functional block diagram of therapy system300that includes at least some therapy devices that are configured to establish trusted connections in accordance with one or more embodiments of the disclosure. Therapy system300is configured, generally, to monitor a patient and deliver therapeutic amounts of medication to the patient. In one or more embodiments, therapy system300includes an analyte monitoring unit302, medication therapy electronics312, and a medication delivery unit328.

Notably, a remote therapy system is not shown as part of therapy system300because, in one or more embodiments, medication therapy electronics312is configured to store and/or calculate the shared secret locally. Nevertheless, one of ordinary skill in the art would understand that therapy system300may include remote therapy management elements.

In one or more embodiments, medication therapy electronics312includes a connection manager314, a shared secret manager316, a communication interface318, and a therapy management application320. In one embodiment, shared secret manager316is configured to retrieve a locally stored candidate shared secret key322responsive to a request to provide a shared secret from analyte monitoring unit302, and connection manager314is configured to provide candidate shared secret key322to analyte monitoring unit302. Candidate shared secret key322may be, for example, a hash of a unique identifier associated with analyte monitoring unit302.

In one or more embodiments, shared secret manager316is configured to determine candidate shared secret key322. In one embodiment, a secret and one or more secret operations are stored at medication therapy electronics312. By way of example, the secret may be a hash key and the secret operations may be a hashing function. Shared secret manager316determines candidate shared secret key322by performing secret operations using secrets as a parameter.

In one or more embodiments, a secret may be static, for example, it may be a unique identifier associated with analyte monitoring unit302. In one or more embodiments, the secret operations may be configured to use at least two parameters: a static component (e.g., a unique identifier) and a variable component (e.g., a time), such that the candidate shared secret key322is different for different variable components. In yet another embodiment, the secret may be a combination of a unique identifier and a variable component.

In one or more embodiments, analyte monitoring unit302may include monitoring unit connection manager304, primary shared secret manager306, monitoring unit communication interface308, and analyte sensors310. Monitoring unit connection manager304is configured to validate a candidate shared secret based, at least in part, on candidate shared secret key322responsive to a primary shared secret provided by primary shared secret manager306, for example, by comparing candidate shared secret key322to a primary shared secret or a primary shared secret key generated using a primary shared secret.

In one embodiment, analyte monitoring unit302may store a primary shared secret. In another embodiment, primary secret parameters and secret operations may be stored at analyte monitoring unit302, and primary shared secret manager306may be configured to determine a primary shared secret or a primary shared secret key, at least in part, using secret operations. In the example ofFIG.8, if secret operations and a secret key used by primary shared secret manager306are the same as secret operation(s) and a secret key(s) used by shared secret manager316of medication therapy electronics312to generate candidate shared secret key322, then primary shared secret key will match candidate shared secret key322. If a candidate shared secret is validated at least in part using candidate shared secret key322, then analyte monitoring unit302is configured to send an acceptance message to medication therapy electronics312, and the two devices may establish trusted communication link324b.

Notably, candidate shared secret key322may also include a variable component if used to generate it, for example, a time stamp. Primary shared secret manager306may generate a primary shared secret or primary shared secret key responsive to a variable component, primary secret operations, and primary shared secret parameters.

FIG.10is a flowchart of a process330for establishing a trusted communication link with another therapy related device, in accordance with one or more embodiments of the disclosure. In one or more embodiments, operations of process330may be performed at medication therapy electronics312, and is one contemplated operation of medication therapy electronics312. In operation332, a candidate shared secret key is generated responsive to one or more locally stored shared secret parameters and locally stored shared secret operations. In various embodiments, the shared secret parameters may include static components, variable components, and/or secret operations. In operation334, a candidate shared secret key is provided to a therapy related device over an intermediate communication link324a. In operation336, a trusted communication link is established with the therapy related device responsive to an acceptance of a candidate shared secret. Acceptance may be communicated responsive to validating a candidate share secret using a candidate shared secret key. In one or more embodiments, a trusted communication link is configured to enable receipt of therapy related information from the therapy device.

One or more embodiments of the disclosure relate to insulin therapy systems configured to implement pairing techniques described in this disclosure.

Diabetes mellitus is a chronic metabolic disorder caused by the inability of a person's pancreas to produce sufficient amounts of the hormone insulin such that the person's metabolism is unable to provide for the proper absorption of sugar and starch. This failure leads to hyperglycemia, i.e., the presence of an excessive amount of glucose within the blood plasma. Persistent hyperglycemia has been associated with a variety of serious symptoms and life threatening long-term complications such as dehydration, ketoacidosis, diabetic coma, cardiovascular diseases, chronic renal failure, retinal damage and nerve damages with the risk of amputation of extremities. Because healing is not yet possible, a permanent therapy is necessary which provides constant glycemic control in order to constantly maintain the level of blood analyte within normal limits. Such glycemic control is achieved by regularly supplying external drugs to the body of the patient to thereby reduce the elevated levels of blood analyte.

An external biologically effective drug (e.g., insulin or its analog) is commonly administered by means of daily injections. In some cases, multiple, daily injections (MDI) of a mixture of rapid- and long-acting insulin via a reusable transdermal liquid dosing device (commonly referred to as an “insulin pen”) or a hypodermic syringe. The injections are typically administered by a person with diabetes (PWD), and so requires self-monitoring of blood glucose and the self-administration of insulin. The PWD that manages their care using MDI often plans insulin injections for each day, in advance, based on basal insulin requirement as well as external factors such as meals, exercise, sleep, etc. A typical dosing plan will include the time of day for an injection, the type of insulin (e.g., fast acting, long acting, a mixture of fast acting and long acting, etc.), and amount of insulin for each dose. In addition, PWDs will self-monitor their blood glucose and self-administer “bolus” dose(s) of rapid-acting insulin if their blood glucose is too high or consume carbohydrates (or sometimes administer glycogen) if their blood glucose is too low.

The “correct” insulin dose is a function of the level of glucose in the blood, physiological factors such as a person's insulin sensitivity, and lifestyle factors such as meals (e.g., recently consumed carbohydrates that have yet to be metabolized into glucose and absorbed into the blood). Moreover, even with careful planning and self-monitoring, a PWD may skip doses, double dose, and dose the wrong amount and/or type of insulin. Insufficient insulin can result in hyperglycemia, and too much insulin can result in hypoglycemia, which can result in clumsiness, trouble talking, confusion, loss of consciousness, seizures, or death. Accordingly, PWDs face a considerable cognitive burden in determining appropriate doses of insulin.

In order to assist with self-treatment, some insulin therapy devices (e.g., blood glucose meters, continuous glucose meters, insulin pumps, insulin pens etc.) are equipped with insulin therapy applications that assist user with making appropriate therapy decisions while minimizing the burdens of data entry, mental calculations, procedures, etc.). For example, insulin bolus calculators may be used that have the user input an estimate (e.g., numerical estimate) of the quantity of carbohydrates consumed or about to be consumed (or additionally or alternatively protein, fat, or other meal data) and the bolus calculator outputs a recommended size for the insulin bolus dosage. Although bolus calculators remove some of the mental calculations that need to be made by the user in determining an appropriate insulin bolus dosage, bolus calculators still burden the user with the mental task of evaluating the constituents of their meal, may require the use of a secondary device, and often require manual entry of data.

Automated insulin delivery may also be used to relieve some of the burdens of self-treatment. A glucose monitoring unit measures levels of glucose in blood samples and sends at least some of the measurements to a therapy application that is monitoring patient's response to insulin therapy. The therapy application determines insulin dosing (e.g., amount, timing, rates of insulin, etc.) dosing to account for a patient's basal insulin needs as well as to account for physiological events such as carbohydrate intake, exercise, sleep, medication intake (other than insulin), and more. The therapy application uses glucose levels received from the glucose monitoring unit as a control variable to determine insulin dosing instructions that it then sends to an insulin delivery device, such an infusion pump. The operation of the insulin delivery device is configured by the insulin dosing instructions and the insulin delivery device will then deliver insulin according to the new configuration. Insulin therapy systems that implement automated insulin delivery may operate in “open loop” modes and “closed loop” modes. By way of example, in an open loop mode, the insulin therapy system may involve some user interaction before sending the insulin delivery instructions326to the insulin delivery device (e.g., a user acceptance of change). In a closed loop mode, the therapy application may determine and automatically send the insulin delivery instructions326to the insulin delivery device without user interaction.

FIG.11shows an insulin therapy system400configured for pairing in accordance with one or more embodiments of the disclosure. Insulin therapy system400includes a blood glucose meter (BGM)402, an insulin injection pen404, and a mobile computing device406with an insulin therapy application executing thereon.

In one or more embodiments, insulin injection pen404and BGM402are configured for pairing in accordance with the embodiments for establishing a trusted communication link described in this disclosure. In one embodiment, a shared secret is locally stored at BGM402, and upon request, insulin injection pen404is configured to provide a candidate shared secret to BGM402in order to pair with BGM402and start receiving glucose level measurement data from BGM402. If insulin injection pen404fails to provide candidate shared secret410or BGM402does not validate candidate shared secret410(e.g., using its stored primary shared secret, or using a shared secret key and secret operations), pairing will fail and trusted communication link408will not be established.

In one or more embodiments, mobile computer device406and insulin injection pen404are configured for pairing in accordance with the embodiments for establishing a trusted communication link described in this disclosure. In one embodiment, a shared secret is locally stored at insulin injection pen404, and upon request, mobile computing device406is configured to provide a candidate shared secret414in order to pair with insulin injection pen404and start receiving insulin dosing event information from insulin injection pen404. If mobile computing device406fails to provide candidate shared secret414or if insulin injection pen404does not validate candidate shared secret410against its stored primary shared secret, pairing will fail and trusted communication link412will not be established.

FIG.12shows an automated insulin therapy system500configured for pairing in accordance with one or more embodiments of the disclosure. Automated insulin therapy system500includes a continuous glucose monitor (CGM)502, an insulin infusion pump506, and a mobile computing device504with an insulin therapy application executing thereon. Automated insulin therapy system500may be configured for open loop and closed loop delivery of insulin to a patient.

In one or more embodiments, insulin infusion pump506and CGM502are configured for pairing in accordance with the embodiments for establishing a trusted communication link described in this disclosure. In one embodiment, a shared secret is locally stored at CGM502, and upon request, insulin infusion pump506is configured to provide a candidate shared secret510to CGM502in order to pair with CGM502and start receiving glucose level measurement data from CGM502. If insulin infusion pump506fails to provide candidate shared secret510or CGM502does not validate candidate shared secret510(e.g., using its stored primary shared secret, or using a shared secret key and secret operations), pairing will fail and trusted communication link508will not be established.

By using the process for establishing trusted communication links, mobile computing devices and infusion pumps that are not part of automated insulin therapy system500may be restricted from receiving blood glucose level measurement data from CGM502.

In one or more embodiments, mobile computer device504and insulin infusion pump506are configured for pairing in accordance with the embodiments for establishing a trusted communication link described in this disclosure. In one embodiment, a shared secret is locally stored at insulin infusion pump506, and upon request, mobile computing device504is configured to provide a candidate shared secret514in order to pair with insulin infusion pump506and start receiving insulin dosing event information from insulin infusion pump506. If mobile computing device504fails to provide candidate shared secret514or if insulin infusion pump506does not validate candidate shared secret514against its stored primary shared secret, pairing will fail and trusted communication link512will not be established. By using the process for establishing trusted communication links, mobile computing devices that are not part of automated insulin therapy system500may be restricted from receiving insulin dosing event information from insulin infusion pump506and sending insulin dosing instructions to insulin infusion pump506.

FIGS.13A and13Bshow a sequence of operations that are part of a pairing process600performed by a BGM608, mobile application604, and insulin delivery device606(e.g., an insulin injection pen, medication delivery accessory such as a pen cap, an insulin infusion pump, etc.) that together form, at least in part, an insulin therapy system, in accordance with one or more embodiments of the disclosure. One or more operations of pairing process600may be performed by a user602of the insulin therapy system. In one or more embodiments, operations indicated as performed by a user may be performed by a user action to activate GUI elements, actuate buttons, speaking voice commands, physically performing pre-defined motions (e.g., waiving a device near another device), etc. Performing the user action(s) initiates some recognition of the action and therefore the operation(s) at a device that is acted on. However, this is not intended to limit this disclosure to requiring a specific user action(s). For example, one or more embodiments may include a recognition of a user action or what is assumed to be a user action, but not the user action itself.

In operation610, user602provides BGM pairing instruction to mobile application604. In operation612, mobile application604provides a BGM pairing instruction to insulin delivery device606responsive to the BGM pairing instruction received in operation610. Pairing operations between insulin delivery device606and BGM608are initiated by insulin delivery device606and BGM608“discovering” each other. In operation614, insulin delivery device606enters a scanning mode responsive to receiving the BGM pairing instruction in operation612, and scans for advertising messages. In operation616, user602provides an advertise instruction to BGM608, for example, but actuating a button for some pre-defined period of time. In operation618, BGM enters and advertising mode and sends advertisement messages that may be received by nearby devices. In operation620, insulin delivery device606sends to mobile application604an available BGM list comprising one or more identifiers for available BGM devices (e.g., unique BGM devices for which advertisement messages have been received in the most recent scan mode period), including an identifier for BGM608. In operation622, mobile application604presents the available BGM list at a display for user602. In operation624, user602provides a BGM selection to mobile application604, the BGM selection uniquely identifying one of the BGM devices listed in the BGM list. In operation626, responsive to the selection, mobile application604provides a connection instruction to insulin delivery device606that, at least in part, identifies the selected BGM device—here, BGM608.

In operation628, insulin delivery device606provides a connection request to BGM608responsive to receiving the connection instruction in operation626. In operation630, insulin delivery device606provides a read device information service (DIS) request (or some other request for identifying information, without limitation) to BGM608. In operation632, BGM608provides DIS information (or other identifying information, without limitation) to insulin delivery device606responsive to the read DIS request in operation630.

In operation634, insulin delivery device606provides a read time request to BGM608. In one embodiment, BGM608provides stored time information (e.g., in seconds) to insulin delivery device606in operation640, responsive to the read time request in operation634. In another embodiment, BGM608may determine in operation636whether the stored time is usable or unusable (e.g., because it is incorrect). Responsive to a determination that the stored time is usable, BGM608may provide the time in seconds in operation640. Responsive to a determination that the stored time is not usable, BGM608may provide the seconds elapsed since last battery insertion in operation638.

In operation642, insulin delivery device606generates a passkey responsive to the time information received in operations640(or in operation638) and the DIS information received in operation632. At about the same time as operation642, in operation644BGM608generates a passkey responsive to the time information sent in operation640and the DIS information sent in operation632.

In operation646, insulin delivery device606provides a connection security start request to BGM608to attempt to establish a trusted communication link between insulin delivery device606and BGM608. In operation648, insulin delivery device606provides an authentication request that includes a public key “pka” to BGM608. In operation650, BGM608provides a public key “pkb” to BGM608responsive to receiving the authentication request in operation648. Up receipt of “pkb,” insulin delivery device606and BGM608may send and receive messages using public key encryption.

In operation652, insulin delivery device606generates DHkey, which is a candidate shared secret, in accordance with tone or more processes for generating candidate shared secrets of this disclosure. In operations654and656, insulin delivery device606provides a verification request to BGM608that includes DHKey encrypted using the public encryption keys “pka” and “pkb.”

In operation658, BGM608determines whether DHkey is a valid key or an invalid key in accordance with one or more processes for validating candidate shared secrets of this disclosure. Responsive to determining that DHkey is an invalid key, in operation676BGM608provides a connection security failure response to insulin delivery device606, and in operation678BGM608sends a disconnect message to insulin delivery device606to end the untrusted communication link, and terminates the link locally. In operation680, insulin delivery device606sends a connection failure message to mobile application604, which, in one or more embodiments, presents a failure message to user602.

Responsive to determining that DHkey is a valid key, in operation662, BGM608sends a connection successful message to insulin delivery device606and stores the DHkey in operation666. In operation664, insulin delivery device606stores the DHkey responsive to receiving the connection successful message provided in operation662. In operation674, insulin delivery device606provides a connection successful message to mobile application604.

In one or more embodiments, insulin delivery device606and BGM608may be configured to continuously perform a truncated authentication process668while the trusted communication link is active. In operation670, insulin delivery device606may provide a request to continue the trusted communication link to BGM608. The request may include DHkey or a new key that is the result of modifying DHkey according to some pre-agreed operations. In operation672, BGM608may provide a response message indicating that the truncated authentication was successful, for example, responsive to validating the DHkey or new key received from insulin delivery device606in operation670.

While one-way sharing of candidate shared secrets has been generally described in this disclosure, one of ordinary skill in the art would understand that two-way sharing of candidate shared secrets is within the scope of the disclosure. When two therapy devices attempt to pair, each therapy device may require the other therapy device to provide a shared secret in order to establish a trusted communication link. In one or more embodiments that implement two-way sharing, each therapy related device may include means for requesting, generating, and/or retrieving a candidate shared secret to provide to the other therapy related device. Similarly, each therapy related device may include means for validating a received candidate shared secret.

One or more of shared secrets, shared secret parameters, secret keys, and secrete operations, may be stored on therapy devices at manufacture or during an initial setup. For example, before an analyte monitoring unit is provided to a patient, the serial number may be used to generate a shared secret that is stored at the monitoring unit and provided either to the patient's specially configured mobile computing device or a remote therapy management system. Alternatively or in addition, the operations used to generate the shared secret may be provided to the patient's specially configured mobile computing device or the remote therapy management system along with the parameters used to generate the shared secret.

Information and signals described herein may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof. Some drawings may illustrate signals as a single signal for clarity of presentation and description. It should be understood by a person of ordinary skill in the art that the signal may represent a bus of signals, wherein the bus may have a variety of bit widths and the disclosure may be implemented on any number of data signals including a single data signal.

Many of the functional descriptions in this specification may be illustrated, described or labeled as modules, threads, steps, or other segregations of programming code, including firmware, in order to more particularly emphasize their implementation independence. Modules may be at least partially implemented in hardware, in one form or another. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like.

Modules may also be implemented using software or firmware, stored on a physical storage device (e.g., a computer readable storage medium), in memory, or a combination thereof for execution by various types of processors.

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 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.

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 devices, 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 devices may be capable of altering and/or transmitting the signals. Examples of non-transitory storage devices are flash memory and random-access-memory (RAM). Another example of a non-transitory storage device 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 in order to execute the corresponding software instructions.

Some embodiments of the disclosure include or are described as implementing a server. A server is a computer program that provides functionality or services to other programs, commonly called clients. While a server is a computer program or process (i.e., executing program), the term may also be used to refer to a computer running one or more server programs, and so, unless otherwise indicated, the use of the term server in this description is intended to cover both situations. Further, the term computer is intended to cover a single machine, several machines (e.g., a server farm), as well as virtual clusters of computers that emulate one or more hardware elements including without limitation central processing units, graphics processing units, local and system memory, memory storage (e.g., hard disks and solid state drives), operating systems, and networking equipment.

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.

While the present disclosure has been described herein with respect to certain illustrated embodiments, those of ordinary skill in the art will recognize and appreciate that the present invention is not so limited. Rather, many additions, deletions, and modifications to the illustrated and described embodiments may be made without departing from the scope of the invention as hereinafter claimed along with their legal equivalents. In addition, features from one embodiment may be combined with features of another embodiment while still being encompassed within the scope of the invention as contemplated by the inventor.