Jane has been hired to help a care team consisting of doctors, care coordinators and therapists map out their care processes. The goal is to be able to tie clinical outcomes back to the care journey that was followed, then use insights from that analysis to further improve their care processes. Jane starts by interviewing the stakeholders to get to know their current workflows. Then Jane begins to map out all the activities in a flowchart, the classic way of representing work processes. In no time, she encounters all the exceptions and conditions at every step of the process. For patient type 1, do this. For patient type 2, do this and that and involve person X. Jane finds herself trying to draw flowcharts with loads of branches. A quick calculation makes her realize that a disease with four different phenotypes and four different treatments for each of these phenotypes would create a flow chart with 16 branches in the second step of the flowchart.
Care teams have always tried to represent their processes as described above, by using BPM or business process modeling and drawing flowcharts. But healthcare processes are unique: they cannot be defined as strictly as business processes. This means the flowchart, and by extension BPM, is not the right medium to capture healthcare processes.
Think about patients that become irresponsive to a given therapy and, thus, have to change it. Patients with comorbidities need their treatment adjusted. Or patients that miss their appointment need extra convincing from the care coordinator about the importance of the consultation. In all these cases, the care team draws from the vast knowledge on how previous patients reacted under similar circumstances. Very often, events happen to a patient or a care team that influence the predefined workflow. Failing to represent the course of action means we're failing to support our care teams to take the best next step at all times in a patient's journey.
Yes, flowcharts can look nice on paper. And indeed care teams see them literally everywhere as it is an attempt to tame the variation in real life and bring it back to a simple process that can be controlled. But this effort is futile. Flowcharts and BPM cannot reflect the whole care process and its variations in practice. In most cases, the multidisciplinarity of a care team, different patient characteristics or sudden changes of circumstances are not taken into account. Thus, what's needed is a modeling language that can capture and incorporate this complexity and the knowledge within the healthcare workflows in a better way.
A modeling language that uses rules to describe variation and does not need to map every eventuality with arrows in flowcharts provides this desired flexibility. In the examples described above, it means providing the flexibility of changing a treatment based on its efficacy. It means adding another treatment against the comorbidities. It means additional following up with a patient and providing further information.
Awell Studio is built for these unique healthcare requirements and allows Jane and her peers to model care processes by combining the flowchart and a powerful rule engine to create the flexibility where it's needed, bringing them one step closer to their ultimate goal of tying clinical outcomes back to the care process.