11

Planning, Designing, and Architecting the Transformation

Achievements are building. Results are beyond what MoM TiSH has taught us. Time to start your independent path.

We know where we’re coming from, and we know where we’re going. But how do we get there? We have learned how to do assessments, and we have defined our goal: sustainable healthcare. Based on these assessments, we have learned how to set up a balanced program with projects on ideation, prototypes, pilots, and deployment with different teams. Now, it’s time to start planning the transformation itself.

We will learn how to conceptualize the plans, how to form the teams to execute these plans, and what actions are part of it. Now, how do we empower these teams to execute the transformation?

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

• Defining the transformation plan
• Designing with Technology Enabled Care (TEC) teams
• Empowering transformation teams

Defining the transformation plan

We ended the previous chapter with an example: a care provider deciding to set up a transformation plan. Simply launching another project does not solve the problems experienced. The urgency calls for a transformation.

The dilemmas they encountered are twofold: the contradiction of collaborating with other care providers, resulting in less revenue, and creating the collaboration in the first place while not having enough development resources to create the digital outreach process for patients in their community. Still, the bottom line is that fulfilling the health needs of the population will be valued. The question is how does this translate into real revenue for the organization? And how does digitalization fit into this equation?

To set up the transformation plan, we can use the transposed maturity board of Table 10.1, resulting in the following table, which gives a constructive foundation to measure progress:

Table 11.1 – The program progress board

We use the four types of projects, ideation, prototyping, piloting, and deployment, to fill any gaps. Each cell can be divided into the different types of care provided if needed to address the different maturities. For the most part, an organization is not equally mature in all departments. For our example care provider, we assume it is.

They use their experience to realize the technical solution for the real-time monitoring of outpatients. The pilot for the coherent application landscape managed as a System of Systems (SoS) gave valuable insights into the increased complexity, and the care teams gained experience in the experiment where the inhibition points included frustrating technology and anxiety on how remote monitoring worked – remember the work of Knoster that we discussed earlier in this book.

Talks with the insurance company have made it clear that, in 2 years, the use of remote monitoring will become mandatory. In this case, the program would be as follows:

1. Project A: Deployment of a cloud strategy on the application landscape to build the SoS and free up IT personnel
2. Project B: Pilot the setting up of the remote monitoring service with the freed-up IT personnel and enable the care personnel to observe patients at home
3. Project C: Contracting remote monitoring and deploying remote monitoring
4. Project D: Ideation project on the next tread of stepped care

Project A has to be finished before project B can start as the IT personnel has to be freed up first. Both have to be finished in 2 years to be on time for the new contracting of health insurance.

In parallel, the ideation for stepped care can be set up together with other care providers and probably followed by an experimental prototype. That is, provided it does not put a strain on the resources for projects A, B, and C.

By using the maturity models, we have a stronger foundation and better control of the risks. Therefore, we will have more successful projects. So, what should the approach to these projects be? We’ll discuss this in the next section.

Micro-communities in the health experience ecosystem

In fact, we start at the bottom and build from there. We start with one or a few patient(s) and improve on one or a few simple tasks and learn from there. Although the program is set up top-down from the campaign for a healthy participating population and the derived mission, vision, targets, and strategy, the realization is the other way around. To avoid the pitfall of internalizing the transformation, we have to look to externalize it from the beginning. As a starting point, we need something to address the changing needs of individual people’s health. This approach means that a project can never be started without involving the patient or client and their community.

For that we can find further inspiration in the Rendanheyi concept of Ecosystem Micro-Communities (EMCs), as shown in the following diagram:

Figure 11.1 – EMCs for organizing health

In the first chapter, we introduced the HeX to incorporate all types of caregivers in the care ecosystem of a person. It’s an EMC to create individual health experiences provided by the TEC teams, as discussed in Chapter 8, Learning How Interaction Works in Technology-Enabled Care Teams.

At the center, we have the individual or family with their own personal micro-enterprise to arrange their health experience, the HeXagon. In this personal micro-enterprise, we find the next of kin and friends. It’s the inner yellow hexagon. This micro-enterprise is supplied by other micro-enterprises for social and medical care. A micro-enterprise equals our TEC teams. Together, they form the Social and Medical EMCs.

The enablers are in the Solution EMC to provide solutions for the care EMC. These are mostly the services from IT, Human Resources (HR), and finance organized in shared services for the EMCs. They are, at the very least, a learning community, and TEC platform (SSP) community, which are governed by the IP Value Board.

This looks like a traditional supply chain, but Rendanheyi is about each employee directly facing the people they attend to, contributing to their health experience, and realizing their own value, too. It’s a win-win. Employees are focused on the health experience, using guidelines and guardrails to stay on track to the destination. It’s not the other way around, following rigid guidelines and guardrails on fixed journeys.

The way this works is that the patient forms the demand side, which must be understood with a very short supply line. The Solution EMC is in direct contact with the care and patients. Translated to DevOps4Care, Ops supports the users of the technology directly.

The challenge is to facilitate the value stages for all involved while creating the health experience. In our example, this is the care provider who wants to solve the dilemma of less revenue in the collaboration and still have the budget for funding technology for the teams and paying salaries. Additionally, the EMC concept is used to remove barriers between micro-enterprises by focusing on the end users of all the combined services.

Because the (potential) patient is the owner of its HeX micro-enterprise, the TEC team of the Social and Medical EMCs is focused on improving health, supported by the enabling teams in the Solution EMC. This evolves along the structures of the micro-enterprises described in Chapter 9, Working with Complex (System of) Systems, introducing even more integration into networked care:

Figure 11.2 – Starting the evolution of networked care from the initial to the first stage

In the preceding figure, our example care provider is still outside the care EMC during the initial stage. The question is how to fit it into the EMC in the first stage.

The governance mentioned in Table 9.1 guides the access to the EMCs to serve the individual HeX micro-enterprises via the Value Board. Any organization can offer an evidence-based proposition to the Value Board and show how they can contribute to the health experience. Depending on the networked care tread of case management, stepped care, integrated care, or directed care, this is the insurance company, collaboration steering group, cooperation committee, or community representation:

Figure 11.3 – The evolution of networked care in the second and third stages

Once in the EMC, our care provider joins, in the second stage, forces with other care providers making use of the Solution EMC’s enabling of cloud services and remote monitoring. Projects A and B are now executed much quicker, and the care provider can focus on the health experience itself. This increases the chance of the successful execution of project C.

The third stage is to align with the social caregivers. This stage is investigated in project D.

The emergence of health experience EMCs from a patient’s view

A person starts their personal HeX micro-enterprise by building it from daily life. Sports or other physical activities might be used for prevention but also friends and family who can help when assistance is required. This is informal. Usually, a GP, dentist, physiotherapist, and pharmacist will join the care EMC. Alongside this setup, supporting technology is used: email, chat, social media, and portals for making appointments or ordering repeat prescriptions and looking up medical history with the convenience of smartphones or tablets. The use of an activity tracker or smartwatch is becoming more common. Gadgets such as Wi-Fi-connected toothbrushes and a plethora of health apps are also available.

The personal HeX grows into an ad hoc care EMC, but at a certain point, this develops into networked care starting with case management. Any care provider’s question should be how to connect to the care EMC and become part of it.

So, for our example care provider in project B, it’s clear that its remote monitoring service has to fit into the health experience, and this orchestration needs to fit into some collaborative TEC platform with other care providers. This seems to be a daunting task. Complexity is not on the list of invitees, but it’s there. Here, the Minimum Viable (or Valuable) Product (MVP) approach comes to the rescue. Challenge a team to find the lead users from the community, understand their needs, and start improving by defining a first MVP.

Tip

For an extensive example of how to build a community in general, we recommend the resources on the Community Canvas website at https://community-canvas.org/#get-started.

Leveraging the power of small

The goal of this example is to monitor the patient remotely. Based on what has been observed with remote monitoring, a decision is made on how to act. This departs from a scheduled check-up in the clinic and can directly lead to a referral to a mobile nurse or physiotherapist outside the organization, but within the care EMC, for a follow-up. It is expected this will increase the health experience at a lower cost.

The wrong way is to select a product, implement it, and start working with it. This will take the better part of a year, and when deploying many things, it easily gets out of hand, inevitably leading to a bad reputation for the transformation as a whole.

Another way is to select a patient who might already have some ideas about why the remote monitoring could be beneficial: the lead users. With these lead users, experience is built. First, do a paper check of the idea with a few patients, then a prototype with some more, then a pilot, and finally the deployment. The first two steps of ideation and prototype can be done without the strong involvement of IT who will be busy with project A. Only the existing systems are used.

