What (if anything) can the recent Sidekick problem teach us?
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.