So welcome to week seven of the introduction to medical software class. And this week, we're going to primarily focus on the process of designing the software, the actual conversion to creative plan that will go from requirements to something that can be implemented on a computer. So here is the goals for the week. We're going to talk about software design, we're going to show an example for our project. Then, we'll have a segment on usability engineering, how to design user interface is to avoid users errors, and then we'll have a segment as an illustration. Doctor Nicholas and I will present a review of an industry sector on behavioral health and how software in behavioral health is changing how it is done right now. So we have the following segments will describe the software design document. I will show a template for this just like we did for the system requires specification, and then we have a section of showing how we create this document for our image guarded neurosurgery project. Then, we'll have a segment on usability engineering, which is the design of the user interface for safety primarily. And then, we'll have a segment from Dr Nicholas as mention before and this is titled the impact analysis of emerging digital behavior, health industry and how this is changing how behavioral health is done right now. This week's material is based on chapter 13 of the textbook and as before, you'll find more details there, especially as when it comes to examples well, the details of this document. So we'll start this process by talking about the software design document and us before this is a simplified recipe. Again, it's for the needs of an introductory class and simplified, we're trying to lose all the concepts here. If you go in industry you'll see different procedures used. But hopefully, we cover the basic concept, and this is the goal of a class such as this. We are still using the V-model as a guide to the class, and now we have come all the way down to this third step. So we've dealt with use cases and system requirements last week. So this week we'll talk about software design, and what is this document? We're going to talk about the software design document. It's another bridge, and it's a bridge between the systems' requirement, specification and the actual process of coding. So this document takes the information from the senior software engineer standing on this side of the river down to the coder which still on the side of the river and the bridge is how the information is can be transferred over. It is a master document for the implementation process and depending on the classification of the software. So if you're doing link with class B or class C software, this will require, this may require a more detailed design document in addition to this. So this may be the high level document, and there may be a second document that takes that high level design and breaks down to even smaller steps to ensure safety in the process. That we have spent more time thinking about what we're going to code before we actually coded. And if you look at the flow chart from the standard, this is this the pier 5.4 software detailed design. This is the extra step that needs to happen for class B and class C. What will focus here is section 5.3, the basic architectural design, the high level design of this process. So back to a risk classification exempt from IEC 62304, sure we are oriented. We have class A, class B, and class c. Class C, the software can either cannot contribute a hazardous situation or if it can, it does not result in an acceptable risk plus B. The software can contribute a hazardous situation which can lead to unacceptable risk, but the resulting harm cannot cause serious injury and class C is all everything else. And so, we have this implode here. Increasing risk leads to increasing requirements, and that's what the previous slide was concluding on in class B and class C. We need to have more detailed design and more details. So let's begin with the actual process and let's look at the outline of the process and the six steps at least in my mind characterize this process. We first read the system's requirements document, that's the input to what we do. We reviews, the use environment to see if they have any fundamental constraints. For example, if the use environment means that it's going to be used in a portable situation, this may mean we have to be on the phone. These changes completely software design process and if you're using a desktop, so the environments often create fundamental constraints that change everything that's going to follow. So you review the user environments to make sure there's no fundamental constraints introduced in the process. The next step is that we construct work close to satisfy each requirement. And again, a workflow is just a list of steps, so I need to be able to do task aid. Then, we break the task into the four components of the task and this is the workflow to accomplish requirement A. We have to do one, two, three, and four. We create workflows that step by step, workers through the process. And it's good if you think about soft, reducing the mission critical sense to break down things into workflows step by step, considerations of how it's done and not just create the software can do anything and react to user. We're not designing micro software here usually, we're designing something that's a focus task where a small number of focus task and constraints the user in a particular way. With the workplace in mind, we can now then create the overall software architecture. This is schematic of all the big modules and how they interconnect. We create sketches of the user interface, and we have to worry here about legacy issues. Software that does this typically look like this, then our interface should adhere to that convention. And then, we check if we need to use any external libraries, and we identify this, and this is a very important part of the software process. The components that we will create versus the components that we will use from outside ready-made. A regulatory background here comes from three documents, the IMDRF QMS document. This is the application of quality management systems. This section 8.2 on how we design software, the GPSV. The general principle software validation from the FDA and this section 5.2.3 and the standard IC 2304. And here we're looking at particular sections 5.3 and 5.4 of the standard. So well do a quick recap of the regulatory process next here. So the guidance from the IMDRF suggests that the purpose of this designer's activity. The software design is to define the architecture components and interface of the software system based on the user requirements and any other performance requirements in line with the intended use of the SaMD software. Is a medical device and the various clinical and home and use environments it is intended to operate in. So this just gives us our guide effectively. This is what we're trying to do, and these are constraints. The GPSV, section 5.2.3 has some more comments that are useful. The software design specifications, a description of what the software should do and how she do it. The completed software design specification constraints the programmer or coder to stay within the intent of the agreed upon requirements and designs, and this is important. The reason we have this design is to make sure the program it does what they're supposed to do. So we don't end up in the game of telephone where they hear one thing, and they do something else. We give them a plan, so they can follow that plan and makes life easier. And in addition to ensuring we do that, I think it really does make life easier. It will be a complete software design specification, will relieve the programmer from the need to make artwork design decisions. Program is stressful enough, is a hard enough job, and so it's best if what needs to happen is well specified. So the program can just follow the design and implement the pass interval. If they now have to make decisions in addition to implementation when they are in the situation of the telephone game, their decisions may not be what they intended decisions of the previous part of the process ware. The GPSV has a few more comments, and this has to do with user error caused by designs that are overly complex or contrary to user's intuitive expectations for operation is one of the most persistent and critical problems encountered by the FDA. Again, remember the software will be used by people, sometimes on little sleep in high stress situations and as such should be easy and intuitive to use. Intuitive here, it doesn't necessarily mean intuitive from the perspective of the intuitive. You mean it should look like other software they use and the button colors and the word things should match other tools that they use because this will let them be intuitive. It should be easy to use because it looks like other things of you. So a piece of software, there's a radical redesign from what the users have used before. May have much confusion and errors and this is not an internet probably well, you know, they'll get used to them in the process of getting used to them. Real patients could suffer. Finally, we get a section, IEC 62304. This will conclude regularly review here and this is the vision of something called a SOUP, not the food, but SOUP means Software of Unknown Provenance. It's off-the-shelf software. This is software previously developed for which we do not have adequate truckers. This could work, but please realize that we are responsible for all the components of our software, including those that we did not write ourselves. So we must identify all the SOUPs justify why they're being used and describe the process to ensure that they behave correctly. So the SOUPs are effectively external dependencies of our software, right? This is a library to allow us to connect to the parks or a library that implements HL7 or a visualization library. This is software that we obtained from outside. Often these are open source tools that we just download and use, but we have to be careful because the company that puts together the software, the medical device manufacturer, is the company of record. They're responsible. We are responsible for these components, whether we wrote them or not. So we have to justify where we're using those subs, and we have to ensure have to put the testing regiment around them to make sure they behave correctly, and we validate them for the needs that we have for them. So this concludes this introduction to software design document. In the next segment, we'll continue our discussion and look at a template for this. Thank you.
