in the start segment, we'll take a look at this more. Some detailed look at this document called the general principles of software realization. This is the initial FDA guidance on medical software and medical software at the time in the context of a medical device. So again, a reminder this sort of flow share of law regulation guidance. We're now into guidance, the GPS is a guidance document. Remember that guidance described the agency's current thinking on a regulatory issue. It is not legally binding, but it should be taken very seriously tells you what the FD thinks, and how software should be validate. And of course, given that they review whether you validate the software correctly. What they think is the appropriate process is something you take seriously, because it's going to impact how the review something that you submit to them. So this is the outline of the document and there's a picture of its January 11, 2002. This is the revised version of the original version is a few years earlier. They have to initial sections called purpose and scope. Then, there's sort of some background theory in the section called context for software validation. We'll zoom in a fair amount of the section called software is different from hardware is an important section will spend some time. Then, there's something called principles of validation will cover this quickly, activity, and task we look at quickly. And then, we'll return to the sections in this section of the document. The subsections as we perform this activity and task will look back and see what the guidance is, and then the final thing is validation of ultimate cross equipment, external light present things and we have one comment to make about that on too. So let's get started. And I will keep this title of content on the left hand side of the screen just to around here as we go through. So the beginning is the purpose. This guidance outlines general validation principles that the Food and Drug Administration, FDA considers to be applicable to the validation of medical device software, or the validation of software used to design development, manufacture medical device. So this is the purpose, it tells you what you're supposed to do in order to validate software, and by value software means software that meets the needs of the user. That is the definition of validation. The scope now and this is where they use the title. This document is a little bit of a miss number, and the scope will make this clear. The scope of this garden somewhat broader than the scope of validation in the stricter definition of the term the way with defining. So the thing that planning, verification, testing, traceability, configuration management, and many other aspects of good software engineering discussed in this guidance are important activities that together help to support a final conclusion that the software is validated. So you could re-title this document is the general principles of software engineering, and you would not be of them. But so their definition of validation of course is much broader than the normal definition of validation, at least the way they're scoping this document. So keep that in mind, people look at the town, think about validation, and they go in and discovered that how the documents about design and coding, which is a little bit confusing. So how should software be developed? And again, when we talk about America software lifecycle and why we use it here is the origin of it. This guidance recommends the integration of a software lifecycle management and risk management activities into the process. This guidance does not recommend any specific lifecycle or any specific techniques and methods. It does recommend the software validation and verification be contacted through the entirety of the life cycle. So what this tells you is, you can follow any of the life cycle you want that you have to have one, it's a basically. So you have to do have a life cycle, you have to know what step of the process you're in. We're now quoting, we're now testing, we're not doing requirements, and you have to do risk management throughout your process. And this is a general guidance. And this is true of much of this vocabulary seeing these kind of documents to tell you what you should do, but not how you should do it. Often, you have flexibility in how you meet this guidance, but they tell you what you absolutely have to do. The next comment and again, this is a critical common. We're going to come back to this again and again throughout this classes. This comment of about software updates and how they get in trouble. So the FADA analyzed 3140 medical device recalls recall is when something significant wrong is found with a device that has to be taken off the market. They found that a fraction of these were a tribute to software failures. End of these, 80% were caused by software defects that were introduced after changes were made to the software, after this initial production distribution. So 80% of the problems with software happening updates and 20% happen in the original version. And you may be familiar with your computers, the computers working fine, then you get an update, and everything slows down. So please keep this in mind, updates are a very significant part of the software lifecycle, and updates can be a big source of trouble. So you will see that in the life cycle as we come to the end, the maintenance process is treated with the same level of seriousness as the original process of creating the software. And when you hear words about self continuously learning AlQ from machine learning realized that we're talking about updates are happening continuously. This is a very serious issue that has to be handled with care because updates can get you in trouble. This is the lesson of history at least the original study by the FDA. Okay, the context now that software validation happens. This is just some background for you, and this is an acknowledgement by the agency, and anybody's develop software knows that this processes are difficult because the developer cannot test forever, and it is hard to know how much evidence is enough in a large measure. Software validation is a matter of developing a level of confidence that the advise and meets all its requirements. You test until you've tested enough and you feel like you've gotten there like the number of boxes low. It worked in enough cases and things. Now, what is this level of confidence? This is the other part of the regulatory process. The level of confidence and therefore the level of safety validation verification, testing, effort needed, would be dependent upon the safety risk posed by the ultimate function of the device. So again, the risk classification, the device, what are we using it for? Are we using in a situation where the output is going to directly impact the treatment of a patient in serious condition? That requires a very detailed testing regimen, because the level of confidence has to be high if it's something that's less directly affecting the patient, or the condition of the patient, no particular serious. We can get away with less detailed testing regime and less detailed design, and those will come over and over again, especially as we start talking about, I see six, two, three, or four, which details some of the steps, the international standard in this process. And this is up there, the classification, the FDA users will come back to this in a couple of segments. Class one low to moderate, class two moderate to high risk, class three high risk. There's a section section 3.3, that to my mind is almost the most interesting part of this document will zoom in a fair amount here. We'll have about five slides talking about just this. And this is the differences between hardware and software. Remember, all these regulations were written for hardware and they are adapted for software. So what are the differences between hardware and software? The first one is of course, that the vast majority of software problems were now quoting and paraphrasing film document a traceable made two errors made during the design and development process. Because unlike hardware, there's no manufacturing process to speak of, right, at the end of the design is the software. The software is the product. You don't send it out to a factory. I mean in the old days we used to make CDs, but that's basically it. And typically, and this is the second part we're going to come back again and again to this point, testing alone cannot verify the software is complete and correct in hardware. You often have a relatively simple mechanisms tested in all possible ways you say good enough, it works. Software can have non-linear path to the system. Different things can happen. We'll talk about the branching problem in a couple of slides. The second set of differences here is that unlike heart, which wears out software does not, so software doesn't really get old and like hardware will have micro structure effects, but you can get defects in the software through updates. This is the 80, 20 things we talked about before, and like some hardware failures, software failures often occur without advanced warning. And this is what we talk about branching statements. So when you look at hardware, you often begin to hear sounds, scares, grinding, weird noise, and this thing is about to fail. Software, one day works in the next day, that's the end of it. And the reason for it is that there are things like branching statements. There are parts of the code that were never exercised, and under certain circumstances you go to a piece of code that you never used before, and all of a sudden you have a problem. And small changes in the code can create unexpected and very significant problems. And that's because of the inherent non-linearity is in the system. So let's look at this branching statements problem. We alluded to it, so let's just look at it here. So it's a very simple piece of code. We have two variables input, A and B. If A is greater than 2 we go to the right hand side of this code, if it's less than 2 go on the left hand side, and we have another variable be less than 4 go to the left, greater than 4 go to the right. And depending on the combination went up in four different functions here, right? So if A and B are both small, we get A plus B plus 2. Otherwise, a plus 6 plus b plus 2 plus 4. So to probably test the software, we have four combinations to exercise all four pieces of this code. Now, these are trivial piece of code with two variables, we can count, and this is pretty easy. If you have anything but the most trivial piece of software, you may have 20, 50, 100 of these things, of which you may only have tested 90%. So all of a sudden now, A goes from in this trivial example 2.1-1.9. And all of a sudden still being on this side of the code, you're now on this side of the code, which you may never have tested. So this small change can all of a sudden give you a problem. So that's what the branching problem is. Is this introduction of non-linearities into the system. Okay, 2.01 you're going to the right, 1.99 you're going to the left. You're not using a completely different piece of code. One more sort of comments about the difference between hardware and software and is one of my favorite parts here. This is a sociological comment If you wish from the FDA. That the personnel who make maintenance changes to software may not have been involved in the original software development. If the software is developed 10, 20 years ago, the people fixing the court may not have been there at the beginning. And so it's important to have, I created a thorough documentation. And the conclusion of this is that for these and other reasons, software engineering needs an even greater level of managerial scrutiny and control than that's hardware engineering. Now, these rounds counted what most people thought at least 10, 15 years ago, hardware is hard. Software is the software guys writing something straightforward, let's not worry about them. But the reality of the matter is that the software is all hidden from you. The hardware you can often see, so problems in the software may not manifest themselves, especially until somebody actually starts looking at the code to figure out. Well, how do we change this? So documentation is important. Proper documents, proper designs are important because without those, you may have a working piece of software, but software you can never fix, you can never change. And you realize that those of you who are old enough to have experienced this. If you go back and look at even your own code that you wrote 15 years ago, it's happened to me recently, you don't really understand why you wrote things the way you did. So you come back now and think, well, if only there was documentation, if only they were designs that would help us understand how this process works. The final pieces that testing is insufficient. Okay, so software testing is a necessary activity. But in most cases software testing by itself is not sufficient to establish confidence that the software is fit for its intended use. And these are like hardware, of course. So you cannot rely on testing to test quality into the software after it is written, you say, okay, I wouldn't care how it's written, well tested to death will make sure it works. The reason, of course, is that all the non linear partners qfter all the system, it means that you can never tested enough. So part of your confidence comes from the design, from the fact that you understand exactly what the thing is doing, is broken up into small units. The smaller the better, and that's the risk class goes up, you need even smaller units to ensure that you have quality process in place. A quality piece of software that lets you sleep at night that it will work just fine. The last couple of segments here, the principles of software validation, it's a reminder that one needs a formal specification. You can't leave the validation without an established software requirement, specification. This is back to our initial myth. The FDA says that the process doesn't start when the time comes to test, you have to have to have had specifications because only then you know what it is to test, right? In many start up companies, many new entrepreneurs here are under the false impression that we first developed the software in some fashions, and we'll worry about the FDA when it comes to validating it. The regulated process starts at the design. That's what design controls means, that's what the whole process is all about. And you can go back to the segment number four of Week One where we talk about this in a little bit more detail. Section Five, which had detailed section actually talks about activism task and both in quality planning requirements, designs, coding, testing, maintenance, and changes. This is the software life cycle in some ways. We will not examine this here in the detail, but we'll pick up the thread of visual these things from Weeks 5 to 10, when we talk about the individual components of this process. Finally, Section Six talks about external components and you're going to see this little graphic that will see over again when we talk about external components. Where software is developed by someone other than the divine manufacturer for example, use of the shelf software, the software developer may not be directly responsible components, safety regulations. Instead of the device manufacturer needs to assess the adequacy of the off the shelf software activities, and examine what additional efforts are needed to establish that the software is validated for device manufacturers intended use. So the option of this is that we limit dependencies to minimum here, and we control dependencies explicitly. So the device manufacturer, if you're the producer of the software, you are responsible for code that even you did not right. Let's say you use an open source library that you downloaded, you get code from somebody else, they are not responsible, they just wrote the code, they give it to you. You are the legally responsible party, the manufacturer of record. So you have to perform the testing process, the review process of the software, you're using the code, you're using that came from an outside source. Therefore, what this means is that you want to limit your dependencies to minimum. You don't want to use lots of code that you don't understand, because it's hard to ensure that that works, and you want to control these dependencies explicitly. You don't want low level system programmers as coders saying, well, we need to use this library. Those are decisions have to meet at a higher level, because when you bring in an outside piece of code, you're bringing in all the problems that come with it. Now, there's a balance here, you don't want to reinvent the wheel every time. We'll come back to this topic again and again as we talk about software design. So in conclusion, what is an FDA compatible process looks like? What is the lesson from this regulation? The structure and the environment in which we're working at critical. We must be able to demonstrate that the overall software development processes controlled and follows an actual plan, as opposed to our talk programming, and to some restaurant presentations online by Calvera. Because of three steps, you established before any programming, what we're going to do, we need a plan, we need to follow the plan. You need to be able to provide documentary evidence that the plan was followed, and those are the three steps, have a plan, follow the plan, and have evidence that you follow the plan. So this concludes our discussion of the GPSV, this original software guidance from the FDA. In the next segment, we'll jump forward 10, 15 years, and we look at the guidance on software as a medical device, and that brings us to the modern era of medical software. Thank you.
