For years, we have managed our own clinical networks, whether it is a clinical monitoring system, an electrocardiogram (ECG), or an obstetrics management system. Intensive-care-unit-monitoring networks go back to the early 1970s, long before the advent of the personal computer (PC) or the explosion of the information technology (IT) industry. These systems tended to be proprietary, in which only specific devices from that vendor could be connected to or work on the network. The communication was always one-directional from the monitor to the central station.
I can remember having discussions with vendors asking to be able to interface other systems, like admission, discharge, and transfer, so nurses would not have to enter patient data into the system. They were very reluctant to even consider the proposition. The prospect of live physiological data connected to an uncontrolled environment was just not something the vendors were comfortable with, and, quite honestly, they were unwilling to consider it.
As PCs and networking architecture came of age, the discussion centered on connecting systems to open networks so physicians could view the data from their offices or remote locations. Many solutions were still proprietary and available only from the system’s vendor. As the Windows® operating system (OS) became widely accepted, vendors started offering the ability to make the data available on the hospital network. The Windows OS became an embedded part of many of our clinical devices and systems.
We finally got our wish! Device communication became bidirectional, companies offered an open architecture so other systems and devices could be interfaced, and data could be sent and viewed all around the world.
Hackers and Viruses
If a crystal ball had shown us the real threat of hackers trying to access and exploit open systems and the flourishing computer viruses, would we have made that wish? There is a constant, real threat of computer viruses invading our networks and devices with the sole purpose of disrupting the device’s operation. While there are serious implications to businesses from the attack of a computer virus, the possible effects to a clinical device with live physiological data that is being used to diagnose and treat patients is potentially a life-threatening occurrence.
All IT departments will almost certainly have policies, protocols, and approved methodologies to deal with all of these issues, but when their policies were developed, were clinical devices considered as a part of the equation? Do you know what the policies are and how they impact your systems and devices? As we have previously discussed, the IT policies are often based on general computer hardware. Since our devices are subject to US Food and Drug Administration (FDA) regulations, it may not be possible for our systems to be reconfigured to use a facility’s approved IT protocols.
Security involves risk management. For years, many of us have used a risk-based strategy to determine what to include as part of our maintenance program and how often to perform planned maintenance. When evaluating security risks, you need to consider the flaws or vulnerabilities in the system’s design, the threats from malicious attacks or outside intruders, and the security measures or mitigations to the risks.
As we implement electronic medical records (EMRs) in hospitals, our desire and need will be to network as many of our clinical devices as possible to automatically update patient-charting information and eliminate the possibility of transcription errors. This is a major patient-safety improvement. What types of clinical devices can be placed on the network? The answer is almost any, such as infusion pumps with wireless capabilities to upload drug-library changes and download quality-improvement data; wireless ECG monitoring for acute-care areas; vital-signs monitors to upload results into EMRs; wireless, hands-free, two-way communication devices that can be interfaced with nurse call systems to send patient calls, and—with physiological monitoring systems—to send alarm data; and wireless radio-frequency asset tags that can transmit the device’s location and can be interfaced with a device to transmit available data to the network.
How can you evaluate security issues when you are considering the purchase of a new device or system? The manufacturers’ disclosure statement for Medical Device Security is a recognized tool to evaluate device security. Jointly developed by the American College of Clinical Engineering (ACCE) and the Healthcare Information Medical Systems Society, this tool includes a standard set of questions that need to be asked when evaluating a medical device’s security. Many medical-device manufacturers have completed this form and have made it available on their Web sites. The form is available for download at http://www.himss.org/content/files/MDS2FormInstructions.pdf
Use this form to discuss how the device may impact security measures on the hospital network. Meet with your IT information security personnel to make sure your device and your implementation plans for it do not conflict with current policies. The last thing you want to occur is to get ready to implement a new system or device, only to find out that the IT department will not allow it to be used on the hospital network.
Below are resources, many of which are free to download.
• ECRI and the ACCE have created a comprehensive CD-ROM, Information Security for Biomedical Technology: A HIPAA Compliance Guide, to help health care organizations identify and address information security issues; http://www.accenet.org or http://www.ecri.org
• Cybersecurity for networked medical devices containing off-the-shelf software; http://www.fda.gov/cdrh/comp/guidance/1553.pdf
• Information for health care organizations about the FDA’s guidance for industry: cybersecurity for networked medical devices containing off-the-shelf software; http://www.fda.gov/cdrh/osb/1553faq.html
• VA Medical Device Isolation Architecture Guide; http://www.himss.org/Content/files/VA_VLAN_Guide_040430.pdf
• US Department of Defense Directorate of Medical Material—Medical Device Security; https://dmmonline.dscp.dla.mil/equip/mdsecinfo.asp
• Security Standards: Final Rule, Federal Register Vol. 68, No. 34; February 20, 2003, 45 CFR Parts 160, 162, and 164; http://www.cms.hhs.gov/hipaa/hipaa2/regulations/security/03-3877.pdf
• National Electrical Manufacturers Association; white papers on medical device security; http://www.nema.org/prod/med/security
Remember, it is all about communication and collaboration with your IT professionals. Developing a positive, collegial relationship is the key to success. 24×7
Dennis Minsent, MSBE, CCE, CBET, is the director of clinical technology services at Oregon Health & Science University, Portland, Ore.