Secrets from the Best Software Companies — What Can Medtech Learn to Build FDA-Read... | LSI USA '25

Maria Gomez  0:05  
Um, so we're going to be going over secrets from top software companies from other industries that Medtech can apply. My name is Maria. 

Martin Zuniga  0:17  
My name is Martin, 

Maria Gomez  0:18  
and we're with Hattrick. So Hattrick specializes in building software solutions to help Medtech companies improve patient outcomes. We've been around for 10 years, and not traditionally from Medtech. So we worked in various other industries, and have brought over the expertise from those industries to Medtech. So before we get started, maybe a quick show of hands to gage where some of you are at. Has anyone here already applied Agile to software development? Great. Has anybody gone through clinical trials before? Great. And do you have a QMS set up. Awesome. This should be easy. So we're going to be going over some of the software requirements from the FDA. We're going to be going over what is waterfall and what is waterfall and what is agile, as well as an introduction to me, Tir 45 we're gonna see what regulated agile looks like in action, and then we'll have a Q and A at the end, and I'll leave you with Martin, thank you.

Martin Zuniga  1:35  
Okay, so this is going to be just a brief intro of what it takes to build software for the FDA, just to get everyone up to speed. But it's going to be brief, I promise. So first of all, the key standards that shape software development for the FDA, as with other parts of medical device development, it's ISO 3045, for Quality Management System, and 14, 971, for risk management. So that's pretty straightforward, and something that is not exclusive to software, but you also have IEC 62, 304, which is the gold standard in terms of software life cycle management. And what it does is it defines a set of rules and ways to comply with the ISO standards to and in a way that applies to software. Ultimately, what the FDA requires is not exactly, for instance, IC 62, 304, but they do say that they recognize it as something that is widely used, and if you comply with it, you'll be good. If not, you can define other ways of defining your software life cycle. So in a summary, or in a nutshell, what the FDA expects when you write software, and this is put in terms of design controls. So your biggest input will be the software requirement specification, which is going to be a large file, or files indicating what your requirements are. And it might be clinical requirements, or they might be intended use requirements of how stakeholders are going to be using your software. It could be patients, physicians, or any other stakeholder using the software. The main outputs are going to be documented in the software design specification, and that is going to be the one that specifies how you comply with with those inputs and how you implemented them. So it's going to have architecture diagrams. It's going to define the different modules that you that you have in your in your software class diagrams and so forth, to show how you build that into your code base. Then risk management, of course, is really important. So hazard analysis and risk assessment has to be done throughout the entire process of building software. And for verification validation, we have software testing taking a very important part in verification. So you have unit test, integration tests and system tests, and those are just ways you test your software at the unit level and also at the integration where you test different integrations between components or system is when you test your software working as an entire unit. Traceability, of course, is very important. So you have to clearly document the links between requirements, the design outputs and the risks and the measures taken to mitigate them and other things that you have to comply with are, for example, you have to define what your software life cycle is. So that leads back to IC 62, 304, it can be, for instance, the FDA accepts that you show compliance with that standard. Or you can define your own software life cycle, but you have to define it. And you have to define how you're going to do the management of the software, for instance, how you're going to react to To fix this, all vulnerabilities that you need to address and so forth, and how you're going to support the users of the of the software. And in terms of cyber security, what you have to do is. Is it's become more stringent in the last couple of years, because the FDA is requiring a lot more than they used to. And what you basically need to do is apply threat modeling and vulnerability assessment to cybersecurity, or the cybersecurity aspects of of your solution. You already need to do a risk management plan, and you also need to do software security testing and documentation. So we need to document all this and also do, probably penetration testing, where someone outside your organization tries to to discover vulnerabilities in it, and you need to report those those findings, and, of course, address any liabilities that may arise. So this is just going to be a basic introduction about waterfall and agile. This has been covered a lot, very extensively throughout the years. So, but just to give a quick intro, waterfall usually is. What it does is it proposes sequential phases that are going to be very as they are sequential, you need to complete each of them as you advance through software development. And for instance, those might be an applied to medical device software. It might be requirements gathering, then designing the solution and and in pure waterfall, you will define all the aspects of the of the solution without writing, writing, sorry, one line of code, then you will go to implementation testing and then maintenance, and repeat this cycle with subsequent releases. This leads to a rigid structure and leads to late feedback and higher risk of changes or and costly changes, because you'll take a lot of time to be able to test something, it might be internal testing, or it might be if it's something that could be tested without submission to the FDA, it might be tested by the physician or the patient. You'll take a lot of time in getting to do that, and you'll also you need to imagine a lot of things in your solution without actually knowing what it's going to look like. So when you make a lot of assumptions, then when you actually build them, and you put it in your in your stakeholders hands, you'll notice that there was a lot of assumptions that you, that you made that are not correct. So agile counts as an alternative to this. This is not exclusive to medical software, of course, but and what you do is iterative cycles, where you do all the stages incrementally, and with every iteration, you get a functioning version of your software and and this leads to more frequent feedback and continuous improvement, and it's more adaptable to change. So one thing we wanted to say is that agile can be used for the FDA and for FDA compliant software. And one of the reasons why because there's an understanding, or there's like a myth, that it can't be used for for FDA regulated software, and we're confident that, or we're where we believe that it is. And first of all, the FDA explicitly says it in their content of pre market submission of device software functions, it says is that it even accepts other methodologies like spiral model, et cetera. So the FDA explicitly says that, and that's very important. The other thing is that we believe that agile can produce documentation that is structured and that covers everything that the FDA requires in terms of design controls. It is true that when agile first came to existence, it came as an alternative to waterfall, where documentation was very extensive, and the people that implemented agile wanted to do less documenting. But when you apply this to the medical device space, it doesn't mean that you don't document or that you don't document extensively. It's just that you plan it and do it in our way. And the other thing is that iterative cycles do align with something the FDA recommends, and it is that you continuously are assessing the risks and the status of your solution. So when you do it in a waterfall approach, you're not you, for example, let's say you do the risk assessment, and you're not always going to be reviewing it, but when you're doing Agile things, or things in an agile way, your every iteration, you are iterating on those risks, and you're updating your assumptions and the way you treat them. To give a brief intro about this, this we're going to be talking about am et ar 45 it's from the Association of the advancement of medical instrumentation, and it is a guideline that specifies and first of all, defines and validates that agile can be used for FDA regulated software or regulated software in the medical device space. And it also has a lot of contributions.

Martin Zuniga  9:57  
First of all, it says And it clearly states that. It's acceptable, and it's as when you have it as a guidance, it gives a lot of strength to the case of using agile, and it's not only individuals supporting it then you have that. It provides practical guidelines for actually doing it, and for continuous management, of risk management and documentation and so forth, and it also helps achieve this in a way that is compliant with the ISO standards that are required, ISO 3045, and ISO 14, 971, so it's a very important piece of documentation or guideline. What regulator looks in action? Well, it's going to look somewhat like this. It's going to have like, three different layers or levels in which you iterate. So at the top level, you have the project, and this is going to dictate the entire duration of your project. So let's say you're building a software for medical device. Then you're going to do some planning. At the beginning, you're going to define the software life cycle management plan, and you're going to define which features you want to toggle and so forth. And after you begin, and one thing about those, those features and requirements there, they don't need to be very clear at this stage. What we recommend is that when doing requirements at this stage. They are high level, and they are indications of what is going to be built later on. Of course, it is important to have a vision of what you're going to eventually try to build. It's not that we recommend doing it always changing it week by week, but it's not necessary that you have everything planned out before actually starting. Then each release is going to be a version of your software, and it's going to be a version that you, if you're regulated, it probably it's going to require a submission, and it's going to be every major release for for your project. Then the sprint is going to be like, like, it's a fine and agile. It's going to be the smallest time frame where the team actually collaborates on generating a piece of software and the documentation that is that is related to it. So at its sprint, you are going to be working on detailed things, because it is the at this stage, where you go, where you where you're going, sorry, to be working on what you'll eventually end up delivering to stakeholders and the FDA. So for instance, you might, you're going to be doing planning at this stage, because you're going to plan the sprint and and everybody's going to have different responsibilities to tackle. You're going to be working on software requirements. So the requirements that have not yet fully been described. I mentioned before that you might have talked high level requirements from previous stages, but at this moment, it's when you are going to be detailing how they are going to look like. It doesn't need to be final. You can always increment incrementally work on them. But at this stage, you're going to be working in a more detailed way that the same happens to architecture. You're going to be defining how you're going to implement that software and more aspects of the design of it, you're going to implement stuff developers are going to be implementing stuff you're going to be testing to or writing, for instance, unit tests, which are written in code. Or you're going to be doing also testing and manual testing, which can be system and integration tests, and it can be also automated tests. What does a spend look like? So just to get a sense of what this is, for instance, a typical team in a project that we work on. And it's just to give you an idea of what it could look like for a team to collaborate on a sprint. It could be the duration, could be between two or four weeks that what we recommend. And you could have, for instance, your developers working, of course, on implementing features, which is going to be the main task that they are going to be doing. But they it's not the only task that they do. They also write unit tests, for instance, for the code that they, that they write. It might be, for instance, a function. It might if it's an algorithm that performs some kind of calculation or prediction or diagnosis, it can be tests for testing that algorithm. So the developer will also be working on that, and it can also they will also be updating code related documentation. The QA specialist will be probably writing test protocols for the features that are going to be tackled. So let's say that we have a feature that is already defined and well the documents, the requirements have been well, well defined. Well, the QA specialist can start working on writing the test protocols, or even if, even if it's already implemented, they can also do this. Those two at this stage, and they can also execute while we iterate. They can execute manual and regression tests. This test the manual ones, and if it's going, if it's system test, for instance, they are probably not going to be the ones that we are going to submit to the FDA, because the software is evolving so but they will give us a clear sense of the status of the solution. It will help developers, because it's it always helps developers build better code when they have someone testing it. So it's in all, in all aspects, is it's a win for for the for the project and the team. Then you could have a QA automation engineer who could be developing and running automated tests. This is not mandatory and does not apply for all companies, but it's something we recommend, and we'll talk about that a bit later on. You could have your tech lead or architect drafting or updating the architecture, so you could have an initial draft of the architecture when you began at the project level, at the top, and when you start iterating, you introduce changes. And the person in charge of that is the tech lead and architect, and they might very well just update it and keep working on other things. And they will also be reviewing and guiding the technical implementations by the team. You could have a UX UI designer working on an aspect of your solution. For instance, you don't need to have the entire UX UI design drafted out when you start development. You could have the UX designer working on a feature that has not been drafted yet, and developers working on something where the details, where the requirements are detailed, and so forth. So that's one of the dynamic things that we love about this methodology. The project manager or someone else could be writing user stories for the backlog. Those might be new features that we're going to tackle in the future, or it could be drafting detailed requirements of features that we are going to tackle right now, and quality regulatory will be, or might be, reviewing the team's work and giving feedback and making sure that everything is is up to date with all that we need to comply with. Here we wanted to leave you with a couple of tips that you hopefully can incorporate to your projects. These are some of the things that we learned from from working, as Maria said, we we came from, from other industries. We worked with Silicon Valley companies where tech is or software is, has a very important role, and we learn stuff that we see that it's not usually applied to Medtech. So that's one of the things that we wanted to leave you with. It's just a few that came to mind to us. But first of all, in this day and age where AI is advancing every week, and it's very accessible to everybody, we are trying to leverage it as much as possible. So for instance, our developers use it for code generation. Of course, we don't just tell it to do something and just be done with it. That wouldn't be acceptable and that, and the FDA wouldn't allow that. But there's nothing wrong in using it for creating better software, for making sure that you are compliant with several things that you need to be compliant with. You could have checks assisted by AI. So there's a lot of things you can do with AI that can help a lot. You can also use LMS to consult information throughout your documentation package or throughout

