IMPLANTABLE MEDICAL DEVICE AND COMMUNICATION METHOD

Abstract

The present invention describes an implantable medical device, IMD, 40, comprising at least one sensor, a processor and a transceiver module, the at least one sensor being configured to monitor at least one predefined body function of a patient, the transceiver module being configured to bidirectionally exchange messages with an external device 60, i.e. to receive a request message from the external device 60 and to send a corresponding response message 401 in response to the request message to the external device 60. To make the most of the limited data communication throughput of the IMD to enable body function data streaming, the processor is configured to receive signals 101, 107 of the at least one predefined body function detected by the at least one sensor. Furthermore, the present invention also describes a communication system, a communication method and a computer program product comprising the IMD, as well as a computer readable data carrier.

Description

[Technical field]

[0001] The present invention is directed to implantable medical devices, in particular to a leadless medical device, such as an ILP, that is part of a communication system comprising an implantable medical device (IMD) and an external device, preferably functioning as an external communication unit. The IMD is configured to monitor a health condition of a patient and may be further configured to deliver a therapy signal to the patient. The IMD comprises at least one sensor configured to monitor at least one predetermined body function of the patient. The body function may also be or may be referred to as a physiological function. The external device is at least partially located outside the body. The present invention is also directed to a corresponding communication system, a communication method, a corresponding computer program product, and a corresponding computer readable data carrier. [Background technology]

[0002] Active 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 subcutaneously implanted cardiac defibrillators (S-ICDs), contain sensors that collect physiological signals to monitor the health of a patient and transmit the physiological signals as data to a physician's device or to a remote server using an external device. Data collected from these various sensors can include, but is not limited to, ECG, intracardiac electrogram (IEGM), such as bi-atrial and bi-ventricular data, impedance, activity, posture, heart sounds, pressure, respiration, and other data. An active IMD, such as a pacemaker, ILP, ICD, ICM, or S-ICD, contains electronics and a power source, and some such devices can provide a therapeutic signal to a patient, such as electrical stimulation within a heart chamber or atrium.

[0003] Typically, such an IMD comprises a processor for data processing and a transceiver module configured for bidirectional message exchange with an external device, for example when implanted in a patient's body. The external device is also configured for bidirectional message exchange with the transceiver module of the IMD. The external device may be a separate device connected to a computer or programmer, or may be a module integrated in a remote device such as a computer or programmer. The external device generates and sends messages to the transceiver module of the IMD, for example in the form of requests to receive data from the IMD regarding the patient's health or the state of the IMD, or requests to program (to configure the IMD to provide an appropriate treatment to the patient).

[0004] Processing data on an IMD, applying algorithms to this data, or communicating with external devices has the drawback that the scope and performance of algorithm processing is limited due to the low power requirements of small IMDs such as the ILP. Such IMDs cannot run high power, high performance communications, data processing, and algorithms at the risk of sacrificing the device's lifespan. To extend the IMD's lifespan and obtain longer clinical benefits would require the use of larger batteries, which would increase the physical size of the IMD, which is generally undesirable. Therefore, on the one hand, the communication infrastructure and message processing must be optimized to minimize energy consumption. On the other hand, IMDs on the market offer streaming of body function data, e.g., streaming of IEGM data, as part of the current standard of care. Such devices currently take the form of shallowly positioned subcutaneous implants that utilize large internal primary batteries and one-way telemetry capabilities that, when combined with their shallow placement in the patient's anatomy, support sufficient data rates to stream body function data from the organ or parts of the organ where sensing and therapeutic support are performed, e.g., from each heart chamber.

[0005] In leadless devices, the IMD resides deeper within the patient's anatomy, necessitating the use of a much smaller self-contained power source. These types of implants therefore face a trade-off: either reducing the amount of data they can relay to an external device in a given time, or requiring more power to match the data rates of comparable legacy devices. The ability to support body function data streaming, such as IEGM data streaming, is therefore a challenge for leadless products with respect to standard of care services required by traditional (leaded) products, such as CRM products.

[0006] For example, known leadless IMDs can support sensing of both right ventricle (RV) and right atrium (RA) signals. The known products further employ accelerometers to detect mechanical cardiac motion associated with atrial contractions as a cue to enable AV synchronous pacing. Because known systems with the known leadless IMDs leverage WAN-based infrastructures common to legacy cardiac rhythm management products or desired telemetry support infrastructures, the IMDs must exhibit significant power output to relay signaling to the programmer as they are forced to deal with the disruptive attenuation effects of high frequency carriers of serial communication schemes over longer intrabody channels. This situation, combined with the smaller capacity of the internal primary batteries of such leadless IMDs, has the direct consequence that any functionality expected in follow-up procedures is realized at the expense of an actual reduction in the useful life of the IMD. Summary of the Invention [Problem to be solved by the invention]

