Low-power medical device communication system and devices for such a system

Abstract

An implantable medical device, IMD, for patient monitoring or treatment that collects clinical data for upload to a remote data center. The IMD is equipped with a first wireless transceiver configured to operate according to a wireless personal area network, WPAN, communications protocol to transmit the clinical data using a first data communication path and a second wireless transceiver configured to operate according to a low-power wide-area network, LPWAN, communications protocol to transmit the clinical data using a second data communication path. The IMD is provided with computing resource to decide when and with which of the first and second wireless transceivers clinical data collected by the IMD is transmitted.

Description

[0001] LOW-POWER MEDICAL DEVICE COMMUNICATION SYSTEM AND DEVICES FOR SUCH A SYSTEM

[0002] The invention relates to a low-power medical device communication system (MDCS) for communication between implantable medical devices (IMD) and a remotely located data repository hosting clinical data that has been uploaded from the IMDs for the purpose of remote patient monitoring. The invention further relates to an IMD and an IMD battery charger for such a MDCS.

[0003] Remote patient monitoring to monitor the health of patients fitted with IMDs and the status of their IMDs is well known. A non-exhaustive list of IMDs is: an implantable pulse generator (IPG), a spinal cord stimulator (SCS), a cardiac pacemaker, an implantable cardioverter defibrillator device (ICD), an implantable loop recorder (ILR), and an implantable neuromodulation device (IND).

[0004] An IMD is implanted in a patient and is configured to upload clinical data on a continual and / or trigger-based basis via a MDCS to a remotely located data repository, which may be a data center. In this document, we use clinical data as an umbrella term to include both patient data relating to physiological monitoring of a patient's health, for example as collected by sensors of the IMD, and device data related to status and operation of the IMD, for example data logging each time an SCS device and / or SCS program is used and at what stimulation level in terms of electrical pulse width, duty cycle, therapy waveform, electrical contacts (anodes / cathodes) and / or pulse frequency.

[0005] These clinical data can then be accessed by health care staff accessing the data center using suitably designed software applications. Treatment plans and, if necessary, interventions can then be decided upon based on analysis of these clinical data.

[0006] Figure 1 shows a standard architecture of a MDCS for communication between an IMD implanted in a patient and a remotely located data center, which is accessible to health care staff using suitable application software. The IMD 10 includes therapeutic components for patient treatment, such as a stimulator 11 or other patient treatment device, and therapeutic components for patient monitoring, such as a sensor 13 or other patient monitoring device. The IMD 10 further comprises chipsets providing computing and telecommunications resource in the form of memory 17, a processor 18 and a low-power wireless personal area network (WPAN) wireless transceiver 12. The IMD 10 is powered by a rechargeable battery 14. The IMD 10 could also be powered by a non-rechargeable battery. The IMD's rechargeable battery 14 of an implanted IMD can be charged in a contactless manner by an inductive charger 20, for example a resonant inductive charger, which is placed on the patient's skin adjacent the implanted IMD 10 to charge its rechargeable battery 14. The charger 20 is itself provided with a rechargeable battery 24 as an electrical energy source as well as an external mains power connection 29 to power the charger 20 so that its rechargeable battery 24 can be recharged. Alternatively, the charger's battery 24 can be recharged wirelessly by placing on a mains- powered charging pad. The IMD local radio 12 uses a suitable WPAN protocol such as Bluetooth Low Energy (BLE), Medical Implant Communication System (MICS), Medical Device Radiocommunications Service (MedRadio), the latter two being almost identical protocols, or proprietary inductive communications in the <100 kHz range (e.g. for distances <10 cm).

[0007] BLE has an operating frequency band usually quoted as 2.4 GHz but which is more specifically one of the ISM radio bands defined by the ITU Radio Regulations, which occupies the frequency band 2.400 to 2.4835 GHz, i.e. with a bandwidth of somewhat less than 100 MHz. BLE is specified with a nominal maximum range of 100 meters. However, a typical range is likely to be a few tens of meters and possibly considerably less in a building setting (or even less than a few meters in case of deeply implanted device) owing to physical obstructions such as walls and interference sources, as constituted by other consumer and domestic electronic devices. MICS and MedRadio occupy a frequency band between 401-406 MHz and are very short range with a range of only two meters.

[0008] The patient is provided with a patient remote controller 30 (patient remote), for example a smartphone with wireless transceivers 32, 35, 36 respectively for WPAN, cellular and WLAN communication. If a smartphone is used, this is a smartphone that is possessed, e.g. owned, by the patient in whom the IMD 10 is implanted and on which a software application ('app') is installed. The app is then a so-called Software as a Medical Device (SaMD) which is defined by the United States Food and Drug Administration (FDA) as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.

[0009] The cellular transceiver 35 and WLAN transceiver 36 provide two different data communication paths for the patient remote 30 to upload clinical data from the IMD 10 to a remotely located data center 60 (backend, e.g., Neuro Service Center) acting as a host for the services, for example a neuro data center. The remote's WLAN transceiver 36 can upload data to the backend 60 via a router 38 and telephone line 40 using a wired internet connection. The remote's cellular transceiver 35 can upload data to the backend 60 via one or more cellular network base stations 42 (cellular towers). In some cases, instead of a public communication network, a dedicated point-to-point transmission, e.g. via a dedicated telephone line, may be provided for uploading clinical data.

[0010] In all these scenarios, uploading of clinical data from the IMD 10 to the backend 60 takes place via the intermediary of the patient remote 30, the latter thereby acting as a relay device.

[0011] Health care staff, such as health care professionals (HCPs), clinical specialists and representatives and remote care team members have access to the backend 60 via suitable portals 70 with the aid of a software application running on the backend 60 and / or the portal 70 to provide the necessary user interfacing, diagnostics and so forth.

[0012] It has been observed that communication between an IMD and the data center is sometimes lost. One cause is when the patient remote is out of range of local radio communication with the IMD, e.g. when left in a different room. Another cause is a discharged battery in the IMD or in the patient remote, so that the IMD or patient remote is powered down. These issues are more common when the IMD is of a kind that has no user adjustment, for example in sub-perception stimlulation therapy, in which case the patient has no ongoing need or prompt to keep their patient remote charged and close by. A further limitation is when the MDCS is designed assuming the patient will use a smartphone running a suitable SaMD software application (app) to act as the patient remote relay device. Many patients lack the skills and cognitive abilities to maintain a SaMD app on a smartphone, or the patient condition or ability may change over time as the IMD may be implanted for 10 years or more. In all these cases, the relay function of the patient remote is likely to be lost intermittently owing to it not being able to fulfill its function in the MDCS.