In the ideation step, the check-up is scheduled as normal, but now a nurse will visit the patient at home just before the appointment and check on the condition using portable equipment and decide, together with the patient, whether to go to the scheduled appointment or to shift it to another time. The equipment can be for vital signs, wound checking, or a questionnaire – things that are normally executed at the clinic. The benefit for the patient’s health experience is not having to go to the clinic if not needed. Of course, this isn’t cost-effective for the care provider yet. This is ideation in the incubation zone.

The second step is ensuring the patient gets the equipment to use at home, either delivered by package delivery or taken when visiting the clinic to get final instructions. This time, the nurse is calling just prior to the scheduled check-up to see what the measurements are and a decision is made on whether to come to the clinic or to refer the patient to another care provider in the EMC. This is the prototype or transformation zone in which the new procedure is tested.

The third step is to let the patient send the measurements to the nurse via secure email. This avoids having to integrate the measuring device into the EPR. The patient does not have to wait for a call from the nurse. Only when the measurements are not satisfactory will the nurse send a message via email with the next step, either an appointment or a referral. This will include a notification to the preferred referral party of the care EMC. The process is adapted in the EPR to have conditional appointments, but no systems integration takes place. This is the pilot in the performance zone.

The final step is to check all the characteristics to see whether all is clear in terms of the requirements for the development of the systems integration and deployment. In the meantime, the application landscape is transferred to the cloud in project A with not only the benefit of freeing up the IT personnel but also the extra security and possibility to make use of the standard IoT and analytics functionality of the cloud.

Now, a selection can be made for a remote monitoring solution with the experience gained in the first three zones. The solution is to use the knowledge of another care provider in the EMC. A collaboration is set up to have a joint platform to facilitate cross-organization processes. This solves the constraint in development capacity in another way.

Connecting the remote monitoring equipment to the EPR is made very easy. The organization is ready for contracts with health insurance reimbursement in the productivity zone, project C.

In discussion with the other care providers regarding the need for coordination around the same person, omniversal care is noticeable. A joint vision that the patients get a seamless service from all care providers emerges. Project D is born to investigate a joint program. The whole program uses a similar approach to the following diagram:

Figure 11.4 – Setting up a program with the Learn, Build, and Measure cycle

In general, we recommend setting up a program with the learn, build, and measure cycle as used for MVPs. The preceding figure shows this MVP cycle including the transformation aspects and main topics within it. To make it actionable, communities for learning, building, and measuring are set up, feeding each other and other care and solution EMCs in the project activities of the program.

Another way to use zoning and project types in maturity-driven program management is to look up the stairs from the current position on the TiSH staircase and plan a deployment for the next tread, a pilot on the tread after that, a prototype on the third tread, and ideation for the fourth.

In our example, this translates into a possible joint program resulting from project D:

• Deployment of case management; one short term
• Pilot on stepped care; short- to mid-term
• Prototype on integrated care; mid-term
• Ideation of directed care; long-term

This will give you time to build the maturities required when needed and build a common understanding with the communities. As with normal education, it takes years to learn. Refer to Chapter 5, Leveraging TiSH as Toolkit for Common Understanding, for more information on how to build up the models.

The learn, build, and measure cycle shows the progress in the maturity of all teams and organizations in the communities; therefore, it offers a balanced way to grow together toward sustainability.

Let’s take a look at how to apply this to the transformation.

Designing with TEC teams

The transformation itself is led by the members of the TEC teams working as micro-enterprises. These teams will cycle through the learn, build, and measure cycle to drive the design process for the enabling technology. So, looking at Figure 11.4, what are important topics to learn, build, and measure?

The main learning topics are listed as follows:

• Omniversal care, including a common understanding between social and medical care and the possibilities of technology, is one of the challenges ahead
• The different forms of networked care; case management, stepped care, integrated care, and directed care
• Digitalization from the act to the treatment loop, including the use of AI algorithms
• Cooperation with other teams in teams of teams to enable systems innovation into sustainable healthcare

The main design topics are listed as follows:

• Systems including IoT, AI, and security realized in Identity and Access Management (IAM)
• Workflows not only within the organization but also across the EMC and for the operations framework for securing the availability of enabling solutions
• The TEC platform for the shared services built with the System of Systems Engineering (SoSE)discipline

For the main measuring topics, we have coined the term “quadruple aim” to which the value stages are related. They consist of the following:

• Level of quality for society in terms of participation, cost of care, and sustainability
• Quality of life in terms of health and lifestyle
• Quality of care provided in treatment and other interventions
• Quality of work for anyone involved, including job satisfaction and the appreciation of volunteers

Every cycle in every zone or project type will address these topics in some form. By continuously doing so, the common understanding will grow and, alongside that, so will the success of the transformation. Common understanding is a success factor for the transformation.

Now we will discuss three concepts, addressing each topic to be considered in real-world projects in terms of what to concentrate on in learning, designing what to build, and appreciating what is or has to be measured:

• Cooperation in digital omniversal networked care
• The TEC platform for integration in the community
• The quadruple aim for sustainable healthcare

Cooperation in digital omniversal networked care

One principle in omniversal care is the combination of medical and social care. Learning to understand the power of this combination is an important step toward sustainable healthcare.

First, we will talk about the differences in approaches that are commonly taken, followed by why that combination can benefit the health experience. The first approach is problem-oriented medical care. Indeed, this is about curing or recovering from a disease, the problem. The other approach is solution-oriented social care, which is about the solution to implement given a health or lifestyle problem. In real life, it is not that exclusive, but it serves the purpose of our understanding.

We will briefly discuss the two representative models for each approach, the Clinical Reasoning Cycle (CRC) for the medical problem approach and Solution-Focused Therapy (SFT) for the social solution approach.

In the following diagram, we show both models mapped on OODA to make the translation for the digitization steps easier:

Figure 11.5 – CRC and SFT mapped onto OODA

The CRC has eight phases, consisting of the following:

• Consideration of the patient’s situation requiring observation
• Collecting cues from the gathered information
• Processing information and analyzing this with past experiences to predict an outcome
• Identifying problems/issues by synthesizing facts and deciding on the problems
• Establishing goals on the desired outcome for the treatment
• Taking action by choosing the steps needed to meet the patient’s treatment goals
• Evaluating the outcomes
• Reflecting and learning to achieve a better outcome, and understanding what should be avoided in similar occurrences in the future

This CRC will facilitate problem-solving and decision-making to provide the best care. Knowing about past health episodes and understanding the problem are key.

SFT was developed by Steve de Shazer and Insoo Kim Berg and is all about finding solutions rather than identifying and eliminating the problem, focusing on addressing what clients want to achieve. By using short interactive interventions including miracle questions, exception questions, coping questions, and scaling questions, they achieved remarkable results. See the following tip for further reading. This approach is very similar to OODA.

Mapped on the OODA steps, this gives the following:

• Make contact so that the observation can commence
• Current context and future wishes are observed
• Orientation on strengths and differentiation on possible solutions
• Set goals for the future
• Above all, act by asking the miracle, exception, coping, and scaling questions
• Make compliments while acting

Tip

More detailed information on CRC can be found in this publication: Levett-Jones, T., Hoffman, K., Dempsey, Y., Jeong, S., Noble, D., Norton, C., et al. (2010). The ‘five rights’ of clinical reasoning and educational model to enhance nursing students’ ability to identify and manage clinically ‘at risk’ patients. Nurse Education Today, 30(6), 515-520.

For an actionable introduction to SFT, we recommend Cauffman, LL. and Dierhof, K., Solution-focused coaching - seven simple steps to solutions in coaching, Brave New Books, ISBN:9789402134971

Bringing social and medical care together in the past, present, and future is done by relating it to the ICF model. This will help us to reason and explore how these two interact. In the following diagram, the approaches are linked:

Figure 11.6 – Two complementary approaches to the health experience

CRC is approaching it from the health problem side and SFT from the participation side. Both have in common the circumstances in the environment including lifestyle.

The analyses using AI algorithms consider all factors to find the optimum balance in activities in terms of the health and participation goals. This is also the basis of the INCA model that we discussed in Chapter 1, Understanding (the Need for) Transformation.

Indeed, the coordination between the two approaches becomes more important in the highest treads of TiSH. Semantic interoperability and integration are human things; however, the platform has to facilitate all of these different actors to be able to cooperate. The ICF model can help with this by addressing which perspective is being communicated regarding the patient. The systems of intelligence have to be able to process both types of approaches and data.

