CiviCRM Community Forums (archive)

(posted by Andrew Clarke)

Xavier, I can't tell you how reassuring it is to have you mention those specific features (automatic population of planned milestones when case type is selected, and time tracking).  I say that because those are features built into the commercial case management system that I've previously been involved in designing and marketing.  So what it's starting to suggest to me is that my current plan for generating objects, properties and requirements just may work out.  What I'd planned to do is just describe the features that are present in the other system I'd been involved in developing, of course trying to improve on what we built.

I think it's also true that there are a number of contexts in which the need to create a case can be discovered.  We want to try to reduce the number of steps from discovery to case creation.  So, as you say, we could be in the middle of a phone call, reading an email, or looking at a printed document when we discover "oh, I think this is the beginning of a case".   In the past, in commercial contexts,  we were also often looking at some other proprietary transaction system, like an HR system, or the output of a different CRM system from some other organization that had sent us a "referral" message.

 

Here's a description I wrote last September 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. 

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.   (look here for an example)
http://wiki.civicrm.org/confluence/display/CRM/CiviCase+-+Requirements#CiviCase-Requirements-milestones)

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.

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

Assuming for each case we have several roles, and that these roles are filed at any time with a person (well, actually, they don't have to be filled, but we can still have an unidentified parole officer to be designated in a few months).

Wouldn't it be be "easier" to have the past activities with the person, and the planned one with the role ? when modifying the case and changing or setting the role to assign it to a person, it would offer to automatically affect all the planned activities with that person.

What do you think ?

X+

Andrew - agree with you on the navigability (hard word!) - I would see that if I was tracking old 'interactions' with the Mayor of a city I would want to be able to identify who was in that role at the time - but envisage that if we had 'role/office' as a new Contact Type then the 'activity' would belong to both the Individual and the Role/Office. So I would be  aiming for the system to deliver what we both need in that respect (and don't see why that wouldn't track in to the future).

We are quite a backward country and I don't think cocaine is high on our mayor's diets.

Just want to be clear that I did not set out to argue for 'role/positions' as a contact type particularly to help with activities - but more to do with the provision of information (we want to keep sending information on eg transport to the mayor, regardless of who is in that role).

I just think that some of the needs i have and foresee will be replicated in other examples such as Activities and am doing my best to tease them out.