9

Working with Complex (System of) Systems

After our first job, it’s time to consider our career. MoM TiSH is confident that we are ready to climb the corporate ladder.

We introduced the Journey Interaction Matrix (JIM) in Chapter 8, Learning How Interaction Works in Technology-Enabled Care Teams, to utilize OODA, which was introduced in Chapter 7, Creating New Platforms with OODA. Together, they provide a way to tell structured stories about the relationships between the activities in health journeys, executed by providers and the enablers. In this chapter, we will learn how to create a common understanding to integrate and transform into the top tread of TiSH, personal directed healthcare with the best-fitting solutions and systems, tread by tread.

The TiSH staircase and DevOps4Care enable users to tell compelling and understandable stories along the presented models. This allows developers to understand the needs to design each tread and build the enabling systems. We will address the integration and interoperability of these systems in the enabling platform, the two critical issues to solve in any complex ecosystem. That requires understanding the technology, as well as the interaction of multi-disciplinary teams that work together from a care perspective. It’s all part of TiSH and DevOps4Care.

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

• Building the Technology-Enabled Care (TEC) teams
• Introducing integration in networked care teams of teams
• Cross-walking integration and interoperability relations
• Applying SSP, governance, and operations
• Integrating TEC teams with patient-centric networks

Building the Technology-Enabled Care (TEC) teams

With the JIM at our disposal, we can define the interactions between teams in terms of OODA activities. In the following figure, we added the JIM to the third tread of TiSH. This enables a care organization to define the care processes in OODA activities and have the required capacity within each team to provide the requested care to patients. Given this capacity, the teams have to be integrated into the activities of other teams when involved in networked care.

Figure 9.1 – Interactions between TEC teams and their (OODA) activities

We are not going to describe the professional medical or social procedures, but rather a strategy for the generic functionality and characteristics of how to integrate the different care teams in the following types of care networks we defined previously:

• In ad hoc networks, case management needs to know what the other care providers are doing. The actions of other care providers are observed to see what they do as part of their own OODA loop. They communicate to each other about what they do or have done.
• In stepped care, several teams make joint decisions on the health OODA loop, requiring coordination and collaboration between the care teams.
• In integrated care, social and medical care teams are integrated. The teams manage the lifestyle OODA loop, enhanced with diagnostics and orient on what the best actions for the lifestyle of a particular patient are.
• In directed care, all care teams’ treatments or other interventions are commanded from the jointly observed participation OODA loop.

To visualize the nested OODA loops for integrating the different teams, the following diagram shows the hierarchy of the OODA loops, each related to the type of networked care:

Figure 9.2 – OODA loop hierarchy

In the final chapter of this book, we will do an exercise on nested OODA loops as the main design for networked care.

Now that we have decomposed the TEC team into the components of roles and OODA activities using the JIM, it’s time to compose the TEC teams and the networked care. First, remember what we discussed in Chapter 6, Applying the Panarchy Principle, regarding Tuckman’s views on how the team is built with forming, storming, norming, performing, and adjourning steps, and must be able to express their care processes in terms of OODA activities. These activities must be mirrored in the technology.

Next, this team must be digitally skilled. These teams need to become digital centaurs in the care networks, which will take time. TEC teams operate in networks, using platform services that they can dynamically scale around the patients using technology.

The next section will address this.

Introducing integration in networked care teams of teams

It’s time to talk about micro-enterprises and 3EO, the Entrepreneurial Ecosystem Enabling Organization. We already briefly mentioned Rendanheyi as an agile way to unbundle and rebundle organizations to suit the patient’s needs, realized in the Moments of Truth on the health journey’s touchpoints. The question is how?

For each network tread, we will provide an example. The first is case management, which is shown in the following diagram:

Figure 9.3 – Teams in case management

Figure 9.3 shows a playing field with Technology in the inner circle, Enabling entities in the middle circle, and Care providers in the outer circle. Other teams or organizations can be outside these circles.

The patient has its healthquarters – analogous to headquarters – at home. Together with the partner, they are their own case manager (self-management) to arrange the care they need. In this example, we have a patient who is recovering after an intervention replacing a hip. The intervention is done in the orthopedic clinic, but the rehabilitation is done at home.

