Automatic data transmission rate adjustment

A method for connecting to a remote unit via a communications medium, determining a data transfer rate of the connection, setting a sampling rate between the remote unit and an implantable medical device at least in part as a function of the determined data transfer rate and receiving real time data from the remote unit via said communications medium.

FIELD OF THE INVENTION

The present invention relates generally to implantable medical devices (IMDs) and more specifically to remote monitoring of patients fitted with an IMD.

BACKGROUND ART

Telemetry is a technology which allows the remote measurement and reporting of information of interest to a user. Telemetry typically refers to wireless communications (i.e. using a radiofrequency system to implement the data link) but can also refer to data transfer over other media, such as a telephone or computer network or via an optical link. Systems which need instructions and data sent to them in order to operate may also require telecommand which is the counterpart of telemetry.

Telemetry is an enabling technology for large complex systems such as spacecraft boosters, oil rigs and chemical plants because it allows automatic monitoring, alerting, and record-keeping necessary for safe, efficient operations. Space agencies such as NASA, ESA, and other agencies use telemetry and telecommand systems to operate spacecraft and satellites. As in other telecommunications fields, international standards exist for telemetry equipment and software. The European Space Agency (ESA) has defined one such standard. In wildlife study and management, telemetry is used to follow members of endangered species. Such animals are now commonly equipped with instrumentation ranging from simple tags to cameras, GPS packages and transceivers to provide position and other information to the scientists, producers, activists, regulators, or other human agencies.

Telemetry is also used for patients who are at risk of abnormal heart activity. Such patients are outfitted with measuring, recording and transmitting devices. A data log can be useful in diagnosis of the patient's condition by doctors. An alerting function can summon nurses if the patient is suffering from an acute or dangerous condition. Telemetry has a wide range of applications for all implantable medical devices (IMDs) and is particularly useful for implantable cardioverter defibrillators (ICDs). ICDs are considered to be a subset of IMDs.

Once an IMD is implanted, it is important that the patient be monitored periodically by a clinic, physician or a commercial group that specializes in IMD follow-up. Some physicians will prefer that the patient be examined in the office on a regular basis to have the IMD checked. Others will arrange an IMD check to be done via transtelephonic monitoring, with periodic visits in the office or clinic. In many offices, the IMD check will be performed by a nurse or technician who is specially trained in management of pacemakers.

IMDs are usually checked with a special device called a wand. A portion of the wand is simply held over the pacemaker and is able to communicate with the pacemaker. It can obtain information about the function of the pacemaker. It can also change certain functions of the pacemaker to whatever the doctor, nurse, or technician feels is most appropriate. A specialized magnet may also be used during the pacemaker evaluation. If transtelephonic monitoring is part of the follow-up, a wand or specialized magnet will probably be given to the patient to use during the telephone evaluations.

However, on initial connection between the system at the patient's end and the system at the clinician's end, communication impairments can cause low baud rate conditions which prevents the execution of the remote patient follow up session. Under these conditions, the available bandwidth cannot support the amount of data coming from the remote patient. Furthermore, low baud rate conditions may prevent the transmission of real time data.

It can also become quite difficult and in some cases even unfeasible to upgrade the firmware on a transmitter used to remotely transfer patient diagnostic data to a receiver at the physician end. This is because the transmitter has to be either brought in-house or a technician will have to go to the patient with the necessary equipment required to perform the upgrade. These upgrades could be for incorporating feature enhancements or even fixes for potential problems in the transmitter. Delays in upgrading could result in patients not getting access to valuable or critical upgrades on time.

Yet another problem is the physical receiver unit on the physician side used to remotely receive patient diagnostic data. The use of a physical receiver unit limits the ability of the physician to conduct the remote follow-up session to locations where such a receiver is available. Thus in the event the physician is not proximate to a physical receiver unit, a follow-up session with a patient will not be possible.

What is needed is a method to optimize remote patient follow up sessions during low baud rate conditions.

BRIEF SUMMARY OF THE INVENTION

The invention comprises a method to connect to a remote unit via a communications medium, determine a data transfer rate of the connection, set a sampling rate between the remote unit and an implantable medical device at least in part as a function of the determined data transfer rate and receive real time data from the remote unit via the communications medium.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed. The detailed description is not intended to limit the scope of the claimed invention in any way.

The present invention will now be described with reference to the accompanying drawings. In the drawings, like reference numbers may indicate identical or functionally similar elements. Additionally, the left-most digit(s) of a reference number may identify the drawing in which the reference number first appears.

DETAILED DESCRIPTION OF THE INVENTION

An IMD is a device that is implanted under the skin of a patient and may be used to obtain patient diagnostic data. An ICD is an IMD that is implanted proximate the heart and under the skin of patients that are at risk of sudden death due to ventricular fibrillation. ICDs typically provide defibrillation if the heart enters a potentially lethal rhythm. The process of implantation of an ICD is similar to implantation of a pacemaker. Similar to pacemakers, these devices typically include a wire that runs through the right chambers of the heart, usually ending in the apex of the right ventricle.

An ICD typically refers to an implantable cardioverter defibrillator or an implantable cardiac device and may also include pacemakers and other implantable cardiac stimulation devices. The term IMD includes ICDs and all other implantable stimulation or diagnostic devices. In one example the IMD is an ICD. In another example it's a pacemaker. In yet another example it is an implanted diagnostic device to monitor, record and transmit patient diagnostic data.

Once an IMD is implanted, a patient may be monitored periodically by an ICD clinic, physician or a commercial group that specializes in IMD follow-up. IMD follow-up is usually done on a defined schedule. Some physicians prefer that the patient be seen in the office on a regular basis to have the IMD checked. Some physicians may arrange an IMD check to be done via transtelephonic monitoring. An IMD is typically checked by a physician or clinician that is specially trained in management of IMDs.

IMDs are typically interrogated with a specialized medical electronic device called a “wand”. A portion of the wand is held over the part of a patient's body implanted with an IMD. The wand can then communicate with the IMD. The wand obtains information about the function of the IMD and patient diagnostic data. It may also be used to change certain functions of the IMD to that specified by a physician or clinician. A wand may also be used during the IMD evaluation, and if transtelephonic monitoring is part of the follow-up, a wand will typically be given to the patient to use during the telephone evaluations.