Martin Zuniga  18:38  
the FDA requirements or different content of market submissions or the the standards that you need to comply with. Those are very extensive regulatory specialists. Know them very well, but sometimes it's not, it's it's not always accessible to a team to have someone who can help on every aspect of this. So you could have an LLM, have access to all your documentation package and all your guidances that you need to follow, and you can consult things there. Of course, there's going to be someone who will have the responsibility and the actual knowledge to check things and make sure that we are complying with everything, but it gives you a help that we think is very important. We have used it, for instance, to check that requirements when you change your requirement where you should be updating the good documentation. Of course, you have your traceability matrixes or or any other way of tracking those. But using AI really helps a lot in not overseeing some of those things that you need to keep in mind. Then you have CICD, which is continuous integration for those of you who don't know it. And what it does is it's a set of pipelines that you can set up for being a. So when, when there is a change to your code base, you could have a different, a new version of your software released, and you could have different sets of tests that run when, when every change is committed to the code base. So what that helps you with is if you have, for instance, unit tests or automated tests, or or, or if you want to have someone internally test something, they will be able to get it without without delays, and you won't need to manually send them something, they will be able to get it right away. And getting to automated testing, this is related to CICD, if you have the means to to write automated tests which are written in code. So you need to be able to afford having a QA engineer to write that, but if you have the means for doing that, it's great for making sure that everything works as expected. We worked on projects where test protocols are run after, I don't know or we've seen and we've tried to change it, but where test protocols were run after four months of development work, and then you notice that a lot of things that were working and were supposed to be working, they are not. So you need to continuously try to change them and to fix them and run them again and so forth. So it's it's very, very complicated, and having, having a set of automated tests helps a lot, even if the A, if the FDA doesn't accept them yet, we believe that's the case that they don't accept them yet as valid testing evidence, it's good to have them and it save you. It can save you a lot of time when actually going through the submission. Of course, you're going to have to have someone run the actual test protocols when doing the submission. That's what I wanted to say. And just a couple of more things that you can use from from agile. Is, first of all, in Agile, if you're familiar with it, you can have different ceremonies that they can be, for instance, the sprint retro, where the team goes through the things that they can improve as a team and as the way we're working on the on the project, you could have the standard reviews, planning and so forth. You could also incorporate risk assessment meetings, where every every sprint, or every two sprints, you just have everybody involved go through risk, the risk analysis that we already that we have in place, and just make sure that everything is well set up. That gives you another layer on top of what you already do in the sprints, to make sure that you're complying with everything that you need to comply and that your software is safe. And then another thing is using the definition of done, this is something that comes from agile, and it's, it's, it's, of course, it's not exclusive to agile, but it's something that comes from from that, and it's having a definition of done that is tailored to your project. So for instance, we mentioned that there are a lot of things that can be involved in the process of building software, regulated software, and a lot of team members. So you have to write the write up the requirements. You have to write up the the architecture and everything related to design outputs. You need to implement the code. You need to write unit tests, automated tests, manual testing. So there's a lot to be covered. And you can define a definition of done that says, Okay, this feature is going to be considered complete when everything has been talked of, when everything from the requirements, the design implementation, the risk assessment, even cybersecurity risk assessment or threat modeling, when all of that has been covered, you can say, Okay, this is done and, and it helps you a lot in guiding the the process. So those are a bit of the tips that that we wanted to share with you. Hopefully some of you can incorporate them, and, and, yeah, that's something we wanted to share. And I'm going to leave you back with Maria to continue with the presentation.

Maria Gomez  23:59  
Great. Um, so this is an example of a typical timeline to bring a medical device to market, and we wanted to show you how you can incorporate your software development efforts into it. What we've seen is usually, everybody wants to build everything at once. I'm sure you have a lot of features you want your solution to have, but sometimes that's not conducive to the timelines you have or especially the funding you have. So what Agile lets you is you can start building and only tackle the features that make sense for whatever stage you're at. For example, you can see here we've adapted the software development stages to the trials and the data, for example, right before animal trials, pre clinical you can start working on the features that you'll need right then. So we wanted to give pro. A real world example that we're most familiar with is an implantable continuous glucose monitor. What are some of the features that you think it should have? There are a lot of them. So what we've done here is adapt some of those most common features to the regulatory pathway, for example, during animal trials, we have no real users. So does that make sense to have a patient app? Probably not. We'll really want to focus on having a secure Bluetooth connection. We'll want the device to correctly collect and store that data, and then we can manually export that data for analysis. So for example, right before animal trials, we'll really start to work on those three features and make sure they're ready for that stage. Moving on to first in human trials, we'll start to have users, typically between five to 20 patients. So now really makes sense to start working just on a very basic mobile application for them. We'll want to have real time trend visualization. We'll also want to work on just basic alerts, at least for those critical levels, for example, low glucose levels. We'll need a clinician dashboard for the clinicians working on that trial, and patients can also start to manually input the data into their patient app later. As our trial expands into a clinical trial, the tools that we've been using so far, or that we've developed so far probably just won't cut it. We'll have well over 100 patients by now. So we really need to make sure we have the right tools for our clinicians and our patients. So right before clinical trials is when you can start to work on a lot more features. For example, we'll need to have full user accounts for both patients and clinicians. We'll want automated alerts for just any type of abnormal reading, not just those critical levels. We will want cloud data thinking for the remote monitoring of the patients, and then we can get started working on just some basic AI driven insights based on the data we collected so far. At this point, the only features that we're holding off on are just only those that really make sense for commercial launch, and we can get started working on them later, when we're ready. So those would be just very personalized insights for users, full EHR integration after we've launched User Settings customization as well as multi device compatibility. So just some very basic closing thoughts, we wanted to leave you with, um, are the perks of using agile and incorporating it in Medtech, we think it's really useful to align the features with regulatory stages that allows you to not have to build everything up front. You can also adapt user and patient feedback that you get from the trials. You Can Have Living documentation. So for every stage, your documentation is up to date, and this essentially lets you be submission ready at all times. So these are just some of the perks that that we think are very useful in Medtech and we started incorporating when we started working in this space about four years ago. So does anybody have any questions? All right, great. Thank you.

