A Framework for the Design of Privacy-Preserving Record Linkage Systems

Abstract

Record linkage can enhance the utility of data by bringing data together from different sources, increasing the available information about data subjects and providing more holistic views. Doing so, however, can increase privacy risks. To mitigate these risks, a family of methods known as privacy-preserving record linkage (PPRL) was developed, using techniques such as cryptography, de-identification, and the strict separation of roles to ensure data subjects’ privacy remains protected throughout the linkage process, and the resulting linked data poses no additional privacy risks. Building privacy protections into the architecture of the system (for instance, ensuring that data flows between different parties in the system do not allow for transmission of private information) is just as important as the technology used to obfuscate private information. In this paper, we present a technology-agnostic framework for designing PPRL systems that is focused on privacy protection, defining key roles, providing a system architecture with data flows, detailing system controls, and discussing privacy evaluations that ensure the system protects privacy. We hope that the framework presented in this paper can both help elucidate how currently deployed PPRL systems protect privacy and help developers design future PPRL systems.

1. Introduction

The linkage of data from multiple sources can provide rich and varied datasets that give holistic views of individuals, providing significant increases in data utility as compared with separate, disparate datasets. For example, the linkage of an electronic health record (EHR) dataset with a social determinant of health (SDOH) dataset can illuminate social factors that are related to health outcomes, which is of interest to policymakers seeking ways to make evidence-based policy decisions [1,2,3,4,5]. Linkage can also streamline data management, usage, and analysis, providing more efficient usage of data while enabling previously unavailable analyses.

However, linkage presents significant risks to individual privacy, not only because the resulting linked data can contain more information about the individual but also because traditional record linkage involves using personally identifiable information (PII) such as name, phone number, email address, unique codes like social security numbers, and indirect identifiers like date of birth, sex, ZIP code of residence, and dates of special events (e.g., a surgery or hospital admission) to match records across datasets [6]. Handling significant amounts of identifiable information can pose privacy and security risks, the mitigation of which can create barriers to usage and sharing. For instance, data that contains identifiable information often cannot be used outside the purposes for which it was initially gathered without either obtaining additional consent or ensuring that the usage falls under specific allowances (e.g., public health emergencies) [7]. This limits the ability of researchers, analysts, and policymakers from using these data in identifiable formats, creating the need for de-identified data with sufficient privacy protections to ensure de-identification remains in place throughout the data usage lifecycle.

After data is de-identified, traditional methods of record linkage cannot be performed because the identifying information necessary for linkage gets removed. To enable such linkage, a family of techniques known as privacy-preserving record linkage (PPRL) has been developed that leverage cryptography, secret sharing, and careful system design to ensure that individual privacy remains protected throughout the linkage process [8]. These techniques have undergone comprehensive review and evaluation for their utility in federal data linkage projects with investigations of both open-source and proprietary commercial systems [9,10,11,12] and have been deployed in real-life data linkage and analysis systems such as that used by the N3C collaborative [13,14].

Missing from the literature is a framework for the design and architecture of a PPRL system, describing the roles and responsibilities of the different parties involved within the system, the transfers of data and information flow between the different parties, the protections that need to be put in place, and the evaluations that need to be performed. The existing literature focuses on tooling and techniques, leaving information gaps around how to structure processes and organize data flows between the different parties. This gives the misconception that PPRL can be achieved solely through technical measures, overlooking that the process and people involved are just as important to ensuring privacy protection as the technology. The authors provide a framework for the design of PPRL systems within this paper, leveraging experience with real-world PPRL systems to provide a system architecture with broad applicability across many use cases. The focus of our framework is privacy protection; by having this focus, we can use this framework to both design systems that better protect privacy when linking data and explain to others how the system protects privacy in a simple and understandable manner. Our framework can be used to simplify the complexities within existing systems, allowing for ease of understanding of the data flows and privacy-preservation techniques being used, and it provides developers and deployers of PPRL systems with a broadly applicable technology-agnostic architecture that can be used to build their own systems. We hope that this framework enables the construction of more PPRL systems to enable greater data sharing and collaboration in a manner that protects the privacy of data subjects.

This paper is organized as follows. We first begin with a section explaining the basic aims of and the techniques that enable PPRL to establish a common baseline of understanding. We then move on to our system design framework, listing out the key roles in a PPRL system, describing the data flow architecture for a PPRL system designed under our framework, detailing system controls to be put in place around a PPRL system to protect privacy, and outlining what the qualified expert evaluation is and what should be evaluated. In the discussion section, we describe how the framework can be used, focusing on the two primary use cases of providing clarity as to the architecture of an already existing PPRL system and designing a new system.

