FDA/FCC on Wireless Medical Devices
A public meeting on Converged Communications and Healthcare Devices Impact on Regulation (see here) was convened by the FDA and FCC on July 26-27, 2010. The major topics addressed by panels were (1) Current State of Wireless Health & Lessons Learned, (2) Innovator Perspective, (3) Healthcare Provider, Clinician & Patient perspective, (4) Investor and Research & Development perspective, (5) Reliability – How to Define Quality of Service, and (6) Electromagnetic Compatibility – How to Promote EMC. A complete transcript of the meeting will be forthcoming at the conference link given above, or at www.regulations.gov using the docket number FDA-2010-N-0291. The docket folder currently includes about 35 written comments made in advance of the meeting including from concerned citizens, professionals and professional groups, and major medical device and communications companies.
The stated motivation for this meeting included concern for the proliferation of devices using radio technology as well as reliance on consumer grade communication devices. In part this reflects potentially overlapping regulatory areas with the FCC on the spectrum side and the FDA on the medical device side. In addition to the usual array of medical device performance issues, the radio arena presents the additional challenges of the shared spectrum space, and the suitability of general purpose devices and systems for medical applications.
The major questions addressed at the meeting included data integrity and reliability, medical device and system security issues, allocated and unlicensed spectrum utilization, joint regulatory requirements, and risk management. The latter included the need to define levels of device criticality (which may then correspond to device FDA classification), and potential performance issues in multiple environments.
The FDA and FCC issued an associated joint press release (here) in which they reiterated the generally held belief that innovations in medical device communication “holds significant promise for enhancing health and reducing cost.” They further reiterated that these applications require agencies to assure that such devices operate in a safe, reliable and secure manner, while also encouraging innovation and affording the public the potential benefit of such devices. In part this will benefit from clarity and predictability with respect to the regulations as the agencies fulfill their mandate to protect the public from unsound devices and/or unsound device performance. In this regard it is certainly a challenge to the FDA to both tighten regulations (e.g. with respect to infusion pumps, and likely with respect to the 510(k) process), while also trying to be pro innovation.
Two issues that will have to be resolved here, and for some wired applications as well, are distinguishing real medical devices from health related toys, and where an integrated and regulated medical device ends and a less regulated general purpose communications or computer network begins. The commercial health toy arena has a strong element of regulatory avoidance, which might be acceptable with clear and honest marketing, and some way to exclude date from such devices from being confused with actual medical device data. It should also be clear that a medical device performing a critical function cannot operate at the whims of smart phone and internet performance when we have ample demonstration that these systems are not in fact reliable. Being unable to make a simple phone call, blog or text is one thing while being unable to send important information to a healthcare provider, who is in turn relying on being able to receive such information, is quite another.
Medical Device Interoperability Workshop
There is a FDA (CDRH) Workshop on Medical Device Interoperability scheduled for January 25 – 27 at the FDA’s White Oak Campus in Silver Springs, MD. Here’s a link to the meeting’s official web site, which includes a number of downloadable files on the agenda, meeting logistics and background.
There is little question the workflow automation and intelligence offered by interconnecting medical devices can improve patient safety. There’s also little doubt that there is significant market demand for such solutions. For example, if hospitals could purchase PCA pumps and SpO2 monitors that were interoperable, i.e., the monitor could suspend drug delivery at the first indication of respiratory arrest, such a capability would quickly become a standard of care. Interoperability is a huge opportunity.
There is no doubt that there are unintended — and in some respects, unregulated by the FDA — systems of systems made up of medical devices sold and in use by health care providers. At the most basic level, there are medical devices with serial ports that were never intended to provide connectivity (or Medical Device Data Systems as the FDA called them in a draft rule issued almost 2 years ago). At the other extreme, you have systems like closed loop infusion therapy delivery, made up of components that are both regulated and unregulated, and that were originally developed with little or no thought to the demands of interoperability. This is a problem.
The FDA’s been interested in this area for some time. Way back in 2005, the FDA held a workgroup to discuss the system of systems issue regarding networked medical devices (see the blog posts here, here and here). The outgrowth of this meeting was IEC 80001, which is scheduled to be completed this year. In 2007, the FDA published an excellent draft guidance on wireless medical devices (posts here and here) on how to apply the Quality System regulation to wireless medical devices. (I can’t help but wonder why this is still a “draft” guidance.) Also back in 2007, the FDA provided a rather limp statement on interoperability at the 2007 conference on Medical Device Interoperability and High Confidence Software (see the posts in this search). (Offered as the first example of the FDA’s interest in interoperability is their dubious buy-in to the questionable patient safety benefits of new medical device unique device identification requirements was not inspiring — more here.)
FDA Posts New Draft Guidance on Computer-Assisted Detection Devices
It may be helpful to compare these new guidances with the pending MDDS rule, discussed here, in which the proposed rule defines an MDDS as Class I, the class with the lowest FDA scrutiny. Unlike MDDS, in the current case these CADe devices are not newly defined. However the FDA does acknowledge that the terminology may not widely known or used. A CADe system is not in the same class as an MDDS, and therefore is not an MDDS, because of the degree to which it analyzes medical device data.
The Federal Register posting defines CADe’s as “computerized systems that incorporate pattern recognition and data analyses capabilities (i.e. combine values, measurements or features extracted fro the patient radiological data) intended to identify, mark, highlight, or in any other manner direct attention to portions of the an image, or aspects of radiology data, that may reveal abnormalities during interpretation of patient radiology images or patient radiology device data by the intended user (i.e., a physician or other health care professional)”. As with the MDDS rule, it can be helpful to know what is excluded from the category as well as what is included. Here certain types of systems are defined to not be CADe. These include:
- CADx devices (which) are computerized systems intended to provide information beyond identifying, marking, highlighting, or in any other manner directing attention to portions of an image, or aspects of radiology device data, that may reveal abnormalities during interpretation of patient radiology images or patient radiology device data by the clinician. CADx devices include those devices that are intended to provide an assessment of disease or other conditions in terms of the likelihood of the presence or absence of disease, or are intended to specify disease type (i.e., specific diagnosis or differential diagnosis), severity, stage, or intervention recommended. An example of such a device would be a computer algorithm designed both to identify and prompt lung nodules on CT exams and also to provide a probability score to the clinician for each potential lesion as additional information.
- Computer-triage devices (which) are computerized systems intended to in any way reduce or eliminate any aspect of clinical care currently provided by a clinician, such as a device for which the output indicates that a subset of patients (i.e., one or more patients in the target population) are normal and therefore do not require interpretation of their radiological data by a clinician. An example of this device is a prescreening computer scheme that identifies patients with normal MRI scans that do not require any review or diagnostic interpretation by a clinician.
Impact of Modifying FDA Regulated Devices
Off Label Use
In a previous post, Medical Device System Network Install Issues, I suggested that when health care providers don’t follow medical device manufacturer’s specifications when installing medical device systems they were using the system “off label.” This site’s latest contributing author, William Hyman, provides an alternative perspective:
My interpretation of off-label use has been that it pertains to the actual use of the medical device, not the way it is set-up. Thus it isn’t off-label use until it is actually used, and use here is with respect to the Indications for Use, which do not generally address set-up and configurations as opposed to what the device is for.
Therefore a set-up or installation that is different from the manufacturer’s recommendations/specifications may be a modification rather than an off-label use. Other types of reconfigurations and changes would also be a modification.
Practice of Medicine Doctrine
Off label use is unregulated per the “practice of medicine doctrine,” but comes with some risk management issues. Also please note that this doctrine applies to physicians, not health care provider organizations. According to Hyman:
This is more than a semantic distinction. Off-label use of a medical device, at least by physicians, is legal and unregulated. This of course does not necessarily mean it is safe, smart, or well justified. The defense of an unsafe off-label use (if necessary) would be an after the fact liability matter, not a regulatory matter. However hospitals might be wise to have their own controls on off-label uses and require appropriate justifications.
After some research, I found that there’s very litte published — by the FDA or others — about the issue of post-market regulated device modification, especially by health care providers. Hyman delivers more:
Canada Posts “Medical Device Data System” Rule
On August 31, 2009 Health Canada, Canada’s medical device regulatory authority, posted classification information for Patient Management Software (pdf). This action is similar to the FDA’s proposed rule for the regulation of Medical Device Data Systems (MDDS), nearing finalization. The Canadian announcement begins with a reminder of its definition of “medical device” which is similar to although not identical to the U.S definition. This definition includes Patient Management Software as a medical device. In addition, Canada defines an “active” device as one that requires an energy source, and “active diagnostic device” as one that is intended to supply information for the purpose of detecting, monitoring or treating a physiological condition, state of health, illness or congenital deformity. Based on these definitions patient management software is declared to be first a medical device, and then an active medical device.
The next question is the appropriate classification of this type of active medical device under the Canadian classification system. The Canadian system has four device classifications which is similar to the European system. The U.S., of course, has three classifications.
Patient Management Software that is used only for archiving or viewing information or images, and is not involved in the primary acquisition, manipulation or transfer of data is deemed to be a Class I device. This definition is somewhat more restrictive than that for a U.S Class I MDDS. Any Patient Management Software that goes beyond these restrictions is a Canadian Class II device. Furthermore such software is categorized as an active diagnostic device. This includes software involved in data manipulation, graphing, flagging of results or performing calculations. Workstations that interface with such software are then also in Class II. The inclusion of the work station appears to directly address the illusive question of when does a computer become a medical device. As a result of these new distinctions some software that was previously Class I (in Canada) will now be Class II. The manufacturers of such systems sold in Canada have been granted a one year transition period to meet those aspects of Class II regulation that are different from or in addition to those for Class I. This defined transition period is a more explicit statement than the FDA has provided in the draft MDDS rule.
The distinctions between system functions made in Canada are somewhat different from those initially defined by the FDA for MDDS. None-the-less they reflect essentially the same issues and concerns which are that (1) any software that receives and manipulates patient data is a medical device, and (2) that the appropriate classification depends in part on exactly what the software does with the data. Only minimal data handling activities are in the least stringent regulatory classification, while classification and therefore regulatory scrutiny will increase along with the sophistication of what the software does.
FCC Seeks Comment (Again) on MBANs
Some semi recent news on Medical Body Area Networks (MBANs) from GE Research and the FCC. It starts with GE’s September 1, 2009 press release (pdf), where they announced:
…an intiative aimed to develop wireless medical monitoring systems, or body sensor networks (BSN), which would replace the traditional tangle of bedside caables used to capture a patient’s vital signs. GE’s vision for the systems would enable wireless monitoring from anywhere in the hospital — or even remotely at home.
For the past couple years, GE’s been pushing for the allocation of spectrum for MBANs. The press release notes that, “The FCC recently issued a notice of proposed rulemaking (NPRM), acting upon GE Healthcare’s petition to establish a new, vendor-neutral dedicated radio frequency band for low-power, short-range, wireless patient monitoring devices. This petition requested creation of a new Medical Body Area Network Service (MBANS), to support wireless sensors that monitor a patient’s health state, linked together in body sensor networks.”
Here’s David Davenport talking about their wireless sensor initiative:
Apparently, GE’s going after the cable replacement business for traditional multi parameter patient monitors. LifeSync has had a product replacing ECG cables (by far the most predominate type of cables in clinical use) for several years. LifeSync also controls the Besson patent (licensed to them exclusively by Motorola) that applies to wireless sensor based physiological monitoring.The FCC Notice of Proposed Rulemaking referenced is from June 29, 2009. Another “article” written by a law firm apparently engaged by GE was published March 20, 2009 and outlines:
Proposed Frequency Band: ”identified the 2360-2400 MHz band as the preferred frequency band based on engineering studies showing that MBANS devices can successfully coexist with incumbent operators and users.” I would love to see that coexistence data. In a conversation with David Davenport of GE Global Research that, he told me that spectrum just outside 2.4 GHz was desired because it would enable the use of off the shelf 2.4 GHz components, with only minimal modifications.
