Wireless communication with medical devices

Abstract

A medical device includes processing circuitry configured to: establish a communication link with a first device in accordance with a first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol; receive from the first device a second set of packets, originating from a second device, the second set of packets generated in accordance with a first client session established between the medical device and the second device and encapsulated in the first set of packets; receive from the first device a third set of packets, originating from a third device, the third set of packets generated in accordance with a second client session established between the medical device and the third device and encapsulated in the first set of packets; perform operations based on the second set of packets; and perform operations based on the third set of packets.

Description

Docket No.: A0012971W001 WIRELESS COMMUNICATION WITH MEDICAL DEVICESCROSS-RELATED REFERENCE

[0001] This application is a PCT application that claims priority to, and the benefit of, U.S. Provisional Patent Application No. 63 / 749,399, filed January 24, 2025, the entire contents of which is incorporated herein by reference.TECHNICAL FIELD

[0002] This disclosure generally relates to medical device communication.BACKGROUND

[0003] Medical devices may be external or implanted, and may be used to sense neural signals (e.g., central and peripheral nerves) and / or deliver electrical stimulation therapy to various tissue sites of a patient to treat a variety of symptoms or conditions such as, for example, one or more of chronic pain, tremor, Parkinson’s disease, other movement disorders, epilepsy, urinary or fecal incontinence, sexual dysfunction, obesity, gastroparesis, sleep apnea, neural control of prosthetic devices, or stimulation to provide peripheral sensation. The medical devices may be configured to communicate with one or more other devices to output information, as well as receive information, such as therapy parameters.SUMMARY

[0004] This disclosure describes example techniques for a medical device to communicate with a plurality of devices via one communication link with one of the devices in a manner that allows for establishing different authorization levels for the different devices, and that allows for device authentication, while ensuring data integrity. For instance, a first device may form a communication link with the medical device in accordance with a communication protocol. In addition, the first device may function as a relay device relaying communication between other devices and the medical device. In accordance with one or more examples, the medical device may establish client sessions with the other devices, as well as the first device, such as by establishing keys and using codes that allow for authorization levels for the different devices and device authentication, while ensuring data integrity. The first device may communicate with the medical device using a first set of packets formed in accordance with the first communication protocol, and these first set of packets may encapsulate packets from the other devices that are generated in accordance with the respective client sessions between the medical device and the other devices.Docket No.: A0012971W001

[0005] In one example, the disclosure describes a medical device comprising: one or more memories; and processing circuitry coupled to the one or more memories, wherein the processing circuitry is configured to: establish, via telemetry circuitry, a communication link with a first device in accordance with a first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol; receive, via the telemetry circuitry, from the first device a second set of packets, originating from a second device, the second set of packets generated in accordance with a first client session established between the medical device and the second device and encapsulated in the first set of packets; receive, via the telemetry circuitry, from the first device a third set of packets, originating from a third device, the third set of packets generated in accordance with a second client session established between the medical device and the third device and encapsulated in the first set of packets; perform a first set of operations based on the second set of packets; and perform a second set of operations based on the third set of packets.

[0006] In one example, the disclosure describes a method of communicating between devices, the method comprising: establishing, with processing circuitry of a medical device, a communication link with a first device in accordance with a first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol; receiving, with the processing circuitry and from the first device, a second set of packets, originating from a second device, the second set of packets generated in accordance with a first client session established between the medical device and the second device and encapsulated in the first set of packets; receiving, with the processing circuitry and from the first device, a third set of packets, originating from a third device, the third set of packets generated in accordance with a second client session established between the medical device and the third device and encapsulated in the first set of packets; performing, with the processing circuitry, a first set of operations based on the second set of packets; and performing, with the processing circuitry, a second set of operations based on the third set of packets.

[0007] In one example, the disclosure describes a computer-readable storage medium storing instructions thereon that when executed cause one or more processors to establish a communication link with a first device in accordance with a first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol; receive from the first device a second set of packets, originating from a second device, the second set of packets generated in accordance with a first client session established between the medical device and the second device and encapsulated in the first set of packets; receive from the first device a third set of packets, originating from a third device, the third set of packets generated in accordance with a second client session established between the medical device and the thirdDocket No.: A0012971W001 device and encapsulated in the first set of packets; perform a first set of operations based on the second set of packets; and perform a second set of operations based on the third set of packets.

[0008] The details of one or more examples of the techniques of this disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the techniques will be apparent from the description and drawings, and from the claims.BRIEF DESCRIPTION OF DRAWINGS

[0001] FIG. l is a conceptual diagram illustrating an example system including a tibial stimulation device, a handheld patient programming remote, and a clinician programmer according to one or more techniques of this disclosure.

[0002] FIG. 2 is a conceptual diagram illustrating an example system including a sacral neuromodulation device, a handheld patient programming remote, and a clinician programmer according to one or more techniques of this disclosure.

[0003] FIGS. 3A-3D are conceptual diagrams illustrating example systems to communicate with a medical device according to one or more techniques of this disclosure.

[0004] FIG. 4 is a conceptual diagram illustrating an example of a packets being encapsulated in packets of a communication protocol according to one or more techniques of this disclosure.

[0005] FIG. 5 is a block diagram illustrating an example of a medical device according to one or more techniques of this disclosure.

[0006] FIG. 6 is a block diagram illustrating an example of a device configured to communicate with a medical device according to one or more techniques of this disclosure.

[0007] FIG. 7 is a flow chart illustrating an example method of operation according to one or more techniques of this disclosure.

[0008] FIG. 8. is a flow chart illustrating another example method of operation according to one or more techniques of this disclosure.DETAILED DESCRIPTION

[0009] Some medical devices, such as implantable medical devices (IMDs) used for neuromodulation or pelvic health, may benefit from multiple communication links to other devices. However, there may be a limitation that a medical device can only support one active connection (e.g., only one communication link) for a communication protocol. For example, the medical device may establish a Bluetooth communication link with one device, and may not beDocket No.: A0012971W001 able to support two Bluetooth communication links (e.g., one Bluetooth communication link to one device, and another Bluetooth communication link with another device).

[0010] To support the medical device communicating with multiple other devices, one of the devices may function as a relay device in addition to performing other functions. For example, a charger for the medical device may recharge the medical device, and function as a relay device that establishes a communication link with the medical device, and other devices (e.g., patient programmer or clinician programmer) communicate with the medical device through the charger. As another example, a patient programmer may allow the patient to program the medical device, and function as a relay device that establishes a communication link with the medical device and a clinician programmer. Accordingly, for establishing multi-connections with devices, a relay device is typically used. The relay device is an intermediary between the medical device and other devices (e.g., distal devices), and can handle multiple connection.

[0011] This disclosure describes example techniques to facilitate communication between the medical device and the other devices in a manner that ensures that the communication is secure and also allows authentication of devices that originated the communication to support different authorization level for different devices. For instance, the end-to-end connection from a second device (e.g., distal device) to a first device (e.g., relay device), and then to a medical device should be secure (e.g., encrypted). In addition, integrity of the messages being exchanged may need to be preserved to defend against communication tampering.

[0012] In one or more examples, a medical device may include processing circuitry configured to establish a communication link with a first device (e.g., relay device or proximal device) in accordance with a first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol. For example, the medical device may establish a Transport Layer Security (TLS 1.3) connection between the medical device and the proximal, relay device (e.g., after establishing another link such as a BlueTooth link).

[0013] In addition, the medical device and a second device may establish a first client session. The medical device may receive from the first device a second set of packets, originating from the second device. The second set of packets may be generated in accordance with the first client session. For example, the medical device and the second device establish a Hash-based Message Authentication Code (HMAC) session. The medical device and a third device may also establish a second client session (e.g., an HMAC session). The medical device may receive from the first device a third set of packets, originating from the third device, and the third set of packets may be generated in accordance with the second client session.

[0014] In some examples, the first device and the second device may be the same device, and the third device may be another device. For instance, assume that a medical deviceDocket No.: A0012971W001 communicates with a patient programmer through a recharger. In this example, the recharger may be both the first device (e.g., the device with which the medical device established a TLS link) and the second device (e.g., the device whose packets are transmitted in accordance with an HMAC session established with the device). The patient programmer may be the third device.

[0015] The first device, the second device, and the third device may be different devices. For example, assume that a medical device communicates with a patient programmer through a recharger, and communicates with a clinician programmer through the recharger. In this example, the recharger may be the first device (e.g., the device with which the medical device established a TLS link). The patient programmer may be the second device, and the clinician programmer may be the third device. In one or more examples, in such a configuration, the medical device may also establish a client session (e.g., HMAC session) with the recharger.

[0016] Moreover, one of the devices with which the medical device is to communicate may be located in a different location than the medical device (e.g., remote from the medical device). For example, a clinician programmer (e.g., third device) may output using a TLS link to a cloud environment, and the cloud environment may output using a TLS link to a patient programmer (e.g., second device and first device in this example). The patient programmer may then output to the medical device. In this example, the medical device and the clinician programmer may have established one client session, and the medical device and the patient programmer may have established another client session.

[0017] A client session may refer to a communication session in which the medical device and other device established keys and agreed upon encryption techniques (e.g., hash functions) so that the medical device and the other device can communicate using packets generated in accordance with the client session (e.g., in accordance with the keys and hash functions).Accordingly, in this disclosure, when a medical device establishes a client session with one device, for that client session there may be one set of key(s) for encoding, and when the medical device establishes a client session with another device, for that client session there may be another set of key(s) for encoding. An HMAC session is one example of a client session.

[0018] By establishing the client sessions with different devices, but relaying communication through one device, the medical device may be able to authenticate from which device the packets originated, and may further be able to ensure the data integrity of the packets. For example, when the medical device receives packets, the medical device may determine which HMAC session the packets came from (e.g., originated from), and may validate the packets based on that session. Therefore, each packet is protected against tampering and each exchange between two devices (e.g., medical device and any of the other devices) is encrypted. The example techniques may provide secure multi-tenant / multi-programming capability to medicalDocket No.: A0012971W001 devices with role based differentiated authorization / authentication based on x509 credentials for each device. In other words, this means that a medical device can communicate concurrently with multiple devices (e.g., closed loop recharging with clinician programmer) and remote / distal (e.g., clinician programmer) enabling more streamlined recharge / clinician session or a remote clinician support for patients or clinicians.

[0019] Moreover, because the medical device can authenticate the originator of the packets, the medical device may perform operations based on which device originated the packets. As an example, the devices with which the medical device may establish client sessions may be associated with different authorization levels. As an example, the clinician programmer may be allowed to change a relatively large set of therapy parameters, and the patient programmer may be limited to changing a subset of the therapy parameters and within defined thresholds. A recharger may be allowed to request information (e.g., charge or temperature level), but may not change any therapy parameter. By authenticating the device that originated the packets, the medical device may confirm that the medical device is performing operations that are consistent with the authorization level of the device that originated the packets. For example, if packets that originated from a patient programmer requested the medical device to change a therapy parameter that the patient programmer is not allowed to change, the medical device may avoid changing the therapy parameter.

[0020] Accordingly, with the authentication of the authorization level of the originating device, and confirmation of the data integrity (e.g., packet integrity), the example techniques promote secure end-to-end communication. For instance, the medical device may determine a first authorization level for the second device (e.g., patient programmer or recharger) based on the second set of packets that originated from the second device, and determine a second authorization level for the third device (e.g., clinician programmer) based on the third set of packets that originated from the third device. The medical device may determine that the medical device is to perform a first set of operations based on the first authorization level, and perform the first set of operations based on the determination that the medical device is to perform the first set of operations (e.g., confirm that the second device is authorized to cause the medical device to perform the first set of operations). Similarly, the medical device may determine that the medical device is to perform the second set of operations based on the second authorization level, and perform the second set of operations based on the determination that the medical device is to perform the second set of operations (e.g., confirm that the third device is authorized to cause the medical device to perform the second set of operations).

[0021] As another example, the medical device may determine a data integrity of the second set of packets, that originated from the second device, indicative of whether the second set ofDocket No.: A0012971W001 packets changed, and determine a data integrity of the third set of packets, that originated from the third device, indicative of whether the third set of packets changed. The medical device may determine that the medical device is to perform a first set of operations based on the determination that the second set of packets did not change, and perform the first set of operations based on the determination that the medical device is to perform the first set of operations. Similarly, the medical device may determine that the medical device is to perform second set of operations based on the determination that the third set of packets did not change, and perform the second set of operations based on the determination that the medical device is to perform the second set of operations.

[0022] FIG. l is a conceptual diagram illustrating an example system including a tibial stimulation device 100, a handheld patient programming remote 104, and a clinician programmer 102 according to one or more techniques of this disclosure. Tibial stimulation device 100 may also be referred to as an implantable medical device (IMD) 100. For ease of description, the examples are described with respect to IMD 100, but the techniques should not be considered limited to implantable medical devices and may be applicable to medical devices generally.

[0023] Clinician programmer 102 and patient programmer 104 may be configured to control the operation of IMD 100. In some examples, a clinician may use clinician programmer 102 to program IMD 100 periodically, e.g., during clinic visits or remotely in response to a patient request or other stimulus. In some examples, clinician programmer 102 may communicate with IMD 100 to download recorded data, to adjust one or more therapy settings, etc. Clinician programmer 102 may include a housing to enclose operational components such as a processor, memory, user interface, telemetry circuitry, and power source. In some examples, a patient may use patient programmer 104 to power IMD 100 on and off or to enable or disable a scheduled therapy. Examples of clinician programmer 102 or patient programmer 104 include a tablet computer, laptop, a smartphone, a dedicated handheld device, or other similar computing devices.

[0024] In some examples, clinician programmer 102 may have relatively greater control over the operation of IMD 100 than patient programmer 104 or the user device. For example, the clinician may set one or more stimulation amplitude limits and / or set a therapy schedule using clinician programmer 102, and the patient may be able to adjust therapy within the limits and / or disable a scheduled therapy via patient programmer 104.

[0025] In the example of FIG. 1, in addition to providing functionality of a patient programmer, patient programmer 104 may also function as a relay device. For instance, clinician programmer 102 may not directly communicate with IMD 100, but instead communicates with IMD 100 through patient programmer 104. There may be various scenarios where patientDocket No.: A0012971W001 programmer 104 may function as a relay device for clinician programmer 102. As one example, clinician programmer 102 may be remote, such as in a different location, than the patient. In this case, for clinician programmer 102 to access IMD 100, clinician programmer 102 may utilize an intermediary device for relaying communication to and from IMD 100. Patient programmer 104 may function as such an intermediary device (e.g., relay device).

[0026] As another example, IMD 100 may be limited in the number of communication links IMD 100 can establish. For instance, IMD 100 may be limited to establish only one BlueTooth link. In the example of FIG. 1, IMD 100 may establish the BlueTooth link with patient programmer 104. In this case, even if clinician programmer 102 is proximate to the patient, clinician programmer 102 may communicate with IMD 100 through the BlueTooth link established using patient programmer 104. In this example, patient programmer 104 may not be limited to only one BlueTooth communication link, but may support multiple BlueTooth communication links.

[0027] Furthermore, in some examples, instead of patient programmer 104, IMD 100 may establish a BlueTooth communication link with a recharger (not shown) of IMD 100. The recharger may function as the intermediary (e.g., relay) device. For example, both patient programmer 104 and clinician programmer 102 may communicate with IMD 100 through the recharger. In addition, the recharger may communicate with IMD 100.

[0028] As described above, IMD 100 may be configured to communicate with multiple devices, but may have only one communication link in accordance with a communication protocol (e.g., BlueTooth or BLE) with one device. However, it may be desirable to have to end-to-end security to ensure that IMD 100 is performing operations in accordance with authorization levels of the different devices, and to ensure that there is no tampering of packets that originated from the different devices communicating with IMD 100.

[0029] In accordance with one or more examples, IMD 100 may be configured to establish client sessions with each of the devices (e.g., clients) that IMD 100 is to communicate with. A client session may refer to IMD 100 and a device establishing keys and / or codes to enable IMD 100 to determine from which device packets originated and / or ensure data integrity. One example of a client session is a Hash-based Message Authentication Code (HMAC) session. However, the techniques should not be considered limited to HMAC sessions. Examples of a client session may be any manner in which IMD 100 can authenticate the originator of packets and / or ensure data integrity.

[0030] In one or more examples, IMD 100 may also establish a client session (e.g., HMAC session) with the device with which IMD 100 also established a communication link in accordance with a communication protocol (e.g., BlueTooth or BLE). For instance, in theDocket No.: A0012971W001 example of FIG. 1, IMD 100 may establish a first client session with patient programmer 104 and a second client session with clinician programmer 102. Patient programmer 104 and IMD 100 may also communicate using transport layer security (TLS) cryptographic protocol of the BlueTooth or BLE. That is, patient programmer 104 and IMD 100 may first establish a BLE link, and then communicate using the TLS protocol.

[0031] In one or more examples, patient programmer 104 may transmit a first set of packets to IMD 100 that are formed in accordance with the communication protocol (e.g., TLS). IMD 100 may receive from patient programmer 104 a second set of packets, originating from patient programmer 104. The second set of packets may be generated in accordance with a first client session (e.g., first HMAC session) established between IMD 100 and patient programmer 104 and encapsulated in the first set of packets. IMD 100 may receive from patient programmer 104 a third set of packets, originating from clinician programmer 102. The third set of packets may be generated in accordance with a second client session (e.g., second client session) established between IMD 100 and clinician programmer 102 and encapsulated in the first set of packets.

[0032] IMD 100 may perform a first set of operations based on the second set of packets (e.g., from patient programmer 104), and perform a second set of operations based on the third set of packets (e.g., from clinician programmer 102). In this example, the types of operations that IMD 100 is allowed to perform may be based on the authorization level of patient programmer 104 and clinician programmer 102, such as where clinician programmer 102 is allowed to change more therapy parameters than patient programmer 104. In one or more examples, using the client sessions, established using techniques of this disclosure, IMD 100 may be configured to determine (e.g., authenticate) the originator of the second set of packets and the third set of packets to ensure that IMD 100 is performing operations consistent with the authorization levels of clinician programmer 102 and patient programmer 104. Moreover, using the client sessions, established using techniques of this disclosure, IMD 100 may be configured to determine the data integrity (e.g., packet integrity) of the second set of packets and the third set of packets to ensure that there was no tampering.

[0033] The example of FIG. 1 is a side view of a patient’s leg 106 showing IMD 100 near the ankle and adjacent to the tibial nerve 108. IMD 100 is a leadless neurostimulation device in the example of FIG. 1. IMD 100 can be implanted through the patient’s skin and cutaneous fat layer via a small incision (e.g., about one to three cm) above the tibial nerve 108 on a medial aspect of the patient’s ankle. While the incision may be approximately horizontal to the length of the tibial nerve 108, other incisions or implantation techniques could be used according to physician preference. The example of FIG. 1 describes a neurostimulation implantable medical device for tibial nerve stimulation.Docket No.: A0012971W001

[0034] In the example of FIG. 1, IMD 100 may be positioned adjacent to the region defined by flexor digitorum longus and soleus in which tibial nerve 108 is contained and implanted adjacent and proximal to a fascia layer. One or more electrodes of IMD 100 may face toward tibial nerve 108. Though not shown in FIG. 1, IMD 100 may also connect to one or more leads comprising one or more electrodes (not shown in FIG. 1). In other examples, IMD 100 may include a lead which goes sub-fascia and is more directly proximal to the tibial nerve.

[0035] IMD 100 may be constructed of any polymer, metal, or composite material sufficient to house the components of IMD 100. In this example, IMD 100 may be constructed with a biocompatible housing, such as titanium or stainless steel, or a polymeric material such as silicone or polyurethane, and surgically implanted at a site in patient near the tibial nerve 108. The housing of IMD 100 may be configured to provide a hermetic seal for components, such as a rechargeable power source or a primary coin cell battery. In addition, the housing of IMD 100 may be selected of a material that facilitates receiving energy to charge the rechargeable power source.

[0036] While providing therapy, an electrical stimulation signal may be transmitted between one or more electrodes through the fascia layer. The electrical signal may be used to stimulate tibial nerve 108 which may be useful in the treatment of overactive bladder (OAB) symptoms of urinary urgency, urinary frequency and / or urge incontinence, fecal incontinence, pain, or other symptoms. The example of FIG. 1 may help relieve some symptoms of some disorders.

[0037] One type of therapy for treating bladder dysfunction includes delivery of electrical stimulation to a target tissue site within a patient to cause a therapeutic effect during delivery of the electrical stimulation. For example, delivery of electrical stimulation from IMD 100 to a target therapy site, e.g., a tissue site that delivers stimulation to modulate activity of a tibial nerve, spinal nerve (e.g., a sacral nerve), a pudendal nerve, dorsal genital nerve, an inferior rectal nerve, a perineal nerve, or branches of any of the aforementioned nerves, may provide a therapeutic effect for bladder dysfunction, such as a desired reduction in frequency of bladder contractions. In some cases, electrical stimulation of the tibial nerve may modulate afferent nerve activities to restore urinary function.

[0038] In some examples, IMD 100 may deliver neurostimulation therapy in a non-continuous manner which may include on-cycles and off-cycles. For example, an IMD 100 may deliver neurostimulation therapy for a specified period of time followed by a specified period of time when the IMD 100 does not deliver neurostimulation (e.g., withholds delivery of neurostimulation). A period during which stimulation is delivered (an on-cycle) may include on and off periods (e.g., a duty cycle or bursts of pulses) with short inter-pulse durations of time when pulses are not delivered.Docket No.: A0012971W001

[0039] The power source of IMD 100 may include one or more capacitors, e.g., supercapacitors, batteries, or other components (e.g., chemical, or electrical energy storage devices). Example batteries may include lithium-based batteries, nickel metal-hydride batteries, or other materials. In some examples, the power source may be a primary cell battery that is replaced when depleted. In other examples, the power source may be rechargeable. The rechargeable power source may be replenished, refilled, or otherwise capable of increasing the amount of energy stored after energy has been depleted.

[0040] Patient programmerl04 may be configured to enable or disable a scheduled therapy to be delivered by IMD 100, to power IMD 100 therapy on and off, or to wake up IMD 100 from an idle state, to facilitate a wireless connection, e.g., a Bluetooth® or Bluetooth® Low Energy (BLE) connection. Patient programmer 104 may also receive information from IMD 100, such as sensed signals, temperature, errors, etc.

[0041] FIG. 2 is a conceptual diagram illustrating an example system including an SCS device, e.g., a sacral neuromodulation (SNM) device 220, patient programmer 212, and a clinician programmer 210 according to one or more techniques of this disclosure. In the illustrated example, SNM device 220 is an electrical stimulator. Accordingly, although therapy system 200 and SNM device 220 are referenced throughout the remainder of the disclosure for purposes of illustration, therapy system 200 and SNM device 220, in accordance with the disclosure, may be adapted for use in a variety of applications.

[0042] Clinician programmer 210 may be similar to clinician programmer 102 of FIG. 1 in some respects, and patient programmer 212 may be similar to or the same as patient programmer 104 of FIG. 1. Clinician programmer 210 may interact with patient programmer 212 in a similar manner to the manner described with respect to clinician programmer 102 and handheld patient programming remote 104. Patient programmer 212 may interact with SNM device 220 in a similar or the same manner as described with respect to patient programmer 104 and IMD 100.

[0043] For example, patient programmer 212 may provide patient programming functionality, and in addition function as a relay device for clinician programmer 210. For instance, clinician programmer 210 may communicate with SNM device 220 through patient programmer 212. SNM device 220 may establish a communication link with patient programmer 212 using a communication protocol, and establish client sessions one patient programmer 212 and clinician programmer 210 to allow for secure end-to-end communication allowing for performing operations consistent with authorization levels, and ensuring data integrity.

[0044] For example, SNM device 220 may establish a communication link with patient programmer 212 in accordance a first communication protocol (e.g., TLS) for receiving a first set of packets formed in accordance with the first communication protocol. SNM device 220 mayDocket No.: A0012971W001 receive from the patient programmer 212 a second set of packets, originating from patient programmer 212. The second set of packets may be generated in accordance with a first client session (e.g., first HMAC sessions) established between SNM device 220 and patient programmer 212 and encapsulated in the first set of packets. SNM device 220 may also receive from patient programmer 212 a third set of packets, originating from clinician programmer 210. The third set of packets may be generated in accordance with a second client session (e.g., second HMAC session) established between SNM device 220 and clinician programmer 210 and encapsulated in the first set of packets.

[0045] SNM device 220 may perform a first set of operations based on the second set of packets, and perform a second set of operations based on the third set of packets. For example, the first set of operations may be a response to a request for certain information from SNM device 220. The second set of operations may be changing therapy parameters that are only allowed to be changed using clinician programmer 210.

[0046] Accordingly, clinician programmer 210 and patient programmer 212 may be configured to control the operation of SNM device 220. In some examples, the clinician may use clinician programmer 210 to program SNM device 220 periodically, e.g., during clinic visits or remotely in response to a patient request or other stimulus. In some examples, clinician programmer 102 may communicate with SNM device 220 to download recorded data, to adjust one or more therapy settings, etc. Clinician programmer 210 may include a housing to enclose operational components such as a processor, memory, user interface, telemetry circuitry, and power source. Examples of clinician programmer 210 and patient programmer 212 include a tablet computer, laptop, a smartphone, a dedicated handheld device, or other similar computing devices.

[0047] SNM device 220 is coupled to stimulation lead 214 and provides a programmable stimulation signal (e.g., in the form of electrical pulses or substantially continuous-time signals) to target stimulation site 208 via stimulation lead 214. More particularly, the programmable stimulation signal is delivered to target stimulation site 208 via one or more stimulation electrodes carried by lead 214. In some embodiments, lead 214 may also carry one or more sense electrodes to permit SNM device 220 to sense electrical signals from target stimulation site 208. Stimulation delivery and sensing may occur via the same electrodes, in some embodiments. Proximal end 216A of lead 214 may be both electrically and mechanically coupled to connector 218 of SNM device 220 either directly or indirectly (e.g., via a lead extension). In particular, conductors disposed in the lead body of lead 214 may electrically connect stimulation electrodes (and sense electrodes, if present) adjacent to distal end 216B of lead 214 to SNM device 220.Docket No.: A0012971W001

[0048] SNM device 220 may be subcutaneously implanted in the body of a patient 202 (e.g., in a chest cavity, lower back, lower abdomen, or buttocks of patient 202). In the example of FIG.2, SNM device 220 is a neurostimulator that is implanted in patient 202 proximate to target stimulation site 208. SNM device 220 may also be referred to as a signal generator, and in the example shown in FIG. 2, SNM device 220 may also be referred to as a neurostimulator. The configuration of SNM device 220 and lead 214 shown in FIG. 2 is merely exemplary. For example, in some examples, SNM device 220 may be coupled to two or more leads, e.g., for bilateral or multi-lateral stimulation.

[0049] In the example of therapy system 200 shown in FIG. 2, target stimulation site 208 is proximate to the S3 sacral nerve, and lead 214 has been introduced into the S3 sacral foramen 206 of sacrum 204 to access the S3 sacral nerve. Stimulation of the S3 sacral nerve may help treat pelvic floor disorders, urinary control disorders, fecal control disorders, interstitial cystitis, sexual dysfunction, and pelvic pain.

[0050] Therapy system 200 may additionally or alternatively be used to provide stimulation therapy to other nerves or tissue sites of a patient. In some examples, target stimulation site 208 may be a location proximate to any of the other sacral nerves in patient 202 or any other suitable nerve, organ, muscle, muscle group or another suitable tissue site in patient 202, which may be selected based on, for example, the symptoms or medical condition of a particular patient. For example, therapy system 200 may be used to deliver neurostimulation therapy to a pudendal nerve, a perineal nerve or other areas of the nervous system, in which cases, lead 214 would be implanted and substantially fixed proximate to the respective nerve. As further examples, lead 214 may be positioned for temporary or chronic SCS for the treatment of pain, for peripheral neuropathy or post-operative pain mitigation, ilioinguinal nerve stimulation, intercostal nerve stimulation, gastric stimulation for the treatment of gastric mobility disorders and obesity, muscle stimulation (e.g., functional electrical stimulation (FES) of muscles), for mitigation of other peripheral and localized pain (e.g., leg pain or back pain), or for deep brain stimulation to treat movement disorders and other neurological disorders.

[0051] While the example systems provided in FIGS. 1 and 2 are directed to internal neurostimulation systems (INS) (e.g., IMD 100 and SNM device 220 are implantable medical devices), the techniques of this disclosure are not so limited. The INS systems of FIGS. 1 and 2 merely serve as examples of types of medical devices that a patient programmer, e.g., patient programmer 104 or patient programmer 212 may communicate with. The medical devices may be configured to establish communication links with other devices as well, such as a recharger, and the recharger may function as a relay device.Docket No.: A0012971W001

[0052] As another example, one or more of the first, second and / or third devices may be configured to establish communication links with a fourth device, which is a patient-provided personal device, such as a smartphone, tablet computer, laptop, or other mobile computing platform (“bring-your-own-device” or BYOD). A patient-facing software application is installed on the patient-provided personal device. In some embodiments, a patient-provided personal device may be the first, second and / or third device. In some embodiments, the patient programmer is a patient-provided personal device.

[0053] In other examples, the techniques of this disclosure may apply to other medical devices without limitation. In other words, the techniques of this disclosure may apply to any medical device system in which a patient may control or adjust therapy using a programming remote.

[0054] FIGS. 3A-3D are conceptual diagrams illustrating example systems to communicate with a medical device according to one or more techniques of this disclosure. FIG. 3 A illustrates patient programmer 300, recharger 302, and medical device 304. Patient programmer 300 may be similar to patient programmer 104 or patient programmer 212. Recharger 302 may be recharger of medical device 304 that provides inductive coupling to recharge a battery of medical device 304. Medical device 304 may be similar to IMD 100 or SNM device 220. Any of the illustrated patient program mer(s) may be a patient-provided personal device. In some embodiments, such embodiments include a patient-provided personal device(s) in addition to a patient programmer(s).

[0055] FIG. 3B illustrates clinician programmer 306, cloud environment 308, and medical device 310. Clinician programmer 306 may be similar to clinician programmer 102 or clinician programmer 210. Cloud environment 308 may be distributed computing environment that includes one or more servers. In some examples, cloud environment 308 may be any router or switches that are used to route traffic to and from clinician programmer 306. Medical device 310 may be similar to IMD 100 or SNM device 220.

[0056] FIG. 3C illustrates patient programmer 312, clinician programmer 314, recharger 316, and medical device 318. Patient programmer 312 may be similar to patient programmer 104 or patient programmer 212. Clinician programmer 314 may be similar to clinician programmer 102 or clinician programmer 210. Recharger 316 may be recharger of medical device 318 that provides inductive coupling to recharge a battery of medical device 318. Medical device 318 may be similar to IMD 100 or SNM device 220.

[0057] FIG. 3D illustrates patient support system 320, which may be a web portal or other system to provide patient support. For instance, patient support system 320 may be a digital twin of the patient used to estimate efficacy of treatment in a digital setting. Patient support systemDocket No.: A0012971W001 320 may be a server that stores relevant information that a clinician can query. There may be other examples of patient support system 320. FIG. 3D also illustrates clinician programmer 322, cloud 308 (similar to FIG. 3B), patient programmer 324, and medical device 326. Similar to above, patient programmer 324 may be similar to patient programmer 104 or patient programmer 212. Clinician programmer 322 may be similar to clinician programmer 102 or clinician programmer 210. Medical device 326 may be similar to IMD 100 or SNM device 220.

[0058] In FIGS. 3A-3D, medical device 304, 310, 318, or 326 may establish a TLS communication link with recharger 302, patient programmer 309, recharger 316, or patient programmer 324, respectively, based on a telemetry credential. For example, medical device 304, 310, 318, or 326 may accept one and only one TLS communication link. In one or more examples, medical device 304, 310, 318, or 326 may first establish a radio frequency (RF) communication as BLE with recharger 302, patient programmer 309, recharger 316, or patient programmer 324, and then establish the TLS communication link as part of the BLE.

[0059] All client sessions may run over the single TLS communication link concurrently. For example, within each respective TLS link, medical device 304 and recharger 302 may establish an independent client session (e.g., HMAC session 0 of FIG. 3 A), medical device 310 and patient programmer 309 may establish an independent client session (e.g., HMAC session 0 of FIG. 3B), medical device 318 and recharger 316 may establish an independent client session (e.g., HMAC session 0 of FIG. 3C), and medical device 326 and patient programmer 324 may establish an independent client session (e.g., HMAC session 0 of FIG. 3D). Using respective TLS links, medical device 304 and patient programmer 300 may also an independent client session (e.g., HMAC session 1 of FIG. 3 A), and medical device 310 and clinician programmer 306 may establish an independent client session (e.g., HMAC session 1 of FIG. 3B). Medical device 318 and clinician programmer 314 may establish an independent client session (e.g., HMAC session 1 of FIG. 3C), and medical device 318 and patient programmer 312 may establish an independent client session (e.g., HMAC session 2 of FIG. 3C). Medical device 326 and clinician programmer 322 may establish an independent client session (e.g., HMAC session 1 of FIG. 3D), and medical device 326 and patient support system 320 may establish an independent client session (e.g., HMAC session 2 of FIG. 3D).

[0060] Each of medical devices 304, 310, 318, and 326 may be configured to support no fewer than two client (e.g., HMAC) sessions. The first client session may be between the medical device and the device with which the medical device established the TLS communication link, and the second client session may be between the medical device and a device that is using the device with the TLS communication link as a relay device. In some examples, there may be no other distinguishing characteristics between the various clientDocket No.: A0012971W001 sessions other than key or identification information. That is, each of the client sessions may be equally functional or capable.

[0061] In FIG. 3 A, patient programmer 300 may establish a BLE or Universal Serial Bus (USB) connection with recharger 302, and recharger 302 may transmit packets from patient programmer 300 as part of HMAC session 1 and transmit packets from recharger 302 as part of HMAC session 0. The packets of HMAC session 0 and HMAC session 1 may be encapsulated as part of the packets of TLS communication between recharger 302 and medical device 304.

[0062] In FIG. 3B, clinician programmer 306 may establish TLS link with cloud environment 308, and cloud environment 308 may establish a TLS link with patient programmer 309 (e.g., through WiFi). Patient programmer 309 may transmit packets from clinician programmer 306 as part of HMAC session 1 and transmit packets from patient programmer 309 as part of HMAC session 0. The packets of HMAC session 0 and HMAC session 1 may be encapsulated as part of the packets of TLS communication between patient programmer 309 and medical device 310.

[0063] In FIG. 3C, patient programmer 312 may establish a BLE or USB connection with recharger 316, and clinician programmer 314 may establish a BLE or USB connection with recharger 316. That is, although medical device 318 may establish only one BLE link, recharger 316, patient programmer 312, and / or clinician programmer 314 may be configured to support multiple BLE links. Recharger 316 may transmit packets from clinician programmer 314 as part of HMAC session 1, transmit packets from patient programmer 312 as part of HMAC session 2, and transmit packets from recharger 316 as part of HMAC session 0. The packets of HMAC session 0, HMAC session 1, and HMAC session 2 may be encapsulated as part of the packets of TLS communication between recharger 316 and medical device 318.

[0064] In FIG. 3D, clinician programmer 322 and patient support system 320 may establish a TLS link with cloud environment 308, and cloud environment 308 may establish a TLS link with patient programmer 324 (e.g., through WiFi). Patient programmer 324 may transmit packets from clinician programmer 322 as part of HMAC session 1, transmit packets from patient support system 320 as part of HMAC session 2, and transmit packets from patient programmer 324 as part of HMAC session 0. The packets of HMAC session 0, HMAC session 1, and HMAC session 2 may be encapsulated as part of the packets of TLS communication between patient programmer 324 and medical device 310.

[0065] HMAC sessions are described as an example of a client session because HMAC sessions may facilitate authentication of which device transmitted packets and / or supports data integrity validation. HMAC sessions may be based on key -based security (e.g., a secret key known only to the sender and the receiver) and hash functioning (e.g., cryptographic hash function like SHA-256, SHA-512, etc.). In some examples, the HMAC sessions may be RFCDocket No.: A0012971W001 2104 HMAC sessions. With the TLS link between medical device 304 and recharger 302, medical device 304 and recharger 302 may share the key used for HMAC session 0, and medical device 304 and patient programmer 300 may share the key used for HMAC session 1. With the TLS link between medical device 310 and patient programmer 309, medical device 310 and patient programmer 309 may share the key used for HMAC session 0, and medical device 310 and clinician programmer 306 may share the key used for HMAC session 1. With the TLS link between medical device 318 and recharger 316, medical device 318 and recharger 316 may share the key used for HMAC session 0, medical device 318 and clinician programmer 314 may share the key used for HMAC session 1, and medical device 318 and patient programmer 312 may share the key used for HMAC session 2. With the TLS link between medical device 326 and patient programmer 324, medical device 326 and patient programmer 324 may share the key used for HMAC session 0, medical device 326 and clinician programmer 322 may share the key used for HMAC session 1, and medical device 326 and patient support system 320 may share the key used for HMAC session 2.

[0066] Accordingly, without the respective shared keys, an attacker may not be able to produce a valid packet in accordance with the specific HMAC session, which means that the HMAC session is effective for authenticating messages or sessions. Also, due to the shared keys, unauthorized changes to the packets may not be possible. For example, for any packets from patient programmer 300, medical device 304 may recompute the hash using the shared key, and if the recomputed hash is the same as the hash created by patient programmer 300, medical device 304 may determine that data integrity is preserved.

[0067] In one or more examples, each client session may be differentiated with 1) an authorization level, which may be established using telemetry certificate, 2) an identification value used to identify the stream, 3) a HMAC key used to generate / verify authenticated HMACs for messages, and 4) an anti-replay rolling counter. Each telemetry message may include 1) a client session HMAC ID, 2) an authenticated HMAC, 3) message counter, and 4) message payload. The message payload may be defined by device transmitting the packets. The identification value used to identify the stream for client differentiation may be the same as a client session HMAC ID in the telemetry message. The anti-replay rolling counter for client differentiation may be the same as the message counter in the telemetry message.

[0068] For instance, medical device 304 may establish HMAC session 0 with recharger 302 and establish HMAC session 1 with patient programmer 300. For both HMAC session 0 with recharger 302 and HMAC session 1 with patient programmer 300, medical device 304 may determine a session identification value (e.g., session ID). For instance, HMAC session 0 with recharger 302 may be associated with a first session identification value, and HMAC session 1Docket No.: A0012971W001 with patient programmer 300 may be associated with a second identification value. Recharger 302 may include the first session identification value in the packets originating from recharger 302, and patient programmer 300 may include the second session identification value in packets originating from patient programmer 300.

[0069] In addition, for establishing the HMAC session 0, medical device 304 may determine a first authorization role for recharger 302, which may be determined from telemetry credentials. For example, when recharger 302 (e.g., a client device) establishes a TLS connection with medical device 304, the client (e.g., recharger 302) may exchange an X.509 “telemetry certificate.” This telemetry certificate includes a field that defines the authentication role of the client (e.g., authentication role of recharger 302). Medical device 304 may extract the role field from the telemetry certificate and identify the authentication role of the client (e.g., authentication role of recharger 302).

[0070] For HMAC session 0, medical device 304 may also determine a first HMAC key to verify data integrity of the packets sent by recharger 302. Similarly, for establishing the HMAC session 1, medical device 304 may determine a second authorization role for patient programmer 300, which may be determined from telemetry credentials. For HMAC session 1, medical device 304 may also determine a second HMAC key to verify data integrity of the packets sent by patient programmer 300.

[0071] There may be various ways in which to determine the first HMAC key and the second HMAC key. As one example, medical device 304 and recharger 302 may determine the first HMAC key using an initialization vector (IV) for medical device 304 and recharger 302, and use the Elliptic-curve Diffie-Hellman (ECDH) key agreement protocol to establish the shared key (e.g., the first HMAC key). Medical device 304 and patient programmer 300 may determine the second HMAC key using an initialization vector (IV) for medical device 304 and patient programmer 300, and use the ECDH key agreement protocol to establish the shared key (e.g., the second HMAC key).

[0072] In some examples, as part of establishing a client session for HMAC session 0, recharger 302 may include a rolling counter to prevent an attacker from repeating a message and either confusing recharger 302 or modifying the programming of medical device 304 maliciously. Similarly, as part of establishing a client session for HMAC session 1, patient programmer 300 may include a rolling counter to prevent an attacker from repeating a message and either confusing programmer 300 or modifying the programming of medical device 304 maliciously. The use of the rolling counter may be optional.

[0073] With the established client sessions (e.g., first HMAC session between medical device 304 and recharger 302 and second HMAC session between medical device 304 and patientDocket No.: A0012971W001 programmer 300), recharger 302 and patient programmer 300 may transmit packets to medical device 304. The packets may include the session identification value. For example, the packets from recharger 302 may include the first session identification value indicating that the packet originated from recharger 302, and the packets from patient programmer 300 may include the second session identification value indicating that the packet originated from patient programmer 300.

[0074] The packets from recharger 302 may also include a first payload and a first authenticated HMAC. In some examples, the first payload may define the operations that medical device 304 is to perform, which may be a request for temperature and battery level from recharger 302. Medical device 304 may utilize the authenticated HMAC to confirm the data integrity of the packets. For example, medical device 304 may determine a hash value for the first payload using the first HMAC key, and compare the resulting hash value to the authenticated HMAC included in the packets from recharger 302. If the hash value and the authenticated HMAC are the same, medical device 304 may determine that the packets have not changed. If the hash value and the authenticated HMAC are not the same, medical device 304 may determine that the packets have changed, and may avoid performing operations based on the first payload.

[0075] The packets from patient programmer 300 may include a second payload and a second authenticated HMAC. In some examples, the second payload may define the operations that medical device 304 is to perform, which may be a change in therapy parameters or a request for sensed data. Medical device 304 may utilize the authenticated HMAC to confirm the data integrity of the packets. For example, medical device 304 may determine a hash value for the second payload using the second HMAC key, and compare the resulting hash value to the authenticated HMAC included in the packets from patient programmer 300. If the hash value and the authenticated HMAC are the same, medical device 304 may determine that the packets have not changed. If the hash value and the authenticated HMAC are not the same, medical device 304 may determine that the packets have changed, and may avoid performing operations based on the second payload.

[0076] In some examples, the packets may include a counter value if rolling counters are being used. In such cases, medical device 304 may determine the hash value using both the counter value and the payload.

[0077] As described above, the packets may include session identification values. Medical device 304 may use the session identification values to determine authorization levels. For instance, in FIG. 3A, patient programmer 300 may have a higher authorization level (e.g., authorized to cause medical device 304 more functions) than recharger 302. As also describedDocket No.: A0012971W001 above, during establishing of the first client session (e.g., HMAC session 0), medical device 304 may determine a first session identification value for recharger 302, and determine a first authorization role for recharger 302 from establishing a first telemetry certificate with recharger 302. Medical device 304 may determine the first authorization level of recharger 302 based on a determination that the packets originated from recharger 302 based on the first session identification value and that recharger 302 has the first authorization role.

[0078] Similarly, during establishing of the second client session (e.g., HMAC session 1), medical device 304 may determine a second session identification value for patient programmer 300, and determine a second authorization role for patient programmer 300 from establishing a second telemetry certificate with patient programmer 300. Medical device 300 may determine the second authorization level based on a determination that the packets originated from patient programmer 300 based on the second session identification value and that patient programmer 300 has the second authorization role.

[0079] Medical device 304 may utilize the authorization levels to determine whether to perform a particular operation or not. For example, to perform a first set of operations defined by recharger 302, medical device 304 may determine that medical device 304 is to perform the first set of operations based on the first authorization level (e.g., the operations are consistent with the authorization level of recharger 302). Medical device 304 may perform the first set of operations based on the determination that medical device 304 is to perform the first set of operations. If, however, medical device 304 determined that medical device 304 is not to perform the first set of operations based on the first authorization level (e.g., the operations are not consistent with the authorization level of recharger 302), medical device 304 may avoid performing the first set of operations.

[0080] Similarly, to perform a second set of operations defined by patient programmer 300, medical device 304 may determine that medical device 304 is to perform the second set of operations based on the second authorization level (e.g., the operations are consistent with the authorization level of patient programmer 300). Medical device 304 may perform the second set of operations based on the determination that medical device 304 is to perform the second set of operations. If, however, medical device 304 determined that medical device 304 is not to perform the second set of operations based on the second authorization level (e.g., the operations are not consistent with the authorization level of patient programmer 300), medical device 304 may avoid performing the second set of operations. Medical device 304 may store information indicative of which operations are permissible for which device to determine whether operations are consistent with the authorization level of devices that are outputting packets to medical device 304.Docket No.: A0012971W001

[0081] The above is described with respect to FIG. 3 A and medical device 304. Medical devices 310 and medical device 318 may operate in a substantially similar manner. For instance, any of medical devices 304, 310, and 318 may be configured to establish a communication link with a first device (e.g., recharger 302, patient programmer 309, or recharger 316) in accordance a first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol. That is, medical device 304 may receive the first set of packets in accordance with the TLS communication link with recharger 302, medical device 310 may receive the first set of packets in accordance with the TLS communication link with patient programmer 309, and medical device 318 may the first set of packets in accordance with the TLS communication link with recharger 316.

[0082] The medical device may receive from the first device a second set of packets, originating from a second device, the second set of packets generated in accordance with a first client session established between the medical device and the second device and encapsulated in the first set of packets. In some examples, the first device and the second device from above may be the same device. As an example, medical device 304 may receive from the first device (e.g., recharger 302) a second set of packets, originating from a second device (e.g., recharger 302). The second set of packets may be generated in accordance with a first client session (e.g., HMAC session 0) between medical device 304 and the second device (e.g., recharger 302) and encapsulated in the first set of packets from recharger 302.

[0083] In some examples, the first device and the second device from above may be different devices. As an example, medical device 318 may receive from the first device (e.g., recharger 316) a second set of packets, originating from a second device (e.g., patient programmer 312). The second set of packets may be generated in accordance with a first client session (e.g., the HMAC session 2) between medical device 318 and the second device (e.g., patient programmer 312) and encapsulated in the first set of packets from recharger 316.

[0084] The medical device may receive from the first device a third set of packets, originating from a third device, the third set of packets generated in accordance with a second client session established between the medical device and the third device and encapsulated in the first set of packets. As an example, medical device 304 may receive from the first device (e.g., recharger 302) a third set of packets, originating from a third device (e.g., patient programmer 300). The third set of packets may be generated in accordance with a second client session (e.g., HMAC session 1) between medical device 304 and the third device (e.g., patient programmer 300) and encapsulated in the first set of packets from recharger 302.

[0085] As another example, medical device 318 may receive from the first device (e.g., recharger 316) a third set of packets, originating from a third device (e.g., clinician programmerDocket No.: A0012971W001 314). The third set of packets may be generated in accordance with a second client session (e.g., the HMAC session 1) between medical device 318 and the third device (e.g., clinician programmer 314) and encapsulated in the first set of packets from recharger 316. In this example, medical device 318 may also establish a HMAC session 0 with recharger 316 in addition to the TLS communication link.

[0086] The medical device may perform a first set of operations based on the second set of packets, and perform a second set of operations based on the third set of packets. For example, the second set of packets include a first session identification value, a first authenticated HMAC, and a first message payload. The first message payload includes information of the first set of operations that the medical device is to perform. The third set of packets include a second session identification value, a second authenticated HMAC, and a second message payload. The second message payload includes information of the second set of operations that the medical device is to perform.

[0087] FIG. 4 is a conceptual diagram illustrating an example of a packets being encapsulated in packets of a communication protocol according to one or more techniques of this disclosure. The example of FIG. 4 may be after a medical device (e.g., any of medical devices 304, 310, or 318) established a client session. For example, referring to FIG. 3B as an example, to establish a first client session (e.g., HMAC session 0), medical device 310 may be configured to determine a first session identification value (e.g., identification value of HMAC session 0) used to identify the second set of packets (e.g., that originate from patient programmer 309). Medical device 310 may determine a first authorization role for the second device (e.g., patient programmer 309), and determine a first HMAC key to verify data integrity of the second set of packets (e.g., from patient programmer 309). To establish the second client session (e.g., HMAC session 1), medical device 310 may be configured to determine a second session identification value (e.g., identification value of HMAC session 1) used to identify the third set of packets (e.g., that originate from clinician programmer 306). Medical device 310 may determine a second authorization role for the third device (e.g., clinician programmer 306), and determine a second HMAC key to verify data integrity of the third set of packets (e.g., from clinician programmer 306).

[0088] In FIG. 4, keeping with FIG. 3B as an illustrative example, assume that packet 402 originated from patient programmer 309 and packet 410 originated from clinician programmer 306. In this example, packet 400 originated from patient programmer 309 but is a packet formed in accordance with a first communication protocol (e.g., TLS protocol). As illustrated, packet 400 encapsulates packet 402 and packet 410.Docket No.: A0012971W001

[0089] As also illustrated, packet 402 includes session identification value 404 which may be the session identification value of HMAC session 0 between medical device 310 and patient programmer 309, which medical device 310 can use to determine the authorization level of patient programmer 309. Packet 402 includes authenticated HMAC 406 which medical device 310 can use to determine data integrity of payload 408. Payload 408 may include the instructions of the operations that medical device 310 is to perform as instructed by patient programmer 309. Medical device 310 may perform the operations as instructed by patient programmer 309 if data integrity is validated and the operations are consistent with the authorization level of patient programmer 309.

[0090] Packet 410 includes session identification value 412 which may be the session identification value of HMAC session 1 between medical device 310 and clinician programmer 306, which medical device 310 can use to determine the authorization level of clinician programmer 306. Packet 410 includes authenticated HMAC 414 which medical device 310 can use to determine data integrity of payload 416. Payload 416 may include the instructions of the operations that medical device 310 is to perform as instructed by clinician programmer 306. Medical device 310 may perform the operations as instructed by clinician programmer 306 if data integrity is validated and the operations are consistent with the authorization level of clinician programmer 306.

[0091] FIG. 5 is a block diagram illustrating an example of a medical device according to one or more techniques of this disclosure. Medical device 500 is an example of IMD 100 described above in relation to FIG. 1, SNM device 220 described above in relation to FIG. 2, or any of medical devices 304, 310, or 318 described above in relation to FIGS. 3A-3C. In the example illustrated in FIG. 5, medical device 500 includes coil 501, power source 502, processing circuitry 504, telemetry circuitry 506, temperature sensor 508, one or more sensor(s) 510 (e.g., accelerometer), memory 512, and therapy and sensing circuitry 514 coupled to one or more electrodes 516A-516D. In other examples, medical device 500 may include a greater or a fewer number of components, e.g., in some examples, medical device 500 may not include sensors 510. In general, medical device 500 may comprise any suitable arrangement of hardware, alone or in combination with software and / or firmware, to perform the various techniques described herein attributed to medical device 500 and processing circuitry 504, and any equivalents thereof.

[0092] Processing circuitry 504 may include one or more processors, such as one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. Medical device 500 may include computer readable storage media, such as memory 512, which may be implemented asDocket No.: A0012971W001 random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, comprising executable instructions for causing the processing circuitry 504 to perform the actions attributed to this circuitry.Moreover, although processing circuitry 504, therapy and sensing circuitry 514, recharge circuitry 503, telemetry circuitry 506, and temperature sensor 508 are described as separate circuits, in some examples, some combination of processing circuitry 504, therapy and sensing circuitry 514, recharge circuitry 503, telemetry circuitry 506, and temperature sensor 508 are functionally integrated. In some examples, processing circuitry 504, therapy and sensing circuitry 514, recharge circuitry 503, telemetry circuitry 506, and temperature sensor 508 correspond to individual hardware units, such as ASICs, DSPs, FPGAs, or other hardware units. In this disclosure, therapy and sensing circuitry 514 may be referred to as therapy circuitry 514, for simplicity, such as in examples where there is no sensing.

[0093] Memory 512 may store therapy programs or other instructions that specify therapy parameter values for the therapy provided by therapy circuitry 514 and medical device 500. In some examples, memory 512 may also store temperature data from temperature sensor 508, instructions for recharging rechargeable power source 502, thresholds, instructions for communication between medical device 500 and a recharger, patient programmer, or clinician programmer, or any other instructions required to perform tasks attributed to medical device 500. In various examples, memory 512 stores information related to determining the temperature of the housing of medical device 500 and / or exterior surface(s) of the housing of medical device 500 based on temperatures sensed by one or more temperature sensors, such as temperature sensor 508.

[0094] In some examples, memory 512 may store programming settings such as electrical stimulation therapy output magnitude, pulse width, and so on. Memory 512 may store programming instructions that when executed by processing circuitry 504 cause processing circuitry 504 to perform example techniques described in this disclosure.

[0095] Therapy and sensing circuitry 514 may generate and deliver electrical stimulation under the control of processing circuitry 504. In some examples, processing circuitry 504 controls therapy circuitry 514 by accessing memory 512 to selectively access and load at least one of the stimulation programs to therapy circuitry 514. For example, in operation, processing circuitry 504 may access memory 512 to load one of the stimulation programs to therapy circuitry 514. In such examples, relevant stimulation parameters may include a voltage amplitude, a current amplitude, a pulse rate, a pulse width, a duty cycle, or the combination of electrodes 516A, 516B, 516C, and 516D (collectively “electrodes 516”) that therapy circuitryDocket No.: A0012971W001 514 may use to deliver the electrical stimulation signal as well as sense biological signals. In other examples, medical device 500 may have more or fewer electrodes than the four shown in the example of FIG. 5. In some examples electrodes 516 may be part of or attached to a housing of medical device 500, e.g., a leadless electrode. In other examples, one or more of electrodes 516 may be part of a lead implanted in or attached to a patient to sense biological signals and / or deliver electrical stimulation.

[0096] In the example of FIG. 5, medical device 500 also includes components to receive power to recharge rechargeable power source 502 when rechargeable power source 502 has been at least partially depleted. As shown in FIG. 5, medical device 500 includes coil 501 and recharge circuitry 503 coupled to rechargeable power source 502. Recharge circuitry 503 may be configured to charge rechargeable power source 502 with the selected power level determined by either processing circuitry 504 or an external charging device. Recharge circuitry 503 may include any of a variety of charging and / or control circuitry configured to process or convert current induced in coil 501 into charging current to charge power source 502.

[0097] Coil 501 may include a coil of wire or other device capable of inductive coupling with a primary coil disposed external to medical device 500. Although coil 501 is illustrated as a simple loop of in FIG. 5, coil 501 may include multiple turns of conductive wire. Coil 501 may include a winding of wire configured such that an electrical current can be induced within coil 501 from a magnetic field. The induced electrical current may then be used to recharge rechargeable power source 502.

[0098] Recharge circuitry 503 may include one or more circuits that process, filter, convert and / or transform the electrical signal induced in coil 501 to an electrical signal capable of recharging rechargeable power source 502. For example, in alternating current induction, recharge circuitry 503 may include a half-wave rectifier circuit and / or a full-wave rectifier circuit configured to convert alternating current from the induction to a direct current for rechargeable power source 502. The full-wave rectifier circuit may be more efficient at converting the induced energy for rechargeable power source 502. However, a half-wave rectifier circuit may be used to store energy in rechargeable power source 502 at a slower rate. In some examples, recharge circuitry 503 may include both a full-wave rectifier circuit and a half-wave rectifier circuit such that recharge circuitry 503 may switch between each circuit to control the charging rate of rechargeable power source 502 and temperature of medical device 500.

