# Privacy-Preserving Linkage of Distributed Datasets using the Personal Health
Train

Maximilian Jugl
Department of Medical Data Science
University Medical Center Leipzig
Leipzig, Germany
<EMAIL_ADDRESS>
Sascha Welten
Chair of Computer Science 5
RWTH Aachen University
Aachen, Germany
<EMAIL_ADDRESS>
Yongli Mou
Chair of Computer Science 5
RWTH Aachen University
Aachen, Germany
<EMAIL_ADDRESS>
Yeliz U. Yediel
Department of Data Science and Artificial Intelligence
Fraunhofer FIT
Sankt Augustin, Germany
<EMAIL_ADDRESS>
Oya D. Beyan
Institute for Medical Informatics
Faculty of Medicine and University Hospital Cologne
Cologne, Germany
<EMAIL_ADDRESS>
Ulrich Sax
Department of Medical Informatics
University Medical Center Göttingen
Göttingen, Germany
<EMAIL_ADDRESS>
Toralf Kirsten
Department of Medical Data Science
University Medical Center Leipzig
Leipzig, Germany
<EMAIL_ADDRESS>

(September 12, 2023)

###### Abstract

With the generation of personal and medical data at several locations, medical
data science faces unique challenges when working on distributed datasets.
Growing data protection requirements in recent years drastically limit the use
of personally identifiable information. Distributed data analysis aims to
provide solutions for securely working on highly sensitive data while
minimizing the risk of information leaks, which would not be possible to the
same degree in a centralized approach. A novel concept in this field is the
Personal Health Train (PHT), which encapsulates the idea of bringing the
analysis to the data, not vice versa. Data sources are represented as train
stations. Trains containing analysis tasks move between stations and aggregate
results. Train executions are coordinated by a central station which data
analysts can interact with. Data remains at their respective stations and
analysis results are only stored inside the train, providing a safe and secure
environment for distributed data analysis.

Duplicate records across multiple locations can skew results in a distributed
data analysis. On the other hand, merging information from several datasets
referring to the same real-world entities may improve data completeness and
therefore data quality. In this paper, we present an approach for record
linkage on distributed datasets using the Personal Health Train. We verify
this approach and evaluate its effectiveness by applying it to two datasets
based on real-world data and outline its possible applications in the context
of distributed data analysis tasks.

The source code for the services and analysis scripts mentioned in this paper
is open source and available from the authors111The source code is located at
https://gitlab.com/ul-mds/record-linkage/infrastructure..

_Keywords_ Distributed Computing $\cdot$ Distributed Datasets $\cdot$
Incremental Learning $\cdot$ Federated Learning $\cdot$ Record Linkage $\cdot$
Cybersecurity $\cdot$ Data Privacy $\cdot$ Data Protection $\cdot$
Containerization

##  1 Introduction

###  1.1 Distributed datasets

In the medical domain, new data is generated on a daily basis. We observe
various types of data, such as structured data in the shape of electronic
health records, textual data from written diagnostic reports, image data from
MRI and CRT scans and genetics data for research purposes. With large amounts
of multi-faceted data, multiple perspectives have to be considered at once,
such as the challenge of efficiently and effectively managing data, capturing
patient data in an appropriate and timely manner, and the eventual analysis of
captured data by researchers to support practicing medical personnel in their
daily tasks.

In a data analysis undertaking spanning multiple institutions, the common
approach is to collect all required data in a central location first. This is
not without its own challenges. First, with growing data protection
requirements, as enforced by the GDPR in the European Union for example [30],
sensitive data has to be carefully anonymized so that re-identification of
natural persons is infeasible. Second, datasets must be submitted over a
secure channel, where the dataset size and the communication overhead can
greatly impact the time needed for a successful transfer. Third, with a
transmission of data from one domain to another comes a loss of sovereignty
for the original data holders, effectively diminishing their say in how the
data they provide can and should be used.

As such, a recent paradigm shift in the field of medical data science is to
favor distributed data analysis approaches, where data analysis is performed
at the respective data sources. Over the last decade, research in this area
gave way to novel concepts and implementations to enable data analysis while
respecting data ownership. Galaxy [13] enables the effective communication of
analysis tasks between multiple parties. Local installation of their software
allows data providers to work on their data without exposing it to others.
ELIXIR [9] acts as an all-in-one provider of data analysis solutions,
represented as several platforms, for scientific purposes in Europe. A central
hub near Cambridge handles administrative tasks and coordinates nodes in $23$
European countries, where a node is accessed by multiple institutions within
that country. DataSHIELD [12] takes this one step further by allowing
researchers to write their analysis tasks as R scripts that are executed in a
distributed way using a custom client-server infrastructure. PADME [31], PHT-
meDIC [14] and VANTAGE6 [17] are implementations of the Personal Health Train
[1], which frees data analysts from constraints on how to define their data
analysis tasks.

###  1.2 Personal Health Train

The Personal Health Train (PHT) follows the analogy of a train which moves
between stations, where the train represents a data analysis task and the
stations represent the respective data holding organizations [1]. All current
PHT implementations use a container-based approach to package analysis tasks
and to transmit them between institutions, which allows data scientists to
freely choose the tools they need to perform their analysis tasks. A broad
overview of the PHT workflow is shown in Fig 1 using the PADME implementation
as an example.

Figure 1: Overview of the PHT using the PADME implementation as an example. A
data scientist submits an analysis script to the Central Service, which
packages it into a train using container-based technologies and orchestrates
the execution between institutions, called stations. Results are aggregated
and reported back to the data scientist.

