Medical Devices: Mitigating Risks

The U.S. Food and Drug Administration should take specific steps to help improve the security of medical devices, says Sharon Finney, data security leader at Adventist Health System.

Finney, who manages the data security strategy for Adventist, a 44-hospital system, says regulators should develop a framework of "minimal necessary" security protections for medical devices.

"If they put some minimum baseline security standards around medical device systems, then I think that would help," Finney says in an interview with HealthcareInfoSecurity (transcript below).

However, to accommodate innovation by device manufacturers, Finney says she wouldn't want to see regulations that drill down to the finest details. "Manufacturers have to be allowed some flexibility in their design and their architecture to build some of these devices and to continue to improve them," she says.

Finney also stresses that healthcare organizations need to assess and mitigate security risks for medical devices just as diligently as the do for other information technology.

We mitigate medical device risks in the same way we do with any device that comes in and rides our network; stores, processes or transmits electronic PHI [protected health information]; or interfaces with our electronic health record," she says.

In the interview, Finney also discusses:

• The security risks posed by medical devices;
• How Adventist secures and monitors user access to medical devices.
• How the organization tracks mobile medical devices.

As corporate data security officer, Finney sets Adventist Health System's data security strategy to ensure the confidentiality, integrity and availability. Before joining Adventist, Finney spent four years in healthcare security management for Dekalb Medical Center in Atlanta, Ga. She also worked for major U.S. organizations as an information technology consultant, where she developed skills in compliance and risk management and technical expertise in system architecture, database administration, data migration and security.

Medical Device Risks

MARIANNE KOLBASUK MCGEE: What sorts of security risks do medical devices pose to your organization and why?

SHARON FINNEY: I think it's important to note the evolution that has occurred in medical devices over the last 10 years. Normally, we're not actually dealing with a single medical device or even a stand-alone medical device any longer. These come in as medical device systems now. [They can be] individual smart devices that communicate back to a central controlled workstation, a controlled server environment or storage mechanism, and then communicate to the electronic health record. Or they come in smart enough to communicate directly [with] the electronic health record. devices today are no longer really just devices. They're very purpose-built smart computer systems.

Mitigating Security Risks

MCGEE: How does your organization mitigate security risks posed by medical devices? Are different medical devices handled differently, and what are those risks?

FINNEY: In this instance, first off we mitigate security risks posed by medical device systems in the same way that we do any other system that's going to come [into] our network; store, process or transmit electronic protected healthcare information; or interface with our electronic health record system. We view these devices and these device systems no differently than we do any application, network device or other [technology] that may come into our environment.

Are different kinds of medical devices handled differently? Definitely, because no two medical device systems are necessarily exactly alike. Different systems - depending on how they're designed, architected and deployed on your network - represent different risks to the environment. We actually analyze each system as it comes through our door. We have a formalized security questionnaire that we ask of the vendors to complete. Not all questions apply to all vendor systems, but it's a good mix of that.

Then we have certain standards that we like for the vendors to be able to adhere to when they're going to be placing [devices] on our network. When they can't adhere to those standards for [what] could be any number of reasons, then we have a set of established ... compensating controls that we try to put around these various systems. [This] continues to minimize the risk not only to our environment, for maybe a security control that they cannot meet, but also to protect that system that in some cases can be very important to clinical care.

Handling Patches, Anti-Malware

MCGEE: How do you handle medical device operating system patches and anti-malware? There seems to be some confusion on whether or not end-users, hospitals or healthcare organizations can make these changes to these devices after they have been approved by the FDA.

FINNEY: There has always been confusion around this point, and so I did a great deal of research about two years ago on this particular topic. The FDA certification of biomedical device vendors is a very expensive and time-consuming process. There's absolutely no doubt that it's a very costly process for them. Historically, a lot of vendors - when they took their medical device systems through the certification process - did not [have] anti-virus or malware protection installed when they were going through the testing process. That can have a significant impact on whether or not that software could be loaded after the fact to that device. I think most major biomedical vendors have probably overcome this issue or are prepared to work with the hospital or the healthcare entity in how they deal with it.

This is a topic that we generally try to cover with the particular biomedical device manufacturer early on in the process of adopting their particular systems in our environment. We have a discussion with them up front that talks about how we ensure that these devices are as protected as they can be. We definitely don't want to violate any kind of FDA certification any more than the vendor does. So we want to make sure that we work very closely with those manufacturers to understand: Who's going to patch what and how frequently are devices patched so that, from a security perspective, my team can interpret where there's going to be potential risk? If they don't load critical security patches to a hardened OS device within 60 days of the device coming out, I know that I've got some vulnerability there. Therefore, I'm going to apply different compensating controls around that particular system to mitigate that risk as much as I can. We continue to work very closely with our medical device suppliers to work through the problems and issues of maintaining these devices on our network in a safe and secure manner.

Securing User Access to Devices

MCGEE: How do you secure and monitor user access to these medical devices?

FINNEY: For the most part, the access to the medical device itself is not always a user-driven access. It depends on the particular medical device and the system and the architecture of it. In some cases, we may have a console system where many medical devices of a particular type are going to report back to a centralized console with a piece of software that actually comes from the medical device manufacturer. [In that case] we may have to create user IDs and passwords. We generally like to use individuals within the specific departments that manage these systems - lab, pharmacy - as we will designate a liaison or a subject matter expert in that particular department that will help us manage creating user IDs, deleting user IDs or terminating access when it's no longer necessary.

Wherever possible, we want the software that comes into our environment to be LDAP-compliant so that we control it through Active Directory groups that are here for automated provisioning and de-provisioning. But that's not always possible. If it's not, then we will manage it in a one-off fashion with the particular department that's going to be utilizing the system, because nobody knows better when users are going to come on and when they're going to come off more so then the department that's actually running the software.

As far as audit ability, [for] most of the systems that we're bringing in today, we try to ensure that they have, at least, minimal audit capability that adheres to the current regulatory standards if they're going to be storing electronic protected health information. A lot of times they will not store extensive amounts of the information and they don't retain it for long periods of time. That has a little bit of a different audit requirement or retention-of-logs requirement than a system like a full-blown EHR that's going to be retaining huge amounts of information.

Tracking Medical Devices

MCGEE: Since many medical devices are mobile and they're moved around patient rooms, how do you keep track of these devices?

FINNEY: We're actually looking at a couple of different technologies. Of course [there's] RFID tracking. I don't think there's any hospital today that doesn't have a very large wireless network presence in their facility. We're actually looking at how we use that wireless network and RFID tagging, or other tagging ... to do asset control and maintenance in the environment.

Advice to Vendors on Improving Security

MCGEE: You mentioned how you work with medical device vendors. How would you suggest that these vendors improve the security of their products overall?

FINNEY: I think they just need to continue down the path that they're on today, which I've seen with some of the most recent acquisitions that we've done of wireless pumps, IV pumps, and smart pumps, where I've really seen the vendors ... considering security in their design and architecture. As I stated, [the] process for them to become FDA-approved and FDA-certified, from a medical device perspective, is a very long and arduous process, and I do see them starting to build that in. If I had some suggestions for them it would be [to] better engage their user community to get feedback on what some of the most common security standards and practices are in the marketplace that they serve. Continue to get better feedback from us; continue to engage us in that process. And I think, over time, we will see it continue to improve as it has in the last five years.

Advice to Regulators

MCGEE: What do you think regulators, such as the FDA, can do to improve the security of medical devices?

FINNEY: I'm not a huge proponent of regulating the things that we should do just because [it's] the right thing to do, but I do think sometimes it's necessary to put a framework around what would be expected or would be the minimum necessary, which is a great word that came out of HIPAA. If they were to develop some minimum necessary security requirements that would be tested through the process of the FDA certification, not only do you have to make a medical device that serves its purpose within reasonable tests, but also are you creating that medical device to serve its purpose and doing that in a secure manner?

If [regulators] put some minimum baseline security standards around medical device systems, then I think that would help. But I'm not sure that I would want to see them regulate down to every bit and byte of what might be necessary in a particular system because the manufacturers have to be allowed some flexibility in their design and their architecture to build some of these devices and to continue to improve them.