Table of Contents

Current Gaps

The main gaps we see at the moment between where CiviCRM is and where we'd like it to be are:
1. milestones activities
2. observed activities and non-observed activities
3. goals (now understood as milestone activities that have a status of "planned" or "desired")
4. roles, or relationships to the case (which may be different from relationships among people and organizations)
5. the way that properties are propagated among activities and between activities and the case

1. Milestone Activities

These are entities that define particularly important occurrences within the case. (I'm struggling not to use the term "event" here, because it might get confused with the way that "event" is used in CiviEVENT). Every type of case has at least two milestones activities:

the milestone activity that defines the beginning of the case
the milestone activity that defines the end of the case

There may be many more activities between these two that are of interest. Cases that start off with the same beginning milestone activity are all of the same type. They may be later altered to be of a more specific type (e.g. "Absence from work" may be altered to "Absence from work for health reasons" ). They may also have their defining milestone activity changed (see observed activity vs. non-observed activity) as for example when an absence from work is reported, then later found out not to be true. The sociotechnical system as a whole needs policies about how to behave in this set of circumstances.

All activities (including milestone activities) have a hierarchical structure. For example, "Andrew went to the store" might be a milestone activity. I can break that down into many smaller activities that have a "part of" or meronymic relationship to the bigger activity:
a) leave the house
b) get on the bus
c) get off the bus
d) walk to the store
e) enter the store

Each of these sub-activies can be further broken down, until the whole exercise is no longer interesting. Likewise, each of these sub-activities is an activity in its own right.

The traditional approach to recording name:value pairs in case management databases has been to create a column in a table somewhere associated with the name (i.e. create a field with a field name) and then fill that field with values. The trouble with this approach is that it basically requires someone with database design privileges to modify the table (or create a new table) every time the requirements change.

We're taking a somewhat different approach. We're assuming that everything is going to be recorded as an activity. The "type" of activity will essentially be the name in the name:value pair. What this means is that where a "traditional" case management data structure might have had one record for a case, and had 20 fields in that record, we'll have 20 records, each one an activity, and each one containing some sort of "name" or "type" field, and then one or more "value" fields. Each activity will also be associated with at least one date-time field, and maybe more than one. The key thing with this is that we probably have a lot more activity records to display than in a "traditional" case management system. This means that users will probably need more ability to filter and sort the large number of activities.

2. Types of activities: observed vs non-observed

There are two different types of activites:

observed activities: these are activities in the CiviCRM sense, in which a CiviCRM user participated in them in some way, and recorded that participation in the system.
non-observed activities: these are activities which are children of observed activities. They are distinct from the observed activities in that no CiviCRM user participated in them in any way. Instead, their existence was described to a CiviCRM user in the context of an observed activity which may or may not have been an milestone activity.

Observed activities are generally communication activities (ie a phone call or a meeting) in which the CiviCRM user participated. Non-observed activities are discovered in the context of an observed activity, and may be past or future dated. When they're past dated, they refer to something that actually occurred that may be of importance to the case. When they're future dated, they generally refer to something that is either planned or desired. Non-observed activities are always discovered in the context of an observed activity. Multiple non-observed activities may be discovered during the course of one observed activity. There's a real advantage to recording each activity separately (i.e. creating multiple records that map one-to-one onto a non-observed activity). The reason for this is that it's really helpful to sort all activities into a chronology of occurrence (story or fabula), rather than one of discovery (plot or syuzhet). This is important because one of the purposes of case management is sometimes to discover "what's really going on": the main motivating forces behind a human situation or problem. Arranging activities into a chronology of occurrence is known to help decipher these for participants.

