De-identification techniques

The technique supports the string data type.

The following table lists examples of constant values that you might use:

The following image shows the technique on the Create Technique for String type window:

For timestamp and datetime data types, the format is HH:mm:ss, and the output time is always set to midnight (00:00:00). For example, 16-09-2018T11:33:00 becomes 01-01-2018T00:00:00 if the date is generalized to only preserve the year.

The technique supports the date and timestamp data types.

The following table describes the date generalization options that you can use in the Generalize section:

The following table describes the date generalization options that you can use in the Generalize user-defined date range section:

The Protect elderly individuals and Protect minor or underage individuals options can help you comply with the U.S. Health Insurance Portability and Accountability Act (HIPAA) requirement for the storage of ages and dates contained in patient healthcare data.

For example, if you select "Preserve Month and Year (MM-YYYY)," and you specify to generalize the birth date for all individuals older than 90 years old, this would result in the following:

If Data Access Management transforms the data on December 31, 2022, then Data Access Management will generalize any date that is after December 31, 1932 (2022-90=1932) to 01-[original month value]-[original year value]. Data Access Management will generalize any date that is before December 31, 1932 to 01-12-1932. For example, Data Access Management would change the input date of June 2, 1929 (02-06-1929) to 01-12-1932.

Data Access Management would not generalize any date that is equal to December 31, 1932.

Alternatively, if you select "Preserve Month and Year (MM-YYYY)," and you specify to generalize the birth date for all individuals younger than 16 years old, this would result in the following:

If Data Access Management transforms the data on December 31, 2022, then Data Access Management will generalize any date that is before December 31, 2006 (2022-16=2006) to 01-[original month value]-[original year value]. Data Access Management will generalize any date that is after December 31, 2006 to 01-12-2006. For example, Data Access Management would change the input date of June 2, 2007 (02-06-2007) to 01-12-2006.

Data Access Management would not generalize any date that is equal to December 31, 2006.

The following image shows the technique on the Create Technique for Date type window:

The hashing data de-identification technique supports the string data type.

The following table lists the fields you use to configure a hashing data protection:

The following image shows the technique on the Create Technique for String type window:

The technique supports all data types.

The technique is useful when you want to remove field values while preserving the schema of the asset after the data transformation. Maintaining the original schema is often critical to correct processing by data integration, data replication, or data virtualization tools. Maintaining the original schema might be required to support software development and testing and when working with third-party applications.

The substitute value data de-identification technique supports the string data type. Regardless of the content of a value, the technique treats it as a string. The technique supports Unicode characters.

When you create the substitute values file, organize it as follows:

The following table lists the fields you use to configure a substitute value data protection:

In consistent substitution, substitute values replace input values consistently but not uniquely.

The following table illustrates this concept with an example of using the "Consistently Substitute" option:

Note that Briana always substitutes Rodrigo and Jose always substitutes Kim. However, Briana also always substitutes Carl. Therefore, Briana is not unique, but it consistently replaced input values.

In random substitution, each row is distinct from others.

The following table illustrates an example of using the "Randomly substitute values" option:

Note that while Briana substitutes Rodrigo in the first row, any possible substitution value can replace Rodrigo in the second row.

The following image shows the technique on the Create Technique for String type window:

The tokenize data de-identification technique supports the string and integer data types. The regular expression syntax specifies a pattern for the generated string.

For example, to replace the value abcdef with a randomly generated six-letter string, use the regular expression syntax [a-z]{6}. This produces the value mvskyc.

To replace the initial value 1234 with a randomly generated four-digit number, use the regular expression syntax [1-9]{4}. This produces the value 4159.

For integers, the range of potential minimum and maximum values that Data Access Management can generate based on the expression must be compatible with the data types the technique is applied to. For example, if your input data type stores numbers from -100 to 100, define an expression that limits output to that range.

The following table lists the fields you use to configure a tokenize data protection:

With Consistently Tokenize, Data Access Management replaces raw text or numeric values with a token derived from the encrypted value of the input. In this case, the application of a tokenize data de-identification technique to tokenize data is consistent, meaning that the same input value always results in the same token whenever the same rule processes it.

With Randomly Tokenize, Data Access Management replaces raw text or numeric values with randomly generated tokens. In this case, the application of a tokenize data de-identification technique to tokenize data is inconsistent, meaning that token duplication is allowed. There will likely be multiple tokens for the same input value if it occurs more than once in the data.

Using Consistently Tokenize is required if a keyed relationship, such as maintaining referential integrity, is to be maintained across several de-identified tables. For rules that you configure to mask or tokenize consistently, you might optionally allow for unmasking of original values. That is, you can enable re-identification of data that was de-identified through that rule.

When creating tokenize data de-identification techniques, you can use any UTF-8 character block. For example, Data Access Management supports the regular expression [a-z]{10}[ก-ฯ]{10}, which includes both Basic Latin and Thai characters.

However, you cannot mix UTF-8 blocks within the same regular expression component. For example, you cannot use both Basic Latin and Thai characters in the same regular expression component, for instance [a-ก]{3}.

The following table lists examples of regular expressions that you can use to replace the value in a given format:

The following image shows the technique on the Create Technique for String type window:

The truncate data de-identification technique supports the string data type.

The following table lists the fields you use to configure a truncate data protection:

For example, you want to remove three characters from the United Kingdom post code SE1 8DJ. If you specify three characters, starting from the left, and you select Preserve characters, Data Access Management returns SE1 for the post code. If you specify three characters, starting from the left, and you do not select Preserve characters, Data Access Management returns 8DJ for the post code.

The following image shows the technique on the Create Technique for String type window: