MEETING HIPAA COMPLIANCE WITH TRAFFIC SCRIPT

In today’s world more and more applications and associated data are being migrated to the Cloud. For instance, in Canada, the Canadian government has announced plans to consolidate hundreds of data centers into a government run cloud. (http://news.gc.ca/web/article-eng.do?nid=614499).  One of the major questions, consumers ask is how private is their data? 

Most data centers have several layers of physical as well as logical security built into them. Data that is stored can even be encrypted. But how do you prevent an individual’s privacy when doing research? This questions keeps coming up in various scenarios.  I am going to talk about one such situation that recently cropped up in a meeting between Riverbed Technology and one of our major Systems Integrators.

I learned about a very interesting HIPAA compliance challenge. Our Security Architect, from our CTO office, is on the privacy board of a health care research program.  He was talking to our partner about a specific “privacy” challenge involved in de-identifying clinical records so that researchers can use the data without discovering who the individual patients are. On the back of a napkin (literally), he created a small record set:

 

Name	Zip	DoB	Pain Medication	Treatment
Alice	98761	09/01/1960	Asprin	Leg Pain
Bob	98712	01/01/1958	Ibuprofen	Leg Pain
Joe	98743	12/15/1955	Motrin	Phantom leg pain
Smith	98785	01/01/1955	Tylenol	Phantom leg pain
Walker	98735	01/01/1971	Motrin	Pain in amputated leg

Obviously this data is identifiable! Easy algorithms exist to obfuscate the most obvious elements. Such algorithms would produce this record set: 

Name	Zip	YoB	Pain Medication	Treatment
******	987**	1960	Asprin	Leg Pain
******	987**	1958	Ibuprofen	Leg Pain
******	987**	1955	Motrin	Phantom leg pain
******	987**	1955	Tylenol	Phantom leg pain
******	987**	1971	Motrin	Pain in amputated leg

For many kinds of analysis, broad geographic area and birth year are important. You’d guess that even a researcher who resided in a location with a 987 zip code would be unable to identify individual records. Lots of people experience pain, and it’s reasonable to assume that a large subset of patients born before 1960 might opt for marijuana treatments. 

But note that the 2 folks who take Marijuana take it for Phantom Leg Pain and Pain in Amputated leg.

Phantom leg pain is pretty rare, occurring only in those with missing limbs—which has the unfortunate characteristic of being very obvious.  It is very similar to the pain described as Amputated leg pain. Do you think a researcher living in 987 might know who this amputee is? Probably.  Does that researcher now know more than he/she needs to know about this person?  Definitely.  In this case, the de-identification requirement failed, and HIPAA compliance is at risk.

Stingray Traffic Script to the rescue 

With a simple TrafficScript in Stingray Traffic Manager, you can block the transmission of data containing combinations of elements that would, in this case, carry the risk of uniquely identifying specific individuals. For example, from a list of diagnoses and a list of treatments, you could create a dataset of potentially identifying pairs. Then, whenever this pair appears in the output of an application, your rule can follow whatever policy you’ve decided is appropriate. For example, your policy could require:

 

·         Deleting the entire record

·         Removing the pair

·         Removing just the diagnosis

·         Removing just the treatment

 

Each of these choices requires making some kind of tradeoff that lowers the total value of the dataset to the researcher. The overarching point to remember is that security decisions are best made in consultation with business units and other stakeholders. Once those decisions are made, then you can configure Stingray Traffic Manager to enforce your policy. 

Here’s an example TrafficScript that would provide the data to the researcher but would still protect the individuals.

 

$keywords = data.get ( "runonce" );             # retrieve keywords from memory  if ( !$keywords ) {    $keywords = resource.getLines("HipaaWords"); # read keywords from disk    data.set("runonce", $keywords);              # save keywords in memory  }    $response = http.getResponseBody();            # get the response    foreach ($word in $keywords) {     $response = string.replaceAllI($response, $word, "");  # remove keyword  }    http.setResponseBody($response);               # update the modified response

 

The end result of running this script is a results table as follows:

 

Name	Zip	YoB	Pain Medication	Treatment
******	987**	1960	Asprin	Leg Pain
******	987**	1958	Ibuprofen	Leg Pain
******	987**	1955	Motrin	leg pain
******	987**	1955	Tylenol	leg pain
******	987**	1971	Motrin	Pain in leg

 

 

The first thing we do is create a simple table of all the words and phrases that we don’t want to display in the end result. I call this table the “HipaaWords”.   Four our example this is essentially a text file having the following 2 lines

 

Hipaa Words text file:

Phantom

amputated

 

The advantage of keeping this in a file is:

• A text file can be easily loaded into the reference section of the Stingray Traffic Manager.
• As our selection criteria changes, it is easy to change the contents of the file

  

Authors:  Raja Srinivasan, Jim Young

 

Comments

[Trish Gundy]

This is an excellent way to complement Data Loss Prevention and provide HIPAA Compliance.

[Sara]

Its like you read my mind! You seem to know so much about this, like you wrote the book in it or something. I think that you can do with a few pics to drive the message home a little bit, but instead of that, this is great blog. An excellent read. I will certainly be back.