---
title: "Streamlining Multi-Region Submissions - MDR, FDA, and EU AI Act"
type: webinar-transcript
publisher: Ketryx
source: "https://fast.wistia.net/embed/iframe/9sg8j15g8l"
content: auto-caption transcript, proper-noun corrected
---

# Streamlining Multi-Region Submissions - MDR, FDA, and EU AI Act

*Ketryx webinar — transcript of the recorded session.*

[▶ Watch the recording](https://fast.wistia.net/embed/iframe/9sg8j15g8l)

---

Hi, everyone. Thank you all for joining us today. We're super excited to talk about a whole host of different topics. I'll just go ahead and share my screen right now. So welcome to the webinar.

So today we're talking about streamlining multi region submissions. So if you are thinking about going into EUs or you're working with MDR, you're thinking about the FDA, medical devices, EUA Act, this topic is for you. Very excited to chat about these things. One thing to note is that we're talking about document orchestration today. So even if these regions are not the regions you're working with, a lot of the same concepts will apply.

So very excited to share all this information today. We'll show how teams are using a single source of truth supported with AI agents to keep evidence, documentation, and traceability aligned across regions without duplicating work. So Kevin and I are gonna dive into this in a second. Before we get started, though, I'll just quickly highlight a little bit about who we are because I'm sure you're like, Ketryx, who are these guys? You might have heard of us, might have not.

And I'll just set that up front so that you can understand where we're coming from. So we are Ketryx. So we are an AI native compliance platform that is purpose built for regulated teams to deliver safer products faster. So if you're working with multiple different teams, especially if you're working in regulatory affairs, you're oftentimes working with all these different subject matter expertise, and you kinda have to coordinate information across all these different teams because they're all needed to build things like medical devices and your submission documentation. So that often means that you're operating in different tools.

So some teams might prefer one platform like Jira. Some teams might prefer something like Notion or Excel. I know I certainly spent a lot of time working in Excel, working on risk management files. So because of that, there's oftentimes some disconnect, and you might actually end up spending a lot of time copying and pasting between systems in order to generate your submissions. Kevin and I come from Ketryx where, you know, we have designed around that, you know, pain point to figure out how can we more identically and automatically generate evidence of compliance for that final submission stage.

So that means, you know, less time spent documenting and, you know, chasing these, like, traceability trails. And it means that you can focus on the important things like risk management, you know, those tough conversations of figuring how do we make sure we're making products safer for everyone. And, of course, we apply an agentic automatic enforcement in order to do this because oftentimes when you're copying and pasting, that's a very manual process. Automation means that you're able to also unlock a lot of these rules and and, agents that allow you to check things before they go through. So just a little bit about us.

So a quick note about who we are personally. So I'll tell you a little bit about my journey to here with you today. So I actually come from, I we sorry. My bad. I actually come from Ontario where we have professional engineers of Ontario where we have a licensed profession that talks about safety, ethical decisions that you might make.

I previously worked in medical device. So before I worked at Ketryx, I was spending a lot of my time doing things like documentation, regulatory affairs, quality assurance, and I noticed a lot of these pain points. So, you know, oftentimes, I'm running around trying to collect evidence, and, you know, I was building towards things like submissions. So EU MDR, CE marking, UKCA, global submissions, and I found it very challenging. And oftentimes, I'd spend, you know, conversations with my developers saying, you know, we should really be doing this because we need to get through our MD SAP audit.

And they'd say, well, why can't we do this with automated tests? And I honestly couldn't really argue with them too much about that. I'm like, yeah. You know what? We should be able to do this in an automated way.

And that's what brought me to Ketryx. So at Ketryx, I help teams develop AI enabled workflows that allow them to pursue their work in quality, regulatory, product design, and I can also support a lot of our partners in their first AI enabled submission. So it's been a very exciting journey so far helping a lot of our partners get up and running in this sort of AI centric world and supporting kind of like the next generation of how we do medical device development. Joining me today is Kevin Brady. So Kevin, I'd love to give you a moment for you to introduce yourself, and I'm very excited for what you have to show us today.

Absolutely. Thanks so much, Jen. Hi, everyone. My name is Kevin. I am from Leachroom in the northwest of Ireland.

It's not as significant as Ontario, so no worries there. Similar enough to Jen, I was also in a medical device startup, so dealt with a lot of the problems that I find Ketryx customers have before they come to Ketryx. A lot of paper based documentation, really hard to kind of review all of these big documents. And I'm now on the delivery and success team within Ketryx. So very much once you start working with Ketryx, making sure that your QMS processes are brought into Ketryx and you can kind of match your existing workflows and your connected systems, but have that compliance layer of Ketryx integrated the entire way through.

And, Kevin, I think you deal with, you know, all sorts of different partners. Right? So folks who are operating globally. Right? So maybe is it North America mostly or other regions?

No. Absolutely. We have all kind of submissions, class one to class three, and definitely a lot of European and US based teams. So nearly every region we have, we have a team that releases across, I think, ten different regions. So Wow.

Definitely all storage. I think when I was, you know, working on initial, we only really worried about, I think, eight or so or five or eight, and, yeah, ten is ten is a lot. There's a lot of reasons why a lot of companies are working globally, right? So there's a lot of opportunity. You have access to more patients, which is obviously very important.

If you're looking to provide benefit in the world, I like to think that a lot of us working in this field are very patient centric and think about how they're adding positive benefit to the world and how you can increase our health outcomes. And access to more regions means you have access to more patients. You also have more commercial you have diversified commercial risks. So maybe in one region, don't do so well, but you can do better in other regions. You can also have access to broader data sets.

So this is something I'm very interested in, in that when you design particularly AI enabled devices, they're very data hungry. And if you're able to access all those different jurisdictions, that also means you have access to all that different data. So there are many, many reasons why many of our partners, Kevin, go global, but there are some risks and challenges. So when you're working in global regions, right, you see a lot of our customers, they have to compile not fifty or one hundred documents. It's like one hundred documents per region, and that can be a lot of work to do that could be manual.

So for example, you might and and what you notice is that you you end up actually reusing a lot of the same things. So for example, with substantial equivalence in, you know, the American market, you might not use that in things like the European market. But risk management, a very common one, is reused everywhere. So but given that, you know, there's still no unified pathway. So there isn't, like, a one submission that you might run into globally, And that's one of the problems that we're trying to solve right now.

So when AI is also part of the product, that's where you also see some friction increases. I think, Kevin, you've definitely seen there's been a lot of diver like divergence, not so much convergence in a lot of AI legislation. And I think we're only gonna see more of that just as, you know, if you think about what's been happening in the last year, a lot of different jurisdictions are choosing different paths. And that means that we now have to find very different ways to fulfill all these different requirements. So even though you'll have global reach and global growth, every update can very quickly become three, four, maybe ten submissions.

So that's why this is something that I'm really excited to talk to you all about today because there is a way out of this, and that is through document orchestration. Here's a quick overview of what we'll be going through today. So given that we're here to talk about regulatory affairs, as promised, there will be some regulatory affairs content. We'll be going through some of the core legislation and things out there that we need to be aware of, but just keep in mind that there's many, many different submission pathways, jurisdictions, and the orchestration piece is really the thing I'd like to see everyone walk away with. So we'll walk through some of the different requirements.

We'll look at some modern approaches of how to tackle them, so how to make sure you're not duplicating effort. And then we'll have Kevin show a quick demo of, like, how you can automatically generate. So we have a platform, Ketryx, that can do automated, document generation. Strongly suggest if you're working with different jurisdictions that you have some sort of automated way to manage all of this complexity. Alright.

As promised, this is also an AI centric webinar, so I know that there's a lot of folks on the call right now who are probably working with maybe AI startups or you're part of this AI digital excellence group within your company. So let's just quickly touch base on what it means to have an AI system. So FDA's definition is intentionally broad and sits within existing software and quality frameworks. It kind of treats AI as an engineered system that generates outputs based on human defined objectives. The EU AI act goes actually a little bit further.

Notice that with these definitions, they don't necessarily say, oh, AI is Chachi b t. There's a lot of different, you can kind of very broadly define as just a machine based system that has some level of kind of simulated thinking. So varying levels of autonomy and adaptiveness, including those that learn or change after deployment. I think there's probably a lot of folks on this call right now who have been reading up on the PCCP. Very excited to talk about that a little bit more.

But, yeah, this is one of the most expansive or future oriented definitions coming from the EU. Doctor doesn't actually have its own definition. It doesn't really talk about AI systems too much, but it does point to the AI Act, and so it does, many, many other, regulations within the EU. So just keeping this up there to to sort of show and compare, there is some overlap, for example, with AA Act and MDR. Some things are AA Act only, some things are MDR only, and of course, FDA kind of fits in there too.

All right, let's quickly talk about the FDA's requirements. So if you are new to the FDA's requirements and expectations of what they'd like to see if you're doing a submission with them, think about how you are going to define your verification and validation. This is something that the FDA has kind of set. So FDA though has a very centralized and well defined review structure. So they say, hey, you've got different options.

You can go through a five ten ks, de novo, PMA, depending on, you know, what your criteria is. You know, there's very clear expectations of what that evidence should be. And, of course, as always, if you're not sure, always recommend some sort of QSIP process to do that. What stands out for AI enabled devices with FDA is that they've been actually steadily building a lot of their guidances around it. So you can see, you know, through the history, you can kinda see, you know, in twenty nineteen, there was just, like, a little little guidance here and there.

And, like, every single year or so, they've been adding more and more information about how you wanna get AI enabled devices to the market. And this is really consistent with their commitment to innovation. So they've been sharpening expectations around how you should do machine learning, how you should do cybersecurity, transparency. Note that those two things are related. Remember, actually, there are AI cybersecurity risks worth a read if you haven't read those already.

And, you know, all of this is things that you should keep up with, read up on so that when you get to the actual submission process, you're making sure you meet all the requirements. You haven't seen the eSTAR forum recently, it's also a really great guide for if you select, for example, software or AI, as, you know, incorporated into the product, it also provides you pointers to the right guidance documents. Everything in the box on the bottom left is kind of the place to focus on. So remember, FDA submissions require full design control traceability. So requirements, risk, architecture, V and V, all align and all tie back to the device's intended use and safety claims.

So keep in mind, if you're not sure what your intended use is or your safety claim is, that's a good thing to get sorted out front because it changes everything. For AI specifically, evidence is expected to be tied back to an exact model version. So if you've been working on, like, different iterations of a model, make sure that you have in your quality management system identified how you're gonna identify your models. So it can't just be like, oh, here is what we had on this date. Make sure you have some sort of written description of how you define what a model version is, which may be different than your typical Mitch Shaw, that sort of thing.

Finally, for any model that could change over time, FDA is increasingly encouraging the use of a PCCP. So a predetermined change control plan is a formal agreement with the FDA about what can change post clearance and what controls you have in place to manage those updates safely. Think about it as if, you know, oh, yes, as we're submitting, we know that three years from now, we need to change it, and it actually is a good thing that we're changing it. We're actually gonna keep it safer. So how would you define those performance expectations, and how do you make sure that happens in a way that is reliable where the FDA can trust you and say, oh, yeah, they're gonna update it.

So you have to think ahead of where you are today and understand what your product will be. But from there, you can make the argument that it's actually we're maintaining the safety over time. So love to dive into that into a dedicated webinar. I'm sure you'll see lots of CatchX content later on, but PCC is worth a look at, see if it makes sense for your device. Altogether, these elements shape the FDA submission pathway.

So again, traceability, structure is all part of it. Let's talk briefly about EU MDR. So with there's a love hate relationship, I think, when it comes to EU MDR MDR. You know, there are so many really great things in MDR that says, hey. Look.

We need to start upping our game a little bit, making sure that we are consistent and we meet all of these GSPRs, which is wonderful. You know? I think we're we're getting to a point where we might see, you know, stronger safety measures. But, also, it's been very challenging over the past few years trying to migrate from the old system into this new MDR system. MDR has much heavier emphasis on things like a clinical evaluation and post market clinical follow-up.

These are things that you might not typically see in your FDA submission to the same degree or same level that you would see in, you know, five ten k. Rule eleven is especially important for AI. It tends to drive classification higher. And if you can get that right, similar to FDA, MDR is also issuing a growing set of guidances around software, significant change, cybersecurity, and now the interplay with the EUA Act. Again, I won't walk you through these kinda, like, one by one, but the point is, like, we have steadily been increasing kind of the guidance and knowledge we should have about what we need to do next if we'd like to take these really innovative products to market.

The most important thing, as usual, is the bottom left box over here. So MDR submissions are very clinical evidence driven. So make sure you have a strong clinical team to support you through that process and really, really great data. You need a clear benefit risk analysis and justification backed by PMF PMS and PMCF plans, so post market clinical follow-up plans. The rule eleven often results in a higher classification, so keep in mind what your software safety class is.

And lastly, you know, if your model or software change, if you're thinking about changing your product, it requires full revalidation. Unlike m e sorry. Unlike FDA, there aren't necessarily PCCP pathways, though it is very likely we might see something come up in the next few months or years around that because I think there's a clear, like, case for why we need this as a regulatory pathway, so keep up with the latest information coming out of the EU for that. So while MDR, FDA, and the AI act ultimately want similar information, MDR does require more clinically oriented information. And that's where you might see some divergence, right?

You might see this thing that we wrote around risk management works great for FDA, but it turns out we need a lot more tiebacks to clinical evidence. And that's where you kind of start seeing like these multiple pieces of documentation kind of floating around within your organization. Kevin, I think, you you've also experienced this yourself, right? So you've also experienced some of this, like reuse of documentation and kind of duplication in your own work with our partners, right? Yeah, absolutely.

And you'll see it a bit more later on, but we have, for example, different risk management files for each regions and specific to some of the regulations as well. But even further than that, if we have some customers that definitely have, say, example, one MDR device and one IVDR device that are using the same software across both. The same code base can be used and still fulfill the regulate both regulations, but you just have to be consistent across both regulations. Obviously, software verification and validation is a requirement. And finally, once you go down to the documents, that's obviously the main point.

It's essential for every submission. That's definitely something we experience and something our customers use all the time. Makes sense. For the AI Act, I think, Kevin, that's something that I think you run into definitely. We'll briefly take a look at that.

So unlike MDR, AI Act is more of like a central E regulation. It doesn't just regulate medical devices. It's kind of a unified enforcement mechanism. Now there's been a lot of changes, so keep in mind, you know, they've been, you know, rejigging how they wanna interpret, you know, what is required, what is not. So please check your latest before you really dive into this.

So AI Act is very heavily focused on data governance, transparency, human oversight, and fairness and robustness. So whenever you're finding you're interacting with, say, like, an interface that's like chat or like an LLM, and you find that it's actually disclosing things like, hey. By the way, like, this is an AI product. Now a lot of that is coming from, you know, it's kind of the spirit of the AI act where it's about, you know, making sure that it's being used in a safe way. It also introduces distinct AI specific risk tiers.

So there's also things like minimal, limited, high, and unacceptable risk. So that's a new risk classification system. I think at this point, if you have a medical device that is also within the AI Act and it's also with FDA, you might have, like or maybe five different classification schemes at this point. So be sure when you're talking about risk class, you specify which regulation or standard or whatever you're referring back to so you don't just talk broadly about risk classes. On the right, you can see the major milestones.

So, again, I'm not gonna read through each one, but the timeline kinda shows how the AI Act has been evolving when it comes to enforcement. The most important part of the slide once again is the bottom, box. So make sure that if you're looking to meet all the requirements of the AI Act, you have explicit documentation that talks about data governance and training data. Now remember, ISO thirteen forty five, which is what a lot of quality systems, you know, implement, doesn't really have any explicit lines about training data from machine learning. So if you only have that system for, say, the FDA, you know, the the latest QSMR changes, make sure that you've also incorporated things for the AIR, so things like training data quality and model transparency.

So this goes a bit deeper just because of the architecture and your chosen technology. The AI Act also mandates human oversight, so an AI specific risk management. Remember that we know that this is a new technology that has very specific risks. Make sure those are incorporated. So look at what's out there.

See the potential risks that come up. I think even recently, right, there was an FDA warning letter about how AI was used within the company internally. So think about what are all the failure modes that come up and how do you incorporate that into your risk management file. In the AI Act, they do talk about, you know, how to trigger nuclear enformity checks. I expect this to be revised over time, but remember that they should be preauthorized or there should be some discussion with your notified body.

The key takeaway here is that MDR governs medical devices, and the AI Act governs artificial intelligence within the device. There are some talks about, you know, not necessarily, having to get, like, a double CE mark, over time, but let's stay tuned for where those updates take place. Alright. I'll just very quickly talk about the Cyber Resiliency Act. So this is something that's very, very new.

And as us being regulatory affairs folks, we often get brought up into brought into conversations that aren't necessarily restricted to medical devices. So say your company builds AI enabled medical devices, there's a pretty good chance that they might also be building something that isn't necessarily a medical device, but, you know, maybe is actually required to be, in conformance with the Cyber Resiliency Act in the EU. So unlike FDA, CRA is not centered around a single submission pathway. You can see on the timeline in the right, you know, the regulation was first kind of brought in in twenty twenty four, so super, super fast. I think in, like, EU terms, we're we're really moving at the speed of light around building better cyber resiliency into a lot of our software products.

So a lot of the things you actually see on the left hand side, for folks who are working in the US jurisdiction, they will actually sound very familiar. Why? Because only a few years ago did the FDA put out all these new requirements around post market monitoring and vulnerability management for any cyber devices for that that are medical devices. Now you're seeing some of those practices come into the EU and start being standard practice for not just medical devices, but also for all devices that are cyber in nature. So all these really wonderful things that you might have already implemented as part of kinda, like, your cybersecurity management system for medical devices only, can actually start leveraging any of those SOPs you wrote for the E Cyber Resiliency Act.

And I think that's really, really exciting. It's a really great opportunity to kinda just say, hey, we already built a framework around this. Why don't we just use it for these other devices? Because keeping patients safe is one thing. Why don't we keep everyone safe?

So together, the CRM model kinda shifts a lot of the what would otherwise be static documentation or, like, onetime documentation into something that's more continuous. So if your departments who are kinda doing your cybersecurity work aren't used to this idea of, like, submitting documentation or maintaining documents over time, this might be a bit of a framework change for them and something worth discussing with them. Alrighty. So basically, at a high level, what I'd like everyone to come away from this conversation with is this idea of like, ah, yes. So I need to find trends across all these different jurisdictions, areas of overlap of, you know, certain things.

So for example, you might look at the FDA's classification rules and say, ah, there's some similarities there with MDR and AI Act. How do I harmonize my processes and documents so that we can create the least amount of documents, so least burdensome, least amount of documents and leverage the same underlying foundations for all of that? So think about, you know, is premarket conformity assessment, you know, all those documents submit upfront? Can we reuse a lot of those? I think we can.

And Kevin's very shortly gonna show you how to do that. Traceability. Luckily, traceability isn't too different across all these jurisdictions. I think the thing that they are these different regulations. The thing they're looking for is that you do have traceability.

You have full traceability. So I'll take a quick pause there and just remind everyone, please submit your questions. I know I just went through a bunch of content and we will be answering questions at the end of this webinar once Kevin shows us how we do some of this orchestration, and then we'll dive into it. Now, I do have to answer this one question because we do have a lot of progressive AI folks within our community. So I'm sure you'll wanna ask, why can't we just use generative AI to do a lot of this orchestration?

Like, I can already, you know, have, my LLM of choice. You know, I'm gonna, like, really give it, like, the most amount of tokens possible, and we're just gonna have l like, the LLM solve it. Well, the issue and the short answer is is that, you know, LLMs and a lot of these AI models are really great at generating something that looks right. But this problem isn't about making it look right. The the problem we're trying to solve is how do we consistently deliver documents that are traceable and reproducible every single time.

And if you change one thing, like your intended use of one jurisdiction, how do you, with intention, change that intended use for all jurisdictions? So remember, your model doesn't always have awareness of your quality management system, your design controls, or your requirements or your risks. There's a structure, this, like, meta structure there that it may not be able to assemble consistently the same way every time you run a prompt. So for example, you might give it, you know, a prompt or the same exact prompt. The run looks one way and then it shifts another way.

You might end up with more rows, less data. I've certainly experienced this before where I've, you know, run a prompt one day and then I rerun it again, and it comes up with something different. So same prompt, but inconsistent outputs. In a regulated environment, the goal isn't to just generate something that looks right. The goal is to generate something that is consistent, traceable, and reproducible every time.

This is how we demonstrate that our product is safe. So these models are nondeterministic by design. Right? So it's not a flaw. It's actually, you know, a feature.

But how do we harness most of the benefit of that without taking on too much of that risk? So can't necessarily generate the same output twice or guarantee it. So how do you build in that structure? One of the things that it also can't do is that it can't really manage branching very well. So I think there's some level of version control coming out now.

But if you're looking for, I would like exactly this, and every time we wanna submit it to this other jurisdiction, change it by this much, that becomes another area where it's hard to generate that consistently. The gap between a plausible output and a defensible output is really what takes makes off the shelf generative AI models fall short, which is why we always recommend a hybrid approach. So how do you combine all the great probabilistic elements of an LLM with the deterministic elements of, say, software and automation? So one of the ways to do that is that you can take all of the data from your data sources in a deterministic way, put it into a structured format and an opinion of what the technical documentation should be. So that orchestration layer is really, really important, and it has to be deterministic.

And then you weave in a lot of those generative elements. So anything that requires a narrative, you can, you know, check and verify that it does, in fact, generate as intended. That's where Eva's wonderful quality and regulatory professionals can kinda step and be like, yes. Yes. This narrative is correct and accurate, reliable.

This is how we wanna present our case. And then from there, you're ready to submit. Doing all of this, this entire flow left to right in an automated way, weaving the generation, that review, it needs to be done not once. It needs to be done multiple times. When you're working with all these different jurisdictions, they all have different submission timelines.

And that's why we always recommend, you know, leverage the power of AI. Leverage the power of automated systems. And that's something that Kevin's going to show you very shortly. Thank you very much, Jen. So let me go ahead and share my screen.

And we will see the Ketryx homepage. Perfect. So can everybody see my screen? Thumbs up, Joan, if you can. Perfect.

Great. So first thing I did want to do was we did have one question around integrations within Ketryx. Think it was Michelle. And I will say, we are actively always working on new integrations. Our integrations team is kept busy.

But the most important thing is once you actually have the items in Ketryx, they act pretty much the same as every other item in Ketryx. We manage version control of the item and keep constant records, and they can always be pulled into documentation just like every other item in Ketryx, you'll see now in a moment. So hopefully that kind of answers part of your question. But here we are on the project dashboard in Ketryx. We have a few different projects within this organization.

But first I'll jump into the irregular rhythm notification global project. So here, this is the all items page. As you can imagine, it has all of the items that you have within your project, all from connected source systems. So this is indicated by this column here, and we have a few items from multiple Jira projects. So we have the CS project, the GSPR project, and so on, because this project is actually connected to multiple other Ketryx projects.

And will probably sound like a broken record, so I'm gonna get that out there pretty early on. I'll say project and connected and and so on lots of times throughout this. And so as I said, yeah, this pulls in all items from each of your source systems. And so, example, some Jira projects as well as and as some GitHub items. So these are bit Git based items.

They are pulled in via markdown files directly in your source code, which is connected to Ketryx. And then as I mentioned earlier, once these are in Ketryx, they act very similarly to all of all our other configuration items. So they have a approval workflow, and they can be signed with a PART eleven compliant signature, and they can also be linked and related to other items within Ketryx. But first, we'll do a deep dive into Jira and how these items actually look in Jira. So Jira is a, among other platforms, a great place to do work and a great place to work collaboratively on tickets.

But it does, as most platforms do, fall short when it comes to compliant workflows. So, it's great for, like, really agile software teams, but once you have to start kind of meeting regulations like we do, it does fall short. So, Ketryx kind of fills those gaps for Jira through what we call widgets. So, if we scroll down to the bottom of this ticket, we have two widgets embedded into the Jira platform, which is our approvals widget. So this shows exactly how and when this item was approved, which record of this item that we're looking at at the moment, as well if this item was open at this time, I could actually approve this if I was one of these designated approvers.

So if I was a part of the r and d lead group, I would be able to approve this item in Jira. So being able to work in my existing source system, not changing how I work on a day to day basis, just adding that Ketryx compliance layer and and level of visibility. And speaking of visibility as well, I'm going back to kind of what Jen mentioned about traceability across the entire system. We also have our traceability widget here. So, this shows the traceability of this item across all your connected projects.

So if this was connected to a Git based item, this also would be visible, but we can see this test case is connected to three different requirements and is also a risk control for two different risks here. And so really great visibility. And one of my favorite parts about this and how we integrate with Jira is that you can actually see this in your connected project. You don't even have to go to Ketryx. It's here within the item that you're looking at in the source system that you're working in.

So using one of these little Malik links, I can actually jump back to my Getchoose project and actually just take a quick look if I want to revise and see how this record has changed over time. As I mentioned, we keep revisions of every single change that has happened in Ketryx throughout the entire item life cycle. So if we scroll back, we can actually see the change between when this was last controlled in twenty twenty five to when it was first brought into Ketryx in October of twenty twenty four. And by hitting this little change button, I can see exactly a red line of how this item has changed in this time period as well. So, which new records and relations were added, who was the new assignee, and any other changes that you might experience in that time period, that's all captured automatically by Ketryx.

So going back, I actually think we got misnavigated, so I'll go back to our main project and just take a look at a few of the AI features in Ketryx. So I think we've all been there when you're looking through a document and trying to find a control f or do a contained search for an item in get an item in your system. This is something that Ketryx handles really well using our AI assistant, and I'll show you a few more AI features. But, for example, if I'm trying to find all items all show me all items related to labeling and packaging. And what this does is it does a semantic search within the context of your entire project.

So as I said, it has records from all your source systems and can read those records and actually understand it's not just a search of control f labeling and packaging. You're actually finding items that might have popped up in those general searches. So it shows our requirements, and I'll actually go to full screen here. And related to this, our test cases, and even our test executions, as well as their results. So we can see as it's generating, it's popping up links and links to the results as well.

And the good thing to know here as well is that, for example, g s p r five probably wouldn't have shown up if I just done control f for enabling and packaging, but because the Ketryx AI has context of the system, it understands that, yes, this is a requirement related to labeling and packaging. So next, we've already seen the kind of traceability view on the item level, but if I'm a quality manager or systems engineer who's really interested in tracking traceability across the entire product, what we have for those individuals is our traceability matrix. So this is actually quite a big traceability matrix. We have three levels of requirements or user needs all the way down to our subsystem requirements, as well as specifications and three layers of testing. So this is a really, really customizable page in Ketryx.

And once again, I'm gonna say that a lot because we really try and match your workflows and your QMS as much as possible. And some of the great things about this is the built in traceability checks that you can set in Ketryx. So, for example, we are at one hundred percent traceability for a lot of these items except for our subsystem requirements. And I can go ahead and apply this check filter, and I'll see that we have three of these requirements that don't have a specification related to the subsystem requirement. So, really good traceability there, and you get an automatic view on exactly what might be missing in your traceability.

But secondly, what we can actually do, and I think Jen mentioned there, GSPRs are general safety and performance requirements. If I want to check requirements and test cases related specifically to GDPR, I can create filters and create a custom traceability matrix that shows me my requirements and test cases specifically for this. Go ahead, Jen, if you have something to say. Oh, I was just gonna say, I think it means that in theory, if you really wanted to check traceability for only one jurisdiction, so say it's a little bit different per jurisdiction, having different views allows you Because you've taken all the manual work out of it, you can kind of now do traceability any way you think is right for that region. Exactly.

Exactly. And we'll see we'll see a bit more of that on the risk page as well as we break down our risks specifically by region. But one more other thing that I just want to show you as we're kind of going through this checking of our GSPR requirements and going through approval, although we it's mostly regulatory focused on this, we definitely have a few people who have gone knee deep in quality. We also have some built in Ketryx AI agents that are baked into Patent's platform and have that full context, just like our Assistant. So, for example, we have our requirements expert quality review.

So this will review your requirements as it relates to your QMS. So if you have your QMS and your documents here, you can actually reference your QMS for this agent to do an expert quality review. So reducing the amount of time that your QAR team actually has to go through and do this review. So it will highlight some issues, the incorrect links, for example, scope doesn't match the implemented item across project parent reference. It really is capable of catching a lot of different issues that are within your system.

So one more page that we do want to go to, and we're slowly tying back to kind of main topic of the conversation is for cross project for cross region submissions is the risk management page. So we can focus on this first risk here, so our delayed or missed irregular rhythm notification, and we can see we have some really nice UI elements that kind of make it really obvious which of these risks are acceptable and unacceptable. So first of all, we have this kind of overall risk acceptability highlight here. But if we scroll over, we also have our initial and residual risk assessments. So, for example, for our delayed and missed regular rhythm notification, this, as you would expect, should be If I was a patient, I would think it's not acceptable if this has a pretty high probability and high severity.

So this is nice and bright red, but this is completely customizable. So this can match your risk matrix within your SOP as well. And you don't really have to worry about the say, for example, if you didn't drag your Excel formula all the way down. Jen, I'm sure you can relate to that. So, you can't even run into a situation where you have p one medium, p two high, but then it's still an acceptable risk.

Ketryx kind of automates that at the back end. And then secondly, we can see the risk control measures related directly to the risk within the table, you can see exactly what your team is doing to mitigate this risk. And then finally, the residual risk assessment here at the end, which shows up down here. But how we pull these into separate into each region's documentation, we can see our filters here. So, for example, if I'm looking for my risks that I've related to my EU AI act, I can apply this filter here, and it filters out one of our risks.

Same again for my US FDA. We can find the overlapping risks between these as well as finding the overlapping risks across all of these regions. So as you'd imagine, once again, the delayed or missed regular rhythm notification is not specific to Europe or the US. Everybody wants to know about that. So as you'd expect, that's a filter that you can apply in Ketryx.

And so finally, we can actually jump to our release page in Ketryx. So going to release one point one. And I'll just pause quickly and take a look at our release dashboard. So this is kind of your one stop shop for checking your release readiness within Ketryx. So this will show you all your controlled and uncontrolled items, all of your items within this release, as well as your progress.

So getting these items controlled, we have seventy percent here, but next we have as well the number of test executions for each test case in your test plan that have been executed on controls. And the last thing I want to highlight on this page, there's a lot here I know, is the release checklist. So this is, once again, probably one of my favorite things about Ketryx is you cannot finish a release in Ketryx unless your release checklist is completely fulfilled. So it's a built in control. For example, as I highlighted earlier, if your traceability matrix doesn't have one hundred percent on all of those checks, if those specs haven't been fulfilled, then you will not be able to release in Ketryx.

So that is the bottom line. Your QMS processes are strictly enforced within Ketryx. So finally, going over to our documentation page, so the crux of the conversation, I can actually see if I hit my generate documents, Ketryx will automatically generate the release documents from your source content. So a single source of the content will release documents for each specific region. So if I'm going down to my risk management files, as we highlighted earlier, we have our US FDA, UMDR, UAI Act risk management files.

But then even further down, if I'm trying to generate documentation specifically for an ESAR submission, here we have our ESAR attachments. And as you can see, they're all getting generated. And then the bottom, we have our EU MDR technical documentation specific documentation. So lots of different documents generated from a single source of truths, which is within Ketryx. But once again, all from your connected systems.

I don't think we actually had any Ketryx specific based items. They were all from Jira and GitHub in this project. So finally, we can dive into one of these specific documents, maybe the US FDA, and download a PDF, and scroll through. So a PDF viewer is popping up. So if I scroll down, I can see this is probably a demo project, so there'll be quite a bit of blank information, as we can see here.

But if I go down to the risk itself, I can see each of the risks that Patrick's pulls into this specific documentation. So based on the filters that I applied earlier, different risks will be pulled into each set of documents so we can see the risks and all the information that we want to pull into this document, and once again, completely customizable, as well as the risk control measures related to this risk and exactly how this has been scored and why it is acceptable as well. So I think that is everything that I did want to cover today. So I'll hand it back to Jen, and I think we might go through a bit of a Q and A. Yeah, yeah, we actually have quite a few questions.

So please, please bring them all in. So one question from Michelle. Does Ketryx also include main QMS functionality, for example, document creating and editing docs within the platform itself, and not in an external Confluence or Google Drive, etcetera? Kevin, you might be able to pull something up there, but I'll just answer verbally for now. So we have several different ways for you to edit documents.

For example, if you're used to the download upload feedback loop cycle, you can do that, obviously, with Microsoft Office. There is some functionality in editing directly in there. But, of course, we do have a Google Drive integration. And one thing we love about Google Drive is that it's a wonderful document editing platform with all the bells and whistles. So there's a lot of options depending on what your needs are.

We also have one question. Would a PCCP be required for cybersecurity updates, even if those are considered non significant? So great question. The software significant change guidance, so the software specific one, make sure you get the software specific one for FDA, does cite cybersecurity updates as a reason for, you know, a change that it would be nonsignificant. Of course, FDA wants you to make these cybersecurity changes as soon as possible.

Think about a vulnerability that needs to be patched. So part of that is maintaining the safety of the device, and that shouldn't really bring in new questions around safety and effectiveness. Now I am curious what you might be considering for a PCCP because I can you know, the PCCP, what people don't often know about it is that it isn't just about adding you know, doing machine model training and then updating the model. It isn't just for that purpose. It's also for changes to inputs or outputs, which is also a very exciting way to change a device without necessarily going through a resubmission pathway.

So generally speaking, the answer is no. You don't necessarily need a PCCP for cybersecurity updates, but curious if you can think of a scenario where that would make sense. Alrighty. We have another question. So maybe, Kevin, you might be able to answer this one.

So how are the data from different clients controlled to maintain confidentiality? Does the model include submission dossier requirements from global jurisdictions beyond US and EU? Yeah. So is this related specifically to kind of control between clients? Or okay.

Perfect. Well, I mean, the first thing I would say is Ketryx Ketryx client information are in completely separate spaces. So we have SOC two certifications among other things, and I think I'll probably answer two different questions in one here, but when it comes to Ketryx and its AI capabilities, The Ketryx AI agent is run-in the cloud system, but it is connected to Anthropic and OpenAI via zero data retention policy. So neither Ketryx nor these connected systems will have access to your personal data or your your company's data. Yeah.

And kinda like piggybacking off off of that question into Shweta's question. Sorry if I mispronounced your name, Shweta. But does the data leave customers' systems? Most of our customers actually don't bring their own hardware. So I think most of them prefer going with a cloud model where we can assure security through SOC two and twenty seven thousand and one.

But for the you know, you own your data. Right? So if, you know, it's running in these cloud systems, we have that segregation. Great questions. Really wonderful questions.

Let's see. How would you manage regulation changes that impact the contents of documents or the number of documents that are in the platform? And is there a possibility to customize the templates of documents? Kevin, do you wanna take that one? Yeah.

I I I can definitely say when it comes to customizing templates, I I do that every week. So every single one of the document templates that you saw there would have been completely custom. We do have some out of the box templates, specifically maybe, have some out of the box templates, but also some for eStar submissions that we make available that match the format that is needed there. And when it comes to managing regulation changes, as we said, all of the templates are completely customizable. You can have I don't think there is a limit to the number of documents you can have in a release in Ketryx.

So there's absolutely no worries there. It's definitely something that we have covered. Well said, Kevin. Well said. All right.

We have one more question. I'm gonna kinda bundle it with our anonymous question as well. So do you have regulatory intelligence in the platform? And if there are regulatory updates, such as NIST risk management frameworks or AIAC, MBCG guidances, or any or even standards, how is that monitored in current platform? So really, really good question.

So Catch ups today doesn't have necessarily, like, this, you know, off the shelf. You know, it's automatically monitoring every regulation in the world. That would be quite a lot of compute power for us right now, but it is something you can do. So for each product, you're going to have relevant frameworks or as part of your regulatory plan. You should plan out what are the relevant jurisdictions that are for your product, what are things you need to monitor over time.

And from that, you can design intelligence around your product. So what does that mean? It means that if you have an AI agent, for example, in Ketryx, that is checking for new regulations that are listed in your regulatory plan, it can do that on a schedule. So you program that based on your product specific architecture and your product needs from the regulatory standpoint. So that allows you to customize it.

Now one thing Kevin didn't quite mention but is totally something you can do is that you can actually take the standards that you have already licenses to and embed them into your Citrix instance. So you might have already uploaded, for example, your quality management system SOPs, but you can also upload this upload the standards themselves, and the agents can read through them. And you can ask specific questions of, like, oh, yes. You see this standard and you see the new standard. Can you do a change impact assessment against all of the items in my project and check if there's any impacted requirements?

That's something that you can absolutely run an agent to do. And I see that we've kind of gone through most of our questions and we have one last question, I think coming in here. So the Ketryx website mentioned Ketryx was trusted by four of the top five medical device manufacturers. Could I share who they are? I can't quite live, but of course, if you'd like to chat some more and we can have a longer discussion about where we're seeing a lot of our partners get a lot of benefit from Ketryx and where do they really excel, always happy to do that in a follow-up call.

I will say as well, we do have some public case studies available on our website as well if you do wanna dive into those a bit more. And, of course, if you have any, you know, quality and regulatory questions, we're also here for that. We have blogs. We have resources. Even just going around the Ketchik platform, you can kind of see a lot of things like the standard sixty two thousand three hundred and four.

It's all embedded into the design of the platform. All righty. I think that's about it for our questions. That was really, really great. I actually love those questions.

Kevin, thank you so much for running this demo, and thank you everyone who's attended. Thank you, Jen. It's it's definitely been incredibly informative, and and trying to keep up on all of these regulations as they come through is is obviously very tough, but, you're definitely keeping that going going strongly in our internal team anyway. Eric, just by the way, I think if you have a question, go go through the q and a. It's the best way to get that through.