With the use of a remote patient monitoring system, a physician can evaluate a patient with an IMD in real time, even if the two are geographically separated by large distances. These remote monitoring systems make it possible to monitor parameters and settings on an IMD, evaluate real-time electrograms, surface ECGs, delivered therapies, stored electrograms, and clear diagnostics. The complete diagnostics available may be equivalent to a full, in-office wand-based interrogation. These remote monitoring systems allow a medical professional to analyze the transmissions immediately and communicate with the patient in real-time. Calls can be initiated by the patient or follow-up center, and the system can be owned and operated by the office, clinic, or hospital.

Example Environment

FIG. 1is a context diagram of a remote monitoring system.FIG. 1shows a transmitter100with a built in speaker phone102, modem104, audio and visual status indicators106, a patient126, an implanted medical device108, wrist electrodes122, a wand124, a transmitter telephone110, a communication network112, a receiver114, an operator interface116, a receiver phone118and a printer120. The transmitter100has a built in speaker phone102, modem104, audio and visual status indicators106and is coupled to the patient's implanted medical device108, to wrist electrodes122, to a transmitter telephone110and to a communication network112. The receiver114has a modem128, a user interface116and is coupled to a receiver telephone118, a printer120and to communication network112.

The wand124is wirelessly coupled to the patient's IMD108and receives the patient's diagnostic data via telemetry. Wand124may be coupled to transmitter100wirelessly or by wire. Wand124receives patient diagnostic data from IMD108and sends it to transmitter100. IMD108typically transfers diagnostic data wirelessly to the transmitter100. For example the wireless means may be radio frequency transmission. The wrist electrodes124may be used to measure the patient's electro cardiogram and other bodily functions. Wrist electrodes124may also be coupled to transmitter100wirelessly or by wires. Transmitter100may send commands to the patient's IMD108to either control the IMD108or to receive inter-cardial electrogram (IEGM) data from the IMD108. Transmitter100may receive surface ECG data from wrist electrodes122.

The audio and visual indicators106may be used to provide operational status of either one or both transmitter100and IMD108to the patient126. For example, transmitter100can have a light and/or a series of beeps to indicate whether the wand124is in the correct position to read data from the IMD108. Another light and a different series of beeps may indicate that the patient126should activate the speaker phone102to communicate with a physician and yet another light and series of beeps may indicate whether there is a problem with transmitter100, IMD108or with the connection to receiver114. The lights can be of different colors and the beeps can have different tones to indicate different status information. The transmitter100enables voice communication with the remotely located physician via the externally attached transmitter phone110or the internal speakerphone102.

The receiver114is coupled to a receiver telephone118, a printer120and either has a built in or external user interface116. The receiver114can be implemented on a personal computer using specialized software or may be a custom hardware unit running specialized software. The user interface116can be a graphical user interface (GUI) that can be used by the physician to send commands to transmitter100and display patient diagnostic data received from transmitter100. The receiver114can also be used to perform upgrades of transmitter100firmware via communication medium112. The receiver phone118can be used to contact the patient126. Receiver114is typically used to initiate the remote follow-up procedure with the patient126and generate patient data reports. The patient data reports can be printed using the printer120.

A “follow-up session” typically involves the remote monitoring of patient's diagnostic data. A physician may execute a single session that involves the remote follow-up of a patient's IMD108. The physician is able to “interrogate” the IMD108which typically involves using receiver114to connect to transmitter100and receive real time and/or stored data collected by transmitter100from IMD108. The physician can view the interrogation data received from transmitter100via user interface116, and print a follow-up session report via printer120. The physician can perform both “standard” and “custom” follow-ups. A standard follow up may be a set of pre-programmed data requests made by receiver114to transmitter100. A custom follow-up may allow the physician to customize the data requests made to transmitter100via receiver114.

The follow-up session to remotely monitor a patient's IMD108and receive other diagnostic and biometric data typically involves the physician calling the patient's transmitter unit. The patient126communicates with the physician via the speakerphone102on transmitter100or the transmitter telephone110and positions the wand124and wrist electrodes122to enable transfer of diagnostic data. The audio and visual indicators106on transmitter100indicate if the wand124and wrist electrodes122are in position to enable data collection. If the communication network112can only transmit voice or data at a given time then the patient126may hang up the phone line so that data can be transmitted to the physician from transmitter100via communication network112. If the communication network is a VoIP network that can support simultaneous transmission of voice and data, then the patient126can continue to communicate with a physician on the transmitter phone110while the data is being transmitted to receiver114. Since the system is capable of transmitting real time patient diagnostic data, the physician can immediately analyze the received data and provide the necessary advice to patient126via transmitter telephone110and/or audio and visual indicators106. The system can support the simultaneous transmission of stored data as well as real time data from transmitter100to receiver114.

The system shown inFIG. 1supports multiple remote patient follow-up functions including but not limited to the interrogation of programmed parameters and diagnostics from IMD108, acquisition of real-time endocardial EGM, surface ECG obtained from wrist electrodes122, and real-time patient data measurements. The system inFIG. 1also supports diagnostic operations including but not limited to clearing diagnostics, clearing EGM data, updating and adding of trending points such as battery voltage, pacing lead impedance, and signal amplitude. The system inFIG. 1is also capable of disabling all features of the wand124software that involve modification of operating parameters or high risk diagnostic follow-up tests that require the presence of clinical personnel, including but not limited to the programming of IMD108timing, output, sensing, therapy and diagnostic parameters, capture testing, device based testing, non-invasive programmed stimulation (NIPS), Direct Current (DC) fibber, burst fibber, and shock-on-T Fibber, wand commanded shock, high voltage lead integrity check, temporary pacing and capacitor maintenance.

