Leadless Pacemaker Communication System for Patient Devices

Abstract

A patient device 200 for a leadless pacemaker communication system is disclosed. The patient device 200 is configured to transmit and receive data to and from a service device 201 and to and from a leadless pacemaker 202. The patient device 200 comprises a first controller 203 for controlling communications with the service device 201 and a second controller 204 for controlling communications with the leadless pacemaker 202. The second controller 204 is stationary.

Description

[Technical field]

[0001] The present invention relates generally to communication systems for leadless intracardiac pacemaker devices. [Background technology]

[0002] In recent years, there has been increasing interest in leadless pacemakers. Leadless pacemakers do not use leads because the pacemaker device itself is implanted intracardially, in contrast to pacemakers that are implanted subcutaneously with leads that extend intravenously into the heart. Leadless pacemakers typically have a capsule shape for implantation in tissue within the heart, specifically the right ventricular wall of the right ventricle. Such pacemakers present the inherent advantage of not using leads and can reduce the risks to patients associated with leads that access the heart intravenously, such as the risks of pneumothorax, lead dislodgement, cardiac perforation, and venous thrombosis.

[0003] A leadless pacemaker may be specifically designed for implantation in the right ventricle, where it is positioned in or on the right ventricular wall during implantation. Ventricular pacing may be required, for example, when atrioventricular nodal dysfunction occurs but sinus node function is intact and adequate. In such cases, so-called VDD pacing may be desired, which specifically involves ventricular pacing with atrial tracking and therefore requires sensing of atrial activity in order to pace the ventricles based on intrinsic atrial contractions.

[0004] Remote interrogation using the implantable leadless pacemaker's inductive communications link (typically used to interface with a clinician's programmer) can generally be used by patient devices to obtain the same information that a programmer obtains during routine in-clinic follow-up. In addition, remote interrogation can be used and performed by service centers (e.g., home monitoring service centers) to enable assurance of comprehensive patient care.

[0005] Secure end-to-end communication techniques are used in many systems to prevent attacks by malicious actors and provide privacy. Leadless pacemakers attempt to use as much of the energy stored in the battery as possible to support pacemaker function for as long a service time as possible. Furthermore, leadless pacemakers are implanted deep within the body, where higher data throughput can be achieved only at the cost of significant energy expenditure. As a result, no leadless pacemakers yet offer encryption or other secure communication techniques for the interface used to communicate with the programmer. The primary mitigation used to compensate for this weakness is that inductive communication requires the implant and programmer to be located very close to each other, and typically such follow-ups must be performed in a clinical environment under the supervision of a trusted physician.

[0006] In summary, leadless pacemakers, due to their extremely low power design, are not conducive to using radio frequency (RF) telemetry for remote monitoring, but can utilize an inductive communication interface to achieve patient-triggered remote interrogation when circumstances permit. Due to the need for extremely high energy efficiency, leadless pacemaker implantation does not allow for the electrical energy savings required for typical wireless cybersecurity measures. Summary of the Invention

[0007] The invention provides elements of a leadless pacemaker communication system that enable remote interrogation of leadless pacemaker data and enhanced protection against remote attacks, such as cyber attacks, on the leadless pacemaker.

[0008] This objective is achieved by a patient device for a leadless pacemaker communication system having the following features. Such a patient device is designed and configured to transmit and receive data to and from a service device. The service device may be, for example, a cellular or smart phone. Furthermore, the patient device is designed and configured to transmit and receive data to and from the leadless pacemaker. Thus, the patient device acts as an intermediate device between the service device and the leadless pacemaker. The patient device comprises a first controller for controlling communication to and from the service device. The patient device further comprises a second controller for controlling communication to and from the leadless pacemaker. Thus, the communication functionality of the patient device is split into two parts, the first part (comprising the first controller) is responsible for controlling communication to and from the service device. Similarly, the second part (comprising the second controller) is responsible for controlling communication to and from the leadless pacemaker. In this context, the second controller is immutable. Thus, the general functionality of the second controller cannot be updated or otherwise influenced.

[0009] Since the second controller serves to control communications between the leadless pacemaker, its immutability ensures secure data communications between the patient device and the leadless pacemaker, even in the event of a cyber or other remote attack directed at the patient device. The second controller can be designed in an immutable manner because it only needs to handle a few very simple tasks that do not require patching or updating. Restricting the functionality of the second controller enables secure and attack-resistant communications between the patient device and the leadless pacemaker.

