Welcome to Module 3 of the Johns Hopkins University Whiting School of Engineering, Foundations of Healthcare Systems Engineering. In Module 3, we'll talk about the systems engineering approach. What we learned in the previous modules, number one were healthcare drivers. The elements of healthcare, what is healthcare systems, what are healthcare services. We then look at different system types. In this module, we'll look at the systems engineering approach. This is the final piece of the puzzle, that when we get to Module 4, we'll pull it all together to show you healthcare systems engineering and problem solving using the systems engineering approach. To get started, let's talk first about a definition of systems engineering. This definition comes from the Kossiakoff book. The function of systems engineering is to guide the engineering that is the multiple pieces of a complex system to bring it to fruition. So when we guide what we're doing is we're leading, and we're managing, and we're directing the engineering team. But what we're doing with that is applying the principles of systems engineering to see the end state of a complex system. If you recall, the complex system is just one type of system. So when you see this definition realize that systems engineering can be systems of systems engineering. As well as enterprise systems engineering, where the function of the system engineer is to guide the engineering of each one of those type systems. So systems engineering, or directing, or showing the way, and we're applying engineering principles to achieve goals of either a complex system, a system of system, or an enterprise system. If you are familiar at all with systems engineering and different systems engineering approaches, you'll see that they come in different framing. They come in different cycles. They come at different rubrics. But in the end, what you're going to see is that what they're trying to do is a, try to figure out what problem you're solving. b, how are we going to solve that problem. And c, are we sure we solve the problem? And looking at methods to make sure we have solved those problems. So you can look at a spiral systems engineering approach, and if you look at the details there, there are different than what these others have. But what we're doing is figuring out, what the problem is, solving the problem, and then making sure we solve the problem. And so it doesn't matter if it's a cycle or a systems engineering V, or a linear process, or some type of Agile spiral process. We are doing the same things. We are trying to define the problem. We are trying to look at methods to make sure that we can solve the problem. And then we are performing activities to make sure that we, in fact, did solve the problem. For the purposes of the short course, this is the framework that we're going to use for the systems engineering approach. It follows very closely with what you saw on the previous slide, but just has a little bit different take. First of all, what you'll see is that we need to understand the context of the objective of the problem we're trying to solve. You saw in the previous slide, the first thing you want to do is figure out what problem you're trying to solve. The other thing that we'll look at is what type of system that we'll be looking at. If you recall from the previous module, it's very important to understand what type of system that you're working with. Next, what you're going to try to do is understand what systems do you have now that perform the function and the goals that you're trying to achieve. Understanding where you're starting is very important to make sure you know where you're going. As well as what type of gaps and needs so you can start pursuing the proper type of system context and scope. We will also look at ways to explore concepts to solve the problem. We'll instantiate that in different types of architectures which we will explain in a moment. We will do functional analysis and functional allocation to determine and make sure what problem are we solving and what options do we have. From there, we will look at the requirements. That is, you need to put quantitative measures on your functions to make sure how well you want to perform things. Eventually, you will design based on those requirements. Develop some interfaces, that is what's going to connect the different elements. Eventually you're going to get to the part where you're going to start putting it all together and integrating it. You'll need to test it, and eventually you'll need to produce it and deploy it and monitor it. So we will talk about each one of these stages in the context of healthcare systems engineering. Based on the framework that you saw earlier for the systems engineering approach, what we're now going to do is go stage by stage and talk through what each stage means. First of all, let's take a look at the baseline and the needs. First of all, what we want to understand is what is the scope of the problem. If you don't understand the boundaries of your problem, you may end up doing too little or too much. Having specific definitions of your scope is critical to solving the right problem. Also understanding the timeline. The timeline means how quickly does this project need to get done as well within the context of the project. What are the timelines? Is this something that you're building that has to be done in seconds or the decisions need to be made in hours or days? So understanding what kind of problems you're solving is key in that area. Also the context of the problem from a healthcare perspective. Are you in rural Africa or are you in suburbian New York? Where are you? As well as, are you in a hospital? Are you in a home? All that's important to figure out what type of context you have for the problem. Also, who are your stakeholders? Who do you need to work with? Administrators, clinicians, the family, the patient, understanding who you need to work with. And as well as the scope and the timeline and the context helps you figure out what problem framing items you have.