For example:
Claire has an accident at the workplace which is witnessed by Andrew. Andrew then communicates the details of the accident with Suzanne the case manager. Claire is the client in this case, Suzanne is the case manager (or administrator: we haven't yet determined the best term to use for this person / relationship). Andrew might be in a relationship to the case of "witness" or "collateral historian".

The observed activity is the meeting between Andrew and Suzanne, in which Andrew describes the accident he witnessed.
The non-observed activity is the actual accident which happened to Claire, and was witnessed by Andrew, and described by Andrew to Suzanne. During her documentation of her meeting with Andrew (which may occur during the actual meeting itself, or shortly thereafter) Suzanne would make a record of the non-observed activity, selecting some properties for the activity which would include the date (and probably time) it happened. Then when Suzanne wanted to create a chronology of the case, the accident milestone activities would sort in the proper order of date-of-occurrence, not according to the date of Suzanne's meeting with Andrew (the activity where the existence of the non-observed activity (the accident) was discovered).

The goal of a case is often a non-observed activity. For example, settling someone in supportive housing might be something that the case manager/administrator doesn't actually do or witness, but hears about in some way. There is often a need to trace / navigate from the record of a non-observed activity back to the observed activity in which it was learned about (this is called attestation).

3. Goals

The goal of the case is the milestone activity that defines the end of a case. All of the activities in a case will be leading to the goal. The goal activity may sometimes be an observed activity and sometimes the non-observed activity it may refer to. For example, "secure the release from prison of [the case subject]" might be a goal, or "[case subject returns to stable employment]." Each of these might not be directly witnessed by the case manager, who may instead rely on observed activities (i.e. communication activities - including paper documentation) that these events took place.

As activities, goals are always hierarchical, being composed of subgoals. Goals have the same kind of complex relationships that work packages and tasks have in project management. Sometimes work toward one goal cannot be started until work on another goal is finished (or started).

Another way of conceiving the goal structure inherent in cases is to view them as processes, which can be represented by process flow diagrams (in all their various standard forms). The achievement of a goal can be considered an activity. Therefore, I guess a goal is an activity that is planned / hoped for, but not yet actualized.

Sometimes it is important to be able to report on the lack of achievement of goals. For example, many of us in IT will be familiar with service level agreements. Generally these are of the form of "within X [time units] of the occurrence of [activity Y], another [activity T] will occur." Case management groups usually have a lot of these sorts of service levels (either explicit or implicit) that they need to be able to report on.

4. Roles

Most people are familiar with the concept of roles as they pertain to an organization, since they are closely linked to the concept of occupational title. In case management, there are generally several archetypal roles that are associated with each type of case. Each person who is interacted with in the case generally fits into one (or more) of these roles. The number of roles will vary, but generally there are more than three, and fewer than twenty. Some examples,

in a vocational rehabilitation case there might be (injured) worker, supervisor, senior manager, primary health care provider, other health care provider, insurance claims representative, etc.
in a correctional rehabilitation case there might be: client, affected victim, parole officer, social worker, etc.
in a physician health case there might be: subject, primary care physician, workplace monitor, drug screen supervisor, licensing authority representative, medical staff assosciation representative, etc.

The roles are similar to "relationships" in CiViCRM. They also describe how individuals are related to the case as well as each other.

5. Case / Event Attributes and their inheritance

Case attributes always need to be non-observed as decision-making activities, rather than just as fields in the case record. The act of deciding that a case has a certain attribute is in itself an activity, and it needs to go into the activity flow (history) of the case. It may be convenient to decide that certain types of case attributes are auto-abstracted and stored as fields directly in the case record, but they would then only represent "the most recent label of type X applied to case Y". (This might be the way that certain folks have implemented in Drupal the feature of modifying taxonomies by comments.)

This turns out to be like reverse inheritance. Instead of the event inheriting properties of the case (which it might be said to do from some viewpoints) the case inherits (in an inverse sense) the properties of one of its component events.

Usually there will be a communication activity associated with the event that changes a case attribute. So, it's probably convenient to offer the user the opportunity to update certain case attributes each time a communication activity takes place.

6. Functions to support QA review

a) Anonymization/Obfuscation

Many case management groups need to have their practices reviewed occasionally by external auditors or reviewers. Sometimes these reviewers are allowed (by locally applicable confidentiality rules) to view the actual identifying information of parties in the case. Other times, the identifying information needs to be removed. An ideal case management system would offer the case manager some support so that as activities are being non-observed, information can be tagged that might later need to be removed / anonymized or obfuscated when the case is reviewed by external parties. For example, if there was a little bar at the top of a text input box that contained the names of those people assigned roles in the case, and a particular "code" which would stand in for that person, the user could enter the code for that person (or entity) and see their code replaced by the person's name. However, during a subsequent export process, a different, fictional name (or other standard term) would be substituted for the actual name.

b) Loadable sets of versionable metrics

Often case managers have to deal with some sort of external body that decides the metrics that are relevant for measuring progress in a case. These metrics are generally ratios of counts of events, or sometimes time intervals between events. For QA purposes, it's often relevant to determine when a goal has not been reached (i.e., when an event that describes a goal or subgoal has not occurred, but was expected to occur, or was supposed to occur). These sets of metrics tend to evolve over time, and to have versions. So it might be relevant to know for particular attributes assigned to a case which version number of metric set applied to the case data collected.

Often these sets of metrics will offer categories that can be applied to a case. These categories are often versioned (ICD-9, ICD-10, DSM-4, etc). As with any system of categorization, it's sometimes difficult to fit a particular event or case into the structure of existing categories. What would be ideal for this is a way to indicate that a particular classification was a "wedge" into a category. This would facilitate the review of cases that don't fit neatly into a category structure, which could then presumably evolve to agree on what to do with such cases.