Internet of Things ... From a Connected Medical Device Perspective

Before I dive into the issues regarding the possible means for connecting medical devices to the Internet, I would like to provide you with a little background on two relevant research programs I have lead. I was the principal investigator on two Federally supported research programs described below.

The first was a NIST Research grant to support the development of a secure and commercially viable wireless data communications technology. Much of that technology has been incorporated into today's smartphones, although not all of what we created has yet found its way into the current generation of smartphones. But with each iteration, more of what we created gets incorporated.

A central part of our program was to insure secure and private data communications. It would be secure from infiltration by malware and impenetrable by snoops ... including the NSA. The system worked by securing and controlling both ends of the communication. It was capable of sending a single file to over multiple communications channels simultaneously, the packets could be sent out of order using multiple forms of encryption including nonstandard or private encryption methods -- that are much harder to break. By securing and controlling both ends of the connection between devices, we could completely control what went in and out of the channel. Nothing would flow to the other end that was out of our view or control.

The second Federal grant was for a data security program. VoIP communications channels are lightly secured largely due to the requirements to insure that audio is clear and voices understandable. This fact makes VoIP channels particularly vulnerable vectors to use for an attack. There have been attempts to logically divide voice and data channels; however, there have been several demonstrations that this does not always work. Our research focused on methods to detect the presence of an intruder without disrupting or significantly lowering audio quality. And when we detected a possible intruder, we attacked this apparent intruder through a series of escalating techniques that could finally end with terminating the connection when it was clearly apparent that an intruder was using the VoIP connection to do something nefarious.

Architectures for the Internet of Things

The two architectures I would like to review are direct and mediated connections that could be used in the realm of the Internet of Things.

Direct and mediated connections are illustrated in the figure below.

The real difference between the two diagrams is the way the Apple Watch is connected to the Internet. On the left the Watch is directly connected to the Internet. When connected, it is an addressable device on the Internet. On the right, the Watch is connected to the Internet through the iPhone. The iPhone mediates the connection to the Internet through the iPhone. All the data traffic to and from the Watch goes through the iPhone.

A mediated connection through the device can be as simple and unmanaged as one through a router. However, with the appropriate software on the iPhone, the iPhone should be able to manage the connection with and security of the Watch.

In the case of the direct connection, management of the connection to the Internet including security must be done by the Watch itself. The Watch could be subject to a direct attack and must defend against such an attack by itself.

Best Architecture for Medical Devices?

In the diagram above, I'm treating the Watch as if it were a medical device ... and a medical device it could be. It would seem that the safest connection to the Internet would be a mediated connection. However, there are hybrid scenarios. For example, incoming communications including software updates could require a mediated connection. Encrypted uploads from the Watch to a centralized server system could use a direct connection.

This is a brief introduction into this topic. I'll have further explorations into this issue in future articles.

How This Blog Got Going: MRI Safe and Conditional Pacemakers, Reprise

I have decided to return to the thing that I was working on when I started this blog ... an MRI conditional pacemaker. Specifically, an MRI conditional pacemaker for St. Jude Medical. At the time I was Lead Human Engineering Clinical Systems Engineer on this project. Before I go any further I would like to distinguish between MRI conditional and MRI safe devices. It is important to distinguish between the two.

MRI Conditional v. MRI Safe

Having an MRI safe implanted cardiac device is the ideal situation. If the cardiac device is MRI safe, it means that a device patient can be "popped" into an MRI without any changes to the device. For the patient it's just like the person does not have an implanted device. The only difference is that the resulting imagery from the MRI around the device may not be as good if the person did not have an implanted device. 

An MRI conditional device presents some significant procedural challenges to all those involved. If a person has an MRI conditional device, certain conditions must be met before the device patient is allowed to enter the MRI. When I was working at St. Jude Medical, changes in the settings that operate the device are required before the patient enters the MRI. Once scanning is complete, the settings need to be changed back to their normal, operational settings.

As of publication of this article, only one medical device company has a commercially available MRI safe pacemaker, Biotronik. St. Jude Medical and Medtronic have commercially available MRI conditional devices. 

When I was work at St. Jude, the only cardiac device being engineered to permit patients to have MRI scans were pacemakers. At the time ICDs and CRTs were not considered for MRI compatibility. However, apparently, Biotronik has developed an MRI conditional ICD that is commercially available ... at least in Europe.

There are other issues regarding MRI compatibility such as whether there are limits on the area that can be scanned a cardiac device patient ... something other than a full body scan. The allowable limits on how much can be scanned are continually in flux. But this particularly issue does not have anything to with the story I want to tell.