The system shown inFIG. 1may also support acquiring a continuous stream of real-time surface and intracardial ECG data for display on user interface116and printing surface and intracardial ECGs via printer120. The system may also collect surface and endocardial electrograms with a delay of not more than 3 seconds between the surface event and the display of the data on user interface116. The system allows the display of pacing spike enhancements on surface ECGs. The pacing spike enhancements may be configured to be on or off depending on user requirements. The pacing spike enhancement marker is typically within ±20 ms of the pacing marker that triggered it. The system may perform an initial interrogation in less than 3 minutes. An initial interrogation may include interrogation of all applicable parameters and any available diagnostics, including the stored EGM directory. The receiver114may also be able to retrieve n minutes of stored EGM data from transmitter100in less than n minutes. The receiver114can support the interrogation of multiple devices while in the same session.

Remote Adjustment of Data Rate

The data connection between the receiver114and transmitter100is negotiated by their respective modems128and104. After the data rate or baud rate has been negotiated, receiver114and/or transmitter100can interrogate either of modems128,104to determine the baud rate of the connection. However, on initial connection between the transmitter100at the patient's end and the receiver114at the clinician's end, communication impairments can cause low baud rate conditions which may prevent the execution of the remote patient follow up session. Under these conditions, the available bandwidth on communication network112, may not be able to support the amount of real time data coming from the remote patient. To enable a remote follow up session to continue in low baud rate connections the transmitter100may need to reduce the amount of data being transmitted. The present invention optimizes the amount of data that can be transmitted at a given data rate connection.

An embodiment of the invention optimizes the amount of data transmitted at a given data rate or available bandwidth. In one example the available bandwidth is optimized by lowering the sampling rate for selected measurements. This reduces the number of characters per packet of data transmitted by transmitter100. Another example selects only certain data types for transmission by transmitter100. By selecting data types for transmission or any combination of reducing the sampling rate for certain data types and selecting certain data types for transmission, more information can be transmitted at lower baud rates. In another example, multiple data packets may be combined to reduce the overall packet overhead thereby increasing the amount of patient diagnostic data transmitted. Combining data packets may be coupled with one or more of reducing the sampling rate and selecting certain data types for transmission.

FIG. 2is an example flowchart of steps that may be performed by receiver114to remotely adjust data transmitted by transmitter100as a function of a determined data transfer rate. These steps may be performed by receiver114hardware, software, firmware or any combination thereof.

In step200, the receiver114connects to the transmitter100. The receiver modem128typically connects to the transmitter modem104via communication network112.

Next, in step202, the receiver114determines the data transfer rate of the connection between the receiver114and the transmitter100. The data connection between the receiver114and transmitter100is negotiated by their respective modems104,128. The receiver114typically obtains the data transfer rate between the receiver114and the transmitter100from modem128.

In step204, the receiver114determines the data types that can be received from transmitter100based on the data transfer rate determined in step202. For example only data types that can be accommodated by the data transfer rate determined in step202may be selected. For low data transfer rates, data types that require fewer characters per packet (such as data types that use a low sampling rate) may be selected whereas for high data transfer rates, data types that require more characters per packet (such as data types that use a high sampling rate) may be selected. In yet another example, data types sent in two or more packets may be combined into a single packet to reduce overhead. Examples of data type selection and combination of packets based on data transfer rates are described below.

In step206, the receiver114may send a signal or a packet to the transmitter100instructing transmitter100to transmit only data types selected in step204. In another example, the receiver114may send a signal or a packet instructing the transmitter100to combine data in two or more packets to reduce overhead.

In optional step208, the receiver114may send a signal or a packet instructing transmitter100to sample data from IMD108or wrist electrodes122at a given sampling rate. Based on the sampling rate received from receiver114, the transmitter100may alter the real time rate at which data is sampled from IMD108via wand124. In one example, based on the data type(s) received from receiver114in step206and the data transfer rate determined in step202, the transmitter100may alter the sampling rate at which data is sampled from IMD108via wand124. Examples of sampling rate selection based on data transfer rates are described below.

In step210, the receiver114receives real time data from transmitter100. Transmitter100obtains real time data by interrogating IMD108via wand124and via wrist electrodes122. In another example, data stored previously in transmitter100may also be sent along with the real time data. In yet another example, only stored data may be sent. The stored data may also be down-sampled or up-sampled to reduce data size and optimize use of the available data rate determined in step202.

In another example, transmitter100may connect to receiver114and upload real time data as a function of the determined data rate.FIG. 3is an example flowchart of steps that may be performed by transmitter100to adjust data transmitted to a receiver114as a function of a determined data transfer rate. These steps may be performed by transmitter100hardware, software, firmware or any combination thereof.

In step300, the transmitter100connects to the receiver114. The transmitter modem104typically connects to the receiver modem128through communication network112.

Next, in step302, the transmitter100determines the data transfer rate of the connection between the receiver114and the transmitter100. The data connection between the receiver114and transmitter100is typically negotiated by their respective modems128,104. The transmitter100typically obtains the data transfer rate between the receiver114and the transmitter100from modem104.

In step304, transmitter100selects the data types that can be transmitted to receiver114based on the data transfer rate determined in step302. For example only data types that can be accommodated by the data transfer rate determined in step302may be selected. For low data transfer rates, data types that require fewer characters per packet (such as data types that use a low sampling rate) may be selected whereas for high data transfer rates, data types that require more characters per packet (such as data types that use a high sampling rate) may be selected. In yet another example, data types sent in two or more packets may be combined into a single packet to reduce overhead. Examples of data type selection and combination of packets based on data transfer rates are described below.

In optional step306, transmitter100may set a sampling rate at which wand124samples data from IMD108and/or wrist electrodes122. In one example the sampling rate may be a function of the data types determined in step304and in another example the sampling rate may be independent of the data types determined in step304and based solely on the data transfer rate determined in step302. Examples of selecting sampling rates are described below.

In step308, real time data obtained by interrogating IMD108and from wrist electrodes122is transmitted to the receiver114by transmitter100. In another example, data stored previously in transmitter100may be sent along with real time data. In yet another example, only stored data may be transmitted. The stored data may be down-sampled or up-sampled by transmitter100to reduce data size and optimize use of the available data rate determined in step302.

Alternate Embodiments of Remote Data Rate Adjustment

Surface ECG data sampled at 512 Hz may require 10 characters per packet whereas surface ECG data sampled at 256 Hz may require only 7 characters per packet. EGM data with markers may require 8 characters per packet whereas EGM data without markers may require only 3 characters per packet. Table 1 shows examples of different types of real time data and the number of characters per packet needed to transmit them.