The patient and their partner have a subscription paid by the insurance company to arrange the care they need. The subscription is issued by an enabling organization, a rehabilitation center. The subscription covers a nursing team and physiotherapists, working together with the General Practitioner (GP).

The binding party here is the healthcare insurance company. They provide the governance for the Integration Platform (IP). Through their purchasing power, they can specify what capabilities and functionalities of communication are required for proper case management. Obviously, all parties must be compliant with the guardrails that have been laid out in governmental regulations.

To make sure that the communication requirements are met, an independent Certifying Agency (CA) certifies all players within their circles of influence.

The rehabilitation center has also made arrangements with the municipality, which has a specific team organizing activities such as cycling, walking, and playing games. Both the rehabilitation center and the municipality have decided to work together on training their personnel but have their own department for Human Resources Management (HRM).

By just looking at the department and team level of organizations, we have already digitally unbundled the organizations. This will help with the organizational unbundling when this is required.

If we go one step further to stepped care, the playing field changes. It’s shown in the following diagram:

Figure 9.4 – Teams in stepped care

Like the Danish Naerkliniken that we already introduced in the first chapters of this book, a formal collaboration is established between the municipality, the clinic, practices in the neighborhood, and the rehabilitation center. The GP is involved and the pharmacy acts as an external supplier.

In the collaboration, it was decided that enabling staff has to be trained jointly. The clinic and rehab center provide the human resources related to the collaboration and the municipality provides all materials for use at home. The assistance for housekeeping from the municipality is also part of the collaboration.

In the collaboration, they use the guiding hand of the insurance company for governance. The use of CAs to certify all entities using the Shared Services Platform (SSP) is retained.

Next, we evolve to integrated care, represented in the following diagram:

Figure 9.5 – Teams in integrated care

If we want to go into integrated care, then more disciplines must be involved to cooperate. This time, a cooperation is founded that will be responsible for all platforms to support the entities. One example of cooperation is that all equipment or things required for use at home can be ordered by any team from the online platform.

The same applies to human resources with a platform to assign tasks to individuals across the teams. The Roamler Care platform that we discussed in Chapter 8, Learning How Interaction Works in Technology-Enabled Care Teams, provides this. The HRM department is absorbed in the teams, like with the Buurtzorg concept.

Last but not least (in fact, delivering the most value for the patient) is directed care, which is shown in the following diagram:

Figure 9.6 – Teams in directed care

In directed care, the healthquarters of anyone can direct the care resources via the SSP. This can be highly autonomous as health trackers predict when some form of care is required.

The IP is now governed by a value board responsible for the population management of the region. All teams are in fact free to independently develop to serve the population as best as possible. The Amazon Care approach has a lot of these characteristics, the population being the workforce of Amazon itself.

Integrating TEC teams with patient-centric networks

Integrating the TEC teams means interaction between the OODA activities, at least the internal activities and especially the OODA activities in networked care. We need nurses, therapists, practitioners, and doctors in the teams to be interoperable. We also need to enable supporting staff to manage the services to create the Health eXperience (HeX) journeys.

Although this integration is on the medical side, it must also be realized on the enabling technical side. To be able to build understanding on both sides, we present an overview of the entities on both sides in the following figure:

Figure 9.7 – Entity relation diagram for journeys, providers, and the enablers

To be able to translate the integration and interoperability into enabling services of the platform, we need to recognize the care provisioning entities in the upper part and the enabling entities in the lower part. The awareness of these entities helps with understanding the stories we tell each other. The transformation task force will have to organize common understanding sessions to build a shared mental model for the DevOps4Care process. We use the Entity Relations Diagram (ERD) for this purpose. The entities are divided into 4Care entities and Ops entities. Together, they will be developed.

On the care provisioning (4Care) business side, we identify the following:

• The HeX on treatment, health, lifestyle, and participation.
• Information represented by the International Classification of Functioning, Disability, and Health (ICF) model and the medical information elements it contains, including other types of information, such as for scheduling, payment, quality, and logistics. For example, medical data entities, datasets, and their granularity are defined in Clinical Information Models (CIMs).
• Activities from the OODA loops consisting of protocols and guidelines translated into workflows of tasks using defined processes based on, for example, the insights of the Interoperable Health Enterprise (IHE).
• Micro-enterprises consisting of TEC teams and the enabling teams, such as for HRM and IT.
• Journey interactions of people as patients or people who want to improve their health, lifestyle, and participation in the touchpoints as part of the care activities.

The enabling entities are as follows:

• Point-of-care environments: Care is indeed traditionally provided in hospitals or on the premises of the caregivers. House calls can be made by GPs and ambulant nurses, but only for a limited set of care activities. But care is increasingly provided anywhere on the globe as things such as wearables and implants become much more common. The environments of the Point-of-care are therefore becoming ever more challenging.
• Internet of Things technology: The Internet of Things, which we talked about in Chapter 2, Exploring Relevant Technologies for Healthcare, is not merely things connected to the internet. It often combines all sorts of technology, such as in a technology warehouse, into very sophisticated and capable devices. It ranges from a common smartwatch to an artificial pancreas, as well as home dialysis or breathing equipment, CT or MRI scanners in hospitals, and DNA sequencers in the lab. It is here where breakthrough innovations are taking place. For instance, smart pills already exist that send back information about where they are in the body, or defibrillator delivery drones give a rapid response. This will shift healthcare increasingly outside the traditional buildings.
• User classes: User classes refer to which types of users are involved in the journey. They have to be classified into distinctive classes, people who are the receivers of care, next of kin, volunteers, community workers, care professionals of all sorts, and supporting staff. Not only people but also increasingly devices and their algorithms are classes on their own. These devices work increasingly autonomously. A simple example is a chatbot.

These classes are managed as users of resources to enable the care teams. For this, users must identify themselves with the right attributes to be authenticated. Once authenticated, authorization to access the resources can be granted.

• Microservices: Microservices are the backbone of digitization and interoperability. The modular setup consists of the systems of engagement with the User Interface (UI) and the systems of record as a Distributed Data System (DDS), distributed in several domains – hospital, personal, private, and public, to name the most common. The systems of engagement, systems of intelligence, and systems of record are connected with Application Programming Interfaces (APIs). This separates data from the application to provide better security and flexibility to reuse data and create data flows along the journey and use the data in research.
• Operations framework: An operations framework is used to define the complete processes, roles, procedures, tools, and activities to govern, design, deploy, train, manage, and continuously improve all IT services. It’s a guide to a network’s governance and assurance of operations on concepts, principles, UI/UX, API, AI algorithms, data, security, and connectivity. The framework sets out the way the network enables care by forming the back office for the microservices, user classes, and connected Internet of Things placed in the Point of Care Environments. For the best healthcare provisioning, an excellent operational framework is needed to ensure collaboration with best-of-class IT services to motivate and enable all involved people. It’s the Ops in DevOps.

The ERD shown in Figure 9.7 shows the relations of the platform between the entities.

This ERD (from TAFIM, the precursor to TOGAF) is used as the foundation for architecture preferably set up from the start to be able to evolve the patient-centric network into the desired SSP.

We use the OODA loops to organize the teams around the patient; how do we mirror that in the IT resources of the platform? What technological topics are important to be aware of as the transformation task force? Let’s dive into it.

IT resources

The IT resources need to be one step ahead of the most advanced organization in the network. But here, we have to say that this is rarely the case. Here, the need for a common vision of the future based on a common understanding becomes apparent. We will address this in the next chapter. The consequence is that the topology of the IT infrastructure must be futureproof in terms of the transformation treads ahead. A multi-cloud strategy is therefore a must as the SSP will evolve from micro-enterprises originating from different, more traditional organizations, each having its own choice of cloud. These can be public clouds such as Azure and AWS, but also private stacks hosted in privately owned data centers or hosting providers. The first step to take is to prepare the modular microservices for interoperability between the environments in these clouds, but also all subsequent integration levels have to be prepared for.

Integration levels are defined on the business side by the OODA loops and the accompanying level of Systems of Systems for the technology on the other side. It’s this combination that has to be addressed in the common understanding.

One field of knowledge for this is decision support systems.

Tip

Read the publication on decision support, Decision Support Systems and Management Information System, by Pawan Thakur and Ram Kumar.

Trust

Another topic for common understanding is trust. Every organization should build trust in the users by having excellent privacy, security, and UX. All actors in the HeXagon have to communicate with each other in a secure way.

