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

Bisher gestellte Fragen

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.

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.

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