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
On September 4, 2013, the FDASIA mandated workgroup presented their recommendations to the Health IT Policy Committee in Washington, D.C. Some reporting on the meeting cast the draft report as downplaying potential FDA regulation of healthcare IT applications (HIT), while others emphasized the uncertainty (subscription required) of the process and ultimate outcome. Such news stories are, by necessity, short and can’t cover all the issues but this one from iHealthBeat provides a good summary.
The final report (links to all draft documents) was submitted September 4, 2013 and was basically unchanged from the preliminary report.
The question to be answered by the workgroup was how to regulate HIT. I think we’re past the question of whether or not HIT should be regulated: there have been reports of patient deaths starting in 2005 (here and here), and that’s with almost zero reporting requirements on the part of providers or vendors, and the proliferation of HIT vendor non-disclosure and hold harmless agreements to supress reporting (see reports here and here).
The report, also called the “Section 618 report” for the section of FDASIA that mandates the workgroup and their report, is extremely concise and to the point – perhaps too concise for those outside the world of regulated medical devices. Of the three entities, FDA, ONC and FCC that are the focus of the report, by far the most focus was on the FDA. ONC and FCC received minor recommendations. This blog post focuses on the FDA issues and recommendations. You will have to read the workgroup’s recommendations yourself to pick up the specifics regarding ONC and FCC.Read More
A bit more than two years after releasing their draft guidance, FDA has released the final guidance (pdf) on mobile medical apps (FDA press release). FDA also put up a new page on their web site with information on mobile medical apps.
In this final guidance, FDA has chosen to use two factors to distinguish between mobile medical apps that are low risk that they do not intend to regulate, and higher risk apps that will be regulated. FDA will regulate those mobile medical apps intended:
- to be used as an accessory to a regulated medical device; or
- to transform a mobile platform into a regulated medical device.
As always with FDA, the question of whether a mobile app is regulated or not, will be decided on the intended use or claims made by the manufacturer as described in promotional materials, user manuals and similar content and communications.
FDA references two pages of examples of mobile medical apps. The first list includes Class II medical devices that have received premarket clearance (aka, a 510k). Anyone can submit a 510k for clearance for any kind of device – whether FDA really thinks its a medical device or not. Consequently, this list is not an absolute guide to what FDA considers a mobile medical app that they want to regulate. Unfortunately, the page does not include any links to product information or information on the 510k summary for each product. A search on the “K number” in the FDA’s 510k database, e.g., K020866 for Abbott’s Freestyle Tracker Diabetes Management System, will return a 510k summary for the product, including intended use, classification and product code.Read More
On August 6, 2013, FDA published modifications to the list of medical device related standards they recognize. News was made of the fact that additions to the recognized standards addressed areas such as cybersecurity and interoperability. While there were many revisions and some additions of a variety of standards, this blog post will focus on the news making standards related to medical device connectivity.
The published modifications are divided between two separate recognition lists, number 31 (pdf) and 32 (pdf). Here is the Federal Register version (PDF). Recognition list number 31 includes one standard under the Software/Informatics category: Laboratory Automation: Data Content for Specimen Identification; Approved Standard (NCCLS AUTO-7A). The 20+ standards listed in recognition list number 32 are all new additions under Software/Informatics and focus on the following topics:
- IT governance in hospitals for networked medical devices,
- Medical device connectivity and interoperability, and
These are all great standards (although they are of varying relevance and usefulness). So where is the confusion, you might ask?Read More
On August 14, 2013, AAMI reports that the FDA has, “issued a new guidance document on integrating RF technology into medical devices.” You can read the FDA blog post on this guidance here. The draft version of this guidance on RF wireless medical devices was published more than 6 years ago in 2007 (blog post here). At the time, I thought the draft guidance was not earth shattering but a solid example of the application of the Quality System regulation to wireless medical devices.
In order to effectively use this guidance, or the earlier draft guidance, one must have a working understanding of wireless technologies and the FDA’s Quality System regulations. Only then is there sufficient context to be able to properly apply the guidance to the design, manufacture, installation and support of wireless medical devices. Like many initial connectivity efforts, dealing with these wireless issues can be a case of not knowing what you don’t know.Read More