5

Leveraging TiSH as Toolkit for Common Understanding

We experienced that MoM TiSH was very helpful. What more has she got in store for us?

The theme for this chapter is how to apply Transformation in Sustainable Healthcare (TiSH) itself. It’s the core toolkit for our transformation task force to embrace complexity tread by tread. In this chapter, we will start building the TiSH toolkit for common understanding, bringing people, technology, and organizations together in a framework of comprehensible models. Eventually, this body of knowledge on models will evolve into the use of DevOps4Care, which is a specific implementation of DevOps for healthcare.

In the previous chapters, we learned that we can describe the complexity of transforming the first treads on the TiSH staircase. However, we not only want to be able to describe the complexity, but we also want to embrace it and guide the transformation itself. That is what the remaining steps on the staircase are about.

We will describe how to learn using TiSH and its underlying models and methods. TiSH and DevOps4Care will be used in the following chapters, showing you how to plan the transformation, model the digital architecture, business, and medicine for use in design, and implement innovations in healthcare and which disciplines to involve.

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

• Starting the modeling for human-centric transformation
• Transforming for people, teams, and organizations
• Defining the transformation strategy
• Working toward automated DevOps

Starting the modeling for human-centric transformation

Transforming is about having sufficient insights into the complexity of transformation to be able to plan the next step with reasonable safety to handle the risks of not being able to predict everything. These risks are worth it because of the values to be gained, as depicted in Figure 3.4.

This means we need models to get insights into the complexity and models to use those insights to transform healthcare. We are going to fill the building blocks of the TiSH framework with these models and build up the embracement of complexity through common understanding tread by tread. This will be from the individual, team, and organization tiers and scales to the provisioning of care, health, lifestyle, and participation tiers and scales.

We use the Systems of Systems Engineering (SoSE) complexity pyramid in Figure 3.6, along with the DevOps4Care process steps, to get a better understanding of how all the models relate to each other. In this chapter, this will be combined in the TiSH stairway.

Let’s recap what we have discussed so far. We ended with the users telling their stories comprehensibly for the developers. Now, we can put this into the perspective of the transformation.

In the first four chapters, we introduced several models. These models relate to each other with respect to the TiSH framework. Additionally, we visualized them. The visual recap is made into icons. These model icons will be used in drawings, putting the models in each other’s context.

In Chapter 1, Understanding (the Need for) Transformation, we introduced TiSH and the objective of the transformation, participation through an optimized health experience symbolized by HeXagon, and introduced integrated care. The basic models are shown in the following diagram:

Figure 5.1 – The TiSH, directed care HeXagon, and integrated care icons

In Chapter 2, Exploring Relevant Technologies for Healthcare, we discussed how technology can create a data-driven network to help realize that objective. We introduced the International Classification of Functioning, Disability, and Health (ICF) model to represent the different types of information, discussed the stepped care model, and learned about case management. The following diagram is a visual representation of this:

Figure 5.2 – The ICF, stepped care, and case management icons

Also, we introduced different types of technology, from standard digital input to messaging, real-world interaction with effectors, sensing in real time, the Internet of Things, AI, and autonomous robots. The icons are as follows:

Figure 5.3 – The technology icons

Chapter 3, Unfolding the Complexity of Transformation, showed, in Table 3.1, the characteristics of the 4Cs (Communication, Coordination, Control, and Command) and stages of networked organizations. This supports the step-by-step approach to creating value with DevOps4Care, and with the awareness that systems also increase in complexity into systems of systems. We’re using the following set of icons:

Figure 5.4 – The 4Cs and networked organizations’ icons

The visualization of value creation with DevOps4Care is shown here:

Figure 5.5 – Creating value and DevOps4Care icons

Finally, we need icons to represent the system of systems complexity and platform design. This is illustrated in the following diagram with the complexity pyramid and the a priori platform design. We need this to define TiSH as an actual complexity model that incorporates everything in the coming sections and chapters:

Figure 5.6 – The system of systems complexity and platform design icons

In Chapter 4, Including the Human Factor in Transformation, we put in the human measure at the personal level, with the activity triangle, interactions, processes and workflows, teams, and organizations, plus a way to use the Observe, Orient, Decide, Act (OODA) loop as the leading principal for the systems architecture. Rendanheyi is used to rebundle organizations with micro-enterprises, forming networked care in ecosystem micro-communities. The icons for the human factor are shown in the following diagram:

Figure 5.7 – The human factor icons

That completes all of the models so far. We have gathered a lot of the knowledge that is packed into these various models. If we continue in this way, you will probably be overloaded with even more models and knowledge. The conclusion afterward would be that the digital transformation of healthcare is indeed complex. But we promised that we can embrace this complexity to make the transformation actionable with a common understanding. That is what TiSH is all about, as we will discover in the next section.

Let’s start simply with four quadrants in our reasoning framework behind TiSH, as shown in the following diagram:

Figure 5.8 – A basic reasoning framework

The upper part is about policies, and the lower part is about execution. The left-hand side shows the internal organization, and the right-hand side shows the external network.

The overlap of Organization and Network are the interactions, and the overlap of Policy and Execution are the goals. One of the boxes in the middle is the goal for the interaction between Organization and Network.

With this basic framework, we can distinguish our reasoning between policies, execution, organization, network, and the relationship between them in terms of goals and interactions.

As pointed out, we use models for common understanding and the digital twin for Model-Based Systems Engineering (MBSE) at some point in the future. Let’s fill the reasoning framework with the models that we presented and put them in each other’s context:

Figure 5.9 – The position of the models in the reasoning framework

The operational layer is formed by people engaging in activities, as modeled in the activity triangle, and people who interact in teams in processes and workflows for the provisioning and communicating, coordinating, controlling, or commanding of the network.