That starts with each organization having its own trust domain. So, how do we unbundle this? By having each entity operating from its own domain with zero trust between the domains. For each person or device, it is possible to get access to the required microservices via the API, including the preferred Operating Systems (OSs) and UI.

With the creation of trusted domains, we’re moving from one domain to confined personal domains. The step toward unbundling becomes easy. The organization becomes just another attribute of an identity. With this, we are already getting close to the next version of the internet, called Web3, using blockchain technology to decentralize the web. It could be used to grant every identity its own personal domain, shielded as a block and providing a greater level of security and privacy. But the benefits are there: patients owning their own domain and granting access to actors in the care network on demand.

We are creating a patient’s health data space domain. In the HeXagon, a practitioner logs into that patient’s domain, where they have permission to look for other data to be used in the therapy or other type of intervention. This is the opposite of a patient logging into all different care providers. Prepare to flip the domain inside out. The consequence of this is that every active entity has to be aware of what they are doing – it's they since we’re talking about both humans and devices – and what data is being stored.

If actors can be anywhere, so can data. We won’t have monolithic data stores anymore, but distributed data. The next challenge is how to find the right data when it’s distributed. You can use an index to find where your data is or search all databases on related data. The index method is quicker and can be recorded with each event between actors. Searching will also include derived or processed data. So, both ways are probably needed for access to complete data.

For example, algorithm micro-AI services will need the required data and will search for it. Technologies such as DDS used in other sectors such as aerospace become relevant for healthcare too.

The way it works is that an actor logs into the required domains, getting access to conditions such as authorization and circumstances such as legal relationship. An actor can publish information and/or subscribe to information required for the task at hand.

From the start, it is best to give this ultimate perspective attention and create the design space for the end goal. Also, unbundle staff organizations in the IT domain to prepare for the coming rebundling around the patient’s needs.

This includes the IT department preparing to support the emerging SSP. The IT department can take the lead on the transformation by first collaborating and then forming a cooperation to ultimately support the individual patient by setting up the support on rigorous Identity and Access Management (IAM) and digital services.

Identity management

The next main topic is how to get access to the data. Every person or thing that needs data for their activity needs to find and get cleared for access in line with their roles in the activity. The main dilemma is, on the one hand, protecting data, and on the other hand, providing access to those who need it. In our practice, we see care providers struggling to give access to personnel outside their own organization. What we need is identity management across all care providers, across the silos.

Before we dive into the specific roles of professionals and patients, we must define what roles are. In IT, roles are associated with identities. But to make it a bit more complex: identities are not just people. Anything can be an identity. In the previous chapter, we discussed how to disentangle or unbundle healthcare services into microservices, allowing the patient to acquire the right service at the desired time. This way, we can dynamically scale resources to provide care.

A microservice is a resource, but it doesn’t run on itself. It needs infrastructure and software. It may need a device and it will certainly need network connectivity. Lastly, it needs a user to drive the service and a receiver that benefits from the service. All of these are identities, and they fulfill a role.

This concept might be a bit hard to understand if you aren’t an IT expert, so we’ll try to make it more specific.

Both the care provider, for instance, a nurse, and the patient are identities. To use care services, they will need access to these services. They might need access to an app on a tablet or a mobile phone. But we only need to grant access to data that is relevant to this specific nurse and patient. Hence, we need to specify who they are, what their role is, and what this role requires. We might even want to be specific about when they need data or where and on what kind of device they are allowed to view data.

A lot of smartphones already have an app that shows relevant health data. That app might collect data from a smartwatch, but it can also hold the data that is entered by a GP or a pharmacy. The patient has access to that app and that data, but also the GP. However, the GP might not be allowed to view data that originated from the smartwatch.

This is where IAM comes in. In our example, we have several identities: patient, provider, GP, pharmacist, and the smartwatch or the tablet and the app itself that needs access to data. Who and what is allowed to view data, based on what role? When and where is access allowed, based on what conditions? This is only about the access, but we need an extra step: we must authenticate the identities – make sure that the identity is whoever or whatever they or it claim(s) to be.

