AIML FDA Submissions common pitfalls, hard lessons, and faster paths forward

Hey, morning, everyone. Welcome to today's session of Friday in Focus Call with MLVX. Our speaker today is Leon Dorn, who is a consultant from Amsterdam, and he's going to be talking about AI ML FDA submissions and his experience with that. While we're waiting for everyone to join, I'm just going to rush through what's coming up. Doing a session, Why MedTech Launches Stall on the 30th of this month. On May 1st, we're gonna have, Sam Patton, founder of Utaprep, talking about getting your, submissions in for UMED. Deadline is, coming up fast. Then we're gonna have first in human clinical trials in Latin America, what med tech companies need to know before they expand, with Julio

Martinez Clark, oughta be a really interesting session. And then we're gonna do, this session is really great for consultants, the QMS conversation your clients are having without you. And this is, from the founder of Tracex, from France, Charles Rolais, and he. Has a really interesting, proposition for consultants, so if you're a consultant, you're not going to want to miss that. In June, I'm going to be attending the, International MedTech Safety Conference in Boston. There's time to register, and we have a special code, which is,

there's startup codes at the bottom, and then there's an MLV200, which gives you $200 off. Either an in-person or virtual registration, and the virtual registration is already, like, half the price of the in-person one, so it really becomes quite the bargain if you want to attend, virtually, with that discount. Ben, Shout out to my friends at Innovation Summit, from MedTech Strategists. The Dublin event, April 28th through the 30th, oughta be super interesting. Lots of, startups presenting. And, coincidentally, I used to work with a lot of them when I worked at, the pink sheet and the gray sheet and whatnot at Elsevier Business Intelligence. And then last is, I finally decided that I'm gonna go to Raps Euroconvergence.

And so, despite the high airfare. Which I object to. I'm gonna be going to that. So I'm gonna put the link in, to, this presentation, and without further ado, I'm gonna turn it over to, Leon to help. Get things started for today's topic. Thanks for joining us, Leon.

Yeah, thanks a lot for the invitation, Sean. Is the screen visible?

Yes, it is.

Thanks. So, today, I'm going to talk to you a little bit through the AI, ML systems, and preparing an FDA submission. And it's an interesting story, I would say, because we are… we don't talk about this enough, probably. Within MedTech, everyone always celebrates successes everywhere we go. My first FDA submission with an AIML system was not that successful, and it led to a very lengthy, complicated process, and I learned a lot from it. And in this session, I'll talk you through some of my lessons, and how to prevent getting into the same situations that we ended up at the organization I was working for.

Yeah, there we go. So about me, a little bit of my background. I am co-founder and CEO of MedCare. We're a small consulting firm based in Amsterdam. We're tailored towards, so far, medical devices and those powered by artificial intelligence. Mainly working in the European Union, also helping European organizations entering the US market. We've supported in various types of FDA activities. And prior to this, I used to work at one of the earlier firms that started applying AIML in their medical device, and we… that was back in 2018, and this is where some part of the story I will talk about. And, what we did is the detection of lesions that are potentially malignant.

In the field of radiology. So, if there's any questions throughout the presentation, feel free to write them, I guess, in the chat, and we can answer those towards the end. One other thing is, also, I'm a member of the THC21 and SE42 working groups within ISO and THC, which is the European organization developing standards around artificial intelligence. So today, I'll start off with a little bit of a personal story, and why my first AIML submission failed. Then a little bit of the process from start to end. So, what does it look like? How do you get to a full submission? And then a little bit more in-depth on each of those steps. What does it mean to get to a successful submission process? So, going to 2018, that's where we started our initial engagement with the FDA.

When we came into the FDA, so maybe a bit story… a short story about myself. My background in quality and regulatory affairs has mainly been focused until 2018 on the European market, having worked with various manufacturers in the field, doing a lot of submissions, helping with quality systems. And in… and this is where I found out that the FDA is truly different than it is in the EU. And at the organization I worked for, we had a lot of data that we gathered in the European Union. We had the data sets that we get it in the European Union, and… We built up various functionalities within our device, so we detected abnormalities, we did a classification of abnormalities, we segmented abnormalities, and we also looked at growth over time. So we picked up earlier studies, made a comparison between two studies, and we could see whether an abnormality would grow or stay the same or shrink over time.

And we thought, well, this is all the data we have, how different is this going to be? So, when we came into the FDA, Where we started is trying to use our EU test data. We wrote our first presop. We said to the FDA, hey, look, this is the data we gathered in the European Union. our data, our product was predominantly trained on data from the United States, but the test data actually came from the European Union. And we thought we can just demonstrate how good our device operates against prior Highlighted, markings on scans. And, we used a predicate device, where the predicate device, that we used

was a similar device on the market aimed at detection. And what we did was the detection, segmentation, and also growth assessment over time… over time. And we thought that this was going to be a good first attempt, and when we submitted it to the FDA, we got, I think, at least 10-page letter back. With very detailed feedback on why everything we tried was not successful and did not make sense to them. And… I think my main… the main feedback from the FDA at that time was, Listen. you guys, your device is truly complicated. What you're trying is not going to work. And… We actually suggest that you cut it up into different pieces.

