E-Rezept ist verpflichtend seit dem 01.01.2024
Alle Hinweise und Informationen zur Nutzung finden Sie unter folgendem Link.
Aktuell kommt es vermehrt zu Störungen und Dienstausfällen in der TI, die das Signieren, u.a. von E-Rezepten, beeinträchtigen.
Infos dazu finden Sie in diesem Forumsbeitrag.
Liebes zollsoft-Team,

die Statistik ist definitiv eine der ganz großen Stärken von tomedo, kann aber sicher da und dort noch etwas aufgebohrt werden.

Ich möchte an dieser Stelle anregen, daß man ICD-Codes mit Wildcards und unter Einbezug der Sicherheit suchen kann. Suchmuster wie "F20*G" wären dann möglich.

Meine Motivation zu der Anfrage: Wir Psychiater können bestimmte Betreuungsziffern (21230, 21231, 21233) bei bestimmten gesicherten Diagnosen abrechnen. Oft gehören diese zu einer ganzen Gruppe. Beispiele wären die gesicherte Alzheimer-Demenz (F00.X mit Sicherheit G) und die gesicherte Schizophrenie (F20.X mit Sicherheit G). Nach gegenwärtigem Stand kann man nach dem Anfangstext "F00" oder "F20" suchen, bekommt aber auch Verdachtsdiagnosen oder Ausschlüsse angeboten, bei denen die Betreuungsziffern nicht abgerechnet werden können. Eine Suche etwa nach "F00*G" oder "F20*G" würde alle Probleme beheben.

Eine Suche einschließlich Sicherheit wäre natürlich auch bei vollständig vier- oder fünfstellig codierten Ziffern sinnvoll und nötig.

Auch in anderen medizinischen Fächern setzen manche Leistungen bestimmte Diagnosen voraus, und überall blamiert man sich bei der KV, wenn man die bei einem Ausschluß oder einem "Zustand nach" abrechnet.

Die Suche mit Wildcards innerhalb einer Zeichenkette könnte der tomedo-Statistik sicherlich auch an anderen Stellen gut tun. Ich weiß nicht, ob die Statistik gegenwärtig vielleicht reguläre Ausdrücke verdaut; die sind meines Erachtens aber keine Alternative, weil zu kompliziert (jedenfalls habe ich mir daran immer wieder die Zähne ausgebissen).

Viele liebe Grüße nach Jena,

Mike Prater
Gefragt von (8.5k Punkte)
0 Punkte

3 Antworten

Beste Antwort

Ich habe mich hingesetzt und die Statistik angepasst. Mit dieser können Sie auch nach der Sicherheit filtern. Ich werde die Statistik im nächsten Quartalsupdate auch automatisch für alle anpassen. Ich wollte dies auch für die Summenstatistik machen, aber da wird dann die Gruppierung beeinflusst. Das will ich nicht anfassen, da die Statistiken eigentlich der Bereich von Dr. Berg ist. Sollten Sie das dort auch haben, müssen sie mind. bis zum Ende seiner Urlaubsreise warten und das mit Ihm nochmal besprechen.

               select   A.codeandtype,
                        1 as anzahl, -- as dummy row for grouping
                        C.kuerzel,
                        B.bezeichnung as icdText,
                        A.freitext as eigene_Bezeichnung,
                        A.datum,
                        A.isDDI as DDI,
                        P.ident as PatientID,
                        P.vorname,
                        P.nachname,
                        P.geburtsdatum,
                        D.ident as scheinID
                from
                (
                select tmpA.*,concat(tmpB.code::text, ' ', tmpA.typ::text) as codeandtype from Diagnose tmpA
                left join ICDKatalogEintrag tmpB
                on (tmpA.ICDkatalogeintrag_ident = tmpB.ident)
                ) as A
                left join ICDKatalogEintrag B
                on (A.ICDkatalogeintrag_ident = B.ident)
                left join Nutzer C on (C.ident = A.dokumentierenderNutzer_ident)
                -- nur Diagnosen beachten die an einem Schein hängen, dehalb nicht LEFT join. Es werden so z.B. die Dummy-Favoritenleistungen ignoriert
                join kvschein_quartalsdiagnosen JT
                on (JT.quartalsdiagnosen_ident = A.ident)    
                join KVSchein D
                on (D.ident = JT.kvschein_ident)
                -- determine patient (cannot be done via kartendaten, since schein doest not need to have kartendaten)
                join patientendetailsrelationen_kvscheine H
                on (D.ident = H.kvscheine_ident)
                left join patientendetails I
                on (I.patientendetailsrelationen_ident = H.patientendetailsrelationen_ident)
                left join patient P
                on (P.patientendetails_ident = I.ident)    
                where
                <ZS:queryParameter2> QUARTAL;Diagnosedatum im Quartal;A.datum;and </ZS>
                <ZS:queryParameter3> DATE;-1;Diagnosedatum ab;A.datum >=; and </ZS>
                <ZS:queryParameter4> DATE; 1;Diagnosedatum bis;A.datum <; and </ZS>
                <ZSBLOCK>
                    <ZS:queryParameter5> STRING;     Diagnosencode;or A.codeandtype; </ZS>
                    <ZS:queryParameter6> STRING;oder Diagnosencode;or A.codeandtype; </ZS>
                    <ZS:queryParameter7> STRING;oder Diagnosencode;or A.codeandtype; </ZS>
                </ZSBLOCK>  and
                <ZSBLOCK>
                    <ZS:queryParameter8> STRING;     Diagnosentext;or A.freitext; </ZS>
                    <ZS:queryParameter9> STRING;oder Diagnosentext;or A.freitext; </ZS>
                    <ZS:queryParameter10> STRING;oder Diagnosentext;or A.freitext; </ZS>
                </ZSBLOCK>  and
                A.visible = true and
                D.visible = true
                order by code asc, kuerzel asc;
