3

Unfolding the Complexity of Transformation

To get more understanding, playing with toys is not enough, we need to learn the complexities. MoM TiSH will lead us to some education on complexity.

The theme for this chapter is defining the complexity of healthcare. In the first two chapters, we saw that healthcare is subject to huge changes and that requires transformation. Transformation is complex and requires new disciplines to address it and realize the desired platform. We introduced the systems engineers and community builders needed for this in the transformation task force.

Systems engineers need to define the complexity of networked care using the decomposition and classification of less complex components. This chapter will provide you with models for describing the complexity characteristics of networked care on the development path toward higher treads in the transformation and describe how it affects all the systems in the healthcare sector.

We will learn about the policies and regulations that form guardrails in healthcare. We will also see how traditional healthcare provisioning based on guidelines is more focused on the output of a particular process and not the integrated health outcome for patients.

We will look at how community builders use different methodologies to define the real value for all stakeholders, such as the revenue for care providers and a better health experience for the patient. We will learn how to discover this value by listening to the voice of the patient and integrating processes in the design, development, and operations of healthcare solutions. This is the start of implementing DevOps4Care for the Transformation into Sustainable Healthcare (TiSH).

In this chapter, we’re going to cover the following topics:

• Defining complexity
• Exploring policies and regulations
• Understanding the value of care with DevOps principles
• Understanding technology in complex systems
• Understanding the role of major technology enablers

Defining complexity

In the first two chapters, we introduced TiSH and the upper four treads consisting of networked care. We learned about case management, stepped care, integrated care, and directed care. Each tread introduced more technology for digitization such as robotics, IoT, and AI to get closer to the optimum health experience. The complexity increases rapidly with each tread. But what is complexity?

Luckily, defining complexity is not so complex if we involve system engineers. Complexity in our context is the characteristics and resulting behavior of the healthcare system in which many components with multiple relations interact in multiple ways and follow certain guardrails and guidelines. It would suffice for us to concentrate on the characteristics of components and the relations and interactions between the components for now. What can we learn from systems engineers?

Complexity emerges from the many possible interactions. This follows the essence of the definition of complexity given by the International Council of Systems Engineering (INCOSE) body of knowledge – A measure of how difficult it is to understand how a system will behave or to predict the consequences of changing it (Sheard and Mostashari, 2009).

Tip

The Systems Engineering Body of Knowledge (SEBoK) maintained by the aforementioned INCOSE provides a guide to key knowledge sources and references in systems engineering. We will refer to this body of knowledge several times in this book for further information. You can search for the word complexity and follow the discussion on this topic. More information is available at https://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK).

Where does healthcare stand in complexity on a scale of one to ten? It depends, of course. Prescribing paracetamol and getting it from the pharmacy is straightforward. Let’s say that’s a 2. Having a hip replacement and going through an MRI scan, surgery, and rehabilitation with medication quickly becomes much more complex. We’ll call this a 5. But if we zoom out and look at the supply chain of the MRI scanner or paracetamol, then we enter the global supply chain. So, that’s easily a 7. If we include the financial aspects, such as reimbursement, we reach an 8, and if we do that over someone’s life span, we are at a 9. So, where is the 10? Imagine doing all of this on the moon. With NASA’s upcoming Artemis missions at the time of writing, maybe it’s something we can look forward to.

Describing the characteristics of networked care in terms of its components, relations, and interactions will help us to create a common understanding of transformation.

As we are not the first to describe complex systems, we can look for descriptions and definitions that are already available. By combining several of them, we get a specific understanding of networked care in terms of these interactions, relations, and components. Here, we will present two applicable models to describe the complexity of networked care in terms of interaction and relation.

Defining interaction

Interactions are needed to get information for some form of decision-making to agree on how to take the next steps. We can use the foresee (4C) model for that. It provides guidance on the best way to make a decision. Although, we have to take decisions in order to reach the goals that we have set, reaching these goals, as we have seen, might be influenced by changes in health conditions or environmental factors. Hence, we need to be able to adjust these decisions based on the acquired knowledge and come up with new insights. There are many variations of the 4C model, but we define it as follows:

• Communications: The interaction of ideas, opinions, and feelings in order to reach a mutual understanding of a topic and decide individually
• Coordination: The joint effort of integrating activities to enable the efficient allocation of resources within or between organizations and its team and team members
• Control: The management of setting goals and standards, measuring performance against the standards to validate whether goals will be achieved, and if needed, taking corrective action
• Command: The process of directly giving orders

We can characterize the four types of networked care as per the 4C model. It’s obvious that communication always takes place right from the start with the case manager taking decisions. With stepped care, coordination becomes more relevant to decide which step is required. Integrated care requires control on which condition to treat first. Directed care is about the patient and their condition directing a command about what care is required in the first place.

In healthcare, we will see that decision-making differs for each stakeholder. In a heavily regulated industry such as healthcare, governmental bodies set standards in terms of compliance requirements. Insurance companies issue direct orders in terms of reimbursable costs. Care teams will need coordination to get things done. In all these cases, communication is essential since every stakeholder requires information to gain knowledge before any decision can be taken.

Defining relations

With respect to the relations between the different types of networked care, we were inspired by ISO 21839, 2019 to name the four stages of networked organizations with the definitions of Systems of Systems (SoS). SoS are used for systems containing many systems interacting with other systems. Think of the communication between two hospitals with each having its own system for electronic patient records. These combinations of interacting systems can be characterized as follows:

• Ad hoc: The healthcare network lacks a central management authority and a centrally agreed-upon purpose for the ad-hoc created SoS. This type of SoS relies on mostly unseen mechanisms – for instance, underlying legislation or de facto industry standards. They may emerge in large-scale systems.
• Collaborative: The component systems of each provider interact more or less voluntarily to fulfill agreed-upon network purposes. Here, mechanisms of enforcement and maintained agreements play a role since stakeholders collectively decide how to provide or revoke services.
• Acknowledged: The healthcare network has recognized objectives, a designated manager, and resources for the joined SoS. Underlying systems still have their respective owners and own objectives, funding, development, and sustainment approaches. Changes are triggered and sustained through cooperative agreements between the SoS and the systems.
• Directed: The SoS is created and managed by the healthcare network to fulfill its purpose and achieve objectives where underlying systems become an integrated part of the SoS, whilst components of systems can still operate independently. However, the SoS is the leading, overarching system.

This derived definition (the original generic formulation can be found in the SEBoK) will help us to define the stages of the transformation.

Tip

ISO – the International Organization for Standardization – and regional or national standards are a great repository of knowledge anyway and are easy to use for defining a common reference.

It is quite plausible that as part of the development path, a network starts ad hoc as a virtual network and progresses toward being a directed network. It’s the case manager that forms ad-hoc networks depending on what an episode of care requires. In stepped care, the collaboration between the systems of each provider is required for coordination. Integrated care needs designated management of the systems to stay in control. For directed care, the patient must be able to trust that the systems are fit for the specific purpose to predict their future health condition and circumstances, as mentioned in the International Classification of Functioning, Disability and Health (ICF) model.

So, what interacting and related systems are we talking about? That is what we will define next.

Defining systems

Healthcare provisioning consists of many activities with supporting systems and their components. We define the characteristics of the systems and components based on the activities within healthcare that we mentioned in Chapter 2, Exploring Relevant Technologies for Healthcare, where we introduced the four types of networked care. Using the ICF model, these activities have a clear purpose (or main characteristic) related to health, lifestyle, and participation.

Let’s start with the activities of case management:

• Intake after a decision made by the patient based on their perceived health condition
• Prepare the pending care episode using the relevant medical history
• Assessments in triage using (self-)diagnostics, including registered circumstances
• Decision-making as the next step to either end the episode, provide more diagnostics, or commence treatment
• Providing treatment or other intervention
• Observation of outcomes

Each of these activities uses specific systems to do things such as measure vital signs, record the findings, order diagnostics, plan staff, manage reimbursement, provide CT scans, or prepare for an operation, rehabilitation, or nursing. The specific systems include electronic patient records (EPRs) and enterprise resource planning (ERP), with modules for human resource management (HRM), quality assurance (QA), and business intelligence (BI) for financial control, among others. This results in a distinct application landscape for each organization. These landscapes can be very extensive and complex on their own. It’s a SoS with architecture and governance.

For now, it suffices to know that the activities we defined as components have some internal structure.

