employee coding for large organizations

Julie Hiland

I have worked with RE for 13+ years, but have only been in healthcare fundraising for about 6 months.  I work for a large healthcare organization that has five hospitals and numerous physician offices throughout the city. We have over 10,000 employees.  For those who work for large organizations, paticularly healthcare organizations or organizations that do employee giving campaigns, can you tell me how you manage employee coding in your database?  Do you code all employees, if so how and when? Do you code specific locations and job titles? How do you keep it updated? I imagine it's a monumental task!



We have so many employee codes and attributes in our database, much of it is MANY years old and not dated in any way, so I'm considering wiping the slate clean, perhaps coding them all as simply "Employee, Current or Former", and just maintaining coding for our executive leadership, as that's really the only segment that we track in terms of percentage that has given.  Otherwise, all gifts through the employee giving campaign are coded, so we can always pull how much employees are giving.  Feedback on this idea?

Patti Hommes, bCRE-PRO

Hi Julie, I was in healthcare for 15+ years. In my last location (9,000+ employees) all employees had their own constituent record, with the Constituent ID the same as the Employee Number assigned by HR. The Constituent Code was Employee, and we used Attributes to further identify the employee. the Atttribute "Employee Type" included, Senior Management, Executive Management, Administration, Nursing Staff etc. The Attribute "Department" told us where they worked, and included the physical location (Medical Records - Philadelphia, Medical Records - Delaware, etc).  The exceptions were Physicians, who had ConsCode of Physician and Attributes of "Physician Type" and "Division" (Surgery, ENT, Oncology, etc.)  Hope this helps!

Gina Gerhard

Here's another possible approach to perhaps consider:

• create organization records for each of the organizational units - so you could create a record for the hospital, records for each branch/department that you wanted, etc.
• Then you can create relationships between these organization records to create a 'hierarchy' and show that they are all linked together.
• Then you create relationships between the employees and the organization record to group them in this manner (versus having codes to categorize them). In your relationship table, you could also optionally develop specific relationship types (Physician, Nurse, etc.) and you can also have additional attributes.

I like this approach because:

• You can just open up the organization record and at a glance see all the relationships (current and former) and drill down to the level you want to look at - and then see the individual relationships.
  • Otherwise, you can create a confusing jumble of coding/categories that's hard to interpret unless you have an instruction manual explaining how you've coded everything. 
  • It's easier for others (who are not data administrators) to make sense of how you have this data structured.
• You can then build your queries based on these relationships:
  • show me everyone who has a relationship to (your specific org record(s) and relationship type one of (Physican, Nurse), etc.
  • con: if you have a lot of these relationships you want to grab, querying may be a bit more involved than if you strictly were using coding and you might have to use more merge queries.

For example, this is how I structured all my State records, with all the governmental departments nested underneath, and sub-departments nested underneath the departments, etc.  and the employees attached by relationships.



 

Marissa Flynn

I also work for a healthcare organization with 5 hospitals and 10,000+ employees. We only use a constituent code "Employee" and their employee ID in the Social Security Number field. This is sufficent data for us to leave them out of direct mailings and upload their Emplopyee Campaign Gifts each year. 



I do not recommend adding additional information such as job title, department, unit, etc. In Healthcare this information changes frequently and often times healthcare workers work in multiple units. If there is no reporting need based on this information, then there is no reason to track it! It would be an incredible task to keep that information updated. I would stay away from this method. 



The only further detail we track is our Executive Team. They have an attribute on their record denoting them as an Executive Team Member because there are specific reports we pull based on that information. 

Julie Hiland

Marissa Flynn:

I also work for a healthcare organization with 5 hospitals and 10,000+ employees. We only use a constituent code "Employee" and their employee ID in the Social Security Number field. This is sufficent data for us to leave them out of direct mailings and upload their Emplopyee Campaign Gifts each year. 



I do not recommend adding additional information such as job title, department, unit, etc. In Healthcare this information changes frequently and often times healthcare workers work in multiple units. If there is no reporting need based on this information, then there is no reason to track it! It would be an incredible task to keep that information updated. I would stay away from this method. 



The only further detail we track is our Executive Team. They have an attribute on their record denoting them as an Executive Team Member because there are specific reports we pull based on that information.

Marisa, I just accepted your Friend Request!  It sounds like you're of the same mindset... if we don't need it for reporting, then there's no need to go to the effort of adding/maintaining it. (I imagine that alone would be a full-time job!)  So two additional questions for you... Do you load in ALL employees, regardless of whether or not they're giving? And do you track when employees leave and then code them as Former Employee?

Marissa Flynn

Julie Hiland:

Marissa Flynn:

I also work for a healthcare organization with 5 hospitals and 10,000+ employees. We only use a constituent code "Employee" and their employee ID in the Social Security Number field. This is sufficent data for us to leave them out of direct mailings and upload their Emplopyee Campaign Gifts each year. 



I do not recommend adding additional information such as job title, department, unit, etc. In Healthcare this information changes frequently and often times healthcare workers work in multiple units. If there is no reporting need based on this information, then there is no reason to track it! It would be an incredible task to keep that information updated. I would stay away from this method. 



The only further detail we track is our Executive Team. They have an attribute on their record denoting them as an Executive Team Member because there are specific reports we pull based on that information.

Marisa, I just accepted your Friend Request!  It sounds like you're of the same mindset... if we don't need it for reporting, then there's no need to go to the effort of adding/maintaining it. (I imagine that alone would be a full-time job!)  So two additional questions for you... Do you load in ALL employees, regardless of whether or not they're giving? And do you track when employees leave and then code them as Former Employee?

 

Thanks for connecting! I figured we are in similar organization so it would be helpful in the future to compare best practices!



We only load employees that give -- whether it be to our campaign, in-kind, or some other means. If they aren't giving, then we don't have a need to house their data in RE. Also to keep in mind, when we all upgrade to RE NXT the pricing is based on number of records. So more records = high price! Good reason to only keep and maintain records that are relevant and nessesary! 



We they leave we just change their constituent code from Employee to Individual. We don't track them as Former, because again there isn't really a need for us. We don't do anything with that data and it was cumbersome to maintain. We only care that they are an Employee because we use that Constituent Code to remove them from mailing & solicitations (we only solicit once per year during our campaign). We use a different system for our employee campaign so the other details and data come from that system or Payroll.

Teri Plemel

I work for a health system that is a similar size. We only add employees who give (whether through payroll deduction, gift-in-kind, or outright gifts) or if they are on a committee or board that we track. The exception is physicians, we include all physicians regardless of giving status due to the number of events that we invite them to. 



We code current and former constituent codes for physicians and employees. We also link their constituent records to their current organization very much in the manner that Gina described.

Julie Hiland

Patti Hommes:

Hi Julie, I was in healthcare for 15+ years. In my last location (9,000+ employees) all employees had their own constituent record, with the Constituent ID the same as the Employee Number assigned by HR. The Constituent Code was Employee, and we used Attributes to further identify the employee. the Atttribute "Employee Type" included, Senior Management, Executive Management, Administration, Nursing Staff etc. The Attribute "Department" told us where they worked, and included the physical location (Medical Records - Philadelphia, Medical Records - Delaware, etc).  The exceptions were Physicians, who had ConsCode of Physician and Attributes of "Physician Type" and "Division" (Surgery, ENT, Oncology, etc.)  Hope this helps!

Patti, can you tell me how you identified employees whose employment had been terminated? Did you switch the constituent code to "Former Employee", or did you add a "To" date onto your "Employee" code?  How did you manage all of that data, and how often? Do you use ImportOmatic? 



If anyone has any documentation on how to manage this coding, I'd LOVE to see it. julie.hiland@piedmont.org  Thanks!!

Julie Hiland

 

Julie Hiland

Teri Plemel:

I work for a health system that is a similar size. We only add employees who give (whether through payroll deduction, gift-in-kind, or outright gifts) or if they are on a committee or board that we track. The exception is physicians, we include all physicians regardless of giving status due to the number of events that we invite them to. 



We code current and former constituent codes for physicians and employees. We also link their constituent records to their current organization very much in the manner that Gina described.

Teri, can you tell me HOW you update your records in this manner? We have ImportOmatic, but I'm very new to the tool. Do you have any documented processes you could share? Particularly identifying/changing physicians and employees to "former".  julie.hiland@piedmont.org  Thank you!!

Margaret Whitaker

I, too, work at in the Foundation of a fairly large healthcare system.  We record employees only if they have given, or are connected to a committee or board.  They are coded in Constituent Attributes as Employee, Current until they leave and at that time if we are made aware of the change they are coded as Employee, Retired or Employee, Former.  Physicians are coded as a Constituent Attribute also using the same Descriptions as the Employees except preceded by Physician.  The ind. physician personal record is linked as a Relationship to the physician practice constituent record. 



We have purchased IOM and have yet to undergo training for the product.  I would also love to get information on how you set up your initial Bio info, pledge schedule etc.  my email is mswhitaker@novanthealth.org



Thanks!!!

Amelia Ketzle

Gina Gerhard:

Here's another possible approach to perhaps consider:

• create organization records for each of the organizational units - so you could create a record for the hospital, records for each branch/department that you wanted, etc.
• Then you can create relationships between these organization records to create a 'hierarchy' and show that they are all linked together.
• Then you create relationships between the employees and the organization record to group them in this manner (versus having codes to categorize them). In your relationship table, you could also optionally develop specific relationship types (Physician, Nurse, etc.) and you can also have additional attributes.

I like this approach because:

• You can just open up the organization record and at a glance see all the relationships (current and former) and drill down to the level you want to look at - and then see the individual relationships.
  • Otherwise, you can create a confusing jumble of coding/categories that's hard to interpret unless you have an instruction manual explaining how you've coded everything. 
  • It's easier for others (who are not data administrators) to make sense of how you have this data structured.
• You can then build your queries based on these relationships:
  • show me everyone who has a relationship to (your specific org record(s) and relationship type one of (Physican, Nurse), etc.
  • con: if you have a lot of these relationships you want to grab, querying may be a bit more involved than if you strictly were using coding and you might have to use more merge queries.

For example, this is how I structured all my State records, with all the governmental departments nested underneath, and sub-departments nested underneath the departments, etc.  and the employees attached by relationships.


 

 

Hi, Gina - 


Can you share more about how you report on employees of the parent company under this structure?  In some instances, we need to be able to report # of employees at a given branch, but we may also want to roll this up into # of employees at the overall company.  Is this tricky in RENXT?


Also, how have you handled mergers/acquisitions/branch sales/name changes, etc.?  We have found this to be very difficult to reflect accurately in our present database (we are on Ellucian Advance and moving to RENXT).  Not only is it impossible to keep up with all these changes, but due to conflicting needs for the existing records, it isn't always possible to change the primary name, for example, or fit a newly acquired branch (with a previously existing record, complete with gift credit and all kinds of other specific data) under its new parent company.  


If you have any tips or procedures either about how you have handled this generally in terms of records management, or about how RENXT specifically can be leveraged for these needs, I'd be very appreciative!

Sunshine Reinken Watson

Our org has 5,000+ employees, and we are currently required to report on employee giving and other participation by department. Employees who give, attend events, or volunteer with the foundation have records. We use importacular and a series of global changes to update employee data based on employee and term lists. We record the employee number in the SSN field. This is, indeed, a time-consuming task (especially the first time it is set up). I estimate that the updates take one staff member 2-3 full business days twice a year.