Secure control of a medical device

Abstract

Certain aspects of the disclosure provide a medical device system for authenticating a communication received at a medical device. The communication is received at a medical device, the communication comprising first data for use by the medical device. The medical device determines a source of the communication. The medical device authenticates the source of the communication. The medical device operates based on the first data and the authenticated source of the communication.

Description

SECURE CONTROL OF A MEDICAL DEVICEBACKGROUNDField

[0001] Aspects of the present disclosure relate to authenticating communications in a medical device system.Description of Related Art

[0002] An infusion pump is a type of medical device utilized to infuse therapeutic fluid into a patient, such as in a hospital or other medical care site. Generally, an infusion pump is programmed to pump fluid at a specific flow rate and up to a specific volume. Control, such as programming, of the infusion pump may occur via one or more different sources. In particular, the infusion pump is configured to receive communications used to control operation of the infusion pump from one or more sources. The communications may include, for example, control messages, input data, or other types of data. For example, control messages may program the infusion pump with one or more treatment parameters, such as flow rate, volume, velocity, infusion time, and / or the like. The infusion pump then operates according to the one or more treatment parameters. Example input data includes sensor data received from one or more sensors that may be used to adjust treatment parameters, such as according to one or more algorithms operating at the infusion pump. For example, an algorithm may use input data to determine one or more treatment parameters, and send control messages to the infusion pump to adjust the one or more treatment parameters.

[0003] One example source of communications is from physical input on the infusion pump itself. In particular, the infusion pump may include physical buttons on a housing of the infusion pump. A clinician may manually enter one or more treatment parameters using the physical buttons on the infusion pump. A control message may be generated based on the entered one or more treatment parameters.

[0004] Another example source of communications is from one or more sensors. For example, one or more sensors may be configured to monitor different vital signs of the patient, such as, heart rate, blood pressure, etc. As another example, one or more sensors may be configured to monitor different operational parameters of a medical devices, such as actual flow rate through an infusion pump. The one or more sensors may include wireless sensors configuredto wirelessly communicate with the infusion pump. The one or more sensors may include wired sensors configured to couple to the infusion pump via a wired interface.

[0005] Another example source of communications is from a wireless communications device. For example, the infusion pump may be configured to wirelessly communicate with a wireless communications device, such as a smartphone, tablet, computing device, etc. A clinician operating the wireless communications device may enter one or more treatment parameters on the wireless communications device that are then wirelessly sent in a control message to the infusion pump.

[0006] An algorithm may also be a source of communications, as discussed, as the algorithm itself may generate control messages. One type of algorithm may be implemented as a closed- loop system. In particular, a closed-loop system algorithm may control the one or more treatment parameters (e.g., based on sensor data), without any input or further confirmation from a user (e.g., clinician). Another type of algorithm may be implemented as a semi-closed-loop system, where the algorithm may generate suggested changes to the one or more treatment parameters that are implemented only after user input confirming the changes to the one or more treatment parameters. There may also be other types of sources of communications.

[0007] As the infusion pump is able to receive communications that change an operation of the infusion pump, there are issues that arise. For example, communications with erroneous information may accidentally or maliciously be sent to the infusion pump, which if utilized to control the infusion pump, may cause the infusion pump to operate improperly, such as at an incorrect flow rate, volume, etc. Accordingly, there is a technical problem that exists in the field of medical devices as to how to enable the infusion pump to receive communications from various sources, while avoiding potential improper operation of the infusion pump.SUMMARY

[0008] Certain aspects provide a medical device system for authenticating a communication received at a medical device, comprising: a memory comprising computer-executable instructions; and a processor configured to execute the computer-executable instructions, and cause the medical device system to: receive the communication, the communication comprising first data for use by the medical device; determine the source of the communication; authenticate the source of the communication; and operate the medical device based on the first data and the authenticated source of the communication.

[0009] Certain aspects provide a method of authenticating a communication received from a source at a medical device, comprising: receiving the communication, the communication comprising first data for use by the medical device; determining the source of the communication; authenticating the source of the communication; and operating the medical device based on the first data and the authenticating the source of the communication.

[0010] Certain aspects provide a method of authenticating a communication received from a source, comprising: receiving, at a medical device, the communication, the communication comprising first data for use by the medical device; determining the source of the communication; authenticating the source of the communication; and determining a first parameter to adjust an element of the medical device based on the first data; and adjusting the element of the medical device according to the first parameter.

[0011] Other aspects provide processing systems configured to perform the aforementioned methods as well as those described herein; non-transitory, computer-readable media comprising instructions that, when executed by a processors of a processing system, cause the processing system to perform the aforementioned methods as well as those described herein; a computer program product embodied on a computer readable storage medium comprising code for performing the aforementioned methods as well as those further described herein; and a processing system comprising means for performing the aforementioned methods as well as those further described herein.

[0012] The following description and the related drawings set forth in detail certain illustrative features of one or more aspects.DESCRIPTION OF THE DRAWINGS

[0013] The appended figures depict certain aspects and are therefore not to be considered limiting of the scope of this disclosure.

[0014] FIG. 1 depicts an example medical device system.

[0015] FIG. 2 depicts another example medical device system.

[0016] FIG. 3 depicts an example flowchart for determining a communication is authentic.

[0017] FIG. 4 depicts an example flowchart for authenticating a communication from a previously authenticated source.

[0018] FIG. 5 depicts an example method for authenticating a communication received by a medical device.

[0019] FIG. 6 depicts an example computing device for implementing various features and processes described herein.

[0020] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the drawings. It is contemplated that elements and features of one embodiment may be beneficially incorporated in other embodiments without further recitation.DETAILED DESCRIPTION

[0021] Aspects of the present disclosure provide apparatuses, methods, processing systems, and computer-readable mediums for authenticating communications received at medical devices. For example, certain aspects relate to authenticating a communication received from a source at an infusion pump system. Though certain aspects are discussed with respect to an infusion pump system, it should be noted that the techniques discussed herein may similarly be used to control operations of other types of medical devices.

[0022] As discussed, a technical problem exists in the field of infusion pump systems as to how to enable the infusion pump system to receive communications from various sources, while avoiding potential improper operation of the infusion pump. In particular, the infusion pump system is configured to receive communications from different sources. Certain sources may be trusted sources, while other sources may not be trusted. A trusted source may be a source that should the infusion pump system receive a communication from the trusted source, it is safe for the infusion pump system to operate based on the communication. A source that is not trusted may be a source that should the infusion pump system receive a communication from the not trusted source, it is not safe for the infusion pump system to operate based on the communication, and the communication should be ignored. In particular, aspects described herein increase the reliability and effectiveness of a medical device system by authenticating received communications, thus beneficially securing a medical device system.

[0023] Certain aspects herein relate to authenticating a source of a communication received at an infusion pump system to determine whether the communication is received from a trusted source or not. In certain aspects, if the communication passes authentication, the communication is determined to be from a trusted source. If the communication does not pass authentication, the communication is determined not to be from a trusted source. For example, trusted sources mayinclude certain types of sources, sources developed or created by certain entities, etc. Therefore, such aspects provide the technical effect of ensuring proper operation of the infusion pump system by ensuring communications that affect the operation are only acted on when from a trusted source.

[0024] In certain aspects, different types of authentication may be used for different types of communications received at the infusion pump system. For example, certain types of authentication may be more secure and other types of authentication may be less secure. Further, certain types of communications may be more critical while other types of communications may be less critical. Therefore, for less critical types of communications, less secure types of authentication may be used, while for more critical types of communications, more secure types of authentication may be used. In particular, more secure types of authentication may require increased messaging between the source and the infusion pump system, or processing to authenticate the communication, as compared to less secure types of authentication. Accordingly, there may be a tradeoff between security levels of authentication versus complexity in implementing the authentication. Therefore, it may not be advantageous to always use a more secure type of authentication. Using different types of authentication for different types of communications provides the technical effect of ensuring critical communications are more secure, while allowing for less processing complexity for handling less critical communications. Authentication resources may be prioritized for the most critical communications. Thus, patient safety is maintained while reducing burden on the system.

[0025] In an example, certain types of communications may include sensor data corresponding to one or more sensors that play a less critical role in operation of the infusion pump system. For example, though sensor data from a certain sensor may be used by an algorithm in adjusting one or more treatment parameters of the infusion pump system, the weight assigned to such sensor data may be lower as compared to the weight assigned to other sensor data. For example, one sensor may provide the temperature of a patient to the infusion pump system, and another sensor may provide the heart rate of the patient to the infusion pump system. An algorithm may further run on the infusion pump system that controls the one or more treatment parameters of the infusion pump system based on both the heart rate and the temperature. However, the algorithm may be configured to give lower weight to the temperature when determining how to adjust the one or more treatment parameters as compared to the heart rate. For example, if the heart rate data indicates to increase a flow rate, while the temperature data indicates to decrease the flow rate, the heart rate data may supersede the temperature data. Accordingly, thecommunication from the heart rate sensor may be more critical than the communication from the temperature sensor. Thus, in certain aspects, a more secure type of authentication may be used for communications from the heart rate sensor, as compared to communications from the temperature sensor.

[0026] In another example, certain sources may be more likely to provide communications with accurate data than other sources. For example, sources that are physically connected to the infusion pump system, or are internal to the infusion pump system, may be more likely to be trusted than sources external to the infusion pump system, such as communicating wirelessly with the infusion pump system. Thus, in certain aspects, a more secure type of authentication may be used for communications from internal sources of the infusion pump system, as compared to sources external to the infusion pump system.

[0027] In another example, a semi-closed-loop system for controlling the one or more parameters may be more likely to provide communications with accurate data as compared to a closed-loop system due to the extra check by a user in the semi-closed-loop system. Thus, in certain aspects, a more secure type of authentication may be used for communications from a closed-loop system, as compared to from a semi-closed-loop system.

[0028] In certain aspects, different types of communications received at the infusion pump may be re-authenticated to determine whether the source sending the communication is still a trusted source or not. In particular, the communication may be re-authenticated with a different form of authentication. If the communication passes re-authentication, the communication is determined to be from a trusted source. If the communication does not pass authentication, the communication is determined not to be from a trusted source. For example, a trusted source may not be a trusted source after failing to pass authentication. Therefore, such aspects provide the technical effect of ensuring proper operation of the infusion pump system by ensuring that a trusted source remains a trusted source for communications that affect the operations of the infusion pump system.

[0029] Furthermore, in certain aspects, different types of authentication may be used to re- authenticate a source, such as for different types of communications or after certain time periods. For example, different security levels of authentication may be used for different communications, such as even for communications from the same source, based on criticality of the communications. Therefore, in certain aspects, more secure authentication methods may be usedas needed, to allow for less processing complexity when less secure authentication methods may be used. Thus, patient safety is maintained while reducing the burden on the system.Example Medical Device System

[0030] FIG. 1 depicts an example medical device system 100, which may implement methods described herein to authenticate communications received at the medical device system.

[0031] Medical device system 100 may be used to monitor and treat patient 110. Medical device system 100 includes sensor 102. Though one sensor 102 is shown, there may be additional sensors (e.g., of different types), or no sensors. In certain aspects, sensor 102 is configured to monitor / sense one or more vital signs of the patient. For example, sensor 102 may be one or more of a heart rate monitor, a pulse oximeter, a continuous glucose monitor, a blood pressure monitor, etc. In another example, sensor 102 may monitor / sense operational parameters of medical device system 100, such as a flow rate of infusion pump 104 included in medical device system 100.

[0032] Sensor 102 transmits communications including sensor data to control module 106 of medical device system 100. In some embodiments, sensor 102 may transmit sensor data to a sensor monitor. The sensor monitor may then transmit the sensor data to control module 106, such as through a wired or wireless communication link. In some embodiments, a sensor monitor, such as a multi-parameter monitor (MPM) may receive sensor data from one or more sensors, such as sensor 102.

[0033] Control module 106, such as using sensor data from sensor 102, determines one or more treatment parameters for infusion pump 104 to implement and treat patient 110. Accordingly, control module 106 transmits communications including the one or more treatment parameters (e.g., in one or more control messages) to infusion pump 104 to control operation of infusion pump 104. Control module 106 may include a user interface 108 to display sensor data, treatment parameters, and the like. In some embodiments, like a semi-closed loop system, a clinician may confirm treatment parameters on user interface 108. In some embodiments, control module 106 may be connected to more than one sensor 102, or more than one infusion pump 104. In some embodiments, control module 106 may be connected to one or more other medical devices, such as an insulin pump.

[0034] Generally, sensor 102, control module 106, and infusion pump 104 may be connected through a wired connection, or a wireless connection, such as a Bluetooth connection, a Wi-Fi connection, an RFID connection, a near-field communication connection, etc.

[0035] Although depicted here as separate devices, in some cases, control module 106 may be integral to or form part of sensor 102 or infusion pump 104.

[0036] In an example, the authentication techniques discussed herein may be used for authentication communications between devices of medical device system 100. For example, control module 106 may utilize the techniques herein to authenticate communications from sensor 102, other control modules, other devices, etc. Further, infusion pump 104 may utilize the techniques herein to authenticate communications from control module 106, other control modules, other devices, etc.Example Medical Device System

[0037] FIG. 2 depicts another example medical device system 200, such as infusion pump 104 in FIG. 11connected to a patient 110. A patient care system may include one or more pumps, for example, pump 202, pump 204, pump 206, and pump 208. Although a large volume pump is illustrated, other types of pumps may be implemented, such as a peristaltic pump, a small volume pump, a syringe pump, an anesthesia delivery pump, or a patient-controlled analgesic. A pump may be an infusion device configured to deliver a substance, (e.g., fluid, nutrients, drug, etc.) to a patient’s circulatory system, or epidural space, for example, via an intravenous infusion, subcutaneous infusion, arterial infusion, epidural infusion, etc., or to a patient’s digestive system, for example, via a nasogastric tube (NG), a percutaneous endoscopic gastrostomy tube (PEG), nasojejunal tube (NJ), etc.

[0038] Each of the pumps 202, 204, 206, or 208, may be fluidly connected with an upstream fluid line 212, fluid line 214, fluid line 216, and fluid line 218, respectively. Further, each of pump 202, pump 204, pump 206, and pump 208, may be fluidly connected with a downstream fluid line 222, fluid line 224, fluid line 226, and fluid line 228, respectively. The fluid lines may be any type of fluid conduit, such as tubing, through which fluid can flow.

[0039] Each of fluid supply 232, fluid supply 234, fluid supply 236, and fluid supply 238, may be a reservoir, for example, as bottles shown, are inverted and suspended above the pumps. Fluid supplies may also take the form of bags, syringes, or other types of contains. The medical device system 200 may be mounted on a roller stand or intravenous pole 240.

[0040] Medical decide system 200 may further comprise check valves, drip chambers, valved ports, connectors, and other devices configured to administer a substance.Example Flowchart for Authenticating a Communication

[0041] FIG. 3 depicts an example flowchart of a flow 300 for determining a communication sent by a source is authentic.

[0042] Initially, flow 300 begins at step 302 with receiving, at a device, a communication with input data, such as sensor data or one or more treatment parameters. For example, control module 106 may receive sensor data from sensor 102 of FIG. 1. In another example, infusion pump 104 may receive one or more treatment parameters from control module 106 of FIG. 1.

[0043] Flow 300 proceeds to step 304 with determining, by the device, a source of the communication. In certain embodiments, the source of the communication is determined based on a physical input over which the communication is received (e.g., internally at the device such as from an algorithm or button press, on a port of the device from a wired interface, over a wireless interface of the device, etc.).

[0044] In certain embodiments, the source of the communication is additionally or alternatively determined based on an identifier included in the communication indicating the source. In some embodiments, the identifier may be a token or some other verifiable information included in the communication. For example, the token may be an encrypted security token provided to the source, or the verifiable information may be information provided to the source. Therefore, should the token or verifiable information be included in the communication, the communication is determined to be from the source.

[0045] In certain embodiments, the source of the communication is additionally or alternative determined based on an additional input received at the device indicating a source of the communication. For example, a radio-frequency identification (RFID) tag may be attached to the source and scanned at the device. The RFID tag may include identifier information of the source. As another example, a barcode or QR code may be attached to the source and scanned at the device. The barcode or QR code may include identifier information of the source.

[0046] In certain embodiments, the source of the communication is additionally or alternative determined based on a characteristic of the communication. For example, different sources may be associated with different encryption schemes or keys used to encrypt the communication. The encryption type used to encrypt the communication may indicate a source of the communication. For example, the device may try different decryption schemes, to decrypt the communication, and the scheme or key that successfully decrypts the communication is used to identify the source of the communication.

