Why SaMD Companies Should be Leveraging Pre-Submissions to FDA

Software as a Medical Device (SaMD) is one of the fastest growing segments of the medical device industry. How are regulators keeping pace with its growth? FDA has a set of specific requirements unique to SaMD that companies are expected to meet in order to market these devices in the United States.

In this episode of the Global Medical Device Podcast, Jon Speer talks to Andrew Frink, regulatory affairs manager at Proxima Clinical Research (CRO) about how companies can improve outcomes of bringing a SaMD to market by leveraging FDA's Pre-submission, which involves meeting the agency's applicable regulatory guidelines and pre-sub expectations.

LISTEN NOW:

Like this episode? Subscribe today on iTunes or Spotify.

Some highlights of this episode include:

• Pre-sub preparation: When a medical device and/or software company wants to expand, the first step with FDA should be a pre-submission meeting to present a packet of information for formal feedback.

• Follow FDA’s guidance documents to know and understand the differences between pre-submission expectations and requirements for 510(k), De Novo, and SaMD regulatory pathways.

• Pre-sub benefits: Save time and money by starting a dialogue to move forward with confidence based on FDA’s formal feedback about achieving regulatory requirements and intended use.

• Minimum Pre-submission must-haves:

  • Detailed and clear device description

  • Intended use statement with medical benefits and impact

  • Target audience description (patient population and intended users)

  • User interface screenshots and device output

  • Risk hazard analysis and mitigation for level of concern

  • Verification and validation plan/outline

  • Software development process documentation (Agile, waterfall, etc.)

  • Cyber security description

  • Off-the-shelf software/code use of unknown pedigree (AWS, Docker, etc.)

Links:

Andrew Frink on LinkedIn

Proxima CRO

FDA - Software as a Medical Device (SaMD)

FDA - Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices

Premarket Notification 510(k) 

De Novo Classification Request

ISO/TR 24971:2020

ISO 14971:2019

EU MDR

2021 State of Medical Device Virtual Summit

Greenlight Guru YouTube Channel

MedTech True Quality Stories Podcast

Greenlight Guru

Memorable quotes from this episode:

“A pre-sub is vital to almost any submission to the FDA. It’s a chance to get formal feedback from FDA.” Andrew Frink

“What do I need to provide to FDA? Software is a little bit different. It’s not tangible good. It’s not something I can hold in my hand per se.” Jon Speer

“One thing that most software developers struggle with is this intended use statement. This is one of the most critical pieces of information that you can give to the FDA.”  Andrew Frink

“FDA is very open to different software development systems. They do want you to document and describe your software development environment.” Andrew Frink

Transcript:

Announcer: Welcome to the Global Medical Device Podcast, where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Jon Speer: We've talked a decent amount about Software as a Med Device on the Global Medical Device Podcast. We've also talked quite a bit about pre- submissions in previous episodes, as well. I don't think that we've ever kind of merged or blended these two topics together until now. Joining me on this episode of the Global Medical Device Podcast is Andrew Frink. Andrew is with Proxima CRO, and we talk about some of the expectations from a documentation standpoint that you should include in your pre-submission if you're a software as a medical device company. So enjoy this episode of the Global Medical Device Podcast. Hello, and welcome to the Global Medical Device Podcast. This is your host and founder at Greenlight Guru, Jon Speer. We talk a lot, well, inaudible we talk about software as a medical device. Why is that that we spend so much time talking about Software as a Med Device? Well, it's one of the fastest growing segments of the medical device industry. And I think if you're paying attention at home with all the gadgets and smartphones and apps and all of these sorts of things, it kind of makes sense. There's certainly a lot of growth in this particular area, but it creates some confusion at times, especially with regulatory agencies because software is this ethereal thing. It's not a tangible good that I can hold. And sometimes the things that I do from a testing or from a documentation perspective may seem a little bit different. So I thought we would try to address some of those expectations. What is the FDA looking for with different types of regulatory submissions for Software as a Med Device? And joining me is Andrew Frink. Andrew is with Proxima Clinical Research and he specializes in regulatory affairs. So Andrew, welcome to the Global Medical Device Podcast.

