Communication system and method for implantable medical devices

Abstract

The present invention is directed to a communication system for wireless message transfer between an implantable medical device IMD, 40 and an external device 60. A communication system for effectively coordinating / managing messages in a resource limited communication scheme is disclosed, where the IMD 40 is configured to monitor a health status of a patient and / or deliver a therapeutic signal to the patient, the IMD 40 comprises a processor and a transceiver module configured to bidirectionally exchange messages with the external device 60, the processor adopting at least a predefined active state and a predefined processing state, the processor of the IMD 40 configured to generate response messages 201, 202, 203, 204 for sending these response messages 201, 202, 203, 204 from the transceiver module to the external device 60. The present invention is further directed to a corresponding communication method, a computer program product and a computer readable data carrier.

Description

Technical Field

[0001] The present invention relates to a communication system for data transfer between an implantable medical device (IMD) and an external device, wherein the IMD is configured to monitor a patient's health status and / or to deliver a treatment signal to the patient. The external device is at least partially located outside the body. The present invention further relates to a method for corresponding data transfer, a corresponding computer program, and a corresponding computer-readable data carrier. The computer program product may be, for example, a software routine associated with hardware support means within the IMD and / or the external device.

Background Art

[0002] Active and passive implantable medical devices (IMDs), such as pacemakers (with leads), implantable cardiac monitors (ICMs), implantable leadless pacers (ILPs), implantable leadless pressure sensors (ILPSs), implantable cardiac defibrillators (ICDs), or subcutaneous implantable cardiac defibrillators (i.e., S-ICDs), include sensors that collect physiological signals to monitor a patient's health status and transmit them as data to a physician's device or a remote server using an external device. Data collected from these various or any such sensors may include, but are not limited to, ECG, impedance, activity, posture, heart sounds, pressure, respiration, and other data. An active IMD (e.g., a pacemaker, ILP, ICD, or S-ICD) may provide a therapeutic output, such as electrical stimulation within the cardiac chambers (e.g., the atrium or ventricle), to the patient.

[0003] Typically, such an IMD consists of a processor for data processing and a transceiver module configured to exchange messages bidirectionally with an external device, for example, if implanted in the patient's body. An external device, which may use its own transceiver, is also configured to exchange messages bidirectionally with the IMD's transceiver module. The external device may be a separate device connected to a computer (sometimes called a programmer) or a module integrated within a remote device such as a computer. The external device creates messages in the form of requests and sends them to the IMD's transceiver, for example, to receive data from the IMD regarding the patient's health status or the IMD's status, or to program it (for the purpose of configuring the IMD to apply appropriate treatment to the patient).

[0004] Processing data, applying algorithms to data, and having the IMD manage communication with external devices presents difficulties and drawbacks due to the low power requirements and limited computing resources within the IMD. Most of the management of such routines cannot be performed within the IMD without risking adverse effects on device lifespan. To extend the IMD's lifespan (by achieving the best access to meaningful clinical benefits), there is a need to accommodate more power / energy within the IMD. Unfortunately, if such power / energy cannot be incorporated into the IMD through high-power / energy-density battery chemistry, then the use of larger batteries may be required to extend lifespan. Given the small size of modern IMDs, larger batteries risk increasing the physical size of the IMD, which is also clinically undesirable, as is the potential for reduced lifespan (especially in the case of leadless pacemaker IMDs, which are devices that reside within cardiac volume). Therefore, the communication infrastructure and message processing required within the IMD system must be optimized for low-energy operation.

[0005] Such optimized communication and messaging also avoids overloading the communication infrastructure (e.g., information routing to buses), 1.) A system command initiation source, such as an external device, is notified by a downstream handler such as IMD about the processing of its generated (instate) request. 2.) In a manner that avoids any possible problematic handling of IMD receiving repeated requests from an external device (i.e., if the external device is unaware that it has requested IMD and therefore "retries"), 3.) In a manner that provides a means for managing navigation through data memory within the IMD without incurring undesirable overhead, The command / response dynamics need to be properly constructed.

[0006] Communication protocols / architectures are known to have some functionality for polling the status of data processing units within a system. Such support often embodies "ping" requests from one or more in-system command initiation sources that can report on the progress of a previously issued request in service status (e.g., the task completion bar often seen in the installation process of Windows® applications). Such situations can take various forms with varying degrees of complexity, but often correspond to a specific command or series of commands asking the downstream handler, "Are you finished?" However, such communication procedures can cause excessive congestion on the data message link between the IMD and external devices, making it difficult for the system to efficiently handle requests and data transfers in a way that does not prolong them over a period of time.

