Thursday, June 30, 2011

Are Electronic Prescription Systems Failing to Trap Errors?

A Brief Introduction

Before I jump into the topic of electronic prescription systems, I want to make known how I came across the article I am about to post. I am creating a website that includes a substantial portion of the human factors related work I have produced over the years. That website also includes posting articles on the home page related specifically to human factors - and that includes article related to medical errors: a topic of interest to me.

The new human factors website is not yet ready for viewing. I have just created a usable home page. The bulk of the work is to come. I'll post the address when it's reached a usable state.


What's Going on with Electronic Prescription Systems?


Bloomberg news recently reported the results of a study that indicated that prescription errors are as frequent whether handwritten or written through an electronic prescription system. Here is the address of the Bloomberg article:
http://www.bloomberg.com/news/2011-06-29/errors-occur-in-12-of-electronic-drug-prescriptions-matching-handwritten.html

I have not yet had the opportunity to read the study. However, I shall and I'll continue to update this blog on this topic based on what I find. 


With respect to the Bloomberg article, this quote caught my eye:


"The most common error was the omission of key information, such as the dose of medicine and how long or how many times a day it should be taken, the researchers said. Other issues included improper abbreviations, conflicting information about how or when to take the drug and clinical errors in the choice or use of the treatment, the researchers said."


I have been a human factors professional for a long time and as I read the quote above my jaw dropped. The errors described in the quote are some of the most fundamental and easily trappable and correctable errors. It seems beyond belief that an electronic prescription system would allow a user to make such errors. In the environments where I have worked, I have designed and installed subsystems to insure that users do not make the kinds of errors as described in the Bloomberg article. When I have a chance to read the report, I'll cover specific errors, their detection and correction. And means to insure that patients are not harmed.


Here's a link to another publication that reported on the same study:


http://www.eurekalert.org/pub_releases/2011-06/bmj-oep062811.php











































Tuesday, June 28, 2011

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: 



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.

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