---
title: "Implementing a PCCP and CI-CD for AI-ML-Enabled Medical Devices"
type: webinar-transcript
publisher: Ketryx
source: "https://fast.wistia.net/embed/iframe/aluz2plf7m"
content: auto-caption transcript, proper-noun corrected
---

# Implementing a PCCP and CI-CD for AI-ML-Enabled Medical Devices

*Ketryx webinar — transcript of the recorded session.*

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

---

Hi, everybody. My name is Erez. I'm the founder and CEO of Ketryx. I used to lead AI and machine learning at Amgen, and I now help teams all over the world develop and deploy highly regulated medical software, faster. When I mean faster, I mean, we can get teams to deploy every week or every day if they want to or every month or every quarter depending on the applicability for their software.

This webinar is being recorded. It'll be sent to you along with the slides, following kind of the end. And a cool thing is we're also gonna send you a PCCP template that you can use if you want. And we're also happy to talk about how to integrate that template into your existing quality system. Please put your questions in the QA area at any time.

I can answer some of them live. Many of them will be answered, asynchronously by some folks who are sitting here and helping me. So if you happen to leave at any point, please do the survey, that it's in the end of the session. And finally, we just have a a link in the webinar chat for our next webinar, which is SBOM and Beyond FDA compliance cybersecurity vulnerability management. So please, register if you wanna learn more about how to comply with all the new regulations around the patch act and SBOM and so on.

So thank you, everybody, for coming today. Very excited to be here, and I see a lot of familiar names, if not faces. So thank you all. This was a very well requested webinar, and I'll just get started. So like I said, this webinar is gonna be about how to implement PCCP, a predetermined change control plan, within a CICD environment, in your company, both for greenfield projects and and projects that have been ongoing.

We've done this with folks, more than once or twice, and we ourselves kind of, I guess, in some way do PCCPs every time we do a small incremental release. My background is I used to be a scientist. I then went to work at a company called Wolfram Research, developing Mathematica, WolframAlpha, and the Wolfram Cloud. I was hired by Amgen, the large, pharmaceutical company, our largest independent biopharmaceutical company, to be the head of AI for their medical device combination product division. Went back to school after that and then started this company.

And I also help write standards related to, cloud development, AI, security, whether that's one one five or three four nine seven one, which are, technical ports, about kind of cloud and AI. And kind of I spend my days trying to help, life science manufacturers develop and deploy software and products faster, and safer. We always like to say the Ketryx is a way to make safer software faster. Before we get started with what PCCP is, I wanted to share why we're even here in this room talking about AI. Why is the FDA launching so much new guidance, around this?

And I'd say the the core aspect is that AI is really helping people out there in the real world. I'd love this example. And I see people in the room that I know that have companies very related to this. And this example specifically talks about how, an AI company, used a program called subtle MR that can connect to existing original equipment, MRIs like these, I think, is a Siemens machine in this case. And with this aftermarket offering, kid reduce the noise, of the image, and as a result, reduce scanning time by about sixty percent.

Now think what a wonderful product this this is. One, it provides companies with a way to increase sales and have value added aftermarket offering to their existing customer base. Two, it increases the throughput of an image facility. Right? So the both the hospital gets more money, but also kind of the, the staff kind of gets to do more of what they love, right, which is working with patients, getting them in and out of the machine.

Patients benefit because they spend only about a third of the time in the machine compared to the current state, and kind of everybody benefits around the ecosystem. So everybody gets access to better medicine faster, and I think that's one of the big parts of AI in medicine. It's not just about replacing what people are doing or changing how they think about things. It's about, enhancing existing, processes and accelerating them and making things more I think that's kind of the one of the true goals of AI. AI is increasing efficiency in health care, and we all know we need a lot of that.

So as a result of so many hundreds of devices are being approved with AI models and AI subsystems, the FDA has decided to, modify existing guidances and expectation and allow manufacturers like folks in this room to release regulated software faster, with continuous integration, continuous deployment, assuming you set it up well and you coordinate with the FDA ahead of time. That's called predetermined change control plans. So what is, PCCP or AIMLPCP all about? It's about the ability to legally change marketed devices, with less regulatory burden, assuming you've preapproved the way you're gonna change with the agency. So it's about core kind of four core aspects.

Number one is what do you plan to change? Number two is how are you gonna manage your data life cycle? Number three is how are you gonna perform the change, and then number four is how are you gonna evaluate the performance of the model given the change. Right? So how are you gonna do it?

What are you gonna do with the data, which is part of this whole process? How are you gonna do it? And then how are you gonna measure success? Very similar to change management procedures that have always existed. Just in this case, we preapprove it with the agency to give us a lot of freedom to work.

And the idea is mostly that the agency wants to see you have a control of your processes and the way product changes. And if you do that, they'll allow you to work much faster than they have before. Right? So you could maybe do a version a week or a version a day or a version a month. Again, still need to generate a DHF and and all the other evidence, and put it in in the right folder, so to speak.

But you would be able to do this very rapidly, at scale. And I'll say that, of course, this is still based on IEC six two three four. We have some great webinars in IEC six two three zero four and how you integrate them with tools and how do you leverage Jira and GitHub for that. But I'll say that six two three zero four is a great standard for software life cycle management. It could be commonly used in many different industries.

We use it for our GXP software because we develop sixty three or four compliant software in Ketryx, and it still works for IRML. They're just kind of a different, specification or software item. So, you know, six two three or four, has these different phases. For example, software development planning. Here you can see the different activities as part of this phase and then the different deliverables.

And, of course, this might mean slightly different based on your quality system. After each phase, you can do kind of an audit, of your materials to make sure you have it. Right? Right? So the next phase, you do software requirements analysis, get all your requirements, produce an SRS.

Then you could, you would design your architecture, produce an chart. And, of course, while this seems like a waterfall, you don't have to do it necessarily, sequentially through time, but you can produce it at the end. You can work through it. Right? You can, make sure you're doing this work in this way because each thread here doesn't necessarily need to be all the use cases, all the requirements.

All the artifacts should be a thread of traceability. But, you know, artifacts can be produced ad hoc and and likely should be produced ad hoc if you're trying to do PCP and rapid change. Then we have the detailed design following the architectural design where we explain in fine detail what the system does. We then implement the units and verify them. We integrate and test, and then we perform system testing and then, of course, release and post market surveillance following one three four eight five one four nine seven one.

Really, PCCP touches these components mostly. Maybe some performance requirement if you think of your metrics as performance requirements. But it kind of just says, hey. Why don't why aren't you able to change this area whenever you think it is appropriate, assuming that you've done thorough testing and you understand how to control that change and the implication of that change and how to measure it and how to automatically update it. Think this is a very, powerful way to think of things where we don't really need a ton of new guidances and standards and regulations.

What we really need is to, comply with the existing regulations in a slightly different way. So to change the way we think of compliance moving from kind of a twentieth century compliance mindset, which is how we translated the rules back then to a twenty first century compliance mindset, which is how we're gonna translate the rules now given what we know about cloud and AI and continuous integration and continuous deployment, which is a tool used by almost any company in the world. And this is all part of the software manufacturing process. So I'd say that this is a very procedural way to look at this, and this is a very functional way to look at the same thing. Right?

Under one three four eight five, one four nine seven one, eight twenty, whichever one of these kind of groups of regulation, the guidance as you wanna or standards you wanna select. What you need to do is really plan what the device should do, have initial risk assessment, design, implement, build, and test it rapidly, ideally all of the time. Right? Produce artifacts like the DHF, software build materials, and then go to verification and validation as well part of the DHF, final risk analysis, release, distribution, and post market surveillance. Two interesting here is, one, because we're now working on cloud and advanced software, instead of a very small embedded device that maybe we've built completely in house, we now have thousands of different dependencies we use.

Right? If you're using TensorFlow or PyTorch, any one of these AI packages, you're likely using thousands of different dependencies as part of your software supply chains. We need to have a way to control all that. Number two is as we deploy it into the cloud, the agency and European regulators are quite interested to understand how exactly are you doing that. And we know from audits from partners that that's starting to come up more and more, show us the path of traceability.

So if this is how it looks for software, right, what changes for AI? And the things that change are quite subtle. So number one is along with traditional passive post market surveillance, there's a more active continuous model validation that us from a safety standpoint, we want to continue to monitor the model to make sure that the error is not growing out of control. The second thing is in this design implement build test, there are just more steps. The steps are very similar, but there are just slightly more of them.

So you don't just need to design your software now. You need to design your data. And you don't just need to design your data. You need to design your software still and then your model. Of course, this is the thing that all the machine learning architects love to do, playing around with architectures, learning more about new architectures.

You then need to implement the software and train the model, Right? On your data, really implement it, build the software, and then test the model and integrate it back into the software. It's a AI subsystem back into the software. And this is what it means to manufacture AI for highly regulated applications. So unlike, software, we just have more steps here in a slightly more, active approach, I guess, to model validation.

But the real change is the fact that you don't just need to design software. You need to design data and models and then, of course, train the model, test it, Ideally, test it totally separately so it's ready for PCCP. Just as a note, happy to get questions on this. Some of them I'll answer live. Some of them, some other folks will have.

So please feel free to post some questions. And at the end of the day, how does PCCP tie to this? One is we gotta agree on the metrics. What are we trying to optimize in this model? Is it a classification model, a prediction model?

