Single Textfile containing multiple datasets

KNIME Analytics Platform
1

Hallo Forum!

Ich versuche es mal auf deutsch, bei Bedarf übersetze ich den Text noch... Vielleicht ist es eine Anfängerfrage, dennoch möchte ich es hier einmal versuchen.

Thema: elektronischer Datenaustausch zwischen Krankenhaus und Krankenkasse

Problem: Analyse der Rückläufer (mögliche Fehlerarten: Formatfehler, fehlende Daten oder falsche Daten

Ziel: strukturieren der Dimensionen, splitting der Werte, schöne Diagramme...

Nachdem ich einen Stapel Rechnungen übermittelt habe, bekomme ich einige Meldungen inklusive Kommentar der Krankenkasse zurück. Diese Fehlermeldungen werden in einer einzigen txt-Datei bereit gestellt. Innerhalb dieser Datei finden sich nun mehrere Dimensionen:

1. Fälle: Satz einer unbestimmten Anzahl Zeilen, Zeilentrenner = ', Falltrenner = Leerzeile oder Beginn_des_Strings = "FKT". Jede Fehlermeldung enthält -einen- Fall, gekennzeichnet durch die Fallnummer (kann man als ID sehen).

FKT+value0+value1+...+valuen' (erster Fall)
INV+patKVNummer+patKVStatus+patKVGültigkeit+khFallnummer'
...
FKT+... (zweiter Fall)

2. Werte eines Falles: In dem o.g. Satz an Zeilen finden sich nun Werte, deren Position eindeutig bestimmt ist. Feldtrenner innerhalb der Zeile = +. Man könnte nun also den Wert einer bestimmten Stelle in die korrespondierende Spalte einer neuen Tabelle schreiben.

BDG+D10.6' (Diagnoseschlüssel nach G-DRG: "D10.6" extrahieren und schreiben)
NAD+patNachname+patVorname+patGeschlecht+patGebDatum+patStrasse+patPLZ+patOrt++'

3. Rechnungspositionen innerhalb eines Falles: In der Fehlermeldung tauchen jetzt mehrere Zeilen mit dem Bezeichner "ENA" auf, dieser definiert die Zeile als eine Rechnungsposition. Diese Positionen müssen in einer Sub-Tabelle zum jeweiligen Fall abgelegt werden.

So, dann mal meine Frage: Welche Nodes setze ich hier ein?
Anbei eine Bsp-Datei.

Ich versuche es natürlich noch weiter try-and-error-mäßig, freue mich aber auf sachdienliche Hinweise...

Herzliche Grüße aus Essen!

Bsp. mit gefälschten Daten :roll:

FKT+10+01+123456789+987654321'
INV+6234576348+10001+1106+4370662.2202'
NAD+Nachname+Vorname+w+19641023+Musterstr. 22+67892+Ort++D'
CUX+EUR'
DPV+2007+2008'
REC+1017005639+20080110+52+20071214+long+123456789+++long+long'
ZLG+0,00+1'
RZA+0700+7654321'
BDG+K52.9'
PRZ+16502'
PRZ+14447'
ENA+01600++20071221+100+4,056200+4,06+1'
ENA+13215++20071221+50+4,056200+2,03+1'
ENA+13421++20071221+4100+4,056200+166,30+1'
ENA+40100++20071221+++2,60+1'
ENA+40120++20071221+++0,55+1'
FHL+DPV+001+03+Versionsnummer in DPV entspricht keiner gültigen Versionsnummer+34599+KRH00789+080110:2033+00022+01023'
FHL+PRZ+001+02+Operationsschlüssel entspricht nicht amtlichem OP-Schlüssel+34023+KRH00789+080110:2033+00022+01023'
FHL+PRZ+002+02+Operationsschlüssel entspricht nicht amtlichem OP-Schlüssel+34023+KRH00789+080110:2033+00022+01023'

FKT+10+01+123456789+987654321’

INV+123456789+10001+1112+2992374.9620’

NAD+Nachname+Vorname+w+19641024+Musterstr. 23+67892+Ort++D’

CUX+EUR’

DPV+2008+2008’

REC+1017006038+20080305+52+20080102+long+123456789+++long+long’

ZLG+10,00+2’

RZA+1500’

BDG+I73.9:L’

PRZ+3614:L’

ENA+07212++20080102+720+3,959700+28,51+1’

ENA+05212++20080102+315+3,959700+12,47+1’

ENA+31204++20080102+7350+3,959700+291,04+1’

ENA+31505++20080102+2845+3,959700+112,65+1’

ENA+31824++20080102+4480+3,959700+177,39+1’

ENA+34294++20080106+1140+3,959700+45,14+1’

ENA+40120++20080106+++0,55+1’

ENA+32001+003+20080106+10+3,959700+0,40+1’

FHL++++ZUR DEN EBM-ZIFFERN  WURDE NICHT DER ZULÄSSIGE OPS GEMELDET BZW.+00000+KRH00261+080305:2030+00173+01516’

FHL++++EBM-ZIFFER BEI GEMELDETER LEISTUNG NICHT ABRECHENBAR. BITTE REICHEN+00000+KRH00261+080305:2030+00173+01516’

FHL++++SIE EINE KORRIGIERTE RECHNUNG EIN.+00000+KRH00261+080305:2030+00173+01516’
2

Hi!

Das schreit nach einer Implementierung eines neuen Knotens, der dieses spezielle Format einlesen kann und in DataTables packt.
Der existierende FileReader kann nur sinnvoll Files einlesen, die eine gewisse Tabellenstruktur aufweisen - und er ist Zeilen orientiert, d.h. eine neue Zeile im File kommt in eine neuen Tabellen-Zeile.
Sie könnten zwar jede Zeile komplett in eine Tabellen-Spalte einlesen und hinterher mit dem CellSplitter beim '+' trennen, aber dafür sind die Daten zu uneinheitlich, fürchte ich. Und das zusammenführen von zwei Zeilen in eine ist m.W. nicht wirklich möglich.

KNIME kommt auch als DeveloperVersion, mit einem Extension Wizard, was das Erstellen von neuen Knoten relativ einfach macht. (So man in Java programmieren kann...) Dazu gibt es auch einen Guide: http://knime.org/extension.html

Vielleicht können Sie das vorhandene Format ja auch über ein Script o.ä. so umformatieren, dass es der FileReader besser lesen kann. Ob das wirklich sinnvoll geht wage ich zwar zu bezweifeln, aber wenn Sie sicherstellen, dass alle Daten-Sätze die zu einem Fall gehören im neuen Format in einer Zeile stehen (mit einem Zeichen getrennt, das nicht in den Daten vorkommt), und dass alle Zeilen/Fälle gleich viel Datensätze enthalten (zur Not fügen Sie einen leeren Datensatz ein) - und dazu noch die gleichen Datensätze an der gleichen Position stehen, dann kann das vielleicht funktionieren.
Aber es ist wahrschienlich mehr Aufwand, als einen neuen speziellen Knoten zu implementieren.

3

Aha. Vielen Dank für die Antwort.

Einen neuen Knoten zu programmieren möchte ich als ultima ratio einsetzen, zumal ich nicht gerade ein Java-König bin...

Inzwischen habe ich mein Modell auf die Betrachtung eines einzelnen Falles reduziert, quasi die Zeilen zwischen zwei "FKT"s. Wenn ich mir nun das Ergebnis des FileReaders (input = txt mit nur einem Fall, delimiter = +, allow short lines) anschaue, sieht das doch gar nicht so schlecht aus. Vorerst muss man halt die Tatsache, dass in einer Spalte verschiedenartige Werte stehen ausbelnden.

Ich habe versucht, das ganze über ein Netz von Filtern und Joinern zu lösen, da taucht aber ein Problem mit den RowNumbers auf. Der FileReader erzeugt ja eine Tabelle mit (hier) 19 Zeilen, die aber letztendlich in einer einzigen landen sollen.

Die Blöcke der Fehlermeldung, die mehrere Zeilen enthalten, können ja auch erst einmal vernachlässigt werden. Also weg mit "BDG, PRZ, ENA, FHL".

Nun möchte ich zuallererst die Fallnummer extrahieren und diese als spätere RowID verwenden. In die Spalten dieser RowID möchte ich dann die anderen Felder, die im Output des FileReaders stehen, eintragen.

Was meinen Sie hier zum Netz von Filtern und Joinern?

4

Noch'n Gedanke: Sie können den FileReader überreden, alles in eine Zeile zu packen, bis zu der Leerzeile, es bedarf aber hässlicher Handarbeit: Stellen Sie den FileReader so ein, dass er das File liest, alles in eine Spalte. Schliessen Sie den Workflow. Ändern Sie die Settings des FileReaders im XML file! In Ihrem Workspace (Location findet man per rechter Mausclick auf dem Project->Properties) befindet sich ein Directory benannt wie das Project. Darin gibt es ein Dir "File Reader (#x)". In diesem FileReader Verzeichnis ist eine settings.xml Datei, die Sie in einem Text-Editor ändern: Suchen Sie nach dem Vorkommen von " " (in der Abteilung "Delimiters"), und ersetzen Sie es durch "

". Ebenfalls das zweite Vorkommen (in der Abteilung “RowDelims”) so ersetzen. Nun den Workflow wieder öffnen und es sollten alle Fälle in einer Zeile erscheinen (so die immer durch eine Leerzeile getrennt sind, was Sie nach Ihrer Aussage aber nicht sein müssen…). Sie können auch mit “
FKT” experimentieren, aber immer in beiden Vorkommen gleich ersetzen! Und immer den Workflow geschlossen halten beim Ändern.

Nun sollten Sie noch das Hochkomma (’) als Delimiter im FileReader Dialog eingeben, dann sind die einzelnen Werte für jeden Fall in separaten Spalten. Allerdings nicht die gleichen Werte in einer Spalte. Die unterschiedliche Anzahl an ENAs ruiniert das. Sie sollten das File umsortieren, die ENAs an den Schluss eines jeden Falls und leere Zeilen (termieniert mit einem ’ ) einfügen, wenn einem Fall ein Wert fehlt.

Damit lässt sich dann vielleicht das Ganze besser filtern und splitten.
Es bietet sich vielleicht der Cell Splitter an und der Java Snippet Knoten.
Damit sollte sich die Fallnummer extrahieren lassen und mit dem RowID knoten zur row ID machen lassen.