This story illustrates the security threat presented by devices like imaging scanners, which can contain hidden security risks, according to a recent presentation by representatives from medical device security firm eProtex. Such risks can often be overlooked by IT personnel focusing on more traditional threats to software-based assets like PACS and RIS.
For example, some imaging devices may not be able to run antivirus software, while others can contain hidden electronic protected health information and are vulnerable to infection from a variety of methods, according to Earl Reber, eProtex executive director. As such, institutions need to be aware of the security risks associated with these and other devices and take the necessary steps to remediate those risks, he said.
Reber and eProtex chief security officer Derek Brost discussed the hidden data security risks of medical devices during a talk at the recent annual Healthcare Information and Management Systems Society (HIMSS) meeting in Las Vegas.
Legacy imaging systems
A variety of devices are connected to hospital networks, including older imaging devices, such as Carestream Health's DirectView CR system. Introduced in 2003, the CR reader has an embedded computer that employs the Windows 2000 operating system, Reber said.
"The manufacturer says it can be patched or updated, but [that depends on how] the manufacturer puts out those patches and updates," he said. "What they often do is put those as part of an upgrade, because if it's an upgrade they can charge you for it. If it's a patch or an update, they typically can't."
The manufacturer does not allow for antivirus software to be placed on the device, and the application software is specific to the device, he said. Reber also noted that, as is often the case with these types of systems, the commercialization date for the device may be three to four years behind the introduction date for the operating system.
"All during that process that they were getting FDA approval on the device, all of those patches and updates weren't typically applied to that device by the time it even got to you brand new," he said.
Another example is Siemens Healthcare's Sireskop fluoroscopy machine. Introduced in 1996, it employs the Windows NT operating system, does not receive patches or updates, is not allowed to have antivirus software, and uses one-off application software, Reber said.
Another legacy system still in use is GE Healthcare's 9600 radiography/fluoroscopy mobile C-arm. Based on the MS-DOS 3.3 operating system, it can't receive patches or updates, can't use antivirus software, and is also a one-off application, Reber said.
Medical devices like these can be infected by viruses in a number of ways, including through the network, an access point left by manufacturers that is being exploited, or from a cell phone being connected to the device for charging, he said.
"[Ensuring security] is further complicated by the typical gap that exists historically between IT and clinical engineering," he said. "Clinical engineering is great at dealing with the mechanical aspects of medical device issues. When [they] start talking about the computer that's running it, they get a little less comfortable in that realm."
IT, on the other hand, does a great job at bringing the network to the device's location but is often less than comfortable at dealing with a medical device console application, Reber said.
Today's economic environment demands a reduced risk of downtime and patient diversion, according to Reber. Under HIPAA, mandatory reporting to the U.S. Office of Civil Rights (OCR) for a breach of unsecured protected health information is also required.
Another issue is that medical devices have often been casually treated by hospital staff as general computing platforms for tasks, such as checking personal email, he said.
"At one hospital in Ohio where a couple was dating, the guy sent the gal spybot software. She opened her personal email at work on a radiology device, and all of a sudden he was getting thousands of radiology images and reports," he said. "No intention of getting those or wanting them, but that was the result of the breach."
Increased and sometimes mandatory penalties are in place for breaches, with fines as high as $1.5 million per HIPAA violation per year. The OCR has also taken a broad interpretation of what constitutes negligence, adding the potential for even more fines, Reber said. In addition, enforcement has also been expanded by inviting state attorney generals to participate in enforcement, as well as sharing in penalties and fines.
What can be done?
Numerous groups within the hospital must be involved in the effort to manage medical device security, including IS, clinical engineering, risk management, legal, supply chain, vendors, third parties, C-suite executives, and owners, said Derek Brost.
"The key is to establish some kind of leadership when you're talking about all of these groups and have a line of communication," he said. "I've been to facilities where the clinical engineering director and the IT director have never even spoken to one another."
The leadership responsibility might default to an appointed HIPAA privacy or security officer, which may be fine in a larger organization, Brost said. In a smaller hospital, however, it really needs to be a group effort, because the burden can't be placed on just one person who may already have many other responsibilities.
A good place to start is by examining policies and procedures that need to be addressed. Make sure existing policies are realistic and enforceable; an example of a policy that's neither is one that mandates the use of antivirus software on all systems connected to the network, he said. Some clinical devices are incapable of meeting this requirement.
Brost recommended that all HIPAA implementation specifications be addressed in security policies, and that workflow should be in place for policy exceptions and exemptions.
Know what you have
Inventory and assessment should be performed, beginning by listing what devices the institution thinks it has. Then find out what you really have.
"You can't just run a network scan," he said. "You have devices that connect only intermittently, like portable x-ray devices that may connect only for a few minutes."
Staff should go through the entire facility and perform physical assessments for the devices they find, Brost said.
Ownership, operations, and management of the devices should be determined. Systems subject to state and federal regulation should be identified, and vendor responsibilities, approvals, and methods should be documented and established, according to Brost. Business associate agreements (BAAs) should be verified.
Change should then be implemented and communication workflow should be delineated, and the relevant parties made accountable, according to Brost.
Brost noted that risk remediation is an iterative process. At this point, system inventory and risk assessment should be completed, and leadership, community, and communication should be in place.
"Now's the time to use it," he said.
A strategy should be developed that focuses on a specific area, such as laboratory or radiology, or electing to focus on all Windows-based devices first, he said.
"There's a lot of different risk-management frameworks and different ways to go about this," Brost said. "Choose the one that's most appropriate for your staff and resources."
The budget for risk remediation could be separated out by department or combined into a compliance program, he said.
It's not if an incident will take place, but when, he said. Institutions should be prepared for breaches, malware, outages, and emergencies.
Training should be provided to ensure that risk isn't compounding during the incident, Brost said, and partners should be evaluated before an incident takes place.
"That's not the time to find out that a partner doesn't have experience in healthcare," he said.
Afterwards, the incident should be assessed, with documentation and review of the lessons learned, Brost said.