Medical Device System Network Install Issues
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.
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.
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?
Interoperability – Barriers to Adoption
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.
Updated Standards Aim to Encrypt Wired Networks
Securing Ethernet networks has not received the interest that wireless LANs have gotten, for a variety of reasons.
Physical layer security is viewed by most IT professionals as a low-priority problem because cables are run behind walls or in ceilings, beyond the accessibility of most people. Wiring closets and data centers often are locked, and anyway, there are easier ways to subvert a network than by recabling it.
With all those open RJ47 Ethernet jacks everywhere, it would seem to me that someone interested in data would just plug in, rather than recabling anything. The aforementioned security is done with encryption, and the standards are 802.1AE and 802.1X-REV. The first standard ensures the integrity and privacy of data between peers at Layer 2 (switches and NICs). The second standard, 802.1X-REV is currently being revised to automate the authentication and key management requirements for 802.1AE. If you’re a networking rocket scientist, you can read more about the potential implications for these revised standards here.
With their concerns about security and HIPAA, will health care enterprises move to encrypt the physical layer? Such an option will be increasingly possible, according to this Information Week story from last week (emphasis mine):
You’ll be answering that question in the next few years as two new network security protocols come to a switch near you. Together, these two protocols–IEEE 802.1AE-2006, Media Access Control Security, known as MACsec; and an update to 802.1X called 802.1X-REV–will help secure Layer 2 traffic on the wire. 802.1AE is a completed standard and will be appearing soon in hardware. 802.1X-REV could be ratified as early as the first quarter of next year.
