GTDS - Benutzerbeiträge [de]

Export zum Kinderkrebsregister (DKKR)

2026-02-23T10:33:55Z

Udo:

Der Export zum Kinderkrebsregister erfolgt über Leitstelle/Sonstige Exporte (im WebGTDS Allg. Exporte). Im Moment ist der Status noch "Prototyp", d.h. es muss mit Änderungen gerechnet werden, die auf Grund von praktischen Erfahrungen einfließen. Daher werden die Einträge der zu exportierenden Datensätze auch noch mit einem SQL*Plus-Skript (obds_aus_patids_krki.sql) erstellt. Über die Masken erfolgt nur das Auslesen.

Der Export erfolgt zeitraumbasiert auf der Basis der betreffenden erstellten/geänderten Diagnosen/Verläufe/Abschlüsse im Exportzeitraum. Dieser lässt sich im Skript über DEFINE-Anweisungen einstellen

<pre>
DEFINE von="to_date('01.01.2000', 'dd.mm.yyyy')"
DEFINE bis="to_date('01.01.2027', 'dd.mm.yyyy')"
</pre>
Die Inhalte sind beschrieben unter:

https://plattform65c.atlassian.net/wiki/spaces/UMK/pages/822607873/Meldungen+an+das+DKKR

== Konfiguration und Dokumentation der Erweiterungen ==
* Die zusätzlichen Items werden per Skript eingespielt, einschließlich der erforderlichen Konversionen.
* Um die Erfassung des Geburtsorts zu aktivieren (nur im WebGTDS verfügbar), muss der GTDS-Parameter PATIENT.GEBURTSORT.ANZEIGEN auf Ja gesetzt werden.
* Die Wohnadresse bei Geburt kann über einen Eintrag in "Vorangehende Anschrift" mit einem Gültigkeitszeitraum, der das Geburtsdatum einschließt, angegeben werden.
* Alle Zusatzitems können im Rahmen der Diagnosedaten eingegeben werden.
* Die Angabe DKKR_Hauptwohnsitz_bei_Erstdiagnose_in_Deutschland ist ein Ja/Nein-Zusatzitem und Pflicht, ebenso wie die Angabe zur Einwilligung.
* Die Melder_IDs werden analog denen der Meldung an die Landeskrebsregister konfiguriert (also Einträge in ID_MATCH und GTDS-Parameter der Art KRKI.MELDER_ID.xxxxxx.DETAILS_IN). Auch die Absender_ID wird über KRKI.ABSENDER_ID gesetzt.
* Der Eintrag der Studien erfolgt über die normale Studienmaske
* Sollten mehrere Syndrome vorhanden sein, die auf unterschiedlichen genetischen Merkmalen beruhen, kann die Beziehung der Genetik zum Syndrom über den Eintrag des Syndromnamens in das Bemerkungsfeld (exakt gleiche Schreibweise) hergestellt werden.

Die DKKR-Erweiterungen werden mit jeder Meldung ausgelesen, sind also ggf. redundant, wenn mehrere Meldungen zu einem Patienten in einem Paket vorhanden sind.

[[Category:GTDS Klassisch GUI]]
[[Category:WebGTDS GUI]]

Export zum Kinderkrebsregister (DKKR)

2026-02-23T10:32:51Z

Udo:

Export zum Kinderkrebsregister (DKKR)

2026-02-23T10:13:15Z

Udo: Die Seite wurde neu angelegt: „Der Export zum Kinderkrebsregister erfolgt über Leitstelle/Sonstige Exporte (im WebGTDS Allg. Exporte). Im Moment ist der Status noch "Prototyp", d.h. es muss…“

Eigene Dateien einbinden

2026-02-10T12:44:57Z

Udo:

An manchen Stellen müssen im WebGTDS-Verzeichnisbaum eigene Dateien (z.B. Konfigurationen und Logos für Tumorkonferenzausdrucke oder Lade-Dateien für bestimmte Daten) hinterlegt werden.

Da bei einer neuen Distribution der WAR-Dateien der gesamte Verzeichnisbaum unter webgtds/tomcat/webapps/gtds neu erstellt wird, gehen eigene Anpassungen zunächst verloren. Daher müssen eigene Anpassungen so gespeichert werden, dass sie dort wieder erstellt werden können.

Damit das geschieht, müssen eigene Dateien unter webgtds/local gespeichert werden, und zwar in einem Unterverzeichnis, das dem Unterverzeichnis unter webgtds/tomcat/webapps/gtds entspricht, also z.B. gtds/xml/meine_bausteine.xml in local/xml/meine_bausteine.xml oder gtds/logos/mein_logo.jpg unter local/logos/mein_logo.jpg.

Beim ersten Anmelden im WebGTDS (nicht beim Start aus dem grafischen Client) nach einem Neustart der Anwendung bzw. des Tomcat werden alle neueren Dateien wieder an die entsprechende Stelle kopiert. Die "meine*"-Dateien werden in jedem Fall kopiert, auch wenn sie älter als die gelieferten sind.

[[Category:WebGTDS GUI]]

Meldeamtsdaten laden

2026-02-10T12:44:38Z

Udo:

Das Laden von Meldeamtsdaten erfolgt unter Leitstelle => Importe => M.amtsdaten-Import (Stand 14.08.2025)
== Konfiguration ==
Zunächst müssen die verfügbaren Verfahren in der Tabelle EIGENE_MERKMALE (Eigene Auswahllisten) bekannt gemacht werden, z.B. am Beispiel "AKDB"
* Merkmal: MELDEAMT.SKRIPTE
* Code: AKDB
* Beschreibung: AKDB

Im nächsten Schritt werden in den GTDS-Parametern die Parameter
* MELDEAMT.AKDB.LADESKRIPT <Name der Ladedatei>
* MELDEAMT.AKDB.VERFAHREN <Name des Verfahrens>
gesetzt. Mit MELDEAMT.SKRIPTCODE kann das bevorzugte Verfahren festgelegt werden (z.B. AKDB)

Die Ladedatei muss sich im webgtds/tomcat/webapps/gtds/xml-Verzeichnis befinden, entweder, weil sie zentral geliefert wird oder weil sie aus dem Verzeichnis webgtds/local/xml beim ersten Login nach Tomcat-Neustart dorthin kopiert wurde (siehe [[Eigene_Dateien_einbinden]]).

Das Verfahren bestimmt den Namen des Verfahrens im Masterdatensatz VITALBW_RUECKMELDUNG.

== Handhabung ==

Zunächst wird ein neues Paket erstellt und anschließend ausgewählt. Anschließend wird die Datendatei zum Upload ausgewählt. Über "Datei einlesen" erfolgt der Upload und das Einlesen der Datensätze in VITALBW_RUECKMELDESATZ.

[[Category:WebGTDS GUI]]

Vitalstatus-Paket

2026-02-10T12:44:19Z

Udo:

Beschriebene Version PACKAGE 070725 / BODY 070725

== FUNCTION sterbeinfo_eintragen(pid IN NUMBER, sterbdat IN DATE, meldung IN OUT VARCHAR2, modus IN VARCHAR2 DEFAULT NULL) RETURN VARCHAR2 ==

Diese Funktion bekommt ein Sterbedatum übergeben und trägt dieses in PATIENT.STERBEDATUM ein. Außerdem wird ggf. ein Abschluss eingetragen.

Der optionale Parameter '''modus''' modifiziert das Verhalten:

=== kein Parameter modus ===
Wenn bereits ein Sterbedatum eingegeben ist, erfolgt nur dann eine Änderung, wenn das Sterbedatum in PATIENT als monatsgenau gekennzeichnet ist und das übergebene Sterbedatum als taggenau definiert ist (Parameter STERBEDATUM_EXAKT s.u.). Ansonsten erfolgt gegebenenfalls ein Hinweis auf ein abweichendes Sterbedatum. Außerdem erfolgt kein Eintrag des Sterbedatums, wenn ein Patient_Dokument.Max_Datum größer dem Sterbedatum vorliegt (keine Berücksichtigung von Konsilen).
Nur, wenn ein Sterbedatum eingetragen oder geändert wird, erfolgt auch die Anlage eines Abschlusses, Details siehe Funktion ins_abschluss.

=== modus enthält PRIOMAX ===
Dieser Wert kann gewählt werden, wenn es sich um sehr verlässliche Angaben handelt. In diesem Fall werden auch abweichende Sterbedatumsangaben überschrieben sowie ein Abschluss angelegt, sofern nicht vorhanden

Der Rückgabewert ist "TRUE" bei Eintrag eines Sterbedatums, sonst "FALSE" oder bei Fehler "ERROR:<sqlerrm>"

== Parametrisierung ==
Parameter beginnend mit "VITALSTATUS." (unabhängig vom Verfahren)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_FREITEXT VERLAUF_FREITEXT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_BEURTEILUNG VERLAUF_BEURTEILUNG]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_UNMITTELBAR TODESURSACHE_UNMITTELBAR]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_GRUNDLEIDEN TODESURSACHE_GRUNDLEIDEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-ABTEILUNG_ID ABTEILUNG_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHFUEHRENDE_ABT_ID DURCHFUEHRENDE_ABT_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHGEFUEHRT_VON DURCHGEFUEHRT_VON]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-KEINE_ALTEN KEINE_ALTEN]

Parameter beginnend mit "VITBWRUECK.". Diese Parameter folgen dem Muster VITBWRUECK.<verfahren.><parameter> . Wenn kein entsprechender Parameter für das Verfahren gesetzt ist, wird ersatzweise VITBWRUECK.<parameter> genutzt.
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-STERBEDATUM_EXAKT STERBEDATUM_EXAKT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMORTOD TUMORTOD]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-AUTOPSIE AUTOPSIE]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-QUELLE_TODESURSACHEN QUELLE_TODESURSACHEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMOR_ID0 TUMOR_ID0]

Zusätzlich gibt es noch diesen Parameter (unabhängig vom Verfahren)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-VERLAUF_ABGLEICH-TUMOR_ID_VERFAHREN VITBWRUECK.VERLAUF_ABGLEICH.TUMOR_ID_VERFAHREN]

== FUNCTION ins_abschluss(pid IN NUMBER, meldung IN OUT VARCHAR2, fehler IN OUT VARCHAR2) RETURN NUMBER ==
Diese Funktion fügt für den übergebenen Patienten einen Abschluss "Tod" ein (sofern noch nicht vorhanden) und ordnet diesen bei mehreren Tumoren dem zeitlich letzten Tumor zu, sofern nicht generell eine Zuordnung zu Tumor_ID 0 konfiguriert ist (Parameter TUMOR_ID0). Ggf. erfolgt auch eine Vorbelegung von Tumortod, Autopsie und Quelle_Todesursachen bei PATIENT. Der Eintrag von Vorgabewerten für die unmittelbare Todesursache und das Grundleiden (fixe ICD-Werte) erfolgt, wenn das konfiguriert ist s.o.. Die Funktion prüft, ob bei dem Patienten ein Sterbedatum eingetragen ist. Rechteabteilung und durchführende Abteilung müssen konfiguriert sein.
Hinweis: Wenn der Tod bereits als tumorbedingt markiert ist (praktisch eher eine Ausnahme), erfolgt kein Eintrag eines Abschlusses, da der letzte Tumor nicht notwendigerweise der ursächliche sein muss.

[[Category:WebGTDS GUI]]

Konfiguration von Arbeitslisten

2026-02-10T12:43:57Z

Udo:

Arbeitslisten sind eine spezielle Form von Abfragen, von denen aus in die Bearbeitung von Patienten oder Dokumenten verzweigt werden kann.
Sie können zentral durch die Entwickler erstellt und über SQL-Skripte verteilt oder auch selbst erstellt werden.
Die Quelle '''zentral''' ist dem Entwicklerteam vorbehalten und darf nicht benutzt werden, da solche Einträge ggf. überschrieben werden.

Dabei müssen folgende Namenskonventionen eingehalten werden:
* Die Spalte Pat_ID ermöglicht die Verzeigung auf Patientenebene
* Die Spalten Datenart und LfdNr ermöglicht die Verzweigung auf ein Dokument
** '''Hinweis''': Manche Dokumente benötigen zusätzlich die Tumor_ID als Kontext. Sonst können die Dokumente als gesperrt erscheinen.

Um eine Arbeitsliste einzurichten, müssen an zwei Stellen Einträge vorgenommen werden
# Erstellen der Abfrage über die Systempflege über die Systempflege => Abfragen
# Einbinden der Abfrage in ein dynamisches Modul über Systempflege => Dyn.Mod.

=== Erstellen der Abfrage ===
Im Prinzip beliebige Abfragen auf Patienten oder Dokumente, wobei die Namenskonventionen, s.o., eingehalten werden müssen.
Zu beachten ist weiterhin das Mengengerüst und die Performance. Browser werden ab sehr großen Datenmengen langsam oder verweigern ihren Dienst.
Zu notieren ist die Quelle und die LfdNr der Abfrage innerhalb der Quelle.

