A Systems Thinking Approach to Designing Clinical Models and Healthcare Services

Abstract

Chronic diseases are on the rise, increasing in number and treatment regimen complexity. Consequently, the needs of patients with chronic diseases are increasing and becoming more complex and multi-faceted. Such chronic conditions require addressing not only the physical body, but also psychosocial and spiritual health. The healthcare delivery system, however, organically organized into departments based on physical organ systems. Such a configuration makes it ill-suited to provide comprehensive multi-faceted healthcare services that span multiple departments and specialties (e.g., podiatry and endocrinology for diabetes; primary care and psychiatry for behavioral health; and palliative care physicians, chaplains, and social workers for end-of-life care). To deliver new services, the medical field typically designs new clinical models to base its new services on. Several challenges arise from typical approaches to designing healthcare services and clinical models, including addressing only single conditions, describing models only at a high-level of abstraction, and using primarily narrative documents called text-based toolkits for implementation. This paper presents and uses systems thinking as an alternative strategy to designing clinical system models and healthcare services to alleviate many of the current design challenges in designing integrated services for chronic conditions. An illustrative example taking a clinical model and describing it as a system model is presented.

1. Introduction

Growing healthcare costs have drawn significant attention to the healthcare delivery system and its fragile and fragmented nature [1]. Similarly, the growing burden of illness and its impact on individuals, families, and society has led to a concerted effort towards addressing the needs of patients (i.e., focusing on person-centered care). The consequences of the growing burden of illness compounded by an increasingly expensive healthcare delivery system place grave consequences on our economy and way of life.

National Academy of Medicine Reports continue to highlight the need to improve healthcare delivery [2,3]. This includes designing healthcare systems that address current needs of patients and can be implemented and disseminated across varying healthcare system environments.

1.1. The Changing Needs of Patients: From Treating Acute to Chronic Conditions

Acute conditions, namely infectious diseases and traumatic injury, dominated the medical problems of the 19th and early 20th century. In response, the development of the biomedical model addressed these problems by focusing on the body as a machine [4] and therefore disease as the consequence of breakdown in the machine. This reductionist approach to the physical body analogy led to dividing the healthcare delivery system into departments based on discrete service types (e.g., cardiology, endocrinology, podiatry).

Healthcare needs have significantly shifted from treating primarily acute conditions to treating primarily chronic conditions. Chronic conditions now make up over 78% of total healthcare costs in the United States [5]. Furthermore, expenditures for patients with multiple chronic conditions are up to seven times as much as patients with only one chronic condition [6]. This is a significant population given that over half (51.7%) of all Americans have at least one chronic condition and almost one third (31.5%) of all Americans have multiple chronic conditions [7]. This problem increases dramatically with age where almost half (50%) of all people aged 45–64, and 80% of those 65 and over, have multiple chronic conditions [7].

While chronic conditions are typically described by their long-term disease duration [8,9,10,11], the complexity that arises from the condition is not to be underestimated. Chronic conditions are particularly complex in that they tend to involve multiple factors with multiple interactions between them [12]. These conditions are described as having a complex, multiple, and co-occurring nature. These conditions can be primarily physical (e.g., diabetes and obesity), physical and behavioral (e.g., cancer and depression), or mental and behavioral (e.g., substance use and mental health).

Increasing patient needs associated with chronic conditions have led many healthcare systems—motivated by both cost and quality—to focus on providing holistic care. Studies have shown improvement in patient health outcomes and reduced system costs when services are restructured to focus on patient-oriented experiences and needs [13,14]. The recognition of such improvements has led to an increasing interest in providing single-point services, classically provided by different departments or healthcare delivery systems (e.g., primary care and behavioral health, palliative care and cancer).

1.2. The Current Healthcare Delivery System and Challenges of Conventional Clinical Modeling

The healthcare delivery system organically developed to address acute conditions. The characteristics of chronic conditions present several new healthcare delivery challenges [15,16]. Namely, continuing to deliver care well after the individual has left the healthcare facility, deeply understanding the health state of the individual, managing individualized health outcomes, and coordinating numerous practitioners representing many medical specialties [15].

Now that healthcare systems recognize the need to provide services tailored to patients with chronic diseases, healthcare uses classic clinical constructs typically used in medicine to design such services. Current clinical methods and tools to generate evidence-based models and implementing them present five key challenges. These challenges have been identified by the author based on the literature, discussions with many different types of clinicians from different training backgrounds (e.g., physicians, nurses, medical assistants, etc.) and specialities (e.g., primary care, psychiatry, palliative care, emergency medicine, etc.). These challenges are presented in

Table 1. Challenges in designing clinical models.

Challenge 1: Designed based on single-diagnosis. Generally, not applicable to patients with multiple conditions,