[0010] In one example, the first controller is updatable, thereby keeping the patient device aligned with wireless standards applied or required by the service device. The updatable first controller therefore allows a patient device user to rely on the latest software available, and such updatable functionality does not adversely affect secure communications between the patient device and the leadless pacemaker. The updatable first controller also allows updates necessary to address cybersecurity vulnerabilities discovered during post-market monitoring of the patient device and communications standards applied by the patient device.

[0011] In one embodiment, the first controller is designed and configured to be updated remotely, for example by a mobile device management (MDM) solution. Such a solution allows for particularly easy and reliable centralized updates of remotely deployed devices. Such centralized and remote updates can also be expressed as a fleet management of the respective devices, i.e., a fleet management of patient devices. Such centralized and remote techniques allow for secure distribution of software to devices. Such techniques are generally susceptible to vulnerabilities, as they typically create a potential risk of attack by malicious actors. However, even if the update process of the first controller is subject to such a malicious attack, due to the communication partitioning within the patient device realized by the first controller and the second controller, this does not affect the secure communication between the patient device and the connected leadless pacemaker.

[0012] In one embodiment, the patient device comprises a first communication transceiver controlled by the first control device. The first communication transceiver is operable to transmit and receive data to and from the service device and / or the service center in a wireless manner. Any standard data transmission protocol or specification is suitable for such wireless data communication. Examples of standard data transmission protocols or specifications are the Global System for Mobile Communications (GSM) standard (including its subsequent generations), the Code-division multiple access (CDMA) protocol, the Medical Device Radiocommunications Service (MICS), the Bluetooth Low Energy (BLE) protocol, and the Zigbee specification.

[0013] In one example, the patient device comprises a second communications transceiver controlled by a second controller. The second communications transceiver functions to transmit and receive data to and from the implanted leadless pacemaker in an inductive manner. Such inductive telemetry between leadless pacemakers and patient devices is generally known and well established. It has proven possible to achieve particularly reliable communication over short distances. Thus, the patient device typically needs to be located in close proximity to the (implanted) leadless pacemaker to establish an inductive telemetry link.

[0014] In one embodiment, the patient device includes an interface between a first controller and a second controller. The interface allows only limited data exchange between the first controller and the second controller. The limited data exchange is dictated by the intentionally limited data comprehension of the second controller. Thus, the second controller is intentionally made less comprehension than the first controller. In so doing, the first controller allows high-level data communication and the second controller allows only low-level data communication. Thus, the higher level functionality of the first controller allows comfortable communication with the service device. However, communication between the first controller and the second controller is necessarily limited to the lower level functionality of the second controller. This ensures secure communication between the patient device and the connected leadless pacemaker, since the second controller is not compromised by high-level data requests.

[0015] Alternatively or additionally, any interface is limited based on the recipient's understanding. Separating high-level and low-level protocols can potentially be more secure, but not necessarily. Low-level protocols are easier to make immutable because they are less likely to change. Simple interfaces are harder to attack because they have a smaller attack surface.

[0016] In one example, the second controller is configured to not allow sending requests to the leadless pacemaker device to disable a write protection feature of the leadless pacemaker device. Such a write protection feature is typically disabled by the leadless pacemaker upon initiating a communications session with a patient device or other communications device. Disabling the write protection feature allows reprogramming the leadless pacemaker according to the medical needs of the patient in whom the leadless pacemaker is implanted. However, such reprogramming is undesirable in an environment where only data is queried from the leadless pacemaker. Disabling the ability of the second controller to send requests to disable write protection features of connected leadless pacemakers effectively reduces or eliminates the risk of unwanted attacks on patient devices and connected leadless pacemaker devices.

[0017] Alternatively or in addition to the last embodiment, the second control device can refuse or not allow the transmission of any command that it considers inappropriate for the remote inquiry. Thus, this immutable device is essentially a firewall that knows which commands can be safely passed and which cannot. This embodiment may be performed on two processors, with or without encryption / authentication between the processors. This embodiment may also be performed on the same processor where trust zones and other security features are used to separate one execution context from another.