[0007] It would therefore be desirable to provide an IMD, communication system, and method that ameliorate the above-mentioned problems, in particular by optimizing the limited data communication throughput that is better suited to the power requirements of deeply implanted leadless IMDs, to enable streaming of body function data that is clinically useful and consistent with the standard of care expected for such products. [Means for solving the problem]

[0008] The above problem is solved by an IMD having the features of claim 1, by a communication system having the features of claim 9, by a corresponding communication method having the features of claim 11, by a computer program product having the features of claim 14 and by a computer-readable data carrier having the features of claim 15.

[0009] In particular, the subject matter concerns a method for providing a patient-assisted surgical procedure comprising: at least one sensor; a processor; and a transceiver module, the at least one sensor configured to monitor at least one predetermined body function of a patient; the transceiver module configured to bidirectionally exchange messages with an external device, i.e., to receive a request message from the external device and to send a corresponding response message to the external device, e.g., to respond to the request message; the processor configured to receive signals of the at least one body function detected by the at least one sensor, to process these signals to yield body function data, and to generate each response message such that each response message contains said body function data only if requested by a request message previously received from the external device, and such that each response message contains a data status field at a predetermined location within the response message; a) if the response message does not include the physical function data, a first predetermined value is assigned to the data status field; or b) If the response message includes the above-mentioned physical function data, the data status field is assigned a predetermined second value different from the first value, which is resolved by the implantable medical device (IMD).

[0010] A power-optimal approach might include turning off direct memory access (DMA) and ring buffer storage unless specifically requested by the programmer to do so to support streaming.

[0011] The IMD is an implantable medical device, as defined above, such as a leadless IMD, configured to monitor the health of a patient. Additionally, the IMD may be an IMD configured to deliver a therapeutic signal to the patient. For example, the IMD may be an ILP implanted in an atrium or ventricle of the patient's heart.

[0012] In one embodiment, the body function signal is an IEGM signal, such as an RA signal and / or a RV signal, and the predetermined body function data is IEGM data, such as RA data and / or RV data.

[0013] The IMD comprises a processor for data processing and a transmitter or transceiver module (e.g., an antenna or a magnetically coupled induction coil) for sending and transmitting messages (i.e., communication signals) to an external device, i.e., for receiving request messages from the external device and for sending corresponding response messages to the external device. The messages are bit strings embedded in a system of syntax and semantic rules defined in a communication protocol and expressed in and / or understood with / interfaced by corresponding algorithms and data structures. The request messages received by the transceiver module are transmitted to the processor for data processing. Conversely, the processor of the IMD generates the contents of the signals / messages and then transmits them to the transceiver module for sending / transmitting to the external device. The IMD further comprises at least one sensor configured to monitor at least one predetermined bodily function of the patient and thus receive its corresponding signals, e.g., IEGM signals, e.g., RA signals and / or RV signals.

[0014] The IMD may include additional modules, such as a memory (e.g., a storage buffer) for storing data, a power source such as a battery, and at least one signal generator for generating an electrical or electromagnetic therapy signal, e.g., to provide therapy to a patient. The transceiver module, the memory, the power source, the at least one sensor, and / or the signal generator may be electrically connected to the processor.

[0015] The memory of an IMD may include any volatile, nonvolatile, 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.

[0016] The external device may be a separate module located at least partially outside the body and connected wirelessly or by wire to a computer (e.g., physician device, remote server, programmer) having a processor. Alternatively, the external device may be an integrated unit of such a computer. The computer may be located at least partially outside the body. In case of two-way communication, the external device may comprise a transceiver or transmission module for messages (signals), e.g. an antenna or a magnetically coupled induction coil. The communication module may comprise a processor, especially if it is a separate module from the computer.

[0017] In one embodiment, communication between the external device and the IMD may be wireless, via the patient's body and / or the air, using electromagnetic waves, e.g., 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. Wired communication (electrical and / or optical) may also be possible.

[0018] For deep leadless implants, the preferred means for communication with / from the IMD and external device are conductive, acoustic, magnetic induction, and possibly optical. If the external device is a patient device, it may be connected to the programmer by other wireless capabilities, which may include Bluetooth, etc. If the external device is a patient device, it may be connected to a remote service center via WLAN, cellular networks, etc. If the external device is simply a programmer wand / programmer head, this is simply a wired connection that links it to the programmer.

