7

Creating New Platforms with OODA

As our knowledge and experience grow, we see patterns emerging. A MoM TiSH will now introduce us to Observe-Orient-Decide-Act (OODA).

You are halfway through this book. The first half consisted of breaking down the complexity of transformation into most of the building blocks of TiSH. Now, we can start composing the transformation from the bottom up, filling in the blanks, and designing the enabling platform. When we think of platforms, we need a common ground – a shared mental model – on which to build new healthcare structures in a community. In this chapter, we will explore the main shared mental model, OODA, as the foundation of a healthcare transformation enabled by technology.

We will elaborate on OODA as a novel way to drive transformation with its feedback loops. In this chapter, the building blocks from TiSH will be put to use in the transformation of sustainable healthcare by creating disruptive platforms that enable teams to dynamically plan resources around a patient.

In the final part of the chapter, we will learn what the transformations made to these platforms look like and how they can be shaped. As an example, we will analyze Amazon Care, Buurtzorg, and Roamler Care as recent initiatives in transforming healthcare.

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

• Understanding and applying the building blocks
• Applying OODA feedback loops to create transformative platforms
• Analyzing platform-driven transformation

Understanding and applying the building blocks

As a transformation task force, we know we have to bridge the three perspectives of provisioning healthcare, enabling the community, and implementing technology platforms with a shared mental model that is understood by medical or social staff, community builders, and systems engineers.

In Figure 5.10 of Chapter 5, Leveraging TiSH as Toolkit for Common Understanding, we presented the building blocks of the TiSH value stairway with some blanks still to fill in. In this chapter, we discuss how OODA will form the principle-of shared mental model to integrate these building blocks. In later chapters, we will use the OODA shared mental model for a common understanding to define the blanks and integrate the building blocks into TiSH.

Let’s start creating the OODA shared mental model. In the following figure, we can see the building blocks arranged around OODA:

Figure 7.1 – OODA’s central shared mental model

Each of the building blocks is related to OODA. Care provisioning is observing a person’s life in terms of health, lifestyle, and participation and orienting continuously to decide what actions to take to either anticipate, prevent, or cure an illness. It works in accordance with the workflows of enabling the community and interacting with a technology platform.

Enabling community, organized to provide and support micro-enterprises within ecosystem micro-communities, defines the workflows and supports the OODA processes in accordance with the activity triangle to safeguard the human element and perspective.

The technology platform makes the OODA functions available and interactive, supports care provisioning, and is designed in the context of the activity triangle.

Now, we will discuss the perspective of care provisioning, enabling community, and the technology platform a bit further.

Reacting to health, lifestyle, and participation events with OODA

We discussed the OODA loop extensively in Chapter 4, Including the Human Factor in Transformation, but it’s good to shortly recap the principles.

In essence, OODA describes how an individual observes a situation based on the available data. All decisions are based on observations. The OODA loop shows observations coming from unfolding circumstances and interactions. These 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: experiential, cultural, and heritage, such as the quality assurance system of a care organization. The enriched information will eventually lead to decision-making and action. That decision leads to new events and that will lead to new observations and eventually, reactions or proactive anticipation.

To speed up the reaction time and reach better, more accurate outcomes, we must implement the OODA loop in the health journey of the patient or patient population to prevent worsening health conditions and detect early symptoms. Different circumstances and interactions unfold in terms of health, lifestyle, and participation. For the care provider to be in control of the situation, the changeable state of health, health conditions, and personal circumstances need to be continually observed. As we have seen in Chapter 4, Including the Human Factor in Transformation, this requires accurate data on the events that unfold.

However, this data is not readily available. It takes a lot of effort to get the data. For a better understanding, we look at the status of digitization in care provisioning from an OODA perspective. On the left-hand side of Figure 2.3, the typical activities mentioned were presented in Chapter 2, Exploring Relevant Technologies for Healthcare. On the right-hand side are the characteristics of this type of networked care:

Table 7.1 – OODA steps in digital provisioning

Each of the activities exchanges its observation, orientation, decision, or actions with other activities carried out by team members or teams – either within a healthcare organization or between organizations. Think of a GP deciding to prescribe medication that will be delivered by the pharmacist. In this rudimentary ad hoc networked care, communication is required.

