5

We use GUIDs to internally to identify patients in our system. I'm having a debate with our regulatory people on whether these identifiers can be used in query strings to REST calls.

They are claiming any patient identifier becomes PHI once exposed outside of the system. I'm arguing that in order to map this identifier into PHI, you either need access to the data store or you need to have a valid log in to the system and access controls are in place.

For parties not having access to the data store and not having a valid login, the retrieval of PHI is not possible (barring a security breach).

Does anyone have experience with this? Are internally used identifiers considered PHI under HIPAA? Can anyone point me to the appropriate section in the law?

Improve this question

1 Answer 1

Reset to default
4

PHI means having any piece of identifying information linked with any type of clinical data -- e.g. a diagnosis, CPT code, etc.

Therefore, an internal patient identifier on its own is not considered PHI. The release of a simple internal identifier is not a breach, nor is it in violation of any HIPAA regulations I am aware of.

Once that identifier can be used by a non-authorized party to identify the person in question; then we have an issue.

However, best practices would dictate that you secure these identifiers the same way as other data in the database. There may be changes in HIPAA regulations at some point that deprecate this practice. I would either ensure that the REST Query is from a secure, trusted system; or find another way to query this information in order to avoid later compliance headaches.

You can read the full text of the sections I'm interpreting here: https://www.hipaa.com/hipaa-protected-health-information-what-does-phi-include/

Improve this answer
4
  • Thanks! That makes total sense to me. All our requests are made over https to avoid leaking these identifiers to any eavesdropping parties. But there was concern that these identifiers were logged in the browser history and server logs. Proposals were made to change GET requests to POST request just for this reason, which I objected to.
    – MvdD
    Commented Jun 11, 2015 at 22:59
  • 1
    I'm not sure what your process is exactly doing, but interpretations of HIPAA requirements for individual browsers/endpoints certainly vary in that it might be a business associate, or your customer (perhaps a covered entity) who is responsible for compliance on the endpoints. To stave off potential issues, I would recommend adding a layer of encryption to the identifier in the browsers -- perhaps sending only a SHA256 hash in the GET request rather than the actual identifier. Server logs on any server that contains PHI, or can be used to access PHI, should also be secured.
    – Herringbone Cat
    Commented Jun 11, 2015 at 23:29
  • The problem is that encryption in the browser is hard to get secure because you need to keep the encryption key secret. Using hashes is not reversible and making the hash a primary key on the patient table makes the hash itself into a patient identifier.
    – MvdD
    Commented Jun 12, 2015 at 3:12
  • 1
    Developers generally like the full REST implementation and don't want to change a GET request to a POST request when retrieving data. Another "workaround" is to send the GUID in the header.
    – Jeroen
    Commented Jun 12, 2015 at 6:48

You must log in to answer this question.

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