[0019] In the context of this invention, each processor is considered an IMD, unit, and a functional unit of a computer that interprets and executes instructions, each comprising an instruction control unit and an arithmetic and logic unit, i.e., a functional unit that can perform substantial calculations, including numerous arithmetic and logic operations, without human intervention, on a remote computer, such as, for example, a personal mobile device (PMD), a desktop computer, a server computer, a cluster / warehouse-scale computer, or an embedded system.

[0020] According to the invention, the processor of the IMD is configured to receive signals of at least one predefined body function detected by at least one sensor, to process these signals to generate body function data requested by the external device, and to generate a corresponding response message. The generation of the response message is performed such that it does not include the predefined body function data in all cases, but only if the predefined body function data was requested by a previously received request message from the external device. Furthermore, each response message includes a so-called data status field at a predefined location in the response message, in which case: a) if the response message does not comprise or contain the physical function data, a predetermined first value is assigned to the data status field (e.g., a one-bit data status field that is assigned the value zero); or b) if the response message comprises or contains the above-mentioned physical function data, a data status field (e.g., a 1-bit data status field assigned a value of 1) is assigned a predetermined second value different from the first value.

[0021] The IMD may be used in a communication system for wireless message transfer between an external device and the IMD. The external device may be adapted to generate and send to the IMD a request message including a data request field, the data request field being assigned a specific value (e.g., value 1) from which a processor in the IMD infers that the IMD is requested to provide the external device with physical function data. If the data request field of the request message contains a value other than the specific value (e.g., value zero), the processor in the IMD infers that the external device is not requesting transmission of any physical function data. In one embodiment, the length of the request field is 1 to 4 bits.

[0022] The IMD and communication system provides a communication packet design structure that includes a flag (data status field) suitable for reporting information carried in an IMD response, together with the ability to append a block of physical function data, such as IEGM data, on the end (i.e. as a caboose) of any such response. This allows the data structure of the response message to be adapted to the actual requirements of the user, based on the content of the request message sent to the external device. This results in only the requested data being sent (and not requested data being avoided), which may have a positive effect on the useful life of the IMD and / or provide more spans in the communication link over which other CMD / response packets can be relayed. Multiple response messages may be sent one after the other by the transceiver module, thus forming a stream of messages. Furthermore, when the external device receives a response message, it obtains information about the structure of the response message (e.g., information on whether the message contains physical function data or not, and may also include a data status field containing other information about the structure), thereby ensuring proper and reliable processing of the data received with the response message in the computer connected to the external device or unit. Information about the structure of the response message is further used to properly display the physical function data on a display provided with an external device or computer.

[0023] The expression "assigned to" means that the response message transmits in its data status field at least the first or second value as defined above, respectively. The same applies analogously to the request message and its data request field. The transmission of additional values ​​in these fields is not excluded in this case, but depends on the length of the corresponding fields. In one embodiment, the length of the data status field is 1 bit to 1 byte. If the data status field is 1 bit, for example, the first value may be the value 1 and the second value may be the value 0. By using the data status field, the IMD indicates whether the requested physical function data is added to the response message or not.

[0024] In one embodiment, the request message is a proximity request message, i.e. a regular request provided at predetermined time intervals to maintain a data link between the IMD and an external device, also called a proximity command relay; a monitoring request message, i.e. a request to determine certain actual body parameters; a programming message, i.e. a request to set or change certain program parameters of a computer program running in the processor; a status request message, i.e. a request to provide certain status parameters (e.g. battery status) of the processor or any other module of the IMD; an execution request message, i.e. a request for the execution of a certain program sequence; or a data request / interrogation message, i.e. a request for the delivery of certain data stored in the data memory of the IMD.

[0025] In one embodiment, the response message (message sent by the IMD to the external device) is a proximity response message, i.e., a response to a proximity request message, a report response message, i.e., a response to a monitoring request message, a programming response message, an execution response message, or a data request / interrogation response message - all of which after completion of the sequence required to provide the relevant data - or an acknowledgement message, i.e., an immediate response to a monitoring request message, a program request message, an execution request message, or a data request / interrogation message - all of which simply convey that the IMD has received the corresponding request.

[0026] Each of the above mentioned messages (request message, response message) may be a complete message including all necessary components and fields according to the corresponding communication protocol, or may only form a part of a complete message because a predefined maximum transmission unit has been reached. In the latter case, the complete message is split into several packets, which are sent separately. A field (e.g. data status field or data request field) is a section of the bit string of the message having a predefined length (e.g. 1-4 bits or 1 bit-1 byte) and / or a predefined location within the complete bit string. The message may of course include other details such as synchronization bytes, addressing information, commands and response contents, but such contents are intentionally excluded from this discussion, since they are part of the broader protocol but are not particularly relevant to the focus of this disclosure.