Andrew Frink: Well, thank you, Jon. Happy to be here.

Jon Speer: Absolutely. I guess a good place to start is you surface this topic like," Jon, this is something that we're dealing with. This is a kind of a hot topic." I guess maybe that might be a good place to start. What are you seeing as sort of the challenge or the obstacle and why does it make sense for us to dive into some of the details today?

Andrew Frink: Certainly. So we have a lot of clients come to us. They're sometimes early stage medical device companies or software companies that want to expand into a medical claim and they have the question," Okay, what do we need to have that first step with the FDA? What do we need to have that first conversation and see where we sit in terms of regulatory pathway, get that initial feedback from FDA in terms of what they're going to expect us to do for our device?" And typically that first interaction for most medical devices would be a pre-submission meeting. I'm sure most of your listeners are familiar with that. And so that that meeting is a relatively formal affair. You have to prepare a packet and send it in and schedule a one- hour meeting with the FDA where you discuss it. You receive written feedback from the FDA on specific questions that you're trying to address in that pre-sub. And these questions can range from anything to the suitability of a predicate for a 510(k) to specifics about testing plans, verification and validation methods, or details of clinical studies. There's a wide range of things you can discuss in a pre- sub. But there are some kind of base minimum things that we see that if we try to engage with FDA too early and the client doesn't have these things, FDA consistently asks," Where are these things? We need to have these things in order to assess your device and answer these questions that you've come to us with." And so for software devices sometimes these are created somewhat quickly. It's a fast moving environment, very competitive. And that means that sometimes all of the documentation or the risk analysis, hasn't all been put together. And so it's an important thing to put that together for that initial conversation with the FDA, so that you look like you have a firm foundation in these things, and you have an idea of risks and risk mitigation. You really want to present that as a good face to the FDA in this first interaction. And so some of these things that you can start to put together, one of the ways that you can get a hint of what FDA is looking for is they have published online a pretty detailed guidance about what software devices need to provide to FDA for a market submission. So this would be a 510(k) or a De Novo. And they have a whole list of documents with quite a bit of detail involved in describing each one of them. But then the question comes, well, this is a whole lot of work. This is going to take months to put all this together. Do we need all of this for a pre-sub? And the answer we've figured out is no, there are parts of it you can skip, or you can summarize. You just need a plan. You don't need the full potato. And so happy to talk about those differences today.

Jon Speer: Yeah, sure. Well, sometimes it's hard to figure out where to jump in. So we'll just jump right in the middle. Andrew was mentioning this guidance document. It is, as far as guidance documents are concerned, a little bit... got a little bit of age to it. And I actually surprised by the data on this as it relates to software, but it's Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices. And this actually dates back to 2005. So that's eons ago, as far as software is concerned. And we'll be sure to share a link to that. But to your point, this is for pre-market submissions, and pre-market is sort of code for something like a 510(k) or De Novo, whereas a pre- sub, I know that the Q-submission program has been around for a bit. It seems like it's more in vogue within the past few years. And I guess before we dive into the specifics of the software side of things, I assume, to your point, that a lot of the listeners probably do know what a pre- sub is, or has heard us talk about it in the past, but maybe talk about some of the benefits of a pre- submission, regardless of it's Software as a Med Device, or just regular med device. Why would one consider going the pre-sub route?

Andrew Frink: Absolutely. I think a pre-sub is vital to almost any submission to the FDA. It's a chance to get formal feedback from FDA. They have to put down in writing what their stance is on a particular issue. And that allows you to move forward with some confidence that your testing plan will actually meet the FDA requirements. So you don't have to guess on this. You don't have to spend a whole bunch of money designing a, a testing plan or even a clinical study plan without that FDA feedback and a formal feedback, even, that you have in writing. You can refer back to it and say," We followed this plan, and this FDA review team agreed that it would be sufficient to meet the intended use that we described."

Jon Speer: Yeah. I was just going to say, I've had a few personal experiences with pre-subs and a lot of anecdotes from other companies that we've worked with. And it's just a really invaluable way to get an audience with FDA relatively early in your development cycles, so that you have some clarity about how this is going to be viewed in the eyes of regulators. But it's also a good opportunity, I think, maybe more so than anything else, for me to start the dialogue with the FDA about this thing that I helped to bring to market sometime in the not too distant future. Remember folks, if you don't... Think about it without a pre-submission. If you put together a 510(k) and you send it to FDA, a lot of times, that's the first time they've ever heard of anything that you're doing, so it's all new to them and there's probably going to be lots of questions. So pre- sub is a great way to try to get some of those questions surfaced a little bit earlier so you can understand how the FDA is looking at this particular product or this space that you're pursuing. So it's a really good opportunity. And like I said, you can do this generally pretty early in the process, but the point of this conversation is discussing how this relates to Software as a Med Device. And to your point, if you read that pre- submission guidance, the list of documentation that is expected for a medical device containing software, including software as a medical device, it's pretty lengthy. And so it's a little confusing if... What do I need to provide to FDA? Again, software is a little bit different. It's not tangible good. It's not something I can hold in my hand per se. So let's dive into some of the expectations. What are the minimum barriers to entry, if you will, from a software perspective, if I'm going to pursue a pre- submission?

Andrew Frink: Sure. I think the number one thing is a really detailed but still very clear device description. This ties into your point about pre-subs is you want... When you end up submitting your 510(k) or De Novo to FDA, and they're actually making regulatory decisions about your company that will impact whether or not you can go to market, you want them to already be familiar with your device. You don't want them to be asking," Well, what does it actually do?" What we found in this pre-sub process is that no matter how detailed we make this device description, there's still always questions that reviewers have. There's still something that they sometimes misunderstand. They're humans too, and they have limited time to read through these things. And sometimes it's a thing that we did leave out or we didn't think about, and they just want more information about it. So these pre-subs are really critical to describing your device, making sure the FDA is comfortable with it, familiar with it, so that when it does get time to doing that full market submission, they can breeze through it. They know exactly what your device looks like, what it does, what it feels like, what are the risks associated with it. And so for software in particular, I think one thing that most software developers struggle with is this intended use statement. So this is one of the most critical pieces of information you can give to the FDA is a simple statement, it's typically about a paragraph long, that describes what medical benefit are you going to bring to the patient. How are you going to impact their workflow, how they travel through the healthcare system? And this tends to be very specific. It needs to name a specific medical condition that you're trying to influence, trying to improve, trying to diagnose. And it needs to describe a little bit about how you're going to accomplish that. So are you an AI algorithm that does this? Are you something that takes radiographic images? There's lots of different examples, but these are kinds of some of the things that is really important to describe. And I think FDA oftentimes have suggestions and changes that they want to make to your intended use statement throughout the process, and this is another really good thing to discuss in a pre-

Jon Speer: And on the topic of intended use, I was actually, as serendipity would have it, I suppose, I've been doing a deep dive into reviewing risk management standards. Specifically, I was reviewing the ISO/TR 24971:2020 document. This is a guidance document that accompanies 14971. And there's an annex in that particular guidance, annex a, and there's a section in there that has a lot of questions that can help guide you and help you figure out this intended use. Because to your point, this is the basis of everything that you're doing from a medical device perspective. This is what you claim your product is going to do. And depending on what you claim your product is going to do is ultimately going to have a indicator or influence on how it's going to be classified. So it's really important to really focus on that in every conversation that you have with FDA.

Andrew Frink: Definitely. I mean, this intended use, it influences what clinical evidence... your need to generate. It influences how you're going to be classified, what your regulatory path will be, what predicates you can use. It's really the linchpin for the whole thing.

Jon Speer: All right. So what are some other things that would be expected to be included at the pre-sub stage for Software as a Med Device?