Challenge 2: Described at a high-level of abstraction with a focus on human personnel,

Challenge 3: Described using text-based toolkits with minimal visuals,

Challenge 4: Described with expected paths; qualitatively describes the system and may be biased, and

Challenge 5: Described with minimal to no specificity of implementation-level details.

and described in detail below.

Challenge 1: Clinical models are typically designed based on a single-diagnoses. The medical approach for generating evidence-based models, treatments, and protocols rests on the current gold standard of testing them using randomized clinical trials (RCTs). RCTs have very strict inclusion criteria, meaning that they test using a homogeneous cohort of patients. Consequently, patients with multiple and complex conditions are specifically excluded, leading to limited generalizability for patients with multiple or complex conditions.

Challenge 2: Clinical models are typically described at a high-level of abstraction with a focus on personnel (i.e., human personnel are one type of resource in the healthcare system). In doing so, clinical models do not define the needed functions, but instead describe the type of provider that should be performing these functions. Describing the model based on the type of provider is problematic for three reasons.

First, identifying a function based on the type of provider is no longer as informative as it used to be. Typically, clinical medicine names the type of provider in a manner that alludes to their functions (e.g., a surgeon performs surgery). This was possible because classic Doctor of Medicine (MD) education, training, and certification processes provide a clear description of scope of work for such a personnel. There are now many additional trainings, certifications, licenses, and bodies of knowledge that are not encompassed in the classic training and medical degree (e.g., providing palliative care, providing behavioral health care, providing opioid treatments). There is also a critical phenomenon occurring in medicine. Some of the fastest growing resources in healthcare are non-MD personnel [17]. While many of these non-MD clinicians (e.g., nurses, medical assistants, behavioral specialists, social workers) also have education programs and certifications, their experiences and continued training allow them to practice with a wider scope of work and provide higher levels of clinical care. For example, using the term “nurse” only describes the most minimal functions that a nurse can provide based on a nursing degree. However, there are nurses that provide specialized nursing support for complex palliative care, complex medication management, opioid treatment, and addiction recovery, to name a few.

Second, new integrated services may bring together personnel from across-departments, but it is important to understand that they tend to bring significantly different clinical language, culture, and operational practices. Not specifically addressing scope of work or tasks of each personnel introduces many possibilities for misunderstanding and allows the behavioral dynamics of the team to be reduced to individual personalities. Bringing together human resources from different departments or systems requires the explicit description of not only individual scope of work, but also dyads and the aggregate team scope of work.

Third, some integrated services may describe individual resource functions or tasks, but functions performed by multiple resources are rarely specifically described as to when, how, and where they are to occur. Furthermore, key functions required for team success are not well defined and, if defined, not allocated the appropriate value (i.e., value in terms of time to perform a task or payment for a task). For example, curbside consults (i.e., when a treating physician seeks information or advice for patient care in an informal face-to-face discussion) of primary care physicians with integrated behavioral health specialists are described as a key element of the collaborative care model in order to help identify the best decisions for patient care needs. It also serves as a teaching and educational moment for human resources in the system. However, it is an underutilized function in real-world implementation because it is left to occur in an ad hoc manner with no design to facilitate, encourage, or monitor when or how it occurs.

Challenge 3: Clinical models are typically described and presented primarily using text-based toolkits [18] with minimal visualizations. Neuroscience has shown that images are processed in as little as 13 ms [19], while integration of processes that allow for word recognition takes 200 ms [20]. Specifically relevant to healthcare, Tien et al. state “Constructing and communicating a mental image common to a team of, say, clinicians and nurses could facilitate collaboration and could lead to more effective decision-making at all levels, from operational to tactical to strategic. Nevertheless, cognitive facilitation is especially necessary in operational settings which are under high stress” [21]. Visual representations have the ability to relieve much of the cognitive burden of reading, comprehending, translating, and processing verbal materials in a fast paced clinical environment. Not having visual models translates to a minimal ability to first, relay the clinical model sufficiently and thoroughly when attempting to get buy-in from a clinical team for implementation and second, implement the model in an easy and time and resource efficient manner.

Challenge 4: Clinical models are typically described by the most expected paths, rather than a comprehensive list of possible paths. Justification to only model expected or typical paths are two-fold. First, it is assumed that being comprehensive distracts from the core model with unnecessary information. Not being comprehensive translates to not noticing or classifying any deviations from the expected path. This allows clinical decision making biases to persist unseen, a significant problem in healthcare [22,23]. Therefore, modeling comprehensively is key to identifying and reducing problematic variations in clinical practice due to clinician decision-making biases.

