Folge #38 – xDT

Wieder Michael Schober von medatixx als Gast und heute geht es um das Thema XDT. 

Hallo Michael. Hallo Renato, Grüß dich. Genau, wir wollen uns das Thema xDT anschauen. XDT sagt man ja auch dafür und schauen uns zuerst mal so ein groben Überblick an, was das überhaupt ist und wofür das gut ist. Bevor wir dann uns ein bisschen vertiefen in zwei spezielle xDT. Einmal BDT, da schauen wir uns an, wofür man das gut verwenden kann und werden auch so ein klein bisschen politisch und dann noch das GDT für die Gerätekommunikation. Da schauen wir uns mal den technischen Aufbau der xDT an, die alle relativ ähnlich sind. Deswegen können wir das als Passprototo nehmen, wir können das als Beispiel nehmen und wissen damit auch, was die anderen so tun. Ja, dann würde ich sagen, starten wir gleich los und gehen ins eingemachte. Michael, was machen denn XDT überhaupt? Wofür steht das und was ist das für ein komischer Begriff? Ich versuche mich mal. Der XDT Standard steht für mehrere Kommunikationsprodukte, die für den Datenaustausch vor allem im niedergelassenen Umfeld in Deutschland entwickelt wurden. Das X in XDT steht dabei als, wenn man so will, als Variable für die unterschiedlichen Einsatzgebiete von XDT und das DT in XDT steht immer für die Bezeichnung Datentransfer. XDT passiert dabei auf einer Textorientierten Sundax, in dem jedes Feld einen eigenen Satz wiederum darstellt. Der XDT Standard hat seinen Ursprung Ende der 80er-Jahre genommen, da die kassen alsliche Bundesvereinigung, die Quartalsabrechnung statt wie bis zur damaligen Zeit in Papierform quasi in Zukunft auf elektronischem Wege und mit einem bundesweit einheitlichen Format umsetzen wollte. Bis zu dieser Zeit war es so das prokassenherzliche Vereinigung letztendlich unterschiedliche Abrechnungsvorschriften gehalten. Es wollte man also vereinheitlichen und vor allem digitalisieren, wenn man es zu dem Zeitpunkt schon sagen darf. Ja und aus dieser Initiative der KBV entwickelt es sich dann 1987 der erste XDT Standard, der sogenannte Abrechnungsdatentransfer, kurz ADT bei der damaligen Entwicklung vom ADT, wurde sich schon an gängigen Geschäftsverkehrstandards, wie zum Beispiel Edie Fakt angelehnt. Und der ADT wurde dann als Anfang der 90er immer mehr Praxissoftwareverlösungen einzug in die Arztpraxen hielten von der KBV als der Standard für die elektronische Quartalsabrechnung etabliert und die niedergelassenen Ärzte konnten damit dann auf Diskette abbrechnen. 

Das heißt wiederum, dass eigentlich bis heute jeder Praxissoftware der Anbieter ADT zwingend unterstützen muss und sich auch dafür regelmäßig bei der KBV zertifizieren lassen muss. 