[0007] Furthermore, in communication systems, it is common for downstream handlers to have architectural features that prevent the system from being bombarded with repeated requests from upstream command initiation sources that generate calls to actions. Such mechanisms often materialize within the downstream handler a buffer or stack that can hold such requests. In the best example, such a system can build up a list of requested commands in a specific order, and when a data handler completes an older request, the local buffer is "popped" to allow further actions to proceed. Moreover, with good judgment, the ability to load buffers can also filter out command repetitions and load only buffers / stacks with new items. This technique may add complexity to the interpretation, handling, and management of units within the system (i.e., downstream handlers) and may not be well-suited to the computational and storage resources available internally. [Overview of the project] [Problems that the invention aims to solve]

[0008] Therefore, it is desirable to provide a communication system and method that effectively coordinates and manages messages in a communication scheme with limited resources. [Means for solving the problem]

[0009] The above problems are solved by a communication system for data transfer between an IMD and an external device having the features of claim 1 and / or claim 5, a corresponding communication method having the features of claim 9 and / or claim 11, a computer program product having the features of claim 14, and a computer-readable data carrier having the features of claim 15.

[0010] Specifically, the problem concerns a communication system for wireless data transfer, particularly between an implantable medical device (IMD) and an external device, wherein the IMD is configured to monitor a patient's health status and / or to deliver therapeutic signals to the patient, and the IMD comprises a processor and a transceiver module configured to exchange messages bidirectionally with an external device (for example, if the IMD is implanted in the patient's body), the processor employing at least a predefined active state and a predefined processing state, and the IMD's processor is configured to create these response messages to send response messages from the IMD's transceiver module to the external device, each response message comprising a processor state field or section at a predefined location within the response message. As long as the processor is currently (i.e., at this moment) in a predefined processing state, a predefined first value is assigned to the processor state section. If the processor is not currently (i.e., at this moment) in a processing state, a predefined second value, different from the first value, is assigned to the processor state section by the communication system.

[0011] An IMD is an implantable medical device configured to monitor a patient's health status and / or to deliver therapeutic signals to a patient, as defined above.

[0012] Since the processor state field can be longer than 1 bit, the value can also be defined as follows: As long as the processor is currently in a predefined processing state, a predefined first set of values ​​is assigned to the processor state field. If the processor is not currently in a processing state, a predefined second value, different from the first value, is assigned to the processor state field.

[0013] Alternatively or additionally, different states may be defined that reflect different levels of sensitivity to specific types or sets of request messages, i.e., expose the current processor / task priority to external devices and communicate what types of requests the IMD will accept and interrupt ongoing processor activity.

[0014] An IMD comprises a processor for data processing and a transceiver module (e.g., a coil connected to an antenna or with appropriate communication management functions) for receiving messages (i.e., communication signals) from an external device and sending messages to the external device. Messages sent by the IMD's transceiver module are hereafter referred to as "response messages." A message is a bit sequence embedded in a syntactic-semantic system defined as part of a communication protocol, represented in clearly defined algorithms and data structures, and interpreted by them. Messages received by the IMD's transceiver module, also called request messages, are relayed to the processor for data processing. Similarly, the processor constructs the content of signals / messages, which are then relayed to the transceiver module to be sent to an external device as response messages.

[0015] The IMD may include further modules such as memory for storing data, a power supply including battery support, at least one sensor for acquiring physiological signals from the patient, and / or a signal generator for generating and administering, for example, electrical or electromagnetic therapeutic signals. The transceiver module, memory, power supply, at least one sensor, and / or signal generator may be electrically connected to the processor.

[0016] IMD memory may include any volatile, non-volatile, magnetic, or electrical medium, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), electrically-erasable programmable ROM (EEPROM), flash memory, or any other memory device.