A data scientist interacts with the Central Service (CS). They submit their
analysis task as an executable script to the CS, where it is then packaged
into a train class with all required dependencies. The train class acts as a
template for trains that are created from it. Once the train class has been
created, the data scientist can select it and a number of target stations. A
train, which is effectively an executable container, is then created from the
selected train class and the participating stations are informed of the train.
The station order is defined by the data scientist.

Station administrators run their stations through a piece of on-premise
software. They may pull trains or reject them if they suspect them to be
malicious. Before a train is executed, the station administrators have the
option to supply variables for the execution of the analysis script. This is
necessary to provide URLs to services that provide data, as well as
authentication credentials for access to these services and other
configuration parameters. Once train execution has finished, the results are
packaged into the train and sent off to the next station.

After the train has been executed at all stations, the final train is sent
back to the CS. Results are extracted from the train and provided to the data
scientist. At no point did the data scientist ever obtain access to
confidential data. Access to sensitive data sources remains at the
participating institutions. The only PHT component that the data scientist has
to interact with to perform a distributed data analysis task is the CS.

Multiple recent use cases using the PHT prove its potential as a functional
mean to enabling distributed data analysis [18, 33]. In cases where a
centralized study has been performed in the past, running the same study in a
decentralized way using the PHT shows no to minimal deviation in the quality
of the obtained results [32].

###  1.3 Problem statement

In distributed datasets, it is possible for duplicates to manifest that refer
to the same real-world entity. Within the medical domain, these entities are
usually patients that seek treatment at multiple locations. In a patient’s
lifetime medical history, it is common to seek treatment at multiple
healthcare providers, such as being referred by one’s own general practitioner
to obtain a verified diagnosis that they cannot make, or seeking special
treatment for a rare disease type.

The process of identifying similar records within one or multiple datasets is
called data matching or record linkage [5]. Duplicates in distributed datasets
can skew the outcome of an analysis task, yet they may also present the
opportunity of fusing multiple information sources together. Though record
linkage algorithms have been extensively studied and applied to centralized
datasets, very few have applied them in a distributed environment. This is
rooted in the inherent challenges of record linkage.

Linkage using a permanent identifier, like a person’s health insurance number,
passport ID, identity card number or social security number would facilitate
this process tremendously, yet they are subject to strict data privacy and
data sharing protections. Additionally, healthcare providers may only store a
subset of the aforementioned identifiers, shrinking the potential overlap in
distributed datasets.

As such, record linkage relies on combining a multitude of so-called quasi-
identifiers (QIDs) to identify similar records [35]. These are stable
identifiers that are unlikely to change over a long period of time, such as a
patient’s first and last name, sex and birth date. Yet since combining these
identifiers allows one to uniquely identify a person with high precision, they
are subject to the same data protection guidelines as the mentioned
identifiers. Releasing identifying information past institutional borders for
the purpose of record linkage therefore poses a great risk for data providers
and the privacy of the entities that are supposed to be linked.

Using the distributed data analysis execution platform that the PHT provides,
we propose an approach to record linkage with distributed datasets which does
not require data providers to share identifying data outside their own
borders.

###  1.4 Related work

Though all of the following works present ways on how to integrate record
linkage into real-life environments, just a select few propose workflows on
distributed datasets. None so far have sought the PHT as their platform of
choice.

Randall et al. [24] performed an evaluation of a Bloom filter based record
linkage protocol on datasets with a total of $26$ million hospital admission
records. They showed that Bloom filters can scale well to large datasets and
provided a workflow to improve scalability without severely affecting linkage
quality. However, the setup was performed locally and not in a distributed
environment.

Yigzaw et al. [36] designed a record linkage protocol based on Bloom filters
for disease surveillance across three laboratories that specialize in the
testing for strains of influenza. Their approach manages to stay performant
while ensuring security in a setting with semi-honest adversaries.

Nguyen et al. [19] performed an evaluation of the GRHANITE software in a
public health surveillance system. They used two separate gold standard
datasets sourced from several clinical sites in Australia, including uniquely
identifiable attributes such as electronic medical record numbers. The authors
opted for a deterministic linkage approach which, while reliable in most
cases, provides limited error tolerance due to the nature of this approach.

Stammler et al. [27] extended the medical record database software
Mainzelliste with a modified version of the EpiLink software by Contiero et
al. [8] to enable secure multi-party privacy-preserving record linkage. Their
linkage algorithm is based on Bloom filters, but the integrity and privacy of
shared data between participating clients is preserved using a tunneled
connection. However, the integration into Mainzelliste imposes a strong
software dependency that may not be implementable in certain environments.

Nóbrega et al. [21] recently published a novel protocol using Bloom filters
using Blockchain technology and applied it to real-world datasets. Their main
motivation for this approach was to provide security beyond the commonly
considered honest-but-curious adversary model. Since then, Christen et al. [6]
published an attack on the protocol which has been considered and mitigated by
the original authors [22].

##  2 Materials and methods

###  2.1 Overall approach

We developed an approach for performing record linkage on distributed datasets
using the PHT. Fig 2 demonstrates the two-phase record linkage execution
within the PHT.

Figure 2: Overview of the record linkage execution within the PHT. In the
first phase, stations are prompted to encode records into a non-reversible bit
vector form and to submit these to a Central Linkage Unit. After matching has
concluded, results are fetched from the Central Linkage Unit at each station.

