Here is an update of where we are heading, let me know if anyone sees any problems/issues:

OPTIMAL: 

We would have loved to have used the Contact and Account objectsto represent key people/businesses in our system.  Here is the example:

People:  Pharmacists, Pharmacy Technician, Doctors, Nurses,Internal Employees, Referral Employees (Insurance companies)

Business:  Hospitals, Medical Groups, Pharmacies, InsuranceCompanies, Nursing Agencies, etc

It would have been great to make each of these record types of Contactand Account, and then have separate page layouts and custom fields.

PROBLEMS:

Problem #1:  Lookup fields show all of theContact/Accounts. 

This means that when I want to link a “Visit” to a Doctor, theuser gets a list of all people.  This is not acceptable.  That meansthat the standard lookup control on both Page layouts and Visual Force pagescould not be used.  We would have to develop our own.

Problem #2: Tabs on Applications  

We have different “Apps” that each represent a different users’sview of the system.  Some users would need a Tab for “Nurses”, some for“Doctors”, and so on.  There are even cases where we would need a few ofthese tabs on the same app.   However, the “Contact” Tab can only beadded to an APP once, and we can not have it show up with different identities(Nurses, Doctors, Pharmacists)

OPTIONS:

Option #1:  Pure Record Types, shared Accounts/Contacts

This is currently not a viable option due to the limitationsabove.

Option #2:  Pure Custom objects.

All of these objects would be custom SObjects.  This wouldsolve the problems above.  However, it would defeat a lot of the out thebox CRM functionality that would have been empowered by storing the data in theAccounts/Contacts.  Also, we would be duplicating a lot of data structuresand functionality that comes build in on the Account/Contactobjects.   We would be locked in to this and not be able to changewithout significant modifications to the data model.

Option #3:  Hybrid, light custom objects, links to Contact/Account

This would create light custom objects, that link to therespective Contact/Account objects.

·        The Lookups would work cleanly.

·        We can create Tabs for the custom objects.

·        To enable some of the nice features such as filtering that donot follow the reference field, we would add “Formula fields” to the customobjects that gave read only access to some of the fields on theAccount/Contact.

·        We would need to build Custom Visual Force pages for theobjects, (one for view, one for new/edit).  These would handle the linkingto the Account/Contact. 

·        I am designing shared Components for Acccount and Contact fieldsthat can be placed on the custom View/Edit pages.  This way we would onlyneed to maintain the layouts (in the Component) in a couple of places, and havethe encapsulating pages (Nurse, Doctor, Pharmacist), contain the components,and just add the extra fields (nursing only, for example)

·        This would limit the use to standard, Force.com page layouts,instead we would utilize Visual Force.

I am still pondering where toput the “custom fields” for each area (Nursing fields, Pharmacy fields, Doctorfields).  They make most sense on the Custom objects.  However, downthe road if Force.com enhances the use of Account/Contact, then these would needto be moved.

We may still want to add ourown custom Lookups if we want to have our own filtering (only show Nurses thatare in the area (state, city, or attached to some office).  This wouldhave been a great set of functionality to add to Force.com.

If anyone has tried something similar, let me know how it worked out.

Steve