Implementing informed consent in federated medical research: a blueprint designed to safeguard data subject rights in Germany

Implementing informed consent in federated medical research: a blueprint designed to safeguard data subject rights in Germany | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article Implementing informed consent in federated medical research: a blueprint designed to safeguard data subject rights in Germany Christopher Hampf, Astrid Wiebke Pley, Peter Penndorf, Frank Michael Moser, and 7 more This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-9069363/v1 This work is licensed under a CC BY 4.0 License Status: Under Review Version 1 posted 4 You are reading this latest preprint version Abstract Background The establishment of the complementary infrastructures Medical Informatics Initiative (MII) and the Network of University Medicine (NUM) has significantly advanced the medical research landscape in Germany. While the MII is focused on the standardization and integration of university clinics routine data, NUM established a central infrastructure for clinical studies and data sharing, both focusing on the cross-institutional integration of health data as basis for strengthening medical research. Within the project NUM Routine Data Platform (NUM-RDP), a federated record linkage approach was implemented across 34 affiliated German university hospitals. Accordingly, a federated Trusted Third Party (fTTP) performed pseudonymisation and privacy-preserving record linkage across all participating sites. This work aims to extend the established fTTP approach to managing consent and withdrawal while bearing in mind the current legal frameworks and research initiatives for the use of health data. Methods A concept for an extended fTTP, termed ‘fTTP Consent,’ is proposed to bridge communication gaps between different sites, facilities and components. This allows for a central coordination for the implementation of patients' consent decisions regarding the storage, transfer and scientific use of their health data in a uniform manner. Results Two practical use cases for an ´fTTP Consent´ have been identified and conceptualized. Firstly, the cross-site improvement of workflows and automated processes to ensure that consent data is correct in formal, legal, semantic and syntactic terms. Secondly, the cross-site improvement of automated notification processes for new or updated consent data including respective withdrawal- and objection-processes. Conclusions The ‘fTTP Consent’ is designed to reduce communicatory and personnel efforts. It should ensure the correct and up-to-date realisation of data subject rights using the NUM-RDP as an example. The designed concept could help to overcome challenges in different consent-scenarios (opt-in, opt-out). Furthermore, it could streamline communication and data linkage processes between institutions and countries in future research projects. federated Consent Management Informed consent objection withdrawal GDPR patient rights Figures Figure 1 Figure 2 Background In recent years, the German medical research landscape has changed significantly, due to the establishment of the Medical Informatics Initiative (MII) and the Network of University Medicine (NUM). Those complementary infrastructural approaches aim to reuse and standardize health data for scientific purposes [ 1 ]. The MII is focused on the standardization and integration of routine data provided by and to university clinics. Driven by the COVID-19 pandemic, the NUM was established as a central infrastructure for clinical studies and their data integration across 34 German university hospitals. Both systems provide a foundation for future challenges: the integration of additional external data sources. This is especially important, as data provided by university clinics might not suffice to provide a holistic foundation for scientific research. Much important information and care data, such as cross-sectional care across healthcare providers and services, treatment cost, long-term outcomes, as well as comorbidities cannot be fully captured by single clinic systems. Therefore, integrating external data sources, such as public and private health insurance providers, cancer registries, and various medical registries, can help build a comprehensive foundation for medical research [ 2 ]. Data integration across institutions and data sources is therefore vital for future research and patient care. Under the legal requirements of the General Data Protection Regulation (GDPR), the processing of personal medical data is generally prohibited unless a specific legal basis exists (opt-in), such as the patient’s informed consent (IC) [ 3 ]. For this purpose, a person must be given the opportunity to ask questions in order to fully understand the data processing steps before consenting to the specific scientific use of their health data. A given consent may be withdrawn by patients and study participants at any time without providing reason (GDPR Art. 7 (3)). In Germany, further legal bases include the Act to Accelerate the Digitalization of the Healthcare System (Digital Act – DigiG) and the Health Data Utilisation Act (GDNG) [ 4 ]. They provide the legal framework for the electronic patient record (ePA) [ 5 ] and the German Research Data Centre (FDZ), allowing the use of health data without explicit prior consent (opt-out). However, in these cases data subjects generally have the right to object to data processing and usage without stating specific reasons. Coordinating cross-sectoral and cross-institutional patients´ consent status in a timely manner poses a current challenge. It demands timely, personnel and communicatory efforts. Ensuring the patient´s data protection rights is crucial. In this paper, the preparatory work provided by MII and NUM Routine Data Platform (RDP) is depicted. NUM-RDP´s current challenges in the context of data transfer and corresponding coordinative and communicatory efforts during the implementation of the patients´ will are explored. Furthermore, general requirements and information flows, to improve the status quo, are assessed. Previous work of the Medical Informatics Initiative Germany (MII) The MII’s standardised broad-consent was developed [ 3 ] by the MII Working Group (WG) Consent and coordinated with the responsible data protection authorities of the federal states. The modular MII template text was technically implemented by the MII Task Force Consent Implementation (TFCI). The ensuing and already published concept design defines the semantics of consent data [ 6 ]. Object Identifiers (OIDs) were implemented into the open-source platform ART-DECOR in order to unambiguously identify a patient`s decision or stated will (specified as ‘consent policies’ [ 7 ]). For example, a consent policy might aim for allowing the collection or sharing of health data. The MII WG Consent points out [ 8 ] that the developed solution concept may only be used for the MII Broad Consent’s realisation. It is not adoptable to other research projects in this exact manner. Within the MII, processes are primarily decentralised, with consents and withdrawals being handled on a site-specific basis. As a result, individuals participating at multiple sites are required to provide separate consent at each site, and, in the case of withdrawal, must withdraw their consent separately for each site. Consequently, the consent status may differ between participating sites. Previous work of NUM-RDP NUM-RDP established necessary infrastructures and processes for the central collection of research data from 34 NUM sites. The MII-Broad Consent [ 3 ] accompanied by an additional NUM-RDP specific consent module provides the legal basis for data processing and research. Within NUM-RDP, consents are also only valid locally. The situation is different in the case of withdrawals. A project-specific decision (September 2021) states that withdrawals are valid across sites. A withdrawal given by one patient is as valid at one study site as another. However, a cross-site, uniform, centralised unit supporting necessary withdrawal workflows was not intended within NUM-RDP. The NUM-RDP infrastructure supports centralised data integration. Each of the 34 NUM sites operates a local Trusted Third Party (TTP) and a local Data Integration Centre (DIC). This local TTP is responsible for management of person-identifying information, generation of pseudonyms and management and validation of the patient consent of the specific site. The local DIC manages the patient`s health data. A federated Trusted Third Party (fTTP) is centrally used for cross-site record linkage and cross-site pseudonymisation within NUM-RDP [ 9 ]. The fTTP does not support consent management processes. Medical data (MDAT) from patients, who have given their consent, is transferred from local sites to the Routine Data Platform of NUM-RDP called ‘Central Research Repository’ (CRR) or ‘Data Management Unit’ (DMU). The pseudonymized medical data is transferred through the NUM Transfer Hub (NTH) to the CRR. With help from the fTTP [ 9 ], site-specific pseudonyms are linked (record linkage) and cross-site pseudonyms are generated. The NTH transfers the MDAT with cross-site pseudonyms to the CRR for central data management. Current challenges within/for NUM-RDP The following section illustrates current challenges in data transfer and the implementation of withdrawal processes in NUM-RDP. Table 1 summarizes challenges for infrastructure components involved (e.g. DIC, NTH, CRR). In addition, potential consequences for individuals (patients) affected are enlisted. Data transfer without validation of consent data A patient’s consent documents remain at the local site. Their typical quality indicators are: completeness, correctness, and legal certainty (cf. [ 10 ]). For further data processing, those responsible (local TTP) should perform a quality test (verification) to ensure legal compliance of data use for scientific research (cf. [ 6 ]). Generally, the quality assessment occurs during the transfer from a paper-based consent form into a structurally queryable format (consent policies), if the informed consent has not been obtained solely digitally [ 11 ]. Only at the site consents are reviewed during the informed consent (IC) collection. As the personnel effort remains with the site, delays between the acquisition of ICs and the completed structurally queryable consent data may occur [ 11 ]. The total expenditure depends on the obtained, and to be quality-tested consents each year (linear scaling). The structural consent data are stored within the local TTP and can usually be made available for inquiry within a FHIR consent format. If a person has multiple consents at different sites, the consent data is currently not compared posing a risk of propositional contradiction. This approach delegates the responsibility of lawful data processing to the local NUM-Site. As of 2024, within the NUM-RDP infrastructure neither the NTH nor the CRR possess sufficient information (all relevant consents and withdrawals of the persons concerned) to ensure the legal permissibility of data sharing. Potentially high coordination effort during the implementation of withdrawal processes Patient withdrawals must be communicated and processed quickly within NUM-RDP, due to their cross-site nature (cf. [ 12 ], p. 51 ff. „Legal Consequences of Withdrawal“). According to the GDPR (Art. 7 (2–3)), there are no formal requirements to withdraw consent; it should be as easy to withdraw consent as to give it. Currently, processing withdrawals within the NUM-RDP project is based on a minimal withdrawal regulation from 2021. It is the local site’s responsibility to receive withdrawals and inform the NUM-RDP components about incoming withdrawals. Their processing is divided into six manual steps. These processing steps entail: the partner responsible for the fTTP is informed about the patient withdrawal via phone (step 1). Then they forward it with its corresponding pseudonym to all relevant components (CRR, sites), thus ensuring no more data is sent to the ‘CRR’ (step 2). Afterwards, the CRR erases all data corresponding to the cross-site pseudonyms (step 3). This encompasses all data of one person, as the CRR must not contain site-specific data. The fTTP is informed about the completed data erasure (step 4). In turn, they inform all relevant sites about this process and request the local erasure of the patient’s data as well (step 5). Lastly, the fTTP erases the Master Person Index (MPI) and additional information used for privacy-preserving record linkage to complete the withdrawal process (step 6). As can be observed, these steps are based on analogous communication, mostly via telephone and/or email, and manual processes. Any nascent procedure, therefore, is linked to high communicational and personnel efforts. Table 1 Summary of current challenges and possible risks for technical components and patients …for technical components (data processor) Challenges and possible risks… • NTH, CRR and DMU are not able to approve the existence of a valid IC stating the intended processing purpose (labelling cf. Art. 5 (1) lit. b GDPR) and time (lawfully, fairly and in a transparent manner in relation to the data subject). NTH, CRR and DMU are processing data from the data-sending location under the assumption that this is being done lawfully . • Only with great (communicational) effort component operators can prove the legality of data processing to the supervisory authority (Art 7. (1) GDPR). • Risk of different consent versions existing for one person at different sites, poses a risk of content contradiction. • Even if a withdrawal was received by the study site, it is possible to transmit data via the DMU, due to the high communicatory efforts and its lengthy processing time. This might result in unlawful data usage. • An increase in withdrawals will significantly increase the expenditure in cost, time, and personnel. This might increase the risk for scaling problems. …for patients (affected individual) • Due to its lengthy processing time, the patient´s right to withdraw (GDPR Art. 7 (3)) may consequently not be processed in a timely manner. Similarly, the reasonable steps a controller has to take, in accordance with the “Right to erasure” (GDPR Art. 17), could be delayed or not processed correctly. Improvement of cross-site processes and automatisms are required The identified challenges and potential consequences (see Table 1 ) illustrate the need for more automation and more standardised orchestration of consent-relevant workflows and processes. In terms of risk minimisation measures, cross-site processes and automatisms need to be improved. The necessary functionalities comprise two additional use cases: Use Case 1 (UC1): Consistently ensure the correctness and matching of consent data (formal, legal, semantical, syntactical). Use Case 2 (UC2) : Enable the notification of new or updated consent data, as well as implementation of withdrawal processes. In this manner, across all participating research sites the processes for ensuring the legality and transparency of data processing could be improved and the correctness of the implementation of patient consent could be ensured. Thus, the recency of consent data could be guaranteed, which reduces the risk of unlawful data transfers or data processing. Objectives This article aims to expand existing fTTP approaches. A new technical component ‘fTTP Consent’ shall support the identified use cases UC1 and UC2 to improve cross-site processes and automatisms in the context of consent management. Therefore, this article's objectives are Analysing the requirements for a new ‘fTTP consent’ to provide technical support for federated consent, withdrawal and objection processes in opt-in as well as opt-out research scenarios. Developing a solution concept that addresses corresponding cross-site processes and automatisms taking into consideration the possible future integration of external data sources. Methods To enable consistent reporting on the current consent status of data subjects at any time, an additional fTTP component ‘Consent’ is designed. It is focused on federated consent, withdrawal and objection processes. Thus, it should be possible to consistently adhere to the patient's will. It should likewise be possible to more effectively orchestrate complex communication processes for implementation of withdrawals and objections with distributed data systems. Additional automation will reduce efforts and shall ensure the correct and up-to-date implementation of data subject rights for all participating sites and infrastructure components. Firstly, this work considered the necessary technical and organisational conditions and identified general requirements for the additional fTTP component. Secondly, the required process workflows and data processes were analysed. Subsequently, necessary data items and data categories for an ´fTTP Consent´ were determined. Within the last step, semantics of consent data and necessary terminologies applicable in this context were considered. This provided the basis for the design of a solution concept for the ‘fTTP Consent’ component. It includes a catalogue of requirements regarding a minimum set of functionalities for the realisation of the identified use cases (UC1, UC2). Results General Requirements Even though NUM-RDP pursues an opt-in approach, the solution concept should not be only limited to it. In order to continue to meet most relevant legal requirements for the use of scientific data in the future, both consent-based (opt-in) as well as and objection-based (opt-out) research scenarios should be supported from the outset. This will promote ongoing research initiatives (MII, NUM) and increasingly relevant data usage scenarios (based on legal frameworks such as ePA [ 5 ] or GDNG [ 4 ]). Health Level 7 Fast Health Care Interoperability Resources (HL7 FHIR) should be the technical basis for communication, to maximise the possibilities for integrating the new consent component into existing infrastructures. This procedure would be similar to the MII and NUM [ 6 ]. Furthermore, recent developments and profiling work provided by the HL7 Germany Working Group ‘Consent Management’ must to be taken into consideration. This includes the technical representation of opt-in and opt-out scenarios and the urgently required standardisation of the definition of consent status and consent documents [ 13 ]. For future scenarios, support for project-independent semantic comparability of the processed consent data should be ensured, e.g. based on a ´Semantic Consent Code´ (SCC) [ 14 ]. Required information flows Regarding current infrastructures and processes in NUM-RDP and the envisaged use cases UC1 and UC2 for optimising the status quo the following figures (Fig. 1 , Fig. 2 ) in BPMN-format describe the nominal state for fulfilling the established objectives. UC1 - Data transfer with real-time consent verification Site-specific pseudonyms are exchanged with cross-site pseudonyms by the involvement of the fTTP. During this process, the component responsible for the data transfer verifies (for NUM-RDP: the NTH) with the `fTTP Consent` whether valid and context-specific consent has been given by the patient for the data transfer. If so, the data is transferred to the data recipient (for NUM-RDP: CRR/ for MII: the DMU). Otherwise, the data sender (for NUM-RDP: NUM site) will be notified by the component responsible about the absence of a legal basis. The data transfer is stopped immediately, and the risk of a potential violation of legal regulations (by the responsible data processor) is reduced. UC2 - Notification on new, updated and withdrawn/objected consent data, including support for the implementation of withdrawal and objection processes The ‘fTTP Consent’ is informed about new and updated consent data by the site, which keeps the original documents, scans, and signatures. For communication between the site and the ‘fTTP Consent’ site-specific pseudonyms are used. They are translatable into cross-site pseudonyms within the fTTP. It documents the most recent consent data in a project-, site-, and person-specific manner. If any information is obliged to be shared with the CRR, e.g. data transfer is no longer permissible, the fTTP will inform the sites accordingly. If the ‘fTTP Consent’ receives a withdrawal or an objection, it documents the request and starts the withdrawal-/objection-process. All relevant NUM-sites and infrastructure components will be informed and requested to perform their respective actions, such as inactivating a person´s data at the NUM-site (to prevent unlawful data sharing). The fTTP centrally documents those activities and the process statuses. Applicable automatic reminder functions should be considered during the planning process. After the sites and NUM-components completed their respective actions, they inform the ‘fTTP Consent’, which in turn documents the successful withdrawal/objection, and reports the status back to the initiating site. Data processed within the fTTP Consent For the implementation of an ‘fTTP Consent’ in the sense of a Consent Registry, which includes a central storage of the most-recent consent data supported by common management functionalities (CRUD: create, read, update, delete) and search functionalities [ 15 ], the listed information from Table 2 and Table 3 are processed and stored (temporarily) within the ‘fTTP Consent’. In most cases, cross-site pseudonyms are documented to communicate with the CRR and other components. Table 2 Necessary data for the processing of a consent registry Required Data Items Purpose Persistency Site-specific pseudonym Site-specific pseudonym for the respective person Permanent Cross-site pseudonym Attributes a patient’s personal information to their consent data, allowing for complex queries (regarding the consent and withdrawal status) e.g. used to communicate with the CRR Permanent Research pseudonym (alias) Store data transfer related pseudonyms Permanent Project-context Ensuring the project context during complex queries Permanent Consent-policies / consent-resources Basis for a standardised documentation of consent data across sites’ borders. This includes the validity period, a policy's semantic meaning, and information about consented facts (permit/deny) Scans, signatures, or filled consent documents are explicitly not processed. Permanent Validation outcome For the documentation of a performed consent data validation, and to respond validation results to the respective sites Permanent Table 3 Necessary data items for the processing of a comprehensive withdrawal (opt-in) and objection (opt-out) documentation Required Data Items Purpose Persistency Withdrawal Information about received withdrawals (i.e. Person-context, time stamp, site, extent of withdrawal) Permanent Process Progress information about the process and documentation of withdrawal implementation Permanent Site-context Site-context in terms of a site-specific pseudonym Temporary Withdrawal confirmation If a direct notification is necessary, the process confirmations sent by the CRR, local TTP, and DMU will be saved (accountability, traceability, transparency) Permanent The semantics and coding of consent data For the semantic querying of consent data, the encoding must be in a standardised format. Those queries (e.g. in order to verify a certain consent status for a selected person-identifier) contain, next to person- and project-specific pseudonyms, a description of the persons consent state. At the first expansion state, this can be based classically on distinct, agreed upon policy-identifiers (cf. [ 14 ]). The SCC could be an independent option to formulate and process consent queries (cf. [ 14 ]), though it allows to describe consent documents regardless of structure and form and supports the practical application of patient’s will to research data. Likewise, this project-independent coding approach was successfully evaluated with regards to convertibility of existing consent codings into/from SCC. Minimum set of functionalities Table 4 lists the necessary API functionalities to support UC1 (cf. Figure 1 ) and UC2 (cf. Figure 2 ). An implementation based on FHIR CRUD and FHIR Search Application Programming Interface (API) is possible. For design decisions, client- and server-based efforts should be determining. Table 4 Overview of required operations for a fTTP consent Operation (Use Case) Purpose IN Parameter OUT Parameter Possible Errors Verify-consent-state (UC1) consent status inquiry of a particular intended use for several independent pseudonyms (internally under consideration of all aliases) • project-context • list of overarching pseudonyms • intended action • time of request • analysis outcome (person-, project-context, reliability of action) as FHIR consent-resources • detailed error messages per cross-site pseudonym • duration of permissions • consent data unavailable • unauthorised access Request-consent-state (UC1) general consent data inquiry for a number of independent person pseudonyms (internally under consideration of all aliases) • project-context • list of overarching pseudonyms • time of request • analysis outcome (person-, project-context, reliability of action) as FHIR consent-resources • duration of permissions • detailed error messages per cross-site pseudonym • consent data unavailable • unauthorised access Provide-consent-data (UC1) information about new or updated consent data • consent data (site-specific pseudonym, project-context, valid/ invalid actions, validity period, reference consent template) • outcome (created, updated, error) • unknown content (project, template, site-specific pseudonym) • invalid content (site pseudonym, semantic of action, consistency) • unauthorised access Provide-withdrawal-objection-data (UC2) information about withdrawals and objections • site-specific pseudonym • project-context • optional: invalidated actions, validity period, reference template, site identifier • request confirmation containing the process identifier • unknown content (project, template, site-pseudonym) • invalid contents (site pseudonym, semantics of action, consistency) • unauthorised access Check-withdrawal-objection-state (UC2) inquiry about withdrawals and objections’ progress status • site-specific pseudonym • project-context • process identifier • detailed feedback about the process status • unknown content (project, template, site-pseudonym) • invalid content (site pseudonym, semantics of action, consistency) • unauthorised access Notify- action-requested (UC2) notification about a successful action from the `fTTP Consent` to a participant (component, site) e.g. received withdrawal or objection • action type • reason for action • depending on the subject: cross-site pseudonym • process identifier • action identifier • participant identifier (subject) • time stamp • request confirmation containing the process identifier and task identifier Notify-action-resolved (UC2) notification about an action´s successful completion by the participant (component) to the `fTTP Consent` • action identifier • participant identifier (responsible component) • depending on the addresser: cross-site pseudonym, site-specific pseudonym • time stamp • outcome of action • optional: confirmation of action, which person´s withdrawal has been processed within the TTP • request confirmation containing the process identifier and task identifier Notify withdrawal-objection-processed (UC2) notification of a completed withdrawal/objection process from the `fTTP Consent` to the initially reporting site • site-specific pseudonym • project-context • process identifier • time stamp • process status • list of components and participants who completed the withdrawal or objection • request confirmation containing the process identifier Discussion As elaborated, the ´fTTP Consent´ concept is able to address the identified needs for improvement by supporting the technical implementation of federated consent-, withdrawal- and objection- processes. Expanding existing fTTP approaches allows for the utilisation of established infrastructures and communication links [ 9 ]. Thus, only little effort is needed to integrate participating sites or components (NTH, CRR, DMU). There are several constraints and general requirements for an ´fTTP Consent´, such as an implementation of a technical foundation based on HL7 FHIR. The same standard is used by NUM and MII [ 1 ]. Opt-in and opt-out approaches (consent, withdrawal, objection) must be supported to allow for a potential expansion to integrate GDNG [ 4 ], ePA [ 5 ] or the German “Healthcare Strengthening Act” (Gesundheitsversorgungsstärkungsgesetz, GVSG) [ 16 ], later on. Additionally, the WG consent management’s recent developments and opt-in/opt-out profiling work must be considered [ 13 ]. Future scenarios and the semantic comparability of consent data must be supported independently from MII and NUM e.g. based on a SCC [ 14 ]. The fTTP facilitates to efficiently communicate the patient´s consent status to its connected institutions and components. This poses not only its greatest advantage, but also its greatest challenge. Upon implementation, two requirements must be met. First of all, all connected components themselves must agree to the use of an ‘fTTP Consent’. If only one party does not agree, it is unable to fulfil its goal. Subsequently, the patient´s rights, e.g., in cases of withdrawal, objection etc., could be endangered. Secondly, each participating site must also use the same semantic standards for description of consent data. This poses a great challenge as individual sites may use varying semantic standards and terminologies. To bridge the gap, the SCC could provide an adequate solution for more standardisation in consent semantics across different sites [ 14 ]. If all the aforementioned prerequisites are met, the success of a ‘fTTP Consent’ still relies on the sites to inform them about an initial consent status change. For decentralized data storage, the responsibility to receive and convey a changed consent status remains with the individual site. It is their mandate to receive potential withdrawals and forward them to the fTTP consent. This might be a single point of failure as a strongly delayed or error-prone withdrawal- and objection-notification from the site to the ‘fTTP Consent’ might result in unlawful scientific data usage. Conclusions This article examined complex research scenarios within the context of both opt-in and opt-out legal frameworks. Using the NUM-RDP project as an example, it considered the requirements for correctly taking the patients´ will into account. The proposed solution ‘fTTP Consent’ was developed to simplify sharing of consent-, withdrawal- and objection-data, which is essential for a legally permissible cross-site data sharing and the linkage of external data sources. The design of the ‘fTTP Consent’ supports both consent-based (opt-in) and legally mandated (opt-out) research scenarios, with a natural focus on the data subject (the patient) and the correct implementation of data subject rights. As NUM-RDP ended officially in 2025, other research projects can benefit from its upcoming implementation. The ‘fTTP Consent’ concept is centred around supporting automatable workflows within research infrastructures. The emphasis is on ensuring the correctness and availability of consent data in formal, legal, semantic and syntactic terms. In future, ‘fTTP Consent’ could be used as an independent, federated consent registry [ 14 ], or as a basis for establishing a patient portal. This would facilitate to strengthen patient-centred, cross-project research. This applies even to pan-European research initiatives such as the European Health Data Space (EHDS) [ 17 ]. Abbreviations API Application Programming Interface BPMN Business Process Model and Notation CODEX COVID Data Exchange CRR Central Research Repository CRUD Create, read, update, delete DIC Data Integration Centre DigiG Act to Accelerate the Digitalization of the Healthcare System (Digital Act) DMU Data Management Unit eCRF Electronic case report forms ePA Electronic Patient Records FDZ German Research Data Centre FHIR Fast Health Care Interoperability Resources fTTP federated Trusted Third Party GDNG Health Data Utilisation Act (Gesundheitsdatennutzungsgesetz) GDPR General Data Protection Regulation GVSG German “Healthcare Strengthening Act” (Gesundheitsversorgungsstärkungsgesetz) HL7 Health Level 7 IC Informed Consent IHE Integrating the Health Care Enterprise MDAT medical data MII Medical Informatics Initiative Germany MPI Master Patient Index NTH NUM Data Transfer Hub NUM Network of University Medicine OIDs Object Identifiers RDP Routine Data Platform SCC Semantic Consent Code TFCI Task Force Consent Implementation TMF Technology, Methods and Infrastructure for Networked Medical Research TTP Trusted Third Party WG Working Group Declarations Ethics approval and consent to participate: Not applicable . Consent for publication: Not applicable. Availability of data and materials: Not applicable. Competing interests: In the interest of transparency, it is disclosed that Gefyra GmbH was engaged as a consultant. Additionally, Gefyra GmbH was responsible for the implementation of FHIR profiles and received financial compensation for their services. Beyond that, the authors declare that they have no competing interests. Funding: The NUM-RDP project (grant number 01KX2121) is funded by the Federal Ministry of Research, Technology and Space (BMFTR). The funders had no role in the design of the study, the collection, analysis or interpretation of data, or the writing of the manuscript. Authors’ contributions: Drafting of the manuscript: CH, AWP, AK and MB; Design and Conceptualisation of the fTTP Consent: CH, FM, MB, PP, SL, PW; Workflow and figure design: CH; Technical Consultation: SL, PW; Revision of the manuscript: MB, AWP, CH, FM, PP, SL, PW, AK, DS, TL, WH; All the authors approved the final version of the manuscript. Acknowledgements: Not applicable. References Bialke M, Geidel L, Hampf C, Blumentritt A, Penndorf P, Schuldt R et al. A FHIR has been lit on gICS: facilitating the standardised exchange of informed consent in a large network of university medicine. BMC Med Inf Decis Mak [Internet]. 2022 [cited 2024 Jul 22];22:335. https://doi.org/10.1186/s12911-022-02081-4 Wolfgang Hoffmann; Martin Sedlmayr. AG Externe Daten: Vernetzte Daten für die Zukunft (GERMAN). ONE MII - Journal der Medizininformatik-Initiative [Internet]. 2025;1:18–20. https://www.medizininformatik-initiative.de/de/erstes-one-mii-journal-der-medizininformatik-initiative-veroeffentlicht Zenker S, Strech D, Ihrig K, Jahns R, Müller G, Schickhardt C, et al. (bio)medical research: Towards a new German national standard. J Biomedical Inf [Internet]. 2022;131:104096. https://doi.org/10.1016/j.jbi.2022.104096 . [cited 2024 Aug 22];. Data protection-compliant broad consent for secondary use of health care data and human biosamples for. Bundesregierung Deutschland. German Health Data Use Act (Gesundheitsdatennutzungsgesetz; GDNG) [Internet]. 2023. https://www.bundesgesundheitsministerium.de/service/gesetze-und-verordnungen/detail/gesundheitsdatennutzungsgesetz.html Bundesministerium für Gesundheit Deutschland. Elektronische Patientenakte (ePA) (German) [Internet]. 2025. https://www.bundesgesundheitsministerium.de/themen/digitalisierung/elektronische-patientenakte/epa-fuer-alle.html Stäubert S*, Bialke M, Geidel L, Merzweiler A, Jörg R, Buckow K, Lang S. HL7-FHIR-Standard für Einwilligungsmanagement auf dem Weg in die Praxis. EHEALTHCOM [Internet]:44–7. https://e-health-com.de/thema-der-woche/hl7-fhir-standard-fuer-einwilligungsmanagement-auf-dem-weg-in-die-praxis/ Rau H, Geidel L, Bialke M, Blumentritt A, Langanke M, Liedtke W et al. The generic Informed Consent Service gICS®: implementation and benefits of a modular consent software tool to master the challenge of electronic consent management in research. J Transl Med [Internet]. 2020 [cited 2024 Sep 13];18:287. https://doi.org/10.1186/s12967-020-02457-y TMF e.V. Minutes of the MII WG Consent meeting on November 9, 2022. Medicalinformatics Initiative; 2022 Nov. Hampf C, Bialke M, Hund H, Fegeler C, Lang S, Penndorf P, et al. Privacy-preserving record linkage by a federated trusted third party (fTTP). – unlocking medical research potential in Germany. GMS Medizinische Informatik, Biometrie und Epidemiologie [Internet]. German Medical Science GMS Publishing House; 2025. [cited 2025 Nov 24];21. https://doi.org/10.3205/MIBE000277 . Rau H, Stahl D, Reichel A-J, Bialke M, Bahls T, Hoffmann W. We Know What You Agreed To, Don’t We?—Evaluating the Quality of Paper-Based Consents Forms and Their Digitalized Equivalent Using the Example of the Baltic Fracture Competence Centre Project. Methods Inf Med [Internet]. 2023 [cited 2024 Aug 22];62:e10–8. https://doi.org/10.1055/s-0042-1760249 Stahl D, Rau H, Blumentritt A, Fiedler-Lacombe L, Heim E, Valentin H, et al. The benefits of fully electronic consent management and consent collection via a tablet PC in supporting time-critical pandemic research-an example from a NAPKON COVID-19 project. Front Digit Health. 2025;7:1489176. https://doi.org/10.3389/fdgth.2025.1489176 . Dierks C, Kircher P, Husemann C, Kleinschmidt J, Haase M. Data Privacy in European Medical Research [Internet]. Medizinisch Wissenschaftliche Verlagsgesellschaft; 2021. [cited 2024 Aug 22]. https://doi.org/10.32745/9783954666034 . Stäubert S, Merzweiler A, Römhild J, Lang S, Bialke M. Consent Management 2.0: Empowering Patient Will in Medical Research and Care. Stud Health Technol Inf. 2025;331:133–41. https://doi.org/10.3233/SHTI251389 . Bialke M, Hampf C, Blumentritt A, Moser F-M, Lang S, Stehn A et al. #consented – A semantic consent code to facilitate consistent documentation and implementation of consent in collaborative medical research. Int J Med Inf [Internet]. 2024 [cited 2024 Aug 22];190:105545. https://doi.org/10.1016/j.ijmedinf.2024.105545 IHE PCF Standard. - Consent Registry [Internet]. https://profiles.ihe.net/ITI/PCF/CapabilityStatement-IHE.PCF.consentRegistry.html Bundesministerium für Gesundheit. Gesetz zur Stärkung der Gesundheitsversorgung in der Kommune (Gesundheitsversorgungsstärkungsgesetz — GVSG) (GERMAN) [Internet]. 2025. https://www.recht.bund.de/bgbl/1/2025/64/VO.html European Parliament and Council of the European Union. European Health Data Space Regulation (EHDS) [Internet]. European Health Data Space Regulation (EHDS). 2025. https://eur-lex.europa.eu/eli/reg/2025/327/oj Cite Share Download PDF Status: Under Review Version 1 posted Reviewers agreed at journal 16 Mar, 2026 Reviewers invited by journal 16 Mar, 2026 Editor assigned by journal 10 Mar, 2026 First submitted to journal 08 Mar, 2026 You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-9069363","acceptedTermsAndConditions":true,"allowDirectSubmit":false,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":606848524,"identity":"754ec515-6a16-4c0e-a445-3a863c0ea53d","order_by":0,"name":"Christopher Hampf","email":"","orcid":"","institution":"Universitätsmedizin Greifswald Institut für Community Medicine: Universitatsmedizin Greifswald Institut fur Community Medicine","correspondingAuthor":false,"prefix":"","firstName":"Christopher","middleName":"","lastName":"Hampf","suffix":""},{"id":606848525,"identity":"996d01e4-e2a4-4bb9-b5da-d6085435b04a","order_by":1,"name":"Astrid Wiebke Pley","email":"","orcid":"","institution":"University Medicine Greifswald Institute of Community Medicine: Universitatsmedizin Greifswald Institute for Community Medicine","correspondingAuthor":false,"prefix":"","firstName":"Astrid","middleName":"Wiebke","lastName":"Pley","suffix":""},{"id":606848526,"identity":"6432bab2-8e19-4034-82e6-f86e8c463a48","order_by":2,"name":"Peter Penndorf","email":"","orcid":"","institution":"University Medicine Greifswald, Institute of Community Medicine: Universitatsmedizin Greifswald Institut fur Community Medicine","correspondingAuthor":false,"prefix":"","firstName":"Peter","middleName":"","lastName":"Penndorf","suffix":""},{"id":606848527,"identity":"f357b389-b771-454b-867b-f0061f36d482","order_by":3,"name":"Frank Michael Moser","email":"","orcid":"","institution":"University Medicine Greifswald, Institute for Community Medicine","correspondingAuthor":false,"prefix":"","firstName":"Frank","middleName":"Michael","lastName":"Moser","suffix":""},{"id":606848528,"identity":"352070ae-0863-4183-a62d-7ab15799fd43","order_by":4,"name":"Stefan Lang","email":"","orcid":"","institution":"Gefyra GmbH","correspondingAuthor":false,"prefix":"","firstName":"Stefan","middleName":"","lastName":"Lang","suffix":""},{"id":606848529,"identity":"17b55df5-ff43-4a84-9e58-208a53e0b215","order_by":5,"name":"Patrick Werner","email":"","orcid":"","institution":"Gefyra GmbH","correspondingAuthor":false,"prefix":"","firstName":"Patrick","middleName":"","lastName":"Werner","suffix":""},{"id":606848530,"identity":"b77287f1-2458-4eb2-b355-143ba8afc705","order_by":6,"name":"Anika Kästner","email":"","orcid":"","institution":"University Medicine Greifswald, Institute for Community Medicine","correspondingAuthor":false,"prefix":"","firstName":"Anika","middleName":"","lastName":"Kästner","suffix":""},{"id":606848531,"identity":"fab1787a-e610-4608-bf41-5b39efec00e6","order_by":7,"name":"Torsten Leddig","email":"","orcid":"","institution":"University Medicine Greifswald, Institute for Community Medicine","correspondingAuthor":false,"prefix":"","firstName":"Torsten","middleName":"","lastName":"Leddig","suffix":""},{"id":606848532,"identity":"47f5909e-3419-47e1-b20f-d9d4236d975a","order_by":8,"name":"Dana Stahl","email":"","orcid":"","institution":"University Medicine Greifswald: Universitatsmedizin Greifswald","correspondingAuthor":false,"prefix":"","firstName":"Dana","middleName":"","lastName":"Stahl","suffix":""},{"id":606848533,"identity":"676041e0-1aa7-411c-8d42-3041b8bd06ed","order_by":9,"name":"Wolfgang Hoffmann","email":"","orcid":"","institution":"University Medicine Greifswald, Institute for Community Medicine","correspondingAuthor":false,"prefix":"","firstName":"Wolfgang","middleName":"","lastName":"Hoffmann","suffix":""},{"id":606848534,"identity":"bff64427-680a-443f-99aa-7f20edadc4bf","order_by":10,"name":"Martin Bialke","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAABRElEQVRIie2RMUvDQBSA3xFIlljXc7G/QHhFKAWL/Ss5Au0WhEBxcIgcnEuhawuif8GpuNlyoEtsN8nYINTFId0qRPSS1io9Co6C+Xgc9967j3fHARQU/FUcFSYYHOAUwMxLuK8WI6CrdAMSLBWilHCtHOadrcpykFKIWFe3KwcXjy/T+Ba8kjXiOL+SXgmspyQ5wQY+jM4jaNc3lWrYqgQsBN+0GWf9gfRNsP1+D5HdhIzXYNzUlGGTBExAFlzuDCQT5VfXsDF1qkMmKBFSUyazlbIbc/l+qRSwXSNFbFQncaZ8aEr0NYUy7pIgUyxpACIZRPmUoa7MSE+1fJPGvNK5b2VTDNJRb7mLYl5zxq5+sSbM30TdK3ddSRdnR+w6sJ5hkWJjr+uOoqR9rH9LDv2Z2Pi9d7YIG1jT350rKCgo+C98AoPfc1ikDbXVAAAAAElFTkSuQmCC","orcid":"https://orcid.org/0000-0001-6888-9086","institution":"University Medicine Greifswald, Institute for Community Medicine","correspondingAuthor":true,"prefix":"","firstName":"Martin","middleName":"","lastName":"Bialke","suffix":""}],"badges":[],"createdAt":"2026-03-09 06:56:39","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-9069363/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-9069363/v1","draftVersion":[],"editorialEvents":[],"editorialNote":"","failedWorkflow":false,"files":[{"id":105035037,"identity":"e50ffd87-97bb-4d9c-9ccf-53065cce221f","added_by":"auto","created_at":"2026-03-20 07:25:20","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":549200,"visible":true,"origin":"","legend":"\u003cp\u003eReal-time consent check prevents legally unauthorised data transfers and thus strengthens the rights of data subjects (UC1). The term ‘consent’ broadly describes the legal admissibility of the intended data processing and applies equally to opt-in and opt-out in this case.\u003c/p\u003e","description":"","filename":"figure1.png","url":"https://assets-eu.researchsquare.com/files/rs-9069363/v1/071fe649da48bce9fb447c80.png"},{"id":104994558,"identity":"daf40765-d6e8-486d-bfb3-1d158a7f9e48","added_by":"auto","created_at":"2026-03-19 16:01:08","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":1384357,"visible":true,"origin":"","legend":"\u003cp\u003eNecessary workflows to notify on new, updated or withdrawn consent data including the implementation of withdrawal and objection processes (UC2)\u003c/p\u003e","description":"","filename":"figure2.png","url":"https://assets-eu.researchsquare.com/files/rs-9069363/v1/80c77078ac0057a63d8cb447.png"},{"id":105036700,"identity":"8b92275f-8f50-495b-a6e8-9af240a644c8","added_by":"auto","created_at":"2026-03-20 07:35:24","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":2269190,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-9069363/v1/8022b02d-3f66-432b-9984-ce3fac6c5132.pdf"}],"financialInterests":"","formattedTitle":"Implementing informed consent in federated medical research: a blueprint designed to safeguard data subject rights in Germany","fulltext":[{"header":"Background","content":"\u003cp\u003eIn recent years, the German medical research landscape has changed significantly, due to the establishment of the Medical Informatics Initiative (MII) and the Network of University Medicine (NUM). Those complementary infrastructural approaches aim to reuse and standardize health data for scientific purposes [\u003cspan citationid=\"CR1\" class=\"CitationRef\"\u003e1\u003c/span\u003e]. The MII is focused on the standardization and integration of routine data provided by and to university clinics. Driven by the COVID-19 pandemic, the NUM was established as a central infrastructure for clinical studies and their data integration across 34 German university hospitals. Both systems provide a foundation for future challenges: the integration of additional external data sources. This is especially important, as data provided by university clinics might not suffice to provide a holistic foundation for scientific research. Much important information and care data, such as cross-sectional care across healthcare providers and services, treatment cost, long-term outcomes, as well as comorbidities cannot be fully captured by single clinic systems. Therefore, integrating external data sources, such as public and private health insurance providers, cancer registries, and various medical registries, can help build a comprehensive foundation for medical research [\u003cspan citationid=\"CR2\" class=\"CitationRef\"\u003e2\u003c/span\u003e]. Data integration across institutions and data sources is therefore vital for future research and patient care.\u003c/p\u003e \u003cp\u003eUnder the legal requirements of the General Data Protection Regulation (GDPR), the processing of personal medical data is generally prohibited unless a specific legal basis exists (opt-in), such as the patient\u0026rsquo;s informed consent (IC) [\u003cspan citationid=\"CR3\" class=\"CitationRef\"\u003e3\u003c/span\u003e]. For this purpose, a person must be given the opportunity to ask questions in order to fully understand the data processing steps before consenting to the specific scientific use of their health data. A given consent may be withdrawn by patients and study participants at any time without providing reason (GDPR Art. 7 (3)). In Germany, further legal bases include the Act to Accelerate the Digitalization of the Healthcare System (Digital Act \u0026ndash; DigiG) and the Health Data Utilisation Act (GDNG) [\u003cspan citationid=\"CR4\" class=\"CitationRef\"\u003e4\u003c/span\u003e]. They provide the legal framework for the electronic patient record (ePA) [\u003cspan citationid=\"CR5\" class=\"CitationRef\"\u003e5\u003c/span\u003e] and the German Research Data Centre (FDZ), allowing the use of health data without explicit prior consent (opt-out). However, in these cases data subjects generally have the right to object to data processing and usage without stating specific reasons.\u003c/p\u003e \u003cp\u003eCoordinating cross-sectoral and cross-institutional patients\u0026acute; consent status in a timely manner poses a current challenge. It demands timely, personnel and communicatory efforts. Ensuring the patient\u0026acute;s data protection rights is crucial.\u003c/p\u003e \u003cp\u003eIn this paper, the preparatory work provided by MII and NUM Routine Data Platform (RDP) is depicted. NUM-RDP\u0026acute;s current challenges in the context of data transfer and corresponding coordinative and communicatory efforts during the implementation of the patients\u0026acute; will are explored. Furthermore, general requirements and information flows, to improve the status quo, are assessed.\u003c/p\u003e \u003cp\u003ePrevious work of the Medical Informatics Initiative Germany (MII)\u003c/p\u003e \u003cp\u003eThe MII\u0026rsquo;s standardised broad-consent was developed [\u003cspan citationid=\"CR3\" class=\"CitationRef\"\u003e3\u003c/span\u003e] by the MII Working Group (WG) Consent and coordinated with the responsible data protection authorities of the federal states. The modular MII template text was technically implemented by the MII Task Force Consent Implementation (TFCI). The ensuing and already published concept design defines the semantics of consent data [\u003cspan citationid=\"CR6\" class=\"CitationRef\"\u003e6\u003c/span\u003e]. Object Identifiers (OIDs) were implemented into the open-source platform ART-DECOR in order to unambiguously identify a patient`s decision or stated will (specified as \u0026lsquo;consent policies\u0026rsquo; [\u003cspan citationid=\"CR7\" class=\"CitationRef\"\u003e7\u003c/span\u003e]). For example, a consent policy might aim for allowing the collection or sharing of health data. The MII WG Consent points out [\u003cspan citationid=\"CR8\" class=\"CitationRef\"\u003e8\u003c/span\u003e] that the developed solution concept may only be used for the MII Broad Consent\u0026rsquo;s realisation. It is not adoptable to other research projects in this exact manner.\u003c/p\u003e \u003cp\u003eWithin the MII, processes are primarily decentralised, with consents and withdrawals being handled on a site-specific basis. As a result, individuals participating at multiple sites are required to provide separate consent at each site, and, in the case of withdrawal, must withdraw their consent separately for each site. Consequently, the consent status may differ between participating sites.\u003c/p\u003e \u003cp\u003ePrevious work of NUM-RDP\u003c/p\u003e \u003cp\u003eNUM-RDP established necessary infrastructures and processes for the central collection of research data from 34 NUM sites. The MII-Broad Consent [\u003cspan citationid=\"CR3\" class=\"CitationRef\"\u003e3\u003c/span\u003e] accompanied by an additional NUM-RDP specific consent module provides the legal basis for data processing and research. Within NUM-RDP, consents are also only valid locally. The situation is different in the case of withdrawals. A project-specific decision (September 2021) states that withdrawals are valid across sites. A withdrawal given by one patient is as valid at one study site as another. However, a cross-site, uniform, centralised unit supporting necessary withdrawal workflows was not intended within NUM-RDP.\u003c/p\u003e \u003cp\u003eThe NUM-RDP infrastructure supports centralised data integration. Each of the 34 NUM sites operates a local Trusted Third Party (TTP) and a local Data Integration Centre (DIC). This local TTP is responsible for management of person-identifying information, generation of pseudonyms and management and validation of the patient consent of the specific site. The local DIC manages the patient`s health data. A federated Trusted Third Party (fTTP) is centrally used for cross-site record linkage and cross-site pseudonymisation within NUM-RDP [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e]. The fTTP does not support consent management processes. Medical data (MDAT) from patients, who have given their consent, is transferred from local sites to the Routine Data Platform of NUM-RDP called \u0026lsquo;Central Research Repository\u0026rsquo; (CRR) or \u0026lsquo;Data Management Unit\u0026rsquo; (DMU). The pseudonymized medical data is transferred through the NUM Transfer Hub (NTH) to the CRR. With help from the fTTP [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e], site-specific pseudonyms are linked (record linkage) and cross-site pseudonyms are generated. The NTH transfers the MDAT with cross-site pseudonyms to the CRR for central data management.\u003c/p\u003e \u003cp\u003eCurrent challenges within/for NUM-RDP\u003c/p\u003e \u003cp\u003eThe following section illustrates current challenges in data transfer and the implementation of withdrawal processes in NUM-RDP. Table\u0026nbsp;\u003cspan refid=\"Tab1\" class=\"InternalRef\"\u003e1\u003c/span\u003e summarizes challenges for infrastructure components involved (e.g. DIC, NTH, CRR). In addition, potential consequences for individuals (patients) affected are enlisted.\u003c/p\u003e\n\u003ch3\u003eData transfer without validation of consent data\u003c/h3\u003e\n\u003cp\u003eA patient\u0026rsquo;s consent documents remain at the local site. Their typical quality indicators are: completeness, correctness, and legal certainty (cf. [\u003cspan citationid=\"CR10\" class=\"CitationRef\"\u003e10\u003c/span\u003e]). For further data processing, those responsible (local TTP) should perform a quality test (verification) to ensure legal compliance of data use for scientific research (cf. [\u003cspan citationid=\"CR6\" class=\"CitationRef\"\u003e6\u003c/span\u003e]). Generally, the quality assessment occurs during the transfer from a paper-based consent form into a structurally queryable format (consent policies), if the informed consent has not been obtained solely digitally [\u003cspan citationid=\"CR11\" class=\"CitationRef\"\u003e11\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eOnly at the site consents are reviewed during the informed consent (IC) collection. As the personnel effort remains with the site, delays between the acquisition of ICs and the completed structurally queryable consent data may occur [\u003cspan citationid=\"CR11\" class=\"CitationRef\"\u003e11\u003c/span\u003e]. The total expenditure depends on the obtained, and to be quality-tested consents each year (linear scaling). The structural consent data are stored within the local TTP and can usually be made available for inquiry within a FHIR consent format. If a person has multiple consents at different sites, the consent data is currently not compared posing a risk of propositional contradiction. This approach delegates the responsibility of lawful data processing to the local NUM-Site. As of 2024, within the NUM-RDP infrastructure neither the NTH nor the CRR possess sufficient information (all relevant consents and withdrawals of the persons concerned) to ensure the legal permissibility of data sharing.\u003c/p\u003e \u003cdiv id=\"Sec3\" class=\"Section2\"\u003e \u003ch2\u003ePotentially high coordination effort during the implementation of withdrawal processes\u003c/h2\u003e \u003cp\u003ePatient withdrawals must be communicated and processed quickly within NUM-RDP, due to their cross-site nature (cf. [\u003cspan citationid=\"CR12\" class=\"CitationRef\"\u003e12\u003c/span\u003e], p. 51 ff. \u0026bdquo;Legal Consequences of Withdrawal\u0026ldquo;). According to the GDPR (Art. 7 (2\u0026ndash;3)), there are no formal requirements to withdraw consent; it should be as easy to withdraw consent as to give it. Currently, processing withdrawals within the NUM-RDP project is based on a minimal withdrawal regulation from 2021. It is the local site\u0026rsquo;s responsibility to receive withdrawals and inform the NUM-RDP components about incoming withdrawals. Their processing is divided into six manual steps. These processing steps entail: the partner responsible for the fTTP is informed about the patient withdrawal via phone (step 1). Then they forward it with its corresponding pseudonym to all relevant components (CRR, sites), thus ensuring no more data is sent to the \u0026lsquo;CRR\u0026rsquo; (step 2). Afterwards, the CRR erases all data corresponding to the cross-site pseudonyms (step 3). This encompasses all data of one person, as the CRR must not contain site-specific data. The fTTP is informed about the completed data erasure (step 4). In turn, they inform all relevant sites about this process and request the local erasure of the patient\u0026rsquo;s data as well (step 5). Lastly, the fTTP erases the Master Person Index (MPI) and additional information used for privacy-preserving record linkage to complete the withdrawal process (step 6). As can be observed, these steps are based on analogous communication, mostly via telephone and/or email, and manual processes. Any nascent procedure, therefore, is linked to high communicational and personnel efforts.\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab1\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 1\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eSummary of current challenges and possible risks for technical components and patients\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"2\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\" morerows=\"1\" rowspan=\"2\"\u003e \u003cp\u003e\u003cb\u003e\u0026hellip;for technical components\u003c/b\u003e\u003c/p\u003e \u003cp\u003e\u003cb\u003e(data processor)\u003c/b\u003e\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003eChallenges and possible risks\u0026hellip;\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003e\u0026bull; NTH, CRR and DMU are not able to approve the existence of a valid IC stating the intended processing purpose (labelling cf. Art. 5 (1) lit. b GDPR) and time (lawfully, fairly and in a transparent manner in relation to the data subject). NTH, CRR and DMU are processing data from the data-sending location under the \u003cb\u003eassumption\u003c/b\u003e that this is being done \u003cb\u003elawfully\u003c/b\u003e.\u003c/p\u003e \u003cp\u003e\u0026bull; Only with great (communicational) effort component operators can prove the legality of data processing to the supervisory authority (Art 7. (1) GDPR).\u003c/p\u003e \u003cp\u003e\u0026bull; Risk of different consent versions existing for one person at different sites, poses a risk of content contradiction.\u003c/p\u003e \u003cp\u003e\u0026bull; Even if a withdrawal was received by the study site, it is possible to transmit data via the DMU, due to the high communicatory efforts and its lengthy processing time. This might result in unlawful data usage.\u003c/p\u003e \u003cp\u003e\u0026bull; An increase in withdrawals will significantly increase the expenditure in cost, time, and personnel. This might increase the risk for scaling problems.\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003e\u0026hellip;for patients\u003c/b\u003e\u003c/p\u003e \u003cp\u003e\u003cb\u003e(affected individual)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e\u0026bull; Due to its lengthy processing time, the patient\u0026acute;s right to withdraw (GDPR Art. 7 (3)) may consequently not be processed in a timely manner. Similarly, the reasonable steps a controller has to take, in accordance with the \u0026ldquo;Right to erasure\u0026rdquo; (GDPR Art. 17), could be delayed or not processed correctly.\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003cp\u003eImprovement of cross-site processes and automatisms are required\u003c/p\u003e \u003cp\u003eThe identified challenges and potential consequences (see Table\u0026nbsp;\u003cspan refid=\"Tab1\" class=\"InternalRef\"\u003e1\u003c/span\u003e) illustrate the need for more automation and more standardised orchestration of consent-relevant workflows and processes. In terms of risk minimisation measures, cross-site processes and automatisms need to be improved. The necessary functionalities comprise two additional use cases:\u003c/p\u003e \u003cp\u003e \u003cul\u003e \u003cli\u003e \u003cp\u003e \u003cem\u003eUse Case 1\u003c/em\u003e (UC1): Consistently ensure the correctness and matching of consent data (formal, legal, semantical, syntactical).\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003e \u003cem\u003eUse Case 2 (UC2)\u003c/em\u003e: Enable the notification of new or updated consent data, as well as implementation of withdrawal processes.\u003c/p\u003e \u003c/li\u003e \u003c/ul\u003e \u003c/p\u003e \u003cp\u003eIn this manner, across all participating research sites the processes for ensuring the legality and transparency of data processing could be improved and the correctness of the implementation of patient consent could be ensured. Thus, the recency of consent data could be guaranteed, which reduces the risk of unlawful data transfers or data processing.\u003c/p\u003e \u003c/div\u003e\n\u003ch3\u003eObjectives\u003c/h3\u003e\n\u003cp\u003eThis article aims to expand existing fTTP approaches. A new technical component \u0026lsquo;fTTP Consent\u0026rsquo; shall support the identified use cases UC1 and UC2 to improve cross-site processes and automatisms in the context of consent management. Therefore, this article's objectives are\u003c/p\u003e \u003cp\u003e \u003col\u003e \u003cspan\u003e \u003cli\u003e \u003cp\u003eAnalysing the requirements for a new \u0026lsquo;fTTP consent\u0026rsquo; to provide technical support for federated consent, withdrawal and objection processes in opt-in as well as opt-out research scenarios.\u003c/p\u003e \u003c/li\u003e \u003c/span\u003e \u003cspan\u003e \u003cli\u003e \u003cp\u003eDeveloping a solution concept that addresses corresponding cross-site processes and automatisms taking into consideration the possible future integration of external data sources.\u003c/p\u003e \u003c/li\u003e \u003c/span\u003e \u003c/ol\u003e \u003c/p\u003e"},{"header":"Methods","content":"\u003cp\u003eTo enable consistent reporting on the current consent status of data subjects at any time, an additional fTTP component \u0026lsquo;Consent\u0026rsquo; is designed. It is focused on federated consent, withdrawal and objection processes. Thus, it should be possible to consistently adhere to the patient's will. It should likewise be possible to more effectively orchestrate complex communication processes for implementation of withdrawals and objections with distributed data systems. Additional automation will reduce efforts and shall ensure the correct and up-to-date implementation of data subject rights for all participating sites and infrastructure components.\u003c/p\u003e \u003cp\u003eFirstly, this work considered the necessary technical and organisational conditions and identified general requirements for the additional fTTP component. Secondly, the required process workflows and data processes were analysed. Subsequently, necessary data items and data categories for an \u0026acute;fTTP Consent\u0026acute; were determined. Within the last step, semantics of consent data and necessary terminologies applicable in this context were considered. This provided the basis for the design of a solution concept for the \u0026lsquo;fTTP Consent\u0026rsquo; component. It includes a catalogue of requirements regarding a minimum set of functionalities for the realisation of the identified use cases (UC1, UC2).\u003c/p\u003e"},{"header":"Results","content":"\u003cp\u003eGeneral Requirements\u003c/p\u003e \u003cp\u003eEven though NUM-RDP pursues an opt-in approach, the solution concept should not be only limited to it. In order to continue to meet most relevant legal requirements for the use of scientific data in the future, both consent-based (opt-in) as well as and objection-based (opt-out) research scenarios should be supported from the outset. This will promote ongoing research initiatives (MII, NUM) and increasingly relevant data usage scenarios (based on legal frameworks such as ePA [\u003cspan citationid=\"CR5\" class=\"CitationRef\"\u003e5\u003c/span\u003e] or GDNG [\u003cspan citationid=\"CR4\" class=\"CitationRef\"\u003e4\u003c/span\u003e]).\u003c/p\u003e \u003cp\u003eHealth Level 7 Fast Health Care Interoperability Resources (HL7 FHIR) should be the technical basis for communication, to maximise the possibilities for integrating the new consent component into existing infrastructures. This procedure would be similar to the MII and NUM [\u003cspan citationid=\"CR6\" class=\"CitationRef\"\u003e6\u003c/span\u003e]. Furthermore, recent developments and profiling work provided by the HL7 Germany Working Group \u0026lsquo;Consent Management\u0026rsquo; must to be taken into consideration. This includes the technical representation of opt-in and opt-out scenarios and the urgently required standardisation of the definition of consent status and consent documents [\u003cspan citationid=\"CR13\" class=\"CitationRef\"\u003e13\u003c/span\u003e]. For future scenarios, support for project-independent semantic comparability of the processed consent data should be ensured, e.g. based on a \u0026acute;Semantic Consent Code\u0026acute; (SCC) [\u003cspan citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eRequired information flows\u003c/p\u003e \u003cp\u003eRegarding current infrastructures and processes in NUM-RDP and the envisaged use cases UC1 and UC2 for optimising the status quo the following figures (Fig.\u0026nbsp;\u003cspan refid=\"Fig1\" class=\"InternalRef\"\u003e1\u003c/span\u003e, Fig.\u0026nbsp;\u003cspan refid=\"Fig2\" class=\"InternalRef\"\u003e2\u003c/span\u003e) in BPMN-format describe the nominal state for fulfilling the established objectives.\u003c/p\u003e\n\u003ch3\u003eUC1 - Data transfer with real-time consent verification\u003c/h3\u003e\n\u003cp\u003eSite-specific pseudonyms are exchanged with cross-site pseudonyms by the involvement of the fTTP. During this process, the component responsible for the data transfer verifies (for NUM-RDP: the NTH) with the `fTTP Consent` whether valid and context-specific consent has been given by the patient for the data transfer. If so, the data is transferred to the data recipient (for NUM-RDP: CRR/ for MII: the DMU). Otherwise, the data sender (for NUM-RDP: NUM site) will be notified by the component responsible about the absence of a legal basis. The data transfer is stopped immediately, and the risk of a potential violation of legal regulations (by the responsible data processor) is reduced.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003e \u003cb\u003eUC2 - Notification on new, updated and withdrawn/objected consent data, including support for the implementation of withdrawal and objection processes\u003c/b\u003e \u003c/p\u003e \u003cp\u003eThe \u0026lsquo;fTTP Consent\u0026rsquo; is informed about new and updated consent data by the site, which keeps the original documents, scans, and signatures. For communication between the site and the \u0026lsquo;fTTP Consent\u0026rsquo; site-specific pseudonyms are used. They are translatable into cross-site pseudonyms within the fTTP. It documents the most recent consent data in a project-, site-, and person-specific manner. If any information is obliged to be shared with the CRR, e.g. data transfer is no longer permissible, the fTTP will inform the sites accordingly.\u003c/p\u003e \u003cp\u003eIf the \u0026lsquo;fTTP Consent\u0026rsquo; receives a withdrawal or an objection, it documents the request and starts the withdrawal-/objection-process. All relevant NUM-sites and infrastructure components will be informed and requested to perform their respective actions, such as inactivating a person\u0026acute;s data at the NUM-site (to prevent unlawful data sharing). The fTTP centrally documents those activities and the process statuses. Applicable automatic reminder functions should be considered during the planning process. After the sites and NUM-components completed their respective actions, they inform the \u0026lsquo;fTTP Consent\u0026rsquo;, which in turn documents the successful withdrawal/objection, and reports the status back to the initiating site.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eData processed within the fTTP Consent\u003c/p\u003e \u003cp\u003eFor the implementation of an \u0026lsquo;fTTP Consent\u0026rsquo; in the sense of a Consent Registry, which includes a central storage of the most-recent consent data supported by common management functionalities (CRUD: create, read, update, delete) and search functionalities [\u003cspan citationid=\"CR15\" class=\"CitationRef\"\u003e15\u003c/span\u003e], the listed information from Table\u0026nbsp;\u003cspan refid=\"Tab2\" class=\"InternalRef\"\u003e2\u003c/span\u003e and\u003c/p\u003e \u003cp\u003eTable\u0026nbsp;\u003cspan refid=\"Tab3\" class=\"InternalRef\"\u003e3\u003c/span\u003e are processed and stored (temporarily) within the \u0026lsquo;fTTP Consent\u0026rsquo;. In most cases, cross-site pseudonyms are documented to communicate with the CRR and other components.\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab2\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 2\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eNecessary data for the processing of a consent registry\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"3\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c3\" colnum=\"3\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003eRequired Data Items\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003ePurpose\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePersistency\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eSite-specific pseudonym\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eSite-specific pseudonym for the respective person\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePermanent\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eCross-site pseudonym\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eAttributes a patient\u0026rsquo;s personal information to their consent data, allowing for complex queries (regarding the consent and withdrawal status) e.g. used to communicate with the CRR\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePermanent\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eResearch pseudonym (alias)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eStore data transfer related pseudonyms\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePermanent\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eProject-context\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eEnsuring the project context during complex queries\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePermanent\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eConsent-policies / consent-resources\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eBasis for a standardised documentation of consent data across sites\u0026rsquo; borders. This includes the validity period, a policy's semantic meaning, and information about consented facts (permit/deny)\u003c/p\u003e \u003cp\u003eScans, signatures, or filled consent documents are explicitly not processed.\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePermanent\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eValidation outcome\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eFor the documentation of a performed consent data validation, and to respond validation results to the respective sites\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePermanent\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab3\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 3\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eNecessary data items for the processing of a comprehensive withdrawal (opt-in) and objection (opt-out) documentation\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"3\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c3\" colnum=\"3\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003eRequired Data Items\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003ePurpose\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePersistency\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eWithdrawal\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eInformation about received withdrawals (i.e. Person-context, time stamp, site, extent of withdrawal)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePermanent\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eProcess\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eProgress information about the process and documentation of withdrawal implementation\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePermanent\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eSite-context\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eSite-context in terms of a site-specific pseudonym\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003eTemporary\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eWithdrawal confirmation\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eIf a direct notification is necessary, the process confirmations sent by the CRR, local TTP, and DMU will be saved (accountability, traceability, transparency)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePermanent\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003cp\u003eThe semantics and coding of consent data\u003c/p\u003e \u003cp\u003eFor the semantic querying of consent data, the encoding must be in a standardised format. Those queries (e.g. in order to verify a certain consent status for a selected person-identifier) contain, next to person- and project-specific pseudonyms, a description of the persons consent state. At the first expansion state, this can be based classically on distinct, agreed upon policy-identifiers (cf. [\u003cspan citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e]).\u003c/p\u003e \u003cp\u003eThe SCC could be an independent option to formulate and process consent queries (cf. [\u003cspan citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e]), though it allows to describe consent documents regardless of structure and form and supports the practical application of patient\u0026rsquo;s will to research data. Likewise, this project-independent coding approach was successfully evaluated with regards to convertibility of existing consent codings into/from SCC.\u003c/p\u003e \u003cp\u003eMinimum set of functionalities\u003c/p\u003e \u003cp\u003eTable\u0026nbsp;\u003cspan refid=\"Tab4\" class=\"InternalRef\"\u003e4\u003c/span\u003e lists the necessary API functionalities to support UC1 (cf. Figure\u0026nbsp;\u003cspan refid=\"Fig1\" class=\"InternalRef\"\u003e1\u003c/span\u003e) and UC2 (cf. Figure\u0026nbsp;\u003cspan refid=\"Fig2\" class=\"InternalRef\"\u003e2\u003c/span\u003e). An implementation based on FHIR CRUD and FHIR Search Application Programming Interface (API) is possible. For design decisions, client- and server-based efforts should be determining.\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab4\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 4\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eOverview of required operations for a fTTP consent\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"5\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c3\" colnum=\"3\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c4\" colnum=\"4\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c5\" colnum=\"5\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003eOperation (Use Case)\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003ePurpose\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c3\"\u003e \u003cp\u003eIN Parameter\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c4\"\u003e \u003cp\u003eOUT Parameter\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c5\"\u003e \u003cp\u003ePossible Errors\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eVerify-consent-state (UC1)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003econsent status inquiry of a particular intended use for several independent pseudonyms (internally under consideration of all aliases)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e\u0026bull; project-context\u003c/p\u003e \u003cp\u003e\u0026bull; list of overarching pseudonyms\u003c/p\u003e \u003cp\u003e\u0026bull; intended action\u003c/p\u003e \u003cp\u003e\u0026bull; time of request\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e\u0026bull; analysis outcome (person-, project-context, reliability of action) as FHIR consent-resources\u003c/p\u003e \u003cp\u003e\u0026bull; detailed error messages per cross-site pseudonym\u003c/p\u003e \u003cp\u003e\u0026bull; duration of permissions\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e\u0026bull; consent data unavailable\u003c/p\u003e \u003cp\u003e\u0026bull; unauthorised access\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eRequest-consent-state (UC1)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003egeneral consent data inquiry for a number of independent person pseudonyms (internally under consideration of all aliases)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e\u0026bull; project-context\u003c/p\u003e \u003cp\u003e\u0026bull; list of overarching pseudonyms\u003c/p\u003e \u003cp\u003e\u0026bull; time of request\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e\u0026bull; analysis outcome (person-, project-context, reliability of action) as FHIR consent-resources\u003c/p\u003e \u003cp\u003e\u0026bull; duration of permissions\u003c/p\u003e \u003cp\u003e\u0026bull; detailed error messages per cross-site pseudonym\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e\u0026bull; consent data unavailable\u003c/p\u003e \u003cp\u003e\u0026bull; unauthorised access\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eProvide-consent-data (UC1)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003einformation about new or updated consent data\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e\u0026bull; consent data (site-specific pseudonym, project-context, valid/ invalid actions, validity period, reference consent template)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e\u0026bull; outcome (created, updated, error)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e\u0026bull; unknown content (project, template, site-specific pseudonym)\u003c/p\u003e \u003cp\u003e\u0026bull; invalid content (site pseudonym, semantic of action, consistency)\u003c/p\u003e \u003cp\u003e\u0026bull; unauthorised access\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eProvide-withdrawal-objection-data (UC2)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003einformation about withdrawals and objections\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e\u0026bull; site-specific pseudonym\u003c/p\u003e \u003cp\u003e\u0026bull; project-context\u003c/p\u003e \u003cp\u003e\u0026bull; optional: invalidated actions, validity period, reference template, site identifier\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e\u0026bull; request confirmation containing the process identifier\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e\u0026bull; unknown content (project, template, site-pseudonym)\u003c/p\u003e \u003cp\u003e\u0026bull; invalid contents (site pseudonym, semantics of action, consistency)\u003c/p\u003e \u003cp\u003e\u0026bull; unauthorised access\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eCheck-withdrawal-objection-state (UC2)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003einquiry about withdrawals and objections\u0026rsquo; progress status\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e\u0026bull; site-specific pseudonym\u003c/p\u003e \u003cp\u003e\u0026bull; project-context\u003c/p\u003e \u003cp\u003e\u0026bull; process identifier\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e\u0026bull; detailed feedback about the process status\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e\u0026bull; unknown content (project, template, site-pseudonym)\u003c/p\u003e \u003cp\u003e\u0026bull; invalid content (site pseudonym, semantics of action, consistency)\u003c/p\u003e \u003cp\u003e\u0026bull; unauthorised access\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eNotify- action-requested (UC2)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003enotification about a successful action from the `fTTP Consent` to a participant (component, site) e.g. received withdrawal or objection\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e\u0026bull; action type\u003c/p\u003e \u003cp\u003e\u0026bull; reason for action\u003c/p\u003e \u003cp\u003e\u0026bull; depending on the subject: cross-site pseudonym\u003c/p\u003e \u003cp\u003e\u0026bull; process identifier\u003c/p\u003e \u003cp\u003e\u0026bull; action identifier\u003c/p\u003e \u003cp\u003e\u0026bull; participant identifier (subject)\u003c/p\u003e \u003cp\u003e\u0026bull; time stamp\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e\u0026bull; request confirmation containing the process identifier and task identifier\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e\u0026nbsp;\u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eNotify-action-resolved (UC2)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003enotification about an action\u0026acute;s successful completion by the participant (component) to the `fTTP Consent`\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e\u0026bull; action identifier\u003c/p\u003e \u003cp\u003e\u0026bull; participant identifier (responsible component)\u003c/p\u003e \u003cp\u003e\u0026bull; depending on the addresser: cross-site pseudonym, site-specific pseudonym\u003c/p\u003e \u003cp\u003e\u0026bull; time stamp\u003c/p\u003e \u003cp\u003e\u0026bull; outcome of action\u003c/p\u003e \u003cp\u003e\u0026bull; optional: confirmation of action, which person\u0026acute;s withdrawal has been processed within the TTP\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e\u0026bull; request confirmation containing the process identifier and task identifier\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e\u0026nbsp;\u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eNotify withdrawal-objection-processed (UC2)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003enotification of a completed withdrawal/objection process from the `fTTP Consent` to the initially reporting site\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e\u0026bull; site-specific pseudonym\u003c/p\u003e \u003cp\u003e\u0026bull; project-context\u003c/p\u003e \u003cp\u003e\u0026bull; process identifier\u003c/p\u003e \u003cp\u003e\u0026bull; time stamp\u003c/p\u003e \u003cp\u003e\u0026bull; process status\u003c/p\u003e \u003cp\u003e\u0026bull; list of components and participants who completed the withdrawal or objection\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e\u0026bull; request confirmation containing the process identifier\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e\u0026nbsp;\u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e"},{"header":"Discussion","content":"\u003cp\u003eAs elaborated, the \u0026acute;fTTP Consent\u0026acute; concept is able to address the identified needs for improvement by supporting the technical implementation of federated consent-, withdrawal- and objection- processes. Expanding existing fTTP approaches allows for the utilisation of established infrastructures and communication links [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e]. Thus, only little effort is needed to integrate participating sites or components (NTH, CRR, DMU).\u003c/p\u003e \u003cp\u003eThere are several constraints and general requirements for an \u0026acute;fTTP Consent\u0026acute;, such as an implementation of a technical foundation based on HL7 FHIR. The same standard is used by NUM and MII [\u003cspan citationid=\"CR1\" class=\"CitationRef\"\u003e1\u003c/span\u003e]. Opt-in and opt-out approaches (consent, withdrawal, objection) must be supported to allow for a potential expansion to integrate GDNG [\u003cspan citationid=\"CR4\" class=\"CitationRef\"\u003e4\u003c/span\u003e], ePA [\u003cspan citationid=\"CR5\" class=\"CitationRef\"\u003e5\u003c/span\u003e] or the German \u0026ldquo;Healthcare Strengthening Act\u0026rdquo; (Gesundheitsversorgungsst\u0026auml;rkungsgesetz, GVSG) [\u003cspan citationid=\"CR16\" class=\"CitationRef\"\u003e16\u003c/span\u003e], later on. Additionally, the WG consent management\u0026rsquo;s recent developments and opt-in/opt-out profiling work must be considered [\u003cspan citationid=\"CR13\" class=\"CitationRef\"\u003e13\u003c/span\u003e]. Future scenarios and the semantic comparability of consent data must be supported independently from MII and NUM e.g. based on a SCC [\u003cspan citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eThe fTTP facilitates to efficiently communicate the patient\u0026acute;s consent status to its connected institutions and components. This poses not only its greatest advantage, but also its greatest challenge. Upon implementation, two requirements must be met. First of all, all connected components themselves must agree to the use of an \u0026lsquo;fTTP Consent\u0026rsquo;. If only one party does not agree, it is unable to fulfil its goal. Subsequently, the patient\u0026acute;s rights, e.g., in cases of withdrawal, objection etc., could be endangered. Secondly, each participating site must also use the same semantic standards for description of consent data. This poses a great challenge as individual sites may use varying semantic standards and terminologies. To bridge the gap, the SCC could provide an adequate solution for more standardisation in consent semantics across different sites [\u003cspan citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eIf all the aforementioned prerequisites are met, the success of a \u0026lsquo;fTTP Consent\u0026rsquo; still relies on the sites to inform them about an initial consent status change. For decentralized data storage, the responsibility to receive and convey a changed consent status remains with the individual site. It is their mandate to receive potential withdrawals and forward them to the fTTP consent. This might be a single point of failure as a strongly delayed or error-prone withdrawal- and objection-notification from the site to the \u0026lsquo;fTTP Consent\u0026rsquo; might result in unlawful scientific data usage.\u003c/p\u003e"},{"header":"Conclusions","content":"\u003cp\u003eThis article examined complex research scenarios within the context of both opt-in and opt-out legal frameworks. Using the NUM-RDP project as an example, it considered the requirements for correctly taking the patients\u0026acute; will into account. The proposed solution \u0026lsquo;fTTP Consent\u0026rsquo; was developed to simplify sharing of consent-, withdrawal- and objection-data, which is essential for a legally permissible cross-site data sharing and the linkage of external data sources. The design of the \u0026lsquo;fTTP Consent\u0026rsquo; supports both consent-based (opt-in) and legally mandated (opt-out) research scenarios, with a natural focus on the data subject (the patient) and the correct implementation of data subject rights. As NUM-RDP ended officially in 2025, other research projects can benefit from its upcoming implementation.\u003c/p\u003e \u003cp\u003eThe \u0026lsquo;fTTP Consent\u0026rsquo; concept is centred around supporting automatable workflows within research infrastructures. The emphasis is on ensuring the correctness and availability of consent data in formal, legal, semantic and syntactic terms. In future, \u0026lsquo;fTTP Consent\u0026rsquo; could be used as an independent, federated consent registry [\u003cspan citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e], or as a basis for establishing a patient portal. This would facilitate to strengthen patient-centred, cross-project research. This applies even to pan-European research initiatives such as the European Health Data Space (EHDS) [\u003cspan citationid=\"CR17\" class=\"CitationRef\"\u003e17\u003c/span\u003e].\u003c/p\u003e"},{"header":"Abbreviations","content":"\u003cdiv class=\"DefinitionList\"\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eAPI\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eApplication Programming Interface\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eBPMN\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eBusiness Process Model and Notation\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eCODEX\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eCOVID Data Exchange\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eCRR\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eCentral Research Repository\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eCRUD\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eCreate, read, update, delete\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eDIC\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eData Integration Centre\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eDigiG\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eAct to Accelerate the Digitalization of the Healthcare System (Digital Act)\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eDMU\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eData Management Unit\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eeCRF\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eElectronic case report forms\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eePA\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eElectronic Patient Records\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eFDZ\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eGerman Research Data Centre\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eFHIR\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eFast Health Care Interoperability Resources\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003efTTP\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003efederated Trusted Third Party\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eGDNG\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eHealth Data Utilisation Act (Gesundheitsdatennutzungsgesetz)\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eGDPR\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eGeneral Data Protection Regulation\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eGVSG\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eGerman \u0026ldquo;Healthcare Strengthening Act\u0026rdquo; (Gesundheitsversorgungsst\u0026auml;rkungsgesetz)\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eHL7\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eHealth Level 7\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eIC\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eInformed Consent\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eIHE\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eIntegrating the Health Care Enterprise\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eMDAT\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003emedical data\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eMII\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eMedical Informatics Initiative Germany\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eMPI\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eMaster Patient Index\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eNTH\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eNUM Data Transfer Hub\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eNUM\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eNetwork of University Medicine\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eOIDs\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eObject Identifiers\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eRDP\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eRoutine Data Platform\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eSCC\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eSemantic Consent Code\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eTFCI\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eTask Force Consent Implementation\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eTMF\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eTechnology, Methods and Infrastructure for Networked Medical Research\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eTTP\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eTrusted Third Party\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eWG\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eWorking Group\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003c/div\u003e"},{"header":"Declarations","content":"\u003cp\u003e\u003cstrong\u003eEthics approval and consent to participate:\u0026nbsp;\u003c/strong\u003eNot applicable\u003cstrong\u003e.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eConsent for publication:\u0026nbsp;\u003c/strong\u003eNot applicable.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAvailability of data and materials:\u0026nbsp;\u003c/strong\u003eNot applicable.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCompeting interests:\u0026nbsp;\u003c/strong\u003eIn the interest of transparency, it is disclosed that Gefyra GmbH was engaged as a consultant. Additionally, Gefyra GmbH was responsible for the implementation of FHIR profiles and received financial compensation for their services. Beyond that, the authors declare that they have no competing interests.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eFunding:\u0026nbsp;\u003c/strong\u003eThe NUM-RDP project (grant number 01KX2121) is funded by the Federal Ministry of Research, Technology and Space (BMFTR). The funders had no role in the design of the study, the collection, analysis or interpretation of data, or the writing of the manuscript.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAuthors\u0026rsquo; contributions:\u0026nbsp;\u003c/strong\u003eDrafting of the manuscript: CH, AWP, AK and MB; Design and Conceptualisation of the fTTP Consent: CH, FM, MB, PP, SL, PW; Workflow and figure design: CH; Technical Consultation: SL, PW; Revision of the manuscript: MB, AWP, CH, FM, PP, SL, PW, AK, DS, TL, WH; All the authors approved the final version of the manuscript.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAcknowledgements:\u0026nbsp;\u003c/strong\u003eNot applicable.\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\u003cli\u003e\u003cspan\u003eBialke M, Geidel L, Hampf C, Blumentritt A, Penndorf P, Schuldt R et al. A FHIR has been lit on gICS: facilitating the standardised exchange of informed consent in a large network of university medicine. BMC Med Inf Decis Mak [Internet]. 2022 [cited 2024 Jul 22];22:335. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.1186/s12911-022-02081-4\u003c/span\u003e\u003cspan address=\"10.1186/s12911-022-02081-4\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eWolfgang Hoffmann; Martin Sedlmayr. AG Externe Daten: Vernetzte Daten f\u0026uuml;r die Zukunft (GERMAN). ONE MII - Journal der Medizininformatik-Initiative [Internet]. 2025;1:18\u0026ndash;20. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://www.medizininformatik-initiative.de/de/erstes-one-mii-journal-der-medizininformatik-initiative-veroeffentlicht\u003c/span\u003e\u003cspan address=\"https://www.medizininformatik-initiative.de/de/erstes-one-mii-journal-der-medizininformatik-initiative-veroeffentlicht\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eZenker S, Strech D, Ihrig K, Jahns R, M\u0026uuml;ller G, Schickhardt C, et al. (bio)medical research: Towards a new German national standard. J Biomedical Inf [Internet]. 2022;131:104096. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.1016/j.jbi.2022.104096\u003c/span\u003e\u003cspan address=\"10.1016/j.jbi.2022.104096\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e. [cited 2024 Aug 22];. Data protection-compliant broad consent for secondary use of health care data and human biosamples for.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBundesregierung Deutschland. German Health Data Use Act (Gesundheitsdatennutzungsgesetz; GDNG) [Internet]. 2023. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://www.bundesgesundheitsministerium.de/service/gesetze-und-verordnungen/detail/gesundheitsdatennutzungsgesetz.html\u003c/span\u003e\u003cspan address=\"https://www.bundesgesundheitsministerium.de/service/gesetze-und-verordnungen/detail/gesundheitsdatennutzungsgesetz.html\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBundesministerium f\u0026uuml;r Gesundheit Deutschland. Elektronische Patientenakte (ePA) (German) [Internet]. 2025. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://www.bundesgesundheitsministerium.de/themen/digitalisierung/elektronische-patientenakte/epa-fuer-alle.html\u003c/span\u003e\u003cspan address=\"https://www.bundesgesundheitsministerium.de/themen/digitalisierung/elektronische-patientenakte/epa-fuer-alle.html\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eSt\u0026auml;ubert S*, Bialke M, Geidel L, Merzweiler A, J\u0026ouml;rg R, Buckow K, Lang S. HL7-FHIR-Standard f\u0026uuml;r Einwilligungsmanagement auf dem Weg in die Praxis. EHEALTHCOM [Internet]:44\u0026ndash;7. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://e-health-com.de/thema-der-woche/hl7-fhir-standard-fuer-einwilligungsmanagement-auf-dem-weg-in-die-praxis/\u003c/span\u003e\u003cspan address=\"https://e-health-com.de/thema-der-woche/hl7-fhir-standard-fuer-einwilligungsmanagement-auf-dem-weg-in-die-praxis/\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eRau H, Geidel L, Bialke M, Blumentritt A, Langanke M, Liedtke W et al. The generic Informed Consent Service gICS\u0026reg;: implementation and benefits of a modular consent software tool to master the challenge of electronic consent management in research. J Transl Med [Internet]. 2020 [cited 2024 Sep 13];18:287. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.1186/s12967-020-02457-y\u003c/span\u003e\u003cspan address=\"10.1186/s12967-020-02457-y\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eTMF e.V. Minutes of the MII WG Consent meeting on November 9, 2022. Medicalinformatics Initiative; 2022 Nov.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eHampf C, Bialke M, Hund H, Fegeler C, Lang S, Penndorf P, et al. Privacy-preserving record linkage by a federated trusted third party (fTTP). \u0026ndash; unlocking medical research potential in Germany. GMS Medizinische Informatik, Biometrie und Epidemiologie [Internet]. German Medical Science GMS Publishing House; 2025. [cited 2025 Nov 24];21. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.3205/MIBE000277\u003c/span\u003e\u003cspan address=\"10.3205/MIBE000277\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eRau H, Stahl D, Reichel A-J, Bialke M, Bahls T, Hoffmann W. We Know What You Agreed To, Don\u0026rsquo;t We?\u0026mdash;Evaluating the Quality of Paper-Based Consents Forms and Their Digitalized Equivalent Using the Example of the Baltic Fracture Competence Centre Project. Methods Inf Med [Internet]. 2023 [cited 2024 Aug 22];62:e10\u0026ndash;8. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.1055/s-0042-1760249\u003c/span\u003e\u003cspan address=\"10.1055/s-0042-1760249\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eStahl D, Rau H, Blumentritt A, Fiedler-Lacombe L, Heim E, Valentin H, et al. The benefits of fully electronic consent management and consent collection via a tablet PC in supporting time-critical pandemic research-an example from a NAPKON COVID-19 project. Front Digit Health. 2025;7:1489176. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.3389/fdgth.2025.1489176\u003c/span\u003e\u003cspan address=\"10.3389/fdgth.2025.1489176\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eDierks C, Kircher P, Husemann C, Kleinschmidt J, Haase M. Data Privacy in European Medical Research [Internet]. Medizinisch Wissenschaftliche Verlagsgesellschaft; 2021. [cited 2024 Aug 22]. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.32745/9783954666034\u003c/span\u003e\u003cspan address=\"10.32745/9783954666034\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eSt\u0026auml;ubert S, Merzweiler A, R\u0026ouml;mhild J, Lang S, Bialke M. Consent Management 2.0: Empowering Patient Will in Medical Research and Care. Stud Health Technol Inf. 2025;331:133\u0026ndash;41. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.3233/SHTI251389\u003c/span\u003e\u003cspan address=\"10.3233/SHTI251389\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBialke M, Hampf C, Blumentritt A, Moser F-M, Lang S, Stehn A et al. #consented \u0026ndash; A semantic consent code to facilitate consistent documentation and implementation of consent in collaborative medical research. Int J Med Inf [Internet]. 2024 [cited 2024 Aug 22];190:105545. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.1016/j.ijmedinf.2024.105545\u003c/span\u003e\u003cspan address=\"10.1016/j.ijmedinf.2024.105545\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eIHE PCF Standard. - Consent Registry [Internet]. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://profiles.ihe.net/ITI/PCF/CapabilityStatement-IHE.PCF.consentRegistry.html\u003c/span\u003e\u003cspan address=\"https://profiles.ihe.net/ITI/PCF/CapabilityStatement-IHE.PCF.consentRegistry.html\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBundesministerium f\u0026uuml;r Gesundheit. Gesetz zur St\u0026auml;rkung der Gesundheitsversorgung in der Kommune (Gesundheitsversorgungsst\u0026auml;rkungsgesetz \u0026mdash; GVSG) (GERMAN) [Internet]. 2025. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://www.recht.bund.de/bgbl/1/2025/64/VO.html\u003c/span\u003e\u003cspan address=\"https://www.recht.bund.de/bgbl/1/2025/64/VO.html\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eEuropean Parliament and Council of the European Union. European Health Data Space Regulation (EHDS) [Internet]. European Health Data Space Regulation (EHDS). 2025. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://eur-lex.europa.eu/eli/reg/2025/327/oj\u003c/span\u003e\u003cspan address=\"https://eur-lex.europa.eu/eli/reg/2025/327/oj\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":false,"highlight":"","institution":"","isAcceptedByJournal":false,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":true,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"journal-of-translational-medicine","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"jtrm","sideBox":"Learn more about [Journal of Translational Medicine](http://translational-medicine.biomedcentral.com)","snPcode":"","submissionUrl":"https://www.editorialmanager.com/jtrm/default.aspx","title":"Journal of Translational Medicine","twitterHandle":"@BioMedCentral","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"em","reportingPortfolio":"BMC/SO AJ","inReviewEnabled":true,"inReviewRevisionsEnabled":true},"keywords":"federated Consent Management, Informed consent, objection, withdrawal, GDPR, patient rights","lastPublishedDoi":"10.21203/rs.3.rs-9069363/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-9069363/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003ch2\u003eBackground\u003c/h2\u003e \u003cp\u003eThe establishment of the complementary infrastructures Medical Informatics Initiative (MII) and the Network of University Medicine (NUM) has significantly advanced the medical research landscape in Germany. While the MII is focused on the standardization and integration of university clinics routine data, NUM established a central infrastructure for clinical studies and data sharing, both focusing on the cross-institutional integration of health data as basis for strengthening medical research. Within the project NUM Routine Data Platform (NUM-RDP), a federated record linkage approach was implemented across 34 affiliated German university hospitals. Accordingly, a federated Trusted Third Party (fTTP) performed pseudonymisation and privacy-preserving record linkage across all participating sites. This work aims to extend the established fTTP approach to managing consent and withdrawal while bearing in mind the current legal frameworks and research initiatives for the use of health data.\u003c/p\u003e\u003ch2\u003eMethods\u003c/h2\u003e \u003cp\u003eA concept for an extended fTTP, termed \u0026lsquo;fTTP Consent,\u0026rsquo; is proposed to bridge communication gaps between different sites, facilities and components. This allows for a central coordination for the implementation of patients' consent decisions regarding the storage, transfer and scientific use of their health data in a uniform manner.\u003c/p\u003e\u003ch2\u003eResults\u003c/h2\u003e \u003cp\u003eTwo practical use cases for an \u0026acute;fTTP Consent\u0026acute; have been identified and conceptualized. Firstly, the cross-site improvement of workflows and automated processes to ensure that consent data is correct in formal, legal, semantic and syntactic terms. Secondly, the cross-site improvement of automated notification processes for new or updated consent data including respective withdrawal- and objection-processes.\u003c/p\u003e\u003ch2\u003eConclusions\u003c/h2\u003e \u003cp\u003eThe \u0026lsquo;fTTP Consent\u0026rsquo; is designed to reduce communicatory and personnel efforts. It should ensure the correct and up-to-date realisation of data subject rights using the NUM-RDP as an example. The designed concept could help to overcome challenges in different consent-scenarios (opt-in, opt-out). Furthermore, it could streamline communication and data linkage processes between institutions and countries in future research projects.\u003c/p\u003e","manuscriptTitle":"Implementing informed consent in federated medical research: a blueprint designed to safeguard data subject rights in Germany","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2026-03-19 16:01:01","doi":"10.21203/rs.3.rs-9069363/v1","editorialEvents":[{"type":"communityComments","content":0},{"type":"reviewerAgreed","content":"","date":"2026-03-16T11:22:01+00:00","index":0,"fulltext":""},{"type":"reviewersInvited","content":"","date":"2026-03-16T11:16:46+00:00","index":"","fulltext":""},{"type":"editorAssigned","content":"","date":"2026-03-10T04:10:37+00:00","index":"","fulltext":""},{"type":"submitted","content":"Journal of Translational Medicine","date":"2026-03-09T02:32:24+00:00","index":"","fulltext":""}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"journal-of-translational-medicine","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"jtrm","sideBox":"Learn more about [Journal of Translational Medicine](http://translational-medicine.biomedcentral.com)","snPcode":"","submissionUrl":"https://www.editorialmanager.com/jtrm/default.aspx","title":"Journal of Translational Medicine","twitterHandle":"@BioMedCentral","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"em","reportingPortfolio":"BMC/SO AJ","inReviewEnabled":true,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"92baaf2c-46d3-4a8b-b1ba-1ac94b35e61d","owner":[],"postedDate":"March 19th, 2026","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"under-review","subjectAreas":[],"tags":[],"updatedAt":"2026-05-17T14:55:47+00:00","versionOfRecord":[],"versionCreatedAt":"2026-03-19 16:01:01","video":"","vorDoi":"","vorDoiUrl":"","workflowStages":[]},"version":"v1","identity":"rs-9069363","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-9069363","identity":"rs-9069363","version":["v1"]},"buildId":"XKTyCvWXoU3ODBz1xrDgd","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}