In the “submission” phase, the data analyst sends their record linkage script
along with a configuration file to the central service. They select the
participating stations and dispatch the record linkage train. At each station,
the train starts the process of sourcing relevant records, pre-processing and
masking them into a non-reversible bit vector form while preserving
similarities between near-identical records. These bit vectors are then sent
to a Central Linkage Unit (CLU), which asynchronously performs matching on the
provided bit vectors.

In the “result” phase, the data analyst dispatches the same train for a second
time. Once the train arrives at the station, it prompts the retrieval of
results from the CLU for that particular station. The train itself receives
identified matches in a pseudonymized form, so that the train never comes into
contact with any personal data. These results can be used to perform informed
decisions on how to treat duplicates in a subsequent data analysis task. The
following sections describe the process in more detail.

###  2.2 Train execution

We developed several standalone web services that enable record linkage with
distributed datasets: a Resolver, Encoder, Broker and Matcher service. An
architectural overview of their integration into the PADME PHT implementation
is presented in Fig 3. Although our research focuses on the interoperability
with the PHT, our services do not rely on any PHT component and can be freely
made to fit with any architecture where client-server interactions are
possible.

Figure 3: Integration of record linkage services into the PHT infrastructure.
Custom components are highlighted in bold. Trains carry the scripts necessary
to communicate with the Resolver service at each station and report identified
matches back to the Central Service.

#### Components

Our services are split up into station-side and central components. The
Resolver service is hosted on-premise at every participating station. Its
purpose is to look up study-specific pseudonyms in the station’s Master
Patient Index (MPI). For our purposes, we opted for E-PIX as the patient
database and gPAS as the pseudonymization service from the MOSAIC suite of
tools to act as an MPI in combination [2, 3]. These services offer an
intuitive user interface for data providers, as well as a SOAP interface for
integration into other software. However, the Resolver offers flexibility to
integrate with other MPI software solutions. The Resolver leverages the
Encoder service, which performs data pre-processing and masking based on a
hash-based approach using Bloom filters [25] on the records obtained from the
MPI. The result is a bit vector for every record which obfuscates the original
data while preserving their similarity. The CLU is composed of the Broker
service which takes in bit vectors from all stations. Similarities between bit
vectors are computed by the Matcher service and reported back to the Broker,
which provides results to the participating stations.

#### Workflow

As mentioned before, a record linkage execution within the PHT consists of two
phases. These two phases make up a matching session. In the first “submission”
phase, the data analyst who wants to perform record linkage selects the
corresponding train image at the Central Service, the participating stations
and provides the necessary configuration which is packaged into the train. The
record linkage configuration consists of a random session identifier and a
matching threshold between $0\text{\,}\mathrm{\char 37\relax}$ and
$100\text{\,}\mathrm{\char 37\relax}$. Upon arrival of the train, station
administrators provide a link to the Resolver service hosted at the station,
as well as a list of study-specific pseudonyms.

Once train execution commences at the station, an executable script inside the
train submits the supplied pseudonyms as well as the record linkage
configuration to the Resolver service at the station. The Resolver looks up
the provided pseudonyms in the MPI and converts the personal data records into
bit vectors using the Encoder service. Finally, the Resolver generates a
random client identifier, ties it to the session identifier locally, and
passes both with the record linkage configuration and the list of bit vectors
to the CLU. The first phase has concluded once all participating stations have
performed this process.

Between phases, the CLU performs asynchronous matching using the bit vectors
submitted by the stations. The submitted station and client identifiers are
used by the Broker service to tell bit vectors from different stations apart,
as well as consolidating bit vectors that are supposed to be matched against
one another. Given bit vectors from two separate stations, the Matcher
performs a cross product on them and computes their similarity using the
Jaccard index. Similarities above the threshold specified in the PPRL
configuration are reported back to the Broker, which aggregates these results.

In the second “result” phase, the data analyst sends the same PPRL train for a
second iteration to all participating stations. The script inside the train
contacts the Resolver hosted at the station. The Resolver looks up the client
identifier generated in the previous phase using the session identifier and
requests results from the Broker. Finally, the Resolver passes the results
along to the train, converting them back into their pseudonymized form. This
means that by the end of the second phase, every station will have a list of
pseudonyms that refer to records that have a match with at least another
record at a different station. The train itself would have had no access to
sensible data during the entire session.

###  2.3 Data preprocessing

The QIDs withing a record are first preprocessed at their respective stations.
The aim is to convert all records into a unified representation across all
stations, so that record linkage is successful even in the presence of
different character encodings and naming conventions. This is done by
performing the following series of steps for every field of a record:

  1. 1.

Ligatures (e.g. ß, æ, œ) are replaced with their non-ligature forms (e.g. ss,
ae, oe).

  2. 2.

Diacritics are separated from the characters they apply to by performing
Unicode normalization in the KD form.

  3. 3.

Non-ASCII characters are removed.

  4. 4.

All characters are converted to lowercase.

  5. 5.

Multiple consecutive whitespaces are reduced into one.

###  2.4 Masking technique

Masking is the key step in ensuring that the privacy of the matched records is
preserved. If all records are sent to the CLU as they are, then the CLU
administrator has access to all records across all stations, posing a big risk
of a potential private data breach. Even if it is assumed that the CLU is
hosted by a trustworthy third party, malicious actors could obtain access to
the original records if the CLU is ever compromised. As such, it is necessary
to make sure that the records are transmitted in a masked form such that re-
identification attacks on masked records are computationally infeasible.