What's the score we're trying to base off? Accuracy, f one, or kind of any other metric your machine learning scientists will find is appropriate for your intended use and what you're doing with this actual model. The next part is ensure the metrics are met. I know that sounds kind of, basic, but I think it's important to think about it. Right?

We need to separate thinking about the metrics, agreeing these are the right metrics, and then ensuring they're met with every build of the system, assuming we wanna deploy it as part of a PCCP. So the idea here is, of course, we have a software system. There's a data system, a model, the AI system, and then we independently test the AI system, integrate that into the software. And, of course, we need to do certain data cleaning, data management activities, to make sure that's safe. And I'm gonna leave this here for a second before we start getting into how to validate AI systems.

You know, I'll say that there's three things. You need to understand the critical quality attributes like the metrics, need to understand risks, and you need to understand the underlying datasets. I'll just share this, the the poll we did at the beginning of this, so folks can see. I can see the most people. Right?

We're still trying to figure a lot of things out. We're beginning to implement it. We have plans to integrate it into our PCC into our QMS, but we haven't done it. So, many people have not really thought about this. I'm glad you're here in this webinar.

I'm happy to help, and my team's happy to help and happy to share more information as as well as the template we're gonna share at the end. And then there's kind of this last question of, do you have plans to integrate it? Like, how are you actually gonna do this live? And I think it's it's very challenging, and doing it manually is against the spirit of the regulation. Because the whole point of this new guidance is, basically, you could do this really, really fast, and you need to validate only certain metrics or verify certain metrics.

So why don't we just do that all automatically? At least as automated as our risk appetite allows us depending on your scale and your type of device. So I see here two questions. I'm I'm just gonna read them for a second and see if we should address them live. Yeah.

So I think, can you give example of the type of changes, that fall under a PCP instead of just regular software changes? So I think it's just more extensive than regular software changes. It one is you could approve a lot of different things with the agency. It still waits to be seen what they'll allow you to do and not to do. But, basically, you can change really substantially your software and the architecture of the model.

Right? Replace a totally new model and retest it, which makes sense because model architecture is not as deterministic as software architecture in the sense that we don't really, really know how it all works. We're mostly kind of feeding a data and testing a lot of different aspects. So maybe putting in a different model. So I think that's one aspect of this, this rapid change, and also the fact that the change is preapproved so we can start kind of, changing things in a more extensive way.

And then I see another question, how functionally do you distinguish them between within your QMS? I think we're gonna show that, in a moment here. So I'll answer that live in a little bit. That's gonna be part of the demo. How do you functionally just go to them from your QRS?

And then the last question here, thank you, is how do you handle the situation with a third party model? Well, in the exact same way. And and we're gonna see how we deal with the subsystem, and I think we'll see that the subsystem is very similar, to just having a third party be the subsystem instead of your subsystem. So, again, you put them under your agreement. You bring in them as you do with other subsystems of your device.

Happy to talk about that further. So coming back to how to validate AI systems, there's these three aspects you wanna know. You wanna understand the CQA, the critical quality attribute, in this case, metrics likely for the model. What's the method you're using? What are the metrics that are appropriate for that?

One of the biggest kind of games in machine learning is that there is a lot of metrics you could use to test different aspects of the model. And that's where your subject matter expert for AI comes in and says this is the appropriate one or these are the appropriate one, one or more. Right? Potential risks. There's a lot of risks that are unique to AI, whether that's data drift or unexpected decisions or, kind of, all kinds of unique, cyber vulnerabilities that, could be used in the model or in the data.

So we need to make sure that we're verifying that those risks are controlled and then making sure that our underlying dataset as we update is still appropriate for our intended population. Right? If you are thinking of serving people in certain regions with certain ages and ethnic groups, it's quite important to make sure that when we update the model that, you know, we thought we're serving all of the US. But in reality, we're only serving patients in MGH and Boston, Massachusetts, different population group. We need to make sure we're debiasing it and looking at that.

So what does a PCCP look like functionally? So let's just go through a few steps. First, we have an approved model, and then we're trying to get to a release of a new model. Right? So we have an approved model.

It's been out there in the wild. People are using it. We're getting new data from patients. And what we wanna do is like any other great AI company, we wanna leverage that data to create a better model, give they can serve patients better and give them better accurate results, for their disease, knowing what we know from real world data. So the first step is we wanna analyze the data under make sure the data is in the right quality.

It's for the right population that we expect. And then number two is segregate the data into training and test data and and make sure that we shuffle it correctly so it's kind of mixed in the right way. After we separate it to the training data, the thing I'm gonna train on the test data, what I'm gonna test that the model works on, we then wanna, send it to the model, retrain it. Maybe it's even a new model with a new architecture because new architectures come out all the time, especially if you're using third party foundation models. These things get updated all the time and every week.