we fought… at that time, well, what can be so complex about our device? Because we went through, in the European Union. quite easily, so we figured we can try To push back, we went back to the FDA. We had 3 further pre-sub iterations to align the study plan, because it became quite Clear. Fast. that our EU data was not going to cut the deal for the US, so we had to gather U.S. data. And we actually needed to do a reader study. And the reader study is where these type of submissions really become complicated. So… at the same time, we… the COVID wave hit. And we saw a lot of radiologists being occupied with different activities in the field, and not being able to support us, which caused delays in our actual study.

So where we took, I think, about two, two and a half years to have continuous iterations with the FDA through pre-sops, where every time FDA came back stating, hey, we think you need to do another pre-sub, we finally landed together with the FDA on a reader study protocol. Our study actually got delayed, but once we did it. We completed the study, we hit all our end goals. So everything that we aligned on with the FDA, we met. And then we went back to the FDA with our final submission. And we found out that the team at the FDA side had changed, we did no longer have the same review team, and the opinions on the side of the FDA had changed as to what would be acceptable for our type of product.

And that was a very painful learning, where we came in Where we spent, I think, 4 years of trying to get our device cleared, doing a study, and then finding out it was not going to cut it. And FDA pointed us to the fact that presubs are non-binding. Clearly, we learned that FDA stuff can change. And what we also learned is that this was not the best strategy, and we've really tried to aim for the stars, and ended up with nothing. So that was a painful process. It's probably one of the darker times of my regulatory career, and I… I think me and the team, we were quite set back, and we were not that,

We lost a lot of motivation to try another attempt at the short term. But if you look at what then the EU and FDA, where they really differ, if you look at the EU, It's really a different system. You demonstrate compliance with the general safety and performance requirements. The conformity route is clearly via Nodefile Body. Back in 2018, Nodefile Bodies had very limited expertise on AI ML devices. I'd like to think that today, the notepad bodies have learned a lot. from the manufacturer data being… becoming better because all these companies go to the US, are being challenged by the FDA, to up their documentation. These companies go back to the EU, notified bodies learn from the experience of the FDA, and the bar in the EU has gone up a lot since 2018, too.

And in the EU, standard-driven, often presumption of conformity, where in the FDA you need to declare conformity. And post-market surveillance is typically woven in… into our EU processes. If you look at the FDA, clearly, for a device that is a Class 2, you need to demonstrate equivalence based on a product of the device. or establish a classification via de novo or PMA, and clearly, special controls apply to many AIML codes. And this is where it becomes complex. So the FDA clearly has their standard product codes. Each of the product codes has different controls attached to them. Some will not have special controls, but some actually do, and the type of special controls, I'm going to…

sadist is… those controls are typically not easy to demonstrate compliance with. They're risky. The studies that FDA is often demanding for the more complicated devices in this field are not simple. They ask for very detailed clinical study protocols with complex statistical test plans. And with, sometimes even very high Demands of demonstrating compliance with, with very… our thresholds. So in our case, we learned that for our device, we needed, obviously, to demonstrate that the aided reader became better compared to an unaided reader. Yet, at the same time, not at a 0.5 significance level, but at a 0.025 significance level.

Which makes it even more complex. By the way, those type of details? you will not find within the FDA database, you will not necessarily find within the clearances and the predicate descriptions, so some of these things we only learned because we went into the FDA, and we got our feedback from the FDA. So, looking at the process, just slightly, where I think we can show what we learned. Is that the very first point that will lead to full process is setting up the indications for you statement in the proper way. understanding what 510Ks are available on the market, and other products are on the market.

What is it that these other products claim? What is it that these other products actually do? And what are the limitations within their indications for use? And it sounds… like, a lesson that everyone should be aware of, and I should have been aware of back at the time. But it's not always that easy. You only start seeing patterns throughout the indications for use from other devices if you start mapping them out, put them one next to each other, and try to find patterns that are in there. And one of the key learnings from… for us was… where we failed in the final submission, is that we were under the impression that we combined… we could combine two different populations into a single study design. That was a screening study… a screening population and a diagnostic population.

We combined the two populations into a single study. FDA agreed to it. We explicitly asked FDA, do you agree that we can combine these populations? We got a positive answer back in our pre-sub. We went in with the submission after having completed the study, and FDA came back saying, nope, these should have been two separate studies, you cannot combine it into a single reader study. And then we turned out that both of the arms of the study were underpowered, because we did not source enough subjects for each of the arms. And then splitting it up led to us not really actually making our endpoints any longer.

So that's where the indications for use are extremely important to understand what it is you can do, and I'll touch on some more of it throughout the slides. Clearly, the cost…

Maria E. Donawa, MD: Yeah, go ahead. Sorry. Just two quick questions, I hope. When you, talked about your team, the people working with you and going through all this turmoil, how many people, more or less, are you talking about?

We were a team of 5 people. We had someone from, well, data scientist, we had a statistician. We had a clinical person and two persons from regulatory.

Maria E. Donawa, MD: Fantastic. And the other question was, did you mention that whether this was a 510K or a de novo? Maybe you did.

It was a 510K. Yep, we went in with a 510K.

Maria E. Donawa, MD: Okay.

And…

Maria E. Donawa, MD: Thank you. Oh.

Today, I also still think that this product can be a 510K, and probably should be a 510K, but probably not one 510K, if that helps.

Maria E. Donawa, MD: Thank you.

Yeah, you're welcome. So then the next step is obviously finding out the classification and the code, which are also super important, and this is where we should have realized our product should probably not be a single 510K. Because we had 3 different products packed into one. We detected abnormalities, we classified them, which the FDA turned out to see as a diagnostic device. And on top of that, we also did a segmentation and determined the volume of the abnormalities. And all three of those are actually 3 different features and functions, and FDA requires different types of validation for each of those functions, and trying to combine those three into a single study design

led to a lot of complexity and misunderstanding on our end and on the end of the FDA. And that really, really increased the number of precepts we needed to perform to get to the final study design, where eventually, as I mentioned, the whole study was not accepted. Whereas, if you cut it up in small pieces, you're clearly reducing the risk Of going in with a regulatory submission. Then the regulatory pathway, right? Do I choose… what do I need to choose? 510K, PMA, de novo? the predicate selection. I also found this very interesting. We came in into our first submission to the FDA using an exact same tool, using the exact same detection

target. We failed to note that the device that we selected, even though it's the same anatomy, it's the same target, what they did not do is classification, and we did not realize that that was a… diagnostic tool in the view of the FDA. So what that led to is that we needed to switch our predicate, and the FDA actually came back saying to us. why not take this device? And what they provided to us was a device that detected bone lesions and classified bone lesions. And what that taught us was that the predicate device doesn't necessarily need to be identical to what you do, but there's AI tasks that it

predicate performs within the same code, obviously, need to be similar. So what they also did is detection and classification, just the way that we did it. So the only thing we still… the only challenge we still had was to find another tool that also performed the segmentation. And growth assessment. Then, clearly, document your validation strategy. In our case, then low performance evaluation, combined with With the reader study. And then you go into your presub, and that can be multiple iterations. If you're intending to do a PCCP, I would already advise to bring as much as you can from your PCCP into your pre-sub, because you don't want to have your 510K being delayed over lengthy discussions on the PCCP.

And then, finally, go to the information package and send it in to the FDA, including the PCCP. So, yeah, where we lost time, so I'm making it general, but that's where we, where we lost time, and these are thinking from this field specifically. the… the learnings we had. So, defining two broad indications for use. can trigger having multiple devices into a single device, and that will make it very complex. And to the question I think Maria, I don't want to ask just now. we came in with 5 people. We were not expecting that when we went into the FDA, we would have 11 people from the end of the FDA on the call with us. So it shows you also that FDA needs to pull in a lot of different people with a lot of different angles, which doesn't really help you in your device submission.

We chose the incorrect predicate, we see that with some of our clients too, and that's not necessarily because of the target that you're trying to do, or… the anatomy, but it's really to do with not having the right task assigned to the AI system. So, is it classifying? Is it doing a segmentation task? Is it detecting something? And FDA will have different requirements to those different features. Fake protocols, and this is the same as with AI. Poor data in is poor data out. If you send a fake protocol to the FDA, you will get unclear feedback, and you will need more submission rounds for your pre-sub.

Although, so… and what I'm trying to say here is we went in with a team with highly skilled people, but with very few FDA experience. That was a problem. Having someone on your team that understands how to do this is crucial. Then the validation itself, studies designed without the alignment on the proofing methodology and the endpoints. The endpoints led to lengthy discussion throughout the whole pre-sub-submission process. We have multiple iterations with the FDA specifically on getting the endpoints correct. And FDA was very adamant about having endpoints for every single device feature, so having a different endpoint for the standalog performance evaluation, for each of the functionalities, and I think different endpoints for each of the functionalities in the reader study.

And with a device with 4 different functionalities in the view of the FDA, that already creates around 8 endpoints that you need to include in a single study, which is really not… not a… I would not recommend it as a strategy. Slightly separate, but that came up in the more recent years, is obviously having your SBOM and threat model ready. To provide it with the FDA, and that will also trigger, probably, questions. I guess we're learning more and more what the actual FDA requirements are, which makes it slightly easier to come into the FDA. And then, finally, the PCCP, I've seen PCCPs coming past from customers where they put a very broad scope into the PCCP. They want to claim too many things. They want to… their endpoints, just like with the clinical studies, FDA is going to ask it to be very specific.

So again, trying to get things through in a broad sense is probably not going to work unless you have very specific endpoints with very specific validation strategies for each of those endpoints. The indications for use, I already talked about it, so maybe I can go through it a little bit quickly, but yeah, it should include the intended patient population, obviously. And it drives, eventually, the product code for the device, the predicates, and the special controls that will apply. And again, I can't stress this enough, read the special controls carefully, and do a very careful assessment of what is needed for validation. And sometimes, small tweaks in the indications for use might just mean that your validation level is going to go down.