My Experience with the MRI Conditional Project

The St. Jude Medical MRI conditional pacemaker was engineered to enable patients to undergo an MRI scan. To insure that pacemaker patients would not be harmed by the scan required that the operating settings on the pacemaker be adjusted. (To make a long story short ... a change in the setting needed to make sure that the sensing lead to heart be turned off. The pacemaker could be changed to constant pace or turned off entirely if the patient is not pacemaker dependent ... as most pacemaker patients are.)

So the major problem in this entire issue was in regards to how to change the settings on the device? Who would do it, how would it be done, what would the settings be? Essentially three basic approaches were considered:

1. Have the patient's cardiac physician or cardiac nurse go to the MRI center, lugging their device programmer with them, change the settings on the patient's device to those that are MRI compatible, wait for the scan to complete, reset the settings to normal and examine the patient to insure that the patient is OK.
2. Have the settings changed remotely. The patient is at the MRI center, the cardiac professional is in the office, at the hospital or at home. This is known as "remote programming."  At the time this was something that the FDA did not allow. Using remote programming, the patient's device communicates wireless to a pacemaker communicator located at the MRI center. The cardiac professional sees a 30 second rhythm strip before setting the patient's device to the MRI settings and sees another 30 second rhythm strip after the changes have been made. (Just like an onsite cardiac professional would do.) The patient undergoes the scan. During that time, the professional can perform other tasks. Once the scan is complete, the cardiac profession changes the pacemaker settings back to normal and sees the before and after rhythm strips. 
3. The pacemaker is programmed with two settings by the cardiac professional using the programmer. The first set of settings define the normal operation of the pacemaker. The second set are the MRI settings: that is, the settings of the pacemaker when the patient undergoes an MRI scan.  When the pacemaker patient goes to the MRI center, the MRI tech takes a wand (that's best way I can describe it.) and changes the settings from normal to MRI. Once the patient completes the MRI scan, the MRI tech uses the wand to change the patient's setting back to normal. 

I became quickly apparent that cardiac professionals had no interest in option 1. As it turned out St. Jude Medical chose the third approach. 

When the third approach was described, I had numerous objections ... mostly related to the device that would change the setting on the pacemaker. Thankfully, there have been substantial changes and upgrades made to the wand. However, I wanted to purse option 2, remote programming. And the desire to purse option 2 inspired me to start this blog ... hence the title Medical Monitoring & Remote Programming.

Wherefore Remote Programming?

Most physicians showed some hesitancy when it came to adopting remote programming. They saw it as unproven ... and they were right, it was (and so far as I know still is) unproven and still not acceptable to the FDA. However, many if not most were intrigued by the idea and thought that the technology should be pursued. Many clearly saw the potential value of the technology, the value of being able to monitor patients remotely with the potential ability to change cardiac device settings without the patient being in the office could be a revolution in patient care ... not only for people with chronic conditions like heart problems, diabetes or neurological problems that involve implanted devices, but potentially everyone. And it need not involve the need for implanted or wearable devices. We'll explore this in later postings.

How to Hack Grandpa's ICD

I've discussed possible communications security problems with implanted devices in an earlier post.  The link below provides a link to a University of Washington study that was published in 2008 in IEEE Symposium on Security and Privacy. Here's a link to the University of Washington article. 

Researchers find implantable cardiac defibrillators may expose patients to security and privacy risks


The article includes a link to the published paper.  I suggest that you download the paper and read it. 


Although the article was published in 2008, I believe it still has relevance.  First, it references a Medtronic Carelink Home Monitoring unit that I am quite certain is still in widespread use.  Second, they reverse engineered the Medtronic unit to create their own system that could mimic the Medtronic unit.  Although I am not an electrical engineer by any stretch of the imagination, I can attest to soundness of their methods.  I have worked with a variety of engineers who have tested communications system security using similar methods.  Furthermore, I have worked with engineers who have successfully cracked harden communications systems.  Thus I shall continue to monitor developments and findings in this field because this could impact the engineering of the communications systems for remote monitoring and programming.


One of the flaws in the Medtronic unit that made reverse engineering relatively easy was that the data was not encrypted.  I do not know if currently any or all communications between home monitoring units from any device company and implanted devices is encrypted.  Encryption adds significant overhead to communications.  Thus it makes the communication between the device and a home monitoring unit significantly longer.  It can impact battery life because encrypted transmissions have more bytes to transmit.

One of the potential limitations to hacking implant radio communications is the extremely low power level of that communication. The low power levels suggest that the hacker would have to be in close proximity to the device, within three meters.  However, their article did not extensively investigate the communications distance issue or methods that might be used to get around the proximity problem.

Third, the authors also had access to a Medtronic programmer.  A study of the operations of the programmer enable the authors extend their capabilities to hack communications with the implanted device. 

The scariest part of the article is a discussion of how it would be possible to kill a person with an ICD using the device they constructed.  Here's that section of the article (edited):

Inducing fibrillation

During implantation surgery, it is common for a physician to test the newly implanted ICD to ensure that it can both sense and appropriately treat a cardiac
condition known as ventricular fibrillation (V-Fib), one of the most common kinds of heart rhythm problems. Accordingly, the ICD has several testing modes in which it can induce VFib.  Such a test — called an electrophysiological (EP) study — is normally conducted with cardiologists standing by to stop the fibrillation if the ICD fails to do so. ... [a] programmer sends the ICD a sequence of commands that ... [a] shock to be applied to the patient’s heart at a precise point in the patient’s cardiac rhythm, with the goal of inducing V-Fib. When its automatic therapies are enabled, the ICD should immediately detect and treat the fibrillation by delivering the proper therapy. ... We then used our commercial programmer to conduct an EP study ... We then replayed a recording of the EP study command sequence via our software radio. At least three of 30 replay attempts succeeded. We successfully triggered command shocks via replayed commands even after turning off all of the
ICD’s automatic therapies.
Quoted from:
Halperin, D, Heydt-Benjamin, T., Ransford, B., Clark, S., Defend, B., Morgan, W., Fu, K., Kohno, T., Maisel, W. Pacemakers and Implantable Cardiac Defibrillators:
Software Radio Attacks and Zero-Power Defenses, IEEE Symposium on Security and Privacy, 2008, pp 1-14.

Update on 29 September 2009 Posting

I have an update related to my 29 September posting, Medtronic Remote Programming Patent.I stated the following in that posting ...

I believe that Medtronic's patent ... reveals not only the extent of Medtronic's work on remote programming and their level of development of this technology, it reveals a product development path. ... The strategy that I believe Medtronic has taken is in keeping with long-standing trends in technology development.

Over the last several decades, the trend has been to move away from  specialized to more powerful, general-purpose processors. This enables products to be defined more by software than by hardware. Processing power has become smaller, less power hungry and cheaper, thus allowing software to become the means for defining the system's capability. Furthermore, this enables multiple products to be defined by a single hardware platform. ...

The Medtronic patent suggests a similar product strategy ... that different products will use fundamentally the same hardware architecture, but they will be defined by the software that they run. So, a pacemaker, a neurostimulator and a drug pump will share the same processor hardware platform, but their operation will be defined primarily by the software that they run. For example, take some time and examine pacemakers, ICDs. CRTs/CRT-Ds, neuro-stimulators, drug pumps, etc.  Although they have different purposes, they have enough in common to consider the possibility that all of them could share a common processor platform.

The implications are significant for all functional areas within Medtronic, from research and development, product development, software development and management, and from product support. Medtronic can leverage its enormous scale to make its scale as a company a major asset. It can substantially reduce the number of hardware platforms it supports, it can leverage its software development capabilities to have its software development groups produce software for multiple product lines, it can create more products without a substantial requirement for additional support each time a product is produced. ...


I unearthed an article published in the August 2008, Journal of Computers, titled "Design Overview Of Processor Based Implantable Pacemaker" authored by Santosh Chede and Kishore Kulat both from the Department of Electronics and Computer Science Engineering at the Visvesvarayan National Institute of Technology. (I do not have an address for you to access this article, however, if you search on the journal, the title and authors, you will find it.)


Their article describes the means by which they created a pacemaker using at Texas Instrument (TI) MSP430F1611 processor to build a pacemaker.  The TI MSP430 processor (TI MSP430 Microcontroller Website) is a general purpose RISC processor similar in architecture to the DEC PDP-11.  The TI MSP430 is designed for ultra-low power consumption and targeted to battery-powered, embedded applications.  In other words, this would be the kind of processor on which to base a line of implantable medical devices.  Having looked around the website, I noted that the application of the processor included medical devices, but not implants.  However, based on the Journal of Computers article, I can see a clear route to creating implants using this processor. (I haven't yet found a comparable processor, however, I suspect the existence of one or more.  As I find additional processors in this class, I shall make them known in this blog.)


Finally, I think the important message of the Journal of Computers article is that it is possible to use a general purpose processor and software to create a pacemaker or any other implantable medical device such as a neuro-stimulator, CRT-D, or drug-pump. As I discussed earlier, using a general purpose processor and software to create the product, can be an effective business and technical strategy.