With people following workflows in the systems, as mentioned here, whether ERP, EPRs, sensors from alarm buttons, or PACSs, these workflows can be integrated to form automated OODA loops. This integration via workflows is required to enable team members to interact seamlessly with the platform and be more focused on their primary job, care provisioning to patients. The care work activities are integrated to guide the patient through their health journey.

If we apply OODA to formal (not ad hoc), networked care, new opportunities arise, as described in the following table:

Table 7.2 – OODA loops in digital provisioning

With a common understanding from a medical perspective, OODA can be translated for healthcare provisioning and applied to the processes and workflows used by care and support teams.

Enabling the OODA activities

To enable the care teams, fitting workflows to their activities is required – workflows to connect the OODA steps within the organization and jointly within teams in different types of networked care. Communication workflows, coordination workflows, control workflows, and command workflows enable the patient-facing ecosystem and micro-community to work together.

The following table describes the combination of network type and type of workflows for each OODA step:

Table 7.3 – The stages of digitization

Community builders will focus on the OODA loops related to communication, collaboration, coordination, control, command, and cooperation in the care networks.

With the workflows agreed on, we will now have a look at the information we need.

Data processing on the technology platform

How do we get data that gives us an accurate view of events and recognizes patterns, thus leading to appropriate responses? To answer that question, we first need to ask: what is an event and how can we make it digital so that it can be communicated to anyone in the care network?

An event is anything that causes a significant change to somebody’s health condition, lifestyle, participation, or circumstances. These events are, in principle, observable and therefore convertible into digital information. The following diagram shows how the event is observed by collecting data and processing this data to lead to a decision or action as output. This output forms new information that’s looped back to the condition or circumstances of the patient:

Figure 7.2 – Data processing with the OODA loop

Events create data that we can observe. The collection of the data can be done by the patient entering an event into a website or by a doctor – a GP, for example – entering the data following medical protocols. The patient can be observed using sensors, check-ups, specific tests, and diagnostics, but also by events that are reported by the patient or by social networks surrounding the patient noticing an event. To recap, we can define an event as anything that causes a significant change to a health condition or personal circumstances.

If the data and therefore the observations lead to any concerns, then orientation starts: why is the event happening, or why did it? From this point onward, it gets interesting. The typical decision or action is to admit the patient to a clinical pathway with fixed workflows and processes. The pathway is bundled, so to speak. In the traditional way of providing healthcare, this is more or less a fixed journey for the patient, delivered from a hospital or other clinical organizations as one entity. This will be different in networked care.

We will analyze the data processing OODA loop depicted step by step. It’s a combination of the elements of the OODA loop and Machine Learning (ML) data processing.

The collection of data involves observing the patient and their circumstances. Actors who are observing the patient are the following:

• The patient themselves (self-assessment)
• Social networks or next of kin
• Sensor equipment
• Check-ups
• Specific tests and diagnostics
• Environmental conditions

We can automate data collection and processing, but we need learning systems for this to achieve our transformation goals. That’s where Artificial Intelligence (AI) with ML and digital twins will play a significant role. These technologies can tap into a vast repository of medical protocols and research data to create an ever faster learning loop to drive the transformation.

The end goal for the transformation is directed care where a personal case manager guides the patient through the agile clinical pathways. We foresee a development where the personal case manager as part of directed care will be an autonomous assistant based on current assistant technology, such as Siri, Google Assistant, Google Home, or Alexa.

The platform will evolve over time from tread to tread, driven by DevOps. With the aforementioned data processing model, the systems engineer has a simple but effective shared mental model to which they can relate the stories told by the care professionals.

Now, we, together with the systems engineers, must design the digital systems – the platform – that enable all this. We will discuss that in the following section.

Applying OODA feedback loops to create transformative platforms

We have learned that OODA is our shared mental model for looking at medical processes and how the activities of the enabling teams in micro-enterprises are executed and connected via workflows. We also learned how data processing can be mapped using OODA. Together, they provide the structure for the stories to be told as input for DevOps. However, remember Chapter 6, Applying the Panarchy Principle, to take the state of mind into account, and the use of CAFCR and QFD development methods, as explained in Chapter 5, Leveraging TiSH as Toolkit for Common Understanding.

Having said that, DevOps translates these stories into modular microservice architectures and shared platforms, as already common in IT. With the use of modern cloud functionality, organizations can plan resources dynamically: they use the resources when needed and only pay for these resources when they are used. If resources are no longer required, they are scaled down or suspended.