[0013] Specifically, the American Medical Association has defined a set of medical codes referred to as Current Procedural Terminology (CPT) for remote physiologic and therapeutic monitoring of patients. For compliance with these codes it is required to upload clinical data from a given patient with a certain frequency over a given time period, e.g. over at least 16 different days in a 30-day period, and so interruptions in communication that fail to meet the CPT requirements can have serious negative consequences.

[0014] According to one aspect of the disclosure there is provided an implantable medical device for implanting into a patient, comprising: an electrical energy source; therapeutic components for at least one of patient monitoring and treatment that are powered by the electrical energy source and configured to collect clinical data including at least one of patient data relating to a patient's health (this may be any kind of physiological data) and device data related to status and operation of the implantable medical device; a first wireless transceiver configured to operate according to a wireless personal area network, WPAN, communications protocol to transmit the clinical data using a first data communication path; a second wireless transceiver configured to operate according to a low-power wide-area network, LPWAN, communications protocol to transmit the clinical data using a second data communication path; and a memory and a microprocessor, wherein the memory stores clinical data prior to its transmission and further stores a computer program which when executed on the microprocessor controls activation of each of the first and second wireless transceivers and makes decisions on when and with which of the first and second wireless transceivers clinical data stored in the memory is transmitted.

[0015] In certain embodiments, the therapeutic components comprise at least one patient treatment device. The patient treatment devices may be one or more of: a pulse generator for an implantable pulse generator; a neurostimulator for spinal cord stimulation; pulse delivering electrodes for a cardiac pacemaker; pulse delivering electrodes for a cardioverter defibrillator; magnetic field generator for an implantable neuromodulation device; and electrical current generator for an implantable neuromodulation device.

[0016] In certain embodiments, the therapeutic components comprise at least one patient monitoring device. The patient monitoring devices may be one or more of: a temperature sensor; a pressure sensor; a pressure and volume sensor (e.g. for heart blood volume sensing); an activity sensor (e.g. piezoelectric or accelerometer); an accelerometer; a microphone (e.g. for cochlear implant); a light sensor (e.g. an optical fiber interferometer, a light attenuation sensor); electrodes for an implantable loop recorder (e.g. for cardiac sensing); a cardiac signal sensor; an evoked compound action potential (ECAP) sensor; electrodes and sensing circuitry for ECAPs; electrodes for a (blood sugar level) glucose sensor (e.g. for continuous glucose monitoring); and a blood pressure sensor (e.g. piezoresistive, capacitive, inductive -capacitive, optical transduction).

[0017] Example WPAN communications protocols supported by the first wireless transceiver include: Bluetooth Low Energy (BLE); Medical Implant Communication System (MICS); Medical Device Radiocommunications Service (MedRadio); Near-Field Communication (NFC); and / or resonant or non-resonant inductive communication, e.g. low power proprietary inductive communications (resonant and non-resonant).

[0018] Example LPWAN communications protocols supported by the second wireless transceiver include: LTE-M (LTE Advanced for Machine Type Communications), NB-IOT (NarrowBand IOT), IEEE 802.11ah, IEEE 802.15.4a, ISO / IEC 18000-7, and EN13757-4. LPWAN communications protocols appear on the market under various trade names such as LoRa, mioty, Weightless, DASH7, Sigfox, and Wize.

[0019] According to another aspect of the disclosure there is provided a medical device communication system utilizing mobile telecommunications network infrastructure that supports a low-power wide- area network, LPWAN, communications protocol, the system comprising: an implantable medical device having first and second wireless transceivers, wherein the first wireless transceiver is configured to operate according to a wireless personal area network, WPAN, communications protocol and wherein the second wireless transceiver is configured to operate according to said LPWAN communications protocol; and a data repository hosting clinical data uploaded from the implantable medical device and that has at least one data communication path to the mobile telecommunications network infrastructure, the system providing first and second data communication paths between the implantable medical device and the data repository, wherein the first data communication path uses said LPWAN communications protocol to transmit between the implantable medical device and the mobile telecommunications network infrastructure, and the second data communication path uses said WPAN communications protocol to transmit between the implantable medical device and a further device, said further device acting as a relay device for onward transmission to the data repository using a further communications protocol.

[0020] The relay device may be any of: a charger for the implantable medical device (e.g. a transcutaneous charger); a user equipment, UE, capable of using the mobile telecommunications network infrastructure; and a wireless local area network, WLAN, enabled device capable of communicating with a router that is in data communicable connection with the data repository. The relay device may have more than one of these functions, for example be a smartphone or tablet which is both WLAN enabled and a telecoms UE. The further communications protocol used by the relay device may be a protocol according to one of: a low-power wide-area network, LPWAN; a wireless local area network, WLAN; 4G; LTE and 5G, or a combination thereof.

[0021] According to a still further aspect of the disclosure there is provided a charging device for wirelessly charging a rechargeable electrical energy source contained in an implantable medical device, the charger comprising: an electrical energy source to provide energy for charging the rechargeable electrical energy source of an implantable medical device; an induction coil (e.g. a resonant induction coil) for transferring energy to a matching or corresponding induction coil of an implantable medical device; a first wireless transceiver configured to operate according to a wireless personal area network, WPAN, communications protocol; a second wireless transceiver configured to operate according to a low-power wide-area network, LPWAN, communications protocol; and a memory and a microprocessor, wherein the memory stores clinical data received by the first wireless transceiver using said WPAN communications protocol prior to its transmission by the second wireless transceiver using said LPWAN communications protocol, and further stores a computer program which when executed on the microprocessor controls activation of each of the first and second wireless transceivers and makes decisions on when the second wireless transceiver transmits the clinical data stored in the memory.