The TEC platform for integration in the community

Mentioning systems of intelligence involves talking about the TEC platform itself, the second concept to connect the different organizations involved in the community. For each type of networked care, more functionality will be productive. Next to the systems of intelligence, the systems of engagement and systems of record are also impacted. The complexity will increase from the tree level, forest level, and mission level to, eventually, the campaign level.

One way to build a TEC platform is to set up a micro-enterprise for each community consisting of a complement of other micro-enterprises for a full service of the roles and processes defined in the engagement entities, as explained in Chapter 9, Working with Complex (System of) Systems. This complement is facing the care EMC and is responsible for delivering the agreed shared services for the micro-community. Operational interoperability and integration are the main tasks to facilitate healthcare provisioning as a starting point and to enable the EMC to continuously improve on their tasks.

The TEC platform adds to the functionality provided by the usually siloed systems of the different organizations. It augments the communication between the care providers and the patients. Therefore, the IT departments of healthcare organizations can become a part of the complement and start the rebundling process.

Now, we will discuss the main functions of each type of networked care.

For case management, it is important that the community knows who is doing which action. Simple messaging and access to applications via a common IAM will enable the necessary communication.

An ecogram is useful here to define the micro-community. For every patient, an ecogram enables you to know who is involved in the patient’s micro-community and in which capacity, that is, informal care, social care, and medical care. With this ecogram, every actor in the network knows who else is involved and how to contact them.

Another functionality that is useful at this stage is an agenda where all the planned contact moments from all caregivers can be seen. The benefit to the patient is that joint planning can make it easier to avoid any traffic jams of caregivers at the front door. Speaking of front doors, controlling physical access via a smart lock controlled by the IAM function can improve the safety of the patient at home.

For stepped care, decisions have to be coordinated as to who has to execute the next action. Here, cross-organizational workflows will have to be enabled by the TEC platform connecting the systems of engagement of the care providers. Here, solutions such as Microsoft Power BI Report Builder, ServiceNow, Zapier, SAP, Oracle, or other integration and workflow platforms can be useful for creating a better health experience so that the patient is attended to at the right place by the right provider in a seamless experience.

A lot of the communication that is needed in case management must be replaced by workflow rules. Think of automated forwarding on follow-up and the automated registration of which care provider is attending to the patient and why.

The experience gained in the workflow platform can inspire individual organizations and automate their internal processes, too. This frees up more capacity for direct care interaction, leveraging the investments in the TEC platform.

The workflow functionality of the TEC platform will empower healthcare professionals to make their own OODA loops designed with Journey Interaction Mapping (JIM) and automate the processes and protocols in incremental steps until autonomy is reached.

For integrated care, all medical data is required to make the integral care plan, which means building the blue line over the systems of medical records, as every integral care plan is based on the automated retrieval of medical data that is available anywhere in the micro-community. As this data is sensitive, the patient has to give consent. Every retrieval action has to be consented to or approved – either for every exchange or waived via a legally accepted mechanism where only a notification is required. This gives maximum flexibility and transparency. The patient keeps track of who is doing what. The privacy policies and rules can be implemented in the IAM functionality of the platform. Distributed Data Systems (DDSs) and the Solid Pod are suitable technologies to implement the interoperability of the systems of record.

On the systems of engagement side, a life planner that visualizes the overarching integral care plan will stimulate awareness of the importance of health. Systems of intelligence use algorithms to predict and advise possible causes of actions on prevention, early detection, and diagnostics based on all collected data, expanding on the developments of current health-supporting smartwatches.

For directed care, this has been developed even further. The individual’s avatar is constantly processing medical, activity, and circumstances data in real time to anticipate the required action in care. On the community side, the care EMC is processing data in real time to predict the required resources to deliver the forecasted care from all individuals in the systems of intelligence.

The systems of intelligence are coupled in such a way that they form an ecosystem to make full use of all available data. The purpose of the European Health Data Space (EHDS) is to provide a sustainable setup for the use of health data for innovation, research, and other activities. It will result in guardrails and guidelines for the ecosystems we are developing, including enabling systems to empower individuals through increased availability of the proper systems of engagement such as medical devices, systems of record, and systems of intelligence with AI algorithms. The same can be said of Japan’s Society 5.0.

