Select Page

Author: William Hyman

Advice from the FDA on Medical Device Data Sharing

Among the many forms of data flow that might occur from a medical device is direct to the patient. This received some notoriety when a patient wanted to access the output directly from their own implanted device. They had to do battle with the device manufacturer who claimed among other things that the FDA would not allow them to make the data available. It turns out that the “FDA won’t let us” is a well known, if not necessarily correct, excuse in a different arena, that of medical device service and repair. The FDA has added some clarification in...

Read More

Connectivity and Hackability

It is somewhat ironic that Hospira and Cerner announced a new collaboration on Hospira’s infusion pumps and Cerner’s EHR given that Hospira has recently had more than its share of attention with respect to asserted LifeCare and Symbiq pump cybersecurity vulnerabilities. This attention included a notice from the Department of Homeland Security as well as from the FDA (here and here). I found it of interest that despite the widespread hype around these notices there has been no recall of these pumps for the related issues. Instead advice was given to transition away from their use, mitigate the risks by some technical...

Read More

Some Funky Cybersecurity Math

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

Read More

The FDA October Workshop on Cybersecurity

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

Read More

DHHS OIG Work Plan Targets Networked Devices

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. The relevant subsection (page 22) is relatively brief: We will examine whether CMS oversight of hospitals’ security controls over networked...

Read More

A Medical Device Recall of an EHR-like Product

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, “…a computer based system which collects, processes, and records data both through manual entry and from monitors which themselves are attached to patients, such as in the operating room environment. The system provides clinical decision support by communicating potential Adverse Drug Event alerts proactively during the pre-anesthesia evaluation and at...

Read More

Legislation Seeks to Deregulate Medical Software

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

Read More

Have You Read a Disclaimer Lately?

Some time ago Tim Gee pointed out that a major vendor for an in hospital communication system included the following statement in its documentation: “This product is not intended for use with patient monitoring devices or other patient care devices. Do not use this product as the primary communications tool in health care environments, as it may use an unregulated frequency band that is susceptible to interference from other devices or equipment.” Of course “primary communication” was exactly why the product was being purchased, and arguably what it was being sold for. When discussing Clinical Decision Support (CDS) (here) I have pointed that it is common for CDS creators to in essence say that one should not rely on the output of the product, but instead always second guess the advice provided. This perhaps approaches a warning that I proposed for a product that I thought was seriously defective: DO NOT USE THIS PRODUCT. Maybe I was being facetious. These examples may pale in comparison to the following disclaimer for medical image processing software: <The manufacturer> ” SHALL HAVE NO LIABILITY OF ANY KIND FOR ANY DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES BASED ON ANY DEFECT, FAILURE OR MALFUNCTION OF THE SOFTWARE, OR USE OF ANY <manufacturer> DOCUMENTATION, WHETHER THE CLAIM IS BASED UPON WARRANTY, CONTRACT, TORT OR OTHERWISE. <Manufacturer> MAKES NO WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, ANY WARRANTY OF...

Read More

Medical Mobile App Draft Guidance Reaches 2nd Birthday

On July 21, 2011 the FDA released its “Draft Guidance for Industry and Food and Drug Administration Staff – Mobile Medical Application.” We have discussed this draft and mobile apps generally here, here, and here. As with all draft guidance documents, following the release of the draft the FDA is supposed to receive and review comments (reported to be about 130), and then issue a revised draft, a final guidance document, withdraw the draft, or do none of these for an extended period, just letting the draft sit. The latter appears to be the  fate of many drafts. The two years that this draft has been out probably qualifies as an extended period. However the FDA did tell Congress, and the public, that the guidance would be released by the end of this fiscal year. Outsiders cannot tell if the appropriate FDA people are hard at work on this item, or if they are distracted in part by other issues. The FDA’s claimed devotion to transparency does not include being able to see how such things are progressing. Once finalized, the guidance document will provide the FDA’s “current thinking” on the subject, but it does not (or should not) officially create any new regulations since new regulations require actual rulemaking. Thus a guidance document is the FDA’s interpretation of the current law and regulations, but is not itself a...

Read More

FDA Offers (draft) Guidance on Cyber Security

The FDA has issued a draft guidance document on the expected content of premarket submissions with respect to medical device cybersecurity.  This guidance targets individual medical devices rather than the network they may be resident on, and it also includes non-networked devices. The FDA notes that both networking capability and  portable media increase vulnerability. The latter issue might be called intermittent or remote connectivity. Guidance documents tell interested people what the FDA’s current thinking is relevant to its regulatory authority, in this case the review of 510(k), PMA and related submissions. A draft guidance is in effect what the FDA is thinking about thinking. Drafts go through a comment period (90 days in this case) after which the FDA contemplates the comments and, after an unspecified time, either issues a guidance document, issues a revised draft, withdraws the draft, or just lets it sit there. Since guidance documents are not requirements, there is standard language that you can use an alternate approach if you can justify it. An open question for me is whether even a draft sufficiently establishes an FDA expectation that should be followed in the interest of a smooth submission review.There are many draft guidances currently under comment or post-comment review, including the long awaited guidance on medical apps discussed here. The current relatively brief draft has three interesting sections. The first defines the cybersecurity issue, the second...

Read More

Recent Tweets