And I'll touch on this very specific example on the next slide. And then determine the… The level of validation that is needed to execute the study. Some categories, I try to map them, so there's a lot of different functionalities, like visualization and quantification, which fall under the QIH code within radiology. You have triaging tools within radiology, which FDA sees as CAPT. That also have their own code. You have the computer-assisted detection, you see you have detection and diagnostic codes that are combined, but also acquisition and optimization. although FDA calls them out in one of their guidances, I'm not really sure what type of devices will fall under those, to be fair. I know that there are some tools that

improve the image quality of the output of a CT scanner or an MR scanner, leading to shorter acquisition periods or to a lower dose. So I assume that FDA notes that those are computer-aided acquisition and optimization algorithms. And then the detection of healthy structures, obviously, computer-assisted diagnosis, the CADX code. By itself, and then computer-assisted prediction tools under the SAK code. And this is non-exhaustive, there's a lot more codes to be found, so this is just a very broad outline of what you may come across. And this is my, the one example I wanted to provide on where you can see a direct impact on the validation burden.

And, for example, in the clinical workflow, where you see semi-automated tools and fully automated tools. This is exactly where we ran into that very hard discussion with the FDA. So, where we thought we'd provide a segmentation of the abnormality. That's going to be relatively simple to get through. The user can decide to use the volume that we derived from the segmentation of the scan. We send it our… we send our result back into the backs of the hospital. And then FDA said, yeah, but the user cannot adjust your actual segmentation. And we said, no, but I can choose to not use our results. And then FDA was very precise in saying.

You're not a semi-automated tool, then. You're a fully automated tool. And the requirements for our segmentation tool went… Sky high, meaning we needed to actually demonstrate what type of outliers the device may have. How would we treat difficult cases, and we would need to enrich a dataset with a lot of examples. And in one case, we… they wanted to know what the extremes were that we might encounter, and in our case, for the type of abnormality, you have a lot of veins around it. And what happened is that sometimes part of the veins, which is the part of the segmentation, And FDA… was very clear to us, stating, if you might include part of that, it could affect the volume by X percentage, and we think that's too high, and we're not going to be able to clear a tool that might have the risk of including such part of a vein in a fully automated system, where the user cannot correct the output.

So… If you have the chance to create these kind of differences in your indications for use, and build in the workflow options for the user to actually review and adjust the output of the tool. It's going to lower your validation burden, and it's going to make the conversation with the FDA a lot easier, because FDA deems that to be of a lot lower risk than a fully automated tool.

Can I just interject for a moment? When AI is embedded in another software device, how does the FDA review the combination device? Two separate reviews by different panels, review at higher risk, clearance issue.

Yes.

So…

Trying to unpack your question, so if you have… It's… Two different devices that interact with each other. Or you have your start, and then you do different clearances for the same device. What is your question? Which one of the two? I can explain both, I guess. So, if you have a device that's intended to be used specifically for use with another device. Then you need to describe your interoperability within the 510K and into your data, and you need to make it very clear that your device is intended to be used with another device, and you specify that in the indications for use, potentially. And if you want to add devices that it's compatible with, that are probably iterations on your 510K clearance.

If, like we would have done, we would have needed to break up our submission into separate components. You submit the device, and every time you submit a new component of the device with a new product code, and This is… I think if you looked at our competitor, which we failed to recognize is they actually have three clearances. They have one for a detection task, they have one for a segmentation task, they have one for a growth assessment task, but all those tasks can be included within a single product.

Cool.

I hope that clarifies.

So he clarified AI embedded in existing software device. Example, AI in an imaging device. So you have AI software embedded in an imaging device.

Yeah, it's… I think there's a lot of options to… to play around with your architecture and how you want to position it. So you can break it up into separate devices, you can do a single submission. But… The smaller you make your submission, the easier it will be to get it through with the FDA. So it might be worth, if you have a larger device, just to cut it up into separate devices, but in some cases, manufacturers might not want to do that, because it's just a single device. But then you may expect some more complexity in the submission.

Michelle has spoken about, having two different product codes, and, like, trying to submit, and then it's, like, getting submitted to two different departments within the FDA, and they… kind of get into, like, a tug-of-war, or, like, who's going to manage this review, and then they kind of… it kind of falls through the cracks. It can be kind of a problem. Carrie, you have your hand off.

Thanks, Eddie.

Sorry, mute. I was just gonna add, even though the split predicate guidance is still active, and you can use it, and I get into TIFs, and I have a sub going right now with the FDA on this, The E star makes it impossible to use the split predicate rule, and this is why they're making us split them up, and it aggravates the heck out of me. And that's why they're making us do these different different submissions for all of the split predicate rules, which… we'll see how this next QSUP goes with a client that I have had for years with this, and I'm going head-to-toe with them, so we'll see how that works. But we shouldn't have to do multiple submissions for what they still have a guidance for with the split predicates.

Because we should be able to submit multiple predicates. like we've been able to do in the past for this, which the ZStar doesn't allow us to do.

In mine. Yeah, you… I think you can use reference devices, though, however, right? I think FDA is quite open to using a reference device, because that will make it clear.

Depending on the department we're getting into. And the digital health group is not as open to it.

Yep.

