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.)
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.
Final MDDS Rule Expected Soon
In an off the record conversation couple months ago I was assured by an FDA contact that they were indeed working on a final version of the MDDS rule. Then this past Friday, David Bowerman with VisICU said that he’d heard that the FDA was going to publish the final draft in a few months.
After some poking around, I came across this page on SoftwareCPR (by the time you visit the page, the 4/7/09 entry may have scrolled off the page). At the top was this intriguing bit:
At public conferences representatives of the FDA have indicated that the draft Medical Device Data System Classification rule was returned from FDA legal review for clarification of how public comments were addressed. This will delay release of the final rule perhaps 3 – 6 months but it is hard to estimate.
On the same page of news, I saw that John Murray, with the CDRH Software Compliance office, gave a presentation at the recent AAMI Standards Conference on what software is a medical device, how such software is classified, and whether pre market submissions are required or the quality system regulation applies. (An interesting presentation (pdf) that you can download here.) Thinking this may be one of the “public conferences” where “the FDA have indicated” the status and not too distant release of a final rule, I give John a call. Here’s what he said:
- FDA legal had indeed come back with a request to more fully address the public comments in the final rule.
- He described the majority of comments as focused on wanting a better understanding the proposed rule’s definitions.
- Consequently, the preamble will be expanded to include better definitions.
- That the basic rule itself will be unchanged.
- And yes, the final rule is close to being published.
When asked about the 3 to 6 month time frame to finish tweaking and publish the final rule, John declined to site a specific time frame.
Compliance Requirements
The proposed rule includes specific time frames for manufacturers to come into compliance. The draft MDDS rule states that vendors have 60 days after the final rule is published to register with the FDA as a medical device vendor and provide a list of their products. Manufacturers who fall under premarket notification (510k) have 90 days to submit, and 180 days to obtain final clearance. This is not a whole lot of time.
Since the draft rule was published, vendor reactions have ranged from “wait and see,” to accepting the MDDS rule as a foregone conclusion and moving towards compliance. This puts some vendors facing FDA regulatory scrutiny in a bit of a pickle.
Facing FDA Regulations for the First Time
A growing number of organizations — large and small, within health care and outside of it — are facing regulation by the FDA. Those potentially affected fall into 3 camps. All of the examples I’m going to talk about deal with multi vendor systems (or systems using lots of off the shelf components) that become the regulated medical device.
Just what is a medical device? The legal definition of a medical device is,
an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:
- recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them, [i.e., a drug]
- intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or
- intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of it’s primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes.
According to the New Oxford American Dictionary, a contrivance is “a thing that is created skillfully and inventively to serve a particular purpose.” So a medical device can be made out of anything, as long as it falls under at least one of the three bullets above.
Who Is Impacted?
