So this week we will actually start working on the design of software will introduce the medical software life cycle, the organizing principle for a software project. And over the next 5 to 6 weeks we will work through the individual steps of the cycle. So today we'll do the big overall introduction and we'll pick up each piece week six to ten, 11 of this class. So our goal for this week is to introduce off the life cycles, will discuss the IEC 62304 standard, the international standard that governs middle of social life cycles. And will introduce our example project of Image carry neurosurgery, which will used to encourage discussion of the steps in the software life cycle, at least the first part of the site. The outline, will introduce life cycles and the standard in the first couple of segments in the next two segments will introduce example project, the image neurosurgical project and will give a guided tour of the life cycle process. And then the last segment, we'll talk about information transmission. This whole very important topic. So how information gets conveyed from the user, to the business analyst, to the software developer engineer, to the coder etcetera. We're still following the textbook and this week's material comes from chapter ten of this book. So, we'll get started. This is our introduction segment to life cycles and the IEC 62304 standard. The reason we care about life cycles is that it's explicit demanded in the guidance here. So from the FDS general principle of software validation. We have the statement that this guidance and comments and integration of software lifecycle management and brief management activities. While the status does not comment any specific life cycle model, it does recommend the software validation verification activities be conducted throughout the entire software life cycle. So the conclusion of this of course is that we must use a life cycle model. Now know that the guidance does not recommend any specific one. Neither, you're not, they don't force it use anyone, but you have to have one. And while the documents speak as if they're using a waterfall, that's just for illustration only. So here is the standard itself. This is IEC 62304, this is the original edition, this comes from 2006. And then this is the amendment that came out in 2016. And this is a fundamental document that governs medical software. Now, unfortunately 2016 is before the machine learning age. So it's a little bit out of date, so hopefully will be a revised version of this soon. But it's still a fundamental document for us to follow. So let's look at this document. So, the introduction is actually very interesting and has a statement that says that this standard provides a framework for life cycle processes with activities and tasks necessary for the safe design and maintenance of medical device software. So the goal is safe design and maintenance of course. As a basic foundation, it is assumed that the medical device software development maintained within the quality management system and the risk management system. And this is exactly what we talked about last week. 4.1, 4.2 referred to sections in the document there. This is the material we covered in the previous week and it's worth keeping in mind that everything that the standard talks about assumes that you have a quality management system and there is management system in place. This is the outline of the document. You can kind of see the heart of the document is section five which is the software development process. But a very important sections, also section six, we talk about the software maintenance process and for the most part, this is a duplicate and tells you what's different about maintenance and the initial development. But those are very important sections and then therefore an excess of which an XP is very readable and very educational if you get your hands on this document as well, there were 3D. As by now, you should be expecting any medical regulatory document. Any standard at some point, you hear the word risk classification. The standard defined software into three classes, Class A low or acceptable risk, Class B unacceptable risk. But the injury is not serious potential is not serious, Class C, it's unacceptable risk that can lead to serious injury or death. This is similar to the class one, class two, class three that the FDR recommends. It's simply a matter for the software component of a project. And remember a lot of these documents came from an era of medical devices where the software was part of a larger device. Just to explain this. It's a very interesting blog post. I came across from cereal mascot from MD11 consulting you can see the link at the bottom and he explains Class A, Class B, Class C in terms of a nurse using a thermometer which gives the wrong value. Now, what would we classify this system? And we're talking about a system here. The nurse plus the thermometer. The system is Class A, low risk, if the document gives the if the thermometer gives the wrong value, then the nurse is going to touch the forehead of the patient. Or you do the measuring with another thermometer or check the blood pressure of the patient to confirm the fever, no damage is possible. So this is Class A, even if the software gives the wrong answer, the human in the loop can make sure that this does not result to any any harm. Class B, the third moment I give their own value. And then the nurse may give the wrong treatment to the patient. So there's no checking by human here. However, there is no chance that this may endanger the patient's. So now, we're class B something could actually cause harm to the patient, but it's not particularly serious harm. And then Class C as you'd expect, then the nurse is going to give the medicine to treat the fever, the wrong medicine may endanger the patient and eventually cause death. Now we're into class C and now our requirements are significantly higher for what's expected. So that's class A, Class B and Class C and will return to this over the next few weeks. So what is the impact of this classification? There are more requirements as you would expect from Class B and Class C software. So section 5.4 states the manufacturer shall subdivide the software until it's represented by software units for classes B and C. So this statement is coming from throughout the standard and the process must ease most rigorous is required. It must be most rigorous for software can cause more serious harm. And this is the essence of all risk classification, both at the FDA level and under standard. So, high risk software requires more work. You need to do a more detailed design. You need to do more detailed testing. You have to have smaller pieces which is the subdivision that the statement that recorded from before. And as you get from A to B to C. Or class one, class two, to class three in the FDA sense. You have to do more, higher risk software requires more detailed design requires more care. It requires more evidence to ensure that we know what we're doing. We're not exposing patients to risk that's unnecessary and potentially dangerous for them. So, what is the life cycle, a life cycle is a collection of steps, so you can see this waterfall model will come back to us in a couple slides we have system requirements, software design, software implementation verification, validation, releasing maintenance. So, the standard defines this has a conceptual structure spanning the life of the software from the definition of its requirements tweets release. So this isIEC 62304, there are different life cycles and what these life cycles essentially are different arrangements of these blocks. Do we do them only once do we do them in a cycle? Do we go back and forth? But the fundamentals are just this block, so we will talk about them in a little bit more. So the most basic life cycle and the one that everybody uses when they first start doing any kind of software work is what one could define as the code and fix lifecycle. You write something, you handed your user user to find something wrong, you fix it and you keep going around and around. This is not what you want to be using, right. This is not appropriate for a medical device, a medical product, anything that tells us to the patient, but this is how a lot of software actually gets developed when people do that amateur level at least. The standard classifies life cycles using these three characteristics here. So first we have, the waterfall and the waterfall. It's on on one shot process from customer needs to deliver it. We have incremental life cycles where the customer needs and the requirements are done once and then we do multiple cycles see judging capabilities. And then finally, we have evolutionary life cycles where the user needs cannot be fully understood at the beginning, so the requirements cannot be fully defined in front. So in this iteration will visit the whole process, so let's just look at this in a little more detail on the next table. So development strategies, the first column. Do we define all the requirements first? Do we have multiple cycles and do we distribute in terms software? So for the waterfall, yes, we define all the requirements first and no, we do not have multiple cycles and we do not distribute in terms software for incremental process. We define all the requirements first, but then we use multiple cycles. And in each cycle we implement, we test maybe we release the software and then go back and we implement a little bit more and go through a job. It's a sort of a slower, more gradual process, and then the full evolutionary cycle where we cannot define all the requirements first. So by definition we have multiple cycles and multiple releases and as we go through a cycle, we use the knowledge gain to improve the requirements to understand a little bit of the user. And this is fundamental if you know exactly what you're doing, you couldn't theoretically go for a waterfall. We're going to design the software implemented, tested, release it all in one go. The incremental process basically says yes, we can define it. But what we're going to do just to make sure we're going to release the first release, we're going to create a first version of the software that doesn't have all the features. Use that to then develop a second release of 30. So we're doing a little bit of testing as you go through. It reduces the risk potentially as well. The evolutionary cycle says, we can't, we we do not understand completely what the users need. So when mega version will send it out to them will get feedback based on that. We may have to update our designs, change the requirements, go back, create a second version of third version until we converge to something. So this is the waterfall. This is this incremental process, one step at a time and which is, it's called a waterfall because follows the flow of water down a waterfall. There's no going up here. It's on one pass through out all the steps. It's a lot or nothing life cycle. So we do not have incomplete prototypes at any point. And these are very useful testing sometimes, and they also allow identification of issues. So the waterfall assumes that you know exactly what you do. The FDA does not prescribe this though many documents use it for illustration both the FDA. The MDRF, the standard are all written as if you're using a waterfall. But that's just because it's the easiest one to explain. Let's go to the other end of this process. Let's look at the evolutionary lifecycle. Here you do an initial requirement analysis and design. You create a version of the software, you release isn't an inversion to your customers. You get feedback, based on the feedback you obtain the design. You create another version and you go around this loop as many times as you need, maybe a few times, maybe every few months. You create another version, You may release four, five, six versions until those things complete and then you release your final version to your customers. Now, again, I just what I would like you to remember as we move to the next segment here is that the different life cycles are govern how the pieces are connected. The individual pieces. How does one required to requirements? How does one design software house one implement? How does one test are the same regardless of the life cycle? It's just the arrangement that changes between the different life cycles. So, what we will talk about from here on out in this class, in this week and the rest of this class is that we're going to pretend that we're talking about the idealized waterfall model and just describe the steps. But remember that in practice the steps could be done in different waters depending on the life cycle model you choose to follow. So with that, we learn the segment, and in the next segment we'll continue our discussion of the standard and the life cycle model. Thank you.
