© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Systems Essentials
What Are Systems Engineers Talking About? Kathleen Whanger and Pat Baird
About the Authors Kathleen Whanger is quality assurance manager for Teleflex Medical in Asheboro, NC. E-mail: kathleen. [email protected] Pat Baird is director of engineering at Baxter Healthcare Corporation in Round Lake, IL. E-mail: [email protected]
Systems engineering is a methodical way to manage complexity, with the key word being “methodical.”
18
Drawing a clear picture of systems engineering can be difficult, as it spans various disciplines in many different industries. Because systems engineering is so vast, many specialties exist; therefore, one systems engineer may offer a completely different viewpoint about his/her work compared with another. An online search for a definition of systems engineering will yield varying resultas, most of which discuss interdisciplinary approaches, customer needs, advanced modeling tools, and a wide range of life-cycle management activities. In addition, because a large collection of tools and techniques have been developed, conversations about systems engineering can quickly devolve into discussions of specific tools rather than systems engineering itself. The International Council on Systems Engineering (INCOSE) is the largest professional society of systems engineers. INCOSE defines systems engineering as follows (emphasis added by the authors)1: “Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: Operations, Cost & Schedule, Performance, Training & Support, Test, Disposal, Manufacturing.” Systems engineering integrates all relevant disciplines and specialty groups, forming a
Horizons Fall 2014
structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers, with the goal of providing a quality product that meets users’ needs.
History of Systems Engineering Systems engineering emerged as a separate discipline in the 1940s and 1950s as organizations tackled increasingly complex projects. Projects for the Department of Defense, during and immediately after World War II, became so complicated that thought leaders from Bell Labs and the RAND Corporation had to develop new tools and new ways of viewing their projects.2 Although systems engineering started in the defense sector, it was subsequently adopted and expanded upon by other industries. If you were to attend an INCOSE meeting, you likely would find people that work in defense, aviation, rail, telecommunications, nuclear power, automotive, and healthcare. While these knowledge domains are drastically different, they all involve complex collections of machines and people working toward a common goal. Another commonality among them is that failing to reach that goal often has severe consequences. Systems engineering is a methodical way to manage complexity, with the key word being “methodical.” Often, when presented with a complex problem, jumping in and immediately working on solutions can be tempting.
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Systems Essentials
However, systems engineers will first try to understand the context of the problem, how the problem interacts with other problems, and the impact that the problem has on the end user. Only after they fully understand these aspects of the problem will a systems engineer begin to break it down into smaller, more manageable elements.
Case in Point: Systems Engineering Project Example You are the systems engineering manager at Tomkat Engineering firm. Your systems engineering team has been awarded a subcontract to define the communication infrastructure system, which will be built from the ground up at a growing hospital. The communications system will be built to allow mobile devices, medical devices, electronic medical records, and software systems to communicate with each other. The contract indicates that your systems team will perform the following functions: • Define system requirements based on stakeholder and user needs • Construct the communications system architecture and interfaces • Determine and mitigate risk • Test the system and subsystems • Manage the entire project from beginning to end To ensure that these five key components of systems engineering are completed within the project timeline, you have assigned a team lead for the first four areas and a project manager for the fifth area. With clearly defined ownership of all main aspects of systems engineering, your systems team can focus on the critical task to complete the project on time. As the contract begins, your entire systems team collaborates to define the intended use statement of this communications infrastructure. Then, to better understand the stakeholders, your systems requirements team, with the support of human factors, initiates a grassroots campaign at the hospital to meet every individual who will interact with the system, even if for a millisecond. The team comes back together and begins to capture all stakeholder needs. To do so, the team answers the following questions: • Who are the active and passive stakeholders? • What are the needs of each stakeholder?
• Do any stakeholder needs overlap? • Are there any conflicting needs? • Are all needs defined at a consistent, 20,000foot viewpoint? Or, are the needs defined specifically in some cases and at a high level in others? After the team has completed this task, they turn to define the high-level functional, physical, and performance requirements of the system. The team uses a quality functional deployment matrix tool to define and structure those requirements. This allows the team to define how the system will meet user needs. Once the high level requirements are defined, the following questions need to be answered and implemented: • What does the use case diagram look like? • What are the use cases? • Will sequence diagrams (i.e., how the mobile device will communicate with the electronic medical records in the system) be included? • What are the regulatory requirements? • What are the financial constraints? With user needs and physical, performance, and functional requirements captured, the task turns to defining the system. The systems engineer asks questions such as: • What is the system? • What are the inputs into the system? • What are the outputs from the system? • What are the subsystems? • What are the interfaces/integration points among the subsystems? • What is the architecture of the system? • How will the functional and physical architectures be defined? • What is the architecture of each subsystem? When the system architecture is captured, the team starts working on risk management. The team asks itself: “Now that we know what the system is supposed to do, what can go wrong? For all the things that can go wrong, what can we do about them?” The risks and mitigations at the system and subsystem levels need to be defined through tools such as a failure modes and effects analysis, system hazard analysis, and fault tree analysis. To prepare for design iterations, possible project scope changes, and complex systems, the systems engineer must address the following questions: • How will the system be maintained? • What happens when a new system or subsysHorizons Fall 2014
The risks and mitigations at the system and subsystem levels need to be defined through tools such as a failure modes and effects analysis, system hazard analysis, and fault tree analysis.
19
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Systems Essentials
Systems Engineering In the Limelight The potential benefits that systems engineering can bring to the healthcare delivery industry have been recognized on a national level. Following the 2001 Institute of Medicine (IOM) report, Crossing the Quality Chasm,3 a committee was formed among the National Science Foundation, National Institutes of Health, Robert Wood Johnson Foundation, National Academy of Engineering, and IOM to explore how engineering tools and techniques could meet the goals outlined in the report. In 2005, this committee issued a report titled Building a Better Delivery System: A New Engineering/ Health Care Partnership.4 In May 2014, the President’s Council of Advisors on Science and Technology issued a report discussing current barriers to systems thinking in healthcare and suggesting several goals to help overcome those barriers.5
tem is introduced? • How do you protect the system from interference of other devices on this modern technology design? • How do you design the system to be flexible for future needs that we simply don’t know at this time? • As we solve problems at one layer of the system, are we unintentionally creating problems at another layer? (Systems are like a wedding cake in that they’re constructed in multiple layers.) Finally, the team turns to thinking about verifying the functionality of the system and validating that the final design actually meets user needs. Underlying all of these activities is a rich set of tools that allows the systems engineer to create and maintain requirements, lay out the architecture, perform risk analysis, and trace requirements to verification and validation activities. While this example was about creating a communications system in a hospital, the exact same processes, tools, and skillsets can be used to design an avionics system for aircraft, a new railway system, or even a better healthcare delivery system.
Systems Engineering and Healthcare Delivery
Although these two reports were published nearly a decade apart, it is interesting to note that they share the common themes of payment alignment, the need for awareness of systems engineering tools and techniques among health professionals, and the importance of healthcare informatics.
Without question, effective healthcare delivery is a complex problem and involves the interactions of multiple systems. The challenge, however, is that most of these individual systems either 1) weren’t designed as systems— they evolved as such—or 2) were designed to meet the needs of a narrow set of stakeholders, without anyone having a big-picture view. For example, consider a physician reviewing a patient’s lab results and ordering a new intravenous (IV) medication. The lab results are generated by one system and reviewed in another system, then the physician creates a new drug order. This drug order is fulfilled by the pharmacy system, and an IV bag is delivered to the patient’s floor, where a clinician will program an infusion pump—which is another system. These separate systems have to interface with each other, and they do so thousands of times each day, but no big-picture
20
Horizons Fall 2014
view exists of how everything fits together. Instead, we see several small-picture views, and over time, these disparate systems have evolved in such a way that they work together, but in an inefficient manner. Wouldn’t it be better if these systems had been intentionally designed to work together, rather than slowly evolving over time to work together? Wouldn’t it be better if the workflow was designed to be optimal for everyone involved in this simple use case? Hundreds, if not thousands, of similar workflows in every hospital have evolved over time, instead of being intentionally designed. In addition, modern healthcare delivery relies on having a large number of specialists, which can lead to siloed workflows that are optimized for some specialists, but at the expense and frustration of other stakeholders.
Learning Tricks from Other Trades In the past several years, the healthcare industry has made great strides in learning from other industries. Probably one of the most well-known examples is the adaptation of the preflight checklist used by pilots into a presurgery checklist, as popularized in Gawande’s book The Checklist Manifesto: How to Get Things Right.6 Similarly, healthcare needs to learn from systems engineering. Healthcare already is complex and is growing evermore complicated. Healthcare has a multitude of stakeholders with multiple, and sometimes conflicting, user needs. Healthcare has an enormous amount of interfaces, both internal and external, that have evolved over time. Although the number of healthcare workers is expected to become increasingly scarce,7 the demand for healthcare services will increase. Meanwhile, pressure to keep healthcare costs down will continue. Efficient and effective healthcare delivery is a highly constrained problem. These are not problems that can be solved in an incremental, evolutionary way. These are not problems that can be tackled piecemeal. These problems must be tackled by asking the right questions at the right time, in order to understand and create the optimal system. Healthcare needs systems engineering. n
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Systems Essentials
References 1. International Council on Systems Engineering. What is Systems Engineering? Available at: www.incose.org/practice/whatissystemseng.aspx. Accessed August 7, 2014. 2. International Council on Systems Engineering. Brief History of Systems Engineering. Available at www.incose.org/mediarelations/briefhistory.aspx. Accessed August 7, 2014. 3. Institute of Medicine. Crossing the Quality Chasm: A New Health System for the 21st Century. Washington, DC: National Academies Press; 2001. 4. National Academy of Engineering and Institute of Medicine. Building a Better Delivery System: A New Engineering/Health Care Partnership. Washington, DC: National Academies Press; 2005.
5. President’s Council of Advisors on Science and Technology. Better Health Care and Lower Costs: Accelerating Improvements through Systems Engineering. Available at: www.whitehouse.gov/ sites/default/files/microsites/ostp/PCAST/pcast_ systems_engineering_in_healthcare_-_may_2014. pdf. Accessed August 7, 2014. 6. Gawande A. The Checklist Manifesto: How to Get Things Right. New York: Metropolitan Books; 2010. 7. World Health Organization. Global Health Workforce Shortage to Reach 12.9 Million in Coming Decades. Available at: www.who. int/mediacentre/news/releases/2013/healthworkforce-shortage/en. Accessed August 7, 2014.
Horizons Fall 2014
21
Systems Essentials
What Are Systems Engineers Talking About? Kathleen Whanger and Pat Baird
About the Authors Kathleen Whanger is quality assurance manager for Teleflex Medical in Asheboro, NC. E-mail: kathleen. [email protected] Pat Baird is director of engineering at Baxter Healthcare Corporation in Round Lake, IL. E-mail: [email protected]
Systems engineering is a methodical way to manage complexity, with the key word being “methodical.”
18
Drawing a clear picture of systems engineering can be difficult, as it spans various disciplines in many different industries. Because systems engineering is so vast, many specialties exist; therefore, one systems engineer may offer a completely different viewpoint about his/her work compared with another. An online search for a definition of systems engineering will yield varying resultas, most of which discuss interdisciplinary approaches, customer needs, advanced modeling tools, and a wide range of life-cycle management activities. In addition, because a large collection of tools and techniques have been developed, conversations about systems engineering can quickly devolve into discussions of specific tools rather than systems engineering itself. The International Council on Systems Engineering (INCOSE) is the largest professional society of systems engineers. INCOSE defines systems engineering as follows (emphasis added by the authors)1: “Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: Operations, Cost & Schedule, Performance, Training & Support, Test, Disposal, Manufacturing.” Systems engineering integrates all relevant disciplines and specialty groups, forming a
Horizons Fall 2014
structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers, with the goal of providing a quality product that meets users’ needs.
History of Systems Engineering Systems engineering emerged as a separate discipline in the 1940s and 1950s as organizations tackled increasingly complex projects. Projects for the Department of Defense, during and immediately after World War II, became so complicated that thought leaders from Bell Labs and the RAND Corporation had to develop new tools and new ways of viewing their projects.2 Although systems engineering started in the defense sector, it was subsequently adopted and expanded upon by other industries. If you were to attend an INCOSE meeting, you likely would find people that work in defense, aviation, rail, telecommunications, nuclear power, automotive, and healthcare. While these knowledge domains are drastically different, they all involve complex collections of machines and people working toward a common goal. Another commonality among them is that failing to reach that goal often has severe consequences. Systems engineering is a methodical way to manage complexity, with the key word being “methodical.” Often, when presented with a complex problem, jumping in and immediately working on solutions can be tempting.
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Systems Essentials
However, systems engineers will first try to understand the context of the problem, how the problem interacts with other problems, and the impact that the problem has on the end user. Only after they fully understand these aspects of the problem will a systems engineer begin to break it down into smaller, more manageable elements.
Case in Point: Systems Engineering Project Example You are the systems engineering manager at Tomkat Engineering firm. Your systems engineering team has been awarded a subcontract to define the communication infrastructure system, which will be built from the ground up at a growing hospital. The communications system will be built to allow mobile devices, medical devices, electronic medical records, and software systems to communicate with each other. The contract indicates that your systems team will perform the following functions: • Define system requirements based on stakeholder and user needs • Construct the communications system architecture and interfaces • Determine and mitigate risk • Test the system and subsystems • Manage the entire project from beginning to end To ensure that these five key components of systems engineering are completed within the project timeline, you have assigned a team lead for the first four areas and a project manager for the fifth area. With clearly defined ownership of all main aspects of systems engineering, your systems team can focus on the critical task to complete the project on time. As the contract begins, your entire systems team collaborates to define the intended use statement of this communications infrastructure. Then, to better understand the stakeholders, your systems requirements team, with the support of human factors, initiates a grassroots campaign at the hospital to meet every individual who will interact with the system, even if for a millisecond. The team comes back together and begins to capture all stakeholder needs. To do so, the team answers the following questions: • Who are the active and passive stakeholders? • What are the needs of each stakeholder?
• Do any stakeholder needs overlap? • Are there any conflicting needs? • Are all needs defined at a consistent, 20,000foot viewpoint? Or, are the needs defined specifically in some cases and at a high level in others? After the team has completed this task, they turn to define the high-level functional, physical, and performance requirements of the system. The team uses a quality functional deployment matrix tool to define and structure those requirements. This allows the team to define how the system will meet user needs. Once the high level requirements are defined, the following questions need to be answered and implemented: • What does the use case diagram look like? • What are the use cases? • Will sequence diagrams (i.e., how the mobile device will communicate with the electronic medical records in the system) be included? • What are the regulatory requirements? • What are the financial constraints? With user needs and physical, performance, and functional requirements captured, the task turns to defining the system. The systems engineer asks questions such as: • What is the system? • What are the inputs into the system? • What are the outputs from the system? • What are the subsystems? • What are the interfaces/integration points among the subsystems? • What is the architecture of the system? • How will the functional and physical architectures be defined? • What is the architecture of each subsystem? When the system architecture is captured, the team starts working on risk management. The team asks itself: “Now that we know what the system is supposed to do, what can go wrong? For all the things that can go wrong, what can we do about them?” The risks and mitigations at the system and subsystem levels need to be defined through tools such as a failure modes and effects analysis, system hazard analysis, and fault tree analysis. To prepare for design iterations, possible project scope changes, and complex systems, the systems engineer must address the following questions: • How will the system be maintained? • What happens when a new system or subsysHorizons Fall 2014
The risks and mitigations at the system and subsystem levels need to be defined through tools such as a failure modes and effects analysis, system hazard analysis, and fault tree analysis.
19
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Systems Essentials
Systems Engineering In the Limelight The potential benefits that systems engineering can bring to the healthcare delivery industry have been recognized on a national level. Following the 2001 Institute of Medicine (IOM) report, Crossing the Quality Chasm,3 a committee was formed among the National Science Foundation, National Institutes of Health, Robert Wood Johnson Foundation, National Academy of Engineering, and IOM to explore how engineering tools and techniques could meet the goals outlined in the report. In 2005, this committee issued a report titled Building a Better Delivery System: A New Engineering/ Health Care Partnership.4 In May 2014, the President’s Council of Advisors on Science and Technology issued a report discussing current barriers to systems thinking in healthcare and suggesting several goals to help overcome those barriers.5
tem is introduced? • How do you protect the system from interference of other devices on this modern technology design? • How do you design the system to be flexible for future needs that we simply don’t know at this time? • As we solve problems at one layer of the system, are we unintentionally creating problems at another layer? (Systems are like a wedding cake in that they’re constructed in multiple layers.) Finally, the team turns to thinking about verifying the functionality of the system and validating that the final design actually meets user needs. Underlying all of these activities is a rich set of tools that allows the systems engineer to create and maintain requirements, lay out the architecture, perform risk analysis, and trace requirements to verification and validation activities. While this example was about creating a communications system in a hospital, the exact same processes, tools, and skillsets can be used to design an avionics system for aircraft, a new railway system, or even a better healthcare delivery system.
Systems Engineering and Healthcare Delivery
Although these two reports were published nearly a decade apart, it is interesting to note that they share the common themes of payment alignment, the need for awareness of systems engineering tools and techniques among health professionals, and the importance of healthcare informatics.
Without question, effective healthcare delivery is a complex problem and involves the interactions of multiple systems. The challenge, however, is that most of these individual systems either 1) weren’t designed as systems— they evolved as such—or 2) were designed to meet the needs of a narrow set of stakeholders, without anyone having a big-picture view. For example, consider a physician reviewing a patient’s lab results and ordering a new intravenous (IV) medication. The lab results are generated by one system and reviewed in another system, then the physician creates a new drug order. This drug order is fulfilled by the pharmacy system, and an IV bag is delivered to the patient’s floor, where a clinician will program an infusion pump—which is another system. These separate systems have to interface with each other, and they do so thousands of times each day, but no big-picture
20
Horizons Fall 2014
view exists of how everything fits together. Instead, we see several small-picture views, and over time, these disparate systems have evolved in such a way that they work together, but in an inefficient manner. Wouldn’t it be better if these systems had been intentionally designed to work together, rather than slowly evolving over time to work together? Wouldn’t it be better if the workflow was designed to be optimal for everyone involved in this simple use case? Hundreds, if not thousands, of similar workflows in every hospital have evolved over time, instead of being intentionally designed. In addition, modern healthcare delivery relies on having a large number of specialists, which can lead to siloed workflows that are optimized for some specialists, but at the expense and frustration of other stakeholders.
Learning Tricks from Other Trades In the past several years, the healthcare industry has made great strides in learning from other industries. Probably one of the most well-known examples is the adaptation of the preflight checklist used by pilots into a presurgery checklist, as popularized in Gawande’s book The Checklist Manifesto: How to Get Things Right.6 Similarly, healthcare needs to learn from systems engineering. Healthcare already is complex and is growing evermore complicated. Healthcare has a multitude of stakeholders with multiple, and sometimes conflicting, user needs. Healthcare has an enormous amount of interfaces, both internal and external, that have evolved over time. Although the number of healthcare workers is expected to become increasingly scarce,7 the demand for healthcare services will increase. Meanwhile, pressure to keep healthcare costs down will continue. Efficient and effective healthcare delivery is a highly constrained problem. These are not problems that can be solved in an incremental, evolutionary way. These are not problems that can be tackled piecemeal. These problems must be tackled by asking the right questions at the right time, in order to understand and create the optimal system. Healthcare needs systems engineering. n
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Systems Essentials
References 1. International Council on Systems Engineering. What is Systems Engineering? Available at: www.incose.org/practice/whatissystemseng.aspx. Accessed August 7, 2014. 2. International Council on Systems Engineering. Brief History of Systems Engineering. Available at www.incose.org/mediarelations/briefhistory.aspx. Accessed August 7, 2014. 3. Institute of Medicine. Crossing the Quality Chasm: A New Health System for the 21st Century. Washington, DC: National Academies Press; 2001. 4. National Academy of Engineering and Institute of Medicine. Building a Better Delivery System: A New Engineering/Health Care Partnership. Washington, DC: National Academies Press; 2005.
5. President’s Council of Advisors on Science and Technology. Better Health Care and Lower Costs: Accelerating Improvements through Systems Engineering. Available at: www.whitehouse.gov/ sites/default/files/microsites/ostp/PCAST/pcast_ systems_engineering_in_healthcare_-_may_2014. pdf. Accessed August 7, 2014. 6. Gawande A. The Checklist Manifesto: How to Get Things Right. New York: Metropolitan Books; 2010. 7. World Health Organization. Global Health Workforce Shortage to Reach 12.9 Million in Coming Decades. Available at: www.who. int/mediacentre/news/releases/2013/healthworkforce-shortage/en. Accessed August 7, 2014.
Horizons Fall 2014
21
