---
title: "Jira for IEC 62304 - Developing FDA-Compliant Software (May 2026)"
type: webinar-transcript
publisher: Ketryx
source: "https://fast.wistia.net/embed/iframe/uv6dwkercy"
content: auto-caption transcript, proper-noun corrected
---

# Jira for IEC 62304 - Developing FDA-Compliant Software (May 2026)

*Ketryx webinar — transcript of the recorded session.*

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

---

Welcome, and thanks for joining today's webinar on using Jira to support IEC sixty two thousand three hundred and four compliance software development. We will get started in just a couple minutes when we get a few more folks. Today, we'll cover how teams use Jira to manage requirements, changes, and traceability under IEC sixty two thirty four three zero four. If you haven't heard already, that's kind of like the golden standard for a software development within medical device. So we'll discuss why it becomes more complex as development cycles get even faster in our ever changing world that we're in.

And we'll go ahead and also cover what changes when AI is a big part of your workflow and part of the product itself. Great. Now that we have a group on the line, let's cover a few housekeeping items before we jump in. First, we will send out the recording and the slides after the webinar. So no need to take screenshots or worry about missing anything.

Feel free to use these slides within your organization or teaching others. We really care about education here at Ketryx, and sixty three zero four is super important to get right if you're planning to do software development. Second, feel free to drop questions in the q a q and a at any time. So we'll keep an eye on them throughout the session. We actually have a whole team who are looking at it, trying to make sure that we, address them as they come up.

And finally, we'd appreciate your feedback through a short survey at the very end. So at Ketryx, we care a lot about continuous improvement. It's part of everything we do here. And your thoughts and your feedback are super, super important to us, whether that's ways that we could be better, but also how do we shape future sessions so that they're more in tune with what you wanna learn about. So please let us know what you'd like to see next here at Ketryx.

Alrighty. So I'll go ahead and do a quick intro for Ketryx. You're probably wondering who you are who we are if you have never heard of us before. So Ketryx is an AI native compliance platform purpose built for life sciences teams to deliver safer products faster. So we interoperate with your tooling across various teams across your organization and apply your quality management system rules across all of it.

So what that means is that you have a super integrated software that actually understands your quality management system, and it does it across all these other systems. So with that data, we can also automatically generate the compliance evidence you need and documentation you need to do your submissions. So you can get at the very bottom. We have FDA ready evidence that we can generate from Ketryx, having leveraged all these other systems like Jira, GitHub, you know, anything you already have. We also have AI agents.

Those can automatically trace requirements, assess change impacts, validate test coverage, and flag compliance risks in real time. I know I've spent a lot of time playing around with our AI agents to kinda, like, make a, you know, twin of myself, so, like, a compliance gen. And that allows me to kinda scale a little bit of, you know, what I do day to day. For quality teams, this means, you know, that you can do less manual chasing of evidence or, you know, simple questions and answers, and you have more confidence in audits or submissions whenever those come up. So they're really, really big events, and you wanna always be audit ready, submission ready at any time.

For r and d teams, the benefit is more time spent coding and spending time in your developer native tools. So, yeah, I guess I've talked a little bit about, you know, who I am. You know, I've kinda teased it a little bit there. This is where I'm coming from. So, hi, my name is Jen.

I here I work at Ketryx here. So I'm the director of AI quality and regulatory strategy. I actually have a history of working in the medical device world. And as I was there, you know, I was working with a lot of software developers at Omnition Neurotechnology, trying to get them to, you know, document their product, you know, in a compliant way, and make sure that they were able to generate all the necessary documentation for their submission needs. Right?

So getting it out into clinicians and patients' hands takes a lot of work, not just actually making the product. I'm also a licensed professional engineer in Ontario. So I'm actually Canadian. Hi, fellow Canadians out there on the webinar. And I actually started my career at Synaptive Medical, where we developed surgical brain robotics and MRIs, all focused on their neurosurgical speech.

So that's a lot about me and sort of where I'm coming from and why I'm so excited to talk about six thousand hundred thirty four today. And joining me is Gabriel. Gabriel, would you like to do a quick intro for yourself? Yeah. Awesome.

Thank you, Jen. Hey, everyone. I'm Gabriel Pasquale. I'm the head of product here at Ketryx. I started my career in research, in cybersecurity, developing safety critical systems at the MITRE Corporation.

I went on to spend some time at Amgen applying AI on the manufacturing side, and that's where I ran into this challenge of developing validated software and validated AI and how hard it is to do in environments, where the tools, I would say, as Jen described it, pull you away from the places where you're doing your work, of building the product or the the software. I spent the last two and a half years here at Ketryx helping organizations implement Ketryx and see the value of of maturing the software life cycle and the tooling and process required to do that. So why are we here? How did we get here? So this chart shows how AI enabled medical device approvals over time, has been changing.

So it's just trending. It's going up and up and up. So approvals are accelerating as regulators grow more comfortable with AI, and we kinda understand a bit better about how it performs, what are the risks, what are the challenges, and products increasingly become more software driven. So what is not scaled, though, at the same pace is how that software is built, validated, and sustained over time. Right?

So we're still applying the same sort of principles of sixty three zero four, but now we're trying to do it even faster. As AI moves into the product itself, complexity just keeps rising. Right? So we have so many more microservices, ways all of our systems are connected, and AI is now adding this probabilistic nature to it as well. Right?

It's not as deterministic as our other systems. And as models evolve and change over time, those systems become connected. There's ripples around, you know, data bias. There's code that needs to be rewritten tests. Risks all come up.

And so for teams that have not yet shipped an AI enabled medical device, this can feel pretty daunting or even unachievable. Right? As soon as you write something down, it feels like it's out of date. So for teams that have already put an AI enabled device in the market, that becomes kind of a maintenance problem. Right?

Keeping it updated, compliant, and safe over time. We know that when it comes to AI models especially, just because it is safe when you maybe first made it and you work on, like, your revision two, revision three, you actually kind of need to keep that up to date to make it continuously safe. So many med tech teams are still relying on those traditional development workflows, those quality workflows that we kind of came up with when the standard first came out that weren't necessarily designed for AI. All these processes are often, you know, manual, fragmented, or they're moving at the speed of something that we would have come up with several years ago, not so much AI today. So a quick overview of, you know, what we plan to cover today.

So Jira is one of the most widely used development tools in the world. I think they're they're so big, and I think they're building on new headquarters now in Sydney. So really wonderful product that's matured significantly over the past couple of years. So it's really familiar for most developers. Most developers have experience working in it, And a lot of medical device teams, even some hardware ones, are using Jira as well.

In this session, we'll start by grounding everyone in what IEC sixty three zero four actually is and what it requires in practice, beyond the standard itself. Right? Like, the standard will say one thing, but how you actually do it can be a bit challenging to interpret, especially in regulated environments. We'll then talk about how this challenge becomes more pronounced when AI is part of the workflow. Workflow.

So what is that additional ten, twenty, maybe even fifty percent that makes it even harder? Finally, we'll walk through a practical blueprint of how to deliver six two three zero four compliant releases in Jira at a modern engineering speed, so as fast as your developers can develop, including a walkthrough of the Ketryx platform itself and how that extends a lot of the Jira regulated development workflows. We'll leave some time for questions at the end. But of course, please feel free to drop them into the chat or sorry, into the q and a throughout the webinar, and we'll try to address them as they come up. So before we go deeper, we'd love to get a quick sense of where this group is starting from.

So one of the biggest variables we see across teams is how deeply Jira is embedded in day to day development, especially in regulated environments. So if you all can just please take a moment and answer this poll, to what extent is your team using Jira today? So if you can just take a moment and answer this poll, your responses will help us understand sort of the range of setups in the room and help shape examples and answers as we go along. So if you take a look at this chart, this is kind of like what you get when you start off with IEC sixty three or four. And this is how they describe it, right?

If you read the standard, they're like, Okay, planning, requirements, design, implementation, these are the main phases they talk about. So it all starts with planning. Now, you know, when you think about planning, think about sprint planning. Right? That's kinda like your first time you're planning a new software increment.

This is where the team is understanding the use cases that they're looking to build. So in six, two, three, or four, believe it or not, they don't say that you have to do sprint planning, but they do say you got to plan your software before you build it. Oh, hey. So you might accidentally build the wrong thing. From there, you'll want to do some requirements analysis.

So you want to figure out what exactly you need to build from a requirements standpoint. Like, does it have to do this? Is this a nice to have? That sort of thing. This is where you might start adding requirements in Jira.

So think about maybe you don't call it a requirement, but you might call it a story. Right? This is I need this thing, and I want to make it. From there, you hand it off to your super smart developer who's like, yes. I'm an engineer.

I'm an architect, and I know how to transform this need into some level of implementation design. And that's where the architectural design comes from. So how do you build a system to achieve the requirements that you set? And then detailed design. This is where all the fun stuff happens.

Or rather, this is the in my experience, this is one of the harder parts to put together with a developer because they have the like, great idea of how this is going to be implemented. Some parts maybe not fully fleshed out. And one of the toughest things to meet with IE sixty three zero four is that they ask you to have a detailed design. And sometimes developers, they don't have that all figured out straight away. And once they do, sometimes they don't wanna write that down because it's almost like duplicative.

Right? Like, they already coded it all out and, like, why should you write it down an extra time? This is where I think potentially you see a lot of gains with machine learning. Right? Because it can kinda read what you wrote and maybe get that first draft of a detailed design together.

I'm kinda getting ahead of myself here, but I think this is one of the parts I'm most excited by because getting this detailed design always took so much effort, in my previous work experience. So once you have a detailed design, you also need to then look at your software units, your implementation, and how you're planning to verify it. Right? So you've gone through all this effort of architecting all these units out. Now remember, we're working in software, so a lot of this is very abstract.

Think about it, you if you're making, like, a a robotic arm, you might, know, have the arm. You might have the base. You might have the wheels. This is kind of like a analogy to that. So you have all these units.

Maybe they're microservices. You have them all architected out. And now that you've called out those units, you now need to think about how do you verify them. So a big focus in IE sixty sixty three zero four, I know I'm saying that a lot, is that you need to verify the underlying units themselves, not just the high level system. So this is where you'll work on things like producing a software build materials.

And if you have any critical soup or software of unknown providence or off the shelf software, you might need to do some additional verification for those units if they're super critical to your architecture. Now, once you have all those units, you gotta do the fun part of integration testing. This is where the QA team or a really strong QA team becomes super, super important. Understanding how they all come together, those contracts, making sure they play well together, that they are integrated, that's something that you also need to do in IEC six IEC sixty three zero four. This is where you'll need a requirements traceability matrix.

Right? So, that's an artifact you need to produce. You need to show that each of these units was tested, and you also need to show that, you know, your integration requirements were met and tested as well. System testing. So this is kind of like the highest level of testing you would do in a software system.

That's to make sure that, you know, not just at these unit levels or this integration level, you want to make sure that the users and how or I guess the consumers of the software system, make sure that it is tested to those needs as well. This is where things like maintenance, service, installation become a big focus as well, because you'll probably maintain at an overall system level. And lastly, validation and software releases. So depending on what type of system you're doing, you might need to do some sort of user validation or human factors or clinical validation or clinical testing. You'll want to do that at the system level or wherever that user interface is.

This should all culminate into a VNB test report. So your verification validation report should summarize everything you did to test whether this is exactly what you wanted to build and how you built it was the right way. So that's your VNB testing file. It's also where risk management becomes finalized, and that's where you look at not just the risks that you identified, but did those risk controls that you put in to mitigate those risks, did you test whether those are working as well? All of this culminates into a software release.

So at the end of the day, in IEC sixty three zero four, you get your software artifact, which is great. It could be a binary. It could be all sorts. You get your software artifact. You get a nice stack of release notes.

So, like, what did you change in that software, or what did you make in that software release? And then you also get all the documentation that comes with it. Right? So, did it, you know, pass your design transfer? We also would recommend, you know, making a note about any AIML systems that you're using and any needs for retraining, and also procedures for how to do post market surveillance with your product.

So this is a high level overview. I know I've talked a lot about, I e six sixty three zero four. I think what I'd really like to hear or hope, you know, everyone who's watching, hope you see is that a lot of these things are actually things that you can do in an agile way. It just comes down to, can you break these down into the smallest sections that they can be so that you can deliver them every sprint or every release cycle? Okay.

Alrighty. So how has software development changed since IEC sixty three or four, was released? So, you know, it was released in two thousand six. If you put yourself in your, you know, two thousand six shoes, there were a lot of other things going on at the time. You know, we were just getting a bit more maturity with the Internet.

Software wasn't releasing as quickly. I recall, you know, in the two thousands, we were still manually downloading updates sometimes, and you'd get an update every couple of months. Now when it comes to even something like Windows eleven, right, you're getting updates every day, it seems. You're always restarting your computer for that sort of thing. So think about how, you know, back then, everything was a bit more deterministic.

It wasn't quite as fast. You had a lot more waterfall documentation, when it came to when things were made. You typically had teams colocated. So they were also centralized into one area. They might be working in the same room, and again, infrequent, planned releases.

Now you're seeing weekly or daily releases, so distributed across different systems and microservices. Also, regions. So some countries might get an update for something and others might not. You also see AI embedded in products, which is another dependency that also gets its own updates. So it's a lot faster.

And here is why the old playbook doesn't work. So because of that shift, the old playbook starts to break down because requirements change more frequently, risk grows as the dependencies between systems increase. Ai increases both development velocity and variability. So think of you know, you're making the engine go faster, but the a the engine itself is getting less and less deterministic. So the gears are becoming more and more floaty.

I maybe haven't think about cars too much on that one. So quality and development work also now spans even more tools than ever. So, you know, if you think about your average developer today, they're probably using ten plus tools. And, of course, documentation, you know, more recently, we haven't really had a lot of big upgrades to the documentation. LM certainly help with the generative aspect, but that doesn't necessarily mean that you're doing less documentation overall.

Right? Like, we still have so many documents we need to submit to the FDA. And so, you know, it becomes a real challenge. It's it's really hard to get this to keep up. So the result is that, you know, what many teams experience today, a lot of teams have to manually copy and paste between tools like Jira, just to stay compliant.

I've seen lots of Confluence pages that are copied and pasted or PDF printouts that are inserted into other PDFs of document files. Traceability and evidence, you know, can live outside of developer workflows, and they get out of sync with what the reality is in the code base. And despite this modern tooling, a lot of teams just feel like they can't show fast enough or as fast as they think that they can. And that's, you know, one of the reasons why we wanted to talk about this today. Right?

So we we talked about how the old validation playbook no longer cleanly maps to how software built is built today. So for most teams, Jira is kind of like the operational backbone for development. So it captures requirements in some form. So the strengths, of course, is, like, you know, it's built for project management. It empowers agile development.

It supports, you know, backlog, sprints. You know, it's been a while since I configured a Jira scrum board, but there's just so many options now and so many different ways you can do it. You can run so many metrics. I think that's always been one of the most exciting things for me. Like all the numbers you can get of, like, how quickly we're actually moving.

It's familiar to developers. So when you work at one company and you go to another one, there's less friction and less onboarding you need to do. Highly customizable. It allows teams to adapt workflows. You can add new stages, everything you need depending on what your organization is looking for.

Super flexible, and it represents AI work pretty decently. Right? So you can attach models, experiments. You can link your PRs if you're working in a machine learning specific code base, but there are some limits. Right?

So Jira does not provide immutable records or electronic signatures out the box. So when I say electronic signatures, I'm referring to part eleven clients. Right? So that that additional requirement we need to have for a lot of health records in the United States. It doesn't provide immutable records, so most people can edit any ticket they like.

So that means that your source of truth becomes everyone's mixed source of truth, which is not what you're looking for, right, in medical device. And those are really fundamental in in, regulated environments. So traceability across systems is largely manual, so Jira can link to other tools. It's actually not too bad at that. When you buy a lot of, like, new software, sometimes it doesn't have, like, the linking.

But Jira has built a lot of maturity around that. However, it doesn't necessarily enforce completeness or correctness at scale. So, you know, for example, with Jira, you have bidirectional links, that, you know, if you change one, it changes the other. There's a lot of little things around the linkage links that can sometimes be hard to maintain. I've seen lots of people try to maintain, like, you know, a field to a link to another URL to another system, and very quickly, it can fall out of compliance.

It's difficult to enforce control across the total product life cycle. Right? So if you have any parts of your product life cycle that aren't utilized, aren't using Jira specifically, for example, you might use a service ticket software to manage service records. And if you're not using Jira for service management, that means that a lot of your service records are now outside of the space that you thought was once, like, regulated. So just keep in mind, like, Jira does development well.

But if you're using other systems as well to support other lifecycle stages, like maintenance or service, it might not be enough for what you're looking for. And because Jira is non product software, it also must be validated. Right? So if you're pointing to Jira as kind of like your validated requirements management system, you also need to make sure that you've done the additional effort to validate it for that use. Right?

If you buy Jira today, it's not gonna say, hey. This is, you know, an IEC sixty three zero four software that, you know, is intended to be used in this way, you can manage all medical device development in it. It's a generic platform. Right? So you as a manufacturer have the burden to prove that you have validated this system for your team, for your use.

It all goes back to the intended use in the quality and regulatory world. So there's no built in enforcement for AI specific traceability or data governance. So when AI becomes critical around, you know, where did the data come from, are you using it correctly, There aren't necessarily additional features we've seen so far with Jira that addresses those use cases. So the takeaway is that Jira is a wonderful tool. We love Jira, but it's not necessarily, the best tool to do all of these different things.

So Jira was designed for speed and flexibility, and we love it for that, but not necessarily regulated control. And that's why it works best as a foundation for six two three zero four, but not everything, not to cover every single element of six two three zero four. So before we move into the specific sixty two three zero four stages, we just wanna hear about, you know, what are your biggest challenges when you're using Jira in a regulated development environment? So we talked about how Jira fits into modern development and where the friction tends to be. I'd like to hear from all of you.

So if you could just quickly take a moment, you know, what are your biggest challenges in Jira in a regulated development environment? I think, you know, certainly one of my biggest challenges for Jira in a regulated development environment is just like, what is, you know, what is the current state of anything? And, like because it's it's so easy to, like, make new tickets. Right? I'm always like, oh, how do I, like, figure out, like, is this the ticket that we're gonna use for this release?

Or, like, how do I combine these three tickets together? I find that Jira is really great at capturing, like, work in progress work, but figuring out how to filter out, like, what is the final work has always been a challenge. Yeah. And even for the most advanced teams that we see come to Ketryx eventually adopt Ketryx, they run into key issues around configuration management version control and particularly when they're trying to manage multiple independent subsystems. So, yes, you can, you know, you can script your way and plug in your way into a system that can get you to that sort of single system release.

But the moment you start to break up and you wanna release independent subsystems, a lot of those other challenging use cases, especially those that are required for developing AI today, that's when you really really reach the limits. Alrighty. Thank you all for your results. We're gonna go ahead and keep moving on here. So we'll quickly talk about, you know, how we've tried to make Jira compliant by design.

So what we've looked at is you know, our philosophy is not to replace Jira. I think I've kind of made that clear. It's like, we really love it for what it does. It contains the work, the decisions, the context that teams rely on, and context is super key for any software development work. The challenge is that it lacks the controls required for compliance and the the controls that the FDA would like to see you have, right, to make sure you're developing software in a very safe way.

That framework creates, so this framework that we've developed, developed is that we focus on things like immutability for record for each item and controlling the relationships between those items. So we control the states, the relationships, the traceability, and we enforce your quality system rules directly into the workflow. So items and records can only be moved between states when predefined rules based conditions are met. That way, compliance is enforced by the system itself, not by manual checks or after the fact documentation. So from a tooling perspective, right, you might have all these different tools.

So these are you know, we we talked to a lot of folks in the industry of, like, what they're using. I'm really excited to see there's a couple of new ones here I've I've actually never experienced before. I've, you know, I come from, like, maybe a different era. So when teams are looking to move faster in Jira, there's a lot of good tools available to get them started. Many teams, you know, as I said, they add plug ins.

Right? Some focus on requirements. Those plug ins might be focused on documentation. Plug ins, like, for example, X-ray focused on testing, and they're really useful for different reasons. What we often see is that teams gradually assemble a set of tools based on where the bottlenecks are.

So maybe you move into, like, q three, and suddenly q three is, like, a big focus on testing. And then you're like, well, we need a testing tool. So you get a testing tool in there. So it's usually like a patchwork of, like, Band Aids of, like, where are we feeling the bottlenecks? Okay.

Great. How do we get a tool to solve that? As teams mature, they actually might wanna automate more, and they might find that this patchwork doesn't quite work the way that they thought that it would because, you know, you'll start to see, like, pressure testing occur across all these different tools. So they might start adding custom workflows or automation rules to sort of deal with some of that complexity. That can be very effective early on, but it gets harder and harder to manage as time goes on.

And as I mentioned, you know, folks that come and go, you might lose the person who maybe maintain those tools and those rules over time. Even teams that are already you know, they already have a life cycle management solution, they tend to connect it to their preferred tools like Jira, GitHub, and CI systems. So that's one thing you need to keep in mind is that you might, in the end, just end up connecting it all. That gives, visibility, of course, into across multiple systems. What this slide is really showing is that the spectrum of approaches teams can take, you know, with SDLC SDLC tools, so software development life cycle tools.

You know, there's all sorts of different permutations and configurations that might work best for your organization. You can start filling those gaps with things like plugins. There's lots of plugins, you know, in the Atlassian workspace, and many two teams do exactly that. One thing we'd like to show you is just how you can do that within Catchrix and sort of like the the typical things that you would try to resolve or try to address with IEC sixty three zero four. How would you demonstrate that with the tools themselves?

