Decrypting FDA's RTA Policy for Cybersecurity

Naomi Schwartz, the Senior Director for Cybersecurity Quality & Safety at Medcrypt, a medical device cybersecurity specialty firm, shares some interesting tidbits about FDA's upcoming Refuse-to-Accept (RTA) policy for Cyber Devices and Related Systems. The policy is effective Oct. 1 and Schwartz breaks down what the RTA will mean for medical device manufacturers and their FDA submissions.

Episode Transcript

Omar: Well, Naomi, welcome to let's talk medtech. I'm so happy that you're here with us today.

Naomi: Thank you.

Omar: Before we jump into FDA's new refuse to accept policy regarding cybersecurity, before we discuss it, can we talk about the overall concern with cybersecurity and medical devices? Paint a picture of the landscape for us right now.

Naomi: Sure. The landscape today is complicated and it's evolving. There are a lot of devices on market today that have been around for 20 plus years. Many of them have little, if any consideration given to security, and we need them. Hospitals can't just turn around and fully replace their inventory overnight. There are a lot of new devices on market that have security by design and are reasonably robust. And then you have everything in between. You have regulatory bodies who are accelerating their awareness of cybersecurity and are increasing their requirements and communicating this. So, we're all basically learning and getting up to speed together. At the same time, there's a lot of opportunity to collaborate and there's some opportunities to make mistakes together.

Omar: Yeah, and I'm just thinking about something you said maybe 15, or 30 years ago. Cybersecurity wasn't even a concern for a lot of these technologies, a lot of these devices.

Naomi: Sure, banking has been dealing with cybersecurity for a very long time, and we can learn a lot from lessons they've learned over the years. But the medical device manufacturers have historically been focused on building systems, and the software has really taken over the feature set in a way that maybe they didn't anticipate 20 years ago. And a lot of these systems are being much more involved on the cybersecurity side because they're involved with so much more software feature set and because they're connecting to each other now and connecting to EHRs, and there's a lot more networking going on. So this is where a lot of the lessons learned from other spaces really need to be absorbed quickly.

Omar: Now I want to go and talk about the RTA policy in basic terms. What is it saying?

Naomi: So the RTA guidance is, first off, really bringing attention to the amendment to the Food, Drug and Cosmetic Act, which is section 524 B, which gave them statutory authority to insist upon Cybersecurity documentation for any pre market submission. We're talking 510ks, we're talking de novos, we're talking PMAS for each of these submissions to FDA to request marketing approval or to notify FDA of the intent to market. FDA is basically saying, hey everybody, you saw the Patch Act got passed as part of the appropriations bill. Here's a repetition exactly what's in 524 B? A repetition of what it's requiring you to submit. And we want to highlight for you that we're not going to start refusing to accept until October 1, but that we will be sending you interactive review questions if between March 30 and October 1. We're finding gaps because they want to give people time to get up to speed and to incorporate this information into their submissions, but they don't want to wait too long.

Omar: Would it be fair to ask if this is enough time? Is this going to be overwhelming for some companies?

Naomi: Well, so that's tricky, right? I mean, this is not out of the blue. The Patch Act has been under discussion for some time, so manufacturers should have been paying attention for a while and should have been aware of it. But there's a further nuance to all of this that bears discussing because I haven't really seen too many people talking about it. And that is in parallel with issuing the RTA guidance. FDA in June made a new announcement about their pilot program for the Electronic Submission Template and Resource, or Estar mechanism for submitting five hundred and ten K and de novo submissions. The Estar pilot has been running for some time. FDA has had a lot of opportunity to test it out and receive public feedback. As of June 9, they issued an update to the program indicating that, first of all, there's a new template for presubmissions. So everyone is supposed to be submitting these things electronically and not through these giant monolithic submissions to the document control center now, but as of October 1, all 510K submissions, unless exempted, have to be submitted through Estar. And there's a final guidance about Estar that explains some of this, but it hasn't been framed in the same context as the RTA guidance. It has immediate impact to Cybersecurity content. So while FDA issued this RTA guidance saying, we're going to start refusing to accept as of October 1, it's actually not quite like that. The Estar template doesn't even let a company submit to FDA until they've fully filled it in, which includes identifying electronic interfaces and if there are any, completing all of the relevant sections for Cybersecurity. So theoretically, the Estar refuses to accept on behalf of FDA because somebody failed to identify something that they should have. Theoretically, you could also just bluff your way through it and say, I have no electronic interfaces, which would preclude you from having to include Cybersecurity. You know, according to the guidance, due to the use of automatic verification, the FDA does not intend to conduct a refuse to accept review for submissions submitted as an e star. Now, that's a quote from their guidance. So theoretically, they're not even going to refuse to accept because Estar is supposed to do it for them. But it gets even trickier. FDA will employ a virus scanning and technical screening process for each Estar they receive. The virus scanning thing. Obviously, that's FDA's Cybersecurity diligence the technical screening process lets them say, oh, you told me you have no electronic interfaces, but right here you're telling me you have USB, which is an electronic interface. You failed to submit any Cybersecurity documentation. We're going to kick you out. So, if the Estar submission is not complete when submitted, FDA will notify the submitter by email, identify the incomplete information, and the submission is placed and will remain on hold until a complete replacement is submitted. So, there's not exactly going to be an RTA for Cybersecurity for 510 KS come October. It's going to be a little bit different than and the RTA guidance didn't even point to this, but there's going to be a mechanism either way by which FDA can say, you should have told us about this. You didn't. We're not reviewing it.

