CiviCRM Community Forums (archive)

Hi,

Conceptually I'm having difficulty understanding your intent.

Is there some security restriction or purpose to have the databases segregated?  In other words is it necessary that certain Contacts be completely separated from others for HIPAA or regulatory reasons?

I'm failing to understand why, if you indeed have a completely different set of Groups to use for certain Contacts, that all the Contacts and Groups cannot live in the same database.

Stuart

Basically i guess, what we are currently doing at the moment is tracking info on the carers, what type of house they have, location, home-life, culture, how far they have progressed through the training and assessment process and are they ready to take on foster children.
Now what the organisation would like to add on is a facility to track the foster children that get referred to them.  Their background, behavioral, emotional issues, why they have come into foster care.
I guess that these two groups require different information recorded about them.  for example if a new contact is being added for a foster child, they wouldn't want to be seeing all the fields for the carers that the foster child wouldn't need and vice verca.  but there will need to be some sort of match-up process between the foster children and the carers.
They don't have to be on different sites, I guess it is just for ease of use for the people that will be using the data base on a day to day basis.

Regards,

John

I think Brian's suggestion of using 2 different contact types is one reasonable approach for now - since that will allow you to establish different sets of custom fields for "carers" vs "foster children".

We will probably be implementing a sub-contact feature for 3.1 which will allow you to do this more "naturally". You would be able to have two sub-contact types under Individual - Carers and Foster Children - and set up distinct custom group fields for each.

A different approach for now would be to use Activities to store the person-type specific info. Something like:
Activity Type 1 = "Foster Carer Info" - and it's custom fields would be career, home-life etc.
Activity Type 2 = "Foster Child Info" - and it's custom fields would be ....

(you could even break up logic chunks of data into multiple activity types)

Viewing / extracting the info if done like this can be a bit more problematic - but you can definitely search on the custom activity fields.

You can try out using organization. Main drawbacks are:
* you'll need to figure out a decent way to store first, middle, last name fields and other demographics that are automatically available for individuals (date of birth, gender, etc.)
* if you need to record relationships like sibling, parent etc. - you'll need to modify or create new relationship types that allow "organization" type contacts to be used (the default relationship types for these relationships are limited to individuals).

... might be a few other gotchas as well - so definitely take some time to work with it before settling on that solution.

No timetable for 3.1 yet. However we expect to start working on contact sub-types in the next month - on a branch - since this is a sponsored project. Stay tuned...

One other approach which really might be best...
* Enter both carers and kids as individuals, but TAG them to make it easy to identify and find only that "group".
* Create custom field group for carers - as a TAB (not inline) set of fields
* Create a second custom field group for kids - also as a tab.

When looking at a give record, staff will see both tabs - but should be able to easily pick the right one to edit or view based on the TAG shown on contact summary screens.