Apple Watch 4: New York Times Review

Here's an article reviewing the Apple Watch 4 that was published in the New York Times on 19 September 2018.

Here's the link: https://www.nytimes.com/2018/09/19/technology/personaltech/apple-watch-series-4-review-health.html?em_pos=large&emc=edit_ct_20180920&nl=technology&nlid=67594383edit_ct_20180920&ref=headline&te=1

As of the posting of this article, Apple has yet to release their ECG app -- the thing I guess that most of us have interest with regards to the Apple Watch 4. It's the one thing that moves the Apple Watch 4 from a consumer to a medical device and a hardware platform on which to base medical applications and services. So, until the ECG application is available, I'm holding off on reviewing the Apple Watch 4.

Apple Watch 4: Will it be suitable as a remote medical monitoring device? Part 1

When I first commented about the Apple Watch as being a possible platform for a remote medical monitoring system in 2015, I was initially excited about the possibilities. Sadly, the technology in 2015 was not quite ready as a platform for remote medical monitoring systems. However, Apple may be turning a corner with the Apple Watch 4 due to be released in Fall 2018. 

To be an effective remote medical monitoring and remote patient management device, the Apple Watch will need to reach acceptable levels of performance in the following seven areas of concern:

1. Bio-sensors
• Built in: are there enough bio sensors with enough resolution?
• Extended: the capability to have additional bio sensors that communicate wirelessly with the watch?
2. Communications over the Internet: Is there a reliable and secure means of communication back to the patient's monitoring system? And the means to communicate with the patient over that same communications channel(s)? 
3. Processing capability, hardware and software: Does the watch have the processing capability to host medical applications?
4. User interface: Visual, touch screen - will patients be able to interact with medical application using the touch screen? Will the watch have an effective audio user interface in order to hear instructions and make requests of the application running on the watch?
5. Reliability: Will the hardware and software reliable enough for a remote medical monitoring and patient management application to run on it?
6. Battery life: When running a remote medical monitoring and patient management application(s) on the watch, will the battery life before needing to recharge be acceptable?
7. Rugged: Is the Apple Watch 4 rugged enough to be a remote medical monitoring and patient management device?

I'm going to touch on each of the areas of concern regarding the performance of the Apple Watch 4.

1. Bio-sensors: I'm not going to address this issue until the Apple Watch 4 has been released. Once it has been released, I'll write an article specifically discussing this topic.
2. Communications over the Internet: A model of the Apple Watch 3 does have the capability of communicating over 4G so reliable communication over the commercial wireless provider networks is possible. We can assume that this capability will continue to the next release. So communications capabilities are likely to be adequate. 
3. Processing capability, hardware and software: Improvements in both are promised over the Apple Watch 3. We can probably assume that hardware and software capabilities will be adequate.
4. User interface:
• Visual, touch screen: The Apple Watch screen has been targeted to those with good visual acuity (with or without glasses) and fine finger control to be able to use the touch screen effectively. Current reports say that the screen will be larger than the Apple Watch 3. Nevertheless it's still a small screen. 
• Auditory: The Apple Watch 3 has Siri, meaning it does have an auditory user interface. More on this after the release of Watch 4.
5. Reliability: Apple has made positive strides in reliability with each release of the Apple Watch. We can assume that this will continue and that the Apple Watch 4 will be reliable enough to serve as a platform for remote medical monitoring and remote patient management applications.
6. Battery life: The Apple Watch 3 has a reported battery life of up to 18 hours. Again Apple has continued its improvements in this area. Patient medical monitoring should be continuous and without long breaks. Even with one or more days of battery life, the watch will still need to be changed and that could take hours. However, having said that, the price of an Apple Watch (because of the ruggedness requirement) that would serve as a remote medical monitoring and patient management device would be around $600. As medical devices go, that's inexpensive and inexpensive enough so that the patient could or should have at least two Apple Watches that would enable the patient to switch watches when necessary. That would place a burden on application software developers to manage when patients change watches, however, this should be manageable.
7. Rugged: The Apple Watch 3 has a version in a stainless steel case. This should be adequate for most situations. Also the issue of reasonably low price and the ability to have redundant watches should effectively address this issue.

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.

