Die Lösungsbausteine der Treuhandstelle finden zunehmend Verbreitung in der Community. Immer mehr Konsortien, Standorte und Projekte haben sich bewusst für die Verwendung unserer Lösungen zur Realisierung ihrer individuellen Anwendungsszenarien entschieden. Zu den Anwendern gehören Register und Krebsregister, lokale Treuhandstellen der MII und des NUM, diverse Studienprojekte und ausgewählte DZGs. Um Erfahrungen untereinander auszutauschen und Ergebnisse miteinander zu teilen haben wir den THS Community Dialog ins Leben gerufen.
Der nächste THS Community Dialog findet auf Anfrage statt. Sie würden gerne teilnehmen, sind aber kein regelmäßiger Teilnehmer? Schicken Sie uns einfach eine kurze Nachricht.
Lust Ideen mit der Community zu teilen?
Sie haben eigene Lösungen für die THS Tools entwickelt oder Anleitungen geschrieben und wollen diese gern im Community-Dialog vorstellen oder allen Interessierten über unser neues „ths-community“-Repository bereitstellen?
Frühere Community Dialoge
Sollten Sie einen Termin verpasst haben, finden Sie hier die Folien früherer Community Dialoge zum Download.
FAQ
Hier finden Sie eine kategorisierte Auswahl von Fragen und Antworten aus vorherigen Terminen des THS Community Dialogs. Sollten Sie noch Fragen haben, melden Sie sich einfach für den nächsten Dialog an.
Ausführliche Anleitungen zur Aktualisierung der THS-Werkzeuge werden hier bereitgestellt.
ths-greifswald.de/e-pix/update
Einfach gesagt: ja.
Auf Anfrage können Sie Zugang zum THS-GitLab erhalten und selbständig für das ausgewählte Werkzeug Bugs melden. GitLab hält Sie automatisch über künftige Entwicklungen zu dem von Ihnen gemeldeten Bug auf dem Laufenden.
Natürlich ist es auch möglich neue Ideen für Features vorzustellen und ein mögliches Vorgehen mit uns abzustimmen.
Nutzen Sie einfach unser Kontaktformular.
Ja, das ist natürlich möglich. Für diesen Anwendungsfall empfehlen wir die Verwendung von Präfixen. Details zur Konfiguration der Domänen finden Sie unter Kapitel 9.4.3 im Handbuch des E-PIX.
Grundsätzlich ist eine Individualisierung dieses Logos, z.B. gICS oben links im Web-Frontend nicht vorgesehen.
Technisch ist es mit ein wenig Aufwand aber dennoch denkbar. Dazu müssen folgende Schritte umgesetzt werden:
- *.war Datei mit Entpacker öffnen
- unter /html/public/assets/images/gics-logo.png gegen Individual-Logo austauschen
- neu deployen
Um die Authentizität einer Einwilligung sicherzustellen, ist aktuell entweder eine Einwilligung oder eine digitale Unterschrift erforderlich. Liegt weder eine Einwilligung noch eine digitale Unterschrift vor, ist es nicht möglich eine Einwilligung, Verweigerung oder einen Widerruf anzulegen. Das Feature „optionale digitale Unterschrift“ ist für gICS 2.14 geplant.
Die THS-Software-Werkzeuge gehen auf das MOSAIC-Projekt zurück, welches die DFG von 2012 bis 2015 gefördert hat und dessen Ergebnisse wir regelkonform per GitHub dauerhaft dokumentiert haben.
Diese Quellen sind im GitHub ausdrücklich als „nicht aktuell“ gekennzeichnet.
Unsere Werkzeuge haben wir seitdem deutlich weiterentwickelt. Die getesteten Weiterentwicklungs-Stände stellen wir seither auf der Website https://ths-greifswald.de/forscher anwendungsbereit für die Community zur Verfügung.
Eine Dispatcher-Lösung bietet die Möglichkeit die Funktionalitäten von E-PIX, gPAS und gICS geeignet zu kombinieren. Diese verfügt über eine umfangreiche REST-Schnittstelle, deren Spezifikationen Sie direkt online einsehen können.
Aufwände sind stets projektspezifisch und nur nach ausführlicher Befassung mit Projekt (Hintergrund, Umfang und Anpassungsbedarfe) abschätzbar.
Die Anpassung einzelner Bezeichner ist aktuell nicht möglich. Um weitere Daten bei der Erfassung einer Einwilligung zu erfassen, können benutzerdefinierte Felder in der Vorlage ergänzt werden. Diese besitzen eine Bezeichnung, welche auf der Einwilligung dargestellt wird.
Aktuell unterstützen die THS-Tools Keycloak und gRAS. Weitere Details finden Sie unter https://www.ths-greifswald.de/faq-items/keycloak-authentifizierung-autorisierung.
Die Kombination von Keycloak und ADFS scheint aber technisch als Brokered Identity Provider möglich: https://www.alphabold.com/ms-adfs-configuration-in-keycloak/
Sollten Sie die Kombination von Keycloak und ADFS ausprobiert haben, senden Sie uns Ihre Erfahrung gerne an kontakt-ths@uni-greifswald.de.
Der THS-Dispatcher wird bereits in einer Vielzahl von Vorhaben deutschlandweit genutzt. Trotzdem wird der THS-Dispatcher auf der THS-Website nicht als separates Produkt, analog zu gPAS, gICS und E-PIX, promotet.
Das hat einen einfachen Grund.
Die 3 THS-Werkzeuge wurden im Rahmen des DFG-geförderten MOSAIC-Projektes (HO 1937/2-1) unter Open Source-Lizenz veröffentlicht und haben bereits Produktreife erlangt.
Die Integration der Werkzeuge in vorhandene IT- und Forschungsinfrastrukturen erfolgt ausgerichtet an individuellen Prozessen und technischen Randbedingungen eines Vorhabens. Für die Abbildung von projektspezifischen Anwendungsszenarien und die Prozessintegration wurde nach Abschluss der DFG-Förderung ein zusätzliches und separates THS-Dispatcher-Modul für werkzeugübergreifende Abläufe (Workflows) realisiert. Der THS-Dispatcher komplettiert die 3 bereits verfügbaren Komponenten und ist die technische Grundlage für den flexiblen Aufbau von Treuhandstellen-Integrationslösungen.
Inbetriebnahme (Konfiguration, Anpassung) und Administration des THS-Dispatchers erfordern jedoch derzeit (noch) erhebliche technische Kenntnisse, zeitliche Aufwände und umfassende Beratungsleistungen unsererseits. Die gewünschte Produktreife ist also aus unserer Sicht noch nicht erreicht.
Daher bieten wir den THS-Dispatcher derzeit indidviduell und ausschließlich im Rahmen von offiziellen (wissenschaftlichen) Kooperations-Vorhaben zum Download an, um entstehende Beratungsaufwände und technischen Support zu finanzieren.
Die umfassende Dispatcher-Dokumentation stellen wir jedoch bereits öffentlich bereit unter: ths-greifswald.de/dispatcher/
Ist die Option „Scan-Upload verpflichtend“ in der Domänenkonfiguration gewählt, so kann eine Einwilligung, Widerruf oder Verweigerung nur angelegt werden, wenn ein Scan der jeweiligen Einwilligung direkt mit hochgeladen wird.
KeyCloak ist eine Open-Source-Lösung für Identitäts- und Zugriffsmanagement, die mit verschiedenen Webservern wie nginx zusammenarbeiten kann. Nginx ist ein leistungsfähiger und flexibler Webserver, der auch als Reverse-Proxy, Load-Balancer oder HTTP-Cache fungieren kann. Docker ist eine Software-Plattform, die es ermöglicht, Anwendungen in isolierten Containern auszuführen, die leicht zu erstellen, zu verteilen und zu verwalten sind.
Die Kombination von KeyCloak, nginx und docker kann einige Vorteile bieten, wie z.B.:
- Skalierbarkeit: Man kann mehrere Instanzen von KeyCloak und nginx in verschiedenen Containern ausführen und sie je nach Bedarf hoch- oder herunterskalieren.
- Sicherheit: Man kann HTTPS (Hypertext Transfer Protocol Secure) verwenden, um eine verschlüsselte Verbindung zwischen dem Client und dem Server zu gewährleisten. HTTPS verhindert, dass Dritte die übertragenen Daten abfangen oder manipulieren können.
- Modularität: Man kann verschiedene Konfigurationen für KeyCloak und nginx erstellen und sie je nach Anwendungsfall anpassen.
Allerdings kann die Kombination von KeyCloak, nginx und docker auch einige Herausforderungen mit sich bringen, wie z.B.:
- Komplexität: Man muss mehrere Komponenten konfigurieren und koordinieren, um sicherzustellen, dass sie korrekt miteinander kommunizieren. Dies erfordert ein gutes Verständnis der Funktionsweise von KeyCloak, nginx und docker sowie der verwendeten Protokolle und Standards.
- Fehlerbehebung: Wenn etwas schief geht, kann es schwierig sein, die Ursache des Problems zu identifizieren und zu beheben. Man muss möglicherweise verschiedene Logdateien überprüfen, Netzwerkverbindungen testen oder Container neu starten.
- Kompatibilität: Man muss darauf achten, dass die verwendeten Versionen von KeyCloak, nginx und docker miteinander kompatibel sind und keine Konflikte verursachen.
Einige der am häufigsten auftretenden Probleme bei der Kombination von KeyCloak, nginx und docker sind:
Problem: Invalid parameter redirect_uri: Dieses Problem tritt auf, wenn KeyCloak die vom Client angeforderte Weiterleitungs-URL nicht validieren kann. Dies kann passieren, wenn die URL nicht mit der in KeyCloak registrierten URL übereinstimmt oder wenn sie nicht korrekt an KeyCloak weitergegeben wird. Um dieses Problem zu beheben, muss man sicherstellen, dass die URL in KeyCloak korrekt konfiguriert ist und dass nginx die richtigen Header an KeyCloak sendet.
Diese Header sind:
- X-Forwarded-For: Dieser Header gibt die IP-Adresse des Clients an.
- X-Forwarded-Proto: Dieser Header gibt das Protokoll an, das vom Client verwendet wird (z.B. http oder https).
- X-Forwarded-Host: Dieser Header gibt den Hostnamen des Clients an (z.B. localhost oder test.com).
Ein Beispiel für eine minimale nginx-Konfiguration, die diese Header setzt, finden Sie hier.
Problem: HTTPS required: Dieses Problem tritt auf, wenn KeyCloak HTTPS erfordert, aber nginx HTTP verwendet oder umgekehrt. Dies kann passieren, wenn KeyCloak im Produktionsmodus läuft oder wenn nginx als TLS-Terminator fungiert. Um dieses Problem zu beheben, muss man sicherstellen, dass KeyCloak und nginx das gleiche Protokoll verwenden oder dass sie entsprechend konfiguriert sind, um mit einem anderen Protokoll zu kommunizieren.
Dazu muss man einen Proxy-Typ für KeyCloak angeben. Es gibt drei mögliche Proxy-Typen:
- edge: Dieser Typ ermöglicht die Kommunikation über HTTP zwischen KeyCloak und nginx, wobei nginx eine sichere Verbindung über TLS mit den Clients aufrechterhält.
- reencrypt: Dieser Typ erfordert die Kommunikation über HTTPS zwischen dem Proxy und KeyCloak.
- passthrough: Dieser Typ ermöglicht die Kommunikation über HTTP oder HTTPS zwischen dem Proxy und KeyCloak. Dieser Modus ist geeignet für Bereitstellungen, bei denen der Reverse-Proxy nicht TLS beendet.
Ein Beispiel für einen benutzerdefinierten Eintrittspunkt für das offizielle Docker-Image von KeyCloak, das den Proxy-Typ angibt, finden Sie hier.
Problem: Connection refused: Dieses Problem tritt auf, wenn nginx keine Verbindung zu KeyCloak herstellen kann. Dies kann passieren, wenn KeyCloak nicht läuft, wenn die Portnummer falsch ist oder wenn das Netzwerk blockiert ist. Um dieses Problem zu beheben, muss man sicherstellen, dass KeyCloak läuft, dass die Portnummer in nginx mit der in KeyCloak übereinstimmt und dass das Netzwerk die Verbindung erlaubt. Dazu muss man möglicherweise die Firewall-Regeln überprüfen oder ein Docker-Netzwerk erstellen.
Dieser FAQ wurde am 2023-08-07 von BING-Chat generiert.
Einfache Frage, einfache Antwort.
Ja, die Option zum Setzen oder Ändern des Qualitätsstatus wird entweder in der jeweiligen Dokumentenliste über das Kontextmenü oder über die Dokument-Details erreicht. Der Qualitätsstatus lässt sich dann auch nachträglich noch anpassen.
In der Änderungshistorie sind in den Details des Dokuments aufgelistet.
Technisch ist die Unterscheidung von Admin/User Funktionalitäten für die FHIR-Endpunkte von E-PIX, gPAS, gICS bereits vorbereitet, werden aber derzeit nur von gICS verwendet.
„Die Angabe einer Admin-Role per Wildfly-Variable oder Wildfly-Konfiguration wird derzeit nur bei der Generierung von FHIR-ConsentPatient-Resourcen berücksichtigt. Da ein Consent durchaus mehrere SignerIds besitzen kann und diese Informationen nicht jedermann zugänglich sein sollten, kann der Umfang der im FHIR Consent Patient exportierten Identifier auf diese Weise reglementiert werden.“
Weitere Erläuterungen und Konfigurationsdetails finden Sie unter Kapitel 10 im Handbuch des gICS und unter ths-greifswald.de/ttpfhirgateway/keycloak.
Grundsätzlich ist eine nachträgliche Integration des Dispatchers möglich. Projektspezifika sind (in den meisten Fällen) per Konfiguration entsprechender Workflows umsetzbar und auch im Nachgang anpassbar.
Details finden Sie unter ths-greifswald.de/dispatcher
Über die Oberfläche des gICS wird eine Unterschrift über HTML5-Mechanismen, wie Sie auch auf Smartphones etabliert sind erzeugt (Canvas, Linie à Bild). Dieses Bild wird im Base64-Format in der Datenbank gespeichert. Die Web-Oberfläche des gICS gibt Auskunft, um welche Art der Unterschrift es sich dabei handelt (Textform i.S.d. § 126b BGB. Bei solchen Erklärungen ist der Aussteller erkennbar und sie werden dauerhaft auf einem Datenträger (hier, in unserem digitalen Archiv des gICS) gespeichert.).
Alles Weitere zum Thema digitale Unterschrift, haben wir per Rechtsgutachten final klären lassen. https://www.ths-greifswald.de/neuer-tmf-band-in-zusammenarbeit-mit-der-universitaetsmedizin-greifswald-erschienen-data-privacy-in-european-medical-research/ (Kapitel 5, Consent)
Nichtsdestotrotz ist ein Anschluss von SignPads (z.B. signoTec) grundsätzlich technisch möglich. Das Speichern der erzeugten Signatur im Base64-Format im gICS ist jedoch nicht implementiert.
In den Tools gPAS, gICS und E-PIX ist die Verwendung von Domänen für die Mandantentrennung vorgesehen. Im Dispatcher können Sie dazu Studien anlegen.
Bitte ziehen Sie ebenso in Betracht, separate Infrastrukturen je Mandant aufzubauen.
Nein. Das ist aktuell nicht möglich und nicht geplant.
Derzeit ist es nicht möglich, Nutzer domänenspezifisch zu autorisieren. Dieses Feature ist für Ende 2022 geplant.
Ein Beispiel zur Anlage einer Einwilligung am Beispiel des MII Broad Consent finden Sie im Anwenderhandbuch des gICS unter Kapitel 15.1. Diese Einwilligung wird via addConsent-Methode der SOAP-Schnittstelle eingespielt.
Eine Demo-Schnittstelle finden Sie hier.
Während E-PIX, gPAS und gICS bereits verfügbare Produkte und separat nutzbare Werkzeuge sind, fehlt dem Dispatcher dieser Reifegrad.
Obwohl der Dispatcher bereits in mehreren Forschungsprojekten eingesetzt wird, erfolgen projektindividuelle Konfiguration des Dispatchers und erforderlichen Anpassungen der Workflows derzeit manuell. Der Individualisierungsprozess erfordert daher mehr als grundlegende Programmier- oder Datenbankkenntnisse und ein tiefes Verständnis der Dispatcher-Architektur.
Personelle Support-Aufwände werden durch Koop-Verträge abgedeckt. Eine Weiterentwicklung des Dispatchers erfolgt im Rahmen laufender Kooperationen.
Nein, es findet keinerlei OCR-Erkennung statt. Im Zuge der ohnehin erforderlichen Qualitätsprüfung sind Ort und Datum der Unterschrift bzw. weitere Angaben (Stand: gICS Version 2.13.3) derzeit manuell zu übertragen.
Intensive Einarbeitungen im Rahmen laufender und geplanter Kooperationen (z.B. MIRACUM) wurden bereits mehrfach durchgeführt. Eine Einarbeitung ist somit im Zuge einer Kooperation grundsätzlich möglich.
Nutzen Sie bitte ebenfalls die frei verfügbare Dokumentation zum Dispatcher, welche hier zu finden ist: ths-greifswald.de/dispatcher
Nein, die Quelle der Signer ID bei geparsten Einwilligungsinhalten ist der QR-Code. Der QR-Code bleibt bei nachträglicher Eintragung der Signer ID im Eingabefeld der Einwilligung unverändert.
Um die Inhalte des QR-Code zu beeinflussen, muss die Signer ID bereits beim Generieren der Vorlage bekannt gemacht werden (vorausgefüllte Vorlage).
Greifswald (MIRACUM) setzt den Dispatcher in vielfältigen Vorhaben (n>10) ein. Die Herausgabe des Dispatchers erfolgte bereits mehrfach im Rahmen aktueller bzw. geplanter Kooperationen, u.a. an
- Gießen, Marburg, Magdeburg, Erlangen, Freiburg und Dresden im Rahmen von MIRACUM
- Heilbronn (Molit Institut) im Rahmen von HiGHmed
- Hamburg – UKE im Rahmen des SMITH-Projekts
Die Taskforce Consent Umsetzung der MII listet im MII Kerndatensatzmodul „Consent“ zahlreiche Beispiele unter Verwendung von Token in Pipe-Notation.
Beispiel:
[baseUrl]/Consent?mii-provision-provision-code=urn:oid:2.16.840.1.113883.3.1937.777.24.5.3|2.16.840.1.113883.3.1937.777.24.5.3.8
Diese Beispiele scheinen im TTP-FHIR Gateway einen Bad-Request (HTTP 400) zu erzeugen.
Grund:
Die Verwendung von Pipes (‚|‘) in GET-Requests (zur Separierung von System+Code), kann je nach Server-Konfiguration zu Fehler führen. Verwenden Sie anstelle der „|-Notation“ das Äquivalent „%7C“. Dies ist auch im gICS-spezifischen Implementation Guide beschrieben.
Es gibt unterschiedliche Ansätze Benutzern und Systemen Zugriff auf unsere Tools (Authentifizierung) zu geben und Ihnen entsprechende Rechte und Rollen (Autorisierung) zuzuweisen.
Absicherung der Web-Oberflächen mit Keycloak
In der Standard-Ausgabe unserer Tools ist keine Authentifizierung notwendig. Möchte man die Web-Oberflächen von gPAS, E-PIX und gICS jedoch nur
für bestimmte Nutzergruppen zugänglich machen oder Funktionsumfänge einschränken, kann dies mit Keycloak erfolgen.
Einrichtung
Details zur Vorbereitung des Keycloak-Servers für unsere Tools unter: https://www.ths-greifswald.de/ttp-tools/keycloak
Die Einrichtung des jeweiligen Tools zur Anbindung des Keycloak-Servers sind per Config–Datei und Environment–Variablen vor Start des Docker–Compose möglich. Details sind in den jeweiligen README.md des Releases beschrieben.
Wie die Absicherung einer FHIR-Schnittstelle mit Keycloak erfolgt, finden Sie unter: https://www.ths-greifswald.de/ttpfhirgateway/keycloak
Empfehlungen zur Absicherung der Anwendungsserver von E-PIX, gPAS und gICS
Der Zugriff auf relevante Anwendungs- und Datenbankserver der Treuhandstellen-Werkzeuge sollte nur für autorisiertes Personal und über autorisierte Endgeräte möglich sein. Wir empfehlen daher zusätzlich die Umsetzung nachfolgender IT-Sicherheitsmaßnahmen:
- Betrieb der relevanten Server in separaten Netzwerkzonen (getrennt von Forschungs- und Versorgungsnetz)
- Verwendung von Firewalls und IP-Filtern
- Zugangsbeschränkung auf URL-Ebene mit Basic Authentication (z.B. mit NGINX oder Apache)
Die derzeitigen FHIR-Funktionalitäten des gPAS finden Sie in folgender Übersicht: https://ths-greifswald.de/gpas/fhir
Diese beinhalten primär lesende Inhalte auf die FHIR Schnittstelle.
Wie eine Domäne mithilfe der SOAP-Schnittstelle im gPAS angelegt werden kann, ist im Anwenderhandbuch des gPAS „Nutzung der SOAP-Schnittstelle“ beschrieben.
Nein, das ist derzeit nicht vorgesehen. Die angelegte Person sollte gelöscht und neu erfasst werden.
Ja und Ja.
Um Entwicklungsstände unserer Werkzeuge aus geförderter Projekten, wie zum Bespiel den DFG-Projekten MOSAIC und MAGIC, dauerhaft für die ehemaligen Fördermittelgeber bereitzustellen nutzen wir das öffentlich zugängliche GitHub (z.B. https://github.com/mosaic-hgw/gICS).
Innerhalb der Treuhandstelle koordinieren wir unsere Entwicklungsarbeiten per GitLab und sichern die kontinuierliche Qualität der Arbeit mittels SonarQube.
Es werden sämtliche durchgeführte Aktionen (Pseudonym erzeugt, gelöscht usw.) in verschiedenen Klassen des Package org.emau.icmvc.ttp.psn.frontend.controller auf dem entsprechenden Level geloggt. Der Level wird im Frontend angezeigt.
Blaue Erfolgsmeldungen = INFO
Gelbe Warnhinweise = WARN
- Seitenaufrufe werden NICHT geloggt
- Fehlerseiten werden in der Klasse org.icmvc.ttp.web.controller.Error auf ERROR Level geloggt
- Login und Logout im Webfrontend werden in der Klasse org.icmvc.ttp.web.controller.Authorization.java auf INFO Level geloggt. Falsche Credentials in der gleichen Klasse auf ERROR Level
Anpassungen sind generell möglich: In der gPAS-CLI des Docker-Containers wird zwar ein Logger angelegt, der aber auch nur im INFO-Level auf die Console schreibt. Wenn eine Log-Datei, speziell für den gPAS, gewünscht wird, kann man diese gern selbst aktivieren im docker-compose.
Der aufgezeigte Ansatz ist für alle Treuhandstellen-Tools analog anwendbar.
Wir haben unsere Werkzeuge unter AGPLv3-Lizenz veröffentlicht. Also ist eine Bereitstellung des Source Code grundsätzlich möglich.
Auf Anfrage gewähren wir Zugang auf aktuellen Source Code direkt per GitLab.
Bei Versionswechseln der Werkzeuge kann es beim Start und zyklisch im Betrieb zu Warnungen (Failed to reinstate timer ‚*.StatisticManagerBean‘) im Serverlog kommen.
Grund hier ist eine verschobene Timer-Funktion innerhalb der Werkzeuge. Dies kann behoben werden, indem im Verzeichnis vom Wildfly die unter [Wildfly-Verzeichnis]/standalone/data/timer-service-data enthaltenen Dateien entfern werden. Danach kann der Dienst neu gestartet werden. Die neuen Dateien werden danach automatisch erzeugt und es kommt diesbezüglich zu weiteren keinen Warnungen mehr.
Kurz gesagt: Ja.
Wir ermöglichen und begrüßen grundsätzlich eine aktive Mitarbeit an unseren Tools.
Dazu pflegen wir natürlich separate GitLab-Projekte je Werkzeug und implementieren neue Features stets in separaten Branches. Dabei achten wir auf einheitliche Qualitätsvorgaben und eine optimale Testabdeckung. Dabei werden wir durch SonarQube unterstützt.
Ist der neue Code formal qualitätsgeprüft und getestet, erfolgt eine letzte inhaltliche Validierung der Umsetzung.
Sind alle Beteiligten mit dem Ergebnis zufrieden, kann das neue Feature in den offiziellen Master einfließen und künftiger Bestandteil unserer Tools werden.
Den dafür notwendigen Zugang zum GitLab ermöglichen wir auf Anfrage.