Anonymizing Health Data: Case Studies and Methods to Get You Started (2013)

Chapter 1. Introduction

Anonymization, sometimes also called de-identification, is a critical piece of the healthcare puzzle: it permits the sharing of data for secondary purposes. The purpose of this book is to walk you through practical methods to produce anonymized data sets in a variety of contexts. This isn’t, however, a book of equations—you can find those in the references we provide. We hope to have a conversation, of sorts, to help you understand some of the problems with anonymization and their solutions.

Because the techniques used to achieve anonymization can’t be separated from their context—the exact data you’re working with, the people you’re sharing it with, and the goals of research—this is partly a book of case studies. We include many examples to illustrate the anonymization methods we describe. The case studies were selected to highlight a specific technique, or to explain how to deal with a certain type of data set. They’re based on our experiences anonymizing hundreds of data sets, and they’re intended to provide you with a broad coverage of the area.

We make no attempt to review all methods that have been invented or proposed in the literature. We focus on methods that have been used extensively in practice, where we have evidence that they work well and have become accepted as reasonable things to do. We also focus on methods that we’ve used because, quite frankly, we know them well. And we try to have a bit of fun at the same time, with plays on words and funny names, just to lighten the mood (à la O’Reilly).

To Anonymize or Not to Anonymize

We take it for granted that the sharing of health data for the purposes of data analysis and research can have many benefits. The question is how to do so in a way that protects individual privacy, but still ensures that the data is of sufficient quality that the analytics are useful and meaningful. Here we mean proper anonymization that is defensible: anonymization that meets current standards and can therefore be presented to legal authorities as evidence that you have taken your responsibility toward patients seriously.

Anonymization is relevant when health data is used for secondary purposes. Secondary purposes are generally understood to be purposes that are not related to providing patient care. Therefore, things such as research, public health, certification or accreditation, and marketing would be considered secondary purposes.

Consent, or Anonymization?

Most privacy laws are consent-based—if patients give their consent or authorization, the data can then be used for secondary purposes. If the data is anonymized, no consent is required. It might seem obvious to just get consent to begin with. But when patients go to a hospital or a clinic for treatment and care, asking them for a broad consent for all possible future secondary uses of their personal data when they register might be viewed as coercion, or not really informed consent. These concerns can be mitigated by having a coordinator discuss this with each patient and answer their questions, allowing patients to take the consent form home and think about it, and informing the community through advertisements in the local newspapers and on television. But this can be an expensive exercise to do properly.

When you consider large existing databases, if you want to get consent after the fact, you run into other practical problems. It could be the cost of contacting hundreds of thousands, or even millions, of individuals. Or trying to reach them years after their health care encounter, when many may have relocated, some may have died, and some may not want to be reminded about an unpleasant or traumatic experience. There’s also evidence that consenters and nonconsenters differ on important characteristics, resulting in potentially biased data sets.^[1^]

Consent isn’t always required, of course. A law or regulation could mandate the sharing of personal health information with law enforcement under certain conditions without consent (e.g., the reporting of gunshot wounds), or the reporting of cases of certain infectious diseases without consent (e.g., tuberculosis). Often any type of personal health information can also be shared with public health departments, but this sharing is discretionary. Actually, the sharing of personal health information for public health purposes is quite permissive in most jurisdictions. But not all health care providers are willing to share their patients’ personal health information, and many decide not to when it’s up to them to decide.^[2^]

Anonymization allows for the sharing of health information when it’s not possible or practical to obtain consent, and when the sharing is discretionary and the data custodian doesn’t want to share that data.

Penny Pinching

There’s actually quite a compelling financial case that can be made for anonymization. The costs from breach notification can be quite high, estimated at $200 per affected individual.^[3^] For large databases, this adds up to quite a lot of money. However, if the data was anonymized, no breach notification is needed. In this case, anonymization allows you to avoid the costs of a breach. A recent return-on-investment analysis showed that the expected returns from the anonymization of health data are quite significant, considering just the cost avoidance of breach notification.^[4^]

NOTE

Many jurisdictions have data breach notification laws. This means that whenever there’s a data breach involving personal (health) information—such as a lost USB stick, a stolen laptop, or a database being hacked into—there’s a need to notify the affected individuals, the media, the attorneys general, or regulators.

Some data custodians make their data recipients subcontractors (these are called Business Associates in the US and Agents in Ontario, for example). As subcontractors, these data recipients are permitted to get personal health information. The subcontractor agreements then make the subcontractor liable for all costs associated with a breach—effectively shifting the financial risk to the subcontractors. But even assuming that the subcontractor has a realistic financial capacity to take on such a risk, the data custodian may still suffer indirect costs due to reputational damage and lost business if there’s a breach.

Poor anonymization or lack of anonymization can also be costly if individuals are re-identified. You may recall the story of AOL, when the company made the search queries of more than half a million of its users publicly available to facilitate research. Soon afterward, New York Timesreporters were able to re-identify a single individual from her search queries. A class action lawsuit was launched and recently settled, with five million dollars going to the class members and one million to the lawyers.^[5^] It’s therefore important to have defensible anonymization techniques if data is going to be shared for secondary purposes.

Regulators are also starting to look at anonymization practices during their audits and investigations. In some jurisdictions, such as under the Health Insurance Portability and Accountability Act (HIPAA) in the US, the regulator can impose penalties. Recent HIPAA audit findings have identified weaknesses in anonymization practices, so these are clearly one of the factors that they’ll be looking at.^[6^]

People Are Private

We know from surveys of the general public and of patients (adults and youths) that a large percentage of people admit to adopting privacy-protective behaviors because they’re concerned about how and for what reasons their health information might be used and disclosed. Privacy-protective behaviors include things like deliberately omitting information from personal or family medical history, self-treating or self-medicating instead of seeking care at a provider, lying to the doctor, paying cash to avoid having a claims record, seeing multiple providers so no individual provider has a complete record, and asking the doctor not to record certain pieces of information.

Youths are mostly concerned about information leaking to their parents, but some are also concerned about future employability. Adults are concerned about insurability and employability, as well as social stigma and the financial and psychological impact of decisions that can be made with their data.

Let’s consider a concrete example. Imagine a public health department that gets an access to information (or freedom of information) request from a newspaper for a database of tests for a sexually transmitted disease. The newspaper subsequently re-identifies the Mayor of Gotham in that database and writes a story about it. In the future, it’s likely that very few people will get tested for that disease, and possibly other sexually transmitted diseases, because they perceive that their privacy can no longer be assured.

The privacy-preserving behaviors we’ve mentioned are potentially detrimental to patients’ health because it makes it harder for the patients to receive the best possible care. It also corrupts the data, because such tactics are the way patients can exercise control over their personal health information. If many patients corrupt their data in subtle ways, then the resultant analytics may not be meaningful because information is missing or incorrect, or the cohorts are incomplete.

Maintaining the public’s and patients’ trust that their health information is being shared and anonymized responsibly is clearly important.

The Two Pillars of Anonymization

The terminology in this space isn’t always clear, and often the same terms are used to mean different, and sometimes conflicting, things. Therefore it’s important at the outset to be clear about what we’re talking about. We’ll use anonymization as an overarching term to refer to everything that we do to protect the identities of individuals in a data set. ISO Technical Specification ISO/TS 25237 (Health informatics—Pseudonymization) defines anonymization as “a process that removes the association between the identifying data and the data subject,” which is a good generally accepted definition to use. There are two types of anonymization techniques: masking and de-identification.

NOTE

Masking and de-identification deal with different fields in a data set, so some fields will be masked and some fields will be de-identified. Masking involves protecting things like names and Social Security numbers (SSNs). De-identification involves protecting fields covering things like demographics and individuals’ socioeconomic information, like age, home and work ZIP codes, income, number of children, and race.

Masking tends to distort the data significantly so that no analytics can be performed on it. This isn’t usually a problem because you normally don’t want to perform analytics on the fields that are masked anyway. De-identification involves minimally distorting the data so that meaningful analytics can still be performed on it, while still being able to make credible claims about protecting privacy. Therefore, de-identification involves maintaining a balance between data utility and privacy.

Masking Standards

The only standard that addresses an important element of data masking is ISO Technical Specification 25237. This focuses on the different ways that pseudonyms can be created (e.g., reversible versus irreversible). It doesn’t go over specific techniques to use, but we’ll illustrate some of these in this book (specifically in Chapter 11).