2. What Is PPRL?

PPRL is a family of techniques for enabling data linkage while protecting the privacy of data subjects. PPRL is intended to mitigate privacy risks and reduce barriers to data linkage and data use, enabling the access to and usage of linked data without needing to process large amounts of identifiable information [10]. Key to privacy protection in these systems is the requirement that no party within a PPRL system can access PII they do not already control [11,15]. PPRL does this by enabling record linkages without using PII via tokenization, where the PII traditionally used for linkage is transformed in a reproducible manner into a unique identifier for data subjects and events associated with those data subjects [16,17]. The tokens can then be matched across datasets to perform linkage instead of using the PII. Tokenization has the additional benefit of de-identifying the component datasets, enabling secondary usage without the need to obtain data subject consent [15]. Figure 1 shows an example of the design of a tokenizer.

The current state of the art in tokenization uses a two-step process to generate linkage tokens and controller-specific tokens [12,17]. First, PII used for linkage gets passed into the tokenizer, where a master salt (i.e., a special set of characters used by the tokenizer for linkage) gets added to the PII. The PII plus master salt is then passed through a one-way hashing algorithm to create the linkage token. This token will be the same for matching sets of PII regardless of the source, which is how it enables data linkage. The linkage token then undergoes a secondary encryption process using keys that are specific to each data controller, creating the controller-specific tokens. This token can be used by data controllers as unique identifiers for their data subjects, but they cannot use them for linkage on their own. Instead, a third party who holds the keys to decrypt the controller-specific tokens can transform them back into the linkage tokens and use that to perform linkage for data controllers. With secondary encryption, controllers can be sure that they do not reveal data subjects present in their data to other parties in the linkage process.

While tokenization enables PPRL, to ensure privacy preservation throughout the linkage process, there needs to be additional technical and administrative controls designed into the record linkage system. While the requirement that no party within a PPRL system can access PII they do not already control is easy to understand, designing a record linkage system that can implement this requirement can be difficult with non-obvious pitfalls that put the privacy preservation of the system at risk. For instance, PPRL systems should allow original data controllers to be able to re-identify subjects in the data they provided. However, they should not be able to re-identify those same data subjects in data provided by other parties. Additionally, in some use cases, controllers need to identify whether a data subject within their data can be found in another controller’s data (a process known as de-duplication) without re-identifying the data subject in the other parties’ data. Creating a system that can enable such complex and seemingly conflicting requirements requires careful design to ensure that privacy protections remain in place.

3. System Design Framework for PPRL

In this section, we present our framework PPRL system design. This framework aims to capture all the key aspects of PPRL systems necessary for privacy preservation throughout the linkage process with a focus on privacy protection. We start by presenting an overview of the key roles within a PPRL system, then move on to discuss the design of the system itself, presenting a data flow diagram with different parties marked out and the flow of information between the different parties. We present a system architecture for creating a linked dataset for analysis that can be modified for other use cases. We demonstrate a modification of this architecture to enable de-duplication and data harmonization between multiple data controllers. We then discuss the protections that need to be put in place to enable PPRL and conclude with key points that need to be part of the privacy evaluation.

3.1. Key Roles in a PPRL System

Table 1. Roles and responsibilities of different parties in a PPRL system.

Party	Roles and Responsibilities
Data Controllers	Role: Custodians of data subjects’ information
	Responsibility: Has the legal obligation to protect the privacy rights of data subjects whose data they control. Must enact physical, administrative, and technical controls to protect data. Must ensure that any data processors who access and use data they control are able to meet the same standards they follow for privacy and security controls.
Tokenizer	Role: Provides a technical solution for the creation of non-identifiable tokens to represent data subjects and facilitate linkages between datasets.
	Responsibility: Provides a secure solution for the creation of data subject tokens. Said solution often involves deploying tokenization software on-site that does not require connection to the internet, cloud computing, or any external system to operate, requiring the solution to be modular and containerizable.
Honest Broker	Role: Facilitates data linkages in a privacy-preserving manner. This can include performing de-identification and data encryption or just be limited to acting as an escrow service for encryption keys and patient token mappings.
	Responsibility: Is a neutral third party that provides protections for data subject privacy within a data use and sharing system. Other responsibilities may be defined in an Honest Broker Agreement with contractual controls in place that specify their role in the system and what they can and cannot do with the data.