[0099] Power source 502 may include one or more capacitors, batteries, and / or other energy storage devices. Power source 502 may deliver operating power to the components of medical device 500. In some examples, rechargeable power source 502 may include a power generation circuit to produce the operating power. Power source 502 may be configured to operate throughDocket No.: A0012971W001 many discharge and recharge cycles. Power source 502 may also be configured to provide operational power to medical device 500 during the recharge process. In some examples, rechargeable power source 502 may be constructed with materials to reduce the amount of heat generated during charging. In other examples, medical device 500 may be constructed of materials and / or using structures that may help dissipate generated heat at rechargeable power source 502, recharge circuitry 503, and / or secondary coil 501 over a larger surface area of the housing of medical device 500.

[0100] Although power source 502, recharge circuitry 503, and coil 501 are shown as contained within the housing of medical device 500, in alternative implementations, at least one of these components may be disposed outside of the housing. For example, in some implementations, coil 501 may be disposed outside of the housing of medical device 500 to facilitate better coupling between coil 501 and the coil of a charger.

[0101] Processing circuitry 504 may also control the exchange of information with the programmers or rechargers, as examples described in this disclosure, using telemetry circuitry 506. Telemetry circuitry 506 may be configured for wireless communication using radio frequency protocols, such as BlueTooth™, BLE, or similar RF protocols, as well as using inductive communication protocols.

[0102] For example, processing circuitry 504 may be configured to establish a communication link with a first device in accordance a first communication protocol (e.g., TLS protocol) for receiving a first set of packets formed in accordance with the first communication protocol. Examples of the first device include patient programmer 104, patient programmer 212, recharger 302, patient programmer 309, or recharger 316.

[0103] In addition, processing circuitry 504 may be configured to establish a first client session with a second device, and a second client session with a third device. For example, to establish the first client session, processing circuitry 504 may be configured to determine a first session identification value used to identify second set of packets, originating from the second device, determine a first authorization role for the second device, and determine a first HMAC key to verify data integrity of the second set of packets. Similarly, to establish the second client session, processing circuitry 504 may be configured to determine a second session identification value used to identify a third set of packets, originated from the third device, determine a second authorization role for the third device, and determine a second HMAC key to verify data integrity of the third set of packets.

[0104] Processing circuitry 504 may receive from the first device a second set of packets, originating from a second device. The second set of packets may be generated in accordance with a first client session established between the medical device 500 and the second device andDocket No.: A0012971W001 encapsulated in the first set of packets. The first device and the second device may be the same devices, or may be different devices. For instance, the second device may be one of patient programmer 104, patient programmer 212, recharger 302, patient programmer 309, or recharger 316, or may be one of clinician programmer 102, clinician programmer 210, patient programmer 300, clinician programmer 306, patient programmer 312, or clinician programmer 314.

[0105] Processing circuitry 504 may receive from the first device a third set of packets, originating from a third device. The third set of packets may be generated in accordance with a second client session established between the medical device 500 and the third device and encapsulated in the first set of packets. The third device may be one of patient programmer 104, patient programmer 212, recharger 302, patient programmer 309, or recharger 316, or may be one of clinician programmer 102, clinician programmer 210, patient programmer 300, clinician programmer 306, patient programmer 312, or clinician programmer 314.

[0106] Processing circuitry 504 may be configured to perform a first set of operations based on the second set of packets, and perform a second set of operations based on the third set of packets. For example, the second set of packets may include a first session identification value, a first authenticated HMAC, and a first message payload. The first message payload may include information of the first set of operations that processing circuitry 504 is to perform. The third set of packets may include a second session identification value, a second authenticated HMAC, and a second message payload. The second message payload may include information of the second set of operations that processing circuitry 504 is to perform.

[0107] Processing circuitry 504 may utilize the first session identification value to determine an authorization level for the second device, and utilize the second session identification value to determine an authorization level for the third device. For instance, as described, during establishing of the first client session, processing circuitry 504 may determine a first session identification value for the second device, and determine a first authorization role for the second device from establishing a first telemetry certificate with the second device. Processing circuitry 504 may determine the first authorization level based on a determination that the second set of packets originated from the second device based on the first session identification value and that the second device has the first authorization role. Stated another way, processing circuitry 504 may have determined that the first session identification value is associated with the second device, and that the second device has a first authorization role. Accordingly, when processing circuitry 504 receives packets from the second device, as determined from the first session identification value, processing circuitry 504 may determine that the authorization role of the second device, and determine the authorization level. For instance, if the second device is a clinician programmer, the authorization role may be clinician programmer, meaning that theDocket No.: A0012971W001 authorization level is the highest level. If the second device is a recharger, the authorization role may recharger, meaning that the authorization level is relatively low.

[0108] Similarly, to determine the second authorization level for the third device, the processing circuitry 504 may be configured to during establishing of the second client session, determine a second session identification value for the third device, and determine a second authorization role for the third device from establishing a second telemetry certificate with the third device. Processing circuitry 504 may determine the second authorization level based on a determination that the third set of packets originated from the third device based on the second session identification value and that the third device has the second authorization role.

[0109] Telemetry circuitry 506 may include one or more antennas configured to communicate with programmer 104, for example. Processing circuitry 504 may transmit operational information and receive therapy programs or therapy parameter adjustments via telemetry circuitry 506. Telemetry circuitry 506 may be configured to control the exchange of information related to sensed and / or determined temperature data, for example temperatures sensed by and / or determined from temperatures sensed using temperature sensor 508.

[0110] FIG. 6 is a block diagram illustrating an example of a device configured to communicate with a medical device according to one or more techniques of this disclosure. FIG.6 illustrates programmer 600, which is an example of patient programmer 104 or clinician programmer 102 of FIG. 1 or patient programmer 212 or clinician programmer 210 of FIG. 2. Although programmer 600 may generally be described as a hand-held device, programmer 600 may be a larger portable device or a more stationary device. As illustrated in FIG. 6, programmer 600 may include processing circuitry 602, storage device 604, user interface 606, telemetry circuitry 608, and power source 610. Storage device 604 may store instructions that, when executed by processing circuitry 602, cause processing circuitry 602 and programmer 600 to provide the functionality ascribed to programmer 600 throughout this disclosure. Each of these components, circuitry, or modules, may include electrical circuitry that is configured to perform some, or all of the functionality described herein.[oni] In general, programmer 600 includes any suitable arrangement of hardware, alone or in combination with software and / or firmware, to perform the techniques attributed to external programmer 600, and processing circuitry 602, user interface 606, and telemetry circuitry 608 of programmer 600. In various examples, programmer 600 may include one or more processors, such as one or more microprocessors, DSPs, ASICs, FPGAs, or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. Programmer 600 also, in various examples, may include a storage device 604, such as RAM, ROM, PROM, EPROM, EEPROM, flash memory, a hard disk, a CD-ROM, including executable instructionsDocket No.: A0012971W001 for causing the one or more processors to perform the actions attributed to them. Moreover, although processing circuitry 602 and telemetry circuitry 608 are described as separate modules, in some examples, processing circuitry 602 and telemetry circuitry 608 are functionally integrated. In some examples, processing circuitry 602 and telemetry circuitry 608 correspond to individual hardware units, such as ASICs, DSPs, FPGAs, or other hardware units.

[0112] Storage device 604 (e.g., a storage device or one or more memories) may store instructions that, when executed by processing circuitry 602, cause processing circuitry 602 and programmer 600 to provide the functionality ascribed to programmer 600 throughout this disclosure. Storage device 604 may include a plurality of programs, where each program includes a parameter set that defines stimulation pulses, such as control pulses and / or informed pulses. Storage device 604 may also store data received from a medical device (e.g., IMD 100, SNM device 220, or medical device 304, 310, or 318).

[0113] User interface 606 may include a button or keypad, lights, a speaker for voice commands, a display, such as a liquid crystal (LCD), light-emitting diode (LED), or organic light-emitting diode (OLED). In some examples the display includes a touch screen. User interface 606 may be configured to display any information related to the delivery of electrical stimulation, identified patient behaviors, sensed patient parameter values, patient behavior criteria, or any other such information. User interface 606 may also receive user input. The input may be, for example, in the form of pressing a button on a keypad or selecting an icon from a touch screen. The input may request starting or stopping electrical stimulation, or request some other change to the delivery of electrical stimulation.

[0114] Telemetry circuitry 608 may support wireless communication between the medical device and programmer 600 under the control of processing circuitry 602. Telemetry circuitry 608 may also be configured to communicate with another computing device via wireless communication techniques, or direct communication through a wired connection. In some examples, telemetry circuitry 608 provides wireless communication via an RF or proximal inductive medium. In some examples, telemetry circuitry 608 includes an antenna, which may take on a variety of forms, such as an internal or external antenna. Examples of local wireless communication techniques that may be employed to facilitate communication between programmer 600 and the medical device include RF communication according to the 802.11 or BlueTooth™ specification sets or other standard or proprietary telemetry protocols.

[0115] In some examples, selection of stimulation parameters for stimulation programs are transmitted to the medical device for delivery to a patient. In other examples, the therapy may include medication, activities, or other instructions that a patient should perform themselves or a caregiver perform for the patient. In some examples, programmer 600 provides visual, audible,Docket No.: A0012971W001 and / or tactile notifications that indicate there are new instructions. Programmer 600 may require receiving user input acknowledging that the instructions have been completed in some examples.

[0116] Power source 610 is configured to deliver operating power to the components of external programmer 600. Power source 610 may include a battery and a power generation circuit to produce the operating power. In some examples, the battery is rechargeable to allow extended operation. Recharging may be accomplished by electrically coupling power source 610 to a cradle or plug that is connected to an alternating current (AC) outlet. In addition, recharging may be accomplished through proximal inductive interaction between an external charger and an inductive charging coil within programmer 600. In other examples, traditional batteries (e.g., nickel cadmium or lithium ion batteries) may be used. In addition, programmer 600 may be directly coupled to an alternating current outlet to operate.

[0117] In the example of FIG. 6, programmer 600 may be configured to establish client sessions (e.g., HMAC sessions) with a medical device as described in this disclosure. For instance, programmer 600 may form packets for transmission to a medical device using the HMAC session, where such packets are encapsulated in packets of a TLS protocol link.

[0118] FIG. 7 is a flow chart illustrating an example method of operation according to one or more techniques of this disclosure. For ease of illustration, the example of FIG. 7 is described with respect to processing circuitry 504.

[0119] Processing circuitry 504 (e.g., via telemetry circuitry 506) may be configured to establish a communication link with a first device in accordance a first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol (700). The first communication protocol may be a transport layer security (TLS) cryptographic protocol.

[0120] Processing circuitry 504 (e.g., via telemetry circuitry 506) may receive from the first device a second set of packets, originating from a second device, the second set of packets generated in accordance with a first client session established between the medical device and the second device and encapsulated in the first set of packets (702). To establish the first client session, processing circuitry 504 may be configured to determine a first session identification value used to identify the second set of packets, determine a first authorization role for the second device, and determine a first HMAC key to verify data integrity of the second set of packets.

[0121] For example, the second set of packets include a first session identification value, a first authenticated HMAC, and a first message payload. The first message payload may include information about the operations that processing circuitry 504 is to perform as requested by the second device.Docket No.: A0012971W001