Hacking Grandpa's ICD: Why do it?

Background

I am part of another professional discussion group with an interest in Medical Data, System and Device security.  One of the topics was whether medical devices are a likely target for cyber-attacks.  I made a contribution to the discussion and stated that I believed that although unlikely, I thought that medical devices will eventually be targets of cyber-attacks.  But putting data security measures into medical devices is at odds with the directions that the medical device industry wants to take its product lines.  The trends are for smaller and less power-hungry devices.  Adding data security measures could increase power demands, increase battery sizes and thus increase device size.  Nevertheless, I believe that starting the process of putting data security measures into the medical devices has merit.

I received a well-reasoned response that hacking medical devices was highly unlikely and research funding on security measures for medical devices would be money best spent elsewhere.  That response started a thought process to develop a threat scenario to address his points.

I reviewed my earlier article on "hacking medical devices," http://medicalremoteprogramming.blogspot.com/2010/04/how-to-hack-grandpas-icd-reprise.html.  I revisited the paragraph in my regarding the motivation for hacking a medical device, an extortion scheme. 

When I wrote that article, I did not have any particular scheme in mind.  It was speculation based more on current trends.  Furthermore, I did not other motivations as particularly viable - data theft, not much money or value in stealing someone's implant data or killing a specific person, there are easier ways to do this although it might make a good murder mystery.

I did come up with a scenario, and when I did, it was chilling.





The Threat Scenario

First, as I had previously suggested, the motivation for hacking medical devices would be extortion.  The target of the extortion would be the medical device companies.  Before getting into the specifics of the extortion scenario requires that you understand some of the technologies and devices involved.

The wireless communications of interest occurs between a "base station" and a wirelessly enabled implanted device as shown in the figure below.

The base station need not be at a permanent location, but could be a mobile device (such as with the Biotronik Home Monitoring system).  The base station in turn communicates with a large enterprise server system operated by the medical device company.


The two systems communicate use wireless or radio communication.  For example, St. Jude Medical uses the MICS band - a band designed by the FCC for medical devices in the range of 400Mhz.  To insure that battery usage for communications is minimal, the maximum effective range between is stated as 3 meters.  (However, I have seen a clear connection established at greater 3 meters.)  


In general, the implant sends telemetry data collected it has collected to the base station.  The base station sends operating parameters to the implant.  Changing the operating parameters of the medical device is know as reprogramming the device and define how the implant operates and the way the implant exerts control over the organ to which it is connected.


Device Dialogue of Interest to Hackers

As you probably have guessed, the dialogue of interest to those with criminal intent is the one between the base station and the device.  The "trick" is to build a device that looks like a legitimate base station to the medical device.  This means that the bogus device will have to authenticate itself with the medical device, transmit and receive signals that the device can interpret.  In an earlier article (http://medicalremoteprogramming.blogspot.com/2010/03/how-to-hack-grandpas-icd.html), I discussed an IEEE article (http://uwnews.org/relatedcontent/2008/March/rc_parentID40358_thisID40398.pdf**) where the authors had constructed a device that performed a successful spoofing attack on a wireless Medtronic ICD. So, based on the article, we know it can be done.  However, based on the IEEE article, we know that it was done at distance of 5 cm.  This was aptly pointed out in a comment on my "How to Hack Grandpa's ICD" article.


Could a Spoofing/Reprogramming Attack be Successful from Greater than 5 cm or Greater than 3 meters?


I believe the answer to the question posed above is "yes."  Consider the following lines of reasoning ...

1. As I had mentioned earlier, I know that base stations and medical devices communicate at distances of 3 meters and can communicates greater distances.  The limitation is power.  Another limitation is the quality of the antenna in the base station.  The communication distance could be increased with improvements in the antenna and received signal amplification. 
2. The spoofing/reprogramming attack device could be constructed to transmit at significantly greater power levels than current base station.  (Remember, this is something built by a criminal enterprise.  They need not abide by rules set by the FCC.)  Furthermore, a limited number, maybe as few as one or two, of these systems need be constructed.  I shall explain why later.
3. A base station can be reverse-engineered.  Base stations can be easily obtained by a variety of means.  Medical devices can be stolen from hospitals.  Documentation about the communication between the medical device and the base station can be obtained.

Thus, I believe the possibility exists that a device that emulates a base station and could successfully perform a spoof/reprogramming attack from a significant distance from the target is possible.  The question is, what is to be gained from such an attack?


Attack Motivations


Extortion: Earlier I mentioned that in an other article, I suggested that the motivation would be extortion: money, and lots of it.  I think the demands would likely be in the millions of US dollars.

In this scenario, the criminal organization would contact the medical device companies and threaten to attack their medical device patients.  The criminal organization might send device designs to substantiate their claims of the ability to injure or kill device patients and/or send the targeted company with news reports sudden unexplained changes in medical devices that have caused injuries or deaths in device patients.


Market Manipulation: Another strategy would be as a means to manipulate the stock prices of medical device companies - through short-selling the stock.  In this scenario the criminal organization will create a few base station spoofing/reprogramming systems. Market manipulation such as placing the value of the stock at risk could be a part of the extortion scheme.




Book of Interest: Hacking Wall Street: Attacks And Countermeasures (Volume 2)


In another article I'll discuss how someone might undertake an attack.




** 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.

How to Hack Grandpa's ICD: New Develoments

A little over a year ago I published a couple of articles in this blog regarding "Hacking Grandpa's ICD." Here are the links: 

• How to hack grandpa's ICD - Reprise
• How to hack grandpa's ICD

I receive a bit of flack from some people regarding the unlikelihood of such a thing occurring. I even wrote another article that I never published because I had convinced myself that ICD hacking scenario would be so unlikely. 

Well, it suffices to say that I have changed my mind. It seems that McAfee has take this seriously. Here are two articles for your consideration.

• McAfee hires elite hackers to break into devices
• Next health hazard: Hackable medical implants

After this, I'm publishing the article that I had originally decided not to publish.

Advanced Technology

I mentioned in an earlier article that I have move out of medical devices for the time being.  However, I have moved out of remote monitoring or remote programming (it is called "remote configuration" where I am now.)

We have been given the go ahead to explore a variety of new and what some may consider, off the beaten path technologies.  Although I shall not be able to discuss specific studies or approaches, I shall be able to discuss how some technologies not currently used by the medical and medical device communities might be useful to them.

I shall have periodic updates on this topic from time to time.

Here are some platforms to consider for mobile technology.  (This is not part of the work that I am doing now.  It is more related to my earlier work.)

Useful Verses Usable

This is a discussion that you are not likely to read in usability texts – the topic of useful verse usability, and the value of each. Just recently I had a discussion with someone on just this topic. Furthermore, I have had numerous discussions with others and each time it surprises me that people often do not know the difference between the two and the value of each.

Useful and Usable

If you go to the dictionary, you will discover that “useful” means “to be of serviceable value, beneficial” and in addition “of practical use.” Pretty straight forward.

On the other hand, the definition of “usable” is “capable of being used” and “convenient and viable for use.” Also a straightforward definition.

However, if you probe more deeply into the definitions, you will note that “useful” is the first, necessary quality of a tool or system. It must be useful or why use it? Usable is a quality of a tool or system. However, it is not primary in relationship with the quality of the being “useful.” It is secondary. Necessary, yes, nevertheless, it is still secondary.

The usefulness as a quality of a tool or system is not addresses in HE-75, or any other usability standard that I have encountered. (If any one knows of a standard where usefulness is addressed, please add a comment to this discussion.) Usefulness is assumed.

However, I have learned that in the real world, the usefulness of any tool or system should not be assumed. It should be tested. Furthermore, with complex systems, the fundamental capabilities of a system or tool are often useful. However, not all of the capabilities of that system may be.

I direct experience with a remote monitoring system where the primary or fundamental capabilities of the system have clear use. However, with each release of this system, as more capabilities are added, the useless capabilities may be on the verge of out numbering the useful ones.

Bottom Line

• 
  
  Usefulness is always more important than usability. If it is not useful, it is fundamentally worthless or at best, excess baggage, and a drag on the actual and perceived quality of the tool or system.
• 
  
  Usefulness should never be assumed. It should be demonstrated. I know of too many projects where usefulness was not demonstrated. This lead to capabilities being developed that waste time and money, and can damage reputations.

Gadgets of the Future

An interesting and to some degree a light-hearted article about future systems that could monitor us.  This was published in the Chicago Tribune.


Here's the link: http://www.blogger.com/post-create.g?blogID=1944904461287889974

Medical Implant Issues: Part 1, A True Story

When I started this article, I thought I could place it into a single posting.  However, having written just the first section, noted it's length and how much more there was to write.  Thus, I decided to turn this into a serialized publication just as I am doing with HE-75.  Thus, here is Part 1 ...
 

Part 1: Background Story

Before I dive into the technical details of this issue, I want to tell a true story from my own experience.  It involves a friend of mine.  (I need to be vague regarding the person's identity including gender and how I came to know this person.  As you read this, you'll understand.) 

My friend was incredibly intelligent (e. g., the best applied statistician I have ever known) and physically attractive, and diagnosed as a paranoid schizophrenic.  In the early 1990's, my friend underwent back surgery.  To my amazement, my friend claimed that the surgeon had placed a "chip," small processor into the person's spinal cord.  My friend said that the chip could be activated by people with controls that looked like garage door openers.  When activated, the chip would cause my friend to have a sudden, overwhelming desire to have sexual relations with the person who had activated the chip.  My friend called this chip a "tutu."

At the time I had been part of the cutting-edge technology community to know that such a chip was absurd.  And I told my friend that this chip did not exist. My information was not well received by my friend who was convinced of the reality of this chip.

I tell this story because at the time my friend informed me of the "tutu," the idea of embedding a chip in a human being and activate it using wireless means was patently absurd.  Embedding programmable chips with wireless communications less than a decade and a half later is no longer considered absurd, but real.  And for some people, frightening with religious overtones.  Consider what the Georgia state legislature just passed and you'll understand what I mean.  Here's a link to that article: Georgia Senate Makes "Mark of the Beast Illegal."


The reaction from the Georgia Senate makes my paranoid-schizophrenic friend's story seem plausible.  Interestingly enough and I did not realize it at the time (but I do now), that was my introduction to wireless, medical remote programming.  As I said, my friend was extremely intelligent and as it turned out more creative and prescient than I realized at the time.  Turns out that today a device embedded in the spinal cord with the ability to trigger sexual experience is real.  And the ability to embed microprocessors and controls in people with the capability of wireless communication and medical management is also real.


I tell you that story not to make light of people's stories and fears, but as a "sideways" introduction to the technical topic of dealing with multiple, embedded medical monitoring and remote programming systems.  And to suggest that people may have real fears and concerns regarding the capabilities that technologists like myself often overlook.  In this series I discuss real and imagined fears as well as the technical problems with multiple, implanted devices.




Part 2: Multiple, Implanted Wireless Communicating Devices

Books sold by Amazon that might be of interest in this series

New Frontiers in Medical Device Technology

MEMS and Nanotechnology-Based Sensors and Devices for Communications, Medical and Aerospace Applications
 

Remote Monitoring and Preventing Unnecessary ICD Shocks

In 2009 there was an interesting editorial written by Joseph E. Marine from Johns Hopkins University School of Medicine, published in the journal, Europace (European Society of Cardiology).  The title of the editorial was "Remote monitoring for prevention of inappropriate implantable cardioverter
defibrillator shocks: is there no place like home?"  The entire article can be found at the following location: http://www.europace.oxfordjournals.org/content/11/4/409.full.pdf
  
For those of you unfamiliar with ICD's (implantable cardioverter
defibrillator), the ICD delivers a relatively high-voltage shock to the heart when conditions indicate that the heart may be about to go ventricle fibrillation (a rapid irregular heartbeat that will likely lead to death) or that the heart ceases beating.  The latter condition is easily detected, however, determining the former condition is more difficult.  Because the conditions are not always clear, ICD (and a companion system, the CRT-D) too frequently deliver shocks unnecessarily. (I have discussed issues related to detection in other articles in the blog.  Here are the links to those discussions:  http://medicalremoteprogramming.blogspot.com/2009/11/remote-monitoring-sensitivity-and.html, http://medicalremoteprogramming.blogspot.com/2009/11/remote-monitoring-update-to-sensitivity.html
http://medicalremoteprogramming.blogspot.com/2009/11/remote-monitoring-predictability.html)  Another reason that an ICD might deliver unnecessary shocks would be because of sensor lead failure or near failure. 


Joseph Marine examined the value of remote monitoring to the prevention of unnecessary shocks.  He concluded that remote monitoring was particularly suited to providing early detection of failing sensor leads.  However, ...

[f]inally, most inappropriate ICD shocks are not caused by
lead failure, but rather by supraventricular arrhythmias, and this
study does not provide any evidence that home monitoring
reduces risk of inappropriate shocks from this cause.

In other words, remote monitoring could not aid with improving the false positive rate - the delivery of unnecessary shocks.

To those who have not been involved with ICDs, it may seem that the delivery of an unnecessary may not be so bad given the alternative, that a failure to deliver a shock will likely lead to the patient's death.  And there are many cardiologists who will argue the case for a "hair-trigger" system - acceptance of false positives, but no acceptance of false negative: that is a failure to deliver a shock when conditions warrant.

However, unnecessary shocks will do damage over time.  Furthermore, those patients who have received a shock describe it as feeling like "... a mule kicked" them in the chest.  I know of situations where patients who a received shocks eventually have the ICD removed. 

So, I want to make the case to the medical device industry that remote monitoring may be the key to solving the false positive problem.  In that the data that remote monitoring systems collect and transmit may lead to better detection and discrimination.  In addition with reference to my article on prediction, remote monitoring may enable physicians to tune ICDs based on specific predecessor events that could enable remotely adjusting the parameters on the ICD to allow better targeting.


I'm not an expert in this area.  However, I know enough about indicator conditions in other areas that can be used to adjust systems and improve their accuracy.

Why the Moniker "RemoteProgrammerGuru?"

For those who have wondered ... there is a story behind why I use the moniker, "RemoteProgrammerGuru."  Any identity that has as part of the name, "guru" could be considered more than a little ostentations.  Here's the definition as provided by Wikipedia:http://en.wikipedia.org/wiki/Guru.

The definition describes someone with "supreme knowledge."  Fortunately for me, the term in India is synomous with "teacher."  For me, the "term" teacher was more appropriate and the role of a teacher came as a surprise.

I was part of a project where remote programming was the technical centerpiece of a proposed solution.  Frankly, I was new to remote programming for medical devices ... as are most.  However, I have a rich telecommunications background including expertise in wireless communications.  (I was the principal investigator on two federally funded telecommunications research grants.)  I know the technologies and I know how things work. 

As it turned out, I knew more about telecommunications than my colleagues who had been working in remote programming for longer than I ... much more.  And I started teaching them, about communications and about remote programming and necessary processes to insure communication integrity.  In effect, I became a "guru," a teacher.

Finally, since remote programming when designed and implimented correctly, involves sophisticated monitoring, I decided to incorporate the term "remote programmer" to represent someone who informs people about remote monitoring and programming.  Thus the moniker, "RemoteProgrammerGuru" was created.

Remote Monitoring/Programming and Diabetes Management

Diabetes management is a personal area of concern for me.  No, I'm not diabetic.  However, my late mother-in-law was.  She had Type II diabetes; however, she was not overweight.  She died of a sudden cardiac arrest that was a direct result of her diabetes.  Although she did a great deal to manage her diabetes, her insulin would swing widely.  Those wide swings damaged her heart muscles leading to a cardiac arrest.  I can't help but believe if remote monitoring had been available to her, that she should would be alive today.

In the past my primary topical area has been cardiac rhythm management.  I plan to broaden my focus. Diabetes management using remote monitoring and even remote programming will be a topical area of increasing focus in this blog.  In later weeks I plan to branch out into COPD.

For those of you who have domain expertise in diabetes management and COPD, I would appreciate your comments.  You can make your comments in the comment area of this blog or email them to me.  Whatever way you feel the most comfortable.

To get things started, I have three links that I would like share.  The first link is a blog article titled, "Finding patterns in diabetes treatment may be key for telemedicine."  The article is a brief discussion about a presentation by Dr. David Klonoff of Mills-Peninsula Health Center and UC San Francisco.  His focus was on Type I diabetics, however, I believe what he discussed has significant implications for Type II diabetics as well.  Dr. Klonoff's interest is technology "...for automatic measurement of blood glucose, automatic dose calculation, and automatic insulin delivery."  From the article ...

For this ideal scenario to develop, five technologies need to be solved, and Klonoff sees printed electronics being used in every one:

• Self-monitoring of blood glucose
• Continuous (and ultimately non-invasive) monitoring of blood glucose
• Alternate routes for delivering insulin rather than needles, such as micro-needles. (Klonoff referred to work being done at UC Berkeley; I saw some demonstrated at the University College Cork/Ireland (PDF poster here) although using traditional semiconductors, not printed electronics.)
• Artificial pancreas
• Telemedicine

 In the quotation above, there are several links.  The one of greatest interest to me and to this forum, is the "non-invasive" link.  This will link you to an article titled, "The Search for Noninvasive Glucose Technology That Works: Where It Stands Now".


The article is a discussion of a need for a means for non-invasive monitoring of glucose levels.  The capability of having a non-invasive means of monitoring glucose levels would go a long ways towards supporting automatic, remote monitoring of glucose levels.  This could be an extension of the body area networks work (BANs).  So if anyone has any ideas in this area, apparently this is a wide open area for invention.

Finally, I want to provide a link to a brief report by the Whittier Institute of Diabetes.  The report is undated, but a brief review of the document's properties indicated that it was created in 2004.  It's not as recent as I would like, however, I believe that it's findings are relevant.  In summary, it showed that even relatively crude means for monitoring diabetes could lead to some positive outcomes at relatively low cost. 

 

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.

Overcoming the Power Connudrum

I have written about the power consumption issue in earlier articles.  I now include a link to another article that discusses further positive developments in towards solving the power requirements problem inherent in remote patient care.  Here's the link to the article: Breakthroughs with Sensing in the Human Body By Dr Peter Harrop, Chairman, IDTechEx

The article discusses the following developments towards solving the power problem.  The two fundamental areas are:

1.  Advancements in reducing the levels of power required for body sensor nets.  
2. Methods for harvesting power: either from the wearer or from the environment.

Developments in power for portable and wearable devices are worth watching because the capabilities of remote patient care are limited primarily by power requirements.  Power requirements for pacemakers, ICDs and CRT(-D)s devices have by in large been met, that is, for those devices where the communications requirements are minimal.  However, as communications requirements increase, so will power consumption. And all indications are that data traffic requirements will increase, thus the need to both find more power and reduce power requirements will increase as well.


I shall continue to publish further developments in this area.

An another article on BANs

Another article on Body Area Networks and the Federal Government's continuing interest in furthering its development.  Here's the link to the article: http://www.informationweek.com/news/healthcare/mobile-wireless/showArticle.jhtml?articleID=224200068

Much of the work seems analogous vehicle telemetry research and development. One of the applications for the technology we developed at Rosetta-Wireless was for the transport of vehicle telemetry over the commercial wireless network in real-time or near real time.  The problem that we solved was handling gaps, faults and multiple types of wireless connections while the vehicle was in motion.  Again, body data will need to be transported over wireless using a robust logical connection to overcome the imperfections of the wireless network and perform the task without burdening the user - an extremely important consideration.

The next article will discuss the implications of HE75 and the means, methods and importance of not burdening or overtaxing the user.

Human Factors Issues in Remote Monitoring and Remote Programming

Series Overview and Background
 
Human factors issues related to remote monitoring and remote programming (remote patient care) will predominate in my postings over the next several months.  If I learned anything while working at St. Jude Medical, I learned the value of human factors engineering in relationship to remote monitoring systems.  Before I discuss what I learned, I want cover a few issues regarding remote patient care.

If you talk to a device clinic clinician, that person will have few difficulties in communicating to you the value of remote monitoring technology.  I heard stories from cardiologists that before remote monitoring technology was in place that device nurses would have to telephone device patients.  The emotional strain on the nurses was so great that device nurses would burn-out in two years.  

Remote monitoring provides a service to patients and their caregivers.  Most patients do not want to come to the device clinic and caregivers would rather that they did not.  Remote monitoring lengthens the time between clinic appointments.  Furthermore, remote monitoring can detect signs of potential problems much earlier than a visit to the clinic.  Remote monitoring can keep patients out of emergency rooms and can provide patients with a better quality of life.  Finally, remote monitoring can lower the cost of care while improving it.


Among the medical trail blazers, there is an interest in remote programming.  The ability to remotely make changes in the operation of a medical device could enable caregivers to be more proactive and provide patients with care where ever they are located, rather than just in the clinic.  This capability significantly lowers barriers and limitations on patients and their caregivers.  Patients can lead more free and independent lives and less tethered to clinic appointments.


Sounds wonderful, doesn't it?  Remote patient care technology does provide the underlayment, the enabling capability.  However, remote patient care system cannot be limited to the technology.  From my perspective working at St. Jude Medical, roles of caregivers and patients have been under valued, misunderstood or neglected in the development of systems to provide remote patient care.  I cannot speak for other medical device manufacturers.  I can say, because this is public information, that St. Jude Medical's remote monitoring system has come under fire because of issues related specifically to the performance and design of the user interface of their remote monitoring system.  

I am not singling-out St. Jude Medical regarding the design and implementation of their remote monitoring system.  St. Jude Medical implemented a beneficial and desired medical system.  However, it appears that they failed to understand two essential elements who are just as essential to the remote care system as the hardware and software.  Thus the current state of St. Jude Medical's remote monitoring system serves as a starting point for the articles that will follow this one.


My next two articles will focus on the new AAMI/ANSI standard HE75 due to be officially released in April 2010.  I cannot quote from the document at this time, however, I can say that HE75 is founded on the basic foundations of human factors. Thus, from that standpoint, there is nothing new about what is contained in HE75. I know several people on the HE75 committee and I can say that they are consumate human factors professionals, and dedicated to the profession. 


I can also say that should the FDA adopt this document (and all expectations are that the FDA will adopt it), the relatively lax approach that FDA approach to usability and human factors will come to an end.  There is a massive body of literature that documents the massive number of injuries and deaths from medical errors, and some of those medical errors can be traced back to poor device designs.  It may well be that the FDA will believe that it is time to "crack down" on poorly designed medical system user interfaces.  Furthermore, medical systems are becoming increasingly more powerful and complicated, thus the capability to do injury to patient will increase.  Thus, the need to insure that medical devices and their user interfaces will meet specific and unambiguous performance standards before being approved by the FDA.


I plan to focus specifically on medical devices related to remote patient care in this blog.  However, I may stray from time to time when there is something that seems particularly relevant or interesting.


I shall not discuss anything regarding future St. Jude Medical products or services in this blog.  However, I can discuss some of the issues I faced in general terms to illustrate points.  I suspect that the experiences I relate will resonate with others.


Next time: Human factors in the research and development of medical devices.

Development of BANS Expected to Accelerate

For those not in the "know," BANs is an acronym for Body Area Network.  It is a technology to capture and transmit body-related telemetry.  The National Institute of Standards and Technology (NIST) has granted the Center for Wireless Information Network Studies at Worcester Polytechnic Institute (WPI) Worcester, MA, $1.2 million over three years to advance BANs technology.  The research will focus on the propagation of radio waves around and through the human body. This could have real potential for the development of robust communications standards to enable medical devices to send and receive data and instructions over wireless networks.  This research is something to watch.

http://medicaldesign.com/engineering-prototyping/research-development/development-bans-expected-accelerate-032210/

Receiving a NIST grant is a significant achievement.  I was the Principal Investigator on a $2 million, two year grant to Rosetta-Wireless.  The NIST vetting process is arduous, but the grants generally fall into the seven figure range over two to three years.  I know that wireless data communication is an important area of interest to NIST particularly as it relates to medical applications, more specifically into the areas of wireless medical monitoring and remote programming.  I know that NIST has continued hopes for a medical application of the technology that my company, my research and development team created.

For those who have an interest in BANs, one of the technical problems is getting the data collected by BANs back to a location where medical professionals can review and evaluate it. And, if need be, make changes remotely in the operation of the implanted medical system (e. g., pacemaker, ICD, insulin pump, etc.).  If you review some of my earlier posts, you'll note that I have described methods to transport data and instructions over the commercial wireless network from and to a patient's implanted medical device. 

I shall continue to bring to light any further developments in BANs.

Revamping the Revenue Generation Model in the Medical Device Industry

My fourth posting on this blog on 29 September 2009 was part of a multi-part examination of Medtronic's remote programming patent (US Patent # 7,565,197 that was granted in 21 July 2009).  I suggested that the patent patent implied two directions in the development of medical devices:

1. The development of a single, common hardware platform based on a generalized processor, similar to TI's low power processor. (Add urls).
2. Medtronic device capabilities would be defined primarily by software.  Furthermore, the patent defines a capability for software to be downloaded to a device, thus defining the capability for updating the software on the device.

We've learned that there are technologies in development that could significantly increase the battery life of devices: maybe at some point eliminating the need for battery replacement all together.

Today, physicians, hospitals and device manufacturers receive the bulk of their payment when a device is implanted or replaced.  Thus, the current business model of device manufacturers relies on primarily on product such as an ICD or CRT and leads.


However, the Medtronic patent suggests the possibility, maybe even the likelihood of strategic shift from a product to a licensing business model. This would suggest a business similar to software companies who charge a flat or yearly fee for the use of software.  Instead of a replacement, the patient receives a software upgrade and the device company receives payment for the software upgrade.  This is one step removed from a pure product to a service-oriented model, but it still treats the software as a product.  Nevertheless, it provides flexibility to the medical device company in that revenue comes less tied to the sale of objects, and more tied to the services provided to the customer.


An even more innovative approach and more in-line with a service-oriented business model would be to have the software redefine the capabilities of the device itself while implanted in the patient.  For example, upgrade an ICD to a CRT-D by changing software.  I do not know the technical, implantation or leads-related issues of doing this, however, from a software standpoint, there should be nothing stopping a device manufacturer who has taken the common hardware design approach.

A pure service-oriented model would change on the basis for the services provided.  Since I'm a technologist and not an MBA who has worked in the device industry for decades, I cannot define all the possible revenue-producing services medical devices with remote monitoring and remote programming could provide device companies.  I can say that the services that medical device companies can provide medical care providers and their patients is becoming less and less tied to the devices themselves. So a more service-oriented perspective in the medical device industry seems warranted.  

It seems apparent that for medical device companies to expand their services and patient-care and management capabilities with information-based services over the communications infrastructure, they are going to have to change the way they receive revenue.  The current business model and means of generating revenue does not provide incentives to companies to expand into information based services given the current product-based revenue model currently in use.  I suspect that in a relatively short time, Medtronic will propose a new revenue model.  I shall be watching for the signs.

Maintaining Communication Security

Having a secure channel is particularly important for remote monitoring and remote programming.  Here's an article that was recently published regarding a company that has taken an interest approach to the problem. Here's the link: Boosting the security of implantable devices.  

I am the inventor of a data communications security technology and a founder of a security company.  (I am currently a silent partner.)  So, I have an interesting in security technology and systems.  In later articles, I'll cover some of the issues regarding maintaining communications security.