Another obvious data masking technique is suppression: removing a whole field. This is appropriate in some contexts. For example, if a health data set is being disclosed to a researcher who doesn’t need to contact the patients for follow-up questions, there’s no need for any names or SSNs. In that case, all of these fields will be removed from the data set. On the other hand, if a data set is being prepared to test a software application, we can’t just remove fields because the application needs to have data that matches its database schema. In that case, the names and SSNs are retained.

Masking normally involves replacing actual values with random values selected from a large database.^[3^] You could use a database of first and last names, for example, to randomize those fields. You can also generate random SSNs to replace the original ones.

De-Identification Standards

In general, three approaches to the de-identification of health data have emerged over the last few decades: lists, heuristics, and a risk-based methodology.

Lists

A good example of this approach is the Safe Harbor standard in the HIPAA Privacy Rule. Safe Harbor specifies 18 data elements that need to be removed or generalized (i.e., reducing the precision of the data elements). If you do that to data, that data is considered de-identified according to HIPAA. The Safe Harbor standard was intended to be a simple “cookie cutter” approach that can be applied by any kind of entity covered by HIPAA (a “covered entity,” or CE). Its application doesn’t require much sophistication or knowledge of de-identification methods. However, you need to be cautious about the “actual knowledge” requirement that is also part of Safe Harbor (see the discussion in the sidebar that follows).

The lists approach has been quite influential globally. We know that it has been incorporated into guidelines used by research, government, and commercial organizations in Canada. At the time of writing, the European Medicines Agency was considering such an approach to de-identify clinical trials data so that it can be shared more broadly.

WARNING

This method of de-identification has been significantly criticized because it doesn’t provide real assurances that there’s a low risk of re-identification.^[4^] It’s quite easy to create a data set that meets the Safe Harbor requirements and still have a significantly high risk of re-identification.

WHAT’S “ACTUAL KNOWLEDGE”?

The HIPAA Privacy Rule Safe Harbor de-identification standard includes the requirement that the covered entity doesn’t have actual knowledge that the information could be used alone or in combination with other information to identify an individual who is a subject of the information (a data subject). This requirement is often ignored by many organizations that apply Safe Harbor. But it’s an important requirement, and failing to observe it can leave a data set identifiable even if the specified 18 elements are removed or generalized.

Actual knowledge has to be specific to the data set and not just general knowledge about what’s theoretically possible. This is clear and direct knowledge that a data subject has a high risk of re-identification and that the data isn’t truly de-identified.

If there’s a record in the data set with an occupation field “Mayor of Gotham,” it will be pretty easy to figure out who that individual is. The covered entity would have to remove the occupation field to ensure that this kind of information isn’t revealed, even though occupation isn’t in HIPAA’s list of 18. If Richard Greyson is a data recipient and it’s known that he has family in the data set, he could use his background knowledge about them to re-identify relatives in the records, so to be anonymized, the information about these relatives would have to be removed or distorted. If Ms. Cobblepot has an unusually large number of children, which was highly publicized because it’s rare and unusual, it would be necessary to remove the number of babies from her record in a data set, or remove her entire record.

In all of these examples, the actions taken to de-identify the data would exceed just dealing with the 18 elements identified in Safe Harbor. A covered entity wouldn’t be able to determine whether any of these examples applied to its data set unless they analyzed the data carefully. Can a covered entity deny that it has actual knowledge if it never looks at the data? This is something for the lawyers to decide!

Heuristics

The second approach uses “heuristics,” which are essentially rules of thumb that have developed over the years and are used by data custodians to de-identify their data before release. Sometimes these rules of thumb are copied from other organizations that are believed to have some expertise in de-identification. These tend to be more complicated than simple lists and have conditions and exceptions. We’ve seen all kinds of heuristics, such as never releasing dates of birth, but allowing the release of treatment or visit dates. But there are all kinds of exceptions for certain types of data, such as for rare diseases or certain rural communities with small populations.

Heuristics aren’t usually backed up by defensible evidence or metrics. This makes them unsuitable for data custodians that want to manage their re-identification risk in data releases. And the last thing you want is to find yourself justifying rules of thumb to a regulator or judge.

Risk-based methodology

This third approach, which is consistent with contemporary standards from regulators and governments, is the approach we present in this book. It’s consistent with the “statistical method” in the HIPAA Privacy Rule, as well as recent guidance documents and codes of practice:

§ “Guidance Regarding Methods for De-Identification of Protected Health Information in Accordance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule,” by the US Department of Health and Human Services

§ “Anonymisation: Managing Data Protection Risk Code of Practice,” by the UK Information Commissioner’s Office

§ “‘Best Practice’ Guidelines for Managing the Disclosure of De-Identified Health Information,” by the Canadian Institute for Health Information in collaboration with Canada Health Infoway

§ “Statistical Policy Working Paper 22, Report on Statistical Disclosure Limitation Methodology,” by the US Federal Committee on Statistical Methodology

We’ve distilled the key items from these four standards into twelve characteristics that a de-identification methodology needs.^[4^] Arguably, then, if a methodology meets these twelve criteria, it should be consistent with contemporary standards and guidelines from regulators.

DE-IDENTIFICATION MYTHS

A number of myths about de-identification have been circulating in the privacy and policy communities for some time. They’re myths because they’re not supported by credible evidence. We’ll summarize some of the important ones here:

Myth: It’s possible to re-identify most, if not all, data.

Current evidence strongly suggests that if you de-identify health data using robust methods, the risk of re-identification can be very small. Known examples of re-identification attacks were not performed on data that was properly de-identified.^[7^] The methods we describe in this book are robust and would ensure that the risk of re-identification is very small.

Myth: Genomic sequences are not identifiable, or are easy to re-identify.

Under certain conditions it’s possible to re-identify genomic sequences,^[8^], [9^] and they’re very difficult to de-identify using the kinds of methods we describe here. This applies to all kinds of “-omics” data. The types of data sets that we’re focusing on in this book consist of clinical, administrative, and survey data. The sharing and analysis of sequences in a privacy-preserving manner requires the use of secure computation techniques, which we’ll touch on in a later chapter.

Anonymization in the Wild

You’ve probably read this far because you’re interested in introducing anonymization within your organization, or helping your clients implement anonymization. If that’s the case, there are a number of factors that you need to consider about the deployment of anonymization methods.

Organizational Readiness

The successful deployment of anonymization within an organization—whether it’s one providing care, a research organization, or a commercial one—requires that organization to be ready. A key indicator of readiness is that the stakeholders believe that they actually need to anonymize their data. The stakeholders include the privacy or compliance officer of the organization, the individuals responsible for the business line, and the IT department.

For example, if the organization is a hospital, the business line may be the pharmacy department that is planning to share its data with researchers. If they don’t believe or are not convinced that the data they share needs to be anonymized, it will be difficult to implement anonymization within that organization.

Sometimes business line stakeholders believe that if a data set does not include full names and SSNs, there’s no need to do anything else to anonymize it. But as we shall see throughout this book, other pieces of information in a database can reveal the identities of patients even if their names and SSNs are removed, and certainly that’s how privacy laws and regulations view the question.

Also, sometimes these stakeholders are not convinced that they’re sharing data for secondary purposes. If data is being shared for the purpose of providing care, patient consent is implied and there’s no need to anonymize the data (and actually, anonymizing data in the context of providing care would be a bad idea). Some stakeholders may argue that sharing health data for quality improvement, public health, and analytics around billing are not secondary purposes. Some researchers have also argued that research isn’t a secondary purpose. While there may be some merit to their arguments in general, this isn’t usually how standards, guidelines, laws, and regulations are written or interpreted.

The IT department is also an important stakeholder because its members will often be responsible for deploying any technology related to anonymization. Believing that anonymization involves removing or randomizing names in a database, IT departments sometimes assign someone to write a few scripts over a couple of days to solve the data sharing problem. As you will see in the remainder of this book, it’s just not that simple. Doing anonymization properly is a legal or regulatory requirement, and not getting it right may have significant financial implications for the organization. The IT department needs to be aligned with that view.

It’s often the case that the organizations most ready for the deployment of anonymization are those that have had a recent data breach—although that isn’t a recommended method to reach a state of readiness!

Making It Practical

A number of things are required to make anonymization usable in practice. We’ve found the following points to be quite important, because while theoretical anonymization methods may be elegant, if they don’t meet the practicality test their broad translation into the real world will be challenging:

§ The most obvious criterion is that the anonymization methods must have been used in practice. Data custodians are always reassured by knowledge that someone else has tried the methods that they’re employing, and that they worked.

§ Data users must accept the anonymization methods that are being applied. For example, if anonymization distorts the data in ways that are not clear, makes the data analysis more complicated, or limits the type of analysis that the data users can do, they’ll resist using anonymized data.

§ The anonymization methods must also be understandable by data users. Especially in cases where care or business decisions are going to be made based on the data analysis, having a clear understanding of the anonymization is important. This also affects whether the data users accept the data.

§ Anonymization methods that have been scrutinized by peers and regulators are more likely to be adopted. This means that transparency in the exact anonymization methods that are being used, and their justifications, helps with their adoption within organizations.

§ Needless to say, anonymization methods must be consistent with regulations. Methods that require changes in the law or paradigm shifts in how private information is perceived will not be adopted by data users because they’re simply too risky (at least until the law is changed).

§ Data custodians want to automate anonymization so that they don’t have to bring in external experts to manually anonymize every single data set they need to share. Analytics is becoming an important driver for business, patient care, and patient safety in many organizations, so having an inefficient process for getting the data quickly becomes a bottleneck.

Use Cases

Practical anonymization has been applied in a number of different situations. The techniques to use will of course depend on the specifics of the situation. Here we summarize some of the use cases:

Research

This use case is the simplest one, in that the data set can be completely defined up front and is often not refreshed or updated. An analyst working for the data custodian decides how to anonymize the data and then creates a file to give to the researcher.

Open data

There’s increasing pressure to make health data openly available on the Web. This may be data from projects funded through the public purse, clinical trials data, or other kinds of government data (so-called “open government” initiatives).

Data warehouses

Organizations are increasingly creating data warehouses that integrate data sets from multiple sources for the purpose of performing analytics. These sources can be internal to the organization (e.g., different units within the hospital), or external (e.g., data sets from commercial data brokers). Data needs to be anonymized before being pulled out of the data warehouses to perform analytics.

Public health surveillance

In this use case, health-related data is being continuously collected—from multiple geographically distributed locations—and sent to a centralized database. The sites need to anonymize their data before sending it to the central repository, and the anonymization must be applied consistently across all sites so that the data is meaningful when it is combined. Once the data is collected centrally, it’s analyzed and interpreted for things like disease surveillance, evaluating compliance to screening guidelines, and service planning.

Medical devices

Similar to public health surveillance, data from medical devices is collected from multiple sources. The devices themselves can be installed at the sites of health care providers across the country and can pull in data about the patients from electronic medical records. This data could include patient-specific information. Data here is flowing regularly and needs to be anonymized as it’s coming in.

Alerts

This use case is a bit different from the others because an alert needs to be sent close in time to when it was generated. Also, an alert may consist of a very small number of patient records. For example, an alert can be generated for a pharma company when a certain drug is dispensed to a patient. But the information in the alert needs to be de-identified before it can be transmitted. In this case individual (or a small number of) records need to be anonymized on the fly, rather than a full database.

Software testing

This use case often requires access to data to conduct functional and performance tests. Organizations developing applications that process health data need to get that data from production environments. The data from production environments must be anonymized before being sent to the testing group.

We’ll discuss many of these use cases in the book and show how they can be handled.

WHAT IF THE DATA IS RE-IDENTIFIED?

A question that often comes up is what would happen if records in a data set that has been properly anonymized were re-identified by an adversary. Assuming that the re-identifications are real and verified, the main concern of the data custodian (or covered entity or business associate) is whether it is liable. There are a number of things to consider:

§ Anonymization is probabilistic—there’s a very small probability that records can be re-identified. But it could happen if you’re unlucky.

§ We can’t guarantee zero risk if we want to share any useful data. The very small risk is the trade-off required to realize the many important benefits of sharing health data.

§ Regulators don’t expect zero risk either—they accept that very small risk is reasonable.

§ There are no court cases or investigations of re-identification attacks by regulators that would set precedents on this issue.

§ By following the methods we describe here, you can make a strong case that you are using best contemporary practices, consistent with current standards, guidelines, and regulator recommendations. This should help considerably in the case of litigation or investigations.

§ Not using defensible methods means that the probability of a successful re-identification attack is much higher (i.e., you are more likely to be unlucky), and the defense you can mount after such an incident would be much weaker.

Stigmatizing Analytics

When health data is anonymized so that it can be used for the sake of analytics, the outcome of the analysis is a model or an algorithm. This model can be as simple as a tabular summary of the data, a regression model, or a set of association rules that characterize the relationships in the data. We make a distinction between the process of building this model (“modeling”) and making decisions using the model (“decision making”).

Anonymized data can be used for modeling. Anonymization addresses the risk of assigning an identity to a record in the database. This promise affects how “personal information” is defined in privacy laws. If the risk of assigning identity is very small, the data will no longer be considered personal information.

However, decision making may raise additional privacy concerns. For example, a model may be used to fire employees who have a high risk of contracting a complex chronic illness (and hence who increase insurance costs for a firm), or to call in the bank loans of individuals who have been diagnosed with cancer and have low predicted survivability, or to send targeted ads (online or by regular mail) to an individual that reveal that that person is gay, pregnant, has had an abortion, or has a mental illness. In all of these cases, financial, social, and psychological harm may result to the affected individuals. And in all of these cases the models themselves may have been constructed using anonymized data. The individuals affected by the decisions may not even be in the data sets that were used in building the models. Therefore, opt-out or withdrawal of an individual from a data set wouldn’t necessarily have an impact on whether a decision is made about the individual.

NOTE

The examples just listed are examples of what we call “stigmatizing analytics.” These are the types of analytics that produce models that can lead to decisions that adversely affect individuals and groups. Data custodians that anonymize and share health data need to consider the impact of stigmatizing analytics, even though, strictly speaking, it goes beyond anonymization.

The model builders and the decision makers may belong to different organizations. For example, a researcher may build a model from anonymized data and then publish it. Later on, someone else may use the model to make decisions about individual patients.

Data recipients that build models using anonymized health data therefore have another obligation to manage the risks from stigmatizing analytics. In a research context, research ethics boards often play that role, evaluating whether a study may potentially cause group harm (e.g., to minority groups or groups living in certain geographies) or whether the publication of certain results may stigmatize communities. In such cases they’re assessing the conclusions that can be drawn from the resultant models and what kinds of decisions can be made. However, outside the research world, a similar structure needs to be put in place.

Managing the risks from stigmatizing analytics is an ethical imperative. It can also have a direct impact on patient trust and regulator scrutiny of an organization. Factors to consider when making these decisions include social and cultural norms, whether patients expect or have been notified that their data may be used in making such decisions (transparency about the analytics), and the extent to which stakeholders’ trust may be affected when they find out that these models and decisions are being made.

A specific individual or group within the organization should be tasked with reviewing analysis and decision-making protocols to decide whether any fall into the “stigmatizing” category. These individuals should have the requisite backgrounds in ethics, privacy, and business to make the necessary trade-offs and (admittedly), subjective risk assessments.

The fallout from inappropriate models and decisions by data users may go back to the provider of the data. In addition to anonymizing the data they release, data custodians may consider not releasing certain variables to certain data users if there’s an increased potential of stigmatizing analytics. They would also be advised to ensure that their data recipients have appropriate mechanisms to manage the risks from stigmatizing analytics.

Anonymization in Other Domains

Although our focus in this book is on health data, many of the methods we describe are applicable to financial, retail, and advertising data. If an online platform needs to report to its advertisers on how many consumers clicked on an ad and segment these individuals by age, location, race, and income, that combination of information may identify some of these individuals with a high probability. The anonymization methods that we discuss here in the context of health data sets can be applied equally well to protect that kind of advertising data.

Basically, the main data fields that make individuals identifiable are similar across these industries: for example, demographic and socioeconomic information. Dates, a very common kind of data in different types of transactions, can also be an identity risk if the transaction is a financial or a retail one. And billing codes might reveal a great deal more than you would expect.