TABLE 1Examples of real time data types.CharactersReal Time Data Typeper PacketSurface ECG at 512 Hz sampling10Surface ECG at 256 Hz sampling7EGM with marker data8EGM without marker data3Block Reading Data8
The time required to transmit each character (CharTime), assuming each character to have 10 bits per byte, in milliseconds is given by:

CharTime⁡(ms)=[10⁢⁢bits⁢-⁢per⁢-⁢byteBaudRate]×1000equation⁢⁢1
where BaudRate is in bits/second and is given as:

BaudRate⁢⁢(bits⁢/⁢sec)=[10⁢⁢bits⁢-⁢per⁢-⁢byteCharTime⁢⁢(ms)]×1000equation⁢⁢2
The time to send 11 bytes of data per packet (PT) is given by:
PT(ms)=11 bytes×CharTime  equation 3
If the baud rate at which the connection is taking place is below the sum of the minimum baud rates for each data type, then only some of the data types may be selected for reception or transmission as in steps204and304. For example, to transmit surface ECG data sampled at 512 Hz, the baud rate using equation 2 and data from table 1 is given by:

BaudRate⁢⁢for⁢⁢E⁢⁢C⁢⁢G⁢⁢at⁢⁢512⁢⁢Hz=10×107.18⁢⁢ms=12⁢,⁢804⁢⁢baudequation⁢⁢4
To transmit surface ECG data sampled at 256 Hz, the baud rate using equation 2 and data from table 1 is given by:

If the data connection rate determined in steps202and302is 10,000 baud, then it may not be possible to transmit real time surface ECG data sampled at 512 Hz since that requires 12,804 baud as determined in equation 4. In this case, ECG data sampled at 256 Hz may be transmitted since it requires 8,962 baud as determined in equation 5. The selection of data types for transmission is determined in steps204and304. Based on the number of characters defined for each packet in Table 1, the baud rate for other data types such as EGM with or without marker data and block reading data may also be calculated. In the examples presented throughout, we assume that the time for transmitting one frame is 7.81 ms. This time is used for example purposes only and does not limit the invention in any way.

The limiting factor in data transmission or reception may be the telemetry speed. For example, at a baud rate of 14,085, the time to send a packet may equal the time it takes to read a telemetry frame. If the baud rate is greater than 14,085, then, the time it takes to send a packet of read data is less than the time it takes to send and read the telemetry frame. In this example, for baud rates greater than 14,085, the limiting factor is the telemetry speed. At lower baud rates fewer characters can be transmitted per millisecond and hence fewer data elements can be transmitted. By using the steps in the flowcharts inFIGS. 2 and 3and in examples presented herein, at lower baud rates, more data elements may be transmitted. Table 2 below shows examples of the number of characters and the types of real time data (based on the number of characters required per data type from table 1) that can be transmitted per 7.81 millisecond at different baud rates.

As in steps204and304, ECG, EGM and marker data may be selected to be transmitted or received in one packet instead of two. As a result the overhead bytes associated with each packet are reduced and more data can be sent at lower baud rates. For example if 4 samples of surface ECG data and 2 frames of EGM and marker data can be sent in one packet instead of two, then the overhead will be averaged over 2 frames and more data can be sent at lower baud rates. In another example, overhead data such as the “packet type” byte, which identifies the type of packet being transmitted, the “sequence number” and the “cyclic redundancy code” (CRC) might require 4 bytes of data and have to be appended to each packet being transmitted. For example, if a packet is transmitted every 15.62 ms then the average overhead is 2 bytes thereby reducing the size of the transmitted packet. Table 3 shows an example of the number of bytes needed for example data types in a packet of real time data sent every 15.62 ms.

TABLE 3Examples of the number of bytes for different data types sampled at512 Hz in a packet sent every 15.62 ms.All Real Time Data in One Packet send every 15.62 ms - 512 HzsamplingReal Time Packet ItemBytes neededPacket type byte1Surface ECG samples 1&2 (512 Hz sampling)3Surface ECG samples 3&4 (512 Hz sampling)3Surface ECG samples 5&6 (512 Hz sampling)3Surface ECG samples 7&8 (512 Hz sampling)3EGM 1&22Marker 14EGM 3&42Marker 24Sequence Number1CRC2

The packet shown in table 3 sends 28 total bytes per 15.62 ms or an average of 14 bytes per 7.81 ms instead of 16 bytes per 7.81 ms as would be the case if two packets, each having their own overhead were transmitted individually.

In another example, as in steps208and306, in addition to the above optimizations, if the sampling rate of the surface ECG is changed from 512 Hz to 256 Hz, then the number of bytes transmitted per 15.62 milliseconds is reduced. Table 4 below illustrates examples of the number of bytes for different data types sampled at 256 Hz in a packet sent every 15.62 ms.

TABLE 4Examples of the number of bytes for different data types sampled at256 Hz in a packet sent every 15.62 msAll Real Time Data in One Packet send every 15.62 ms - 256 HzsamplingReal Time Packet ItemBytes neededPacket type byte1Surface ECG samples 1&2 (256 Hz3sampling)Surface ECG samples 3&4 (256 Hz sampling)3EGM 1&22Marker 14EGM 3&42Marker 24Sequence Number1CRC2

The packet shown in table 4 has 22 total bytes per 15.62 ms or an average of 11 bytes per 7.81 ms instead of 13 bytes per 7.81 ms as would be the case if two packets, each having their own overhead were transmitted individually. Also, the number of bytes when using 256 Hz sampling as in table 4 is less than the number of bytes when using 512 Hz sampling as in table 3. Thus, by reducing the average overhead per packet of transmitted data, the sampling rate and or by selecting transmission data types, data can be transmission is possible and can be optimized for low baud rate conditions. Table 5 below shows another example of optimizing data transfer by reducing overhead by combining packets.