Second, decision paths are described from the providers’ perspective rather than the patients’ perspectives. While there have been significant efforts to shift the discussion of clinical decision-making from the clinician to a shared-decision between the patient and clinician [24,25], the focus of shared-decision making is made at specific times rather than for every healthcare system interaction with the patient. Taking into account patient choice at each level of the modeling allows for the explicit elucidation of patient drop-out and non-compliance. This allows for the quantification of not only services provided, but to which types of patients and with what outcomes.

Challenge 5: Clinical models are typically described with minimal to no specificity of implementation-level details. This is particularly evident where details are needed at the mid- to most-specific detail-level description of the model. While healthcare environments vary and it may be best to leave certain details to the implementer, it is critical to be able to specifically describe the aspect of the tested model, which yields the success outcomes claimed by the model. This helps to inform implementers of the critical and more optional components of the tested clinical model.

1.3. Paper Contribution—Systems Thinking Approach to Tackle Current Clinical Modeling Challenges

This paper presents and uses systems thinking and systems engineering principles and tools as an alternative strategy to thinking about and designing clinical system models and healthcare services to alleviate many of the current healthcare clinical modeling design challenges. This allows current clinical models to be described as system models with multi-level detail and quantification, currently limited in clinical models. Systems thinking as a process also produces transparency and invites collaboration and understanding across all involved stakeholders. In doing so, stakeholders gain appreciation for the complexity across the healthcare system and insights as to how their own behavior affects patients, other healthcare personnel, and the healthcare delivery system.

1.4. Paper Outline

The background, in Section 2, will first describe a systems thinking approach to modeling healthcare delivery. This includes a description of the domains applying systems thinking to the health field and a systems thinking approach to healthcare delivery. Section 3 includes an illustrative example of taking a clinical model, called the Collaborative Care Model (CoCM) and developing a system model. This includes a description of the Collaborative Care Model, the methodology for developing the system model, and a detailed description of the developed system model. Section 4 includes a discussion of advantages and limitations of systems thinking in modeling and designing healthcare delivery services and models. Finally, Section 5 ends with the paper’s conclusions.

2. Systems Thinking Approach to Modeling Healthcare Delivery

The health field, similar to most of the sciences, is based on reductionist thinking [12], breaking things down into their components and examining each of the pieces separately. On the opposite end of reductionist thinking is systems thinking. Systems thinking is based on examining the full system, its pieces, and interconnections to understand the system. The idea of systems thinking has been used in many fields and actually does not have a very clear definition. This special issue states that “Systems thinking can be broadly considered the activity of thinking applied in a systems context, forming a basis for fundamental approaches to several systems disciplines, including systems engineering, systems science, and system dynamics”.

2.1. Domains Applying Systems Thinking to the Health Field

Systems thinking and systems engineering methods and tools have been used as exemplars across the health field. This section, however, focuses on the fields that have emerged that draw significantly from systems thinking [26]. These include Systems Biology and Healthcare Systems Engineering.

Systems Biology can be broadly viewed as a convergence of molecular biology and systems theory where the focus shifts to understanding the system structure and dynamics rather than the static connections of the components [27,28,29,30,31,32,33,34,35,36,37]. One of the goals of systems biology is to understand a complex biological process in sufficient detail to allow for the building of a computational model. This model would then allow for the simulation of system behavior, thus elucidating system function [38]. This can be viewed as applying systems theory at the cellular and sub-cellular level, one of the smaller physical scales.

Healthcare Systems Engineering is a relatively new field that applies systems theory and systems engineering tools to healthcare delivery primarily in acute care (e.g., intensive care unit (ICU), emergency department (ED)). This field can be viewed as an application of industrial engineering and operations research to health [39]. It is primarily focused on informing administrative stakeholder decision-making based on computational optimization of time and cost [39]. It is primarily focused on quantitatively representing the system in order to use optimization techniques for applications ranging from scheduling [40,41,42,43,44,45], reducing errors [46], improving hospital outpatient flow [47,48], improving emergency room operations [49], and improving patient safety [50].

This section presented the two primary domains specifically focused on using systems thinking tools and methods. It is worth noting that many applications of system tools (e.g., system dynamics [51], social network analysis [52], and agent-based simulation [53]) have been used across the health field to glean insights. It is beyond the scope of this paper to describe all such applications.

2.2. Systems Thinking for Healthcare Delivery

Next, a formal description of healthcare delivery as a system is described based on systems thinking principles that specifically addresses both acute and chronic conditions [15]. It begins with describing a system in the most abstract terms, its characterization by its system function, system form, and the allocation of function to form, called the system concept. This section highlights the application of systems thinking to developing a system model representation of personalized healthcare delivery and managed individual health outcomes [15].

2.2.1. System Function

The healthcare delivery system is composed of processes representing system function (i.e., the function of a system). Four types of processes have been previously defined in the literature [15] based on merging two concepts: the clinical diagnostic framework of measure, decide, and treat [54] and engineering systems functional type classifications of transform and transport [55]. The clinical diagnostic framework first examines the patient’s complaint or concern (measure), second, decides on the cause of the issue or how to proceed next (decide), and third applies a treatment regiment (treat or transform) [54]. The healthcare delivery system function is thus represented as the union of the following four processes: Transformation Process: A physical process that transforms the operand: specifically the internal health state of the individual (i.e., treatment of condition, disease or disorder); Decision Process: A cyber(non-physical)-physical process occurring between a healthcare system resource and the operand: the individual, which generates a decision on how to proceed next with the healthcare delivery system; Measurement Process: A cyber-physical process that converts a physical property of the operand into a cyber, (i.e., non-physical, informatic) property to ascertain health state of the individual; and Transportation Process: A physical process that moves individuals between healthcare resources (e.g., bring individual to emergency department, move individual from operating to recovery room).

2.2.2. System Form

The healthcare delivery system is composed of resources representing system form (i.e., the components of a system). Four types of resources have been previously defined in the literature [15], similarly to system function. The healthcare delivery system form is thus represented as the union of the following four resources: Transformation Resource: A resource capable of a transformative effect on its operand (e.g., the health state of an individual). They include the set union of human transformation resources (e.g., surgeon, cardiologist, psychologist) and technical transformation resources (e.g., operating theaters, drugs, chemotherapy infusion room, delivery room); Decision Resource: A resource capable of advising the operand, an individual, on how to proceed next with the healthcare delivery system. They include the set union of human decision resources (e.g., oncologist, general practitioner) and technical decision resources (e.g., decision support systems, electronic medical record decision tools); Measurement Resource: A resource capable of measuring the operand: here the health state of an individual. They include the set union of human measurement resources (e.g., MRI technician, sonographer, phlebotomist) and technical measurement resources (e.g., magnetic resonance imaging scanner, ultrasound machine, hematology analyzers); and Transportation Resource: A resource capable of transporting its operand: the individuals themselves. They include the set union of human transportation resources (e.g., runners, emergency medical technician, clinical care coordinator) and technical transportation resources (e.g., ambulance, gurney, wheelchair).

2.2.3. System Concept

The allocation of system function to form then allows for the composition of a matrix representing a bipartite graph between system processes and resources, which is referred to as the system concept. This allocated matrix is defined as the system knowledge base [56,57,58,59,60,61,62] and represents the elemental capabilities that exist within the system.

3. Designing Clinical Models Using Systems Thinking and Systems Methodology: An Illustrative Example

This section takes a current clinical model and develops it into a system model as an illustrative example of a clinical model represented using elements from systems thinking. The example is of a service model that embeds behavioral health (BH) care into primary care. The remainder of this section describes the clinical model, followed by the methodology for developing the system model, and finally presents a detailed description of the designed system model.

3.1. Clinical Model of Behavioral Health Integration into Primary Care

Behavioral health care is a broad umbrella term used to encompass care for patients around mental health, substance use conditions, health behavior change, life stresses and crises, as well as stress-related physical symptoms [63,64]. Growing recognition for behavioral health needs makes this example critical and timely. The National Academy of Medicine has highlighted the importance of health care’s recognition of the interaction of physical, mental, and substance use issues when providing health care [65].

The importance of behavioral health has been echoed by many sources, including the World Health Organization (WHO) [66], the Agency for Healthcare Research and Quality (AHRQ) [67], and the Substance Abuse and Mental Health Services Administration (SAMHSA) [68]. The call to action has been strengthened by recent federal and state actions, including the Mental Health Parity and Addiction Equity Act of 2008 ensuring parity in coverage between behavioral and physical conditions and the Patient Protection and Affordable Care Act (ACA) of 2010 containing many provisions promoting integrated behavioral and physical care delivery.

There currently exist several clinical models that describe varying levels of integration of behavioral health into primary care. One of the typically referenced models is the Collaborative Care Model (CoCM) based on the IMPACT trial [69]. The Collaborative Care Model was developed by the University of Washington’s Advancing Integrated Mental Health Solutions (AIMS) Center [70]. It is typically presented using the Collaborative Care team structure visual, published initially in 2015, Figure 1 [71], and updated in 2017 with a newer visual, Figure 2 [70]. CoCM includes several figures that describe certain aspects of the model, such as the stepped care aspect of the model (where a stepped intensity level of providers are enlisted if insufficient results are being achieved) [72], or the step-by-step guide to implementing the model (described as a one-page document of high level tasks) [73]. The closest representation of functions and activities is described by the task list in Figure 3.