Bloom filters have seen wide adoption in privacy-preserving record linkage
(PPRL) protocols as a data structure that can obfuscate the data that is
inserted into it while preserving similarities. Since the inception of Bloom
filters in the field of PPRL, many security recommendations have been proposed
to make them more resilient to re-identification attacks [15, 20, 7].
According to current security recommendations for Bloom filters in PPRL, we
chose to implement the following measures.

We used CLKRBF as our masking technique [29]. The tokenized values of a record
are hashed into the same Bloom filter, but the amount of hashes is decided on
weights assigned to a record’s attributes. Consequentially, attributes with a
higher weight likely occupy more bits in the resulting Bloom filter. The
reason for this approach is that some attributes, like first and last name,
have a higher discriminatory power than others, like gender [10]. We computed
the weights by generating a random list of values for each attribute,
splitting them into unique text tokens and then computing the entropy across
all values for an attribute.

Further security measures we implemented were to use HMAC-SHA-256 as a keyed
hash function, apply random hashing, attribute salting, as well as balancing
and randomly permuting Bloom filters after the masking step [20, 26]. All
these techniques mitigate basic dictionary and frequency attacks, as well as
known cryptanalytic attacks on Bloom filters based on their Hamming weights at
the time of writing.

##  3 Results

We used the readily available PADME PHT stations at the RWTH Aachen
University, the University of Applied Sciences Mittweida and the University
Medical Center Leipzig to validate our suggested approach to record linkage on
distributed datasets. We performed two experiments with two different
datasets. The source code for the generation of these datasets, as well as the
software components we developed, is available from the authors.

For our first experiment, we used the North Carolina Voter Registration (NCVR)
dataset222The data is available at https://www.ncsbe.gov/results-data/voter-
registration-data. We used a snapshot of statewide voter registrations from
February 16th, 2023. This dataset has been used to test several record linkage
applications in the past [16, 10, 11, 23]. Its popularity stems from the fact
that it contains real-world data sourced from a large population. It is a
public record of registered voters in the state of North Carolina where a
large number of personally identifiable attributes are tracked for every
person. These attributes include first, middle and last name, gender, year of
birth, residential and mail address, party affiliation, phone number and
supplemental information on the record itself. Every person in the NCVR
database has a unique identifier called NCID. We performed data cleaning by
only keeping records that abide by the following rules.

  * •

person must have an active and verified record

  * •

person must have been at least $16$ years old on their registration date

  * •

person must be no older than $120$ years

  * •

record must not be marked as confidential

  * •

residential and mail zip codes must be either five or nine characters in
length and must not be all zeros

  * •

phone numbers must not be all zeros

After this process, about $6.1$ million records remain from the original $8.2$
million records. From the cleaned dataset, we selected first and last name,
gender, year of birth and city of residence to be used for our record linkage
experiment.

We created three files with approximately $5000$ records each, where all files
have $100$ records in common. To select records, we grouped all records by
first and last name and counted the amount of records in each group, which we
refer to as group size. For each group size up to five, we then randomly
selected records drawn from each group such that every group size contributes
about a fifth of all records to the final dataset, which is composed of
$14\,800$ unique records across all files. The distribution of records with
respect to the group sizes they were drawn from is shown in Tab 1.

Table 1: Amount of selected records in the final dataset with respect to group size based on distinct first and last names in the NCVR dataset Group size | # Total records | # Selected records
---|---|---
$1$ | $2\,975\,253$ | $2971$
$2$ | $668\,560$ | $2992$
$3$ | $358\,608$ | $2901$
$4$ | $240\,640$ | $2784$
$5$ | $179\,465$ | $2910$
$\Sigma$ | $4\,422\,526$ | $14\,558$

Finally, we selected $100$ records at random and inserted them into each of
the three files. We inserted each of the remaining $14\,700$ records into one
of the three files at random. The amount of records for each file is shown in
Tab 2.

Table 2: Amount of records in each file for our record linkage experiment with the NCVR dataset File | # Records
---|---
$1$ | $4981$
$2$ | $4945$
$3$ | $4832$

We assigned the files to the participating stations at random, so that each
station holds one of the three files. The station administrators were provided
a mapping to import the given files into the data schema of their on-premise
E-PIX instance. Knowing that only exact matches were supposed to be found, we
set the match threshold for the train execution accordingly to
$100\text{\,}\mathrm{\char 37\relax}$. We used the NCIDs of predicted matching
pairs to classify them as true or false positives.

We were able to identify all true matches while only accumulating three false
positives, yielding a F1-score of $99.5\text{\,}\mathrm{\char 37\relax}$. The
false positives are a result of the limited subset of attributes we chose.
Upon review, we found that the affected records were sufficiently different
from one another when observing all attributes of the NCVR dataset. However,
by chance alone, the false positives we identified were indeed identical by
our choice of attributes.

For our second experiment, we generated a synthetic dataset with built-in
typographic errors to validate the error-resistance of our approach. We used
German first names, surnames and city names with respective frequency
information from publicly available data sources. We used the GeCo framework
[28] to generate a file containing $1000$ personal records. The distribution
of the aforementioned attribute values was modeled after their real-life
frequencies. We also added a randomly generated gender and birth date to each
record.