[0047] In some embodiments, the communication includes a hash value to verify an integrity of the communication. For example, the communication may be hashed by the source using a hashing algorithm to generate the hash value, and the source may include the hash value in the communication. The device may use the same hashing algorithm to hash the communication (e.g., without the hash value) and see if it generates a hash value that matches the hash value included in the communication. If they do not match, the communication may be discarded. If the hash value in the communication and generated by the device match, the device may further process the communication.

[0048] In some embodiments, the communication includes a cyclic redundancy check that is used to confirm the integrity of the communication.

[0049] Flow 300 proceeds to step 306 with authenticating, by the device, the source of the communication.

[0050] In certain embodiments, the determination of the source at step 304 inherently authenticates the source. For example, where the communication includes a token or other verifiable information provided to the source, the inclusion of the token or other verifiable information in the communication authenticates the source as the source of the communication. As another example, where additional input is received at the device indicating the source of the communication, such additional input may authenticate the source as the source of the communication.

[0051] In certain embodiments, the device separately authenticates the source, such as to determine the source indicated in the communication was not spoofed. For example, where the communication includes an identifier of the source that may be generally known, the communication may be further authenticated to ensure the communication is from the source and not some other entity claiming to be the source. For example, the communication (e.g., other than the identifier of the source) may be encrypted using an encryption scheme or key associated with the source. For example, different sources may be associated with different encryption schemes or keys that are not generally known. Accordingly, the device, based on the identifier of the source in the communication, may attempt to decrypt the communication based on the encryption scheme or key associated with the source. If the decryption is successful, the source is authenticated. If the decryption is not successful, the source is not authenticated.

[0052] In certain embodiments, the type of authentication (e.g., token based, identifier based, encryption based, additional input based, etc.) used for authenticating a source is different fordifferent sources. For example, based on the identifier of the source in a communication, the device may require or use a different type of authentication to authenticate the communication as being from the source. If the communication does not include information to perform the type of authentication associated with the source, authentication of the communication fails.

[0053] If authentication fails flow 300 proceeds to step 320 where the communication is rejected. If authentication passes, flow 300 proceeds to step 308 with authorizing, by the device, use of the data in the communication from the source based on the authenticated source. For example, some sources may be authorized to provide data to the device that the device uses for operation, while some sources may not be authorized to provide data to the device that the device uses for operation. Where the source is authorized, the device may use the data in the communication for operating the device. Where the source is not authorized, the device may not use the data in the communication for operating the device. In some cases, where the source is authenticated, the source is inherently authorized at step 308, as unauthorized devices cannot be authenticated. In some cases, further authorization is performed, such as where some unauthorized devices can still be authenticated.

[0054] In certain embodiments, to perform authorization, the device queries whether the source (e.g., an identifier of the source, such as included in the communication) is on a registry. A registry of sources of communications may include an approved list, e.g., a “permit list” of sources authorized to communicate with the device. For example, a control module from the same manufacturer as the infusion pump may be added to the approved list and all communications from the control modules by that manufacturer are approved.

[0055] In some aspects, the registry of sources of communications may include an unapproved list, e.g., a “deny list” of sources not authorized to communicate with the device. For example, it may have been recently discovered that a specific sensor (e.g., sensor 102 of FIG. 1) contains a sensing error, and the specific sensor is added to the unapproved registry. Beneficially, the restriction on the sensor may be quickly updated at the device to prevent the sensor from communicating an erroneous reading to the device.

[0056] In certain embodiments, a source may be authorized based on whether the source meets one or more criteria. For example, the source may be authorized based on whether one or more parameters of the source meet one or more criteria. The one or more parameters of the source may include one or more of a type of the source, a protocol operated by the source, a manufacturerof the source, safety thresholds, mechanical thresholds associated with the source, algorithmic thresholds associated with the source, etc.

[0057] A type of source, for example, may include the type of data monitored (e.g., heart rate monitor, pulse oximeter, continuous glucose monitor, etc.), the type of therapy administered (e.g., insulin, cardiovascular therapy, intravenous therapy, etc.), the type of therapy administration device (e.g., infusion pump, insulin pump, respiratory assist device, etc.), and the like. Information associated with the type of source may include serial number, manufacturer identification, firmware version, SKU, etc. In some embodiments, source type information may be obtained from a manufacturer’s database. Where a type of the source is authorized, the source may be authorized. Where a type of the source is not authorized, the source may not be authorized.

[0058] A protocol of a source, for example, may include the type of protocol the source is operating, such as the method of obtaining a sensor value, the method of administering therapy, etc. In some examples, a protocol of a source may include the inputs (e.g., sensor data) used by the source and the outputs generated by the source (e.g., treatment parameters). Where a type of protocol of the source is authorized, the source may be authorized. Where a type of protocol of the source is not authorized, the source may not be authorized.

[0059] A safety threshold of a source, for example, may include operating within a safe state for the source. A source may be operable only in association with certain patient states (e.g., clinical outlook), certain other equipment (e.g., connected to the medical device system), certain time periods (e.g., operable for 3 days), etc., to ensure patient safety. Where a safety threshold of the source is authorized, the source may be authorized. Where a safety threshold of the source is not authorized, the source may not be authorized.

[0060] A mechanical threshold of a source, for example, may include operation compatibility. Certain sources may be indicated as incompatible with the device, such as to be restricted when an incompatible source is connected to the medical device system, or transmits a communication. Where a mechanical threshold of the source is authorized, the source may be authorized. Where a mechanical threshold of the source is not authorized, the source may not be authorized.

[0061] If the source is an unauthorized source, then flow 300 proceeds to step 320 with rejecting the communication. In some embodiments, an indication of the rejection is sent to the source of the communication.

[0062] In some embodiments, if the source is authorized flow 300 optionally proceeds to step 310 to further determine the contents of the communication and whether the contents areauthorized. In some embodiments, if the source is authorized flow 300 proceeds directly to step 314.

[0063] At step 310, the device determines the contents of the communication. In some embodiments, the contents of the communication are decrypted.

[0064] Flow 300 then proceeds to step 312 with analyzing the contents of the communication to determine whether the contents of the communication are authorized. For example, an approved source may nonetheless send an erroneous communication, but analysis of the contents of the communication denies the erroneous communication.

[0065] In some embodiments, the communication may not be authorized if the contents indicate values of one or more device parameters that exceed a functional threshold. For example, a communication may instruct an infusion pump to adjust the flow rate above the functional limit (e.g., the physical limit) of the infusion pump. The communication will not be authorized, even though the communication was sent by an authenticated source. If the contents indicate values of one or more treatment parameters that meet a functional threshold, the communication may be authorized. For example, a communication may instruct an infusion pump to adjust the flow rate below the functional limit (e.g., the physical limit) of the infusion pump. The communication will be authorized, because the communication was sent by an authenticated source and the contents of the communication are authorized.

[0066] In some embodiments, the communication may not be authorized based on the clinical effect of one or more treatment parameters or sensor data indicated by the contents of the communication. For example, a communication may indicate a significant change in patient status through a value change, such as a 75% change in sensor value, or in treatment, such as a 50% change in flow rate, associated with a change in clinical outcome. Where the sensor data or one or more treatment parameters do not satisfy a clinical effect threshold, the communication may not be authorized. Where the sensor data or one or more treatment parameters do satisfy a clinical effect threshold, the communication may be authorized.

[0067] In some embodiments, the communication may not be authorized based on a violation of a safety threshold by one or more treatment parameters or sensor data indicated by the contents of the communication. For example, a communication may indicate a patient status above a safety threshold, such as a sensor value not treatable by the medical device system. Where the sensor data or one or more treatment parameters do not satisfy a safety threshold, the communicationmay not be authorized. Where the sensor data or one or more treatment parameters do satisfy a safety threshold, the communication may be authorized.

[0068] In some embodiments, a clinician may manually provide or deny authorization for the communication using an input. For example, a clinician may determine a therapy is no longer needed, and a communication to start or resume the therapy may not be authorized.

[0069] In certain embodiments, the communication may be authorized based on a combination of the type of authentication used to authenticate the source and the contents of the communication. In particular, different contents, as discussed above, may be associated with requiring different types of authentication. For example, if the communication contents indicate to change one or more treatment parameters above a threshold, a first type of authentication may be required, while if the communication contents indicate to change one or more treatment parameters below the threshold, a second type of authentication may be required.

[0070] If the contents of the communication are not authorized, then flow 300 proceeds to step 320 with rejecting the communication. In some embodiments, rejecting a communication may include transmitting, to the source of the communication, an indication the communication was rejected. In some embodiments, the indication may include an instruction for the source to re-authenticate, or provide a different type of authentication, prior to subsequent communications, such as described with respect to FIG. 4.

[0071] In some embodiments, a rejection of a communication may also send an indication to a user interface, such as user interface 108 in FIG. 1, displaying the rejection. The displayed rejection may include the source of the communication, the contents of the communication, or a reason associated with the rejection.

[0072] If the contents of the communication are authorized, then flow 300 proceeds to step 314 with implementing the communication. For example, where the communication contains sensor data, such as from sensor 102 in FIG. 1, a control module may determine treatment parameters for the infusion pump. In another example, where the communication contains treatment parameters, an infusion pump, such as infusion pump 104 in FIG. 1, may adjust its settings according to the treatment parameters. In another example, where the communication contains sensor data, such as from sensor 102 in FIG. 1, an infusion pump may determine treatment parameters and operate according to the treatment parameters.

[0073] In some embodiments, such as a semi-closed loop system, implementing the communication at step 314 includes displaying the communication, such as on a user interface (e.g., user interface 108 in FIG. 1), for confirmation by a clinician.

[0074] Note that flow 300 is just one example, and other flows including fewer, additional, or alternative steps, consistent with this disclosure, are possible.Example Flowchart for Determining a Type of Authentication for a Communication

[0075] FIG. 4 depicts an example flowchart of a flow 400 for authenticating a communication from a previously authenticated source.

[0076] Initially, flow 400 begins at step 402 with receiving, at a device, a communication with data, such as sensor data or one or more treatment parameters, such described at step 302 in FIG. 3. Flow 400 proceeds to step 404 with determining, by the device, a source of the communication, such as described at step 304 in FIG. 3.

[0077] Flow 400 then proceeds to step 406 with determining, by the device, whether the source was previously authenticated, for example, by determining whether a previous communication from the source was authenticated. If at step 406 it is determined the source was not previously authenticated, then flow 400 proceeds to step 412 with authenticating, by the device, the source of the communication, such as described at step 306 in FIG. 3. If, at step 412, the source of the communication is not authenticated, flow 400 proceeds to step 420, where the communication is rejected, such as described at step 320 in FIG. 3. If, at step 412, the source of the communication is authenticated, flow 400 proceeds to step 414, with determining, by the device, whether the source is authorized, such as described at step 308 of FIG. 3.

[0078] If at step 406 it is determined the source was previously authenticated, then flow 400 proceeds to step 410 with determining, by the device, whether the authentication expired. In certain embodiments, an authentication expires based on whether the source meets one or more criteria. For example, the authentication may expire based on whether one or more parameters associated with the source meet the one or more criteria. The one or more parameters of the source may include a period of time of connectivity, a type of connection, a type of source, a source indication, criticality of the communication, etc.

