Patent Application
20090048644
The invention relates in general to active implantable medical devices and, specifically, to a system and method for providing intrabody data security on an active implantable medical device.
Active implantable medical devices (AIMDs), such as defined in European Economic Community Directive 90/385/EEC, are medical devices that rely on electrical or self-provided energy. AIMDs are generally intended to be totally or partially introduced into a living body. AIMDs include both discrete devices, such as cochlear implants and insulin pumps, and multi-component devices, for instance, implantable cardiac defibrillators (ICDs) with wired intracardiac pressure sensors. Still further types of AIMDs are possible.
AIMDs provide intrabody, that is, in situ therapy or physiometric monitoring through preprogrammed autonomous or remotely controlled operation. Permanently implanted AIMDs must periodically be interfaced to external devices, such as programmers and patient-operable communicators, for diagnosis, troubleshooting, and reprogramming, and to exchange stored parametric and physiological data, while temporarily implanted AIMDs either function autonomously or operate interoperatively through an external controller.
AIMDs must balance desired capabilities against available resources, particularly power, storage, and size. Data security, for instance, serves a function secondary to the primary role of an AIMD and is only addressed implicitly. For instance, wireless data exchange provided through inductive or radio frequency telemetry relies upon the one-to-one nature of interconnections to ensure confidentiality, integrity, and authenticity.
Nevertheless, independent AIMDs can potentially interfere with one another when communicating with an external system or where components communicate intrabodily. Implicit data security alone is insufficient for ensuring that external devices are allowed to interface only to permissible AIMDs. Additionally, implicit data security fails to ensure confidentiality. Legal considerations, such as the Health Insurance Portability and Accountability Act (HIPAA) and the European Privacy Directive (EPD), mandate patient privacy be protected, especially patient health information (PHI) that identifies a specific individual with health- and medical-related information.
U.S. Pat. No. 6,223,018 issued Apr. 24, 2001 discloses an intrabody information transfer device. A transmission device includes a signal source for outputting a time varying signal that is modulated to a transmission electrode arranged in the vicinity of a human body. Another transmission electrode is connected to a reference voltage for the transmission device and is arranged outwardly from the human body. Similar separate apparatuses are provided for signal reception. Communication is provided through two absolute signal routes by means of a human-body induced electric field and via the air. However, data is exchanged in the open without data security control or protection.
U.S. Pat. No. 6,277,078 issued Aug. 21, 2001 discloses an intracardiac system that includes a pressure sensor and a sensor to collect information on blood flow into or out of a heart cavity. The sensors can be formed with or attached to a stent. The sensors are connected to a data relaying device via electrical wire. An extracorporeal processing unit collects relayed information via wired or wireless interconnect. However, data security is implicit, as data is only exchanged one-to-one between the sensors and the data relaying device, or between the data relaying device and the extracorporeal processing unit.
U.S. Pat. No. 6,764,446 issued Jul. 20, 2004 discloses an implantable pressure sensor, which measures pressure or other physiological parameters. An external transducer transmits acoustic signals into a patient's body to energize a capacitor. An acoustic transceiver converts energy between electrical and acoustic energy. The capacitor stores the electrical energy converted by the transceiver and provides electrical energy to operate the sensor, which sends pressure data as acoustic signals. Although serial numbers can be used to distinguish between multiple devices, data is only exchanged one-to-one between the sensor and the external transducer and not between interoperative implanted sensors.
U.S. Patent Application Publication No. US2002/0077673 A1, published Jun. 20, 2002, pending, and U.S. Patent Application Publication No. US2002/0177782 A1, published Nov. 28, 2002, pending, both describe an implantable sensor interfaceable via an external acoustic transducer. The sensor functions autonomously to monitor pressure or physiological parameters. The acoustic transducer transmits acoustic signals into a patient's body to interface with the implantable sensor, which downloads pressure measures recorded by the sensor. However, data is only exchanged one-to-one between the sensor and the external acoustic transducer and not between interoperative implanted sensors.
Finally, U.S. Patent Application Publication No. US2002/0082480 A1, published Jun. 27, 2002, pending, and U.S. Patent Application Publication No. US2005/0021370 A1, published Jan. 27, 2005, pending, both describe network implemented remote patient management schemes. Medical devices upload physiologic data through wireless technology, such as radio frequency telemetry, over a robust internetwork, where the data can be stored in a database, processed, analyzed, or presented for viewing. The medical devices may also communicate between one another. Medical provider access is validated or authenticated, as applicable, and data transfer over a public network is encrypted to maintain security. However, communications between medical devices remain unprotected and source trustworthiness and data integrity are assumed.
Therefore, there is a need for an approach to providing data security to AIMDs for internal intrabody and external extracorporeal data communications. Such an approach would need to secure all forms of data, including patient data, commands, and any other type of information electronically storable, exchangeable, or manipulable by or between AIMDs, or other devices.
There is a further need for an approach to ensuring the availability and the security of data to authorized devices only and to also enable multiple independent AIMDs to function without interference from either within or without a patient's body.
One embodiment provides a system and a method for providing intrabody data security on an active implantable medical device. Data is maintained through an active implantable medical device. The data is secured on the active implantable medical device among at least one other active implantable medical device wirelessly interfaced. At least one of access to and use of the data with the other active implantable medical device is limited. Unauthorized changes to the form of the data are prevented.
Still other embodiments will become readily apparent to those skilled in the art from the following detailed description, wherein are described embodiments of the invention by way of illustrating the best mode contemplated for carrying out the invention. As will be realized, the invention is capable of other and different embodiments and its several details are capable of modifications in various obvious respects, all without departing from the spirit and the scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.
Although described in this application in relation to AIMDs primarily intended for providing cardio and cardiopulmonary diagnosis, therapy, or monitoring, the embodiments described apply generally to all forms of AIMDs capable of being remotely interrogated or programmed.
Active IMDs (AIMDs) are defined in European Economic Community Directive 90/385/EEC, the disclosure of which is incorporated by reference. In general, AIMDs rely on electrical or self-provided energy for therapy delivery, sensing, diagnosing, monitoring, and other purposes, and are intended to be totally or partially introduced, surgically or medically, into a living body or by medical intervention into a natural orifice.
The patient 101 has received both a pair of independent AIMDs and a conventional external medical device 118. One AIMD is a multi-component AIMD 103 for intracardiac monitoring that includes separate intrabody components 104, 109a, 109b that intercommunicate wirelessly, such as through electromagnetic, acoustic, vibrational, chemical, or optical telemetry. Other forms of wireless communication are possible. Each component 104, 109a, 109b is self-powered and self-contained. A relay device 104 is implanted subdermally over the pectoralis major. The relay device 104 is wirelessly interfaced intrabodily to two remote intracardiac pressure sensors 109a, 109b that are respectively implanted in the right atrium 110 and ventricle 111 of the patient's heart 102. The monitoring device 104 can also wirelessly interface extracorporeally to an external device, such as a programmer, patient-operable communicator, or server, as further described below with reference to
The housing of the relay device 104 contains control circuitry 105, telemetry circuitry 106, memory 107, and battery 108. The control circuitry 105 includes a microprocessor-based controller, signal filters, and amplifiers to process raw intracardiac data signals, which are stored into memory 107 for later retrieval and analysis by the external device. The telemetry circuitry 106 provides a wireless intrabody interface between the relay device 104 and the sensors 109a, 109b, as well as a wireless extracorporeal interface with the external device. The battery 108 provides a finite electrical power source. The sensors 109a, 109b also include a control circuitry, intrabody telemetry circuitry, battery, and memory, as well as pressure sampling circuitry (not shown). Other intrabody components and multi-component AIMDs are possible.
The other AIMD is a discrete AIMD 112 for pulmonary monitoring. A self-contained intrapulmonary sensor 113 is implanted subcutaneously over the lower lobe of the right lung. The sensor 113 can wirelessly interface extracorporeally to an external device, as further described below with reference to
The housing of the sensor 113 similarly contains control circuitry 114, telemetry circuitry 115, memory 116, and battery 117. The control circuitry 114 includes a microprocessor-based controller, sampling circuits, noise filters, and amplifiers to sample and process raw intracardiac data signals, which are stored into memory 116 for later retrieval and analysis by the external device. The telemetry circuitry 115 provides a wireless interface between the sensor 113 and the external device. The battery 117 provides a finite electrical power source. Other discrete AIMDs are possible.
The conventional external medical device 118 is an insulin pump, which includes a removable stent 120 with a hollow lumen and distally oriented insulin delivery probe 121. The probe 121 is introduced subcutaneously by a caregiver or the patient for temporary therapeutic use. An insulin pump housing 119 remains outside the patient's body and communicates with the stent 120 through the hollow lumen for delivering insulin therapy. The insulin pump housing 119 includes control circuitry and battery, which execute therapy programming instructions. Communications involving the insulin pump 118 are strictly extracorporeal and therefore distinct from those involving the AIMDs 103, 112. Other external medical devices are possible.
Implanted and external AIMDs perform therapy delivery, sensing, diagnosing, monitoring, and related functions, either autonomously or through remote control. Intrabody data security is necessary to ensure that these functions are performed correctly and safely, and without interference from other sources, including other AIMDs.
Patient data is broadly defined and includes quantitative physiometric data that has been recorded or derived from raw physiometry measured by an AIMD. Patient data also includes non-patient information, such as parametric data reporting on the status and operational characteristics of the AIMD itself, and environmental data that includes non-AIMD related information, such as the ambient temperature or time of day. Patient data further includes qualitative data values, such as subjective impressions of personal wellness or quality of life. Still further types of patient data are possible.
Commands are a specific type of instructional data, which are issued to control, effect an operational result, and communicate. Commands can be originated by an AIMD or other device, and include program or instructional codes and messages that convey directions, orders, responses, acknowledgements, and other forms of operational information to be carried out or used by an AIMD or other device. Still further types of commands are possible. Commands require security over issuance and transmittal, as well as over their integrity.
Data, whether patient data, commands, or other data, can originate with one or more multi-component or discrete AIMDs that are permanently or temporarily introduced into a patient's body. These devices include AIMDs 132, 133 that are totally introduced into a patient's body, which include therapy delivery devices, such as pacemakers, implantable cardiac defibrillators, cardiac resynchronization devices, drug pumps, and neuro-stimulators; and physiometric monitoring devices, such as cardio monitors and pulmonary monitors. These devices also include AIMDs that are partially introduced into a patient's body, which include therapy delivery devices 134, such as remotely controlled insulin pumps consisting of an extracorporeal controller and an implanted bolus delivery device, and physiometric monitoring devices 135, such as electroencephalogram recorders consisting of an extracorporeal recording device and electrodes that are placed subdurally or in the cerebral cortex. Other types of AIMDs are possible. Multi-component AIMDs can be hierarchically structured in master-slave fashion, or as peer-to-peer components, as further described below with reference to
Data can also originate with conventional fully extracorporeal medical devices 136. These devices include external sensors that remain in contact with the patient's body, such as a Holter monitor, and a wide range of medical and non-medical devices that a patient can use, operate, or perform tests, such as blood pressure cuffs, weight scales, Spirometers, and the like. Other types of extracorporeal devices having patient-related purposes are possible.
Generally, those AIMDs that are either permanently introduced, or which are totally implanted require extracorporeal interfacing to interrogate or retrieve data and to provide programming over the operation of the AIMD while in situ. Extracorporeal interfacing to these types of AIMDs can be provided through conventional interrogation devices, such as programmers 137, patient-operable communicators 138, or similar devices, which are interfaced to an AIMD through wired or wireless means, such as inductive or radio frequency, or other forms of wireless telemetry based on, for example, “strong” Bluetooth or IEEE 802.11 interfacing standards. Other types of devices for AIMD interrogation and programming are possible.
Absent data security controls, data is susceptible to a wide range of potential harms, including compromise, interception, interference, and corruption originating from within or outside of the patient's body. Data security approaches used in conventional data exchange have been applied with varying degrees of success to extracorporeal data exchange, such as between an AIMD and an external interrogation device. However, strictly intrabody communications also require data security, which can most effectively be provided through protections over data confidentiality and assurances of data integrity, source authentication, and data availability, as further described below beginning with reference to
In a further embodiment, extracorporeal interfacing can be provided through a server 140, which is remotely interfaced over a network 139, either directly with an AIMD or via an intermediary interface. Structurally, the server 140 is a server-grade computing platform configured as a uni-, multi- or distributed processing system, which includes those components conventionally found in computing devices, such as, for example, a central processing unit (CPU), memory, network interface, persistent storage, and various components for interconnecting such components. The server 140 can include a database 141 or other storage means to maintain retrieved data 142 and other information for caregiver review and analysis and other authorized uses. The network 139 is based on the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite, although other protocol suites are possible. Additionally, other network topologies and configurations are possible.
In a further embodiment, the data can be evaluated for the occurrence of one or more chronic or acute health conditions, such as described in related, commonly-owned U.S. Pat. No. 6,336,903, to Bardy, issued Jan. 8, 2002; U.S. Pat. No. 6,368,284, to Bardy, issued Apr. 9, 2002; U.S. Pat. No. 6,398,728, to Bardy, issued Jun. 4, 2002; U.S. Pat. No. 6,411,840, to Bardy, issued Jun. 25, 2002; and U.S. Pat. No. 6,440,066, to Bardy, issued Aug. 27, 2002, the disclosures of which are incorporated by reference.
In a still further embodiment, the data is extracorporeally safeguarded against unauthorized disclosure to third parties, including during collection, assembly, evaluation, transmission, and storage, to protect patient privacy and comply with recently enacted medical information privacy laws, such as the Health Insurance Portability and Accountability Act (HIPAA) and the European Privacy Directive. At a minimum, patient health information that identifies a particular individual with health- and medical-related information is treated as protectable, although other types of sensitive information in addition to or in lieu of specific patient health information could also be protectable.
Multi-component AIMDs constitute an intrabody data network that operates independent of other devices, including extracorporeal interfacing devices, fully extracorporeal medical devices, and other AIMDs. Thus, the individual components must be structured in an organized fashion to allow secure data storage and exchange.
Hierarchical Structuring
One of the simplest forms of multi-component AIMD structurings is hierarchical.
Peer-to-Peer Structuring
Although simple, hierarchical structurings scale poorly and can unevenly tax the processing, storage, and power resources of the master device. Non-hierarchical structurings attempt to ally these shortcomings by decentralizing communication responsibility.
Data exchange can occur in one or more forms within an intrabody data network created by a multi-component AIMD.
Referring first to
Referring next to
Referring next to
Finally, referring to FIG. 5D,—multicast data exchange 163 involves a plurality of components sending information to one or more components during the same time period. All data security controls, particularly data integrity control due to the potential for data contention, are generally required. Other forms of communication are possible.
In an intrabody environment, data security is necessary to protect data when stored in an AIMD and while in transit between components or an extracorporeal device, such as a conventional interrogation device. Commands require additional security to protect their issuance and transmittal, as well as their integrity. Data security is also needed to protect against interference from fully extracorporeal medical devices and other AIMDs in operation within the same patient.
Intrabody data security is provided through a set of four security controls (operation 171). Each of the controls is necessary to ensure full data security, although the underlying functionality of the component can still be performed, albeit non-securely, if any of the controls fails or are unavailable. First, data confidentiality (operation 172) limits access to and use of data by other devices, including conventional interrogation devices, fully extracorporeal medical devices, and other AIMDs, as further described below with reference to
Data Confidentiality
Data confidentiality ensures that data is only accessible by other devices that have been granted proper authorization. Such devices include conventional interrogation devices, fully extracorporeal medical devices, and other AIMDs, as well as other types of medical and non-medical devices.
Data confidentiality (operation 182) is exercised over data 181, either in whole or in part, by each AIMD while stored or when in transit. Data confidentiality extends to attempts to access (operation 183), use (operation 184), copy (operation 185), or disclose (operation 186) the data 181 without proper authorization. Other operations are possible.
Data confidentiality can be introduced through several means. For instance, the AIMD can maintain an access list of authorized devices and permissible operations. As well, the data 181 can be encrypted by using symmetric encryption, such as the Advanced Encryption Standard (AES), or by using asymmetric encryption that uses public and private key pairs in a public key infrastructure, such as the Rivest, Shamir, Adleman (RSA) or Elliptic Curve Cryptography (ECC) schemes. As a result, the data 181 would only be available to those devices possessing a valid decryption cipher and key. Data confidentiality can also be achieved over a channel with limited or open access. Still further forms of data confidentiality control are possible.
Data Integrity
Whereas data confidentiality focuses on access, data integrity ensures that the form of data cannot be altered by other devices without proper authorization, whether by design or accident. For example, data could be maliciously deleted by malware, or could be unintentionally changed when in transit due to transmission error.
Thus, data integrity (operation 192) concerns more than just the content of data 191. Data integrity involves confirming that the form of the data 191 remains as intended by the originator, which can be another device or the AIMD itself. For commands, data integrity includes protecting the issuance and transmittal of commands, as well as the integrity of the commands themselves. In basic form, data integrity typically entails including a check, marker, or other identifier with the data to enable subsequent integrity confirmation. Data integrity provides assurances that data 191 has neither been created as unauthorized new “data” 196 (operation 193), changed into unauthorized altered “data” 197 (operation 194), or deleted with resultantly lost “data” 198 (operation 195), whether by intention, inadvertence, or accident. Other operations are possible.
Data integrity can also be introduced through several means. For instance, conventional error detection and correction schemes, such as parity checking, cyclic redundancy codes, and error correction codes, can be incorporated into commands and data exchanged. Similarly, unique identifiers, such as device serial numbers, can be assigned at time of manufacture and can be included with commands and data, as well as time stamps and other protections that “lock” information against unauthorized compromise. Data integrity can also be supplied through data confidentiality mechanisms, such as cryptographic signatures included in digital certificates provided through a public key infrastructure. Still further forms of data integrity control are possible.
Source Authentication
Source authentication or, simply “authentication,” verifies claims of identity presented to an AIMD by other devices. Consequently, source authentication is needed whenever an unauthenticated device makes a request of the AIMD.
Source authentication (operation 202) is performed by an intrabody device 203 in response to a command or request for data 201 from another device 204, such as conventional interrogation devices, fully extracorporeal medical devices, and other AIMDs.
Source authentication is a form of trust mutually established between a requesting device and a receiving AIMD. Trust can be established through several means. For instance, trust can be established through data confidentiality mechanisms, such as cryptographic signatures included in a digital certificate, such as an X.509 digital certificate, which is included with a request 205 as credentials 206. The receiving intrabody device 203 would authenticate the credentials 206 against trusted credentials 208 previously received from a certificate authority or trusted agent or intermediary, such as a manufacturer. In simpler form, the intrabody device 203 could maintain an access list 209 that would identify those devices that are known and trusted. With an access list 209, the requesting device 204 would need only present a request 205 with a set of credentials 206, which could also be digitally signed. Still further forms of source authentication control are possible.
Data Availability
Data availability is less a security concern than a data access and use policy. This control ensures that data and the responsible AIMD are online with security controls that work.
Data availability (operation 211) is assured if both the data 212 and associated intrabody device 213 are available to other devices, for instance, via a network 139 (shown in
Data availability can be provided as part of the security controls. Access to the data 212 and intrabody device 213 are thus refused if the security controls 214 are inoperable or otherwise offline. Still further forms of data availability control are possible.
While the invention has been particularly shown and described as referenced to the embodiments thereof, those skilled in the art will understand that the foregoing and other changes in form and detail may be made therein without departing from the spirit and scope of the invention.