[0122] Processing circuitry 504 may determine from which device the second set of packets originated based on the first session identification value. Processing circuitry 504 may also determine the authorization level of the second device based on the first session identification value. For instance, from the first session identification value, the processing circuitry 504 may determine the authorization role of the second device, and from the authorization role, the processing circuitry may determine the authorization level. It may be possible to determine the authorization level of the second device directly from the first session identification value.

[0123] Processing circuitry 504 may be able to verify data integrity of the second set of packets using the first authenticated HMAC. For instance, during establishing the first client session, the processing circuitry 504 may have determine a first HMAC key. Processing circuitry 504 may generate a hash value based on at least the first message payload, and compare that hash value to the first authenticated HMAC. If the values are the same, processing circuitry 504 may determine that the packets are not corrupted (e.g., there is data integrity).

[0124] Processing circuitry 504 (e.g., via telemetry circuitry 506) may receive from the first device a third set of packets, originating from a third device, the third set of packets generated in accordance with a second client session established between the medical device and the third device and encapsulated in the first set of packets (704). To establish the second client session, processing circuitry 504 may be configured to determine a second session identification value used to identify the third set of packets, determine a second authorization role for the third device, and determine a second HMAC key to verify data integrity of the second set of packets.

[0125] For example, the third set of packets include a second session identification value, a second authenticated HMAC, and a second message payload. The second message payload may include information about the operations that processing circuitry 504 is to perform as requested by the third device.

[0126] Processing circuitry 504 may determine from which device the third set of packets originated based on the second session identification value. Processing circuitry 504 may also determine the authorization level of the third device based on the second session identification value. For instance, from the second session identification value, the processing circuitry 504 may determine the authorization role of the third device, and from the authorization role, the processing circuitry may determine the authorization level. It may be possible to determine the authorization level of the third device directly from the first session identification value.

[0127] Processing circuitry 504 may be able to verify data integrity of the third set of packets using the second authenticated HMAC. For instance, during establishing the second client session, the processing circuitry 504 may have determine a second HMAC key. Processing circuitry 504 may generate a hash value based on at least the second message payload, andDocket No.: A0012971W001 compare that hash value to the second authenticated HMAC. If the values are the same, processing circuitry 504 may determine that the packets are not corrupted (e.g., there is data integrity).

[0128] Processing circuitry 504 may perform a first set of operations based on the second set of packets (706). As one example, processing circuitry 504 may determine a first authorization level for the second device based on the second set of packets. To determine the first authorization level for the second device, processing circuitry 504 may during establishing of the first client session, determine a first session identification value for the second device, and determine a first authorization role for the second device from establishing a first telemetry certificate with the second device, and determine the first authorization level based on a determination that the second set of packets originated from the second device based on the first session identification value and that the second device has the first authorization role.

[0129] The processing circuitry 504 may determine that the medical device is to perform the first set of operations based on the first authorization level, and perform the first set of operations based on the determination that the medical device is to perform the first set of operations. In another case, processing circuitry 504 may determine that the medical device is to not perform the first set of operations based on the first authorization level, and avoid performing the first set of operations based on the determination that the medical device is to not perform the first set of operations.

[0130] As another example, processing circuitry 504 may determine a data integrity of the second set of packets indicative of whether the second set of packets changed. To perform the first set of operations, the processing circuitry 504 may determine that the medical device is to perform the first set of operations based on the determination that the second set of packets did not change, and perform the first set of operations based on the determination that the medical device is to perform the first set of operations. In another case, processing circuitry 504 may determine that the medical device is to not perform the first set of operations based on the determination that the second set of packets changed, and avoid performing the first set of operations based on the determination that the medical device is to not perform the first set of operations.

[0131] Processing circuitry 504 may perform a second set of operations based on the third set of packets (708). As one example, processing circuitry 504 may determine a second authorization level for the third device based on the third set of packets. To determine the second authorization level for the third device, processing circuitry 504 may during establishing of the second client session, determine a second session identification value for the third device, and determine a second authorization role for the third device from establishing a first telemetryDocket No.: A0012971W001 certificate with the third device, and determine the second authorization level based on a determination that the third set of packets originated from the third device based on the second session identification value and that the third device has the second authorization role.

[0132] The processing circuitry 504 may determine that the medical device is to perform the second set of operations based on the second authorization level, and perform the second set of operations based on the determination that the medical device is to perform the second set of operations. In another case, processing circuitry 504 may determine that the medical device is to not perform the second set of operations based on the second authorization level, and avoid performing the second set of operations based on the determination that the medical device is to not perform the second set of operations.

[0133] As another example, processing circuitry 504 may determine a data integrity of the third set of packets indicative of whether the third set of packets changed. To perform the second set of operations, the processing circuitry 504 may determine that the medical device is to perform the second set of operations based on the determination that the third set of packets did not change, and perform the second set of operations based on the determination that the medical device is to perform the second set of operations. In another case, processing circuitry 504 may determine that the medical device is to not perform the second set of operations based on the determination that the third set of packets changed, and avoid performing the second set of operations based on the determination that the medical device is to not perform the second set of operations.

[0134] FIG. 8. is a flow chart illustrating another example method of operation according to one or more techniques of this disclosure. For purposes of illustration only, the example of FIG.8 is described with FIG. 3C.

[0135] In the example of FIG. 8, a first device establishes a TLS communication link with a medical device (e.g., a communication link in accordance with a first communication protocol) using telemetry certificates (800). The medical device may establish a communication link with the first device in accordance with the first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol (e.g., TLS communication link) using telemetry certificates (802).

[0136] The first device may establish links with other devices using the telemetry certificates (804). For instance, referring back to FIG. 3C as an example, the first device may be recharger 316. As illustrated, recharger 316 may establish links (e.g., BLE or USB) with patient programmer 312 and clinician programmer 314. The other devices may also establish a link with the first device (814). For example, patient programmer 312 and clinician programmer 314 establish a link with recharger 316.Docket No.: A0012971W001

[0137] The respective other devices (e.g., patient programmer 312 and clinician programmer 314) may generate respective telemetry certification indicative of authorization levels and generate respective session identification values (816). In some examples, it may be possible that the first device may generate telemetry certification information indicative of authorization level and generate session identification value of the first device. However, the telemetry certification information may be stored on the first device already, and no generation of telemetry certification information may be needed by the first device.

[0138] The first device may generate an HMAC key (e.g., using IVs and ECDH) (808). The other devices may each generate a respective HMAC key (818). The medical device may generate an HMAC key 0 (e.g., for communication with the first device) (824). The medical device may also generate an HMAC key 1 (e.g., for communication with another device) (825). In this manner, the first device, the other devices, and the medical device may establish respective client sessions (e.g., HMAC sessions).

[0139] The first device may generate payload using HMAC key that includes telemetry certification and session identification values (810). Similarly, the other devices may generate payload using HMAC key that includes telemetry certification and session identification values (820). The other device may transmit to the first device, such as via the TLS link (822). The first device may relay the information to the medical device via the TLS link and including packets formed in accordance with the respective HMAC sessions (812). The medical device may receive the packets, validate the data integrity of payload based on the HMAC key (826). The medical device may then perform operations based on payload and authorization level (828). For instance, if the operations are consistent with the authorization level of the device that originated the payload, the medical device may perform the operations. If the operations are not consistent with the authorization level of the device that originated the payload, the medical device may avoid performing the operations.

[0140] The following clauses are a non-limiting list of examples in accordance with one or more techniques of this disclosure.

[0141] Example 1 : A medical device comprising: one or more memories; and processing circuitry coupled to the one or more memories, wherein the processing circuitry is configured to: establish, via telemetry circuitry, a communication link with a first device in accordance with a first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol; receive, via the telemetry circuitry, from the first device a second set of packets, originating from a second device, the second set of packets generated in accordance with a first client session established between the medical device and the second device and encapsulated in the first set of packets; receive, via the telemetry circuitry,Docket No.: A0012971W001 from the first device a third set of packets, originating from a third device, the third set of packets generated in accordance with a second client session established between the medical device and the third device and encapsulated in the first set of packets; perform a first set of operations based on the second set of packets; and perform a second set of operations based on the third set of packets.

[0142] Example 2. The medical device of example 1, wherein the first device and the second device are the same device.

[0143] Example 3. The medical device of example 1, wherein the first device, the second device, and the third device are different devices.

[0144] Example 4. The medical device of any of examples 1-3, wherein the processing circuitry is further configured to: determine a first authorization level for the second device based on the second set of packets; and determine a second authorization level for the third device based on the third set of packets, wherein to perform the first set of operations, the processing circuitry is configured to: determine that the medical device is to perform the first set of operations based on the first authorization level; and perform the first set of operations based on the determination that the medical device is to perform the first set of operations, and wherein to perform the second set of operations, the processing circuitry is configured to: determine that the medical device is to perform the second set of operations based on the second authorization level; and perform the second set of operations based on the determination that the medical device is to perform the second set of operations.

[0145] Example 5. The medical device of example 4, wherein to determine the first authorization level for the second device, the processing circuitry is configured to: during establishing of the first client session, determine a first session identification value for the second device, and determine a first authorization role for the second device from a first telemetry certificate with the second device; and determine the first authorization level based on a determination that the second set of packets originated from the second device based on the first session identification value and that the second device has the first authorization role, and wherein to determine the second authorization level for the third device, the processing circuitry is configured to: during establishing of the second client session, determine a second session identification value for the third device, and determine a second authorization role for the third device from a second telemetry certificate with the third device; and determine the second authorization level based on a determination that the third set of packets originated from the third device based on the second session identification value and that the third device has the second authorization role.Docket No.: A0012971W001

[0146] Example 6. The medical device of any of examples 1-5, wherein the processing circuitry is further configured to: determine a data integrity of the second set of packets indicative of whether the second set of packets changed; and determine a data integrity of the third set of packets indicative of whether the third set of packets changed, wherein to perform the first set of operations, the processing circuitry is configured to: determine that the medical device is to perform the first set of operations based on the determination that the second set of packets did not change; and perform the first set of operations based on the determination that the medical device is to perform the first set of operations, and wherein to perform the second set of operations, the processing circuitry is configured to: determine that the medical device is to perform second set of operations based on the determination that the third set of packets did not change; and perform the second set of operations based on the determination that the medical device is to perform the second set of operations.

[0147] Example 7. The medical device of any of examples 1-6, wherein the processing circuitry is configured to establish the first client session and establish the second client session, wherein to establish the first client session, the processing circuitry is configured to: determine a first session identification value used to identify the second set of packets; determine a first authorization role for the second device; and determine a first hash-based message authentication code (HMAC) key to verify data integrity of the second set of packets, and wherein to establish the second client session, the processing circuitry is configured to: determine a second session identification value used to identify the third set of packets; determine a second authorization role for the third device; and determine a second HMAC key to verify data integrity of the third set of packets.

[0148] Example 8. The medical device of any of examples 1-7, wherein the second set of packets include a first session identification value, a first authenticated hash-based message authentication code (HMAC), and a first message payload, wherein the third set of packets include a second session identification value, a second authenticated HMAC, and a second message payload, wherein the first message payload includes information of the first set of operations that the processing circuitry is to perform, and wherein the second message payload includes information of the second set of operations that the processing circuitry is to perform.

[0149] Example 9. The medical device of any of examples 1-8, wherein the first communication protocol comprises a transport layer security (TLS) cryptographic protocol.

