GTDS speichert derartige Informationen normalerweise, wenn sie direkt eingegeben werden, Stammdaten-orientiert. Alle gebräuchlichen Abteilungen oder Ärzte müssen einmal in den entsprechenden Stammdaten definiert worden sein und können dann immer wieder aufgerufen werden. In den Daten der einzelnen Patienten werden dann jeweils nur die ID-Nummern z.B. der behandelnden Abteilungen oder Ärzte festgehalten.
Schickt nun ein externes System Daten an GTDS, wird es dessen Abteilungs- oder Arztnummern nicht verwenden. Vielmehr kommen die Daten als entweder
Mit diesen Daten kann GTDS unmittelbar nichts rechtes anfangen, denn es kann nicht von sich aus allein wissen, welche ID-Nummer dem gelieferten Arzt oder der gelieferten Abteilung in seinen eigenen (GTDS-) Stammdaten zugeordnet ist. Das gilt sowohl wenn Klartext geliefert wird, als auch bei Codes oder Kürzeln aus einem fremden System. Zur Einordnung ins GTDS stehen nun zwei Wege zur Verfügung :
Tabelle ID_MATCH |
---|
|
Die Spalten ANDERE_ID und EIGENE_ID zeigen schon worum es geht, eben eine Übersetzungstabelle zwischen ID`s in verschiedenen Systemen. Da aber durchaus innerhalb des gleichen GTDS solche Umsetzungen für Daten aus verschiedenen Systemen oder Quellen vorkommen können, und auch innerhalb von Daten aus einer Quelle die ID`s verschiedene Bedeutung haben können (z.B. Arzt-ID und Abteilungs-ID des anderen Systems), sind noch zwei weitere Spalten notwendig, die das Umfeld festlegen.
Tabelle ID_MATCH - Bedeutung der Spalten | |
---|---|
OBJEKT | Art der zu übersetzenden Kennung. Dieser Wert muß mit dem
Schnittstellen-Programm "abgesprochen" sein. Bekannt sind i.d.R. ABTEILUNG
und STATION. Einige dieser Kennungen sind in der Pflegemaske über
Liste auswählbar. Für diese wird auch beim Aufruf der Maske die
Bezeichnung des Objekts angezeigt. Wenn eine Kennungsart nicht auswählbar
ist (wie bei STATION), bedeutet, das jedoch nicht, daß mit dieser
Kennung nicht gearbeitet werden kann.
nur HL7-Schnittstelle - In bestimmten Fällen kann dieser Wert auch durch einen Eintrag GTDS_PARAMETER mit dem Namen HL7_OBJEKT festgelegt werden. |
EIGENE_ID | EIGENE_ID gesehen aus dem Blickwinkel des GTDS. Die ID-Nummer, die
nach der Übersetzung herauskommt und im GTDS in den entsprechenden
Stammdaten bekannt sein sollte. Das heißt, daß z.B. eine Abteilung
in den Stammdaten im GTDS einmal definiert werden müßte, bevor
dann ihre Abteilung_ID als Ziel verwendet wird.
Bei dafür vorgesehenen Kennungen sind in der Pflegemaske die eigenen ID's auswählbar. |
FK_ANDERE_EINRICHTUNG_ID | Globale Bezeichnung für die Andere Einrichtung oder Datenquelle.
Diese kann, muß aber nicht unbedingt, im GTDS in der Pflegemaske
für andere Einrichtungen definiert sein.
Für die HL7-Schnittstelle kann derzeit mit einem GTDS_PARAMETER namens HL7_ANDERE_EINRICHTUNG festgelegt werden, nach Einträgen für welche Einrichtung in der Tabelle ID_MATCH gesucht wird. Nennen Sie die andere Einrichtung einfach KLINIKUM , ist kein GTDS-Parameter nötig. |
ANDERE_ID | Die Identifikation, unter der das andere System namens FK_ANDERE_EINRICHTUNG_ID (z.B. Klinikum) Daten von einem bestimmten OBJEKT (z.B. Abteilung) liefert. Diese Identifikation soll das Schnittstellen-Programm dann in die EIGENE_ID übersetzen. |
Eine alphanumerische Pflegemaske für ID_MATCH steht gleichfalls zur Verfügung unter sYstem==>Schnittstelle . In der aufgerufenen Maske müssen Sie dann 3 mal F8 drücken, bis Sie zum "Zuordnen von Objekten" gelangen.
Die HL7-Schnittstelle realisiert dies für Abteilungen folgendermaßen:
Für alle ID`s , die nicht zu übersetzen sind, weil sie nicht
in der Tabelle ID_MATCH stehen, wird nach dem Wert "DEFAULT_ABTEILUNG"
in ANDERE_ID gesucht und die EIGENE_ID dieser Zeile verwendet. Wird ein
Aufenthalt in einem solchen Falle eingetragen, wird die originale andere
ID zusätzlich in das (sonst leere) Feld Krankenblattnr der Tabelle
ABTEILUNG_PATIENT_BEZIEHUNG
gesetzt.