So Ketryx is just one way to do that in an integrated way. But regardless of the path you choose, the key idea is the same, letting developers stay in their preferred tools while progressively automating more and more so that your life cycle teams can move faster with confidence. So I'll leave it at that. Gabriel, I'm really excited for you to show us what you have here for the demo. Gabriel, I feel like, you know, you're kind of like an honorary quality and regulatory person at this point.

I feel like you know the standard in and out, and I'll let you lead from here on out. Thanks, Jen. I appreciate the the compliment. That's a high high regards. Alright.

So let's jump into the demonstration portion of the webinar. And before we do that, I'll go through a few slides that talk through how teams today with without Ketryx typically, implement a six two three zero four workflow, within Jira. So we'll go through a few of these parallel slides talking about the sections of six two three zero four and how they're accomplished, and then we'll jump in the platform to see how we do it within Ketryx. So as we jump into section five, we talk about the software development process, and documenting aspects of your design, your process, testing, and so on. This really comes down to using core Jira features, like stories or other custom issue types to maintain aspects or the configuration items in six two three zero four speak, leveraging plug ins, and platforms like Confluence to produce the actual documents that that compose your DHF, and then leveraging different plugins, Requirements Yogi, R4J, along with a number of other plugins that are specialized for testing.

Now, typically, where this approach we find breaks down is it's a lot of manual configuration, a lot of plugins to manage. Collecting signatures can be a challenge, and maintaining overall control of the platform, particularly as you're developing AI systems, AI systems that require speed in development, and oftentimes complex system architectures. Now a bigger, you know, challenge outside of documenting specific requirements often comes down to traceability. So traceability, not only from requirements to tests and risk controls, but traceability across other parts of your life cycle, including cybersecurity, risk management, change management. Typically, this is is managed in in Jira without Ketryx is the use of links.

So the native Jira links, the use of tables in Confluence, or using plug ins. Many of the challenges that that I've seen from teams that are using these approaches typically come down to the mutability of traceability with these approaches. So trace links that get corrupted or changed. And the biggest thing is there's always other systems. We're always gonna add in an an additional system where evidence will live that we need to provide traceability to, whether that's to a a data store for your machine learning model, to an automated testing system for verification, or or many other systems that are involved in a complex life cycle like that which is required to develop an AI system.

Now the third and final slide before we jump into the platform is around software maintenance. It's one thing to go through the process of of developing and documenting your device the first time. But particularly for AI devices whose life cycle moves quite rapidly, given the the benefit of an AI system is the ability for us to expand the dataset and improve the functionality of our product without complicated code changes or those types of changes that are typical in traditional software. And the maintenance process is where a lot of this breaks down because we're needing to do rapid changes and maintain all of the documentation traceability alongside the development work. Now, what teams will do is is typically integrate tools like a tool for collecting product feedback into Jira.

They'll create custom dashboards for monitoring the process, and they'll leverage a lot of custom automation for supporting the change management process within Jira. And like I said before, once we start to talk about this maintenance phase where your team might want to move from or need to move from a yearly or quarterly release cycle down to a monthly or weekly release cycle. Now let's talk about, all of these concepts in the context of Ketryx. And we'll actually start with software maintenance, and then we'll touch on section five as well as traceability. So when you first go into Ketryx, into a project, we're working on a project called insulin delivery, which is an insulin delivery system that we're building using Ketryx.

You'll be met with the all items dashboard. The all items dashboard, as you can see, is all of the various tasks, requirements, risks, change requests, anomalies, any of the configuration items in the six two three zero four sense that we're managing across many different systems. In this case, this particular project is connected to Jira as well as a code repository in GitHub. So if I filter the source here, we'll actually see a number of items that are also coming from my Git repository. On the right, you'll see an AI assistant.

So the Ketryx AI assistant is at your side to help you analyze and drive change, as well as help you understand the process and what's necessary to ship a compliant change. I've actually gone ahead and executed a change impact analysis on one of the changes that is live and in process for this particular product, which is this top change request which lives over in Jira. Now if I scroll up to the top of this assistant conversation, we'll see that the assistant has gone through and analyzed this Jira ticket, which is a a change request in this case. It's gone through and understood the context of my product, the context of my quality management system, as well as the context of the change that I want to initiate through through coordination in Jira as well as in Ketryx. It's gone through and executed a change impact assessment, which understands my particular quality management system rules and how this particular change needs to flow through my process.

Now before we dig into this change impact assessment, let's go into Jira and talk a little bit about Jira integration and how we help teams spend more time in Jira while automating the collection of evidence from that system. I'll open up this Jira ticket, k d one four zero, which is a change request. And what this will do is it'll bring me directly into Jira, where the team is spending most of their time during their development work, and we'll see some familiar fields. We'll also see some fields that has automatically configured. So Ketryx will configure Jira, if you choose, to use six two three zero four compliant fields and issue types.

We can also map on to your existing configuration if you wanna move forward with how you are currently developing in Jira today. As you scroll down, you'll see two different widgets. The first is an approvals widget. So this allows you to do your reviews and approvals without leaving Jira, including both click through approvals as well as your part eleven compliant esign using a biometric or MFA token. The second is this traceability widget.

And the traceability widget is an easy way to understand how the particular item that we're working on, in this case, a change request, relates to other items in Jira, as well as outside of Jira. We're looking at a change request that affects two software specifications, but it could also affect, and and likely will before we ship this change, an automated test that's documented in the source code. With Ketryx, we can link this change request directly to that automated test that also lives in the source code. Now, as we scroll back up, we'll go ahead and and make an update to this particular change request. And I'll just enter down here a few times and add an update during webinar to this change just to show that we've we can make a change and and Ketryx will will capture this in its audit trail.

