On October 12 the NY Times headline read “Some Users May Lose Data On a T-Mobile Smartphone”. Those phones use software and support from Microsoft/Danger for their data applications. According to the article a “technical glitch” had resulted in customers losing personal information held on at least in part an associated cloud computer service. Another story here by Eric Savitz, led with the question: “So how sure are you that you want all of your data to live in the cloud?”
The precursor to the Times story had appeared earlier in a number of places including here on October 5th. At that time the issue was reported as a loss of data service as opposed to a loss of data, although it was noted that a reset could cause loss of the user's contacts and calendar. On the 11th it was reported here that the data may be lost for good, but then on the 13th it was said here that maybe not all of the lost data was permanently lost. Apparently Microsoft/Danger was being run on a single server.
While there is no direct association of this situation with medical information (unless your doctor’s contact information was among the stored data), it should serve as yet another reminder that the connected world, and its operational software and hardware, is not without its own issues. When new medical applications are being discussed there seems too often to be a suspension of reality with respect to system functionality, data reliability, and data availability. Whether it is “just” an EMR/EHR, or it is more direct functionality (e.g. an alarm or communication system), or even a single device, it must be remembered that software anomalies (a nice word meaning it sometimes doesn’t work) are more common than rare, and that reliance on “the network” to perform as imagined can often be a false reliance.
In case there was any doubt of this, software is a fairly common cause of FDA mediated medical device recalls. The FDA’s recall datebase has a Simple Search function. Entering “software” without date limits brings up 500 hits, the systems maximum. Limiting the search to 2009 (through 10/21/09) on the Advanced Search produces 62 hits. The most recent of these involves a “software bug” cryptically reported as “The … flag is configured incorrectly. The flag is not generated according to system requirements.” A “software update” is said to be forthcoming.
As I have noted elsewhere, the software industry really needs to be congratulated for its use of the term “upgrade” to mean fixing something that was never right in the first place. The second most recent recall had an equally cryptic explanation: “There is a potential safety issue with … 3.0.x software where study split operations are not correctly replicated to a secondary 'shadow' archive”. Of course the software here will also be updated. And one more: “Software issue may result in unintended modifications to treatment.” Mix-ups between patient identification and data or images are also well known.
So as connectivity and EMR/EHR’s continue to be heavily promoted, let’s always pause long enough to do some risk management thinking and reality checks, and not act as if we really believe that new products and systems will have flawless performance, or that their mal-performance cannot have serious consequences. A little failure modes and effects analysis can go a long way here: What can go wrong? What are the consequences of it going wrong? What are the risks associated with those consequences? And what preventive measures do such risks require in order to achieve an acceptable level of safety? And I would add, acceptable to who? And don't forget to back up your data.
The Sidekick meltdown is just the latest cloud computing outage — it certainly won’t be the last.
The dominant paradigm in contemporary IT systems engineering is loose-coupling. Whether you call it “web services”, “cloud computing”, “plug-n-play” or what have you, the advantage is flexibility and openness to rapid evolution. The disadvantage is complexity which neither engineers or managers can truly grasp.
In Sidekick’s case, there’s blame to go around: an over-aggressive Microsoft business manager who overruled her engineering staff, balky computer network components, engineers who didn’t understand the equipment, a poor system design that made backups difficult and so on. Microsoft and T-Mobile management was negligent but in a way it’s hard to blame them for failing to understanding how all the pieces fit together.
“For want of a nail a kingdom was lost.”
As an IT systems specialist I am quite dubious about the prospect of putting mission-critical health care data in “the cloud”, at least at this early juncture.
Sidekick debacle not withstanding, the “cloud” remains a very attractive prospect for healthcare information distribution. The biggest allure of the cloud is the ease of access to data by clinicians regardless of where they are. With the popularization of EHR systems (eg. Google Health) we are already on that path.
However, the biggest lesson that the Sidekick meltdown provides is the need for backups or parallel storage. Cloud may never be a 100% reliable storage medium. There will always be server failures, access problems etc. Therefore, to rely on the Cloud as a primary storage medium (as many Sidekick users did) is pure suicide. Cloud should be thought of as a distribution center, not a warehouse.
Not only in health care but in our daily life, we should always think of
risk management and do reality checks. Also, no matter how old a software or a system may be it will almost always need an upgrade or an update should I say. Also, Prevention is always better than cure. Thus, I agree with Professor William, never forget to back up your data files. Do not rely purely on ‘the cloud’.
I do understand Jeremy’s concern (as an IT specialist) of putting mission critical health care data in “the cloud”, but if we’re not going to do that at this early stage, how could the system managers improve this so called warehouse management software or system?
I agree with Pete, relying purely on the cloud is suicide. But, personally, I am still going to use it. I will just have to have another backup file, both in soft copy and hard copy (on very important informations).