Next, we generated two corrupted versions of the original file by randomly
introducing typographic errors commonly found in the real world. These include
optical character recognition errors, phonetic errors, input errors, e.g. by
pressing a neighboring key on a keyboard, and edit errors, such as random
insertion, deletion or substitution of a character. Finally, we shuffled the
records between the three files in a way that ensured that matches could only
be found between files, not in one and the same file. As with the first
dataset, we randomly assigned each file to one of the three participating
stations and provided the mappings for the E-PIX import to all station
administrators.

For our synthetic dataset, we opted for a more conservative matching threshold
of $70\text{\,}\mathrm{\char 37\relax}$. We found this threshold to be a
reasonable choice in prior testing with similar datasets using our
infrastructure. In our train execution, we achieved an F1-score of
$99.3\text{\,}\mathrm{\char 37\relax}$. Out of $1157$ possible true matches,
we accumulated only four false positives and $12$ false negatives, as
represented in Tab 3. This result is impressive, considering the amount of
true non-matches is bigger by about three orders of magnitude compared to the
amount of matches.

Table 3:  Confusion matrix of predicted matches and non-matches at a $70\text{\,}\mathrm{\char 37\relax}$ threshold  | True matches | True non-matches | $\Sigma$
---|---|---|---
Predicted matches | $1145$ | $4$ | $1149$
Predicted non-matches | $12$ | $1\,142\,091$ | $1\,142\,103$
$\Sigma$ | $1157$ | $1\,142\,095$ |

Finally, we conducted a statistical analysis on both datasets to evaluate our
threshold choices. We ran the same linkage procedures using a local setup with
varying thresholds, ranging from $0\text{\,}\mathrm{\char 37\relax}$ to
$100\text{\,}\mathrm{\char 37\relax}$ in $1\text{\,}\mathrm{\char 37\relax}$
increments. At every threshold, we computed precision, recall and F1-score.
The resulting plots are shown in Fig 4.

Figure 4: Precision, recall and F1-score depending on the selected match
threshold. Measures were taken using our experimental datasets. Samples were
taken in $1\text{\,}\mathrm{\char 37\relax}$ threshold increments.

For the NCVR dataset, we observed a sharp decline in match quality around the
$95\text{\,}\mathrm{\char 37\relax}$ threshold. The F1-score declined slowly
between $90\text{\,}\mathrm{\char 37\relax}$ and $75\text{\,}\mathrm{\char
37\relax}$ before falling off drastically again and leveling off below
$60\text{\,}\mathrm{\char 37\relax}$. Since we chose records in groups based
on distinct first and last names, a base level of similarity is present in a
significant number of record pairs. This explains the first drop-off as
records with identical first and last names are being recognized as matches.
The second, significantly more prolonged drop-off is caused by record pairs
that are decisively unlike one another.

For our synthetic dataset, we found that our threshold of choice at
$70\text{\,}\mathrm{\char 37\relax}$ was not far off the threshold which
maximized the F1-score on our synthetic dataset. At a threshold of
$68\text{\,}\mathrm{\char 37\relax}$, the amount of false negatives dropped
down to four, raising the F1-score to $99.7\text{\,}\mathrm{\char 37\relax}$.
Furthermore, we found that all true matches were classified as such at a
threshold of $66\text{\,}\mathrm{\char 37\relax}$. However, false positives
increased drastically with lower thresholds. On the opposite end, the first
false positive was reported at a threshold of $84\text{\,}\mathrm{\char
37\relax}$, while about $40\text{\,}\mathrm{\char 37\relax}$ of true matches
were already being identified as such.

##  4 Discussion

###  4.1 Security implications of the PHT

The PHT concept allows the execution of arbitrary analysis tasks on medical
data provided by healthcare institutions. This is desirable for data
scientists who act in good faith and wish to use the statistical tools and
programming languages that they are familiar with, but this still poses a
major threat to data protection and privacy. Therefore PHT implementations
must provide security guarantees to mitigate unauthorized access to and
distribution of medical data. We consider possible attack vectors for a
malicious actor aiming to exfiltrate medical data using the PHT and show
mitigations at the example of PADME and PHT-meDIC.

Both PADME and PHT-meDIC employ a manual approval process for incoming trains.
Station administrators must first inspect and confirm that they wish to
execute a train at their station. The code packaged inside a train is always
public and should be used by station administrators to conclude what the
train’s purpose is and which data sources it aims to connect to. This allows
them to reject trains that have been sent to a station due to human error or
malicious intent.

Furthermore, both PADME and PHT-meDIC require data sources to be defined
manually. For PADME, connection details must be provided before the train is
executed. This allows the data holders to configure their data sources in a
way that mitigates illegal operations and to limit the train’s view on the
required data. PHT-meDIC completely denies network access to the train. Data
sources are mounted into the train as a read-only volume. This further
mitigates the train’s abilities to retrieve and share information outside of
institutional borders.

Results of a train execution at a station must be securely stored, and PADME
and PHT-meDIC choose different ways to ensure that no unauthorized party may
be able to inspect results. PADME employs the use of public-key cryptography.
The Central Service and all stations maintain their own keypairs which are
used to encrypt trains and the results that are packaged into them after each
train execution. PHT-meDIC goes one step further by cryptographically signing
trains to ensure that trains are only executed by trusted parties. Results
from a train execution at a station are not stored within the train but rather
encrypted using homomorphic encryption. Only the data scientist running the
analysis task using PHT-meDIC may decrypt the results which ensures that
analysis artifacts submitted to the central service cannot be read by its
administrators.