'''Hinweis:''' Ggf. ist es sinnvoll, die Abfrage mit Parametern zu versehen. Es ist möglich, mehrere Parameter anzugeben. Die Parameter sind alles Text-Parameter, d.h. z.B. Datumsangaben müssen innerhalb der Abfrage mit der gewünschten Formatmaske angegeben werden. Die Parameter werden im Feld "Bind Variablen" benannt und innerhalb der Abfrage mit vorangestelltem Doppelpunkt referenziert. Alle Parameter müssen bei der Abfrage eingegeben werden.

Beispiel: in Bind Param steht "VON BIS" (ohne Anführungszeichen). In Wherebedingung steht "Datum BETWEEN to_date(:von, 'dd.mm.yyyy') AND to_date(:bis, 'dd.mm.yyyy')" (ohne Anführungszeichen)

=== Einbinden der Abfrage in ein dynamisches Modul ===
Der Eintrag der Abfrage in ein dynamisches Modul sorgt dafür, dass die Abfrage unter dem Punkt Arbeitsliste erscheint.
Folgende Einträge sind erforderlich:
# Kennung: ARBEITSLISTE
# Programm: ABFRAGE
# Parameter: <quelle>#<lfdnr>, also z.B. default_eigene#815
# Bezeichnung: treffende Bezeichnung
# Status_Aktiv: angehakt (J)

[[Category:WebGTDS GUI]]

Organspezifische Dokumentation

2026-02-10T11:55:47Z

Udo:

== Videotutorial ==
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/anlegen_organspezifischer_programme.mp4 Anlegen einer organspezifischen Dokumentation]

[[Category:Schulung]][[Category:WebGTDS GUI]]

Organspezifische Dokumentation

2026-02-10T11:53:13Z

Udo:

Organspezifische Dokumentation

2026-02-10T11:52:09Z

Udo:

== Videotutorial ==
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/anlegen_organspezifischer_programme.mp4 Anlegen einer organspezifischen Dokumentation]

Organspezifische Dokumentation

2026-02-10T11:50:46Z

Udo: Die Seite wurde neu angelegt: „== Videotutorial == * [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/anlegen_organspezifischer_programme.mp4 Video]“

== Videotutorial ==
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/anlegen_organspezifischer_programme.mp4 Video]

Menue-Anpassen

2025-09-25T18:05:55Z

Udo:

== Prinzip ==
GTDS regelt den Zugriff auf Masken und damit den Aufbau des Menübaums über Einträge in die Tabelle GTDS_PARAMETER, nach dem Schema "SERVLET.<maske>.ERLAUBT. Zulässige Werte sind "Ja" und "Nein". Wird bei der Bestimmung des Parameterwerts kein Wert gefunden, wird als Ergebnis "Ja" angenommen.

* Dabei haben Parameter für Masken, die als Servlets realisiert sind, den Servletnamen in Großbuchstaben an der Stelle von "<maske>" stehen.

* Bei Masken, die über das REST-API umgesetzt sind, erfolgt der Eintrag für <maske> nach dem Schema ../REST/XXXXX.HTML

Das, was in der Adressleiste hinter ; oder ? steht, wird nicht gewertet.

Beispiele:

{| class="wikitable"
|-
! URL in der Adressleiste (nach dem Server:Port) !! GTDS-Parameter
|-
| /gtds/servlet/haemonkausw || SERVLET.HAEMONKAUSW.ERLAUBT
|-
| /gtds/rest/lssErfassung.html || SERVLET.../REST/LSSERFASSUNG.HTML.ERLAUBT
|}

Damit lässt sich feingranuliert und benutzerbezogen festlegen, wie der Menübaum für einen Benutzer aussieht. Zur Feststellung, ob ein Benutzer eine bestimmte Maske aufrufen darf, wird seit August 2025 die Funktion param.servlet_erlaubt verwendet.

== Funktion param.servlet_erlaubt ==

{| class="wikitable"
|-
! Parameter !! Wert !! Beschreibung
|-
| welches || Maskenname|| Es wird hier nur der Servletname bzw. der REST-API-Name übergeben, also das, was oben unter <maske> beschrieben ist,
Beispiel:
* HAEMONKAUSW entsprechend dem Parameter SERVLET.HAEMONKAUSW.ERLAUBT
* ../REST/LSSERFASSUNG.HTML entsprechend dem Parameter SERVLET.../REST/LSSERFASSUNG.HTML.ERLAUBT
|-
| ben_id || Name eines Profilnutzers || Ein Profilnutzer ist eine echte Benutzerkennung oder ein fiktiver Name für ein Profil, also z.B. "TUMORKONFERENZ", "NORMALBENUTZER" "STAMMDATEN".
|-
| abt_id || Abteilung_ID || Wäre sinnvoll, wenn die Berechtigung von der Vorgabeabteilung eines Benutzers abhängig ist, vermutlich eher unrealistisch
|-
| mand_id || Mandant.ID || Wäre sinnvoll, wenn die Berechtigung vom Vorgabemandanten eines Benutzers abhängig ist, vermutlich eher unrealistisch
|}

Die Funktion arbeitet nach dem Prinzip der Spezifität/Priorität. Sie durchläuft alle Einträge für den gewünschten Parameter. Sobald einer auf die übergebenen Parameter ben_id/abt_id/mand_id passt, wird der Wert zurückgegeben. Höchste Priorität haben die Einträge für den aktuellen Datenbankbenutzer, niedrigste nicht spezifisch vergebene Einträge.

Priorität:

# Übereinstimmung in USER (DB-Benutzer)
# Übereinstimmung in ben_id
# Übereinstimmung in abt_id
# Übereinstimmung in mand_id
# Parameter ist nicht einschränkend gesetzt (globaler Parameter)
# Parametereintrag existiert nicht

Bemerkungen:

* Der Menübaum wird einmalig bei Anmeldung aus dem Vorgabekontext bestimmt, Änderungen des Kontexts werden nicht berücksichtigt.
* USER wird nicht übergeben, sondern ergibt sich aus der Datenbankverbindung.
* ben_id wird aus dem GTDS-Parameter WEBGTDS.MENUE_BENUTZER bestimmt.
* abt_id wird aus der Kontext-Abteilung bestimmt.
* mand_id wird aus dem Kontext-Mandanten bestimmt.
* Wenn zwar der passende Parametereintrag auf einer beliebigen Ebene existiert, aber keinen Wert hat, wird ersatzweise "Ja" angenommen. Parametereinträge auf der Ebene ben_id müssen aber immer einen Wert eingetragen haben.
* Wenn kein passender Parametereintrag vorhanden ist, wird ebenfalls ersatzweise "Ja" angenommen.
* Da der Menübaum nur einmalig festgelegt wird, könnte man argumentieren, dass man überhaupt keine Parameter übergeben müsste. Da die Funktion aber für alle potentiellen Masken aufgerufen wird, werden die Parameter einmalig vorab bestimmt.

== Anwendungshinweise ==

Die neu eingeführte Funktionalität eines Profilbenutzers ermöglicht eine einfachere Pflege über weniger Parametereinträge. So könnte "TUMORKONFERENZ" nur Masken zur Verfügung stellen, die zur Anmeldung und Durchführung einer Tumorkonferenz dienen, "NORMALBENUTZER" vielleicht nur die Dokumentationsmasken im engeren Sinn zur Verfügung stellen und "STAMMDATEN" zusätzlich den Zugriff auf die Stammdaten ermöglich. Zu beachten ist, dass es derzeit nicht vorgesehen ist, einem Benutzer mehrere Profile zuzuweisen.

Wie man vorgeht, wenn man ein Profil anlegen will, hängt davon ab, ob man eher Profile anlegen will, in denen man nur wenig verbieten oder viel verbieten will. Dementsprechend kann man die globalen Parameter eher auf Ja setzen und dann nur die Unerwünschten profilbezogen verbieten oder umgekehrt.

Die Einträge in der Tabelle MENUE_EINTRAG umfassen alle Masken. Die IDs sind dort thematisch gruppiert, z.B. sind (derzeit) zwischen 400 und 499 die Einträge für das Leitstellenmenü zu finden. So kann man skriptbasiert ganze Bereiche frei- oder abschalten. Beispiele findet man im Skript "init_menu_parameter.sql" im GTDS-Verzeichnis. Dieses Skript wird derzeit beim Durchführen eines Update oder Patches ausgeführt und sorgt dafür, dass der Bereich "Verwaltung" und einige registerspezische Masken nur für den Durchführenden des Updates (also OPS$TUMSYS) freigeschaltet sind, global aber auf "Nein" gesetzt werden.

Menue-Anpassen

2025-09-25T17:12:33Z

Udo: Die Seite wurde neu angelegt: „== Prinzip == GTDS regelt den Zugriff auf Masken über Einträge in die Tabelle GTDS_PARAMETER, nach dem Schema "SERVLET.<maske>.ERLAUBT. Zulässige Werte sind…“

== Prinzip ==
GTDS regelt den Zugriff auf Masken über Einträge in die Tabelle GTDS_PARAMETER, nach dem Schema "SERVLET.<maske>.ERLAUBT. Zulässige Werte sind "Ja" und "Nein". Wird bei der Bestimmung des Parameterwerts kein Wert gefunden, wird als Ergebnis "Ja" angenommen.

* Dabei haben Parameter für Masken, die als Servlets realisiert sind, den Servletnamen in Großbuchstaben an der Stelle von "<maske>" stehen.

* Bei Masken, die über das REST-API umgesetzt sind, ist der Eintrag für <maske> nach dem Schema ../REST/XXXXX.HTML

Das, was in der Adressleite hinter ; oder ? steht, wird nicht gewertet.

Beispiele:

{| class="wikitable"
|-
! URL in der Adressleiste (nach dem Server:Port) !! GTDS-Parameter
|-
| /gtds/servlet/haemonkausw || SERVLET.HAEMONKAUSW.ERLAUBT
|-
| /gtds/rest/lssErfassung.html || SERVLET.../REST/LSSERFASSUNG.HTML.ERLAUBT
|}

Damit lässt sich feingranuliert und benutzerbezogen festlegen, wie der Menübaum für einen Benutzer aussieht. Zur Feststellung, ob ein Benutzer eine bestimmte Maske aufrufen darf, wird seit August 2025 die Funktion param.servlet_erlaubt verwendet.

== Funktion param.servlet_erlaubt ==

{| class="wikitable"
|-
! Parameter !! Wert !! Beschreibung
|-
| welches || Maskenname|| Es wird hier nur der Servletname bzw. der REST-API-Name übergeben, also das, was oben unter <maske> beschrieben ist,
Beispiel:
* HAEMONKAUSW entsprechend dem Parameter SERVLET.HAEMONKAUSW.ERLAUBT
* ../REST/LSSERFASSUNG.HTML entsprechend dem Parameter SERVLET.../REST/LSSERFASSUNG.HTML.ERLAUBT
|-
| ben_id || Name eines Profilnutzers || Ein Profilnutzer ist eine echte Benutzerkennung oder ein fiktiver Name für ein Profil, also z.B. "TUMORKONFERENZ", "NORMALBENUTZER" "STAMMDATEN".
|-
| abt_id || Abteilung_ID || Wäre sinnvoll, wenn die Berechtigung von der Vorgabeabteilung eines Benutzers abhängig ist, vermutlich eher unrealistisch
|-
| mand_id || Mandant.ID || Wäre sinnvoll, wenn die Berechtigung vom Vorgabemandanten eines Benutzers abhängig ist, vermutlich eher unrealistisch
|}

Die Funk

Meldeamtsdaten laden

2025-08-14T16:33:10Z

Udo: /* Konfiguration */

Eigene Dateien einbinden

2025-08-14T16:31:56Z

