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
    Commented Mar 20, 2015 at 20:09
  • @Gray But it's a good opinion and a valid point. :) Commented Mar 21, 2015 at 19:35

2 Answers 2


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.


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. :) Commented Jul 3, 2015 at 0:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .