HE-75 Touch Screen Recommendations

I have found HE-75 to be one of the best human factors standards ever produced.  However, I have found their analysis and recommendations regarding touch screens lacking, and out of date.  To place a perspective on the HE-75 touch screen recommendations ... in the late 1980's and early 1990's, I ran a user interface design and implementation project inside of a larger project at Bell Laboratories.  To make a long story short, one of the user interfaces we needed to design and produce was a touch screen interface.  The touch screen used a CRT as a display device and it was as flat as we could make it.  In addition, the distance between the touch screen surface and the display was about 35 mm.  When I read of the issues related to touch screens and the recommendations in HE-75, I experience deja vu and I feel as if I've been transported back to that time.

Some of the most significant advances in user interfaces have been in the areas of display technology and touch screens with respect to hardware and in particular software.  Apple Computer has been a leader in combining the advances in both display technology, touch screen design and touch screen interface software.  I would have expected the HE-75 committee to have incorporated these advances and innovations in touchscreen software into the standard.  However, what I have found appears to me as ossified thinking or ignoring what has transpired.  

People in the medical field are using smart phones with their advanced touch screen interfaces in their medical practice.  Smart phone touch screens and now the Apple iPad have become the de facto standard in touch screen technology.  My previous article related to consistency ... here's a consistency issue.  Is it wise to suggest that medical device touch screen interfaces look and operate in a way different from the accepted standard in the field?  I know this is not a simple question, but I think it is one that will need to be addressed in future editions of HE-75.

The Return: The Value of Consistency

I have been distracted for a couple of months ... working to find and land another consulting contract.  I have completed that task.  However, it is outside of the medical device industry.  I am not completely happy with the situation, however, having a position outside of the medical device industry does afford some freedom when commenting on it.

Another reason for the significant gap between my last post and this one has been that I was working on a long and intricate post regarding hacking or hijacking medical device communications.  The post began to look more like a short story than a commentary.  The more I worked on it, the longer and more convoluted it became.  At some point, I may publish portions of it.

This experience with the article that would never end has lead me to change the way I'll be posting articles in the future.  In the future, my articles will be short - two to four paragraphs.  And will address a single topic.  I think that some of my posts have been too long and in some cases, overly intricate.  I still plan to cover difficult topics, but in a format that is more readable and succinct.

Consistency in User Interfaces

When it comes to making user interface "usable," the two qualities are 1. Performance and 2. Consistency.  Performance is obvious.  If the interface is slow, unresponsive, sluggish, etc. people will not use it.  Or those who are stuck with using it will scream.  Consistency is somewhat less obvious and more difficult to describe.  However, when you encounter a user interface that has changed dramatically on an application that you thought that you knew, you understand the value of consistency. 

Recently, I encountered a newer version of Microsoft Office.  Gone are the pull down menus, the organization of the operations and tools has changed dramatically.  Frankly, I hate the new version.  If I had encountered the newer version of Office as my first encounter with Office, I know that my reaction would be different.  The new version is inconsistent with the older version.  My ability to transfer my knowledge about how to use the newer version is being hindered by the dramatic changes that have been made.  

Consistency is about providing your users with the capability to reapply their knowledge about how things work to new and updated systems.  Operations work the same between applications and between older and newer versions.  In the case of the new version of Word, I am grateful that once I have selected a particular operation, such as formatting, it essentially works the same as the older version.  However, I have tried to use the newer version of PowerPoint and it's drawing capabilities.  I have not yet been successful and am a drawing tool that I know how to use.

Consistency has a side benefit for the development process as well.  When operations, layouts, navigation, etc. become standardized, extending the design of a user interface becomes easier, less risky and less likely to be rejected by users.  The effect of creating consistent user interfaces is similar to having a common language. More on consistency and HE-75 in a later post.

HE-75 Topic: Design First and Ask Questions Later?

I was planning on publishing Part 2 of my Medical Implant Issues series.  However, something came up that I could not avoid discussing because it perfectly illustrates the issues regarding defining and understanding your user population.

A Story