While the CoCM is considered a clinically successful model, “the degree of integration of behavioral care into the primary care setting can vary from selective screening, diagnosis, brief treatment, and referral to a truly integrated care approach in which all aspects of primary care recognize both the physical and behavioral perspectives” [75]. This statement describes the dissociation between the description of the model and many varying levels of implementation across different healthcare delivery systems.

3.2. Methodology for Developing the System Model

A team at a local hospital was assembled and tasked with integrating behavioral health into primary care for an initial implementation at a test site, to be further rolled out in the future as a system-wide model to several other sites. The team included a systems engineering researcher and a range of personnel from the Departments of Psychiatry and Internal Medicine. The team proceeded to develop the hospital’s integrated behavioral health service, with a heavy focus on the clinical aspect of the model followed by the operational aspect of the service model. This one-year implementation environment and process provided the knowledge needed for the development of the system model from an engineering perspective. Developing the system model of the CoCM was achieved in two steps: (1) by first describing system function, form, and context and (2) graphically representing the system.

First, the healthcare service model was described from a system function and form perspective by identifying the processes and resources, using the methodology presented in Section 2 and described in more detail in prior work [15]. Next, the system context was constructed, describing the resources performing each function at several clinically appropriate levels. This included a high-level description of the model as is typically presented in healthcare and in other fields. Next, more specific levels describing the details of the operations were constructed. This was prepared so as to highlight specific pros of integration. The determination of resources, processes, and allocation of function to form at varying levels was accomplished in two ways and from two sources. First, the material and literature on the Collaborative Care Model was used to begin to develop the model. Next, the year-long experience shadowing, interviewing and meetinging at the implementing hospital provided the much needed details.

Second, the system model was represented using a systems engineering graphical language. As part of systems thinking and systems engineering, there exists a systems modeling language that maps English language structure into graphical elements [76]. It also involves a unique vocabulary for describing structure and function of a system and can therefore be thought of as a language. The model was graphed using the model-based systems engineering tool, SysML. Finally, the model was presented and validated through individual and group feedback from the hospital team integrating behavioral health into primary care.

3.3. Description of the System Model

This section describes the system model describing the integration of behavioral health into primary care based on the collaborative care model. The multi-level system model is described by three levels. The description of the model follows in the remainder of this section, organized by system function, form, and concept.

3.3.1. System Function

System function refers to the services provided. As described in Section 2.2.1, the function of providing behavioral health within primary care in accordance with the CoCM was decomposed into several processes organized into three functional levels. Following the clinical diagnostic framework, a high-level functional model of Integrated Behavioral Health (BH) is presented in Figure 4.

It is composed of four functions: a function describing the engagement of the patient with the healthcare delivery system and the three functions from the clinical diagnostic framework. Specifically, Function 1, Engage patient describes the collective functions by which patients engage, interact, and enter the healthcare delivery system. This includes phone calls to make appointments, administrative check-in (e.g., check in at the reception desk) and clinical check-in (e.g., room patient, take vitals) processes that generally occur before a patient sees the primary care provider. Function 2, Identify/Measure behavioral health needs and severity describes the classic first step process of identifying and measuring a patient need and if required severity. Function 3, Decide on the care plan follows the identification of a behavioral health need. Deciding on a care plan incorporates understanding the patient’s needs taking into consideration their wishes and circumstances and determining how to fulfill them. This includes deciding how to proceed within the healthcare system. This may include deciding to engage an integrated behavioral health clinician to provide therapy or measurement followup. It may also include deciding that more significant behavioral health services are needed beyond what may be provided within the integrated behavioral health service. In that case, direct referral to external services may occur, or a more active referral may be initiated. Function 4, Deliver service/treatment describes the delivery of treatments or services based on the developed care plan.

The 1st level functional model of Integrated Behavioral Health, shown in Figure 4, is represented using SysML in Figure 5. These functional diagrams are called activity diagrams in SysML. This 1st level represents the primary care clinic-level system model without explicitly representing any specific integrated behavioral health functions. It shows patient contact or physical arrival (i.e., virtual or physical presence at the clinic) as inputs to this level. It also shows patients as outputs from this level when they are referred or supported into long-term external services. The figure also explicitly shows a significant problem in behavioral health, one of leakiness of patients coming from a patient’s decision to not continue, follow through, or engage in next care steps, or their inability to remain engaged.

The 2nd level functional model begins to show the details of the model classically recognized as collaborative care, as shown in Figure 6, and specifically in the Deliver Care dotted box. The 1st level identify/measure function described as “identify patients with BH needs” is functionally performed in the 2nd level by “determining and administering screening function”. The CoCM health community typically names this step “systematic screening”. The 2nd level functional model also specifically shows the decision function “determine needed BH services” as the gate to the options for BH services of the high-level deliver care function. It also makes it clear that there are four different types of internal services that integrated behavioral health services can provide in primary care. The details of each of these four services are described in the 3rd level functional model.

