The CareOps Lifecycle

Under the CareOps model, experts from clinical operations, product and technology (software and data engineering) come together to join forces. In some organizations they are complemented by regulatory compliance to work in a tightly integrated way across the CareOps lifecycle. As mentioned in What is CareOps and why do we need it, although all these roles have a seat at the table, clinical ownership from both the clinical expertise and the clinical operations perspective is key.

Design & Validate

This stage covers the collection of inputs needed to build the care delivery process, turning the inputs into a process that makes sense and validating it with a limited set of stakeholders so it can be built to support daily clinical operations.

Inputs are wide ranging and include evidence-based guidelines, clinical knowledge, decision moments, outcome measures and timelines, patient touchpoints, data synchronization and automation needs. Boulder care looks at this from 3 perspectives: the product perspective, service design perspective and process perspective.

The objective of the Design & Validate stage is to turn all these inputs into an integrated process that deals with care delivery, data collection, distribution of information and decision support for all stakeholders, ready to be built into the software that is used during clinical operations, both for the care team (often the EMR) and for the patient (the patient app or patient web app).

For reasons explained in the “Build” stage, many care provider organizations end up never building these processes into the EMR or patient apps. Instead they end up with PDFs or other documents that are called “care pathways”, “care process models” or similar and published online or on an intranet for an individual provider to follow during daily clinical operations.

In contrast, many modern care providers are able to turn these static processes into prototypes for their care teams and patients to validate. Prototyping is a pillar of the agile software development practice and a crucial element to further refine processes and products ahead of spending expensive engineering resources in the Build stage. It allows testing of assumptions, refining of steps and activities in the process, spotting bottlenecks and checking off theory against practice. An additional opportunity at this stage is validation from a compliance perspective. Is our care delivery process in line with the most up to date guidelines? How about clinical safety?

To summarize, during the Design & Validate stage:

• Low performers iterate on and end up with static documents such as PDFs that document their processes.
• High performers iterate on collaborative tools such as Google Docs (text-based) or Miro, LucidChart, Awell (visual) and end up with interactive prototypes for validation of the care delivery processes.
• Best in class performers are largely the same as high performers but include their regulatory and compliance colleagues early in the process, to make sure the care delivery processes adhere to guidelines, medical device regulation and clinical safety requirements.

Build & Operate

During the Build & Operate stage, the validated care delivery processes are built into the patient and care team software applications and deployed for use in clinical practice.

At provider organizations where it is too costly to implement these processes into their care team software application (often the EMR), or where the EMR simply prohibits this kind of functionality, the care teams are stuck with the above mentioned PDFs and other documents to support daily clinical operations. Anyone visiting a traditional care facility must have seen flowcharts hanging on walls in examination or procedure rooms.

On the patient’s side, the existence of a patient (web) app or digital channel to exchange communication with the patient such as text message is a requirement to be able to operate these processes for patients. Too often still, these channels don’t exist and the patient is blind as to what is happening during their care delivery process. The result from the patient’s perspective is a fragmented string of consultations and procedures without understanding the overall journey.

All too often, the care team and patient’s worlds are seen as separate. In fact, they should be seamlessly intertwined. This is where building and operating in both the patient and care team apps becomes relevant. Imagine an individual care provider having a teleconsultation with a patient, recording the patient’s answers to standard questions, reading a script off of a document, explaining next steps to the patient and spending time documenting the encounter. Now imagine the same patient answering the same set of questions the day before the consultation, the care provider seeing a summary of the information as well as suggested next steps during the consultation after which automated messages are sent out to the patient and the relevant systems for clinical documentation.

Having software operate a maximum of activities the care delivery process means high amounts of automation and a severe reduction of waste in communication to align on who does what, when and where in the process. In short, the more steps and activities of the care delivery process are built into the software applications and automated, the higher the efficiencies gained and the lower the errors against the validated process. This benefits patients, care team and payers.

To summarize, during the Build & Operate stage:

• Low performers were not successful at building their (digital) paper processes into their software applications. Operations happens by reading protocols off of a PDF or flowchart.
• Medium performers have built parts of care processes and clinical workflows into their software applications, like reminders before a consultation or triggering of a specific order set. Most if not all of the building happens by software engineers.
• Good performers have built extensive care processes and clinical workflows into their software applications. Care teams and patients are prompted at appropriate times along the care journey on what’s the next step. A layer of configurability enables non-engineering roles to edit and update parts of the implemented processes and workflows but software engineers are still needed.
• The best performers manage versions of their processes over time and have tooling that enable them to do controlled, on-demand releases to specific percentages of their population (care team or patient) with a high autonomy of the clinical expert / clinical operations team in building and deploying the care processes and workflows.

Monitor & Prove

As soon as software operates processes for more than a handful of patients and care team members, the need for monitoring becomes obvious. Are all messages being delivered? What is the data capture compliance? Where are people stuck in the process? Are there any bugs or errors causing users to abandon the flow?

These questions cannot wait for a post-hoc, retrospective analysis as is common practice in the medical field. Ensuring an optimal experience and delivery of the validated process means providers organizations need to develop the ability to monitor these aspects of the processes in real-time.

Besides the need for these real-time performance indicators, healthcare is focusing more and more on outcomes of the care delivery process. Here as well there is a shift happening between care teams collecting outcomes for post-hoc analysis and those using outcomes data to inform daily care delivery for patients.

In the end, the goal of collecting data is to understand what works and what can be improved. Extracting insights from data and tying them back to the process that generated that data means the ability to prove that a specific intervention (or lack thereof) led to a specific outcome which is the holy grail in healthcare. The provider organizations who have developed this ability will gain significant competitive advantage over their peers and emerge as healthcare winners in the decades to come.

To summarize, during the Monitor & Prove stage:

• Low performers collect partial data and do post-hoc analysis
• Good performers collect data that tells the full picture (outcomes data and process performance metrics) and use it for both post-hoc analysis as well as to inform daily care delivery
• Best performers are like good performers but on top have developed the ability to prove that a given variation of a care delivery process or clinical workflow leads to better outcomes and/or lower cost

Rinse, repeat

Finally, the CareOps lifecycle is exactly what it says: not a one-time implementation but a loop that needs to be closed and ran frequently to yield improvements. Insights from the Monitor & Prove stage should be fed back into Design & Validate to generate hypotheses on improvements to care processes and clinical workflows.

A higher iteration frequency is an important pillar that will set healthcare winners apart from their peers. A quarterly iteration means four opportunities to learn and improve vs. only one for a competitor that iterates once a year. Building the organizational muscle to constantly experiment and iterate needs first and foremost a culture of agility and continuous improvement. It also requires the right infrastructure and tooling. You might want to do a monthly release but if your tooling prohibits you from doing so, you will not go far. Finally it requires a set of practices that make sure something of value comes out of the cultural mindset and tooling that is available.

In the third and final article, we’ll dive deeper into what successful organizations look like in terms of culture, tooling and practices and propose metrics to measure the CareOps practice.