Omar:Those subtleties or maybe that shouldn't be considered a subtlety, but it's just those nuances that I would say that MedCrypt kind of helps point out to manufacturers just to guide them through some of these policies. Can you talk a little bit about the work that MedCrypt is doing in this space?

Naomi: Sure. A lot of companies who focus on Cybersecurity don't specialize in medical devices first, so a lot of them might miss that nuance. They might not be aware of Estar at all because we have several people who came out of FDA doing Cybersecurity work deeply me from the diabetes space, and Seth primarily from policy, although he actually used to be in my review branch. We have a depth in terms of the understanding of FDA's thinking that your typical IoT cybersecurity firm won't be able to bring to the table. In addition to that, a lot of companies have a basic set of Cybersecurity documentation, but they don't know how to bring that together with the rest of their quality system. So MedCrypt brings a deep understanding of both the quality system and the Cybersecurity and marries the two in a way that helps the manufacturers who come to us asking for help. We get them to a right sized documentation practice, and we help them understand continuous improvement activities that they can engage in over time that will get their maturity evolving. But it's not the kind of thing you change overnight, and a lot of companies really need that little bit of help that says you have some gaps prioritize them. It's not like you can just throw your entire budget at fixing these problems tomorrow, but here are the ones you have to fix first.

Omar: Yeah. And I would guess with cybersecurity and with software, it's always evolving. The problems you might have today might not be the problems or the issues that you face six months from now. Would that be correct? Yeah.

Naomi: And especially when we start talking about medical devices that are incorporating artificial intelligence or machine learning, you add an entire depth of complexity there because you have to understand your data integrity. You have to understand how to manage the different kinds of data and how to manage your update cycle and all sorts of tricky things. But FDA has been very active in having conversations with industry about that and putting out white papers to elicit response and to understand where people's concerns are, where the sticky points are. Because, again, this is a space where we're all learning together. We are very much building this plane while we fly it.

Omar: Yes. That reminds me, whenever we would interview entrepreneurs that were coming into the space, they were coming into medical devices. They'd been in other disciplines in the past, software engineering, so to speak. And they would come into Med tech, and the huge hurdle that they would face would be the regulatory environment. Not necessarily knocking FDA or anything like that, but it was just an unfamiliarity with the regulatory landscape. And the comments we would always get was things moved so slower. We were able to do so much in this industry. But when we came to medtech, we hit a huge roadblock. And I think that companies, especially entrepreneurs and smaller companies who are just coming over to the industry, they need someone to help them bridge the gap, to understand these nuances, to understand the regulatory environment, especially when we're talking about cybersecurity.

Naomi: Sure. And FDA has a large and well established and complex infrastructure. If you've never worked with them before, a lot of that comes as a surprise. I can work with a startup tomorrow, and I can give them a list of 1015 30 guidance documents that are pertinent to their particular system that they need to take into consideration, and that can span the gamut of basic. Here is how to submit a 510K. Here's how to manage software change in 510 KS to biocompatibility, human factors, cybersecurity, interoperability. There are so many of them that you have to help people understand. Which ones do I need to know about right now? How do I find help in these areas? Really small companies often don't have in house expertise in biocompatibility or human factors or cybersecurity. We'll have people call us up and say, hey, can you help us with artificial intelligence and machine learning? And we'll say, you know, we have a friend who does that. But we at MedCrypt are solely focused on cybersecurity for medical devices that touches on interoperability. And we can have a good conversation there and really support someone. But we're not going to be supporting the AI and ML conversation because that's not our space. But it's really important to know whose space it is and help people find that rapidly, because startups especially need to rapidly find the right people who can help them figure out when they need the help and fit that into their schedule in an optimal way. They don't have large amounts of money, they don't have large amounts of resources. They can't throw a 50-person team at the problem. They need to really be very targeted.