But all that processed data has a purpose. It’s time to see how to work with that data so that it really serves that purpose.

The quadruple aim for sustainable healthcare

Measuring progress is a challenge in itself. Sustainability is the most challenging and most complex part of the transition. So, how do we measure it with a common understanding?

If we have another look at the value stages, the definitions of costs such as salary and the cost of materials, buildings, and services are well defined. It’s only a matter of opinion that defines whether these are high or low. The same applies to team efficiency in processes and the organization’s overhead of staff departments such as HR, finance, and IT.

The costs of care provisioning have to be aligned with the reimbursement.

But what about the value of health, lifestyle, and participation in relation to the changing costs because of digitalization and integration?

First, we will take a closer look at three different approaches to handling this topic. They include Triple Aim from IHI, Value-Based Health Care (VBHC) with Time-Driven Activity-Based Costing (TDABC), and John Hopkins Adjusted Clinical Group® (ACG®).

IHI has made a framework in which to measure three qualities: patient experience, population health, and cost per capita. They are widely used all over the world. However, this can only be as accurate as the data allows. Common concerns are that the granularity of the data level is too coarse, is not current, and that it takes a lot of effort to get and aggregate the data. The TEC platform will have to address these concerns as it has to automate the data collection, aggregation, and processing.

In light of personnel shortage, we add job satisfaction as a quality attribute, making a quadruple aim. Otherwise, there is no personnel to go for the triple aim anyway.

Another framework that we mentioned earlier is VBHC. It has six main themes and can be applied to TiSH as follows:

1. Organizing into integrated practice units, such as our micro-enterprise TEC teams
2. Measuring the outcomes and costs for every patient, per TiSH tread
3. Moving to bundled payments for care cycles, as per our value stage
4. Integrating care delivery across separate facilities, applying un- and re-bundling
5. Expanding excellent services across geography, via the learning community
6. Building an enabling IT platform, our TEC platform

The VBHC formula to calculate the value is Value = Outcomes that matter to patients / Cost per patient.

Here, the outcomes must be defined very well and registered to make sense. Experiences are very personal. Each community will have to choose their instruments and agree on them. This will take time and can become more elaborate with the values outside healthcare in the higher treads of TiSH.

One tricky part is understanding how to measure and monetize the outcome and how to address the time delay between making the costs and manifesting the outcomes. Investments in prevention will lead to lower care costs somewhere in the future.

On the side of costs, things are somewhat easier. The TDABC approach is an extension of VBHC. For each medical condition, the care delivery value chain is defined, and all of the key activities performed within the entire care cycle are identified. The required direct and indirect resources are mapped per step including the costs per activity and the needed capacity. The sum of all activities is used to calculate the costs.

This approach fits well with the micro-enterprises and activities supported with workflows. In fact, this creates a digital twin of the operations in the set of workflows, which can be used to allocate and calculate costs in near real time. The TEC platform has to enable the data collection for these steps. It’s clear that with the increased complexity of the community, it becomes more difficult to get the right data in a timely and automated way. Also, here, maturity has to grow in the community, which will take time.

Then, there is the method of John Hopkins ACG® at the level of the community itself. This population management approach collects data on the health and circumstances of people in the community. This data is assessed in clinical groups and classified in terms of risks (stratified) to care needs. The risk factors, social determinants, and health are translated into what health interventions need to be implemented. The monitoring and evaluation of these outcomes are key to understanding the effects and improving the approach.

Again, the monitoring of outcomes is key to a successful application. Putting the triple aim, VBHC, TDABC, and ACG®, and perhaps other models together to good use will require another topic in terms of maturity. Here, the challenge is to select properly registered data (quality data) using statistical analysis and train AI algorithms to get an accurate digital twin of the community.

The outcomes have to be defined within the community to be able to make decisions on how many resources to allocate to healthcare.

Start on the case management tread by sharing the available financial data to learn from each other and grow with the availability of better data.

With stepped care and the supporting workflows, TDABC can be applied and, along with integrated care, outcomes can be put into the value equation, too.

We place ACG® or another type of population management on the highest tread of TiSH. Fostering population management is a good sign that the transformation has succeeded.

If we go back to our example care provider, the advice for their transformation program zones is to do the following:

