WO2008094080A1 - Method for segmentation in a medical telemetry system - Google Patents
Method for segmentation in a medical telemetry system Download PDFInfo
- Publication number
- WO2008094080A1 WO2008094080A1 PCT/SE2007/000083 SE2007000083W WO2008094080A1 WO 2008094080 A1 WO2008094080 A1 WO 2008094080A1 SE 2007000083 W SE2007000083 W SE 2007000083W WO 2008094080 A1 WO2008094080 A1 WO 2008094080A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data
- frame
- implantable medical
- medical device
- packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- A—HUMAN NECESSITIES
- A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
- A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
- A61B5/00—Measuring for diagnostic purposes; Identification of persons
- A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
- A61B5/0031—Implanted circuitry
-
- A—HUMAN NECESSITIES
- A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
- A61N—ELECTROTHERAPY; MAGNETOTHERAPY; RADIATION THERAPY; ULTRASOUND THERAPY
- A61N1/00—Electrotherapy; Circuits therefor
- A61N1/18—Applying electric currents by contact electrodes
- A61N1/32—Applying electric currents by contact electrodes alternating or intermittent currents
- A61N1/36—Applying electric currents by contact electrodes alternating or intermittent currents for stimulation
- A61N1/372—Arrangements in connection with the implantation of stimulators
- A61N1/37211—Means for communicating with stimulators
- A61N1/37252—Details of algorithms or data aspects of communication system, e.g. handshaking, transmitting specific data or segmenting data
- A61N1/37254—Pacemaker or defibrillator security, e.g. to prevent or inhibit programming alterations by hackers or unauthorised individuals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1874—Buffer management
- H04L1/1877—Buffer management for semi-reliable protocols, e.g. for less sensitive applications like streaming video
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
Definitions
- the present invention is related to the field of medical telemetry, and in particular to a method for segmentation and reassembly of data transmitted in a medical telemetry system.
- Telemetry is a generic term for techniques for conveying measuring data from one point to another, usually by means of radio or cable connections.
- telemetry systems are generally used for enabling radio- frequency (RF) communication between a device worn by a patient, for example an implantable medical device such as a pace maker, and an external monitoring device.
- RF radio- frequency
- the communication of messages between the implantable medical device and the external monitoring device should be made as efficient and as secure as possible.
- real-time physiologic data is transmitted. It is therefore most important that as few communication messages as possible are lost or delayed.
- the coinmunication between the implantable medical device and the external monitoring device is deficient, then an excessive number of retransmissions is required, which increases the power consumption of the implantable medical device. Besides the risk of losing real-time physiological data, the service time of the battery of the IMD is also shortened.
- Another aspect of rendering the communication as efficient as possible is to bundle up the data to be transmitted as efficiently as possible.
- Communication packets are often required to be made smaller to speed them through the network or because of specified packet size restrictions in a given path.
- a segmentation and reassembly process is a process to accomplish this, that is, to break a communication packet into smaller units before transmission and reassembling them into the proper order at the receiving end of the communication.
- a design difficulty in medical telemetry systems is the limited size available in an implantable medical device for the electronics required for enabling communication.
- Published patent document US 6,128,528 relates to one aspect of the way the communication is to be conducted between devices 'in a medical system.
- a method for detecting corrupt implantable medical device data within a data block is disclosed.
- an error code is calculated and appended to a block or blocks of implantable medical device data as the implantable medical device data are moved and/or read by a block mover/reader in a block move or read operation within an implantable medical device.
- a method in a medical telemetry system for communication between an external monitoring device and an implantable medical device.
- the method comprises a first step of segmenting, at a transmitting end, an implantable medical device frame layer packet into one or more data blocks of a radio packet, wherein the data blocks are transmitted in the communication between the external monitoring device and the implantable medical device.
- the start of the implantable medical device frame layer packet is indicated by including in a first data block of the radio packet a segmentation and reassembly indicator having a first value.
- the data blocks are transmitted, at the transmitted end, over a short-range medical radio link.
- the data blocks are reassembled, at the receiving end into the originally transmitted implantable medical device frame layer packet.
- one segmentation and reassembly bit is included for each data block of the radio packet, wherein each data block comprises 14 bytes. This means little overhead and the use of the available data bandwidth is maximized in that as much payload as possible can be conveyed.
- the method comprises the step of including the segmentation and reassembly indicator in data blocks following the first data block, but now having a second value.
- the second value indicates that the originally sent implantable medical device frame layer packet is continued in this data block. It is possible to segment the implantable medical device frame layer packet into one or into several radio packet data blocks .
- the method comprises the step of including cyclic redundancy check bits in the radio packet. Increasing the length of the CRC checksum will result in fewer bit errors passing unnoticed through the MICS link. It is possible to detect errors at the radio layer, whereby the power consumption of the implantable medical device can be lowered and its service life prolonged. Further, detecting errors at this lower layer will also be time saving, since retransmissions can be handled at the radio link level.
- the segmentation and reassembly indicator may comprise a single bit, the indicator then taking the values 1 and 0, respectively for indicating the start or continuation of an implantable medical device frame layer packet. Alternatively, the segmentation and reassembly indicator may comprise two bits, whereby it is possible to indicate the start of an implantable medical device frame layer packet, continuation and end of it. Design flexibility is thereby provided, enabling adapting the method in dependence on specific needs.
- the invention is also related to a medical implantable device and a base station comprising means for performing the method, whereby advantages similar to the above are achieved.
- Figure 1 is a schematic overview of a medical telemetry system in which the present invention may be utilized.
- Figure 2 is an overview over frame layer protocols used for communication between devices of a medical telemetry system.
- Figure 3 illustrates the implantable medical device layer formats .
- Figure 4 illustrates a basic radio packet.
- Figure 5 illustrates a data block
- Figure 6 illustrates the byte that conveys the SAR bit.
- Figure 7 illustrates a layer-to-layer relationship
- Figure 8 illustrates another layer-to-layer relationship.
- Figure 9 illustrates an IMD frame divided into several radio packets .
- Figures 10a and 10b illustrate the minimum and maximum size of an IMD frame.
- FIG 11 is a flowchart over steps included in a method in accordance with the present invention.
- FIG. 1 illustrates schematically a medical telemetry system 1 in which the present invention may be implemented.
- the medical telemetry system 1 comprises a base station, also denoted wand 2, which typically communicates with an external instrument, such as an external programmer or monitoring device 3 through a wired connection (e.g. a USB connection).
- the wand 2 and the external monitoring device 3 may be an integrated unit or two separate units.
- the wand 2 communicates wirelessly with one or more implantable medical device (IMD) 4, such as for example a pace maker or an internal cardiac defibrillator.
- IMD implantable medical device
- curled braces ⁇ ⁇ , are used for denoting messages that are exchanged between peer entities
- a radio packet comprises data blocks and is used for denoting the lowest physical layer providing the means for transmitting raw bits. That is, the physical layer performs services requested by the IMD frame layer.
- Figure 2 is an overview over a protocol suite used for the communication between devices of the medical telemetry system
- protocol suites for the IMD 4, for the RF wand 2 (in the MICS standard known as "ultralow power active medical implant periphery", ULP AMI-P) and for the external monitoring device 3 are shown in the figure.
- the present invention is primarily related to and concerned with an IMD frame layer protocol.
- the IMD frame layer protocol of the protocol suite is run on top of the MICS radio physical layer.
- the IMD frame layer protocol is used for effectuating the wireless communication between the RF Wand and the implantable medical device.
- the purpose of the IMD frame layer is to provide services for multiple access points of connectionless message transfer for passing information across the radio link.
- Segmentation and reassembly refers to the process used to fragment and reassemble data packets so as to allow them to be transported across the desired communication link.
- a MICS channel can transport 14 bytes of payload, that is, 112 bits of information.
- the transmitting side in the following example the wand 2 (which receives the data to be transmitted from the external monitoring device 3), has to divide, i.e. segment, the packets into a stream of smaller packets. That is, the large communication packet (i.e. the IMD frame layer packet) has to be segmented into chunks of 14 bytes, which can be sent over the MICS link.
- the receiver then has to put together, i.e. reassemble, the received 14 bytes chunks into the originally sent IMD frame layer packet.
- FIG. 3 illustrates the IMD frame layer format.
- Frame Type identifies the current IMD frame type.
- IMD frame types There are several IMD frame types:
- Packet Data Frame carrying e.g data for programming a parameter.
- a Packet Data Frame conveys Transport Layer messages (the data field of the Packet Data Frame carries the transport layer messages) .
- a Packet Data Frame is identified by setting ⁇ Frame Type> to 0 (0 0 0 0).
- a Stream Data Frame carrying e.g. real-time data or markers (intracardiac electrogram markers).
- a Stream Data Frame is identified by setting ⁇ Frame Type> to 1 (0 0 0 1).
- a Keep-alive Request is identified by setting ⁇ Frame Type> to 2 (0 0 1 0).
- This frame is initiated by a Keep Alive Procedure, which is a mechanism intended for detecting a temporary loss of the MICS radio link, i.e. the physical channel, and provides link quality parameters to a Link Quality Assessment Procedure.
- the Link Quality Assessment Procedure in turn has the purpose to assess the current link quality by means of the parameters in the wand 2 and the IMD 4. The link quality is indicated to upper layer upon a value change.
- Keep-alive Reply is identified by setting ⁇ Frame Type> to 3 (0 0 1 1) .
- This frame is sent from the IMD in response to a Keep-alive Request and contributes to the above-described Keep Alive Procedure.
- This message carries, for example, data related to the RF link quality.
- Loopback frame is identified by setting ⁇ Frame Type> to OxF and is used for sending data to the IMD, whereby the IMD just echoes the data back from the frame layer to the host.
- the ⁇ Data Length> field is the total length of data field, wherein applicable values are, in an exemplary embodiment, from 1 to 512 bytes. In another embodiment however, the IMD frame layer is designed to carry between 1 and 4095 bytes. It is to be noted that the IMD frame layer may be designed to carry even more data. In the illustrated case, the ⁇ Data Length> field is defined by 9 bits of the available 12 bits, but if the ⁇ Data Length> field were to be defined by, for example, 12 bits, then a length of 4095 bytes would be the highest number of bytes that can be expressed. In yet other implementations, the IMD frame layer may be designed to carry even further data.
- the ⁇ Data> field represents different messages as defined above.
- a message is governed by the content of the ⁇ Frame Type> field.
- the ⁇ Padding> field is used to accommodate an IMD Frame to 14 bytes alignment, which, as mentioned earlier, is required for MICS radio packet data blocks.
- This field contains undefined octet values and may be of any size between 0 and 12 bytes.
- the padding field is included in the cyclic redundancy check algorithm.
- the CRC algorithm is used by the IMD frame layer and is sent in the last data block.
- the CRC algorithm may for example be a CRC-I6 polynomial.
- FIG. 4 illustrates a basic MICS radio packet, onto which the IMD frames described above are to be mapped.
- the radio packet may carry up to 31 data blocks, each data block able to convey
- each data block conveys a payload of 14 bytes plus one extra bit denoted a SAR
- Figure 5 illustrates a data block of a radio packet more in detail.
- the data block comprises 14 bytes of payload, i.e. user information, and a SAR bit.
- a cyclic redundancy check (CRC) comprising for example 12 bits is included, i.e. a conventional checksum computed and appended before transmission, and verified afterwards by the receiving side to confirm that no changes occurred during transmission.
- CRC cyclic redundancy check
- conventional error correction code comprising for example 30 bits is also included.
- Reed-Solomon error correction code could be utilized, e.g. RS(31,25).
- the SAR bit could be used to indicate whether user data within a data block is a fragment or not.
- the SAR bit is used to indicate the start of an IMD frame or continuation of the IMD frame.
- the SAR bit is represented by a byte and could have the value zero (0) or one (1).
- Figure 6 illustrates the byte that conveys the SAR bit.
- the SAR bit indicating the start of the IMD frame can have the value zero ("0") or one ("1") .
- a continued data block is then indicated by the other value.
- the segmentation and reassembly indicator comprises two or more bits.
- the segmentation and reassembly indicator may then have several values, e.g 00, 01, 10, 11. It is thereby possible to indicate the start, the end and even the middle of the IMD frame .
- the SAR bit is represented as a byte when it is delivered to/from the MICS layer and a SAR bit is sent for each data block. That is, every 15 th byte to/from the MICS layer is a byte that carries the SAR bit.
- the SAR byte is included in the CRC computation as well as the ⁇ Frame Type> field, the ⁇ Data Length> field, the ⁇ Data> field and the ⁇ Padding> field.
- FIG. 7 illustrates the relationship of the messages, illustrated from layer to layer starting at Transport Layer
- the transport layer data (e.g. for maintaining flow control of data and recovery of data between devices) are mapped onto IMD frame packets, as is illustrated. Transport layer messages are carried by the ⁇ Data> field of the IMD frames .
- Figure 8 illustrates the relationship of the messages from layer to layer, starting at Stream Data Layer.
- ⁇ Frame Type> is set to 1 (0 0 0 1), i.e. identifying stream data
- the ⁇ Data Length> is set to whatever length the ⁇ Data> field has (between 1 and 512 bytes) , followed by data, padding bits and CRC bits, as described above.
- the IMD frame is mapped onto the radio packet in chunks of 14 bytes plus 1 SAR bit.
- the start of the IMD frame is indicated by setting the SAR bit of the first radio packet data block to 0 (zero) .
- the subsequent chunks of data (contained in 14 bytes plus 1 SAR bit) are indicated by a 1 (one), i.e. the respective SAR bits of the following data blocks are set to 1 (one) for indicating that the data block is a continuation of the IMD frame.
- the IMD frame contains more information than what can be fitted into a radio packet, then the IMD frame is suitably divided.
- the IMD frame may be divided into several radio packets, which is illustrated in figure 9.
- the IMD frame layer cannot control whether an IMD frame should be carried by one radio packet or not, this is governed by the MICS layer only. That is, the MICS chip or the RF chip, i.e. the radio module of the wand 2 and the IMD 4, transmits data with certain time intervals and whatever data is within the data buffer of the MICS chip at this time is mapped onto a radio packet and transmitted. This means that irrespective of whether or not more data would fit into a radio packet at the time of transmission, the radio packet is transmitted.
- the IMD frame is divided into several radio packets, and the first data block of the first radio packet has a SAR bit 0, the first data block of the second radio packet is a continuation of the IMD frame and has SAR bit 1, the first data block of the third radio packet is also a continuation of the IMD frame and thus has SAR bit 1 and so on.
- the total length of an IMD frame is derived through the ⁇ Data Length> field (described earlier) and the fact that a frame has to be aligned with a 14 bytes data block carried by a radio packet.
- Figure 10a shows an IMD frame that carries a ⁇ Data> field with minimum ⁇ Data Length>, which is 1 byte. A padding of 9 bytes is then needed in order to be aligned with a data block of a radio packet.
- the frame type field, the data length field and the CRC field require in total 4 bytes and the frame ' length is thus 14 bytes, which is equal to one data block.
- the ⁇ Data Length> field is equal to 1 for a minimum size of an IMD Frame, although it's total frame length is 14 bytes.
- the following procedure is used during transmission of an IMD frame at the IMD frame layer.
- a request to transmit a Packet Data is received from an upper layer.
- a frame fragment of 14 bytes is then created, wherein the frame fragment fits into a radio packet data block.
- the frame fragment is assigned a ⁇ Frame Type> field and its value is set to Packet Data.
- the frame fragment is also assigned a ⁇ Data Length> field and the value is egual to the length of the ⁇ Data> field of the Packet Data.
- At least 1 and up to 12 bytes are added from the upper layer data to the frame fragment.
- the current frame fragment is the last fragment, which will be the case when the upper layer requests to send between 1 and 10 bytes, then an appropriate number of zeros (between 0 and 9 bytes) are added for padding. CRC bytes are also added (2 bytes) .
- the frame fragment is sent to the MICS layer by means of a request that sets SAR bit to value "First block".
- a new frame fragment is created (14 bytes) and 1-14 bytes are added from the upper layer data to this frame fragment.
- the frame fragment is sent to the MICS layer by means of a request that sets SAR bit to value "Subsequent block". This is repeated while new frame fragments are needed, i.e. until a last frame fragment is created, then 0-12 bytes are added for padding and also CRC bytes (2 bytes) .
- the steps are as above, except that the request from upper layer is to transmit Stream Data, and the ⁇ Frame Type> is accordingly set to Stream Data. Further, an internal byte counter is copied to a ⁇ Sequence Number> field and the counter is incremented by one for each radio packet transmitted. This counter is initialized to zero when a MICS radio link has been established.
- the following procedure is used during reception of an IMD frame at the IMD frame layer.
- the IMD frame layer receives radio packet data blocks and a SAR bit from the MICS radio layer (see for example figure 2 and 7) .
- the SAR bit indicates the beginning of a new IMD frame and several radio packet data blocks may be assembled to form a complete IMD frame.
- a radio packet data block is received and the SAR bit indicates a "First block”. It is verified that the ⁇ Frame Type> field is valid and that the ⁇ Data Length> field is valid (i.e. a value greater than zero and lesser than 513). If more radio packet data blocks are expected then a new radio packet data block is awaited, and it is verified that the SAR bit indicates "subsequent block" (or equivalently "continued frame”) .
- the frame is concatenated with the previously received frame. Thereafter it is verified that a correct ⁇ CRC> field is received. Finally the payload is extracted from the IMD frame and indicated to the upper layer. If the current frame is a stream data frame then this frame is further conveyed to Receive Stream Data Procedure (described next) .
- This procedure is run only in the RF wand 2 and it is run on top of the receive IMD frame procedure (described earlier) .
- This procedure is started as soon as a radio link has been established between the RF wand 2 and the IMD 4.
- the procedure has two active states: Wait for Synch and Is Synch. A ⁇ Stream Data Frame ⁇ message that is received in Wait for Synch state will be discarded. If a ⁇ Stream Data Frame ⁇ message is received in Is Synch state, the message payload will be extracted and delivered by means of an indication to upper layer. The latter state opens the stream data flow between the IMD 4 and the external monitoring device 2.
- a ⁇ Stream Data Frame ⁇ message carries a ⁇ Sequence Number>, which number is cleared (in the IMD 4) when a MICS radio link has been established.
- the RF wand 2 verifies that the
- ⁇ Sequence Number> incremented properly, i.e. increased by one for every new message.
- Each ⁇ Stream Data Frame ⁇ message is time stamped upon reception by the RF wand 2. This enables the RF wand 2 to measure the time interval between two consecutive ⁇ Stream Data Frame ⁇ messages.
- FIG. 11 illustrates the steps of the method in accordance with the present invention and also summarizes some central aspects of the present invention.
- the method 100 comprises a first step, step 110 of segmenting, at the transmitting end, an IMD frame layer packet into one or more data blocks of one or more radio packets, which data blocks are transmitted in the communication between the wand 2 and the IMD 4.
- a second step, indicated at 120 the start or continuation of the IMD frame layer packet is indicated by including in the first data block of the radio packet a segmentation and reassembly indicator (SAR bit) having a first value.
- SAR bit segmentation and reassembly indicator
- the start of the IMD frame layer packet can be indicated by a single bit and the value can then be a zero ("0") or a one ("1") , as described earlier.
- the data blocks of the radio packet following the first data block are also provided with a segmentation and reassembly indicator. These data blocks are a continuation (fragment) of the IMD frame and are indicated by a value differing from the indicator of the first data block indicating the start of the IMD frame.
- the data blocks are transmitted over radio interface, more specifically a short-range medical radio link, at the transmitting end.
- the data blocks are reassembled at the receiving end, into the originally transmitted IMD frame layer packet .
- cyclic redundancy check (CRC) bits are included, at a transmitting end, in the last data block of the radio packet. If, at a receiving end, a CRC error is detected, then saved data intended for the matching IMD frame layer packet is discarded. If an indication of a transmission error is received from the MICS layer, then any ongoing transmission is discarded, upon which a new transmit request (request to transmit Packet Data or request to transmit Stream Data) is awaited from the upper layer.
- CRC cyclic redundancy check
- data can be discarded in dependence on the type of data that is sent. For example, if stream data is sent, then it may happen that the data is not of any interest after a certain period of time, and therefore discarded if a transmission has failed. Packet data, on the other hand, may be retransmitted until the radio channel is lost.
- the length of the CRC checksum is increased, this will result in fewer bit errors passing unnoticed through the MICS link. That is, the errors can be found at the radio link level and the radio modules may then perform retransmissions, else such retransmissions are made at a higher level, which entails the transmission of larger data packets. Stated differently, when errors are detected, retransmissions handled on the lower layers are less costly in terms of power consumption and time, compared to being handled by the higher layers. There are thus benefits of including more CRC bits. Adding one bit for the
- 112 information bits, 1 SAR bit, and 12 CRC bits amounting to a total of 125 bits, which are then encoded using RS (31, 25).
- CRC-12 x 12 + x 11 + x 3 + x 2 + x 1 + x.
- G(x) x 16 + x 12 + x 5 + 1.
- CRC-32 being yet an example.
- one particular difficulty encountered in medical telemetry systems is the limited size available in the implantable medical device for the electronics required for enabling communication. In the above-described invention, this can be taken into account. More specifically, the available space in the IMD for, for example, needed memory means (e.g. buffer for storing data to be transmitted) has to be considered when determining the amount of data to transmit. Further, if the packet data packets are allowed to be too large, then there will be scheduling issues when a user wishes to transmit streaming data. If the stream data packets are allowed to be too large, then there may be a too large delay before the data received is actually displayed to a physician monitoring for example the heart activity of a patient.
- needed memory means e.g. buffer for storing data to be transmitted
- the invention provides a flexible solution, wherein the different aspects, such as device sizes, delay and so on, can be balanced and taken into account.
- the solution most appropriate for a particular application can then be chosen.
- This frame may contain six samples of Intra cardiac electrogram (IEGM) data and optional markers. The delay before the physician actually sees the data is then still acceptable.
- IEGM Intra cardiac electrogram
- the invention is also related to a medical telemetry system 1 comprising means for performing the above methods.
- the medical telemetry system 1 comprises a transmitting end, e.g. the RF wand 2 or the implantable medical device 4, and a receiving end, again, either the RF wand 2 or the implantable medical device 4.
- the transmitting and receiving sides comprise radio modules (MICS chips) and means for implementing the methods described above.
- the methods may be implemented in hardware and/or software.
Landscapes
- Health & Medical Sciences (AREA)
- Engineering & Computer Science (AREA)
- Life Sciences & Earth Sciences (AREA)
- Heart & Thoracic Surgery (AREA)
- Animal Behavior & Ethology (AREA)
- Veterinary Medicine (AREA)
- Computer Networks & Wireless Communication (AREA)
- Biophysics (AREA)
- Public Health (AREA)
- Biomedical Technology (AREA)
- General Health & Medical Sciences (AREA)
- Pathology (AREA)
- Molecular Biology (AREA)
- Surgery (AREA)
- Medical Informatics (AREA)
- Multimedia (AREA)
- Physics & Mathematics (AREA)
- Signal Processing (AREA)
- Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
- Radiology & Medical Imaging (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
The invention relates to a method in a medical telemetry system for communication between an external monitoring device (3) and an implantable medical device (4) of the medical telemetry system (1). The method comprises the steps of: segmenting, at a transmitting end, an implantable medical device frame layer packet into one or more data blocks of a radio packet, wherein the data blocks are transmitted in the communication between the external monitoring device (3) and the implantable medical device (4); indicating a start of the implantable medical device frame layer packet by including in a first data block of the radio packet a segmentation and reassembly indicator having a first value; transmitting, at the transmitting end, the data blocks over a short-range medical radio link; and reassembling, at a receiving end, the data blocks into the originally transmitted implantable medical device frame layer packet.
Description
Method for segmentation in a medical telemetry system
Field of the invention
The present invention is related to the field of medical telemetry, and in particular to a method for segmentation and reassembly of data transmitted in a medical telemetry system.
Background of the invention
Telemetry is a generic term for techniques for conveying measuring data from one point to another, usually by means of radio or cable connections. Within the medical field, telemetry systems are generally used for enabling radio- frequency (RF) communication between a device worn by a patient, for example an implantable medical device such as a pace maker, and an external monitoring device.
The communication of messages between the implantable medical device and the external monitoring device should be made as efficient and as secure as possible. In medical telemetry applications real-time physiologic data is transmitted. It is therefore most important that as few communication messages as possible are lost or delayed.
However, the nature of air interface means that some bit errors will inevitably be introduced from time to time, and it is important to minimize the effects of lost individual bits or lost frames. One way to alleviate this is to apply error detection and error correction schemes.
If the coinmunication between the implantable medical device and the external monitoring device is deficient, then an excessive number of retransmissions is required, which increases the power consumption of the implantable medical device. Besides the risk of losing real-time physiological
data, the service time of the battery of the IMD is also shortened.
Another aspect of rendering the communication as efficient as possible is to bundle up the data to be transmitted as efficiently as possible. Communication packets are often required to be made smaller to speed them through the network or because of specified packet size restrictions in a given path. A segmentation and reassembly process is a process to accomplish this, that is, to break a communication packet into smaller units before transmission and reassembling them into the proper order at the receiving end of the communication.
In a medical telemetry system complying with the MICS (Medical Implant Communication System) standard the data is transmitted continuously at specified instants of time regardless of the available amount of data at that time. In order for the receiving side to be able to reassemble the originally transmitted data, functionality to this end is needed. This segmentation and reassembly process should be made as efficient as possible.
Further, a design difficulty in medical telemetry systems is the limited size available in an implantable medical device for the electronics required for enabling communication.
Published patent document US 6,128,528 relates to one aspect of the way the communication is to be conducted between devices 'in a medical system. In particular, a method for detecting corrupt implantable medical device data within a data block is disclosed. In accordance with the disclosed invention, an error code is calculated and appended to a block or blocks of implantable medical device data as the implantable medical device data are moved and/or read by a block mover/reader in a block move or read operation within an implantable medical device.
Thus, it is realized that a number of considerations have to be made when designing a medical telemetry system, and in view of this it would be desirable to provide improvements in such a system.
Summary of the invention
It is a general object of the invention to provide improvements in the communication between devices of a medical telemetry system.
It is another object of the invention to provide an improved segmentation and reassembly functionality within a medical telemetry system. In particular, it is an object to provide a method in a medical telemetry system that renders the segmentation and reassembly efficient and secure.
It is another object of the invention to provide a high reliability in data transmission and in system operation.
These objects, among others, are achieved by a method, by an implantable medical device and by an external monitoring device as claimed in the independent claims.
In accordance with the invention, a method in a medical telemetry system is provided for communication between an external monitoring device and an implantable medical device.
The method comprises a first step of segmenting, at a transmitting end, an implantable medical device frame layer packet into one or more data blocks of a radio packet, wherein the data blocks are transmitted in the communication between the external monitoring device and the implantable medical device. In a second step of the method the start of the implantable medical device frame layer packet is indicated by including in a first data block of the radio packet a segmentation and reassembly indicator having a first value.
Thereafter, the data blocks are transmitted, at the
transmitted end, over a short-range medical radio link. Finally, the data blocks are reassembled, at the receiving end into the originally transmitted implantable medical device frame layer packet. By providing such SAR functionality an efficient method for conveying radio packets is provided. The communication between the implantable medical device and the external monitoring device is rendered secure and efficient.
In accordance with another embodiment of the invention, one segmentation and reassembly bit is included for each data block of the radio packet, wherein each data block comprises 14 bytes. This means little overhead and the use of the available data bandwidth is maximized in that as much payload as possible can be conveyed.
In accordance with yet another embodiment of the invention, the method comprises the step of including the segmentation and reassembly indicator in data blocks following the first data block, but now having a second value. The second value indicates that the originally sent implantable medical device frame layer packet is continued in this data block. It is possible to segment the implantable medical device frame layer packet into one or into several radio packet data blocks .
In accordance with still another embodiment of the invention, the method comprises the step of including cyclic redundancy check bits in the radio packet. Increasing the length of the CRC checksum will result in fewer bit errors passing unnoticed through the MICS link. It is possible to detect errors at the radio layer, whereby the power consumption of the implantable medical device can be lowered and its service life prolonged. Further, detecting errors at this lower layer will also be time saving, since retransmissions can be handled at the radio link level.
In accordance with yet another embodiment of the invention, the segmentation and reassembly indicator may comprise a single bit, the indicator then taking the values 1 and 0, respectively for indicating the start or continuation of an implantable medical device frame layer packet. Alternatively, the segmentation and reassembly indicator may comprise two bits, whereby it is possible to indicate the start of an implantable medical device frame layer packet, continuation and end of it. Design flexibility is thereby provided, enabling adapting the method in dependence on specific needs.
The invention is also related to a medical implantable device and a base station comprising means for performing the method, whereby advantages similar to the above are achieved.
Further characteristics of the invention and advantages thereof will be evident from the following description and the accompanying figures. ,
Brief description of the drawings
Figure 1 is a schematic overview of a medical telemetry system in which the present invention may be utilized.
Figure 2 is an overview over frame layer protocols used for communication between devices of a medical telemetry system.
Figure 3 illustrates the implantable medical device layer formats .
Figure 4 illustrates a basic radio packet.
Figure 5 illustrates a data block.
Figure 6 illustrates the byte that conveys the SAR bit.
Figure 7 illustrates a layer-to-layer relationship.
Figure 8 illustrates another layer-to-layer relationship.
Figure 9 illustrates an IMD frame divided into several radio packets .
Figures 10a and 10b, respectively, illustrate the minimum and maximum size of an IMD frame.
Figure 11 is a flowchart over steps included in a method in accordance with the present invention.
Detailed description of embodiments
Figure 1 illustrates schematically a medical telemetry system 1 in which the present invention may be implemented. The medical telemetry system 1 comprises a base station, also denoted wand 2, which typically communicates with an external instrument, such as an external programmer or monitoring device 3 through a wired connection (e.g. a USB connection). The wand 2 and the external monitoring device 3 may be an integrated unit or two separate units. The wand 2 communicates wirelessly with one or more implantable medical device (IMD) 4, such as for example a pace maker or an internal cardiac defibrillator.
In the following description, curled braces, { }, are used for denoting messages that are exchanged between peer entities
(e.g. {Stream Data Frame}), and square brackets, < >, are used for denoting elements (fields) of a frame (e.g. <Sequence
Number>) . Further, a radio packet comprises data blocks and is used for denoting the lowest physical layer providing the means for transmitting raw bits. That is, the physical layer performs services requested by the IMD frame layer.
Figure 2 is an overview over a protocol suite used for the communication between devices of the medical telemetry system
1. In particular, the protocol suites for the IMD 4, for the RF wand 2 (in the MICS standard known as "ultralow power
active medical implant periphery", ULP AMI-P) and for the external monitoring device 3 are shown in the figure.
The present invention is primarily related to and concerned with an IMD frame layer protocol. The IMD frame layer protocol of the protocol suite is run on top of the MICS radio physical layer. The IMD frame layer protocol is used for effectuating the wireless communication between the RF Wand and the implantable medical device. The purpose of the IMD frame layer is to provide services for multiple access points of connectionless message transfer for passing information across the radio link.
Segmentation and reassembly (SAR) refers to the process used to fragment and reassemble data packets so as to allow them to be transported across the desired communication link. A MICS channel can transport 14 bytes of payload, that is, 112 bits of information. If the IMD frame layer protocol uses packets of a larger size, and this will most likely be the case, then the transmitting side, in the following example the wand 2 (which receives the data to be transmitted from the external monitoring device 3), has to divide, i.e. segment, the packets into a stream of smaller packets. That is, the large communication packet (i.e. the IMD frame layer packet) has to be segmented into chunks of 14 bytes, which can be sent over the MICS link. The receiver then has to put together, i.e. reassemble, the received 14 bytes chunks into the originally sent IMD frame layer packet.
Figure 3 illustrates the IMD frame layer format. Frame Type identifies the current IMD frame type. There are several IMD frame types:
Packet Data Frame, carrying e.g data for programming a parameter. A Packet Data Frame conveys Transport Layer messages (the data field of the Packet Data Frame carries the
transport layer messages) . A Packet Data Frame is identified by setting <Frame Type> to 0 (0 0 0 0).
Stream Data Frame, carrying e.g. real-time data or markers (intracardiac electrogram markers). A Stream Data Frame is identified by setting <Frame Type> to 1 (0 0 0 1).
Keep-alive Request; A Keep-alive Request is identified by setting <Frame Type> to 2 (0 0 1 0). This frame is initiated by a Keep Alive Procedure, which is a mechanism intended for detecting a temporary loss of the MICS radio link, i.e. the physical channel, and provides link quality parameters to a Link Quality Assessment Procedure. The Link Quality Assessment Procedure in turn has the purpose to assess the current link quality by means of the parameters in the wand 2 and the IMD 4. The link quality is indicated to upper layer upon a value change.
Keep-alive Reply; A Keep-alive Reply is identified by setting <Frame Type> to 3 (0 0 1 1) . This frame is sent from the IMD in response to a Keep-alive Request and contributes to the above-described Keep Alive Procedure. This message carries, for example, data related to the RF link quality.
Loopback frame; A Loopback frame is identified by setting <Frame Type> to OxF and is used for sending data to the IMD, whereby the IMD just echoes the data back from the frame layer to the host.
The <Data Length> field is the total length of data field, wherein applicable values are, in an exemplary embodiment, from 1 to 512 bytes. In another embodiment however, the IMD frame layer is designed to carry between 1 and 4095 bytes. It is to be noted that the IMD frame layer may be designed to carry even more data. In the illustrated case, the <Data Length> field is defined by 9 bits of the available 12 bits,
but if the <Data Length> field were to be defined by, for example, 12 bits, then a length of 4095 bytes would be the highest number of bytes that can be expressed. In yet other implementations, the IMD frame layer may be designed to carry even further data.
The <Data> field represents different messages as defined above. A message is governed by the content of the <Frame Type> field.
The <Padding> field is used to accommodate an IMD Frame to 14 bytes alignment, which, as mentioned earlier, is required for MICS radio packet data blocks. This field contains undefined octet values and may be of any size between 0 and 12 bytes. The padding field is included in the cyclic redundancy check algorithm. The CRC algorithm is used by the IMD frame layer and is sent in the last data block. The CRC algorithm may for example be a CRC-I6 polynomial. An exemplary polynomial used for the CRC algorithm is G(x) = x16 + x12 + x5 + 1. Other polynomials may be used.
Figure 4 illustrates a basic MICS radio packet, onto which the IMD frames described above are to be mapped. The radio packet may carry up to 31 data blocks, each data block able to convey
113 bits of user data. In particular, each data block conveys a payload of 14 bytes plus one extra bit denoted a SAR
(Segmentation and Reassembly) bit. In the figure a 16 bits training sequence, 40 bits for synchronisation and a header comprising 140 bits are shown as an example.
Figure 5 illustrates a data block of a radio packet more in detail. The data block comprises 14 bytes of payload, i.e. user information, and a SAR bit. Further, a cyclic redundancy check (CRC) comprising for example 12 bits is included, i.e. a conventional checksum computed and appended before transmission, and verified afterwards by the receiving side to
confirm that no changes occurred during transmission. Further still, conventional error correction code comprising for example 30 bits is also included. As an example, Reed-Solomon error correction code could be utilized, e.g. RS(31,25).
The SAR bit could be used to indicate whether user data within a data block is a fragment or not. However, in accordance with the invention, the SAR bit is used to indicate the start of an IMD frame or continuation of the IMD frame. The SAR bit is represented by a byte and could have the value zero (0) or one (1). Figure 6 illustrates the byte that conveys the SAR bit. The SAR bit indicating the start of the IMD frame can have the value zero ("0") or one ("1") . A continued data block is then indicated by the other value. In an alternative embodiment, the segmentation and reassembly indicator comprises two or more bits. The segmentation and reassembly indicator may then have several values, e.g 00, 01, 10, 11. It is thereby possible to indicate the start, the end and even the middle of the IMD frame .
The SAR bit is represented as a byte when it is delivered to/from the MICS layer and a SAR bit is sent for each data block. That is, every 15th byte to/from the MICS layer is a byte that carries the SAR bit. The SAR byte is included in the CRC computation as well as the <Frame Type> field, the <Data Length> field, the <Data> field and the <Padding> field.
Only 1 SAR bit is needed for each data block, that is, just 1 SAR bit per 14 bytes. The SAR functionality of the invention thus adds little overhead data and the available data bandwidth is thereby maximized.
Figure 7 illustrates the relationship of the messages, illustrated from layer to layer starting at Transport Layer
(on the top). The transport layer data (e.g. for maintaining flow control of data and recovery of data between devices) are
mapped onto IMD frame packets, as is illustrated. Transport layer messages are carried by the <Data> field of the IMD frames .
Figure 8 illustrates the relationship of the messages from layer to layer, starting at Stream Data Layer. In this example, <Frame Type> is set to 1 (0 0 0 1), i.e. identifying stream data, the <Data Length> is set to whatever length the <Data> field has (between 1 and 512 bytes) , followed by data, padding bits and CRC bits, as described above. The IMD frame is mapped onto the radio packet in chunks of 14 bytes plus 1 SAR bit. In a preferred embodiment, the start of the IMD frame is indicated by setting the SAR bit of the first radio packet data block to 0 (zero) . The subsequent chunks of data (contained in 14 bytes plus 1 SAR bit) are indicated by a 1 (one), i.e. the respective SAR bits of the following data blocks are set to 1 (one) for indicating that the data block is a continuation of the IMD frame.
If the IMD frame contains more information than what can be fitted into a radio packet, then the IMD frame is suitably divided. The IMD frame may be divided into several radio packets, which is illustrated in figure 9. The IMD frame layer cannot control whether an IMD frame should be carried by one radio packet or not, this is governed by the MICS layer only. That is, the MICS chip or the RF chip, i.e. the radio module of the wand 2 and the IMD 4, transmits data with certain time intervals and whatever data is within the data buffer of the MICS chip at this time is mapped onto a radio packet and transmitted. This means that irrespective of whether or not more data would fit into a radio packet at the time of transmission, the radio packet is transmitted. In the illustrated example, the IMD frame is divided into several radio packets, and the first data block of the first radio packet has a SAR bit 0, the first data block of the second
radio packet is a continuation of the IMD frame and has SAR bit 1, the first data block of the third radio packet is also a continuation of the IMD frame and thus has SAR bit 1 and so on.
The total length of an IMD frame is derived through the <Data Length> field (described earlier) and the fact that a frame has to be aligned with a 14 bytes data block carried by a radio packet. Figure 10a shows an IMD frame that carries a <Data> field with minimum <Data Length>, which is 1 byte. A padding of 9 bytes is then needed in order to be aligned with a data block of a radio packet. The frame type field, the data length field and the CRC field require in total 4 bytes and the frame 'length is thus 14 bytes, which is equal to one data block. It is noted that the <Data Length> field is equal to 1 for a minimum size of an IMD Frame, although it's total frame length is 14 bytes.
Figure 10b shows an IMD frame that carries a <Data> field with maximum <Data Length>, which is, in the illustrated case, 512 bytes. A padding of 2 bytes is needed in order to be aligned with the data blocks. This gives a maximum frame length of 518 bytes, which is equivalent to 37 (= 518/14) radio frame data blocks. It is noted that the <Data Length> field is equal to 512 for a maximum size of an IMD Frame, although its total frame length is 518 bytes.
Procedure during transmission of IMP Frame
The following procedure is used during transmission of an IMD frame at the IMD frame layer.
In the typical case, a request to transmit a Packet Data is received from an upper layer. A frame fragment of 14 bytes is then created, wherein the frame fragment fits into a radio packet data block. The frame fragment is assigned a <Frame
Type> field and its value is set to Packet Data. The frame fragment is also assigned a <Data Length> field and the value is egual to the length of the <Data> field of the Packet Data.
At least 1 and up to 12 bytes are added from the upper layer data to the frame fragment.
If the current frame fragment is the last fragment, which will be the case when the upper layer requests to send between 1 and 10 bytes, then an appropriate number of zeros (between 0 and 9 bytes) are added for padding. CRC bytes are also added (2 bytes) . The frame fragment is sent to the MICS layer by means of a request that sets SAR bit to value "First block".
If the current frame fragment is not the last fragment then a new frame fragment is created (14 bytes) and 1-14 bytes are added from the upper layer data to this frame fragment.. The frame fragment is sent to the MICS layer by means of a request that sets SAR bit to value "Subsequent block". This is repeated while new frame fragments are needed, i.e. until a last frame fragment is created, then 0-12 bytes are added for padding and also CRC bytes (2 bytes) .
In a request at the IMD side, the steps are as above, except that the request from upper layer is to transmit Stream Data, and the <Frame Type> is accordingly set to Stream Data. Further, an internal byte counter is copied to a <Sequence Number> field and the counter is incremented by one for each radio packet transmitted. This counter is initialized to zero when a MICS radio link has been established.
Procedure during reception of IMP Frame
The following procedure is used during reception of an IMD frame at the IMD frame layer.
The IMD frame layer receives radio packet data blocks and a SAR bit from the MICS radio layer (see for example figure 2
and 7) . As described, the SAR bit indicates the beginning of a new IMD frame and several radio packet data blocks may be assembled to form a complete IMD frame. In the typical case, a radio packet data block is received and the SAR bit indicates a "First block". It is verified that the <Frame Type> field is valid and that the <Data Length> field is valid (i.e. a value greater than zero and lesser than 513). If more radio packet data blocks are expected then a new radio packet data block is awaited, and it is verified that the SAR bit indicates "subsequent block" (or equivalently "continued frame") . The frame is concatenated with the previously received frame. Thereafter it is verified that a correct <CRC> field is received. Finally the payload is extracted from the IMD frame and indicated to the upper layer. If the current frame is a stream data frame then this frame is further conveyed to Receive Stream Data Procedure (described next) .
Receive Stream Data Procedure
This procedure is run only in the RF wand 2 and it is run on top of the receive IMD frame procedure (described earlier) . This procedure is started as soon as a radio link has been established between the RF wand 2 and the IMD 4. The procedure has two active states: Wait for Synch and Is Synch. A {Stream Data Frame} message that is received in Wait for Synch state will be discarded. If a {Stream Data Frame} message is received in Is Synch state, the message payload will be extracted and delivered by means of an indication to upper layer. The latter state opens the stream data flow between the IMD 4 and the external monitoring device 2.
A {Stream Data Frame} message carries a <Sequence Number>, which number is cleared (in the IMD 4) when a MICS radio link has been established. The RF wand 2 verifies that the
<Sequence Number> incremented properly, i.e. increased by one
for every new message. Each {Stream Data Frame} message is time stamped upon reception by the RF wand 2. This enables the RF wand 2 to measure the time interval between two consecutive {Stream Data Frame} messages.
Figure 11 illustrates the steps of the method in accordance with the present invention and also summarizes some central aspects of the present invention. The method 100 comprises a first step, step 110 of segmenting, at the transmitting end, an IMD frame layer packet into one or more data blocks of one or more radio packets, which data blocks are transmitted in the communication between the wand 2 and the IMD 4. In a second step, indicated at 120, the start or continuation of the IMD frame layer packet is indicated by including in the first data block of the radio packet a segmentation and reassembly indicator (SAR bit) having a first value. The start of the IMD frame layer packet can be indicated by a single bit and the value can then be a zero ("0") or a one ("1") , as described earlier. As also described earlier, if the IMD frame layer packet comprises more data than what can be fitted in one radio packet, and this will typically be the case, then the data blocks of the radio packet following the first data block are also provided with a segmentation and reassembly indicator. These data blocks are a continuation (fragment) of the IMD frame and are indicated by a value differing from the indicator of the first data block indicating the start of the IMD frame. In a third step, indicated at 130, the data blocks are transmitted over radio interface, more specifically a short-range medical radio link, at the transmitting end. Finally, in step 140, the data blocks are reassembled at the receiving end, into the originally transmitted IMD frame layer packet .
In another, optional step of the method, cyclic redundancy check (CRC) bits are included, at a transmitting end, in the
last data block of the radio packet. If, at a receiving end, a CRC error is detected, then saved data intended for the matching IMD frame layer packet is discarded. If an indication of a transmission error is received from the MICS layer, then any ongoing transmission is discarded, upon which a new transmit request (request to transmit Packet Data or request to transmit Stream Data) is awaited from the upper layer.
It is to be noted that data can be discarded in dependence on the type of data that is sent. For example, if stream data is sent, then it may happen that the data is not of any interest after a certain period of time, and therefore discarded if a transmission has failed. Packet data, on the other hand, may be retransmitted until the radio channel is lost.
If the length of the CRC checksum is increased, this will result in fewer bit errors passing unnoticed through the MICS link. That is, the errors can be found at the radio link level and the radio modules may then perform retransmissions, else such retransmissions are made at a higher level, which entails the transmission of larger data packets. Stated differently, when errors are detected, retransmissions handled on the lower layers are less costly in terms of power consumption and time, compared to being handled by the higher layers. There are thus benefits of including more CRC bits. Adding one bit for the
SAR functionality can be combined with an increase of the CRC checksum length, which would result in a data block comprising
112 information bits, 1 SAR bit, and 12 CRC bits amounting to a total of 125 bits, which are then encoded using RS (31, 25).
On the radio link layer (MICS chip) a CRC-12 algorithm can be utilized on each data block provided by the MICS chip, having the following polynomial: CRC-12 = x12 + x11 + x3 + x2 + x1 + x. In the IMD frame layer any CRC algorithm may be implemented, for example the CRC-16 algorithm, that is, the earlier
mentioned polynomial G(x) = x16 + x12 + x5 + 1. Yet other polynomials may be used in alternative embodiments, CRC-32 being yet an example.
As mentioned in the introductory part, one particular difficulty encountered in medical telemetry systems is the limited size available in the implantable medical device for the electronics required for enabling communication. In the above-described invention, this can be taken into account. More specifically, the available space in the IMD for, for example, needed memory means (e.g. buffer for storing data to be transmitted) has to be considered when determining the amount of data to transmit. Further, if the packet data packets are allowed to be too large, then there will be scheduling issues when a user wishes to transmit streaming data. If the stream data packets are allowed to be too large, then there may be a too large delay before the data received is actually displayed to a physician monitoring for example the heart activity of a patient. The invention provides a flexible solution, wherein the different aspects, such as device sizes, delay and so on, can be balanced and taken into account. The solution most appropriate for a particular application can then be chosen. For example, an exemplary size of stream data frame size is 5 radio data blocks, which equals 5 x 14 = 70 bytes. This frame may contain six samples of Intra cardiac electrogram (IEGM) data and optional markers. The delay before the physician actually sees the data is then still acceptable.
The invention is also related to a medical telemetry system 1 comprising means for performing the above methods. In particular, the medical telemetry system 1 comprises a transmitting end, e.g. the RF wand 2 or the implantable medical device 4, and a receiving end, again, either the RF wand 2 or the implantable medical device 4. The transmitting
and receiving sides comprise radio modules (MICS chips) and means for implementing the methods described above. The methods may be implemented in hardware and/or software.
While the present invention has been described in various embodiments it shall be appreciated that the invention is not limited to the specific features and details set forth, but is defined only by the appended patent claims.
Claims
1. A method in a medical telemetry system for communication between an external monitoring device (3) and an implantable medical device (4) of said medical telemetry system (1), said method being characterized by the steps of:
segmenting (110), at a transmitting end, an implantable medical device frame layer packet into one or more data blocks of a radio packet, said data blocks being transmitted in the communication between said external monitoring device (3) and said implantable medical device (4),
- indicating (120) a start of said implantable medical device frame layer packet by including in a first data block a segmentation and reassembly indicator having a first value,
- transmitting (130), at said transmitting end, said radio packet data blocks over a short-range medical radio link, and
- reassembling (140), at a receiving end, said data blocks into the originally transmitted implantable medical device frame layer packet.
2. Method as claimed in claim 1, further comprising the step of including in data blocks following said first data block said segmentation and reassembly indicator having a second value for indicating a continuation of said implantable medical device frame layer packet.
3. Method as claimed in claim 1 or 2, wherein one segmentation and reassembly bit is included for each data block of said radio packet, each data block comprising 14 bytes.
4. Method as claimed in any of claims 1-3, further comprising the step of including cyclic redundancy check bits in said radio packet.
5. The method as claimed in any of claims 1-5, wherein said segmentation and reassembly indicator comprises a single bit.
6. The method as claimed in claim 5, wherein said first value is one of 1 and 0, and said second value is the other of 1 or 0.
7. The method as claimed in any of claims 1-4, wherein said segmentation and reassembly indicator comprises two bits.
8. The method as claimed in claim 7, wherein said segmentation and reassembly indicator comprises values for indicating the start of an implantable medical device frame layer packet, continued implantable medical device frame layer packet and end of implantable medical device frame layer packet.
9. A medical implantable device (4) characterized by means for performing a method as claimed in any of claims 1-8.
10. A medical monitoring device (3) characterized by means for performing a method as claimed in any of claims 1-8.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/SE2007/000083 WO2008094080A1 (en) | 2007-01-31 | 2007-01-31 | Method for segmentation in a medical telemetry system |
| US12/522,022 US20100013668A1 (en) | 2007-01-31 | 2007-01-31 | Method in a medical telemetry system and medical telemetry system |
| EP07709299.7A EP2115922B1 (en) | 2007-01-31 | 2007-01-31 | Method for segmentation in a medical telemetry system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/SE2007/000083 WO2008094080A1 (en) | 2007-01-31 | 2007-01-31 | Method for segmentation in a medical telemetry system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2008094080A1 true WO2008094080A1 (en) | 2008-08-07 |
Family
ID=39674293
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/SE2007/000083 Ceased WO2008094080A1 (en) | 2007-01-31 | 2007-01-31 | Method for segmentation in a medical telemetry system |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20100013668A1 (en) |
| EP (1) | EP2115922B1 (en) |
| WO (1) | WO2008094080A1 (en) |
Families Citing this family (90)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8458149B2 (en) * | 2010-03-29 | 2013-06-04 | Welch Allyn, Inc. | Small footprint medical information transfer protocol stack |
| KR101208894B1 (en) * | 2010-05-24 | 2012-12-06 | 주식회사 엠아이텍 | Apparatus and method for transmitting and receiving for the body implantable medical devices |
| US9098610B2 (en) * | 2011-12-22 | 2015-08-04 | Greatbatch Ltd. | Communication for implantable medical devices |
| US9592391B2 (en) | 2014-01-10 | 2017-03-14 | Cardiac Pacemakers, Inc. | Systems and methods for detecting cardiac arrhythmias |
| JP2017501839A (en) | 2014-01-10 | 2017-01-19 | カーディアック ペースメイカーズ, インコーポレイテッド | Method and system for superior communication between medical devices |
| US20150349919A1 (en) * | 2014-05-29 | 2015-12-03 | Nordic Semiconductor Asa | Radio data packets |
| WO2016033087A1 (en) | 2014-08-28 | 2016-03-03 | Cardiac Pacemakers, Inc. | Display of temporally aligned heart information from separate implantable medical devices on an extracorporeal display |
| US9526909B2 (en) | 2014-08-28 | 2016-12-27 | Cardiac Pacemakers, Inc. | Medical device with triggered blanking period |
| ES2713231T3 (en) | 2015-02-06 | 2019-05-20 | Cardiac Pacemakers Inc | Systems for the safe supply of electrical stimulation therapy |
| EP3827877B1 (en) | 2015-02-06 | 2024-06-19 | Cardiac Pacemakers, Inc. | Systems for treating cardiac arrhythmias |
| WO2016130477A2 (en) | 2015-02-09 | 2016-08-18 | Cardiac Pacemakers, Inc. | Implantable medical device with radiopaque id tag |
| US11285326B2 (en) | 2015-03-04 | 2022-03-29 | Cardiac Pacemakers, Inc. | Systems and methods for treating cardiac arrhythmias |
| US10050700B2 (en) | 2015-03-18 | 2018-08-14 | Cardiac Pacemakers, Inc. | Communications in a medical device system with temporal optimization |
| WO2016149262A1 (en) | 2015-03-18 | 2016-09-22 | Cardiac Pacemakers, Inc. | Communications in a medical device system with link quality assessment |
| WO2017031221A1 (en) | 2015-08-20 | 2017-02-23 | Cardiac Pacemakers, Inc. | Systems and methods for communication between medical devices |
| WO2017031347A1 (en) | 2015-08-20 | 2017-02-23 | Cardiac Pacemakers, Inc. | Systems and methods for communication between medical devices |
| US9968787B2 (en) | 2015-08-27 | 2018-05-15 | Cardiac Pacemakers, Inc. | Spatial configuration of a motion sensor in an implantable medical device |
| US9956414B2 (en) | 2015-08-27 | 2018-05-01 | Cardiac Pacemakers, Inc. | Temporal configuration of a motion sensor in an implantable medical device |
| EP3341076B1 (en) | 2015-08-28 | 2022-05-11 | Cardiac Pacemakers, Inc. | Systems and methods for behaviorally responsive signal detection and therapy delivery |
| WO2017040115A1 (en) | 2015-08-28 | 2017-03-09 | Cardiac Pacemakers, Inc. | System for detecting tamponade |
| US10226631B2 (en) | 2015-08-28 | 2019-03-12 | Cardiac Pacemakers, Inc. | Systems and methods for infarct detection |
| US10092760B2 (en) | 2015-09-11 | 2018-10-09 | Cardiac Pacemakers, Inc. | Arrhythmia detection and confirmation |
| CN108136185B (en) | 2015-10-08 | 2021-08-31 | 心脏起搏器股份公司 | Apparatus and method for adjusting pacing rate in an implantable medical device |
| EP3389775B1 (en) | 2015-12-17 | 2019-09-25 | Cardiac Pacemakers, Inc. | Conducted communication in a medical device system |
| US10905886B2 (en) | 2015-12-28 | 2021-02-02 | Cardiac Pacemakers, Inc. | Implantable medical device for deployment across the atrioventricular septum |
| US10583303B2 (en) | 2016-01-19 | 2020-03-10 | Cardiac Pacemakers, Inc. | Devices and methods for wirelessly recharging a rechargeable battery of an implantable medical device |
| CN109069840B (en) | 2016-02-04 | 2022-03-15 | 心脏起搏器股份公司 | Delivery system with force sensor for leadless cardiac devices |
| US11116988B2 (en) | 2016-03-31 | 2021-09-14 | Cardiac Pacemakers, Inc. | Implantable medical device with rechargeable battery |
| US10668294B2 (en) | 2016-05-10 | 2020-06-02 | Cardiac Pacemakers, Inc. | Leadless cardiac pacemaker configured for over the wire delivery |
| US10328272B2 (en) | 2016-05-10 | 2019-06-25 | Cardiac Pacemakers, Inc. | Retrievability for implantable medical devices |
| JP6764956B2 (en) | 2016-06-27 | 2020-10-07 | カーディアック ペースメイカーズ, インコーポレイテッド | Cardiac therapy system that uses subcutaneously sensed P-waves for resynchronization pacing management |
| WO2018009569A1 (en) | 2016-07-06 | 2018-01-11 | Cardiac Pacemakers, Inc. | Method and system for determining an atrial contraction timing fiducial in a leadless cardiac pacemaker system |
| WO2018009392A1 (en) | 2016-07-07 | 2018-01-11 | Cardiac Pacemakers, Inc. | Leadless pacemaker using pressure measurements for pacing capture verification |
| US10688304B2 (en) | 2016-07-20 | 2020-06-23 | Cardiac Pacemakers, Inc. | Method and system for utilizing an atrial contraction timing fiducial in a leadless cardiac pacemaker system |
| WO2018035343A1 (en) | 2016-08-19 | 2018-02-22 | Cardiac Pacemakers, Inc. | Trans septal implantable medical device |
| US10870008B2 (en) | 2016-08-24 | 2020-12-22 | Cardiac Pacemakers, Inc. | Cardiac resynchronization using fusion promotion for timing management |
| EP3503799B1 (en) | 2016-08-24 | 2021-06-30 | Cardiac Pacemakers, Inc. | Integrated multi-device cardiac resynchronization therapy using p-wave to pace timing |
| US10758737B2 (en) | 2016-09-21 | 2020-09-01 | Cardiac Pacemakers, Inc. | Using sensor data from an intracardially implanted medical device to influence operation of an extracardially implantable cardioverter |
| WO2018057626A1 (en) | 2016-09-21 | 2018-03-29 | Cardiac Pacemakers, Inc. | Implantable cardiac monitor |
| EP3515553B1 (en) | 2016-09-21 | 2020-08-26 | Cardiac Pacemakers, Inc. | Leadless stimulation device with a housing that houses internal components of the leadless stimulation device and functions as the battery case and a terminal of an internal battery |
| US10561330B2 (en) | 2016-10-27 | 2020-02-18 | Cardiac Pacemakers, Inc. | Implantable medical device having a sense channel with performance adjustment |
| EP3532159B1 (en) | 2016-10-27 | 2021-12-22 | Cardiac Pacemakers, Inc. | Implantable medical device delivery system with integrated sensor |
| EP3532160B1 (en) | 2016-10-27 | 2023-01-25 | Cardiac Pacemakers, Inc. | Separate device in managing the pace pulse energy of a cardiac pacemaker |
| US10463305B2 (en) | 2016-10-27 | 2019-11-05 | Cardiac Pacemakers, Inc. | Multi-device cardiac resynchronization therapy with timing enhancements |
| CN109890458B (en) | 2016-10-27 | 2023-08-11 | 心脏起搏器股份公司 | Implantable medical device with pressure sensor |
| US10413733B2 (en) | 2016-10-27 | 2019-09-17 | Cardiac Pacemakers, Inc. | Implantable medical device with gyroscope |
| US10434317B2 (en) | 2016-10-31 | 2019-10-08 | Cardiac Pacemakers, Inc. | Systems and methods for activity level pacing |
| EP3532157B1 (en) | 2016-10-31 | 2020-08-26 | Cardiac Pacemakers, Inc. | Systems for activity level pacing |
| WO2018089311A1 (en) | 2016-11-08 | 2018-05-17 | Cardiac Pacemakers, Inc | Implantable medical device for atrial deployment |
| US10632313B2 (en) | 2016-11-09 | 2020-04-28 | Cardiac Pacemakers, Inc. | Systems, devices, and methods for setting cardiac pacing pulse parameters for a cardiac pacing device |
| JP6781346B2 (en) | 2016-11-21 | 2020-11-04 | カーディアック ペースメイカーズ, インコーポレイテッド | Leadless cardiac pacemaker with multi-mode communication |
| US10881869B2 (en) | 2016-11-21 | 2021-01-05 | Cardiac Pacemakers, Inc. | Wireless re-charge of an implantable medical device |
| WO2018093605A1 (en) | 2016-11-21 | 2018-05-24 | Cardiac Pacemakers, Inc. | Leadless cardiac pacemaker providing cardiac resynchronization therapy |
| US11147979B2 (en) | 2016-11-21 | 2021-10-19 | Cardiac Pacemakers, Inc. | Implantable medical device with a magnetically permeable housing and an inductive coil disposed about the housing |
| US10639486B2 (en) | 2016-11-21 | 2020-05-05 | Cardiac Pacemakers, Inc. | Implantable medical device with recharge coil |
| US11207532B2 (en) | 2017-01-04 | 2021-12-28 | Cardiac Pacemakers, Inc. | Dynamic sensing updates using postural input in a multiple device cardiac rhythm management system |
| WO2018140623A1 (en) | 2017-01-26 | 2018-08-02 | Cardiac Pacemakers, Inc. | Leadless device with overmolded components |
| CN110198759B (en) | 2017-01-26 | 2023-08-11 | 心脏起搏器股份公司 | Leadless implantable device with removable fasteners |
| CN110225778B (en) | 2017-01-26 | 2023-06-13 | 心脏起搏器股份公司 | In vivo device communication with redundant message transmission |
| US10905872B2 (en) | 2017-04-03 | 2021-02-02 | Cardiac Pacemakers, Inc. | Implantable medical device with a movable electrode biased toward an extended position |
| CN110740779B (en) | 2017-04-03 | 2024-03-08 | 心脏起搏器股份公司 | Cardiac pacemaker with pacing pulse energy regulation based on sensed heart rate |
| WO2019036568A1 (en) | 2017-08-18 | 2019-02-21 | Cardiac Pacemakers, Inc. | Implantable medical device with a flux concentrator and a receiving coil disposed about the flux concentrator |
| EP3668592B1 (en) | 2017-08-18 | 2021-11-17 | Cardiac Pacemakers, Inc. | Implantable medical device with pressure sensor |
| JP2019041182A (en) * | 2017-08-23 | 2019-03-14 | 株式会社東芝 | Radio communication equipment and radio communication method |
| JP7318033B2 (en) * | 2017-08-23 | 2023-07-31 | 株式会社東芝 | Wireless communication device and wireless communication method |
| EP3684465B1 (en) | 2017-09-20 | 2021-07-14 | Cardiac Pacemakers, Inc. | Implantable medical device with multiple modes of operation |
| US11185703B2 (en) | 2017-11-07 | 2021-11-30 | Cardiac Pacemakers, Inc. | Leadless cardiac pacemaker for bundle of his pacing |
| US11813463B2 (en) | 2017-12-01 | 2023-11-14 | Cardiac Pacemakers, Inc. | Leadless cardiac pacemaker with reversionary behavior |
| CN111417433B (en) | 2017-12-01 | 2024-04-30 | 心脏起搏器股份公司 | Method and system for detecting atrial contraction timing reference during ventricular filling from a ventricularly implanted leadless cardiac pacemaker |
| CN111432875B (en) | 2017-12-01 | 2024-04-30 | 心脏起搏器股份公司 | Method and system for detecting atrial contraction timing reference and determining cardiac intervals from a ventricular implantable leadless cardiac pacemaker |
| US11052258B2 (en) | 2017-12-01 | 2021-07-06 | Cardiac Pacemakers, Inc. | Methods and systems for detecting atrial contraction timing fiducials within a search window from a ventricularly implanted leadless cardiac pacemaker |
| EP3735293B1 (en) | 2018-01-04 | 2022-03-09 | Cardiac Pacemakers, Inc. | Dual chamber pacing without beat-to-beat communication |
| US11529523B2 (en) | 2018-01-04 | 2022-12-20 | Cardiac Pacemakers, Inc. | Handheld bridge device for providing a communication bridge between an implanted medical device and a smartphone |
| WO2019183514A1 (en) | 2018-03-23 | 2019-09-26 | Medtronic, Inc. | Vfa cardiac therapy for tachycardia |
| EP3768369A1 (en) | 2018-03-23 | 2021-01-27 | Medtronic, Inc. | Av synchronous vfa cardiac therapy |
| CN111902187B (en) | 2018-03-23 | 2025-05-16 | 美敦力公司 | Cardiac resynchronization therapy with VFA |
| JP2022501085A (en) | 2018-09-26 | 2022-01-06 | メドトロニック,インコーポレイテッド | Capturing in ventricular cardiac therapy from the atria |
| US11951313B2 (en) | 2018-11-17 | 2024-04-09 | Medtronic, Inc. | VFA delivery systems and methods |
| EP3897816B1 (en) | 2018-12-21 | 2024-03-27 | Medtronic, Inc. | Delivery systems for left ventricular pacing |
| US11679265B2 (en) | 2019-02-14 | 2023-06-20 | Medtronic, Inc. | Lead-in-lead systems and methods for cardiac therapy |
| US11697025B2 (en) | 2019-03-29 | 2023-07-11 | Medtronic, Inc. | Cardiac conduction system capture |
| US11213676B2 (en) | 2019-04-01 | 2022-01-04 | Medtronic, Inc. | Delivery systems for VfA cardiac therapy |
| US11712188B2 (en) | 2019-05-07 | 2023-08-01 | Medtronic, Inc. | Posterior left bundle branch engagement |
| US11305127B2 (en) | 2019-08-26 | 2022-04-19 | Medtronic Inc. | VfA delivery and implant region detection |
| US11813466B2 (en) | 2020-01-27 | 2023-11-14 | Medtronic, Inc. | Atrioventricular nodal stimulation |
| US12543992B2 (en) | 2020-03-30 | 2026-02-10 | Medtronic, Inc. | Pacing efficacy determination using a representative morphology of external cardiac signals |
| US11911168B2 (en) | 2020-04-03 | 2024-02-27 | Medtronic, Inc. | Cardiac conduction system therapy benefit determination |
| US12605103B2 (en) | 2020-05-21 | 2026-04-21 | Medtronic, Inc. | QRS detection and bracketing |
| US11813464B2 (en) | 2020-07-31 | 2023-11-14 | Medtronic, Inc. | Cardiac conduction system evaluation |
| US12465770B2 (en) | 2020-07-31 | 2025-11-11 | Medtronic, Inc. | Coronary sinus conduction system pacing and delivery |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040042440A1 (en) * | 2002-08-30 | 2004-03-04 | Mcgowan Steven B. | Supporting disparate packet based wireless communications |
| US20040088027A1 (en) | 2002-10-31 | 2004-05-06 | Burnes John E. | Aggregation of data from external data sources within an implantable medical device |
| US20050111416A1 (en) * | 2003-11-24 | 2005-05-26 | Boris Ginzburg | Method, system and device of fragmentation with group acknowledgement in wireless networks |
| WO2006107244A1 (en) * | 2005-04-07 | 2006-10-12 | St. Jude Medical Ab | System and method for radio communication between an implantable medical device and an external base unit |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5404374A (en) * | 1993-07-12 | 1995-04-04 | Apple Computer, Inc. | Method and apparatus for transmitting and receiving encoded data using multiple frequency coding |
| US6128528A (en) * | 1999-03-18 | 2000-10-03 | Medtronics, Inc. | Error code calculations for data stored in an implantable medical device |
| US6993393B2 (en) * | 2001-12-19 | 2006-01-31 | Cardiac Pacemakers, Inc. | Telemetry duty cycle management system for an implantable medical device |
-
2007
- 2007-01-31 US US12/522,022 patent/US20100013668A1/en not_active Abandoned
- 2007-01-31 EP EP07709299.7A patent/EP2115922B1/en not_active Not-in-force
- 2007-01-31 WO PCT/SE2007/000083 patent/WO2008094080A1/en not_active Ceased
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040042440A1 (en) * | 2002-08-30 | 2004-03-04 | Mcgowan Steven B. | Supporting disparate packet based wireless communications |
| US20040088027A1 (en) | 2002-10-31 | 2004-05-06 | Burnes John E. | Aggregation of data from external data sources within an implantable medical device |
| US20050111416A1 (en) * | 2003-11-24 | 2005-05-26 | Boris Ginzburg | Method, system and device of fragmentation with group acknowledgement in wireless networks |
| WO2006107244A1 (en) * | 2005-04-07 | 2006-10-12 | St. Jude Medical Ab | System and method for radio communication between an implantable medical device and an external base unit |
Non-Patent Citations (2)
| Title |
|---|
| "Data Integrity in 802.16.4 MAC", IEEE 802.16 BROADBAND WIRELESS ACCESS WORKING GROUP; IEEE 802.16.4-01/06, 13 January 2001 (2001-01-13), XP003018647, Retrieved from the Internet <URL:http://www.ieee802.org/16/tg4/contrib/802164c-01_06.pdf> * |
| See also references of EP2115922A4 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP2115922B1 (en) | 2014-10-15 |
| EP2115922A1 (en) | 2009-11-11 |
| US20100013668A1 (en) | 2010-01-21 |
| EP2115922A4 (en) | 2010-06-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2115922B1 (en) | Method for segmentation in a medical telemetry system | |
| CN109905925B (en) | The communication means of wireless device component and wireless device component | |
| US7519430B2 (en) | Dynamic telemetry encoding for an implantable medical device | |
| JP3897822B2 (en) | Apparatus and method for transmitting IP data through a satellite network | |
| US20230239076A1 (en) | Method and device for BLE audio data transmission | |
| JP4754638B2 (en) | Communication device | |
| KR101705768B1 (en) | Apparatus and method for operating duplication harq in mobile communication system | |
| WO2012109602A1 (en) | Forward error correction scheduling for an improved radio link protocol | |
| US20070263708A1 (en) | Receiver Controlled Isochronous Transmission | |
| WO2012109597A1 (en) | Framing for an improved radio link protocol including fec | |
| KR20000050784A (en) | Data communication apparatus and method in cdma communication system | |
| KR20040023568A (en) | Forward error correction system and method for packet based communication systems | |
| WO2017072100A1 (en) | Reliable communication algorithm for wireless medical devices and sensors within monitoring systems | |
| CN1157019C (en) | Method and system for data reception acknowledgement | |
| US7519084B2 (en) | Error control mechanism for a segment based link layer in a digital network | |
| US7440805B2 (en) | Implantable pulse generator system and method for utilizing communication protocols | |
| US20120170564A1 (en) | Frame formation method having improved communication efficiency in wireless communication network for in-body medical device | |
| US20040034826A1 (en) | Transport protocol checksum recalculation | |
| US20240297677A1 (en) | Implantable medical device and method for managing a physical layer utilized during a wireless connection | |
| CN119011701A (en) | Data transmission method based on improved USART protocol | |
| US20120195327A1 (en) | Frame formation method in wireless communication network for medical prosthetic device | |
| CN108134652B (en) | Method and system for reducing data loss of PH capsule wireless detection system | |
| US20250375122A1 (en) | Method and system for managing medical device wireless data transmission with packet functional incorporation | |
| KR101121585B1 (en) | Frame data forming method in wireless communication for implant medical device | |
| KR20100065460A (en) | Apparatus and method for controlling data transmission depending on reassembl status in a mobile communication system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 07709299 Country of ref document: EP Kind code of ref document: A1 |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 12522022 Country of ref document: US |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 2007709299 Country of ref document: EP |