Udo: Die Seite wurde neu angelegt: „An manchen Stellen müssen im WebGTDS-Verzeichnisbaum eigene Dateien (z.B. Konfigurationen und Logos für Tumorkonferenzausdrucke oder Lade-Dateien für bestim…“

Kategorie:WebGTDS GUI

2025-08-14T16:19:20Z

Udo: /* Konfigurationen */

== Konfigurationen ==
[[Konfiguration von Arbeitslisten]] 
[[Vitalstatus-Paket]] 
[[Meldeamtsdaten laden]] 
[[Eigene Dateien einbinden]]

Meldeamtsdaten laden

2025-08-14T16:11:43Z

Udo: /* Konfiguration */

Das Laden von Meldeamtsdaten erfolgt unter Leitstelle => Importe => M.amtsdaten-Import (Stand 14.08.2025)
== Konfiguration ==
Zunächst müssen die verfügbaren Verfahren in der Tabelle EIGENE_MERKMALE (Eigene Auswahllisten) bekannt gemacht werden, z.B. am Beispiel "AKDB"
* Merkmal: MELDEAMT.SKRIPTE
* Code: AKDB
* Beschreibung: AKDB

Im nächsten Schritt werden in den GTDS-Parametern die Parameter
* MELDEAMT.AKDB.LADESKRIPT <Name der Ladedatei>
* MELDEAMT.AKDB.VERFAHREN <Name des Verfahrens>
gesetzt. Mit MELDEAMT.SKRIPTCODE kann das bevorzugte Verfahren festgelegt werden (z.B. AKDB)

Die Ladedatei muss sich im webgtds/tomcat/webapps/gtds/xml-Verzeichnis befinden, entweder, weil sie zentral geliefert wird oder weil sie aus dem Verzeichnis webgtds/local/xml beim ersten Login nach Tomcat-Neustart dorthin kopiert wurde.

Das Verfahren bestimmt den Namen des Verfahrens im Masterdatensatz VITALBW_RUECKMELDUNG.

== Handhabung ==

Zunächst wird ein neues Paket erstellt und anschließend ausgewählt. Anschließend wird die Datendatei zum Upload ausgewählt. Über "Datei einlesen" erfolgt der Upload und das Einlesen der Datensätze in VITALBW_RUECKMELDESATZ.

Meldeamtsdaten laden

2025-08-14T15:57:52Z

Udo: /* Konfiguration */

Meldeamtsdaten laden

2025-08-14T15:43:28Z

Udo: /* Konfiguration */

Meldeamtsdaten laden

2025-08-14T15:42:06Z

Udo: Die Seite wurde neu angelegt: „Das Laden von Meldeamtsdaten erfolgt unter Leitstelle => Importe => M.amtsdaten-Import (Stand 14.08.2025) == Konfiguration == Zunächst müssen die verfügbare…“

Das Laden von Meldeamtsdaten erfolgt unter Leitstelle => Importe => M.amtsdaten-Import (Stand 14.08.2025)
== Konfiguration ==
Zunächst müssen die verfügbaren Verfahren in der Tabelle EIGENE_MERKMALE (Eigene Auswahllisten) bekannt gemacht werden, z.B.

#WEITERLEITUNG [[Screenshot_2025-08-14_
<gallery>
Screenshot_2025-08-14_172639.jpg.jpg|Beschreibung1
</gallery>
]]

Kategorie:WebGTDS GUI

2025-08-14T15:09:50Z

Udo: /* Konfigurationen */

== Konfigurationen ==
[[Konfiguration von Arbeitslisten]] 
[[Vitalstatus-Paket]] 
[[Meldeamtsdaten laden]]

Konfiguration von Arbeitslisten

2025-07-10T11:16:38Z

Udo: Hinweis auf Tumor_ID

Vitalstatus-Paket

2025-07-08T15:57:38Z

Udo: Anpassung der Beschreibung an Version 070725

Konfiguration von Arbeitslisten

2025-04-07T12:31:48Z

Udo: /* Erstellen der Abfrage */ Hinweis auf Bind-Variablen

Arbeitslisten sind eine spezielle Form von Abfragen, von denen aus in die Bearbeitung von Patienten oder Dokumenten verzweigt werden kann.
Sie können zentral durch die Entwickler erstellt und über SQL-Skripte verteilt oder auch selbst erstellt werden.
Die Quelle '''zentral''' ist dem Entwicklerteam vorbehalten und darf nicht benutzt werden, da solche Einträge ggf. überschrieben werden.

Dabei müssen folgende Namenskonventionen eingehalten werden:
* Die Spalte Pat_ID ermöglicht die Verzeigung auf Patientenebene
* Die Spalten Datenart und LfdNr ermöglicht die Verzweigung auf ein Dokument

Um eine Arbeitsliste einzurichten, müssen an zwei Stellen Einträge vorgenommen werden
# Erstellen der Abfrage über die Systempflege über die Systempflege => Abfragen
# Einbinden der Abfrage in ein dynamisches Modul über Systempflege => Dyn.Mod.

=== Erstellen der Abfrage ===
Im Prinzip beliebige Abfragen auf Patienten oder Dokumente, wobei die Namenskonventionen, s.o., eingehalten werden müssen.
Zu beachten ist weiterhin das Mengengerüst und die Performance. Browser werden ab sehr großen Datenmengen langsam oder verweigern ihren Dienst.
Zu notieren ist die Quelle und die LfdNr der Abfrage innerhalb der Quelle.

'''Hinweis:''' Ggf. ist es sinnvoll, die Abfrage mit Parametern zu versehen. Es ist möglich, mehrere Parameter anzugeben. Die Parameter sind alles Text-Parameter, d.h. z.B. Datumsangaben müssen innerhalb der Abfrage mit der gewünschten Formatmaske angegeben werden. Die Parameter werden im Feld "Bind Variablen" benannt und innerhalb der Abfrage mit vorangestelltem Doppelpunkt referenziert. Alle Parameter müssen bei der Abfrage eingegeben werden.

Beispiel: in Bind Param steht "VON BIS" (ohne Anführungszeichen). In Wherebedingung steht "Datum BETWEEN to_date(:von, 'dd.mm.yyyy') AND to_date(:bis, 'dd.mm.yyyy')" (ohne Anführungszeichen)

=== Einbinden der Abfrage in ein dynamisches Modul ===
Der Eintrag der Abfrage in ein dynamisches Modul sorgt dafür, dass die Abfrage unter dem Punkt Arbeitsliste erscheint.
Folgende Einträge sind erforderlich:
# Kennung: ARBEITSLISTE
# Programm: ABFRAGE
# Parameter: <quelle>#<lfdnr>, also z.B. default_eigene#815
# Bezeichnung: treffende Bezeichnung
# Status_Aktiv: angehakt (J)

Vitalstatus-Paket

2025-02-17T21:51:41Z

Udo: Beschreibung der neuen Funktion ins_abschluss

Beschriebene Version PACKAGE 160225 / BODY 160225

== FUNCTION sterbeinfo_eintragen(pid IN NUMBER, sterbdat IN DATE, meldung IN OUT VARCHAR2) RETURN VARCHAR2 ==
Diese Funktion bekommt ein Sterbedatum übergeben und trägt dieses in PATIENT.STERBEDATUM ein. Wenn bereits ein Sterbedatum eingegeben ist, erfolgt nur dann eine Änderung, wenn das Sterbedatum in PATIENT als monatsgenau gekennzeichnet ist und das übergebene Sterbedatum als taggenau definiert ist (Parameter STERBEDATUM_EXAKT s.u.). Ansonsten erfolgt gegebenenfalls ein Hinweis auf ein abweichendes Sterbedatum. Außerdem erfolgt kein Eintrag des Sterbedatums, wenn ein Patient_Dokument.Max_Datum größer dem Sterbedatum vorliegt (keine Berücksichtigung von Konsilen).

Nur, wenn ein Sterbedatum eingetragen oder geändert wird, erfolgt auch die Anlage eines Abschlusses, Details siehe Funktion ins_abschluss.

Der Rückgabewert ist "TRUE" bei Eintrag eines Sterbedatums, sonst "FALSE" oder bei Fehler "ERROR:<sqlerrm>"

== Parametrisierung ==
Parameter beginnend mit "VITALSTATUS." (unabhängig vom Verfahren)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_FREITEXT VERLAUF_FREITEXT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_BEURTEILUNG VERLAUF_BEURTEILUNG]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_UNMITTELBAR TODESURSACHE_UNMITTELBAR]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_GRUNDLEIDEN TODESURSACHE_GRUNDLEIDEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-ABTEILUNG_ID ABTEILUNG_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHFUEHRENDE_ABT_ID DURCHFUEHRENDE_ABT_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHGEFUEHRT_VON DURCHGEFUEHRT_VON]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-KEINE_ALTEN KEINE_ALTEN]

Parameter beginnend mit "VITBWRUECK.". Diese Parameter folgen dem Muster VITBWRUECK.<verfahren.><parameter> . Wenn kein entsprechender Parameter für das Verfahren gesetzt ist, wird ersatzweise VITBWRUECK.<parameter> genutzt.
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-STERBEDATUM_EXAKT STERBEDATUM_EXAKT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMORTOD TUMORTOD]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-AUTOPSIE AUTOPSIE]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-QUELLE_TODESURSACHEN QUELLE_TODESURSACHEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMOR_ID0 TUMOR_ID0]

Zusätzlich gibt es noch diesen Parameter (unabhängig vom Verfahren)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-VERLAUF_ABGLEICH-TUMOR_ID_VERFAHREN VITBWRUECK.VERLAUF_ABGLEICH.TUMOR_ID_VERFAHREN]

== FUNCTION ins_abschluss(pid IN NUMBER, meldung IN OUT VARCHAR2, fehler IN OUT VARCHAR2) RETURN NUMBER ==
Diese Funktion fügt für den übergebenen Patienten einen Abschluss "Tod" ein (sofern noch nicht vorhanden) und ordnet diesen bei mehreren Tumoren der Tumor_ID 0 zu, sofern nicht generell eine Zuordnung zu Tumor_ID 0 konfiguriert ist (Parameter TUMOR_ID0). Ggf. erfolgt auch eine Vorbelegung von Tumortod, Autopsie und Quelle_Todesursachen bei PATIENT und gegebenenfalls Eintrag von Vorgabewerten für die unmittelbare Todesursache und das Grundleiden (fixe ICD-Werte), wenn das konfiguriert ist s.o.. Die Funktion prüft, ob bei dem Patienten ein Sterbedatum eingetragen ist. Rechteabteilung und durchführende Abteilung müssen konfiguriert sein.

Vitalstatus-Paket

2025-02-17T21:39:18Z

Udo: Beschreibung auf aktuelle Version angepaßt

Beschriebene Version PACKAGE 231020 / BODY 090924

== FUNCTION sterbeinfo_eintragen(pid IN NUMBER, sterbdat IN DATE, meldung IN OUT VARCHAR2) RETURN VARCHAR2 ==
Diese Funktion bekommt ein Sterbedatum übergeben und trägt dieses in PATIENT.STERBEDATUM ein. Wenn bereits ein Sterbedatum eingegeben ist, erfolgt nur dann eine Änderung, wenn das Sterbedatum in PATIENT als monatsgenau gekennzeichnet ist und das übergebene Sterbedatum als taggenau definiert ist (Parameter STERBEDATUM_EXAKT s.u.). Ansonsten erfolgt gegebenenfalls ein Hinweis auf ein abweichendes Sterbedatum. Außerdem erfolgt kein Eintrag des Sterbedatums, wenn ein Patient_Dokument.Max_Datum größer dem Sterbedatum vorliegt (keine Berücksichtigung von Konsilen). Die Tumorzuordnung erfolgt dabei dem einzigen Tumor (oder bei mehreren Tumoren "0"), sofern nicht der Parameter VITBWRUECK.<verfahren.>TUMOR_ID0 auf Ja gesetzt ist.

Nur, wenn ein Sterbedatum eingetragen oder geändert wird, erfolgt auch die Anlage eines Abschlusses mit ggf. Vorbelegung von Tumortod, Autopsie und Quelle_Todesursachen bei PATIENT und gegebenenfalls Eintrag von Vorgabewerten für die unmittelbare Todesursache und das Grundleiden (fixe ICD-Werte).

Der Rückgabewert ist "TRUE" bei Eintrag eines Sterbedatums, sonst "FALSE" oder bei Fehler "ERROR:<sqlerrm>"

== Parametrisierung ==
Parameter beginnend mit "VITALSTATUS." (unabhängig vom Verfahren)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_FREITEXT VERLAUF_FREITEXT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_BEURTEILUNG VERLAUF_BEURTEILUNG]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_UNMITTELBAR TODESURSACHE_UNMITTELBAR]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_GRUNDLEIDEN TODESURSACHE_GRUNDLEIDEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-ABTEILUNG_ID ABTEILUNG_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHFUEHRENDE_ABT_ID DURCHFUEHRENDE_ABT_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHGEFUEHRT_VON DURCHGEFUEHRT_VON]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-KEINE_ALTEN KEINE_ALTEN]

Parameter beginnend mit "VITBWRUECK.". Diese Parameter folgen dem Muster VITBWRUECK.<verfahren.><parameter> . Wenn kein entsprechender Parameter für das Verfahren gesetzt ist, wird ersatzweise VITBWRUECK.<parameter> genutzt.
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-STERBEDATUM_EXAKT STERBEDATUM_EXAKT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMORTOD TUMORTOD]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-AUTOPSIE AUTOPSIE]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-QUELLE_TODESURSACHEN QUELLE_TODESURSACHEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMOR_ID0 TUMOR_ID0]