Martin Zuniga  28:54  
Thanks so much. Thanks for being hit with

Audience Question  28:58  
this line that he showed was very interesting. The one that was showing that client can come to you even when they are doing the pre clinical animal study. So that just shook my whole understanding, because it was thinking they come to you only when it comes to commercialization. So could you please explain in your experience, what's the best time to connect? Because I understand that's where they can get engaged. But is it the optimal time to invest into software, or is it better if they wait? Let's say when they're getting close to clinical trial. What is your experience of popcorns?

Martin Zuniga  29:38  
That's a great question. My take is that, thanks a lot for the question. My take is that it's the sooner the better, in my experience, because there are a lot of things that you can do to help with your with your even with your animal trials, as Maria said, you can work on on gathering the information in a way that allows you. For analysis of that information better. It doesn't have to be anything fancy, it's just things that can help you. For instance, we've come across people that are using solutions that help them store data in the cloud, but they are restricted to what those platforms give them. So it might be worth it to invest just a little bit on customizing something and making something that is helps you in getting information for your trials. But we've also seen that, of course, everybody knows that trials are very costly, so it's difficult for a startup to have money to invest at that stage. It can happen, but I would say it's better. And us as a software company, for instance, are always willing to help with something that can support the founders or the company throughout different stages. So if at the beginning it's going to be something small, we are very happy to work on that in a way that is that adjust to their budget, and as the project evolves, and as they start getting funding that helps them cover more robust software that they need for their for whatever their whatever therapy they are developing, then we can adjust to that and continue growing with them. But I don't know if that that answers your question, or Maria, if you have something

Maria Gomez  31:29  
to Oh, thank you.

Martin Zuniga  31:31  
Thank you so much. 

Maria Gomez  31:34  
All right. Awesome. Thank you guys.

Martin Zuniga  31:38  
Thanks. We can go to the bar now.