That’s not something that you can do easily with big, monolithic, legacy systems. We would need to stop the entire system, where we still might want to use some of the services that these systems provide. If we require a new feature, we would need to upgrade the whole system and might even need to plan for significant downtime for testing to check whether a new feature disrupts the system. This does not lead to the agility to form dynamic care networks in collaborations and cooperations.

Explaining microservices

It’s good to explain what microservices are all about. In contradiction to monolithic systems that are designed as one piece, microservices are loosely coupled components that form a system. You will recognize the bundling and rebundling principle here: the big monolith is transformed into a system that consists of loosely coupled modular components. The problem with monolithic systems is that they slow down innovation since it’s very hard to adopt changes within these systems. The significant advantage of microservices is that systems become more agile and scalable to swiftly accommodate the new workflows in networked care and are an important prerequisite to making the systems more modular.

As a matter of fact, it’s very hard to react to events and apply changes accordingly in vast, legacy systems. That’s the reason we need to unbundle monolithic systems and rebundle them into modular microservices systems so that they can be rapidly reconfigured for the required care networks.

In our case, the OODA microservices need to be interacted with using easy user interfaces (UXs) and stimulate individuals to do their work, but there’s also a major risk that we must consider. If more and more systems are integrated to cope with the interactions between teams, organizations, and care networks, resulting in activities with ever more types of stimuli, simultaneously in ever broader environments, it can very easily lead to an overload of stimuli from the other systems. Robotic Process Automation (RPA) and AI are required to cope with this increasing complexity without overloading individuals.

The systems engineers are tasked with designing the technological platform with intuitive systems of engagement. On the one hand, we see many great opportunities in things such as big data, ML, AI, and bioengineering, but we also see the potential undesirable effects these can have on people and, more generally, society. Patients, care providers, organizations, and society at large need time to digest the new possibilities before taking well-founded decisions. The consequences can be profound. Remember the de-decelerating forces in the panarchy.

Alongside microservices, it is at the level of these individual components that interoperability must be built in to enable integration at higher levels. With this in mind, we can start the design of the microservices. Therefore, we use the following five categories of components in systems:

• Actors such as people and machines as effectors in the physical world or performers of data processing, requiring a system of engagement.
• Sensors translating events and stimuli, whether these are people observing events and registering them in a digital system, simple detectors, such as a motion detector, or complex sensors, such as an MRI scanner or ML detecting a pattern in data. The latter includes algorithms analyzing real-time vital signs or smartwatches sensing a fall. These require systems of recording and systems of intelligence.
• Controllers for managing the activities and workflows, including when to take decisions in processes, either manually made on the part of humans or software-automated, also requiring systems of intelligence.
• Stimuli, as in, external and observable events and triggers between entities of sensors, controllers, and actors. This can range from a simple notification of a personal alarm to large amounts of data, such as 4D CT or MRI scans. These stimuli come typically from the Internet of Things.
• The environment, which influences the performance of the functions – for example, the conditions in which entities can perform. An MRI scanner typically needs a well-equipped hospital to function. A wearable gives more freedom but has fewer capabilities. Typical environments are hospitals, nursing homes, practices, homes, workplaces, outdoors, or transport. The environment is part of the system too.

The systems engineers have to explore possible solutions in (re)designing monolithic systems into modular microservices together with the users and other stakeholders, such as the community builders. The OODA functions and these system components plotted along the healthcare activities are the structures used to explore options and tell stories in healthcare. Not the underlying technologies.

Nevertheless, how do we transform from the current often monolithic systems to the new microservices?

Reversed build of the OODA loop

Can you imagine a hospital letting go of its buildings and each room in it, including all the equipment and staff? Next, staff and equipment are micro-rented by the dedicated teams around a patient. This could be done if we developed platforms and systems as microservices and had micro-enterprises as care teams. Food for thought, at least for now.

The message is that if we want to transform healthcare, we must let go of traditional thinking and of doing things simply because we have learned to do it in a specific way. That’s why we build on the principles of the OODA loop in order to facilitate the transition.

We must address OODA functions such as Act by selecting the required components, whether actors, sensors, or controllers, and determining the stimuli to which they need to respond (input) or that they need to provide (output) and which individuals will be using it in the environment. These individuals can be machines or devices, care professionals, supporting staff, or people to whom care is provided.

