In the second segment we'll begin our guided tour of medical software. We're going to do the first half in this segment in the second half in the following segment and we're going to walk through the process and give you some highlights. These are all topics that we will revisit in the remainder of this class. So we will start as all of these things start with the regulatory process and in the regulatory process is a figure from the IMDRF untouched a medical device regulars forum. We have a classification of software from class one to class four depending on the risk involved. So, if you take the software and we classified according to variables, it's the importance of the information that the software provides the doctor. So is it actually immediately affecting diagnosis appear or is simply informing clinical management down the road and the severity of the situation of the patient. Are we talking about somebody who's a non serious situation where we're talking about somebody who's in a very critical condition. So if the software is the further you go to the upper left, the classification goes from one to four. And the regulatory process will change as you move from a low risk piece of software class one to higher risk piece of software class four. And this affects everything we will talk about. So the risk classification of the software defines the rest of the presume will come back to this classification multiple times. They're slightly different systems one two three, one two four, A B and C. But the fundamental principle is the same, low risk, low requirements, high risk, high requirements. The next step in addition to the regulatory environment in week three here we will talk about the healthcare environment and data privacy and security. So in the healthcare environment we have all these players that are involved in the delivery of health care. We have points of here doctors, hospitals have players with insurance companies or governments, clinical support, business associates IT services. Others position and law firms, life insurance companies, all of those people, maybe your customers, maybe your users when you work in medical software. So keep that in mind, it's not just doctors and nurses is a lot more. And the second part is the data privacy and security issues that happen in the medical space. So these five points or the five steps in the news framework for cybersecurity identify protect detect, respond recover. And we'll talk about data, private security cybersecurity and that will come in week three of this class. With that, we're ready to start now thinking about how to organize the process and the next step is a quality management system. This is the rule book for a company and this divides into three levels. The discussion of the leadership of the company and the support personnel infrastructure work environment. The next second level is the support processes, how the company has planning measurements, configuration documentation. All of those are processes are the same for all software projects. And then they're in the loop is the process of specific to our specific software projects, requirements, deployment, maintenance, retirement, designed all of that above. And again, this comes from a regulatory document from international medical device regulators forum. The cure mess is what defines how company or president remember we're doing serious projects often dealing with people who are very sick and serious software requires serious processes and this is our rule book. The next step and we're still in week four of the classes. The other part of the management standards of what's called the management standards is the risk management process. And any time you see this symbol here, the radiation symbol there, we're going to be talking about risk management and it would be a companion throughout this class. So we'll talk about risk analysis, identifying what can go wrong, evaluating how bad can it get risk control. What can we do to reduce the level, to reduce how bad it could be? And then evaluation of what the risk that's left after we take in our measures. So any time you see this icon up there will be talking about risk management, and risk management would be an ever present companion in this class. Will be talking about risk management, we design our software. We'll be talking about risk management. We called our software. We're talking about risk management. We test our software when you install the software. When you retire software, every step of the process will always ask the question, what can go wrong here? And at that point, we'll engage in the risk management process because that's how serious projects work. We'll talk about the medical software life cycle. We will begin this process in week five and work our way down this v model. And each of those things that you see here, each of the circle things will be a week of this class. So we'll talk about user needs and system requirements, software design, implementation and testing, validation, deployment, maintenance, retirement. And this will stay with us now, underlying this process, of course, is the quality management system and the risk management. Those are the supporting infrastructure that allow this to happen outside of the quality management system and the risk management system. This life cycle makes no sense, and this is what's known by the standards. To illustrate the process will do a case study and we'll use it to explain how software is designed and to some extent implemented. And we're going to use this case study of image carry neurosurgery is an area of worked a little bit before. And think about an image carry neurosurgery system as a GPS type system for brain surgery, allows the surgeon to see images of the patients at the same time as when they are operating. So here's what the system looks like. It's a picture of a brain lab system from here and you have a hospital can see the screens here. So this is a software, at the top we have these cameras that will be looking at the surgical tools. So here's a zoom picture of our surgeon, he's holding a tool in his hand here. This is the patient is an exposed brain, if you've never seen exposed brain, that's an exposed brain. This is a surgical pointer. So when he touches the pointer, these sensors here attract by the camera and the position of this point here is shown on the screen. So the surgeon knows where they are at any given point. And this allows them to organize the surgery to know how far they are to the left or to the right or any candles. So this is a case study will use it to identify user needs requirements to design our software and this will follow us for a few of the weeks of this class. So the first step of the process is to figure out what our users need. Now, you can go and talk to your users and they might tell you what they need or they might tell you what they think they need. And most of the time that you're going to get the immediate information. This is what's bothering me right now, this is what I think my problem is. Your job now as a designer is to take that information and abstract it and figure out what is it that they really need. So, if we look at this chart and this comes from a book by Robertson & Robertson on the requirements process, you'll see that the process starts with this thing called How Now? We are at the bottom of this pile scale. How are the users doing what they're doing right now? So you go, you observe them, you look at what they do, you ask them questions. But really your challenge is to go from how now to what now? So, you want to move from this concrete face down here, this is the concrete to the abstract. If we take a simple example that I will return to multiple times in this class, how now maybe that the using alone were to cut the grass, but really what now they just want the grass to be short. So if they had another way to keep the grass short, maybe they'll be just as happy. So we're moving from how now the details of what's going on, what you can observe to what now, getting an understanding of what's going on. And then what now becomes toward future, what more would they like to be able to do. Again at this abstract level, not only do I want my grass to be short, but I want to look a certain way, I want to have a certain color. And then we use that information to go back to the real world into the concrete space, to think about how future. What are we going to design house, I designed going to develop to allow our users not only do what they need to do now, but what they would like to do in the future. And so, we're going to have this constant interplay between the concrete and the abstract in this business. Embedded in this problem is this challenge of communication and the way to I understand this. The easiest way to explain it is this children's game called telephone you may have played as children yourselves. We have four children in a role as industry in this picture. And the first child whispers something, the ear of the second child say computer park. The second child tries to whisper to a third child what they heard, too much like computer pass leave a mark. And at the end of the game, the last child tells the first class what they heard and they compare. And they all have a good laugh and so very funny and that's lots of amusement, but let's transpose that now into our world. The first child here might be a user. This is what they need. The second child here is our analyst. The person who doesn't talk to the user and try to figure out what the user needs. The third user might be a senior software engineer who has to design the software and maybe a fourth user is a programmer who has to implement the software. The challenge in this process is that what the programmer produces should match what the user needs. Obviously, if we end up in a situation like the game of telephone where what the program that produces only vaguely resemble what the user needs to have failed. So this is part of this problem of checks and balances of documentation, of reviews, of written documents, written designs that are necessary to ensure that our final piece of software meets the needs of our user. Because if it doesn't, we have a perfectly good piece of software is utterly useless for the needs of our users. So an example that people give is, our user wanted a car and we've designed the best bicycle in the world, still not a car. So we have to be careful. So these issues of communication are critical and they will. It's a challenge in any multidisciplinary setting. Any place where lots of people involved. The way we think about the needs of the user is through the use of usage scenarios. And the way to understand usage scenarios again, to use another children's game, there's a game clue or concluded that some of you may have played as children is a family favorite. In our family is to think about this game where the goal is to figure out who perform a murder in which room with what type of weapon. And so people navigate across the sport. They get to check, they ask questions and goes on and on. So here's a classic solution. Here the solutions that Colonel Mustard give the murder in the ballroom with a rope. So this is the proposed solution to this problem. Now, if you look at this example, you're seeing who, where, and with what. Now the missing aspect of this is the what, what it Colonel Mustard too? Well, Colonel Master of course did the murder. But this is the basis of us understanding usage scenario in the real world. In your assertion would like to be able to do tumor resection in the operating room and they're using a touch screen computer in addition to their sexual tools. Who, what, where, and with what? Those are the basic questions that we use to identify whether usage scenario. This is the basis for our software design. So in the beginning you have to identify who your users are, what they want to do, where they're doing it, what tools they need to use, what are the constraints they are under. And that's an incredibly important. So to just make it more concrete who, what, where, and with what? Back to clue, a user is neurosurgeon the what to navigate during a brain epilepsy neurosurgery procedure. This means being able to see the position of the surgical pointer on the anatomical camera image of the patient, the intended use environment in the operating room using a task in computer mounted at eye level. So this defines the usage scenario and from here now we can think about designing a software. So what we need to do in order to accomplish to implement this usage scenario? Well, one of the things we need to be able to do is get the anatomical MRI images right there, part of the description. And so the usage scenario naturally lead us to the requirements. So here's the first requirement the system shall. This is the magic formulation. It's like the 10 commandments, shall be able to successful import images from the hospital database service called the PACS. If you need to navigate on top of images, you need the images or a requirement. The thing that the software must do and we'll have a long list of this requirements. One of them is they have to be able to get an image. So this concludes the first half of the medical software tool. We've gotten to the point of what does our software need to do in an abstract sense? In the next segment, we'll take a look at the back end of this process and from what is it that needs to be able to do. We figure out how it will be doing, how well tested, and all the other things that are involved in this process
