Creating or purchasing a HIPAA compliant database involves many different HIPAA compliance elements. If you’re a developer whose products use personal health data, and you’re doing business in the US, you must use databases that are fully compliant with HIPAA, the major US law protecting the privacy and security of health data. But just what is a HIPAA Compliant Database, and what makes a database compliant with HIPAA?
Since the latest updates to HIPAA from the HITECH Act, health-related businesses that process, store, transmit, or receive health data are considered “Business Associates” (BAs) under HIPAA. Health-related apps process, transmit and receive “protected health information”, or PHI, as HIPAA defines it. When a digital health app contains or processes PHI, the app developer and all its databases, servers and other system elements must be fully compliant with HIPAA. Health app developers, like other HIPAA Business Associates, must meet all of HIPAA’s compliance requirements — including the use of a HIPAA compliant database.
For a health app developer to be able to claim full HIPAA compliance, the developer must have implemented everything operationally that HIPAA Rules and Regulations require. These include a number of very specific administrative, physical and technical safeguards. The vendor must also be able to document their compliance to third parties, such as customers like you, or the HIPAA enforcement agency, the HHS Office for Civil Rights (OCR).
For a truly HIPAA compliant database, HIPAA’s requirements can be achieved with careful planning and configuration. Here are the requirements for a HIPAA-compliant database:
- Complete Data Encryption — All health data is encrypted while in the database and during transit. This includes data at rest in the file system, data moving from the application layer to the database layer or among database components. Encryption must ensure that a malicious party cannot bypass the database controls and access information directly.
- Proper Encryption Key Management — including keys, initialization vectors, and HMAC keys.
- Data Stores — If applicable, any subsystems that store encrypted BLOBs should have no ‘knowledge’ of what is being stored.
- Unique User IDs — HIPAA requires unique user IDs for all users and prohibits the sharing of user login credentials.
- Authentication — A database must securely authenticate users who will have access to PHI.
- Authorization — The database must control access to PHI by assigning differing — and appropriate — roles and privileges to users.
- Audit Logs — All data usage (user logins, reads, writes and edits) must be logged in a separate infrastructure and archived according to HIPAA requirements. Generally, this means at least six years.
- Database Backups — Must be created, tested and securely stored. All database backups must themselves be fully encrypted. Note that, under current HIPAA Rules, data that has been properly encrypted does nottrigger mandatory Breach Reporting if the data is stolen or compromised.
- Dedicated Infrastructure — All HIPAA compliant databases must reside in a high-security infrastructure that is itself fully HIPAA compliant.
- HIPAA-Trained Support Personnel — Technical support for issues involving PHI is provided by personnel trained on HIPAA.
- Automatic Updates — Regular software upgrades to ensure that software is always running the latest and best tech available.
- Data Disposal — Methods must be in place or available to ensure that data and media are disposed of securely when no longer needed. High-security file wiping, according to current NIST standards, is a must.
- Business Associate Agreements (BAAs) — These are a specific type of legal contract that must be in place between parties that use, transmit, receive, or exchange PHI. Developers note: BAAs must be in place between parties who share PHI before any PHI is received or shared.
While the points above outline the technical requirements for a HIPAA compliant database, HIPAA also requires developers and database admins to follow a policy of Data Minimization. This is a general HIPAA concept that states that only the “minimum necessary” health data actually needed for any particular purpose should be used. For example, if a developer or technician needs to access actual PHI (not anonymized or dummy data) for testing, configuration, or repair purposes, the least amount of PHI that is necessary to accomplish the task must be used in every case.
And finally, every HIPAA compliant database must generally support the primary goals of the HIPAA Security Rule, which is to “ensure the confidentiality, integrity, and availability of PHI that it creates, receives, maintains, or transmits.” According to the definitions in the HIPAA Security Rule at §164.304, these terms have the following meanings:
- Confidentiality is “the property that data or information is not made available or disclosed to unauthorized persons or processes.”
- Integrity is “the property that data or information have not been altered or destroyed in an unauthorized manner.”
- Availability is “the property that data or information is accessible and useable upon demand by an authorized person.”
As a developer, you must be certain you are using a HIPAA compliant database for all PHI. Your overall HIPAA compliance cannot be achieved without this.
Was this article helpful? Check out Tip #3 on HIPAA enforcement, or subscribe to MedStack to get tips delivered straight to your inbox.
