Geräte anbinden ohne Doppeleingabe: Was GDT für Ihre Praxis wirklich bedeutet

Es ist ein kleiner, aber teurer Moment im Praxisalltag: Der Patient sitzt am Ultraschall, das EKG ist vorbereitet, das Spirometer wartet, und jemand tippt Name, Geburtsdatum und Patientennummer noch einmal von Hand in das Gerät. Jede dieser Eingaben kostet Sekunden, und jede kann einen Zahlendreher enthalten, der später zu einem falsch zugeordneten Befund führt.

Die Frage, die sich hinter der Softwareauswahl versteckt, lautet deshalb ganz praktisch: Kann ich mein vorhandenes Gerät anschließen, ohne alles doppelt einzutippen? Die Antwort darauf heißt in den allermeisten deutschen Praxen GDT, der Gerätedatentransfer. Dieser Artikel zeigt, was dabei technisch passiert, warum die Details über eine funktionierende Anbindung entscheiden, und welche Fragen Sie einem Softwareanbieter stellen sollten.

Erst einmal die Begriffe sortieren: GDT, xDT, DICOM

Rund um Geräteanbindung kursieren mehrere Kürzel, die leicht durcheinandergehen.

GDT wird heute meist als Gerätedatentransfer aufgelöst, in älteren Quellen und Handbüchern auch als Gerätedatenträger. Gemeint ist in beiden Fällen derselbe Standard, über den Praxissoftware und diagnostische Geräte (Ultraschall, EKG, Laborgerät, Lungenfunktion) ihre Daten austauschen. Wer nach dem einen Begriff sucht und beim anderen landet, ist also richtig. Er gehört zur Familie der sogenannten xDT-Formate, die der Qualitätsring Medizinische Software (QMS) gemeinsam mit der Kassenärztlichen Bundesvereinigung entwickelt hat und zu der auch BDT (Behandlungsdaten) und LDT (Labordaten) zählen. GDT ist bewusst schlicht: eine Textdatei mit klar definierten Feldern.

Nicht zu verwechseln ist GDT mit DICOM. DICOM ist der weltweite Standard für die Bildgebung: Röntgen, CT, große Bildarchive. GDT dagegen regelt den nüchternen Datenaustausch mit dem einzelnen Gerät im Behandlungszimmer: Wer ist der Patient, wann ist er geboren, welche Nummer trägt er? Für genau diesen Zweck ist GDT bis heute das verbreitetste Format und das Erste, wonach Praxen bei der Geräteanbindung fragen.

Eine bis heute weit verbreitete Ausprägung ist GDT in der Version 02.10, und zwar dateibasiert. Das ist ein wichtiger Punkt, der oft falsch verstanden wird.

Wie es wirklich funktioniert: Das Verzeichnis ist die Schnittstelle

Viele stellen sich Geräteanbindung als Kabel vor, als serielle Leitung, über die Daten fließen. In der Praxis läuft moderne GDT-Anbindung anders und viel robuster: über ein gemeinsames Verzeichnis.

Die Praxissoftware legt eine GDT-Datei in einen vereinbarten Ordner. Das Gerät liest sie dort aus und übernimmt die Stammdaten. Schickt das Gerät später einen Befund zurück, legt es seinerseits eine Datei in denselben Ordner, und die Software holt sie ab. Der Ordner wirkt dabei wie ein kleiner Briefkasten zwischen zwei Systemen, die sich sonst nicht kennen.

Damit das funktioniert, muss ein Prozess dieses Verzeichnis kontinuierlich überwachen, typischerweise im Sekundentakt, und auf jede neue Datei reagieren. Das klingt banal, ist aber der Kern einer verlässlichen Anbindung: Es gibt keinen Verbindungsabbruch, der repariert werden müsste, und keine Treiber, die zum Gerät passen müssen. Es gibt nur einen Ordner. Der Preis dafür ist Disziplin an anderer Stelle, nämlich im Format der Datei selbst.

Die Stammdaten-Datei selbst ist eine Abfolge von Zeilen, jede nach demselben strengen Muster aufgebaut:

Jede Zeile beginnt mit einer dreistelligen Längenangabe, gefolgt von einer vierstelligen Feldkennung und dann dem eigentlichen Inhalt. Die Satzart 6301 bedeutet „Stammdaten übermitteln“, exakt der Vorgang, um den es hier geht: Die Praxissoftware reicht die Patientenstammdaten an das Gerät durch.

Was hier so aufgeräumt aussieht, verbirgt jedoch genau die Details, an denen eine Anbindung in der Praxis scheitert.

Die Fallstricke, an denen die Anbindung scheitert oder gelingt

Was GDT einfach aussehen lässt, macht es in der Umsetzung tückisch. Drei Details entscheiden darüber, ob das Gerät die Datei annimmt oder wortlos verwirft.

Erstens: Die Längenangabe zählt sich selbst mit. Jede Zeile trägt vorne ihre eigene Länge, aber nicht etwa nur die Länge des Inhalts. Gezählt werden die drei Ziffern der Längenangabe selbst, die vier Ziffern der Feldkennung, der Inhalt und der abschließende Zeilenumbruch aus zwei Zeichen (Wagenrücklauf und Zeilenvorschub). Die Zeile mit dem Vornamen Max etwa ist mit 012 ausgezeichnet: drei Ziffern Länge + vier Ziffern Feldkennung (3102) + drei Zeichen Max + zwei Zeichen Umbruch = zwölf. Wer hier auch nur um eins danebenliegt, etwa weil er den Zeilenumbruch vergisst mitzuzählen, produziert eine Datei, die formal defekt ist. Eine saubere Umsetzung prüft diese Längenangabe deshalb für jede einzelne Zeile.

