The University Medicine Greifswald’s Trusted Third Party Dispatcher: State-of-the-Art Perspective Into Comprehensive Architectures and Complex Research Workflows

With great interest we read the article entitled “Development of a Trusted Third Party at a Large University Hospital: Design and Implementation Study” by Wündisch et al. (1). The objective of the article was to introduce a “comprehensive architecture for a Trusted Third Party (TTP) that aims to support a wide range of different research projects” incorporating “a fine-grained authentication and authorization model [and] a modern REST-API” in order to “support cross-service workflows”. Their work is based on well-established software components of the University Medicine Greifswald for record linkage (E PIX®), pseudonymisation (gPAS®) and consent management (gICS®) (2). With this letter, we aim to place the authors’ statement that “the literature lacks insights into the design of more comprehensive architectures that support complex research workflows that are actually in production use” into a state-of-the-art perspective to prevent any misleading impressions. While the authors concede that “research exists on the components mentioned above”, their article contains several inaccuracies that we would like to highlight in the following. The functional scope of the existing solutions (E-PIX, gPAS, gICS) is presented in Table 1. However, the existing workflow management solution of the University Medicine Greifswald (TTP Dispatcher) was not displayed (2). The authors only reference this highly relevant component later in text of their article. Furthermore, the content and designation of Table 2 “additional functional requirements” misleadingly suggests that the listed requirements are not covered by the solutions mentioned in Table 1. In published work (2) (3) and available materials (4), many of the checkmarks listed in Table 2 have been successfully validated, and moreover, the compliance of the tools with the pertinent TMF guidelines (3) has been demonstrated. Unlike the authors’ indication, the TTP dispatcher solution from the University Medicine Greifswald provides a common REST-API across all TTP services (based on E-PIX, gPAS and gICS) and enables cross-service workflows (2). Contrary to the description by Wündisch et. al., the dispatcher architecture allows the implementation of complex research workflows. We published a list of available workflows together with a corresponding example (“automatic creation of pseudonyms linked to the primary identifier when registering a patient or study participant”)(2). Since 2018, the existing TTP dispatcher solution has been made available in various project collaborations (3). In 2024, the TTP dispatcher is used in projects throughout Germany and the comprehensive documentation for the latest software version is publicly available (4). With regard to the relevance of the secure authentication mechanisms, we fully agree with the authors that OAuth 2.0 support based on OIDC and a fine-grained authorisation model are essential for securing TTP-Services. Therefore, Keycloak-support for E-PIX, gPAS and gICS is operational since 2022 (5). We can also only encourage the interoperability endeavours of the authors with regard to HL7 FHIR. For this reason, the University Medicine Greifswald has actively contributed to the HL7 FHIR standard and has fully implemented it (5). We hope that our additions have clarified any remaining uncertainties and welcome further opportunities to exchange and share our practical experience with the authors.

Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.