4

Including the Human Factor in Transformation

Learning in a group will accelerate understanding. Indeed MoM TiSH sends us to school and interacts with the others in the classroom.

In the previous chapter, we introduced the complexity of healthcare when it comes to the transformation into data-driven healthcare. However, we also promised to keep a hundred percent focus on the persons working on their or someone else’s health. How do we take human factors into consideration? What skills do care providers need in the ongoing digitalization of healthcare?

The theme for this chapter is viewpoints on human measure. Our transformation taskforce, including the system engineering architects and community builders in healthcare, will apply one golden rule to achieve this: it’s always about the patient and the people who care for them. Healthcare is about humans. How do we make sure that humans—patients, but also next of kin, social workers, and medical staff—don’t get lost in the regulations, systems, and technology of the platform we build? How do we prevent them from getting lost in data? And how do we balance between man and machine? All these are relevant questions that we will try to answer in this chapter.

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

• Introducing human-centric information technology (IT)
• Human interaction on the health journey
• Working together in technology-enabled care (TEC) teams
• Defining a new way of organizing healthcare

Introducing human-centric IT

In the previous chapter, we stated that digital transformation requires new disciplines. We introduced systems engineering (SE) and community building as skills for our transformation taskforce team. But what about the digital and other skills of the personnel within the care organizations and other stakeholders? In this chapter, we will eventually conclude that we need new roles in healthcare to get the transformation executed in practice. An e-nurse—to put it simply, a nurse with specific digital skills—is such a role. But also remember the e-doctor from the Nearklinikken. We will come to speak about this later in this chapter from both an engineering approach and a community-building approach.

Starting with engineering, let’s get back to the basic principles of development-operations (DevOps). Companies that adopt DevOps work with autonomous tools that are end-to-end (E2E) responsible for the development and operations of a product or a service. Could we plot that model to healthcare? The short and obvious answer is yes. But we need to get a deeper understanding first of the value streams and dynamics in healthcare and what these mean for the roles and tasks that are required in this domain.

The goal that we are trying to achieve is to increase the value for the patient. We want to create real value for the patient by integrating workstreams aimed at the outlook, which is participation. To recap the learning from the previous chapter, outlook leading to participation means that a patient can—for instance—get back to work or participate in a social life again. That is the goal of care, and not just treating a specific condition.

As explained in the last chapter with DevOps4Care, we added support, experience, value, and tell features to the feedback loop to iterate to the desired value creation. Value is created in experienced interactions.

Increasing value means more and more data streams to be developed and operated. What does this mean for the activities of involved personnel, patients, and persons in other roles alike in the 4Care part of DevOps4Care? What is their perspective? Let’s find out.

Including 4Care in DevOps

DevOps is all about keeping in touch with the users: Is the platform user-friendly? Is it performing well? Is it making my work as a professional easier? Therefore, users need to be involved in the DevOps process. When we start implementing DevOps4Care, one of the first things that we need to do is to position the user well in the organization and empower them. We will learn how that will look when we study the new role of storytellers in healthcare. It’s giving the healthcare professional the opportunity to have regular talks and conversations with the back offices to express their concerns and experiences with the systems in detail. A simple “does not work” is a start, but something such as “filling in that form takes me a lot of time and I don’t understand why I have to fill it completely” is already better. The storyteller is a pivotal role in adopting new technology in care provisioning. They provide feedback for continuous improvement and innovation.

Before we dive into the 4Care component, we need to get a better understanding of DevOps as an overall concept and why it’s perfectly usable in healthcare.

To start, we must begin reasoning on experience level. This means that we start with exploring user stories. This is a common approach in DevOps and agile methods. A user story is a short description of what a user wants. Typically, user stories are used as the start of product or software development. A user story consists of a few sentences in the user’s common language stating what the user does or must do as part of their job. In our case, a user story should be something a patient or care worker desires. In other words: what do the patient and their caregivers want or need? Next, a user story must have a certain format. A typical format for a user story looks like this: As a {persona}, I want to be able to {action} so that I can {goal}.

Note

Remember we mentioned earlier that we need to automate DevOps4Care to address the fact that programmers are an even scarcer resource than care personnel? Let’s have a small intermezzo to contemplate that before we proceed. Imagine that the preceding story of the persona is enough to make a new app. What are the possibilities to realize code by just telling stories? Hold that thought—we’ll come back to it later in this chapter.

From the user story, we can derive and set objectives and requirements. What should a solution aim for, and what requirements do we need to fulfill to achieve the objectives? Even more important, when do we consider a solution to be ready? In development, this is often referred to as the Definition of Done (DoD). The DoD sets a very clear description of the status when a product or a service is ready to be delivered. From that point onward, feedback is retrieved to improve the product or service. We will discover in the next sections how this feedback loop is integrated into models that we can use for the delivery of healthcare, but first, we will study user stories.

Defining user stories

In this section, we turn to the users of the systems. In different stages of DevOps4Care, we involve three types of users as storytellers. We can then plot these storytellers to the different stages in the user story. These triple-A stages are adapt, accept, and adopt. This addresses the adoption of new or modified systems and ways of working by all users. How would that translate into a concrete model with real user stories? We will have the following:

• Lead users who help in the development process (adapt). These lead users are able to tell or show the developers what the needs are. Lead users are not bound to a role. They can be a patient, next of kin or a friend, or a caregiver. They are highly motivated.
• Specialized users who enroll the solutions into the operations (accept). We can think of an e-nurse. An e-nurse is a trained nurse with extra skills to understand how new or adapted systems would fit into healthcare provisioning and advise what has to be changed before it can be accepted.
• Supporting users who provide peer support (adopt) to all other users in understanding the why and the how. They typically have coaching skills to tell the story to users, operators, and developers alike.

The number of users scales with every stage, from a few lead users to more specialized users and many supporting users. Consequently, a different way to look at this is at what development stage these storyteller types can be the most effective in terms of the following scaling phases: start-up, scale-up, and scaler. Let’s look at this in more detail here:

• The initial development of processes and technology adaptation is the start-up phase with help of the lead users to guide the process
• Scale-up is done through specialized users such as an e-nurse and an e-doctor who have accepted the processes and systems to use in the field
• The supporting users are used as the scaler, making sure that processes and systems are adopted on a wide basis in the field

Recognizing these three types of users in the organization makes sure that the stories from these actual users are the input for the development process.

How is this done in practice? Let’s have a look at Figure 4.1, which is based on the Activity Theory and the triangle model developed by Y. Engeström, used for the Digicoach training program developed by Q-Consult Zorg for the healthcare innovation institute, ZonMw commissioned by the Dutch Ministry of Public Health, Welfare and Sport (VWS).

Tip

For more insights, the scientific research behind the Activity Theory can be explored. A good starting point is the bundle of articles Learning and Expanding with Activity Theory, edited by Annalisa Sannino, Harry Daniels, and Kris D. Gutiérrez at http://www.cambridge.org/9780521760751 where in part Five, Article 16 of Who is Acting in an Activity System by Rita Engeström explores the application of Activity Theory in a healthcare setting.

Remember that in the last chapter, we emphasized interactions and activities are key to the experience. The source of the stories is in these activities and interactions. Therefore, model structuring activities to identify relations to understand the complexity is what we need. That is the Activity Theory and, specifically, the activity triangle. This will help in analyzing the narrative of the stories. Stories are in the center of gravity in the activity triangle shown in the following diagram:

Figure 4.1 – Digital healthcare activity triangle (Courtesy of Q-Consult Zorg)

The Digicoach program was developed to increase the capacity of peer support on the actual work floors where care is provided. Care workers of all sorts were trained to understand digitalization from the point of view of the people engaged in digital activities and learn how to be a coach for their co-workers.

The activity triangle relates the care workers engaged in digital activities related to the 30 terms such as interaction, competences, information, and processes shown in Figure 4.1. The digicoaches (digital coaches) are trained to support their peers on the work floor, and when feedback is needed from management and technology suppliers, they have—from the defined terms—the vocabulary to express themselves. They have learned to tell stories.

Now, we can put this to good use in DevOps4Care. As mentioned shortly before, we added the support, experience, value, and tell features to the feedback loop to iterate to the desired value creation.

For each of these features in 4Care, the digicoach can express themself with the activity triangle terms shown in Figure 4.1, as follows:

• Support is extended by the digicoach for the right skills. This form of peer support coexists with the more traditional help or service desk.
• Experience of the users is noticed through their acquired coaching skills in the Activity Triangle terms of policies, division of labor, community, the sense and meaning of it, and the interaction characteristics of the platform.
• Value for the patient is understood in terms of problems and solutions for output in better health, outcome in health lifestyle, and outlook on participation.
• Telling stories about how the interaction with the platform used in the working processes influences the experience of the users and the value for both users and patients.

The digicoach is also trained to be aware of the relations between the other terms of the activity triangle to be better able to indicate problems and room for improvement.

Using these terms in the narrative helps to format the story as input for the developers, like so:

As a {professional doctor}, I want to be able to {interact remotely with the nurse present with the patient} so that I can {inspect the wound} {using the smartglass the nurse is wearing}.

The terms not mentioned are not forgotten but form the explicit context of the story to take into consideration during development.

The same is true for the e-nurse (or e-doctor) specialized user, with the distinction that they are not only aware of the relationships but have a better understanding of them. They are expected to give more structured stories.

The lead user has an intrinsic motivation and direct interest to develop specific applications or improve them. It is quite common for lead users to show the way it can or should be done. To capture their stories, the aforementioned digicoaches and specialized users can conduct a semi-structured interview.

This is how these three roles act as storytellers for the input of DevOps iterations, and they comply with the one rule: it’s always about the patient and the people who care for them. Healthcare is about humans.

With the terms in the activity triangle, we have learned that from a viewpoint of people such as professionals engaged in digital activities, it’s about interactions between people and platforms—interactions with applications to access information to engage with passion in the activity with the patient, an engagement requiring digital competences based on the right skills. That’s what we are going to talk about in the next section.

Human interaction on the health journey

In the activity triangle shown in Figure 4.1, we have identified that the relation between the people and the platform is the interaction between them, given the context of the other entities. In daily practice, this translates to many types of applications to support the interactions in which they engage in their activities throughout the health journey of the patient. In Chapter 1, Understanding (the Need for) Transformation, Figure 1.7, we depicted the personal health journey with the desired output of better health with meaningful health information needed in interactions.

Complexity is in the number of possible interactions between all types of actors—a number of interactions that, in the reality of healthcare provisioning, very quickly become very complex indeed, certainly within health journeys in networked care. To embrace the complexity, we need to model these interactions from the caregiver’s perspective, both within the teams of care professionals and between the teams also providing care for the patient.

The following diagram is a representation of the types of data streams, workflows, and processes for these interactions. You will recognize medical data, planning data, financial data, logistics data, support data, data on human resources (HR), and communications used in activities:

Figure 4.2 – Example of data streams in care provisioning

It’s not very hard to see and understand that all these data streams can easily lead to an overload of information for the care provider, who sits in the middle of the diagram, yet all this data is required to enable the interactions to provide care. However, an overload of data can mean that data is not processed into meaningful information to be utilized in decision-making. What is worse is it will distract from personal attention to the patient. This can all lead to undesired effects, such as higher workloads and lower job satisfaction. Gone is the passion—hardly something to keep the sector attractive for professionals. Therefore, traditional automation of processes is no longer improving healthcare; on the contrary, it inhibits progress.

Hence, we must understand what we need to do when it comes to designing and engineering integrated digital care. We must design systems in such a way that users can easily understand and use these systems. This is the field of Human Systems Integration (HSI). We will learn more about this in the next section.

Working with HSI

Let’s have another look at Figure 4.2 and identify different workflows and processes. We recognize the following processes:

• Registration of patients
• Scheduling of appointments
• Defining the patient journey (customer relationship management, or CRM)
• Filing discharge instructions
• Initiating reimbursement and payment
• Filing training admissions
• Processing support requests
• Supporting audit procedures

But it’s not just the process itself—with every process, we must consider privacy, security, patient safety, and value as well. This will add to the number of interactions within the process and thus more stimuli for the worker, meaning more attention points. Does technology lift the burden of this? Unfortunately, that’s often not the case since healthcare has to deal with a lot of legacy systems. Workers must scroll through many fields and fill out various pages in systems, creating an even bigger load. The complaint of having too many administrative tasks in healthcare is an often-heard tune.

This is a bad thing, as you will see in the example of increasing complexity by the increased number of interactions. So, how do we decrease it?

Here’s where HSI can help. HSI comes with a comprehensive set of principles that integrate nicely with the principles of DevOps. Some of the principles from the perspective of care workers are set out here:

• Registering only once and reusing data
• Combining actions into one step in the workflow
• Automating as much as possible; also, things such as single sign-on (SSO)
• A common look and feel
• Single support desk

Keep in mind that this will apply also to patients, but is more complicated in the last two points. A common look and feel for the patient is very personal and has to do with all interactions, including using apps for travel, banking, shopping, gaming, and much more. A healthcare application must take into consideration that different types of users have different user requirements.

It’s a good idea to leverage a bit on what HSI is and how it could benefit design in healthcare systems. To put it simply, HSI encompasses an approach to developing systems that focuses on the interfaces between man and machine. To achieve optimal interaction between humans and technical systems, HSI includes multiple domains, as outlined here:

• Improved utilization of manpower
• Reduced training costs for using technology
• Improved user acceptance
• Decreased life-cycle costs of systems because of decreased need for redesign

HSI is a topic within SE that we introduced as an important discipline to be included in our transformation taskforce. SE is applied in designing complex environments such as aerospace or traffic control where vast amounts of data are used for decision-making. That’s why we think it’s a good place to look for best practices to be used in healthcare. So, let’s have a look.

Recently, a new vision of SE, called Systems Engineering Vision 2035 (or Vision 35 for short) was released. In that vision, systems in 2035 will be even more autonomous and more interconnected, and stakeholders will expect these systems to be safe, secure, resilient, and affordable. Obviously, this includes systems for healthcare.

Tip

The International Council on Systems Engineering (INCOSE) offers a huge generic knowledge base to explore, with Vision 35 as an excellent starting point. Have a look at https://violin-strawberry-9kms.squarespace.com/model-based-practices.

One of the key elements in Vision 35 is model-based working. INCOSE states the future of SE is predominantly model-based. Vision 35 implies the use of virtual, digital twin-based models that can be reused many times and that enable a high degree of collaboration. To put this in a more comprehensive wording, virtual models allow for intensive user testing and reduce the costs of engineering dramatically. Cloud and cloud-native technologies with high-capacity compute infrastructure are preferred in future engineering.

The challenge is that the many legacy systems in place within healthcare prevent an ideal design for systems that comply with the HSI principles. Legacy systems are often based on 30-year-old design principles and are typically monolithic, whereas in modern system design, services are designed as microservices, using cloud and cloud-native technology. Let’s look at this in a bit more detail here:

• Monolithic: Systems designed as one piece. Typically, these systems are capable of handling multiple tasks, but components in the systems are tightly coupled. Changing the architecture is complex.
• Microservices: Systems built as microservices consist of loosely coupled, independent services that have been developed and deployed separately. These independent services can integrate with other services using application programming interfaces (APIs). These systems are more flexible and scalable. Changes to these systems are easier since updates and upgrades can be executed per service instead of for the entire system, but require more governance on integration.

If we design according to microservices architectures, the integration of systems becomes more manageable. The driver for this, however, is not technology itself but to relieve the burden on staff. A way to do that is to create interoperability between systems and—especially—data streams so that staff get the exact right data at the right place and time. Interoperability requires that we design with integration in mind—integration of data streams, processes, and workflows.

HSI can have several stages to integrate, as outlined here:

• Screen integration: Bigger screens with more room to display the user interfaces (UIs) of different systems and the ability to cut and paste. Not ideal, but the first step for task integration by the user, assisted with the presentation level.
• Robotic process automation (RPA) to automate processes. Suitable for simple rule-based administration tasks and point-of-care process automation assisted by artificial intelligence (AI).
• Integration of workflow engines such as Zapier and If This Then That (IFTTT) and integration platforms from leading enterprise resource planning (ERP)/CRM and electronic patient record (EPR) solution providers for integration on a workflow level.
• HSI first-principle redesign (sometimes referred to as brownfield or refactoring) to address all levels at once.
• A new modern HSI system taking fully into account all new developments in the automation of DevOps4Care. We asked a question to imagine how storytelling can drive development directly. We can think of using, for example, Azure Generative Pretrained Transformer 3 (Azure GPT-3) to generate code based on the narrative from the stories. We think this is, in the end, needed for a large-scale transformation.

Building greenfield is one solution to leapfrog HSI, meaning that we build new systems, according to the HSI principles, from the ground up. This is one of the common transformation strategies. We would build a new healthcare network and transfer services and involved personas—stakeholders, providers, patients—one by one. However, we must still deal with the legacy systems that are hard to replace or rebuild without disrupting critical-care processes in a dramatic way. But what we can do is build an interaction model alongside the patient’s journey as a starting point, focusing on the interaction between humans and systems, and limiting the number of interactions that users must have with underlying systems. We can build greenfield cockpits and dashboards as tools for interaction. We can also automate processes.

Designing human interaction

For those interested in the how, a discipline that excels in supporting interactions is the design of UIs in these cockpits and dashboards. Without exaggerating, this is, in our experience, by far the biggest success factor for successful digital transformation. Comprehensive UIs are essential for an optimal user experience (UX). It’s the crux, so to speak. To make this more tangible, we can think of a UI as the comprehensive, transparent entrance to underlying systems.

A UI is the first level of interaction between humans and systems. In architecture, UIs are commonly referred to as systems of engagement (SOEs), whereas the underlying systems that hold and process the data are referred to as systems of record (SORs). Humans engage in activities through SOEs, so these must be extremely user-friendly.

The number of interactions in the engagement layer should be limited to patterns that can lead to direct actions—only those with a direct impact on the activities influencing the health condition of the patient for the better. Obviously, the technology guiding the care provider in understanding the interactions, identifying relevant issues, and taking the right, highest-priority decisions must be user-friendly.

With this, we concluded the first tread of Transformation into Sustainable Healthcare (TiSH) for people skilled in digital activities for TEC. Next, we’ll talk about interaction in TEC teams.