Expert Determiner	Role: Evaluates and provides evidence (i.e., a report) that shows that what is being planned with the data does not violate the privacy rights of data subjects
	Responsibility: Provides an unbiased evaluation of the privacy risks to data subjects from the anticipated usage and data linkages and, if there are risks, provides recommendations for mitigation strategies to address those risks. The expert determiner may evaluate data subject identifiability before and after linkage, privacy and security controls on a system, end data user motives and capacity for privacy violations (including data access and use limitations), and likelihood of data breach. The determination may recommend additional transformations be applied to the data or additional controls be put in place.
Privacy Officer	Role: Knowledgeable expert in privacy-related matters who can help identify and address privacy-related issues when handling PII.
	Responsibility: Provides guidance on privacy-related matters on projects where PII is being handled to ensure compliance with regulations and policies. Assists with system design to ensure privacy principles are followed throughout the data lifecycle.
Data Platform	Role: Provides the hosting environment where individual unlinked datasets and linked datasets are stored and may also provide a computational platform for data users to access, process, and analyze said data.
	Responsibility: Implement the necessary privacy and security controls to protect the data hosted on the platform and provide analytic tools to end users for data processing and analysis. Platforms may be the enablers of PPRL, as the actual linkage process may take place on the platform using analytic tools provided within the platform. Platforms may also be the best place to implement technical privacy and security controls, such as limits on downloading data, access controls, and logging and monitoring data use.
Data Governance	Role: Provides the rules within which the system operates and oversight to ensure rules are followed.
	Responsibility: Development of the rules that govern the data system, including the privacy and security controls that must be followed, access control procedures, roles and responsibilities of different parties in the system, contractual terms and agreements, data retention and destruction policies, quality rules, data and metadata standards, and regular monitoring and auditing. Provides oversight over data governance rules to ensure that they are followed.
Data Users	Role: End users of the data product.
	Responsibility: Process and analyze the data according to the requirements and limitations set down within the data access and use agreements they sign.

describes the roles and responsibilities of different parties within a PPRL system. This table can be used to identify roles and establish responsibilities for different parties to a PPRL system. It can also help identify which roles have not been filled by existing parties so that either existing parties take up multiple roles or new parties can be engaged to take on those roles. All roles should be filled to ensure privacy protections in a PPRL system.

3.2. Architecture of PPRL Systems

As the primary goal of PPRL is to link data while protecting privacy, that is, to link data without any party to the linkage obtaining PII they do not already possess, the system must be designed so that flows of data do not involve transfer of PII outside of any individual party’s control. Key to enabling this goal are the Tokenizer and the Honest Broker; the Tokenizer masks PII used for linkage before it gets transferred outside a data controller’s security perimeter, and the Honest Broker facilitates the linkage so that controllers do not need to handle tokens generated from another controller’s data. Figure 2 shows the architecture of the PPRL system, focusing on data flows between different parties in the system, with the goal of creating a linked dataset for analysis.

In this system, linked de-identified data from two controllers is meant to be provided to users of a data platform for analysis. Each step of the process is marked in the figure and listed below.

• Data controllers send the PII they use for linkage through a tokenizer to create linkage tokens and controller-specific tokens.
• Tokens are then sent to the Honest Broker.
• Data controllers provide to the data platform de-identified data with controller-specific tokens generated from the tokenizer.
• The honest broker facilitates linkage by either providing mapping tables between the linkage tokens and controller-specific tokens or by providing the encryption keys that can decrypt the controller-specific tokens back into the linkage tokens. The linkage process can be performed automatically by the platform using the information provided by data controllers and the honest broker.
• A qualified expert determiner examines the system and the processes performed by the data platform to ensure that no PII gets shared at any point in this process and may make recommendations for mitigating any privacy gaps if necessary. These recommendations could include modifications to the data flow, additional encryption steps, increasing the security context of the data platform, adding access controls, limiting the number or type of data queries, perturbing the linked data to prevent the data controllers from linking it to their original data, or others.
• Data users are able to submit queries to the platform and receive the linked de-identified data they need for their analyses. They will not be able to see the process performed by the data platform to create the linked dataset.

This system architecture is flexible in that it can accommodate any number of data controllers (our example shows just two for simplicity), multiple data platforms for analysis, multiple Honest Brokers for different linkage purposes, or even multiple Tokenizer tools. It is technology-agnostic, not requiring any specific hardware or software to be implementable. To ensure the system is privacy-preserving, the data flows as described between the different key roles in the system must be in place.

