14

I have been asked by a client to deidentify the PHI data in their database and I'm either over-simplifying the process or my client is overly paranoid. Perhaps you can tell me which is the case.

This client's need for de-identification is two-fold. When they lose a client they have the right to keep a deidentified copy of the data for analytical purposes. Also, they need to be able to move the data to dev/test environments in a deidentified form.

Here's an example of what would be in the database:
First Name
Last Name
Gender
Birthdate
Facility
Admission Date
Discharge Date
Admission Score
Discharge Score

This data is used for analysis and some of the important factors are:
Gender
Age at admission (Admission Date - Birthdate)
Length of stay (Discharge Date - Admission Date)
Improvement (Discharge Score - Admission Score)

Here are my questions...

If I simply randomize the names, is this not deidentified enough to satisfy HIPAA requirements?

I didn't think so. What if I also randomize the Facility name? If I only know the other pieces of information, birthdate, gender, dates, and scores, has this been reasonably deidentified?

Ok, assuming the answer is no, what if I then choose a random birthdate and adjust the admission and discharge dates so that age at admission and length of stay are still the same? For example, if the patient was born on 1/1/1930 and was admitted on 1/1/2011 and discharged on 1/10/2011 the birthdate could be randomly chosen as 5/5/1920 and the other dates would be 5/5/2001 and 5/14/2001. The age at admission and length of stay would be the same. Would this be reasonably deidentified?

Also, one other question. If the client has a list of patients with their birthdates in an excel spreadsheet (no other information), would that data be considered PHI? My client says yes, but that doesn't make sense because no medical information is tied to those names.

Thanks for your input!

Darvis

3 Answers 3

7

I genuinely don't think we have enough information - and it sounds like you don't either - on what exactly your client wants. Part of your problem is not just deidentification, but deidentification that maintains the data's usefulness. The second part is as tricky as the first.

Ok, assuming the answer is no, what if I then choose a random birthdate and adjust the admission and discharge dates so that age at admission and length of stay are still the same? For example, if the patient was born on 1/1/1930 and was admitted on 1/1/2011 and discharged on 1/10/2011 the birthdate could be randomly chosen as 5/5/1920 and the other dates would be 5/5/2001 and 5/14/2001. The age at admission and length of stay would be the same. Would this be reasonably deidentified?

For example, this solution, while it might technically have changed the PHI so it cannot be tracked back to a particular individual, has ruined any and all time related usefulness of the data that isn't just the difference between the admission and discharge date. An analysis of the data could not, for example, adjust for what season of the year the admission was in (important for many diseases) or even what year the admission was in (important for all kinds of things).

Also, one other question. If the client has a list of patients with their birthdates in an excel spreadsheet (no other information), would that data be considered PHI? My client says yes, but that doesn't make sense because no medical information is tied to those names.

We don't know who your client is, but considering the site you're asking this on, the answer is absolutely yes. The existence of these records implies certain medical information. Consider three circumstances, of varying risk to the patient if exposed:

  1. Patent X is on Clinic Y's list. They must have gone there.
  2. Patient X is on Clinic Y's list. That clinic does STI screening. I wonder what they were up to?
  3. Patient X is on Clinic Y's list. That clinic is helping administer an HIV prevalence study among high-risk sex workers in the area. Isn't that interesting...

All of those could be assembled with nothing more than a name and birthdate, and the existence of the list itself. "Shows up on in a healthcare provider's records" is medical information.

4

The way we read the current HIPAA/HITECH is that two pieces of information is considered PHI and needs to be protected.

So yes, the spread sheet with fname,lname and DoB is totally PHI and should be protected. Just because there isn't claim data doesn't make it non-PHI data.

That said, we have our data "encrypted at rest" with Transparent Data Encryption using SQL2008R2. That is enough the company has decided to cover us for HIPAA/HITECH. We sanitize the data for testing, but not in production.

4
  • What do you mean by sanitize? This client's need for de-identification is two-fold. When they lose a client they have the right to keep a deidentified copy of the data for analytical purposes. Also, they need to be able to move the data to dev/test environments in a deidentified form. I have updated my original post with this same info.
    – Darvis
    Nov 22, 2011 at 16:17
  • By sanitize, I mean to remove the actual values and replace with junk. For example, actual record: lname=smith, fname=john; test record: lname=Verlander, fname=Justin. See also: healthcareit.stackexchange.com/questions/159/… However leaving just the DoB shouldn't be PHI by it's lonesome, as you can't discover an single individual from that data alone. Nov 22, 2011 at 16:39
  • 1
    So why is a spreadsheet with names and birthdates considered PHI if it is not attached to any medical data? What if it was just a list of names, would that also be considered PHI? Perhaps this should be a separate question. If so, I'll be glad to ask it.
    – Darvis
    Nov 23, 2011 at 15:53
  • PHI and PII (personal identifiable information) are different things. You may be correct in saying the spreadhsheet isn't PHI, but is it most certainly PII which you should protect in under HIPAA ( i believe). Nov 23, 2011 at 16:00
3

As an additional note, there might be a gotcha in the future if you just replace names and birthdates randomly. You might want to add an identifier to the table to indicate that you have performed the randomization so that you don't either clobber good data or consider old data as good.

1
  • 1
    Good point. There will definitely be the need to know which records are "real" and which are not.
    – Darvis
    Nov 23, 2011 at 15:49

You must log in to answer this question.