Medical Connectivity » Standards & Regulatory

Medical Device Interoperability Workshop

Tim Gee — Sun, 17 Jan 2010 23:59:28 +0000

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.) (more…)

FDA Posts New Draft Guidance on Computer-Assisted Detection Devices

William Hyman — Mon, 09 Nov 2009 17:03:16 +0000

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. (more…)

Impact of Modifying FDA Regulated Devices

Tim Gee — Sun, 25 Oct 2009 19:47:46 +0000

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: (more…)

Canada Posts “Medical Device Data System” Rule

William Hyman — Wed, 14 Oct 2009 16:44:11 +0000

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

Tim Gee — Thu, 24 Sep 2009 05:48:34 +0000

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. (more…)

Medical Device System Network Install Issues

Tim Gee — Tue, 22 Sep 2009 16:37:19 +0000

Last week there was an interesting discussion on the Biomed Listserv about network installation for patient monitoring systems. Emphasis highlighting key issues and best practices are mine. The discussion started with a question from Scott Skinner:

I’m curious if anyone has been successful using their own vendors to pull cables for monitoring installations. With the monitoring OEM we work with, they simply get a local subcontractor to do the cable pulls.

So this would involve breaking future monitoring packages up into two quotes: one for the actual technology itself (and associated installation and implementation), and then one for just the cable pull work. The latter would get bid out, and the OEM could compete against other vendors.

Of course, the OEM can just take the profit they would have made on the cable pull and add that to the cost of the equipment bid. One would need to find a way to watch that carefully.

Which lead to a critical observation from Craig Muehling:

We have started pulling our own cable for monitoring installations. I have one happening now and I’m not exactly pleased how it’s working out. I won’t mention and names, [vendor name removed] but they make their equipment charges per drop whether you have any drops or not.

I would still like our [networking] vendor to do the networking, ie: install and configure switches and physically plug patch cables into the switches. Seems easy, but the way they [the patient monitoring vendor] charge it’s really not much less than if they did the whole job. I think from now on, we will have to take on the entire networking job.

I have learned a lesson from this last installation and will scrutinize the quotes closer from now on, but with their charging structure
(supposedly) there’s not a lot of options. Either we do the entire job, or they make lots and lots of money for relatively little work.

Here’s how they do it at the Mayo Clinic, from Steve May:

We have our own low voltage and high voltage contractors for all in-house cable pulling, to include data pulls and all project related work, so cable pulling and wiring costs are never part of an installation package, but an infrastructure cost which we earmark as Capital expenditures and plan/budget annually. Bids & labor costs are renewed by Purchasing every 2 years and our preferred contractors are all able to bid on both project services & time & material services. (more…)

Running Medical Device Software on Shared Computers

Tim Gee — Sun, 06 Sep 2009 23:52:00 +0000

The following question came up on the biomed listserv:

Has anybody wrestled with the idea of placing patient-care applications on the laptop COWs (Computers on Wheels) in Hospitals?

There is a new series of USB-connected Ultrasound transducers that can do many ultrasound procedures, including Bladder Scanner functions. It operates on any laptop, when loaded with the manufacturer’s software. I can foresee many other patient-care functions vying to share the computers already in the patient vicinity.

Any guidance on this subject?

Here’s my reply:

As others have pointed out, you are right to be concerned about the safety of mixing regulated medical device applications and applications from any other source on the same computer. Moving forward without the proper information does expose your hospital to additional risk. At minimum you may be using the device “off label” if you unwittingly fail to follow the manufacturer’s instructions. (Note that the FDA’s interest in “off label use” centers on patient safety, where manufacturers may promote products for uses they were not designed and tested, or when manufacturers make an application with an easily cleared intended use knowing the market will buy and use the product for a more difficult intended use.)

You will need some information from your medical device vendor with the USB scan head and associated software.

Questions on General Purpose Computers

How specific are their specifications for the computer (hardware configuration, operating system, any additional libraries or applications) that is used to run their medical device?

Regardless of how specific their specifications may be, you must use and maintain your system (the USB scan head heads, application software and general purpose PC) in accordance with the vendor’s directions for use, or you will be using the system “off label.” The actual specifications can be high level, indicating a PC of any make or model as long as it includes a specific processor class and minimum speed, and meets minimum required memory and disk space, and a minimum version for the operating system. Alternatively, the vendor may be obsessively specific, calling out computer manufacturer and model, the specific CPU, the required version of BIOS, and even specific versions of operating system components. (more…)

Final MDDS Rule Expected Soon

Tim Gee — Sun, 03 May 2009 21:08:32 +0000

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. (more…)

Facing FDA Regulations for the First Time

Tim Gee — Sat, 14 Mar 2009 00:53:03 +0000

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?

(more…)

Interoperability - Barriers to Adoption

Tim Gee — Fri, 31 Oct 2008 19:50:25 +0000

There’s been some great comments on the recent post about the announcement of MD FIRE. That plus some other activities I’ve been involved in have inspired some thoughts on barriers to adoption for medical device interoperability.

For this discussion, interoperability refers to the ability of a medical device to be controlled by another medical device or third party information system. Medical device systems from a single vendor frequently include interoperability between the medical devices and applications running on general purpose computers, but since all the components are from the same vendor I’m excluding them from this discussion.

Like everything else, medical device interoperability will walk before it runs. In a recent comment, JimW suggests that MD FIRE’s focus is on driving the adoption of, “tightly coupled, low latency, deterministic connection[s].” I beg to differ; I found the MD FIRE text to be very general and that it avoided any kind of design solution whatsoever. Further, it is interesting that what little multi vendor interoperability that is actually on the market, is based on “tightly coupled, low latency, deterministic connection[s].” The example that comes to mind (actually the only one I can think of right now) is the use of CANopen to integrate radiographic equipment with contrast injectors in diagnostic imaging. Perhaps someone can provide additional examples.

Jim is right that such interoperability presents considerable product design and verification challenges, which is why I think that a different kind of interoperability will broad gain market traction before designs with tightly coupled deterministic connections. If you’ve heard Julian Goldman speak on this topic, he provides numerous examples of interoperability that revolve around simple safety interlocks like:

Using a patient monitor to cease therapy delivery (and sound an alarm, of course) on a PCA pump when respiratory arrest is detected,
Linking a heart lung machine and ventilator in surgery to ensure that one is turned on when the other is turned off, and
Linking diagnostic imaging with a ventilator to ensure ventlation is restarted after it is stopped to reduce motion artifact during imaging.

A portion of the 500 patients who die unnecessary deaths every day in U.S. hospitals are killed because simple safety interlocks like these don’t exist. Why? Clearly such interoperability is not rocket science.