PlanningThe CiviCase component provides a high degree of customization to meet the needs of a wide variety of case management settings and workflows. It is important to understand CiviCase's underlying principles and assumptions, as well as the elements which can be customized. Then you can plan and configure the component based on how your organization manages cases. Assumptions:
Case Types, Activity Types and TimelinesThe first step in planning your CiviCase configuration is creating a list of the types of cases you handle. Examples of case types from the Physician Health Program are:
For a community services organization, examples might include:
For each case type, list the types of activities (interactions or other events) you typically record for a case. Then create a timeline for each case type, listing any of these activities which generally occur in a predictable order and should be accomplished within a certain timeframe (e.g. you might think of this as a case plan). Define the expected number of days between the beginning of the case and each of the subsequent activities in the timeline (reference offset). If needed, you can also define an offset from another activity. EXAMPLE: For a "Referral to Specialist" case, the "facilitate first appointment" activity might be expected to occur within 2 days after the case is opened. "Survey client satisfaction" might be scheduled for 30 days after "facilitate first appointment". You can also define a set of activities to be included in audit reports that CiviCase can generate. These reports consolidate activity data for the defined activities. EXAMPLE: For a given type of case, what set of activities should be reviewed by a case supervisor periodically? This set could be defined as your "Monthly Review" report. Activity DataThere is a standard set of data collected whenever a case activity is recorded in CiviCase:
This is sufficient for some types of activities. However it is often useful to collect additional structured data for some types of activities. The "Open Case" (intake) activity is a common example - where you may want to include a set of specific questions about the client and their situation. Create a list of additional (custom data) requirements for each activity type. The list should include the type of data being recorded (free text, multiple choice, date, etc.). Case Roles and Relationships
If no case roles, client relationships, or case resources are defined, then the only person related to the case is the Client. CiviCRM provides relationship type definitions for most of the standard relationships you might track (e.g. Spouse, Child ...). However you will probably need to define additional relationship types for your case roles. Examples include:
Make a list of the expected case roles for each type of case listed above. Then determine which role is generally considered to be the "case manager" for that case type. Configuring CiviCaseAs of CiviCRM 4.5 CiviCase is configured via the user interface. Refer to the Case Management section of the User and Administrator Guide for details.
|
Étiquette
5 commentaires
Afficher/Masquer les commentairesSep 02, 2014
Tim Otten dit :
Re: "...if you have a lot of Activity Types or Case Roles to configure, when you may like to get your consultant or developer to create these using the API."
I'm curious about the circumstance where this is appropriate. When editing a case-type through the GUI, the comboboxes should allow you to select an existing activity-type or enter in a a new one – and any new ones should get auto-created when you save. (The same goes for roles/relationship-types.) Have you tried the auto-create behavior – or are there cases where it's not good enough?
Sep 02, 2014
Joanne Chester dit :
It may not be appropriate at all.
These two pieces of code were included in the User and Admin Guide by the first person who modified the Case Management section for 4.5. The second person to look at it made no comment about the appropriateness or otherwise of the code. Both those people have more experience with CiviCase than do I.
I know it doesn't belong in the book as that is meant for non-coders, but I didn't want to toss it out altogether, so I compromised by adding it to the wiki and referring to it in the book.
If you think it is inappropriate then perhaps it should be ditched totally.
Sep 02, 2014
Graham Mitchell dit :
Wow! Great feature - very well hidden. This functionality is totally non-apparent to the user, speaking as someone who has spent hours working with the new GUI. I've just looked at it again and yes I can create activity types and relationship types on the fly via this interface, but only because I knew I could.
I'll edit the documentation to include some notes about this hidden functionality. Is there any chance we might be able to include something on-screen to give the user an indication that they can do this? The combobox appears simply to provide a drop-down list of available activity types/relationships with a search facility.
When/if the user keys in a name to the search field, as well as the list providing any partial matches from the existing list, the entered string is also presented in a blue bar. Maybe that bar could include the text "create new" or similar as a hint to the user of what's possible?
Sep 02, 2014
Joanne Chester dit :
I agree with Graham, great feature, but not obvious. No need to use the API. I will remove that from the Page. I will leave the rest in case it hold something useful for rewriting the section in the book.
Sep 02, 2014
Graham Mitchell dit :
In fact, looking at the documentation, this means that we can substantially re-jig the Set-up chapter, which currently starts off with a chunk of information about how to create custom activity types and relationships.