Source: https://www.mydrg.de/forum/index.php?thread/1415-drg-daten-pr%C3%BCftool-der-dkg/
Timestamp: 2018-12-17 10:32:42
Document Index: 340520863

Matched Legal Cases: ['§ 21', '§ 301', '§21', '§21', '§21', '§21', '§21', '§21', '§21']

DRG-Daten Prüftool der DKG - DRG-Forum - myDRG - Forum Medizincontrolling, Kodierung & Krankenhausabrechnung
DRG-Daten Prüftool der DKG
Ich habe mir gestern das Programm der DKG für die § 21 Daten heruntergeladen und unsere Daten überprüfen lassen.
Mit Erschrecken habe ich ich eine Fehlerliste erhalten, die über mehrere Seiten ging. Unter anderem wurde angemahnt, dass Sterndiagnosen (als Nebendiagnosen) nicht als sogenannte Sekundärdiagnosen verschlüsselt wurden. Nun meine Frage an Leidensgenossen, die ähnliche Fehler zu bewältigen haben. Müssen wir wirklich alle Diagnosen nacharbeiten?? Hat jemand schon gemeldete Daten zurückbekommen, weil dieser Fehler auftrat oder wird es von der Erfassungsstelle toleriert??
Freundliche Grüße aus dem frühlingshaften KW
Grundsätzlich wird eine Fehlerquote von 10 % lt. Datenannahmestelle toleriert.
Das Tool der DKG weicht im Prüfergebnis von dem der Datenannahmestelle ab. Bei uns waren Datensätze von der Datenannahmestelle als Fehlerhaft gekennzeichnet, die im Tool der DKG nur mit einem Hinweis versehen waren.
Ich kann nur empfehlen mit der Datenannahmestelle Kontakt auszunehmen.
Guten Abend Dr. Haubold und Marion,
ich finde das Tool der DKG sehr nützlich, weil es u.a. Formalia prüft (z.B. numerisches Format falsch, etc.).
Was mich jedoch sehr stutzig macht, ist die Tatsache, dass auch unsere Dateien formal mit noch einigen groben Fehlern behaftet sind. Ich verstehe das deswegen nicht, weil doch - bis auf einige nachträgliche (zumeist inhaltliche) Änderungen - schon im letzten Juli (2002) die entsprechenden Exportschnittstellen hätten fertig sein müssen (Die Dateien hätten ja ursprünglich schon zum 01.08.2002 geliefert werden sollen). Wieso jetzt - mehr als ein halbes Jahr später -, zumindest bei uns, noch 8 Leerzeichen in Feldern auftauchen, die eigentlich 9 Stellen haben müssen (etc.) ist mir unbegreiflich. Darüber hinaus entdeckte ich Fälle mit zwei Hauptdiagnosen oder ohne jegliche Hauptdiagnose, in den Beatmungsstundenfeldern wird ein Tausender-Trennzeichen (.) eingefügt, was ebenfalls falsch ist. Viele Eingaben sind aber auch durch unsere Fehleingaben fehlerhaft (Beispiel: Entlassgrund Tod, arbeitsfähig). Ich würde mir wünschen, dass solcher Mist schon bei der Eingabe abgefangen würde. Erstaunlich auch, dass KIS-eigene Bezeichnungen (rein vorstationär) nicht automatisch zu einer Aufnahmeart 04 gemäß § 301 führen, weit gefehlt: Bei uns ist alles frei kombinierbar (gewesen ?). Ein Prüftool, wie es die DKG dankenswerterweise verfügbar machte, scheint einigen KIS-Herstellern völlig unbekannt zu sein (oder sie benutzen es nicht...). Und dafür bezahlt man dann auch noch... Ich kann nur raten, in der kommenden Woche noch einmal genau, besonders auch die dateiübergreifenden Prüfungen vorzunehmen:
1. nach formalen Aspekten
2. nach inhaltlichen Aspekten
Dabei sollte man fair bleiben hinsichtlich der eigenen Fehleingaben (aber diese empfehlen sich ganz besonders, um herauszubekommen, wie der Export der §21-Daten im jeweiligen KIS funktioniert). Und immer schön die Einzelfälle dokumentieren und an den KIS-Anbieter weiterleiten.
Seit 2 Wochen mache ich (fast) nichts anderes... Z.B. macht auch der Abgleich der fall.csv mit der fab.csv bezgl. Entlassungsdatum viel Freude oder OP-Datum und -Uhrzeit gegen Entlass- oder Aufnahmedatum, etc. Schön ist auch die Benennung einer nicht näher definierten "Eingriffszeit" in unserem KIS (soll wohl Schnitt-Naht-Zeit sein), weicht aber merkwürdigerweise von dieser (sie ist separat in der OP-Maske erfassbar) in unerklärlicher Weise manchmal ab...
Wie gesagt, hätte alles schon seit vergangenem Juli/August fertig sein können, ich lese jedoch immer wieder, dass man gerad in der vergangenen Woche die "Schnittstelle" bekommen habe. Kostenpflichtig und ungeprüft, versteht sich.
Warum akzeptieren die Krankenhäuser das nur ??? Und zahlen auch noch für grob fehlerhafte, gesetzlich vorgeschriebene Datenexporte ???
Ich erinnere mich nur an einen grundfalschen imc-Datensatz-Export näh. zu bez. KIS-Hersteller, in dem die DRG-Hauptdiagnose als Nebendiagnose im Datensatz erscheint...
Es ist nicht zu fassen, dass man dagegen nichts unternimmt.
ich kann Hr. Sommerhäuser nur zustimmen, auch ich bin seit einer Woche intensiv mit den §21-Daten beschäftigt...
Neben den schon erwähnten Fehlern (die übrigens auch deshalb zustande kommen, weil man neue Kombi-Schlüssel erfunden hat [herzlichsten Dank!!!])....bin auch ich entäuscht über die Softwarehersteller. Wie schon gesagt bis auf zwei strittige Felder, ist das Datensatzformat schon seit Februar 2001 bekannt.
Die Softwarehersteller sahen in den zwei vom Datenschutz bemängelten Feldern wohl eine willkommene Ausrede, erst mal nichts zu tun....
Aber es gibt ja eine gute Möglichkeit den Druck auf die Softwarehersteller auszuüben, diese sind vertraglich verpflichtet die gesetzlichen Forderungen an Datenlieferungen nachzukommen....
Tun Sie das nicht, dann können diese auch sämtliche Sanktionen tragen......
Ein weiterer häufiger Fehler ist die Nachbearbeitung der Daten in MS-Excel....
Die führende Null der PLZ, des Aufnahme und Entlassungsgrundes wird von excel automatisch gelöscht (Umgehung: Datei von xyz.csv in xyz.txt umbenennen, Excel öffnen und aus Excel die txt-Datei importieren und beim Exportassistenten für diese Felder expliziet Text-Format wählen)...
Ein weiterer Excel-Fehler ist hier das nicht-erzeugen von Trennzeichen zwischen Leerfeldern (Tabellen: ICD und Fall)...
Also kann ich nur empfehlen, gerade diese zwei Tabellen mit dem Editor anzuschauen und die Symikolons zumindest Stichprobenartig zu zählen....sonst führt dies nämlich zu einem Fotmatfehler und automatisch zur Ablehnung des gesamten Datensatzes....
gerade was die Überprüfung auf die richtige Anzahl der Semicolons angeht, bringt mir das DKG-Tool bei allen Dateien die Meldung es seien zu viele Semicolons pro Zeile und die Dateien seien deshalb nicht einlesbar.
Bei Betrachtung mit einem Editor sehe ich allerdings immer die korrekte Anzahl der Semicolons.
das hört sich an, als fehlten die Zeilenumbrüche (CR = Carriage Return) in Ihren Dateien. Herr Jacobs hatte dazu kürzlich mal einen Tipp gegeben (ich weiss nur nicht mehr wo).
die Lösung von Hr. Jacobs finden Sie im Forum "EDV u. kritische Erfolgsfaktoren" im Thread "Siemens / Clinicom §21 KHEntgG".
Könnten Sie mich über das Ergebnis kurz informieren? Die Lösungen von Hr. Jacobs führen bei mir leider nicht zum Erfolg.
bei der DKG ist ein Update des Prüftools verfügbar:
http://www.dkgev.de/pub/newpdf…ten-Pruefung_26-03-03.zip
Unser KIS-Hersteller hat heute seine Kunden gewarnt, das Tool einzusetzen, da es gegenüber dem File-Prüfer von MMM abweichende Ergebnisse liefern soll. Mich persönlich interessiert die Meinung unseres KIS-Anbieters bezgl. Datensätzen und wie sie zu erstellen seien nicht mehr, da auch in der heute eingespielten §21-Version Merkwürdigkeiten auftreten, die mein Vertrauen in automatisch generierte Datensätze nicht gerade positiv beeinflussen (8 Leerzeichen, wo eigentlich 9 Stellen oder gar nichts drinstehen sollte, zwei Hauptdiagnosen zu einem Fall, automatische Generierung des Arbeitsfähigkeitskennzeichen 2 bei Personen, deren Arbeitsfähigkeit aufgrund des Alters tatsächlich von Interesse ist, die Fehlerprüfung der Datenstelle aber geau diese Fälle als Fehler rückmeldet...ich hab' noch mehr :-((
Rückmeldung zur Datenlieferung durch 3M: 127 Fehler, davon 126 externe Verlegungen (Kennzeichen 06 / 08 / 09 / 10), jeweils mit Arbeitsfähigkeit 2, also 062 / 082 / 092 / 102 --> Fehler, weil wohl statt der 2 die 9 da rein muss. Da dieses Kennzeichen im KIS oftmals gar nicht angegeben war (schlechte Doku), schließe ich daraus, dass es automatisch, nur leider wohl nicht File-Inspector-konform generiert wurde. Ich schließe weiter, dass - wenn man seine Kunden vor, wie ich nach wie vor finde, hilfreichen Tools warnt - man lieber zusehen sollte, dass der eigene Datensatz stimmt, zumal man ja mehr als ein halbes Jahr Zeit zu dessen "Programmierung" hatte...
Ach ja: Der eine Fall von den 127 Fehlern --> Ein Neugeborenes - aufgenommen am 22.04., geboren am 23.04. Alter im Datensatz: Minus 1 Tag. Soviel zu Plausibilitätsprüfungen im KIS. Ja, ja, könnte man einwänden --> habt ihr eben nicht aufgepasst und was falsch gemacht, ihr dummen KH-Mitarbeiter...
Man könnte aber auch fragen: Wie kann das eigentlich edv-technisch möglich sein ???
Das 30300 Gramm (Tippfehler, nicht als Fehler erkannt) schwere Neugeborene ist dann vermutlich Kind einer Diabetikerin...
EDV zu Fuss
... können ... hat da diesbezüglich irgendjemand Erfahrungen? Ein Rechtsstreit scheint mir vom Ausgang her in diesen Dingen sehr ungewiss zu sein....
nachdem ich nun (endlich) damit beginne, die §-21-Dateien mal intensiver anzuschauen, stellen sich viele Fragen:
Laut Anlage 2 zur Vereinbarung nach §21 KHEntgG (Seite 16, Datei ICD) soll zu jeder Diagnose max. eine Sekundärdiagnose angegeben werden können und zwar IN DERSELBEN ZEILE!
1. Wie soll das bei Fällen gehen, die zu einer Primärdiagnose mehrere Sekundärdiagnosen haben (z.B. diabet. Fuß: vgl. DKR2003, Seite 93).
2. Unser KIS (SAP IS-H) kümmert sich erwartungsgemäß um diese Vorgabe nicht und liest alle Diagnosen untereinander aus. Muß damit gerechnet werden, daß diese Datensätze als fehlerhaft zurückgewiesen werden?
3. Wie soll man sich bezügl. Aufnahmediagnosen verhalten? Meiner Meinung nach gehören diese nicht in die §21-ICD-Datei, aber ich finde nirgends eine Spezifikation.
unser KIS(Siemens) bietet die Möglichkeit, bestimmte Diagnosen nicht mit in den §21-Datensatz einzulesen. Daher habe ich auf die Aufnahmediagnose auch verzichtet.
also wir haben in ORBIS von GWI die Sekundärcodes in derselben Zeile. Das scheint ein Programmierfehler bei SAP?
Zu Frage 1: die Primärcodes müssen mehrmals angegeben werden z.B. E11.70+ G63.2* und E11.70+ I79.2* usw
Nach Auskunft von GWI ist das technisch z.Z. noch nicht anders lösbar.