The architecture of this system can be modified for other use cases as well. For instance, in some PPRL frameworks, instead of linking data, data controllers may be trying to determine whether they hold duplicate or redundant information between themselves. They may be performing this as a required step in data harmonization (e.g., removing duplicate records prior to combining their data, a process used within N3C [13]) or to identify individuals that are of interest because they appear in two different datasets (e.g., two states comparing data to find individuals who may have crossed state lines, a use case present in a pilot program that looked at linkage of Supplemental Nutrition Assistance Program (SNAP) recipients across state lines to prevent duplicate issuances of SNAP benefits [18]). In this case, the Honest Broker identifies overlapping linkage tokens, maps them back to controller tokens, and delivers the matched controller tokens back to their original data controller. Figure 3 is an architecture diagram showing the data flows for this use case, which is a simplified version of the diagram in Figure 2.

3.3. System Controls for Privacy Protection

To ensure the PPRL process remains privacy-preserving, in addition to the system architecture, privacy and security controls need to be put in place. The establishment of a set of controls typically involves working with data governance and privacy officers, performing evaluations such as Privacy Impact Assessments, Data-Protecting Impact Assessments, Vendor Risk Assessments, Business Impact Assessments, Enterprise Risk Assessments, and potentially Transfer Impact Assessments (used for transfers of data out of the European Union) to identify risks and then determining the best controls to deploy to mitigate those risks. Privacy and security controls utilized to mitigate risks typically include the following:

• Data sharing agreements between controllers specifying the data they plan to share, who will have access and for what purpose, allowable data usages, term limits, and liabilities;
• Data use agreements for end users specifying the specific terms of use, including prohibitions against further data sharing without approval and re-identification of data subjects;
• Honest Broker agreements between controllers and Honest Brokers within the PPRL system, specifying the data Honest Brokers will receive from controllers, the allowed usages for said data, and whom the Honest Brokers can share data with;
• Business agreements with Tokenizer providers should Tokenization software need to be purchased or licensed;
• Policies at organizations receiving data (such as the Honest Broker, the host of the data platform, and the data users) that establish roles-based access to data, data protection, secure data storage, data retention and destruction, identity and authentication, regular monitoring of data access and data use, and oversight over the PPRL system;
• Sanctions for people who violate terms of agreements and privacy and security policies;
• Personnel granted with authority and responsibility for oversight over the system, which includes IT security, data privacy and protection officers, data governance and ethics councils, and data stewardship committees;
• Training on privacy, security, and confidentiality for staff who have access to the system and users of the data;
• Establishment of protocols for privacy breaches, including playbooks for containment, response, and informing those who are affected;
• IT technical controls that enable identity and authentication, role-based access, secure data storage, data retention and destruction, and monitoring of data access and data use;
• Secure transmission of data with encryption in transit to ensure sensitive information does not get leaked when transferring data between different parties in the system;
• Encryption and hardening of systems that hold sensitive information, such as the Honest Broker’s environments that hold lookup tables between different sets of tokens;
• Implementation of anti-virus and anti-malware programs on all systems where data is stored;
• Physical and technical security for all systems where data is stored; and
• Regular review and security audits of the system.

Several frameworks for establishing these controls exist that can be used to guide their implementation, such as the National Institute of Standards and Technology (NIST) Privacy Framework [19] and Cybersecurity Framework [20], International Standards Organization (ISO) and International Electrotechnical Commission (IEC) standards ISO/IEC 27001:2022 and ISO/IEC 27701:2019 [21,22], Federal Information Security Modernization Act (FISMA) control levels [23], Systems and Organization Controls 2 (SOC 2) [24], and Health Information Trust Alliance (HITRUST) cybersecurity framework [25].

3.4. Qualified Expert Evaluations

A key part of the PPRL system is an evaluation performed by qualified experts to ensure that privacy protections are in place throughout the record linkage process. This kind of evaluation is similar to the Expert Determination as defined under the HIPAA Privacy Rule [26]. The expert is not only looking for whether the resulting linked data is de-identified but also looking through the linkage process to ensure that data is not identifiable in any part of the linkage process. As such, the expert typically evaluates the following:

• If any PII gets transferred out of a controller’s environment during the tokenization process;
• Whether the tokens generated through the tokenization process could still be considered PII;
• Whether the information transferred by the Honest Broker back to data controllers or the data platform could be considered PII;
• Any additional re-identification risk to the de-identified datasets arising from the data linkage;
• Whether the controls implemented on the system ensure privacy protection throughout the PPRL process.

After performing a holistic evaluation on the entire PPRL system, the expert provides their report, which acts as evidence that the system can successfully conduct PPRL. They may also recommend some mitigations to be put into place to ensure privacy preservation in the report if they discover issues during their evaluation. While these evaluations have no set timeframe for expiry and renewal, due to changing technologies and the evolution of privacy regulations, setting up a regular schedule of reviews (i.e., annually) is recommended. Should there be significant changes to the system, such as the addition of new data controllers participating in the linkage system, the addition of new data to link, the switching of Honest Brokers, changing tokenization methods or providers, changing methods by which data users access and analyze the data, or changes to the data flow between different parties, then a re-evaluation may need to be performed.

4. Discussion

Our goal for presenting this framework is to describe a system architecture focused on privacy protection that is broadly applicable to many domains while being technology-agnostic. This framework can be used in two ways: (1) when looking at an existing PPRL system, we can use this framework to determine the roles of each party in the system, map out data flows between the different parties, and explain how the system protects privacy while producing linked data, and (2) when designing a new system, we can use this framework to identify the roles and responsibilities of the different parties who participate in the system and create a system architecture for the data flows between them. We will go into further detail as to how this framework accomplishes each use case in the following section.

4.1. Elucidation of Existing Systems

The usage of this framework can help with creating easy-to-understand explanations of the architectures of existing PPRL systems, as well as identifying the roles different parties play in the system and detailing their responsibilities. As an example, we can take the PPRL system currently in use by N3C to facilitate linkages for clinical research. When applying the framework, we can map roles to the different parties in the system; i.e., the clinical sites are data controllers, the Regenstrief Institute acts as the Honest Broker, Datavant is the Tokenization provider, N3C hosts the data platform and provides data governance for the system, researchers who apply for research access are data users, the National Center for Advancing Translational Sciences (NCATS) privacy office acts as the privacy officer overseeing the system, and Datavant and Regenstrief Institute provided their expert evaluation for the system [13,27]. After mapping out the roles, our framework also helps clarify the data transfers between different parties, which allows us to create a simple data flow diagram for the N3C ecosystem using the architecture presented in Figure 2 (shown in Figure 4). The N3C PPRL system also has many of the privacy-protecting system controls listed in Section 3.3 (as well as additional controls for government data systems) [14]. Thus, with this framework, we are able to reduce the complexity of the N3C PPRL system, gaining a clear understanding of the different parties’ roles and responsibilities, what data flows between these different parties, and how privacy is protected while data gets shared, linked, and analyzed.

4.2. Design of New PPRL Systems

The usage of this framework can provide developers of new PPRL systems with an overall system architecture that can enable PPRL, identifying all the different parties who should take part in the system, highlighting privacy and security controls that should be in place, and providing guidance on what to look for when engaging experts for an evaluation. Starting with the roles and responsibilities, the utilization of this framework ensures that the different parties participating in the linkage process get mapped to the key roles and identifies roles that are not filled by existing parties. Afterwards, either existing parties to the linkage take up multiple roles (when allowed), or the developers engage with new parties to fill those roles. Developers can then use the system architecture to map out the data flows between the parties. By following the architecture, developers ensure that no party within the system can access PII they do not already control. They then work with data governance and privacy officers to perform necessary assessments of the system and establish a set of system controls to mitigate identified risks. Finally, they have a qualified third-party perform an expert evaluation on the system to ensure privacy protection throughout the linkage process.

5. Conclusions

The key benefit to using this framework is that it can reduce complexities to focus on the privacy-protecting aspects of PPRL systems. It covers the key roles that should be present within such systems, how the data should flow between different parties to enable linkage while preventing the sharing of PII, the controls to be put on the system to ensure privacy protection, and the necessary components of privacy-protection evaluations. This framework can be used to clarify complexities within currently deployed PPRL systems to explain how they protect privacy while still enabling record linkage. It also helps developers designing PPRL systems build their system with a focus on privacy preservation while being technology agnostic.

Future research plans include the utilization of the framework to create new PPRL systems across various domains. Beyond the healthcare and health research domains where PPRL is already in use, the authors believe PPRL can also be applied to criminal justice data (e.g., facilitating linkages between criminal justice agencies to track criminals across jurisdictions or to map out criminal case proceedings), socioeconomic data (e.g., facilitating linkages between different social and economic surveys), other government data (e.g., used for determination of government benefit eligibility and identification of benefits fraud) and used in cross-domain research (i.e., linkage of healthcare data with social survey data to identify social determinants of health). In cases where there are potential overlapping populations and PII should not be shared, PPRL can be an option to enable linkages to create datasets with greater analytic utility while preserving privacy. The utilization of the framework presented in this paper can help researchers across many domains construct PPRL systems to create linked data for their research while ensuring privacy protection.