This must be very fine-grained since we are organizing the healthcare to be dynamically scalable into micro-enterprises, changing networks and ecosystems, and microservices. All of this requires management with those end-to-end managed services. We don’t want the nurse or the patient to be bothered by things such as IAM and authentication; it simply must be arranged. We need services that take care of the entire process: from login up to the presentation of the requested data. We need services that manage the functioning of the app, the security of the databases, and the establishment of network connectivity.

One important aspect of granting access to identities with specific roles is trust. If we grant access to identities, we have to first authenticate the role they have, verify that the identity is whoever they claim to be, and trust that they have the appropriate access. Identities should only have access to data that they are eligible to see and use. This is important for a lot of reasons: compliance with laws and regulations to start with. In IT, we use the zero-trust model and use micro-segmentation to enforce proper access, authorization, and authentication.

The most important principle in zero trust is never trust, always verify. In IT, this is typically translated into an architecture that authorizes and authenticates an identity by default. A zero-trust architecture has a single source of user identities. Users and devices are authenticated against that source, including the context, such as compliance with policies and the state of devices. Policies include rules to access an application and data within that application.

An extra line of defense is micro-segmentation, allowing architects to logically divide segments where applications and data reside. This prevents identities – users and devices – from simply hopping from one segment in a network to another without strong authorization and authentication. The identities and roles provided grant the proper access, after verification. These should be common rules in defining roles and access policies in healthcare.

Enabling integration in operations framework

Nothing will happen in the health journey if there are no operations in the background enabling healthcare with technology. We already introduced our TEC teams. This is a term that is also used by CENELEC, the European standardization body, in the framework for service design and management and the development of management standards and shared values within and between the organizations engaged in the social alarm service chain.

CENELEC uses TECOM derived from eTOM from TM Forum. The entity in Figure 9.7 is a representation of their Open Digital Architecture (ODA), which can be explored in detail online at http://www.casewise.tmforum.org/evolve/statics/tmfmodel/index.html.

It’s a comprehensive operations framework including governance of, for instance, APIs used in the microservices. Again, for a common understanding, it suffices that the key principles are understood. So, what should this service look like? It’s these enabling operations that provide the support services so that care workers can concentrate on the health journey and not have to worry about the technology that is used. Technology is water from a tap; it needs to be there, and it needs to work. However, to make that happen, the operations on all supporting entities and the logistics must be executed in an orchestrated way, allowing care workers to execute sense and response in events during the health journey. In fact, we can apply OODA here too: observe whether services are working for the users, orient on the detected service disturbances and user stories, decide on what measures to take, and act upon them. The users will recognize this approach. As operations become more complex with each tread, we also foresee a development in the operations framework, such as starting with TECOM, evolving to eTOM, using Ops4Care where user stories are readily understood by Ops, and using DevOps4Care when automated DevOps is added where users can no-code their services.

This concludes the dive into the technology. It’s clear that it requires the skills of systems engineering and community building alike. In the next chapter, we will address this further by cross-walking the resulting integration and interoperability.

Cross-walking integration and interoperability relations

In Chapter 3, Unfolding the Complexity of Transformation, we first mentioned the terms interoperability and integration. Remember Figure 3.5 – Structuring governance in healthcare systems. Interoperability matters a lot to us. It’s even the foundation for the transformation. Think of it as the HeX being created around touchpoints and interaction in each journey, this implicitly means that interoperability enables these interactions. The interoperability we are talking about is that between the OODA activities. These activities are overarching organizations and teams.

Using the ERD of Figure 9.7, we can describe the enabling entities step by step from components via systems to System of Systems and explore two essential topics: the interoperability and data domains and enabling integration along the ERD relations.

Understanding interoperability in data domains

Infrastructure must be interoperable from day one. This is the foundation. Systems need to be able to communicate with each other. Technologically, it means that systems must share protocols and interactive connections. But just interoperability of infrastructure doesn’t mean by default that systems can communicate. They need to understand each other and understand each other’s language. In terms of data, it means that we first have to connect to share data and next, make sure that systems can understand and work with this data when the data is transferred between systems.

In broad terms, we have three different levels of interoperability: the syntax in technology, including the structuring of data, the semantic interoperability, where the data has the same meaning in the different medical protocols, and the pragmatic level of everyday usage of data in practical decision-making.