[0017] The external device may be located at least partially outside the body and may be a separate module wirelessly or wired to a computer having a processor (e.g., a physician's device, a remote server, a programmer). Alternatively, the external device may be an integrated unit of such a computer, for example, forming an integrated unit for a programmer. For bidirectional communication, the external device may include a transceiver for messages (signals), such as a communication module or a coil connected to an antenna. The communication module may include a processor, or interface with one, especially if it is a separate module from the computer.

[0018] Wireless communication between an external device and the IMD includes (wireless) aerial communication. Communication may use inductive magnetic means, acoustic methods (e.g., ultrasound), and / or acoustic waves, light waves and / or electromagnetic waves, such as Bluetooth, WLAN, ZigBee, NFC, Wibree or WiMAX in the radio frequency domain, or IrDA or free-space optical communication (FSO) in the infrared or optical frequency domain.

[0019] With regard to the present invention, each processor is considered a functional unit of an IMD, external device, and / or computer, respectively, which interprets and executes instructions, including an instruction control unit and arithmetic and logic units. A (remote) computer or external device is a functional unit that can perform substantial calculations, including numerous arithmetic and logical operations, without human intervention, such as a personal mobile device (PMD), desktop computer, server computer, cluster / warehouse-scale computer, or embedded system.

[0020] According to the present invention, the IMD processor employs at least an active state and / or a processing state. In the processing state, the processor needs to collect, gather, or transmit internally stored data (in one or more responses), or take control or actions to collect measurements or perform routines (e.g., for therapeutic applications) for a period that delays the IMD's immediate response capability. Thus, in the processing state, the processor operates to respond to external requests and / or process data according to internal routines / algorithms. Hereinafter, the processing state will also be referred to as the “busy state”. When the IMD’s communication support is not in the “busy state” but is engaged in a communication link with an external device, this is simply the “active state” (the transceiver is on and the IMD is ready for further interaction with the external device). In the active state, the processor is not “busy” and can receive requests from external devices that may next be addressed. The conditions under which the processor changes from an "active state" (i.e., initial standby state) to a "processing state" may be predefined and stored, for example, in the IMD's data memory, or such a transition may simply be generated by handling any particular request from an external device and the resulting urgent duration required for such handling. After completing each task that kept the IMD in a "busy state," the processor switches back to an "active state."

[0021] In accordance with the present invention, each response message sent by the IMD (i.e., its transceiver module) to notify an external device of the state of the processor includes a processor state field in a predefined location within the response message. As long as the processor is currently in a predefined processing state, a predefined first value is assigned to the processor state field. If the processor is not currently in a processing state, a predefined second value, different from the first value, is assigned to the processor state field.

[0022] The location (information) may be a single bit within the wrapper (i.e., the non-payload portion). This bit is a location understood by both the sender and receiver in the communication system. As long as this bit is a location known / understood by both the sender and receiver, it doesn't literally matter where it lies within the message. It could be the first bit or some other bit. It's unlikely to be the last bit because signature confirmation is often at the end of the message, but there's no rule that enforces such a design.

[0023] All messages transmitted by the IMD involve the IMD's processor assigning at least a first value or a second value, respectively, to the processor state field within the transmitted message, as defined above. Thus, the transmission of additional values within this field is not precluded, depending on the length of the field. In one embodiment, the length of the processor state field is from 1 bit to 4 bits. If the processor state field is 1 bit ("busy bit"), for example, the first value may be value 1 and the second value may be value 0. This very simplified approach means that the IMD reports (through the processor state field) whether the processor has completed the processing task from the last received request message using a yes / no, busy / not busy, 1 / 0 only style toggle.

[0024] The command source (external device) was described above with respect to the means for determining the readiness of the command handler (IMD). This is also used by the command source (external device) to limit the transmission of additional commands until the command handler (IMD) is ready to receive commands. Also, the command source (external device) may send additional non-command messages that poll for updates to this status.

[0025] In one embodiment, an external device that receives a response message from the IMD containing the first value assigned to the processor state field is configured to stop sending all new request messages to the IMD's transceiver module until the external device receives a message containing the second value assigned to the processor state field. Such request messages that require waiting are pre-defined and may, for example, be stored in the data memory of the external device or may simply arise from a dominant situation within the IMD that extends the processing time when dealing with any received request / command, as described above.

[0026] The leadless communication scheme defined above is based on the concept of single-threaded command processing. In this regard, new commands cannot be processed until the processing and handling of the current command is completed by the IMD. Cases in which such support has proven particularly appropriate include device follow-up querying, programming, and test routines. According to the present invention, the IMD provides a means for reporting its predefined processing status (i.e., "in progress" or "busy" status) to the user-side infrastructure (i.e., external devices) as a means of avoiding facing congestion of requests that would break the single-threaded architecture. According to the present invention, the processor status section is incorporated into the message relayed from the IMD and used as part of the leadless system packet design to enable IMD status communication to support the coordination of new requests from resources on the external device side before handling related to previously received requests is completed.

[0027] The communication system according to the present invention provides active feedback within a leadless communication infrastructure regarding the processing state of the IMD's processor, preventing the system with limited resources from being overwhelmed by a flood of request messages that could make it difficult to optimize high-level functional support. The communication system provides a bandwidth-saving handshake mechanism for data relay between the sender (i.e., the external device) and the receiver (i.e., the IMD), as command data can be managed without unnecessarily interfering with support for passing real-time streaming data from the IMD to an external device.

[0028] In one embodiment, request messages (messages sent from an external device to the IMD) include proximity request messages (i.e., normal requests from an external device sent at specified time intervals) nominally intended to maintain a data link between the IMD and the external device (also called proximity command relay), monitoring request messages (i.e., requests to determine specific actual physiological signals stored in or collectible by the IMD), data request messages (i.e., requests to deliver specific data stored in the IMD or parameter states within the IMD), program write messages (i.e., instructions to set specific treatment parameters, etc.), status request messages (i.e., requests to provide the status of status parameters, such as the state of a battery charge), or execution request messages (i.e., requests to execute a specified routine or program sequence).

[0029] In one embodiment, an external device receiving a response message from the IMD containing a first value assigned to the processor state field is configured to wait for the latest response message to contain a second value assigned to the processor state field before sending a new request message of a specific type to the IMD's transceiver module.

[0030] In one embodiment, the response message (a message sent by the IMD to an external device) is either a proximity response message (i.e., a response to a proximity request message) or a reporting response message (i.e., a response to a monitoring, data request, program, or execution request message), the latter of which is sent after the IMD has completed the necessary actions. If the IMD's consequent task is solely to notify the external device that the IMD has received the corresponding request (i.e., an acknowledgment), then it is a nominal instantaneous response.

[0031] In one embodiment, the response message may be a proximity response message, a status reporting response message, a data payload / relay response message, a response message carrying measurement data acquired through a trigger routine generated by an external device, or an acknowledgment response message.

[0032] As an addition or alternative, an external device may be configured to create request messages to send to the transceiver module of the IMD, each request message including a sequence field in a predefined location within the request message, the sequence field being toggled between at least a first value and a second value associated with the sequence section, and if the external device has received a valid response from the IMD to a first request message sent immediately before it containing the first value, the second request message will include the toggled second value, or vice versa (i.e., if the external device has received a valid response from the IMD to a first request message sent immediately before it containing the second value, the second request message will include the toggled first value).

[0033] Therefore, the above problem also relates in particular to a communication system for wireless data transfer between an implantable medical device (IMD) and an external device, wherein the IMD is configured to monitor the patient's health status and / or to deliver therapeutic signals to the patient, and the IMD comprises a processor and a transceiver module configured to exchange messages bidirectionally with an external device (for example, if the IMD is implanted in the patient's body), the processor employing at least a predefined active state and a predefined processing state, and the IMD's processor is configured to create these response messages in order to send response messages from the IMD's transceiver module to the external device, and the external device sends request messages These messages may be configured to be sent to the transceiver module of the IMD, and each request message may include a sequence field in a predefined location within the request message, the sequence field is toggled between at least a first value and a second value associated with the sequence section, and the communication system may resolve such messages, where if the external device receives a valid response from the IMD to a first request message sent immediately before which the first value is included, the second request message includes the toggled second value, or vice versa (i.e., if the external device receives a valid response from the IMD to a first request message sent immediately before which the second value is included, the second request message includes the toggled first value).

[0034] In one embodiment, an external device is configured to generate request messages and transmit them to the transceiver module of the IMD, each request message including a sequence field at a predefined location within the request message, the sequence field being toggled between at least a first value and a second value associated with the sequence section, and if the external device receives a valid response from the IMD to a first request message sent immediately before that included the first value, the second request message includes the toggled second value, or vice versa (i.e., if the external device receives a valid response from the IMD to a first request message sent immediately before that included the second value, the second request message includes the toggled first value). In one embodiment, the length of the sequence field is 1 to 4 bits. If the sequence field is 1 bit ("sequence bit"), for example, the first value is 1 and the second value is 0.

[0035] In one embodiment, the request message is a proximity request message, a status request message, a data request message, a monitoring request message, an execution / measurement request message, a program write message, a program request message, a status request message, an execution request message, or a data request message.

[0036] In one embodiment, the communication system is configured such that, when the IMD receives a request message from an external device containing a value assigned to the sequence field equal to the value assigned to the sequence field of the request message received immediately before, the IMD sends a repeat of that response message, also called a repeat response message, to the external device. Subject to receiving a suitable message response or response message from the IMD, the external device assigns a different value to the sequence field of the next message than the value of the last sent request message. However, if the external device does not receive a suitable response message after a predetermined duration or other conditions met, the external device repeats its last sent message and leaves the sequence field in the repeated message unchanged (i.e., the same as the last request command state). The sequence field value of the last request message sent from the external device to the IMD may be stored in memory in the IMD and / or the external device as a means of managing whether a new command or a retry of unsuccessful messaging is being performed.

[0037] It was recognized that not all request messages reach the IMD, and not all response messages reach the external device, because communication between the IMD and external devices uses a channel where the anatomical structure of the intervening patient provides substantial physical isolation between the transmitting and receiving modules in the system. Therefore, if the external device cannot determine whether the sent request message has been processed by the IMD, it is important that the system has means to ensure that the IMD recognizes that the external device is repeating the request message and that the handling of such incoming messaging occurs in a non-complex manner. Sequence field mechanisms may also be used to access the efficiency of the communication data link when it is necessary to query large memory blocks within the IMD. Rather than creating a command request that includes a specific IMD memory address target, the command and system design can be constructed to simply request that a “query” be carried out. The system (i.e., the IMD and the external device) is designed so that key information that can be queried for a given IMD type is always present in a given portion of the IMD memory. This information, determined by the design, eliminates the need to include addressing in the messaging sent between the external device and the IMD. The system knows (in advance) how much memory needs to be read as part of such a sequence, and then issues a "query" style command to the IMD. Such a "query" style command includes a sequence field that is set to a new state when it is first sent. If the IMD returns the appropriate first portion of the data requested by this process to the external device, the external device can change the sequence field value and reissue the "query" style command. The IMD's recognition of the changed sequence field notifies the external device that it has received the first portion of the data requested by the "query" style command, and in turn responds by sending the "next" portion of the larger block of data within the IMD that the external device intends to read.This process continues until the entire block of data is successfully relayed to the external device (retries during such a process are enabled through the sequential sending of query-style commands, keeping the sequence field in a state matching the last sent query-style command). As described above, one or more bits in the sent request message can be used as sequence fields to support this process. The state of these sequence fields is updated each time the external device infrastructure receives a valid response from the IMD. Assuming all commands and responses traverse the communication channel without corruption, packet loss, or interference, each command relayed from the external device will show a value assigned to a sequence field that moves back and forth between at least two available states. If the request message was not received by the IMD (and therefore unable to respond), or if the IMD responded but that response did not reach the external device infrastructure, the value assigned to the sequence field remains in a steady state. Subject to one or more timeout mechanisms (e.g., waiting for a sufficient amount of time for the IMD to process and respond to the command), the external device infrastructure can know that a command has not been received or processed and can resend the unprocessed / unanswered command with an unchanged sequence field. By receiving a command with an unchanged sequence field, the IMD can know that the command is a retry, which allows the IMD to repeat the command or simply resend the same response. In this way, the technique makes it easier to address the need to segment / query large data blocks.

[0038] This method incorporates a dedicated mechanism within the leadless communication infrastructure to ensure that the IMD's handling of incoming request messages is always notified regarding the "new" vs. "retry" status of individual requests, helping to avoid potentially problematic situations that may arise from resuming command execution / processing. Furthermore, the use / implementation of sequence fields provides a bandwidth-saving transport mechanism for data segmentation (i.e., rather than sending memory or location pointer information from the external device infrastructure when long writes or reads are required). The message itself can be shortened simply by notifying the implanted device at the appropriate time to "hop" to the next segment of data in the IMD. Moreover, the functionality described above can be implemented in a low-overhead manner by embedding the functionality within the baseline message structure, avoiding the need for a message buffering scheme within the IMD.

[0039] The messaging scheme described above for managing interaction with large blocks of memory within the IMD certainly involves command and response messages containing the necessary processor state and sequence fields associated with the communication protocol described, but these are specifically designed to involve IMD responses that lack the complete payload targeted by the command interaction, due to their interaction with a predefined maximum acceptable duration between message transmissions. In such cases, the complete target payload is divided across several responses from the IMD, each sent separately. The fields within each of these partially segmented responses then provide a bit sequence defining the length (e.g., 1 to 4 bits) of the payload each carries.

[0040] Similarly, the above problem is solved by a communication method for data transfer between an implantable medical device (IMD) and an external device. This method has the advantages described above with respect to the system. Specifically, the IMD is configured to monitor the patient's health status and / or to deliver therapeutic signals to the patient, and the IMD comprises a processor and a transceiver module configured to exchange messages bidirectionally with an external device, the processor adopting at least a predefined active state and a predefined processing state, the processor of the IMD creating response messages and sending these response messages from its transceiver module to the external device, each response message including a processor state field at a predefined location within the response message. As long as the processor is currently in a predefined processing state, a predefined first value is assigned to the processor state field. If the processor is not currently in a processing state, a predefined second value, different from the first value, is assigned to the processor state field.

[0041] Therefore, in one embodiment, an external device receiving a response message from the IMD containing a first value assigned to the processor state field waits to send all new request messages to the IMD's transceiver module (or waits to send one new request message) until the latest response message contains a second value assigned to the processor state field.

[0042] As an addition or alternative, an external device may create request messages and send them to the IMD's transceiver module, each request message including a sequence field in a predefined location within the request message, the sequence field being toggled between at least a first value and a second value associated with the sequence field, and if the external device has received a valid response from the IMD to a first request message sent immediately before, the second request message includes the toggled second value, or vice versa.

