2

Table 1 has PHI and it's encrypted. Table 2 doesn't have PHI, isn't encrypted and has a foreign key to Table 1.

I'd like to recommend the strongest security. If there's a requirement in HIPAA, it's not optional and must be done. If it's part of a standards body like ISO/IEC 27001 then it will need to be done for compliance to that standard. If it's a best a practice, it would be ideal but difficult to persuade for a best practice vs the performance impact.

1) Does HIPAA have any requirements for the foreign key to Table 1 in Table 2?
2) Is there a standard like ISO/IEC 27001 that has a requirement for the foreign key to Table 1 in Table 2?
3) Is there a best practice or anything similar that covers the foreign key to Table 1 in Table 2?

  • Eventually you will have a FK that links to a FK that links to a FK. I don't know HIPAA, and legal advice is off-topic, but it sounds like if you are using a relational database, eventually, you'll need to establish a relationship with private data. As long as that data is encrypted, I think you are ok. If you try to obscure it, it doesn't make it more secure, just more confusing. (Disclaimer: opinion) – Gray Mar 20 '15 at 20:09
  • @Gray But it's a good opinion and a valid point. :) – Paraplastic2 Mar 21 '15 at 19:35
1

To answer your question according to the points:

1) In a pure sense, no. PHI means identifiable patient information (e.g. a name, an address, a social security number, etc) combined with clinical data (e.g. a diagnosis, CPT code, test result etc). A foreign key in and of itself is not PHI.

2) Not that I am aware of for HIPAA -- HIPAA is more of general guidelines than clear, distinct standards.

3) Yes! If it makes you worried that the release of any particular data might cause problems for your company, your customers, or especially trigger HIPAA breach notifications: encrypt it! With HIPAA, it's always best to err on the side of encryption. If properly encrypted data is compromised, this does not trigger reporting requirements; which can be a life saver for a company -- especially a small one.

0

Disclaimer: I only have a baseline understanding of HIPAA.

I would think that as long as the encrypted data is not accessible in an unencrypted form, through the foreign key then it's acceptable. Provided your foreign key is an ID of some sort that's unrelated to the specific PHI the key would not need to be encrypted.

  • 1
    The foreign key is an ID linking the 2 tables. To get to the PHI in table 1, it would have to be decrypted which can't be done with only the foreign key. It's nice to have more confirmation. :) – Paraplastic2 Jul 3 '15 at 0:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.