At the time of writing, manual review and approval of train, manual
configuration of data sources, restricting network access, result encryption
and train signatures summarize the scope of security practices of both PADME
and PHT-meDIC. This serves to ensure that medical data is not leaked to
untrusted parties, but puts a major responsibility on station administrators.
They must diligently inspect trains before executing them and ensure that the
data sources are properly configured. The public nature of both PHT
implementations gives them the necessary tools to validate trains and approve
or deny their execution on site.

###  4.2 Attacks on the record linkage protocol

Cryptanalysis of Bloom filters in privacy-preserving record linkage protocols
has been conducted in the past with the consensus being that basic field-level
Bloom filters provide no meaningful security for data that is meant to be
obfuscated [20, 15, 7]. We chose to adapt our use of Bloom filters for PPRL in
line with current security recommendations, which make re-identification
attacks infeasible. Instead of providing a formal cryptanalysis of Bloom
filters in our protocol, we present the scope of possible attack vectors that
malicious actors could abuse in our approach.

There are three main actors who take part in a PPRL execution within the PHT.
The first actor is the data scientist. Since they only interact with the
Central Service, there is no way for them to get access to the underlying
container infrastructure. Their only entrypoint for attack is the PPRL
container image, which can be freely adjusted. This means that a malicious
data scientist could include malicious code in the PPRL train image that is
then executed at the participating stations. However, within the context of
the PPRL workflow as described in this paper, there is no way to obtain
unauthorized access to confidential patient data. The only information that
could be leaked are the pseudonyms provided at every station, which inherently
do not represent personally identifiable information. Since the Resolver
service is the sole component responsible for handling depseudonymized data,
there is no feasible way of leaking confidential data from it using a
malicious PPRL train image either. Furthermore, the PADME PHT implementation
allows station administrators to deny the execution of a train image that they
do not trust.

The second actor is the station administrator. Since they are restricted to
executing or rejecting trains, there are no means for the station
administrator to achieve unauthorized data access. They have no access to the
underlying container infrastructure that is managed by the station software
and can therefore not leak results from executions at previous stations. Since
the PPRL train is not supposed to store sensitive data in the first place, it
is not possible to infer patient data from other stations.

The third actor is the administrator of the CLU. They are the weakest link,
since we assume a trusted third party setting and therefore do not consider
their entire attack scope in a practical setting. However, a bad actor in this
position has a few options. The central linkage unit receives and processes
bit vectors submitted by all stations. We assume that a re-identification
attack is too compute-intensive and therefore infeasible. However, suppose
there are matching bit vectors across all participating stations of a PPRL
execution. Given the metadata attached to these bit vectors, it would be an
easy task for a malicious CLU administrator to make assumptions about the
medical or treatment history of a patient that produced these bit vectors.
This greatly limits the search scope, though this knowledge is still useless
without prior knowledge about personal patient details. Furthermore, if the
secret for the authenticated hash digest in the masking step is changed in
every train execution, then inferring information during multiple train
executions is not possible for the CLU administrator.

Another attack vector for a CLU administrator is to disrupt the PPRL
execution. Since the assignment of clients to a match session is handled by
the central linkage unit, a malicious CLU administrator could assign submitted
bit vectors to arbitrary match sessions, therefore impacting the usefulness of
the reported results. It is also possible to simply withhold match results or
to inject false match results.

###  4.3 Federated train execution

Our proposed approach performs a train execution in two round trips. This
incremental workflow comes down to the fact that all participating stations
are processed sequentially. In theory, a federated workflow where all stations
are processed simultaneously is also possible and would require a single round
trip instead.

A train class for this federated approach is prepared. All participating
stations are selected and the train is dispatched. Once at a station, the
train performs the usual workflow of submitting pseudonyms to the Resolver
service. However, instead of terminating, the PPRL train queries the progress
of the match session and waits for it to reach completion. As soon as all
stations have submitted their bit vectors and matching has been carried out,
all trains submit a request to the Resolver to fetch the results from the
broker. The main challenge lies in coordinating all stations to perform their
submission step in a similar time frame. Suppose that in a setup with three
stations, two execute the train immediately and one does so only an hour later
after receiving, there is currently no way for the Broker service to tell when
matching is to be considered finished. In the worst case, the first two
stations request their results too early, omitting potential matches with the
third station. A federated version of the train used in our approach is
actively being worked on.

###  4.4 Future improvements

We used a simple measure for estimating attribute weight based on their
discriminatory power. Though weight estimation algorithms for record linkage
exist [34, 4], none of them can be applied to blind record linkage, meaning
that known algorithms which are mostly based on the Fellegi-Sunter model of
record linkage cannot be applied to PPRL, since we do not have the datasets to
be matched available to us. In the future, we hope to develop and evaluate
more advanced algorithms for blind attribute weight estimation.

The same applies to the threshold estimation. We chose a threshold based on
prior knowledge about the data to be matched and previous experiments. A
future area of research concerns the study of thresholds based on the chosen
masking technique and input data.

While the GeCo framework is decent at generating authentic-looking datasets
with a variety of options for common errors to induce, the data it generates
is still synthetic. We are actively working on cooperating with personal data
providers to create use cases around our approach to PPRL to prove its
effectiveness in real-world settings.

##  5 Conclusion

We presented an approach to perform record linkage on distributed datasets
using the PHT. The PHT enables data holding organizations to allow access to
their personal records without leaking sensitive information beyond
institutional borders. Inferring information from masked records is infeasible
with the security measures we chose to implement, keeping the chance of a
successful re-identification attack at a minimum. We validated this approach
in two experiments with two different synthetic datasets with respect to the
quality of the identified matches and the typographic error-resistance. In the
future, we aim to demonstrate our approach in real-life scenarios.

