Die Werkzeuge der Treuhandstelle finden zunehmend Verbreitung in der Community. Immer mehr Konsortien, Standorte und Projekte haben sich bewusst für die Verwendung von E-PIX, gICS und gPAS zur Realisierung ihrer individuellen Anwendungsszenarien entschieden. Das freut uns sehr.
Wir haben über die letzten Monate zahlreiche technische und organisatorische Fragen zu Einrichtung und Betrieb unserer Werkzeuge bekommen. Dies schloss natürlich auch Hosting- und Beratungsanfragen ein, die wir bis heute gern individuell beantwortet haben.
Um diese Beratungsleistung zu bündeln und gleichzeitig allen Anwendern die Möglichkeit zu geben, sich kennenzulernen und Erfahrungen untereinander auszutauschen, haben wir die THS Community ins Leben gerufen.
Der THS Community Dialog:
- bietet eine zentrale Anlaufstelle für Anwender-Fragen, die über den Inhalt der Handbücher hinausgehen
- hilft Hintergründe besser zu verstehen und gemeinsam mit den Entwicklern erforderliche Antworten zu finden.
- schafft die Basis für eine gemeinsam aufgebaute FAQ.
- erfordert eine persönliche Anmeldung für die Web-Konferenz und ggf. Einreichung von Fragen im Vorfeld
Der nächste THS Community Dialog findet am 1. Juni 2023 in der Zeit von 14:00 – 15:30 Uhr statt. Den Fokus werden wir auf die Vorstellung der Frühjahrs-Releases (Mai 2023) unserer Tools legen. Sie wollen teilnehmen und sind kein Dauerteilnehmer? Eine kurze Nachricht an uns reicht.
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.
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.
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/
Einfache Frage, einfache Antwort.
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
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.
Derzeit ist es nicht möglich, Nutzer domänenspezifisch zu autorisieren. Dieses Feature ist für Ende 2022 geplant.
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.
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
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
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)
Nein, das ist derzeit nicht vorgesehen. Die angelegte Person sollte gelöscht und neu erfasst werden.
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.
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.
Ausführliche Anleitungen zur Aktualisierung der THS-Werkzeuge werden hier bereitgestellt.
ths-greifswald.de/e-pix/update
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.
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 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.
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.
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.
Ü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.
Nein. Das ist aktuell nicht möglich und nicht 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.
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.
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).
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.
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.
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.
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.
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.
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.
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
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.
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.
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.