Now if I want to approve this change request, I can leverage the existing workflows within Jira, move this into a resolved or or ready for review status, which will then send notifications to the my team to come and approve this change request. I'll go ahead and approve this as owner. And as I'm a super user in this particular demo, it will allow me to count all of my approvals for this particular item. Now what you'll see happened is once Ketryx detected that all the necessary approvals have been collected for this change request, it moved it into a closed state, and it created a new record, controlled record of this change request. Now if I go to this record, record number nine in Ketryx, what we'll see is a view in Ketryx containing the description, my approval, and importantly, a complete history of all the changes that have been made to that ticket in Jira.

This allows us to easily understand and have an honorable history of each item that we're maintaining in Jira and easily understand the changes that have been made between different versions. So as you can see, we moved this from a resolve to a closed state. And if I go back one more change in the past, you'll see that a green line has been highlighted showing that change that we made just now. Now it's very important to understand the change of specific items across versions, but Katriks could also help you look at more of a global scale around how changes are evolving across versions of your product that you're deploying. So if we go back to the all items screen and I compare versions, in this case, I'm comparing a previously review released version one point one to a patch release that we're working on version one point one point two.

And in the all items screen, you'll see this diff column, which highlights the items that have changed, the items that are new, and those that are obsolete or removed from the release. This means I can go down and filter for my requirements that are new or changed that happen to be risk controls. So we can use all of this rich context that we're collecting from the relations in Jira as well as the content and types in Jira in order to have a clear picture around the changes that are moving between one release to another. Pair that with the AI assistant that can help you analyze and understand the changes that you need to make, and we allow your team to execute change workflows using AI, using your preferred tools like Jira and GitHub, all while capturing that evidence into documents, which we'll show next. So when I wanna move towards the release process, so I'm doing my maintenance on my product, I've created my new feature, I can go into my releases area, into the particular patch release that we're working on.

And what we'll see is a complete view of all of the changes that are going into this particular release along with a configurable release checklist that encodes our quality management system and the rules of our release process into controls that are enforced by Ketryx. This allows you to minimize the amount of time you're spending reading SOPs or or asking for someone's guidance and letting Ketryx guide you through the process as you release your product. Now going to the documents area, we can see that we have a list of generated documents associated with this release. I can click generate documents, and this will go ahead and pull the latest controlled record, which could have come from Jira in the case of our change request or requirements or from any other system that's connected to Ketryx. Once all of our documents are are generated, we can go ahead and download to view that document.

In this case, I just have our our standard templates for a multi region deployment of a device. But we can take your particular templates and template, our templating language, which allows you to pull any information from the various systems into your format. So that particular logo in the top right will will match the margin. What you'll see is in this document, pulled in a table of context contents, including all the requirements, along with specific requirements information from the various systems where these requirements are maintained. Now, includes not just Word documents, but also, Excel documents, which brings us to the traceability matrix.

Now, I'll first download the traceability Excel file, and then we'll go into the Ketryx UI, which has a number of other helpful features helping your team maintain traceability and improve traceability as you're developing. Before we do that, here's the final artifact, which is items as well as their relations extracted from the systems where they're maintained and then placed into an Excel table format as you prefer, matching your process and templates. Now, typically, when we're building our traceability, we're not gonna refer to a generated report. We'll refer to our traceability matrix within Ketryx that updates live as work is being done across systems. So if I go to the traceability module here, we'll be met met with a traceability matrix.

And this is a set of configured columns and configured relationships between those columns that allows us to control and enforce a requirements model within our documentation. So you can see here on the left, we have a set of use cases and design inputs that come from Jira that trace down to design outputs, which are, in this case, spec software specifications that live in Jira, as well as some specifications that live directly in the source code as code annotations. Tracing down to our tests, these tests could be automated tests. These tests could be within the X-ray test management plugin in Jira, or any type of issue issue type that you configure in Jira. And then finally, we'll see that we've also configured an additional column to track defects as well as testing that's being done against those defects.

But this traceability matrix can be configured for many different views. We may wanna view on cyber risk. We may wanna view on soup validation or a view that takes up approach of starting with our safety risk analysis flowing through to those items that control those risks. Now, at any point in this process, we may want to leverage one of two features that leverage AI within our product development process. One is always referring back to our our AI assistant.

This allows us to do analysis on a number of different things that can accelerate the change management process. Now if we return to the change of act assessment that we did previously on the change request, that's centered in this demo, we'll see that the first step of this particular workflow has been identifying impacted requirements. So each of these requirements that's listed here has been identified by the AI as being affected and potentially needing to update or retest due to the change. In addition to identifying which requirements are impacted, we'll also see that the agent has suggested updates to particular requirements or new requirements that need to be drafted. In this case, fortunately, it's a small change, and we don't have any.

Finally, this particular workflow that we've configured for this product also has a step where it creates a retest plan, which requirements need to be retested, which software items need to be retested, and so on. And then finally, for this particular agent workflow, it's not just about understanding what's impacted, but also what's not impacted and providing a justification for why those aspects of the system aren't impacted and therefore may not require testing. The goal of these agent assisted or agent driven change impact assessment and other types of analyses is to give your team a head start on the particular steps of the process that they need to execute. We see teams getting to a ninety percent draft of their particular change plan, in one or two hours of the agent running on their information. This allows a systems engineer, a quality lead, to take this as a draft and then review, identify additional or oftentimes, what we found is that these types of agent assisted change plans drafting workflows identify requirements that were previously missed by human teams.

