New York Times Opinion: Why Health Care Tech Is Still So Bad

This was an opinion piece published 21 March 2015 in the New York Times written by Robert M. Wachter, Professor of Medicine, University of California, San Francisco and author of "The Digital Doctor: Hope, Hype, and Harm at the Dawn of Medicine’s Computer Age” also published in the New York Times.

Here's the link to the article: http://www.nytimes.com/2015/03/22/opinion/sunday/why-health-care-tech-is-still-so-bad.html?smid=nytcore-ipad-share&smprod=nytcore-ipad

I have commented on several quotes from the article.

1. "Even in preventing medical mistakes — a central rationale for computerization — technology has let us down. (My emphasis.) A recent study of more than one million medication errors reported to a national database between 2003 and 2010 found that 6 percent were related to the computerized prescribing system.

At my own hospital, in 2013 we gave a teenager a 39-fold overdose of a common antibiotic. The initial glitch was innocent enough: A doctor failed to recognize that a screen was set on “milligrams per kilogram” rather than just “milligrams.” But the jaw-dropping part of the error involved alerts that were ignored by both physician and pharmacist. The error caused a grand mal seizure that sent the boy to the I.C.U. and nearly killed him.

How could they do such a thing? It’s because providers receive tens of thousands of such alerts each month, a vast majority of them false alarms. (My emphasis.) In one month, the electronic monitors in our five intensive care units, which track things like heart rate and oxygen level, produced more than 2.5 million alerts. It’s little wonder that health care providers have grown numb to them."

Comments: Before I read the third paragraph, I was thinking How can you blame the computer when it provided you with an alert regarding the prescribing error that you made? 

It is well known that systems that produce a high percentage of false alarms, that those alarms over time will be ignored or discounted. I consider this is a devastating indictment. We must do better.

I have been a human factors engineer and researcher for decades. One of the mantras of human factors is preventing errors. That's central to what we're about. But if the systems we help engineer generate false alarms at a rate that has our users ignoring the correct ones, then we have failed and failed miserably.

I think the problem of false alarms requires further research and commentary.


2. "... despite the problems, the evidence shows that care is better and safer with computers than without them."

Commentary: This is nice to read, but we as medical technologists need to do better. We really need to follow up on the repercussions of our technology we create when it's deployed and used in the field.


3. "Moreover, the digitization of health care promises, eventually, to be transformative. Patients who today sit in hospital beds will one day receive telemedicine-enabled care in their homes and workplaces."

Commentary: I agree. Of course that's a central theme of this blog.


4. "Big-data techniques will guide the treatment of individual patients, as well as the best ways to organize our systems of care. ... Some improvements will come with refinement of the software. Today’s health care technology has that Version 1.0 feel, and it is sure to get better.

... training students and physicians to focus on the patient despite the demands of the computers.

We also need far better collaboration between academic researchers and software developers to weed out bugs and reimagine how our work can be accomplished in a digital environment."

Commentary: Agreed again. But, I believe that technologist just can't dump these systems into the healthcare environments without significant follow-up research to insure that these systems provide or suggest the correct treatment programs and effectively monitor patients. Investment in systems like these will be cost effective and improve lives, but only if the necessary level of care and follow-up is performed.


5. "... Boeing’s top cockpit designers, who wouldn’t dream of green-lighting a new plane until they had spent thousands of hours watching pilots in simulators and on test flights. This principle of user-centered design is part of aviation’s DNA, yet has been woefully lacking in health care software design."

Commentary: All this is true. And as noted above that it would be a good idea to do more extensive research on medical systems before we deploy them to the field as well. That this is not done may be a regulatory issue that the FDA has not required the kind of rigorous research as performed in aircraft cockpit design. They should require more research in real or simulated environments. Right now, all that appears to be required is a single verification and single validation test before allowing commercialization. I think it would be valuable for regulators to require more research in real or simulated settings before allowing companies to commercialize their products.

Or, requiring more extensive follow-up research. Grant companies the right to sell their medical products on a probationary basis for (say) 1 year after receiving initial commercialization certification. During that year, the company must perform follow-up research on how their medical product performs in real environments. If there are no significant problems ... such as overly abundant number of false alarms ... then the product no longer on probation and would be considered fully certified for commercialization.
However, if significant problems emerge, the FDA could:

a) continue to keep the product in a probationary status pending correction of those problems and another year of follow-up research or

b) it could require the withdrawal of the product from sale. A product that had been withdrawn would have to go through the entire commercialization certification process just as if it were a new product before commercialization and sale would be allowed.


A final thought ... I think there's a reality in commercial aviation that is not true in medicine. If commercial aircraft killed and injured as many people as are killed and injured by medical practitioners, then the commercial aviation would come to a halt. People would refuse to fly because they perceive it to be too dangerous. But, if you're sick, then you have little choice but the clinic, ER or hospital.

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.

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)) 

 

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.

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.
 

Medtronic International Patent Application: Remote Programming of Implantable Medical Devices

Medtronic has an international patent application that extends Remote Programming, particularly, the capability to maintain security and safety of patients.  Before I dive into the details, the authors of this patent application make some very interesting points regarding the value of remote programming.  I'd like to quote a few items from that application.  It provides a clear argument regarding the value of remote programming.

... if the medical conditions of a patient with an implantable device warrant continuous monitoring or adjustment of the device [e. g. a pacemaker], the patient would have to stay in the hospital indefinitely. 

From personal and discussions with others, people want to live at home, not in a hospital or a nursing home.  Remote programming can be one tool that makes this possible even for people with severe, irreversible heart failure.  

Yet another condition ... requires that a patient visit a clinical center for occasional retrieval of data from the implanted device ... .  Depending on the frequency of data collection, this procedure may pose a serious difficulty and inconvenience for patients who live in rural areas or have limited mobility.  ... in the event a need arises to upgrade the software of an implantable medical device, the patient will be required to come to the clinic or hospital to have the upgrade installed.

Consider a patient who lives in the middle of the Navajo Reservation.  The Navajo Reservation (that surrounds the Hopi Reservation) lies in the northeast corner of Arizona and takes in parts of Utah and New Mexico.  To say the least, it is huge, rural and a very long way from any major metropolitan area.  It would be a significant burden for someone living in the middle of the Navajo Reservation to travel to any of the likely places where a device physician would be located.  Remote programming would be a significant help to these patients.

The essence of the patent application

The following quote summarizes the purpose of the patent application.

The present invention is directed toward providing a remote programming method for use with implantable medical device systems that helps ensure safe, secure programming of a medical device in a remote location.

The quote isn't particularly well-written, but it does convey what this patent is addressing: it's addressing the security problem.  Briefly, here's the problem, as it stands, anyone in a device clinic or for that matter, a hospital with a computer log-in who has access to a patient's records or has the ability to perform remote programming is provided with the ability to do virtually anything to the patient's device remotely.  This is a not a safe situation for the  patient and it's a potentially massive legal problem for the device managers.

Medtronic has defined a multi-layered or tiered system whereby certain people are provided with a specific level or levels of authorization.  For example, a clerical person may be granted authorization to review patient records and verify that certain scheduled changes and updates to patients' devices have been performed.  On the other hand, device physicians may be granted full authorization to see and do anything and everything. 

The security system that they propose is not unlike other security systems in the field.  Agencies in the Federal Government, National Laboratories, many companies, etc. all have authorization systems similar to the one being proposed.  The difference is that this addresses remote programming of medical devices.  

The patent application is narrow enough so that I suspect that Medtronic will likely receive an International Patent.  That's assuming that there are no patent applications in the same domain that have preceded the Medtronic application.  It does make clear Medtronic's strong interest in this area of technology.  Patient care is the future of the medical device industry and clearly, Medtronic has clearly recognized this.

Next time, I'll dive into remote programming and issues related to data communication.  I'll intersperse these posts to discuss the Achilles Heel of Remote Programming: Electrical Power.  And a way that this problem might be solved.  Say tuned.  These next posts should be interesting and informative.