Systems Engineering in Healthcare Delivery

From SEBoK
Jump to: navigation, search

The healthcare system is complex and adaptive and confronts significant challenges for which systems engineering tools are useful and necessary.  The President’s Council of Advisors on Science and Technology (PCAST) prepared a report concluding that healthcare improvement could be accelerated with the use of systems engineering. (PCAST 2014) They noted that they key incentives are wrong (fee for service vs. fee for outcomes), and key enablers are missing (access to useful data, lack accepted systems techniques and people trained in systems engineering)

This article provides an overview of healthcare delivery with some historical context, and describes some different approaches to systems engineering which have been found helpful in addressing healthcare delivery problems.

Human Centered Design

Healthcare delivery is not a product but a service and that makes it different than typical hardware or software design that may be seen in aerospace, defense, or even medical devices. There are three primary factors for these differences. First, quality in services can be difficult to measure objectively. Second, in this service system, care providers are continually making risk, cost, and quality of care decisions at the time of service. Each patient is unique and multiple pathologies and value streams are possible based upon any given patient’s needs. Those needs are complemented by a care team that is unique and complex and includes the patients themselves, family support, medical professionals, hospitals, and even the industry in which it resides. Third, if returning to or maintaining wellness is considered to be the core value for a healthcare delivery system, then the patient’s behaviors both within and outside any designed care plan has a significant role to play, because roughly half of all healthcare cost is derived from preventable disease. (Conover 2012)

Structure of the Healthcare Delivery Industry

The healthcare industry is large, diverse, and fragmented and this causes considerable complexity. This complexity is experienced both at the macro and micro levels.

At the macro level the healthcare industry is highly fragmented with over 50% of all healthcare workers employed in companies with less than 500 employees. (Griffith & White 2007) Nearly 1 million physicians practice medicine in the US; roughly half of these are in primary care and the rest are in over 30 specialties and many more subspecialties and clinics. In addition to physicians, some 5 million others in some 50 other specialties provide care to patients.

At the micro level, the complexity and pace of change make care difficult. Healthcare is a rapidly developing field with over 700,000 publications produced annually and the pace in fact is increasing. (Smith et al. 2013). That there are already 14,400 codes in the World Health Organization's International Statistical Classification of Diseases and Related Health Problems (ICD) complicates the issue. Add to this the regulatory and administrative burden of primary care providers interacting with approximately 200 specialists in any given year and the complexity that care providers face on a daily basis becomes clear.

In short, the healthcare delivery system is itself a complex adaptive system and represents a wicked_problem_, whereby any changes to the system intended to solve an issue will likely create other issues.

Improving Ongoing Operations

As mentioned, above caregivers are faced with many challenges and the goal of in systems engineering in healthcare delivery is to lessen that burden in a systematic way without significant disruption of current operations. To do this successfully requires several factors:

  • First, as stated above, systems engineers have to acknowledge that they are dealing with a complex adaptive system that includes many wicked problems. An analogy is that what systems engineers experience in healthcare is like rewiring a house with the power turned on because whatever changes are made are to an existing system that must operate while the changes are being made.
  • Second, “the system” in place is difficult to define. The "healthcare system" is actually a combination of many open systems and interdependencies with the system of interest may be unknown.
  • Third, patient safety is always a concern and any actions that could affect patient safety must be very carefully considered. Often, "optimizing" a system may introduce a potential risk to patient safety. These system aspects are always in tension.
  • Fourth, there is a bias towards the current (known) system versus a change leading to an unknown system. Any change will create a certain amount of disruption to an operational system that may be currently operating at or beyond capacity.
  • Fifth, healthcare delivery systems are combinations of patients, providers, process, and products and therefore uncertainty is a daily reality. This level of uncertainty may not be amenable to typical agile approaches of 4-6 week sprints nor traditional waterfall methods.
  • Sixth, local factors could play a significant role; therefore no two sites may perform an operation in exactly the same way.
  • Seventh, the entire industry acts as a complex adaptive system with multiple intelligent agents working sometimes in partnership and sometimes in conflict with the goals of the system or patient.

Because of these factors and others the tradition of healthcare systems engineering has been to use adaptable human-centered methods. (Checkland 1999)

History of Healthcare Improvement Research

There have been many attempts to understand and improve healthcare both in the public and private domains. Examples include the National Healthcare Service Change Model, the efforts of the Agency for Healthcare Research and Quality, and the Institute for Healthcare Improvement. Here we outline some representative efforts.