The tactical layer starts with the OODA way of working in teams, a blank for something to arrange provisioning (to be defined in Chapter 8, Learning How Interaction Works in Technology-Enabled Care Teams in ad hoc or virtual, collaborative, acknowledged, or directed networks.

The strategy layer begins with the (re)bundling of TEC teams for provisioning using a platform that, in the end, evolves into the solution for enabling sustainable healthcare. From the a priori solution given in Chapter 3, Unfolding the Complexity of Transformation, we have to define the strategy for the TEC platform for each of the goals of the four types of networked care.

If we add value creation staging, the complexity pyramid, the technology types, and DevOps4Care, then we get a better understanding of how all the models relate to each other, combined on the TiSH stairway, as shown in Figure 5.10.

We still have to fill in the blanks, but the models give each other the context needed to limit the complexity in each tread. For example, the first blank component is something between the TEC teams and workflows, based on OODA. Technology refers to both standard business applications and the use of effector devices such as medicine dispensers or smart locks. The value is to create capacity within a given budget. We will address that in Chapter 7, Creating New Platforms with OODA:

Figure 5.10 – The almost filled-in building blocks of the TiSH value staircase

The three blanks on the systems level are about the platform, which will be addressed in Chapter 8, Learning How Interaction Works in Technology-Enabled Care Teams, and Chapter 9, Working with Complex (System of) Systems. With this, we mention a quote that is allegedly from Albert Einstein: “Keep it simple, but not simpler than that.”

In the next section, we will explore what sustainable healthcare is, what our top block campaign could look like, and what steps our transformation task force must take to achieve the goals based on our models.

Defining the campaign for transformation

A campaign needs consensus: what is the ultimate goal of transformation? Transformation is about change. But what does “change” mean? Well, it refers to something that doesn’t stay the way it was, but transformation also implies that something is changing into something profoundly or even disruptively different, something that has been thought through very well indeed. Change is a consequence of choice, that is, a choice for a future direction. In the paper Co-Emerging Futures: A model for reflecting on streams in future change, which was published by Philips Design in 2019, this was explained in philosophical terms. A link can be found in the Further reading section at the end of this chapter.

One type of transformation referred to in the paper is also a sustainable (Habitania) scenario. Habitania aims for a good standard of living for all humans, acknowledging that the world in which humans live has limitations such as non-renewable resources. This transformation direction seeks a balance between humans and the world they live in, while also fulfilling the desire for wealth and optimal access to resources for all.

The next question, and part of setting the campaign, is how do we get there?

We might have an example in Society 5.0 that envisions changing healthcare in Japan to learn from.

A leading example – Society 5.0

Japanese society is facing severe threats since its population is aging rapidly, more so than in other parts of the world. This imposes massive challenges on the healthcare system. There is an urgent need to transform healthcare; first and foremost, to enable people to participate in society for as long as possible. That’s the outlook that defines the campaign of Society 5.0. But secondly, the costs of traditionally organized healthcare simply get too high. The rise in costs is the second driver of the transformation of healthcare.

Japanese healthcare institutions have adopted the principles of Society 5.0 at large, shifting care to the beginning of the health continuum – prevention – using modern technology, including digitalization, and embracing biotechnology. It involves a shift from curative care to prevention, standardized care to personalized care, and provider-led healthcare to active patient involvement. The results are improved longevity with longer periods of good health and, thus, improved quality of life.

The Japanese Business Federation, Keidanren, developed an action plan for reforming healthcare in Society 5.0. This plan certainly holds some revolutionary elements, such as unraveling mechanisms of the human body using biotech.

The plan further comprises the mass collection, linkage, and use of life-course data:

• Collect: This includes genomic tests and extensive health exam checklists but also the utilization of wearable devices. The digitalization and standardization of medical and care data are key in Society 5.0.
• Link: Data belongs to the patient, who has control over that data through medical blockchains in Personal Data Stores (PDS) and further in the ID-controlled development of Electronic Health Records (EHR) and Personal Health Records (PHR).
• Use: This includes a national database forming a healthcare data platform. This platform has open access, yet is compliant with guardrails provided through new healthcare platform laws. Under these conditions and guardrails, the database can also be used by private sector firms.

The plan leads to two major developments:

• Next-generation medicine: This includes personalized, regenerative medicines, digital therapy, and other new forms of care.
• Integrated healthcare services: Personal health programs are developed providing pre-symptomatic care and prevention plans. These programs are coordinated by private firms, local governments, and hospitals. Hospitals are also involved to guide and assist in remote patient monitoring.

The closing remark in the plan of Keidanren is that “Society 5.0 is a human-centered society. Healthcare is one domain that could benefit most through utilization of cutting-edge technologies.” This is exactly what we are trying to achieve in TiSH, using DevOps4Care.

Now we need to figure out how we can start the execution and plan the transformation. First, we need to understand that our plan doesn’t stand on its own. The transformation of healthcare means the transformation of an ecosystem and the building of collaborating organizations. We will explore that in the next section. In the Working toward automated DevOps4Care section of this chapter, we will put it all together, connecting people, processes, and technology.

Transforming for people, teams, and organizations

It is important to understand the stories of the care workers, but also understand under which circumstances these stories have been told. The people, the teams they work in, and the organizations experience transformations that influence their stories. So, be sure to involve the management of change specialists within the task force.

We are going to explore the methods these specialists use, which can be applied to the treads of individual skills, capable teams, and organizational capacity in TiSH.

Our approach is not only about systems architecture, but also a community that enables people, teams – our Technology Enabled Care (TEC) teams – and their organizations to grow, wherein professionals learn and come to joint decision-making in a healthcare ecosystem and community:

Figure 5.11 – The GROW individual model, Tuckman’s team building model, and Greiner’s organizational development model

So, how do we get there? There are several methods that community builders can use for this: GROW, the personal growth model; Tuckman’s Model of Team Dynamics; and Greiner’s Organizational Growth Model. On a personal level, in the operational tier of TiSH, we can use the basic GROW model (Goals, Reality, Options, Will):

• Goals: What are our goals, and what do we want to achieve?
• Reality: What happens, and why does it happen?
• Options: What is the best course of action?
• Will: Are we provisioning the solution and executing the action (and gathering feedback to check whether we are achieving our goals)?

Our TEC teams in the tactical tier will go through the following Tuckman phases of development:

• Forming the team and getting to know each other
• Storming to establish the required relations
• Norming the purpose and goals
• Performing (the desired state)
• Adjourning when things have to be abandoned or changed

The model that Larry Greiner developed identifies five stages for growing the organization and forming a good reference for the organizational context in the strategy tier.

Greiner sees growth through the following:

• Creativity: This means small, informal teams that work in an agile way to create products or services.
• Direction: Managers are hired to give direction to the teams. Decisions are taken by managers and no longer by the teams themselves. Formal parts of an organization are formed, such as a sales or human resources department.
• Delegation: The leadership starts delegating tasks back to the teams and starts hiring professionals with the right skills to empower the teams. Also, responsibility is shifted back to the teams.
• Coordination: Teams work together to get to best results and the best outcome. Workflows and processes are matured and embedded in the culture.
• Collaboration: All teams work together in a trusted manner, and successes are shared amongst every member of every team. Team members are encouraged to bring in new ideas for products and services or improvements for leaner processes and workflows. All teams recognize their contribution to the success of the entire organization.

We will address these methods further in the coming chapters, such as in development cycles in Chapter 6, Applying the Panarchy Principle, and community building in Chapter 11, Planning, Designing, and Architecting the Transformation.

Defining the transformation strategy

With the changes in individuals, teams, and organizations covered, we also need specialists in the strategy of networked care. The strategy for sustainable healthcare with digital means implies that we need a TEC platform consisting of technology and the teams and communities using this technology. We need a TEC platform with modern architectures that is flexible and agile, suitable for the DevOps way of working, and that consists of reusable components from earlier treads. In technical architecture, we would refer to this as microservices – loosely coupled components that communicate with other services through interfaces. Microservices do not stand on themselves. They are all part of an ecosystem. An ecosystem exists through collaboration. So, a mature architecture is an architecture that enables collaboration in the communities. This is also true for the TEC platform.

This is only realized in a situation where user and stakeholder stories are centerstage for the DevOps4Care processes, as described in Chapter 4, Including the Human Factor in Transformation. Starting with the a priori solution, we need a path from the current loosely coupled digital systems of the individual care providers to the fully capable TEC platform for directed care.

Additionally, an important part of the strategy has to cope with the limited recourses of both medical and IT staff. The transformation has to facilitate autonomous self-learning systems as much as possible. The automation of DevOps4Care is a viable solution for this. Also, the transformation is about building this part of the solution. In order to do so, a model of development and operations itself is required. We will start with modeling development in this chapter. Operations will follow in Chapter 9, Working with Complex (System of) Systems.

So far, we have defined our own strategy to start our architecture, and we have concluded that the architecture can only mature by collaborating with and learning about organizations in the ecosystem communities of healthcare. In essence, we have laid out the strategy and the organization of the architecture of the TEC platform through collaboration, aiming for joint decision-making on all levels as the guiding process in healthcare.

Here, we need specialist knowledge from experts. Why do we ask them?

Well, for (automating) DevOps4Care and connecting to people, processes, and technology in a truly integrated architecture for every transformation, we need a structured method.

And yes, to embrace complexity, we need some sophisticated methods.

We will briefly study two possible methods used by these experts:

• CAFCR stands for Customer Objectives, Application, Functional, Conceptual, and Realization. We will use this as a decomposition of architecture.
• Quality Function Deployment (QFD) is one of the specific submethods to be applied in CAFCR to integrate or compose the architecture again.

Both methods are highly driven by user stories, which is the input that drives DevOps. Both methods work toward the definition of value, which in our case is the value for the health, lifestyle, and participation of people. We will elaborate on this in the next sections.

Working toward automated DevOps4Care

We started this chapter by looking at the reasoning framework, reflecting on TiSH and the models that we have used so far. In this section, we will learn how to use reasoning with this when working with DevOps4Care for each tread and building block on the TiSH value stairway.

In Chapter 4, Including the Human Factor in Transformation, we introduced the concept of user stories and the storytellers themselves as part of the 4Care part. We learned how to build a user story as a way to describe the desire of the patient and its caregivers, and what the user does or must do to achieve a certain goal.

To build the user story, we use the experience of the user, their circumstances, and the goal we want to achieve. From that user story, we derive the needs and, subsequently, set objectives and requirements to define how we must fulfill the goal and what a particular service or product should look like. In the case of the highest value tread, we consider how we should organize care to fulfill the optimal outcome and outlook for the patient. Remember our campaign: our outlook is patients, or better healthy persons, participating in society. However, experience and circumstances are equally important to each value tread.

We know that circumstances change. Therefore, we need an architecture that can adopt these changes and evolve to the next value tread. Depending on the stakeholders’ perspectives, requirements might change. We constantly evaluate what happens, why events happen, what will happen, and what’s the best course of action.

By doing this, we can connect the user story (human) with the DevOps process for realization using technology and work toward an accurate design of the desired solution for the chosen value. We do this with the CAFCR method, as explained next.

Reasoning is the power behind good architecting, as Gerrit Muller explains very well in his work Architectural Reasoning Explained. The following flowchart presents a way that tells us how to reason. We can combine this in one model that encompasses knowledge, organizational development, the human factor, and technology:

Figure 5.12 – The reasoning approach

The preceding model shows how we start from a dominant need, which, in our case, is a specific tread or building block in the transformation, to sustainable healthcare, expressed through users to create the optimum health experience in each personal HeXagon network. With this, we gain knowledge and create insights to fulfill this dominant need. These insights are broadened by asking questions such as what happens, and why does it happen? This leads to decision-making: what’s the best course for action, what is influencing this course, and will these actions lead to the desired outcome? As the model shows, this is a process of continuous refinement.

In Figure 5.13, the CAFCR method is explained in more detail. With reasoning, you think about the design, then explore specific details, hold the details against the qualities from the guardrails and the guidelines on privacy, safety, cost and value, and use different submethods to specify the requirements of the component, system, or system of systems.

Note that, in the lower-left corner, you have the people’s perspective, starting with the context of the HeXagon, and in the upper-right corner, you have the realized TEC platform. In between Customer objectives and People form the input of the application of the system (of systems) to be designed and to understand the circumstances. This is used to define the functional requirements of the system and the conceptual solutions to be realized in the actual technology to be used by the people:

Figure 5.13 – Reasoning, exploring, qualities, and submethods using CAFCR and QFD

The power and distinction in the CAFCR method are in the four REQS layers:

• Reasoning: This starts with reasoning, which is probably 90% of the time spent by all involved in the development, not only architects and engineers but also operations, caregivers, and patients alike.
• Exploring: When it comes to sharing each other’s thoughts and then stories and reflections or reactions on it are the next step to explore the needs, requirements, and possible direction of the solutions together. Design thinking workshops, patient journey sessions, prototypes, and hackathons are great ways to listen to and interact with stories, not only verbally but also by action.
• Integrating via Qualities: This is the rigorous process to see whether the quality standards are met via our specific application of the QFD methods, as explained next. The guardrails are mapped to architectural artifacts.
• Submethods: The formalization of specifications through the decomposition of artifacts is done through Customer objectives, Application, Functional, Conceptual, and Realization processes, logically translating the human operational view into technological realization. This is the final step that concludes the process of needs, requirements, changes, and releases.

It’s fair to say that the method should be called CAFCR REQS because the four REQS layers are at the core of the model.

Reasoning is mostly done individually. Exploring is done jointly via the user stories. We have already paid some attention to both. Integrating the qualities and formalizing specifications using submethods also have to be addressed with formal models to embrace the complexity, by keeping consistent and being comprehensible, and being able to automate the DevOps4Care cycles.

The models forming the building blocks form a starting point.

Remember that, in our reasoning threads, the viewpoint of the customer objectives must be derived from health experiences. That requires a relation map. That relation map could look like the diagram in Figure 5.14. Here, the QFD map comes in and represents the integrated architecture, connecting people with processes and technology in which the CAFCR elements can be recognized:

Figure 5.14 – Going from Customer Objectives to Realization and back to Users

Clearly, we start with the users, who are the patients, but also the next of kin, professional caregivers, and volunteers helping to provide care. The user is everyone and everything that can be seen as an entity or actor that plays a role in providing (think of devices, too) or receiving care.

Users have competencies: they have a profile and a specific role, and through education and experience, have gained the skills to perform a function. One way to define a profile is through the Canadian Medical Education Directions for Specialists (CanMEDS) framework that identifies the abilities that practitioners require or Skills Framework for the Information Age (SFIA) 8 for IT competencies.

From the different user perspectives, we derive user stories to identify customer objectives. Remember that we must deal with various dimensions: a society where users live, organizations that they are part of, and their skill levels of using technology, just to name a few examples. All of this matters in terms of defining the user story and, eventually, setting objectives. What type of care is required? What type of care must be provided? This translates into the Voice of the Customer (VoC), which we will discuss, in more detail, in the next section.

From the VoC, we can define the solutions using the other steps of CAFCR. Customer objectives are translated via a House of Quality (HoQ) into requirements following the BAIT principles: Business, Application, Information, Technology. A business requirement answers the following question: what problem are we solving? To understand the problem and define the solution, we need information. The interface to that information – data – is the application.

To support users to get information using an application, we need technology: a comprehensive tool to view and analyze data that enables the execution of functions. Functions are assembled in a portfolio providing solutions for prevention, diagnostics, treatments, and different forms of care.

Note

To get a better understanding, please read the classic article, House of Quality, by John R. Hauser and Don Clausing, which was published in May 1988. It can be found on HBR at https://hbr.org/1988/05/the-house-of-quality.

Now we need people to work with that portfolio, providing solutions that match the objectives and requirements of the customer. For that, we use the models in Figure 5.14.

Besides that, patient safety and security are a priority when it comes to providing care, next to costs and value. Hence, we need guardrails to make sure that care is provided safely by people that have the right knowledge and skills to execute the solutions at affordable costs with respect to the value experienced. These professionals along with the patients will give feedback on the solutions. This feedback is looped back into the VoC, completing the life cycle of DevOps4Care.

By the way, what we just did is reasoning through QFD threads. We started reasoning from the customer, translated that into objectives and requirements, defined a methodology to derive solutions, and made sure that we created a safe, secure environment to execute those solutions. In the next section, we will explain how to use QFD and HoQ more specifically.

Here, we remark that the experts included in the transformation task force must be given time to exercise these methods in the task force to make the task force more capable.

Using the VoC in DevOps

In the previous section, we introduced the VoC to define customer objectives and as a methodology to start creating user stories. VoC is part of a broader method called QFD. In this section, we will explore what QFD is and how it can help us in transforming healthcare.

Once we have defined the user story, we must integrate it with the constraints of the stakeholders so that we specify the exact requirements. For exploring constraints and translating to specifications, QFD is a comprehensive method. QFD is a process that helps to translate customer requirements into the detailed specifications of products, by describing the various components and planning of development, tracking the entire process to ensure that the requirements are fulfilled.

The HoQ is another attribute within QFD to ensure that the customer requirements (VoC) have a direct relationship with the activities to achieve these requirements. The HoQ is a quality matrix that monitors whether the requirements are met and how resources are planned to fulfill the requirements in Dev, Ops, and 4Care.

In QFD, it is essential how the VoC is communicated throughout an organization. The entire organization needs to be aware of the VoC to work together in creating the desired products and services that deliver value to the customer, expressed in the VoC. QFD emphasizes the demands and wishes of the customer, which need to be accomplished. It does not focus on what a provider believes a customer wants or desires.

So, how does this match with DevOps principles and user stories? Well, a user story could be a good way to make the VoC tangible and very concrete. Where, in DevOps and agile, we would get to the so-called epics and features of the product, QFD defines four stages in getting to the definition and development of a product or service. Also, user stories must come from real voices, not what an engineer thinks the user wants!

With this in mind, we will study the four stages briefly, mapping them to DevOps and agile artifacts:

• Product definition: This is based on the collection of the VoC. In agile working and DevOps, we would define an epic, which is an artifact that can be detailed in specific tasks – the user stories – based on the needs and demands of the customer.
• Product development: Components of the product are identified and specified. In DevOps, we would refer to features.
• Process development: In this phase, the process flow is developed, describing how the product is being assembled.
• Quality control: The product is tested and inspected for any failures. Only when all the tests have been successfully completed, the product is launched for production. Testing for quality is essential in DevOps. This is always a team effort. The team defines and designs the tests and decides when tests have resulted in the expected outcome. The HoQ plays an essential role in this process. So, have these activities led to the desired outcome?

We can translate that to healthcare and DevOps4Care. We start with the VoC, and using the HoQ, we monitor whether all activities lead to the desired outcome, which is health to participate in society (again). Through aligned processes, team participation, and integrated workflows we ensure collaboration. In Chapters 7, 8, and 9, we will learn how to make this specific.

Take another look at Figure 5.14: you will now recognize how VoC, HoQ, and QFD provide quality guardrails. Now that we have a place for our guardrails, we are ready to start the execution of the transformation. The next step is this: getting everyone on the same page in terms of shared mental models at the same time in the following chapter.

Summary

In this chapter, we worked toward using the TiSH staircase and its building blocks. We started by looking at each perspective of the different models in the transformation. Next, we used this for defining our campaign and setting goals. Our campaign is providing the outlook for patients, which is participation in society.

The strategy to enable the operations and tactics in the care networks is set by defining a TEC platform – a platform that has to be developed and operated by IT personnel and used by people involved in care.

Guided by reasoning in the reasoning framework, we next defined the steps that we must take to achieve the goals of this campaign. In this chapter, we worked with various models and methods that help us in defining these steps, forming the teams to execute the steps, and understanding what skills are needed to provide care in a new, disruptive manner. It all started with applicable models for each building block: we have to know where we are coming from and where we are going, along with what our final destination is. That defines the transformation.

We learned that needs and requirements are crucial in defining each of the transformation phases. We are aware that specialists are needed to do this. We studied the methodologies they use to gather these requirements wherein the demands of the patient are the priority. Methodologies such as CAFCR and QFD with the HoQ and the VoC are coherent ways in which to grasp the requirements.

The essence of TiSH is to get care professionals to work together in teams, where they jointly decide with the patient what the best course of action is, given the circumstances and the desired outlook of that patient. Technology can be of great aid, but we need to train professionals in working with technology to get the best results in the different stages of care. In other words, care teams, supported by technology, jointly decide with the patient what the desired value is in the outcome of care processes. Therefore, technology, people’s roles, and organizations have to be designed and developed together in a community to realize the required value.

In the following chapters of this book, we will start the execution of this process using the models and methods that we put into perspective in this chapter.

Further reading

• Paper on transformation by Philips Design, 2019: https://www.researchgate.net/publication/333972702_Co-Emerging_Futures_A_model_for_reflecting_on_streams_of_future_change
• The action plan of the Japanese institute, Keidanren, for Society 5.0: https://www.keidanren.or.jp/en/policy/2018/021_overview.pdf