Okay, so in the second part of our guided tour of medical software, we look at the bargain of the process. Now we ended up, we stopped last week at the requirements. What a software has to do at an abstract level to meet the needs of the user. And now we're going to talk about the bargain of the process, the software design, the testing, and then the supporting processes that are involved in doing that. So first we'll talk about software design as an example of a software. Architectural design is for our image carry neurosurgery case study example. We'll talk about this in week 7, and what you're seeing here is three pieces of software. The thing that the session losing the operating room, let's call it part A, part B is a bag and database system, part C is what will be used outside the operating room to plan the procedure. The boxes in blue are the modules, they're the big functional components of the software and the outside world here represented by the hospital database and the tool tracking. What you're seeing these lines is how these modules will communicate what talks to the outside world and what the piece of software look like. With that high level design, we also produce an initial design of the user interfaces for tools A and C the user facing tools. And they might look something like this is my sketches, this one at the top is inspired by the brainlab VV cranial system. This is what it looked like 15 years ago they one at the bottom is from our own open source work with the yield by mystery software package. The next step after your design you have to implement and test your code and testing is an interesting process and in the beginning you want to find actually lots of things. If you're not finding bikes in the beginning of testing, you're not testing correctly. But you want that flow to go down, you want this curve to decay. So in the beginning you find lots of parks that means that you're testing process is robust and it's catching things. But by the end you want that number to go down, which means that you're actually fixing them, catching and fixing them you're doing a good job. In week 9, we'll take a detour from the actual software life cycle to talk about math and probability statistics decision three. A little bit of an introduction to all of those topics that underlie the development of medical software. A key processes this process of signal detection. What you're seeing on the screen is a radar screen here and you're seeing this blip that will appear here and the radar operator and think yourself back to World War II when these things were introduced. Is that an enemy plane to have to scramble up a fighter to defend my area against that or is that noise and I just don't do anything. And obviously there's a cost of doing something, if it's not a plane you're wasting fuel, your wasting resources. And there's a cost to not doing something when it's in fact a plane you get bombed. So a lot of the issues with decision theory is this trade off of the cost of action versus the cost of inaction. And the same of course applies to the medical world, the medical software, let's say that are piece of software is measuring the likelihood that you have a brain tumor. And we have a number from zero to one, one we're sure there's a brain tumor zero, there's no brain tumor. At some point you have to say that the threshold and say, well, anything about 0.7 will call the brain tumor, I think below 0.7 we're not going to call it a brain tumor. And the trade off the way you said that value of 0.7 is how many tumors can you afford to miss? And versus how many times can you afford to have somebody be told that they have a tumor and all the extra medical procedures that, that will involve when in fact it's not a tumor? So this is what's called the trade off between sensitivity missing things and specificity, when you say that there's something there it is in fact there. So this is a key problem in medical software and we'll spend some time talking about in week nine. It also underlies how we valued machine learning artificial intelligence algorithms, we try to detect things in images. Did something happen? This is a kind of thing we're talking about. In week 10, we'll talk about validation, validation again, we'll talk about this in more detail again later. But validation means that our software meets the needs of our user and we'll talk about a medical piece of software in is that it does something useful in the clinical world. And this breaks down into three steps. What the FDA calls, Valid Clinical Association is a software measuring something that's relevant to the diseases. If a disease is prostate cancer and we're measuring tumor volume of a lesion maybe that's useful and relevant, if we're measuring something and related to disease, this is a waste of time. So this is the first step showing that what we measure is actually relevant to the disease. The second component is Analytical Validation, the thing we measure that is relevant to the disease, we're actually measuring accurately, and this is what analytical validation means. And the third step is what's called Clinical Validation, the thing that's relevant and that we measure accurately in fact is useful for some clinical procedures. So those are the three components of the validation process and we'll come back to this, especially in week 10 when we talk about validation in more detail. In week 11, we'll begin to talk about machine learning and artificial intelligence. And this is revolutionizing the medical software field, it's beginning to allow us to solve problems that we didn't know how to solve before and you can see a workflow here that the up parent is what happens in the lab. We have data, we split to training and testing data, we learn an outgoing and then we apply this alchemy and performance side with a different set of data to get proper deployment and monitoring. And this is an evolving area, we're still developing best practice for it, the regulatory world still discovering how to do it. We have some ideas and you'll see some documents in week 11 from various countries, but to say that this is an area that's in flux and the agencies are also trying to figure out how to do it. And a big challenge in particular is that with all of these machine learning outcomes you need more and more data. And one way to get more data is to update a system in production, every time we get a new image that we classify, we added to our database as in your example. And how you manage that safely without introducing more problems is a challenge that everybody's trying to figure out right now. And finally in week 12, my colleagues Dr. Khalid and Dr. Nicholai will talk about business considerations, medical software. We'll talk about the changing models and healthcare, the nuts and bolts of start the new healthcare adventure, and when and how to raise capital and related issues that you're going to do. There are lots of opportunities for software, digital health to redefine how healthcare stand. The recent pandemic is changing health care with telehealth and other issues and there's lots of opportunities here and this is an interesting area to think about. For those of you who have no interest in doing a start, giving us why do I need this? And the answer is, in any organization you work, you may not be directly responsible for raising money or intellectual property or meeting customers, but this is what your bosses, your manners are worrying about. So this is important understanding what your organization is doing, even if you're not directly responsible. I think you'll find this part useful as well. So this concludes our guided tour, in the next of menu, we're going to begin to talk about the regulatory process and introducing concepts from there.