[0027] In one embodiment, the data status field contains further information about at least one characteristic of the included physical function data, for example the type of said physical function data and / or the length of said physical function data and / or its data resolution and / or information about the physical function data structure in the response message (the data status field may contain such information, but a scheme for relaying such content may be part of various markers introduced in the IEGM data). In this embodiment, the characteristics of the physical function data described in the data status field convey on the one hand information about the structure of the response message to the external device. For example, from the information about the length (i.e. number of bits) of the physical function data, the external device can determine the end of a message block (field) belonging to the physical function data. In one embodiment, a cyclic redundancy check (CRC) word may be included that takes this length information into account, so that the infrastructure on the external device side can properly time and concatenate any data received and display it to the user. On the other hand, the information about at least one characteristic of the included physical function data allows the external device or a computer connected to the external device to properly evaluate and display the received data of the at least one physical function. The predetermined body function data type refers to the type of data transmitted when the IMD monitors various body functions, e.g., RA data and RV data. As indicated above, the information about at least one characteristic of the included body function data includes the resolution of the data (e.g., 128 Hz, 64 Hz). The system may have non-user access to controls to support either high resolution rendering of a single selected IEGM data (e.g., RA data or RV data) or simultaneous display of two IEGM data (e.g., RA data and RV data) at lower resolution. This provides system controls (which may be user accessible depending on the product design) to configure the resolution of the streamed content of two or more body function sources in the IMD, e.g., two or more IEGM sources in a leadless IMD.This allows standard of care CRM functionality to be effectively provided despite the lower data rate requirements necessary for low power transmission from / to deep IMDs such as ILP. Furthermore, if display of a particular source is specifically desired (e.g., as part of an atrial far-field sensing test), the inventive approach provides a means to optimize / enhance its resolution. Alternatively, if a balanced approach is desired, the approach supports adjustment of stream resolution such that clinically relevant signaling is reported without overtly compromising the interpretability of any signal source. As a result, this embodiment provides the ability for the system to change the resolution and format of the presented body function streams as required by follow-up use cases (e.g., high-resolution atrial streaming during atrial sensing tests and low-resolution rendering otherwise).

[0028] In one embodiment, the data status field further includes information about when the included body function data changes at least one of its at least one characteristics. This embodiment allows, for example, to render in one message two different resolutions or different data types of a body function adapted to the user's requirements. For example, it is possible to change the transmission of a selected single IEGM data (e.g., RA data or RV data) in high resolution to a simultaneous display of two IEGM data (e.g., RA data and RV data) in low resolution, or vice versa.

[0029] Additionally or alternatively, markers can be introduced into the IEGM at the locations where the data for a sample changes (instead of in the data status field), in which case time is effectively communicated by the position of the sample.

[0030] In one embodiment, the response message, e.g., physical function data, is used to carry any event markers associated with the physical function data, e.g., IEGM data, that can be used to know when the source of the physical function data has actually changed. They are sent in a manner embedded within the IEGM payload, where one or more bytes can be used to report, for example, an atrial sensed event (e.g., an atrial contraction), a ventricular sensed element (e.g., a ventricular contraction), a ventricular premature contraction, or others.

[0031] In one embodiment, the processor is electrically connected to the storage buffer, and the processor is adapted to directly and continuously store the physical function data in the storage buffer after receiving a request from the external device to provide at least one physical function data. To save overhead associated with managing the physical function stream data (e.g., IEGM data), an embodiment for supporting the requests outlined above utilizes a hardware-based accelerator to enable direct memory access (DMA). In other words, an "engine" in the processor's integrated circuit facilitates the rapid populating of the storage buffer with sensed data. In one embodiment, such a storage location is a rotating ring buffer of sufficient size that is continuously filled as physical function data is requested from the external device. In the event of an incoming request from the external device infrastructure to either respond to a command or maintain communication (proximity response message), the IMD "rips" all new content stored in the ring buffer since its last "dump" operation (i.e., since the preceding command / response interaction). In general, the processor may be configured such that the complete contents of the storage buffer of the physical function data stored in the storage buffer since a previous emptying operation is retrieved from the storage buffer and transferred to the processor.

[0032] Similarly, the above problem is addressed by a method of communication for an IMD, comprising at least one sensor, a processor, and a transceiver module, wherein the at least one sensor monitors at least one predetermined bodily function of a patient, and the transceiver bidirectionally exchanges messages with an external device, - receiving a request message from an external device; - checking whether the received request message contains a specific value assigned to a data request field, from which the IMD infers that the IMD is requested to provide physical function data to an external device; - receiving a signal of at least one predetermined body function detected by at least one sensor, such as an IEGM signal, such as an RA signal and / or an RV signal; - processing these signals to generate body function data, such as IEGM data, such as RA data and / or RV data, required by an external device; - generating a response message such that the response message includes the physical function data only if requested by a previously received request message (i.e., only if the previously received request message included a particular value in the data request field) and such that the response message includes a data status field in a predetermined location within the response message; a) if the response message does not comprise or contain said physical function data, a data status field is assigned a predetermined first value; or b) generating, if the response message comprises or contains the requested physical function data, a data status field is assigned a second predetermined value different from the first value; - transmitting the generated response message by the transceiver module to the external device, thereby responding to the request message.

[0033] The above method has the same advantages as the above IMD or communication system. Furthermore, the transmitted physical function data is used for further processing and / or display in the external device or in a connected computer. Further processing may include data transfer to a medical professional for adaptation of program parameters, data evaluation to adapt the corresponding patient's treatment.

[0034] In one embodiment, the physical function data is stored directly and continuously in a storage buffer of the IMD after receiving a request from an external device that includes a particular value in the data request field.

[0035] In one embodiment of the above method, the complete contents of the storage buffer's physical function data stored in the storage buffer since the last emptying operation is transferred to the processor.

[0036] Additionally or alternatively, a processor is present to assemble a packet and send it out as a response. The processor can simply point to the IEGM in the ring buffer, or it can capture it and shove it into the outgoing message.

[0037] The above method may be implemented, for example, as a computer program comprising instructions that, when executed, cause a processor to perform the steps of the above method (to be executed by the IMD, in particular in its processor and transceiver modules), which may be a combination of computer instructions and data definitions as specified above and below that enable computer hardware to perform a computational or control function, or may be syntactic units conforming to the rules of a particular programming language, consisting of declarations and statements or instructions necessary to perform the functions, tasks or problem solutions specified above and below.

[0038] Furthermore, a computer program product is disclosed comprising instructions which, when executed by a processor, cause the processor to perform the steps of the method defined above. Accordingly, a computer readable data carrier having such a computer program product stored thereon is disclosed.

[0039] The invention will now be described in more detail with reference to the accompanying schematic drawings. [Brief description of the drawings]

[0040] [Figure 1] FIG. 1 illustrates an embodiment of a communication system of the invention that includes an implantable leadless pacemaker (ILP) and an external device, where the ILP is shown in cross-section of a patient's heart. [Diagram 2] FIG. 2 illustrates a scheme showing a body function signal in the form of an RV IEGM signal and a corresponding response message of a first embodiment of the communication method of the present invention. [Diagram 3] FIG. 13 illustrates a scheme showing body function signals in the form of RA IEGM and RV IEGM signals and corresponding response messages of a second embodiment of the communication method of the present invention. [Figure 4] A diagram illustrating a scheme showing body function signals in the form of RA IEGM and RV IEGM signals and corresponding response messages of a third embodiment of the communication method of the present invention. [Diagram 5] A diagram illustrating a scheme showing body function signals in the form of RA IEGM and RV IEGM signals and corresponding response messages of a fourth embodiment of the communication method of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0041] FIG. 1 illustrates an example communication system 10 and a heart 20 (having a right ventricle 21 and a right atrium 22) of a patient 30. The system 10 includes an example IMD, a ventricular leadless pacemaker device 40 (hereinafter "ILP 40"), and an external device 60. The ILP 40 can be configured for implantation in the right ventricle 21 of the heart and for pacing the ventricle and sensing intrinsic ventricular depolarizations. The ILP 40 can further include an accelerometer sensor to measure mechanical motion of the heart 20 associated with atrial contractions as a cue to enable AV synchronous pacing. A programmer (not shown) can be used to program the ILP 40 using the external device 60. The external device 60 is positioned outside the body and is adapted for bidirectional communication with the ILP 40.

[0042] The ILP 40 may include modules such as a processor, a data memory, a signal generator unit for providing a therapy signal (e.g., a pacing signal), a sensor including an IEGM measurement unit and an accelerometer sensor for detecting ventricular depolarizations, a transceiver module for sending and receiving messages to and from the external device 60, and a power source, which are electrically connected to each other. The power source may include a battery, e.g., a rechargeable or non-rechargeable battery. The data memory may include any type of memory described above.

