I just wanted to document some discussion around case creation and intake forms, mostly in an attempt to get my head around it.

I think no matter which organization you are when a case is created there's some initial information you need to gather. If we define the term "Questionnaire" to be a generalization of this type of form that could happen at any time during the case, then within civicase we have two choices for how that can be done:

1) Define an activity, e.g. "Intake Questionnaire", and put all the questions on it as custom fields.

2) Define multiple activities, each one containing a single question or group of related questions, and configure them as an Activity Set, e.g. called "Intake Questionnaire".

The advantage to the first one is that it fits in better with most people's concept of filling out a form, where it's all on one page. Custom functionality based on the fields can be put into the associated php file (with possibly a separate config file mapping the custom field names so that you don't hard code the custom field names into the php code). You can search and report on these fields if needed too.

One disadvantage is that suppose you had one of those custom fields configured as an activity as well, for other use. The custom functionality for that activity would need to make a call in the php code for that activity, as well as in the php code for the questionnaire activity. It's not difficult to deal with this, just it might be better not to even have that.

The advantage to the second one is that it fits in with the ideas behind having activities and activity sets, specifically that you can prepopulate a set on the case, which gives the user a pre-built todo list. Or that you can easily define multiple questionnaires and possibly re-use some of the existing questions by just creating another activity set in the config file.

Also I think that the custom functionality required when a case is created is going to be highly dependent on each individual organization, so it seems better to me to use the more granular approach and let them mix and match from some more granular activities, rather than having several separate "intake" forms with their own custom code which might share some code with other intake forms.

Note also that setting the case type is an activity that would often get done as part of the intake questionnaire, near the end of it, which would then prepopulate some more activities (todos), so this reinforces the notion that we need an activity set, rather than custom fields.

The disadvantage is that there is currently no convenient UI within civicrm to allow them to enter the data without individually editing each activity. In the situation where the population has been done because of a set or change of case type, that's fine because they're usually upcoming todos over time. But at intake time it's a bunch all at once.

So one possibility is that there is the case audit/review feature (http://wiki.civicrm.org/confluence/display/CRM/In-depth+case+audit). It could be modified to provide the necessary UI, although it wouldn't be the ideal one. The idea is there would be a default case type that every case gets on creation, and configure that case type to prepopulate the case with the "intake questionnaire" activity set. Then the system could automatically run the review for incomplete activities. Not being familiar enough with civicrm I'm not sure how this would integrate, but one possibility is that the review would pop up in a floating window, and the edit links along the left hand pane of the audit window would link to the main window, so you could click the first one, edit it in the other window, click save, then return to the floating window and click the second one, etc...

Excellent distillation of the essential dilemma we're facing.  I look forward to discussing this in some depth when we get together in person next week in SF.  Just want to clarify that your references to php in the comment above refer to "pre-hypertext processor: a programming language" rather than "Physician Health Program(s)".  Maybe if we mean the computer language we could agree to do as you've done and use php, whereas if we mean Physician Health Programs we could use the all-caps version PHP?