Andrew Frink: Sure. So I think a good description of the patient population, as well as the intended user. So sometimes a good description of the patients that the device will be targeted towards, but also the different users who will be using the device. That might be physicians or healthcare providers of all sorts. That might be nurses. That might be the patients themselves. This will influence your risk analysis and your usability concerns. I think another good thing to include would be user interface screenshots. I think this is another piece that we get to where a lot of companies are very early stage. Maybe they have a smash algorithm that can do something that no one else can do, but they haven't quite built the front end, and FDA is going to want to see it. They want to see what it looks like to those patients, what it looks like to those physicians, what your device output will be.

Jon Speer: And Andrew, in your experience, the user interface and screenshots, do you think that it's okay to be kind of wireframe low-fi or should these be more high- fidelity types of screenshots? Any opinion on that?

Andrew Frink: They can be wireframe. What FDA is really interested in is what information are you providing to patients and healthcare providers, and then, how are they going to use that information? So do they have the ability to interpret the test results or interpret the information you're giving them? Are you maybe giving them information that's not fully supported by the research? It might be more speculative in nature. So that's why they're really interested in the user interface, is how does it tie into your intended use? Make sure you're not overstepping what you're providing to patients and users.

Jon Speer: Yeah. Software is one of those tricky things too, that there are a few different, I guess, practices, so to speak, and the risk-based approaches like determining like level of concern and if you're outside of the US and pursuing EU under the EU MDR. They bring in these different risk classes for software. So what about a level of concern and risk? How important are these things that at the pre-submission stage?

Andrew Frink: Very important. I think these are probably the most important things to have really firmly established before you start the conversation with FDA. Level of concern is kind of FDA's specific risk classification system for software. It has a few quirks to it. And I think the most important is that any mitigations that are software-based cannot be considered when you evaluate level of concern. And that means that if you are a software-only device, then you basically can't include any of your mitigations when you look at level of concern, and you have to end up saying," What's the worst possible outcome that this device can provide, and then what is the possible harm to patients?" And then that ends up getting filtered into either a severe harm that would be life- threatening or irreversibly debilitating without surgical intervention or major intervention, or it would be a minor harm, which more or less encompasses everything else, including increased risk of certain diseases or increased risk of different conditions or an incorrect diagnosis. Or even a delayed diagnosis would be considered a minor harm or minor injury. And all of those would end up in the moderate level of concern. And then if there are no possible harms, then you would be a minor level of concern. For a software as a medical device this probably isn't ever an option. I think this would probably be more something... so for software that's contained in a medical device that doesn't have an impact on the intended use.

Jon Speer: I want to remind folks, I'm talking with Andrew Frink. Andrew is a regulatory affairs specialist with Proxima Clinical Research Organization. You can learn more about Proxima CRO by going to proximacro.com and it's www.proximacro.com. And they help companies with regulatory submissions, pre-subs, 510(k)'s, De Novo's, as well as clinical research and keeping this all together. And it's a team of experts. I've worked with quite a few of the folks at the Proxima team, and top-notch folks. So go check them out, proximacro.com. And while we're taking this quick break, I also want to remind folks that Greenlight Guru is here to help. We have the only medical device quality management system software platform on the market today. It's designed specifically and only for the medical device industry, and it's been designed by actual medical device professionals. So whether you're a" traditional" medical device or Software as a Med Device, whatever the case may be, we've got you covered. We've got workflows especially to help you through the design and development process by capturing your design controls, design reviews, your design history file, your full ISO 14971 risk management and all the aspects of that, document management, change management. And then as you get to market, we have workflows to help you with quality events, including CAPAs and complaints and nonconformances. So go to www.greenlight.guru to learn a whole lot more about the Greenlight Guru Medical Device Quality Management System software platform. And if you're so inclined, click the button to request a demo, and we'd be thrilled to talk to you about some of your needs and see if there might be some opportunity that we can help you with. So enjoy that. All right. So Andrew, we've talked quite a bit about the things that should be included. There's probably kind of a next class, if you will, of documents or items that don't necessarily need to be fully vetted per se, or they could be a little bit less mature in their life cycle as artifacts, but let's talk a little bit about some of those things like V&V planning and maybe some of the software architecture and things of that nature.

Andrew Frink: Absolutely. I think the verification and validation, the V&V plan, I think this is something that FDA always asks us about if it's not included. They kind of want to see, have you thought about this. But typically if we do include some statement that yes, we are planning to do software verification and validation according to this method and outline, it just has to be a few sentences, really, just to let FDA know that," Okay, we do understand this, and we do understand that this is something that's important to consider." Because I guess for those who aren't familiar, the verification and validation for a software- only device is a major undertaking. This is something that can potentially take weeks to months to complete. It's a huge part of the final QMS system for a software- only device. And so it is something that you don't necessarily have to have, coming into the first interaction with the FDA, but it's something you need to be thinking about for your company projected timeline as a whole.

Jon Speer: This is usually the time in this type of conversation where I want to continue to dispel the myths about FDA expectations with respect to product development. Even if you are a software, I think there's this perception that especially a lot of softwares and med device folks have that to be a regulated medical device there's an expectation that you have to be waterfall and you can't be agile. But folks, that is entirely false. Andrew, I don't know if you have any thoughts about that.

Andrew Frink: No, that's a really, really great thing to dispel. Because I do think FDA is very open to different software development systems. They do want you to document and describe your software development environment. So that would include your process, whether you're waterfall or agile. And I think they want you to describe your code review process, how does software make it into the final production code. But at the end of the day, as long as you have that V&V plan, you can be very, I guess, open on the design side of things, as long as it's well documented. And then as long as you have a robust V&V plan, then that would still suffice for medical devices.

Jon Speer: Again, a pre-sub is a means for me to try to communicate to FDA what I'm doing with this product, and it seems to me that a picture is important. So I think something like a software architecture diagram or something of that nature, it seems like that'd be invaluable as part of a pre-sub. What do you think?

Andrew Frink: Absolutely. Yeah, it's something that is listed in that guidance document as even separate from the device description. And we typically do put it into our device description section of the pre-sub, but I think it's listed separately because of how important it is. I think FDA reviewers are busy. They're going to be looking through the document quickly and it's really good to have that visual representation of how does information move through the device? What inputs are you taking from the environment or from patients or from databases or from physicians or from diagnostic tests? What are those inputs into the device? How does information flow through it? What modules or algorithms are involved? And then finally, how does it get put together and output? What does that output look like? When it ends up going back to the user, how does it impact the clinical workflow? And I guess that that last piece is outside the software architecture, and is something different, but all of those previous pieces, they all flow into the software architecture. I think it's okay for it to be a very high level in this initial conversation with FDA. You don't have to have your software broken down into individual unit testing modules and all of that. I think this is more, it should be a diagram of how does information flow through the device, what are the different logic engines that are associated with your device, whether it's machine learning or traditional logic gates, or however your software is designed. And I guess, what are the different inputs that end up providing that intended use?

Jon Speer: Yeah, totally makes sense. So I'm sure you're probably keeping track as we're going through this to make sure we're covering all the must haves, if you will, from a pre-sub perspective. Is there anything that we've left off the list of expected documentation to provide as part of a pre-sub for Software as a Med Device?

Andrew Frink: I think cybersecurity.

Jon Speer: Oh, yeah, that's a big topic.

Andrew Frink: Yeah, it's a hot topic. This is another one similar to the V&V plan. I think it's good to have a description of an outline of what you're planning to do. This should be part of your risk hazard analysis. You should identify cybersecurity risks and then list out different possible mitigations for them, whether that's secure communication protocols or limiting access to certain users, that sort of thing. It's a whole other conversation on its own in terms of how to meet requirements. And I think tied into that is this idea of software of unknown pedigree or off-the-shelf software. There's lots of different names for this, but basically it's any software, any code that you incorporate into your device that you don't have full control over the code. You've imported it in from a different source. This can also be fully packaged software that you're running on top of, whether that's Linux or Docker or Amazon Web Services. That would all kind of fall into the off-the-shelf software description. And FDA doesn't require you to verify and validate all of AWS for your medical device, if you run on it, but you do need to verify and validate the pieces of it that apply to your device and pieces of it that you are going to be using.

Jon Speer: Sure. And on that particular topic too, I would encourage folks... I was going to say I was going to be on the edge of my seat, but if that's the case, I would have been on the edge of my seat for about a year and a half now. But keep hearing that FDA is going to come out with some new guidance as with respect to CSV, computer system validation, software validation, and part 11 and all that sort of thing. That's not happened yet, but through the grapevine, what I've heard is FDA accepts you as a practice to assess and evaluate what that software vendor might have already done with respect to V&V activities. And AWS is a really good example. They have a whole library of content and information to help you make that case. So do try to lean on your software providers where you can, because there's a good chance that they may have already done some of these sorts of things, especially if they work in any sort of regulated industry. You don't need to reinvent the wheel, but do factor in your particular use case may be a slight variation or difference from that software that you're purchasing. But just keep that in mind. All right, so we've covered quite a bit of information and for going through this exhaustive lesson, folks, I do encourage you to review this pre-submission guidance. The link again is going to be with the text accompanying this podcast. But there's a handful of documents that we didn't really talk about, including the SDS traceability matrix, revision level history and unresolved bugs. I don't know if it's easy enough to summarize why those are not needed at the time of a pre-submission. I think it's pretty obvious, but it wouldn't hurt to hear you say so.

Andrew Frink: Yes. I definitely agree that these are things that are more on the final market-ready device. And so these could be omitted entirely from this initial conversation with FDA.

Jon Speer: All right. Andrew, while we wrap things up today, any last minute tips or pointers or gotchas or things that you think are really important for companies to understand about this entire process of preparing a Software as a Med Device pre-sub?

Andrew Frink: I think just be prepared for you FDA to be a little bit skeptical going into these things. They're definitely a conservative organization. They want to allow health advancements to occur, but they definitely want to make sure that they have lots of documentation and clinical evidence to support them. So be prepared to make a strong argument as to why your testing plan is accurate and appropriate. And that's kind of out of the scope of the conversation today about just software. But I think one of the most important things to engage with FDA in this pre-sub process would be testing plans. And so all this software documentation just facilitates that final conversation you have with them.

Jon Speer: For sure. And I know sometimes folks may get a little frustrated with regulatory bodies such as FDA, but remember, FDA's job is to protect and promote the health of US citizens who are going to eventually receive your product, so they need evidence to support that it's going to be safe. So just keep that in mind, that they have an awesome responsibility as it relates to healthcare and patients in our country. So just bear that in mind, and do yourself a favor and pursue these pre-submission options. Because like I said at the beginning, this is a great way to engage the FDA in a dialogue about what it is that you're doing, to communicate and to share why this product is important. So this is your story. These documents help you tell that story. And if you need some help, remember, there are people here who have this expertise. Of course, I've been talking with Andrew Frink, but he and his company, Proxima CRO, this is what they do. So I encourage you to go check them out and learn a little bit more about them. Reach out to them, go to www.proximacro.com. And I know Andrew and the team at Proxima would be more than thrilled to have a conversation with you to provide a little bit of guidance and some tips and pointers. Andrew, thank you so much for being a guest on the Global Medical Device Podcast today.

Andrew Frink: Yes, Jon, thanks for having me.

Jon Speer: Well, you're welcome. And folks, again, remember at Greenlight Guru, we're also here to help. We have that Medical Device Quality Management System. That's going to be really important as you're going through design and development, and eventually as you bring these products to market, so go to www.greenlight.guru to learn more. As always, thank you for listening to the Global Medical Device Podcast, the number one podcast in the medical device industry. And that's because of all of you. So keep spreading the word, sharing this with your friends and colleagues. We definitely appreciate it. As always, this is your host and founder at Greenlight Guru, Jon Speer, and you have been listening to the Global Medical Device Podcast.

ABOUT THE GLOBAL MEDICAL DEVICE PODCAST:

The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Like this episode? Subscribe today on iTunes or Spotify.