Over the course of the past few weeks there has been much information discussed about the status of security in cardiac pacing and ICDs...overall this industry.
This post should perhaps help provide some solid framework that St. Jude Cardiac Pacemakers/ICDs and the Merlin.Net Patient Care Network are safe and effective in cardiac patient therapy in a most secure manner. We have received zero technical, corporate, or financial incentives from St. Jude Medical. This is our own opinion based upon our understanding of the facts.
The following covers the scope of statements made in reports, to include a highly respected researcher providing background to lot's of questions in these reports, and finally St. Jude’s response.
As one who has spent his entire career spanning thirty plus years in the medical device industry, the wireless domain space, and in the cardiac pacing industry, I feel obligated to share my professional opinions regarding the recent statements by third-party entities, which have, in my opinion have questionable domain experience in the cardiac pacing space.
Please see the following links to these third party firms as well as another interesting link of another reality check provided.
http://www.bloomberg.com/news/videos/2016-08-25/medsec-s-bone-hope-st-jude-responds-with-urgency
http://www.businessinsider.com/muddy-waters-shorts-st-jude-2016-8
Do they (those that provide these statements) actually have
the clinical and pacing domain experience to back this up their findings? One needs to consider this.
https://threatpost.com/researchers-medsec-muddy-waters-set-bad-precedent-with-st-jude-medical-short/120266/
Please see the link to Kevin Fu and the University of Michigan, and the excellent research report he has authored.
http://www.engin.umich.edu/college/about/news/stories/2016/august/holes-found-in-report
There is one important aspect of this report by the University of Michigan is that that they essentially provided the exact same described testing situation described by the third party. From a technical standpoint: no leads were actually connected to the “can” (industry term) pacemaker itself, so no doubt there was resistance (impedance alerts). Look carefully at the screen shot provided by the report. This is normal and expected based upon the testing platform provided. Some questions of which were not apparent was the device programmed to a asynchronous mode (DOO, AOO, or VOO) and or programmed to a single chamber inhibited mode) (AAI, VVI, or triggered mode AAT or VVT)? A pacing system needs to be validated for sensitivity, voltage, and impedance as a system in its totality, i.e an ecosystem, of how the actual implant was completed. This is the only way you will be able to show a true and validated testing environment.
Questions for the third party firm that originated their initial findings?
Where is the of detail regarding their findings? Did they (the firm that provided the testing) test with an actual patient with the device implanted?
Another point from Kevin Fu’s report:
There would no actual way to communicate with the “implanted” device 50 feet away. This is just not possible, as the body would attenuate (degrade) any RF pathway as this device would not be in "free space" at the connected security AES.
Close proximity for a solid communications pathway would actually be less than 6 feet.
References:
FCC 47 CFR 95.601-95.673 Subpart E Rules applicable to the MedRadio Service
FCC 11-176 Amendments of Parts 2 and 95, November 30, 2011
ITCU-R SA.1346
(Note; Limited to a EIRP (equivalent isotropically radiated power) of -16dBm of the Medical Implant Communications Systems (MICS), of which is (25 uW (microwatts)
ETSI TR 102 343 V1.1.1.(2004-07) (Technical Report) Electromagnetic compatibility and Radio spectrum Matters (ERM), Ultra Low Power Active Medical Implants (ULP-AMI), operating int the 401MHz to 402MHz and 405 MHz to 406 MHz bands:, System Reference Document
ETSI RN 301 839-1 V1.3.1 (2009-10) European Standard (Telecommunications Series)
Electromagnetic compatibility and Radio Spectrum Matters (ERM), Short Range Devices (SRD), Ultra Low Power Active Medical Implants (ULP-AMI) and Peripherals (ULP-AMI-P) operating in the frequency range 402MHz to 405MHz: Part 1: Technical characteristics and test methods.
AES (Advanced Encryption Standard). A symmetric block cipher used by the United States government to protect classified information and is implemented in software and hardware throughout the world to encrypt sensitive data.
Also draining the battery to EOL (End of Life) could not happen in our opinion in an actual clinical situation. In order for this to happen you would have to be constantly real time "pinging" the device in proximity to less than six feet for a matter of many days and/or weeks, or even months. This simply is not realistic. EOL pacemaker) indicators would be in effect to provide notification that this would be happening, thus giving you real time on the fly notification. ERI (Elective Replacement Interval) would more the likely to come first before EOL.
From the CEO of St. Jude Medical, Michael T. Rousseau, “Patients are the highest priority.”
Those that have not been around this space, they simply do not perhaps understand the dedication of those that work tirelessly to provide life-saving and life-improving therapies. This is a highly regulated industry. Designing pacemakers and ICDs with multiple layers of security, protection and redundancy is nearly at the level of the Apollo 11 flight and sending a man to the moon. Not a trivial task.
The demonstrated RF (radio frequency) Telemetry Lockout feature by St. Jude confirms that the device clinical functions are operating as expected.
St. Jude pacemakers are actually performing as they were designed with significant security and patient safety as part of the design features. If any potential security threat arises, devices will go into a “safe mode”, which provides all continued patient functionality for both pacing and ICD requirements as programed to specific patient requirements.
See St. Jude’s response both on August 26th and August 30, 2016:
http://media.sjm.com/newsroom/news-releases/news-releases-details/2016/St-Jude-Medical-Refutes-Muddy-Waters-Device-Security-Allegations-and-Reinforces-Security-of-Devices-and-Commitment-to-Patient-Safety/default.aspx
http://www.healthcareitnews.com/news/st-jude-fires-back-muddy-waters-medsec-our-medical-devices-are-secure
Merlin.net Patient Care Network and Validation and Verification of Security.
St. Jude Medical uses several administrative, physical, and technical safeguards to protect the personal information of patients with St. Jude devices. As a measure of these safeguards, St. Jude Medical maintains a registration of the ISO/IEC 27001:2013, and leverages a Private Framework that is based on ISO/IEC 29100. ISO standards are accepted internationally as risk-based auditable principles.
ISO/IEC 27001:2013 has ten short clauses:
1. Scope of the Standard
2. How the document is referenced
3. Reuse of he terms and definitions in ISO/IEC 27000
4. Organizational context and stakeholders
5. Information security leadership and high level support for policy
6. Planning an information security management system, risk assessment and risk treatment
7. Supporting an information security management system
8. Making an information security management system operational
9. Reviewing the systems performance
10. Corrective action
In summation, St. Jude Medical is a world-class company with proven products in the cardiac therapy space. Their safety record, reputation, and security in the medical device space is unprecedented.
