Assessing the magnitude and significance of cyber threats has at least two important purposes. One is to determine the extent of measures that have been or should be taken to respond to or counter the threat. This is part of the rational deployment of resources across the multiple risks that we face, whether cyber or otherwise. In this regard it is simply not possible or necessary to respond to all risks with equal vigor. A second purpose can be to communicate threat significance to or among interested parties. For such communication there is a tendency to reduce complex, multifaceted issues to a simple broad summary word, e.g., the threat level is “Guarded”. Such simplicity is possibly attractive but not necessarily meaningful with regard to what to do with the information communicated.Read More
If it were possible to be unaware of the general problem of cybersecurity, the recent Sony hack with its public disclosures of “private” e- conversations and then terroristic blackmail, following the earlier release of celebrity cloud photos, ought to have provided notice that what is electronically stored is likely to be available to those determined to have it. Moreover we know that cybersecurity can in principle also impact the function and availability of connected systems (Sony again) and/or the information they contain. We also need to be concerned about the malicious alteration of information or disruption of device performance. You may remember the hacked insulin pump story which is already a few years old, and the story that the wireless function of Vice President Cheney’s pacemaker was disabled to protect against hacking.
In this broad context it may be worth taking a look at the FDA’s now posted contents of the October 21-22, 2014 FDA workshop on “Collaborative Approaches for Medical Device and Healthcare Cybersecurity”. There is also a link there to the October 29 FDA Webinar on the Final Guidance on Premarket Submissions for Management of Cybersecurity in Medical Devices. (If that link doesn’t work, as it didn’t for me, try here.) I had not been not aware that October was National Cybersecurity Awareness Month under the auspices of the Department of Homeland Security (DHS).Read More
The Office of the Inspector General (OIG) of the U.S Department of Health and Human Services has released a report (pdf) outlining its 2015 work plan. Among a host of subjects is “Information Technology Security, Protected Health Information, and Data Accuracy” with the subsection “Controls over networked medical devices at hospitals”. The focus here is on the security of patient electronic health information which is to be protected under law. Other risks associated with device networking are not addressed.Read More
The recent recall (links below) for McKesson’s Anesthesia Care system raises interesting questions about potential information system failure modes as well as what system/software functions cross the imaginary line between unregulated EHRs and regulated medical devices.
First the facts. The FDA announced McKesson’s voluntary recall of its Anesthesia Care system in several on-line (here, here and here) postings. This trio of postings is interesting because the first links only to the second, the second does not link to either of the other two. The third also does not link to the other two, and was not part of any of the announcements, but it is the most complete.
The statement of the reason for the recall is that, “There was an occurrence where the patient case data did not match the patient data when the case was recalled in the anesthesia care record (ACR) in that it included data from another case.” It was further noted that, “Use of this affected product may cause serious adverse health consequences, including death.” In the third link the FDA identifies the product as,Read More
Introduced in the House back in October was the wittily named Sensible Oversight for Technology which Advances Regulatory Efficiency Act of 2013 which has the acronym SOFTWARE. Not to be outdone on the creation of legislative acronyms, now comes the Senate version with a bill entitled Preventing Regulatory Overreach To Enhance Care Technology, which of course gives us PROTECT. Both of these bills seek to define and sub-define medically related software, and then to take part of what they have defined away from the FDA, and do something else with it that has not yet been clearly identified.
The premise of these bills is that the FDA inhibits entrepreneurs by peskily requiring, at least in some cases, that the developer meet regulations that are supposed to provide some measure of safety and efficacy before these products are used for or by the public. These issues arise in part because the definition of a medical device does not explicitly include or exclude software. This has allowed the occasional debate about whether and what kind of software is or is not a medical device. The FDA’s position is to simply look at the function of the software and the definition, and then to say that if what the software does meets the definition then it is a medical device. Debating this with the FDA is typically not a fruitful endeavor. Some other countries have explicitly included software, presumably to try to end the discussion. For example the UK explicitly includes “software” in its list of the multiple categories of things that may be a medical device.Read More