Actors perform a single task or multiple activities in a workflow as part of a process that the microservice supports.

Before they can act, the environment, including the required equipment, must be prepared. If a device is not already installed, it needs to be ordered and installed in such a way that it’s integrated into the workflow and operational for the individuals involved. This requires a professionally managed device service or services that includes support for the end user, the care professional, and the patient alike.

Note

This is not solely about the big irons such as CT and MR scanners but is also true for a device that takes an electrocardiogram (ECG) of the patient at home. The device needs to be set up for the patient. It’s even true for something as simple as a personal alarm system or medicine dispenser. It needs to be installed and configured so that it can support the patient in the proper way. Before the act of actually dispensing medicine, other actions already have taken place. It’s applicable to almost every action, including installing apps for self-help.

Microservices can be designed and built for each of the components for the OODA functions. Interoperability between these microservices is a design requirement for forming the OODA loops.

We have unbundled the systems into the related components at the task and activity level for each OODA step and are able to rebundle them into the required loop. At this stage, it’s important to keep track of the configuration and relations of each of the many components in terms of interoperability. For a micro-services approach to succeed, an Application Programming Interface (API) strategy is required. Legacy systems can also be gradually replaced with microservices in this way.

The significant benefit is that we now have the foundation for agile iterative innovation and transformation.

Now, go back to Table 7.2 and Table 7.3. Here, the four OODA steps and three OODA loops were related to the healthcare activities and the current ERP and EPR systems used in those activities.

We propose to (re)build the legacy systems into microservices recycling the same sequence, which is reversed from OODA to ADOO, so to speak:

• Act: Define the components with the required interoperability characteristics to communicate between activities, both inside and outside the organization
• Decide: Integrate decision-making for the teams, taking input from inside and outside the organization
• Orient: Facilitate the following in organizations:
  • Genetic heritage in guardrails, guidelines, and protocols, including formal decision points as agreed by law, in collaboration in stepped care or cooperation in integrated or directed care
  • Culture and traditions in mandates, processes, and intuitive workflow interactions in systems of engagement
  • Analytics or synthesis in algorithms in systems of intelligence
  • Previous experiences with logging, storing, and retrieving records in systems
  • New information acquired and data from sensors processed
• Observations: They become relevant when the patient and its network are involved by connecting their data to the activities of other organizations.
• Observation loop: Workflows for collaboration to coordinate each provisioning in stepped care
• Diagnose loop: Control workflows in integrated care
• Treatment loop: Command workflows in directed care

Following this sequence implies that time will be required for rebuilding. However, the sequence is purposely aligned with the TiSH staircase to keep technological and community change in sync.

In the next chapter, we will go into more detail. By defining the OODA loops, we have a way to explore the requirements and solutions for the enabling platform with the actual users.

Analyzing platform-driven transformation

In the previous sections, we discussed new systems for observing patients, driving decisions, and acting upon them. We talked about sensors and observers around the patient collecting data, allowing accurate diagnostics to be made by highly skilled practitioners and personal case management, assisted by simulations using ML and personalized medicine. These are all promising developments, but since we are discussing DevOps4Care, we must take Ops into careful consideration as well. Operations are critical in the delivery of end-to-end managed services for the sensors and other equipment, including apps and interfaces.

This is where models such as IT4IT come in. These models recognize the enabling platforms that must be managed and the product teams that develop and deploy the services on top of that platform. IT4IT uses value streams to identify and design the IT resources required to deliver end-to-end services based on the customer journey. In our case, that would be the journey of the patient and the actors in their network. New digital roles such as an e-nurse identify the needs – these are translated into services in a specialized team that makes use of microservices from managed platforms, allowing them to dynamically scale resources.

Clearly, this is not a transformation that is done overnight. We must follow the rules of DevOps and agile here. If we look at our TiSH staircase MoM, we must start with a Minimal Viable Product (MVP) at every tread: from there, development and deployment will be done step by step, taking inhibition points into account.

To succeed, organizations, teams, networks, and even societies on national levels need to be on the same page with shared mental models. Shared mental models, however, take time to build. Learning must be an integral part of the system on all levels. Otherwise, many unrelated and incompatible services (apps and programs) are not interoperable.

Therefore, we must build carefully on a step-by-step basis, starting with an MVP on each tread of our TiSH staircase.