Right? There's a new model that's slightly better than that other model. Right? Is it, CHAT GPT, or is it CLOD, or is it a million other stuff? And then we get a new model, and now we need to make sure that the model matches our acceptance criteria, the impact assessment passes, and basically our PCCP, kind of can be done, and then we release it.

We need to both make sure the model infrastructure is still validated and the model is retrained, and then we need to make sure the system is real, validated, and accepted. Right? Because depending on your system, it could be that the model being accurate could be many other things. So going forward, I wanna talk for a second about what is CICD, and then I'll bring both of these together. So what is a PCCP and what is CICD?

So many developers, especially cloud developers, view this as kind of their, I'd say, their their temple almost. This is a belief system. The belief is that we need to continuously develop software, integrate it into our main branch, and then deploy it into the server. In many companies, this happens every hour or so. There are release trains that go out every hour.

And if your new software code integrated into the system and all the automated tests have passed, it gets kind of kicked off on a train into the cloud, yeah, every sixty minutes or so in most large tech companies. And what happens is we have this main branch where all the development happens. All the code is a developer then takes that branch often called the feature branch. They do a lot of work. Right?

They do their own work on this, try to tweak something small ideally. Right? We want changes to be as small as possible to increase quality, and then they have a change request, merge them, and have a code review as done in any other industry as well as our industry only here. It's kind of required by law under GPSV. And then continuously integrate it into the main branch and continuously deploy it into the production server.

And just to be clear, the reason people do CICD is, one, you can deploy features faster to customers, but two, it's safer. You produce higher quality product by making smaller and smaller changes and constantly updating, kind of the external product environment and then getting feedback on it. So this is a really, really important concept, CICD. I think it's extremely challenging to do validated CICD. So CICD inside a validated environment, and I've spent the better part of my adult life trying to figure out how I can help people all around the world do this, with an amazing team of folks doing that.

But how do the two the two ideas relate, both PCCP and CICD? And I'm sure the folks here noticed from this drawing that CICD is very much a twenty first century, type compliance problem, and we need to transition from how we've thought about doing compliance to how compliance needs to be done today. This is kind of what it looks like at scale. Right? So let's pick just a place here to start the cycle.

Instead of new product introduction, I kind of wanna pick, after release deployment monitor, maybe here, post market surveillance. So we get a lot of new data about the product. We then plan our next release. We develop. We design the data.

We make sure we grab the data, make sure it's debiased, design the model, make sure the model is validated given our PCCP, configure a software supply chain, validate our software, release it, deploy, and then monitor and go all the way back. So this is kind of how both of these ideas intersect, where the part of the PCCP is really tied to this. So you kind of do the PCCP, here more or less and here making sure the software is still validated and the model has met all your metrics. And then you keep releasing it continuously or manually. Right?

I don't think that all application need to be released every hour, every day, every week. I work with a lot of customers who have ultra high risk applications, and I don't think that would be appropriate for them. But I think for a huge majority of applications, essentially, the lower risk ones, the class one, class two maybe sometimes that folks work on, can be deployed like this regularly, and both companies, patients, and hospitals, would benefit from that. And this is just gonna get more and more important as we take medicine away from the hospital into the home for folks to treat it there. I'll stop here for a second to see if there's any question because we're about to go into the demo in just a few slides and kind of just do this together.

We're gonna go through a PCCP, and do this together. Good. So let's keep going. So how do we actually do this? I think we had one question of how do you functionally distinguish them?

That's part of the strategy is this building of the the architecture. But how do you, how do you design the world you work in to allow you to do this? Because I think in the very near term, five or ten years, we're gonna see two types of regulated companies in life science. The companies who can take advantage of this and the leaders who set them up to do that and the companies who did not And the companies who did have preapproved the PCCP with FDA, have designed their system for this. And by the time the companies who did not are in version two, they're on version fifty.

And they have a much better product with much better functionality, and it's safer, and they have less recalls because they're doing smaller releases at any time. So there's three things we think about. Number one is architecture. Exactly like this question from Mary. How do you distinguish functionally between them?

Two is how do you enforce procedures automatically and generate evidence automatically? And number three, how do you integrate risk analysis into your configuration and management to make sure that when you're working on something, you're working on the right thing? And one of the challenges is that while PCCP requires to be very organized, most software does not look like this. Most software looks like what they call a ball of mud, which is, you know, you just try to figure out how it works and you broke something and broke something else. That's not the type of software we need to have to take advantage of this.

And in fact, it's, in many cases, not the type of software even kind of very, forward thinking tech companies build anymore. They're actually trying to build things quite organized in order to make it more maintainable by a smaller staff. What we need is this. We need a LEGO tower, and then we need to be able to grab one brick of this LEGO tower, the AIML subsystem, lift everything off, change that brick for another brick, and retest that it still has the same, qualities or attribute. It's very hard to do.