So we truly believe that this agent human teaming approach to change impact assessment will have improvements towards quality, not to mention helping your team move faster through the change management process. So now that we've talked about, maintenance, section five, traceability, let's go back and cover two more slides focused on risk management, as well as soup management, before we finish out the demo. Going back to the slides, we'll see a a section, section seven, focused on risk management. Now risk management is, in some ways, very special because it has a a process around it, has a state machine around it that is typically very hard to model using Jira. That being said, teams, we still find using custom issue types in Jira.

We see plugins or oftentimes external Excel sheets in order to manage the risk management process. Where this breaks down is typically everything centers around risk management. You change a requirement, a test, and it impacts a risk. All of a sudden, you need to go back through that process and understand traceability and downstream impact. So having risk in a system where you can maintain automated traceability and you can leverage AI for the analysis and helping the human understand the impact of change is is critical.

Late discovery of issues relevant to traceability, testing, requirements, and risk controls can, as you know, set your project back significantly. The second area which is tied to to risk management is around soup management. And this is an area that we've focused heavily on, which allows teams to streamline the way that they're managing soup, their SBOM, and any vulnerabilities that have been reported against your software supply chain. Now teams will typically manage the soup process, SBOM and vulnerabilities, using a set of external tools, Excel sheets, as well as custom issue types in in Jira. Now, as you probably know, this can be a significant challenge because unlike requirements, unlike risks, the number of vulnerabilities, the number of dependencies is almost unmanageable in the number of these items that you typically have to maintain, filter, triage, disposition, and document.

So having a way to manage this information effectively, not only in the pre market as you determine what are the most secure soup and SBOM components to use within your product, but as well as in the post market. Once your product is out there and accessible to attackers, and therefore you have requirements to maintain and document and remediate post market vulnerabilities, what does it, what does your process look like, and what does your tooling look like to support this workflow that right now is is frankly overwhelming teams in their ability to keep up with the documentation? So let's jump in back to Ketryx. We'll look at risk management and then touch on soup management and SBOM. When we go back into Ketryx, we'll see this risks module.

And the risks module allows us to understand and track particular risk records for our product. You'll see a standard ISO one four nine seven one layout, although each of these fields is configurable to your process. And as we scroll to the right, we'll see a set of configured risk matrices for doing our risk analysis. We'll see a set of risk control measures. These risk control measures are just other items from systems where your team is working.

In this case, we have four different risk control measures you can see here, each of which is a Jira item along with traced test cases that are verifying this particular risk control measure. Ketryx has a number of controls that can be enforced in in your process. One of the most used and most critical controls within the platform is enforcing that all of your risk control measures are tested before release. This allows you to move faster, move with higher quality, and not be not have the risk or the the anxiety that you're gonna miss a step of your process. This particular scheme here can be configured to different types of risk.

In this case, we've configured risks to also document cyber risks. But you could imagine doing additional risk formats and additional risk schemas to con to configure and support other types of processes. Now the other component which we talked about in the slides was a suit management in your SBOM. Ketryx, when it connects to code repositories where you host your application, will automatically index the dependencies that are used by your application. We can also ingest SPDX or a cyclone d x file if you use an existing SBOM or software composition analysis tool in your life cycle.

Once Ketryx collects all of these dependencies, we'll scan and provide a list of vulnerabilities that need to be remediated, such as those from the CDE database and so on. Now, each of these dependencies allows you to document the necessary information based upon guidances from FDA, such as the level of support, end of life date, as well as other of the attributes from the NTAA guidance, the baseline attributes. Each of these SBOM components will also have a set of vulnerabilities that have been reported, as I mentioned before. And Ketryx allows you to execute a vulnerability, impact assessment process based upon real time data collected from various vulnerability databases. And after all of that, produce a, report, including the human readable and machine readable SBOMs along with the necessary vulnerability reports that you'll need to produce as a part of your software development life cycle.

Now this is a whirlwind tour of the Ketryx platform all the way from how we integrate into Jira and allow you to extract information from Jira that support compliance along with traceability, generate documents from this information into Word and Excel documents, manage and enforce traceability through the process, and wrap that all together with comprehensive end to end risk management and management of cybersecurity related information like your SBOM and vulnerabilities. All of this at your side has the Ketryx assistant, which can access this information, and with your review and approval, modify the information, enabling you to automate many of the aspects of the compliance process that typically are manual, managed by large teams of individuals who could spend their time on high value focused work centered around risk, product development, rather than on manually maintaining traceability or documentation. Now that wraps up the the demo here today, and we'll have a member of the team live here shortly to answer questions. Thank you so much. Hello.

Good afternoon, everyone, or good morning, depending on where you're calling in from. My name is William. I'm a solutions engineer on the Ketryx team here to answer any questions that may come up live as we're moving through the the call here. I saw there's a number of q and a in the chat, so we'll be able to go through all of those. And as more questions come up, please feel free to drop them in the chat, and we'll cover them during the next ten minutes or so of the webinar.

But wonderful. To get started, I think what we can do is just go through, like I mentioned, those questions that came in at the start, just starting from the order in which they arrived. So I'll go ahead and actually share my screen here, and we'll move through what it looks like to see this in action in Ketryx. So the first question we were asked was, how does the approval process in Ketryx align with ISO twenty seven thousand one? So in order to kinda get started in answering that, I'll just go through the approval process so we can talk to how it maps to some of those principles and, you know, more what the approval process looks like at a more granular level.