[0079] A period of time of connectivity, for example, may be a length of time between a first communication from the source, and the current communication from the source. For example, source authentication may expire after a set period of time, such as 72 hours after the firstcommunication. As another example, a source authentication may expire after a source lifespan, such as a sensor with a lifespan of 8 days. As a further example, a source authentication may expire after a treatment period, such as an infusion treatment period of 3 days.

[0080] A type of connection, for example, may be the physical input over which the communication is received from the source. Authentication for a source connected by a wired connection, for example, may expire after a shorter time period because a nefarious actor would need to be physically connected to the source to intercept or send erroneous communications. Authentication for a source connected by a wireless connection, for example, may expire after a longer time period because a nefarious actor would not need to be physically connected to the source to intercept or send erroneous communications. Further, authentication for a source connected by a wireless connection with a larger connectivity range may expire after a shorter time period than authentication for a source connected by a wireless connection with a shorter connectivity range.

[0081] A type of source, for example, may include the type of data monitored (e.g., heart rate monitor, pulse oximeter, continuous glucose monitor, etc.), the type of therapy administered (e.g., insulin, cardiovascular therapy, intravenous therapy, etc.), the type of therapy administration device (e.g., infusion pump, insulin pump, respiratory assist device, etc.), and the like-LAuthentication for a first type of source, for example, a source connected to an infusion pump, may expire after a shorter time period than authentication for another type of source.

[0082] An indication sent by the source, for example, may include an indication of an error detected by the source. A source may have self-diagnostic capabilities, such as a signal quality determination or other error-detecting capabilities, to determine a possible error with the source and send an indication of the detected error to the device. An authentication for the source may expire based on receiving an indication of a detected error.

[0083] A more critical communication sent by the source, for example, may include a communication associated with a source critical to operation of the device. A critical source may provide inputs (e.g., sensor data) to the device to generate outputs (e.g., one or more treatment parameters), which may impact clinical outlook. An authentication may expire after a shorter period of time for sources sending more critical communications, and after a longer period of time for sources sending less critical communications.

[0084] In certain embodiments, an authentication expires based on a change in the system, for example, when a device is removed or added to the system, authentication for one or more sources in the system may expire.

[0085] In some embodiments, an authentication for a source may expire based on a clinician input.

[0086] If at step 410 it is determined the authentication has expired, then flow 400 proceeds to step 412 to again determine whether the source is authenticated. In some embodiments, the device sends an indication to the source, indicating the source needs to be re-authenticated by the device. In certain embodiments, the indication may further indicate to the source a different method of authentication, for example, a more secure method, is needed to authenticate the source.

[0087] If at step 410 it is determined the authentication has not expired, then the source is authenticated and flow 400 proceeds to step 414 with determining, by the device, whether the source is authorized.

[0088] If at step 414 it is determined the source is not authorized, flow 400 proceeds to step 420, where the communication is rejected.

[0089] In some embodiments, if it is determined the source is authorized at step 414, flow 400 optionally proceeds to step 416 to further determine the contents of the communication, such as described at step 310 of FIG. 3. In some embodiments, if the source is authorized, flow 400 proceeds directly to step 422.

[0090] After step 416, flow 400 proceeds to step 418 with analyzing the contents of the communication to determine whether the contents of the communication are authorized, such as described at step 312 of FIG. 3.

[0091] If at step 418 the contents of the communication are authorized, then flow 400 proceeds to step 422 with implementing the communication, such as described at step 314 of FIG. 3. In some embodiments, such as a semi-closed loop system, implementing the communication at step 422 includes displaying the communication, such as on a user interface (e.g., user interface 108 in FIG. 1), for confirmation by a clinician. If at step 418 the contents of the communication are not authorized, then flow 400 proceeds to step 420, where the communication is rejected.

[0092] Note that flow 400 is just one example, and other flows including fewer, additional, or alternative steps, consistent with this disclosure, are possible.Example Method for Authenticating Communications

[0093] FIG. 5 depicts an example method 500 for authenticating a communication received by a medical device for example, a control module, or an infusion pump, such as control module 106 or infusion pump 104 in FIG. 1.

[0094] Method 500 beings at step 502 with receiving the communication, the communication comprising first data for use by the medical device.

[0095] Method 500 then proceeds to step 504 with determining the source of the communication.

[0096] In some embodiments, determining the source of the communication comprises determining the source based on an identifier of the source included in the communication.

[0097] In some embodiments, the identifier of the source, comprises at least one of: a token; an encrypted certificate; an RFID tag; or a barcode.

[0098] Method 500 then proceeds to step 506 with authenticating the source of the communication.

[0099] In some embodiments, authenticating the source comprises: selecting a type of authentication based on the determined source; and authenticating the source using the selected type of authentication.

[0100] In some embodiments, authenticating the source of the communication comprises determining whether a previous authentication of the source is expired.

[0101] Method 500 then proceeds to step 508 with operating the medical device based on the first data and the authenticating the source of the communication.

[0102] In some embodiments, operating the medical device based on the first data and the authenticating the source of the communication, comprises: determining a first parameter to adjust an element of the medical device based on the first data; and adjusting the element of the medical device according to the first parameter.

[0103] In some embodiments, method 500 further comprises authorizing the communication, wherein operating the medical device is further based on authorizing the communication. In some embodiments, authorizing the communication comprises authorizing the source of the communication. In some embodiments, authorizing the source of the communication comprisesdetermining whether the source of the communication is indicated as approved or unapproved in a list of sources.