TABLE 5Examples of optimizing data transfer at different baud rates byreducing overhead per packet.Data transfer with reduced overhead per packetCharacters perBaud Rate7.81 msAllowable Data Combinations2400018Any2160016Any1920014Surface ECG at 512 Hzsampling and EGM with markerdata (14 chars)ORBlock Reading Data (8 chars)1680013Surface ECG at 256 Hzsampling and EGM with markerdata (11 chars)ORBlock Reading Data (8 chars)1440011Surface ECG at 256 Hzsampling, EGM with marker data(11 chars)ORBlock Reading Data (8 chars)

In another example, as in steps208and306, if the ECG sampling rate is changed to 128 Hz, then the packet size is reduced further. With a reduced ECG packet size more data and more combinations of different data types may be transmitted at lower baud rates without the need to combine packets and reduce overhead per packet. This modification of the sampling rate allows the reception of all real time data at a baud rate of 19,200 as compared to 21,600 with no changes in packet format. In addition, the 19,200 baud rate also allows reception of surface ECG data with block reading. Table 6 is an example of data combinations that can be transmitted at different baud rates when the ECG sampling rate has been modified to 128 Hz.

TABLE 6Example of optimizing data transfer at different baud rates using 128 Hzsampling.Data transfer with reduced sampling rate of 128 HzMinimum BaudCharacters perRate7.81 msAllowable Data Combinations2400018Any2160016Surface ECG at 256 Hzsampling and EGM with markerdata (15 chars)ORSurface ECG at 256 Hzsampling and Block Reading Data(15 chars)1920014Surface ECG at 128 Hzsampling and EGM with markerdata (14 chars)ORSurface ECG at 128 Hzsampling and Block Reading Data(14 chars)1680013Surface ECG at 256 Hzsampling and EGM with nomarker data (10 chars)ORBlock Reading Data (8 chars)1440011Surface ECG at 256 Hzsampling and EGM with nomarker data (10 chars)ORBlock Reading Data (8 chars)

In another example, a surface ECG sampling rate of 128 Hz in combination with a reduced overhead per packet may allow transmission of greater amounts of real time data at reduced baud rates. In yet another example, if all the real time data is incorporated in one packet, then a 256 Hz surface ECG in combination with EGM data and marker data can be transmitted at 14,400 baud. In a further example, all real time data can be transmitted without reducing the sampling rate by compressing or encoding the data instead of reducing the sampling rate or overhead per packet. In another example, all real time data can be transmitted by encoding some features and reducing the sampling rate for other features. In yet another example, disabling certain real time features will allow transmission of other real time features. In one example, there is a table of frame types that lists the type of data that can be sent at a particular baud rate. This table can be either at the transmitter end or the receiver end or at both ends. The transmitter100or receiver114looks up the frame type to determine the type of real time data to transmit or receive.

Remote Upgrade of Firmware

It can become quite difficult and in some cases even unfeasible to upgrade the firmware on transmitter100used in the remote follow-up of patients fitted with an IMD108. This is because the transmitter100has to be either brought in-house or a technician will have to go to the patient with the necessary equipment required to perform the upgrade. These upgrades could be for incorporating feature enhancements or even fixes for potential problems in transmitter100. Delays in upgrading could result in patients not getting access to valuable or critical upgrades on time. If the patient is traveling it becomes even more challenging to perform the upgrade. It is inconvenient and expensive for the patient to bring the transmitter100to either a clinic or a factory outlet for an upgrade. A firmware upgrade may be performed remotely via the internet, trans-telephonically or by any other communications means in communication network112to mitigate this problem.

An example provides for a remote upgrade of transmitter100firmware. In one example a system is provided where such an upgrade can be accomplished from anywhere in the world via the internet or trans-telephonically. Communication media such as, for example, in communications network112can be used to perform the upgrade from a remote location. Such upgrades can be performed at the convenience of the patient. Furthermore, if there is a break in communication during an upgrade or if the upgrade cannot be performed successfully the transmitter100can still be made functional by using the previous version of firmware.

FIG. 4is an example flowchart of steps that may be performed by a receiver114to remotely upgrade transmitter100firmware. These steps may be performed by receiver114hardware, software, firmware or any combination thereof. In the flowchart shown inFIG. 4, Rxis the firmware revision number stored in receiver114and Txis the firmware revision number loaded in transmitter100. The firmware revision numbers Rxand Txof both the receiver114and the transmitter100are in an “a.b” format, where “a” denotes the major firmware revision number and “b” denotes the minor firmware revision number. For example, a firmware revision number may be 23.04. In this example, the major firmware revision number is “23” and the minor firmware revision number is “04”. In the flowchart inFIG. 4, “Major Rx” refers to the “a” portion of Rxand “Minor Rx” refers to the “b” portion of Rx. Similarly, the “Major Tx” refers to the “a” portion of Txand the “Minor Tx” refers to the “b” portion of Tx.

In step400, the receiver114connects to the transmitter100. The receiver114modem128typically connects to the transmitter100modem104via communication network112.

Next, in step402, the receiver114determines if the major Rxis equal to the major Tx.

If the major Rxis determined to not be equal to the major Txin step402, then in step408, the receiver114determines if the major Rxis greater than the major Tx.

If the major Rxis determined to be greater than the major Txin step408, then in step410, the receiver114uploads the new firmware to the transmitter100.

If the major Rxis determined to be equal to the major Txin step402, then in step404, the receiver114determines whether the minor Rxis equal to the minor Tx.

If the minor Rxis determined to not be equal to the minor Txin step404, then in step406, the receiver114determines whether the minor Rxis greater than the minor Tx.

If the minor Rxis determined to be greater that the minor Txin step406, then in step410, the receiver114uploads the new firmware to the transmitter100.

In step412, the receiver114determines if the firmware upload to transmitter100was successful.

If the firmware upload to transmitter100was determined to be successful in step412, then in step414, the receiver114signals the transmitter100to restart.

In step416, the receiver114determines if the transmitter100restarted correctly. The receiver114may accomplish this by sending a test signal to transmitter100or by waiting to receive a response from transmitter100on successful startup.

If it was determined that the transmitter100restarted successfully in step416, then in step424, the receiver114records a log of transactions with transmitter100in one or both receiver114and transmitter100and exits the upload process in step432.

If transmitter100restart is determined to be unsuccessful in step416, then in step418, the receiver114may notify a user at receiver114end and/or the user at transmitter100end. In one example, receiver114may send restart failure notification via telephone110and/or audio visual indicators106to the user at transmitter100end. In another example receiver114may send restart failure notification to the clinician at receiver114end via telephone118, user interface116and/or printer120. The receiver114then records a log of transactions with transmitter100in one or both receiver114and transmitter100in step424and exits the upload process in step432.

If it is determined that the upload to transmitter100was unsuccessful in step412, then in step420, the receiver114may send upload failure notification to users at one or both receiver114and transmitter100ends. The notification may be sent by methods similar to those described in step418.

In step422, the receiver114may query users at one or both the receiver114and transmitter100ends to retry uploading firmware to transmitter100. The user on the receiver114end may be queried via interface116or by an automated message using receiver telephone118. The user on the transmitter100end may be queried via an automated message using transmitter telephone110.

If the query in step422results in an instruction to retry uploading firmware to transmitter100, then the receiver114returns to step410and again tries to upload firmware to transmitter100, otherwise the receiver114proceeds to step424and records a log of transactions with transmitter100in one or both receiver114and transmitter100and exits the upload process in step432.

If it is determined that the minor Txis greater than the minor Rxin step406, then in step426, the receiver114may send notification that a newer version of firmware exists than that available on receiver114to users at one or both receiver114and transmitter100ends. The notification may be sent by methods similar to those described in step418. The receiver114then records a log of transactions with transmitter100in one or both receiver114and transmitter100in step424and exits the upload process in step432.

If it is determined in step404that the minor Rxis equal to the minor Tx, then in step428, the receiver114may notify users at one or both the receiver114and transmitter100ends that transmitter100has the same version of firmware as stored in receiver114. The notification may be sent by methods similar to those described in step418. The receiver114then records a log of results from transactions with transmitter100in one or both receiver114and transmitter100in step424and exits the upload process in step432.

If it is determined in step408that the major Rxis less than the major Tx, then in step430, the receiver114may notify users at one or both the receiver114and transmitter100ends that the firmware stored in receiver114may possibly be incompatible with the firmware version loaded in transmitter100. The notification may be sent by methods similar to those described in step418. The receiver114then records a log of transactions with transmitter100in one or both receiver114and transmitter100in step424and exits the upload process in step432.

FIG. 5is an exemplary flowchart of steps that may be performed by transmitter100to upgrade its firmware. These steps may be performed by transmitter100hardware, software, firmware or any combination thereof. In the flowchart inFIG. 5, Rxis the firmware revision number stored in receiver114and Txis the firmware revision number loaded in transmitter100. The firmware revision numbers Rxand Txof both the receiver114and the transmitter100are in an “a.b” format, where “a” denotes the major firmware revision number and “b” denotes the minor firmware revision number. For example, a firmware revision number may be 23.04. In this case the major firmware revision number is 23 and the minor firmware revision number is 04. In the flowchart inFIG. 5, “Major Rx” is the “a” portion of Rxand “Minor Rx” is the “b” portion of Rx. The “Major Tx” refers to the “a” portion of Txand the “Minor Tx” refers to the “b” portion of Tx.

In step500, the transmitter100connects to the receiver114. The transmitter100modem104typically connects to the receiver modem128via communication network112.

Next, in step502, the transmitter100determines if the major Rxis equal to the major Tx.

If the major Rxis determined to not be equal to the major Txin step502, then in step508, the transmitter100determines if the major Rxis greater than the major Tx.

If the major Rxis determined to be greater than the major Txin step508, then in step510, the transmitter100downloads the new firmware from receiver114.

If the major Rxis determined to be equal to the major Txin step502, then in step504, the transmitter100determines whether the minor Rxis equal to the minor Tx.

If the minor Rxis determined to not be equal to the minor Txin step504, then in step506, the transmitter100determines whether the minor Rxis greater than the minor Tx.

If the minor Rxis determined to be greater that the minor Txin step506, then in step510, the transmitter100downloads the new firmware from receiver114.

In step512, the transmitter100determines if the firmware download from receiver114was successful.

If the firmware download from receiver114was determined to be successful in step512, then in step514, the transmitter100attempts to restart itself.

In step516, the transmitter100determines if the restart is successful. The transmitter100may accomplish this by using software or firmware similar to Microsoft Windows™ “safe mode” operation.

If it was determined that the transmitter100restarted successfully in step516, then in step524, transmitter100records a log of transactions with receiver114in one or both receiver114and transmitter100and exits the download process in step532.

If transmitter100restart is determined to be unsuccessful in step516, then, in step518, the transmitter100may notify a user at receiver114end and/or a user at transmitter100end. In one example, transmitter100may send restart failure notification via telephone110and/or audio and visual indicators106to the user at transmitter100end. In another example transmitter100may send restart failure notification to a user at receiver114end via telephone118, user interface116and/or printer120. The transmitter100then records a log of transactions with receiver114in one or both receiver114and transmitter100in step524and exits the upload process in step532.

If it is determined that the download from receiver114was unsuccessful in step512, then in step520, the transmitter100may send upload failure notification to users at one or both receiver114and transmitter100ends. The notification may be sent by methods similar to those described in step518.

In step522, the transmitter100may query users at one or both the receiver114and transmitter100ends to retry downloading firmware from receiver114. The user on the receiver114end may be queried via interface116or receiver telephone118. The user on the transmitter100end may be queried via transmitter telephone110or audio/visual indicators106.

If the query in step522results in an instruction to retry downloading firmware from receiver114, then in step510, the transmitter100returns to step510, otherwise transmitter100proceeds to step524and records a log of transactions with receiver114in one or both receiver114and transmitter100and exits the download process in step532.

If it is determined that the minor Txis greater than the minor Rxin step506, then in step526, the transmitter100may send notification that a newer version of firmware exists than that available on receiver114to users at one or both receiver114end and transmitter100end. The notification may be sent by methods similar to those described in step518. The transmitter100then records a log of transactions with receiver114in one or both receiver114and transmitter100in step524and exits the download process in step532.

If it is determined in step504that the minor Rxis equal to the minor Tx, then in step528, the transmitter100may notify users at one or both the receiver114and transmitter100ends that transmitter100has the same version of firmware as stored in receiver114. The notification may be sent by methods similar to those described in step518. The transmitter100then records a log of transactions with receiver114in one or both receiver114and transmitter100in step524and exits the download process in step532.

In step530, the transmitter100may notify users at one or both receiver114and transmitter100ends that the firmware stored in receiver114may possibly be incompatible with the firmware version loaded in transmitter100. The notification may be sent by similar methods as described in step518. The transmitter100then records a log of transactions with receiver114in one or both receiver114and transmitter100in step524and exits the download process in step532.

It is to be appreciated that for clarity and ease of illustration, not all steps are illustrated in detail in the flowcharts inFIGS. 4 and 5because these items are known to those skilled in the relevant art, and are further defined in well known communication standards. Furthermore, it is to be appreciated that similar or substitute steps may be used to implement examples.

Alternate Embodiments of Remote Data Rate Adjustment

In one example the upgrade is performed during a clinician's remote follow-up session with a patient fitted with an IMD108. A remote upgrade of transmitter100firmware is implemented trans-telephonically or via the internet where the receiver114communicates with the transmitter100at the patient end through telephone lines to accomplish the upgrade during a follow-up session. The upgrade may also be performed via the internet at a later time when the patient can download the upgrade from the internet to the transmitter100directly or indirectly through a home computer. In yet another example, the internet upgrade of transmitter100firmware can be implemented as an automatic upgrade feature where the receiver114or an internet service provider periodically determines the need for an upgrade of transmitter100firmware and automatically uploads the firmware upgrade to the transmitter100as required. An upgrade may be done by a remote server on the internet where the upgrade firmware is sent through the internet to transmitter100which also connects to the internet. The remote server may initiate a download of the necessary firmware to transmitter100. Alternatively, the remote server may also automatically download the firmware to the patient's home computer from where the patient can then transfer it to transmitter100. The internet service provider and remote server may be part of communication network112.

The examples presented above may also ensure proper function of the transmitter100in the event the upload or download is incomplete or interrupted as determined in steps412and512. For example the download may be incomplete because of phone line impairments, a corrupt copy of the firmware or a version of hardware that is incompatible with the current firmware update. In the event of an incomplete or corrupt download or incompatible hardware, the transmitter100may be able to continue to function on the previous version of firmware. In one example only after the upload or download is verified as being successful with no corruption or hardware incompatibility issues, is the firmware installed in the transmitter by replacing the image of the previous firmware with the image of the new uploaded or downloaded firmware. During the entire upload or download process and installation, transmitter100may continue to function normally.

Virtual Receiver

The receiver114is typically a custom hardware unit that executes software using its operating system (OS). The physical receiver114can be transformed into a “virtual receiver” which is a software executable that may run on a server. The software executable version of physical receiver114can perform all the standard receiver114functions including those mentioned above. A clinician can perform the same remote patient follow-up session, as with physical receiver114, from anywhere in the world via the internet by connecting to the server running the virtual receiver version of receiver114.

FIG. 6shows an example embodiment of a remote monitoring system using virtual receiver602.FIG. 6shows a transmitter100with a built in speaker phone102, modem104and audio and visual status indicators106, a patient126, an implanted medical device108, wrist electrodes122, a wand124, a transmitter telephone110, a communication network112, a server600, a virtual receiver602comprising an interface604, a data processor606and a database608, communication network610, a communication device612with modem614.

Functionalities of receiver114are transformed into virtual receiver602that runs on server600. Virtual receiver602may be software or a combination of hardware and software. Virtual receiver602may comprise an interface604, a data processor606and a database608. Communication device612may be used to connect to server600through a website via communication network610. After connecting to virtual receiver602via the website, a user may initiate a remote follow-up session with a patient126. Interface604is used to connect to transmitter100via communication network112. Communication devices and protocols inherent to server600may be used by interface604to connect to transmitter100. Interface604instructs transmitter100to interrogate IMD108and receive real time and/or stored patient diagnostic data from transmitter100. Data processor606may comprise a GUI, data interpreter and a parsing engine. The GUI may generate one or more web pages or web objects to conduct remote follow-ups via the website. Web pages and web GUI objects may also be generated dynamically by data processor602using Active Server Pages (ASP), Java Server Pages (JSP), JAVA applets or third party software such as Macromedia Flash. The data interpreter may convert at least one of the real time patient diagnostic data and stored patient diagnostic data received from transmitter100into at least one of a Digital Imaging and Communications in Medicine (DICOM) format, extensible markup language (XML) format and health level 7 (HL7) format. The parsing engine may store in database608: interpreted data from the data interpreter, archive data from transmitter100, real time data from transmitter100and log reports of transactions between transmitter100and virtual receiver602. It is to be appreciated that virtual receiver602, interface604, data processor606and database608may be implemented in hardware, software, firmware or any combination thereof. For example, functions performed by virtual receiver602may be implement on an Application Specific Integrated Circuit (ASIC) or may be software running on a microprocessor.

FIG. 7is an exemplary flowchart of steps that may be performed by virtual receiver602. These steps may be performed by receiver114hardware, software, firmware or any combination thereof. These steps may also be performed by virtual receiver602in conjunction with server600.

In step700, virtual receiver602receives a login request from a user such as a clinician or physician from communication device612through a website generated by server600or data processor606.

In step702, the login request received in step600may be verified by comparing a user entered login and password to information stored in database608. The virtual receiver602may also verify whether the connection is secure by checking the security level of the connection on communication network610.

In step704, if a user logged in successfully in step702, the virtual receiver602may receive a request from the clinician to connect to a transmitter100.

In step706, the virtual receiver602initiates connection with a user specified transmitter100. The connection may be initiated via interface604through communication network112.

In step708, the virtual receiver608may request patient diagnostic data from transmitter100using interface604via communication network112.

In step710, the virtual receiver602may download real time and/or stored patient diagnostic data from transmitter100using interface604via communication network112.

In step712, the virtual receiver602may interpret real time and/or stored patient diagnostic data downloaded from transmitter100in step710using the data interpreter in data processor602.

In step714, the virtual receiver602may parse the raw real time and/or stored patient diagnostic data downloaded from transmitter100in step710and/or the interpreted data from step712and store it in database608.