In the recent, because it is a newer department, and they are somewhat… I don't know what everybody else's experience is with that, but Because then, you know, they're still coming up with all their newest guidances, and still… still working around getting out of the LLC product code and developing all their own product codes for each new indications for use.

Exactly. Yeah, we also struggled finding the right product code and getting it into a single product code, and FDA kept hinting to us, use that product code and not the other one.

fighting now between making it a de novo, or putting them, like, all the mental health codes now, each indications for use, they're giving them each, you know, a new 510K, right, and or they're putting them in the different… product codes, so we'll see how this next split predicate argument I'm doing with the Different groups works, but… That seems to be my recent experience with the… We'll see how my split predicate argument goes with them. Again, that they… it's still a guidance, so they have to…

Two updates.

Allow it, even though it's not binding, quote-unquote, but…

Let us know how it works out.

I will.

Yeah.

That's in June. Because with that client, I have a step, and I have two NSR. Q-subs with them that have been going back for… So, we'll see. Great.

Yeah, FDA has a tendency to make things complicated, in my experience, unnecessarily at times. So the classification and the product code, clearly, identify where your device lives in the FDA. I think we just mentioned it. And codes can change over time, and I think that's also relevant, right? The LOZ that Kerry just called out as well, it was the initial code specifically for PACS, products, and you see that sort of visualization of radiology devices and output of radiology devices, and then you saw that it could have a little bit more advanced features. All these AI ML submissions would go under the LSAT code, then FDA created the QI8 code, and other Q codes to also govern more complex AI algorithms, and then it became dispersed over a wide set of different codes with different

Special controls attached to those. Which I think also makes it more complex, so if you have two codes and you're trying to adhere to two codes. And they might have, different… special controls, it could really become compliant. So, keep it easy, I would still say. This, I think, I guess to most people is probably well known. It's just trying to find the right code, use the classification database, use the databases on the products to have a look at whether you can find devices that you know are already cleared. And I've… I've started to use more and more tools like ChatGPT, Claude, and Perplexity.

And also the analytics tool I find very handy. I have it online. Where you can search predicates. However, especially in the chat TPT and in the cloud, if they… there is no code. it will be very helpful in finding you a code that's for something entirely different. It kept coming back to me, trying to find a code around a specific type of device, and it just kept giving me codes that were absolutely irrelevant. So, use them with caution. Three pathways, clearly all three different journeys, so the 510K, the de novo, and the PMA. I think for the… I think also judging time, maybe we don't need to go into this, because I guess most people will be aware of those routes. One thing I'll say is indeed that the PMA code to date has been very limitedly used

for AIML devices, although some of the older devices in the field were down-classified. So, specifically in the machine learning age, some of the devices lived in the PMA code, and then were later down classified to being 510Ks. So sometimes it's worth going back there to understand where the codes actually come from. Special controls, I think I already called that out, right? They have specific requirements, such as clinical performance testing, but also standalone performance testing. the dataset annotation and truthing methods can… could be described in there, and labeling requirements specific to the AIML devices.

And specifically, and I think… For anyone in this field, it's very important to understand the difference between The standalone performance testing, and the clinical performance testing, and when which is required. And each, code will have different requirements regarding formless testing. So some demand reader test… reader studies. Other will actually request other types of prospective clinical study designs. Predicate selection, I think, very known to everyone. just build your predicate matrix, compare what the other devices do, check what clinical features are in there, I mentioned it already, right? Are they also using the same type of actions in the AIML?

part, and what have they done? What were the subgroups that they looked at? We also struggled in our initial submission back in 2018 to… Figure out the right subgroups. We offered subgroups to the FDA. FDA came back to us saying, you need more subgroups. We asked them, could you please help us and guide us to what other subgroups you might expect? And they said, you could think about X, and then we added X, and then they came back. No, we still expect more, and… judging our predicates, they were not, at that time, not very open about what subgroups were used, and it was a bit of a hassle in finding out what the FDA actually wanted.

But that ended up being aligned. Again, just back to the whole storyline, I guess. Start small, player first, and then expand later. So, try to make the first submission smaller. And narrowing it down to the… to a single device with an existing 510K, where as much as possible, everything is already covered. Align the metrics, and where needed, split the device you need into separate products with submissions per code. And I think it might not always be possible. But where it is, it will probably help you. Validation strategy, again, I talked about this already quite some time. For people not aware of standalone performance evaluation, what you do is you have your data set, so you gather for the AIML tool, you gather the data, an independent data set, you sure… make sure that the dataset is proved accurately.

And following up on that, you compare how your device compare… is able to find the detection, or the target within the within the annotated data set. So, for example, in the case of lesions, let's say there's a data set with 100 data points, 80 have lesions, how many of the device will… how many of those 80 will the device find, and how many false positives might it generate? I think that's, very straightforward. And for the lower-risk devices, that will be the only data requested by the FDA, and clearly that data set size needs to be subject to a sample size rationale. You need to ensure that the data is geographically representative. You need to make sure that you include the right subgroups and assess the performance for different subgroups.