## References

  * [1] Oya Beyan et al.  “Distributed Analytics on Sensitive Medical Data: The Personal Health Train”  In _Data Intelligence_ 2.1-2, 2020, pp. 96–107  DOI: 10.1162/dint\\_a\\_00032
  * [2] M. Bialke et al.  “MOSAIC – A Modular Approach to Data Management in Epidemiological Studies” Publisher: Georg Thieme Verlag KG  In _Methods of Information in Medicine_ 54.04, 2015, pp. 364–371  DOI: 10.3414/ME14-01-0133
  * [3] Martin Bialke et al.  “A workflow-driven approach to integrate generic software modules in a Trusted Third Party” Number: 1 Publisher: BioMed Central  In _Journal of Translational Medicine_ 13.1, 2015, pp. 1–8  DOI: 10.1186/s12967-015-0545-6
  * [4] Tony Blakely and Clare Salmond  “Probabilistic record linkage and a method to calculate the positive predictive value”  In _International Journal of Epidemiology_ 31.6, 2002, pp. 1246–1252  DOI: 10.1093/ije/31.6.1246
  * [5] Peter Christen  “The Data Matching Process”  In _Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection_ , Data-Centric Systems and Applications  Berlin, Heidelberg: Springer, 2012, pp. 23–35  DOI: 10.1007/978-3-642-31164-2_2
  * [6] Peter Christen, Rainer Schnell, Thilina Ranbaduge and Anushka Vidanage  “A critique and attack on “Blockchain-based privacy-preserving record linkage””  In _Information Systems_ 108, 2022, pp. 101930  DOI: 10.1016/j.is.2021.101930
  * [7] Peter Christen, Rainer Schnell, Dinusha Vatsalan and Thilina Ranbaduge  “Efficient Cryptanalysis of Bloom Filters for Privacy-Preserving Record Linkage”  In _Advances in Knowledge Discovery and Data Mining_ , Lecture Notes in Computer Science  Cham: Springer International Publishing, 2017, pp. 628–640  DOI: 10.1007/978-3-319-57454-7_49
  * [8] P. Contiero et al.  “The EpiLink Record Linkage Software” Publisher: Schattauer GmbH  In _Methods of Information in Medicine_ 44.1, 2005, pp. 66–71  DOI: 10.1055/s-0038-1633924
  * [9] Lindsey C. Crosswell and Janet M. Thornton  “ELIXIR: a distributed infrastructure for European biological data” Publisher: Elsevier  In _Trends in Biotechnology_ 30.5, 2012, pp. 241–242  DOI: 10.1016/j.tibtech.2012.02.002
  * [10] Elizabeth A. Durham et al.  “Composite Bloom Filters for Secure Record Linkage” Conference Name: IEEE Transactions on Knowledge and Data Engineering  In _IEEE Transactions on Knowledge and Data Engineering_ 26.12, 2014, pp. 2956–2968  DOI: 10.1109/TKDE.2013.91
  * [11] Elizabeth Ashley Durham  “A framework for accurate, efficient private record linkage” Accepted: 2020-08-22T00:02:52Z, 2012  URL: https://ir.vanderbilt.edu/handle/1803/11417
  * [12] Amadou Gaye et al.  “DataSHIELD: taking the analysis to the data, not the data to the analysis”  In _International Journal of Epidemiology_ 43.6, 2014, pp. 1929–1944  DOI: 10.1093/ije/dyu188
  * [13] Jeremy Goecks, Anton Nekrutenko, James Taylor and The Galaxy Team  “Galaxy: a comprehensive approach for supporting accessible, reproducible, and transparent computational research in the life sciences”  In _Genome Biology_ 11.8, 2010, pp. R86  DOI: 10.1186/gb-2010-11-8-r86
  * [14] Marius de Arruda Botelho Herr et al.  “Bringing the Algorithms to the Data – Secure Distributed Medical Analytics using the Personal Health Train (PHT-meDIC)” arXiv:2212.03481 [cs]  arXiv, 2022  DOI: 10.48550/arXiv.2212.03481
  * [15] Mehmet Kuzu, Murat Kantarcioglu, Elizabeth Durham and Bradley Malin  “A Constraint Satisfaction Cryptanalysis of Bloom Filters in Private Record Linkage”  In _Privacy Enhancing Technologies_ , Lecture Notes in Computer Science  Berlin, Heidelberg: Springer, 2011, pp. 226–245  DOI: 10.1007/978-3-642-22263-4_13
  * [16] Mehmet Kuzu et al.  “A practical approach to achieve private medical record linkage in light of public resources”  In _Journal of the American Medical Informatics Association_ 20.2, 2013, pp. 285–292  DOI: 10.1136/amiajnl-2012-000917
  * [17] Arturo Moncada-Torres et al.  “VANTAGE6: an open source priVAcy preserviNg federaTed leArninG infrastructurE for Secure Insight eXchange”  In _AMIA Annual Symposium Proceedings_ 2020, 2021, pp. 870–877  URL: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8075508/
  * [18] Yongli Mou et al.  “Distributed Skin Lesion Analysis Across Decentralised Data Sources” Publisher: IOS Press  In _Public Health and Informatics_ , 2021, pp. 352–356  DOI: 10.3233/SHTI210179
  * [19] Long Nguyen et al.  “Privacy-Preserving Record Linkage of Deidentified Records Within a Public Health Surveillance System: Evaluation Study” Company: Journal of Medical Internet Research Distributor: Journal of Medical Internet Research Institution: Journal of Medical Internet Research Label: Journal of Medical Internet Research Publisher: JMIR Publications Inc., Toronto, Canada  In _Journal of Medical Internet Research_ 22.6, 2020, pp. e16757  DOI: 10.2196/16757
  * [20] Frank Niedermeyer, Simone Steinmetzer, Martin Kroll and Rainer Schnell  “Cryptanalysis of Basic Bloom Filters Used for Privacy Preserving Record Linkage”, 2014  DOI: 10.2139/ssrn.3530867
  * [21] Thiago Nóbrega, Carlos Eduardo S. Pires and Dimas Cassimiro Nascimento  “Blockchain-based Privacy-Preserving Record Linkage: enhancing data privacy in an untrusted environment”  In _Information Systems_ 102, 2021, pp. 101826  DOI: 10.1016/j.is.2021.101826
  * [22] Thiago Nóbrega, Carlos Eduardo S. Pires and Dimas Cassimiro Nascimento  “Explanation and answers to critiques on: Blockchain-based Privacy-Preserving Record Linkage”  In _Information Systems_ 108, 2022, pp. 101935  DOI: 10.1016/j.is.2021.101935
  * [23] Thilina Ranbaduge and Rainer Schnell  “Securing Bloom Filters for Privacy-preserving Record Linkage”  In _Proceedings of the 29th ACM International Conference on Information & Knowledge Management_, CIKM ’20  New York, NY, USA: Association for Computing Machinery, 2020, pp. 2185–2188  DOI: 10.1145/3340531.3412105
  * [24] Sean M. Randall et al.  “Privacy-preserving record linkage on large real world datasets”  In _Journal of Biomedical Informatics_ 50, Special Issue on Informatics Methods in Medical Privacy, 2014, pp. 205–212  DOI: 10.1016/j.jbi.2013.12.003
  * [25] Rainer Schnell, Tobias Bachteler and Jörg Reiher  “A Novel Error-Tolerant Anonymous Linking Code”, 2011  DOI: 10.2139/ssrn.3549247
  * [26] Rainer Schnell and Christian Borgs  “Randomized Response and Balanced Bloom Filters for Privacy Preserving Record Linkage” ISSN: 2375-9259  In _2016 IEEE 16th International Conference on Data Mining Workshops (ICDMW)_ , 2016, pp. 218–224  DOI: 10.1109/ICDMW.2016.0038
  * [27] Sebastian Stammler et al.  “Mainzelliste SecureEpiLinker (MainSEL): Privacy-Preserving Record Linkage using Secure Multi-Party Computation”  In _Bioinformatics_ , 2020, pp. btaa764  DOI: 10.1093/bioinformatics/btaa764
  * [28] Khoi-Nguyen Tran, Dinusha Vatsalan and Peter Christen  “GeCo: an online personal data generator and corruptor”  In _Proceedings of the 22nd ACM international conference on Information & Knowledge Management_, CIKM ’13  New York, NY, USA: Association for Computing Machinery, 2013, pp. 2473–2476  DOI: 10.1145/2505515.2508207
  * [29] Dinusha Vatsalan, Peter Christen, Christine M. O’Keefe and Vassilios S. Verykios  “An Evaluation Framework for Privacy-Preserving Record Linkage” Number: 1  In _Journal of Privacy and Confidentiality_ 6.1, 2014  DOI: 10.29012/jpc.v6i1.636
  * [30] Paul Voigt and Axel Bussche  “The EU General Data Protection Regulation (GDPR)”  Cham: Springer International Publishing, 2017  DOI: 10.1007/978-3-319-57959-7
  * [31] Sascha Welten et al.  “A Privacy-Preserving Distributed Analytics Platform for Health Care Data” Publisher: Georg Thieme Verlag KG  In _Methods of Information in Medicine_ 61.S 01, 2022, pp. e1–e11  DOI: 10.1055/s-0041-1740564
  * [32] Sascha Welten et al.  “Multi-Institutional Breast Cancer Detection Using a Secure On-Boarding Service for Distributed Analytics” Number: 9 Publisher: Multidisciplinary Digital Publishing Institute  In _Applied Sciences_ 12.9, 2022, pp. 4336  DOI: 10.3390/app12094336
  * [33] Sascha Welten et al.  “Synthetic rainfall data generator development through decentralised model training”  In _Journal of Hydrology_ 612, 2022, pp. 128210  DOI: 10.1016/j.jhydrol.2022.128210
  * [34] William E Winkler  “Using the EM algorithm for weight computation in the Fellegi-Sunter model of record linkage”  US Bureau of the Census Washington, DC, 2000, pp. 12
  * [35] William E. Winkler  “Chapter 14 - Record Linkage”  In _Handbook of Statistics_ 29, Handbook of Statistics  Elsevier, 2009, pp. 351–380  DOI: 10.1016/S0169-7161(08)00014-X
  * [36] Kassaye Yitbarek Yigzaw, Antonis Michalas and Johan Gustav Bellika  “Secure and scalable deduplication of horizontally partitioned health data for privacy-preserving distributed statistical computation” Number: 1 Publisher: BioMed Central  In _BMC Medical Informatics and Decision Making_ 17.1, 2017, pp. 1–19  DOI: 10.1186/s12911-016-0389-x