Zusätzlich gibt es noch diesen Parameter (unabhängig vom Verfahren)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-VERLAUF_ABGLEICH-TUMOR_ID_VERFAHREN VITBWRUECK.VERLAUF_ABGLEICH.TUMOR_ID_VERFAHREN]

Vitalstatus-Paket

2024-12-12T15:26:17Z

Udo:

Beschriebene Version PACKAGE 231020 / BODY 090924

== FUNCTION sterbeinfo_eintragen(pid IN NUMBER, sterbdat IN DATE, meldung IN OUT VARCHAR2) RETURN VARCHAR2 ==
Diese Funktion bekommt ein Sterbedatum übergeben. Wenn bereits ein Sterbedatum eingegeben ist, erfolgt keine Änderung, aber gegebenenfalls ein Hinweis auf ein abweichendes Sterbedatum. Die Sterbedatumgenauigkeit wird derzeit nicht bewertet. Außerdem erfolgt kein Eintrag des Sterbedatums, wenn ein Patient_Dokument.Max_Datum größer dem Sterbedatum vorliegt (keine Berücksichtigung von Konsilen). Die Tumorzuordnung erfolgt dabei dem zeitlich letzten Tumor, sofern nicht der Parameter VITBWRUECK.<verfahren.>TUMOR_ID0 auf Ja gesetzt ist.

Nur, wenn ein Sterbedatum eingetragen wird, erfolgt auch die Anlage eines Abschlusses mit ggf. Vorbelegung von Tumortod, Autopsie und Quelle_Todesursachen bei PATIENT und gegebenenfalls Eintrag von Vorgabewerten für die unmittelbare Todesursache und das Grundleiden (fixe ICD-Werte).

Der Rückgabewert ist "TRUE" bei Eintrag eines Sterbedatums, sonst "FALSE" oder bei Fehler "ERROR:<sqlerrm>"

== Parametrisierung ==
Parameter beginnend mit "VITALSTATUS." (unabhängig vom Verfahren)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_FREITEXT VERLAUF_FREITEXT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_BEURTEILUNG VERLAUF_BEURTEILUNG]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_UNMITTELBAR TODESURSACHE_UNMITTELBAR]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_GRUNDLEIDEN TODESURSACHE_GRUNDLEIDEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-ABTEILUNG_ID ABTEILUNG_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHFUEHRENDE_ABT_ID DURCHFUEHRENDE_ABT_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHGEFUEHRT_VON DURCHGEFUEHRT_VON]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-KEINE_ALTEN KEINE_ALTEN]

Parameter beginnend mit "VITBWRUECK.". Diese Parameter folgen dem Muster VITBWRUECK.<verfahren.><parameter> . Wenn kein entsprechender Parameter für das Verfahren gesetzt ist, wird ersatzweise VITBWRUECK.<parameter> genutzt.
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-STERBEDATUM_EXAKT STERBEDATUM_EXAKT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMORTOD TUMORTOD]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-AUTOPSIE AUTOPSIE]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-QUELLE_TODESURSACHEN QUELLE_TODESURSACHEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMOR_ID0 TUMOR_ID0]

Zusätzlich gibt es noch diesen Parameter (unabhängig vom Verfahren)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-VERLAUF_ABGLEICH-TUMOR_ID_VERFAHREN VITBWRUECK.VERLAUF_ABGLEICH.TUMOR_ID_VERFAHREN]

Vitalstatus-Paket

2024-12-12T14:56:38Z

Udo:

Parameter beginnend mit "VITALSTATUS." (unabhängig vom Verfahren)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_FREITEXT VERLAUF_FREITEXT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_BEURTEILUNG VERLAUF_BEURTEILUNG]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_UNMITTELBAR TODESURSACHE_UNMITTELBAR]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_GRUNDLEIDEN TODESURSACHE_GRUNDLEIDEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-ABTEILUNG_ID ABTEILUNG_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHFUEHRENDE_ABT_ID DURCHFUEHRENDE_ABT_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHGEFUEHRT_VON DURCHGEFUEHRT_VON]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-KEINE_ALTEN KEINE_ALTEN]

Parameter beginnend mit "VITBWRUECK.". Diese Parameter folgen dem Muster VITBWRUECK.<verfahren.><parameter> . Wenn kein entsprechender Parameter für das Verfahren gesetzt ist, wird ersatzweise VITBWRUECK.<parameter> genutzt.
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-STERBEDATUM_EXAKT STERBEDATUM_EXAKT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMORTOD TUMORTOD]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-AUTOPSIE AUTOPSIE]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-QUELLE_TODESURSACHEN QUELLE_TODESURSACHEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMOR_ID0 TUMOR_ID0]

Zusätzlich gibt es noch diesen Parameter (unabhängig vom Verfahren)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-VERLAUF_ABGLEICH-TUMOR_ID_VERFAHREN VITBWRUECK.VERLAUF_ABGLEICH.TUMOR_ID_VERFAHREN]

Vitalstatus-Paket

2024-12-12T14:56:24Z

Udo:

Parameter beginnend mit "VITALSTATUS." (unabhängig vom Verfahren)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_FREITEXT VERLAUF_FREITEXT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_BEURTEILUNG VERLAUF_BEURTEILUNG]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_UNMITTELBAR TODESURSACHE_UNMITTELBAR]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-TODESURSACHE_GRUNDLEIDEN TODESURSACHE_GRUNDLEIDEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-ABTEILUNG_ID ABTEILUNG_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHFUEHRENDE_ABT_ID DURCHFUEHRENDE_ABT_ID]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-DURCHGEFUEHRT_VON DURCHGEFUEHRT_VON]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-KEINE_ALTEN KEINE_ALTEN]

Parameter beginnend mit "VITBWRUECK.". Diese Parameter folgen dem Muster VITBWRUECK.<verfahren.><parameter> . Wenn kein entsprechender Parameter für das Verfahren gesetzt ist, wird ersatzweise VITBWRUECK.<parameter> genutzt.
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-STERBEDATUM_EXAKT STERBEDATUM_EXAKT]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMORTOD TUMORTOD]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-AUTOPSIE AUTOPSIE]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-QUELLE_TODESURSACHEN QUELLE_TODESURSACHEN]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-TUMOR_ID0 TUMOR_ID0]

Zusätzlich gibt es noch diesen Parameter (unabhängig vom Verfahen)
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITBWRUECK-VERLAUF_ABGLEICH-TUMOR_ID_VERFAHREN VITBWRUECK.VERLAUF_ABGLEICH.TUMOR_ID_VERFAHREN]

Vitalstatus-Paket