In step716, the virtual receiver602may display the patient diagnostic data on a website using web objects and GUIs that may be generated by the data processor. The user may access the website and view the patient diagnostic data shown using these web objects and GUIs.

In step718, if the clinician desires to communicate with patient126, the virtual receiver602may query the clinician. The query may be via a web GUI dialog box that requires clinician input.

In step720, if the clinician decides to initiate a conversation with patient126in step718, then virtual receiver602may initiate a call with patient126over communication network112. The patient126may communicate via transmitter telephone110or speakerphone102. The clinician may communicate via communication device612which may have built in audio capability such as a cellular phone or may be connected to a telephone. The communication networks112,610may be VoIP networks.

In step722, after the clinician ends the discussion with patient126in steps720or if the clinician selected to not initiate a conversation with patient126, the virtual receiver602logs an account of the transaction with transmitter100and communication device614in database608.

In step724, the virtual receiver602receives an instruction from the clinician via the website to terminate the connection with transmitter100. The virtual receiver safely disconnects with transmitter100using interface604and exits the interrogation process.

Alternate Virtual Receiver Embodiments

In one example, communication network610is the internet and communication device612is a personal computer with a web browser and modem612. In another example, the communication device612may be an internet accessible PDA or cell phone and communication network610is a wireless network. The website on server600for accessing virtual receiver602may provide a GUI for conducting remote patient follow-up and viewing patient diagnostic data. The patient diagnostic data may be processed by data processor606and stored in database608. The virtual receiver602may be configured to conduct multiple follow-up sessions simultaneously. The virtual receiver602may be implemented in LINUX, UNIX, MAC, WINDOWS or other operating systems.

The parsing engine may be implemented using object oriented languages such as JAVA and C++. The database602may store all data received from transmitter100in raw or interpreted format. The log reports may detail the transaction history of user logins and system errors. The clinician may also be able to send the user audio/visual alerts via audio/visual indicators106. If communication device612has audio transmission capability then the clinician may also be able to contact patient126via transmitter phone110or speakerphone102. At the end of the follow-up session, the clinician may instruct virtual receiver602to safely disconnect with transmitter100using interface604. The clinician may then log out of virtual receiver602or conduct more follow-up sessions with other patients by initiating connections with other transmitters. Alternatively the clinician may simultaneously conduct multiple follow-up sessions.

In another example, patient126may be able to log into virtual receiver602using transmitter100and/or connect via a website and upload the data from transmitter100. In one example interface604and data processor606may be combined into a single unit. This unit may be implemented in hardware, software, firmware or any combination thereof. It is to be appreciated that communication networks112and610may be the same in some examples.

In the examples presented above, the term “physician” refers to a person who remotely monitors the patient implanted with an IMD or other medical device and conducts a remote follow-up session. The terms physician and clinician are used interchangeably throughout. The terms EGM, ECG, block reading and marker data are merely examples of patient diagnostic data and do not limit the invention in any way. It is to be appreciated that other patient diagnostic data acquired from the patient may be also be transmitted or received.

The communication network112may be a public switched telephone network (PSTN), a private branch exchange (PBX), internet, voice over internet protocol (VoIP), broadband network, an optical network, a wide area network, intranet or other wired or wireless communication medium. The receiver114and transmitter100may be coupled to the communication network112via physical, optical, wireless or other media. The modem104on the transmitter100side may be internal or external to transmitter100and modem128on the receiver114side may be internal or external to receiver114. Modems104,128are able to communicate via any of the above mentioned communication media in communication network112.

The present invention, or portions thereof, can be implemented in hardware, firmware, software, and/or combinations thereof.

The following description of a general purpose computer system is provided for completeness. The present invention can be implemented in hardware, or as a combination of software and hardware. Consequently, the invention may be implemented in the environment of a computer system or other processing system. An example of such a computer system800is shown inFIG. 8. The computer system800includes one or more processors, such as processor804. Processor804can be a special purpose or a general purpose digital signal processor. The processor804is connected to a communication infrastructure806(for example, a bus or network). Various software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures.

Computer system800also includes a main memory805, preferably random access memory (RAM), and may also include a secondary memory810. The secondary memory810may include, for example, a hard disk drive812, and/or a RAID array816, and/or a removable storage drive814, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive814reads from and/or writes to a removable storage unit818in a well known manner. Removable storage unit818, represents a floppy disk, magnetic tape, optical disk, etc. As will be appreciated, the removable storage unit818includes a computer usable storage medium having stored therein computer software and/or data.

In alternative implementations, secondary memory810may include other similar means for allowing computer programs or other instructions to be loaded into computer system800. Such means may include, for example, a removable storage unit822and an interface820. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units822and interfaces820which allow software and data to be transferred from the removable storage unit822to computer system800.

Computer system800may also include a communications interface824. Communications interface824allows software and data to be transferred between computer system800and external devices. Examples of communications interface824may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via communications interface824are in the form of signals828which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface824. These signals828are provided to communications interface824via a communications path826. Communications path826carries signals828and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link and other communications channels.

The terms “computer program medium” and “computer usable medium” are used herein to generally refer to media such as removable storage drive814, a hard disk installed in hard disk drive812, and signals828. These computer program products are means for providing software to computer system800.

Computer programs (also called computer control logic) are stored in main memory808and/or secondary memory810. Computer programs may also be received via communications interface824. Such computer programs, when executed, enable the computer system800to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor804to implement the processes of the present invention. Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system800using raid array816, removable storage drive814, hard drive812or communications interface824.

In other embodiments, features of the invention are implemented primarily in hardware using, for example, hardware components such as Application Specific Integrated Circuits (ASICs) and gate arrays. Implementation of a hardware state machine so as to perform the functions described herein will also be apparent to persons skilled in the relevant art(s).

CONCLUSION

The present invention has been described above with the aid of functional building blocks and method steps illustrating the performance of specified functions and relationships thereof. The boundaries of these functional building blocks and method steps have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Any such alternate boundaries are thus within the scope and spirit of the claimed invention. One skilled in the art will recognize that these functional building blocks can be implemented by discrete components, application specific integrated circuits, processors executing appropriate software and the like or any combination thereof. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.