We spend a lot of time talking about security these days. And right so. Data breaches can be costly for everyone involved. We’re not just talking financial costs either, although those can mount quickly.
Industries that deal with sensitive customer data on a daily basis need to ensure that the people and companies creating and using that data do so securely. Two of the most common security standards are HIPAA and PCI-DSS.
In the U.S., healthcare entities must comply with HIPAA standards for patient data. Interestingly, there is no formal certificate that HIPAA-compliant companies can obtain.
The other area where security is a major concern is with financial data. The Payment Card Industry created their own data security standard (hence PCI-DSS) to ensure that any company that processes credit card payments does so securely. A PCI certification does exist that validates companies based on the volume of transactions they do annually. These range from level 1 (the highest volume) to level 4 (the lowest).
When it comes to HIPAA a lot depends on the type of data you have and who has access to it. If you’re new to HIPAA here are some things to keep in mind when thinking about the compliance process. Of course, be sure to run any HIPAA questions by your compliance department before making any final decisions about compliance.
Covered Entity or Business Associate
If you are creating software for use in healthcare it’s important to understand where you stand under the HIPAA umbrella. Covered entities include healthcare providers (like doctors), health plans, or healthcare clearinghouses. Basically, these are any entity that needs access to patient data.
The Department of Health & Human Services defines a business associate as “… a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity.” So if you’re doing accounting, processing payments, or performing legal or other services for a covered entity then you’d fall into this category.
PHI or CHI?
Regardless of whether your application or service is a covered entity or a business associate, you need to know what type of data you’ll be dealing with. No, PHI and CHI aren’t a callback to college Greek life. We’re talking about Protected Health Information (PHI) and Consumer Health Information (CHI).
PHI is pretty straightforward. It constitutes any health-related data that gets shared with a covered entity. These are the types of things we typically think of making up our medical records: medical history, test results, diagnoses, prescriptions, account balances, etc. Your application or service must be HIPAA-compliant if you deal with PHI.
CHI is any data that doesn’t get shared with a covered entity. Think about your FitBit or any other type of health monitoring apps on your phone. These can track different health metrics, but that data isn’t considered protected health information, nor is it transmitted to a covered entity. In this case, you don’t need to worry about HIPAA compliance.
People, Hardware, & Software
We can breakdown HIPAA compliance in three major sections.
It’s critical that employees, the people who actually manage and interact with this data, know how to keep it secure. The administrative aspects of HIPAA compliance deals with the policies and procedures that go into training employees to properly handle PHI. This includes having the right management and oversight tactics in place.
This aspect of HIPAA compliance isn’t just about the rack servers and other hardware you use, but how they’re physically secured, whether they have appropriate redundancy, and who has access to them.
It makes a lot of sense to ensure that your people and plant meet HIPAA compliance before going too far down the software rabbit hold. When the time to focus on software compliance occurs, it needs to store, encrypt, and decrypt data according to HIPAA guidelines, provide audit controls, and enable access in emergency situations, among other items.
The major credit card companies in the U.S. got together and agreed on a set of security measures that are consistent across the industry. If you process payments or financial information there’s a good chance that you need to be PCI-compliant.
PCI employs a continuous three-step process to achieve and maintain security compliance. The first step is to assess your current payment processes and system security. The next step is to fix any errors that emerge through that evaluation process. The third and final step is compile and submit reports to the proper banks and card companies.
Like HIPAA, PCI compliance requires a secure environment and stringent access to the data stored within it. PCI established twelve different requirements around these principles for the purpose of meeting six different goals.
The Payment Card Industry has trained and validated assessors who audit payment processes and systems. These assessors work with companies to achieve compliances with the industry security standards.
Other Avenues to Compliance
A lot goes into building and certifying a system as either HIPAA- or PCI-compliant. Companies that are in need of technical compliance stand to spend considerable resources, both in terms of time and funding, on technology, audits, and other aspects of the process.
However, there’s no rule that says companies have to possess a secure environment. Rather, their data simply needs to be secured and protected. Therefore, it’s possible for companies to build technology on another company’s compliant platform and to gain the benefit of compliance for themselves.