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.

Advertisements

Hardware…. Hardware… ein Bericht aus dem Nähkästchen


Die Arbeit an der Computerhardware der Praxis geht in die nächsten Runden. Unser Praxisserver hat nun nach KV-Vorschrift einen neuen Router bekommen (als Ersatz für den Telekom-Router ins Internet) mit „Black-Box-Hochsicherheitseinstellung“, eine Hardwarefirewall.  Dazu dann einen Netzwerk Virusschutz von GData, der nicht nur den Server,sondern auch alle Arbeitsplätze simultan überprüft.
Somit ist der Server selbst nun erstmals direkt mit dem Internet verbunden (Der KV Safenet Router stellt keine offene Internetverbindung her).
Soweit, so gut.
Am gleichen Tag fand dann eine Online Schulung für eine neue DMP Software statt.  Es geht um ein bislang extern geführtes DMP Programm, dessen Funktionalität nun intern in der Praxissoftware verwaltet werden soll.
Diese neue Funktionalität wird nun ganz anders als bisher verwaltet, zwar moderner und sicherlich von der Idee her besser, aber dazu sind weitreichende Änderungen an der Datenbank notwendig. Im Prinzip muss aus 2 Datenbanken eine gemacht werden.

Nun war es aber so, dass durch die Internet-Router Anbindung der Server sofort anfing, das alte Betriebssystem, das ja seit Jahren das Internet nicht gesehen hatte und daher nie aktualisiert wurde, upzudaten. Dazu war aber auf der C-Partition nicht genug Festplatte frei, was nicht sofort auffiel. Jedenfalls scheiterte das Updaten von >150 Sicherheitsupdates gleichzeitig, so dass der Server beim Neubooten nicht sauber hochfuhr. Ein Staatsdrama, wie man sich vorstellen kann. Beim zweiten Versuch aber ging es dann. In einer weiteren Fernwartungssitzung schließlich wurde die Windows Auslagerungsdatei verschoben und mehr als 3 Gbyte Temporäre Dateien (die interessanterweise bei der Datenträgerbereiigung gar nicht angeboten werden) gelöscht,  so dass schließlich ausreichend Platz da war.
Bezogen auf die Datenbanken hatten sich die Leute von medatixx Testdaten besorgt, um damit die Anpassung in Ruhe „offline“ auszuprobieren.  Dabei waren, wie ich hörte, mehrere Anläufe notwendig, jedenfalls war die Anpassung eigentlich für gestern per Fernwartung terminiert, wurde dann aber verschoben, weil die Software dazu unzählige Stunden brauchte, in der man nicht arbeiten kann. So bleibt nur, nach Praxisschluß den Vorgang zu starten, es wird erst eine Sicherung angefertigt (etwa 4-5 Gbyte, 2 Datenbanken) dann die Anpassung gestartet, was bis heute Abend dauern kann.

Über die neue DMP Funktionalität von ISYNET werde ich dann eigens berichten.

Expertenanhörung zur Gesundheitskarte im Bundestag


Am Mittwoch, den 4. November fand im Deutschen Bundestag eine öffentliche Anhörung des Gesundheitsausschusses statt. Dabei beschäftigte man sich unter anderem mit den zuvor abgegebenen schriftlichen Stellungnahmen der Verbände zum geplanten Gesetz.

Es wurde unter anderem deutlich, dass Daten aus den Testgebieten zum Ende April 2016 noch nicht vorliegen werden, weil die Industrie aktuell die Komponenten nicht rechtzeitig liefern kann. In dem Zusammenhang sind offenbar Sanktionen für die Gesellschafter der gematik vorgestehen, die von den Verbänden aber mit Hinweis auf die Industrie abgelehnt werden.

Als erster „Mehrwertdienst“ ist der Notfalldatensatz (NFD) vorgesehen  über dessen Praktikabilität angesichts einer Planung aus dem Jahr 2006 diskutiert wurde. So seien damals z.B. noch keine USB Sticks verfügbar gewesen, so dass die Planungen darauf keine Rücksicht hätten nehmen können.

So wurde darauf hingewiesen, dass die Zeitläufe technisch gesehen über das Projekt hinweg gegangen sind. Vorgesehene Schnittstellen zum Patienten (z.B. ein Kiosk um Daten einzusehen) seien mitlerweile lebensfremd.

Ziel des Gesetzentwurfes ist es vor allem, die Teilnehmer am Gesundheitswesen besser miteinander zu verbinden. Es wurde beklagt, dass mit dem KV Safenet bereits Paralellstrukturen existieren, die nicht den hohen Anforderungen des BSI unterliegen, im Gegensatz zu den Komponenten der zentralen Telematik Infrastruktur der gematik.

Quelle:

Bundestag.de

Heise

schriftliche Stellungmahmen der Verbände

Deutsches Ärzteblatt

Alexander Beyer bleibt Geschäftsführer der gematik


Ende Juni 2015 hatte Prof. Arno Elmer sein Amt als Geschäftsführer der gematik niedergelegt, seither war Alexander Beyer kommissarisch zum Leiter bestimmt worden.

In einer Pressemitteilung der gematik wurde nun mitgeteilt, dass Herr Beyer nun dauerhaft zum Geschäftsführer ernannt wurde:

Wir freuen uns sehr, dass Herr Beyer nun auch dauerhaft die Geschäftsführung der gematik übernimmt. Mit ihm haben wir einen kompetenten Partner gewonnen, dessen umfassendes Know-how und langjährigen Erfahrungen für die Kontinuität sorgen werden, die nötig ist, um dieses herausfordernde Projekt meistern zu können“, so Dr. Thomas Kriedel (KV Westfalen-Lippe), Vorsitzender der Gesellschafterversammlung der gematik.

Quelle

Herr Beyer war zuvor Leiter der Rechtsabteilung der gematik.

Migration von D2D zu KV Connect – Nachtrag


Wie ich bereits vor kurzem schrieb, verdichteten sich die Hinweise, dass die Migration von D2D zu KV-Connect bis Ende September 2016 möglich sein wird. Dies hat mir nun Herr Mohr von der KV-Telematik in einem Telefongespräch bestätigt. Er erwähnt auch, dies in einem Vortrag vor Vertretern der Systemhäuser im September dieses Jahres (2015) erklärt zu haben, aber offensichtlich wird das innerhalb der Hierarchie der Systemhäuser nicht bis in die Peripherie weitergegeben. Zumindest hat mein lokaler Vertrieb ganz offenbar nichts davon gewusst.

Das interne Praxisnetz und ein neues Handy – oder was ein Handy so alles anrichten kann


Wir haben in der Praxis ein Netz von sechs Rechnern an einem Netzwerk mit Windows Terminal Server (WTS). Der Server selbst ist vom Internet getrennt, aber im Netz hängt ein Telekom DSL Router neuerer Bauart mit gesichertem Wlan. Und an dem Wlan seit Jahr und Tag 2 Android-Handys und ein iPad, um ins Internet zu gelangen.

Ein defektes Handy musste ausgetauscht werden, und damit begann ein Problem, das den ganzen Tag in Anspruch genommen hatte.

Zunächst war es morgens unmöglich mit einem der  Rechner ins interne Netz zu kommen, mögliche Probleme wie frisch geupdateter lokaler Virenchecker mit neuer Firewall und Kabelprobleme wurden rasch ausgeschlossen. Es half nichts, ein Hardwareproblem schien nicht ausgeschlossen. Nach langer Suche zusammen mit einem hinzugezogenen Techniker fand sich schließlich die Ursache: ein „fremder Rechner“ hatte sich über Wlan ins Netz eingeloggt und per Zufall eine Netzwerkadresse bezogen, die für einen der lokalen Rechner bereits vergeben war. Der Adressenkonfikt war die Ursache. Anhand der Mac-Adressen wurden die beiden „Androiden“ und das iPad für unschuldig erklärt, der „fremde Rechner“ war zunächst nicht aufzufinden.

Bis die Kollegin am nächsten morgen mit einem frisch ausgetauschtem Handy (und eingerichtetem Wlan….) in der Praxis auftauchte und der Vorgang sich wiederholte, diesmal mit einem anderen Rechner. Ein Blick auf die Wlan Einstellung des neuen Handys bestätigte den Andressenkonflikt: es war tatsächlich eine bereits vergebene IP Adresse, identisch mit dem Rechner, der nun nicht mehr ins Netz wollte. Abschalten des Handys identifizierte den „Täter“ nun endgültig. Der Vorgang lies sich beliebig reproduzieren. Interessanterweise half auch das Löschen der Wlan Einstellung im Handy und Neueinrichtung nichts: es besteht darauf, eine bereits bezogenen IP Adresse zu bekommen.

Ich werde das Wlan abschalten ….

D2D Migration für DMP verlängert bis 30.9.2016


Ich hatte in meiner Artikelserie über KV-Connect bereits darauf hingewiesen: aktuell ist es technisch auf Seiten der Betreiber nicht möglich DMP Daten via KV-Connect zu verschicken. Wie man hier (D2D Migration, pdf Datei, Vortrag von Gilbert Mohr von der KV-Telematik) erfahren kann, wird das Ende von „DMP via D2D“ auf Ende des 3. Quartals 2016 verlängert.

Somit haben die Betreiber mehr Zeit für die Einrichtung  von KV-Connect und der anwendende Arzt hat weiterhin die Möglichkeit, die Daten wie bisher zu übertragen. Ich werde berichten, wenn ich weitere Details erfahre.