Probleme mit KV Safenet bei der KV-No ?

Wie immer stand Ende März 2017 die KV-Quartalsabrechnung in unserer Praxis an, wobei wir neben der eigentlichen Abrechnungsdatei auch eine digital signierte Gesamtaufstellung (eine pdf)  erstellen und zusammen mit der eigentlichen Abrechnungsdatei als Paket mittels KV Safenet an die KV Nordrhein übermitteln.

Zur Signatur wird der HBA (Heilberufeausweis) von medisign verwendet, als Signatursoftware (noch) eine nicht mehr ganz frische Version von OPENLIMIT.

Das läuft an sich auch alles ganz gut.

Wäre nicht eine Woche vorher Sommerzeit-Umstellung gewesen.

Aber der Reihe nach.

Es muß hinzugefügt werden, dass ich zwei Wochen zuvor erfolgreich eine Testabrechnung, inkl. digital signierter Gesamtaufstellung (das ist möglich in KV Safenet 2.1) bereits erfolgreich übermittelt hatte, aber das war vor der Zeitumstellung.

Auf unserer Seite lief die Erstellung der Abrechnung für die beiden Ärzte der Praxisgemeinschaft zunächst ganz problemlos: Erstellen der Abrechnungsdatei, der Gesamtaufstellung, die Signatur mittels der jeweiligen HBA, selbst die Übermittlung zur KV Nordrhein, alles ohne Probleme.

Zurück kam eine Quittung, die besagte, dass die Signatur zwar gültig, aber nicht kontrolliert werden konnte. Nach einigen Anrufen bei der KV ergab sich folgende Situation: Die Signatur sei deswegen abgelehnt worden, weil die überprüfende Software zum Zeitpunkt des Eintreffens der Datei auf dem Server der KV eine Signatur vorfand, die eine Stunde in der Zukunft signiert worden war. Also beispielsweise ist die Abrechnung um 10.27 Uhr eingetroffen, die Signatur aber war – laut der kontrollierenden Software bei der KV – um 11.27 Uhr erfolgt, also in der Zukunft, daher habe die Software die Signatur abgelehnt. Ich müsse die Zeiteinstellung auf meinem Rechner überprüfen, so wurde mir mitgeteilt.

Nun ist es aber so: wäre ein einsendender Rechner nicht umgestellt worden, wäre er um eine Stunde in der Vergangenheit, da die Uhren in der Sommerzeitumstellung vorgestellt wurden.

Mit der Zeit wurde mir also klar, dass das Problem nicht auf unserer Seite liegen kann. Wenn der Rechner, der auf Seiten der KV die Signatur kontrolliert in der falschen Zeitzone liegt, oder die Umstellung nicht mitgemacht hat, wird er jede Signatur als aus der Zukunft kommend empfinden – und offenbar ablehnen.

Es gelang mir schließlich, der KV Nordrhein klar zu machen, dass ein solches Problem nicht auf unserer Seite liegen kann. Ein Mitarbeiter der KV hatte zunächst, um das Problem vordergründig zu lösen, die abgelehnte Abrechnung eine Stunde später wieder ins System gestellt (nun fand der kontrollierende Rechner die Uhrzeit der Signatur in Ordnung) und damit – zunächst – das Problem gelöst. Die Abrechnung war nun gültig und  passierte das System einwandfrei.

Weitere Kontrollen ergaben nach Aussagen des Mitarbeiters folgende Situation: auf ein- und demselben Rechner der KV waren 3 verschiedene Signatursoftware-Programme installiert, offenbar zu Testzwecken. Zwei davon ließen die Signatur anstandslos passieren, eine nicht, genau diese aber kontrolliert alle Abrechnungen und fand viele davon vermeintlich in der Zukunft. Die Systemzeit dieses Rechners war aber offenbar in Ordnung.

Das Problem ist zum Zeitpunkt dieser Niederschrift noch nicht abschließend gelöst, man behalf sich damit, auf Seiten der KV die abgelehnten Abrechnungen (es gab mehrere Kollegen mit dem Problem)  eine Stunde später  noch einmal einzustellen, dann jeweils mit Erfolg.

Einige Kollegen konnten das Problem offenbar vermeiden, indem sie eine signierte Abrechnung erst eine Stunde später mit KV Safenet verschickten, oder die Abrechnungssoftware tut dies von sich aus. Dann natürlich findet der KV Rechner keine Probleme.

Nun also verlangte ich eine korrigierte Quittung. Die sei erstellt und verschickt, erreichte mich aber nicht. Eine Kontrolle auf meiner Seite ergab dazu folgendes: technisch sollte die Quittung aus der pdf Datei („Empfang.pdf“), einer Datei mit der Endung „eda“ und einer „begleitdatei.xml“ bestehen. Im Falle der abgelehnten Abrechnung war das auch der Fall.

Diese Quittung war auch erfolgreich übertragen worden.

Die korrigierte Quittung aber erfolgte ohne „begleitdatei.xml“, die wird aber von Seiten der bei uns verwendeten Software (ISYNET von medatixx) zur Anzeige der mittels KV-Safenet empfangenen Daten benötigt und ist auch Teil der KV Safenet-Spezifikation.

Nach einiger Suche fand ich die (korrigierte) Quittung dann auch in den Tiefen meines Servers und konnte sie einsehen und ausdrucken. Sie war übermittelt, aber aufgrund des beschriebenen Fehlers nicht angezeigt worden.

Ein weiterer Anruf bestätigte auch diesen Fehler auf Seiten der KV No.

Aus meiner Sicht also fanden sich zwei Fehler auf Seiten der KV Nordrhein: zum einen ist die Software zur Überprüfung der Signaturen auffälligerweise eine Woche nach Sommerzeitumstellung in der falschen Zeitzone und lehnt die Signaturen daher ab, zum anderen erfolgt die Rücksendung der Quittungen nicht in jedem Falle gemäß der Spezifikationen für KV Safenet.

Wie unter diesen Umständen jemand seine Abrechnung ohne Detailkenntnisse zuzüglich 30 Telefonate machen soll, ist mir schleierhaft. Das ganze ist weit davon entfernt kundenfreundlich zu sein und natürlich höchst ärgerlich.

Ich denke, ich werde in einigen Tagen mehr zum Thema erfahren, ich werden dann erneut berichten.

SCM eHealth500 nun auch für MCS-ISYNET verfügbar

Rückseite des Gerätes mit Akkus und Rückendeckel mit Einschub für den Heilberufeausweis

Lieferumfang des SCM eHealth500

SCM eHealth 500 mobiler eGK Leser

Bereits vor Monaten wurde das SCM eHealth 500, ein mobiles eGK Lesegerät für die Gesundheitskarte und KVK (alte Krankenversicherungskarte) geliefert, mit einiger Verzögerung ist das Gerät nun endlich unter der Praxissoftware MCS-ISNET betriebsbereit und zwar auch unter Terminalserver.

Dies gilt im übrigen auch für das offenbar baugleiche Hypercom medMobile.

Zu diesem Zweck ist eine neue Treibersoftware, insbesondere eine aktulisierte CTSCM500.dll verfügbar, die auf dem Server im Verzeichnis c:\windows\system32 ausgetauscht werden muß. Dann endlich funktioniert das Gerät auch unter Terminalserver 2003.

Zuvor ist das Gerät in ISYNET unter den Parametereinstellungen zunächst zu aktivieren, dann der genaue Gerätetyp auszuwählen, schließlich wählt man „USB“ und den genauen COM Port, den das angeschlossene Gerät auf dem Arbeitsplatz belegt.  Wie bekannt, wird der USB Anschluß unter Windows Terminalserver 2003 nicht an den Server weitergegeben, daher wird der USB port über einen COM Port abgebildet. Den genauen Port sieht man dazu in den Windows Systemeinstellungen nach.  Einziges Handycap bisher: das Gerät muß beim Start der terminal- session angeschlossen sein, um erkannt zu werden.

Zum Auslesen der gespeicherten Karten sollte man sich die erste Karte anzeigen lassen, das Gerät erwingt dann die Eingabe der mehrstelligen PIN, die man bei Ersteinrichtung des Gerätes angeben musste.  Ohne diese PIN erhält man in ISYNET beim Versuch die Karten auszulesen, eine Fehlermeldung.

Nachtrag vom 7.12.: Es erreichte mich eine E-mail von MCS, die ich an dieser Stelle weitergeben möchte:

es ist leider korrekt, dass das Lesegerät zum Zeitpunkt des Starts der Terminalsitzung angeschlossen sein muss. Ansonsten wird der Anschluss, der ja zu dem Zeitpunkt nicht vorhanden ist, auch nicht mit in die Terminalsitzung genommen. Dies lässt sich momentan technisch nicht anders realisieren, bzw. ist mir hier in Bezug auf COM Schnittstellen nichts anderes bekannt. An dieser Stelle müsste ein Weg gefunden werden, den einmal virtuell im Geräte Manager erzeugten COM Port des Clients, auch nach dem Abziehen des Gerätes nicht wieder zu entfernen.

MCS-ISYNET können Sie aber an dieser Stelle geöffnet lassen. D.h. es sollte reichen, die RDP Sitzung z.B. über das Kreuz zu trennen. Dabei wird MCS-ISYNET nicht geschlossen und ist dann nach Anschluss des Gerätes und starten der gleichen RDP Sitzung sofort wieder verfügbar.

Mit der Belegung des gleichen COM-Port bei Anschluss an einen anderen USB Port könnten Probleme auftreten. Hier sollte nach Möglichkeit der Port (unbekannt) funktionieren. Dies werde ich prüfen lassen.

Mit freundlichen Grüßen

i.A. Mark Mitchard
Produktmanagement

Herzlichen Dank an Herrn Mitchard für diese Info!

Siehe auch weitere Artikel

Erfahrungen mit der Installation eines neuen stationären Kartenlesegerätes (Hypercom medcompact slot) 2. Teil

Foto: flickr creative commons Autor: rofi

Den ersten Teil der Artikelserie finden Sie hier.

Ich hatte von Anfang an in der Praxis eine heftige Verzögerung beim Einlesevorgang einer KVK (Krankenversicherungskarte, also alte „Chipkarte“ eines Patienten) beobachtet. Zwar gab es keinerlei Fehlermeldungen und das Einlesen einer KVK war möglich, dauerte aber satte 30 bis 35 Sekunden. Verwendet wird ein terminal server 2003, das PVS ist MCS ISYNET, der client ein älterer Rechner mit einem Celeron 2,67Ghz unter Win 98 second edition mit 256Mbyte RAM, mehr wird unter terminal server auch nicht gebraucht.

Die folgende Fehlersuche gestaltete sich sehr aufwendig. Nach Kontaktaufnahme mit einem Entwickler der MCS AG in Eltville, der sich die Mühe machte, unser System naturgetreu nachzubauen, also Server unter terminal server 2003, alten client mit alten Win98 second edition Betriebssystem etc. nachbaute (!) um mir bei der Fehleranalyse zu helfen, weiterhin einem Kontakt zum Hersteller Hypercom gab es zunächst Überraschungen: der Fehler lies sich nicht reproduzieren, beim Nachbau-System lief der ganze Einlesevorgang in 5 Sekunden (eGKG rund 6-8 Sekunden) ab, eine genauere Untersuchung meines Systems zeigte dann, dass das eGK Lesegerät richtig eingestellt war, die COM Schnittstelle korrekt auf 115200 baud eingestellt war, alle Treiber richtig eingestellt etc.

Alles schien zu stimmen, dennoch gab es scheinbar unerklärlicherweise die Verzögerung beim Einlesevorgang in  meinem System, nicht jedoch beim „Nachbau“ des Systems beim Entwickler in Eltville.

Wie bekannt,  ist ein alternativ denkbarer Anschluß über USB unter terminal server 2003 nicht möglich bzw. erschwert, da USB vom client nicht an den Server durchgeschliffen wird, dies ist erst unter terminal server 2008 möglich.

Nach anfänglicher Ratlosigkeit fand sich dann aber eine überraschende Ursache für die Verzögerung: die COM Schnittstelle.

Zwar war diese  ordnungsgemäß auf die maximale Baudzahl eingestellt, 115200 baud,  hatte aber kein FIFO (Informationen hierzu: Wiki, auch hier), da es sich um ein älteres Modell handelte. Überraschenderweise war im Nachbau in Eltville weder der alte client, noch dessen RAM, noch win 98 ein Problem gewesen, selbst damit lief alles problemlos.  Den entscheidenden Satz:

Schnittstellen ohne FIFO sollten mit maximal 19200 baud betrieben werden. Da die Geschwindigkeit auf der seriellen Schnittstelle höher sein sollte als zwischen den Modems, ist für schnelle Modems eine Schnittstelle mit FIFO erfoderlich.

fand ich bei dieser Quelle. Die COM Schnittstelle muß für den Betrieb  aller eGK Leser auf die Maxmalgeschwindigkeit von 115200 eingestellt werden, also ein vielfaches davon.

Eine nähere Betrachtung zeigte dann auch, dass die fragliche COM Schnittstelle ein älteres Modell ohne FIFO war, das für den Betrieb in dieser Geschwindigkeit schlicht nicht geeignet ist. In einer ersten Fehlerbehebung verbanden wir das Lesegerät unter ansonsten identischen Bedingungen mit einem glücklicherweise zur Verfügung stehenden zweiten Arbeitsplatz, dessen Schnittstelle FIFO fähig ist und fanden das Problem beseitigt.

Die alten Kartenleser waren hiervon nicht betroffen, das diese in wesentlich niedrigerer Geschwindigkeit betrieben werden konnten, der Fehler also nie auftreten konnte.

Nun konnte eine  KVK in etwa 5 Sekunden, eine Test-eGK in 6-8 Sekunden eingelesen werden, also exakt die Zeiten, die der hilfreiche Entwickler von MCS in Eltville im Testsystem darstellen konnte.

In einem zweiten Schritt werde ich in dem alten Rechner die alte on-board COM Schnittstelle durch eine moderne Schnittstellenkarte mit COM ports ersetzen, die FIFO fähig sind um damit den Gegentest zu machen. Dann müßte auch auf dem alten Rechner alles normal laufen.

Ich werde dazu an dieser Stelle neu berichten.

Erfahrungen mit der Installation eines neuen stationären Kartenlesegerätes (Hypercom medcompact 2slot)

Foto: flickr creative commons Autor: rofi

In den ersten Apriltagen erhielt ich eines der damals ersten lieferbaren Kartenlesegeräte  für die neuen elektronischen Gesundheitskarte, es war das Hypercom medcompact 2slot. Es wurde zusammen mit einer Installations-CD geliefert und harrte seither der Anbindung an meine Praxisverwaltungssoftware, der ISYNET der Firma MCS. Fertig installiert ist es nun seit Anfang Juni, also 2 Monate später. Die dabei durchgemachte Lernkurve halte ich für außerordentlich bemerkenswert.
Aber der Reihe nach.
Zunächst einmal bat ich meinen lokalen Servicepartner um einen Termin zur Installation des Gerätes, wobei sich heraus stellte, dass eine Anleitung zur Einbindung dieses Gerätes zunächst gar nicht existierte. Wochen später erschien dann ein Techniker und tauschte schlicht das alte gegen das neue Lesegerät aus (ich berichtete) und überprüfte das Lesegerät mit Hilfe einer alten KVK („sehen Sie, es geht, das haben wir bisher immer so gemacht“). Es wurden keinerlei Treiber installiert, nur schlicht das alte gegen das neue Gerät ausgetauscht. Meinen Einwurf, da hätte ich aber von dem Hersteller des Lesegerätes etwas anderes gehört, wurde erst geglaubt, als ich bei MCS direkt anrief und erfuhr, es gäbe sehr wohl eine Einbindungsanleitung. Das ist deswegen bemerkenswert, weil die Firma MCS gar keine direkten Kundenkontakte unterhält, also mit den Ärzten in der Praxis vor Ort nur über ihre Servicepartner Kontakt hält. In meinem Fall jedoch wurde sehr rasch der Servicepartner informiert und mehrere Wochen später ein weiterer Installationstermin vereinbart. Die Kosten für den Installationsversuch wurden mir erlassen.
Nun erschien der Techniker 2 Wochen später mit einer vermeintlich aktuellen, ca. 2 Wochen alten Anleitung zur Einbindung des Lesegerätes. Bei nun folgenden kostenpflichtig abzuarbeitenden Lernkurve schließlich stellte sich heraus, dass die Installations– bzw. Einbindungsanleitung auf einer älteren Treiberversion beruhte, bzw diese voraussetzte. Erst nach Installation eines aktuellen ISYNET Updates von Anfang Juni, das ich erst einige Tage zuvor bekommen hatte und einer dann neu besorgten (in der Eile an meine E-Mail verschickte) aktuelleren Einbindungsanleitung, die den Stand 2.6.09 hatte, gelang dann eine problemlose Installation und Einbindung des Lesegerätes.

Um das Gerät testen zu können habe ich mir eigens zuvor auf dem kleinen (um nicht zu sagen sehr kleinen) Dienstweg eGK Testkarten besorgt, also elektronische Gesundheitskarten mit „fake Daten“ zu Testzwecken, um überhaupt sicher sagen zu können, dass nun Lesegerät,  PVS System und eGK  problemlos zusammenarbeiten. Denn elektronische Gesundheitskarten sind noch nicht in Gebrauch und ich wollte nicht erst am 1.10 (ich berichtete) feststellen, dass es mit den neuen Gesundheitskarten in der Praxis ein Problem gibt, weil das Gerät möglicherweise falsch installiert ist.

Die Testkarten konnten aber anstandslos gelesen werden, alles klappte prima. Das Gerät war nun endlich korrekt installiert.

In der Summe aber bleiben einige Dinge bemerkenswert:

1. Das Hypercom Gerät ist 2 Monate nach dem Erscheinen nun in die MCS-ISYNET eingebunden und funktioniert problemlos mit den alten und neuen Karten. Einzige Auffälligkeit bei allen von mir getesteten Geräten ist, dass der Einlesevorgang etwas länger dauert als mit der alten Karte. Daran wird man sich aber gewöhnen. Ansonsten ändert sich im Praxisalltag nichts.
2. Die Idee, in Zukunft nur eigens zertifizierte und geschulte Techniker für die in der Onlinephase sehr viel komplexere Hardware und deren Installation zuzulassen, kann ich nur voll unterstützen (ich berichtete).
3. Bei schlichtem Austausch „alt gegen neu“ ohne korrekte Installation können die neuen Lesegeräte die alte KVK (Krankenversicherungskarte) lesen, nicht jedoch die neue Gesundheitskarte. Dies habe ich mit den Testkarten ausprobiert! Das könnte manchen Arzt zu der Annahme verführen, ihr Gerät sei korrekt installiert, da eGK Testkarten nicht zur Verfügung stehen, um die korrekte Installation nachzuweisen.
4. eGK Testkarten stehen nur den Geräteherstellern und den Softwareprogrammierern zur Verfügung, jedoch nicht den Ärzten und den Servicepartnern vor Ort. Dies wird mit den Kosten der Karten begründet, die sich auf 40€ pro Stück belaufen. Nach Informationen, die ich von der gematik erhielt, war ursprünglich vorgesehen, den Geräten je eine Testkarte beizufügen, die damit einhergehenden zusätzlichen Kosten wollten aber weder die Hersteller, noch die KV und schon gar nicht die Kassen tragen, so dass dies unterblieb. Daher gibt es bis zur Auslieferung der ersten echten eGKs keine Möglichkeit, sein neues Lesegerät unter realen Bedingungen zu testen. Auch die Krankenkassen sind aktuell nicht in der Lage Testkarten zu liefern, dürfen dies wohl auch offiziell nicht.
5. Die abschließend gültige und funktionsfähige Einbindungsanleitung für das Hypercom Gerät, das ich Anfang April bekam, stammt von Anfang Juni und setzte auch ein ISYNET Update von Anfang Juni voraus. Die zuvor kursierende Anleitung basierte auf einem älteren Software /Treiberstand der Firma Hypercom. Das bedeutet eine Wartezeit von vollen 2 Monaten, bis eine Installationsanleitung den Weg Hypercom-MCS-Servicepartner vor Ort erfolgreich durchlaufen hat. Selbst wenn der Techniker gleich zu Anfang mit der seinerzeit gültigen Anleitung aufgetaucht wäre, wäre die Installation nach der bis dahin gültigen Anleitung nicht erfolgreich gewesen.
6. Die Firma MCS hat seit einiger Zeit die Angewohnheit, die monatlich zu zahlende Servicepauschale nicht nach der Anzahl der Installation, sondern nach Zahl der Klienten zu bemessen. Da wir eine Praxisgemeinschaft von zwei Ärzten haben (mit einer ISYNET Installation, zwei eingerichtete unabhängige Klienten) zahlen wir also die doppelte Pauschale!  Aus diesem Grunde ist die Verärgerung  bzw. Frustrationsbereitschaft hier natürlich besonders groß. Wenn ich alles richtig sehe,  zahle ich im Moment 542€/Quartal für den Service von MCS (letzte Abbuchung).
7. Es ist davon auszugehen, dass eine unbekannte Anzahl von Kartenlesegeräten unerkannt falsch installiert wurde und dies bis zum Auftauchen der ersten eGKs unbemerkt bleibt. Dies wird der Arzt vor Ort im ersten Reflex fälschlicherweise den Geräteherstellern anlasten, die zumindest in meinem Falle aber gänzlich unschuldig gewesen wären.
8. Ich halte es für unabdingbar, dass die Servicepartener vor Ort mit einer genügenden Anzahl Testkarten ausgestattet werden um die erfolgreiche Installation im Einzelfall vor Ort testen zu können.
9. Um die Sache vollständig kompliziert zu machen, existieren Testkarten in zumindest zwei verschiedenen Revisionen, die technisch unterschiedlich sind. Das Hypercom Lesegerät, das nun bei mir eingerichtet ist, kann aber beide Revisionen  lesen (von mir gestestet!). Dies düfte auch bei den anderen Geräten der Fall sein

Nachtrag vom 15.6.:

Ich erhielt heute eine E-mail der Firma MCS in der es u.a. hiess:

Das bundesweit alle Servicepartner die neusten eGK-Testkarten erhalten, finden auch wir für absolut notwendig.
Leider scheitert diese ja bekanntlich an den Kosten.

Die MCS Arzt- und Ambulanzsysteme steht mit insgesamt fünf eigenen Geschäftsstellen in direktem Kundenkontakt, so dass wir selbst auch einen regen Austausch mit unseren Anwendern pflegen.

Die Softwarepflege-Gebühr für Ihre Praxis beträgt für den ersten Arzt 78,00 EUR und für den zweite(n) Arzt/Ärztin die Hälfte = 39,00 EUR plus 35,00 EUR Gebührenerhöhung für die AVWG-zertifizierte Version von MCS-ISYNET incl. der Medikamentendatenbank.

Ich ergänze den Bericht insoweit. Die genannten Summen addieren sich pro Monat und zzgl. Mwst exakt auf den im Artikel genannten Betrag.