CASE is a place.
It’s where you collect data, make decisions, manage work and workload, record progress toward meeting objectives and it’s a place where you make data available for use by local and remote 3rd party systems and application.
It’s not a methodology.
We manage Cases using various methodologies such as background BPM (“best practices” orchestration), background ACM (flexibility, governance), R.A.L.B.(Resource Allocation, Leveling and Balancing) and FOMM (Figure of Merit Matrices).
Clearly, we want consistent good outcomes at Cases.
It follows that if some Cases have better outcomes, it makes sense to use one of these as a template for a new Case as opposed to starting from scratch with process fragment templates and then adapting the Case by adding ad hoc interventions as the new Case evolves.
All of which brings us to the notion that cloning Cases that had good outcomes “is a good thing”. Martha Stewart would agree.
Our starting position is to identify Cases that had good outcomes.
Not much guidance available here – you have to define a set of KPIs at Cases (key performance indicators), consolidate and weigh these over time across multiple instances to where you can “rank” Cases according to outcome and the rest, (i.e. picking a high-ranking Case to clone) becomes relatively easy and non-subjective.
Except that if we pick an area like healthcare, where it can seem that each patient is unique, we need a few ground rules.
In healthcare you rarely see end-to-end “best practices”.
What we see instead are process fragments that healthcare professionals, robots and software thread together.
Whereas we used to have “the chart”, we now have e-charts, and the idea is you go there before you make any decision regarding the next intervention for a patient.
Not surprisingly, above and beyond process fragment templates, we see ad hoc interventions at healthcare Cases based on actor experience, judgment, peer consultations, and, again, e-chart reviews.
How / what do we clone under this scenario?
- Clone a “good” Case.
- Mark up the Clone to show the sub-pathways that the Patient who was the focus in the source Case navigated through.
- Purge out information that would allow you to identify the source Patient but keep data like symptoms/signs, diagnoses, treatment plans, goals/objectives.
- Stream your new Patient onto the Cloned Case’s pathways (including ad hoc steps which you can consider to be “pathways of one step each”).
- Pale out the inherited data from the source Case.
Now, as you proceed to process the new Patient, as usual, post the forms at each step as steps become current, and record, for example, symptoms/signs as you would, starting from an empty Case, but, in respect of paled out data, treat the data as you would when doing a differential diagnosis (i.e. does the new Patient perhaps have “night terrors”?).
If the patient says yes, affirm the inherited data, if they say no, then do nothing or expressly null out the data, the processing rules will automatically drop any un-affirmed data as you leave each form and then commit the step.
At decision boxes, reach a decision re which way to branch in the usual way, but, again, take note of the source Case branching. Do not allow the branching choice in the previous Case to bias your decision-making but remember the reason the source Case had a good outcome is because the processing at the reference Case went this way instead of that way.
You can see that this type of shadowing of your new Case gives you a something of a real-time “second opinion”.
Not into healthcare services delivery?
No problem, the same approach can be used for manufacturing, insurance, b2b.
In fact, if each new Case does not lean too far toward once-off, you might be able to skip the manual decision-making and consider “Meta Case” management where software picks the best reference Cases and automatically updates “best practice” templates.
We will steer clear of Meta Cases in the healthcare domain for the time being.