Beantwortet von (82.9k Punkte)
ausgewählt von
+1 Punkt

(da die 8000 Zeichen erreicht sind geht es hier weiter:)

Sie können dann "einfach" nach Dingen wie

  • "F79.1 G" -> genau der Code mit gesichert
  • "F7_._ G" -> alle gesicherten die mit F7 beginnen
  • "F71._ A" -> alle Subdiagnosen mit Ausschluss
  • "% V" -> nur Verdachtsfälle
  • "F70.8" -> dieser code egal welche sicherung

filtern ... ich glaube das System ist klar

Lieber Herr Thierfelder,

jetzt hauen Sie mich von den Socken. Ich habe da mal so eine Idee für eher langfristige Entwicklungen gehabt und wollte eigentlich gar nicht quengeln, und nun präsentieren Sie gleich am nächsten Tag eine fertige Lösung. Total Spitze, ganz herzlichen Dank. Werde das neue Script nach der Sprechstunde in unsere Statistik reinbasteln.

Vielen Dank nach Jena und ein hoffentlich erholsames Wochenende!

Wildcards gehen schon, man muss nur wiessen wie die gehen. Ein % ist für beliebig viele Zeichen, ein _ für ein Zeichen. Die sollten in der Statistik meist funktionieren, ausser tomedo hebelt die nativen sql Sachen aus.

In Ihrem Fall könnte man mit F7_._ nutzen.

Beantwortet von (82.9k Punkte)
+1 Punkt
Erst mal ganz vielen Dank für den Tip mit den Wildcards. Ich werde damit experimentieren. Habe nämlich die Wildcards versucht, die man von Textverarbeitungen kennt, also "*" oder "?", und damit keinen Erfolg gehabt.

Die Wildcards wären doch bestimmt auch was für das Nutzerhandbuch?

Den systematischen Einbezug der Diagnosesicherheiten würde ich noch toll finden. Man findet sie durchaus in der Statistik "EBM-Diagnosen" und kann danach einfach filtern. Schön wären sie aber auch in der Statistik "KV-Scheine", dann könnte man "KV-Scheine mit Diagnose X.XG" suchen, ohne zwei Tabellen verknüpfen zu müssen.
Handbuch: stimmt, da ist die frage, wo genau soll es hin. Das ist eine info die man eh gern überliesst.

Das mit der Diagnosesicherheit ist nach 5min draufschaun nicht einfach zu lösen. Da muss die Statistik neu gestaltet werden...
Handbuch: Ich glaube, ein kleiner Unterabschnitt zum Umgang mit Sub-Strings mit der Erklärung, daß er für Auswahl- und Ergebnisfenster zutrifft, wäre toll. Da könnte z.B. auch eine Bemerkung für Neulinge rein, daß Leistungs- und ICD-Ziffern nicht als Zahlen, sondern als Zeichenketten behandelt werden.

Überhaupt finde ich, daß ein so überaus mächtiges Werkzeug wie die tomedo-Statistik mehr Raum im Handbuch verdient hätte. Wenn man eine Weile an allen Knöpfen gespielt hat und sich auskennt, kommt man selbst dann, wenn mehrere Primärabfragen, Filter und Verknüpfungen nötig sind, in meist weniger als einer Minute in jeden noch so seltsamen Winkel der Datenbank, aber erst einmal ist die Bedienung komplex.

Die Manipulation der SQL-Abfragen (das Abwählen des visible-Atributs schätze ich als archäologisches Werkzeug) würde natürlich jeden Rahmen sprengen.

Da hat Herr Prater Recht. Könnte das in das Liste der Abrechnungsfehler Panel aufgenommen werden? Das ist zwar kein Fehler durch den die Abrechnung durchläuft aber man bekommt dadurch Post von der KV. Oft ist ein Tumor nicht gesichert vor dem Eingriff und muss mit Ausschluss oder Verdacht codiert werden. Man vergisst den Schalter hier später umzustellen, weil es auch für den Patienten ganz gleichgültig ist und mir eigentlich auch, was da steht, der KV und den Kassen aber leider nicht. 

und überall blamiert man sich bei der KV - der war richtig gut Herr Prater, super! hahaha :)

Beantwortet von (55.2k Punkte)
0 Punkte
15,709 Beiträge
23,399 Antworten
40,981 Kommentare
10,811 Nutzer