Through field-level encryption and other data-centric protection functions in IRI's FieldShield and CoSort (SortCL) products (or Voracity platform), you can now de-identify protected health information (PHI) subject to HIPAA regulations, which include 45 CFR 164.312 and 170.210 (requiring encryption, hashing, etc.).
45 CFR 164.312, Technical Safeguards
Implement technical policies and procedures to limit EPHI access to only "those persons or software programs that have been granted access rights. These systems must allow for unique user identification, emergency access, automatic logoff, and encryption and decryption.
With field-level control, you can use multiple encryption libraries and pass phrases for field-specific need-to-know decryption entitlements.
* Transmission security, including two addressable specifications:
- Integrity controls -- security measures to ensure that electronically-transmitted PHI is not improperly modified without detection until disposed of, and
- Encryption. Designation of encryption as an addressable specification is a key departure from the proposed rule, which explicitly required encryption when using open networks. Covered entities now must determine how to protect EPHI "in a manner commensurate with the associated risk." Covered entities are encouraged in the Rule's preamble to consider use of encryption technology for transmitting EPHI, particularly over the Internet. The key reasons cited by HHS for this change are the cost burden for small providers and the current lack of a simple and interoperable solution for email encryption.
FieldShield makes encryption another option for field-level protection within tables and files, along with filtering, anonymization, and pseudonymization. CoSort's SortCL program does as well, while running high volume manipulations and reports against massive data sources.
* Hardware, software, and/or procedural methods for providing audit controls
Optional application statistics, and a query-ready XML audit log, record the job script and encryption libraries used to show what, when, how, and by whom the PHI field data was encrypted (and otherwise protected and/or transformed).
* Policies and procedures to protect EPHI from improper alteration or destruction to ensure data integrity. This integrity standard is coupled with one addressable implementation specification for a mechanism to corroborate that EPHI has not been altered or destroyed in an unauthorized manner.
Data that does not decrypt with the proper encryption key suggests that the decrypted field has been compromised. You can trace this through FieldShield or SortCL runtime statistics and audit logs. You can see when and how the file was processed for field encryption.
* Person or entity authentication, which requires the covered entity to implement procedures that verify that a person or entity seeking access to EPHI is the one claimed to be doing so.