Exploring the disciplines for common understanding

We have set our challenge. Who do we need? Looking at Amazon, they utilize their platform to provide the care needed for their employees with the same rigor of customer obsession as with their logistics services.

A platform creates value by enabling interactions between two or more groups. In the case of healthcare, this is the providers, patients, and people who want to stay healthy. A platform has two major parts. One is the digital technology and the other is the community of involved people, care workers, and patients alike. Building a platform requires disciplines to build the technology and communities:

Figure 1.5 – The platform consists of technology and communities to serve at the point of care 

The two disciplines that can build this are systems engineering with a technology approach for the platform and systems innovation for the community-building approach. So, how do we involve our transformation teams in these disciplines?

Working with system engineers on health

System engineers focus on how to design, integrate, and manage complex systems over their life cycles. For a successful transformation, we have to understand how they think and work, especially in their role as architects.

Getting to a model that supports HeX means that healthcare must adopt agile, highly scalable concepts and embrace DevOps as part of the transformation. It’s a guided, agile way of developing solutions to execute this transformation. Applying this to healthcare transformation leads to something that we call DevOps4Care. This is where technology architects and consultants from medicine and healthcare enterprises closely work together to find the best solutions for the patient.

Ultimately, this book is about DevOps4Care: an agile way to create new, sustainable solutions in a speedy manner that will improve healthcare. It requires a complex transformation. In Chapter 3, Unfolding the Complexity of Transformation, we will discuss the complexity of this transformation in much more detail.

Understanding the difference between the architect and medical or business consultants requires a common reference such as we already introduced with metaphors and the book-related reference models of TiSH and HeX. In this section, we will further discuss these references and models.

Architects shape structures. They do not predict the future, although enterprise and business architects have visions of the future just as real estate architects do. What collectively binds us – or better yet, what we have in common – is that all architects and consultants come from a perspective where something is needed or desired. In business, that typically starts with business requirements, usually expressed by the consultant representing the many stakeholders. The business sees a demand, formulates requirements to address this demand, and sets these requirements as a starting point for creating architecture that, in the end, will result in a solution or a product. Healthcare isn’t different from that general principle, the only difference is that we now have a lot of medical-oriented stakeholders.

As an architect, the architecture in healthcare also is derived from the medical and business perspective. It’s the reason why all enterprise architecture models start with the business view. The Open Group Architecture Framework (TOGAF), the enterprise architecture method of The Open Group, is a good example and an industry standard for architecture. TOGAF starts reasoning from the business: what are the requirements of the business, which, in our case, is healthcare? But TOGAF is a technology perspective. We need to build an understanding of the healthcare enterprise and medicine itself.

Each person will have their own way of picturing and reasoning the transformation. We need to find a way in which to get a common understanding as it will take some effort. How do we understand each other in the following questions? Why do we need to transform healthcare, and why is it so urgent to do something about it? How do we define that something?

You will understand by reading, reasoning (even while reading this book), exploring your ideas together with the other stakeholders, integrating them within the constraints given by the qualities of the environment, and finally specifying it in such a way that others also can understand it to do their tasks in the transformation. We can make good use of Architectural Reasoning to achieve this common understanding.

Tip

To make this book a more effective read, we advise you to have a look at Architectural Reasoning by Gerrit Muller. A link is provided in the Further reading section.

The takeaway from Architectural Reasoning is that you mostly reason in your own mind, going back and forth on all aspects, viewpoints, and details. By telling stories and/or interacting with someone who is telling stories, together, you explore what possible solutions could be considered. In these stories, metaphors and generic models are used. They are used in the next step to formally integrate the insights within the constraints of budget, laws, and required qualities leading to the description (specification) of the actual solutions based on selected and jointly understood specific models.

A common understanding can be advanced by using reference models to which the different disciplines can relate equally. From the common understanding the various disciplines can agree on joint insights and understand the real needs behind the wishes and demands of patients. As we mentioned earlier for the transformation, we need perspectives on the following three pillars:

• Technology to be developed and led by the architect
• Enabling business operations and healthcare enterprises led by business consultants
• Care activities led by the respective medical disciplines

As a side note, together, the first characters of the above pillar form the acronym Technology-Enabled Care (TEC). Remember this acronym for later.

These three perspectives are different. Let’s find out more by giving each perspective some attention and learning about their differences.

Understanding the architecture of technology

As mentioned earlier, architects are familiar with TOGAF when they are designing digital systems. Requirements management sits in the middle of this. TOGAF recommends working with business scenarios as a technique to discover and document business requirements and, by doing that, drive the architecture. Now, how would that work in healthcare? The answer to that question is that it works exactly the same.

Tip

Another thing that might draw attention is the fact that architecture is not driven by technology. On the contrary, architecture is driven by business and that results in requirements for the technology that can be used as an enabler to achieve your business goals. In other words, it’s never about technology in the first place.

Read the last sentence a few times over, and reflect on it. It’s an important point of departure in reasoning about and exploring the transformation.

In this book, we will look at the most important driver for doing architecture in healthcare: the needs of the patient. Our business objective is sustainable healthcare where we can take care of more people, improve their lives, and increase the quality of care. Where is the input for these requirements coming from? In the previous sections, we studied some of the most important drivers: demographic changes resulting in the aging of people and scarcity of staff, the impact of diagnostics resulting in more treatable diseases, and change in lifestyle. It’s all causing increasing pressure on the need for sustainable healthcare.

The architect is responsible for the overall quality of the architecture. But creating architecture is not an isolated process. The architect has to work with different requirements, coming from various stakeholders that are mostly represented or advised by consultants. These stakeholders all have different needs, concerns, demands, wishes, and expectations. The architect will have to meet the stakeholders’ views on what they perceive as a good outcome of architecture. Let’s make that a bit more tangible.

The stakeholders in healthcare are the care providers, such as GPs, hospitals, clinicians, and care staff. Then, we have regulatory bodies such as governments setting regulations, rules, and laws for the delivery of care. Next, we have the institutions that pay for the care, typically insurance companies or public funds. Another stakeholder is the suppliers of services and goods, such as pharmaceutical companies and companies that deliver high-tech equipment to hospitals. And of course, the patient is likely the most important stakeholder. At the end of the day, it’s all about their well-being.

Working with reference architecture to enable business operations

How do architects put all of this together: the requirements, the stakeholders’ views, the objectives, and the architectural methods? How do architects address technology, healthcare enterprise, and healthcare itself in the architecture?

For development, we refer to Agile and DevOps as a reference. Let’s concentrate on the healthcare enterprise enabling the operations of care activities.

Here, the reference architectures for healthcare might be of help. An example of such a reference architecture on the TOGAF side is the Reference Architecture for Health (RA4H) by Oliver-Matthias Kipf, as shown in the following diagram of health enterprise activities:

Figure 1.6 – Reference Architecture for Health (RA4H), used with the consent of O.M. Kipf

The key in this architecture is the position of the patient, who is the health user. The focus is on the personal health journey and how stakeholders in the ecosystem can provide services that ensure a better, healthier, and safer life for the patient. As Kipf rightfully explains, the ultimate aim of the architecture is to help improve healthcare, but from the health user’s perspective.

The reference architecture shows how the ecosystem around the user is built, who the stakeholders are, and where the requirements originate from in terms of people, services, processes, products, and data. The architecture connects the domains of the stakeholders, collects the inputs along the patient’s journey, and enables a structured way to get to the desired output – better health – as shown in the next diagram:

Figure 1.7 – The personal health journey, used with the consent of O.M. Kipf

Architecture is about setting goals and planning the transformation to achieve these goals. It’s about building, delivering services, managing these services, and continuously improving these services, while also managing the risks that threaten to derail the transformation. That can’t be done in isolation – you need all of the partners within the ecosystems to work together with a common understanding.

With such a reference model, it is possible to relate technological architecture with the business needs of the healthcare enterprise. But what about the care community?

Working with communities on medical outcomes

Also, for medical goals, we need a reference model, preferably omniversal with medical and social care combined if we want to have a successful transformation. There are many medical models out there, but for our purpose and to demonstrate getting a common understanding of the TEC pillars, we will show you how to relate to the care episodes of the personal health journey in Figure 1.7. Note that several care episodes can be in parallel and executed by different care providers, which have to be aligned in their desired output. These care providers form a community around the patient.

An example of such a reference model is Integrated Care (INCA), as shown in the next diagram:

Figure 1.8 – Integrated Care (INCA) spider diagram, used with the consent of Dr. Javier Asin

The preceding example of an INCA spider diagram depicts five interdependent health conditions, each with its own care provider and care episodes. The medical and social professionals coordinate the interventions within these episodes for each condition to maximize the overall outcome for the patient, which is better health. In this case, an improvement over one year is shown in this spider diagram. The color red refers to this year, and the color blue refers to last year. A lower score means a lower care intensity in the episode. The care intensity is either self-care, social care, ambulatory medical care, or medical care in a GP practice or clinic. This spider is used to define the person’s health journey in a patient-centric way by deciding which health condition is impacting their participation in society the most.

This spider method was successfully introduced in Suriname by Dr. Javier Asin. We will elaborate on this in Chapter 9, Working with Complex (System of) Systems, where we will talk about integration and integrated care that requires the building of a care community consisting of social and medical care.

In the next chapters, we will explore how to relate these three TEC pillars and get a common understanding between stakeholders on all levels.

The wicked challenge – thinking patient-centric

Patient-centric thinking adds much to the complexity and has to be addressed by the architecture, or otherwise, it leads either to chaos or excessive costs. Therefore, in this book, we will work with many reference architectures and models, all with the same goal: transforming healthcare to improve it for the patient from the perspective of the patient’s own activities.

Finding and linking these reference models with each other for common understanding is what we will address in the coming chapters to build the health experience with HeX.

We will look at different methodologies such as observe–orient–decide–act (OODA), Moment of Truth (MoT), and Ecosystem Micro Communities (EMC) to form shared mental models that help us align viewpoints in transforming healthcare. Chapter 7, Creating New Platforms with OODA, will introduce a way of working in such an architecture, Chapter 8, Learning How Interaction Works in Technology-Enabled Care Teams, covers how to realize MoT in the health experience, and Chapter 9, Working with Complex (System of) Systems, discusses EMC.

We promised to be completely human-centric. The Reference Architecture for Healthcare (RA4H), which is derived from TOGAF principles, does just that: it focuses on the person, the patient, or the health user.

But we are also setting the scene for the digital transformation of healthcare, for all the reasons that we discussed in the previous sections. We need to transform to get to a more sustainable model for the delivery of healthcare. TiSH will help us in getting our heads around this wicked challenge.

In summary, healthcare transformation is about the following:

• Creating platform solutions that address comfort and convenience for the patient – 100% patient-centric for the outcome of a healthy lifestyle with a positive outlook on participation
• Creating platform solutions that are continuously improving the enabling business by adopting agile principles and community building
• Creating platform solutions that are cost-effective by adopting scalability as a driver to cover the world over
• Above all, creating a common understanding between technology, enabling, and care

So, where’s the technology in all of this? Health technology can, and will, certainly enable the creation of sustainable solutions. In Chapter 2, Exploring Relevant Technologies for Healthcare, we will explore the innovations of technology in healthcare, but always with that one question in mind: what’s in it for the patient?