[0043] Therefore, the above problem can also be solved by a communication method for data transfer between an implantable medical device (IMD) and an external device, wherein the IMD is configured to monitor the patient's health status and / or to deliver therapeutic signals to the patient, and the IMD comprises a processor and a transceiver module configured to exchange messages bidirectionally with the external device, the processor employing at least a predefined active state and a predefined processing state, the external device creating these messages to send request messages to the transceiver module of the IMD, each request message including a sequence field at a predefined location within the request message, the sequence field being toggled between at least a first value and a second value associated with the sequence field, and if the external device has received a valid response from the IMD to a first request message sent immediately before, a second request message including the toggled second value, or vice versa.

[0044] Alternatively or additionally, an external device may create request messages to send to the IMD's transceiver module, each request message containing a sequence field at a predefined location within the request message, the sequence field being toggled between at least a first value and a second value associated with the sequence field, and if the external device has received a valid response from the IMD to the first request message sent immediately before, the second request message may contain the toggled second value, or vice versa.

[0045] Furthermore, in one embodiment, if the IMD receives a request message from an external device that contains a value assigned to a sequence field equal to the value assigned to the sequence field of the request message received immediately before, the IMD is configured to send a repeat of that response message to the external device.

[0046] At least one of the above methods may be implemented, for example, as a routine or algorithm (executed in an external device and / or IMD, particularly utilizing each of their respective processors as needed), the routine or algorithm being either a combination of instructions and data definitions specified above and below that enables the system to perform computational or control operations, or a syntactic unit consisting of declarations and statements or instructions necessary to solve the functions, tasks, or issues specified above and below, in accordance with the rules of a particular programming language.

[0047] Also disclosed is a computer program product comprising instructions that, when executed by a processor, cause the processor to perform steps in the manner defined above. Accordingly, a computer-readable data carrier for storing such a computer program product is described.

[0048] The present invention will now be described in more detail with reference to the attached schematic drawings. [Brief explanation of the drawing]

[0049] [Figure 1] This figure shows one embodiment of the communication system of the present invention, comprising an implantable leadless pacemaker (ILP) and an external device, with the ILP shown in a cross-section of the patient's heart. [Figure 2] This is a flowchart of a first embodiment of the communication method of the present invention. [Modes for carrying out the invention]

[0050] Figure 1 shows an exemplary communication system 10 and the heart 20 of a patient 30 (having a right ventricle 21 and a right atrium 22). The system 10 comprises a leadless ventricular pacemaker device 40 (hereinafter "ILP40") as an example of an IMD and an external device 60. The ILP40 may be implanted in the right ventricle 21 of the heart 20 and configured to pace this ventricle, detect intrinsic ventricular depolarization and impedance, and suppress ventricular pacing in response to detected ventricular depolarization. The ILP40 may further include an accelerometer sensor for measuring the posture of the patient 30 (for example, by determining the acceleration force due to gravity). A programmer (not shown) may be used to program the ILP40 using the external device 60. The external device 60 is located outside the body and is adapted to communicate bidirectionally with the ILP40.

[0051] The ILP40 may comprise modules such as a processor, data memory, a signal generator unit for providing treatment signals (e.g., pacing signals), a measurement unit including an ECG measurement unit, a DC impedance sensor and an accelerometer sensor, a transceiver for sending and receiving messages with an external device 60, and a power supply, each of which is electrically connected in some way within the IMD. The power supply may comprise a battery (e.g., a rechargeable or non-rechargeable battery). The data memory module may include any of the memory types described above. The processor of the ILP40 may employ at least the active state and the processing state described above.

[0052] The external device 60 comprises a processor 61 and a transceiver 62 for exchanging messages with the ILP 40, which are electrically connected to each other. Furthermore, the external device 60 may exchange data with other external devices and / or remote servers (not shown). The external device 60 may also be a programmer. Bidirectional message exchange with the ILP 40 is symbolized by a double-headed arrow 50. Leadless communication between the external device 60 and the ILP 40 may be inductive magnetic communication, conducted communication, and / or acoustic communication.

[0053] The operation of one embodiment of the communication system and method will be described below using Figure 2. The figure shows an illustrative sequence of events and interactions, in particular, the case in which a programmer-side infrastructure, comprising an external device 60, requests that the pace amplitude be measured by the ILP 40. The request message sent by the external device 60 is symbolized in a black envelope, while the white envelope represents the response message from the ILP 40. From each rectangle on the left side of each envelope, it is possible to derive the contents of some key information or the addressing used by the associated message. Specifically, the request message from the external device 60 includes a sequence field ("Sequence" in Figure 2) with a length of 1 bit, as described above. Thus, the values ​​0 and 1 are associated with the sequence field, and these are shown in Figure 2 as "Sequence=0" or "Sequence=1". The response message from the ILP 40 may also include a processor state field ("Busy" in Figure 2) with a length of 1 bit, as described above. Therefore, values ​​0 and 1 may be associated with the processor state field, which are shown as "Busy=0" or "Busy=1" in Figure 2.

