FDA > CDRH > MedSun > Educational Materials > Cybersecurity of Medical Devices - April 12, 2005

Cybersecurity of Medical Devices - April 12, 2005

Agenda

Complete Transcript

Presentations

Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software. Software Compliance Expert, Center for Devices and Radiological Health, Food and Drug Administration, John Murray

Cybersecurity for Medical Devices: Three Threads Intertwined. Product Security Program Manager, GE Healthcare, Scott Bolte

Cybersecurity for Medical Devices. Senior Business Analyst, University Health Consortium, Cathy Sprague

Cybersecurity References

Food and Drug Administration Web site. Information for Healthcare Organizations about FDA's "Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software." http://www.fda.gov/cdrh/osb/1553faq.html. Accessed March 10, 2005.

Food and Drug Administration Web site. Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software. January 14, 2005. Available at: http://www.fda.gov/cdrh/comp/guidance/1553.html. Accessed March 10, 2005.

GE Healthcare Security Portal. Available at: http://www.gehealthcare.com/usen/security/index.html. Accessed March 10, 2005.

HIMSS Medical Device Security Workgroup Web site. Available at: http://www.himss.org/ASP/topics_medicalDevice.asp. Accessed March 10, 2005.

Manufacturer disclosure statement for medical device security-MDS². Available at: http://www.himss.org/content/files/MDS2FormInstructions.pdf. Accessed March 10, 2005.

University HealthSystem Consortium: Medical Device Security. January 2005. http://public.uhc.edu/uhcmail/Push_Emails/MedicalDeviceWhitePaper.pdf. Accessed March

Agenda

Clinical Engineering Topic Discussion Series: Cybersecurity of Medical Devices

Call-In Date: April 12, 2005
Time: 1:00 – 2:30 pm EDT
Meeting Call-In phone: 888-889-6348
The operator will ask you for the leader name and the code for the meeting. Please provide the following--Leader: Terrie Reed Code: Devices
NOTE: You must be registered to Attend this call!

Conference Objectives:

• Improve understanding of FDA’s role and available guidance on Cybersecurity
• Increase awareness of cooperative work done by FDA, Device Manufacturers and other organizations to address this complicated issue
• Improve understanding of role that your staff can play to improve the safe use of networked medical devices networked in your facility

Moderator

Jay Crowley, Senior Advisor for Patient Safety, Center for Devices and Radiological Health, Food and Drug Administration

Speakers

John Murray - Software Compliance Expert, Center for Devices and Radiological Health, Food and Drug Administration

• Cybersecurity Vulnerability – Defined
• Review of the FDA Cybersecurity Guidance
• Manufacturer Responsibilities to Comply with Guidance

Scott Bolte - Product Security Program Manager, GE Healthcare

• Role of User vs. Device Vendor. vs. IT Vendor
• GE Cybersecurity Initiatives
• Working Together to Build Solutions
• MDS²

Cathy Sprague - Senior Business Analyst, University HealthSystem Consortium

• UHC Cybersecurity Initiatives
• Viewing the Problem from the Health Provider Perspective
• Recommended short-term, medium-term, and long-term solutions

*****************************************************************
You may e-mail questions prior to or during the conference. Send questions to tzr@cdrh.fda.gov

Complete Transcript

FTS-HHS-FDA-CDRH

April 12, 2005
12:00 p.m. CDT

Coordinator: Good afternoon and thank you for holding. I’d like to inform all participants you’ll be in a listen-only until the question and answer session of today’s conference. I’d like to inform all parties that the call is being recorded, for transcription purposes. If there are any objections, you may disconnect at this time. I’d like to turn the call over to your host today, Mr. Jay Crowley, you may begin.

J. Crowley: Thank you, Joyce. Welcome everyone, good day, good morning or good afternoon, depending on where you are. Welcome to the current Clinical Engineering Topic Discussion Series. The title of this one is Cybersecurity for Network Devices. As Joyce said, my name is Jay Crowley and I’m with the MedSun Program here at FDA. I’d like to thank you all for taking the time to participate in this very important discussion and I’d like to thank Terrie Reed for organizing this audio conference.

Let me explain a little bit what’s going to happen. We’ll be here for about the next 90 minutes. For about the first 45 or 50 minutes or so, each of our three speakers will take 15 to 20 minutes to present their presentation, and during this time, as Joyce said, you can only listen-in. At the end of our three speakers we’ll open it up for questions, and Joyce will explain how that works.

Each speaker will be referring to their handouts, and hopefully you all have already received those, they should have been e-mailed to you. If you don’t have them, you can either obtain from the MedSun Participant Web site or you can call 1-800-859-9821, again 1-800-859-9821 and have those e-mailed to you.

As Joyce said, this conference call is being recorded and therefore what is being presented is not confidential. If you need to bow out at this time, please go right ahead and do that.

Let’s get into it then. Let’s talk a little bit about cybersecurity for network medical devices. In January of this year FDA released a guidance and a question and answer for hospitals that addresses FDAs view of cybersecurity issues. FDA has been and continues to work with hospital IT experts, manufacturers and professional organizations, to work through all the very complex issues associated with this topic. Today we have a very nice representation of speakers here, to talk about the various stakeholder positions in this issue.

What each of these three speakers is going to do is to give you their impression of the current understanding or their current thinking on this issue. If you joined in hoping to get the final answers, I’m afraid they’re not going to be here for you. As I said, this is a very complex issues, as I’m sure the speakers will talk about, that they are still working through all of the various nuances associated with this issue.

We are also interested in hearing how MedSun and UHC participants have dealt with this issue. We want to encourage you to report to FDA, any cybersecurity issues with medical devices, when there’s a cybersecurity issue that’s suspected.

As a disclaimer, I’d like to say that the opinions and assertions presented during this audio conference are the view of the presenters and are not to be construed as conveying either an official endorsement or a criticism by the FDA.

With that I’ll go ahead and get started. I will introduce each speaker before they present. Our first speaker is John Murray. John is a software and electronics records compliance expert for the Office of Compliance in the Center for Devices and Radiological Health at FDA. John is the primary advisor to the Director of the Office of Compliance, in the areas of software validation, software policy, software classification and electronic record compliance.

John joined FDA in March of ’94. Previously, John was a Qualified Reactor Operator with the U.S. Navy Submarine Fleet, a Computer Field Engineer with Telex Computer Products, and Electronics and Software Engineer with the General Dynamics Corporation and a Systems Engineer at Technology Management and Analysis. With that, I’ll turn it over to John Murray. John?

J. Murray: Good afternoon everyone, this is John Murray here. I want to talk about the guidance document that we published in January of 2005. But most importantly, I want to put out the word that we’re really at the beginning of this journey. The issue of cybersecurity and the issue of the use of off-the-shelf software and the integration of proprietary products with third party products is kind of a long-term issue or long-term problem that’s going to require a lot of work by a lot of folks.