2024-12-12T14:25:11Z

Udo: Die Seite wurde neu angelegt: „Parameter beginnend mit "VITALSTATUS." (unabhängig vom Verfahren) * [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/gtdspara.htm#VITALSTATUS-VERLAUF_FRE…“

Kategorie:WebGTDS GUI

2024-12-12T13:30:43Z

Udo: /* Konfigurationen */

== Konfigurationen ==
[[Konfiguration von Arbeitslisten]] 
[[Vitalstatus-Paket]]

Kategorie:WebGTDS GUI

2024-12-12T13:30:12Z

Udo: /* Konfigurationen */

== Konfigurationen ==
[[Konfiguration von Arbeitslisten]]
[[Vitalstatus-Paket]]

Datei:Arbeitsliste abfrage.jpg

2024-11-28T08:41:13Z

Udo:

Datei:Anmeldung Login Passwort Meldeportalportal.png

2024-11-27T18:29:24Z

Udo:

Kategorie:WebGTDS GUI

2024-11-27T13:24:29Z

Udo:

== Konfigurationen ==
[[Konfiguration von Arbeitslisten]]

Konfiguration von Arbeitslisten

2024-11-27T13:23:05Z

Udo: Udo verschob die Seite Arbeitslisten nach Konfiguration von Arbeitslisten

Konfiguration von Arbeitslisten

2024-11-27T13:22:08Z

Udo:

Konfiguration von Arbeitslisten

2024-11-27T11:58:13Z

Udo: Die Seite wurde neu angelegt: „Arbeitslisten sind eine spezielle Form von Abfragen, von denen aus in die Bearbeitung von Patienten oder Dokumenten verzweigt werden kann. Dabei müssen folgen…“

Arbeitslisten sind eine spezielle Form von Abfragen, von denen aus in die Bearbeitung von Patienten oder Dokumenten verzweigt werden kann.
Dabei müssen folgende Namenskonventionen eingehalten werden:
* Die Spalte Pat_ID ermöglicht die Verzeigung auf Patientenebene
* Die Spalten Datenart und LfdNr ermöglicht die Verzweigung auf ein Dokument
Um eine Arbeitsliste einzurichten, müssen an zwei Stellen Einträge vorgenommen werden
# Erstellen der Abfrage über die Systempflege über die Systempflege => Abfragen
# Einbinden der Abfrage in ein dynamisches Modul über Systempflege => Dyn.Mod.

=== Erstellen der Abfrage ===
Im Prinzip beliebige Abfragen auf Patienten oder Dokumente, wobei die Namenskonventionen, s.o., eingehalten werden müssen.
Zu beachten ist weiterhin das Mengengerüst und die Performance. Browser werden ab sehr großen Datenmengen langsam oder verweigern ihren Dienst.
Zu notieren sind die Quelle und die LfdNr der Abfrage innerhalb der Quelle.
<gallery>
Beispiel.jpg|Beschreibung1
Beispiel.jpg|Beschreibung2
</gallery>

=== Einbinden der Abfrage in ein dynamisches Modul ===

Kategorie:WebGTDS GUI

2024-11-27T11:44:46Z

Udo: Die Seite wurde neu angelegt: „== Konfigurationen == Arbeitslisten“

== Konfigurationen ==
[[Arbeitslisten]]

Konfiguration

2020-10-21T17:27:10Z

Udo:

* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/einrichtung_organspezifische_dokumentation.m4v Einrichtung einer organspezifischen Dokumentation (Video)]
* [http://www.med.uni-giessen.de/akkk/gtds/grafisch/doku/orspedo.htm Einrichtung einer organspezifischen Dokumentation (HTML)]
[[Category:Schulung]][[Category:GTDS Klassisch GUI]]

Konfiguration

2020-10-21T17:22:34Z

Udo: Die Seite wurde neu angelegt: „* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/einrichtung_organspezifische_dokumentation.m4v Einrichtung einer organspezifischen Dokumentation (Video…“

Krebsregisterexport

2020-09-22T18:13:16Z

Udo:

* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/adtgekid_export.pdf Konfiguration und Bedienung (PDF)]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/bedienung_krebsregister_export.m4v Bedienung des Krebsregisterexports (Video)]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/konfiguration_ADTGEKID_export.m4v Konfiguration des Krebsregisterexports (Video)]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/krebsregisterexport_fuer_melder_ids.m4v Spezialfall: Export für unterschiedliche Absender/Melder/Länder (Video)]
[[Category:Schulung]][[Category:GTDS Klassisch GUI]]

Krebsregisterexport

2020-09-08T14:12:47Z

Udo:

Krebsregisterexport

2020-09-08T14:07:29Z

Udo:

Krebsregisterexport

2020-09-08T14:06:26Z

Udo:

* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/adtgekid_export.pdf|Konfiguration und Bedienung (PDF)]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/bedienung_krebsregister_export.m4v|Bedienung des Krebsregisterexports]
[[Category:Schulung]][[Category:GTDS Klassisch GUI]]

Krebsregisterexport

2020-09-08T14:02:32Z

Udo: Die Seite wurde neu angelegt: „ Bedienung des Krebsregisterexports“

[[http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/bedienung_krebsregister_export.m4v|Bedienung des Krebsregisterexports]]

Kategorie:Vorlesung

2020-09-03T15:29:46Z

Udo: Die Seite wurde neu angelegt: „Verschiedene Vorlesungen, die ggf. auch für nicht Studierende interessant sind.“

Verschiedene Vorlesungen, die ggf. auch für nicht Studierende interessant sind.

Kategorie:GTDS Klassisch GUI

2020-09-03T15:28:24Z

Udo: Leere Seite erstellt

Auswertungen

2020-09-03T14:58:57Z

Udo:

== Überlebensstatistik ==

* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/ueberlebensstatistik.pdf Überlebensstatistik mit GTDS (PDF) ]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/ueberleben.mkv Video zur Handhabung ]

[[Category:Schulung]][[Category:GUI]]

Bedienung des GTDS

2020-09-03T14:56:54Z

Udo:

== Videotutorials ==
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/bedienelemente.avi Bedienelemente ]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/eingangsmaske_klassisch.avi Eingangsmaske ]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/patientenauswahl.avi Patientenauswahl ]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/patientenstamm.avi Patientenstamm ]
* [http://imigtds.med.uni-giessen.de/gtds/grafisch/doku/vorhandene_daten.avi Übersicht vorhandene Daten ]

[[Category:Schulung]][[Category:GUI]]