[0104] In some embodiments, authorizing the communication comprises authorizing the first data. In some embodiments, authorizing the first data comprises authorizing the first data based on whether the first data meets one or more thresholds. In some embodiments, the one or more thresholds are associated with a type of authentication used to authenticate the source.

[0105] Note that method 500 is just one example, and other flows including fewer, additional, or alternative steps, consistent with this disclosure, are possible.Example Processing System for a Medical Device

[0106] FIG. 6 depicts an example computing device 600 for a medical device that implements various features and processes described herein. For example, the computing device 600 may perform one or more steps of any of flows 300 or 400 or method 500. The computing device 600 may include one or more processors 604, memory 606, one or more input components 610, one or more output components 612, and one or more communication interfaces 608. Each of these components may be coupled by a bus 602.

[0107] Computing device 600 may perform these processes based on processor 604 executing software instructions stored by a computer-readable medium, such as memory 606. A computer- readable medium (e.g., a non-transitory computer-readable medium) is defined herein as a non- transitory memory device. A memory device includes memory space located inside of a single physical storage device or memory space spread across multiple physical storage devices. Software instructions may be read into memory 606 from another computer-readable medium or from another device via communication interface 608. When executed, software instructions stored in memory 606 may cause processor(s) 604 to perform one or more processes described herein.

[0108] Memory 606 may include data storage or one or more data structures (e.g., a database, etc.). Computing device 600 may be capable of receiving information from, storing information in, communicating information to, or searching information stored in the data storage or one or more data structures in memory 606.

[0109] Memory 606 may include random access memory (RAM), read only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, optical memory, etc.), that stores information and / or instructions for use by one or more processors604. For example, memory 606 may include one or more forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0110] Memory 606 may include an authentication component 614 and authorization component 616.[oni] Authentication component 614 is configured to authenticate a source transmitting a communication, such as a communication received by a medical device, according to aspects described herein.

[0112] Authorization component 616 is configured to authorize a source transmitting a communication and / or a communication, such as a communication received by a medical device according to aspects described herein.

[0113] One or more processors 604 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and / or any processing component (e.g., a field- programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), that may be programmed to perform a function, such as described herein.

[0114] One or more input components 610 may include a component that permits computing device 600 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). Further, one or more input components 610 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.).

[0115] One or more output components 612 may include a component that provides output information from computing device 600 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.).

[0116] Communication interface 608 may include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables computing device 600 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 608 may permit computing device 600 to receive information from another device and / or provide information to another device. For example, communication interface 608 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, auniversal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, and / or the like.Example Clauses

[0117] Implementation examples are described in the following numbered clauses:

[0118] Clause 1 : A method of authenticating a communication received from a source at a medical device, comprising: receiving the communication, the communication comprising first data for use by the medical device; determining the source of the communication; authenticating the source of the communication; and operating the medical device based on the first data and the authenticating the source of the communication.

[0119] Clause 2: The method of clause 1, wherein determining the source of the communication comprises determining the source based on an identifier of the source included in the communication.

[0120] Clause 3: The method of clause 2, wherein authenticating the source comprises: selecting a type of authentication based on the determined source; and authenticating the source using the selected type of authentication.

[0121] Clause 4: The method of any one of clauses 1-3, further comprising authorizing the communication, wherein operating the medical device is further based on authorizing the communication.

[0122] Clause 5: The method of any one of clauses 1-4, wherein authorizing the communication further comprises authorizing the source of the communication.

[0123] Clause 6: The method of any one of clauses 1-5, wherein authorizing the source of the communication comprises determining whether the source of the communication is indicated as approved or unapproved in a list of sources.

[0124] Clause 7: The method of any one of clauses 1-6, wherein authorizing the communication comprises authorizing the first data.

[0125] Clause 8: The method of clause 7, wherein authorizing the first data comprises authorizing the first data based on whether the first data meets one or more thresholds.

[0126] Clause 9: The method of clause 8, wherein the one or more thresholds are associated with a type of authentication used to authenticate the source.

[0127] Clause 10: The method of any one of clauses 1-9, wherein authenticating the source of the communication comprises determining whether a previous authentication of the source is expired.

[0128] Clause 11 : The method of any one of clauses 1- 10, wherein operating the medical device based on the first data and the authenticating the source of the communication, comprises: determining a first parameter to adjust an element of the medical device based on the first data; and adjusting the element of the medical device according to the first parameter.

[0129] Clause 12: A medical device system for authenticating a communication received at a medical device, comprising: one or more memories comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the medical device system to perform a method in accordance with any one of Clauses 1-11.

[0130] Clause 13: A processing system, comprising means for performing a method in accordance with any one of Clauses 1-11.

[0131] Clause 14: One or more non-transitory computer-readable media storing program code for causing a processing system to perform the steps of any one of Clauses 1-11.

[0132] Clause 15: A computer program product embodied on a computer-readable storage medium comprising code for performing a method in accordance with any one of Clauses 1-11.Additional Considerations

[0133] The preceding description is provided to enable any person skilled in the art to practice the various embodiments described herein. The examples discussed herein are not limiting of the scope, applicability, or embodiments set forth in the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments. For example, changes may be made in the function and arrangement of elements discussed without departing from the scope of the disclosure. Various examples may omit, substitute, or add various procedures or components as appropriate. For instance, the methods described may be performed in an order different from that described, and various steps may be added, omitted, or combined. Also, features described with respect to some examples may be combined in some other examples. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. In addition, the scope of the disclosure is intended to cover such an apparatus or method that is practiced using other structure, functionality, or structure and functionality in addition to, or otherthan, the various aspects of the disclosure set forth herein. It should be understood that any aspect of the disclosure disclosed herein may be embodied by one or more elements of a claim.