And FDA typically does not Require those subgroups to be statistically powered. But you do need to think about it in your sample size rationale. Some cases where you have complex tissue that you need to segment, the number of samples you actually need to segment might not be that high in your test set if you do a sample size calculation, but then when FDA will come back and ask you to divide your age groups up into five. or you have different acquisition devices that you need to break up into, or the ethnicity of your patient population. You can see that it It becomes really hard at some point to have sufficient data left over to do any meaningful subgroup assessments.

Then the clinical performance assessment, I just picked up two examples. So, for example, in the MYN code, which is the code where our device fell under eventually after we removed the diagnostic component. Is, is the reader study design. For detection devices, where you do a comparison, for example, between an aided reader and an unaided reader, you need to demonstrate one of the following, depending on what the other devices in the market have demonstrated. It's a complex design, and there's a high statistical risk. And the costs are typically high, and the timeline is typically long. And… What I mean by high statistical risk is you need to demonstrate that an aided group becomes better than an aided group. This is not straightforward. This is not simple. Especially in devices where you rely on human beings to determine what the grand truth is, where you will compare against.

So you have your data set, you have the ground truth, and then you have the readers that are unaided and aided. And you need to compare how each of those groups compares against the ground truth. And what you will find, or what we found, at least in our study design. Is that in our… group, the… well, in our ground truth. We noted that the people were… Maybe missing some of the findings, and consistently missing some of the findings. And then our device actually detected it. And because we detected things that were more complicated to detect than the humans might detect it. But then, when you showed that to the readers, all of the readers agreed. So in some of the instances, we had 5 people involved in the truthing panel, none of them have detected the detection target, 10 of our readers all detected the detection target and agreed with our device.

Consequently, you get 10 times a false positive, because the ground truth says there's nothing there. well, there you go. This is what makes these studies complex and risky, because… If the ground truth is not very solid, your readers might just… Agree a lot with what your device does. for the right reasons, and it might be correct, but you are going to screw your data. So you need to be very thoughtful when you set the threshold for such a device, where you're going to place the threshold. Are you going to go for a lot of findings? It might be correct. But then, you might just generate a lot of false positives, too, because just the truth is not being able to capture all of these.

actual findings. The prospective clinical study is slightly different, where you can do it in a prospective manner. So you have two groups. You have the aided group and also an unaided group. But you need to monitor them prospectively and see how many more targets were found in the aided group versus the unaided group. And then your ground truth is going to be determined in a prospective manner. So it's not a retrospective analysis against the ground truth, which… It's a little bit more… it also bears the same level of uncertainty, because you do not know… there is a risk of having inaccuracies, and you might need slightly larger groups because of the effect size.

But it's… Both study designs are complex and are not straightforward, and will require a lot of interaction with the FDA to get the protocols quite right. Yep, exactly. I think I already mentioned those. And also why the endpoints can fail, even with a good algorithm. Again, the aided readers might find more subtle lesions. The correct findings get scored as false positives, just because of 0.1. The sensitivity threshold, if you put it too high to low, that can tilt the outcome into the incorrect direction. And the truthing methodology disagreements that weren't resolved in the pre-sub. On our end, at least. So, we had in our truthing.

how you define your definitions, and what we actually found an abnormality, what the definition is of that abnormality. You have to make sure also that your truthing panel very clearly understands what the… what the definition is that they're looking for, because they… You might ask them to look for a certain bandwidth of lesions, but in their clinical practice, they're just used to finding the whole bandwidth of lesions, so it might not represent your device, but then when they go into the truthing. yeah, that might just not always work with them. They might just go for their standard political workflow if they're not trained properly, and you get a lot of inaccuracies as well.

Yeah, so, different challenge, this is the perspective. It's an example of certain codes, for example, the one of, real-time lesion detection, one where I think it's the code of where GI Genius is in. It's a device manufactured by Medtronic, which requires prospective data. We collected in actual clinical workflows. what FDA expects here is, indeed, the performance under anticipated conditions of use, but they will also always ask for the adverse event evaluation, so you need to document adverse events that can happen. And these studies, by their nature, because they're prospective, they will have

Potentially a little bit more interaction From a clinical risk perspective. Generalizability testing. The quiet deal-breaker, yeah, why? Clearly, if you need to have the data, and you need to make sure that it's sufficiently general… you need to make sure that your device is sufficiently generalizable, but that means that you need to collect all that information, and that might also not always be straightforward. Collecting a patient's ethnicity is not always A very easy thing to do. And depending on the claim you want to make, the age groups. You need to ensure that if you claim an age from 22 years onwards.

And your full study data starts at 50, then how do you evidence that the device will actually work in an age group between 22 and 50? You can expect those kind of questions from the FDA. Then the technical generalizability across vendors, acquisition protocols, site configurations, but also image quality. The disease generalizability stages, rare representations in challenging cases. But also disease subtypes. In our case, the size of the lesions, for example, how good is it at detecting smaller lesions? How good is it at detecting bigger lesions? And not having that done. Yeah, if… and I think, in my experience, with the submission we recently did, we did not meet all our subgroups, but FDA is going to ask, and by minor.

