Here's a description I first wrote a few months ago when I was tossing back and forth ideas to build this kind of system in a different context. I've adapted it a bit to suit the current terminology. I originally posted it in the
forum, which is where I'd invite you to put your comments.
A case management system is basically a big table of activities, which come from various sources. The sources might include:
- humans entering them into a web form
- another system spitting out an event stream, which is then parsed, filtered and stored
Activities involve, and therefore refer to, people and organizations. In CiviCRM and CiviCASE we refer to people and organizations as Contacts. When Contacts are associated with activities or milestones (by participating in them in some way) they acquire a relationship to (or role in) that activity or milestone. For example, an activity whose type is "criminal act" might have roles labeled "perpetrator" and "victim". An activity whose type is "commercial transaction" might have roles labeled "vendor" and "purchaser". Some of these activities tend to create roles that persist for quite a while. For example, the signing of an employment contract defines the roles of "employer" and "employee" and what we commonly refer to as "the employment relationship" often persists for quite a while, until it ends with one of a range of activities that define its ending, like quitting or being fired.
CiviCRM already has the ability to store relationships between contacts. What I don't think it currently has, and which it might need to acquire in CiviCASE, is the ability to associate these relationships to the activity or milestone that created them. For example a parent-child relationship might be associated with a birth milestone. A spouse-partner relationship might be associated with a wedding milestone. The storage of relationships in contact records is really just a convenient way to store relationships that are relatively persistent over time. More transient relationships might exist only within the context of a single milestone (like vendor/purchaser) or might persist for the life of a case (like claimant/insurer).
In addition to creating relationships with various degrees of persistence, milestones and activities can have different stereotypical data that can be associated with them. Going back again to our example of a commercial transaction, there might be an amount and a description of an item. Or it may be decided to model the entire transaction as two separate but related milestones: making a payment, and delivering the goods. Payment milestones would always have $ amounts associated with them, and imply the relationships of payor and payee to the milestone. Writing a cheque could be a single milestone, or it could actually consist of multiple “payment” milestones, because it's possible for a payor to pay a number of different amounts for different things on one cheque.
So we arrive back back at the general feature of activities and milestones that they can always be composed of multiple smaller entities of the same or related types. For example, interactive conversations are really just an ordered collection of smaller conversations. Stories are an ordered collection of smaller stories.
Viewed in this light, a “case” is really just a definition stored somewhere of a pattern of activities and milestones (possibly of different types) that together make up a larger, more complex composite activity or milestone. The definition of which activities and milestones are archetypal of a particular type of case is stored somewhere, and populates the planned stream of activities when the case is created. From that point, the real lived experience of participating in the case is in some sense a working out of how closely the actual order of activities conforms to the definition that the system stores.
Just like activities and milestones, cases have contacts (meaning people and organizations) in relationships to them (i.e. roles). The thing that's sort of implied about cases is this notion of trying to achieve one milestone when another is encountered. Cases look at one milestone (or pattern of milestones that's called a single one for convenience) and then try to work toward another planned milestone that is the ultimate goal of the case management process. The goal is essentially represented as another pattern of milestones agreed on by the participants (roles) in the case as being the stored definition of the “end” of the case.
Comments
Hi andrew - have you given any thought as to how one might associate a milestone with a 'role' rather than a 'person' or an 'organisation'? I raise this because I can see several benefits from being able to associate information with a 'position' rather than with the 'individual' who holds that position at any one particular time. To this end I am trying to stimulate some debate around the notion of their being a new 'contact type' that is a 'role/position/office' - examples of these might be Principal of a School, Mayor of a City, Manager of a project - in all cases the information/data needs to be associated with the role, and persist with that role whenever the person in that role changes. You can see my wiki on the idea here http://wiki.civicrm.org/confluence/display/CRM/New+contact+type+for+Position+or+Office (will duplicate this on the forum post too)