[0018] In one example, the second controller is configured to assign an attribute to any data request provided by the first controller. The attribute classifies the data request to which it is assigned as originating from a remote device. The connected leadless pacemaker classifies the request it receives as either remote or non-remote. If a request is classified as remote (i.e., originating from a patient device), it cannot activate or deactivate certain features of the leadless pacemaker. As an example, the leadless pacemaker in this example does not accept to disable a write protection mechanism if the request to do so is flagged as remote. Only matching requests flagged (or not) as non-remote can disable the write protection mechanism. Thus, in this example, there is an interaction between the second controller and the connected leadless pacemaker that allows secure communication between the two devices and can activate or deactivate certain features of the leadless pacemaker. The attribute can also be expressed as a characteristic of the data request. This can be implemented, for example, as a specific bit or sequence of bits that are automatically set by the second controller.

[0019] In one embodiment, the second control device comprises a computation circuit and a read-only memory (ROM) containing code executed on the computation circuit. Such an embodiment using a ROM makes the configuration of the immutability of the second control device particularly simple. In general, however, any embodiment that can prevent remote updates can enable the immutability of the second control device.

[0020] In one aspect, the invention relates to a leadless pacemaker communication system comprising a service device enabling user interaction to retrieve data from a leadless pacemaker. The system further comprises a patient device, in particular a patient device according to the preceding description. Such a patient device is configured to transmit and receive data to and from the service device and to and from the leadless pacemaker. The patient device comprises a first controller for controlling communication to and from the service device. Furthermore, it comprises a second controller for controlling communication to and from the leadless pacemaker. In this context, the second controller is invariant.

[0021] In one embodiment, the leadless pacemaker communication system further comprises a leadless pacemaker operatively coupled to a patient device, the operative coupling being established between a second controller and the leadless pacemaker. In one embodiment, the operative coupling is achieved by inductive communication. Inductive communication requires proximity between the leadless pacemaker and the patient device.

[0022] In one embodiment, the service device is a mobile device and / or a service center device. The mobile device is located in close proximity to the patient device and includes software (e.g., implemented as an app) for acquiring data from the leadless pacemaker. A close location occurs when the patient device is separated from the mobile device by a distance in the range of 1 cm to 1 m, in particular 5 cm to 90 cm, in particular 10 cm to 80 cm, in particular 20 cm to 70 cm, in particular 30 cm to 60 cm, in particular 40 cm to 50 cm. The service center device is located remotely from the patient device and includes software for acquiring data from the leadless pacemaker. A remote location occurs when the service device is located more than 1 m from the patient device, typically in another room or building, in an embodiment in another town, or even another country, or another continent.

[0023] Additionally or alternatively, there are several concepts for how remote interrogation can be performed: (1) implantation of the lead patient device, a mobile phone, into a service center; or (2) implantation of the lead patient device into a service center.

[0024] In one embodiment, the mobile device is a smart watch, a mobile phone, a smart phone or a tablet. It can establish a communication link with the patient device, typically via a short-range wireless connection such as Bluetooth or Bluetooth Low Energy (BLE). Other communication standards are possible, especially those mentioned above.

[0025] In one embodiment, the service center device establishes a communications link to the patient device via a long range communications standard such as GSM or CDMA wireless uplink.

[0026] In one embodiment, the service center device establishes a connection to the patient device utilizing a mobile device as an intermediate service device. This mobile device may be a mobile device from one of the above-mentioned embodiments. The service center device then communicates with the mobile device in a wireless manner, which in turn communicates with the patient device in a wireless manner. In that way, the patient device does not need to be equipped with a communication module that allows long-range wireless communication. Rather, this functionality is provided by the mobile device located in close proximity to the patient device, such that a first wireless link is established between the patient device and the mobile device, and a second wireless link is established between the mobile device and the service center device.

[0027] In one embodiment, the service center device has access to a database, such as a remotely managed database. Typically, a user accessible graphical user interface is provided to enable user interaction with the service center device and with additional connected devices, such as a leadless pacemaker implanted in a patient.

[0028] In one aspect, the invention relates to a method for enabling secure communication between a patient device and a leadless pacemaker, the method comprising the steps described below.

[0029] A request to retrieve leadless pacemaker data is received from a service device under control of a first controller.

[0030] The received request is then transmitted to the leadless pacemaker under control of the second controller.

[0031] A response from the leadless pacemaker is then received under control of the second controller. Finally, the response is sent to the service device under control of the first controller. In this context, the second controller is immutable. As described above, this division of the service device-enabled communication into a first part (between the first controller and the service device) and a second part (between the second controller and the leadless pacemaker), together with the immutable configuration of the second controller, ensures secure communication between the patient device and the leadless pacemaker that is resistant to remote attacks, such as cyber attacks. Thus, the method enables interrogation of the leadless pacemaker, for example using inductive communication, without providing an attack surface that could remotely manipulate the patient device to change the state of the leadless pacemaker.

[0032] Alternatively or additionally, encryption and / or authentication may be used between all devices and / or device components used to ensure that communications between them are private and authentic.

[0033] All embodiments of patient devices can be combined in any desired manner and transitioned either individually or in any combination into a leadless pacemaker communication system and described communication methods. Similarly, all embodiments of leadless pacemaker communication systems can be combined in any desired manner and transitioned either individually or in any combination into a patient device and described communication methods. Furthermore, all embodiments of the described communication methods can be combined in any desired manner and transitioned either individually or in any combination into a patient device and leadless pacemaker communication system.

[0034] Further details of aspects of the invention are explained below with reference to exemplary embodiments and the accompanying drawings. [Brief description of the drawings]

[0035] [Figure 1] 1 illustrates a communication path known from the prior art for remote interrogation of a leadless pacemaker. [Diagram 2] An embodiment of a patient device that enables secure communication with a leadless pacemaker is shown. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0036] FIGURE 1 shows a communication path known from the prior art that functions for remote interrogation of a leadless pacemaker. For this communication path, a user can operate a user-accessible graphical user interface (GUI) 100. The GUI 100 is connected to a remotely managed database 101 at a service center. The remotely managed database 101 can communicate via GSM with a mobile phone 102 with an app that also functions to communicate wirelessly with a patient device 103. For this wireless connection between the mobile phone 102 and the patient device 103, a Bluetooth connection is typically used. The patient device 103 sends an interrogation command 104 to the leadless pacemaker 105. The leadless pacemaker 105 sends the requested data 106 back to the patient device 103. From there, the data 106 can be provided to the mobile phone 102 and can be displayed within the app of the mobile phone 102. Furthermore, the data can be further transmitted to the remotely managed database 101.

[0037] FIGURE 2 shows a patient device 200 that serves as a communications bridge between a service device 201, in this example a mobile phone 201, and a leadless pacemaker 202 implanted in a patient in need thereof. The patient device 200 includes a first controller 203 that functions as a first controller. The first controller 203 serves the communications between the patient device 200 and the mobile phone 201. The first controller 203 is updatable and enables data communications with a high level of functionality. Data communications between the first controller 203 and the mobile phone 201 are achieved via a Bluetooth connection.

[0038] The patient device 200 further comprises a second controller 204 functioning as a second controller. The second controller 204 functions to establish wireless communication with the leadless pacemaker 202 via inductive telemetry. An interface 205, here a hardware bus interface 205, functions to establish communication between the first controller 203 and the second controller 204.

[0039] The second controller 204 allows only a low level of communication between the patient device 200 and the leadless pacemaker 202. Due to this lower level of functionality of the second controller 204, the hardware bus interface 205 also limits the possible data exchange between the first controller 203 and the second controller 204 to data that can be understood by the second controller 204. In other words, the hardware bus interface 205 only allows data exchange between the first controller 203 and the second controller 204 at a limited level corresponding to the low level of functionality of the second controller 204. This ensures that only relatively simple requests can be received by and forwarded from the second controller 204 to the leadless pacemaker 202.

[0040] The second controller 204 is immutable. Thus, the second controller 204 cannot be updated or patched. As a result, the functionality provided to the second controller 204 during manufacturing of the patient device 200 remains the same throughout the life of the second controller 204. Thus, the type of data communication between the second controller 204 and the leadless pacemaker 202 is defined during the manufacturing process of the patient device 200 and is not susceptible to remote attacks that attempt to compromise the functionality of the leadless pacemaker 202. Furthermore, the hardware bus interface 205 is also made immutable such that it is not vulnerable to any remote security attacks.