[0022] The charging device may further comprise a third wireless transceiver configured to operate according to a wireless local area network, WLAN, communications protocol. In that case, the computer program can also control activation of the third wireless transceiver and makes decisions on when and with which of the second and third wireless transceivers the clinical data stored in the memory is transmitted.

[0023] To support use of a WPAN and WPLAN capable charging device, the computer program may be configured to control data communication between the charging device and an implantable medical device via the first wireless transceiver using said WPAN communications protocol, and further data communication between the charging device and mobile telecommunications network infrastructure using said LPWAN communications protocol. This invention will now be further described, by way of example only, with reference to the accompanying drawings.

[0024] Fig. 1 is a schematic diagram of a MDCS according to an example standard architecture known in the prior art.

[0025] Fig. 2 is a schematic diagram of a MDCS with IMD according to a first embodiment.

[0026] Fig. 3 is a schematic diagram of a MDCS with IMD and intelligent inductive charger according to a second embodiment.

[0027] Fig. 4 is a schematic diagram of a MDCS with IMD and intelligent inductive charger according to a third embodiment.

[0028] Fig. 5 schematically illustrates various functional units of the IMD as can be used in any of the first to third embodiments.

[0029] Fig. 6 is a flow diagram showing steps of a method of uploading clinical data and acting on downloaded control data in a MDCS according to certain embodiments.

[0030] In the following detailed description, for purposes of explanation and not limitation, specific details are set forth in order to provide a better understanding of the present disclosure. It will be apparent to one skilled in the art that the present disclosure may be practiced in other embodiments that depart from these specific details.

[0031] Those skilled in the art will further appreciate that the services, functions and steps explained herein may be implemented using software, i.e. a computer program, stored in memory and functioning in conjunction with a programmed microprocessor, or using an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Programmable Logic Array (PLA), or a field programmable gate array (FPGA). As such references to a processor should include ASICs including artificial intelligence accelerator ASICs, DSPs, PLAs and FPGAs as well as central processor units (CPUs), graphics processor units (GPUs). References to memory in the following may refer to any one or more of: a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), and a static random access memory (SRAM).

[0032] References to computer program in the following refer to machine readable program instructions for carrying out operations and may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C#, Python, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages.

[0033] Certain terms used in the following detailed description of exemplary embodiments are defined as follows:

[0034] 4G: is the fourth generation of mobile telecommunications technology as defined by the ITU in IMT Advanced, such as LTE (Long Term Evolution).

[0035] 5G: is the fifth generation of mobile telecommunications and wireless technology.

[0036] UA: is part of a UE and acts as a client in a transport protocol for communication with a server.

[0037] UE: is a terminal that resides with the user which hosts a UA

[0038] WLAN: is a wireless local area network standard, for example according to one of the family of IEEE 802.11 standards.

[0039] It will be understood that features and elements of the standard MDCS architecture described above with reference to Figure 1 will be incorporated in embodiments of the invention as appropriate and specific detail already described above may not be repeated in the following detailed description for corresponding features.

[0040] In recent times, low-power wide-area network (LPWAN) technology has become available that allows for low-power radio frequency (RF) transmission of data over the cellular network at modest transmission rates as needed for Internet of Things (loT) sensors. Typical data payload and transmission rates for LPWAN are total payload < 25 kB and daily transmission.

[0041] Currently there are two LPWAN technologies that are widely available: LTE Cat M (LTE-M) and Narrowband loT (NB-IoT). Both are intended for low power / low data rate / low duty cycle transmission of data from remote loT sensors to the internet. These technologies employ side bands or guard bands of existing LTE (Long Term Evolution) cellular networks, and thus are generally not in need of dedicated cellular infrastructure. Notable differences are that NB-IoT is marginally more power efficient than LTE-M and that LTE-M allows for cellular tower hand-off LTE-M therefore caters for continuity of communication when traveling from one cellular tower to another, whereas NB-IoT does not. Some specification parameters of NB-IoT and LTE-M are summarized in the following table:

[0042] NB-IoT LTE-M

[0043] Peak Data Rate <100 kbps >384 kbps, up to 1 Mbps

[0044] Latency 1.5-10 50-100 ms

[0045] Bandwidth <200KHz 1.4 MHz

[0046] Power Consumption Best at very low data rates Best at medium to high data rates

[0047] Mobility No for Cat-NB 1, limited for Cat-NB2 Yes

[0048] Support for Voice

[0049] No

[0050] (VoLTE)

[0051] Antennas 1

[0052] NB-IoT and LTE-M both provide two power-saving modalities: Power Saving Mode (PSM) and Extended Discontinuous Reception (eDRX).

[0053] PSM is a modality that enables the device to set sleep and active timers which are then forwarded to the network. If accepted by the network, the network will keep the device registered in the system for the set time . If the device wakes up during this time, no re-attach procedure is needed (detach and re-attach procedures can be very energy consuming). During the sleep interval, the device is not reachable, but the network knows, due to the timers, the next wake-up time of the device and how long it will be active to receive paging messages. It is possible to set a device in a deep sleep mode for up to 14 days. In PSM, the device can also be woken up on receipt of certain triggers, such as TAU (Tracking Area Update) and RAU (Routing Area Update). In PSM mode, the device needs to be triggered to become reachable, so PSM is an asynchronous mode. eDRX is a modality that extends the time of the regular discontinuous reception (DRX) modality provided in LTE networks. Regular DRX saves power by allowing a device to switch off its receiver, and thus save power, during periods of inactivity for a time period of up to a few seconds. The extension of DRX to eDRX allows for more extended switch-off times of up to several hours. A device in the eDRX mode is thus available for paging through mobile terminated services every so often, i.e. over a short period within each eDRX cycle. In eDRX mode, the device is reachable once every cycle, so PSM is a synchronous mode.

[0054] Certain embodiments of the invention are now described with reference to Figures 2 to 4. In this description, for the low -power wireless personal area network (WPAN) protocol, we refer to a BLE radio by way of example, noting that other types of low-power WPAN protocol are also suitable, such as MICS radio, MedRadio radio, proprietary inductive or resonant inductive telemetry and near- field communication (NFC) radio. Moreover, after describing the first embodiment, in subsequent embodiments common features are not in all cases described again or described to the same level of detail for the sake of brevity.