[0150] Example 10. The medical device of any of examples 1-9, wherein the medical device is an implantable medical device (HMD).Docket No.: A0012971W001

[0151] Example 11. The medical device of any of examples 1-10, wherein the first device is a recharger for the medical device, the second device is the same as the first device, and the third device is a patient programmer for the medical device.

[0152] Example 12. The medical device of any of examples 1-10, wherein the first device is a patient programmer in a same location as the medical device, the second device is the same as the first device, and the third device is a clinician programmer in a remote location from the medical device.

[0153] Example 13. The medical device of any of examples 1-10, wherein the first device is a recharger for the medical device, the second device is a patient programmer, and the third device is a clinician programmer.

[0154] Example 14. The medical device of any of examples 1-10, wherein the first device is a patient programmer for the medical device, the second device is a patient support system, and the third device is a clinician programmer.

[0155] Example 15. A method of communicating between devices, the method comprising: establishing, with processing circuitry of a medical device, a communication link with a first device in accordance with a first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol; receiving, with the processing circuitry and from the first device, a second set of packets, originating from a second device, the second set of packets generated in accordance with a first client session established between the medical device and the second device and encapsulated in the first set of packets; receiving, with the processing circuitry and from the first device, a third set of packets, originating from a third device, the third set of packets generated in accordance with a second client session established between the medical device and the third device and encapsulated in the first set of packets; performing, with the processing circuitry, a first set of operations based on the second set of packets; and performing, with the processing circuitry, a second set of operations based on the third set of packets.

[0156] Example 16. The method of example 15, wherein the first device and the second device are the same device.

[0157] Example 17. The method of example 15, wherein the first device, the second device, and the third device are different devices.

[0158] Example 18. The method of any of examples 15-17, further comprising: determining a first authorization level for the second device based on the second set of packets; and determining a second authorization level for the third device based on the third set of packets, wherein performing the first set of operations comprises: determining that the medical device is to perform the first set of operations based on the first authorization level; andDocket No.: A0012971W001 performing the first set of operations based on the determination that the medical device is to perform the first set of operations, and wherein performing the second set of operations comprises: determining that the medical device is to perform the second set of operations based on the second authorization level; and performing the second set of operations based on the determination that the medical device is to perform the second set of operations.

[0159] Example 19. The method of example 18, wherein determining the first authorization level for the second device comprises: during establishing of the first client session, determining a first session identification value for the second device, and determining a first authorization role for the second device from a first telemetry certificate with the second device; and determining the first authorization level based on a determination that the second set of packets originated from the second device based on the first session identification value and that the second device has the first authorization role, and wherein determining the second authorization level for the third device: during establishing of the second client session, determining a second session identification value for the third device, and determining a second authorization role for the third device from a second telemetry certificate with the third device; and determining the second authorization level based on a determination that the third set of packets originated from the third device based on the second session identification value and that the third device has the second authorization role.

[0160] Example 20. The method of any of examples 15-19, further comprising: determining a data integrity of the second set of packets indicative of whether the second set of packets changed; and determining a data integrity of the third set of packets indicative of whether the third set of packets changed, wherein performing the first set of operations comprises: determining that the medical device is to perform the first set of operations based on the determination that the second set of packets did not change; and performing the first set of operations based on the determination that the medical device is to perform the first set of operations, and wherein performing the second set of operations comprises: determining that the medical device is to perform second set of operations based on the determination that the third set of packets did not change; and performing the second set of operations based on the determination that the medical device is to perform the second set of operations.

[0161] Example 21. The method of any of examples 15-20, further comprising establishing the first client session and establish the second client session, wherein establishing the first client session comprises: determining a first session identification value used to identify the second set of packets; determining a first authorization role for the second device; and determining a first hash-based message authentication code (HMAC) key to verify data integrity of the second set of packets, and wherein establishing the second client session comprises:Docket No.: A0012971W001 determining a second session identification value used to identify the third set of packets; determining a second authorization role for the third device; and determining a second HMAC key to verify data integrity of the third set of packets.

[0162] Example 22. The method of any of examples 15-21, wherein the second set of packets include a first session identification value, a first authenticated hash-based message authentication code (HMAC), and a first message payload, wherein the third set of packets include a second session identification value, a second authenticated HMAC, and a second message payload, wherein the first message payload includes information of the first set of operations that the processing circuitry is to perform, and wherein the second message payload includes information of the second set of operations that the processing circuitry is to perform.

[0163] Example 23. The method of any of examples 15-22, wherein the first communication protocol comprises a transport layer security (TLS) cryptographic protocol.

[0164] Example 24. The method of any of examples 15-23, wherein the medical device is an implantable medical device (HMD).

[0165] Example 25. The method of any of examples 15-24, wherein the first device is a recharger for the medical device, the second device is the same as the first device, and the third device is a patient programmer for the medical device.

[0166] Example 26. The method of any of examples 15-24, wherein the first device is a patient programmer in a same location as the medical device, the second device is the same as the first device, and the third device is a clinician programmer in a remote location from the medical device.

[0167] Example 27. The method of any of examples 15-24, wherein the first device is a recharger for the medical device, the second device is a patient programmer, and the third device is a clinician programmer.

[0168] Example 28. The method of any of examples 15-24, wherein the first device is a patient programmer for the medical device, the second device is a patient support system, and the third device is a clinician programmer.

[0169] Example 29. A computer-readable storage medium storing instructions thereon that when executed cause one or more processors to perform the method of any of examples 15-28.

[0170] Example 30. A medical device comprising means for performing the method of any of examples 15-28.

[0171] The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including one or moreDocket No.: A0012971W001 microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. The term “processor” or “processing circuitry” may generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. A control unit comprising hardware may also perform one or more of the techniques of this disclosure.

[0172] Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. In addition, any of the described units, modules or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components, or integrated within common or separate hardware or software components.

[0173] The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable storage medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer readable storage media may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, magnetic media, optical media, or other computer readable media.

[0174] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

Docket No.: A0012971W001 WHAT IS CLAIMED IS:

1.

1. A medical device comprising:one or more memories; andprocessing circuitry coupled to the one or more memories, wherein the processing circuitry is configured to:establish, via telemetry circuitry, a communication link with a first device in accordance with a first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol;receive, via the telemetry circuitry, from the first device a second set of packets, originating from a second device, the second set of packets generated in accordance with a first client session established between the medical device and the second device and encapsulated in the first set of packets;receive, via the telemetry circuitry, from the first device a third set of packets, originating from a third device, the third set of packets generated in accordance with a second client session established between the medical device and the third device and encapsulated in the first set of packets;perform a first set of operations based on the second set of packets; and perform a second set of operations based on the third set of packets.

2. The medical device of claim 1, wherein the first device and the second device are the same device.

3. The medical device of claim 1, wherein the first device, the second device, and the third device are different devices.Docket No.: A0012971W001 4. The medical device of any of claims 1-3, wherein the processing circuitry is further configured to:determine a first authorization level for the second device based on the second set of packets; anddetermine a second authorization level for the third device based on the third set of packets,wherein to perform the first set of operations, the processing circuitry is configured to: determine that the medical device is to perform the first set of operations based on the first authorization level; andperform the first set of operations based on the determination that the medical device is to perform the first set of operations, andwherein to perform the second set of operations, the processing circuitry is configured to:determine that the medical device is to perform the second set of operations based on the second authorization level; andperform the second set of operations based on the determination that the medical device is to perform the second set of operations.

5. The medical device of claim 4,wherein to determine the first authorization level for the second device, the processing circuitry is configured to:during establishing of the first client session, determine a first session identification value for the second device, and determine a first authorization role for the second device from a first telemetry certificate with the second device; and determine the first authorization level based on a determination that the second set of packets originated from the second device based on the first session identification value and that the second device has the first authorization role, andwherein to determine the second authorization level for the third device, the processing circuitry is configured to:during establishing of the second client session, determine a second session identification value for the third device, and determine a second authorization role for the third device from a second telemetry certificate with the third device; anddetermine the second authorization level based on a determination that the third set of packets originated from the third device based on the second session identification value and that the third device has the second authorization role.Docket No.: A0012971W001 6. The medical device of any of claims 1-5, wherein the processing circuitry is further configured to:determine a data integrity of the second set of packets indicative of whether the second set of packets changed; anddetermine a data integrity of the third set of packets indicative of whether the third set of packets changed,wherein to perform the first set of operations, the processing circuitry is configured to:determine that the medical device is to perform the first set of operations based on the determination that the second set of packets did not change; andperform the first set of operations based on the determination that the medical device is to perform the first set of operations, andwherein to perform the second set of operations, the processing circuitry is configured to:determine that the medical device is to perform second set of operations based on the determination that the third set of packets did not change; andperform the second set of operations based on the determination that the medical device is to perform the second set of operations.

7. The medical device of any of claims 1-6,wherein the processing circuitry is configured to establish the first client session and establish the second client session,wherein to establish the first client session, the processing circuitry is configured to: determine a first session identification value used to identify the second set of packets;determine a first authorization role for the second device; anddetermine a first hash-based message authentication code (HMAC) key to verify data integrity of the second set of packets, andwherein to establish the second client session, the processing circuitry is configured to:determine a second session identification value used to identify the third set of packets;determine a second authorization role for the third device; anddetermine a second HMAC key to verify data integrity of the third set of packets.Docket No.: A0012971W001 8. The medical device of any of claims 1-7, wherein the second set of packets include a first session identification value, a first authenticated hash-based message authentication code (HMAC), and a first message payload, wherein the third set of packets include a second session identification value, a second authenticated HMAC, and a second message payload, wherein the first message payload includes information of the first set of operations that the processing circuitry is to perform, and wherein the second message payload includes information of the second set of operations that the processing circuitry is to perform.

9. The medical device of any of claims 1-8, wherein the first communication protocol comprises a transport layer security (TLS) cryptographic protocol.

10. The medical device of any of claims 1-9, wherein the medical device is an implantable medical device (IMD).

11. The medical device of any of claims 1-10, wherein the first device is a recharger for the medical device, the second device is the same as the first device, and the third device is a patient programmer for the medical device.

12. The medical device of any of claims 1-10, wherein the first device is a patient programmer in a same location as the medical device, the second device is the same as the first device, and the third device is a clinician programmer in a remote location from the medical device.

13. The medical device of any of claims 1-10, wherein the first device is a recharger for the medical device, the second device is a patient programmer, and the third device is a clinician programmer.

14. The medical device of any of claims 1-10, wherein the first device is a patient programmer for the medical device, the second device is a patient support system, and the third device is a clinician programmer.Docket No.: A0012971W001 15. A method of communicating between devices, the method comprising:establishing, with processing circuitry of a medical device, a communication link with a first device in accordance with a first communication protocol for receiving a first set of packets formed in accordance with the first communication protocol;receiving, with the processing circuitry and from the first device, a second set of packets, originating from a second device, the second set of packets generated in accordance with a first client session established between the medical device and the second device and encapsulated in the first set of packets;receiving, with the processing circuitry and from the first device, a third set of packets, originating from a third device, the third set of packets generated in accordance with a second client session established between the medical device and the third device and encapsulated in the first set of packets;performing, with the processing circuitry, a first set of operations based on the second set of packets; andperforming, with the processing circuitry, a second set of operations based on the third set of packets.

Images