Omar:So, when we're talking about the current policy, the RTA, when we're talking about this guidance, it seems as if this has some real teeth to it. Would you agree to and if it does, what makes it different from other attempts in the past or other cybersecurity initiatives from FDA in the past?

Naomi: So, RTA has real teeth, and that's really because we have statutory authority written for the administration now. In the past, the agency has made recommendations. That's what guidance documents are. They are a set of best practices, things that FDA recommends, but you can always push back and argue, well, for this reason or that reason, this doesn't pertain to us. And that leads to a long cycle of FDA showing why they disagree and trying to leverage the quality system regulation to demand the information they're asking for. Manufacturers can't push back with reviewers now because it's no longer guidance, it's not a set of recommendations. It is a set of statutory requirements, period. The RTA guidance itself just says, hey, we're going to bring this to the table and enforce it starting in October at the Refuse to Accept Point, rather than doing it interactively, which started in March, they're going to be issuing deficiencies. They're going to issue hold letters and files are going to come to a stop from FDA's review side and go back to manufacturers, and there's not going to be any more of this squishy. Well, we don't think we need it. Why are you pushing us for it? It's full stop. It's a requirement, and that's really important. It takes the burden off FDA reviewers to give a solid explanation through risk management principles and puts it back on the manufacturer to do the right thing from the start.

Omar: Wow. I want to ask this question now because obviously you have companies that are coming to you all the time just seeking some answers to questions. When is the right time that companies should engage with you all with MedCrypt, and when is the wrong time? When is it too late? Are there any nightmare scenarios that you can point to? You don't have to go into specifics, but. When is the wrong time for engagement and when is the right time?

Naomi: Yeah, so there's no wrong time for engagement. I mean, you see the full spectrum. MedCrypt receives calls that say, we submitted something 45 days ago and we started getting some interactive review questions hinting that there are some problems with our cybersecurity. And we think in a week FDA is going to issue us a hold letter. We are going to need your help. Is that too late? No, it's not. It's a good time to get into the problem because you're going to have FDA giving you very specific direction about what's missing and how they think you need to correct it. Is it preferable to find that out before you ever submit? Sure, but that doesn't mean that we can't help somebody. We get calls all the time where people are in a real rush. They're trying to get something submitted to FDA very soon and they want just a quick look at it in a sanity check. How far off are we? We had somebody tell us, we're submitting a response to an interactive review question on Monday and it was like ten days ago. Can you help us get this put together right so that we can lay this to bed and get this thing cleared and we can rapidly ramp up on a project like that. It doesn't hurt in this case that it's a project I was already familiar with because we've worked with them before. But it's hard and we MedCrypt are small, so we have to be able to spin people up very fast. And that means that we have to have some answers rebuilt that we can fine tune to help particular manufacturer with their specific problem. It's much, much preferable to have someone call us and say, we're going to market in a year and a half and we'd like you to take a look at some stuff that we're thinking about. We don't fully have our design completed, but we want to make sure we're not off target. Is this the right way to do this particular type of cryptographic methodology? Is this a good implementation? Do you have recommendations for how we can change it? How do we do key management? Because you need to have a plan for these things now. That's part of what is in section 524 B. Have a plan for the entire lifecycle. If you start early enough, we can delve into that and really build out a timeline that lets people plan their resources, figure out if they need to invest more than they're expecting, which is usually true, and put it together right. But you could come in anywhere between there. You can come into us and say, we got a bunch of legacy products and we need to figure out what the risks are with them. That's a totally separate conversation, and it's not necessarily about a submission that's going in, but it's about recognizing that you need to manage your vulnerabilities for your on market products. And we do a lot of research in that area where we're poking at things and figuring out how do you handle an inventory of 25 legacy products and maybe 20 more products that are not legacy. They're still patchable. They're being patched, but you need to manage them across a wide install base. That's another area where there's a lot of activity and there's going to be a lot of enforcement focus in the near future, as FDA says. All right, you guys have had time to build this into your premarket. Let's talk about what you're doing in your post market.

Omar:Lots of good stuff.  If a manufacturer wants to get in contact with MedCrypt and use MedCrypt services, where can they go? How can they get in contact with you all?

Naomi: So you can start off at our website. We have ways to reach out to us through the website. We get a lot of touches through LinkedIn or other things. We're at conferences frequently, so you can look for MedCrypt. Sometimes we'll have a table and a banner up. Sometimes we're giving talks. We're very approachable. We love to have conversations with folks. You can just reach out and send emails to any one of the primary stakeholders if you have our email addresses. But the easiest way to reach out to us is through our website.

Omar: Sounds good. Well, Naomi, thank you for speaking with us. Thank you for coming on to let's talk medtech. Appreciate the conversation.

Naomi: Thank you for having me.