[0055] Figure 2 is a schematic diagram of a MDCS 1 with an IMD 10 and an IMD charger 20 according to a first embodiment. The IMD 10 includes therapeutic components for patient treatment, such as a stimulator 11, and therapeutic components for patient monitoring, such as a sensor 13, as well as chipsets providing computing and telecommunications resource in the form of memory 17, a processor 18 and first and second wireless transceivers 12, 15. The therapeutic components are powered by the electrical energy source 14, which will typically be a battery, more specifically in this embodiment a rechargeable battery. In other embodiments a single-use battery or primary cell battery may be used, i.e. not rechargeable. Alternatively, the electrical energy source need not be a battery. For example, it could be a storage capacitor. The first wireless transceiver 12 is configured to operate according to a low-power WPAN communications protocol, such as BLE, to transmit the clinical data using a first data communication path (illustrated with dot-dashed lines) and optionally also to receive control data from a remotely located data center acting as repository for storage of clinical data, referred to in the following as the backend 60. The second wireless transceiver 15 is configured to operate according to a LPWAN communications protocol to transmit the clinical data using a second data communication path (illustrated with dot-dashed lines) and optionally also to receive control data from the backend 60. The IMD 10 is configured to collect clinical data including at least one of patient data relating to a patient's health and device data related to status and operation of the IMD 10. The clinical data is locally stored in the memory 17 prior to onward transmission to the backend 60. The memory 17 also stores a computer program, i.e. computer readable instructions, which when executed on the processor 18 controls collection, local storage and transmissions of the clinical data, wherein activation of the first and second wireless transceivers 12, 15 is based on the computer program making decisions on when and with which of the first and second wireless transceivers 12, 15 transmissions of the clinical data is to be performed. An electrical charger 20 is provided for wirelessly recharging the IMD battery 14 through induction (e.g., resonant induction, or other options including ultrasound). The charger 20 is itself provided with a rechargeable battery 24 as its electrical energy source as well as an external mains power connection 29 to power the charger 20 so that its rechargeable battery 24 can be recharged. Alternatively, the charger can be recharged wirelessly by placing it on a mains-powered charging pad.

[0056] The MDCS 1 provides first and second data communication paths from the IMD 10 to the backend 60 as illustrated respectively with dot-dashed and dashed lines. The first data communication path involves direct communication between the IMD 10 and a LPWAN-capable cellular network base station 42, referred to in the following as a cellular tower, using the IMD's LPWAN transceiver 15. The second data communication path involves the IMD's low-power WPAN transceiver 12 (e.g. BLE) transmitting to a WPAN-capable smartphone 30. The smartphone 30 is possessed by the patient in which the IMD 10 is implanted which has a software application ('app') installed acting as SaMD for the IMD 10. The smartphone 30 has wireless transceivers 32, 35, 36 respectively for WPAN, cellular and WLAN communication. For the second data communication path, the smartphone 30 relays the clinical data it receives from the IMD 10 onwards to the backend 60 in one of two ways. One option for the second data communication path is to use the smartphone's WLAN capability to transmit the signal to a router 38, and the router 38 transmits the clinical data onward via a telephone network 40 to the backend optionally via a distributed network forming cloud services 50. Another option for the second data communication path is to use the smartphone's cellular capability as a user equipment (UE), e.g. using LTE, 4G (4th generation) or 5G (5th generation) protocols, to transmit the clinical data onward to the cellular tower 42 and then to the backend 60 optionally via cloud services 50.

[0057] The first embodiment thus provides two modes of data communication, there being the first data communication path which uses direct communication from the IMD to the cellular network without any intermediary relay device and the second data communication path which uses an intermediary relay device with the capability of WLAN transmission and / or cellular transmission. The MDCS is thus resilient to outage of the relay device through providing the first data communication path in which the IMD communicates directly with the cellular network. It will be further understood that healthcare staff, such as healthcare professionals (HCPs), clinical specialists and representatives and remote care team members have access to the backend 60 via suitable workstations 70, referred to as portals, with the aid of a software application running on the backend 60 and / or the portals 70 to provide the necessary user interfacing, diagnostics and so forth for assessment of the clinical data. Figure 3 is a schematic diagram of a MDCS 1 with IMD 10 and charger 20 according to a second embodiment. In the second embodiment, the IMD's external charger 20 may be referred to as a wireless-enabled smart charger in that it is provided with low-power WPAN and LPWAN wireless chip sets 22, 25 as well as memory 27 and a processor 28. The MDCS 1 provides first and second data communication paths from the IMD 10 and its smart charger 20 to the backend 60 shown respectively with dot-dashed and dashed lines. The first data communication path involves direct communication between the IMD 10 and optionally also its smart charger 20 and a proximal cellular tower 42 using the respective LPWAN transceivers 15, 25 provided in the IMD 10 and its smart charger 20. The second data communication path involves a smartphone 30 possessed by the patient in whom the IMD is implanted which has a software application ('app') installed acting as SaMD for the IMD. The smartphone 30 has transceivers 32, 34 / 35, 36 respectively for WPAN, LPWAN / cellular and WPAN communication. The LPWAN and cellular signals may be handled by the same transceiver given that LPWAN utilizes the guard bands of the regular cellular signal using a usual protocol according to 4G, LTE, 5G etc. For the second data communication path, the respective low-power WPAN transceivers 12, 22 of the IMD 10 and its smart charger 20 transmit to the smartphone 30 which as mentioned above also has a low-power WPAN capability. The smartphone 30 then relays the clinical data onwards in the second data communication path in one of two ways. One option for the second data communication path is to use the smartphone's WLAN to transmit the clinical data to a router 38, and the router 38 transmits the clinical data onward via the telephone network 40 to the backend 60 optionally via cloud services 50. Another option for the second data communication path is to use the smartphone's cellular capability, e.g. LTE, 4G or 5G, to transmit the clinical data onward to the cellular tower 42 and then to the backend 60 optionally via cloud services 50. The second embodiment thus provides two modes of data communication, there being the first data communication path which uses direct communication from the IMD, and optionally also its charger, to the cellular network without any intermediary relay device and the second data communication path which uses a smartphone as an intermediary relay device.

