Constituent Coding in a healthcare system

Stephanie Roland

Our hospital recently merged with a larger healthcare system. Our foundation is separate and we are interested in how other foundation's code employees that are part of a system. So some of our donors who are employees, moved to other hospitals within the system or they moved to the corporate office. In our current set up, we have a constituent code for employees, called "Employee". Each employee also receives 2 attributes, 1 to indicate their department and 1 to indicate the type of employee they are (physician, director, etc). Now we are considering adding a location attribute to designate what hospital they are working at, or if it's the corporate office. Before we do that, we wanted to see what others might be doing.

Tracie Cassidy

Stephanie Roland:
Our hospital recently merged with a larger healthcare system. Our foundation is separate and we are interested in how other foundation's code employees that are part of a system. So some of our donors who are employees, moved to other hospitals within the system or they moved to the corporate office. In our current set up, we have a constituent code for employees, called "Employee". Each employee also receives 2 attributes, 1 to indicate their department and 1 to indicate the type of employee they are (physician, director, etc). Now we are considering adding a location attribute to designate what hospital they are working at, or if it's the corporate office. Before we do that, we wanted to see what others might be doing.

Stephanie - We currently do what you're doing. My suggestion would be adding the location in the Cons Code; so it would be: LocationA-Employee, LocationB-Employee, etc.

 

Stephanie Roland

Tracie Cassidy:

Stephanie - We currently do what you're doing. My suggestion would be adding the location in the Cons Code; so it would be: LocationA-Employee, LocationB-Employee, etc.

 

Thanks Tracie, The more I think about it, I like your suggestion. Having it as a Constituent Code vs. Attribute will give us a better way to track dates. So we can track employees who were with us before the merger and then moved to another hospital post-merger. Attributes don't really allow for that. I'll run some test reports to see how that might look. Stephanie

Melissa Graves 2

Stephanie Roland:
Our hospital recently merged with a larger healthcare system. Our foundation is separate and we are interested in how other foundation's code employees that are part of a system. So some of our donors who are employees, moved to other hospitals within the system or they moved to the corporate office. In our current set up, we have a constituent code for employees, called "Employee". Each employee also receives 2 attributes, 1 to indicate their department and 1 to indicate the type of employee they are (physician, director, etc). Now we are considering adding a location attribute to designate what hospital they are working at, or if it's the corporate office. Before we do that, we wanted to see what others might be doing.

I would not put location into Constituent Code.

Why not simply manage nearly ALL of this via relationships. I think an employee cons code makes sense but everything else can go into a relationship. A relationship to the overall org with the address indicating location or having separate org records for the different locations is up to you. But you can put in their employee type into the profession drop down, include their actual title into position, even. People who move to another location just get a date from and to filled in on the old relationship and then get a new relationship indicating the new location, etc. This makes much more sense to me than cons code - your centralizing all of the information you know about them into one place - relationships - it is not spread amongst cons code, attributes, etc.

Stephanie Roland

Melissa Graves:

I would not put location into Constituent Code.

Why not simply manage nearly ALL of this via relationships. I think an employee cons code makes sense but everything else can go into a relationship. A relationship to the overall org with the address indicating location or having separate org records for the different locations is up to you. But you can put in their employee type into the profession drop down, include their actual title into position, even. People who move to another location just get a date from and to filled in on the old relationship and then get a new relationship indicating the new location, etc. This makes much more sense to me than cons code - your centralizing all of the information you know about them into one place - relationships - it is not spread amongst cons code, attributes, etc.

Yes, that makes sense and we are using Relationships to record much of this information. The challenge comes when it's time to query and/or report on employee solicitation and giving. I think may be the barrier for us to use Relationships, since that is not a category available to filter by in Mail and Reports. Thanks everyone.

Gina Gerhard

Stephanie Roland:
Yes, that makes sense and we are using Relationships to record much of this information. The challenge comes when it's time to query and/or report on employee solicitation and giving. I think may be the barrier for us to use Relationships, since that is not a category available to filter by in Mail and Reports. Thanks everyone.

In Mail and Reports, your "filter" might be the query that you choose to pull in -- the query would be pulling specific groups based on the relationships, and then you choose the query to run your mail or report.

Patti Posey

Stephanie Roland:
Our hospital recently merged with a larger healthcare system. Our foundation is separate and we are interested in how other foundation's code employees that are part of a system. So some of our donors who are employees, moved to other hospitals within the system or they moved to the corporate office. In our current set up, we have a constituent code for employees, called "Employee". Each employee also receives 2 attributes, 1 to indicate their department and 1 to indicate the type of employee they are (physician, director, etc). Now we are considering adding a location attribute to designate what hospital they are working at, or if it's the corporate office. Before we do that, we wanted to see what others might be doing.

Hi Stephanie:

 We have physicians and staff all over too.  What I did was create two constituent codes -  Physician and Staff.  Then I use attributes to track their department and their location.  Employee Department/Physician Department, Employee Location/Physician Location.  I also includ the Physician Status (on staff, active, courtesy, etc) because we do a lot of segmentation with our docs so we may not solicit doc swho only has courtesy rights to our hospital.  Or we may just want to send to docs who are employed by the hospital.  So breaking out their status really helps us.  Hope this helps.