[0134] As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.

[0135] As used herein, a phrase referring to “at least one of’ a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiples of the same element (e.g., a-a, a-a-a, a-a-b, a-a-c, a-b-b, a-c-c, b-b, b-b-b, b-b-c, c-c, and c-c-c or any other ordering of a, b, and c).

[0136] As used herein, the term “determining” encompasses a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” may include resolving, selecting, choosing, establishing and the like.

[0137] The methods disclosed herein comprise one or more steps or actions for achieving the methods. The method steps and / or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims. Further, the various operations of methods described above may be performed by any suitable means capable of performing the corresponding functions. The means may include various hardware and / or software component(s) and / or module(s), including, but not limited to a circuit, an application specific integrated circuit (ASIC), or processor. Generally, where there are operations illustrated in figures, those operations may have corresponding counterpart means-plus-function components with similar numbering.

[0138] The following claims are not intended to be limited to the embodiments shown herein, but are to be accorded the full scope consistent with the language of the claims. Within a claim, reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. No claim element is to be construed under the provisions of 35 U.S.C. § 112(f) unless the element is expressly recited using the phrase “means for” or, in the caseof a method claim, the element is recited using the phrase “step for.” All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.

Claims

WHAT IS CLAIMED IS:

1. A medical device for authenticating a communication received at the medical device, comprising: one or more memories comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions, and cause the medical device to: receive the communication, the communication comprising first data for use by the medical device; determine a source of the communication; authenticate the source of the communication; and operate based on the first data and the authenticating of the source of the communication.

2. The medical device of claim 1, wherein to determine the source of the communication, the one or more processors are further configured to execute the computerexecutable instructions, and cause the medical device to determine the source based on an identifier of the source included in the communication.

3. The medical device of claim 2, wherein to authenticate the source the one or more processors are further configured to execute the computer-executable instructions, and cause the medical device to: select a type of authentication based on the determined source; and authenticate the source using the selected type of authentication.

4. The medical device of claim 1, wherein the one or more processors are further configured to execute the computer-executable instructions, and cause the medical device to: authorize the communication; and operate further based on authorizing the communication.

5. The medical device of claim 4, wherein to authorize the communication the one or more processors are further configured to execute the computer-executable instructions, and cause the medical device to authorize the source of the communication.

6. The medical device of claim 5, wherein to authorize the source of the communication the one or more processors are further configured to execute the computerexecutable instructions, and cause the medical device to determine whether the source of the communication is indicated as approved or unapproved in a list of sources.

7. The medical device of claim 4, wherein to authorize the communication the one or more processors are further configured to execute the computer-executable instructions, and cause the medical device to authorize the first data.

8. The medical device of claim 7, wherein to authorize the first data the one or more processors are further configured to execute the computer-executable instructions, and cause the medical device to authorize the first data based on whether the first data meets one or more thresholds.

9. The medical device of claim 8, wherein the one or more thresholds are associated with a type of authentication used to authenticate the source.

10. The medical device of claim 1, wherein to authenticate the source of the communication the one or more processors are further configured to execute the computerexecutable instructions, and cause the medical device to determine whether a previous authentication of the source is expired.

11. The medical device of claim 1, wherein to operate based on the first data and the authenticating the source of the communication, the one or more processors are further configured to execute the computer-executable instructions, and cause the medical device to: determine a first parameter to adjust of the medical device based on the first data; and adjust the first parameter.

12. The medical device of claim 11, wherein the medical device comprises an infusion pump system, and wherein the first parameter comprises a flow rate.

13. A method of authenticating a communication received from a source at a medical device, comprising:receiving the communication, the communication comprising first data for use by the medical device; determining the source of the communication; authenticating the source of the communication; and operating the medical device based on the first data and the authenticating the source of the communication.

14. The method of claim 13, wherein determining the source of the communication comprises determining the source based on an identifier of the source included in the communication.

15. The method of claim 14, wherein authenticating the source comprises: selecting a type of authentication based on the determined source; and authenticating the source using the selected type of authentication.

16. The method of claim 13, further comprising authorizing the communication, wherein operating the medical device is further based on authorizing the communication.

17. The method of claim 15, wherein authorizing the communication comprises authorizing the source of the communication.

18. The method of claim 16, wherein authorizing the source of the communication comprises determining whether the source of the communication is indicated as approved or unapproved in a list of sources.

19. The method of claim 13, wherein authorizing the communication comprises authorizing the first data.

20. The method of claim 18, wherein authorizing the first data comprises authorizing the first data based on whether the first data meets one or more thresholds.

21. The method of claim 20, wherein the one or more thresholds are associated with a type of authentication used to authenticate the source.

22. The method of claim 13, wherein authenticating the source of the communication comprises determining whether a previous authentication of the source is expired.

23. The method of claim 13, wherein operating the medical device based on the first data and the authenticating the source of the communication, comprises: determining a first parameter to adjust of the medical device based on the first data; and adjusting the first parameter.

24. The method of claim 13, wherein the medical device comprises an infusion pump, and wherein the source comprises a control module for the infusion pump.

25. The method of claim 13, wherein the medical device comprises an infusion pump, and wherein the source comprises a sensor.

26. The method of claim 13, wherein the medical device comprises a control module for an infusion pump, and wherein the source comprises a sensor.

27. A non-transitory computer-readable medium comprising instructions, which when executed by one or more processors of a medical device, cause the medical device to perform operations for authenticating a communication received from a source at the medical device, the operations comprising: receiving the communication, the communication comprising first data for use by the medical device; determining the source of the communication; authenticating the source of the communication; and operating the medical device based on the first data and the authenticating the source of the communication.

Images