[0054] In the sequence of events shown in Figure 2, a V-pace amplitude measurement request message 101 is sent from the external device 60 to the ILP 40, and the ILP 40's processor is in an active state at the start. The sequence field in the message starts with an initial state of "0" ("sequence=0", which may have been "1" at another point). Upon receiving the request message to perform a V-pace amplitude measurement, the ILP 40 responds by sending a response message 201 "ACK" and acknowledging it by changing the value of the processor state field to "1" ("busy=1"), indicating that the ILP's state has been changed to a processing state. The processor waits for an opportunity to collect the measurement, and during this time, the external device 60 should refrain from sending request messages for additional support until the IMD has completed the requested task. While the measurement is being performed and waiting for the value to be available for reporting, the external device infrastructure sends a series of proximity request messages 102, which serve only to maintain the data link between ILP40 and the external device 60 and relay the streaming real-time IEGM to the external device while waiting for ILP40 to complete the requested measurement (in the illustrated example, the proximity request message cycle occurs every 200ms). Throughout this process, the external device monitors the value of the processor state field in ILP response messages 202, 203, known as so-called Null responses (often also called acknowledgments). When a V-pace event occurs (see reference no. 300 in Figure 2), ILP40 performs a V-pace measurement. ILP40 then sends a response message 203 with the changed processor state field (changed from "1" to "0") to inform the external device 60 that ILP40 has returned to an active state and is ready to be instructed to report the available measurements. Next, the external device 60 sends a message 103 requesting the measurement result, and the ILP 40 immediately after receiving the request message 103 sends a response message 204 reporting an amplitude of 2.5V (in this particular example).In this response message 204, the processor of ILP40 terminates the request immediately upon receipt by sending the measurement using response message 204, and therefore the processor status field is associated with the value "0".

[0055] An alternative implementation would simply cause the IMD to report an amplitude of 2.5V, which would be done in the next cycle 204 instead of sending a Null response 203. This technique would return the amplitude to the external device without having the IMD first report its availability, and without relying on the external device issuing another data acquisition command. In such a response, the "busy" bit would be set to "0" as it was handled in response 203.

[0056] Regarding the sequence field, Figure 2 shows that the sequence field is toggled with each request message 101, 102, and 103, that is, it toggles from its initial value "0" in the first request message 101 to the second value "1" in the second request message 102, to the first value "0" in the third request message 102, to the second value "1" in the fourth request message 102, and finally to the first value "0" in the last request message 103. This is because the external device 60 receives an appropriate response from ILP40 for the previous request message as part of the data messaging cycle in which each of them is involved. If one of the request messages 101, 102, or 103 does not reach ILP40, there is no response from ILP40, and the value of the sequence field does not change (note that the sequence field does not change in any cycle in which the response from IMD40 does not successfully reach the external device 60). Therefore, after each request message is sent by the external device 60, the ILP will deduce from this request message that the value of the sequence field is the same as the previous request message. The ILP 40 processor then concludes that one provisional request message was not properly received or processed (i.e., one response was missed by the external device), and therefore the ILP 40 will either 1) re-execute the routine requested by the recognized command and respond, or perhaps more optimally, 2) simply resend the response to the external device 60.

Claims

1. A communication system (10) for wireless message transfer between an implantable medical device (IMD, 40) and an external device (60), wherein the IMD (40) is configured to monitor the health status of a patient (30) and / or to deliver therapeutic signals to the patient, and the IMD (40) comprises a processor and a transceiver module configured to exchange messages bidirectionally with the external device (60), wherein the processor has at least a predefined Employing an active state and a predefined processing state, the processor of the IMD (40) is configured to create response messages (201, 202, 203, 204) to send from the transceiver module to the external device (60), and each response message (201, 202, 203, 204) includes a processor state field in a predefined location within the response message (201, 202, 203, 204). As long as the processor is currently in a predefined processing state, a predefined first value is assigned to the processor state field. If the processor is not currently in the processing state, a predefined second value different from the first value is assigned to the processor state field. A communication system (10) in which the external device (60) receives response messages (201, 202, 203, 204) from the IMD (40) that include the predefined first value assigned to the processor state field is configured to wait for all new request messages to be sent to the transceiver module of the IMD (40) until the latest response message (201, 202, 203, 204) includes the predefined second value assigned to the processor state field.

2. The communication system according to claim 1, wherein the length of the processor state field is 1 bit to 4 bits.

3. The communication system according to claim 1 or 2, wherein the response messages (201, 202, 203, 204) are proximity response messages, status reporting response messages, data payload / relay response messages, response messages carrying measurement data acquired through a trigger routine generated by the external device, or acknowledgment response messages.

4. A communication system (10) for wireless message transfer between an implantable medical device (IMD, 40) and an external device (60), wherein the IMD (40) is configured to monitor the health status of a patient (30) and / or to deliver therapeutic signals to the patient, and the IMD (40) comprises a processor and a transceiver module configured to exchange messages bidirectionally with the external device (60), wherein the processor employs at least a predefined active state and a predefined processing state, and the external device (60) sends request messages (101, 102, 103) to the IMD (40) via the transceiver A communication system (10) configured to create the messages to be sent to an interceptor module, wherein each request message (101, 102, 103) includes a sequence field in a predefined location within the request message (101, 102, 103), the sequence field is toggled between at least a first value and a second value associated with the sequence field, and if the external device (60) receives a valid response from the IMD (40) to a first request message sent immediately before which the first value is included, the second request message (101, 102, 103) includes the toggled second value, or vice versa.

5. The communication system according to claim 4, wherein the length of the sequence field is 1 bit to 4 bits.

6. The communication system according to claim 4 or 5, wherein the request messages (101, 102, 103) are proximity request messages, status request messages, data request messages, monitoring request messages, execution / measurement request messages, program write messages, program request messages, status request messages, execution request messages, or data request messages.

7. The communication system according to claim 4 or 5, wherein when the IMD receives a request message (101, 102, 103) from the external device (60) that includes a value assigned to the sequence field equal to the value assigned to the sequence field of the request message (101, 102, 103) that was received immediately before, the IMD (40) is configured to repeatedly send response messages to the external device (60).

8. A communication method for data transfer between an implantable medical device (IMD, 40) and an external device (60), wherein the IMD (40) is configured to monitor the health status of a patient (30) and / or to deliver therapeutic signals to the patient, and the IMD (40) comprises a processor and a transceiver module configured to exchange messages bidirectionally with the external device (60), wherein the processor employs at least a predefined active state and a predefined processing state, and the processor of the IMD (40) is configured to create response messages (201, 202, 203, 204) and send the response messages (201, 202, 203, 204) from the transceiver module to the external device (60), and each response message (201, 202, 203, 204) includes a processor state field in a predefined location within the response message (201, 202, 203, 204). As long as the processor is currently in a predefined processing state, a predefined first value is assigned to the processor state field. If the processor is not currently in the processing state, a predefined second value different from the first value is assigned to the processor state field. A communication method in which the external device (60), which receives response messages (201, 202, 203, 204) from the IMD (40) that include the predefined first value assigned to the processor state field, waits for the latest response message (201, 202, 203, 204) to include the predefined second value assigned to the processor state field before sending all new request messages (101, 102, 103) to the transceiver module of the IMD (40).

9. A communication method for data transfer between an implantable medical device (IMD, 40) and an external device (60), wherein the IMD (40) is configured to monitor the health status of a patient (30) and / or to deliver therapeutic signals to the patient, and the IMD (40) comprises a processor and a transceiver module configured to exchange messages bidirectionally with the external device (60), wherein the processor employs at least a predefined active state and a predefined processing state, and the external device (60) sends request messages (101, 102, 103) to the transceiver module of the IMD (40). A communication method configured to create the messages to be sent, wherein each request message (101, 102, 103) includes a sequence field in a predefined location within the request message (101, 102, 103), the sequence field is toggled between at least a first value and a second value associated with the sequence field, and if the external device (60) receives from the IMD (40) a valid response to a first request message (101, 102, 103) sent immediately before, which includes the first value, then the second request message (101, 102, 103) includes the toggled second value, or vice versa.

10. The communication method according to claim 8 or 9, wherein the response messages (201, 202, 203, 204) are proximity response messages, status report response messages, data payload / relay response messages, response messages carrying measurement data acquired through a trigger routine generated by the external device, or affirmative response messages, and the request messages (101, 102, 103) are proximity request messages, status request messages, data request messages, monitoring request messages, execution / measurement request messages, program write request messages, program request messages, status request messages, execution request messages, or data request messages.

11. The communication method according to claim 8 or 9, wherein when the IMD (40) receives a request message (101, 102, 103) from the external device (60) that includes a value assigned to the sequence field equal to the value assigned to the sequence field of the request message (101, 102, 103) received immediately before, the IMD (40) sends a repeat message to the external device (60).

12. A computer program product that, when executed by a processor, includes instructions causing the processor to perform the steps of the method according to claim 8 or 9.

13. A computer-readable data carrier for storing the computer program product described in claim 12.

Images