lower scoring points, but then FDA will say, okay, for that subgroup, you… can you please disclose that in your instructions for use, so that people understand That it might not perform as well in certain subgroups. The pre-submission, also in this case, the FDA recommends it in their draft guidance from January 2025. I would also recommend it, especially in your first AIML submission, always do a pre-op. Just go into the FDA, learn what their feedback is, see if you've missed anything, because these are not easy devices to get through with the FDA. If you do have the experience, you have done multiple

clearances already, then potentially another presub would not be necessary. You can rely on your data and your understanding of the device. However, especially where you're including awful features. or you're trying to use non-US data, it's still a good idea just to go in with the FDA and check with them if they're okay with that. The truthing methodology, for example, if it's slightly different than what's used in predicate devices. And especially if you have to do a reader or prospective study, to me, that's, 100%, reason to go for a pre-sop and never skip it. And… Probably expect that multiple pre-subs are going to be required.

What to include? I think the outline is pretty clear and straightforward, like for most devices. And… again, I've written it down before, I read it down before, is the study protocol. The better the study protocol, the better the feedback you get from the FDA. So really overthink think very carefully about how you want to do your clinical study, where your data is going to come from, what the groups will look like, how big your sample size is going to be, your sample size calculation. All of these components you probably want to align with the FDA in your pre-sub. Because if any of those are wrong, and you go through the study, you are at serious risk of losing

A lot of money that you might need to invest in a study, in another study. The submission package, I think… Sean, if I'm not mistaken, there was a recent update of the eStar, and also, I remember Michelle doing a presentation on the E-Star package, if I'm not incorrect. Or… That's correct, right?

Yeah, and they update it all the time.

Yeah, yeah, I think they're now at version 6. And I… I guess this is also pretty well known to everyone here, but it's… it goes beyond saying, always open it before you even start your… your whole development of your documentation. Start to understand, click through it, start understanding exactly what you need to include and what you need to upload. the E-Star is not that flexible, so if you build up a whole long document with all different documentation intertwined, and then you open up the E-Star and you see That some of these things need to be split into separate documents, and it won't allow you to submit without having those separate documents.

Then you need to restructure your documentation. That is not very helpful. Some of the items I have listed here on the right, like risk management, it's good to note that the AMI34971 is specific risk management for AI and machine learning-enabled devices. the 34971 is about to be replaced by the ISO TR24971-2, which is going to be an international standard around how to apply ISO 14971 to AI-enabled medical devices. And I think it's about to be published somewhere in the next few months. I think the final vote just closed. It's one to monitor.

Yeah, I put it down here as well. So this one is about to be replaced. The others are, I think. Probably well known to people already. And there are some more standards about to be published in… The short term, I'm not sure if FDA is already asking it, a publicly available specification by… TC62 was published last month on data management. That's probably also a good standard to look at and understand how it is to be applied for the… for the OS. Cybersecurity, I think there have been multiple, webinars about this as well, and so I might want to skip through this a little bit quicker.

Obviously.

Sorry, Leon. So this… this is very interesting, because one of the revisions to the E-Star, which you just talked about, was that whole cybersecurity section, and it went from, like, maybe a couple of small sections in the E-Star to, like, taking up, like, pages now of the requirements, so… yeah.

And it was already paid.

pages, right? Do it.

It already was quite a lot of pages before, so it's even become lengthier in version 6.

It wants 22 docum… or 24, last one, I just… for software as a medical device.

Thanks. Yeah, that's a very helpful addition, and… the lines, it underpins…

Basic, that wasn't an enhanced software, so…

Man.

I don't know what I need to take. Oh, God.

I think it very clearly underlines why you need to open the E-Star prior to writing any of the documentation. Because you might find yourself in a pickle if you don't, and you're ending up at the end of the… the whole process, and you're going to fill the E-Star and find out that you're missing all of those documents.

2 is the QMSR version, so now it includes all your QMSR… ISO 1345 documentation and certs, just so y'all know. which includes.

Strings.

Configuration… configuration management and, GMLP and all of your good manufacturing learning documentation as well for your software as a medical device, and SI. MG. Stop and think.

That's good to know. Thanks, thanks a lot for the edging, Karen. Yeah, and also the specific cybersecurity threat, right, to consider for your model development and for the AIML is the model tempering, data poisoning, model extraction risks, and the adversarial attacks. It's probably good to think about those risks in your setup of your technical documentation, in your risk assessment, in your cybersecurity approach, and ensure that you've thought about the specific risks that apply to AI ML devices, and make sure to include those. And I think the 24971-2 that's going to be published, goes a little bit into more detail on some of the specific risks associated with AIML devices.

Predetermined change control plan, clearly, descriptions of modifications, modification protocol, and the impact assessment. Start with the description of the modifications. quantitative measures, again, and I… I think… I noted it before, but one of the most crucial things is, indeed, be specific. Be very clear on how you're going to validate the device, what are going to be the endpoints for each of the items that you want to clear with the FDA? How are you… what is your data set going to look like that you need to submit to the FDA? How does it build up, and… what are your pass and fail criteria in order to bring the… to clear the additional,

items that you expect under the PCCP, and… always good to understand that there is an inherent risk with including a PCP in your submission, which is that the submission is going to end up in the discussion of the PCP rather than with the whole rest of the submission, and you're going to delay the whole device because you're stuck in a… In a discussion on the PCCP.