I live in the South Loop of Chicago - easy walking distance to the central city ("the Loop).  I do not drive or park a car on the streets in the city of Chicago.  I walk or take public transportation.

One morning I had to run a couple of errands and as I was walking up the street from my home, I saw a man who had parked his car and was staring at the new Chicago Parking Meter machine with dismay.  I'll tell you why a little later.

Depending on how closely you follow the news about Chicago, you may or may not know that Chicago recently sold its street parking revenue rights to a private company.  The company (that as you might imagine has political connections) has recently started to remove the traditional parking meters (that is, one space, one meter) with new meters.  Separate painted parking spaces and their meters have been removed.  People park their vehicles in any space on the street where their vehicle fits, go to a centralized meter on the block where they parked and purchase a ticket (or receipt) that is placed on the dashboard of the vehicle.  On the ticket is printed the end time wherein the vehicle is legally parked.  After the time passes, the vehicle can receive a citation for parking illegally.  Many cities have moved to this system.  However, this system has something missing that I have seen on other systems.

Here's a photograph of the meter's interface ...

Chicago Street-Parking Meter

 

I have placed black ellipse around the credit card reader and a black circle around a coin slot.  Do you see anything wrong in the photo?  ...

Getting back to the man who was staring at the parking meter ... he saw something that was very wrong ... there was no place to enter paper money into to the meter. 


I was surprised. This was the first time I had ever taken the time to really look at one of these meters.

As street parking goes, this is expensive.  One hour will cost you $2.50.  The maximum time that you can park is 3 hours - translated, that's 30 quarters if you had the change.  You can use a credit card. However, there are a lot of people in the City of Chicago who don't have credit cards.  And this man was one of them, nor did he have 30 quarters.

I have seen machines used other cities and towns, and they have a place for paper money.  Oak Park, the suburb immediately west of Chicago, has similar meters and they have a place to use paper money to pay for parking.  What gives with this meter?

I take the City of Chicago off the hook for the design of this parking meter.  I don't believe they had anything to do with the design of the meter.  I have parked in city garages over the years (when I was living in the suburbs), and the city garages have some pretty effective means to enable one to pay for parking - either using cash (paper money) or credit card.  But I think they should have been more aware of what the parking meter company was deploying.  I think they failed the public in that regard.

I can take the cynical view and suggest that this is a tactic by the private company to extract more revenue for itself and the city through issuing parking citations.  However, I think is the more likely that some one designed the system without any regard to the population that was expected to use it and the city fell-down on its responsibility to oversee what the parking company was doing.

Failure to Include a Necessary Feature

For the purposes of examining the value of usability research - that is, the research to understand your users and their environment, what does this incident teach?  It teaches that failure to perform the research to understand your user population could result in the failure to include a necessary capability - such as a means to pay for your parking with paper money.  

What I find interesting (and plausible) is that this parking meter design could have been usability tested and passed the test.  The subjects involved in the usability test could have been provided quarters and credit cards, and under those conditions the subjects would have performed admirably.  However, the parking meter fails the deployment test because the assumptions regarding populace, conditions and environment fail to align with reality of the needs of the population it should have been designed to serve.

Another Failure: Including the Unnecessary or Unwanted Features   


As I was walking to my destination, I started composing this article.  While thinking about what to include in this article, I remembered what a friend of mine said about a system wherein he was in charge of its development.  (I have to be careful about how I write this.  He's a friend of mine for whom I have great respect.  And, defining the set of features that are included in this system is not his responsibility.)


He said that "... we build a system with capabilities that customers neither need nor want."  The process for selecting capabilities to include in a product release at this company is an insular process.  More echo-chamber than outreach to include customers or users.  As a result this company has failed to understand their customers, users, their work environment, etc.  

Some might suggest that the requirements gathering process should reduce the likelihood of either failure occurring - failure to include or include unnecessary or unwanted features.  Again, I know that in case of my friend's company, requirements-gathering takes its direction largely from competitors instead of customers and/or users.  So what often results is the release of a system that fails to include capabilities that customers want and includes capabilities that customers do not want or need.
   
I don't know about you, but I see the process my friend's company engages in as a colossal waste of money and time.  Why would any company use or continue to use such a process?  


Ignorance, Stupidity or Arrogance - Or a combination?



I return to the title of this article "Design First and Ask Questions Later?" and the question I pose above.  I have seen company after company see design as an end in itself and failing to understand that creating a successful design requires an effective process that includes research and testing.  Failure to recognize this costs money and time, and possibly customers.  It is not always a good idea to be first in the market with a device or system that includes a trashy user interface.

So why to companies continue to hang on to failing processes?  Is it ignorance, stupidity or arrogance?  Is it a combination?  My personal experience suggests a combination all three factors with the addition of two others: delusion and denial.  These are two factors that we saw in operation that lead to the financial crisis of 2008.  I think the people will continue to believe that what they're doing is correct up to the point until the whole thing comes crashing down.

The Chicago Parking Meters has a user interface with poor and inconsiderate design ... inconsiderate of those who would use it.  (If I get comments from city officials, it will probably be for that last sentence.)  However, I don't believe that the parking meter company will face any major consequences such as being forced to redesign and redeploy new meters.  They will have gotten away with creating a poor design.  And they're not alone.  There are lots of poorly designed systems, some of the poor designs can be and have been life threatening.  Yet, there are no major consequences.  For medical devices and systems, I believe this needs to change and I hope the FDA exerts it's oversight authority to insure that it happens. 





Medical Device Design: Reader Suggested Books


One of my readers provided me the following list of books related to usable medical product designs.  I pass this list of three books on to you.  I do not yet have them in my library but these would be suitable additions.

Medical Design Article: FDA announces Medical Device Home use Initiative

As I was working on a human factors related article, this article from Medical Design appeared.  Here's the link to the article: http://medicaldesign.com/contract-manufacturing/fda-announces-medical-device-home-050310/

I thought that this article is interesting and telling with respect to how the FDA will assert it regulatory authority regarding usability issues. Here are a few quote from the article.

Recognizing that more patients of all ages are being discharged from hospitals to continue their medical treatment at home, the U.S. Food and Drug Administration announced an initiative to ensure that caregivers and patients safely use complex medical devices in the home. (My emphasis.) The initiative will develop guidance for manufacturers that intend to market such devices for home use, provide for post-market surveillance, and put in place other measures to encourage safe use of these products. The FDA is also developing education materials on home use of medical devices.

These home care patients often need medical devices and equipment such as hemodialysis equipment to treat kidney failure, wound therapy care, intravenous therapy devices, and ventilators. 

HE-75 Topic: Risk Management

One more HE-75 topic before proceeding into design and design related activities.  The topic, risk management.

Reading HE-75, you will note that this document continually discusses risk management and reducing risk.  In fact, the entire document is fundamentally about reducing risk, the risks associated with a poor or inappropriate design.

If you drive a car, especially if you have been driving cars for more than a decade or two, you will note that a driving a car with well-designed controls and well-laid out and designed displays seems inherently easier than one that is poorly designed.  Furthermore, it has been demonstrated time and again that driving safety increases when a driver has been provided well-designed controls and displays, driving become less risky for everyone concerned.

Car makers now see safety as selling point.  (Look at a car that was built in the 40s, 50s or 60s and you'll note how few safety features the car included.)  Manufacturers are beginning to include in their luxury models driver-error detection systems.  For example, one manufacturer has a system that signals the driver of the existence of an other vehicle the space the driver wants to move to.  One of the qualities of a well-designed user interface is the ability to anticipate the user and identify and trap errors or potential user errors, and provide a means or path for preventing or correcting the error without serious consequences.  Car manufacturers have been moving in this direction.  I suggest that the adoption of HE-75 will be the FDA's way of pushing medical manufacturers in the same direction.


Risk Management: Creating a Good Design and Verifying It


My many blog postings on HE-75 will address the specifics of how to create a good design and verify it, and the process of incorporating these design and verification processes in the a company's risk management processes.  In this posting I want to address a two issues at a high level.


First, I want to address "what is a good design and how to do to create it." Creating a good design requires a process such as one outlined by HE-75.  I am often amused at hiring managers and HR people who want to see a designer's portfolio having no conception regarding how the design were created.  A good design for a user interface is not artistry, it is a result of an effective process.  It should not only look good, but it should enable users to perform their tasks effectively and with a minimum of errors.  Furthermore, it should anticipate users and trap errors and prevent serious errors occurring.  And finally, it should provide users with paths or instructions on how to correct the error.  This is what HE-75 teaches in that it instructs researchers and designs   And to that end, the design process should reduce risk.  Think this is not possible?  Then I suggest you spend some time in the cockpit of a commercial airline.  It is possible.


Second, HE-75 teaches that design verification should be empirical and practiced often throughout the design process.  This is an adjunct to classic risk management that tends to be speculative or theoretical in that it relies on brainstorming and rational analysis.  HE-75 teaches that medical device and system manufacturers should not rely just on opinions - although opinions provided by subject-matter experts can provide valuable guidance.  HE-75 instructs subjects drawn from the targeted population(s) should be used to guide and test the design at each stage of the process.  This becomes the essence of risk management and risk reduction in the design of user interfaces.



Additional Resources

I have this book in my library.  It provides some good information, but it's not comprehensive.  Unfortunately, it's the only book I know of in this field.  
















These books I do not owe, but provide you with the links for information purposes.  I am surprised at how few books in the field of medical risk management there are.  It may go a long ways to explain the large number medical errors, especially the ones that injure or kill patients.

Risk Management Handbook for Health Care Organizations, Student Edition (J-B Public Health/Health Services Text) 

Medical Malpractice Risk Management 

HE-75 Topic: Meta Analysis

The definition of a "meta-analysis" is an analysis of analyzes.  Meta analyzes are often confused with a literature search, although a literature search is often the first step in a meta-analysis.

A meta-analysis is a consolidation of similar studies on a single, well defined topic.  The each study may have covered a variety of topics, but with the meta-analysis, each study will have addressed the common topic in depth and collected data regarding it.

The meta-analysis is a well-respected means of developing broad-based conclusions from a variety of studies.  (I have included a book on the topic at the end of this article.)  If you search the literature, you will note that meta-analyzes are often found in the medical literature, particularly in relationship to the effectiveness or problems with medications.

In some quarters, the meta-analysis is not always welcome or respected.  Human factors (Human engineering) is rooted in experimental psychology, and meta-analyzes are not always respected or well-received in this community.  It is work outside of the laboratory.  It is not collecting your own data, but using the data collected by others, thus the tendency has been to consider the meta-analysis as lesser.

However, the meta-analysis has a particular strength in that it provides a richer and wider view than a single study with a single population sample.  It is true that the studies of others often do not directly address all the issues that researchers could study if those researchers performed that research themselves.  In other words, the level and the types of research related controls were employed by the researchers themselves.  But, again, the meta-analysis can provide a richness and the numeric depth that a single study cannot provide.

Thus the question is, to use or not to use a meta-analysis when collecting data about a specific population?  Should a meta-analysis be used in lieu of collecting empirical data?  

Answer.  There are no easy answers.  Yes, a meta-analysis could be used in lieu of an empirical analysis, but only if there are enough applicable studies recently performed.  However, I would suggest that when moving forward with a study of a specific, target population that the first response should be to initiate a literature search and perform some level of a meta-analysis.  If the data is not available or is incomplete, then the meta-analysis will not suffice.  But, a meta-analysis is always a good first step, and a relatively inexpensive first step, even if the decision is made to go forward with an empirical study.  The meta-analysis will aid in the study's design and data analysis.  And will act as a guide when drawing conclusions.

Additional Resources

Meta Analysis: A Guide to Calibrating and Combining Statistical Evidence (Wiley Series in Probability and Statistics)

How to Hack Grandpa's ICD, Reprise ...

Several weeks ago I published an article (How to Hack Grandpa's ICD) discussing another article published in an IEEE journal that described a variety of ways to hack, illicitly manipulate or modify an ICD.  To those in the know, this is a potentially greater concern than I had imagined.  As it turns out, not surprisingly enough, the concerns about hacking are not limited to ICDs. 

One of my readers notified me of a recent article published by the CNN website that discusses concerns regarding the capability to hack ICDs.  Here's the link to the article that was published on 16 April 2010.  I was also republished in the Communications of the ACM (of which I am a member) on 19 April 2010.


Much of the article appears below Before proceeding, I would like to add a little background about myself and a little bit of commentary regarding hacking.  I am a co-founder of data leak security company, Salare Security (http://www.salaresecurity.com).  If anyone is interested in what the company does, please do follow the link above.  (As of this point, I am a silent partner in the company.  My partners are currently running the business.)  I mention this because I have some real-world based knowledge regarding system vulnerabilities.  

From experience and research I have found that even vulnerabilities that seem unlikely to be exploited, inevitably are exploited.  If something can be gained from a target and a vulnerability exists, you can be assured that the vulnerability will be exploited.  

For example, specific vulnerabilities that Salare Security addresses months ago were considered unlikely to be exploited because of the lack knowledge and a lack of interest on the part of hackers.  However, the vulnerabilities are of significant interest because if exploited, the damage to a government, a company or other organization could be severe.  Nevertheless, the thinking in the industry has been that exploitation of the vulnerabilities over the near term were remote.

However, recently, we have received information that the system vulnerabilities that Salare Security addresses have been exploited by a government funded group of hackers.  So much for "nothing happening in the near term."  

In the case of the vulnerabilities that Salare Security protects ... the hackers were after information.  (I do not know the details of the attack so I cannot tell you what information they stole.)  But, why might hackers develop systems to exploit medical device vulnerabilities?  

My sense is that the hackers most likely are not out to attack, injure or kill people with medical devices.  In my estimation, these hackers would be engaged in an extortion scheme against a device manufacturer or manufacturers.  This suggestion is based on some of the current trends in criminal activity. (Please see: http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1510919,00.html?track=NL-102&ad=763387&asrc=EM_NLN_11442713&uid=6228713)  The article references other possible motives for hacking medical devices.  I would strongly side with any motivation that opens the door for extracting money from a manufacturer.

Here is the article published by CNN

Scientists work to keep hackers out of implanted medical devices
By John D. Sutter, CNN  (4/16/2010)

(CNN) -- Nathanael Paul likes the convenience of the insulin pump that regulates his diabetes. It communicates with other gadgets wirelessly and adjusts his blood sugar levels automatically.
But, a few years ago, the computer scientist started to worry about the security of this setup.
What if someone hacked into that system and sent his blood sugar levels plummeting? Or skyrocketing? Those scenarios could be fatal.  

Researchers say it is possible for hackers to access and remotely control medical devices like insulin pumps, pacemakers and cardiac defibrillators, all of which emit wireless signals.
In 2008, a coalition of researchers from the University of Washington, Harvard Medical School and the University of Massachusetts at Amherst wrote that they remotely accessed a common cardiac defibrillator using easy-to-find radio and computer equipment. In a lab, the researchers used their wireless access to steal personal information from the device and to induce fatal heart rhythms by taking control of the system.

This article references the same IEEE article that I referenced in my blog posting.

"Medical devices have provided important health benefits for many patients, but their increasing number, automation, functionality, connectivity and remote-communication capabilities augment their security vulnerabilities," he wrote.

FDA spokeswoman Karen Riley declined to say whether the FDA is looking into new regulations of wireless medical devices; she added that the responsibility for making the devices secure falls primarily on the manufacturer.

"The FDA shares concerns about the security and privacy of medical devices and emphasizes security as a key element of device design," she said.
Wendy Dougherty, spokeswoman for Medtronic Inc., a large maker of implantable medical devices, said the company is willing to work with the FDA to establish "formal device security guidelines."
The company is aware of potential security risks to implanted medical devices, she said. "Safety is an integral part of our design and quality process. We're constantly evolving and improving our technologies."
In a written statement, Dougherty described the risk of someone hacking into a wireless medical device as "extremely low."

Wireless connections

The security concerns stem from the fact that pacemakers, defibrillators and insulin pumps emit wireless signals, somewhat like computers.
These signals vary in range and openness. Researchers who reported hacking into a defibrillator said some in-the-body devices have a wireless range of about 15 feet.

Many devices do not have encrypted signals to ward off attack, the researchers say. Encryption is a type of signal scrambling that is, for example, employed on many home Wi-Fi routers to prevent unknown people from accessing the network.

Motive

There's some question as to why a person would hack into a pacemaker or insulin pump and how the hacker would know a person uses a medical device.
Maisel listed some possible scenarios in his New England Journal article.
"Motivation for such actions might include the acquisition of private information for financial gain or competitive advantage; damage to a device manufacturer's reputation; sabotage by a disgruntled employee, dissatisfied customer or terrorist to inflict financial or personal injury; or simply the satisfaction of the attacker's ego," he wrote.
Denning, from the University of Washington, said the current risk of attack is very low, but that someone could hack into a pacemaker without apparent motive.
She referenced a case from 2008 in which a hacker reportedly tried to induce seizures in epilepsy patients by putting rapidly flashing images on an online forum run by the Epilepsy Foundation.

I emphasized Denning's comments because in my experience those are "famous last words." If there is a way to profit from exploiting a vulnerability, be assured, it will be exploited.

 

Additional Resources

Hacking For Dummies

Gray Hat Hacking, Second Edition: The Ethical Hacker's Handbook

Hacking Exposed: Network Security Secrets and Solutions, Sixth Edition

Hacking: The Art of Exploitation, 2nd Edition

Hacking Wireless Networks For Dummies (For Dummies (Computer/Tech)) 

 

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 Demonstration System for Diabetes & COPD Available

I want to share the article and it's link to the the demonstration system.  Here are a few quotes from the article.

Health Revolution Sciences Inc. has launched a new Website demonstrating its remote health care monitoring capabilities for perspective patients and care givers.

Called ForVida, the software application represents a sea change in health care technology. 

The software allows physicians and patients to watch streaming cardiac telemetry or reference steadily growing actionable patient EKG and heart rate histories.

The system apparently uses a communication model similar to one I have described in an earlier article.  (http://medicalremoteprogramming.blogspot.com/2009/10/communication-model-for-medical-devices.html)  I do not know what data integrity and security measures they have taken.
 
The article can be found at:
http://www.healthrevolutionsciences.com/2010/04/forvida-demo-up-and-running/

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.