I really envision this problem as being owned by four different parties. The first party is the Food & Drug Administration. The second party would be the medical device manufacturer. The third party is what I refer to as the IT users (Information Technology User Group) which are mostly hospitals and doctor’s offices. The fourth party is what is referred to as the Independent IT Providers, the Information Technology Providers, like the IBMs, the Microsoft’s, the Cisco’s of the world and things like that.

What we’re trying to do here, is we’re trying to get all the parties together, so that we can talk about issue, because many times it’s not clear who owns responsibility for the problem. What each party should be doing. What we’re trying to minimize is all the finger pointing that has been going on for the last year and a half or two years. So the idea is to put together these events and get some folks to the table, so that we can actually start putting our points of view out and we can come to some kind of resolution.

There’s another event that we’ve scheduled for May 26th. It’s going to be sponsored by AdvaMed, here in Washington DC; it’s a one day workshop. If you go to the AdvaMed Web site, you can get some information on how to register for that. Currently for that event we have a guest speaker from Microsoft, from IBM and from Cisco appearing. So it should be a great opportunity to get all four of these groups together in the same room and actually discuss this issue.

I’m moving on to slide number two. The question is what is the issue? Well the cybersecurity vulnerability exists whenever the software provides the opportunity for unauthorized access. This is problematic, because once the doors are open, some unknown force or unknown hacker or virus can penetrate the inner workings of a medical device and this represents a risk to the safe and effective operation of these devices. Medical device manufactures spend a large amount of time and money and effort in making safe devices, and cybersecurity represents a hole in that.

The failure to properly address these vulnerabilities could result in an adverse effect on public health. It’s unclear at this point what that risk could be, and I will point out to-date, in our entire database, we only have two reports of incidents related to a cybersecurity threat or cybersecurity vulnerability. But I want to make it clear that FDAs issue in this is the safety of medical devices. We fully recognize that there are other issues that are around like compliance with HIPAA, from Sarbanes-Oxley issues, but we’re mainly focused on the safety of medical devices.

Slide three, please. Over the last two years we’ve received a lot of phone calls from device manufacturers, from hospitals, even from Microsoft itself, and there seemed to be a lot of confusion about what FDA laws and regulations actually applied. So when we sat down at the table, we decided that we should write a guidance document to reinforce what the regulation says.

Our current position is that this is not a new policy or a new regulation; this is merely pointing out or providing a roadmap to the elements in the regulation or in the policy that currently applied to cybersecurity. So this guidance outlines general principles that FDA considers to be applicable to the situation. Of course the quality system regulation applies to software maintenance actions, which a cybersecurity update or patch is on software maintenance activity.

We’d further like to point out that existing FDA guidance documents, there are three of them listed at the bottom of slide number three, if you go look at the material in those guidance documents or software, you will clearly see that the maintenance and the validation of cybersecurity patches, would easily fit within the instructions and guidance in those documents.

Slide number four, please. The next most common question that comes up is which medical devices are covered by this guidance document? Clearly the medical device that incorporates the use of off-the-shelf software, which is where most of these cybersecurity vulnerabilities occur, this guidance applies to. These devices are devices connected to private Intranet or public Internet connections. In other words, there has to be an opportunity for a risk to exist.

We also believe that the information that’s in this guidance document could be helpful to the user, to the hospitals themselves, by understanding and having an appreciation for the regulatory process and the validation process that we go through on a regular basis. Hopefully they can help us understand this problem a little better and actually provide a solution in a quicker fashion.

Slide number five. I often hear the question, who is responsible for insuring the safety and effectiveness of medical devices? Clearly under the food and drug law, the device manufacturer bears the ultimate responsibility for the continued safe and effective performance of their medical device. However, the device manufacturer does not always bear the responsibility for the hospital network.

This line can become very blurred at times, because just about every hospital I take a look at, for every situation the engineering configuration is different, the type of equipment is different, the equipment provided by device manufacturers are different. Some device manufacturers actually provide networks and some do not. So this line is very, very blurred and it’s going to require an effort on both sides of this problem to actually solve that.

I do want to point out that from and FDA perspective, we have no regulatory concern for compliance with HIPAA. Although we think it’s important, from a personal point of view, we don’t have a regulation that requires us to ensure that medical device manufacturers are HIPAA compliant.

Slide number six, please. We get questions all the time about what we think the user should be doing. The number one thing is that we need the purchasers and the users to be in a continual contact with medical device manufacturers. A lot of folks just buy these products and it’s an event that occurs once every two or three years. We’ve discovered in this integrated environment, with the use of products from multiple sources that that’s no longer sufficient. We require some kind of continuous contact or continuous relationship between the users and the device manufacturers.

We also believe you should have some kind of continuous contact with the off-the-shelf software provider. I got an opportunity in February, to go out to Microsoft and speak for their computer security officer’s conference. I discovered that they’re actually setting up a system, and they call it an early warning system, where you as a device manufacturer or a user can get signed up in a program that allows you to sign a non-disclosure agreement with Microsoft and they will give you up-to-date, early information about upcoming threats. So this occurs, maybe two or three weeks, before the actual patch arrives on the scene.

The problem we’ve had in the past is that this patch would be popping out the end of the tunnel and when that patch arrives, that gives a flag to the hackers and the virus makers of the world. So this could give us a running start on the problem. I suggest that you could contact Microsoft, and if you send me an e-mail, I can probably put you directly in contact with the people running that program there. The second piece of guidance or information that we’d like to put out is that we don’t believe that users should attempt to make changes without seeking device manufacturer’s advice and recommendations.

Now to me, this is merely common sense. When I look at the back of my television, I clearly see a sign that says, “To be serviced by qualified personnel, only.” We believe that the device manufacturers know best about the safety packages and the criteria from which the devices were built. We don’t suggest that users go about making changes without some interaction or some guidance from their manufacturer.

We also suggest that in each hospital, each user facility, where you’re actually involved in devices that are networked, and you have hospital networks, I think everyone does, it would be a really great idea to have some kind of proof plan in place that actually addressed the risk management and the assurance system that you’re going to use to address this problem. I know that hospitals do a really great job at this with everything else. They have controls in place, they have procedures in place and they go about their business in a daily base, but for some reason, we as a society have adopted a new philosophy when it comes to patching our software.

I’m not sure where that comes from, but my recommendation is if you apply your current biomedical engineering practices and thought processes and risk management process to this problem, you’ll have some great success. The way to do that is by addressing the problem in the way you’d address any other update or change to your system, by having a plan, a standard SOPs, standard training and things like that.

The one thing you should absolutely not do is turn on the automatic download feature of any software product of a hospital network or a hospital medical device. That could be disastrous. You don’t really want Microsoft or IBM or Cisco controlling the configuration of your hospital network, without you having some kind of prior knowledge.

Slide number seven, please. Another question that always comes up is; I’ve gotten calls from users and they’ve said they’ve call the device manufacturer and the device manufacturer says, “I can’t do anything, I have to get FDA approval.” So we went back and examined this question and the answer is that pre-market review of a software patch or a cybersecurity update, usually does not require and FDA pre-market approval.

There is a guidance document under bullet three there, and it’s available on our Web site, about when to submit a new 510 (k) or a new pre-market submission. The rules are basically still the same for cybersecurity patches, as they are for other changes. One is if it does not change the intended use of a device, there’s no requirement for pre-market submission. Two is that it doesn’t introduce any new elements of risk.

Our opinion is that we can’t think of a case where a cybersecurity patch would represent a change of intended use or the introduction of new risk. In fact we believe that this is a decrease of risk. Although we don’t absolutely say 100% of the time that this could be true. We really believe that it’s unlikely that a software patch for cybersecurity would require pre-market approval.

Slide number eight, please. This is the million dollar question. Can software change made to address cybersecurity be validated? The answer is yes. Any change made to any medical device, requires some kind of validation or some kind of assurance that it works correctly. All software design changes, which are cybersecurity patches, a software design change under the regulation, requires validation.

The key to this is it doesn’t say 100% validation. It doesn’t say to go back in time and redo all of the validation and all the assurance activities you’ve done to that point. You have to do what is necessary. The way to address what is necessary is by analyzing the problem, understanding your networks and understanding your devices. In other words, do your engineering homework. Then you’ll be in a better position to make valid decisions about what kind of assurances or validation you need to put in place, to address these cybersecurity changes. It’s very, very important.

We say in our guidance document that we believe that analysis inspection and some form of testing should be adequate and clinical validation should never to necessary for a cybersecurity patch. I think the key thing here is that you have to do your homework, you have to have an ongoing program and you have to understand your domain to be able to make good decisions. It doesn’t make much sense to just put these patches on a system, in an automatic mode or in any mode, without some kind of assurance activity.

You should always keep in mind, and I think Scott, who is a speaker today, said, “Well you can always disconnect a device from a network, you need to get work.” That’s kind of an extreme case, but you know, that’s pretty true. If you feel some kind of threat from the network and you need to use the device, you should have some kind of alternative plan in your facility, to use this equipment.

I really hate it when I go into a store and I can’t buy anything, because their cash registers are down, and nobody knows how to fill out a paper slip. So it’s kind of the same situation. We have to be prepared. We can’t always accept the benefits of this technology without recognizing that there’s some risk that we need to take on.

I’m on to slide number nine. We were asked a question about what other things we should be doing to ensure that these medical devices remain safe. We recommend a formal business relationship between the off-the-shelf software vendors and the medical device manufacturers. The reality of it is that we haven’t done a very good job of this in the past. But we’re not going to go around and blame the past and point fingers. The idea is, “Hey, we could have done a better job.” So in the future, when you write an RFP (Request for Proposal, Request for Quote,) you need to put this kind of information in there.

Of course it’s going to cost money, nothing in the world is free. But the continued use of this technology, we need to address the risk, as well as the benefits of using these. So you need to maintain some formal business relationship. My suggestion is that even if you know that the vendor can’t provide it right away, you do want to put it in there, and then you can change the RFP/RFQ later.

When the FDA comes along and starts asking you questions about what you’ve done about these things and you have no documentation or what I call breadcrumbs, you’re going to be in a non-defensible situation. What you want to do is keep track of these things and keep trying to get these technologies in these things. You need to develop a maintenance system, to provide this assurance, just like you provide assurance for other biomedical engineering activity in your hospital.

Our recommendation is that each device manufacturer, with his product line or his product, has some kind of maintenance plan. This could be in the user manual or it could be under the contract. It’s not quite clear how this should be conveyed, that’s kind of a business-to-business issue. But the idea is that once you have this in place, you have a better understanding of who’s responsible for what. The idea is that the device manufacturer provides the engineering leadership. He may delegate some of that authority or some of that activity to the hospital, and that would be a very good thing.

Before I conclude, I don’t have a slide for this, but the other question I’m always asked is does the FDA regulations prohibit a user from updating his own medical device? The answer to that question is no. I get phone calls all the times, from users, and they’re being pressured by their administrative staff or their executive staff, to put this patch on. They want to defend themselves by putting the FDA flag up, saying, “Well the FDA says that I can’t do this.” Well there’s no regulation that prohibits a user from modifying a medical device.

However, when you do so, you open up a whole new category of risk. It’s really unclear, under the law, as to who would actually be responsible for the safety and effects of that device. This is one of those areas that need to get worked out, and hopefully we can have more discussion about that in the future.

I think that’s all I have to say today. I’m not sure who is next, but it’s been a pleasure to speak to you, and I hope that I’ve added some insight and value to the subject for you. Thank you very much.

J. Crowley: You sure did, John. Thank you very much. That was a great overview and I think it really gives us a great framework, from which our next two speakers will present their views on this.

Our next speaker is Scott Bolte. Scott has been leading efforts to better understand and protect against security threats to medical devices, for many years. In addition to his work at GE Healthcare, where he currently is. Scott is an active member of the NEMA Security and Privacy Committee; the NEMA VADOD taskforce for medial devices and the HIMSS Medical Device Security Work Group. In the HIMSS Group, he was the primary driver behind the creation of the manufacturer’s disclosure statement for medical device security, the MDS².

Previously, Scott spent ten years in the super computing industry and another ten years developing medical devices for Market, Medical and GE Healthcare. Scott, I turn it over to you.

S. Bolte: Thank you very much, Jay. As you said, my name is Scott Bolte and I am currently the product security program manager for GE Healthcare. For many years I have been working the issue of security for medical devices. In that time I’ve had the privilege to speak to many people throughout the industry. I believe I have a pretty good grasp of the issues, from both manufacturer’s and the healthcare providers’ perspective.

Today I’d like to briefly share what we at GE are doing, as a result of those discussions. I’ll spend more time outlining what healthcare providers should consider as they manage their risk. I’ll then close talking about industry forums in which we’re developing standard solutions to better address these problems.

By the way, there are six pages in the appendix that provide links to more information. I will not have time to go over those pages today. But please, look into the sites they mention for additional data. (These are also available on the MedSun Participant website – https://www.medsun.net/participants)

Please turn to page three and I’ll start by talking about the patient’s perspective. Many people are focused on the security of individual devices. Unfortunately, that narrow focus sometimes results in the larger picture being lost. Those of you, who are not clinical personnel, may not realize how interdependent today’s medical systems have become. Whether it is reviewing CT images from a PAC Server or pulling up lab results on a patient’s bedside monitor, the need for the smooth flow of information across the network continues to grow.

The information will improve the quality of care for patients. Attempts to secure networks and devices must not interfere with that flow of data or the solution may be worse than the problem.

Please go to page five, and I’ll start talking about the manufacturer’s perspective. Let me start by clearing up a common misconception. John already talked about this, but I’ll reinforce it. Manufacturers rarely need to get approval from the FDA, with regards to cybersecurity fixes. However, each patch is believed to be guilty, until proven innocent.

Even though they may share the same hardware and operating system, as a general purpose computer, medical devices are critically different. If you apply a patch or make any other change that breaks a general purpose computer, it’s inconvenient. If that same change breaks a medical device, and the device affects patient care, a well-intentioned change can affect patient’s safety. I don’t want to be overly dramatic, but manufacturers must validate that modifications do not alter the safe and effective operation of the device. We need to take the time to prove that a patch is innocent. There is no way to skip that critical step.

Please go to page six. As I mentioned at the beginning, I’m going to spend a relatively short time talking about what GE Healthcare has been doing over the last several years, to improve the security characteristics of our products. If you have questions, you can contact me later; my e-mail address is on the first page. I’ll also be at the AAMI conference in May, as well as the AdvaMed conference on May 26th that John mentioned earlier, and we can make arrangements to meet there.

At a high level, GE Healthcare’s efforts have been broken into three areas. First, we are making changes to the product itself, to make it less likely that it will be vulnerable to an attack. This includes eliminating all unnecessary network services, to reduce the changes that we’ll be affected by viruses and worms. We are also running vulnerability assessment scans against each product, throughout development and provide that information to product development teams.

Second, we’ve created a virtual global product security team that quickly evaluates threats and determines the best response. Members of that team also serve as the local experts to educate product development teams about the importance of security and the techniques that they can use to better secure their product.

Third, we’ve created a Web site where you can learn more about GE Healthcare’s products, including vulnerability information. That Web site will continue to grow over time, as we provide you the information you need.

Let’s go to page eight, and I’ll switch to the healthcare providers threat. As I said, medical devices are truly different. While I sympathize with someone who is between a rock and a hard place and has been told to secure the device, no matter what, they need to keep that difference in mind. As I mentioned a few minutes ago, indiscriminately applying patches, has broken medical devices. The software vendor, who issues the patch, does not and cannot make sure that there are not unexpected side effects for the medical devices.

Anti-virus software is another hazard. It’s okay to slowdown someone’s laptop with a system scan or quarantine a suspicious file and have them manually recover it. It’s another thing altogether to interfere with time critical arrhythmia alerts or block cardiac wave forms, because they unexpectedly match a virus imager. Now I’m not saying that common security techniques are impossible, just that they need to be evaluated and integrated into the medical device, very carefully.

Page nine, please. One issue I don’t yet hear being talked about is the long lifetime of medical devices. The general purpose computer system that most people use is obsolete in just a few years. That’s because the task people expect it to grow over time and outstrip the operating system and hardware. With a medical device, its operations are fixed, focused and relatively static. When tied to a large expensive hardware, such as the CTR MR Scanner, its operational life could be ten to twenty years, because the scanner, application software, operating system and underlying host hardware are so tightly intertwined, it is not possible to update a single piece, such as the operating system. As a result, you may see medical devices using a host OS for many years longer than you otherwise would expect.

Page ten, please. I’ve mentioned a few hazards that I want people to keep in mind, but all is not doom and gloom. Newcomers to security are often overwhelmed because they see all the problems as equal, fortunately that is not so. It is possible to do a risk assessment, often known as a threat assessment and identify which problems need to be fixed today and which ones in good conscience can be addressed tomorrow. You can then create a base plan to manage the risk to your organization that does not require you working around the clock for the next year.

Another reassuring point is that we can work in parallel. I just scratched the surface of what GE Healthcare is doing to reduce the chances that a network attack can hinder the operation of our products. We have made improvements and will continue to do so for years. Fortunately, you don’t need to wait until we are done. There are things you can do today to reduce your exposure to malicious attacks.

Please go to page 11. I’ve mentioned several technical issues when securing medical devices, but one thing I’ve not mentioned are communication hazards. I can speak about strategic initiatives GE Healthcare is working on, but I lack the in-depth understanding of specific products. Likewise, I worry that the IT staff at a hospital, often does not have the full picture of how specific devices are used by the clinical staff. As a result, any conversation that does not include the clinical staff at the hospital or someone with an in-depth understanding of the products being discussed has a dangerous blind spot.

Another problem is when normal support channels are bypassed. A few years ago, when the IT department of a customer had a security problem or concern, they would often end up speaking directly with a cross-modality security expert, such as myself. While we all were doing our best to address the problem, going directly to me was ultimately a disservice to other teams, both at the hospital and inside GE Healthcare.

That is because the support systems that detect trends, such as new security questions coming from multiple customers, didn’t see anything. Therefore the clinical users, the manufacturers support, sales, marketing and engineering teams were in the dark. As John alluded to, the FDA too has seen that problem, with only two reports of adverse events, due to security problems. So as you work to improve your organizations security posture, make sure education and awareness training are part of your plan.

Please go to slide 12. As I mentioned at the very start, medical devices are exchanging more and more information to improve patient care. As a result, they are more dependent on the quality of their network connection. While the device can condition other necessary services, such as power, the ability to exchange data with a remote HIS, RIS, PACS or lab system, for example, is completely out of its control.

I understand the cost and organizational pressures to flatten and simplify networks. Unfortunately that both threatens the timely flow of clinical data and exposes the medical devices, unnecessarily, to network attacks. Segregating medical device networks, either physically for patient monitors with their very stringent need to send real-time patient data or logically using VLANs for less demanding applications, is my number one recommendation to hospital IT departments.

Medical devices are creatures of habit. They have a well-defined set of peers with which they communicate. External controls, such as internal firewalls or layer-three switches, should be used to restrict the devices network connections, to those peers. That greatly reduces the chance that a compromised system, a mobile laptop that was carried past the perimeter firewall, for example, can in any way threaten the medical device. Not only will segregated networks manage the risk, while manufacturers do their validation of a patch, it also ensures improved operations, the majority of the time, when hospital networks are not exposed to viruses and worms.

If you’ll go to page 14, I’ll start to tie the three threads together; patient, manufacturer and healthcare provider. Clearly, any solution that diminishes clinical interoperability is not acceptable. Manufacturers of medical devices need to work together with the users of those devices, to develop standards and best practices. That has been happening successfully and I see no reason why it will not continue.

The two groups I’ve personally worked within are the security and privacy committee at NEMA and the medical device security group in HIMSS. But links for more information in the appendix, point to those two groups. However, there are several additional groups that are working on cybersecurity, such as UHC, ECRI, AdvaMed and obviously, the FDA. Don’t be shy about joining one of the groups, if you want to share best practices that you’ve developed or want to learn more from others.

Please go to page 15. I’d like to offer an excellent example of collaboration. Last year, healthcare providers began requesting information from GE Healthcare, to assist them, as they did the risk assessments called for by the April 2005 HIPAA security regulations. No two request forms were the same, each required a lot of time to complete and I worried that we were going to be buried with requests, as the deadline drew near.

The HIMSS Medical Device Security Work Group, which includes other manufacturers, as well as healthcare providers, rose to the challenge. The group took and ECRI document as a starting point, simplified it and restructured it a bit, made sure every question required only an objective yes/no answer, added quite a bit of supporting documentation and got it approved by HIMSS and NEMA, in just a couple of months. I’d like to note, by the way, that while HIPAA security regulations definitely drove development of the MDS², it was designed with a global audience in mind.

The new standard form is much easier on the manufacturers, because we can create the document once, and use it time and again. GE Healthcare has about 300 MDS² documents available on our Web site for installed base products. We will create a new one for each new product going forward.

The form is also easier on the healthcare providers. Multiple manufacturers answering the same set of objective questions, along with consistent instructions, used by everyone, simplifies the processing and understanding of the MDS² documents.

The last three pages of this presentation, which I won’t be covering today, include more material on the MDS². Included is a link to a source storage site, where I hope discussions of the future of device profile statements will take place. I think we as an industry have a chance to turn disclosure statements into living documents, augmented by the device users. That will help not just with initial installation, but device upgrades and streamlined introduction of new, but equivalent devices into existing infrastructures, as well.

I’m looking forward to exchanging information about vulnerabilities and other security data, I feel manual processes are bound to be ineffective. I hope if you have time and interest in trying to create an automated process that spans manufacturers and healthcare providers, you will join either the HIMSS Work Group or the Source for Discussion.

Please go to page 16, the last page I’ll discuss today. I have raised some concerns today, but I do not mean to be an alarmist. Everyone can take steps to reduce the likelihood that clinical operations will be disrupted by network security problems. By stepping back from time to time and looking at the entire picture, including manufacturers and clinical users, it is possible to create security measures that are effective and don’t compromise clinical functions. Working in collaborative forums, I am confident we will continue to share the lessons we have already learned and tackle the problems that still remain. Thank you very much for your time.

J. Crowley: Thank you, Scott. That was very helpful, very insightful and gave us quite a bit to think about.

Our last speaker is Cathy Sprague. She is the Senior Business Analyst at the University HealthSystem Consortium. Cathy has been involved in Healthcare Information Technology for over 20 years. She has held a variety of positions ranging from technical to strategic. One of her primary roles at UHC is to work with its 90+ academic medical center members, to understand the issues and challenges they face, and to foster collaboration among their CIOs, for the exchange of ideas and solutions for technology support and implementation.

At the members’ request, UHC created a medical device security team, of which Cathy was a member. The team has spent the past year studying the issues surrounding medical device security and working with the AMCs to identify potential solutions for dealing with this very real and complex problem. Cathy, I turn it over to you.

C. Sprague: Thank you. If we can just get moving here, I know we’re just running a bit long, so we can get to slide two, I wanted to just quickly say who we are, which is the University HealthSystem Consortium.

As noted, we are a consortium of academic medical centers, with over 90 organizations. Some of the things that we do with and for our members include benchmarking studies on clinical and operational topics, new program development, collaborating with our members on such programs as our patient safety net, products and services to optimize the supply chains and we research issues that are of specific interest to our members.

Next slide, which segues nicely into why we’re here. Over a year ago, our CIO member steering committee came to us and asked us to start researching this topic. This came after several of them had been negatively impacted by viruses that had attacked medical devices, causing them not to function correctly. The issue, of course, was also important to members that did not specifically suffer from an exploit, because they still have to go through the time and expense to secure their devices and networks.

UHC did construct a team of senior level staff to investigate the problem; Pete Giordano, who can’t be here today, who’s our senior security analyst, myself and Doug Surch, who is also sitting here with me. So he will help with Q&A. I drew the short straw, which is why I’m presenting.

Next page. What I want to emphasize on this slide is that we are all about collaboration. So in addition to lots of research and interviews with manufacturers and government agencies and industry groups, we talk to our members, lots and lots of members and more members. Our hospitals have a lot of experience and a lot of expertise in dealing with this issue. So by having this pool of expertise to draw on, we were better able to define the problem and identify a number of approaches and stuff that can be taken to mitigate the problem. All of our research resulted in a whitepaper that is available on our Web site, as well as on the link that you were given for today’s conference.

Next page. For those of you following along, and did not print this out, I do have a few little custom animations, so you’ll have to bear with me. I had forgotten this was an audio conference and somewhat difficult to have you navigate through. So anyway, we should all be on slide five right now.

As established, medical device security is a significant issue for all healthcare organizations, not just the AMCs. Medical devices have been breached by … and continue to risk exposure by a variety of factors. If you hit next, you should still be on slide five.

The factors involved, contrary to popular belief and we’re just jumping on the bandwagon that you’ve already heard, are not the direct result of FDA regulations and red tape, they’re really just related to the complex nature of medical devices. Hit next, we’re still on slide five. Security solutions are often evasive, requiring patches to the device software and/or operating systems. Device manufacturers often have strict rules as to who, how and what can modify their software and device. Generally speaking, again, as we’ve heard, device manufacturers take the onus of medical device security upon themselves.

The last for page five, the problem that there is often a disconnect between the manufacturers and providers, as to the definition of secure and more importantly as to the length of time that it is acceptable for a medical device to either be exposed to risk or taken offline.

Next slide, finally on to slide six. So we all need a solution that can accommodate the providers need, timing and sense of urgency, as well as accommodate the vendors’ time and resource constraints. And of course, whatever solution he has to fix and identified vulnerability or provide some protection. The ultimate goal here though, is really patient safety. So given the variety of manufacturers and devices and providers and environments, what we discovered is that there is no single best approach or solution to medical device security. So along with our members, we identified a variety of approaches, short-term and long-term, proactive and reactive measures that can be implemented by providers, manufacturers, third parties or a combination there of.

So select approaches are presented here. The more technical ones, such as the isolation techniques and some of the techniques described in the VA guidelines, are described in our paper, which again I encourage you to go and read.

The good news is that there’s actually a lot of overlap between what you’ve already heard and some of the solutions that we are presenting. So that tells us that maybe different factions aren’t quite as hard as we all might think.

Next page, slide seven. First and foremost, and I apologize, because I know you’re hearing some of this again, but report your problems. As noted, the FDA encourages healthcare organizations to report all problems, when there is any concern whatsoever about the quality, performance or safety of a device. It doesn’t just have to be in the case of an adverse event.

Although there is a lot of anecdotal evidence that malicious software has compromised medical devices, there is a notable lack of formal evidence. So without this formal reporting, the FDA is limited in its ability to act or intervene. Reporting is something providers and arguably the manufacturers themselves can and should start doing immediately.

One concern that I know providers have and that MSVA has heard several times, is issues surrounding confidentiality. Providers don’t necessarily want to risk their reputations by suggesting that their network has had a security breach. MSVA and MVFDA do take this seriously and do everything they can to protect the identity of the reporting person and/or organization, to the full extent that they can, by Statute of Regulation.

Next slide. So our next suggestion is to have an Incident Response Plan. And effective incident management plan can minimize the damage from a security breach event and provide important lessons for improving the enterprise security posture. The plan obviously must include network devices and provide some back to regulatory agencies and the device manufacturers. This approach has actually met with great success at several of the UHC member organizations.

Next slide. Another recommendation is risk management or basically a vigilant methodology to constantly assess and manage risk. Here I would like to emphasize the concept of the multi-disciplinary team. The teams should certainly consist of both IT and biomedical engineering resources. During the course of our research, we found that often biomedical engineers at the institution know as much or more about the in and outs of the communication of the device, then even the manufacturers themselves.

Risk assessment must also definitely be applied at the device level. By understanding and quantifying the risk posed by each device, it becomes easier to prioritize where to place extra controls. It also aids in making a case to management for needed funds to minimize the risks posed by the network medical device.

Since each device is different in terms of its operating system, manageability, anti-virus posture and level of vendor support for security, it is important to perform this risk analysis for each device individually. Again, I can’t emphasize how critical this is. I mean obviously, or arguably, as the case may be, a Windows operating system device is going to have more vulnerability then a Linux one. Both Surge and Microsoft offer risk assessment methodologies, which can be easily tailored to address medical device concerns and provider concerns.

Next slide. Okay, now we’re moving into some of the little longer term ideas that can be implemented. One idea is to create a common set of questions or a form that might be used to hold a vendor accountable. I do apologize, if you get confused, I tend to use the words vendor and manufacturer interchangeably. I think that’s my software background talking, but we are really referring to device manufacturers and not OTS vendors.

Anyway, one idea is create this common set of questions or form that may be used to hold a vendor accountable during renewals and upgrade planning. The form can also be used during the RFP process. At the least, a form can supply enough information to the provider to understand the risk associated with the device and take appropriate measures. At the opposite extreme, it may be used to make the decision not to buy a specific product and to go with a comparable, more secure product. We actually have some members that are using a form for this purpose.

Obviously, any organization can implement this concept, relatively quickly. The reason we have categorized this as a medium-term approach, rather than a short-term approach is because of the power that can come from using a standardized form. You already heard about the MDS² form, which we really like. With some slight further refinements, this form can become an industry standard that is used both by providers and manufacturers.

It is already actually being actively used, as you’ve heard, by GE. But since it was posted on the HIMSS Web site about three months ago, almost 2000 forms have already been downloaded. As an aside here, I wanted to say that UHC has recently become a member of the HIMSS Medical Device Security Work Group and so we will continue to work on this form with them.

Another example of a form is provided by the North Carolina Healthcare Information and Communications Alliance. They’ve developed the NCHICA Vendor RFP Template, for meeting HIPAA security requirements. Although this was designed more with HIPAA specs in mind, the form provides a good prototype for a medical device security checklist and is actually used by one of our members, the University of Virginia Health System, as part of their RFP process for medical device vendors.

Leading towards the long-term, we feel that consistent use of the standardized form will also start driving some of the longer terms changes from the device manufacturers, in terms of incorporating this into their products. I think we already heard that in GEs presentation, in Scott’s presentation.

Next slide, slide 11. This is another one with my little fancy animations, so bear with me. That segues nicely into the long-term changes, which is a lot of UHC members feel that security components should be incorporated right into the device. They should be installed and supported by the manufacturer and that this would make the responsibility clearer, providing that the user or provider applies maintenance as required, risk is transferred directly onto the manufacturer.

Next, we should still be on slide 11. We do recognize that this approach has several drawbacks, including identifying the best security strategy in software, how security components impact the function of the device, the impact of seeing devices and components within a single environment, the compatibility with the users environment, and of course, the length of time it takes to develop a medical device.

Even though there are obvious drawbacks, the idea has still has great appeal from the provider perspective. But does the accountability and clearer delimitation of responsibility outweigh the costs? Are the vendors willing and are they able? I’m thinking that maybe we can explore this a little bit more in the Q&A.

Next slide. Finally, in terms of solutions, we do believe in the power of collaboration.

Next slide. I’m basically showing you a couple of the groups, and again, this is something you heard from Scott, and we agree.

If you hit next, we are still in slide 13. There is strength in numbers. We truly believe that industry groups such as HIMSS and NCHICA and some of the others that Scott mentioned, can wheedle great influence. I think they can be the driving force that helps providers, manufacturers and government agencies come to a unified approach.

Next slide, slide 14. So to conclude, there is a variety of approaches to medical device security. There is no one single solution that stands out over the others, and they all have merit. The unfortunate truth is that as long as there are computers, there will be a potential for compromise. A combination of approaches is necessary to achieve the maximum level of security required. Because of the rapidly changing environment, the job is never going to be truly finished.

Providers do need to take the appropriate measures to ensure the safety of their own networks, their own environments. However, and here’s the final next, vendors and providers or manufacturers and providers, as the case may be, need to work together to define a common approach and resolution to the issue of medical device security. I think this conference and our HIMSS groups and our NCHICA groups have really gotten us off to that good start. That’s my little spiel. You can get more information from any of our team, and thank you.

J. Crowley: Great Cathy, thank you very much. That was very helpful. It really rounded out our presentations.

Before we jump into questions, let me just say one or two things. First of all, we had overwhelming response to this audio conference, this is the highest number of participants that we’ve ever had; we have over 80 participating sites. We apologize if it took a little bit of time to get on the call. We understand that some of you got on a few minutes late, and for that we apologize.

I do want to again mention the Participant Web site. All of the presenters’ presentations and the references that they referred to, will be on that Web site.

J. Crowley: That was Terrie Reed, she was chiming in. If you do have any questions or comments, you can either address them to the speakers or if you have more general comments on the audio conference, please contact Terrie Reed. With that, we will go ahead, Joyce, and open it up to questions.

Question 1: Yes, I have a question on working models in consortium based hospitals, of how biomed interacts with IT and if there are any models that are out there, and if there are, are they successful and what are they doing, as far as partnering.

J. Crowley: Okay, Cathy or Doug, do you have any insight into that?

D. Surch: We do have some members that have security models and they have a risk plan, for example the University of Virginia is very effective at it, and there are others that do the same thing. But they have a response team that meets routinely; some of them do hourly and daily scans. But they work together as a team to put together what their response is going to be. I’m not sure what you mean by a model with the vendors, though.

Question 1: Kind of like a working model. Also, maybe even reporting, are the biomeds reporting to IT, as opposed to facilities or how are they developing their relationships, where that they can communicate the different equipment issues.

D. Surch: Typically what we’ve found is the clinical engineers, the biomedical engineers report it up through the clinical and the IT, and was separate, it was a matrix collaboration of the two groups that got together for the security. We can get that information out there, but there is a recommendation of who should form that team and how often that team should be put together. But I don’t have that with me right now.

J. Crowley: Alright, Doug, thank you. That would be great, we’ll go ahead and put that up on the Participant Web site, we’ll contact you later for that. If there are any meds, from hospitals out there, as well, as who have any, what they consider to be successful models, you can go ahead and send those to Terrie Reed, as well and we’ll post those on the Participant Web site. Next question, Joyce.

Question 2: Thank you. This was a great presentation. I have three points to make. One is that even if everybody adapts the consolidation of standard, tomorrow, we still have introduction of both off-the-shelf software and medical devices, in different sequences of time. So it’s very difficult to put vendors, manufacturers, providers, whatever you call them, at the same table, at the same time, because you have to live with some infrastructure that’s already in place. So I would like to ask the question, number one, is how do you deal with existing conditions, when you add new items to it, like new software to a device and so on?

Number two, medical devices that are in the hospital have different software versions embedded in them and not necessarily that information is provided to the clinicians or to the biomedical or the clinical engineers. By the way, Scott, you need to add clinical engineers to your metrics, there are more than just IT out there. So how do you deal with the lack of information on the interaction between medical devices and network, when the information is not provided by the manufacturers?

The last part is on service contracts. Some of the service contracts provided by outside the hospital organization, are claiming that they have to put patches in, in order to qualify you for the service that they provide, and how do you validate those kinds of conditions?

J. Crowley: Okay, there are quite a few questions there. Scott, do you want to try to start us off on this one?

S. Bolte: It sounds like you’re talking about a situation where there are, software-only, packages and a few of GEs products are indeed structured that way, where we will sell you it, you will then install it on a system of your own choosing and your own local engineers would manage that.

The point I raised about the validation, to make sure that the patch is correct, the burden then transfers to you. You fortunately have the freedom and flexibility to do testing sooner and to maintain your own infrastructure and your own devices. But the tests that we’re doing, to make sure that it continues to operate properly, are tests that you then should be doing.

These are not tests that you create at 2 a.m. when MS Blaster is hitting. This is something that you plan ahead, you understand how the device will be used and you try to look for the interactions between the software packages from different vendors. It’s a hard problem. This is one of the reasons why it takes us some time, because the dependencies and interactions, sometimes are very easy to detect and other times they are very subtle, and it can take some time.

As far as how do you deal with the different versions of the software, it’s still a very basic fundamental problem that I don’t think has been solved. If you look at Microsoft, for example, they will talk about the vulnerabilities for two, three or four versions of their operating system, at most. I don’t know how many hundreds of installed base products that we’re installing, different types that is, at any one time, but we’ve got a much more complex scenario and it takes effort, it takes planning and it takes resources, there’s no way to just magically get around it. I don’t know if that’s a satisfactory answer.

J. Crowley: Doug or Cathy, do you have anything to add to Scott’s answer?

D. Surch: Yes, we do. Actually you kind of mentioned the mix introductions between the software and the vendors and stuff like that. Again, if you have a good incident response team and a plan together, you can determine when you get them. A lot of our members, for example, actually the Department of Defense is not a member of the UHC, but what they have done is they’ve required certain things to be on the device, before they’re going to even accept it, and they’ve been very successful at doing that. So that’s just an example of how the end user of the device can enforce what they want and what they want to happen. But again, if you have a well-defined CERT plan, then I think that will do that.

The other one you talked about was the service contractors requiring that they do the patch. I think this conference will give you the leverage to go back to them and say, “Here is really what the real story is.” You know, “What it is; is what it is,” is a term that has been used before. I think this and what John has said and what Scott has said, all confirm the same story, which is, absolutely, is not a word, it’s put in the patch, but just make sure it’s validated. Any time you accept a device, you need a checklist of here’s what it should or shouldn’t do, and that’s your validation criteria, at a minimum.

J. Crowley: Great. Thanks, Doug.

S. Bolte: Can I follow on?

J. Crowley: Sure, Scott, go ahead.

S. Bolte: Doug brought up a point that I meant to make earlier. I’m encouraging everyone to work in the collaborative forums, to develop best practices and standards. But we want to make sure that we have consistent standards and consistent expectations. So between HIMSS and NEMA, for example, we have a lot of cross-membership; in AdvaMed, once again, cross membership. We talked to the FDA to make sure that nobody is going off and asking for something that’s mutually exclusive from what another group wants.

That’s a position we take with the DOD, we strongly encourage them to work in commercial industry forums, because no manufacturer can afford to have different requirements from each of their customers, be they large or small. So if there is a group that has developed a standard, you should not try to come up with another one that’s slightly better, we should try to make use of it where we can and address new areas, collectively.

J. Crowley: Great, Scott, thank you very much. Next question, Joyce.

Question 3: My first question would be, when I’m dealing with the vendors on the MDS², it doesn’t quite go into the detail that I need for virus protection. On the next version, are we going to have some input into adding some additional questions?

My second question would be we seem to be seeing more off-the-shelf software, which I believe to be more vulnerable. Is this the direction that the industry is going? Are we going to continue to see more movement towards off-the-shelf software? Thank you.

J. Crowley: Easy for you to say. Scott, do want to at least take on the first part of that question?

S. Bolte: Sure. The MDS², we realized we were working under a deadline, and we did not want to take the time to make it perfect. We realized that we had to get something out there soon, something practical and something useful, recognizing that we may need to come back to it.

There is a subgroup of the HIMSS group, right now, that’s trying to determine where we turn our attention next, whether it’s adding or clarifying a few questions to the existing MDS², whether we talk about network protocols and needs, whether we talk about something else entirely. That discussion is still going on, I think we will go back and revisit the MDS². I’m hoping that people will be able to use it as it is now and we don’t see it start to fragment, already.

As far as the use of off-the-shelf software, I alluded to it, as to what we’re doing, which is trying to strip out things, rather than add more complexity, add more components, add more things that need to be tested for interoperability and validation, try to get it down to it’s bare essentials. That will reduce the size of the target. So just because we use the commercial operating system, we won’t necessarily have the same vulnerabilities. That’s the goal, because we don’t want to have to patch these, we would much rather be able to say, doesn’t apply, doesn’t apply, doesn’t apply, as vulnerabilities are announced.

J. Crowley: Great Scott. Doug or Cathy, do you have anything to add to that?

C. Sprague: I just wanted to say that I basically agree with you that MDS² is not perfect and we’re aware of that, and UHC has recently joined the HIMSS Medical Device Security Group, as well as the subgroup that’s working on refining the form. So I just want to emphasize that it’s a great starting place and that with a few refinements, I think it will address your concerns.

J. Crowley: Great. Thanks, Cathy. Joyce, next question, please.

Question 4: Hi. References were made to two medical device incidents that occurred that were reported to the FDA, can you elaborate on the details of them, briefly?

J. Murray: I don’t have that information available, but I can tell you that neither one of those reports involved any injury or any death of any kind. They were merely reports of a user who said, “I have a patch problem, I’m having trouble getting an update, I’m concerned that I might have an unsafe condition here.”

Question 4: So there was nothing that took it as far as direct patient delivery of a service or a treatment or anything.

J. Murray: That’s correct. There’s no report of denial of service, no report of any injury or death. It was merely the user saying, “I have an issue here, Microsoft announced a patch, I think it was, and I can’t get an upgrade from my device manufacturer, what should I do?”

Question 4: Okay. Thank you.

J. Crowley: If we can find and post those reports, we will do that, as well.

J. Crowley: Okay. Joyce, next question, please.

Question 5: Hi. What is the recommendation for maintaining security on medical devices that have support modem connections, which are constantly connected, because of a vendor requirement?

J. Crowley: Scott, would you like to try to answer that?

S. Bolte: I don’t know details. I do know in broad, that we do point out that some of our legacy devices, are indeed dependent on modems for service. When they were designed, that was the only avenue for reaching them. The idea of an Internet connection or Broadband connection was in the distant future, and we cannot retroactively modify those devices to make use of the new communication channels. However, if the healthcare provider is comfortable with a break/fix model, where we wait until a complete failure of the device or something that’s obvious to the customer, they can disconnect the phones, when there’s a problem, contact our support organization, connect it for the duration of the service and then disconnect it after that.

What is lost at that point are proactive diagnostics. It depends on the actual product, but some of our systems are doing ongoing monitoring of themselves and can notify the service organization, when there is something that is getting out of spec, when there may be a problem, and we can proactively fix things, before there’s a disruption of service. When the phone is disconnected, obviously, that is lost.

J. Crowley: Thanks, Scott. Doug or Cathy, do you have any insight into this?

D. Surch: There are a couple of different solutions, and we don’t know the specifics. But some of our members have put things like firewalls between the modem and the device, to limit what ports are being attacked. As Scott said just a little bit ago, if you can narrow down that window, you’ll narrow down your risk of attack.

VPNs is another way that you may go about. But again, I’d kind of need to know the device. But initially I would say my reaction would be a firewall.

J. Crowley: Great. Thanks. Joyce, next question, please.

Coordinator: Question 6, your line is open.

Question 6: Scott, you had a real good point in one of your slides where you pointed out that medical devices are provided with filtered power, filtered air, filtered water and the idea of, why not a filtered network? But in my experience, the vendors and manufacturers are very hesitant to tell the hospitals how they should network these devices, and consequently they’re often just kind of plug and play. What’s your comment on the hesitancy to give hospitals a little more guidance on exactly how they should network these devices for security?

S. Bolte: We have an IT professional services organization that has been involved for many, many years, but more traditionally in the PAC or patient monitoring arena, where the need for high availability, high bandwidth, well-engineered networks has been obvious, for quite some time. That organization, I’m not sure how large they are, so if everybody called today, they might find that there’s a bit of a delay. But that organization can be engaged to learn more. We point at best practices, such as the BAs, Medical Device Isolation Architecture, I’m not sure I’ve got the name quite right, but it’s in my presentation, as a group that’s done it themselves. The Army has created a network enclave architecture that they’re testing out at Eisenhower Medical Center, I believe.

In all these organizations, we encourage them to make it available for other groups to see and learn from. So this is a situation where a best practice can be demonstrated. But there are other consulting organizations, either dedicated to the medical device industry or network in general, that can be engaged to understand or can help you understand and control your network.

One thing I do encourage people to do, when they embark upon this, is to empirically gather data for quite some time. When we release the device, we have certain expectations, but we don’t necessarily know the interconnects, we don’t necessarily know what additional modifications you have made to enable certain services, when there’s a software-only relation or things like that. So don’t go in and just start clamping down, but monitor or perhaps inbound connections to a medical device first and then after you quite comfortably understand the usage patterns, start to reinforce that and restrict it further.

J. Crowley: Great Scott. Thanks. Doug or Cathy, do you have any insight?

D. Surch: No, not from that end.

J. Crowley: Okay. Joyce, next question, please.

Question 7: Yes, is anyone pursuing ethical hacking, rather than wait for an incident, to see if systems can be cracked into?

J. Crowley: Scott, that sounds like something you might know something about.

S. Bolte: I mentioned in my presentation that we’re doing vulnerability assessment scans. We use a standard tool, we actually enable all of the non-invasive and invasive tests, we basically throw everything at our products, because we know they are safely in our development environment. They’re often tested; they’re being used for nightly regression tests and such. If there is a problem, there is no impact.

A couple of years ago, I started asking around, to see if there was interest inside the company or in our customers to do a similar scan in the hospital infrastructure and while that wouldn’t necessarily go to ethical hacking, which is more of a manual process, it would certainly be a step in that direction, and there an awful lot of issues and concerns around that. So much so that there are more important things that we decided to pursue.

If you do decide to use an automated tool or do decide to engage a company to help you understand your resources from a black box or a white box testing perspective, you need to be very careful to coordinate with the clinical users of the devices. By definition, these tests are going to be trying to do things that can hurt the device. Yes, it’s important to know that, yes you want to find out that there’s, for example, a buffer overflow problem, but you don’t want to do it while there’s a patient on the table. So that amount of coordination is pretty much going to be driven by the healthcare provider.

J. Crowley: Great, Scott. Thanks. Doug or Cathy?

C. Sprague: It sounds, actually, like an interesting idea. In all of our conversations, we did not run across anyone who was specifically doing that.

J. Crowley: Great. Thank you. Joyce, next question, please.

Question 8: My question concerns the life span of medical devices being considerable longer than other information devices. How does the FDA approach a vendor who has gone out of business or with a software product that is no longer supported by the original vendor?

J. Murray: The basic law requires a medical device manufacturer to provide maintenance or survivability of a medical device, for the expected life of the device. But that kind of get narrowed down when a manufacturer decides to stop marketing that device. From that point on, their only true legal requirement is to ensure the safety and effectiveness of that device.

So unless it’s a safety related issue, the FDA probably has very little teeth that they can issue in the here and now. An idea I have, which I’ve been floating around for awhile and no one seems to be biting, is that why doesn’t medical device software have an expiration label, just food or drugs? Because we all know when we put something out on the market that it only has a certain lifespan before it actually has to go to the next generation or next thing like that. I’ve been kind of tossing this idea around for awhile and I recently found out that in the new version of the medical device standard, which is 60601-1, there’s actually something in there that calls for the expiration labeling of all medical devices under the new standard.

I’m going to call those folks up and say, “Well how does this apply to software?” Because I really believe that we need to be honest upfront and when you sign a contract with a device that has some software in it, you need some kind of idea of what your expectation could be for the life of that device and the support for that software. Each individual device manufacturer has a different policy, but it should be made clear, and I suggested actually being in the labeling or the user manual of the device. Do you have anything to add to that, Scott?

S. Bolte: I would add that external controls could be a very valuable way to extend the life of a product, if you cannot for some reason, alter the original device, perhaps the manufacturer has gone out of business or there are other constraints upon making that change. Like I said, at least from a network perspective, adding a managed switch can reduce exposure quite a bit, and perhaps get more viable use out of the device.

J. Crowley: Great. Thank you. Joyce, next question, please.

Coordinator: I’m showing no one else in queue.

J. Crowley: Great, Joyce. Thank you very much. I’d like to thank our three speakers, John Murray from FDA, Scott Bolte from GE Healthcare and Cathy Sprague from the University HealthSystem Consortium, for presenting today. I’d like to thank all of you on the phone for listening and for your very good questions. I’d also like to thank Terrie Reed for organizing this conference. With that, I wish you all a good day and we’ll talk to you soon. Take care. Bye.

Updated July 18, 2007