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.
Tim, I fully agree with your comments. However, I would love to see more and more “medical devices” becoming software applications that can run on general PCs (and ofcourse, not hog the whole PC to themselves). My dream is to combine software modules from multiple vendors on a single PC workstation bringing diagnostic, therapeutic and physiological information in to a single portal. I believe this is the future of medical technology, and that this will be a reality sooner than we think. One example in this direction is Philips XDS (more on that later).
You are ofcourse correct in recommending caution. Most things we take for granted in general software (OS patches, co-existence with other applications) are generally absent in today’s software “medical devices”. They were designed to exist alone on a very specific PC. In this respect, such software is very similar to software running on embedded systems.
If one is planning to install a “medical device” (software) on a general PC there are many questions that the vendor has to answer:
1. Required specs for the PC, and minimum specs
2. Has the application been tested/verified for the OS (and service pack) that the hospital is using?
3. Can the Application perform to specifications when the PC is logged in to a domain account (as most COWs are), and administered by domain policies?
4. If the application requires login, can the Application authenticate via the hospital ActiveDirectory?
5. Will firewall settings interfere with the Application?
6. Will anti-virus applications, their updates and OS updates interfere with the Application?
7. If the Application is a client-server type application, can it connect to the server via the general LAN, or does it need a dedicated LAN?
8. Will the Application interfere with other applications on the PC?
In my experience, it is not a good idea to attempt to install “medical devices” on general PCs, unless the manufacturer has stated outright that this is an intended use model for their application.
This brings me back to the example of Philips XDS application. When this application was first demonstrated to me, I was awestruck by its potential.
The XDS application is an extension of the intellivue patient monitor that provides a window on the PC desktop to view and interact with the monitor, and communicates patient demographics to any other application that you launch on the PC (eg. EMR, CIS, PACS). Philips has stated outright that the application can be installed by the hospital on general PCs and has provided an installation guide. They have included full instructions for XP as well as Vista, and the firewall requirements to prevent other applications from interfering with their monitor. Philips also states that the application can co-exist with other (also non-Philips) applications, and if required, can share patient demographics with them.
Draeger created a somewhat similar application called Infinity Explorer long time ago, but unfortunately it still remains trapped within a proprietary PC co-existing only with a few selected Draeger/Siemens applications, and cannot login to the hospital domain.
In this regard, Philips has taken a giant step towards making my dream a reality. I hope other vendors will soon follow suit.
In any case you’re talking about having external devices handy. The better option would be to build modular (variable) diagnostics into the bed itself. I’ve just realised, typing this, that that’s what they had in original Star Trek, in McCoy’s Sickbay. It’s beginning to appear as though that was an idea before its time literally as well as metaphorically.
Have you ever been inside a hospital? I mean a real hospital, not a StarTrek movie set.
Embedding hardware devices in to a bed will make the bed extremely expensive. More components mean more points of failure. A single wheel stuck means you lose a bed, a monitor, infusion stack and ventilator. The BME dept will have to be the size of an aircraft hangar to handle all the beds coming in for repairs.
This article and my response to that article concerned loading software components on a PC.
Beds are indeed transforming into more complex electronic medical devices. One interesting example is Hoana with vital sign sensors built into a mattress pad the patient lays on. Just like Star Trek, there’s no wires attaching sensors to the patient.
The top of the line hospital beds come with personal computers built in. While they don’t do patient monitoring (yet) they report bed position and focus on minimizing patient falls.
It is also true that building medical devices into beds is somewhat problematic. Besides the costs that Pete mentions, there’s a more basic challenge with how health care is delivered. Patients are transferred from bed to bed during an episode of care, while many of the medical devices they’re attached to move with them. With the exception of the OR and ICU, patients frequently leave their beds. They also leave their beds for diagnostic tests or to receive therapy, and — to their own and their caregiver’s relief — to go to the bathroom.
This mobility, that’s inherent to health care delivery, limits the kinds of medical devices you can build into the bed.
I read the article on “Bob on medical devices” blog. He argues that Windows based PCs are inherently unable to run multiple device drivers in real-time.
Tim, do you have any idea whether there is any truth to the claim that Windows is unsuitable for running multiple device drivers simultaneously?
It sounds like a typical “Linux fanboy” comment to me. In fact, there was a reply to his post from some guy who claims to manufacture industrial controllers based on Windows, handling up to 32 real-time devices. When I looked in today, that comment has disappeared. Maybe “Bob” doesn’t like to be proven wrong.
I do wonder what Microsoft would have to say on this. As long as there are un-informed individuals like this “Bob” masquarading as experts and spreading panic, we probably wouldn’t see any advancement in technology.
Oops, a small correction. That comment has reappeared with a reply from “Bob”. Maybe it is time I bulldoze my way in there.
In his reply, “Bob” acknowledges that todays systems are indeed capable of doing the required tasks. He adds a rather lame “what if” - what if you install something else that takes up a huge amount of bandwidth (serial interface bandwidth? processor bandwidth? LAN bandwidth - “Bob” doesn’t specify).
One of the things that impressed me most about the philips XDS was that this has been thought of, and taken in to account. Their answer was simple - whenever you install anything new on the PC, run a test. If test passes, they guarantee their system will work. If the test fails, either you “spec up” the PC or remove the new application. That, I guess, would work for me.
What is needed, is for “software device” manufacturers to get out of the mindset that their application will own the entire PC. Applications should be written as good IT citizens (according to the Microsoft definition on MSDN), and written/tested with the assumption that there will be multiple other applications installed and running simultaneously. No application should alter the PC environment to suit itself. With tools like the Microsoft .net framework, it is not difficult to write applications like this.
Philips used to produce “selfish bloatware” (and still does), but I believe this XDS is a step in the right direction and a sign that they have finally realized the future direction of the industry. Many other manufacturers, unfortunately, have not.
Thanks for alerting your readers to these scenarios.
In the industry we follow, cardiovascular ultrasound, blending and merging of product categories is on the horizon, and wireless is near the top of the feature sets in nearly every instance.
-combination of smart phone and ultrasound
We have already of course seen smart phones and charting,e-script applications how long before we merge all three?
-combination of cath-lab table and ultrasound
-Philips, Siemens, GE and MindRay all have monitoring and ultrasound divisions using similar computer components, the difference being the ultrasound transducer.
How long before we see “distributed ultrasound” at the bed side?
The clinician plugs a transducer into the “monitoring station” does the ultrasound exam, un-plugs the transducer and walks to the next bed.
These large manufacturers are eager for this repackaging because:
- customers are demanding it
-they compete more effectively with smaller companies
Thanks for bringing this up - I have a slide in several of my presentations where I detail a product like this and say, “The clinicians love this, however….”
As a clinical engineer, what does one sequester if there is an incident? The transducer, the computer, the network, the server??????
Who does the clinician call if there is an issue? Has there been a ‘behavior/troubleshooting tree’ built so that problems can be easily identified?
What happens if the OS platform for the whole hospital changes? How does that affect the ‘device?’
Who is ultimately responsible for the proper working of the device? I can see a lot of finger-pointing going on with this type of set-up, especially in a large healthcare organization that has many different department responsible for different parts of this ‘device system.’
As an engineer, I’ve learned that one should have one’s measuring device not affect that which is being measured - if there is no intermediate step or display (i.e. on the transducer) to verify if the other parts of the system (not provided by the device vendor) don’t affect the measurement - how do I have trust in that and therefore communicate that trust to the clinician?
Those are only a few of the questions I had, yet they could be ‘make or break’ ones in terms of whether or not the hospital would adopt this type of device.
Frankly, I could see a doctor’s office or clinic more easily adopt this type of device platform right now.
i liked it very much