[0041] The split architecture of the patient device 200 using a first controller 203 for external communication and a second controller 204 for communication with the leadless pacemaker 202 ensures secure data communication between the patient device 200 and the leadless pacemaker 202 that is not compromised by external attacks.

[0042] The patient device 200 further comprises user interface elements 206 operatively coupled to the first controller 203. These user interface elements 206 (e.g., buttons, LEDs, displays, GUIs, or other hardware, software, or graphic elements) may enable user interaction with the patient device 200 or indicate the status of the patient device 200 to a user, such as a patient. The first controller 203 is updatable so that the latest in data transmission standards required for secure and state-of-the-art data communication with the mobile phone 201 can be used. Thus, a user using an app on the mobile phone 201 will enjoy easy, reliable, and state-of-the-art communication with the patient device 200. Nevertheless, by providing the second controller 204, secure and attack-resistant communication between the patient device 200 and the leadless pacemaker 202 is achieved.

Claims

1. A patient device (200) for a leadless pacemaker communication system configured to transmit and receive data to and from a service device (201) and to and from a leadless pacemaker (202), the patient device (200) comprising: a first control device (203) for controlling communication between the first control device (203) and the service device (201); a second controller (204) for controlling communication with the leadless pacemaker (202); A patient device (200) wherein the second control device (204) is unchanged.

2. The patient device of claim 1 , wherein the first control device (203) is updatable.

3. 3. The patient device of claim 1, wherein the patient device is controlled by the first control device and comprises a first communication transceiver that functions to transmit and receive data to and from a service device in a wireless manner.

4. 3. The patient device of claim 1, wherein the patient device comprises a second communications transceiver controlled by the second controller and operative to transmit and receive data to and from a leadless pacemaker in an inductive manner.

5. 3. The patient device of claim 1, wherein the patient device comprises an interface between the first control device and the second control device, the interface allowing only limited data exchange between the first control device and the second control device due to the intentionally limited data comprehension of the second control device.

6. 3. The patient device of claim 1 or 2, wherein the second controller is configured to disallow sending a request to the leadless pacemaker to disable a write protection mechanism of the leadless pacemaker.

7. 3. The patient device of claim 1, wherein the second control device (204) is configured to assign an attribute to any data request provided from the first control device (203), the attribute classifying the data request to which the attribute is assigned as originating from a remote device.

8. 3. A patient device according to claim 1 or 2, wherein the second controller (204) comprises a computing circuit and a read-only memory containing code that executes on the computing circuit.

9. 1. A leadless pacemaker communication system comprising: a service device (201) that enables user interaction to retrieve data from the leadless pacemaker (202); a patient device (200) configured to transmit and receive data to and from the service device (201) and to and from a leadless pacemaker (202), the patient device (200) comprising: a first control device (203) for controlling communication between the service device (201); a second controller (204) for controlling communication with the leadless pacemaker (202); The leadless pacemaker communication system, wherein the second controller is unchanged.

10. The leadless pacemaker communication system of claim 9 further comprising a leadless pacemaker operably coupled to the patient device.

11. 11. The leadless pacemaker communication system of claim 9 or 10, wherein the service device (201) is a service center device remote from the patient device (200) and comprises software for acquiring data from the leadless pacemaker (202).

12. 12. The leadless pacemaker communication system of claim 11 further comprising a mobile device, the service center device configured to establish a connection to the patient device utilizing the mobile device as an intermediate service device.

13. 11. The leadless pacemaker communication system of claim 9 or 10, wherein the service device is a mobile device located in proximity to the patient device and comprises software for acquiring data from the leadless pacemaker.

14. The leadless pacemaker communication system of claim 12 , wherein the mobile device is a smart watch, a mobile phone, a smartphone, or a tablet.

15. A method for enabling secure communication between a patient device (200) and a leadless pacemaker (202), the method comprising: receiving, under control of a first controller (203), a request to retrieve leadless pacemaker (202) data from a service device (201); sending the request to the leadless pacemaker under control of a second controller; receiving a response from the leadless pacemaker under control of the second controller; transmitting the response to the service device (201) under the control of the first control device (203); The method wherein the second control device is unchanged.

Images