Delimitation of probability and clearing
One of the concepts followed by the MII provides an fTTP for record linkage. However, this concept only shows the required components, but not their specific implementation. For this reason, these components were specified and implemented both technically and organisationally as part of the NUM-CODEX project. In detail, the fTTP is based on two technically separate components, fTTP (probability) and fTTP (clearing).
(1) The fTTP (probability) performs record linkage based on BFs. Project and site-specific pseudonyms are generated and managed. In addition, pseudonyms can be re-pseudonymised.
(2) The fTTP (clearing) performs record linkage on temporarily cached PII. This operation is triggered only when a record linkage based on BFs within the fTTP (probability) reach a possible match. For projects with large cohorts, this component can be omitted if needed. Projects with a small number of participants (e.g., in the context of rare diseases) may require exact matching, so fTTP (clearing) can be added for quality improvement.
The fTTP (probability) represents the first stage, which is sufficient in NUM-CODEX for initial data transmissions. After successfull roll-out of the first stage, the fTTP (clearing) is establisehd as the second stage at a later time.
Identification and coordination of use cases and processes
NUM-CODEX consists of central components, which include the fTTP, the GTH and the central platform (CODEX). These central components are available for the decentralised structures consisting of 34 DICs. The fTTP of the first stage basically requires two interfaces (to the sites and to the GTH). The necessary interfaces are shown in Figure 1.
The local TTP and the fTTP each provide data trustee capabilities, but operate in different modes. The local TTP may manage a person's PII for the site and performs record linkage based on PII.The fTTP per design does not store PII, but only manages BFs. BF can be categorised as person-relatable data, however, do not belong to PII. The local TTP generates a BF from the PII and transmits it to the fTTP (IF-1). The basis for the transmission of the BF is a corresponding informed consent from the patient. In case of an ambigious record linkage result in the fTTP, the PII can be requested from the local TTP for an additional classic record linkage procedure (9).
Data transfers from a DIC to the central platform require an additional pseudonymisation step (IF-2). The required pseudonyms are to be generated and managed within the fTTP.
In sum, two use cases were identified and modeled that need to be considered for fTTP implementation.
(UC1) Registration of persons and assignment of pseudonyms
Use case 1 comprises the registration of persons triggered by a site. In this case, a BF is transmitted to the fTTP. The fTTP performs a BF-based record linkage and assigns corresponding pseudonyms. During initial registration, two pseudonyms are generated:
1. The DIC PSN is a site-specific pseudonym that is only disclosed to the site sending the Bloomfilter. The site uses this pseudonym to reference the corresponding person.
2. The CODEX PSN is a cross-site pseudonym. This is only disclosed to the central platform (CODEX) and uniquely references a person in NUM-CODEX across all site boundaries.
Within the fTTP, all DIC PSNs for a person are assigned to a CODEX PSN. The sites cannot use the DIC PSN to determine which sites a person has visited.
To complete the person registration process, the fTTP sends a BF-specific response containing the DIC PSN to the requesting site. If a person was already known because he or she was already registered by another site, no new CODEX PSN is generated. In this case only a new DIC PSN that is assigned to the CODEX PSN is generated. If a local site accidentally sends an unmodified BF of the same person to the fTTP multiple times, the fTTP will always respond with the same DIC PSN. No additional pseudonyms will be generated. The process is summarised in Figure 2.
(UC2) Re-pseudonymisation of a site-specific pseudonym to a cross-site pseudonym
If medical data is transmitted from a site to the central platform, use case 2 describes the re-pseudonymisation of the data with the support of the fTTP. This means that the CODEX PSN cannot be used in the CODEX platform to determine which site has supplied data on this person. This re-pseudonymisation is initiated by the GECCO Transfer Hub (GTH). For this purpose, the GTH first sends the corresponding DIC PSN to the fTTP. The fTTP validates the incoming pseudonym and returns the correspondingly assigned CODEX PSN to the GTH. The GTH is responsible to replace the existing DIC PSN in the medical data with the CODEX PSN received (re-pseudonymisation) and then sends the re-pseudonymised MDAT to the central platform. The process is summarised in Figure 3.
NUM-wide coordination of required interfaces and responsibilities
Based on the modeled use cases for person registration and re-pseudonymisation, the necessary interfaces were identified. These were coordinated between the partners involved in the implementation or who uses these interfaces later.
To implement the two use cases of the fTTP (probability), initially only two fTTP-interfaces are required:
(1) fTTP-IF1: is used for person registration and is only called by the DICs. The fTTP receives a BF and returns a DIC pseudonym.
(2) fTTP-IF2: is used for re-pseudonymisation and expects a DIC pseudonym and returns the corresponding CODEX pseudonym. This interface is only used by the GTH.
The interfaces were implemented as generically as possible so that they can also be applied in other projects.
Specification and implementation of the interfaces
The technical interfaces were specified in FHIR format, as required in MII and NUM. To ensure FHIR conformity, the company Gefyra was commissioned to support the specification-process, to validate corresponding implementations and to propose corrections, if applicable. The interfaces were continuously documented in the public Simplifier project of the Independent Trusted Third-Party of the University Medicine Greifswald (16).
The technical implementation of the interfaces required for UC1 and UC2 expanded the existing Trusted Third Party FHIR Gateway (TTP-FHIR Gateway). This FHIR-specific, supplementary module of the TTP tools coordinates and validates incoming FHIR requests and forwards them to assigned ttp-components (for example dispatchers, E-PIX®) as required. For this purpose, the TTP-FHIR Gateway is based on HAPI FHIR (17) (version 5.4.0).
Extension of the E-PIX®
The E-PIX® is used at some sites within the local TTP as identity management for the management of PII and local record linkage. Likewise, this software solution will be used within the fTTP for the planned PPRL processes.
Therefore, E-PIX® has been extended with functionalities for the generation of BFs and matching of BFs were implemented.
Setup of the fTTP infrastructure
A data protection concept and a data protection impact assessment were prepared in advance and coordinated across NUM. Both basically describe the security concepts, tools used and the procedures of the fTTP.
The fTTP infrastructure, of course, relies on the concepts of the Independent Trusted Third-Party Greifswald. This comprises a set of secured network-zones separated by firewalls and with restrictive communication-capabilities consisting of a demilitarised network zone, a transfer network zone and a data trustee network zone. The virtual machines with the tools of the fTTP are operated in the network data trustee zone. Access to the interfaces is only granted if a site has been registered beforehand and enabled by the respective IP range of the site or a site-specific login.
The tools used in the fTTP are configured accordingly and provided in the fTTP. The E-PIX® is provided as identity management for the sites, if required, in an already pre-configured instance.
First, the required test infrastructure of the fTTP was set up and selected sites were authorised to use the provided fTTP functionalities and enabled for corresponding tests.
In the form of a NUM-wide demonstrator event for interested sites, the correct implementation of UC1 on the part of the fTTP for patient registration was first shown with the help of the Charité - University Medicine Berlin and the University Hospital Heidelberg. In addition, the correct support of the fTTP for the implementation of UC2 for re-pseudonymisation during a data transfer was then demonstrated by using the GTH, which is operated at Heilbronn University.