[0043] 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 messages with a programmer and / or a remote computer (not shown) or may be integrated in the programmer or the remote computer. In the latter case, the processor 61 may be integrated in the processor of the programmer or computer. The 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 facilitated, for example, by acoustic, conductive or magnetic induction methods, or by electromagnetic waves in the radio frequency band.

[0044] The operation of one embodiment of a communication method is described below with reference to Figures 2-5, which provide further scrutiny of the interactions used to support the disclosed general approach for managing and reporting high-resolution and low-resolution IEGM streams. Within Figures 2-5, like reference numbers refer to like elements of these schemes.

[0045] FIG. 2 shows high resolution streaming of the IEGM signal, specifically the RV signal 101 including events such as ventricular contraction 103 and atrial contraction 104, by the corresponding sensors of the ILP 40. Atrial contractions are very often not visible in the RV stream. The markers "As" were generated behind the scenes using an atrial autodetection circuit that utilizes a different signaling than the RV stream. The RV signal 101 is continuously measured or collected by the ILP sensor and sent to the processor, which takes an analog signal, converts it to a digital value, and places it in the IEGM stream. The processor generates a high resolution (e.g. 128Hz) RV data stream 301 from only a single data type 201 populated into a data memory formed by a DMA ring buffer formed by a number of packets 303 (containing the body function data). A packet (i.e. 303) is or can be simply the content pulled from the ring buffer between its start and end indexes at any given time. Each time the content is pulled from the buffer and sent to the external device, the external device creates an IEGM payload for the packet. For transmission to the external device 60, the data packets 303 are separated from the DMA ring buffer to form a plurality of response messages 401, each including a second predetermined value in the data status field indicating that each response message 401 includes RV data as the body function data. In other words, the contents of the ring buffer are placed in a packet only if the response packet is one for which the programmer has specifically requested that an IEGM be relayed as part of the response. The response packet will include a data status field indicating that it includes an IEGM. Additionally, the corresponding message 401 includes event data (time of ventricular contraction 103 and atrial contraction 104) embedded within the RV data. This allows the location of the sample within the packet to determine the time of the event, or can be, and the type of marker to indicate what event occurred.Additionally, any message 401 sent from the ILP contains a start-of-packet marker 403 that reports not only the type of IEGM sent (e.g., RV type data) but also the resolution at which it is recorded (e.g., 128 Hz). This approach can be employed only for rendering high-resolution content from some sources (e.g., RV stream 101).

[0046] After sending the message 401 to the external device 60, the RV data stream derived from the message 401 may be displayed on a programmer's or computer's display or may be further processed. The external device 60 may be integrated into the programmer or computer.

[0047] In Figures 2-5, all messages 401 are presented as being of the same length. Such a situation would not actually apply to a periodic programmer communication session where command requests are sent in a nominally asynchronous fashion. The situation shown is more representative of a situation where the communication link is simply maintained by a proximity command sent, for example, every 200 ms as a means of keeping the communication channel between the ILP 40 and the programmer (and external device 60) active.

[0048] To support the situation of targeted transition between specific different IEGM sources (e.g., between only atria or only ventricles), it has been found that the outlay of Fig. 3 can be well illustrated. In this scheme, the RV stream 101 measured as shown above and the RA stream 107 continuously detected by the accelerator are shown. In section 110 of the RV stream 101 and section 111 of the RA stream as viewed by the user, the external device may use the content from the rendered channel at this point (measurements in section 111 of the RV stream 101 or measurements of the RA stream 107 in section 110 of the RV stream 101) and display this content on the other (e.g., RV data 101 rendered into the RA channel or RA data 107 rendered into the RV channel) by scaling it down (e.g., scaling RV data down to RA amplitude) or up (e.g., scaling RA data up to RV amplitude). This signal display management is handled exclusively by the external device (i.e., the programmer GUI display) and the implant plays no role in making the contents in 111 or 110 visible to the user. This results in a continuous data stream 301 (including body function data) in a single packet 303 containing RV type data 201 and alternating RA type data 203. The data stream 301 and packets 303 described above are body function data. While such an approach avoids presenting any false information, it must be admitted that it is not guaranteed to show all important elements in the raw signaling that may be associated with the reported cardiac event marker stream. As indicated by the start of packet marker 403 in message 401, the RV and RA data are provided at high resolution (e.g., 128 Hz). Information regarding the change of data type as shown in sample 205 is embedded within the RV and RA data.Similar to the embodiment shown in FIG. 2, any message 401 sent from the ILP includes a start-of-packet marker 403 that reports not only the type of IEGM sent (e.g., RA-type data or RV-type data) but also the resolution at which it is recorded (e.g., 128 Hz).

[0049] FIG. 3 represents the case where the maximum resolution per channel is shown. This may be beneficial in certain follow-up cases, but does not necessarily guarantee to satisfy all users or the market in every condition. As in the case of the data described with respect to FIG. 2, the RV and RA data may be displayed after transmission to the external device 60. It should further be mentioned that the programmer's GUI design may employ creative means to provide the user / clinician with display elements that cover gaps in the data in sections 110, 111 in the graphic (in other words, the content streamed from the implant does not provide data in regions 110, 111). Incarnations of this kind may include a wide range of techniques, such as simply leaving gaps in the display (i.e., nothing is shown since no data fills these spaces as described above), highlighting the display in a way that indicates a feature indicative of a "no data" condition (e.g., inserting a "greyed out" state or a series of ellipses), or scaling the data of the alternate channels as described in the previous paragraph.

[0050] 4 illustrates a situation where the system switches between displaying high resolution IEGM content on a single channel (i.e. RV Stream Data 101 according to Section 201) and displaying low resolution IEGM content (e.g. 64Hz) on multiple channels (i.e. RV Stream Data 101 and RA Stream Data 107 according to Section 206). Information about the data type change and resolution change as shown in sample 205 is embedded in the RV and RA data of the corresponding message 401. Furthermore, at the beginning of each data packet, the corresponding data start marker 403 indicates not only the two different data types but also the resolution of each data type, if applicable.

[0051] In the final scheme shown in Figure 5, even simultaneous streaming of low resolution IEGM data from multiple channels (RV data 101 and RA data 107) is supported at all times (see Data Type Representation 206). Multiple channel sampling, even at 64Hz, is clinically useful for atrial and ventricular cardiac signals.

[0052] Aside from the embedded markers that accompany the packages, each data sample in the stream can vary between an RA sample and an RV sample - in other words, sample 5 is an RA data point, sample 6 is an RV data point, sample 7 is an RV data point, etc.

[0053] 2-5 all contain a 1-bit data status field that is assigned a second value (e.g., value 1), thereby indicating to the external device 60 that the corresponding message 401 contains body function data (RA data 107 and / or RV data 101). Additionally, each message 401 may contain information regarding the length of the included RA data 107 and / or RV data 101.

[0054] Prior to sending the response message 401 described above, the external device 60 has sent a request message including a data request field having a length of 1 bit. A value of 1 was assigned to the data request field, thereby indicating to the ILP 40 that data transmission is requested for RA and / or RV data. In one embodiment, the data request field may indicate the type of data and its resolution. This request triggers the ILP 40 to start measuring and / or collecting the requested data, and to process and transmit the data as described above. As soon as sufficient data has been received or the clinician has turned off IEGM collection or measurement, the external device 60 may send another request message with a value of 0 assigned to the data request field, thereby indicating that data generation and transmission is finished.

[0055] In summary, the systems and methods of the present invention provide system control capabilities (which may be user accessible depending on the product design) for configuring the resolution and type of streaming content of one or more single IEGM sources in a leadless product such as an ILP.

[0056] Notwithstanding the above observations about clinically meaningful signal output, it should be noted that it is quite likely that a significant portion of the collected data represents a "flat line" zero amplitude condition, given that there is no actual data outside the active atrial sensing window accessible in the atrial channel during VDD mode operation. Reporting such values ​​reflects the observable condition for the atrial channel, but may not represent optimal use of the accessible cross-product signal resolution for the data transmission throughput supported by the leadless product. In that case, the configuration in Figure 4 is likely to be favored over the rendering in Figure 5, since it avoids data space occupation in relayed IEGM signaling by the atrial sensing window during VDD time in favor of higher resolution ventricular sensing.

[0057] A possible implementation extension (not shown) of the above concept would be to suspend DMA transfers to the ring buffer during segments of the stream where no meaningful data can be collected (e.g., during its quiet "zero" parts, consider possible Fig. 2b) and use suitable markers to manage the intended cooperation with the external device. This approach could save on the data throughput limit between the implant and the external device (i.e., by avoiding sending long streams of "zeros"), but would still lose the time resolution of any event markers within such "non-strobed" periods (i.e., the positions of "As", "Vs", etc. events within the non-signal parts would not be known with the same accuracy as in the previous embodiment, since their positions within the relayed samples are not indexed by the surrounding null data points).

[0058] Again, how to report to the user the observable changes in resolution made possible by Figure 4 is a matter of GUI design for the programmer or computer receiving the data from the external device. Even this enhanced embodiment may rely on the "smarts" of the programmer to pick out lower resolution markers and match them to morphological considerations in the ventricular signal.

Claims

**Claim 1** An implantable medical device (IMD, 40) comprising at least one sensor, a processor, and a transceiver module, wherein the at least one sensor is configured to monitor at least one predetermined body function (101, 107) of a patient, and the transceiver module is configured to exchange messages bidirectionally with an external device (60), i.e., to receive a request message from the external device (60) and to transmit a response message (401) corresponding to the external device (60), and the processor is configured to receive a signal (101, 107) of the at least one predetermined body function detected by the at least one sensor, process the signal to generate body function data (303), and generate each response message such that each response message includes the body function data only if each response message is requested by a request message previously received from the external device (60), and each response message includes a data status field at a predetermined location within the response message, a) when the response message does not include the body function data, a predetermined first value is assigned to the data status field, b) when the response message includes the body function data, a predetermined second value different from the first value is assigned to the data status field. **Claim 2** The IMD according to claim 1, wherein the length of the data status field is from 1 bit to 1 byte. **Claim 3** The IMD according to claim 1 or claim 2, wherein the generated response message (401) is a proximity response message or a direct response message to a request message. **Claim 4** The IMD according to claim 1 or claim 2, wherein the body function signal is an IEGM signal, such as an RA signal (107) and / or an RV signal (101), and the body function data is IEGM data (303), such as RA data and / or RV data. **Claim 5** The response message (401) includes event information (103, 104), and / or the data status field includes further information about at least one characteristic of the included physiological function data, such as, for example, the type of the physiological function data (103, 104), and / or the length of the physiological function data, and / or its data resolution, and / or information about the physiological function data structure (201, 203, 205) in the response message. The IMD according to claim 1 or claim 2.

6. The IMD according to claim 5, wherein the data status field further includes information about a point in time (205) at which the included physiological function data changes at least one of its at least one characteristic.

7. The processor is connected to a memory buffer, and the processor is configured such that after receiving a corresponding request from the external device (60), physiological function data (301) is directly and continuously stored in the memory buffer. The IMD according to claim 1 or claim 2.

8. The processor is adapted such that the complete content of the physiological function data of the memory buffer stored in the memory buffer since the last emptying operation is collected from the memory buffer and transferred to the processor. The IMD according to claim 1 or claim 2.

9. A communication system for performing wireless message transfer between an external device (60) and an IMD (40) according to claim 1 or claim 2.

10. The external device (60) is adapted to generate a request message including a data request field, a specific value is assigned to the data request field, and the processor of the IMD infers from the value that the IMD is requested to provide physiological function data to the external device. The communication system according to claim 9.

11. A communication method for an implantable medical device (IMD, 40), comprising at least one sensor, a processor, and a transceiver module, wherein the at least one sensor monitors at least one predetermined physiological function of a patient, and the transceiver exchanges messages bidirectionally with an external device (60), comprising: Receiving a request message from the external device (60); A step of checking whether the received request message contains a specific value assigned to the data request field, and the IMD infers from the value that the IMD is requested to provide data of the at least one body function to the external device, the step of checking; Receiving signals (101, 107) of the at least one body function detected by the at least one sensor, such as an IEGM signal, such as an RA signal (107) and / or an RV signal (101); Processing the signals to produce the required body function data (301, 303), such as IEGM data, such as RA data and / or RV data; Generating a response message (401) only if the response message is requested by a previously received request message, such that the response message includes the body function data and such that the response message includes a data status field at a predetermined location within the response message; a) If the response message does not include the body function data, a predetermined first value is assigned to the data status field, or b) If the response message includes the body function data, a predetermined second value different from the first value is assigned to the data status field, the step of generating; Transmitting the generated response message to the external device (60) to respond to the request message. A communication method for an implantable medical device (IMD, 40).

12. The communication method according to claim 11, wherein after receiving a request including the specific value in the data request field from the external device (60), body function data is directly and continuously stored in the memory buffer of the IMD.

13. The communication method according to claim 11 or claim 12, wherein the complete content of the body function data of the memory buffer stored in the memory buffer after the previous emptying operation is transferred to the processor.

14. A computer program product comprising instructions that, when executed by a processor, cause the processor to execute the steps of the method according to claim 11 or claim 12.

15. A computer-readable data carrier storing the computer program product according to claim 14.

Images