 profession, especially in the medical field? Yeah, if you have. What happens, what happens if you ask them how their day was, how their job is, how they feel about their job? Usually within 10 seconds, 30 seconds, they start to cry, right? I see in the medical field it's a mess and here to talk about why how and how we maybe fix it for future products we have on stage Petina Neuhaus. So please welcome her with a very warm round of applause. Yeah, good morning everyone. Thank you very much for being here on this very lovely sunny day and spend your time in this tent. Yeah, I will talk about medical software and the regulation. Let's see our itinerary of our journey. We have five parts or basically four parts. First I give you the intention of this talk, would be very short. Then we'll take a discovery tour. Where is medical software in what devices or maybe without a device? Then a short disaster tourism tour, spectacular fails in recent times because I want to give you the idea why it is important, the part that I will talk about afterwards and that is the regulatory part and what this means if you have an idea for a medical product. So yeah, let's start and the fine print of course a few references, contact into info and so on. So first part, this is a field trip, not a study tour, which means I will not go into the details of every regulation because first of all that would take a few days and also I want to give you an idea. This is from a European Union perspective, but it will give you an idea even if you're in other parts of the world. So if you are a regulatory expert, you may not hear much new stuff, but if you are doing regular IT, then you can get the idea what to do when you want to go into the medical field. Yeah, next part, where can we find medical software? You have first idea that you have will most likely be the pacemakers, implants, ventilators and so on. I will not read out all the slides. You have external parts that don't touch your body and you have secondary parts that are not directly in contact that receive and send data and do stuff with that. And also the mobile apps, which can be free to use or may also be officially regulated medical devices. Yeah, so just talked about that, the prescription apps and also you may have, for example, the very simple ones or the very complicated ones, IA based, supporting, for example, skin conditions, making a first hint for a diagnosis, which will then be screened by medical personnel. All of this is medical software and all of this is regulated. Yeah, and then we have the cases of doubt. For example, clinical information systems. Those are the systems that run in hospitals and some of them try to cover everything from administrative tasks, so getting the patient data, where is that patient in what room and so on, but also diagnostic info. And here's the gray scale. If it's, for example, the software that focuses more on the diagnostic part, then it may be most probably a medical product and needs to be regulated. Of course, there is a lot of discussion and the manufacturers are often not so happy when they are told, this is a medical product, you need to get certified because that means a lot of time and money, but also a lot of safety. Yeah, and then I want to bring to your attention, I mean, as IT people, you will already know that, but those medical devices comprise of many parts, of course. Often you have a part of hardware, there you have the firmware, of course, the software for analysis and so on. So the example I've taken here is loosely based on a lab analyzer. And what's important is that all of this can come from different suppliers. And they all need to comply. And who is responsible in the end? That's the manufacturer. That's the one whose name is on the packaging. And that's the one who tells the agencies, the official agencies, here's the medical product I want to enter the market. And that manufacturer has to make sure that each supplier is compliant. So, yeah, that's important. And also, on the lower left, you see third party applications. Of course, you will not write everything from scratch. You will not write most likely an operation system. Sometimes you do, but often you don't. And you take third party software. That is called here a soup, a software of unknown provenance, which means you haven't written the code yourself. But you still have to make sure that it is safe for your medical product. So you have to take the measures. Sometimes this supplier of, for example, the operating system is also certified for medical product, but often is not. And then you have to take measures to show that it is still safe. So you have to consider time and effort for this as well. So what can possibly go wrong? Let's take a very short tour, disaster tour for spectacular fails in recent times. We have here first thing. I have taken a look at the FDA database. You can find the link below. Just the cases of 2021. So you can see here it's a lot. I can't tell you how many because the database would just return a maximum of 500. So the class one recalls for mostly harmless product that was just 26. And most of those were mislabeling. So for example, there is a lab. What's that called? Let me check my notes. Oh, it's for in vitro diagnostic agents. So maybe there was a different agent in this soup. So okay. But it still works very fine. It's not a problem. It's just mislabeling. That's cause for a class one recall. The class two is slightly more dangerous, possibly. And there were more than 500. I can tell you how many just very many recalls where something went wrong and they had to recall. And then we have the class three recalls. That means they in case of a failure, this can lead to permanent harm or even death. And this has happened. I will show you a sample, an example on the next slides. So this happened 179 times. Just the last year. Just FDA. And I said in the beginning, I'm referring to EU regulations, but frankly, the FDA seems to me much more transparent and accessible. So I took these data. Yeah. First example, we have the dexcom glucose monitoring system that was or is for diabetes patients. They had to recall more than 250,000 units. It's a system where you have a small implant measuring your blood sugar levels and a receiver. And the measurement was just fine. But the alarm didn't sound. So if your blood sugar level was too high or too low, if you didn't check actively, you didn't know. And that can of course lead to death. And they had to recall all their devices distributed between 2012 and 2016. You can imagine what that costs and what that means logistically. Then we have an infusion pump module for high volume infusion. And they had to recall almost three quarters of a million units because they had multiple errors. They weren't described in detail. And this could have caused an interruption in infusion. And here is the really serious case. They had at least 55 reported injuries. So we don't know if there were more maybe. And they had one reported death. So this can happen if all the procedures fail. And there are a lot of procedures you can see that later. Also a very nice example. I love it so much because there was a very interesting talk on the last CCC camp. The link is down here. I highly recommend to watch it. This was the pacemaker and could be hacked. And you could change the heart rate of the patients. Or you can drain the battery quickly, quicker than they wanted to. And interestingly, the manufacturer tried to save for some time. No, it works. It's not true. But just watch that talk. It's really good what they did. In the end, they had to recall all of these. And one example that's not on the slide. A recent thing I saw in Germany. Mobile applications. So wouldn't cause any death or something. But, well, you probably have heard that before. They had user IDs. Numerical order. So you can just guess. Adjust the number and you're in the account of another patient. Voila. I think this has happened not only in medical software but it still happens. Okay. So these were the examples. And now the biggest part is we take a look into the regulations and what that means for your product. Let's say you have a good idea for a medical product because that's what I will focus on. There are other types. I will show you on the next slide. So focus is medical product, EU, but also applies in big parts to other kinds of products. So first you have to determine is it a medical product? And the first question is is it for human use? Because if you have something that heals cancer of cats, that is fantastic, but it's not a medical product in the regulatory sense. It has to be for human use. And then the next thing is the intended purpose. And the intended purpose is what you say it is. So you often will see in manuals that it is, it says this is not for medical use. Well then it's not a medical product because the manufacturer tells you you don't use this for medical use. So you can decide a little bit if your product is for medical use or not. If you have to follow the regulations or not. And if you don't then it's not a medical product and it can't be used in that field of course. Okay, so also, yeah, is it a lifestyle product or something like that? And it's not a medical product, but if it is, for example, it is on the on the human body somewhere in touch with the human body, like diagnosis systems or the implants that I just talked about, then it falls under the medical device regulation. If it's not in direct contact, lab material and so on, analyzers somewhere else, not in direct contact with the human body, then the in vitro diagnostic device regulation is the one to go for. And then you have the pharmaceuticals. That's a whole different part. And there we have the ICH and the GMP. And ICH sounds so short. I will just read out what that means. That's the International Council for harmonizing of technical requirements of the pharmaceuticals for human use. ICH. I will leave that out today. And I will focus on the medical device regulation. But for example, the in vitro diagnostic regulation is more than 80% the same. It just focuses more on calibration that you get the right results on weighing, measuring and so on. And yeah, next thing, you will hear this a few times more during this talk documentation, because get ready for a lot of documentation, which is very important. I will get to that later. You begin to compile your technical documentation with what is a bunch of documents. And this goes from the very start of your project until the end. Yeah, you document everything that I will mention on the following slides and even more. You can reference the documents to each other so you don't have to write things twice, because then also maybe a cause of failure, you update one document and not the other. So link them to each other saves time and is easier later. What we do in our projects in my company is in every project, we have a regulatory expert just for that poor purpose. And I highly recommend to do that because I have to say I'm not that expert. I'm certified. I know all the stuff, but I have a lot of things to do. And I am very grateful that I have one person just for the regulatory part makes sure from morning to evening that everything is compliant. Yeah, you have to get a declaration of conformity. That's the E sign that's everywhere. And if it's a harmless device, class one, we get to that. Then you can apply that to your set, not to yourself, but you can apply it yourself and write the declaration of conformity. But if your product has a higher risk, then you need a notified body to audit you and give you this E sign. And yeah, it's important to also plan ahead because that takes a lot of time. You can't tell those people, okay, I'm ready. Please come tomorrow. Usually it takes, I don't know, in our projects nine, 12 weeks or more for the first talk to those people. So plan ahead. Yeah, then we come to this class that I've already mentioned. The classification of your product depends on the health risk. So, and you have different classification types for medical products in the EU. You have one, two A, two B, and three. In the US, you have one, two, and three. For in vitro devices, you have A, B, C, D. And there's also a different one for software. So just look it up. If you find your product, then yeah, you can spend a lot of time and discussion to find this classification. Software running on those devices, if you have hardware, they have their own classification on top. And standalone software, if there's no hardware, they are considered, you can also look that up in the regulation as an active medical device. And active means it needs a power source or it has a power source. So implants like a new knee joint, that's not an active device because it doesn't have a power source. Yeah, then you do the risk assessment. So risk management is one of the biggest parts of medical software projects. You take a look, can your product cause harm to patients, to users or to others? And how serious might that be? And how likely is it? And then you create a risk matrix. You take all the reasonable measures to lower those risks. You have to describe this. And this is also, yeah, the topic for a lot of discussion. Where is my product or product? What does the notified body say? What do the agency say? Is this a real class or not? So this is not a thing of, I find this, I say this, done. There's a lot of movement and discussion here. So also prepare for a lot of time, yeah, to find that risk. Sorry. Yeah, a few examples. What are those classes? Also, again, this is EU medical device regulation. The class one is the mostly harmless things like a band aid. Nothing can happen, mainly, or still can, but unlikely. So then you have the class two, A and B. They interact with the body or maybe enter the body like hearing aids, infusion pumps and so on. They can cause harm for a temporary time and they have a medium risk. And the class three products are the ones that are permanently implanted to your body or interact with a central body, a nervous system, for example. And if they fail, they can cause permanent harm or death. So that's the highest class and they have to take the most measures and get the most auditing and so on. Yeah, what to do next? You have to establish a quality management system, which describes the processes that you will adhere to and document everything. You are obliged to do so from class two up, but even for the class one, they recommend to do this. So, yeah, this is to make sure that you have all the processes there to ensure you comply and practically know what you are doing and can document that. The alternative is if you're a small company or maybe even just one person, which I also had before, you can try and someone to do all this. Maybe they already have a management system, the quality management system. Maybe they are already qualified. And then you can also get them in as a partner because you say, okay, I want to focus on the software or on whatever. And you can find someone. But then this partner has to act as the legal manufacturer. So their name will be on the packaging. And yeah, just decide if that's the way to go for you or not. Yeah, also you have to verify that your software actually works. And this means for the class one products, you have to make a clinical evaluation. So check literature, write down what you found and why your product will work. And for classes two and B, you have to do a clinical evaluation. So basically the same, but you have to use clinical data or a clinical trial, which is more work. And for class three, you have to conduct a clinical full scale clinical study, evaluate that and document everything to show that your product is effective. Yeah, my favorite word is traceability because that is basically one main point for all the medical products traceability. You have three kinds of I will focus on the first one. The traceability of product requirements from the requirements to the testing in the end, which means or I will come to that later. And also we have traceability for the for measuring the in vitro devices. So does your device show the right results? Is it calibrated? You have to show that all the way and through the whole life cycle of your product. And also they have the logistics. So in case something fails, you need to have the traceability. Yeah, back to the first supplier. If something fails, for example, there is one piece of hardware in your medical device with from some supplier, you have to know, okay, where is my product that has this batch from this supplier that you have to recall. So that's also logistics traceability. But let's take a look at the first one. Software, mainly software, but also hardware traceability in your project. Classical thing is to do a V model planning here. Hello project managers. Which basically means that from the very first part for the very first planning up to the last and you have to show where all the requirements are. So looking at, for example, a software code, there is a line of code somewhere. It's audited. You have to show why this line of code is there. Where is the requirement? Because of that, this line of code was written. And also, where is the test that relates to this code? So we have to have this chain of traceability throughout the whole project to make sure that there is no code that is just fancy and undocumented Easter eggs or something like that, that can't happen in a medical product. And that's all, of course, for the safety reasons. I just shown you that no disaster happens like the ones I've shown you just now. Okay. Next one. Oh, I already said that, I guess. Let me see. Yeah. So result is document, document, document, verify, validate. So are you actually building your product the right way? And also, can users reach the goal that the intended goal? And yeah, test, document, and document. Yeah. Okay. All this documentation can happen, even either on paper, the classical way. And you have a lot of files sitting there. And for each change in your software for each new release, you have to print out the new versions. They have to be signed, sealed, and delivered. Or you can use electronic systems for that. We just heard about in the talk before about the digital signatures. That's a very good thing you will need for those electronic documentation systems. There are a bunch they are working. They are specialized in making sure that you have the trace ability that you need, so that everything is linked to each other and you can find each item on the way. And also that it can't be changed later. So you have your safe documentation there. Yeah. You need to be audited on a regular basis. Again, that depends on the class of your product. If it's a class one product, then you have the audit from time to time. And if it's a class three product, you have to get re-audited every year. If you deal with ISO 9001 certificates and audits, you will know how this works, because it's quite similar. Oh, okay. I see. I'm quite good with the time. Okay. So let's say you have everything you ready. You have spent the last one and a half years planning, documenting, talking to the notified bodies, getting everything and encoding everything and testing everything. Then you have to register your product with the official body in your country to enter the market. In Germany, for example, that's the Bayfarm, the Bundesinstitut für Arzneimittel- und Medizinprodukte, Federal Institute for Drugs and Medical Devices, because you can't just start to sell something. You have to register it first. And then you have to start with a long-time market observation. What does that mean? That means, of course, you have to watch what happens with your product, and you have to have all the processes in line to receive complaints, failures, and to call back the products and so on. But you also have to take a look constantly at other products on the market. Are there new procedures or are there findings in other products that might apply to yours as well? You are obliged to do so. And if you learn something that might have an influence on your product, you have to check and maybe apply some changes. So you can't just sell it like a normal product and wait for complaints or something. You have to actively monitor the market and take measures if something shows up. If something shows up, you have to notify the notified body of the institutions that there is something in Germany. For example, it's the BFARM in the USA. It's the FDA. That is where I got all the numbers in the beginning. Because they need to know. And then they need to distribute the information that there is something going on. And you have to take measures to again lower the risk. Because maybe if there is a critical failure and you are not able to recall everything at once, then you have to send out information what to do. Sometimes it's just read this label and know that it's wrong. Or here's a software update and here is how to install it until we deliver the new product to you. Or in the worst case, it is we'll just stop using it once because it may cause death. And well, this is a difficult thing because just yesterday I was talking to my colleagues over at the Hack the Health Village. And they said basically, well, in Europe, yes, you say, okay, stop using this product. We give you a new one. But if you are in countries like South America or I don't know, India, maybe it's not so easy because there is not a quick replacement. And they really want to use it, although it might be risky because there's just no alternative. And yeah, I just heard I have no link for that. That there were guys specializing in making the devices work even longer, even if they are risky because they just don't have an alternative. So yeah, it's sometimes it's difficult to see what the right decision is. But officially, of course, if there's a serious risk, then you have to recall all of that. Okay. So I said in the beginning, I won't bother you with all the regulations. But here is your guide. Take that with you if you want to start a medical product. These are the most relevant regulations. It's not complete, of course, but it will give you a start. And all of this is well documented, of course, is regulations and norms. So let's take a look. We have the quality aspects. I think I was talking mostly about that today. That's the ISO 13485. And ISO tells you it's international. It's not only EU. That deals with the medical device quality management system. Sounds easy, but there's a bunch of regulations behind this or definitions and so on. Then one aspect that I didn't talk about that much today, or at all, almost, is usability. Medical device usability. And this means that by design, does your product work? Does it cause no harm? And can people reach the goal they are intended to reach? You have the software life cycle processes. That is such a bunch of things. I described to you what to do to plan, develop, test, roll out your medical device and the big part of the risk management. As I said before, this is a big part of discussion. So prepare for spending quite a lot of time to find the class for your product and discuss with people and show your measures and then discuss again and then settle on a class at last, I guess. And then IT security for medical software projects and for health products in general. So this does not only apply to certified medical products, but also to health and lifestyle products. So if you want to go that way, check this regulation as well. Okay. Yeah, not all of these are harmonized, I have here, so they are not completely agreed upon between all the different country institutions. So check for your country if they apply or if there are sort of differences. Okay. And I think with that, I'm almost at the end. I have here a bunch of links that I used for compiling this talk. And also I'd like to thank my colleague, Milena, who is the validation or the regulatory expert on my current projects. So thank you, Milena, very much for saving a few errors on this first version. Yeah, that's all. I'm Bettina, as I said before, happy to get in contact. And oh, there's one little thing I'd like to mention. I don't know if you have seen my post on Twitter about the multi-tool that I brought. That's a bit unrelated, but it's a bit of language fun. So I have a few of these multi-tools for people in need of a tool or bottle opener. I think that's the most important one. And I promise to pronounce a German word, because there is an explanation here. And there is a Phillips screwdriver on this multi- tool. And the German word for Phillips screwdriver is Kreuzschlitzschraubendreher. So thank you very much. And yeah, we have a few minutes for questions, if you like. Thank you, Bettina. That was a very well-documented talk. Thank you for that. We already have people lining up at the microphones. Excellent. Please, sir, step forward. Come close to the microphone and ask your question. Hi. Thanks for the talk. I'm afraid I missed the beginning. So if you already covered this, excuse me, can you say something about the permissibility of using AI-based algorithms in medical products? Yeah. So if I'm using a neural network to identify cells, can I certify that? Because it's kind of a black box. I don't know what's going on. Yeah, but it's still, I mentioned that very briefly as part of where might medical software be. And as soon as it's part of medical software, then you need to put this into all of these regulatory processes and validate and verify that it works exactly and follow all the procedures from the medical regulations. And I know it's hard because, as you said, it's a black box. Yeah. Thank you for your talk. You discussed the concept of soup within your regulatory environment where you have third-party components. And there have been a lot of discussions with the open source community in combination with medical devices and medical suppliers. So my question is like, and this is also in other regulatory industries, like how do you, for example, for a leaner's kernel, validate like, yeah, you have this user called happy banana, which made some drive-through dates and we have some, yeah, singing monkey on the other part. So how does that come together in the medical industry that you can certify such a thing? Because you're not building your own operating system. You're running on, for example, a leaner's system in certain cases. So how do you, how does that work? And give a little bit more insight on that one? Well, one thing is to see if already others are using it, of course, and have done some work for you there in advance. And then, well, you might have to audit the software and really look into it and check if it's safe, if there are risks inside the code, for example. Also risk assessment, what part is this in your medical product? What kind of harm can it cause? I didn't go into that, how to do that. You can do preliminary hazard analysis for this, for example, an FMEA might have heard that before. And yeah, you might have to do this for soups as well. If they are well known, it might be easier. So if you're using a Windows operating system, I think nobody will require you to audit this in all depth. But if you're using some brand new library, then yeah, you have to do that. Okay, but also for existing, if you, for example, look at the Linux kernel, that gets updated quite often, et cetera. So how do you keep that basically on one hand secure? On the other hand, yeah, you got that certification there. Yeah, I mean, first of all, one part of your documentation is a list of soups. So you always have to document all kinds of soup that you are using in your software. So you have to write down I am using Linux kernel, this and that version. And if it's a brand new one, I guess, then you would also have to audit that you can't just take it. No one has, of course, someone has tested it, but not in the way for a medical product, then yeah, you have to do this if you're the first one. But also, yeah, if you're using Linux or some library or everything that touches your software, you have to list it. You have to make sure you keep it updated all the time. And with every release, you also have to update your list of soups. Is there something new? Is there a new version of that library or that kernel? Next one, please. Oh, microphone is off. Still mute? Okay, now it's here. So thank you for your talk. Would any software that a user interacts with basically be a class one product? Because if it has any impact on health? I'm not sure if you get your Okay, if you have a software that impacts the user's health anyway, would it be a class one product? For example, an app, mobile app? Oh, that's actually a good example, because that was one discussion that I had with my colleague Milena. The information that I had is that medical products, medical apps in Germany at least, until recently, mostly were class one products. But with the newest version and with the MDA, MDR, sorry, they are now mostly class two a. So that shows you again, there's a lot of movement. And the regulation is still new. So it's not fixed. Next one, please. Thank you very much for the talk. Back in the beginning of the pandemic, the UK government at some point asked companies to come up with medical ventilators right then and there. And the Dyson company said, well, we'll design one in 30 days. Do you remember that? And was that realistic at any point in time? Design the product? Yes, maybe. But don't you don't get that certified in that time? It's not possible, I guess, because everything I just talked about, you have to do. And ventilators, they are serious. I'm not sure I think they are at least class two B or something like that. Don't want to say something wrong here. So you have to comply with a lot of regulations and follow a lot of processes. I don't think it's realistic. Thank you very much. Well, again, thank you for your talk. I was wondering, you talked about if there's you bring the product on the market that you constantly have to keep in check with any developments in the field. Let's say there is a development, and you find that you have to update your product. Do you have to go through the entire regulation process again? Or is it just parts? Well, depends. If there is a new feature that might cause a change in chances, but also risks, you have to check with each change. Is there a change in my risk? And if there is a serious change in my risk, and I don't have the measurements to lower that again, the possibility that it actually happens, then you might have to change the class of your product. And then you have to change the processes and apply a bunch of more measures. So with almost everything, it depends. Yeah, you have to check. And if there's all a small change, maybe you have to update your documents. If it's a bigger change, then you have to change classes and do a lot of more things. Thank you. So Bettina, where can people find you for further questions? Where to find? Where can we find you if we have further questions? Yeah. Right now, after this talk, you can find me around the tent. I don't know. Somewhere nice and easy. At the Health Village, if the music is not too loud, because I found out that we're unfortunately between two, I mean, they have fun. Nothing against that. But please do make it up. Thank you very much, Bettina. We're out of time. So please give a very warm applause to Bettina. Thank you.