It's very hard to teach people to do that. But the advantages, again, people who won't be doing this will be on version two. People who will be doing this will be on version fifty. So we said one major thing is to design your system with PCCP in mind. So today, we're gonna talk about how, you could do that in a system, and I'm gonna demo that system, and then we're gonna talk about kind of the other strategies.

So one example of a system like this is you have a system that interacts with patients. Maybe it's some irregular arrhythmia notification system, and it has two different subsystems. One is this hardware subsystem. We're not gonna talk about that too much. And the other is this AI ML subsystem.

We're gonna address that mostly. And that AI ML subsystem is gonna be changing rapidly and often. And, of course, it has different kind of libraries or soup items that it uses. So before we go into that, I just wanna have one more poll question. So please fill up the poll.

We'll see what people say, and then we got into the demo. And, of course, during the demo, we're happy to get questions and answer things. And what we're gonna do is we're just gonna bring to life this specific system, and then we're gonna do a PCCP together today in the next fifteen minutes. And I think, I hope that will show you how this is gonna look for all companies in the future because there is a way to do it every day automatically or every week or every month, but with more control and safety than we have today. So I'm about to close the poll.

I'll just give it another second here because I see things folks are are still filling in the poll. Thank you for that. And and, yeah, we know that there's a lot of kind of regulatory froth and lack of understanding of how this looks and what to do. And we're trying to understand. It's very hard, to do this.

Someone who worked for a large biopharmaceutical company, I'm aware of well of these challenges. Okay. So let me share this poll results, and I think we're gonna see that many of us are in a very similar boat. Right? We're trying to do this stuff, together.

And one of the things we wanna do as a company is help bring that cross industry knowledge into different companies to help you, know how to do this and kind of reduce the time you spent on done nondifferentiated parts of your product, like the infrastructure for PCCP. But let's get into a demo now. So, what I'm gonna do is I think the I shared the results already, so that's good. And right now, I'm just gonna get into a demo and show you this exact system. So again, remember, there's a top level system or an application of product.

There's two subsystems. One of them is software AI subsystem, which we're gonna do a PCCP to. The other is a hardware soft subsystem. And let's just get started. So I'm now jumping into Ketryx.

All of you are welcome to try it on app.Ketryx.com. I'll ask someone, from the office to please share a link to app.Ketryx.com. You can connect this to Jira. This is something that you can do in a few minutes and try it out for yourself. And what you see here is the exact diagram we have here.

Right? We have this irregular notification system. This one, the two subsystem is the hardware and the software subsystem. And we're gonna talk about how we are gonna link these different systems up, particularly this soft resale system is linked to this art to this, product. And then we are gonna, make sure we're running through a process with it, doing it right, and, going from there.

So let's dive into this AI ML subsystem. So this is the Ketryx project. We have all the different modules of Ketryx, whether that's traceability or risk management and so on and so forth or SBOM management. And I'm on the all items screen. This is a screen that allows me to navigate all the different items.

In this case, I see that I have some requirements that are in Jira, where I can kind of see different things. There's really three things we do to Jira. Number one is, create traceability. So we can see here the traceability of this item to other items based on the Jira links and links across other systems. This case, we see it has one parent requirement and many different specifications.

We provide a means of approval. So we have this approval palette, where you can sign in a part eleven compliant way depending on your role. And number three is we provide a complete audible history of Jira or any other connected system, including all the changes that happened to it based on Alcoa plus plus, requirements, as well as all the different documents generated using this configuration item, which is stored in Jira. There's other types of configuration items. For example, you can have specifications that sit in Git.

So I just clicked on this. I transferred to the Ketryx record, and now I'm in Git looking at another configuration item. In this case, it's a software item, and it has that c s one as a requirement it fulfills. We see that mentioned here in the code comment. And kind of we do the same thing, traceability, approval history, and so on.

So you can store items whether in Jira or in Git. And it doesn't just need to be a code comment in Git. It can also be, different kind of tests like this type of test, cucumber test. It could also be a markdown file. I'll try to find a good markdown file here.

Just a moment. No. That's still a, still code comments. So here's an example of a markdown file. So you can store it however you want to, and developers love this.

They love to store that information. It also makes it easier to change and manage that change. The second thing you can do on the screen is look at different versions. So what we wanna do today is approve version one point one. And first, I wanna see the difference between version one point one and version one.

So let's see difference between version one point one and the baseline, the last approved version, version one. And let's see only changed items that are risk controls. Well, none. How about change item that are missing tests? Well, none.

How about new items? We have none. So the difference between version one and version one point one is that we added risks, three risks in this case, model hallucination, interpreted data connection, and so on. And we can see that this model hallucination is, again, a Ketryx record. You can see it in Ketryx.

You can download it as a word or a PDF. You can see it in other ways. So what we do now is after we work through this change in Jira, we can go and kind of see how we're progressing. So we can go in our traceability area, and we can see you know, I'm gonna align this by design output because it's gonna be slightly, I think, more organized. And we can see that we have, several different specifications that are in Git.

They have different verification tests. There's several different design inputs requirements that have validation tests. It's all very neatly organized. We can read that everything is okay and passed, and there's no errors. And we can see up top here that the traceability is a hundred percent.

So a hundred percent of the design inputs are covered by design outputs. A hundred percent of the design outputs are covered by tests, and so on and so forth. And if something wasn't covered, we could use this to discover that. And we can also use this to find kind of gaps in the traceability and the traceability level. So now what I wanna do is make sure we see that we can have automated tests in this case that are testing as part of this might be part of your PCCP, that automated test.

Right? Part of viewing that metric and proving that metric. And then maybe we should look at the risks for a moment to make sure all the risk controls are met. So we're in version one point one. We see that we have three risks, model hallucination, interpretation of data connection, model drift.

All the risks are acceptable as we can see. We can move here, see the different risk calculation, see the different mitigation, the different risk digital residual risk calculation. And if we need a benefit risk analysis, we could require that to happen. So we know all the risk controls. And the last thing is we can see just all the risk controls for a moment and make sure they're tested in this version.

Another cool thing in Ketryx is that you can automatically, ensure that all risk controls are tested as part of a release. So as part of your PCCP, you can make sure that all the risk controls who are ideally automated tests have run and tested, and, you can see all of them. The next thing I wanna show you is kind of the architecture of this product for a moment. So we see here this automatically generated architecture diagram. We're in this AI subsystem.

It has an AI module, and has a sensor module regarding to reading the sensor, giving some warnings, and then doing the model inference. So we see the subsystem. We can also see it in a tree view if we want of how it's structured. We can also see just the first two levels of it and not more to understand this, how it's structured. And this, of course, can be printed out in your documents again as part of the PCCP.

And now let's go to the release screen to start going through a PCCP. So I go to the release screen. Let's go to release for version one point one. We can see all the different aspects of this project. Right?

I have twenty controlled items. Three of them have changed recently. All my design controls are ready. All my tests are executed. All my risks are done.

No change vulnerabilities or change impact analysis. All my risk controls are verified. I can click here to see all my documentation is ready. Specifically, it's kind of a shallower system. I just had an SBOM or risk management file, an SRS, an SDS test plan testing report, and a predetermined change control plan report and a conformance report, which we're gonna show later on.

And then we can see all the different milestones that are part of this project. So milestones are a way to block or monitor information. So we can say that we wanna collect all the real world evidence and and do certain things, data cleaning, make sure that data cleaning is happening, configure different things, and then configure a bias report and get ready for a release. And then we can decide also which kind of type of artifacts we wanna generate as part of this. If you notice, this is very similar to the setup of, six two three or four kind of workflows where we can create different milestones for different phases.

So we do all this, and then we generate a document, right, for the PCCP conformance. So I'll generate this document for a second. We'll just open to see what we mean by this. What it means here's a report. Of course, it's a templated system, so it could be adjusted to your templates.

We can see here the different test cases and the test case title, and if it it it passed or didn't pass and a link to that. And, of course, you can add much more information than this. This is just kind of the very basic testing, and we can automatically produce this for every release. And this is what you need to do in order to do PCCPs fast enough, especially if you wanna do it in adaptive algorithms automatically. And now after we kind of looked at this and the different documents, I wanna go back into the higher system.

So we just spent time in this machine learning subsystem exploring it, and now let's go one up back into the regular system and notification. So I go back to my projects and I click on this system. This is kind of the application where things are stored. Again, it's very similar. Right?

I see that it's a lot of Jira project. I can look at its traceability. As you see, the traceability table is different. It's configured to be a system and subsystems. I could look at all the different user needs to make sure they're met.

In this case, it's a very simple demo build system. It has just one use case or one user need, different system requirements, different subsystem requirements. If you notice, some of them come from the system we were just on, the c s one system, different specifications, for those subsystems, and then different testing for the subsystems as well as the system if you wanted to. Again, we can see that everything is passed or, whatever is not passed is not included in our test plan in this case because we already have a strong baseline. And we can, of course, move between different versions to see how this changed over time if it has changed.

Let's put ourselves back on version two. And then in this case, we wanna see the architecture diagram for a moment. So we see that we are in this system. The application we're in right now, there's two aspects aspects to it, monitoring and the device administration UI. And we see that the monitoring dashboard uses this AI kind of PCCP subsystem, particularly the AI system, the AI module in that subsystem.

And then this sensor calibration manager uses some specification in the sensor. Right? The hardware system. All of this is, of course, like I said, automatically generated, easy to see. We see the gray parts are external systems that are validated separately.

The purple is an external kind of protocol, and everything else in red is, this system. It could also be color coded based on the risk level. We now wanna move from here after we saw that we have these different subsystems, different AI, ML subsystem, and I wanna show you how to release this. So before I go through the whole release process, I just wanna show how the, DHF would look. So the DHF looks, something like this.

If I go to the history and design history, I see that there is, a lot of different documents here. These are documents from the DHS for my primary system, the system I'm in. And then here on the bottom are the different milestones, including the product milestone and the subsystem milestone and the reference project, the report from version one, which we can see is not released yet, unlike version one of optical heart sensor. Sorry. Version one point one and version one.

And this would be all the different kind of information from that generating another file for us. Right? So we just leverage that subsystem to create the DHF for this system, and we could do that in multiple places. So we can actually spread that model across many different systems easily. And now let's go to the release.

So we wanna approve version two. That's the version that has the PCCP. We see that it's kind of done. Right? I can see this checklist.

All my design controls, item validation, dependencies, test execution, and test plan, traceability, and documents are done. And the only thing that's really missing is I don't have any, approvals for the milestones and then the final proven approval. So let's go just take care of those two milestones. Right? So I click on this.

I go into the milestones. It's ready to be approved. Only the only thing that needs to happen is I need to approve the subversion. So let's go to that subversion. Let's approve it.

If you notice, I'm in a version one point one of the AI PCCP subsystem. Unlike where I just came from, oops, which is the, the product that was just in, the the kind of higher level system. So we go back into that. I approve it. It's part eleven compliance.

I need to give my biometric signature. I've approved it. Voila. The model is approved. I've just done a PCCP.

I've tested it all, and let's now go back. So we are proving here. Let's approve this milestone. So we've approved the milestone. Now let's approve the V and V report.

Again, you say it just blocked me because I couldn't the underlying subsystem wasn't proof. So, Mary, I hope this answers your question of how we segment things. Right? It's totally segmented away, that subsystem that we're just working on. And then let's approve this milestone.

So I'm proving the last milestone as part of this PCCP. And then let's go to the release, and we see that the release is ready to go. The checklist is done. The only thing that's waiting is for me. All of this, by the way, can be edited to have your organizational procedures bring to life that QMS.

I approve it. I'm using my security key. I scan it. I approve fireworks. We just did a PCCP together, including creating all the DHS documents.

And what I mean by that is we can go back to the release documents, and we can see the different documents for this system, whether that's the code review or risk management file for the system or SRS. We can see the architecture chart for the system. I'll just open up a few a few different things. Oh, probably don't have the right app for that. So let's look at the risk management file for this system.

So we see the risk management file here, the approval of it, right, the generation that just happened, and then also all the different kind of fields and metrics and calculations and all the different information of items related to risk and the different risk controls and their execution. You see that in this case, a lot of my risk controls for a risk came from the subsystem. And here's what it's a risk control for and the different tests. And now if I keep going down the DHF, I can get eventually to my AI system, and here is the kind of underlying risk management file for that system. And, again, I can tie all the risk controls into an automated testing to make sure that every time I do a CICD build, an engineer can't break what we're working on.

And then finally, I can see that PCCP conformance report we show earlier. Again, I'm in the top level project. This is now part of a different DHF of that higher level project. Wonderful. So I will give this a moment of pause because I know that this is, a big topic for folks, and I'll see if there's any questions.

One second. So I just realized my screen is a bit frozen, so maybe I'll ask someone, to let me know if there's any questions I should address live or any questions that, I should, or folks can answer asynchronously. I just can't see the questions right now. Hey, guys. Jumping on here to provide a question.

Thanks, Gabriel. So we have a question that says, in the demo, I didn't see anything about data analysis and management. What data did I select for training versus test versus test validation? What a great question. It's funny because we were just talking about this ahead of time that someone would ask that.

So I'd say that this is a very simplified demo. And what I would really do for that is I'd have another project that just for the data, and then I would do kind of a similar procedure for that data that gets fed into this AI subsystem. So we didn't really do that, but you could do that, where data is just in some cases a soft item. Right? Because it's just a code entry.

Any other question there, Gabriel? Yeah. Yeah. Yeah. We have another great one from the crowd.

What is the process of evaluating whether a change is within the scope of the authorized PCCP and checking whether the authorized modification protocols are followed per CCP? How do you label PCCP changes and non PCCP changes within the AML subsystem in Datrix. So let's go there. And there's a bunch of different ways to do this. Right?

This is one of the challenges of building something like this that works with large companies and small companies. It needs to be quite accommodating. So you can design this to be a release that's more, you could say that every release here is PCP. You can also create different types of releases, like a full release or a patch release or an incremental release that is based on certain items. I'd say that most PCCP releases are more incremental in nature.

