eGK läßt sich nach Quartalswechsel nicht einlesen

[maderstorfer]

Hallo alle zusammen,

habe lange nichts von mir hören lassen, weil Probleme zuletzt lösbar ohne Hilfe der guten Feen.
ABER: Jetzt hab ich ein Riesenproblem.

Die Versichertenkarten (eGK) lassen sich seit heute, Quartalswechsel, nicht mehr einlesen. (Habe bereits Update 14.4.1 auf dem Rechner, Update via Download)

Wenn ich die Versichertenkarte ins Lesegerät stecke und anschließend "Behandlungsfall mit eGK anlegen" anklicke, dann kommt folgende (zum Beispiel für einen Barmer-Patienten) Meldung:
"Ein Kostenträger mit den Daten dieser KVK (Name = Barmer GEK) VKNR= "", IK 8380007, KTUG= "-1", ist in keinem Kostenträgerstamm vorhanden! Es wird daher ein Ersatz Eintrag mit den Daten diser KVK erstellt. Überprüfen, komplettieren und ggf. korrigieren Sie bitte die Angaben."

Drücke ich OK, dann kommt folgende Meldung:
"Klären Sie unbedingt bei Ihrer KV, ob es diese Kasse überhaupt gibt!
Diese so manuell angelegte Kasse und in der Folge als ..... " (ewig langer Text)

Drücke ch dann OK, dann kommt folgende Meldung:
"Diese Vknr () ist nicht 5-stellig numerisch oder die ersten beiden Ziffern sind kein gültiger K bereich. Bitet bearbeiten Sie Ihre Kasse."

Drücke ich dann OK, dann kommt folgende Meldung:
"Abrechnungsart "0" ist ungültig. Bitte bearbeiten Sie Ihre Kasse:"

usw.usw.usw

Wem ist das auch passiert?
Die Hotline von TurboMed glüht, seit 4 Stunden komme ich nicht durch.

Ich habe am Sonntag, den 28.09.14 das Update 4/2014 (14.4.1.) draufgespielt. Da ich noch keine DVD hatte (kam erst am Montag, den 29.09.14 mit der Post) habe ich ein Download von der TurboMed Web-Seite verwendet.

Was tun?
Sollte ich das Update von der DVD nochmals drüberspielen? Oder wer hat eine Lösung?

Vorab schon mal vielen Dank für Lösungsmöglichkeiten!

Schöne Grüße
A. Maderstorfer

[DocMoritz]

Hallo, ich habe auch das neueste Update (Download)und auch heute viele Patienten gehabt überhaupt kein Problem alles glatt gelaufen. Zu Ihrem Problem: wenn man bei TM nicht durchkommt,dann Neuinstallation, wäre meine Empfehlung ,vielleicht klappts. irgendwie sind wohl bei Datenbankaktualisierung neue Kassen nicht richtig übernommen worden vermute ich. Viel Glück

[Otmar Cramer]

Auch bei mir heute morgen keine Probs b. Einlesen v. eGK`s - alles
gut bis auf (bekannten) Fehler, daß mit "Strg F9" keine Datumsaktualisierung möglich war.
Bremst den Praxisablauf v.a. vorne bei meinen Damen.
Ansonsten gleiche Empfehlung wie bei "DocMoritz" - neu installieren !

Viel Glück

Frdl. Gruß

Otmar Cramer,Neuwied

[J.Becker]

Vielleicht einfach nochmal die Krankenkassen aktualisieren lassen ? dieses sollte ja autmatisch passiert sein....Bevor man nochmal neu installiert. Viel Glück!

[maderstorfer]

Hallo alle zusammen,

vielen Dank an die bisher antwortenden.

Werde jetzt gleich mal die Krankenkassen aktualisieren und wenns nicht geht, nochmals ein Update von der DVD runterspielen.

Anschließend berichte ich über das Ergebnis.

Nochmals vielen Dank und schöne Grüße

A. Maderstorfer

[maderstorfer]

Hallo alle zusammen,

leider haben die Tipps fehlgeschlagen.

Habe über Wartung versucht, die Krankenkassen anzugleichen. Anschließend war gleiches Problem wieder. Oder gibt es eine andere Möglichkeit die Krankenkassen zu aktualisieren?

Hab dann von der DVD Update nochmals neu draufgespielt. Anschließend wieder gleiches Problem.

Oder könnte es am Lesegerät liegen? Habe 2 mobile Zemo-Geräte.

Bitte nochmals um Hilfe und sage im Voraus schon "Danke"!

Schöne Grüße
A. Maderstorfer

[Geigenberger]

Hallo,

ergänzen möchte ich noch, dass das Update bereits am Wochenende eingespielt worden ist und dass das Programm am Montag und am Dienstag diese Woche, also vor dem Quartalswechsel, noch problemlos gelaufen ist - auch das Einlesen von neuen Versicherungskarten.

Erst der Quartalswechsel führte zu dem Problem!

A. Geigenberger

... und ich weiß, dass TurboMed hier mitliest. Ich bin sehr enttäuscht von der Hilfsbereitschaft dieser Firma. Unter Frau Telse Ramm war das ganz anders! Sind die Anwender TurboMed mittlerweile total egal????
Aber - die Zeiten könnten sich schnell dramatisch ändern!!
http://www.vondoczudoc.de/viewforum.php?f=70

[Kasimir]

...Oder könnte es am Lesegerät liegen? Habe 2 mobile Zemo-Geräte...

Ich habe (unter anderem) auch ein mobiles Lesegerät von ZEMO - und ich hatte keine Probleme. Das Lesegerät ist bestimmt nicht der Übeltäter.

Ich lese die Karten llerdings anders ein:
Es wird irgendein Patient aufgerufen und dann mit "Shift-F9" der Patientensuchvorgang und damit das Chipkartenlesen angestoßen...

[wahnfried]

Ich lese die Karten llerdings anders ein:
Es wird irgendein Patient aufgerufen und dann mit "Shift-F9" der Patientensuchvorgang und damit das Chipkartenlesen angestoßen...

Hallo,

wenn es aber Schreibweise-Veränderungen des Namens oder auch mal der Adresse gibt, oder ein manuell angelegter Fall eine andere IK-Nummer zugeordnet hatte als auf der Karte gespeichert ist, gibt es mit "Fernglas" oder "Shift + F9" Probleme, dann hilft nur: die angebotene Neuanlage des Patienten abbrechen, korrekten Patienten aufrufen und dann F10, BEVOR man die Chippppkarte gesteckt hat.

Grüsse, Wahnfried

[maderstorfer]

Hallo alle zusammen,

Danke an Kasimir und Wahnfried, aber leider auch fehlgeschlagen.

Habe gestern ungefähr 30 x (!) bei TurboMed Hotline angerufen. Immer belegt. Und abends dann Meldung außerhalb unserer Sprechzeiten.

TurboMed hat ja in der Nacht eine Korrekturpatch zum Downloaden reingestellt, dort kommt logsicherweise aber mein Problem nicht vor, weil ich in der Hotline ja nicht durchgekommen bin. Habe trotzdem die Korrekturpatch draufgespielt und ging, wie erwartet, nicht.

Habe aber eine neue Erkrenntis, vielleicht ist dies eine wichtige Information für die Lösung.

Wenn ich eine Veersichertenkarte (z.B. AOK) einlesen will, dann folgt dieses unsinnige Flußdiagramm , wie in meinen Ur-Schreiben beschrieben. Aber mir ist aufgefallen, dass dann unter "Eigene Listen" "Kostenträger" "Krankenkasse" plötzlich eine AOK auftaucht, bei der unter VKNR gar nichts drinsteht, unter IK die normale AOK Nummer 8310400, unter KTUG "-1" (bei den anderen Kassen steht "0" oder eine andere Zahl), unter KTG steht "0" und unter GO steht ein Fragezeichen. Dann habe ich eine Barmer Karte eingelesen und plötzlich war unter Eigenen Listen - Kostenträger - Krankenaksse eine neue Barmer GEK mit den gleichen sinnlosen Daten wie bei der AOK. Also baut hier beim Einlesen der Karte das Programm unter Eigene Listen - Kostenträger- Krankenkasse eine neue unsinnige Kasse ein. Vileleicht ist da der Schlüssel für die Lösung? Aber ich kann die Lösung nicht finden.

Übrigens: Wenn ich das Flußdiagramm beim Einlesen der Karte durchziehe, dann kommt beim Patienten schon ein grüner Punkt, aber es wurde dann ein Sozialhilfefall angelgt und unter F2 kennt er die EBM-Ziffern nicht mehr und mault.

Bitte nochmals dringend um Hilfe und hoffe, dass hier auch ein TurboMedler reinschaut. Bin stocksauer!!

Bei mir ist jetzt schon die ganze Kartekarte mit Patienten voll, die ohne eGK angelegt wurden. Die MFAs können dann wieder den Leuten hinterher telefoniereen und die Karten nachbestellen, wenn das Problem mal gelöst ist.

Schöne Grüße und vielen Dank
A.Maderstorfer

[Geigenberger]

Hallo Armin,

zu denken gibt die Tatsache, dass dieses Problem offenbar nicht bei sehr vielen Praxen auftritt. Es könnte (muss?) also etwas mit der Konfiguration unserer Netzwerk-Topologie zu tun haben...
Zur Lösung könnte es weiterhin führen, dass der Fehler erst beim Quartalswechsel selber aufgetreten ist und nicht schon vorher. Das Update wurde ja schon Tage vorher eingespielt und der Praxisbetrieb lief völlig ungestört genau bis zum Quartalswechsel.

Ganz offenbar erwartet TurboMed ab dem Quartalswechsel Daten im Programmablauf, die es nicht geliefert bekommt - und zwar erst ab dem Quartalswechsel!! Dies muss mit irgendwelchen neuen Krankenkassen-Kennziffern zu tun haben, soweit ich das am Rande mitbekommen habe. Darauf weist auch diese Fehlermeldung hin:
"Ein Kostenträger mit den Daten dieser KVK (Name = Barmer GEK) VKNR= "", IK 8380007, KTUG= "-1", ist in keinem Kostenträgerstamm vorhanden! "

Die Frage ist also: WO erwartet TurboMed die Daten, die in keinem Kostenträgerstamm vorhanden sind??? Und warum findet TurboMed diesen Kostenträgerstamm ab dem Quartalswechsel gerade bei uns nicht mehr?? Welche Daten braucht TurboMed aus dem Kostenträgerstamm, die es vorher (also vor dem Quartalswechsel) nicht gebraucht hat??

Vielleicht führen diese Gedanken zur Lösung. Vielleicht erbarmt sich ja sogar jemand von T2Med Diese Jungs kennen doch die TurboMed-Programm-Strukturen

Zur "Topologie" des Netzwerks, soweit ich es auswendig im Kopf habe:
6-Platz Anlage
Peer-to-Peer (mit einem vorbereiteten "Notfallserver")
Der Server hat eine SSD als zusätzlich Festplatte, auf der die "PraxisDB", die "StammDB", die "DruckDB" und die "Dokumente" sind.
Kann es sein, dass ein Arbeitsplatzrechner nicht über den FastObjects-Server auf die "StammDB" zugreift, sondern "direkt" über einen Netzwerkpfad (local.ini) ?

Jemand weitere Ideen?? Danke!

A. Geigenberger

[J.Becker]

Vielleicht kommt man dem Problem näher, wenn man den Einleseplatz mal auf Einzelplatz umstellt ( sofern er eine Spiegelung der Praxis DB besitzt ) und versucht eine Karte einzulesen....Gruß aus Wuppertal

[michael]

Habe gestern ungefähr 30 x (!) bei TurboMed Hotline angerufen. Immer belegt. Und abends dann Meldung außerhalb unserer Sprechzeiten.

Schreiben sie an hotline@turbomed.de, bisher hat mich am gleichen Tag immer jemand angerufen!

Die MFAs können dann wieder den Leuten hinterher telefoniereen und die Karten nachbestellen, wenn das Problem mal gelöst ist.

Ich habe gestern das mobile Lesegerät zum doppelt einlesn an der Anmeldung daneben gelegt.
Gott sei Dank brauchten wir die daten nicht.

Viel Erfolg

Michael

[Geigenberger]

Hallo,

soeben konnten wir das Prolem lösen!

Damit alle Forumsteilnehmer etwas davon haben, hier kurz ein Erläuterung dieses Fehlers, der wieder einmal sehr lehrreich war.

Auf unserem Praxisserver ist eine SMD-Festplatte und auf dieser hatten wir neben den "Dokumenten" auch die "PraxisDB", die "StammDB" und die "DruckDB". Diese SMD Platte hat im Netzwerk den Netzwerkbuchstaben "E:\". Der FastObjectServer greift auf diese SMD zu.

Beim Update wird aber die "StammDB" im Laufwerk "C:\" des Servers "upgedatet", der FOS liest also im Netzwerkbetrieb nicht die aktualisierten Daten ein, sondern die nicht aktualisierten Daten auf "E:\"

Eine entsprechende Änderung der Pfade in der "PtServer.cfg" löste das Problem.
Dank an alle hilfsbereiten Kollegen hier!!

A. Geigenberger

<<<<<<<<<<<<

Was es mit den "Server-Pfaden" auf sich hat können Sie hier unter Punkt 3 http://www.vondoczudoc.de/viewtopic.php?f=11&t=5061 nachlesen, wenn Sie mit dieser Materie noch nicht so vertraut sind.

[McLeod]

Also vom Prinzip das gleiche Problem wie hier (vom März 2014):
http://vondoczudoc.de/viewtopic.php?f=11&t=4851

Weicht man mit den DB-Verzeichnissen vom Standard (unterhalb des TM-Ordners) ab, muß man händisch nacharbeiten.
Entweder a) durch Rückändern der ptserver.cfg auf Standardpfade
oder b) durch Kopieren/Verschieben der betreffenden Dateien an das gewünschte bzw. in der ptserver.cfg eingetragene Ziel.

Dem ganzen Gefummel kann man natürlich aus dem Weg gehen, wenn man einfach den ganzen TM-Ordner auf die SSD bzw. das SSD-RAID legt.

[maderstorfer]

Hallo alle zusammen,

wie von A. Geigenberger schon geschildert läuft die Sache jetzt. Der entscheidende Hinweis kam von J.Becker mit dem Versuch auf Einzelplatzversion umzustellen. Dann funktionierte die Sache. Also war klar, dass die Pfade nicht stimmten.

Ich möchte mich nur abschließend bei allen bedanken, die unterstützend zur Seite standen.

Schöne Grüße

A. Maderstorfer

[danspie]

Hallo,
nun haben wir auch ein Problem beim Einlesen der eGK oder auch nur bei händischem Neuuanlegen eines KV- odr HzV-Falles: Turbomed hängt sich auf. Danach muss man Turbomed abschießen und sich aus Windwos auloggen. Teilweise geht es dann wieder, teilweise auch nicht. Dies betrifft auch immer wieder andere PCs, aber alle sind davon betroffen, auch der Terminalserver. Gestern habe ich eine Datenbankreorganisation durchgeführt ohne wesentlichen Erfolg. Hat jemand dazu eine Idee?
Vielen Dank
A. Spiegl