The issues raised in Tim's post Running Medical Device Software on Shared Computers literally opens Pandora's box. Installation of medical device software on general purpose computers is an intractable problem.
It's very similar to the complications associated with Networked Medical Devices, except worse. An FDA approved device in a changing network environment is one thing. Software that controls a medical device on a PC that is open for the user to install operating system upgrades, applications, and other device drivers is a recipe for disaster.
I don't care how obsessed a vendor is, there is no way for a medical device manufacturer to verify proper operation for all possible hardware and software environments.
With today's PC architectures, the highest risk area is at the device driver level. Running multiple devices that require even modest I/O bandwidth can cause interference that could result in lost or significantly delayed data. This is especially true with Windows XP or Vista that do not inherently provide any real-time data processing capabilities.
I think the best strategy is to provide stand-alone medical devices that have no dependencies on the PC hardware and software that may be available for down-stream data processing and display. This not only reduces compatibility risk, but it can also address mobility issues. With miniaturization and wireless capabilities, the medical device can now travel with the patient.
Also, with Pandora's box safely closed, solving the networked medical device issues suddenly feels manageable.
UPDATE (9/15/09): Here's an interesting take on this subject from the consumer perspective: Should Medical Devices Multitask?
“With today’s PC architectures, the highest risk area is at the device driver level. Running multiple devices that require even modest I/O bandwidth can cause interference that could result in lost or significantly delayed data. This is especially true with Windows XP or Vista that do not inherently provide any real-time data processing capabilities.”
Bob, where on earth are you getting your information from? This might have been true for my granddad’s PC XT, but not anymore. My company designs industrial control systems on embedded Win XP and on Server 2003 that handle multiple (up to 32)simultaneous data streams via serial port concentrators. You just need to spec the device to the level where it can handle it.
@Konrad W I agree that most of today’s consumer-grade PCs are very capable of handling high bandwidth I/O and processing tasks. As you say, all you need to do is “spec the device”. But that’s where the problem lays when you’re sharing the system. Even if the PC and OS are capable of handling your task(s), what happens when the user installs other applications that double or even triple the bandwidth and processing requirements? At some point the device will not be able to handle it.
Dear Bob,
What is required is for the “software device” manufacturers to:
a. write applications that are designed from ground up to be good IT citizens
b. test and understand the processing and bandwidth requirements for the application
c. test the application in conjunction with other applications running simultaneously at different I/O bandwidth, processor bandwidth levels and discover the vulnerabilities
d. provide a diagnostic test that can be run each time the PC environment is changed, to ensure the application still works properly. If it doesn’t, then “spec up” the PC or remove the last application.
You may also wish to read my comments on Tim Gee’s Medical Connectivity blog. I do sincerely apologize for the statement on the penultimate comment, when I thought you had removed Konrad W’s reply.
I don’t think blindly spreading panic based on unfounded belief systems are good for the advancement of technology that people like I have been waiting for a very very long time. I still hope to see it happen during the few years I have left in my (working) life.
Thats why we ship our product with WindowsXP Embedded and we control what is done with our system. No shared access issues.
Pingback: A .NET Application that Never Dies | Bob on Medical Device Software
@Steve:
“No shared access issues”! Fantastic. This is absolutely the best solution – from your point of view and your convenience as a manufacturer. But what about us, the users? We would end up with 20 PCs at the bedside – one from you, one from GE, one from Philips, one from… well, you get the idea.
Grow up and move on with the times, Steve. Your strategy of “we control what is done with our system” would work only if you were the only supplier of “software devices” in the hospital. Maybe you do have grandiose dreams of being in such a priviledged position, but unfortunately, when you wake up from your delusional dreams, you will find that customers are not sheep – they do pick and choose the best systems and devices from different vendors.
If you stick with the pre-historic strategy of having “No shared access issues” because you, infact, have no shared access – your products will end up in the reject pile at our next evaluation. I promise you that. Your arrogant tone in this post has motivated me to make the resolution that I will use whatever influence I have with NHS to make sure that, in the future, interoperability and co-existance of medical applications will become one of the core criteria for choosing such systems in UK. Then, I’m sure, you will discover all sorts of new strategies, like how Philips has finally done with their xds application (which I always cite as an example, not because I am so partial to Philips, but because, unfortunately, it seems to be the only such product in the market).
Pingback: Access to Medical Data: Are PC Standards and PHRs (You) the Answer? | Bob on Medical Device Software
excellent article! security is always an issue when your talking about medical computers and the equipment used to store patient information inside hospital and doctors offices.