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.
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:
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:
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:
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.