When you transition from BPM to ACM/BPM the notion of “process” changes.

No longer do we have start-finish processes that ensure that a Case instance called “generator” or “patient” carries through to completion.

When constructing processes or process fragments for assemblies, patients, or b2b initiatives, it’s not prudent to rely on a “go to” or “return to services” construct as the final step along each process/process fragment/ad hoc step.  One missing construct across a daisy-chained sequence of interventions at the Case and your Case becomes an orphan.

Besides, who says any Case will go to the end of any open/active process fragment?  – in ACM and ACM/BPM users can do what they like, including exiting abruptly at any stage of the processing.

All of this added flexibility goes against the core objective of Case of ensuring continuity over time through to attaining Case objectives and Case closure.

The way to solve this problem is to incorporate a cross-Case query that tracks the following state indicators:

Cases not on any Pathway (i.e. process/process fragment/ad hoc step)
Open Cases
Archived Cases

Cases that have exceeded time limits

Completed Pathways
Suspended Pathways
Cancelled Pathways
Removed Pathways

The first three tags cover 100% of all eventualities (not on a pathway, on a pathway, archived).

Next, we a qualifier for Open Cases (i.e. processes/fragments/ad hoc steps) that are not receiving services (e.g. we figured 8 weeks to case closure, it is now 10 weeks).

“Completed” is the usual expected outcome; “Suspended” means someone has put a hold on the process/fragment/step; “Cancelled” means a user terminated processing; “Removed” means a recall of a process\process fragment\step.

I would appreciate comments on any missing states.

Courtesy to Walter Keirstead. This blog is also available on http://kwkeirstead.wordpress.com/

Follow