Publicat
2008-05-19 13:22
Case management is a central activity for a large number of non-profits and NGO's who are current or prospective users of CiviCRM. Basic support for defining cases as a grouping of activities with a "client" was added to CiviCRM 2.0 through the sponsorship of Frontline Defenders. Subsequently, interest has been growing for adding more comprehensive case management support to CiviCRM. Earlier this year Michelle Murrain of NOSI organized a lively discussion list which allowed folks to share ideas about requirements and use cases.
Andrew Clarke, the Executive Director of The Physician Health Program of British Columbia (PHP-BC) was one of the participants in that discussion. PHP-BC provides "advocacy and support for physicians...who are experiencing problems related to personal and family emotional health issues..." They have been looking to replace their current data management system. Recognizing the potential of an open source solution that could both serve his organization's needs AND those of other human service organizations - Andrew advocated and obtained funding to partner with CiviCRM in designing and developing a CiviCase component.
We are really excited to have an active and engaged partner with both domain and technical expertise (Andrew has prior experience developing a case management system for disability services providers). PHP-BC is also committed to building a tool that can be useful to a wide variety of case management environments. Here's an excerpt from the introduction of their draft requirements document:
Our intention in this document is to try to be fairly general, but also to give examples of how the general features we’re envisioning would be used and applied in the actual practice of case management. One of the problems that case management has suffered from in the past is this mindfulness of generality: everyone seems to think that their notions of “cases” and “case management” are the only ones that could possibly be. As a result, case management systems have been very purpose specific, and not easily adaptable from one type of case to another. We’re explicitly trying to avoid this problem, and to outline first a means to support the most generalizable entities and relationships. Although we may only have the budget to build out fully those features that apply specifically to our immediate needs (in physician health), we want to try to place these into a context that will allow others to build on our work at various levels of generality.
The project will be divided into 3-4 phases. The first phase - which kicked off last week - is a design and feasibility phase. The outcome will be specifications for a feature-set that can be deployed as part of CiviCRM 2.2, and used by PHP-BC staff. Acknowledging the possibility that once the requirements are detailed out, there might not be a reasonable fit with the CiviCRM framework - the other outcome of this phase is a decision about whether to continue the project.
As with other sponsored projects - we will be actively seeking review and feedback from folks who have expertise in this area and are interested in potentially deploying "CiviCase". That said, it will be critical to avoid the "a little something for everyone - but not quite useful for anyone" syndrome. Recognizing that there is a diverse set of human processes, regulations, reporting requirements etc. in this area - our goal is to cast a reasonably wide net while prioritizing the needs of PHP-BC.
All documents related to this project will be posted under the CiviCase Project Home Page on our wiki. You can jump in and read the first (partial) requirements discussion now.
Comments
I've been wanting to contribute to an open-source case management project for some time. So it's just great karma that I happen to be in a job now where I have both a strong need for such a thing, and access to the resources to support its development.
As is probably typical at very early stages of requirements generation, if you tune into the wiki at this point you might find that it's undergoing fairly rapid evolution. At least that's what we hope. We're putting on a conference on May 31st, which may moderate the pace of change in a good way.
We all look forward to review and suggestions from anyone who might think they have an eventual interest in deploying such a system. One measure of success for me personally in developing the requirements will be that folks can envision many local applications of the abstract objects, properties and relationships that we'll be describing. As we get a sense of the comments and suggestions that people are putting forward, we'll try to spotlight ones whose format makes them most useful to the overall effort. For now, though, if you can think of anything, fling it out there!