And then you can write all that information here from a scoping baseline perspective. And at the end of the day to know that you meet the metrics, I would say that they're just certain tests, And maybe you need to create a test plan or a test protocol that has those tests as part of PCP that has to pass. In my, I'd say kind of my opinion, working with a bunch of companies and thinking about this for many years and designing systems to do this, I'd say that why don't you just say that every release of the AI ML subsystem is compliant with PCCP? It only has automated tests that test those exact things, and then that's the only way that it can do. And you tie those tests into your kind of pipeline, so you have to run them.

Anything any other question, Gabriel? And I'm, again, happy to to take more questions on this. Yeah. Absolutely. Yeah.

If there's any follow-up questions on that one, feel free to add them in. One more question on change assessment. How do you how are you able to link the significant change assessment and regulatory assessment against every software change made in Ketryx? Yeah. So there's all kinds of ways to do that.

You could one is just create documents that describe those changes and the different assessments. You can also kind of create a regulatory project and then, link them as a kind of it's kind of like another system that links into this system with all different regulations, and then you can diff the changes if you wanna do that. And, again, you can create fields as part of the release, area that are mandatory that say, you know, I have to write this kind of assessment or not assessment. And, frankly, I would say that for PCCP like changes, I would suggest modifying the SDLC to not require, any significant, assessments of that nature. So just have it be done automatically unless it's a change more significant than what we defined in the PCCP.

Cool. So One more. Yeah. One last question, Erez, on working with partners. How do we manage the control of components and models or algorithms which are developed by partners?

Yeah. So, it depends what kind of partner. If it's totally on someone else's server, I would say that you should be testing it, kind of routinely. And I would wanna see in the same way they interact with vendors as part of one three four eight five, some evidence of that. Again, it's probably gonna be soup if it's an AI system because they're not developing under, the same type of ecosystem that you are in the same type of life cycle.

And then, I'd wanna at least qualify, that kind of incoming item as I update and change. And if you're saying, you know, I leverage this other system that's constantly changing, I would just create a bunch of automated tests to test it frequently to make sure it meets my PCP requirements. And we have partners who basically, what they do is they outsource one of the subsystems, kind of we'd link into a Jira project in their vendor's hand, which helps a lot with that. Cool. And I'll take some more questions at the end.

I just wanna make sure we, finish on time and then get enough time for questions. So, going forward, we did the demo. I just wanna recap of the three major, I would say, strategies you need to cover to bigger the foundation for rapid change. Number one is design your architecture thinking of this change. And ideally, this AI subsystem and this hardware subsystem would be connected to many different systems.

Right? Not just one irregular arrhythmia notification system. Number two is you want your procedures to be enforced automatically and and your evidence to be generated automatically. Like I showed you, I can enforce certain procedures about, requirement traceability, risk control, verification, document generation, approval, segmentation automatically through the system. And it can also happen kind of as part of a push in a CICD kind of way.

And that helps a lot. Right? Especially if some subsystems are much less risky than the top level application or another subsystem. Number three is you wanna think how risk analysis is integrated into the way you manage your configuration. So one way to think about it is in the grand scheme of things, we're trying to get ready for post market surveillance and modifications that happen.

So we wanna have everything well segmented under six two three or four and delineated. The other part is I wanna be able to say this specification deals with kind of very low risk or a very high risk thing. And as a result, it has certain procedures or not, that it should go through, and you should enforce that automatically to make sure it happens every single time. And the last thing I wanted to share, is really how we think of, governing this. This is a a format that I've shared with a lot of different businesses.

Some of them kind of run on this now, which is just, I'd say how, one way for a large organization to do AI program governance. So you typically would have an AI center of excellence where you have PCCP experts and AI validation experts as well as AI experts. They they, work with different business units, to do this work. Different business units have different applications that get served to them. Right?

They create kind of the models, business units, apply them to their specific need, maybe modify them, and then run different programs. And as part of those programs, you get attached to a PCCP and an AI validation strategy or metrics, and those get approved by the governance committee. Now what helps here is the more this governance committee does this work, the better they will get at doing this. The more the staff at the AI Center of Excellence will get better at PCCP and AI validation. The more they'll sit together and think of these things, the more you'd be able to deploy it in the business units, the more programs you'd be able to run.

And that's it for our session today. I know we have five minutes left, so I'm gonna, wait and answer questions, and I'll be here kind of over time to answer even more questions. And I'll say that if you wanna move faster and use your preferred dev tools, automate your DHF, and enforce your SOPs in those different tools, we'd love to talk to you about it. We'd love for you to try the product. It's free to try app dot dot com.

It also has certain free features that we'd welcome people to use, like our EQMS.