[0058] Figure 4 is a schematic diagram of a MDCS 1 with IMD 10 and smart charger 20 according to a third embodiment. In the third embodiment, the IMD's external charger 20 is a smart charger provided with low-power WPAN, LPWAN and WLAN wireless chip sets 22, 25, 26 as well as memory 27 and a processor 28. The MDCS 1 provides first and second data communication paths from the IMD 10 and its smart charger 20 to the backend 60 illustrated respectively with dot-dashed and dashed lines. The first data communication path involves direct communication between the IMD 10, and optionally also its smart charger 20, and a proximal cellular tower 42 using the respective LPWAN transceivers 15, 25 provided in the IMD 10 and optionally also its smart charger 20. The second data communication path involves the IMD's low-power WPAN transceiver 12 transmitting to a low- power WPAN transceiver 22 of the smart charger 20. Another path for communication between IMD and Charger may be via backscatter communication during the recharging. Thereby a signal may be basically part of the power transmission scheme. This is sometimes called Load Shift Keying (LSK), and the data rate is usually low like < 5 kSymbols / sec. The smart charger 20 then relays the signal carrying the patient and device data onwards using the smart charger's WLAN transceiver 26 to transmit the clinical data to a router 38. The router 38 then transmits the clinical data onward via the telephone network 40 to the backend 60 optionally via cloud services 50. The third embodiment thus provides two modes of data communication, there being the first data communication path which uses direct communication from the IMD to the cellular network without any intermediary relay device and the second data communication path which uses the IMD charger as an intermediary relay device using the charger's low-power WPAN to receive the clinical data from the IMD and the charger's WLAN transceiver to transmit the clinical data. The use of the IMD charger as the relay device in the second data communication path has several advantages over use of a smartphone as the relay device, since it is essential for the patient to bring the IMD charger into close proximity with the IMD for charging and also since an intelligent IMD charger of this kind avoids the need to install and operate SaMD as an app on a smartphone.

[0059] In a variant of the third embodiment, the charger is modified to omit the WLAN transceiver. This variant may be useful if the charger is provided with greater resources than the IMD, e.g. a larger battery than the IMD, or greater computing resources in terms of its memory and / or processor. In this variant, the second data communication path would then, instead of using WLAN to transmit clinical data from the charger to the router, use the charger's LPWAN transceiver to transmit clinical data from the charger to a proximal cellular tower.

[0060] Detailed implementation of the various components of the above embodiments are now described and discussed in more detail.

[0061] The IMD is provided with a battery having sufficient peak current and capacity to provide reasonable performance for its LPWAN cellular radio. For example, a rechargeable lithium-ion battery or battery stack can be used with a capacity of 200-300 mAh and capable of delivering a peak current of between 200 and 900 mApk in short bursts. This battery specification is sufficient when the communication duty cycle is kept low so that average current consumption is very low.

[0062] The IMD, and in some embodiments also its charger, are each provided with a suitable LPWAN transceiver chip set. An example of a suitable system-in-package chip is the Nordic Semiconductor nRF9160 which includes: a cellular modem, a 64 MHz ARM cortex M33 processor, 1MB flash memory, 256kB RAM memory within a package of dimensions 10x16x1.04 mm. The average current consumption of the nRF9160 chip with a supply voltage of 3.7 V and 23 dBm transmission power is: 2.7 pA PSM floor current for both NB-IoT and LTE-M; and in eDRX with a cycle length of 655 seconds currents of 9 pA and 6 pA respectively for NB-IoT and LTE-M.

[0063] The IMD comprises a housing which accommodates the IMD components including an electrical energy supply (battery), a memory, a processor, a LPWAN transceiver and a WP AN transceiver (e.g. BLE radio, MICS radio, MedRadio radio, near-field communication radio) as well as some or all of the therapeutic component features such as a circuit for delivering electrical stimulation energy to a patient in an SCS trial, sensors to measure ambient physical parameters or patient-specific physical parameters and so forth. The LPWAN radio may operate according to NB-IoT or LTE Cat M, for example.

[0064] As mentioned above clinical data to be transmitted in any particular instance may include one or both of patient data and device data. A non-exhaustive list of example patient data obtained from physiological monitoring by the IMD for upload to the backend is any of the following:

[0065] • intracardiac electrograms (lEGMs)

[0066] • electrocardiograms (ECGs)

[0067] • evoked compound action potentials (ECAP)

[0068] • local or ambient temperature

[0069] • physical activity of the patient

[0070] • angular orientation of the IMD

[0071] • patient blood pressure

[0072] • chemical sensor data collected by chemical sensors that are part of the IMD.

[0073] A non-exhaustive list of example device data collected from the IMD is: therapy adherence, charging adherence, stimulator status (hardware and software), battery charge state, lead impedance, magnet detection (used for patient triggered events).

[0074] According to NB-IoT or LTE Cat M, the LPWAN is ordinarily in a sleep mode but becomes active sporadically.

[0075] One option is for activity of the LPWAN to be triggered asynchronously by an event, which may be an external event or an internal event. PSM mode may be used for this. An external event can force the LPWAN to wake up through receipt of an external signal, e.g. in the form of a TAU or RAU in PSM mode. An internal event is one triggered by logic within the device hosting the LPWAN transceiver. An example external event would be when software running on the backend decides that clinical data must be received, e.g. owing to a long wait since the last clinical data was received. An example internal event would be when software running on the processor decides there is an urgent need to transmit patient data or device data to the backend, e.g. when a monitored physiological parameter goes outside a safe range. Event triggered activity of the LPWAN can be termed asynchronous.

[0076] Another option is for activity of the LPWAN to occur synchronously at pre-set time intervals, typically regular time intervals, such as once or twice a day, this being suitable for routine transmission of clinical data which does not have a high priority. eDRX mode may be used for this. The LPWAN protocol distributes the timings of the activity among the network nodes, IMD, user equipment etc. so these are known in advance. Lor example, there may be daily periods of activity at a set time of day, e.g. every day starting at 11 :00. The IMD communicates clinical data to a backend for remote patient monitoring, with the communication taking place either asynchronously following event triggers, or synchronously at regular intervals, or a combination of both.

[0077] As well as uploading patient data and device data from the IMD to the backend, the IMD may receive data from the backend. Lor example, the IMD may be configured to be responsive to remote commands that configure patient therapy or set sensing parameters.

[0078] The IMD may incorporate a switched-mode power supply (SMPS) to step-up or step-down the voltage supplied by the battery to the other components of the IMD. The SMPS may include both a buck-boost converter and a switched capacitor converter and which is used may be selectable, e.g. based on load characteristics. Lor example, the buck-boost converter may be selected when the LPWAN is active and the switched capacitor converter may be selected for PSM mode. There is a wide dynamic range of power requirements. Inductor based Boost, Buck and buck-boost are generally most efficient at higher loads such as when LPWAN (cellular) loads are required. Lor supporting sleep and stimulation a charge pump (switched capacitor) may provide higher efficiency. So based on the peak and average consumption an optimal switch mode converter may be used to minimize power consumption. A further example for a buck-boost converter is pulse width modulation (PWM) and Pulse Skipping Modulation (PSM).

[0079] The IMD may be provided with an embedded-SIM (eSIM), for example in the processor or in another chip of the IMD chipset, such as an application-specific integrated circuit (ASIC).

[0080] The IMD may also contain a global navigation satellite system (GNSS), such as GPS, Baidu or Galileo through provision of a suitable radio and antenna for geolocating the IMD. The GNSS data is provided to the processor to trigger location-specific transmission. For example, it may be useful to transmit data as the patient is attending the clinic, which may be implemented by detecting coordinates geofenced to a clinic to trigger data transmission. Such a geofencing concept may cover also cases like when a patient is moving more outside their home, this may be a type of physiological signal that the patient’s activity is increasing. In other words, the act of moving around is a kind of physiological measure of patient activity and wellness. To differentiate between the patient moving themselves and the patient being transported (e.g., to and from a care facility) information should be included from where the patient is going. For example, if its >2 miles it’s not likely they walked there. Also, GPS may provide information about speed (like it does in the car) for such a differentiation.

[0081] Figure 5 schematically illustrates how the IMD 10 includes various functional units within its programmed configuration to assist and control data transmission, these being a transmission path allocation unit 80, a data prioritization unit 82 and a data compression unit 84. These functional units can be used in any of the above embodiments individually or in any combination.

[0082] TRANSMISSION PATH ALLOCATION UNIT

[0083] The IMD processor includes a transmission path allocation unit which has the role of determining which transmission path is optimum for the present circumstances in terms of relevant factors such as power consumption and signal strength. Selection of the transmission path may be made based on a score derived from a factor-weighting table created in advance. A simple example is to select either LPWAN or a local wireless signal, such as BLE, based on the larger of the sum of A plus B where:

[0084] A is:

[0085] • BLE available: weight of 1.0;

[0086] • cellular signal available: weight of 0.9;

[0087] • no connection: weight of 0 B is:

[0088] • BLE signal strength <x: weight of 0.5;

[0089] • cellular signal strength >x: weight of 1.0;

[0090] • no connection: weight of 0

[0091] "No connection" may mean the logical extreme of the protocol weighting, where a zero is scored if a protocol is not available at all. Another simple scheme is to attempt transmission via a local wireless signal, such as BLE, and upon failure switch to LPWAN using the cellular network.

[0092] Selection of the transmission path may also depend on properties of the clinical data to be transmitted, for example: clinical importance or urgency of the clinical data; amount or size of clinical data; and receipt of a signal from the backend indicating an urgent requirement to receive more clinical data based on the data set already uploaded to the backend.

[0093] Alternatively, in other embodiments, the data transmission path determination can be done via analysis of labeled operational data over a period of time via a supervised learning algorithm, or via a routing algorithm specific to this application. A routing algorithm is a procedure that lays down the route or path to transfer data packets from source to the destination during transmission, i.e. after a data packet leaves its source, it can choose among the many different paths to reach its destination. Geolocation data may also be incorporated in the selection, e.g. to give a stronger weighting towards the local wireless signal when the IMD is at a known home location or a known work location.

[0094] DATA PRIORITIZATION UNIT

[0095] The IMD is configured to set priorities for transmitting data items based on multiple factors so it is decided whether transmission of the data items can be delayed or should be sent immediately. The data prioritization may be set via a look-up table . Relevant factors for prioritization may, for example, include:

[0096] • which transmission paths are permitted for transmitting the data items. For example, if certain data items have a higher degree of patient confidentiality, and one of the data communication path is deemed more secure than another, then the more secure data transmission path is selected for transmitting those data items;

[0097] • whether the data needs to be transmitted asynchronously or can wait until the next pre-defined transmission period (e.g. the allotted time of day for daily transmission) based on clinical assessment, such as IMD usage too low, IMD operation outside of a therapeutic range, active electrode impedance measured to be out of range, imminent IMD battery recharge needed;

[0098] • age of data. For example, each time a clinical data item is not uploaded in a synchronous preplanned time window then the clinical data item has an age-related priority parameter that is incremented so that when clinically non-urgent data is selected for upload in the next preplanned time window the oldest such data is given priority; and / or

[0099] • how much clinical data stored in the IMD memory is ready for transmission. For example, to make a transmission of clinical data that contains no data items with a high clinical priority, it may be a requirement that at least a threshold amount of data is ready for transmission (e.g. at least 1 kB of data), since the minimum energy usage associated with activation of the wireless transceiver and a data transmission of even a small amount of data is significant. Another example would be that an immediate transmission can be triggered, i.e. asynchronously, if the IMD memory is full or is predicted to become full in the near future, e.g. based on a memory fill factor of 80% being reached.

[0100] The IMD data prioritization can be configured via local or remote programming. The IMD data prioritization can also be amended by clinical staff members based on clinical decisions taken after analysis of the clinical data from the patient's IMD stored at the backend. The IMD data prioritization may also be reconfigured from time to time on an automatic basis applying an algorithm of needs related to remote patient monitoring. Automatic updating and configuration of the data prioritization may also be performed by e.g., a deep learning artificial intelligence program.

[0101] Example Data prioritization Table

[0102] Use Example 1: A care team member monitoring a patient via a user portal to access the backend comes to know that a patient’s IMD charging adherence is consistently good, so it no longer needs to be closely monitored. The care team member therefore unchecks a box in the portal indicating the need for receiving clinical data in real-time, i.e. as and when the clinical data is collected. The backend then transmits a message to the IMD, so the IMD knows that clinical data transmissions can be reduced in priority such that asynchronous data transmission is no longer routinely needed and, for example, daily transmission at an allotted time of day is sufficient. Of course, the logic in the IMD itself may nevertheless determine that certain clinical data items require asynchronous data transmission based on clinical importance, e.g. adverse patient health indicator, failure or predicted failure of some functionality of the IMD, or other factors as discussed above.

[0103] Use Example 2: A portal user, e.g. a care team member, may select to be notified about therapy adherence data which exceeds a certain threshold or bound, or goes out of a certain range. For example, the care team member may want to be informed immediately of stimulations and / or relating to therapy adherence of an SCS trial, after a patient has adjusted the stimulation amplitude more than 10 times in the current day. The portal user would enable this type of device data to be transmitted asynchronously through an event trigger. Subsequently, every patient adjustment of amplitude would cause an alert message to be sent immediately, i.e. asynchronously, from the IMD to the backend as it occurs using LPWAN. In practice, the latency of the upload may be of the order of minutes up to an hour. In this use example, other patient and device data could still be sent on a once-a-day basis at the allotted transmission time using either LPWAN or WPAN as determined by the IMD's transmission path allocation unit.

[0104] Figure 6 is a flow diagram showing steps of a method of uploading clinical data and acting on downloaded control data in a MDCS 1 as described above. As described above the data transmission method utilizes mobile telecommunications network infrastructure that supports a LPWAN communications protocol, such as LTE-M or NB-IoT.

[0105] In Step SI, clinical data accumulates, i.e. is collected from the IMD and locally stored in the IMD memory.

[0106] In Step S2, the locally stored clinical data is monitored and the items of data, such as physical parameters with discrete or scalar values, are classified according to one of a plurality of priority levels. In the simplest case, this is a binary classification between urgent and non-urgent data items. In other cases, 3 or more priority levels could be applied or multiple classification types could be created, such as two classification types which are both binary thus creating 4 permutations for the overall data item classification.

[0107] In Step S3, which is an optional step, the IMD assesses control data it may from time to time be received, i.e. downloaded, from a remote source such as the backend. The control data may be of a type that causes the IMD to reconfigure a setting of the IMD's therapeutic components, e.g. patient- accessible ranges of pulse width and pulse frequency in an SCS trial. In this case reconfiguration of the IMD is undertaken in Step S4. The control data may also be of a type that controls upload of clinical data, e.g. PSM mode TAU or RAU signals to externally trigger an asynchronous upload of clinical data which is dealt with in Step S5 as follows.

[0108] In Step S5, based on the ongoing monitoring of the priority-classified locally stored clinical data and any external trigger received in control data (Step S3), it is evaluated on an ongoing basis whether or not to initiate a clinical data transmission. If 'no', then the ongoing data accumulation and classification continues.

[0109] If 'yes', then in Step S6 the data path for the upload is selected, i.e. it is decided which of the IMD's wireless transceivers is to be used.

[0110] In Step S7, the clinical data is uploaded from the IMD using the selected one of the data communication paths, i.e. using either LPWAN or WPAN for the first segment of the data communication path from the IMD.

[0111] After an upload, the method then repeats as the clinical data is once more allowed to accumulate in the local storage while at the same time being monitored and prioritized according to the above- mentioned classification process so that it can then be decided whether an immediate upload is needed based on factors such as the priority classification, accumulated data volume and so forth as described elsewhere in this document. It will also be understood that in some cases all the accumulated clinical data is uploaded whereas in other cases only some of the clinical data is uploaded, for example only the data items with higher priority levels and optionally also further data to ensure a minimum amount of data is sent in the upload, e.g. for most efficient energy management of the IMD battery.

[0112] DATA COMPRESSION UNIT

[0113] The IMD is configured with a data compression scheme. The clinical data comprises a plurality of parameters, each of which is associated with a parameter value. A temporal compression unit is configured such that messages only transmit clinical data items which have changed. To implement this, the clinical data for transmission is pre-processed according to a data compression protocol. A log is maintained of the parameters and their values as transmitted in immediately previously transmitted messages. The pre-processing then selects for transmission only parameters whose values have changed according to the log. From time to time, e.g. periodically, a message is sent containing a complete data set, including parameters whose values have not changed, thereby to resynchronize or initialize the data stream.

[0114] An implementation of the present disclosure may take the form of or incorporate a computer program product embodied in one or more computer-readable storage medium(s) (e.g., memory) having computer-readable program code embodied or stored thereon. Program code embodied on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, radio frequency (RF), etc., or any suitable combination thereof.

[0115] It is to be understood that although this disclosure includes a detailed description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computer system. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computer system now known or later developed.

[0116] Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0117] Characteristics are as follows:

[0118] On-demand self-service: a cloud consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with the service’s provider.

[0119] Broad network access: capabilities are available over a network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., smartphones, tablets, laptops, workstations).

[0120] Resource pooling: the provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. There is a sense of location independence in that the consumer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).

[0121] Rapid elasticity: capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.

[0122] Measured service: cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

[0123] Service Models are as follows:

[0124] Software as a Service (SaaS): the capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based e-mail). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0125] Platform as a Service (PaaS): the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

[0126] Deployment Models are as follows:

[0127] Private cloud: the cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on-premises or off-premises.

[0128] Community cloud: the cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on-premises or off-premises.

[0129] Public cloud: the cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.

[0130] Hybrid cloud: the cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds).

[0131] A cloud computer system is service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0132] Reference Numerals

[0133] I Medical Device / Implant Communication System (MDCS / MICS)

[0134] 10 Implantable Medical Device (IMD)

[0135] I I IMD stimulator

[0136] 12 IMD wireless personal area network (WPAN) transceiver (e.g. BLE)

[0137] 13 IMD sensor

[0138] 14 IMD rechargeable battery

[0139] 15 IMD low-power wide-area network (LPWAN) transceiver

[0140] 17 IMD memory

[0141] 18 IMD processor

[0142] 20 charger for IMD

[0143] 22 charger wireless personal area network (WPAN) transceiver (e.g. BLE)