I just had one with.

Yep.

the FTA submission, and they want a Q sub now, if you're even thinking about a PCC in your submissions, so…

Yeah, I would highly, highly, highly recommend it to do a QSOP first, yeah.

It was kind of a note, not even a mute point. They want a Q sub, even. If you're.

good.

Stop.

Yeah, that helps to clarify.

I don't know, I think… I don't think they necessarily are, so they want to see what you're doing. I don't know.

Yep, and they're probably also not happy about many of these submissions being delayed because of the PCCP, because they have their internal timelines as well, and if they need to review the whole PCCP and have multiple iterations on it, it's just not helpful, I think, for either the FDA or the submitter.

they're.

core component.

Either take it all the way out, or… Delay your submission, and…

Yeah, exactly. I think I… if I go one further, I think… I included an example from XVO3D, And what you see is they've done this, indeed, they only did… they did the first 510K, then went through a pre-sop, and then they came in with a PCP to amend the initial 510K, so they could just go in with an additional 510K, where you just include the PCCP items. And that's probably the easiest to do, and then explain what it is you want to do, and… Get it cleared through that way. Going back, so the modification protocol should have the data management retraining practices. Performance evaluation. Again, how are you going to demonstrate that?

The device will work. And then the update procedures on how is that going to look like. And the final impact assessment of the device on your existing risk management file. So I'll… is the… the PCB going to tie in with all the existing documentation that you already have. And yeah, maybe good to call out, right, if you… do a PCP, you think you implement it, but you're actually stray from what was submitted, and you're not following the PCB strictly from what you did submit it, it can be considered misbranding, or it can be alliterated by the FDA. So, be careful not to.

put that in the major deficiency note. They wrote a PCP that, like, you got almost like a warning letter about the misbranding. Yeah. The major deficiency note part of the… Which I was like, whoa, okay.

Yep.

Let's just remove it this round, we'll go back in.

Exactly, yep. Yeah, the example. So, my takeaway messages, I guess, at the end, And… what I… I really learned is that the indications for you statement is the basic consideration for these type of devices. And if you've… If you are unfamiliar with this very specific field. It's worth getting some support from someone who has done this before and understands where the subtleties are in the indications for you statement. And do a very thorough assessment of all the 510Ks that you can find on the type of device to understand what are potential limitations, how it could apply to your device. Again, that ties in very much with the fully automated is not the same as semi-automated.

And having workflow adjustments. can easily… it can make your, process with the FDA call more smoothly and easily. Clearly, choose the right predicate that narrows risks, and expand after the first clearance. Precepts are leveraged, specific input. Obviously, let's see, yeah, yield specific feedback. And that is obviously also very important, right? Be very specific in your pre-sub. Know what you want to ask. The more information you provide, the more precise you document it, the better and more quality you will get out of the interaction with the FDA. Yet, in our experience, it's not a guarantee at all if you have had the pre-op with the FDA. I recently learned, and I was unaware, that there's actually a possibility to ask for

a, binding pre-stop process as well, but it seems to be a very lengthy process, so I'm not sure if that's worth it. cybersecurity and SBOM are engineering work, clearly. So what… what I mean to say there is that, It's not just getting the paper done, it actually means that you need to address vulnerabilities that are available within the software code. And… that should not come towards the very end. We've seen a submission through the Novo fail quite recently with one of our companies. Because they, had to resolve, in their interactions with the FDA, many vulnerabilities towards the end.

They had done their penetration test prior to it. They went back in with the submission. FDA said, you made now so many changes to your device, the penetration test is no longer valid. This was the last round of feedback. Here's where the submission stops. You need to do a new pen test and come back with a new de novo submission. And that's where it can become really tricky, and that was the moment, the final question round, when this company involved us in the de novo, and… We couldn't fix it, which was really a shame. Pcps, reward precision. So, again, the more precise, the more specific, the bigger the chances of getting it through. And as we just learned, thanks, Gary, go through a pre-sop with the FDA.

That's it, thanks.

That was amazing. I'd like to encourage anyone on the call to reach out to Leon or me, and I'll contact him, if you want to talk to him about what you're working on, or what your clients are working on. If you want assistance. And thank you again. If you learned something today, please put it in the chat. You know, one thing that you learned, and if you loved today's presentation as much as I did, please Show some love to, and connect with him on LinkedIn, and I hope everybody has a great weekend. I want to thank everybody for giving up an hour of your time on a Friday morning or afternoon, depending on where you are. And, look forward to seeing many of you again next week for the,

Udamid presentation, ought to be interesting. And, thanks again. Thank you, Leon.

Thanks a lot, sir.

That's really useful. Thank you.

Michelle and Kerry, thanks a lot for your contributions as well. It's very helpful to hear from multiple people, because, yeah, things evolve so fast in this field that I'm also not always as much as up-to-date with the latest versions. So, thanks.

Maria E. Donawa, MD: That's excellent. Maria E. Donawa, MD: Excellent.

Thank you. Yay.

Thank you very much.

Have a good weekend.

Bye, bye.