Working together in TEC teams

In the previous section, we concluded that we needed to build new systems. Think of SOEs, such as the cockpits and dashboards in aerospace that limit the number of actions that users have to execute and avoid an information overload. Once properly designed, these newly designed systems form a basis to work together with other team members, and if all team members can utilize technology, then we have a TEC team. This will also have an effect on supporting systems.

The different types of storytellers in the team are trained in listening to the users and are able to tell the story to the enabling management and developers of technology. The storytellers must be able to use certain words and concepts in their narrative to be understood. They have learned to use the terms of the activity triangle, but those terms have to be detailed. Although people are not strict, digital transformation requires specific definitions, such as for processes. This is shown in the following diagram, where a simple model is plotted to the required processes:

Figure 4.3 – Representation of workflows and processes

The technology layer, where information—data—is processed and systems are built and used, is depicted at the bottom of the diagram. The enabling management layer sits in the middle, whereas the top layer is the actual care layer or the layer where the TEC team operates, interacts, and provides care.

Provisioning is carried out in activities that consist of the following:

• Actions: Discrete activities performed by stakeholders or automated in a system
• Tasks: Series of related actions taken to achieve specified results or outcomes
• Procedures: Sequential tasks that form a distinct phase of a workflow (or protocol if it is regulated)
• Processes: Activities that contribute toward achieving larger goals or objectives, such as medical, management, and communication objectives
• Workflows: Series of actions, tasks, and procedures over the processes performed to achieve a set output by an actor

We have now defined a process model for telling stories for lean digitization with only relevant interactions for the people engaged in the activities and creating skills needed for digital transformation. This will shape and guide teams to work in a data-driven way, but always with a strong human focus.

Tip

Note that what we discussed is oversimplified. The reality is much more complex. To get a good appreciation of it, we refer to the International Organization for Standardization (ISO) 13940, of which a visualization can be found on the website http://www.contsys.org. A link is given in the Further reading section at the end of the chapter.

The green triangle in the middle of the diagram in Figure 4.1 is also representing the three roles in the TEC team for this. The TEC team incorporates digitally proficient professionals, uses technology, and is embedded in the management of an organization as a change agent. It is the leading example for the rest of the organization. From this position, it helps other professionals, works with management on continuous improvements, and voices stories to technology providers inside and outside the organization, all with the purpose of creating a voice telling stories matching the different stages in DevOps4Care and bringing change into practice with a triple-A rating: adapt, accept, adopt.

Now that we have activities in a sequence or workflow with processes and tasks, it’s time to decide in what order they have to be carried out on the health journey—how to decide on the right things in the right way at the right pace.

Data-driven decisions with OODA

In the previous sections, we introduced DevOps4Care and TEC teams. We learned that in the current system landscape in healthcare, there’s a high risk of information overload. Hence, we explored frameworks that enable us to build new systems that limit the number of interactions between professionals and systems and avoid the overload of data. However, teams do need data. The systems that we design, build, and operate should enable professionals to get the right data at the right place and right moment. They need the data to take decisions on the health journey. We can be inspired by how customer journeys are supported in general with the interaction of touchpoints and moments of truth in Chapter 8, Learning How Interaction Works in Technology-Enabled Care Teams, where we will address this in more detail. For now, it’s important to know that decisions have to be made. We need the TEC teams to become data-driven to do that.

What does data-driven mean? It means that organizations or humans take decisions based on data as evidence and not only on experiences or intuition. Doesn’t experience play a role at all? On the contrary. Working data-driven is, above all, working based on facts. These facts are collected from data that is analyzed with analytics tools. These tools translate data, using data models, into meaningful and useful information. The information combined with knowledge and—indeed—experience form insights. Insights are input for decisions and actions.

This is a recurring theme in all types of decisions. Therefore, we can use the Observe, Orient, Decide, Act (OODA) loop developed by the American military strategist and air force colonel John Boyd to visualize this recurring process, as follows:

Figure 4.4 – Basic OODA model

It’s a simple but very powerful model that will help us greatly in embracing the complexity, as we will see in the remainder of this book.

In the acronym OODA, Observe means gathering data and facts, Orient for using it to make information on which we can Decide to Act. That is the main loop. The dotted lines are shortcuts when either more data is needed to orient on, the action is clear, or a decision is made to have another look and observe further.

The OODA loop gives us a mechanism to design systems by classifying the type of interaction and can relate to the enabling technology.

With respect to increased complexity, it allows us to focus on the now. The activities and interactions themselves are to be classified as observation, orientation, decision, or acting activities or interactions. To make sense, they always will have to form an OODA loop.