This is a very simplified explanation of concepts such as Distributed Data System by Object Management Group (OMG DDS). This international standard addresses the real-time publish-subscribe communication for embedded systems by declaring a virtual global data space. In this space, applications can share information through data objects that are defined by an application-defined name called a topic and a key. In other words: DDS allows for real data integration. On top of this global space, DDS supports local object models.

In our case, the DDS domain is the health data space. These data spaces need governance, not only by standards such as OMG DDS but also regulations. One of these regulations is the European Health Data Space (EHDS).

Jeroen Tas, former chief of innovation and strategy at Philips and now a member of the board of directors of European cloud initiative Gaia-X, says about the EHDS: “We have enormous possibilities with data in the healthcare sector. We can eliminate overdue care, increase capacity, analyze patients, and gain more insight into diseases. But that process is difficult because parties are sometimes sitting on their own data. The market is fragmented. Files, processes, and market parties must be brought together in a secure manner, whereby privacy and identity access are guaranteed.”

Each data space has its regulations defining who is allowed to do what with data. It sounds simple but the legal complexity of it tends to create data silos and not data spaces due to privacy and security concerns. This inhibits innovation.

Each data space or subdomain has its own access rules about which authenticated identities have the authority to do something. The integration happens at the user or user class level. Each person should have a personal environment like they have on their smartphone. Each person has a personal set of apps and devices as systems of engagement. To enable this, we need a clear definition of the API and UI.

For our personal space, we can look at a concept that was put forward by internet pioneer Tim Berners-Lee, called SOLID, which stands for social linked data. In essence, SOLID is a development approach that fits the concept of Web 3.0, where users own and/or direct their personal assets such as data. The promise of SOLID is to decouple applications from the data, and it is built completely according to the microservices principles. With this concept, users have complete freedom in where their data is stored and who is allowed to access that data. It’s truly a personal data space.

SOLID makes information accessible through microservices. We can apply these principles for health data, using information standards as in the IHE and CIM, specifically ISO 13972:2022, an international standard meaning there are no restrictions when traveling abroad on the availability of data both in syntax and semantics. For the understanding we seek, it’s enough to know that the information in the ICF model can be defined with these standards. Although that’s difficult, focus should stay on the value and not the standard itself.

Integration along relations

With the understanding of the entities, we can now address the relations themselves to understand integration. First, we define four relations between the providing entities:

• HeX “provided by” micro-enterprises who treat diseases and/or other interventions to improve the health condition, lifestyle, and ability to participate
• Micro-enterprises “using” workflows consistent with the procedures
• Procedures “requiring” information on the medical condition, circumstances, and care provisioning
• Information that “supports” the HeX with the patient record and overarching care plans

Together, they form the health enterprise. Then, we have four relations between the providing and enabling entities:

• Information is “accessed through” microservices, for instance, the apps
• Procedures “build from” microservices, which form the specifications for the systems of record
• User classes “perform roles” in micro-enterprises, which can be care teams or support teams
• Micro-enterprises “performing in” Point-of-care Environments, either remote or on-site

These four relations are critical as a common understanding is required to lead to the contracts and specifications to develop, build, deliver, and maintain the enabling technology. Within, we have six relationships between entities of the enabling system of systems:

• Point-of-care Environments “provide facilities for” user classes. Think of providing workplaces with a smartphone, tablet, PC, or other devices for professionals and smart clinical beds for patients. These can be Internet of Things devices.
• User classes “that access” microservices via the systems of engagement. We learned that this access plays an important role in securing trust in digital healthcare.
• Microservices “realized with” the operations framework.
• Operations framework “connected to” the Internet of Things.
• Internet of Things “used by” user classes and supported accordingly. This usage normally requires a display and buttons or other I/O devices, the physical part of systems of engagement.
• Internet of Things “placed in” Point-of-care Environments. This includes the logistics to deliver and install these facilities.

The last two are the value relations. Those are the touchpoints on the journeys and OODA loop excursions where the Moments of Truth take place:

• Procedures “resulting in” journeys of episodes of care with touchpoints
• Journeys “executed by” user classes of people and devices with authorization for the specific roles under certain circumstances in the activities in the touchpoints

These two relations of executing itself and the results from execution, bring everything together and form the touchstone of healthcare performance.

This completes all entities and relations in a structure that we will use later on. By following the relation arrows along the entities, for each actual real-life touchpoint, the following questions can be asked: who does what and why? Where and when? What rules should be followed? How can these questions can be explored with all stakeholders? The users can tell their stories along these structured relations and entities. The operators and developers understand these structured stories to plan the initial functionality and subsequent improved iterations based on the new stories from experience.

Now that we have discussed how to tell stories to each other, we should have a closer look at the governance of the community. That’s what the next section is about.

Applying SSP, governance, and operations

We have to set up governance, which has to follow the development of networked care from case management to directed care. Here, we will see what has to be set up for each type of networked care:

• Case management starts, for example, with insurance companies having a role in kickstarting virtual or ad hoc networks and making sure communication is clear between the care providers and that coordination for case management is defined. Case management can be enabled to be self-management or management by the next of kin, a case manager from the municipality, or one of the healthcare providers. The governance is embedded in service levels specified in the contract and certifications from an independent body. For IT operations, we refer to the TECOM model for the availability of digital equipment. We can call this Ops “light.” The direct per-user cost of the platform is included in the reimbursement tariffs.
• For stepped care, we need a formal collaboration working toward a certain health condition – in our example, to create a seamless journey toward mobility. Stepped care reduces the claims needed. Here, the usability of the platform in the stepped care processes becomes the target. For operations, the comprehensive eTOM, from which TECOM is derived, is suitable to govern the complexity. Maturity assessments and Total Cost of Ownership (TCO) are the Key Performance Indicators (KPIs) for the platform.
• Cooperating in integrated care has the benefit of reaching for shared savings on healthcare costs and dividing the savings among the participants. Therefore, eTOM has to be adapted to include specific care, resulting in Ops4Care. The platform must provide a utility with a Return on Investment (ROI) on the shared savings via a balanced scorecard in the integrated care operations.
• Finally, directed care becomes possible if the whole population can be managed to maximize the economic value with the value board. Health becomes a manageable investment in the population. The entire DevOps4Care process ensures innovation and person-centered delivery. The Adjusted Clinical Group (ACG©) from John Hopkins or other algorithms are used to predict and anticipate which resources are needed for a healthy population.

Note

For more details on the ACG by John Hopkins, we cordially refer you to https://www.hopkinsacg.org.

The following table provides an overview of the governance of the TEC platform:

Table 9.1 – Overview TEC platform governance

Governance is about community building and it is here where the panarchy principles apply. The speed of community building will set the order and pace, not the technology. Given the complexity, it will take time to build a common understanding and navigate the panarchy dynamics. It takes time to learn to tell clear stories to each other.

Note

A way to start governance and community building for a platform is using the Contract for the Web from, yet again, Tim Berners-Lee. A good exercise would be to adapt this yourself for healthcare. More information can be found at https://contractfortheweb.org.

Summary

In this chapter, we have learned that a common understanding of interoperability and integration can be achieved by using reference models to identify the relations to be used in stories to the operators and developers. We have addressed integration and interoperability as the two critical issues that we must solve in a complex ecosystem. That requires understanding the technology, as well as the interaction of multi-disciplinary teams that work together from a care perspective. It’s all part of TiSH and DevOps4Care, as we have shown in this chapter.

We also learned how to unbundle and rebundle organizations in TEC and supporting teams using OODA loops to establish networked care with ever more value, ultimately for the patient but clearly addressing the roles that all stakeholders have in networked and integrated care. We learned how to implement these care models in feasible and defined steps.

Lastly, we demonstrated how to arrange and grow the governance model to ensure operability. We explored several technology domains, such as AI, Internet of Things, and data, and for additional learning on these topics, we kindly refer to the titles in the Further reading section. In the next section, we will learn how to perform assessments using TiSH, as a starting point to grow maturity in healthcare transformation.

Further reading

In this chapter, we mentioned a number of frameworks and initiatives. This section gives links to more information:

• Data Distribution Service by the Object Management Group: https://www.dds-foundation.org
• Gaia-X: https://gaia-x.eu/what-is-gaia-x/about-gaia-x/
• European Health Data Space: https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space_en
• SOLID: https://solidproject.org/about
• IHE: https://www.ihe.net