The 3rd level functional model is the level where specific processes are defined and can be specifically allocated to resources. Interestingly, implementation teams allocate who will perform each process at the 2nd not 3rd level. This highlights that implementers have some form of a working visual model of the sequence of processes shown in the 2nd level in Figure 6, although this visual is not represented in any of the CoCM documentation figures. Implementers allocate at the 2nd level since most of the processes represented by the yellow rectangles can be assigned to a single provider; in this case, a primary care clinician resource or behavioral health clinician resource.

Many of the functions described as key aspects to the success of integrating behavioral health into primary care are processes that require the collaboration of two or more resources. For example, the decide function (Level 1) of “determine needed BH services” (Level 2) includes a key supporting task called “engage in curbside consult” (Level 3.3, shown in Figure 7), which occurs between a primary care clinician resource and a behavioral health clinician resource, shown with a red background. This is a key task that helps with quicker identification and faster directed care towards the appropriate services needed for the patient. This task also fulfills the function of educating and training primary care clinician resources to identify, determine, and provide behavioral health care more robustly.

A second example of this can be seen under the deliver care function (Level 1) of “provide medication management” (Level 2), which includes two key supporting tasks called “engage in curbside consult” and “warm handoff—introduce patient to behavioral health clinician” (Level 3.4, shown in Figure 8) and also shown with a red background.

Not specifically identifying the need for the additional clinical resource does not provide future implements with the details to recognize what functions require these multiple resource collaborations and how to design both of their workflows to ensure that they can both engage and perform these collaborative functions efficiently and consistently.

The development of system function using the activity diagrams allows for several noteworthy contributions. First, the clinical team providing services to patients include several types of clinicians: primary care clinicians, psychiatrists, and behavioral health clinicians. While, in theory, all clinicians may have a high-level understanding of the roles of their team members, the system model visually and cognitively clarifies the processes, flows, problems, concerns, and issues of how an individual’s workflow can potentially impact other team members’ workflow. This understanding was critical for implementation processes to minimize typical and current problems and dissatisfactions by colleagues and patients. Furthermore, it is important to note that the professional environment for healthcare human resources is very hierarchical, with medical doctor (MD) clinicians at the top and non-MD clinicians socially relegated to a lower clinician status. This modeling approach brought justification and voice to team members typically unheard or marginalized, whose information was invaluable in helping develop and improve patient care experience. This section described the functions performed in the CoCM detailing the processes and interconnections at three levels. We now turn to describing a system form that embodies and performs the processes described.

3.3.2. System Form

System form in healthcare includes the human and technical resources (i.e., the people (clinical and administrative) and the tools and rooms (the electronic medical record—EMR, examination materials, etc.). The human and technical resources in the CoCM are represented using a block definition diagram in SySML Figure 9. Resources are described at the level describing provider type (e.g., nurse, receptionist, primary care provider, behavioral health clinician). In the instance where the actual resource is identified, a specific human resource name would be included. For privacy, no specific names are included in the resource diagram. Resources are also grouped based on the system boundary they belong to (i.e., Integrated Behavioral Health Service, Department of Internal Medicine, Department of Psychiatry, or External System). The description of primary care and collaborative care personnel from different departments is highlighted in the background rather than described as part of the specification of System Form. This is because these classes of personnel are typically part of different departments, but this may not be the case in every implementation site. An allocation from the external system showing counselors allocated to collaborative care represents the instances when more personnel or specific types of personnel, such as counselors, are brought in to support collaborative care. The External System may include some, none, or possibly more services than have been shown. The classes of community behavioral health services included are ones typically needed when behavioral health needs are identified. The typical types of external resources are represented in the model, however, as one may speculate, the specific types and numbers of external services vary based on the implementation site.

3.3.3. System Concept

System concept refers to the allocation of function to form, or, in other words, what (function) is performed by who (form). This is visualized in the allocation matrix in Figure 10. The allocation makes clear what processes are performed by which resource or groups of resources. In many instances, both technical and human resources are allocated to performing a specific process. Such a mapping allows implementing organizations to decide, based on their own resource availabilities, how to perform the needed tasks and therefore create their own system concept. For example, the function of “referring to long-term external behavior health services”, typically performed by a behavioral health clinician can instead be performed by a social worker who is not licensed to provide behavioral health treatment, thus freeing up behavioral health clinician time to perform other functions that require behavioral health expertise.

4. Discussion

This paper presents current challenges of designing clinical models and healthcare delivery services and presents a systems thinking approach to modeling healthcare delivery as an alternative framework to address the limitations presented in Section 1.2. An illustrative example of a clinical model, which embeds behavioral health services into primary care, was used to develop the system model. The remainder of this section highlights the advantages of system models over clinical models and the limitations of using such systems thinking models in healthcare delivery.

4.1. Potential Advantages of Systems Thinking Based Modeling

Systems thinking in healthcare delivery allows for five key advantages in system models that address the five challenges of designing clinical models, presented in Table 1. The five key advantages are presented in

Table 2. Advantages of system models.

Advantage 1: Designed based on specified needs rather than a specific diagnosis,

Advantage 2: Described at multiple levels and scales,

Advantage 3: Described visually,

Advantage 4: Described with comprehensive paths; consequently, quantitatively describing the system, and

Advantage 5: Described in multi-level detail, providing a detailed multi-level implementation description.

.

Advantage 1: System models are designed based on specified needs, rather than a specific diagnosis. The needs, also described as requirements in systems engineering, can come from patients with single or multiple diagnoses. Furthermore, since the system is designed to address specific needs, it becomes clearer to provide services that may help patients with multiple or complex diagnoses that have many different types of needs. The needs simply translate into a list of requirements that the system must be able to address.

Advantage 1 suggests that system models provide the ability over classic clinical models to describe and incorporate multiple patient needs, which need not be completely focused on a specific diagnosis. This is important and relevant since almost half of all people over the age of 45 have multiple chronic conditions [7].

Advantage 2: System models are inherently described at multiple levels and scales. Scope and scale are foundational concepts in systems thinking [77,78,79]. Diagraming a system at multiple levels is a core feature of system modeling [80,81]. Friedenthal et al. states, “An understandable model should include multiple levels of abstraction that represent different levels of detail but relate to one another” [80].

Advantage 2 suggests that system models provide the ability over classic clinical models to explain more clearly at the appropriate abstraction level the model details. This is critical for the multi-stakeholders that require different information from the model. For example, a high-level administrator would be interested in understanding the model of care implemented in their practice at the most abstract level, whereas a receptionist would need to clearly understand her tasks in detail. A classic clinical model does not provide the required information to all stakeholders.

Advantage 3: System models are described visually. Model-based systems engineering is by definition based on creating a visual model of the system. The focus on developing a model of the system is a shift from the traditional document based approach to systems engineering, where the emphasis is on producing and controlling documentation about the system [82]. The transition from the classic text document-based to visual model-based systems engineering occurred in the 1990s [83], while model-based approaches have been standard practice in electrical and mechanical design since the 1980s [80].

Advantage 3 suggests that a system model can be visually represented, whereas a typical clinical model is only described in narrative form. There are significant advantages to a visual representation. This includes the ability to see interconnections and interactions that may affect each other prior to implementation. For example, nurses suggesting a change to the method and type of data collected may not clearly pose an issue, but when checked in the system model would highlight how a specific data type is feeding into the data presented in a physicians dashboard.

Advantage 4: System models describe paths comprehensively. When modeling a system and specifically an activity, systems engineering methodology prescribes that all classes of inputs and outputs be described [78,79,82]. This ensures a comprehensive model and therefore allows the system to be quantitatively described. Situations which many clinical stakeholders may describe as having endless paths, are typically described in systems thinking by abstracting to generate a class of outputs representing a set of paths.

Advantage 4 allows system models to take into considerations paths that are typically ignored by clinicians because they believe they do not occur very often or they do not represent the focus of the model. It is critical to represent at least an abstraction of all outputs, since, when trying to understand problems in behavior, it is critical to ensure that all elements are included. This is an issue since recall abilities and perception of rates of occurrences of certain events may not be accurately recalled. For example, the role of the supporting psychiatrist in the CoCM is to have up to three clinical visits with a specific patient. Patient level data analysis, however, indicated many instances where a patient would see the psychiatrist for 10+ visits, indicating use of psychiatrists outside of the expected model.

Advantage 5: System models describe details at multiple levels, including implementation details [82]. Describing a model at multiple levels and scales to the very specific levels and scales leads to a comprehensive description that can be used for implementation. This is a natural conclusion given that engineering incorporates implementation as part of the engineering process [78,79].

Advantage 5 is critical in medicine. Engineering is naturally a field which develops and translates a solution as part of the same process. The medical research model, however, tends to follow a five-stage scheme of: T1 involves basic research, T2 involves pre-clinical research, T3 involves clinical research, T4 involves clinical implementation, and T5 involves implementation in the public health sphere [84]. Development separation creates significant delays in implementation and development, and does not take into consideration implementation science. This is an active concern of medical funding agencies [85].

4.2. Limitations of a Systems Thinking Approach in Healthcare Delivery

While the previous section presented several advantages of using systems thinking based modeling, it is also important to note possible limitations of a systems thinking approach in healthcare delivery. Three limitations have been identified and discussed below.

First, healthcare delivery systems have organized and structured their departments based on a reductionist view of the body into physical components of organ systems (e.g., cardiology, neurology, dermatology)—in other words, based on system form. This is the same mental construct used to develop clinical models. While this is exactly why there is a need for systems thinking, it is also a limitation in that the personnel in this field are not trained to think from a systems perspective. This may make systems thinking harder for healthcare personnel to grasp and understand. Systems thinking is not currently part of mainstream medical school curriculum. However, the importance of systems thinking in medicine and public health is evident in literature [86,87]. Furthermore, the Council on Education for Public Health (CEPH) (www.ceph.org) which provides accreditation to Masters of Public Health (MPH) programs and schools has now included “Apply systems thinking tools to a public health issue” as one of the foundational competencies expected of students when they complete a public health accredited degree. While systems thinking education and consequently knowledge in the healthcare field is limited, it is slowly being addressed and integrated into medical and public health education.

Second, introducing systems thinking to the healthcare field, especially to model current care, requires bringing in systems engineering personnel into the healthcare field. Although the importance of systems engineering in medicine has been presented in several high impact reports such as the President’s Council of Advisors on Science and Technology [88] and the National Academy of Sciences [89], there still exists a limited number of systems engineers entering medicine relative to other fields. This is primarily because, at this early stage, there are limited systems engineering positions in medicine and healthcare delivery. The defense sector currently attracts a significant portion of systems engineering graduates.

Third, the current fee-for-service payment models in healthcare have forced clinical practices to increase throughput of patients, leaving the system with very little space to innovate, or add any new functionalities such as systems thinking and systems modeling. The fee-for-service system creates incentives for operations research focused on increasing throughput—moving patients faster through a poorly designed system. Systems thinking and system modeling take time from the already very fast pace and full schedule load of clinicians and personnel in healthcare. While there is much evidence to suggest that systems thinking could help alleviate some of the time-related issues by ensuring that processes are performed in an efficient manner (1) relative to how they are needed by the patient, (2) relative to the operations of the healthcare delivery system, and (3) relative to the use and need of other fellow clinicians across the healthcare delivery system in space (i.e., different department) and time (i.e., one month later), current fee-for-service payment models pose a limitation.

5. Conclusions and Future Directions

In conclusion, this paper presents and uses systems thinking and systems engineering principles and tools as an alternative strategy to thinking about and designing clinical system models and healthcare services to alleviate many of the current healthcare clinical modeling design challenges. An illustrative example taking a clinical model and describing it as a system model was presented based on the literature available and implementing an integrated behavioral health model of care into primary care at a local hospital. The developed system model alleviates many of the described clinical modeling limitations, by describing the healthcare delivery system from a systems perspective, in which system form, system function, and their allocation were described at multiple levels of detail. This allowed the model to be described at varying levels, including implementation-level details, from a patient-perspective. Such a description also facilitates the ability to evaluate and quantify the system at any of the levels. The process of developing the model was also just as useful as the model. It helped the team “see” things they didn’t otherwise see, especially related to the work of co-workers and how an individual’s work process can drastically affect a downstream co-worker work flow. This process in the described case example allowed the team to make process changes that improved both organizational and patient outcomes.

The culture and current work environment in healthcare delivery systems is a fast-paced environment, which does not typically reward organizations to slow down and self-assess and develop such clinical models. The typical fee-for-service payment models pose a limitation to the translation of this work since they incentivize high patient throughput over patient satisfaction and health outcomes. Luckily, in many organizations, the patient voice, patient needs and outcomes are so highly regarded and assessed that organizations are trying to accommodate and develop these new healthcare services and models regardless of current payment models. These frameworks can be used as a roadmap for organizations to develop services and models themselves, or to translate these services and models to their organizations using a more clearly described and enumerated model described at many levels of detail. Developing these models not only helps support new healthcare delivery services, but they also address many patient needs for integrated services and an integrated system experience. This work highlights the need to increase systems trained thinkers in healthcare and systems education in clinical and public health training and degree programs.

Future work will utilize the described modeling methodology and framework to enumerate both the healthcare delivery system and individual patient trajectories. This includes the use of this model in its enumerated form to address the generally high no-show rates seen for this service. This is not atypical for behavioral health and psychiatry visits, but did suggest room for improvement. Furthermore, designing quantifiable models (i.e., allowing for the evaluation of the system model) is often requested by high-level administration assessing their clinical services.