Learning together to use this way of looking at activities and interactions can increase our common understanding of complexity. In Chapter 7, Creating New Platforms with OODA, we will discuss in more detail how to use the model, but we will discuss the model here in terms of its relation to healthcare.

The basic idea is that observation means measuring the temperature, for example. The orientation is making diagnostics based on the measurement. If a fever is diagnosed, a decision could be made to prescribe paracetamol. The loop is closed by taking, after a while, a new temperature measurement to see if the fever has gone.

As mentioned, the model has some shortcuts. One is this: if the orientation is that the temperature is in range, further observations are done by measuring the temperature at regular intervals until a decision has to be made. This is the observation loop.

Another shortcut is that after orientation, we want to know if there are other symptoms to observe to get better diagnostics—for example, does the patient experience pain? This is the diagnostics loop.

The third shortcut is that there might be something else going on that requires a different look at the patient altogether. Maybe a different discipline is needed for a different type of treatment. This we call the treatment loop.

If a different discipline is needed, another team has to be involved, triggering its own OODA loop.

The following diagram shows a more elaborate OODA-loop model:

Figure 4.5 – The OODA model for sustainable healthcare

The power of the model lies in the fact that it incorporates human measures such as generic heritage consisting of the guardrails and guidelines set in medicine, cultural tradition within healthcare, and previous experiences of care workers. But the main point of OODA is that all decisions are based on observations. In the preceding diagram, we see observations coming from unfolding circumstances and interactions. Observations lead to information that is processed in the orient phase. In other words: observations do not immediately lead to decisions and actions. Observations are filtered through human factors: experience, culture, and the generic heritage of medicine. The enriched information will eventually lead to decision-making and action.

Let’s elaborate this into a use case for care—a case for our TEC team. We start with the patient and observations related to the patient. The care provider will observe the health condition but will also collect data about the circumstances. That is likely raw data such as blood pressure, heart rate, body temperature, skin conditions, abnormalities in movements and cognitive capabilities, plus environmental factors ranging from weather and social activities to interactions with the caregivers in the network. A lot of this data can be collected through technical means, using medical monitoring equipment and all types of health, wellness, and activity apps. But also, the findings of other teams are observed, including their explicit decisions in the treatment loop. This data is now processed through analysis and synthesis in the orient phase and combined with knowledge, experience, and heritage to form information on the patient or patient groups on which decisions can be made.

The essence of OODA is to get inside the OODA loop of the health disorder of the patient. Within the observation loop, we have unfolding circumstances and interactions such as medication; hence, the care provider needs to be in control of the situation. This can be further observed, such as vital signs monitoring on the unfolding situation of health condition and circumstances, or—if needed—direct action such as changing the prescription to intervene in the situation. This implicit guidance and control take care of both normal conditions not needing extra attention and emergency situations requiring explicit action. The data gives a clear picture of what to do. Think also of the response when a fall is detected, and an alarm is forwarded.

However, if the data does not provide clear information on the situation for decisions on what to do next, we enter the diagnostics loop. At first, decisions will probably be taken on the first observations and medical history—the initial available data. Analysis and synthesis give several options to make a decision on which diagnostics are required. Think of the Nearklinikken E-health Care Model (ECM) stepped care model to decide which step to take. Prior to taking action to step up the care by a level, we can test the hypothesis by making extra diagnostics.

Are that decision and subsequent test leading to new insights? For the treatment loop, in the orient phase, the care provider needs to weigh up the outcomes—is the reaction as expected, or is it leading to new unfolding events? This can again lead to clarity for implicit control or needing another decision for a different treatment. At all phases in the loop, information must be readily available to take the right next step.

The unfolding interaction on the health journey can be precisely defined with the OODA model and used to enrich the stories. Learning about the OODA model to structure the stories is therefore recommended for specialized users such as e-nurses and developers.

It is clear by now that in the case of advanced healthcare, quick and precise data acquisition and information processing—such as diagnostics and decision support—must be designed carefully to avoid attention overload or delayed decision-making. This is increasingly the case for networked care.

Operating with OODA also means that TEC teams have to be enabled to work as autonomously as possible to be speedy with decision-making and subsequent actions based on the decisions. Teams need to be able to respond quick to unfolding circumstances: that’s the essence of OODA.

The TEC teams need full support on how observations can be made and new information gathered, which protocols and procedures (genetic heritage) to follow, and which systems to use for analysis and synthesis to facilitate decision-making, to name a few. The next question is: how to organize the support for these teams? That’s the third tread of TiSH. We will discuss that in the final section of this chapter.

Defining a new way of organizing healthcare

