Healthcare organizations today are often described as “complex adaptive systems,” but for many executives and clinicians, they simply feel like chaotic tangles of disconnected processes. As hospitals merge into massive conglomerates and technology stacks grow increasingly unwieldy, the need for architectural clarity has never been more urgent. Enter Systems Engineering—a discipline born in the high-stakes worlds of aerospace and defense, now poised to revolutionize how we deliver care.
In a recent episode of the Strategy of Health podcast, host Cole Lyons sat down with Dr. Dr. Matthew Montoya , a distinguished professor of Systems Science at The Johns Hopkins University, to discuss this critical intersection. With a 40-year career spanning applied physics, defense, and public health, Dr. Montoya brings a unique, "Renaissance" perspective to the industry. His insights reveal why traditional management techniques often fail to solve healthcare’s wicked problems and how a systems mindset can turn organizational chaos into streamlined, patient-centered outcomes.
Systems Engineering provides the structural architecture and clarity necessary to solve complex, multi-stakeholder problems that traditional specialization cannot address. While medical education typically incentivizes deep specialization—focusing intensely on cardiology, neurology, or oncology—organizational problems rarely respect these boundaries. They spill across departments, technologies, and workflows. Dr. Montoya argues that the primary value of a systems engineer is the ability to stand in the middle of a "cloudy mess" and orchestrate a solution that accounts for every moving part, from the initial need to the final patient outcome. It is not about knowing everything about a specific medical niche, but about understanding how the pieces fit together.
"Part of my DNA is creating clarity out of chaos. And so systems engineering is a tool that allowed [me] to do that... bringing clarity to a problem and providing outcomes." — Dr. Matthew Montoya
In healthcare, where "clarity of communication" is often a struggle, this approach is transformative. By focusing on the entire lifecycle of a problem—defining the architecture, establishing metrics, and mapping the roadmap—leaders can bridge the gap between disjointed departments and ensure that the "widget" they are buying actually solves the underlying itch.
Systems Engineering focuses on the technical integrity and architectural validity of the solution, whereas Project Management focuses on the mechanics of execution, such as budget, schedule, and resource allocation.
This is a common point of confusion for executives. Many assume that a strong project manager can fix a broken system. However, while Project Management ensures a project lands on time and within budget, it does not inherently ensure that the solution is technically sound or that it will function harmoniously within the larger ecosystem. Dr. Montoya explains that while the two disciplines are inseparable and must link together, they serve different functions. The systems engineer is responsible for the "technical aspect," ensuring the inputs, outputs, and component interactions actually work.
"The project management, I view that as the, I'll say, process and product mechanics, which is budget, schedule, um maybe resource allocation, where the systems engineering is you're working on the technical aspect." — Dr. Matthew Montoya
For healthcare leaders, understanding this distinction is vital. If you are trying to integrate a new EHR across forty hospitals, a project manager will tell you when it will happen; a systems engineer will ensure the data architecture actually supports clinical workflows across those diverse sites.
The most effective way to implement systems engineering in large healthcare organizations is through "pilot efforts" that test the ecosystem on a small scale before attempting a system-wide rollout. Attempting to overhaul a massive health system’s operations in one fell swoop is a recipe for failure. Dr. Montoya warns against trying to "eat the whole elephant at once," noting that top-down mandates often generate significant resistance from the staff who actually have to do the work. instead, leaders should identify specific patient outcomes that involve two or three specialty areas and build a "systems ecosystem" around that smaller scope.
"If you can create these key principles... do it on a smaller pilot effort and check the outcomes... This allows you to create a more enduring ecosystem, try it [at] a smaller level, and then you know expand it to other areas as you're able to." — Dr. Matthew Montoya
This approach mirrors the scientific method: frame the problem, test the hypothesis (the new process) in a controlled environment, validate the metrics, and only then scale up. This "pilot" strategy not only mitigates risk but also creates internal champions. When a pilot works, "word of mouth from those folks can carry on to others," organic adoption often follows.
Artificial Intelligence is a powerful tool for initiating collaboration and crowdsourcing potential solutions, but it is not a replacement for critical thinking or human architectural design.
As AI permeates healthcare, there is a temptation to view it as a magic bullet for efficiency. Dr. Montoya views AI fundamentally as a set of algorithms—tools for problem-solving that can handle complexity far better than manual analysis. However, he cautions that these tools can give "absolutely completely wrong answers" if not shepherded by human expertise. The true hidden value of AI in systems engineering may actually be social rather than purely technical. Dr. Montoya suggests using AI tools to bring disparate teams onto the "same sheet of paper".
"If you can have an AI tool that can bring people to better collaborate, you're able to solve the problem and start addressing the problem as a team." — Dr. Matthew Montoya
By using AI to generate initial scenarios or process maps, teams can stop arguing over blank whiteboards and start refining a shared starting point. It democratizes the problem-solving process, allowing for a "middle-out" approach where top-level architecture meets bottom-level "boots on the ground" reality.
Systems engineering is highly effective for device development and process improvement but should be applied with extreme caution in direct clinical, patient-provider interaction. There is a time and place for rigorous engineering logic. If you are designing a new medical device or optimizing the supply chain, the "needs/requirements" framework of systems engineering is indispensable. Similarly, general organizational processes—how a patient moves from admission to discharge—benefit greatly from this structural view.
However, the exam room is different. Dr. Montoya warns that the "personalization associated with working with patients" does not always fit neatly into an engineering schematic.
"You want to be very personal and make sure that you're clear on the outcomes of the patient... [Systems Engineering] is not as clear cut how you use it [in clinical interactions] as the other two areas." — Dr. Matthew Montoya
Executives must recognize this boundary. Over-engineering the human connection can lead to clinician burnout and patient dissatisfaction. The goal is to engineer the system to support the human, not to engineer the human out of the system.
Building a systems culture requires a blend of formal education and "on-the-job training" (OJT) within safe "design thinking" environments or sandboxes. You do not need to fire your staff and replace them with engineers. In fact, Dr. Montoya argues that the most effective change agents are often clinical staff—nurses and doctors—who are cross-trained in systems principles. These individuals already have credibility; they don't trigger the organizational "antibodies" that often attack outside consultants.
"If you have a clinical staff... and you can show them the systems principles, they can carry these things through... that really carries much more weight." — Dr. Matthew Montoya
To start this journey, Dr. Montoya recommends creating "design thinking workshops" where staff can practice these concepts away from the high-stakes pressure of the operating room. This allows teams to "build the bridge" mentally before they have to walk on it physically.
If you are a leader looking to introduce systems thinking to your organization, do not start by buying new software or hiring a fleet of engineers. Start with education and a single problem. Dr. Montoya explicitly recommends Peter Senge’s book, The Fifth Discipline, as a foundational resource to help your team understand the mindset of interconnectivity and dynamics.
Your Next Step: Identify one recurring "cloudy mess" in your organization—a specific friction point involving at least two different departments. Instead of applying a quick fix, form a small cross-functional team (a pilot). Have them map the inputs, outputs, and architecture of that single problem, focusing on clarity over speed. Use this pilot not just to fix the issue, but to prove the methodology to the rest of your organization.
<p>For those folks that are in that area, I would say do learn the principles and know how you can apply them. But you know, you want to be very personal and make sure that you're clear on the outcomes of the patient and how you're going to be using them. [Music] Hello everyone and welcome to the strategy of health podcast from the American Journal of Healthc Care Strategy. My name is Cole Lions and I'm joined today with Dr.</p> <p>Matthew Mononttoya who is the professor of of system science uh among many other things a very long and impressive career history at John's Hopkins. Uh Dr. Mononttoya, can you please just introduce yourself and tell us a little bit about uh what you're working on now and your current role? >> Sure, absolutely. Hi, Matt Matoya. I appreciate being on the podcast, by the way. And so, um, I was thinking about this, the idea that I've been at Hopkins for 40 years now. So, this is my 40th year.</p> <p>I started in the Hopkins family in the in the mid 80s. And so, I've transitioned recently into uh healthc care systems, but I worked uh several decades in other areas focusing on on health. And so part of what I'm trying to do now is bring the systems science, the systems thinking, systems engineering to healthcare. Um and that comes in a variety of forms. And uh one of the great forms is um lecturing uh working with uh people who are interested in this.</p> <p>But also then looking at the next level of health care systems in terms of introduction to AI and the tools associated with AI and improving processes and outcomes. Um, so that's what I'm currently doing. >> And you have an impressive amount of education and I just wanted to kind of go over some of it here.</p> <p>You have, you know, mathematics, a graduate degree in mathematics and systems engineering, uh, as well as a doctorate in systems engineering, a masters in public health and and a master's in business administration. I have to ask what caused you to get this amount of education?</p> <p>And um and so um part of what I what I I think about is early on in my life and I don't want to get too far into this, but early on in my life, I was always very uh kind of eclectic and uh you know, some version of a Renaissance person. I always liked blending different pieces together. So you know, back in high school, I did well at u mathematics and physics, but I also played instruments. I also did sports.</p> <p>So, I love doing all these eclectic things and zeroing in on something just wasn't in my DNA. And so, as I started my u college venture, I started in uh the college of of physics, natural sciences, but I didn't want to be bound to that. So, I had an applied physics degree which led me to engineering and other mechanical and electrical engineering as well as I found that I could get a minor in mathematics. So, I did all that in my undergrad.</p> <p>And so as I continued on my journey, I learned that as I became more acquainted with the concept of systems, it started with systems analysis.</p> <p>I went into more mathematics background as well as zeroed in on systems engineering eventually u started doing more business aspects as I started getting involved in more of a management of larger portfolios and then eventually as I'd mentioned as I'm in health now I wanted to be more aware of u I'll say healthc care thinking and then all the context of health care so I decided to get an M PH as well so it's kind of part of my DNA how I solve problems how I attack problems And I love looking at larger context and solving the problems that make sure that stakeholders and other factors are involved.</p> <p>>> And I appreciate that a lot personally because I also feel like in order to kind of solve problems, you do have to have a pretty solid understanding of kind of the periphery and what's happening around that. And we've discussed that actually in systems engineering class that I'm taking with you which is >> you have to as a systems engineer understand a bit of these different disciplines that's happening.</p> <p>>> One of the first questions I wanted to ask you though is why systems engineering because even with your engineering background and the kind of healthcare degrees and business degrees there's a lot of executives who have that background. there's a lot of uh public health workers and public health officials who have that background. So it feels like something had to have been special about systems engineering for you to want to kind of delve and and kind of practice in that area.</p> <p>So what about it struck that kind of spark for you? >> Sure. I appreciate that.</p> <p>the for me the idea of the larger problem solving I again part of my DNA is I did not want to get locked into working on one specific problem and so as I looked at solving problems I found that as those focus areas touch other areas I was able to contribute and provide more value to the organization as well as provide more insights uh to the problem and so as I think about this and I just think of my journey uh in systems engineering it came in a sense somewhat naturally and I think of um uh as I look at problems the idea of looking at and you and we've talked about this in class the idea of endpoints context the the roadmap to solving problems and I think u my value and contributions at a APL as well as Hopkins over the years has been able to dive into different problems um and solve them where they're very complex because as you dive into a problem um and a lot of people experience it's it's just a cloudy mess of of confusion and people um you know asking for things and so clarity and so part of my DNA is creating clarity out of chaos and so systems engineering is a tool that allowed to do that electrical engineering mechanical and other these special areas like allow you to focus but bringing clarity to a problem and providing outcomes and specifically within healthcare you know outcomes are such an important piece and so many different elements within healthcare and again same kind of thing so many areas that are kind of kind of talking and trying to bring focus but you have to bring the clarity to the overall problem patient output or tools provided to the clinician or whomever.</p> <p>I know that in a lot of healthcare organizations that clarity of communication is really something that they're still kind of developing and struggling with. Sometimes things that have already been solved in the business world are still not really solved in the healthcare business world and I think that's with good reason.</p> <p>I wanted to kind of ask then what are some examples of whether it's work you've done or work that you've seen when it comes to systems engineering that has you know benefited a clinical outcome or or healthcare like what what are some examples of this that our audience can relate to? Yeah.</p> <p>And and I'll give a little bit of context to my answer here, which is as you think through the systems engineering uh I'll call it the life cycle when a product or a capability um or process is being generated u there's a sequence that you will go through in order to generate that.</p> <p>And so part of um what I've done over the uh years is be able to kind of plot myself in the middle of that context to get it be at the beginning of the problem, the end of the problem, the middle of the problem, and be able to kind of work my way through all the the uh elements.</p> <p>And so um I've worked on um some uh defense related health as well as private health but I'll pick on a specific defense related health uh area where u part of what we were doing is coming up with a um and I will just use kind of a generic term kind of a crash desk dummy um generically speaking there's more technical terms than that um but part of what we're trying to do is develop a more accurate uh version of that for division within the Department of Defense.</p> <p>And so within our organization, they really struggled bringing all the pieces together. We had easily a dozen subcontractors. They were university performers we called them and they were from from top-notch universities across the country. And uh what we were trying to do is bring that uh capability to realization uh for uh DoD. And so um I had gained a reputation within uh JHU to solve these larger problems. So they approached me uh to be able to jump into this team and be able to do that.</p> <p>I had uh limited to zero experience in this particular area but they knew I could solve large complex problems. And so jumping into this problem I was in the middle of it. They had kind of put some concepts together. They had worked with their university performers um and they developed some um technical capabilities but my job was to bring it all together.</p> <p>So I had to think through um in terms that are are are in the vernacular systems engineering think through the architecture of what the problem was going to be. Think through the measures and metrics that actually mattered associated with this particular capability. Um, I like to think of the outcomes, you know, what kind of outcomes needed to happen and that can be in terms of product or it could be in terms of of analysis or reports.</p> <p>And so I had to create this architecture with the performers with my internal team. Um, in a sense it's kind of like brid building the bridge as you're wa you know as you're moving across it.</p> <p>And so being able to look at the ideas of requirements, looking at the idea of creating measures and metrics and how they all fit together so that you can create this one um uh capability um brought to me, you know, I've done lots of things over the years, but this really crystallized the ability of a systems person to jump into any problem um even if they have limited technical background in that particular specialty area and be able to create a structure to it, bring clarity to it, create a road map, um create touch points, clarify metrics, and drive that capability to the end.</p> <p>Um because a lot of this is an orchestration. That's some of the terms that we use in in systems as you're you're creating this, you're orchestrating all these performers and outputs and capabilities. And um it's not for the faint of heart, let me tell you that. because as you go through this process, um there's a lot of people uh kind of nipping at your heels and and uh uh sponsors and other customers, you know, giving you an earful of things.</p> <p>And so, you really have to keep your head as you're moving through this. But that to me within the healthcare arena was one of the more interesting and and really stressing the systems capabilities to be able to drive something like that. And it was a successful outcome. um and I probably did some accelerated aging at that point in my life from from that from that uh endeavor.</p> <p>>> So some of the questions I think especially at the the executive level as health systems are getting more bigger and complicated, right? People are wondering how to avoid running into these issues where you have kind of some really intelligent and some of the best people but they're they're not operating as efficiently. they're not actually solving the problems because of a lack of this kind of cohesion.</p> <p>The question that might come up from executives is what is the difference between systems engineering and really good you know project management? How do you separate those two things? >> Yeah.</p> <p>And I um the the way that I look at it that they're they're inseparable because the project management I view that as uh the um I'll say process and product mechanics which is budget schedule uh maybe resource allocation where the systems engineering as you're working on the technical aspect but that's so important to link into the resources if there's risks associated with it you have to work with the project management you if there's uh technical resources that you need you need to work with the project manager So they're linked together.</p> <p>However, the idea of how do you accomplish this technically um health care is one of the more difficult areas because this has been going on for decades if not centuries in some cases where people are incentivized and specialized. And so people come in and they're especially in cardiac or specialty in something else. And so they're incentivized in these particular specialty areas.</p> <p>And so if you come in with the systems mindset trying to you know have an outcome in a you know more of an integrated outcome that is a difficult uh barrier uh to overcome. And so part of what I look at is um there has to be and I use the term a pilot effort kind of a smaller effort um to get these kind of concepts over.</p> <p>So part of what I think through maybe there's a specific outcome um that people are interested and I and I will say a patient outcome and so maybe there's two or three specialty areas uh that play into that outcome and so you can do a pilot effort with these concepts and I used uh ar I've used the terms already architectures metrics um um kind of process outcomes and work through kind of a a smaller effort to see can I create this systems ecosystem at a smaller level and deliver some of the outcomes that expect as opposed to trying to eat the whole elephant at once which has you know you may have a hospital and you have you know you know 87 different specialties and you're trying to do it all at once.</p> <p>So if you can create these key principles that I'm describing, do it on a smaller pilot effort and check the outcomes and that's uh part of what um is and you've heard the term six sigma and that's something that they do is they'll look at the outcomes and they'll check the metrics associated with it but creating that overall ecosystem and architecture and a process approach um goes beyond just kind of a six sigma thing here and this allows you to create a more enduring ecosystem.</p> <p>try it at a smaller level and then you know expand it to other areas as you're able to. But you know trying to orchestrate all these things all at once at an executive level um that's undoable. Um and a lot of times when you have a top down push there's a lot of resistance from the people who are actually working. So you have to be very careful how you do this kind of work a top down concept but then do a lower level um pilot to to try it out.</p> <p>And then once that pilot works, assuming it works, hopefully it works, then um then that word of mouth from those folks can carry on to others uh which again I've seen that happen um on many occasions.</p> <p>I've found because I've you know I have my green belt and six sigma and I've uh mostly made it through my black belt and I've done some project management work and what I found with the the systems engineering even in just this first course is when you talk about the technical aspects compared to the financial and the management aspects you we're getting you're getting really technical right we're not I think in in project management or in six sigma you do sometimes track inputs and outputs but this goes really beyond that to actually looking at the components and the functions of those components and also how they interact and move that data.</p> <p>>> Yes. >> My question is why isn't that already being done as why are you getting called in at the middle or the end, right? Why is why isn't it like a standard thing from the beginning of all the projects? >> Yeah.</p> <p>And that's common and you know it's the it's the good and the bad where you know I have I've loved um helping people and fixing things but part of what I love to do is create and carry this message because um part of what happens in problem solving is people want to rush to the end and we've talked about this during some of our lectures is people will say I have an itch so here's a widget that's going to you know address the itch where really you want to start creating through a more repeatable process because if you just bought the one widget and then it's not repeatable and you can't figure out how I'm gonna create another buy another widget for whatever reason.</p> <p>Um, you've only solved one. It's like a whack-a-mole thing. So, what you want to do is create more of an enduring process. And so, part of what we're doing in our healthcare systems engineering program is bringing these concepts of systems problem solving to health care. And um just like I mentioned in the pilot effort um so it's like one one organization or one student or one effort at a time um because you can't do it all at once.</p> <p>And so part of our message is think you know sol be very clear on what your problem statement is. Be very clear on what your need is because so many times people think they need something and at the end state they realize that's not really what I needed. And so spend a lot of time in the clarity of the problem statement and then uh the context and of the problem and then what the way I like to solve problem is do that beginning point and then the end point. What are my outcomes?</p> <p>What are my measures and metrics and then you build this bridge between the two and then these processes that you're describing in the detail technical pieces. Those are the tools that we provide uh the students so that they know how to build that bridge as they start crossing it.</p> <p>when it comes to what you're saying which is you know we got to start with one student one small project one hospital what do you see the future as being when it comes to you know we have AI which is going to change a lot of things but at the same time you have these huge systems like advocate health which have 40 hospitals and you know 5,000 offices these crazy amounts of things >> that is a kind of a system of a system >> so where do you see the future of the profession going when it comes to both AI and these larger kind of almost monopolistic systems, these huge systems.</p> <p>>> Yeah. And um unfortunately uh I've I've seen and lived and and experienced some of these things um not only as a as a systems engineer but also as a patient. I've been through these things and I've seen some of the drawbacks of of some of these. And so um I'll I'll address the AI question first and then I'll get into the larger ecosystem uh question. And so as people become aware of AI and it sounds you know very you know kind of scary or you know people aren't quite sure what it is.</p> <p>um as I've worked in that area for a number of years um and my math my math background uh really kind of is the basis for that which is there's algorithms and there's algorithms are the basis for problem solving and so these AI tools are tools to help you solve problems and so the whole context of systems engineering is solving problems and so these AI tools uh through their mathematical algorithms and I use the term crowdsourcing they're giving all kinds kinds of people are providing all these informations in them.</p> <p>Um you can solve much more uh uh many more problems as well as a more complex problem and you just have to use the right tool in the right arena because and if if you've worked it with AI at all sometimes it can give you absolutely completely wrong answers. So you have to be very careful how you employ these things. So there's a lot of practice and learning by the algorithms. So know that that can work at a micro level.</p> <p>you know, you're looking for some u you know, protein u characterization at a very low level as well as as you're trying to think through what process should I put together for this organization in order to be more efficient. So these AI algorithms can help you do that. And so as you think through the utilization of AI, I think it's a great tool for a starting point.</p> <p>don't ever replace it for critical thinking and critical problem solving uh and and asking the right questions, all the things I've mentioned, but I think it's a great start to be able to start framing these things out. Um what I've noticed as you use these tools, um it helps bring people together. One of the things that we like to do in systems engineering and in systems thinking and systems science is you need to be get people on the same page.</p> <p>And so we'll use things like we've talked about before with just use cases and scenarios where it brings everybody on the same sheet of paper. So if you can have an AI tool that can bring people better collaborate um you're able to uh solve the problem and start addressing the problem as a team because when you get these topdown executive decisions and they're pushed down and then they you know don't work well. Um part of the problem is that there was not collaboration on the process.</p> <p>People didn't have buyin. people didn't have a say. And so what you can use these AI tools for is to help bring collaboration and people asking similar questions and then building off something that maybe someone started asking a question through one of these AI tools and then you can start um rendering it further with more people with other questions and start doing it a little bit more uh collaboratively.</p> <p>Um but um you know these large organizations and trying to work uh in a systems context it's very difficult. Yeah. So I'm always a proponent of and you'll see me use the term kind of the end points for processes the beginning and the end and work the bridge. Same thing for uh putting a putting some type of initiative in place.</p> <p>You can have a top level framework architecture but you got to work with those that have boots on the ground because they'll have a lot of insights as well as a lot of um um heruristics and and uh you know ways that thing work and don't work and you got to then meet in the middle. um that's the best way because if you just do one or the other uh if you start at the bottom you won't necessarily be able to affect the whole organization.</p> <p>If you start on the top you'll get a lot of resistance and it won't you know one size does not fit all in the process. >> So with what you're saying is you can't just have a couple of systems engineers at headquarters pull all of the data you know run it through run it through AI that that won't necessarily give you give you the result. you have to actually have kind of systems engineers being involved. >> Yeah.</p> <p>>> In the each hospital or or each of the kind of the actual things that they're trying to look at, right? >> Yeah. Yeah. And and and and one of the messages I wanted to to make sure I said here is the idea of um and I used the word kind of specialist incent and specialist incentivize. Part of the thing that I think would be important is to have people as best you can is you know be cross-trained in different things.</p> <p>And so as you think of u systems engineering if you could have clinical staff um have systems training not just six sigma because that you know focuses on certain areas but you know have more of a systems training they'll have an appreciation for that. So the idea you know you don't have to have a quot employee a system engineer at everywhere.</p> <p>You may have a clinical staff who's a lead but they are conversant in systems uh processes and efforts and so they can be the emissary to carry the message and a lot of times in specifically within healthcare you know as a systems engineer comes in there can be you know a lot of antibodies as you walk in and uh they're like who is this and what are they going to do um if you have a clinical staff we've had nurses doctors all kinds of people work through our program and they carry the weight if you can show them the systems principles they can carry these things through.</p> <p>So if as long as you have the system principles somewhere within the organization um and like I say within healthcare specifically it can be encapsulated in one of the clinical staff nurses whatever that that really carries much more weight. Well what does that practically look like?</p> <p>Because that's one of the big questions is people are going to be hearing this and they might be thinking that they need to get to work on implementing systems engineering in their organizations especially organizations who are undergoing you know mergers and acquisitions or they're doing these big things or organizations who are solving some of these big problems. So they might want to implement this. What is the the most reasonable method?</p> <p>Is it to you know have staff get their their masters in it? Is it you know a certificate course? What do you recommend? Yeah.</p> <p>And there's um there's there's education and there I use OT on the OJT on the job training um because uh we'll you know within the things that we will teach at Hopkins and there could be certification programs or M's programs um you will learn principles but it's when you actually take those principles and you have the opportunity to do on the job training and in some cases you can have within your uh organization um I'll just call them, we use the term design thinking exercises where you can actually have people think these things through.</p> <p>You're not actually in a in an operations context where you know people's lives are on the line here, but you have some type of design thinking uh workshop that you can work these things through and then after you practice it in that kind of um you know laboratory setting so to speak uh you can then take it to the on the job.</p> <p>And like I say, I always encourage starting small, making sure it's going to work because um the one size does not fit all and uh personalities and how you conduct things do matter. And so learn the skills. Like I say, you use the term certificate. Um we'll be having a certification program with the health care systems. Um the masters u many have taken that as well.</p> <p>But then make sure your organization does have these opportunities for design thinking uh uh places, sandboxes some people call them, where you're actually able to think these things through and work them through before you actually take them to the live setting where you know literally people's lives are on the line um and make sure that you've thought through how you're going to do these things.</p> <p>>> What's the limit with that when it comes to you know where is systems engineering applicable? Is it applicable in every clinical specialty? Is it applicable everywhere? You know, when should it be used? When shouldn't it be used? >> Yeah. So, uh I would say as you're think and I'm going to put this in like three different categories here.</p> <p>So, you think about um devices and so people when we think about building devices and so systems engineering, you're trying to build a new device, whatever that may be, very very applicable in there because you're working through the the needs requirements.</p> <p>you're actually building a system and so very applicable in there from a process standpoint in terms of how do you bring process improvements to an organization very applicable within there and making sure that you um uh understand needs requirements outcomes metrics and then when you and I'll use the word now clinical when or you know you have something very specific where a nurse or a doctor is working very specifically uh with the patient and so there you have to be very careful how you apply these things because um there's a personalization um associated with working with with um with patients and so there are principles that I think you can use and then problem solving problem solving approaches that you can use in the clinical fashion there but it's not as clear-cut how you use it as the other two areas that I just described and so be so for for those folks that are in that area I would say do learn the principles and know how you can apply them but you know you want to be very personal and make sure that you're clear on the outcomes of the patient and how you're going to be using this.</p> <p>>> Wow. Very good uh answers to to that question. I hope that a lot of people come away from this knowing what some of the first steps are that they can take. One final question. If there is an individual who is interested in getting involved in systems engineering or interested in possibly, you know, brushing up on their skill set, what's a kind of the first step that you'd recommend that they take? What's the first piece of homework you'd give to our listeners?</p> <p>And so you mean from a from a academic standpoint or just if you're >> just in general, you know, if if it's a physician or an executive leader and they they want to learn more, is there a a book you'd recommend or a resource you'd recommend to just get them at least more familiarized with the subject? >> Yeah.</p> <p>And so um um one of the books and there are so many different books and I we used I used the word earlier or you used the word earlier system science and so that's to me kind of the larger um area. But then within there there are things called systems thinking and then systems engineering. So systems science allows you to think through the larger picture.</p> <p>Um there's systems thinking that allows you to come up with conceptual ways that you view problems and then systems engineering is the mechanics that we actually go through which is more the what we've been a little bit focusing on is how do you you know now develop processes uh capabilities uh technical areas and so if people are interested to me I think part of what you're trying to do is get a mindset first and so systems thinking I think is one of those areas and uh one of the books I use in my courses all all the time is something called the fifth discipline which is a a little bit of a business book.</p> <p>Um but it talks a lot about systems thinking. And so part of what I I encourage is making sure you have a sense of the mindset you want to have. And so having the sense of what is interconnectivity, what are relationships, what are dynamics, um how do u the how do the u so you know how do the how does your um push result in some type of outcome and in some cases it's it's exactly what you did not expect.</p> <p>And so make sure you have an appreciation for the the interconnections, the dynamics and the unexpected.</p> <p>And then once you do that uh you have a sense of of how problems is solved in some way somehow uh how things actually uh function then you can to me dive in more into the systems engineering mechanics because you have an appreciation for what does it mean why am I even looking at it in this context and now systems engineering allows you to put through these processes and tools and details that we're describing. Um and so again the fifth discipline I think is a great book.</p> <p>There are many others um along those line, but I think that's a good start. >> And I also I've loved that book during our class. It's actually been uh very very interesting because I you know came out of the MBA and then into this program and it's been very interesting seeing how that book the fifth discipline has applied some of the like you said the business concepts to system engineering.</p> <p>So for a lot of the individuals watching this who do have their MBA or MHA I would also very much recommend that book as well. Um, but yeah, thank you so much for coming on, Dr. Mononttoya. This was a great conversation. I really hope it it, you know, kind of elucidates this this topic at least a little bit for our audience. And I hope that we can have you on again in the future to talk more. >> Appreciate it. Thanks for a time.</p>
Want to reach healthcare executives and decision-makers? Join industry leaders like HealthMap Solutions on our podcast.
Become a GuestDiscover related content across the AJHCS ecosystem
Articles on the same topic in AJHCS
Abstract Healthcare contact centers are undergoing a structured transition as health systems move from legacy telephony to cloud-based, AI-enabled omnichannel platforms. These platforms increasingly function as centralized digital access hubs for scheduling, triage, navigation, and patient communica...
ArticleAbstract This article presents a comprehensive analysis of hazard-focused frameworks as a strategic imperative for modern public health administration2. As a systematic and proactive alternative to traditional reactive models, this approach enhances preparedness and response to a full spectrum of ev...