Because of escalating concerns about the sharing of personal information in general, the methods that have been developed to de-identify health data are increasingly being applied in other domains. Additionally, regulators are increasingly expecting the more rigorous methods applied in health care to be more broadly followed in other domains.

GENETICS, CUT FROM A DIFFERENT CLOTH

The methods described in this book aren’t suitable for the anonymization of genetic data, and would cause significant distortion to long sequences. The assumptions needed to de-identify sequences of patient events (e.g., visits and claims) would not apply to genomic or other “-omic” data. But there are nuances that are worth considering.

Some of the attacks that have been performed on genomic data didn’t actually take advantage of the sequence information at all. In one attack, the dates of birth and ZIP codes that participants included in their profiles for the Personal Genome Project (PGP) were used to re-identify them.^[10^] This attack used variables that can easily be protected using the techniques we describe in this book. Another attack on PGP exploited the fact that individuals were uploading compressed files that had their names used as filenames when uncompressed.

To the extent that phenotypic information can be inferred from genetic data, such information could possibly be used in a re-identification attack. Predictions (varying in accuracy) of various physical features and certain diagnoses have been reported from genetic information.^[11^], [12^], [13^], [14^] There have not been any full demonstrations of attacks using this kind of information. Because of the errors in some of these predictions, it’s not even clear that they would be useful for a re-identification attack.

More direct attacks are, however, plausible. There is evidence that a sequence of 30 to 80 independent single-nucleotide polymorphisms (SNPs) could uniquely identify a single person.^[15^] Although such an attack requires the adversary to have genotype data for a target individual, it’s also possible to determine whether an individual is in a pool of several thousand SNPs using summary statistics on the proportion of individuals in the case or control group.^[8^] By utilizing a common Y-chromosome and surname correlation, and relying on generally available recreational genetic genealogy databases, a recent attack was also able to recover individuals’ surnames under certain circumstances.^[9^]

One approach to avoiding these types of attacks is to use secure multiparty computation. This is a set of techniques and protocols that allow sophisticated mathematical and statistical operations to be performed on encrypted data. We look at an example of this in Chapter 12, about secure linking. However, the application of these methods to genetic data is still in the early stages of research and we may have to wait a few more years to see some large-scale practical results.

About This Book

Like an onion, this book has layers. Chapter 2 introduces our overall methodology to de-identification (spoiler alert: it’s risk-based), including the threats we consider. It’s a big chapter, but an important one to read in order to understand the basics of de-identification. Skip it at your own risk!

After that we jump into case studies that highlight the methods we want to demonstrate—from cross-sectional to longitudinal data to more methods to deal with different problems depending on the complexity of the data. The case studies are two-pronged: they are based on both a method and a type of data. The methods start with the basics, with Chapter 3, then Chapter 4. But longitudinal data can be complicated, given the number of records per patient or the size of the data sets involved. So we keep refining methods in Chapter 5 and Chapter 6. For both cross-sectional and longitudinal data sets, when you want to lighten the load, you may wish to consider the methods of Chapter 7.

For something completely different, and to deal with the inevitable free-form text fields we find in many data sets, we look at text anonymization in Chapter 8. Here we can again measure risk to de-identify, although the methods are very different from what’s presented in the previous chapters of the book.

Something else we find in many data sets is the locations of patients and their providers. To anonymize this data, we turn to the geospatial methods in Chapter 9. And we would be remiss if we didn’t also include Chapter 10, not only because medical codes are frequently present in health data, but because we get to highlight the Cajun Code Fest (seriously, what a great name).

We mentioned that there are two pillars to anonymization, so inevitably we needed Chapter 11 to discuss masking. We also describe ways to bring data sets together before anonymization with secure linking in Chapter 12. This opens up many new opportunities for building more comprehensive and detailed data sets that otherwise wouldn’t be possible. And last but not least, we discuss something on everyone’s mind—data quality—in Chapter 13. Obviously there are trade-offs to be made when we strive to protect patient privacy, and a lot depends on the risk thresholds in place. We strive to produce the best quality data we can while managing the risk of re-identification, and ultimately the purpose of this book is to help you balance those competing interests.