Samantha Jacques, PhD, VP of clinical engineering at McLaren Health Care, is concerned about the security risks of medical devices. More and more, bad actors are using devices as a way to access a health system’s network. But it’s not as simple as shutting these devices down when a threat is discovered, as they could be connected to patients, she explains. In this interview with healthsystemCIO Founder & Editor-in-Chief Anthony Guerra, Jacques discusses the security implications of medical devices. Hacks are on the increase and patches sometimes take a year for approval, leaving these devices vulnerable. That’s why, now more than ever, the clinical engineering department and C-suite IT team need to put their heads together — and even involve the board, listen to each other, keep an open mind, have a plan and practice it, she says.
LISTEN HERE USING THE PLAYER BELOW OR SUBSCRIBE THROUGH YOUR FAVORITE PODCASTING SERVICE.
Podcast: Play in new window | Download (Duration: 33:10 — 22.8MB)
Subscribe: Apple Podcasts | Spotify | Android | Pandora | iHeartRadio | Podchaser | Podcast Index | Email | TuneIn | RSS
Bold Statements
There are literally devices that still roll off the manufacturing floor today that have outdated operating systems because the newer operating system has yet to be approved and released by the manufacturer.
If I’m tracking hundreds of patches for hundreds of devices over a year from when they’re released, it’s very time consuming and very effort intensive to figure out what your risk is, where it is, and which one’s the one you need to prioritize to try and really control what’s going on within your environment.
… those CISOs that are out there doing large education efforts to help their population understand and drive home that security is everybody’s responsibility, I applaud you, because that’s fundamentally where, as a society, we’re moving.
Guerra: Sam, thanks for joining me.
Jacques: Thank you very much, Anthony. I’m happy to be here.
Guerra: Excellent. Looking forward to a fun chat. So, Sam, do you want to start off by telling me a little bit about your organization and your role?
Jacques: Sure. So McLaren Health is a 14-hospital system in Michigan and Ohio. And I run the clinical engineering department. So that’s the department that maintains all the medical equipment across all of our 14-hospital system.
Guerra: Very good, maintains medical equipment. We’ll get into that a little more. But first, do you want to tell me a little bit about your career journey, how you wound up in the position you’re in?
Jacques: Sure. So I’ve been in healthcare about 15 years now, I actually came from a completely different background. I was a professor for a couple of years before transitioning into healthcare. I’ve run programs at Texas Children’s Hospital down in Houston, as well as Penn State in Pennsylvania. And then I’ve been here at McLaren for about three years now.
Guerra: So what made you interested in this particular field of work? How did that transition happen?
Jacques: So I actually taught biomedical engineering. And so transitioning into healthcare is just doing what I used to teach. So it’s wonderful to be able to give back to those of us that work in healthcare with this mission and vision to really help individuals do the best that we can with, in my instance, technology.
Guerra: Excellent. Let’s talk a little bit more about the role of clinical engineering and, just for my benefit, is it the same thing as biomedical engineering? Are they slightly different? Remember, our readers are primarily the CIOs and for this interview will be a lot of CISO types. So usually, they’re not coming from the clinical side, they’re coming at it from the technology side. And I’ve heard a lot of questions in the past, they ask each other, well, “Where does it sit in your organization?” They’re trying to see, because maybe it’s not optimal everywhere in terms of the way it’s set up, or at least they question if it could be set up differently. But tell me more about the clinical engineering role. And then we’ll go into where it sits in your organization.
Jacques: So clinical engineering is also known as biomedical engineering, which is also known as healthcare technology management. So years and years ago, it actually started as a subset of biomedical engineering. So individuals can go out and get a degree, a bachelor’s, a master’s degree, in biomedical engineering. Those individuals have a wide range of areas they can go into. One of those subgroups is clinical engineering, which is the application of technology within the hospital setting. If you don’t want to work in a hospital and you have a biomed degree, you can end up designing new medical equipment, you can end up doing research, all kinds of other stuff. But within the hospital, historically, it’s been called clinical engineering. The problem is, in the U.S., at least American institutions do not provide a BS in clinical engineering; you have to get your bachelor’s in biomed, and then use this as a subgroup.
Now, probably about 10 years ago, AAMI – the Association for the Advancement of Medical Instrumentation, which is our primary body that works with biomedical engineers – tried to rebrand because it’s very confusing when some departments are called biomed, some departments are called clinical engineering. So they came up with healthcare technology management as the nomenclature. So across the country, you’ll see departments called biomedical engineering, you’ll see departments called clinical engineering, you’ll see departments called healthcare technology management. And so there is no one correct way. But fundamentally, regardless of what we’re called, within the hospital, we’re the department that helps maintain, define, choose, and support all the medical equipment across the industry. And then to your point, we also don’t standardly report anywhere, right?
So again, historically, before technology became ubiquitous, biomed was usually aligned with the facilities department, because they fix the boilers and the chillers. And then we turn around and fix the medical equipment. And so in the U.S. about a third of biomed departments actually report to facilities. Now as technology got very advanced, and we got systems like physiological monitoring and systems that integrate to the network and run on all kinds of Windows-based platforms. So at this point about a third of departments report up through IT. And so they may report to the CIO directly, they may report to infrastructure, sometimes they align us very well with the field services group that touches all the computers. Because again, they touch the technology piece, we touch the computers that then touch the medical equipment. So that works.
And then the last third of us are people who report everywhere else. So some of us report to the chief administrative officer, some of us report to supply chain. There’s a lot of places and parts throughout the country where individuals report. My direct report is actually the chief administrative officer. And so I don’t report either through supply chain or finance or IT. But of course, we have to work with all of those groups across the system to implement the technology that we support.
Guerra: So it’s interesting; it makes me think that people often say, it’s not so important where you report, it’s relationships that matter, you have to build relationships. I’m imagining, if you have the right people, anything can work. But if you have the wrong people, almost nothing can work. You do want to get the reporting structure optimal, and then have the best people. So you don’t want a sub optimal reporting structure. What would you do if you were green fielding a health system? How would you design it in terms of clinical engineering? Where would it sit? Who would report to whom and that type of thing?
Jacques: So I appreciate our current reporting structure in so far that, from a chief administrative officer perspective, I’m aligned with a little bit of everything. So supply chain rolls up through us, all the contracts that I manage, all the legal stuff that we go ahead and do to purchase equipment to do RFPs, to select equipment, gets aligned very well. And so our organization is very focused on appropriate choice of technology as well as the appropriate implementation. Specifically, for our system, our IT is outsourced to a third party and so reporting up there, to IT, becomes problematic.
And so I really think it depends on your organization. But for our organization and the way we’re focused and how our IT is outsourced, we’re appropriately structured. If you have different circumstances, obviously, if your IT is in-sourced, if your IT is a strong driver of selection of equipment and technology, if you have strong standardization, I can see a case where clinical engineering easily reports up to IT because we’re aligned on that point as well.
Guerra: So it can be done in any number of ways. And depending on how you’re reporting, some things may be easier for you to control. And some things may be harder. If you’re going up through facilities, there may be some upside to that and some downside, and different upside and downside for IT. And different upside and downside for the other mixture. Is that correct?
Jacques: Oh, yes, of course, of course. But to your point, it’s all about relationships, right? If you can build the appropriate relationships, and drive standard process and drive best practices, it truly doesn’t matter where you report. You know, a lot of us are focused on what’s best for the patient. Did we pick the appropriate technology? Did we implement IT in the most optimal way? Did we train our staff to use it appropriately and to get the best price for it from a supply chain negotiation perspective.
Guerra: This is one of those little areas that are very challenging for CISOs to get their arms around for a number of reasons, and let’s talk about some of those. The devices are expensive and they last for a long time, but the underlying operating systems do not, and that creates security vulnerabilities when the vendor stops putting out patches. Also, many vendors won’t even allow patching. They’re also delicate in the sense that even scanning the network to find them can break them. Most CISOs will talk about network segmentation as a solution, but it doesn’t seem to be a silver bullet. What are your thoughts?
Jacques: So I think CIOs have started to understand the medical device world. But it’s incredibly complicated to your point, right? So manufacturers start designing devices, let’s say they start designing it today, right? If it’s a brand new device that’s from scratch, square one, that’s got to go through full FDA approval, that can take up to seven years. And so any operating system that I put in a computer today that doesn’t actually ever hit the market for seven years will automatically run into issues with operating system end-of-life. There are literally devices that still roll off the manufacturing floor today that have outdated operating systems because the newer operating system has yet to be approved and released by the manufacturer.
Those of us in healthcare like to point the finger at manufacturers, saying you have to do this faster; you have to do this better. And there’s some truth to that. But fundamentally, the system is set up in a way that doesn’t allow them to quickly release new products and new systems. They have to go through a long regulatory process of approval, which is very different than IT.
Our IT counterparts don’t quite understand that because I can go buy a laptop today and if a new operating system comes out, I can go buy a laptop tomorrow. Unfortunately, the regulatory piece of it causes all kinds of issues related to that. So that’s your first issue, right? We physically have equipment that we’re buying today that are brand new, that already are outdated from an infrastructure perspective, from an operating system perspective. On top of that, you have to think about the patient safety piece of it. And again, we all like to bash the manufacturers, but the manufacturers have a point. They validated and verified that piece of equipment works to the level to which they’ve obtained their regulatory approval. So anytime we as hospitals and hospital systems want to change that, there’s actually laws and regulations that indicate that we become a manufacturer.
So if I want to change a medical device, if I want to change its intended use, I want to change the operating system, anything like that, add a patch to it, I have to verify and validate that it, in fact, does not affect quality and safety. And I have to do that as a manufacturer. So I have to register with the FDA, I have to go ahead and go through an entire quality assurance process. And then I have to report to the FDA. Most hospitals and hospital systems don’t do that. Because A) it’s very expensive, and B) we don’t have the subject matter expertise to do that. And so a lot of the CIOs historically have thought, well, “I’ll just put this software on it, and it won’t have any effect.” They don’t think about the regulatory implications of that. And so when manufacturers are telling us, “You can’t do this, you can’t do that,” it’s actually because they are trying to protect us as hospitals, right? We don’t want to take a liability to become that manufacturer, because it opens up all kinds of regulatory and legal issues that we have to deal with.
Now, I won’t say that there aren’t hospitals who have decided to go that route, because there are, there’s just a lot of overhead to do that. Now, to your point, patching is something that a lot of IT folks understand. Patch Tuesday comes out from Microsoft, I get my package, I package it up, I push it out remotely. Again, this is something that doesn’t work very well for medical devices. Patch Tuesday comes, we as medical professionals have not verified or validated that that patch will affect our medical device. We have to wait for manufacturers to do that. And so sometimes that can take up to a year. And so if there’s a year lag between when the patch comes out and when I can actually apply the patch, you’re taking the risk of whatever that vulnerability is for an extended period of time. So a lot of us in the hospital world have been pushing back on our manufacturers to more quickly approve patches and verify and validate them so that we can patch that equipment in a more real-time manner. But it’s very problematic because you have to prove from a manufacturer’s perspective that that patch doesn’t harm the device or harm the patient in any way before it can be approved and released.
So that’s where a lot of individuals have decided that patching is not the answer. It’s a secondary control because it takes so long to patch a medical device. So therefore, we’re going to use something like segmentation. We’re going to go ahead and not completely rid ourselves of the risk, because in theory our unpatched device is still a risk, but we’re going to mitigate the attack surface across our entire network. So I’m going to segment all of my imaging devices into a single VLAN where it only talks to my PACS. And therefore, if that segment of my network gets infected, I’m really only taking down a small portion of my network, the entire hospital’s not going to go belly up. And so that’s a mitigating factor a lot of hospitals have undertaken, but it is expensive, it is time consuming, it’s a lot to manage.
But managing at an individual device level is the same, right? If I’m tracking hundreds of patches for hundreds of devices over a year from when they’re released, it’s very time consuming and very effort intensive to figure out what your risk is, where it is, and which one’s the one you need to prioritize to try and really control what’s going on within your environment.
Guerra: Yes, that lag sounds very troubling. I mean, is it correct to say that when a patch is released, especially if it’s got security implications, that’s a sort of waving your hand to the bad guy saying, “Hey, we got a problem over here.” And if they understand that these things are not implemented quickly, unlike regular patches in IT which can be rolled out fairly quickly, then you’re pretty much putting up a sign for the bad guys.
Jacques: Yes, and most medical devices have been around for a very long time. We’ve got medical devices that sit on our networks for 7, 8, 9, 10 years, right? You have a ton of opportunity for bad actors to investigate those. I could spend six months learning how to break into a particular medical device. And I literally have all kinds of opportunity across the entire ecosystem of healthcare because that medical device may be within a hospital for years. Because the lifecycle of those devices aren’t nearly as short as some of the IoT devices. And so the ability to go ahead and infect our networks are actually greater because of how we handle medical devices.
Guerra: Yes, and I’ve been told that the goal is not necessarily to mess with the medical device. But it’s maybe more just an entryway into the network. Is that correct?
Jacques: Exactly, exactly. So bad actors will use the easiest mechanism possible to get into your network, and then they want to go get whatever they want to go get, whether it’s PHI, whether it’s credit card data, they’re after something else. We have yet to see individuals who are really using the medical device as the end means. Their goal is something else, they want to get to something else in your network. And they’re just using that as the open door to get into where they need to get into.
Guerra: Right. I think the typical scenario we all fear is somebody messing around with the settings on our pump. But that’s really not what’s going on so much right now. Correct?
Jacques: Right. That’s true for right now, but I’m not going to say that in the future if somebody doesn’t have an axe to grind and that’s their end means, but usually that’s not the mechanism for which they want to get into your network; they want to get into your network for other data that you have that they want to expose.
Guerra: Yes. As you said, they’ll use whatever they can. I was speaking to someone the other day that talked about hacking a casino through a fish tank camera.
Jacques: Well, we talked about medical devices because it’s becoming very, very well known to the CIOs and the CISOs that they have this risk we need to deal with, but we still have elevator systems, and building automation systems and temperature monitors. There are thousands of devices that sit on the network in a hospital and all of them have to be protected, right? Our CISOs, our CIOs always think about our computers and our servers. But there are literally thousands of devices that sit on the network that are all possible attack vectors, and we as a healthcare system have got to protect the entirety of our network.
Guerra: It’s so interesting. We talked about clinical engineering reporting up to facilities at one point, but then it became so technology heavy it was changed to reporting to IT. Well, the next thing we’re going to see is facilities is going to be so IT heavy that everybody’s going to wind up reporting to the CIO, because everything is run by technology. We’re going in that direction as a society.
Jacques: Yes. When we’ve all got clouds, right? Everything reports up to the cloud, we’ve got to go ahead and protect those as well. The technology is becoming ubiquitous. And so as technology continues to drive improvements and workflow and drive improvements in healthcare, the problem is IT can’t be the only one who understands security. And I know a lot of the CISOs have been trying to talk about security as not being a security issue. Security is everybody’s issue, we all need to be talking about it, we all need to be understanding exactly what the risks are. Those in clinical engineering have to understand the risks of medical devices, those in facilities have got to understand the security risks for their systems as well. Nursing, right? A transport, it doesn’t matter where you are within the healthcare organization, you need to understand that there are IT security risks everywhere in our organization. And those CISOs that are out there doing large education efforts to help their population understand and drive home that security is everybody’s responsibility, I applaud you, because that’s fundamentally where, as a society, we’re moving.
Guerra: Yes, that’s absolutely true. So what would your advice be to CIOs and CISOs? And if it’s a different message for each, then take them one at a time. They want to get these things secured. They know they have an issue. It’s a challenging issue. What’s your best advice to them?
Jacques: So I will tell you that biomed and clinical engineering departments across the country are at varying levels – very similar to your CIOs and your CISOs. Not everyone even understands the problem. So obviously, the first thing that we need to do is everybody needs to understand what the problem is. What are the issues we’re trying to face? And then we have to get to a roles and responsibilities type of mechanism and matrix. I understand very clearly where manufacturers stand. Most organizations still are pointing at the manufacturers going, “Why aren’t you doing blank, blank, blank?” because they don’t understand how the ecosystem works.
Once the education piece really gets completed and we’re all on the same page, it’s then a roles and responsibilities conversation, right? Who is patching this? Who is segmenting the network? How are we approaching risk as an organization to go ahead and reduce it? And that conversation has got to have a lot of people in it, right? IT, whether it be the CIO or the CISO, can’t look at risk without the clinical lens, right? And those of us in clinical engineering, we work very closely with our clinical counterparts, but we can’t speak for them. And so, if your CIO, or if your CISO, decides we’re going to do this, to go ahead and mitigate our risk, there needs to be a clinician in that conversation. How is this going to impact clinical care? Are you changing workflow? Are you changing how many steps somebody has to do to actually take care of the patient?
And so one of the things I would highly recommend for both the CIOs and the CISOs is, as we’re talking about mitigating risk, whether it be facilities risk, clinical engineering risk, whatever, there needs to be clinicians in that conversation, and there needs to be an understanding of what that impact looks like from an operations perspective. Balancing risk with taking care of patients is incredibly complicated, right? It’s incredibly complicated. And you come to try and have conversations like, “What if my big piece of medical equipment gets infected? Okay, what is our gameplan? What is our playbook for responding to that?” You go ask a CIO or CISO. Yes, shut it down, take it off the network, because that’s what they do with their laptops. Well, what if I have a patient literally in the device being cared for at that very moment? What’s the impact of shutting it down? Are you actually harming a patient to do that? A lot of the CIOs and CISOs haven’t thought through those types of conversations.
And so building your playbooks, building out your communication channels, understanding what implications look like so that you can make rational and reasonable decisions in a quick manner when you need to is something that all of us should be striving for. The problem is, it’s not as easy as following our typical playbooks. You need to talk to way more people and you need to understand a lot more implications. And the choices aren’t nearly as clear as we wish they would be. And so starting those conversations, creating those playbooks and then practicing them – all of us have been through various events and seen events that have happened in other organizations. If you don’t practice what your plan is, you’re going to still be caught flat-footed, you’re not going to know what you don’t know. And so in a typical mechanism, once you’ve planned what your roles and responsibilities are, once you’ve documented them, put your playbooks together and practice them to see if they actually work or not.
Guerra: I still feel like this won’t get done unless someone who sits above IT, clinical engineering and clinical care drives it. That might be the CEO or the COO or the chief administrative officer. Otherwise, I just don’t see it getting done. What do you think?
Jacques: No, and I think, especially with the way we’ve seen more events occurring, right, all of us have been reading the news, all of us have seen the massive events that have happened over the last year. And we all know about the uptake of ransomware and occurrences across all of the healthcare sector. I don’t think it’s just the CEO that needs to be included, I started seeing the risk committee of the board having these conversations. So, in those cases, the board is engaged to say this is a risk, we know this is a defined risk, we know we have issues, look at what’s happening in the entire healthcare environment. We’re starting to see those conversations happen at a level they’ve never happened before. And so there are healthcare systems that are really, really concerned that they don’t have a great plan and that the risk continues to go up. Because all of our healthcare systems are being targeted now at a much higher rate. We need to get this together.
And so I would agree. If it’s not the CEO, or the COO, the risk committees of the board in some instances are really looking at this to say, we need to pull together a team to really have our disaster recovery plan together, our response together. And those risk committees are the ones that, at this point, are looking at 300% and 400% increases in your cyber insurance. And so they leverage that data to say it’s super expensive for us to mitigate the risks that we have, we have to be prepared from an operations perspective. I’ll tell you; the large healthcare systems have started having those conversations, they’ve started putting those plans together. But I would advocate for those mid and small hospitals – this is some something you guys should be doing as well. If it’s not your CEO, or COO that’s leading it, your clinical leaders and your technical leaders need to get together and have a conversation so that at least you can start planning because if you don’t plan, you’re going to end up reacting to whatever is going to affect you. And that, of course, is not a place any of us want to be.
Guerra: 100% agree. 100% agree. We only have about a minute or so left. So my final question is, from your perspective, from where you sit, obviously a CIO and a CISO are going to be key individuals you need to work with. What do you want from them? What do you want from your CIO or CISO in terms of communication and relationship?
Jacques: Yes, so ultimately, it’s a partnership where we need to understand each other, right? I’m not a CIO, I’m not a CISO, I know enough it to be incredibly dangerous, right? I’ve learned enough about networking to understand how stuff flows across the network, but I’m not the subject matter expert. I have to understand that they’re not the medical equipment subject matter expert, and we need to rely on each other to really figure out what those roles and responsibilities are. Who is going to patch servers? Is it going to be the IT team? Is it going to be my team? Who’s going to physically touch the medical devices to patch them? Does it depend if it’s pushed from a network? Does it depend if I have to go around with a stick and plug stuff in? It depends.
And so having those robust conversations with your IT and CISO partners is incredibly important. My security partners don’t understand medical devices. So when I say, “Hey, your scan knocked over half my medical equipment.” They look at me like, “Well, what do you mean? It’s a passive scan, it’s not going to hurt anything.” We all have to come together with a stance that says we’re going to educate each other about our subject matter expertise because none of us are going to know everything. Once we build that relationship and really talk to each other about what our subject matter expertise is, we’ve got to be open to other’s perspectives. And I think that’s very challenging, right? Sometimes we like to see things in black and white. And once we end up in the healthcare world, there’s absolutely nothing that is black and white. And we have to figure out exactly what risks we’re willing to take, and where we’re willing to take them.
And that’s a conversation that’s not the CISO indicating that it’s my way or the highway type of stuff. And so, again, it’s all about relationships, you need to be able to build one where you have these robust conversations, and you can disagree, there’s nothing that says you can’t disagree, but you also have to get to a place where all of you have to understand that we’re doing everything we can to mitigate risk for the patient. And as long as we stay focused on what we’re doing, and the patient focus of it, we’ll end up in a place that’s much better than we are right now. Right? Today there are individual silos or unilateral decisions we’re all trying to make for our best interest and we have to give that up, we really have to focus on what’s best for the patient and find a way to get from where we are today to there.
Guerra: Wow, fantastic interview, Sam, great stuff. I really appreciate your time today.
Jacques: I appreciate you talking to me. And I’m hoping that this is helpful for individuals. And if you’ve not gone and talked with your clinical engineering department, find out who they are and go have an introductory conversation with them.
Guerra: Well, I will tell you, I’ve been focused on CIOs for 12 years and CISOs for about three years. You are the first clinical engineering executive I’ve interviewed because of what’s going on with these devices and the security implications. So you get that distinction. Thank you.
Jacques: Thank you very much. I’m happy to help and, like I said, your clinical engineers have some great subject matter expertise, figure out who they are and go leverage them as much as you can.
Guerra: Thank you, Sam.
Jacques: All right. You have a great day.
Share Your Thoughts
You must be logged in to post a comment.