The US Health insurance Portability and Accountability Act or (HIPAA) was passed in 1996 and Health Information Technology for Economic and Clinical Health (HITECH) Act was passed in 2009 as part of American Recovery and Reinvestment Act(ARRA). The HIPAA legislation requires that covered entities implement technical safeguards to protect all electronic Personal Healthcare Information or PHI whereas the HITECH Act mandates that a successful breach of “unprotected” ePHI must be publicly disclosed. Furthermore, the HIPAA Omnibus Rule holds business associates liable for non-compliance.
According to recent reports over $1B in revenue is attributable to ransomware in 2016. 25% of healthcare entities utilizing the public cloud are not encrypting their data. 38% of those surveyed have data spread across multi-cloud environments. Approximately 50% of enterprises have experienced at least 1 breach while exchanging files with their partner in the last 2 years according to the Office of Civil Rights’s June 2016 newsletter. At the same time the HIPAA Act requires covered entities to provide public notification upon discovery of a breach of their unsecured electronic Patient Health Information involving more than 500 records. Loss of PHI can result in significant erosion in brand equity. Given these dire consequences of a successful breach, covered entities are faced with a fundamental question when it comes to data security – how to protect regulated data and how to regulate access to it. Even if you are using a HIPAA compliant cloud provider the ultimate responsibility of securing your PHI lies with you.
The HIPAA Security Rule applies to electronic Protected Health Information (PHI). The covered entity is defined as an entity who creates or receives or manages or transmits PHI and is responsible for maintaining privacy. The loss of PHI can result in fines and may expose the covered entity to a barrage of legal issues. However, protecting PHI is not enough. You also have to prove it that your PHI is in fact protected which is a much harder problem to solve as it gets into generating tamper-resistant logs.
When a customer decides to use their cloud vendor’s data-at-rest encryption offering then it becomes virtually impossible for the customer to switch their cloud vendor without spending a significant amount of time and effort. It is because the encrypted PHI must be decrypted first.
Let’s look at some of the challenges associated with a move:
Is your disk partition large enough to decrypt your data set before the move?
Where will you store your PHI during transition?
How will you secure your PHI during transition?
Will you be violating your business partner agreement?
Does data-at-rest encryption offered by the new vendor require you to make changes to your application, process or procedures?
How long will it take to encrypt your PHI again?
How will the change impact your cost?
Of course this issue can be mitigated by not using the data-at-rest encryption offering of your cloud platform provider but instead going with a neutral third party solution that works with all cloud platforms.
If you are representing one of our partners, please log into your account to access hidden resources or request an invitation to sign up for the account.
.png)
Want to be notificated about new features and updates? Enter your email adress and name below to be the first to know.
Don't worry! You will not be spammed!
.png)
.png)