We started this chapter with systems creating a lot of various data streams, causing the risk of information overload for care providers. Next, we explored possibilities to overcome this issue by developing new systems with the use of storytellers and creating autonomous working TEC teams that work OODA data-driven, based on the right data at the right time and place. New systems akin to cockpits and dashboards should enable decision-making based on specific datasets and workflows.

We have one more task to do, and that is to organize these data-driven autonomous TEC teams. This can be done in traditional organizations such as a nursing home or a hospital, or with a group of practitioners. However, we saw that cooperation and collaboration between teams of what are traditionally different and siloed organizations are increasingly required to create more value. Demolish the silos is a remark you’ll often hear when developing networked care ecosystems. Maybe it’s time to look for a truly disruptive solution. Here, we need the community builders of the transformation taskforce and look at the concepts they bring in.

A solution to that challenge could be micro-enterprises (MEs). At least, we invite you to think about it. In this section, we will therefore study these MEs, which allow entrepreneurship to focus 100% on the patient. We will look at the Entrepreneurial Ecosystem Enabling Organization (3EO) concept to organize the TEC and its supporting teams.

3EO was inspired by the Rendanheyi model that was first implemented by the Chinese company Haier, a world-leading manufacturer of domestic appliances. The chief executive officer (CEO) of Haier, Zhang Ruimin, is convinced that organizations constantly need to adapt to changing realities. The only way to do so is by creating network organizations that can swiftly adapt to changing conditions.

Rendanheyi literally means employer-user-combination, and that is exactly what the concept implies—in Rendanheyi, an employer doesn’t listen to the one that sits higher in the hierarchy of the organization, but to the user. The user is at the center of every single decision. By doing so, organizations that work according to the Rendanheyi principles create an experience economy. It’s all about the UX.

Translated to healthcare, it’s all about the patient’s health experience. Care organizations that adopt Rendanheyi would be better equipped to listen directly to the patients and provide care to the exact needs of the patient. The TEC teams are modeled according to the Rendanheyi principles of 3EO. They interact directly with the patients and can take joint decisions with the patients—data-driven and, as such, enabled through technology.

What Haier did with this approach was restructure its organization to become more customer-oriented. With MEs, it unbundled the organization and rebundled it into a rigorous customer-focused community.

This sounds like a good approach to focus on the health experience and a (re)constructive way to demolish silos.

Implementing MEs as a disruptive model in healthcare

How can we apply 3EO to organize the health experience? In Chapter 9, Working with Complex (System of) Systems, we will go into detail on this. For now, we will touch upon the basic principles.

It starts with the care network, as defined in the HeXagon-model that we presented in the previous chapters. This care network is the ultimate customer- (patient-) focused ME delivering the outlook on participation as value. All team members are truly focused on the care needs of the patient to achieve the optimum value.

This HeXME as the user ME gets revenues from insurance, the patient itself, and—as a possibility—the patient’s employer and or municipality. With this revenue, formal and informal care is acquired from other MEs. This can be from local practices such as a physiotherapist’s team or a computerized tomography (CT)-scan team residing in a hospital.

The HeXME also gets services from so-called node MEs via shared services platforms (SSPs) enabling support. Think of reimbursement, planning, managed IT services, getting trained on new medical methods, or career planning—typical staff operations in traditional organizations.

The value board is the industry platform (IP) that can decide whether user and node MEs are fitting in the ecosystem by adding the right value. The value board makes decisions based on architecture principles such as OODA-type of operations and common shared platforms design within the constraints of guardrails’ value, safety, costs, and privacy.

The HeXagon elements can be found as different MEs scattered around the ecosystem and can be easily bundled and configured as required for each patient. However, to do that properly, the organizations of traditional care providers must be willing to unbundle their organization first. That probably will not start all at once, but it is possible to start with a few patients and grow from there. All transition scenarios and speeds are possible, as we will discover in the following chapters.

The 3EO system in healthcare is shown in the following diagram:

Figure 4.6 – Boundaryless 3EO map applied to health experience

In the center, the architecting takes place to ensure the genetic heritage with interoperable and integrated systems and structures throughout the ecosystem. In our case, this is symbolized by the OODA loop. Governance based on that genetic heritage is executed by the IP formed, in our case, by the value board.

The enabling-node MEs provide SSPs such as analytics services and federated regulation (blue hexagon) representing the secure exchange of medical information between MEs and staff services to nurture the culture in the ecosystem through HR, education, and coaching. The enterprising outer ring consists of specialized care teams providing care to the care network of patients.

To recap in general, 3EO is based on a few relatively simple principles for transforming organizations, as follows:

