Automated Population of Case Milestones

[Dave Greenberg]

(posted by Xavier Dutoit)
Hi,

 I'm making analogies with issue trackers/helpdesk tools (eg. eventum).

One thing that's been proven painfully annoying is to have the open case+create first activity milestone as two separated steps (same goes for closing+final milestone). No matter how it is stored, I'd suggest to have it done in one single screen.

Ok, please allow me to throw a few questions/ideas here, and feel free to suggest a better place:

 1) Template case

In most of the cases, I suppose the various steps and activities are more or less defined. eg: case type "dummy": Initial meeting now, call with the manager in 3 weeks time, another meeting in 1 month, close the case in 2 months, send a thank you email to the manager 2 days after.

It would be great when I create the dummy case with Andrew and that I assign claire as the manager to the case to have automatically the various activities pre-filled with the right status planned, so I will not forget to send her a thank you email.

2) Time tracking

is it planned to keep track of the time spend on the various activities ?

[claire sauve]

(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.

 

[Andrew Clarke]

I'm starting a use case about case creation here, because it seems to be discussing the use case "create a new case". 

http://wiki.civicrm.org/confluence/display/CRM/CiviCase+-+Primary+Use+Cases

I guess this page might move if we eventually reorganize the wiki so that each use case has its own child page, but this should at least take you to a page where you can easily find the relevant use case.

[Andrew Clarke]

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.

[Dave Greenberg]

Andrew - I think this is a really helpful overview which I suspect will play a significant role in driving the design work for CiviCase. Can you post this to the blog to give it a bit more visibility?

[petednz]

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

[Andrew Clarke]

Hi Peter - Yes, I've given this quite a bit of thought.   The entity you describe makes a lot of sense.   The concept of a "position" is inherent in most Human Resource Information Systems.  Most things go along with a position, not a person.  A person in an organization fills a position.

With respect to cases, it's even a bit more complicated.  What we've found works well is a double layer of indirection: you most often need both a position AND a role.  The role defines the set of activities and milestones that are usually carried out by one person in the context of a case (e.g. 'parole officer').  In many cases, the person who fills a role in a given case will be in a given position within an organization (e. g. Joe Smith is a Parole Officer at the Baltimore Police Department).  Sometimes the mapping isn't so obvious.  For example, someone who fills the role of "worker advocate" in a disability case might map onto the position of "shop steward"  at an organization like a trade union.  If you just map the two individuals directly together, you actually miss the chain of relationships that you need in order to manage workflow and milestones properly.

Jane reports a "workplace accident" milestone.
Susan recognizes this as a milestone that begins the case type "worker disability".
Susan creates a case with herself as the case manager, and Jane as the client.  Susan assigns the case type "worker disability".
Worker Disability case type has a role defined for "worker advocate". 
Susan knows that Jane belongs to the SEIU, and places the position of "SEIU Shop Steward" into the role of "worker advocate". (In a later version of CiviCASE, the system might even read in a business rule and make this assignment for her).

Here's where things get slightly interesting.  Often times case management spans organizational boundaries.  If the case manager (Susan ) doesn't know, or has out of date information about, who is the SEIU Shop Steward, it becomes problematic to route things like reminder notices and such to the right person.  In our work, we've suggested that where organizations have service providers that need to interface with a case management system that is administered by a different organization, they should set up email accounts that use role titles rather than personal names.   So for example, SEIU would have an email account for "ShopStewardLocalXXXX@SEIU.org" or something like that.  That way, CiviCASE can just route information to the email corresponding to a position, without worrying who is filling that position.  It becomes the responsibility of the SEIU mail system administrator to make sure that mail addressed to the Position-specific email address gets routed to a real person.   

I don't know if this is making sense or not.  It seems like a lot of complexity, but I think that complexity is actually needed where people from various organizations are collaborating on a case, and where they don't all have access to the case management system.    If they all DO have access, it might still be a good practice to use position-specific email addresses, because it becomes a way to remind people that they need to go into the system and update the association between their name and their position.

[xavier]

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 Clarke]

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).

I think basically what you're referring to here is the notion of double indirection:  a case refers to a role, which refers to a position, which refers to a person.

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.

Depends on what you mean by "easier", I think.  Easier might be in a trade-off with better.  I'm all for keeping things simple, but no simpler than they have to be.

With respect to past activities, I think we want navigability to both the person who participated in it and the role that person was acting in (with respect to the case) when they participated in it.   We want to store this because people change roles over time, and it's sometimes important for program evaluation purposes to know what their role is with respect to a case when we're tallying up the cost effectiveness of a particular case management plan, for example.

With respect to future activities, I think it's an implementation decision, and it will depend a lot on how Lobo and others decide it's best to drive the workflow engine.  Clearly you want to be able to say at any given point which upcoming activities are assigned to Jane Smith.  You want this to be an aggregate of all the activities that are assigned to Jane in all the different roles that Jane plays in various cases.  I think that Jane probably wants to see her activities with some traceability back to the roles that she plays in the cases, again perhaps for purposes of time budgeting.    I don't pretend to know how it's best to store things so that the query that provides her with such a view would execute quickly.  It does seem to me, though, that you don't want to lose the information about which role she's in for any given future activity.

[petednz]

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).

[xavier]

Hi,

About the double indirection:

role->position->person

Might have simpler needs than you, but within one case the role->position link is pretty obvious (eg. the role "manager" is going to be filled by the "case manager position"). In my cases, the position is redundant I think.

You are right saying that it's important to remember that one activity as conducted as someone fulfilling a specific role. However, that's a need for all the activities, not the only the ones in within a case.

eg. if you see an activity "bring 2 big cheeses" associated with your city major, it doesn't make much sense, unless you see he was having the job title "pizza delivery man" at that time.

(if this example is too far fetched, replace pizza with cocaine, might get closer from real live scenarios

X+

[petednz]

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.

[Andrew Clarke]

I probably come at this from a set of experiences that have involved just about all the potential complexity there is in case management. So I might suggest things that seem too complex for others.

In my world, most case management is quite interorganizational: roles within a case are filled by folks from four or five different organizations.  What those organizations call their people internally is one thing (their position in the organization).  The names we use to refer to them in the case management context is another thing (the role).   So I mostly see the need for proxies on both ends.  But I understand how not everyone would see this need.  (There is a good example of where this may be needed in this previous post http://forum.civicrm.org/index.php/topic,3453.msg15807.html#msg15807)

Would it be easy and do-able to just relegate the double indirection to a single layer by saying that in many organizations roles are always going to be filled by the positions of the same name?