Custom group to extend the 'case type' entity

[nickholden]

Is there any ongoing work, or a plan even, to enhance the capacity of CiviCase with regard to custom data such that a custom group could extend the 'case type' entity? Currently we can extend individual cases with custom data, but there is sometimes what might be called metadata which is common to all cases of the same type. The attributes available when case types are defined (label, description, and that's basically it) would benefit from being extensible with custom data, but currently when you add a custom field set, "case types" is not an available use for it.

Is anyone interested in exploring this?

[demeritcowboy]

Hi,
It's difficult to determine the context from your question. Can you describe what is the task being performed by the user and the expected results of that task? And if necessary a description of why the task is currently difficult.

[nickholden]

The task is creating case types, which in our civiCRM instance we are using to represent research projects, with each 'case' representing the recruitment of a particular contact to a particular project. We want to be able to record additional information about the project / case type. Metadata if you like, about the cases, which will be common for all cases of the same type, but different for cases of different types. We can create a custom group which extends the 'case' entity, but then each case has the custom data, not the case type. And entering the same information into every case of a certain type is an inefficient data entry practice - it would be better to record that custom data just once against the 'case type' entity. Custom field sets can apply to many entities in CiviCRM, but not (currently) case types. That means the only way to record such metadata is to include it in the 'description' field when we create the various case types, but we would like something more searchable and systematic than that.

[demeritcowboy]

Ok, the short answer is there isn't currently anything like that other than the description field. Activity types can be limited to only be used for certain case types, and those can have custom fields. But I think I'm still missing the "use case"/end-goal (http://www.usability.gov/methods/usecases.html).

You say "more searchable/systematic", but for what end-use? At the moment I'd have to guess, which probably won't be helpful. What is the task in which the metadata is later used? There may be another way to set it up so you can do that task.

[nickholden]

It's probably because we're stretching the intended use of CiviCase to begin with. Let me take a step back...

We have adopted CiviCase to represent research studies. Our contacts are potential study subjects, with whom we have a series of engagements (letters, emails, etc.) inviting them to participate in particular studies, and then, for those who agree to take part, we monitor their involvement. Civi seems an excellent platform for this work, and the way we've modelled it includes the use of CiviCase. So for us, a 'case type' represents the actual research project itself, and each individual 'case' is actually an enrolment of a participant/contact onto that project. Each project has a workflow, which the CiviCase activity timeline allows us to model, and we can track which contacts have agreed to take part in which studies, by monitoring open 'cases'.

What that means is that for us the 'case type' is not an abstract entity (a 'type' of a thing isn't a thing) but is in fact the representation of the specific research project, to which contacts will be invited to enrol. Therefore, because the 'case type' entity is being used to model the specific research studies, we want to record for each study additional attributes such as the ethics committee approval number of the study, the name of the Principal Investigator of the study, and some similar data. These attributes are attributes of the study itself, not of individual enrolments, so we need the capability to add custom fields to the 'case type' entity in order to record them.

I recognise that this is an edge case. We're using the CiviCase object model in a different way. But since custom fields can be set to extend many different objects within the CiviCRM object model, it seems to me that it should be possible to allow for a custom field set to extend the 'case type' object as well.

Thanks for your thoughts on this.

[demeritcowboy]

Thanks for taking the time to provide more info, and sorry if I sound like a broken record, but the end-use of this metadata is still missing.

Maybe I'm not explaining well. This http://lyle.smu.edu/~lghuang/CSE8313/paper/usecases_intro.pdf (pages 3-6) seems pretty good. In particular the part where it says "We don't have ATMs just so that people can enter PINs". The user enters their PIN as part of an end-task, in which buying something with cash is yet just another step towards that end-goal. e.g. you might take out some cash so that you can buy an umbrella, with the end goal being to keep yourself dry.

So taking the two examples of metadata you've provided, one thing is it's still not clear why they couldn't go in the description field of the case type, because how the user interacts with this metadata is still missing. I have to assume having it appear on the manage case screen isn't enough, but it's not clear where it should/could appear because it's not clear what the user is supposed to do with it.

In terms of the civi data model, case type isn't really modeled as an object the same as other objects, although you could sort of treat the xml file that way, i.e. add sections to the xml file corresponding to "custom fields", and then pull those in where you want them. But still, you'd need a use-case to determine where they should be pulled in.

[MJCO]

I'm looking for this as a feature too.

I'm implementing CiviCRM, in particular CiviCase as the records management system for an asylum and immigration advice service. We have certain 'codes' which we need to track. Some of these are related to case-types which should NOT be seen by the end user really but should be tied into certain reporting scenarios.

Example:

Case type: Asylum
LAA Code: IAXL

Case type: Immigration
LAA Code: IMXL

Case type: Asylum Appeals
LAA Code: IAXC

Case type: Immigration Appeals
LAA Code: IMXC

etc...

We need to store the LAA codes against a particular case type so that we can programmatically utilise these in our reporting functions.

These are not for 'end users' (caseworkers) they are more for the administration side of the system.

Nevertheless the ability to collect extra information on a 'case' level would be advantageous in a number of scenarios.

[demeritcowboy]

This particular requirement can be implemented by setting the "name" of your case type to the code, and the "label" to the english word. You can either edit table civicrm_option_value in the database directly, or when you very first set up the case types in the UI, use the code, then re-edit it and change it to the english word. This will keep the "name" as the code, but change the "label".

And of course in your xml you ALWAYS use name, which in this case is your "code": http://wiki.civicrm.org/confluence/display/CRMDOC43/CiviCase+Configuration

[MJCO]

Thanks,

I had set it up this way for another field in the system. Don't know WHY I didn't think of doing it for the case types...

[dlats]

This is for nickholden. I realize that this is after the fact, but might be of value. If the reseasch projects are entered as Organizations, then custom fields can be attached. The contacts could have cases to assist signing them up for the study. Finally the contacts would then have "membership"  in the study.