[0144] 24 charger energy source (battery)

[0145] 25 charger low-power wide-area network (LPWAN) transceiver

[0146] 26 charger wireless local area network (WLAN) transceiver

[0147] 27 charger memory

[0148] 28 charger processor

[0149] 29 charger external power jack

[0150] 30 user equipment (UE) / smartphone / patient remote controller (patient remote)

[0151] 32 smartphone wireless personal area network (WPAN) transceiver (e.g. BLE)

[0152] 34 smartphone low-power wide-area network (LPWAN) transceiver

[0153] 35 smartphone cellular (e.g. 4G / LTE / 5G) transceiver

[0154] 36 smartphone wireless local area network (WLAN) transceiver

[0155] 38 router

[0156] 40 telephone line / telephone network

[0157] 42 LPWAN-capable cellular network base station (cellular tower)

[0158] 50 distributed network (cloud services)

[0159] 60 data center acting as repository for storage of clinical data (backend)

[0160] 70 workstation(s) for health care staff to access data center (portal)

[0161] 80 IMD transmission path allocation unit

[0162] 82 IMD data prioritization unit

[0163] 84 IMD data compression unit

Claims

Claims1. An implantable medical device for implanting into a patient, comprising: an electrical energy source; therapeutic components for at least one of patient monitoring and treatment that are powered by the electrical energy source and configured to collect clinical data including at least one of patient data relating to a patient's health and device data related to status and operation of the implantable medical device; a first wireless transceiver configured to operate according to a wireless personal area network, WPAN, communications protocol to transmit the clinical data using a first data communication path; a second wireless transceiver configured to operate according to a low-power wide-area network, LPWAN, communications protocol to transmit the clinical data using a second data communication path; and a memory and a microprocessor, wherein the memory stores clinical data prior to its transmission and further stores a computer program which when executed on the microprocessor controls activation of each of the first and second wireless transceivers and makes decisions on when and with which of the first and second wireless transceivers clinical data stored in the memory is transmitted.

2. The device of claim 1, wherein the therapeutic components comprise at least one patient treatment device.

3. The device of claim 2, wherein the at least one patient treatment device is selected from the group: a pulse generator for an implantable pulse generator; a neurostimulator for a spinal cord stimulation; pulse delivering electrodes for a cardiac pacemaker; pulse delivering electrodes for a cardioverter defibrillator; magnetic field generator for an implantable neuromodulation device; and electrical current generator for an implantable neuromodulation device.

4. The device of claim 1, 2 or 3, wherein the therapeutic components comprise at least one patient monitoring device.

5. The device of claim 4, wherein the at least one patient monitoring device is selected from the group: a temperature sensor; a pressure sensor; a pressure and volume sensor; an activity sensor; an accelerometer; a microphone; a light sensor; electrodes for an implantable loop recorder; an evoked compound action potential (ECAP) sensor; electrodes for a glucose sensor; and a blood pressure sensor.

6. The device of any preceding claim, wherein the WPAN communications protocol supported by the first wireless transceiver is selected from the group: Bluetooth Low Energy (BLE); Medical Implant Communication System (MICS); and Medical Device Radiocommunications Service (MedRadio); Near-Field Communication (NFC); and resonant or non-resonant inductive communication.

7. The device of any preceding claim, wherein the LPWAN communications protocol supported by the second wireless transceiver is selected from the group: LTE-M; NB-IOT; IEEE 802.1 lah, IEEE 802.15.4a, ISO / IEC 18000-7, and EN 13757-4.

8. A medical device communication system utilizing mobile telecommunications network infrastructure that supports a low-power wide-area network, LPWAN, communications protocol, the system comprising: an implantable medical device having first and second wireless transceivers, wherein the first wireless transceiver is configured to operate according to a wireless personal area network, WPAN, communications protocol and wherein the second wireless transceiver is configured to operate according to said LPWAN communications protocol; and a data repository hosting clinical data uploaded from the implantable medical device and that has at least one data communication path to the mobile telecommunications network infrastructure, the system providing first and second data communication paths between the implantable medical device and the data repository, wherein the first data communication path uses saidLPWAN communications protocol to transmit between the implantable medical device and the mobile telecommunications network infrastructure, and the second data communication path uses said WPAN communications protocol to transmit between the implantable medical device and a further device, said further device acting as a relay device for onward transmission to the data repository using a further communications protocol.

9. The system of claim 8, wherein the relay device is one of: a charger for the implantable medical device; a user equipment, UE, capable of using the mobile telecommunications network infrastructure; and a wireless local area network, WLAN, enabled device capable of communicating with a router that is in data communicable connection with the data repository.

10. The system of claim 8 or 9, wherein the further communications protocol is a protocol according to one of: a low-power wide-area network, LPWAN; a wireless local area network, WLAN; 4G; LTE and 5G.

11. A charging device for wirelessly charging a rechargeable electrical energy source contained in an implantable medical device, the charger comprising: an electrical energy source to provide energy for charging the rechargeable electrical energy source of an implantable medical device; an induction coil for transferring energy to a matching induction coil of an implantable medical device; a first wireless transceiver configured to operate according to a wireless personal area network, WPAN, communications protocol; a second wireless transceiver configured to operate according to a low-power wide-area network, LPWAN, communications protocol; and a memory and a microprocessor, wherein the memory stores clinical data received by the first wireless transceiver using said WPAN communications protocol prior to its transmission by the second wireless transceiver using said LPWAN communications protocol, and further stores a computer program which when executed on the microprocessor controls activation of each of the first and second wireless transceivers and makes decisions on when the second wireless transceiver transmits the clinical data stored in the memory.

12. The device of claim 11, further comprising: a third wireless transceiver configured to operate according to a wireless local area network, WLAN, communications protocol, andwherein the computer program also controls activation of the third wireless transceiver and makes decisions on when and with which of the second and third wireless transceivers the clinical data stored in the memory is transmitted.

13. The device of claim 11 or 12, wherein the computer program is configured to control data communication between the charging device and an implantable medical device via the first wireless transceiver using said WPAN communications protocol, and further data communication between the charging device and mobile telecommunications network infrastructure using said LPWAN communications protocol.

Images