Community

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 auf Anfrage statt.

JETZT ANMELDEN

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.

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.

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: https://www.ths-greifswald.de/dispatcher-spezifikation-online-verfuegbar/

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 ConfigDatei und EnvironmentVariablen vor Start des DockerCompose 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.

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

ths-greifswald.de/gpas/update

ths-greifswald.de/gics/update

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 derzeitigen FHIR-Funktionalitäten des gPAS finden Sie in folgender Übersicht: https://simplifier.net/guide/ttp-fhir-gateway-ig/Pseudonymmanagement

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. Nutzen Sie dafür bitte unser Kontaktformular.

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 über unser Kontaktformular.

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:

  1. *.war Datei mit Entpacker öffnen
  2. unter /html/public/assets/images/gics-logo.png gegen Individual-Logo austauschen
  3. 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.