So right now, we're in the Captrix platform as Gabriel was walking through previously, looking at a number of different projects. I'll click into the insulin delivery system and then click into this particular requirement that's being leveraged or managed in Jira. What we're looking at here within Jira is, again, that requirement that's currently in a controlled and already approved state. If I move this, though, from closed to reopened and take it out of that immutable state, we can now draft some changes. So maybe I'll add demo for May twenty eighth to this requirement here and then move it to resolved.

And that's what will ultimately kick off the approval process. So the way the approval process works is that once it moves to that state, all of these user groups like r and d leads, quality managers, and product managers will be notified to come in and sign off on this particular requirement with their twenty one CFR par eleven compliance signature. So, again, if I just click approve as owner, my signature will account for everyone because this is just a demo environment. But, again, this aspect of role based access control, you know, restricting certain users to only be able to approve and sign off on certain items is really how Ketryx starts to maintain compliance and adherence to twenty seven thousand one. On top of this as well, I'd say once we get back into the Ketryx platform itself and view how this signature has translated over, Ketryx keeps the full audit history of the signature and approval process.

So we have that immutable record of all the changes that took place where we have my signature at the bottom here. As I signed off for all of these user groups, we have a unique key associated with my signature there. And, of course, we can produce a document that reflects all of this information as well. If there's any questions again about that, please feel free to to drop them in the chat, and and we'll come back and answer those. Moving along here, the next question was, can an item be approved by a group or just one person?

I would say it depends. You can also you know, along with that group level approval, which we saw previously within Jira, where you define a user group of, you know, product managers and they can sign off on them. You can also route approvals to individual users within the platform. So it depends on how you wanna structure your CatchX application, and we can accommodate both ways of using groups and individual users for approvals. The next question is, how does an export of this record look like?

So Gabriel walked through this in the demo environment, but when it comes to producing export of all this information, what we walked through previously was, you know, a change made in in Jira that flowing back to Ketryx where we see that demo for May twenty seventh. And then if we navigate to the releases tab into the underlying version that we've been working on, Ketryx allows you to have these underlying document templates that are configurable to your organization. So as you're making those changes within Jira, all of that information of all of the changes will be pulled in to this document template after I click refresh. And once I go ahead and download this, we'll be able to see all those changes in the document format along with the fact that we had that signature appended to the requirement. The next question here is, can you walk through what change management looks like?

Yes. Absolutely. So in terms of change management and what that process looks like, there's a number of different ways we can coordinate change within the platform. In Gabriel's example, he walked through creating that change request item and leveraging AI to start that process off. So here, we'll take a very similar approach where I can actually access our AI assistant and give it a prompt like, please perform a change impact analysis for changing the dose suggestion to consider user age.

And what's gonna happen is it's actually gonna create a new change request item or change request or change order item for us that then lists out everything that's affected by this change, gonna give us a requirement, test case risk, and prompt that for us for approval before we wanna introduce this change into our system. So as our AI is thinking here and finding all the right items that are affected by this change, it's now gonna go through and draft that action for us. And here we are. So it suggested edits to accommodate that particular change to a requirement, a risk, and a test case. And now finally, it's also gonna draft an item that we can push to Jira to ultimately start coordinating that change and send the work off to the relevant parties.

So now if I actually go ahead and review this suggested item, Ketryx has created that change order for us, described the scope of this change, and also traced it to the items that we need to update in order to accommodate this. So, if I just click create item, that will create and push that change order to Jira to coordinate and get our team started on that work. The next question is, can I please ask whether or not your AI assistant is using a deterministic LLM, or is it using a raw generalized LLM? That's a great question. I'd say the answer is that Ketryx is under the hood using a non or, excuse me, a nondeterministic LLM.

We're leveraging Claude and ChatGPT under the hood while adhering and adding specific guardrails on to make it a bit more controlled. One of the guardrails, for instance, that we just saw is that human in loop approval. So only being able to introduce change that's suggested by the AI. The AI will never add things or make changes in your project without your explicit approval. Another aspect here of making it a bit more deterministic is that we have this generalized rule set within Ketryx where the AI will make suggestions and you ultimately have to approve them.

But Ketryx can still enforce things like deterministic traceability checks. So if the AI suggests, for instance, a new requirement, you can always make sure with these deterministic checks that it is in fact covered by things like a test case or a specification. So, again, the actual AI assistant is nondeterministic itself, but Ketryx as a whole has these deterministic checks embedded within the platform to give you further guardrails in that regard. Next question. How difficult is it to import existing items that are in Excel slash Word to Ketryx like risk?

I'd say it's quite straightforward to do that. I don't have it configured in this demo environment, but one of the things that Ketryx actually has is a CSV import functionality where similar to the export button you see here, there's actually an import button that allows you to import CSV or Excel files directly to our system. And that will break everything up into that itemized approach that you're seeing here with the set of risk items with all of their relevant data. So I'd say it's quite straightforward to be able to bring that information to Ketryx. What's the next question?

Does Ketryx have documentation available to help with validation of Ketryx as a non product software tool? Absolutely. We do have that validation evidence. So Ketryx itself is UL certified to six two three zero four thirteen four eight five and fourteen nine seven one. And we actually produce a, you know, existing design history like set of documentation for all of our releases and can provide that to you in order to support your efforts in validating metrics for non product software.

Wonderful. If there's any other questions, I think we're nearing the end here with about a minute left. I'll take a few more in the chat, but we'll just keep moving along. Should I okay. Perfect.

I think we're at time, but, you know, appreciate all the questions, everyone. If there's questions we didn't get to that, for some reason, got lost in all of the traffic, happy to take that to an offline discussion or or can follow-up via email. But thank you so much for for joining this webinar, everyone, and I'll sign off for now.