• 3EO is based on the concept of MEs as a set of loosely coupled, independent units that work autonomously, cutting down on bureaucracy and organizational debt.
• 3EO promotes a culture of independence and entrepreneurship: teams are empowered to take decisions and are responsible for those decisions. Teams can even decide to create new teams and new enterprises to fuel innovation.
• MEs are independent, but they are part of an ecosystem. Choices and strategies are derived from that ecosystem. This is likely the most important principle. In the vision of 3EO, the user shapes the ecosystem and is ultimately in charge of decisions. In healthcare, this is indeed a revolutionary model. It would mean that patients are in charge and not the care organizations.

In short, MEs have the right to make decisions and hire staff and are empowered to drive innovation. 3EO defines two types of MEs: user MEs and node MEs. User MEs directly address the needs of users—in our case, patients. Node MEs enable user MEs with more centralized functions such as research and development (R&D), logistics, and supply management. User and node MEs as a community work closely together to provide the best service that directly matches the needs of the users. User MEs also gather continuous feedback, looping back into the node MEs to constantly improve products and services.

In Chapter 9, Working with Complex (System of) Systems, we will study 3EO in more detail and learn more about MEs. In Chapter 12, Executing the Transformation, we will show how to put it all together and discuss the field experiences with autonomous teams.

Human factors in the TiSH staircase

What we have learned are the first steps in embracing complexity by introducing models to describe it. The activity triangle, interactions, workflow, OODA loop, and (re)bundling of teams can be used not only to count the number of possible interactions but also to classify them, and put them into the context of relations with guardrails, guidelines, and the value of healthcare provisioning. These are important steps to be able to get insights and use these in the transformation of healthcare.

We have studied the need for transformation in healthcare in Chapter 1, Understanding (the Need for) Transformation, explored new technologies in Chapter 2, Exploring Relevant Technologies for Healthcare, and discussed the changing roles of different stakeholders in Chapter 3, Unfolding the Complexity of Transformation, in that transformation—the patient being the most important stakeholder. Together with the insights based on the description of complexity, these form a basis of the requirements for transformation. It is all part of the TiSH staircase, as shown in the next diagram, which serves as a visual recap:

Figure 4.7 – TiSH first three treads

The first tier shows that the Activity Theory helps in getting skilled people to interact with digital systems used in the workflows of capable teams. The second tier shows how the OODA creates capable TEC teams and takes informed decisions. The third tier is about how 3EO creates the flexibility to manage and organize the unsiloed capacity for the networked care upstairs. Together, they form building blocks to ensure the human measure in the transformation by telling compelling stories. The next chapter will complement the other building blocks of TiSH to understand how to create sustainable healthcare.

Summary

For the human factor, we learned that the Activity Theory gives us a clear point of view from people’s perspectives of digital transformation. Caregivers in healthcare face a growing risk of information overload. We must create systems that allow professionals to swiftly come to the right decisions, taken jointly with and for the patient. We studied a new way of SE, focusing on UX and limiting the number of interactions between humans and systems. HSI is an architecting and engineering methodology to achieve this.

Next, these systems must be continuously improved. The same applies to processes and workflows. In this chapter, we further introduced DevOps4Care. We addressed the role of real-life storytellers to realize a process where feedback is continuously looped back into the requirements for systems, workflows, and processes, with the goal of improving the patient’s life. We’ve studied OODA, to organize data-driven care teams. OODA teaches us how to value observations and take decisions while circumstances, such as the patient’s condition, change. We learned that the right data at the right time, presented in a coherent way to the caregiver, is crucial.

Now, we need to organize teams around these data-driven concepts and make sure that these teams are mandated to make decisions. We introduced Rendanheyi and the 3EO concepts, working with MEs that form autonomously working, technology-enabled teams with an extreme focus on the patient—however, integrated into a network with other stakeholders in healthcare.

With this fourth chapter, we have learned to describe the complexity and introduced the components to eventually start working with TiSH. This will be the main subject of the next chapter—using these components as a toolkit for designing the transformation and the platform.

Further reading

If you would like to read more on the topics covered in this chapter, please refer to the following resources:

• A Discourse on Winning and Losing, by Col John R. Boyd, USAF, Retired, Edited and Compiled by Dr. Grant T. Hammond, Air University Press, page 383 (Appendix, The OODA Loop shows the original OODA loop)
• Website visualizing ISO 13940, Contsys.org, by Nicholas Oughtibridge and Trish Williams: https://www.contsys.org/package/7+Concepts+related+to+activities
• Blog on 3EO: https://www.boundaryless.io/blog/an-entrepreneurial-ecosystem-enabling-organization/
• The Experience Economy by B. Joseph Pine, Harvard Business Review, 1999
• RenDanHeYi: the Organizational Model Defining the Future of Work?: https://corporate-rebels.com/rendanheyi-forum/