Ja super, jetzt haben wir ADT als einen dieser DT sehr schon kennengelernt. Was gibt es denn noch für DT’s? Welche Standards haben wir denn noch in diesem Bereich? Ja, nachdem der ADT erfolgreich als quasi Standard für die elektronische Abrechnung etabliert waren konnte, entstanden wiederum schnell Initiativen um weitere Schnittstellen auf dieser ADT bzw. XDT Basis zu entwickeln. Da wurde Anfang der 90er, also kurz nach dem ADT, wurde dann das ZI, das ist das Zentralinstitut der Kassenärztlichen Versorgung von der KBV beauftragt, basierend auf XDT an Standard zum Austausch von den gesamten Behandlungsinformationen in den Praxissoftware -Lösungen zu entwickeln, den sogenannten Behandlungsdaten-Transfer kurz BDT und damit war es eben einem Arzt möglich bei einem Wechsel des Praxissoftwares für Anbieters, die nahezu, ja ich sage mal nahezu, gesamten Patienten-Dokumentationen aus seinem Allsystem in das neue Praxissoftwareesystem zu übertragen. Zum BDT kommen wir nochmal neben dem BDT, gibt es noch den sogenannten Labordaten-Transfer, kurz ADT, ist ein weiterer wichtiger Standard, der ADT wurde ebenfalls von der KBV entwickelt und ist seit Mitte bzw. Ja Ende der 90er Jahre der Standard für die Übertragung von Daten zwischen Praxissoftware -Lösungen und Labor. Ein weiterer nennenswerter Standard ist der Gerätedatentransfer kurz GDT, gehen wir dann auch nochmal drauf ein, der GDT wurde nicht von der KBV, sondern vom QMS, vom Qualitätsring medizinische Software entwickelt und wird für die Datenübertragung zwischen Praxissoftware und Medizintechnik, beziehungsweise Medizintechnik Software eingesetzt und gilt auch als Standard. Ja und eben, denen ich jetzt genannt habe, gibt es noch eine ganze Reihe von auf XDT-basierten, Formaden wie SADT, KADT und so weiter, die aber nur in eher speziellen Einsatzzenarien genutzt werden. Der ADT wird bis heute noch von der KBV gepflegt und BDT, GDT und LDT werden mittlerweile alle vom QMS gepflegt und weiterentwickelt. 

Vielleicht dann nochmal zusammengefasst, wir haben diese vier HauptDT, ADT für Abrechnung, BDT für vor allem Migration, LDT für Labordaten und GDT für die Geräteanbindung. Richtig. 

Okay, die Migration, das ist ja immer so ein heikles Thema, klar, dass ein Anbieter jetzt nicht gerne hat, wenn er durch jemanden anderen abgelöst wird, aber es gibt ja immer den Vorruf der Politik, dass es sowas wie eine Migration immer nur schwer möglich macht und dass die Hersteller das bewusst unterbinden wollen und dass sie das schwer machen, aber jetzt ist ja gerade dieser BDT genau dafür gemacht. Erzähl doch ein bisschen was über diesen BDT und weswegen es diese ganze Kontroverse gibt. Ja, wie beschrieben gibt es für die Daten übernahme, es sage ich mal, von PraxisoftVA, zu PraxisoftVA eigentlich diesen BDT-Standard. Der Vorwurf der Politik gegenüber der Industrie, da geht weniger in die Richtung, dass es heute keinerlei technischen Möglichkeiten zur Daten übernahme gibt, sondern dass die Daten übernahme an sich einen spürbaren Kostenfaktor beim Systemwechsel darstellt. Das hat sich auch jüngst in einem Beschluss vom ersten Juni 2017 zur Neufassung des Paragraphen 291DSGB5 niedergeschlagen. Dort ist es jetzt vermerkt, dass IT-Systeme, die in der ärztlichen Versorgung und in Krankenhäusern eingesetzt werden, also PraxisoftVA und KIS-Systeme, standardisierte Schnittstellen für die Archivierung und für die Übertragung vom Patientendaten beim Systemwechsel integrieren müssen. Das ganze läuft jetzt so ab, die Selbstverwaltung muss ich auf eine Schnittstelle einigen, die wir als PraxisoftVA anbauen und auch die Kisern wieder umsetzen müssen und müssen diese Schnittstelle ins Interoperabilitätsverzeichnis der Gematik eintragen lassen und ab diesen Zeitpunkt haben alle PraxisoftVA und Kisern wieder dann zwei Jahre Zeit diese Schnittstellen verpflichtend umzusetzen. Ja, und wir hoffen eben dabei logischerweise, dass die vorhandenen Standards wie eben BDT berücksichtigt werden. Und ich will mal ein Beispiel erklären, dass die Komplexität an einem Datenübernahme erklärt und vielleicht auch ein bisschen darstellt, warum das mit Kosten verbunden ist. Der Arzt hat in der PraxisoftVA relativ individuelle Möglichkeiten, seine patienten Dokumentation freizugstalten. Er kann sich also zum Beispiel individuelle Krankenblatt- und Rupriken festbligen. Zudem ist es so, dass jede PraxisoftVA schon allein historisch bedingt mit unterschiedlichen Krankenblatt-Rupriken arbeitet. So kann zum Beispiel in anderen Näße in einer PraxisoftVA mit A, in der nächsten mit A, N und in einer weiteren PraxisoftVA mit A, N, A abgekürzt sein oder die Erfassung vom Fremderdressen ist auch immer ein super Beispiel, also zuweisern, in System A wird der Titel der Vornahme und der Nachnahme in Einfeld geschrieben, in System B in drei Fälle zum Beispiel. Und genau diese Unterschiede machen eine Datenübernahme oder Datenkonvertierungs- so komplex und verursachen damit logischer weise Kosten, da es zwar einen BDT-Standard gibt, der es als Zwischenformat fungiert, aber jede Datenübernahme von Praxis A nach Praxis B ist aufgrund dieser verschiedenen Dokumentationsmöglichkeiten, ich gerade erglädt ab, trotzdem immer ein Stück weit individuell und bin der Dressusen. Und mittlerweile haben sich am Markt Unternehmen platziert die quasi passende Ex und teilweise auch Import-Routinen für diese unterschiedlichen Praxisoft–Lösungen anbieten. Das heißt, der Export wird wahrscheinlich einfach sein, das Importierende, die eigene Datenbank bereitet, dann ist die großen Probleme. Ich würde nicht von großen Problemen reden, aber ich würde zumindest sagen, tatsächlich der Export ein bisschen einfach richtig, aber jedes Mal muss man das Ganze anfassen und muss vorher vor dem Export sehr genau schauen, was will der Arzt eigentlich alles mitnehmen ins neue System und muss dann versuchen, schon bevor die Datenübernahme stattfindet, ein bisschen eine Vereinheitlichung der Daten hinzubekommen. Und das ist natürlich, wenn man es schon einiges in die neue Software reingesteckt hat, immer noch so zuse sich erprocken, den die Ärzte wahrscheinlich nicht gerne dann ausgeben wollen. Richtig, der aber aus momentan der dänische Sicht eigentlich unumgänglich ist, da dieses manuelle anfassen und einbinden von Ressourcen da immer auf jeden Fall dabei ist. Von Prozesse muss man sich quasi eine Datenübernahme wie vorhin vorstellen, der Arzt entscheidet sich für einen Praxisoft-Verwechsel und der Mitarbeiter oder der Service-Badener des neuen Anbieters. Er stellt dann mit Hilfe dieser genannten Routinen einen auf BDT-Basschen-Export-Ausenal-System für dann in aller Regel erstmal eine Probe-Konvertierung ins neue System durch, meistens nur von einem Teil der Altdaten sage ich mal und schaut dann ist das ganze vollständig, passt die Daten-Konsistenz und so weiter, hol dem Idealfall sogar den Arzt dazu oder die Ärzte dazu ans neue System und schauen mit ihnen über die Daten und erst wenn da alles in Ordnung ist, wird dann die finale Konvertierung quasi durchgeführt, so läuft der Prozess ja. Und wo sind da die größten Fallstricke, was macht immer am meisten Probleme bei so was? Ein Problem ist das Thema Zeit sogar, würde ich sagen, da es einfach so ist, dass das häufig am Wochenende stattfinden muss zum Beispiel, also ist ja dann so der Arzt, will natürlich am Eiden, dass da viele Tage oder mehrere Tage irgendwie die Praxis geschlossen ist, deswegen ist es dann oft so, dass sie im Allsystem noch irgendwie bis dahin oder frei nach arbeiten und dass es dann relativ zügig gehen muss und dann auch nichts mehr schiefgehen darf, dass sie eben am Mondach wieder mit der neuen Software schon starten können zum Beispiel. Deswegen ist diese Probe-Konvertierung und ganz entscheidender Punkt, was noch schiefgehen kann ist, dass sich manches Systeme besser eignen, sage ich mal, ne? Dem gewisses Systeme, die am so spezielle Datenformate oder auch Speicherformate, das ist ganz schwierig, es im neuen Systemnis zu übernehmen oder man anderes Beispiel, es gibt ein Impfmodul zum Beispiel in der Praxis Software A, weil der Arzt bisher war und er wechselt zu einer neuen Praxis Software und die hat gar keinen Impfmodul, dann ist eben die Frage, was passiert mit solchen Daten? Ja, ich könnte mir auch vorstellen, dass gerade die Medikationsdaten, die an jedem System unterschiedlicher fast werden, dass die dann auch immer eine gewisse Hürde darstellen mit den Raten und mit den Gaben und so. 

Gut, das war BDT, also der Datensatz, der den Ersten bei der Migration von einem in das andere System hilft, dann werden wir jetzt ein bisschen technischer und schauen und den Standard mal unter der Lupe an und das, an Beispiel von GDT, also von den Geräte-Daten. 

Vielleicht fangen wir da auch wieder mit dem Prozess an, wie sieht es denn aus, was für Geräte werden angebunden und wie sieht der Prozess der Datenübernahme aus? Wie gesagt, wird GDT geräte Datentransfer für den Austausch zwischen der Praxis Software und Medizintechnik, beziehungsweise der dazugehörigen Medizintechnik Software eingesetzt. Wenn wir einen klassischen Prozess beschreiben, der klassische Prozess sieht dabei so aus, dass die Praxis Software eine neue Untersuchung anfordert und dazu eine GDT-Datei erstellt, die die gesamten Patienten-Daten enthält. Das heißt, in der Praxis Software kann man sich so vorstellen, man steht im Patienten-Michael Schober und sagt, der mir jetzt okay, weil Michael Schober möchte ich einen EKG durchführen und ruft dann diese Medizintechnik Software auf und währenddessen passiert diese Patienten-Datenübergabe. Und dann öffnet sich quasi automatisch die Medizintechnik Software und liest diese GDT-Datei, die von der Praxis Software geschrieben wurde ein und öffnet daraufhin automatisch den richtigen Patienten, also Michael Schober und mein Beispiel zu bleiben und stattet die Untersuchung oder Messung, also das EKG in dem Fall. Dann führt es diese Messung durch, führt es EKG durch und nachdem die durchgeführt wurde, erstellt wieder um die Medizintechnik Software eine GDT-Datei, die jetzt von der Praxis Software eingelesen wird und die die Untersuchungsergebnisse enthält. Und diese werden dann in das Krankenblatt von Michael Schober in der Praxis Software automatisch reingeschrieben und so funktioniert eigentlich der klassische Prozess in der Kommunikation zwischen Praxis Software und Medizintechnik Software. 

Okay, also das könnte man so ein bisschen wie ORM und ORU bei HL7 vergleichen. Ja, nicht richtig. Dem Unterschied, dass wir hier tatsächlich nicht über TCP/IP kommunizieren, also über direkt Internetverbindungen, sondern über einen Datei austausch. Richtig, fallbasier. 

Okay, das klingt jetzt nicht sehr fortschrittlich, aber du hast ja gesagt, das ist auch schon ein bisschen älterer Standard. Richtig ist es auch und sicherlich auch ein bisschen pragmatisch geprägt, sage ich mal, aber auch was du gerade gesagt hast, mit diesem IP-Konikation und so weiter, weil man eben weiß, dass auch das Thema Vernetzung in der klassischen Niedergelassenen Arztpraxis noch nicht megawide fortgeschütten ist im Regelfall. Ist es sicherlich ein Ansatz, dem man in Zukunft auch gehen kann, aber momentan sehe noch keine wirkliche Alternative für GDT und ja, da können wir vielleicht ja nachher nochmal ganz kurz drauf aufbauen, vielleicht jetzt so ein bisschen, ohne dass wir die Leute verlieren, aber so ein bisschen ins technische Gegend, wie sieht denn so eine Nachricht aus? 

Okay, ich versuche es mal mit Worten zu erklären, also vielleicht noch als Hinweis für die Zuhörer, wir werden auch noch eine Beispiel Nachricht in die Show Notes packen, also alles, was mich jetzt gleich erzählt, kann man sich dann noch live in den Show Notes angucken. Genau, richtig. Ja, die GDT-Schnittstelle oder der Standard verwendet. Verschiebene so genannte Satzarten für wiederum unterschiedliche Einsatzzenarien, also es gibt zum Beispiel die Satzer 63.01 für das Patientendaten übermitteln. Da würde ich zum Beispiel mal eine Beispiel, da drei dann zur Verfügung stellen für die Show Notes oder eine andere Satzer, der zum Beispiel die 30.11 für die Daten einer Untersuchung anzeigen. Also, diese Satzarten sind ein bisschen an diesem Prozess, den ich gerade versucht habe, zu beschreiben, bisschen gekoppelt. Und welche Informationen in einer GDT-Data übergeben werden, ist in so genannten Feldkennungen geregelt. Die GDT-Data an sich ist zahlenbasiert, es stehen also verschiedene Zahlen untereinander weg, so kann man sich das vorstellen und die einzelnen Zahlen sind wiederum in vier Spalten aufgeteilt, die direkt hintereinander weggeschrieben werden, also wenn jemanden der Sonne da einmal aufmacht, schau es einfach, wie ein String aus, sage ich mal. Die erste Spalte definiert dabei die Zahlenlänge des Eindrages, die zweite Spalte von den vier, definiert die Feldkennung, die dritte Spalte ist dann der tatsächliche Inhalt, beziehungsweise der Wert dieses Feldes und die vierte Spalte definiert lediglich das zahlenende, also Linefeed oder solche Geschichten. Und wie sind diese Spalten getrennt? Die sind überhaupt nicht getrennt, die sind hintereinander weggeschrieben. Ah, okay, alles klar, dann habe ich’s, also das jetzt einfach, es steht am Anfang der Zahl, dann steht noch eine Zahl, damit wir gehen der Text und am Schluss gibt es noch ein Leinfied. Richtig genau. Die beiden Lösungen, um beim Beispiel von oben zu bleiben, also sowohl die Praxis Software, also die EKG Software in diesem Fall müssen quasi beide diese Syntax kennen einfach, um wissen, wie sie damit umgehen müssen. Ich will’s noch mal ein bisschen konkrete machen, dann kann man es sich vielleicht noch besser vorstellen. Wenn ich oben bei meinem Beispiel bleib, diese Satzer 63.01, also machen wir mal eine Beispiel Datei für das Patienten-Daten übermitteln, die könnte dann wie folgt aussehen. In der ersten Zahl wird die Satzer hat genannt, die Satzer des 360.01, also Patienten-Daten übermitteln. In der zweiten Seile in der GDT-Datei wird die Länge der gesamten GDT-Datei genannt, der dritten Seile die eingesetzte GDT-Version und ab der vierten Seile kommt Seile für Seile die einzelnen Patienten-Daten, weil ich ja eben versuchen, mit dieser GDT-Datei Patienten-Daten zu übermitteln. Und so eine Beispiel Datei würde ich einfach mal anhängen, weil ich glaube, dass man sich deutlich besser vorstellen kann, wenn man das mal vorsicht hat und im Podcast vielleicht parallel hört oder sich dann nachhin anziehen. 

Auf jeden Fall. Und das bemerkenswerte bei diesen GDT-Nachrichten ist dann natürlich auch, dass sie vom Menschen einigermaßen lesbar sind, jetzt im Gegensatz zu einkommen. Also ähnlich wie halt sieben lesbar sind auf den ersten Blick. Ja, was ich gerade beschrieben habe, sieht man auch sehr schön, wenn man einfach mal in der Reihe aufmacht. Diese vier Spalten sich mal gedanklich dazu denkt, dass das sich schnell schnell erkennen. Und wenn ich jetzt sagt, lesbar, dann wird’s bei einigen wahrscheinlich in den Ohren klingeln und sagen, oh, wenn das dann aber jetzt jeder lesen kann, diese Datei, die ja dann irgendwo akkuleg werden muss, besteht da auch ein gewisses Datenschutzproblem, gibt’s da denn Möglichkeiten der Verschlüsselung oder sieht das der Standard nicht vor. Nein, nein, nein, nein, nein, nein, nein, nein, wirklich eine Möglichkeit. Was ein Stück weit das Thema sicher ist, sicherlich, dass dieses gegenseitige Einlesene GDT 1 nur funktioniert, wenn System A und System P ihre gegenseitige GDT ID kennen, da gibt’s so eine eindeutige ID und jeder softwehranbieter der GDT einsetzen will, muss es ja einmal umsetzen und sich einmal beim QMS gegen diese Brüfsoftware laufen. Ich weiß nicht, ob das das Thema ein bisschen schützt, am Ende nicht 100% sicherlich, aber Verschlüssel ist das momentan nicht. Das ist also der Aufbau, wie man sieht, so ein bisschen, ich sag mal, altbacken im negativen oder konservativ, wenn man es positiv ausdrückt, gibt’s denn Ansätze, die sind doch etwas in die Jahre gekommenen Standard zu modernisieren oder gibt’s alternativen, die das tun. Also A ist es so, dass diese XDT Standard ständig weitentwickelt werden, beziehungsweise weiter gepflegt werden, wie gesagt, ADT wird weiterhin von der KBV gepflegt und BDT, GDT und LEDT vom QMS und da gibt es neue Reversionen von den Schnittstellen, also es gibt zum Beispiel einen BDT30, es gibt einen LEDT30 und so weiter und auch noch immer wieder neue Versionen von GDT, die natürlich auch mit der Zeit gehen, also dann teilweise XML passiert sind und so weiter. Grundsätzlich ist es aber zum Großteil nur fallbasiert, was da passiert, gerade gesehen in der Erklärung. Wir sind uns relativ sicher, wenn jetzt tatsächlich die Telematikinfrastruktur einzug hält in die Praxen und somit alle Praxen, auch mehr der weniger mit dem Internet verbunden sind auf sicherem Wege, dass sich dann auch andere Vernetzungsmöglichkeiten etablieren. Also ich will mal einen Beispiel nennen, zum Beispiel der elektronische Arztbriefe, sie heute nicht besonders stark verbreitet, aber der passiert ein Stück weit auf CDA, dass sich solche Dinge einfach mehr etablieren, wenn tatsächlich man eine Vernetzung da ist und auch in anderen Anwendungen, andere internationale Standards aus den Gesundheitswesen angewandt werden. Ich denke dann verbreitet sich automatisch auch auf diese Themen wie Labor-Kommunikation, Geräte-Kommunikation und so weiter. 

Okay, aber bis dahin müssen wir auf jeden Fall mit dem Auskommen, was wir haben und aktuell funktioniert es ja auch gut. 

xDT, ADT, LDT, GDT, BDT, Schnittstellen, ambulante Versorgung, Arztpraxis, Laborkommunikation, Abrechnung, Medizintechnik, Interoperabilität