Let’s analyze some actual examples.

Amazon Care

Amazon Care started with its own employees to provide a fitting health experience via the app so that they were able to participate well in their work at Amazon. It’s an MVP for directed care with the limited scope of, in this case, an ambulant nurse, e-doctor, and pharmacist. This covers most of the required medical attention and it provides a foundation for learning how to improve services and extend them to other groups. Learning is entrenched in the way of working, enabling Amazon Care to expand quickly. Amazon Care is as a next iteration offered to other employers in the US for their employees.

Buurtzorg

Buurtzorg has created a platform to support their specialized nurses to coordinate the care network around mostly elderly living independently at home. They create a stepped care approach for the inner (yellow) HeXagon, in which choices are made regarding what the client can do themselves, what their next of kin can do, and what can be done by the nurses at Buurtzorg. Specialized nurses are trained to oversee integral elderly care and know when to refer to other social or medical providers. This has proven to be very successful and has been adopted in many other countries.

Roamler Care

An example of an organization that has successfully implemented case management with a shared platform and executed unbundling and rebundling is Roamler Care. The organizations using Roamler Care’s platform are unbundled in crowd-sourced communities and bundled via the platform, allowing for dynamic allocation of resources around a patient based on the ad hoc needs in the virtual network. It goes without saying that Roamler Care relies heavily on technology that enables the deployment of data-driven activities:

Figure 7.3 – Aspects of the transformation for Roamler

Roamler Care unbundles care in specific tasks, which leads to a more efficient allocation of resources. To enable this, Roamler Care works in a data-driven mode. The data is collected from millions of tasks performed annually by Roamler Care teams across Europe, allowing the organization to identify patterns and make predictions. It uses the data to streamline activities and organize resources better. Before applying this principle to healthcare, they use it for quality assurance in retail (as in, mystery shoppers) and to fulfill the installation of connected equipment, such as smart thermostats in homes via Roamler Tech.

How does Roamler Care collect that data? Via mobile technology that integrates with Roamler Care’s own systems and other systems used by the professionals in the communities. In this way, care providers can work with independent care professionals and integrate them into their own organization in existing, permanent teams. It leverages the flexibility, scalability, and speed of activities at the right time, place, and for the right patient. Roamler Care provides the technology – the Roamler Care app, which is used to collect and show the tasks – and the management of the communities. It is the systems engineer and community builder.

Note

Roamler Care was founded in 2011 and has expanded to become an international organization with operations across Europe since then. More information can be found at roamler.com.

Organizations that work with Roamler Care stay in control through customer portals and dashboards. Obviously, data is protected and compliant with the defined and agreed guardrails.

Do you recognize all of the three examples from the previous sections in this chapter? You should since they are great examples of applying OODA design principles to platforms:

• Communication via care platform to enable case management to request resources when needed by Roamler
• Coordinate actions in a stepped care model by using an enabling platform, adhering to the principles of interoperability and integration by Buurtzorg
• Control via a platform by referring to the right provider for integral (elderly) care by Amazon and Buurtzorg
• Command directed by the patient based on their own health condition by Amazon

They all have joint quality control to build trust in the various networks and organizations and are learning to foster a customer-obsessed and collaborative approach to transforming healthcare and expanding this field.

Summary

In essence, this chapter was about events and how we can react to events. First, we explained what an event is: anything which causes a significant change in the health condition or personal circumstances. An event needs to be observed; we need to know that it happens. For that, we must collect data. In this chapter, we studied how we can collect and analyze the data, following the principles of OODA: Observe, Orient, Decide, and Act. We can use these principles to design our systems – that is, systems with the required feedback loops for both operational use and transformational learning.

In this chapter, we also learned how we can design systems by using microservices architectures. We have learned to unbundle and rebundle organizations – now, we must do the same with the systems that these organizations use. It’s all about enabling the dynamic scaling of resources around the patient. We unbundle the tasks and the resources and provide these when and where the patient needs them. In the final section, we saw that this is not just theory: Amazon Care, Buurtzorg, and Roamler Care have unbundled and rebundled their organizations and made their systems flexible and scalable, responding to the needs of the patients.

We’ve studied the organization of healthcare and the future systems. In the following chapter, we will discuss how all of this works out for the actual teams and the health journeys of individuals.