As more hospitals and clinics plug patient monitoring equipment and other devices into traditional data networks, the closer the U.S. Food and Drug Administration (FDA) comes to regulating the networks as medical devices.
Currently, most hospitals and clinics manage medical devices on discrete networks to better ensure the safety and security of those systems. But there is a trend toward consolidation, particularly onto wireless networks, for easier management.
"We're trying to get away from separate networks and put those medical devices on the IT backbone; the problem is that backbone has never been tested to support these medical systems," said Rick Hampton, wireless communications manager for Partners HealthCare System in Boston.
In 2008, the FDA released its Medical Device Data System (MDDS) proposal, which is aimed at reclassifying health IT. The proposed regulation would define medical devices as anything that provides electronic transfer, exchange, storage, retrieval, display or conversion of medical device data without altering the function or parameters of any connected device.
"If you take a thing and connect that thing to a medical device as defined by the FDA and that thing extracts medical data as defined by the FDA ... and it takes that data and transports, displays, stores or manipulates that data, then that thing is a medical device," Hampton said.
Partners Healthcare, which includes Massachusetts General Hospital, Brigham and Women's Hospital, and Data-Farber/Partners CancerCare, is for now keeping its medical devices on stand-alone wireless networks, according to Hampton. But that's frustrating for IT administrators who would rather manage all of their wireless networks as a single system for convenience. At the same time, "most IT departments look at being regulated with quite a bit of disdain. Being a regulated medical device, you can't make changes to those networks willy-nilly," Hampton said.
The FDA encouraged the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) to form a joint working group to draft a standard that addresses management risks associated with medical IT networks. After years of work, the IEC 80001-1 Risk Management Standard was finalized in November by both the IEC and the Association for the Advancement of Medical Instrumentation.
The standard is aimed at protecting patient safety, patient data security, and effectiveness of care, said Karen Delvecchio, the lead systems designer with GE Healthcare. "Those three things all have some risk associated with them in medical IT networks, and in fact they need to be balanced. Often we do things to increase effectiveness that brings safety risks. Or we may increase security to the degradation to safety risks or effectiveness."
IEC's 80001 standard defines three key areas of risk management, according Delvecchio. The first addresses risk levels to patient health. The second is effectiveness, or the ability of a healthcare organization to perform its duties. The third Is data and systems security, which addresses a network's ability to protect sensitive patient information.
"A lot of people have actually been looking forward to  because it organizes how to address risk management. It organizes the roles and responsibilities," Delvecchio said.
The standard, for instance, deals with such issues as electromagnetic compatibility between electronic devices and defines the requirements for risk management of IT networks that incorporate medical devices. However, the standard does not specify acceptable risk levels and adherence isn't mandatory, at least not officially. The FDA typically takes a carrot-and-stick approach to pushing standards compliance.
"You can follow joint working groups' standards or not. If you follow them, then you get to collect money from Medicare and Medicaid. If you don't comply, then you have two choices. You can have the federal government come in and inspect your hospital, or you can decide not to accept money from Medicare or Medicaid," Hampton said. "Voluntary sometimes isn't exactly voluntary."
Last year, Jeffrey Shuren, director of the FDA's Center for Devices and Radiological Health, informally spoke before the policy committee (download PDF) of the U.S. Office of the National Coordinator for Health Information Technology. During that meeting, he discussed the possibility of regulatory oversight for health IT software.
According to Shuren, the FDA last year received reports that six patients died and 44 people were injured as a result of health IT-related malfunctions. The FDA also received 260 reports of malfunctions that had the potential to harm patients.
"Because these reports are purely voluntary, they may represent only the tip of the iceberg in terms of the ... problems that exist," Shuren said.
Todd Cooper, a member of the ISO and IEC joint working group, said the group is currently working on three follow-up documents to the new standard. Those documents, due out later this year, will focus on wireless networks; step-by-step risk management for healthcare organizations; and issues involving the communication of security risks and requirements.
Cooper, who started a healthcare IT consultancy called 80001 Experts LLC, described the wireless network convergence in the industry as "a complete mess.
"In fact, some people have said wireless is one of the technologies that forced the hand of 80001-1," he said. "With wired networks you can always lay new cable ... because you can guarantee better system effectiveness. With wireless you can't do that. You only have so much spectrum."
The cost of adhering to the standard could be significant. For example, hospitals will have to designate a risk management facilitator to develop processes and procedures and analyze what has or has not already been done. "The purpose of that is to expose what hidden risk has not been thought of yet," Delvecchio said.
Hampton recognizes that, before they can converge medical device and data networks, hospitals need a list of the requirements a network must meet in order for medical devices to work safely and effectively. And staff need to be trained to maintain those networks.
"Now we have to know as much about our IT network as we do about our medical device network," he said. "I'm here to tell you there's a huge gap in information that I can get from the IT world. Most IT vendors I've talked with, their notion is that 80001 doesn't affect them because they're not a medical device manufacturer. But, it's not what you think you are, it's what the FDA thinks you are."
"Some hospitals have either not gone forward with the wireless network convergence or greatly constrained what they would have done. Others have gone ahead with integrating medical device alarms on their wireless devices and perhaps even turned the alarms off at the bedside, which is a no-no from a regulatory standpoint," Hampton said.
In 2002, for example, CareGroup Healthcare System in Boston lost its entire data network for four days due to physical, unmanaged changes. But its medical devices continue to work because they used a separate and discrete network.
"Had they had a truly converged network, their medical devices wouldn't have worked either," Hampton said.
Delvecchio said the medical community is keenly aware of the problems and dangers associated with converged networks -- including the unanticipated consequences when medical or communication devices are added. For example, an OS upgrade or a security patch can cause a clinical application to go down.
"I've been to meetings of biomedical engineers. If you ask them if there are any cases where IT has disrupted patient care, all their hands go up," she said. "Sometimes it happens during the network design phase. Or, it could be patient monitors, or some kind of alarming system, and when you fire it up something else breaks."
Lucas Mearian covers storage, disaster recovery and business continuity, financial services infrastructure and health care IT for Computerworld. Follow Lucas on Twitter at Twitter @lucasmearian or subscribe to Lucas's RSS feed Mearian RSS. His e-mail address is email@example.com.