• Deploy the sharing of financial data with the other care providers in the community
• Pilot the collection of activity-based costs on one type of stepped-care intervention
• Get involved in a proof of concept or prototype on outcome recording
• Attend a workshop or meeting on population management in the community or initiate this when aspiring for a leading role in the community

This gives a clear road ahead along with expectations for the transformation based on the possibilities of digitization structured with TiSH and JIM. Next, we will take a look at how DevOps4Care can facilitate this road.

Empowering transformation teams

Who is doing the architecting? What is preferable to the TEC teams themselves is to be coached by engineers and consultants and empowered by DevOps4Care. DevOps is about involving all stakeholders. DevOps4Care is for care as the main stakeholder using DevOps to design quick and flexible solutions, becoming even faster and more responsive to the needs of care. This requires automation and a standardized approach to applying DevOps. In IT, we use methodologies such as Test-Driven Development (TDD) and Site Reliability Engineering (SRE). Although both methodologies focus on the development of software, we can use these principles in DevOps4Care, too.

In TDD, first, we define the test based on the requirements. Next, the tests are run. This will lead to failures since not every feature has been included yet. The initial tests are meant to fail: this will provide the data to build the product to the exact specifications and fix all the bugs during the iterative process. Tests are rerun every time the product has been improved, up until the point where all tests complete successfully.

SRE mainly focuses on making things easier by automation. Again, it’s focusing on software development, but the overarching principle can be used. That principle is about eliminating toil. If a new service or product has been launched, but it causes an increase in the workload for anyone who has to work with the product, it’s referred back to the architecting team with the assignment to improve it. This is constantly repeated, up until the product actually does make things easier and the workload is decreased.

The type of DevOps automation that we need has to reduce human assistance to process the 4Care feedback loops so that iterative updates can be deployed faster to applications in production.

The ultimate challenge in the transformation is to automate in such a way that “telling is coding” because automation resources are scarce. It would inhibit the transformation from the lowest ecocycle in the panarchy.

The models utilizing Model-Based Systems Engineering (MBSE) and building proper digital twins have to be developed for that. This will be one of the key success factors for the transformation, addressing the key issues during the whole transformation, including panarchy factors, and how and why micro-communities are getting involved.

The processes described in Chapter 5, Leveraging TiSH as Toolkit for Common Understanding, with our MoM TiSH as the model of models, CAFCR-REQS, and QFD, are to be automated. Think of capturing the voice of the customer and helping with AI such as DALL.E in an interactive exploration session: new solutions become available by going back and forth between the stories and solutions with SRE. QFD rules are automated to comply with the guardrails, guidelines, and deployment to the decomposition of functions as part of the CAFCR process.

Maturity-driven development is one way to develop the automated and, maybe one day, autonomous DevOps process. It uses Moore’s zoning to realize short feedback loops, maybe even on a daily basis, based on a common understanding of the technology with respect to healthcare so that trust is built in the minds and hands of healthcare professionals and, of course, for the health experience of every individual. With this automated DevOps4Care mechanism, we become empowered, allowing us to achieve great things. In the final section of this chapter, let’s take a look at the possibilities.

In the next and final chapter, we will land with our feet on the terra firma of today again and explore real-world stories. We will see what we can learn from the reflection of real cases using the mental models and the reasonings behind how to use OODA.

Summary

In this chapter, we learned how to bring it all together to take action in the transformation using actionable steps: the shared mental models of TiSH and JIM. We learned how to put these models into action, taking two different approaches to healthcare into consideration. The first approach is the fixing of a health issue, and the second one focuses on alternative solutions that lead to a different lifestyle and health condition.

We learned how TEC teams fulfill a key role in the transformation by architecting, designing, and implementing solutions. They form the bridge between all relevant stakeholders in the transformation process: connecting technology with care and other disciplines such as resource management and connecting various teams and organizations as part of micro-communities. However, the central stakeholder in these communities is always the patient. Finally, we learned in what order transformation steps must be taken to be successful. One important lesson here is to start small and then expand.

There is one last thing to do to conclude this book and that is to practice and hear some stories from the field. In the final chapter, we will learn from the experiences of organizations transforming into sustainable healthcare.

Further reading

Enterprise DevOps for Architects, by Jeroen Mulder, Packt Publishing, 2021