Healthcare improvement has been shaped in part by four seminal works by the Institute of Medicine (IOM). To Err is Human reported that up to 98,000 patients were killed by healthcare each year. (Kohn, Corrigan, & Donaldson 2000) This put an emphasis on safety as a key quality of care metric. The following year the Institute of Medicine (IOM) broadened the concept of quality beyond safety to include six measures of quality. They determined that healthcare should be safe, effective, patient centered, timely, efficient, and equitable. (Institute of Medicine 2001) This report called Crossing the Quality Chasm included an appendix that documented poor quality and the severity of the issues of under use, over use, and potential for harm in medicine. A search for the underlying reasons for poor quality led to three primary reasons for poor quality. The three reasons were the growing complexity of science and technology; the increase in chronic conditions; and the failure to exploit information technology.

To address these concerns the IOM partnered with the National Academy of Engineering (NAE) to see what could be done from a systems engineering perspective to address the real challenges facing the industry in Building a Better Delivery System. (Compton et al. 2005). That was followed by the realization that standard systems engineering needed to be modified and healthcare was and would remain a human centered endeavor as stated in Best Care at Lower Cost (Smith et al. 2013)

Three Approaches

Although there are many accepted approaches to healthcare systems engineering and improvement, here we outline three that share common characteristics and are representative of most of the other methods.

The first approach is Lean Six Sigma which is a combination of two methods. Lean has its roots in the Toyota Production System (Ohno 1988) and the work of the International Motor Vehicle Program (Womack, Jones, & Roos 1990). Six-Sigma has its roots at Motorola and the work of Bill Smith. These two methods were combined by Michael L. George (see (George 2002) and (George 2003)). It includes techniques like value stream mapping, waste elimination, root cause analysis, and voice of customer. For additional information see Lean Engineering and Lean in Healthcare.

The second approach is based on industrial engineering, which has its roots in the work of Frederick Taylor and others. This approach includes tools such as discrete event simulation, ergonomics, production control, and operations research as shown in Figure 1. For additional information, see Systems Engineering and Industrial Engineering.

Insert Table ES-1 from Building a Better Delivery System here once we obtain the proper permissions.

The third approach is healthcare systems engineering. Traditional systems engineering uses a functional decomposition approach; see for example (Defense Systems Management College 2001). However, healthcare problems are often classified as wicked and complex and not amenable to traditional decomposition methods found in other areas of engineering. (Rouse & Serban 2014).

There are many tailored approaches to improving healthcare delivery, but almost all are based on one of these three approaches, or a combination of these.

Healthcare Systems Engineering

The basic systems engineering steps are similar to those for any industry specific applications, but the steps are tailored for healthcare. The traditional waterfall model of requirements, design, implementation, verification, and maintenance is interrupted in favor of almost continuous support. In many cases the closeout and transfer of the project to operational staff is more challenging in healthcare than in many industries.

Below is outlined a general methodology used by the US Department of Veteran's Affairs (VA) that may suit a wide variety of situations and programs, composed of 4 pillars: Define the Problem, Investigate Alternatives, Develop the Solution, and Launch and Assess the Solution. These 4 pillars are similar to classic mistake avoidance, development fundamentals, risk management, and schedule oriented approaches. (McConnell 1996); they are also similar to the Plan/Do/Check/Act methodology.

Define the Problem

As mentioned above, the patient is augmented by a care team consisting of family, friends, clinical staff, and many other support staff the patient will not directly encounter. This care team may not be familiar with the rigors of traditional engineering design. Because of this, a systems engineer may use a paired partnership model where engineers are embedded with clinical and administrative staff, family, and the patients themselves. In this concept, everyone is a designer and our goal is to provide them with the tools to contribute to the system design process. Even at this early stage, configuration management would be considered. Depending on the size of the rollout one alpha site and several beta sites may be used at any phase to avoid local optimal solutions that don’t work globally.

Investigate Alternatives

During the proof-of-concept phase, visualizing the result is important for the reasons mentioned above. Therefore, one or more initial prototypes may be developed with the alpha site. The goal is to get to a minimally viable product as soon as possible to demonstrate the viability of the product or methodology. After the initial conversations and meetings, participants have a need to have a common understanding of how the system will work. The systems engineer would embrace the concept of operations with rich pictures, model based systems engineering, story boards, customer journey maps and other tools so that we all have a common understanding of the proposed system.

Develop the Solution

Using what has been learned from the minimally viable product feedback and incorporate that into the future state optimization, one would continue developing the prototype at the initial paired partner alpha site and then the trusted beta demonstration sites. In our case, stakeholders are a part of the development team and not an ancillary function. For this reason, demonstration is considered a key element of the communication plan when developing the solution.

Launch the Solution and Access the Performance

During evaluation and deployment phase, a systems engineer would have considered the future state optimization with corresponding alpha and beta sites. Live implementation would then be used for further testing and evaluation. At any phase feedback is encouraged and reflected in the next iteration of the solution. As mentioned previously abandonment and closeout even during the live phase may not be practical and in fact could be disadvantageous because not all possible needed configurations or situations would have been encountered.

Example Systems Engineering Tools

Below is a list of systems engineering tools which could be used at each of the four steps.

  1. Define the Problem
    1. Establish the scope and context of the problem (define boundary conditions)
    2. Stakeholder identification and management
    3. Lifecycle mapping
    4. Value Stream Process Mapping
    5. SWOT analysis (Operational Deficiencies and Technological Opportunities)
    6. Workflow/Usability/Use Case analysis
    7. Observation Research
    8. Root Cause Analysis (Fishbone diagrams, 5 whys, …)
  2. Investigate Alternatives
    1. Requirements management
    2. SE Evaluation Methods (Decision Trees, Quality Function Deployment (QFD))
    3. Trade-off Analysis
    4. Model-Based Systems Engineering (MBSE)
    5. Technical Risk Management
  3. Develop the Solution
    1. Concept Development
    2. Architecting the solution (functional analysis, subsystem decomposition, interface definition and control, modeling)
    3. Define the implementation
    4. Process Redesign Techniques (including Lean Six Sigma)
    5. Active Integration
    6. Agile / Lean Development Principles (iterative development)
  4. Launch and Assess the Solution
    1. Managing Change in Organizations
    2. Stakeholder Management, Change Management Techniques
    3. Spiral, Agile, and Lean Startup Delivery Practices (Minimal Viable Product delivery)
    4. Business Risk Management
    5. Metrics and benchmarking

During all phases, elements of cognitive & organizational psychology, industrial engineering, usability engineering, systems engineering, and other facets may be critical to implement a solution. Humans are the major part of the system and even the system of systems approach in healthcare.

Conclusion

Systems Engineering for Healthcare delivery shares many aspects with traditional SE, but differs significantly since healthcare delivery is a service (not a product) and due to the domain specific challenges. In particular, problem definition is a particularly ‘wicked’ problem, and measuring successful outcomes in a clear and objective fashion is challenging.

References

Works Cited

Checkland, P. 1999. Systems Thinking, Systems Practice. Hoboken NJ: John Wiley. Compton, W.D., G. Fanjiang, J.H. Grossman, & P.P. Reid. 2005. Building a better delivery system: a new engineering/health care partnership. Washington DC: National Academies Press. Conover, C.J. 2012. American health economy illustrated. Washington DC: American Enterprise Institute. Defense Systems Management College. 2001. Systems engineering fundamentals: Supplementary text. Fort Belvoir, VA: The Press. George, M.L. 2002. Lean Six Sigma. New York, NY: McGraw-Hill. George, M.L. 2003. Lean Six Sigma for Service. New York, NY: McGraw-Hill. Griffith, J.R., & K.R. White. 2007. The Well-Managed Healthcare Organization. Chicago, IL: Health Administration Press. Institute of Medicine. 2001. Crossing the quality chasm: A new health system for the 21st century. Washington DC: National Academy Press. Kohn, L.T., J. Corrigan, & M.S. Donaldson. 2000. To err is human: Building a safer health system. Washington DC: National Academy Press. McConnell, S. 1996. Rapid Development. Redmond, WA: Microsoft Press. Ohno, T. 1988. Toyota Production System. Portland OR: Productivity Press. PCAST. 2014. Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering. Washington DC.: President’s Council of Advisors on Science and Technology (PCAST). Rouse, W.B., & N. Serban. 2014. Understanding and managing the complexity of healthcare. Cambridge, MA: The MIT Press. Smith, M.D., R.S. Saunders, L. Stuckhardt, & J.M. McGinnis. 2013. Best care at lower cost: The path to continuously learning health care in America. Washington DC: National Academies Press. Womack, J.P., D.T. Jones, and D. Roos.1990. The machine that changed the world. New York, NY: Harper Collins.

Primary References

PCAST. 2014. Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering. Washington DC.: President’s Council of Advisors on Science and Technology (PCAST).

Additional References

None.


< Previous Article | Parent Article | Next Article >


SEBoK v. 1.7 released 27 October 2016

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus