The IMD system includes IMD 10 (shown as a pacemaker in
Also depicted in
In existing IMD systems, programming unit 20 includes a number of functional components for storing and executing instructions related to communication with IMD 10, programming of IMD 10, and processing of data received from IMD 10. In most systems, these components are designed specifically for IMD 10 with which programming unit 20 is designed to operate. However, according to the principles of the present invention, the IMD system shown in
In this configuration, remote programming of a patient's IMD may be performed, such as by the Medtronic CareLink® network. Telemetry module 30 serves as an in-home monitor, or may be connected to additional hardware to provide the in-home monitor, which is designed to be used by an unskilled person (e.g., the patient). Direct interaction with the patient is therefore limited appropriately. The monitor may function to monitor the IMD and to communicate data collected from the IMD to server 40 at a remote location, such as via a telephone line or by other connections or links. Based on the data collected and communicated, appropriate instructions for programming the IMD may be selected at a clinic via computer 42 that is communicatively coupled to server 40, such as by medical personnel operating appropriate software on computer 42, or by automatic selection of the software itself). The selected instructions are then transmitted back to telemetry module 30 via server 40, so that programming of the IMD can be performed.
In one embodiment, the system includes one or more of the following features:
The application software executed by computer 70 is stored in a compact flash card (or other media) that is physically blocked from being accessed without a tool. Further, power is provided to telemetry module 30 from computer 70 via USB interface 30b. Further, more data is handled via Unicode resource DLLs in order to support various languages, such as Chinese. Additionally, a “dual emergency key” feature is provided for pacing applications, which requires the simultaneous pressing of two buttons (either hardware-based buttons, software-based buttons, or a combination of the two, for example) in order to activate emergency pacing (in order to avoid inadvertent activation of emergency pacing).
In some embodiments, telemetry module 30 may itself offer a simplified or basic application, in addition to supporting a computing device-based application. For example, a disconnected telemetry module could operate to verify basic health parameters and IMD functions, while more complex issues that are identified which require more information or programming capability could require connection to a computing device. In one embodiment, the basic status information could be simply red and green lights (indicating either an “OK” or “more information required” status), or a more detailed on-board display, depending on the desired environment for use.
In operation, computer 89 executes an application that provides a user interface for interaction with IMD 10, similar to special purpose programming units that currently exist. Telemetry module 30 provides communication capability between computer 89 and IMD 10 by appropriate telemetry, which depends on the type of IMD 10 that is employed. Telemetry module 30 also is responsible for insuring that the interactions between computer 89 and IMD 10 are valid and safe. This is an important feature of telemetry module 30, due to the many possible forms, functions, capabilities and security associated with computer 89. For example, computer 89 may be a programming unit provided by the same manufacturer that manufactured IMD 10. Computer 89 may also be a programming unit provided by a different manufacturer. Computer 89 may alternatively be a general purpose computer executing an application that allows computer 89 to function as a programming unit, either locally or remotely (e.g., over the Internet/World Wide Web), or may be a personal digital assistant (PDA) or other portable device executing a similar type of application. This capability afforded by telemetry module 30 enables a variety of equipment configurations to perform the function of IMD programming, which can result in significant cost savings and/or service enhancements for patients and medical facilities. The details of the functions performed by telemetry module 30 are discussed below with respect to the software shown in
Communication manager 100 is responsible for managing communications between telemetry module 30 and device application 126, to acquire information from device application 126 that will be used to program IMD 10, and to provide information to device application 126 representative of the operation and/or status of IMD 10, the patient in whom IMD 10 is implanted, or both. Communication manager 100 communicates over communication channel 120 (which in one example is a USB interface), and also communicates information with local user input/output (I/O) interface 122 over local communication channel 124, as well as with network 94. Communication manager 100 also controls and/or monitors functions performed by job processor 102, telemetry application 104, telemetry firmware 106, and telemetry data link layer 108 based on data received over network communication channel 120 and/or local communication channel 124. Communication manager 100 also communicates with security processor 127, configuration manager 128 and architect monitor 130 (an optional component for capturing diagnostic information) to further control job processor 102, telemetry application 104, telemetry firmware 106, and telemetry data link layer 108. Security processor 127 provides cryptographic functions for communication manager 100, managing public/private key pairs, certificate chains of authority, and fingerprint generation and validation. The certification and security provided in the operation of telemetry module 30 is explained in detail below with respect to
Job processor 102 is responsible for controlling the tasks performed by telemetry head 30. Telemetry head 30 may operate in a number of modes, such as a basic mode, an autonomous mode, a networked mode, a maintenance mode, or others. In one embodiment, these modes of operation are characterized as follows:
Basic Mode—In basic mode, low-level telemetry commands are exposed to device application 126, similar to the operation of existing programming units. Thus, basic mode is most appropriate when the connection between job processor 102 and device application 126 is a high speed, high reliability link, such as when telemetry module 30 is integrated in a programming unit or is locally connected to a programming unit.
Autonomous Mode—Autonomous mode includes the functions of Basic mode, and also allows device application 126 to assemble “jobs” and submit them to job processor 102 for execution. A job may include a series of commands, read requests, write requests, and real time data configuration commands, for example. Tasks that make up a job may be defined and executed conditionally, and macros may be employed so that tasks are executed based on the occurrence of certain events. Autonomous mode is suitable for use in scenarios where device application 126 is connected to telemetry module 30 via a network connection that may not be high speed or may have less reliability than a direct connection. This mode allows for local emergency activation of job processor 102 to automatically complete certain jobs (such as jobs that are deemed critical) if communication with device application 126 is interrupted.
Network Mode—Network mode includes the functions of Basic and Autonomous modes, and also allows communications between job processor 102 and other instruments. For example, job processor 102 may interact with a local automated external defibrillator (AED). This interaction could be used as an additional safety measure in appropriate situations, by requiring a patient to be connected to a defibrillator when IMD 10 is being reprogrammed.
Maintenance Mode—This mode provides development, test and debugging capability, when telemetry module 30 is not employed in an actual patient session.
In some embodiments, job processor 102 may be configured to accept remote programming via communications received from communication manager 100 over network communication channel 120, for example. Job processor 102 provides the capability to implement such programming in its control of tasks and its interaction with telemetry application 104, telemetry firmware 106, and telemetry data link layer 108. Job processor 102 may also interact with configuration manager 128 and communication manager 100 to implement an update of telemetry firmware 106 and telemetry data link layer 108 to support a new telemetry version.
Telemetry application 104 performs high level telemetry functions, such as automatic identification of device types (to identify IMD 10), real-time processing of data from IMD 10 (such as electrogram (EGM) signals and markers), and interrogation and programming of IMD 10. Telemetry application 104 may also perform a passthrough function, allowing OSI layer 7 services to be provided within device application 126 instead. These tasks are defined and executed in a manner that is specific to device application 126.
Telemetry firmware 106 includes the components of OSI layers 3, 4, 5 and 6. OSI layer 6 is the presentation layer. This layer provides independence from differences in data representation (e.g., encryption) by translating the data from application format to network format, and vice versa. Data is transformed into a form that telemetry application layer 104 can accept, and formats and encrypts data so that the data can be sent across a network, providing freedom from compatibility problems. This layer may also be called the syntax layer
OSI layer 5 is the session layer. This layer establishes, manages and terminates connections between applications. Specifically, the session layer sets up, coordinates, and terminates conversations, exchanges and dialogues between device IMD 10 and device application 126. The session layer coordinates the communication session and the connection between devices.
OSI layer 4 is the transport layer. This layer provides transparent transfer of data between IMD 10 and device application 126. The transport layer is responsible for end-to-end error recovery and flow control, to ensure complete data transfer. This layer breaks large messages from device application 126 down into a sequence of smaller data packets, and assembles packets received from IMD 10 into a message to be transmitted to device application 126.
OSI layer 3 is the network layer. This layer provides switching and routing capability, creating logical paths (also known as virtual circuits) for transmitting data from node to node. Routing and forwarding are functions of this layer, as well as addressing, internetworking, error handling, congestion control and packet sequencing.
Telemetry data link layer 108 forms OSI layer 2. In one embodiment, this layer is implemented in a FPGA, and is divided into a media access control (MAC) sublayer for controlling access to the transmission hardware, and a logical link control (LLC) for controlling frame synchronization and flow control and handling errors in the physical layer. Telemetry data link layer 108 encodes data packets and decodes data packets into bits, and also manages the transmission protocol.
Telemetry physical layer 100 forms OSI layer 1. This layer conveys the bit stream (electrical impulses, light signals or radio signals, for example) through the network at the electrical and mechanical level. This layer is implemented by analog electronics 82 and digital electronics 84 (including the FPGA) shown in
In operation, telemetry module 30 represents a trusted party in the IMD system, since it is under the control of the medical device manufacturer. In order to preserve its trusted status, any changes to its software may only be accomplished if they are sent from a trusted source. Telemetry module 30 will validate any request to supply a software update using cryptographic and authentication technology.
Similarly, telemetry module 30 communicates with a computing device that provides programming instructions using public/private and symmetric keys. The application software running on the computing device is isolated from other software on the computing device using a memory management unit (MMU), a virtual environment, or similar known technology. As part of its operation, the application software performs an analysis of its data and code space to create a fingerprint using cryptographic techniques. This fingerprint is encrypted and sent to telemetry module 30 along with possible commands or programming instructions. Telemetry module 30 decrypts the fingerprint and compares the fingerprint against a list of valid fingerprints for each possible device application. If the fingerprint is invalid, the commands or instructions are not executed. The fingerprint is periodically recalculated to verify the continued integrity of the application software.
The application software periodically executes performance tests to determine if the hardware has sufficient resources to properly maintain the device programming session. Should insufficient resources be available due to activity of other programs, the presence of a virus, or other factors, the software application will discontinue the device programming session and notify the user.
The functional components shown in
Other configurations of components are of course possible as well, and the above-described examples are intended only to illustrate some of the configurations that can be achieved. These and other configurations are able to be used at least in part because of the safety and certification capability that is provided by telemetry module 30, which is described in detail below with respect to
The CD then generates a software fingerprint at step 168. The software fingerprint is based on the software structures, data structures, key values, etc. associated with the CD, and a change to any of these parameters would modify the software fingerprint. This allows detection of any alteration to the software due to malicious software (e.g., a virus, a worm, or others) running on the CD. The CD has no knowledge of what a valid fingerprint is, and so a valid software fingerprint cannot be reverse engineered. In one embodiment, the software fingerprint is generated using a one-way hash process, which prevents generation of a new fingerprint based only on a new random sequence key. The software fingerprint and a CD certificate are then encrypted with the TM's public key at step 170, and the encrypted data is transmitted to the TM with the TM's public key at step 172. Only the TM is able to decrypt this message, using the TM's private key, to validate the CD's certificate and fingerprint, as shown at step 174. In this step, the CD's certificate is used to validate its fingerprint. The CD's certificate is encrypted with the TM's public key, and thus, the TM knows whether the CD's certificate is valid (and also because the CD's certificate is digitally signed by a root authority that is under the control of the system manufacturer).
If the CD's fingerprint and certificate are determined (at decision step 175) by the TM to be invalid, the CD's request to connect with the TM is rejected, as shown at step 176. If the CD's fingerprint and certificate are determined by the TM to be valid, the TM generates a random symmetric key, encrypts that random symmetric key with the CD's public key, and sends it to the CD, as shown at step 178. The CD then decrypts the symmetric key using the CD's private key at step 180, so that the symmetric key is established as the key for encrypting and decrypting future transmissions, as shown at step 182.
During the communication session between the CD and the TM, the TM sends the CD a random sequence key, as shown at step 184. The CD acknowledges the random sequence key and stores it in its memory, as shown at step 186. The random sequence key allows a new and different fingerprint to be generated by the CD, so that copying and re-use of previously valid fingerprints is not possible.
The security associated with the software fingerprint allows the system to detect adulterated or otherwise improper software, such as software that has been altered due to a virus or worm, software that is out of date, software that is an incorrect version or is incompatible with certain aspects of the IMD or other components of the system, or others. In some embodiments, the software fingerprint is generated for only selected transmissions, such as transmissions that are critical to patient health, so that processing bandwidth is utilized efficiently. Similar procedures could be used to validate users of the IMD system, other equipment employed in the IMD system, new software acquired to update the system, or others.
The present invention, which can be implemented in a variety of embodiments and configurations, provides a telemetry module that is connectable to a computing device in order to perform the functions related to programming and interaction with an IMD that were typically performed by a specially designed programming unit in existing systems. These functions include receiving programming instructions from the computing device and certifying the safety of those instructions before performing the instructed programming (due to the potentially hazardous environment of general purpose computing devices), and converting data transmitted by an IMD into a format that is usable for a device application being executed on the computer device. This capability allows existing equipment that is already in use at a medical facility to be used, with appropriate software and firmware, as a programming unit, which could potentially allow IMDs to be utilized in environments and markets where they were not previously available.
Although the present invention has been described with reference to preferred embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the invention. For example, one skilled in the art will recognize that other types of medical devices, in addition to the examples described herein, can be employed in various embodiments while practicing the principles of the invention.