Zweitens: Der Zeichensatz ist ein DOS-Relikt. Das Feld 9206=2 legt fest, dass die Datei in IBM CP437 kodiert ist, einer Zeichentabelle aus den frühen PC-Tagen. Das ist kein Versehen: Viele medizinische Geräte erwarten bis heute exakt diese Kodierung. Der Haken sind die Umlaute. ä, ö, ü und ß haben in CP437 jeweils eine eigene, feste Position, die nicht mit den heute üblichen Kodierungen (UTF-8, Latin-1) übereinstimmt. Schreibt die Software naiv in UTF-8, erscheint aus „Müller“ auf dem Gerät schnell ein „M³ller“ oder Schlimmeres. Der gesamte Satz muss deshalb konsequent nach CP437 kodiert werden, bevor er auf die Platte geht.

Drittens: Die Gesamtlänge steht erst am Ende fest. Das Feld 8100 gibt die Länge des kompletten Satzes an, und die kennt man erst, wenn der Satz fertig gebaut und in CP437 kodiert ist. Man kann die Zahl also nicht einfach vorab hinschreiben. Der übliche Weg führt über zwei Durchgänge: Erst wird ein Platzhalter (00000) eingesetzt, dann der ganze Satz kodiert, die Bytes gezählt und die echte Länge an dieselbe Stelle zurückgeschrieben. Entscheidend ist, dass der Platzhalter genauso breit ist wie die eingesetzte Zahl (beide fünfstellig). Sonst würde das Nachtragen der Länge die Länge selbst wieder verändern. Genau diese Selbstbezüglichkeit sollte man prüfen: Die im Feld 8100 deklarierte Länge muss exakt der tatsächlichen Bytezahl der Datei entsprechen.

Ein vierter Punkt betrifft die Ablage, nicht mehr das Format. Damit eine neue Stammdaten-Datei eine ältere nicht überschreibt, kann die Software die Dateinamen fortlaufend hochzählen: EMPFABS.001, EMPFABS.002 und so weiter, wobei der Name aus den Kürzeln von Empfänger und Absender besteht. Die Software sucht dazu die bereits vorhandenen Dateien, ermittelt die höchste Nummer und vergibt die nächste. So bleibt der „Briefkasten“ geordnet, auch wenn mehrere Vorgänge kurz hintereinander laufen.

Ein konkretes Beispiel, Feld für Feld

So sieht ein korrekt aufgebauter Stammdatensatz für einen erfundenen Patienten aus. Die Werte sind anonymisiert und frei erfunden, der Aufbau folgt der GDT-Spezifikation. Max Mustermann, geboren am 15. März 1990, Patientennummer 12345:

01380006301
014810000113 
014921802.10 
01092062 
014300012345 
0193101Mustermann 
0123102Max 
017310315031990

(Aus Gründen der Lesbarkeit ohne die unsichtbaren Zeilenumbrüche dargestellt.) Jede Zeile trägt vorne ihre Länge: 013 für die Satzart, 019 für den zehn Zeichen langen Nachnamen „Mustermann“, 017 für das achtstellige Geburtsdatum. Addiert man alle Zeilenlängen, kommt man auf 113 Byte, und genau diese Zahl trägt das Feld 8100. Das Geburtsdatum steht als 15031990: Tag, Monat, Jahr, ohne Punkte, ohne Leerzeichen. Ein Gerät, das TTMMJJJJ erwartet und ein Datum mit Punkten bekommt, quittiert das mit einem Fehler.

Was das für die Softwareauswahl bedeutet

Ob eine Praxissoftware Geräte wirklich sauber anbindet, zeigt sich weniger an der Zahl der beworbenen „Schnittstellen“ als daran, ob der Anbieter die unbequemen Fragen präzise beantworten kann. Wer die folgenden Fragen nur vage beantwortet, hat GDT vermutlich nicht selbst durchdrungen:

• In welcher GDT-Version und mit welchem Zeichensatz schreibt Ihre Software? (Eine belastbare Antwort nennt konkret die Version, etwa 02.10, und den Zeichensatz, etwa CP437.)
• Wie berechnen Sie die Satzlänge im Feld 8100 (nach der Kodierung, in Byte)?
• Wie gehen Sie mit Umlauten in Namen und Adressen um?
• Überschreibt Ihre Software vorhandene Dateien, oder zählt sie die Dateinamen hoch?
• In welches Verzeichnis wird geschrieben, und wie schnell wird eine Antwort des Geräts erkannt?
• Wie stellen Sie sicher, dass das Gerät keine erst halb geschriebene Datei liest?

Diese Fragen wirken kleinlich, aber genau an ihnen entscheidet sich, ob die Geräteanbindung im Alltag läuft oder ob Ihr Personal doch wieder von Hand nachtippt. Eine Software, die GDT ernst nimmt, hat auf jede davon eine klare Antwort.