Creating Different Contact Types

General support questions.
Posts: 2
Joined: Mon Dec 15, 2008 12:24 pm
Location: Malta
PostPosted: Mon Dec 15, 2008 12:35 pm
I am using SeedCode Calender Pro to create an Optometric Contact Management Database. The main categories of Contacts are Patients, Corporate Clients, Practioners, Suppliers and practices. I have been struggling with how to create a way to introduce these categories other then the default contact table. So far my idea has been to create seperate tables for the different categories and then duplicate the Contact TO's and link them to the new tables. However I wonder if there is a better way of doings this.
SeedCode Staff
SeedCode Staff
Posts: 2764
Joined: Thu Nov 20, 2003 11:01 am
PostPosted: Tue Dec 16, 2008 5:38 pm
Smart people can certainly disagree on this, but I like to keep all the "people" in the same table. This way they can all take advantage of the things linked to "people": they can be sent mailings, they can be linked to appointments, etc.

Then if some of these people have information requirements that are markedly different from other people, you can create related tables for just the Supplier specific fields, for example. This table would then essentially be a list of suppliers, but the "people" information for each would be in our contact table.

I think having separate tables for each time of person reduces your options more than it expands them.

And note that you can modify our contact selector so that it just shows one type of contact (suppliers, for example) buy looking at how we filter to show just companies.

I hope that helps!
John Sindelar
SeedCode
Posts: 2
Joined: Mon Dec 15, 2008 12:24 pm
Location: Malta
PostPosted: Fri Dec 19, 2008 3:29 am
Thanks For your Reply, John.

Presumably my relationship should therefor be something of the sort:

Contacts=>Patient detail specific table
Contacts=>Practioner detail specific table

and so forth.

My query now is how to link the contacts table to the Patient_Contact table.
Meaning contacts::contactID_kprime=>Patient_Contact::Patient_ContactID_kf

or is there a better way.


As the project evolves I want to attach an EMR module to seedcalendar Pro. So I would have to be able to link my patients to the EMR module but not the suppliers. Without a Patient primary key how would I be able to do that of the general Contactprimary Key?

I was thinking of a way to specify that if the contact is a patient then to link the the contactIDkey with a patientID. However it sounds complicated.
SeedCode Staff
SeedCode Staff
Posts: 2764
Joined: Thu Nov 20, 2003 11:01 am
PostPosted: Fri Dec 19, 2008 9:21 am
JKodurand wrote:My query now is how to link the contacts table to the Patient_Contact table.
Meaning contacts::contactID_kprime=>Patient_Contact::Patient_ContactID_kf

or is there a better way.


That sounds good. If the relationship is solely as you describe above (if there are no other match fields) then any contact with a corresponding patient record would be considered a patient. You could even have a "patient" checkbox on the contact layout that is a boolean field from Patient_Contact table; have "allow creation of related records" turned on and clicking this checkbox would make your Patient_Contact record.

JKodurand wrote:I was thinking of a way to specify that if the contact is a patient then to link the the contactIDkey with a patientID. However it sounds complicated.


Well you can have the "patient" checkbox in the contact table and then your relationship would look like this:

Contacts::contactID_kprime = Patient_Contact::Patient_ContactID_kf
Contacts::contacIsPatient = Patient_Contact::AnumberFieldEqualTo1

Having the is-a-patient attribute IN the contact table does make a couple of things simpler. Since the contact's "patientness" could now be indexed you can more easily filter list of contacts to show those that are just patients.

Hope that helps.
John Sindelar
SeedCode

Return to General Support

Who is online

Users browsing this forum: Google [Bot] and 2 guests

(855) SEEDCODE
[email protected]
Follow us: