HRMS Benefits Data: Sensitivity and Security
Have you implemented HRMS benefits management? Are you keeping benefits data in your HR system? While there are advantages to storing this data for employee spend analysis as well as centralizing it for interfaces to vendors, there are dangers too. If you are considering adding benefits data to your HRMS or are already storing it, here are some things to keep in mind.
Benefits data, or data needed to support benefits processes, can include employee enrollment in medical, dental, life insurance or similar plans. As well, it comprises sensitive data needed to identify the employee, such as social security number and date of birth. It usually requires demographic details like the employee’s full name and home address. If a health plan includes dependents, similar data will be required from the dependents. Such a collection of data tied to an employee can become very interesting for those with malicious intent and can become a target for those seeking to perform identify theft.
Acts & Access
From a legal standpoint, benefits data is covered under its own set of US federal legislation: The Health Insurance Portability and Accountability Act of 1996 (HIPAA) and the Health Information Technology for Economic and Clinical Health Act (HITECH Act). While these acts have various provisions, from an HRMS perspective it’s important to understand that HIPAA supports the use of electronic data interchange as well as controlling the use and release of Protected Health Information (PHI) held by "covered entities," including employer sponsored health plans. HITECH imposes notification requirements if a breach of unsecured PHI occurs, such as if an employer’s HRMS with benefits data is hacked.
It is healthy to review your outgoing interfaces annually. Question your vendors to confirm that the data on your interfaces is truly needed for their processes.
So your HRMS plays an important role in storing this data, but it *requires guardrails in place to protect the data from harm. One of the first things to consider is if you have a business reason to store the data that you are keeping. If none of your vendors or business processes use a dependent’s social security number, then it’s best not to store the data in the first place. On a similar note, it is healthy to review your outgoing interfaces annually. Question your vendors to confirm that the data on your interfaces is truly needed for their processes. If not, remove it from the interface files. Finally, consider carefully who has access to this data via user security. If an HR person is not using this data in operational work, then best practice is to remove the access.
Benefits data can be a minefield, but if you keep it secure, holding it will provide business advantages. Keep on top of the latest and greatest benefits functionality with the HRMS Software Guide.
Featured white papers
5 ways HRMS helps you get more out of your HR data
A comprehensive guide to the data analytics capabilities of your HRMSDownload
Four HRMS data sets that can boost recruiting analytics
Improve your recruiting using these four HRMS data sets
HR analytics and the GDPR: where things stand
How does General Data Protection Regulation impact your HR analytics?
Minimize stress during open enrollment with these benefits management tips
Is your HRMS’ benefits management module ready for open enrollment? It’s never too early to start...