Running Medical Device Software on Shared Computers
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.
Neither approach, generalized or detailed specifications, is inherently superior. Generalized specifications provide a lot more flexibility in what computers to buy — and important consideration given the product life cycle for a PC is about 18 months. Detailed specifications limit you to buying a particular make and model that will soon be discontinued, forcing your manufacturer to complete verification testing on new models and possibly making “last time buys” of discontinued models to sell to their customers (until the verification testing is successfully completed).
Coexistence Issues Beyond the Computer
The above information is typically readily available. The trickier part in all this is to determine how accommodating their product development approach was regarding coexisting with other applications on the same computer. These are general purpose computers, and one should not be surprised when a customer wants to use it for more than one thing. Some medical device manufacturers anticipate this need, while some don’t. The framework for software specifications and coexistence is similar to the systems specifications above.
Don’t neglect to consider networking issues. Is the medical device in question intended to operate only on a standalone computer? Can the product “tolerate” a computer that’s part of a network? And if the medical device is a system that actively uses a network, there’s a similar (but more complicated) set of considerations regarding coexistence.
Start with the vendor’s service department (or sales if you’ve not yet bought), and ask for a written document detailing any restrictions there may be regarding installing other software applications on the same computer as the medical device. Also inquire about possible restrictions on running other third party applications at the same time as the medical device. Don’t be surprised if your vendor has a hard time understanding your questions, let alone digging up the answers. Some manufacturers haven’t quite come to grips with the fact that medical devices are becoming information appliances, and not black boxes that they exclusively design and control.
The ability to support third party apps on a PC that’s a medical device is highly dependent on the design approach and verification testing used by the manufacturer. The verification test lab is a frequent bottleneck in R&D departments, so designing products that need to be retested any time Microsoft or Dell make a product change — or a customer wants to run some third party application — is a recipe for disaster.
“It’s the FDA’s Fault”
Don’t be surprised if the FDA comes up as an excuse somewhere along these discussions with device manufacturers — much like it has regarding operating system patches. The FDA does not define how manufacturers must or should specify or design their products. If a manufacturer wants to sell you a discontinued PC because that’s the way they specified it when the product was first developed (and they haven’t gotten around to doing the verification test for a new model), that was the vendor’s decision not the FDA’s. If the vendor chose that route, they can’t just do something else later because they now realize it would be easier — the FDA does insist that vendors follow their own processes. (That’s not to say the vendor can’t make a change like that, they just have to follow their quality system to plan and implement that change.)
In summary, if the medical device manufacturer anticipated customers running third party applications along with theirs, you are free to do so. But you may have to poke and prod and dig to get this answer with some vendors. Those vendors who are obsessively specific and design their products to run on their own dedicated computers may represent a hidden cost if you would like to run them on other computers available at the point of care. This hidden cost can manifest in 2 ways, the incremental cost to buy a dedicated computer, or the added costs to support discontinued PCs and/or running behind on OS patches as part of your enterprise IT infrastructure.