Adding to the aforementioned activities, the case manager uses a system for communication with the different providers in the care network. This system can also comprise several applications – for example, several apps on the mobile phone of the patient. That is a system too, used mostly for communication.

With stepped care, the different landscapes of the different providers and the case manager are connected for the coordination of activities between the providers. This requires a coordinating system to connect the systems of the different care providers. This system is not necessarily a physical system – it can also be a coordination agreement to adhere to certain standards on the interoperability of systems.

With integrated care, the joint management of the interoperability and integration of systems is a system of its own. This is more than a coordination agreement; it requires a control activity to be managed. Think of joint DevOps activities and the systems they need.

Directed care requires yet another activity – the governance of all systems must ensure that people can rely on the availability of all the required systems for the optimum health experience as defined by society.

Let’s recap what we have presented so far. To describe complexity, we learned how to characterize complexity based on the type of interaction between components, the relationship between components, and the components themselves for each type of networked care using the 4C model. See the visualization in the following table:

Table 3.1 – The structural complexity characteristics of networked care

Exploring policies and regulations

Policies and regulations are determined by governments and their institutes. Although it differs for each country or region, it is possible to recognize certain elements, whether a national health service, such as the NHS in the UK, municipal, as in Finland, or regulated to some extent via insurance companies, as in a lot of countries in the European Union, or via the employer, as practiced in the US.

Policies and regulations set the guardrails for the development of solutions. Hence, we need to start with this. There’s no escaping or working around policies and regulations – we simply have to deal with them. In this section, we will explore policies, regulations, principles, and the various stakeholders that have to work with these rules of engagement in healthcare. We will learn how these rules are crucial in the delivery and transformation of healthcare.

We call these the rules of engagement, a military term that explains the internal rules for defense forces that set the guardrails for the circumstances, conditions, levels, and methods that justify the use of force by defense resources. These can be derived from internal agreements or rules set by law. As we are defending our health, it’s a metaphor you can use to make sense of policies, regulations, and the behavior of stakeholders in healthcare.

Policies and regulations set the guardrails for the circumstances, conditions, levels, treatments, and other types of interventions that necessitate care being given to patients. It’s not just the opinion, experience, skills, or judgment of a clinician or the feelings of a patient that set these conditions and circumstances. There are laws, policies, principles, standards, budgets, and even public opinions set by the media that define the conditions for the delivery and innovation of healthcare. Safety, privacy, cost, and above all, value are some of the most important themes here.

The following list contains some examples of these rules of engagement in healthcare, but is by no means exhaustive:

• Policies on what is in the scope of healthcare. Think of plastic surgery, the prevention of becoming ill, birth control, alternative medicine, certain treatments that only concern a small group, or the way palliative treatments should be done. These can be ethical issues and are influenced by politics.
• The scientific proof of treatments and medicine. This is used to define what is referred to as claims in medicine. The formal value of treatments and medicine.
• The cost of healthcare. Think of the huge cost of resources and the time spent developing medicine.
• Inspection and audits on quality and safety. An example is a recent bill in the US that calls for a Software Bill of Materials (SBOM) for 510(k)-eligible products. 510(k) is the technical dossier required by the US Food and Drug Administration (FDA) that allows you to sell medium-risk medical devices or in vitro diagnostic devices (IVDs).
• Reimbursement rules to the claims that are legitimate. This varies strongly per the insurer, as well as region and country.
• Security and privacy standards including audit frameworks. Think of the Health Insurance Portability and Accountability Act (HIPAA), the General Data Protection Regulation (GDPR), and 510(k).
• Professional standards for clinicians, physicians, nurses, and other care staff.
• Investments by medical companies, including pharmaceutics.
• Innovation – for instance, in automation.
• Legal possibilities to pursue after malpractice.

The important stakeholders in this are the following:

• National as well as local governments such as municipalities.
• Umbrella organizations for care providers, patients, and other groups of interest.
• International institutions such as the World Health Organization (WHO), the International Standards Organization (ISO), and similar regional organizations.
• Vendors and vendor programs. Think of discounts on medical equipment or certain medications.
• Patient groups.
• Unions for professionals to ensure decent wages and working conditions.
• Investors.
• Media in all forms and formats.

All of these formal and informal engagements play a role in the way future healthcare will be organized and they set guardrails and constraints on the architecture of healthcare systems. They make architecture and governance in healthcare extremely complex, especially since there are huge differences per continent, region, and even within regions, countries, or states.

If we want to disrupt this complex system, start focusing on the well-being of the patient, and lower healthcare costs, then we need to look at different systems for organizing healthcare in the future. It calls for the integration of value streams and interoperability between systems. We have to combine the disciplines of systems engineering and community building.

So to recap, complexity is about the (un)predictability of the many possible interactions between all actors within the healthcare system – interactions that can relate to communication about or the intent of the coordination, control, or command of activities. These can be activities in ad-hoc groups or organized in collaborations, such as alliances or corporations to let people direct their health; activities performed in systems or components performing functions such as diagnostics and interventions such as providing treatments and observations; activities that can be classified into case management, stepped care, integrated care, or directed care; activities with ever-increasing interaction that have to adhere to policies and regulations.

We will further discuss embracing this complexity in the following sections of this chapter and make a start by defining DevOps4Care.

Understanding the value of care with DevOps principles

The commonly used definition of DevOps is a set of practices that combines development (dev) and operations (ops), typically referring to software development. The goal is to shorten the development life cycle of digital products, whilst maintaining high quality by integrating continuous feedback from the end users.  

The most essential rules are listed as follows:

• Customer-centric action: Solutions and products are developed with the customer in mind – not only in mind but in some form of co-creation with the customer and users.
• Create with the end result in mind: What will a solution do or what will a product look like when it’s completely finished? How will it be experienced?
• Continuous improvement: A solution or a product is not a one-off thing but must be improved in every iteration.

The DevOps processes and how these are integrated into a continuous cycle are shown in the following diagram:

Figure 3.1 – The DevOps cycle

DevOps is widely adopted in IT service management and software development. It helps improve solutions through a continuous loopback into the demands that are set for solutions. Products and services are constantly improved by listening to the customer, retrieving their feedback, and integrating that into the specifications of the product or service. The next release will have improved in quality or include new features, delivering more value to the customers. Modern companies can have multiple releases per day.

An important learning curve in DevOps is that these processes will not work if the development and operations of solutions are siloed. This is a huge problem in healthcare – the industry as a whole and healthcare institutes themselves are heavily siloed. DevOps is all about teams developing and even executing solutions with end-to-end responsibility. These teams work cross-functionally and autonomously, meaning that they can and must take decisions by themselves.

How would that work in the delivery of care? Would DevOps be suitable for the delivery of healthcare? For sure it would mean a disruptive model of delivery, but as we have seen in Chapter 2, Exploring Relevant Technologies for Healthcare, with the example of the Danish Naerkliniken, it’s certainly not impossible if teams are supported with the right tools and the right skills. Care teams must become multi-disciplinary and qualified for digital work.

The key in DevOps is that it’s customer-centric, or in the case of DevOps4Care, patient-centric. It’s about delivering value to the patient. Value, Objectives, Indicators, Confidence, and Experience (VOICE) is a model that incorporates this principle very well. The VOICE model is shown in the following diagram:

Figure 3.2 – The VOICE model

VOICE was developed by the IT company Sogeti. The idea is that value sets the objectives for a product or a service. The objectives are measured by defined indicators. Confidence is about confirming that the value is delivered by achieving the objectives. Experience proves that a product or a service is fulfilling the demands of the business – this is a continuous feedback loop to constantly improve the product or service and add more value to the customer.

If we replace IT delivery with healthcare provisioning in VOICE, then it almost immediately shows that these models can be used in healthcare too. The business delivery means the output of health, the outcome of lifestyle, and the outlook to participate.

If we combine DevOps with VOICE, we get the following diagram:

Figure 3.3 – Integrated development, operations, and (health)care: DevOps4Care

The extension 4Care consists of the support to get the confidence to use digital care, experience it, value it, and be able to tell what value improvements need to be defined in the next cycle.

Supporting healthcare activities

Support is usually achieved with a service desk, training sessions when a new system is introduced, and peer support by colleagues who know how to use the systems involved in healthcare activities. We will address this topic in later chapters on how to strengthen this support with actual healthcare workers to create a better experience.

Experiencing healthcare activities

It’s during the interactions that take place within healthcare activities where the systems are experienced. This is implicit, but we will see that where the moment of truth happens. Designing and improving how these interactions are experienced is what we will concentrate on as the foundation of transformation. This is explained in further detail in upcoming chapters.

Valuing the healthcare activities

Value is a broad term and very subjective. Understanding value in light of the complexity of experience is the key to translating it into explicit terms that can form a narrative. See the Defining value in healthcare section for the terms used to give this narrative structure and meaning.

Telling about the healthcare activities

To close the 4Care feedback loop in DevOps, the storytelling must be taken care of. The value put into a structured narrative via stories feeds the monitoring. Storytelling and exploring these stories will be elaborated on in the next two chapters.

DevOps4Care is all about giving the patients and caregivers a voice to tell the stories that match the different stages in DevOps4Care and bringing change into practice with a triple-A rating: Adapt, Accept, and Adopt.

But we need a clear definition of what value is. It’s not as simple as a business case. The problem with defining value as a positive outcome of a business case is that organizations tend to start tweaking the financial levers – for example, with cost-cutting. By doing that, we’re not adding value to our end customer. In our case, the person wants treatment to improve their health and lifestyle and be able to participate in society. We need to integrate the business case and value creation with a broader perspective.

In the next section, we will discuss what value is in our proposition for healthcare.

Defining value in healthcare

Let’s define what value means in healthcare. We will explore this step by step. The steps are shown in the following diagram, including the guardrails of cost, safety, and privacy next to the value itself:

Figure 3.4 – Value creation staging in healthcare

The first stage – on the far-left-hand side of the diagram – is the supply orientation with qualified personnel, equipment, infrastructure, or services. Here, value refers to the wages of personnel and revenue for suppliers. Basically, here, value is about the earnings, as it says at the bottom of the box.

The next stage is input-oriented – the capabilities have to be built by purchasing services and resources in accordance with the requirements.

The preceding stage is followed by throughput, which is process-oriented and focuses on enough delivery capacity, with the protocols and processes made into workflows for the care activities. Care providers have typical departmental budgets for the capacity needed to perform their work. This results in the provisioning of treatments with performance and cost control defined by quality standard parameters. For the work they have done with satisfactory performance, the care providers are reimbursed, in most cases, by insurance companies or public institutions.

So far, this is the traditional way of delivering care. At most, a few care providers are involved with referrals in the chain or clinical pathway. However, we have still no guarantee that we are creating the optimum value for the patient. We are treating one medical problem or health condition and following the protocols. These protocols are, of course, based on proven medical research and clinical claims to ensure the quality of care. However, there is room for greater value in terms of quality of life.

Next, we will be focusing on value in the following three stages – output of health, outcome on lifestyle, and outlook to participate. In these stages, we create value beyond a single care provider or simple referrals in a chain. We aim for the quality of health, life, and eventually participation as the metric of real value. But why is it so difficult to get to these stages of value creation? The answer to that question is a bit cynical – follow the money and you will understand the basic behavior of the stakeholders.

To be fair, the earnings, reimbursement, and economic value stages are typically more tangible than the in-between stages. With that in mind, the buying power of teams and departmental budgets are defined within organizations and as part of the value streams. However, for the last three steps (output, outcome, and outlook), it is much harder to create these value streams. Output, outcome, and outlook are less tangible than earnings, reimbursements, and economics. Business cases are much harder to realize in practice to create value streams for these last three stages. Let’s explore the cause of that.

Medical protocols treat specific problems and often do not take the outputs of other care activities into account, leading to a disconnect between the output and outcome. The output doesn’t take the health experience of an individual patient into consideration very much, other than measuring customer satisfaction after treatment. Medical output, therefore, doesn’t generate the full potential value for the patient. However, social care can be more focused on solutions for the patient.

Hence, we can find a solution to create an integrated output for value streams to get to an optimized outcome or outlook. One reason why it can be hard to achieve this is solidarity through insurance. This sounds strange, but insurance creates a disconnect between care usage and care costs. It’s different from personal care, such as a fitness club membership. You are willing to pay for a subscription if it improves your health experience. Also, for an employer, there is a more direct relation in terms of care costs, as far as healthy employees take less sick leave. Regardless, we can see that insurance companies have an interest in reducing claims. And last but not least, there is extra economical value coming from a healthier population. Broken value streams can therefore inhibit value creation. In Chapter 6, Applying the Panarchy Principles, we will learn about some ways to detect these inhibition points and deal with them.

Theoretical insights on this can be found in Michael Porter’s Value-Based HealthCare (VBHC) approach. One important insight from that is that technology is a great enabler in creating this value. This certainly agrees with our experience that creating value streams can only be done through measuring results by collecting data.

This is the real transition in healthcare – relevant data must be collected to determine the value and how to control the value streams – exactly what VOICE aims to achieve. Let’s consider bringing DevOps4Care into practice.

One big challenge in creating value lies in enabling disciplines to communicate with each other about value – we need interoperability between systems to enable integration and synchronization through optimized workflows that aim for more individual, personalized healthcare provisioning. To add to the described complexity, we can do this continuously over the whole lifetime of a person. That means we must train care providers in the use of these systems. With that being said, we return to the need for new, digital skills on the part of these providers. Our TiSH has now really begun.

With value better defined, we can understand the complex relations, attitudes, and decisions taken better. Now, we can take this into consideration during the DevOps process. Following value, better designs can be made for the enabling systems.

In the next section, we will take a closer look at the interoperability of systems and discover how we can create an integrated SoS. However, we will learn that it’s not so much a matter of getting technology in place. We must address governance in the transformation of healthcare.

Understanding technology in complex systems

Healthcare is, almost by default, not delivered through integrated systems because of different policies and regulations and the variety of technologies. That variety and the lack of integration slows down innovation and transformation in healthcare. How do we change that? This is where the rationale behind the SoS concept becomes relevant to use in the platform that we want to develop as part of our transformation. In other words, to address the complexity of various systems, we need to understand the interoperability of these systems.

Integrating systems or components means that they must connect where they’re supposed to. Think of Lego© blocks put together. The blocks are interoperable. The blocks fit together by design. Being able to integrate systems around people needing health attention requires paying the same attention to interoperability.

Interoperability often refers to the ability of computer systems or software to exchange and make use of information that is stored and processed in different systems. Although this definition pertains to computer systems and software, it’s applicable to all systems. How do we get the systems and the professionals working with these systems to make use of information across systems in and outside their own organization and provide integrated care?

Technical architects will immediately start thinking of communication protocols, which is a logical thing to do. We have defined these protocols in healthcare systems with, for example, Health Level Seven (HL7) as a global standard for securely exchanging healthcare data, Fast Healthcare Interoperability Resources (FHIR) as a standard for interoperability, and Digital Imaging and Communications in Medicine (DICOM), which defines the standards for medical images from, for example, CT and MR scanners.

However, the challenge is not so much on the technology side of things – it’s more a matter of proper governance and community building to provide that governance.

The more complex the platform becomes, the more governance from the community is required. If we want to understand the real complexity of integrated healthcare, we first need to classify the complexity of the platform and match it with the characteristics of networked care, as defined in Figure 3.1.

For this classification, we refer to System of Systems Engineering (SoSE) this time. In the following figure, on the left-hand side, the system complexity is classified, and on the right-hand side, we have the associated type of networked care:

Figure 3.5 – Structuring governance in healthcare systems (adapted from Raymond Deiotte)

Again, we draw some insights from the defense sector. Here, complex systems are very common. As with the rules of engagement for a military campaign, we can imagine the campaign and missions from the ministry or city council formed so that a population with a healthy lifestyle can participate in society. Let’s see what we get if we can apply this understanding to TiSH.

At the bottom of the pyramid, we find the components are the resources of individual care providers. These components comprise the traditional applications for processing patient records, picture archiving from CT scans, HR and logistics applications, and also e-health devices or other resources such as sensors that define some kind of health condition. At this level, application components are usually not integrated – they mostly deliver input from single observations or perform single tasks. For care provisioning, the components in the application landscape are integrated via processes and workflows as provided by ERP applications. This is the system on an organizational level.

To get an integrated view of the overall condition of the patient, in networked care case management, we need to get these systems and components to work with other health care providers first. Their own systems will branch out, communicating with the systems of these other providers to communicate about each other’s activities. This is called a Trees-level SoS.

The collaboration in stepped care, enabling care professionals to orientate on possible (clinical) pathways, requires the Trees-level SoS of the care providers to agree on the coordination of activities in this collaboration and form a Forest-level SoS.

Next is the cooperation in integrated care where all the components of all the organizations combine to act as a single Mission-level SoS, control the concurrent care activities of all involved in the care network, and acknowledge the effects of these activities.

To get to the desired outcome for individuals and the population at large in directed care, joint decision-making and integrated workflows are required at the Campaign-level to realize the goal for the patient and population to participate in social environments again – as in, the outlook value. This calls for directing and commanding, which is at the top of the pyramid – defining the joint missions, deciding how to fulfill those missions, and acting upon them by population management.

Tip

The detailed, scientific article which Figure 3.5 is based on, A Novel Approach to Mission-Level Engineering of Complex Systems of Systems; Addressing Integration and Interoperability Shortfalls by Interrogating the Interstitials, by Ray Deiotte (ISSAC Corp) and Robert K. Garrett, Jr (Missile Defense Agency), is also a good starting point for modeling a digital twin for healthcare provisioning and defining the requirements of the technology to develop. It’s very comprehensive, but demonstrates what complex systems are can how they can be modeled.

The takeaway from this article is the term “interstitials,” which is used to define the importance of paying attention to designing the connections between constituent systems. That’s why we are going to focus on Interoperability and Integration (I & I) for each tread of the TiSH staircase. But that’s a topic for Chapter 8, Learning How Interaction Works in Technology-Enabled Care Teams.

Now is the time to remember the value creation stages that we studied in Figure 3.3 about value creation staging in healthcare; remember the stages developing from earnings to the output, outcome, and outlook. If we were to combine the horizontal value creation stages with the vertical complexity hierarchy that we showed in Figure 3.5, you can probably already guess that there is a correlation between the value and the complexity, as can be seen in the following diagram:

Figure 3.6 – Complexity versus value stages

With proper governance in place, we can define the standards for integrated systems in terms of Mission Level-SoSE. Major tech companies and their capabilities will play a significant role in this because it is too complex for any care provider. We will explore their role in the final section of this chapter.

Understanding the role of major technology providers

Technology providers are enablers – with the technology that these companies develop, they can support medical staff and patients. We have seen in the previous section that the existence of technical protocols such as FHIR and DICOM doesn’t solve the challenges of I & I by themselves. Technology is not a magic wand.

However, we are seeing the role of these providers grow and they are having more impact. With an in-depth understanding of clinical processes, they develop technology that professionals and patients can use intuitively for medical purposes.

There’s a major shift happening. Technology providers are no longer just an enabler. They are transforming into drivers of innovation as well as transformation. How did this evolve? To start with, money plays a huge role in this. Innovation means investing and that’s what these technology companies can do. These firms simply have deep pockets. Innovations are their lifeline.

Secondly, they know how to develop innovations. That’s because they have that required mindset. A lot of these companies are not hindered by regulations and policies from the start. They can start from a blank sheet, develop a solution, and along the way, iterate and improve the solution as issues occur. They don’t start with the roadblocks of regulations and policies. They start with the end goal in mind – the health and well-being of a patient.

Lastly, most of these companies have adopted DevOps as a working methodology to speed up their development and get constant feedback on products and services.

Let’s explore what’s needed for an Mission Level-SoS interoperable healthcare proposition required for harmonizing the outcome or outlook value. The following figure gives an a priori solution with all the recognizable elements we have covered:

Figure 3.7 – An a priori solution for sustainable health(care)

In the middle, we have the INCA algorithm to optimize the personal hexagon where all care is centered around the patient. This is translated into an Individual Care Plan (ICP) projected with a Community Capacity Management (CCM) platform on a Naerklinikken-style EHealthCare Model (ECM) on the left, providing care per problem or condition. On the right-hand side, information is gathered to simulate the projected type and capacity to serve the population in the community in the near future. This is used by the value board to make decisions on investments and contract the required capacity with the help of the value creation stages.

It seems deceptively easy to realize, but we will see that convincing all the stakeholders at the same time takes time. We will also see that value creation staging will help.

An important question is – why should big tech invest in this? It is common sense that technology can enable transformation. Once the first examples and evidence are delivered through initiatives such as Amazon Care, Buurtzorg, Nearklinikken, and INCA, it will attract investors. Note that Amazon Care started with its own employees and their families as the community. So, they could act as the value board deciding for themselves with closed-loop value streams – one of the success factors.

Big tech can speed up transformation by making sure the opportunities they pursue are interoperable and can be integrated into the relevant care platforms, as in the following examples:

• On the infrastructure level, the cloud services of Microsoft, AWS, and Google can be used for rapid scaling. Kubernetes-based architectures with containers and container orchestration can help with interoperability here.
• Amazon as a customer-focused logistics company can facilitate the generic process of providing the right health devices, services, and medicine at the point of care when it is needed. No special healthcare knowledge is required for such operations.
• Others such as Apple and Samsung offer very good services on personal devices including vital signs, activity tracking, and personal security. They offer app builders and accessory vendors a safe platform. However, to date, they often do not yet integrate into a seamlessly integrated personal health environment. There are examples of patients with Type 2 diabetes using eighteen apps without the ability to merge all their data into a meaningful dashboard.
• On the professional side, companies such as GE, Philips, and Siemens Healthineers, with long traditions in medicine, can and are developing more and more clinical diagnostics to use in local practices and as wearables, making it possible to shift healthcare to the left in the Nearklinikken ECM model.

Together, these companies can and should create innovative design spaces for SMEs to enable them to come up with new solutions – be they medication dispensers, social robots, home automation, or, one of our personal favorites, a hip airbag to give people with mobility problems more confidence and cushion their hip if they fall, preventing medical care. This hip airbag was an instant hit on increasing outlook value and direct contribution to participation at low cost.

Summary

This chapter served as an introduction to the methodologies that we will explore in more detail over the course of this book. These methodologies form the foundation of DevOps4Care and TiSH. We unpacked the complexity of the transformation by studying the policies and regulations that form the guardrails for provisioning healthcare first. We then discussed how we could transform healthcare by using DevOps principles. We learned that DevOps starts with the demands – the voice of the customer – and tries to translate these demands into specifications for products and services, including continuous feedback. These principles are also applicable to healthcare services. We also saw that we need different skills in healthcare to start this transformation.

The most important lesson is that we can use DevOps and other methods to start creating real value for the patient. The key is the integration of care value streams, as opposed to acting on addressing one specific medical condition, as with most contemporary healthcare. With integrated care, focusing on the overall health experience of the patient, we will create new value. Combined outputs create the outlook value – enabling the patient to participate in their communities again. Care is no longer provided in separate care episodes per condition (or siloed), but all conditions are integrated into one care program.

We concluded that integration and interoperability between systems are the key to achieving the goal of enabling the outlook of participation. This adds immense complexity to the solution, requiring an understanding of SoSE in the transformation task force to address these challenges. With that in mind, we constructed an a priori solution for sustainable healthcare, incorporating best practices from Amazon Care, Buurtzorg, Nearklinikken, and INCA. Finally, we discussed the role of big tech to enable the realization of such a solution.

This chapter was more about the methodology to correlate and validate value with stakeholders in networked care. In the next chapter, we will zoom in on the skills of the professionals in care and learn more about human interaction in the new delivery models.

Further reading

• Enterprise DevOps for Architects by Jeroen Mulder, Packt Publishing, 2021
• Quality for DevOps Teams by Rik Marselis, Berend van Veenendaal, Dennis Geurts and Wouter Ruigrok, Sogeti, 2020
• The DevOps Career Handbook by John Knight and Nate Swenson, Packt Publishing, 2022
• Healthcare Digital Transformation by Edward W. Marx and Paddy Padmanabhan, CRC Press, 2021
• Redefining Health Care: Creating Value-Based Competition on Results, by Micheal E. Porter and Elizabeth Olmsted Teisberg
• A Novel Approach to Mission-Level Engineering of Complex Systems of Systems; Addressing Integration and Interoperability Shortfalls by Interrogating the Interstitials, by Ray Deiotte (ISSAC Corp) and Robert K. Garrett, Jr (Missile Defense Agency)