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.

Erlebnisse mit der Signatursoftware

Ärztliche Kollegen wissen, dass zumindest in Nordrhein seit längerem die Möglichkeit existiert und gezielt gefördert wird, die KV Abrechnung online zu verschicken. Dabei gab und gibt es aus grundsätzlichen Erwägungen heraus immer noch die so genannte Gesamtaufstellung, die in der Vergangenheit manuell zu unterschreiben war und per Post verschickt wurde.

Seit einiger Zeit schon gibt es nun die Möglichkeit, diese Aufstellung  elektronisch zu erstellen und elektronisch zu signieren.

In Nordrhein wird wie in den meisten anderen KVen auch dazu der elektronische Arztausweis ausgegeben (gelegentlich auch als HBA – Heilberufeausweis bezeichnet), der zur elektronischen Signatur erforderlich ist. Zusätzlich wird speziell in Nordrhein eine Signatursoftware von OPENLIMIT eingesetzt.

Und genau um die soll es hier gehen.

Seit langem schon ärgere ich mich  – wie viele meiner Kollegen auch –  mit dieser Software herum. Anlass bei mir war nun eine notwendig gewordenen Server Neuinstallation in der Praxis, die eine erneute Installation unter anderem auch dieser Software notwendig machte.

Wer sich den Installationsgang einmal ansehen möchte, findet bei GMC Systems eine schöne Anleitung hierzu.

Wie mein betreuendes Softwarehaus mir mitteilte, bin ich mit dem Ärger nicht alleine. Fast jeder Arzt, der diese Software einsetzt, kennt die Ungewissheit bei der Abrechnung, ob die Signatur nun funktioniert oder nicht. So wird der Arztausweis sehr oft von der Software nicht erkannt, oder es gibt gleich eine Fehlermeldung.

Nach langem herum telefonieren  meine ich nun herausbekommen zu haben, worin das Problem besteht: die verteilte Software war und ist NICHT serverfähig, vor allem nicht für Windows terminal Server (WTS 2003 und höher).

Das sagt einem aber niemand.

Es kommt noch besser: Bestellt man die neueste Version dieser Software, was man in Nordrhein bei medisign tun muss, so bekommt man eine WTS fähige Variante nur auf spezielle Anforderung, das heisst auf dem Bestellformular muss dieses händisch vermerkt werden (Mitteilung des telefonischen Supports von medisign). Der gewöhnliche obrigkeitshörige Arzt aber macht hier allenfalls seine Kreuze und schickt das FAX zur Bestellung ab – und bekommt wieder keine lauffähige Software für seinen Server.

Versucht man etwas neutral zu bleiben muss man sagen, dass (offenbar….) eine unter WTS  2008 lauffähige Variante existiert, aber schlicht niemand für die Kommunikation mit den Ärzten zuständig ist. Ich finde es ausserordentlich naiv vom Hersteller, eine unter den gebräuchlichen Servervarianten einer Arztpraxis nicht lauffähige Version zu verteilen und dann auch noch es dem Arzt zu überlassen sich eine lauffähige Vartiante (dann natürlich für Extrakosten) zu besorgen, ohne ihn darüber zu informieren.

Und niemand informiert ihn. Auch die Servicepartner der PVS Hersteller vor Ort wissen nichts von dieser Servervariante der Software, wenn ich nicht 15 Stellen abtelefoniert hätte, wüsste auch ich es bis heute nicht.

Man kann davon ausgehen, dass zahllose Ärzte zumindest in Nordrhein aktuell für die Signatur eine aktuell für Ihre Hardware nicht taugliche Signatursoftware einsetzen ohne dies zu wissen da die seinerzeit ausgelieferte Software NICHT SERVERFÄHIG ist.

Ich nun habe die angeblich taugliche Software bei medisign bestellt und werde nach deren Installation hier erneut berichten.

Quellen:

GMC Software

medisign

ältere Artikel zum Thema

Verschlüsselung von Dateien mit dem elektronischen Arztausweis – Hinweise zur Openlimit Software

Mittlerweile ist zumindest in Nordrhein der elektronische Arztausweis weitgehend verfügbar. Ich hatte über das Antragsverfahren und erste Erfahrungen mit dem elektronischen Arztausweis bereits vor längerer Zeit berichtet. Hier noch einmal eine Übersicht der wesentlichen Berichte:

Details zum neuen Arztausweis

Der neue Heilberufeausweis ist angekommen – 4 Monate nach dem Antrag

Das Antragsverfahren zum neuen Arztausweis – ein Erfahrungsbericht

Nachtrag zum Artikel über das Antragsverfahren zum neuen Arztausweis

Der elektronische Heilberufeausweis macht’s möglich: Online-Abrechnung digital signiert

Mit dem elektronischen Arztausweis erhielt man in Nordrhein auf Wunsch auch ein kleines Kartenlesegerät (nicht zu verwechseln mit einem eGK Lesegerät!) und eine Signatursoftware Openlimit SignCubes. Diese wird zur Signatur und /oder Verschlüsselung von Dateien verwendet. Unter anderem kann man in Nordrhein damit bereits als Kassenarzt seine Abrechnung elektronisch signieren.

Im folgenden möchte ich mich mit der Verschlüsselung (also nicht Signatur!) von Dateien mit der erwähnten Ausstattung, also Openlimit Software, Kartenlesegerät und Arztausweis, beschäftigen. Im Grundsatz werden für die Verschlüsselung zwei Schlüssel gebraucht, ein öffentlicher und ein privater, letzterer ist auf dem Ausweis selbst untergebracht. ein Beispiel: Dr. A will Dr. B einen verschlüsselten Arztbrief schicken. Dazu benötigt er dessen öffentlichen Schlüssel (aus einem Verzeichnis), verschlüsselt die Datei mit Hilfe dieses Schlüssels und der Signatursoftware Openlimit signCubes und verschickt die Datei an den Kollegen Dr. B.   Die Datei ist nun so verschlüsselt, dass sie nur vom Kollegen B mit Hilfe des privaten Schlüssels (auf dessen Arztausweis) entschlüsselt werden kann.

Ich habe erste Erfahrungen mit genau diesem Vorgang gemacht und konnte eine Datei verschlüsselt mit einem Kollegen austauschen. Zunächst benötigt man für den Verschlüsselungsvorgang den öffentlichen Schlüssel des Kollegen. Den kann man jedesmal nachschlagen (Hinweise hierzu am Ende des Artikels) oder aber man läßt die Software „automatisch“ in einem Verzeichnisdienst nachschlagen. Dazu müssen aber einige Einstellungen gemacht werden. Den entsprechenden Vorgang möchte ich unter Windows XP hier schildern.

1. Verschlüsselung einer Datei mit der  Openlimit Software

Man geht wie folgt vor: Rechtsklick auf die zu verschlüsselnde Datei aus dem Windows  Explorer, Menueauswahl „Openlimit Sign Cubes“, dann „Datei verschlüsseln“, es öffnet sich ein Fenster zur Auswahl des Zertifikates. Bereits installierte Zertifikate sind links im Fenster dargestellt, neue erhält man entweder  indem man über die Schaltfläche „aus Datei“ die Zertifikatsdatei auswählt, die man zuvor manuell geladen hat oder aber man wählt die Schaltfläche „weitere“ und kommt an den Verzeichnisdienst:

Bild 1: Auswahl des Zertifikates, für das verschlüsselt werden soll

Bild 2: Der Verzeichnis client

Genau hierum geht es im folgenden. Dort vermisst man leider in der normalen, d.h. nicht angepassten Version der Software das Verzeichnis von medisign für die öffentlichen Zertifikate der Schlüssel. Die Verzeichnisse müssen manuell eingetragen werden. Dazu ist eine Anpassung notwendig.

2. Anpassung des OPENLIMIT Signcubes Verzeichnis-clients

Dazu fügt man  in der Datei siqLDAP.ini (C:\Programme\OPENLiMiT) die nachfolgend aufgelisteten drei Einträge hinzu (nachdem man sich eine Sicherheitskopie dieser Datei irgendwohin gespeichert hat!)

——————————————————
[DGN Service/Medisign 2103]
Server=ldap.medisign.de
SearchBase=ou=Mandant2103,o=ENC,c=de
Port=389

[DGN Service/Medisign 2104]
Server=ldap.medisign.de
SearchBase=ou=Mandant2104,o=ENC,c=de
Port=389

[DGN Service/Medisign 2116]
Server=ldap.medisign.de
SearchBase=ou=Mandant2116,o=ENC,c=de
Port=389
——————————————————

Startet man nun den Verschlüsselungsvorgang wie oben beschrieben, so hat man drei neue Servereinträge, die man zur Auswahl des Namens der Reihe nach durchprobiert.

3. Hinweise zur Namenssuche im Verzeichnis-client

Gesucht werden kann nur nach Namen, nicht aber nach Email-Adressen.  Dabei gelten einige Regeln:

Über ‚Start‘ wird der Suchvorgang aktiviert. Mit * setzt man einen Platzhalter.

Suchvarianten:

mei*  –  alle, deren Nachname mit „mei“ beginnt

*mei*  –  alle, deren Nachname oder Vorname „mei“ beinhaltet

meier* – alle, deren Nachname mit „meier“ beginnt.

Die  selektierten Zertifikate werden dann direkt zum Verschlüsseln benutzen und lokal installiert. Man klickt auf ‚Übernehmen‘, ‚Installieren‘ und dann auf ‚Fertig stellen‘.

Die aufgeführte Erweiterung der INI Datei wurde auf meine Anfrage ausdrücklich vom Support von Openlimit empfohlen und frei gegeben. Auf meinem Rechner funktioniert es einwandfrei, wenn man in der Suchmaske das Sternchen  wie oben erwähnt verwendet.

4. Hinweise zur manuellen Suche nach den öffentlichen Teilnehmerzertifikaten

Will man Openlimit SignCubes nicht wie oben dargestellt anpassen, muß man den Schlüssel des Kollegen, an den man die Datei verschicken will jedesmal neu suchen und die Schlüsseldatei in dem Verzeichnis client wie oben dargestellt auswählen. Durch Doppelklick auf die Schlüsseldatei ist der Schlüssel für zukünftige Verwendung dauerhaft installiert und findet sich im dem Verzeichnis-client nun im dem linken Fenster. (Siehe Bild 1).

Manuell findet man den Schlüssel für die von medisign ausgegebenen Karten hier. Für die Namenssuche gilt das oben gesagte, also Namen werden immer mit „Sternchen“ gesucht. In dem folgenden Fenster kann man das Zertifikat anklicken und danach im DER Format laden. Seltsamerweise gelingt dies ohne Probleme nur mit dem Internet Explorer, nicht mit firefox, das mit einer Fehlermeldung abbricht. Die so geladene Datei muß nun wie oben aufgeführt ausgewählt werden.

Zuletzt erhält man die verschlüsselte Datei die man nun an den Kollegen verschicken kann. Nur er kann nun die Datei entschlüsseln, da nur er den privaten Schlüssel hierzu hat. Im Augenblick muß man die Datei wohl noch per E-Mail verschicken, in Zukunft erfolgt dies in dem geschlossenen System des online rollouts der eGK. Die Verschlüsselung wird dann überwiegend im Hintergrund erfolgen.

Der Vorgang des Entschlüsselns ist dem gegenüber einfacher. Hierüber werde ich in einem weiteren Artiel berichten.

Quellen und Infos:

Seite der ÄkNo zum Arztausweis

Öffentliche Teilnehmer Zertifikate  von Medisign

Hamburger Ärztekammer gibt elektronischen Arztausweis aus

Die Hamburger Ärztekammer hat laut „Arzt am Abend“ damit begonnen, elektronische Arztausweise auszugeben, allerdings im Moment vorwiegend an Ärzte, die im Auftrag der Behörde für Soziales, Gesundheit, Familie und Verbraucherschutz Gutachten nach dem Schwerbehindertenrecht erstellen. Damit sollen sich die Ärzte gegenüber dem Internetportal GovernmentGateway sicher ausweisen. „Wir haben das Projekt von Anfang an sehr unterstützt, weil wir darin neben dem inhaltlichen Erfordernis auch die Chance sahen, uns für einen zunächst überschaubaren Kreis von Kollegen mit dem Procedere vertraut zu machen, welches mit der Herausgabe von elektronischen Arztausweisen verbunden ist“, erklärte Kammerpräsident Dr. Frank Ulrich Montgomery. Wenn der Startschuss für diese falle, sei dieKammer dann „bestens vorbereitet“.

Auch Microsoft entwickelt ein GovernmentGateway, dabei scheint es sich um eine „Microsoft-Lösungen für die integrierte Verwaltung“ zu handeln. Auch weitere Firmen entwickeln ähnliche Lösungen.

Vortrag fey mit GovernmentGateway Vorstellung

GovernmentGateway Vortrag

Hamburg-Service online Dienste

Praxisdaten speichern: einmal signiert und abgelegt reicht nicht aus

unter diesem Titel ist in der aktuellen Printausgabe von „ArztOnline“ ein interessanter Bericht zum Thema Datensicherheit erschienen. Er wird hier auszugsweise zitiert.

Arztpraxen sollen und wollen vielfach weg vom Papier. Doch dabei ergibt sich für Ärzte ein Problem: Sie müssen Patientendaten, Röntgenbilder etc. zehn oder gar 30 Jahre aufbewahren – und zwar beweissicher. Technisch ist das durchaus möglich, mit der digitalen Signatur. Doch auch dabei gibt es einiges zu beachten.

Aus der schlichten Empfehlung zur Datensicherung ist ein Maßnahmenbündel geworden. Denn längst genügt es nicht mehr, die elektronische Patientendokumentation auf einem anderen Datenträger zu speichern. Die Speicherung muss beweiskräftig sicher in der Weise sein, dass ein Patientendokument nicht etwa nachträglich geändert werden kann.

Hier kommt die digitale Signatur ins Spiel. Der Arzt unterschreibt ein Dokument elektronisch, dazu wird ein „Hash-Wert“ gespeichert, ehe die Akte in das digitale Archiv wandern kann. Dabei ist der Hash-Wert eine Art technischer Fingerabdruck, da er eine nahezu eindeutige Kennzeichnung einer größeren Datenmenge in Form von Zahlen darstellt. Schon die kleinste Dokumentenänderung wie das Löschen eines Kommas führt dazu, dass dieser „Hash-Wert“ sich verändert.

Auch eingescannte Papier-Dokumente wie die Arztpost oder Gutachten von stationären Aufenthalten fallen unter diese Signatur-Regel. Ist der Prozess des Einscannens und der Archivierung protokolliert, können sie sogar vernichtet werden – eine Aufbewahrungspflicht von Papier gibt es nicht mehr.

In dieser Zeitspanne kann es durchaus passieren, dass die Verfahren veralten, die bei der Signatur und bei der Ermittlung von Hash-Werten eingesetzt werden. Entweder sind dabei die kryptografischen Algorithmen „gebrochen“ worden, oder die wachsende Rechnerleistung lässt es zu, dass eine Signatur aufgeschlüsselt werden kann.

In beiden Fällen müssen neue Signaturen zum Einsatz kommen. Noch sind die Signaturen, die seit etwa 1998 im Einsatz sind, nicht akut gefährdet. Dafür sind – zunächst für den Archivierungsbedarf von Krankenhäusern – Verfahren entwickelt worden, die die Sicherheit des Archivs garantieren sollen.

Das entsprechende Konzept heißt Übersignatur: Alle langfristig zu archivierenden Dokumente werden mit einer Signatur versehen, die den neuesten kryptografischen Anforderungen entspricht. Dabei werden nicht einzelne Dokumente, sondern ganze „Dokumentencontainer“ übersigniert, die unter Umständen ergänzende Befundungen enthalten, die nicht in die Originaldatei eingefügt werden dürfen, sobald diese signiert ist.

Von der signierten fälschungssicheren Speicherung im elektronischen Archiv muss die Verschlüsselung der Patientendaten unterschieden werden, die vor unberechtigtem Daten-Zugriff schützen soll. Nach dem aktuellen Leitfaden ist sie nur dann zwingend erforderlich, wenn der Dokumentationscomputer als Praxiscomputer am Internet angeschlossen ist, also die Gefahr besteht, dass ein Angriff aus dem Internet die Daten kompromittiert.

Nachtrag aus meiner Sicht: wie bekannt dient der neue Arztausweis auch und vor allem als Signaturkarte. Der Artikel unterstreicht aus meiner Sicht die Notwendigkeit der digitalen Signatur und des Arztausweises.

Quelle (erfordert Anmeldung)

verwandte Artikel:

Arztausweis

Gematik: Sicherheitsmechanismen bei Root-Zertifikaten wirksam

Mittlerweile existiert eine Stellungnahme der Gematik zu dem Heiseartikel über das Root-CA Problem. Hierzu heißt es:

Aufgrund eines Hardwarefehlers in dem dedizierten Hochsicherheitsmodul (HSM) der Test-Root–CVC-CA ist das Schlüsselmaterial der Test-Root–CVC-CA gelöscht worden. Diese Test-Root wird ausschließlich im Zusammenhang mit Musterkarten verwendet. Das Modul wird von einem Zertifizierungsdienst im Auftrag der gematik betrieben. Der Datenfehler betrifft Daten die benötigt werden, damit sich Gesundheitskarten und Heilberufsausweise gegenseitig als „gültig“ erkennen können.

• Die durch die betroffenen TEST-Sub–CVC–CAs ausgestellten Zertifikate werden ausschließlich von sog. eGK-Musterkarten verwendet, die u.a. zu Funktions- und Integrationstests in den Projektbüros der Testumgebungen eingesetzt werden. Sie enthalten lediglich fiktive Daten von fiktiven Versicherten. Es handelt sich dabei um höchstens 1.000 Karten. Diese Karten müssen nun ersetzt werden, weil ihre „Echtheit“ im Testverfahren nicht mehr bestätigt werden kann. Eine sichere Authentifizierung ist mit diesen Karten daher nicht mehr möglich.Die Musterkarten sind zu unterscheiden von den ca. 60.000 eGK in den 7 Testregionen (Produktiv-Karten), die bereits echte Daten von echten Versicherten, die am Test teilnehmen, enthalten. Die eGKs in den Testregionen wurden von produktiven Sub–CVC–CAs bestätigt, die wiederum von der produktiven Root–CVC-CA bestätigt sind. Die produktive Root–CVC-CA ist nicht betroffen.
• Es hat zu keiner Zeit ein Datenschutzproblem bestanden. Es könnten lediglich die bereits ausgestellten Musterkarten nicht mit neu produzierten Musterkarten zusammenarbeiten. Auch die fiktiven Testdaten konnten zu keinem Zeitpunkt von unberechtigten Dritten eingesehen werden.
• Der Vorfall hat gezeigt, dass die geplanten Sicherheitsmechanismen voll greifen. Das Hochsicherheitsmodul (HSM) hat den Hardwaredefekt als Angriffsversuch interpretiert und entsprechend der Spezifikation das zu schützende Schüsselmaterial sicher, nicht reproduzierbar und vollständig zerstört.
• Aufgrund der höheren Kartenanzahl und der Tatsache, dass echte Versicherte, mit echten Karten am Feldtest teilnehmen, hat der Zertifizierungsdienst für die produktiv CVC-CA weitere, voneinander unabhängige HSMs im Einsatz, die Kopien des Schlüsselmaterials enthalten, so dass der Verlust eines HSMs nicht automatisch zum Verlust des Schlüsselmaterials führt.

Offenbar ist für das Testsystem ein Backupverfahren nicht nötig gewesen:

Bis zu ca. 1000 Musterkarten müssen ersetzt werden. Ein gesondertes Backup-Verfahren für die Musterkarten wäre teurer als der Ersatz der Karten.

Echtdaten für „richtige“ eGKs waren nicht betroffen. Offenbar war der Aufbau eines Sicherheitssystems mit allem drum und dran inkl. Backup für die wenigen intern benutzten Testkarten, die ja in den Testregionen schlicht nicht benutzt werden, gar nicht vorgesehen. Die „Echtkarten“ in den Testregionen dagegen werden mit einem wesentlich aufwendigerem System geschützt, dessen Aufbau für die wenigen Testkarten schlicht zu teuer gewesen wäre. Nach meinem Verständnis wird die Firma, die für die gematik die Dienstleistung der Root-CA erbringt, auch von ihr selbst bezahlt. Die Dienstleistung des backups wäre wohl teurer gekommen, als der schlicht Ersatz der wenigen Testkarten. In einem Echtkarteneinsatz in der Onlinephase werden andere Mechanismen greifen.

Datenverlust bei D-Trust führt zu möglichen Problemen mit eGK Testkarten

Für den Betrieb der eGK wird eine Public–Key–Infrastruktur aufgebaut. Wie bekannt handelt es sich dabei um ein asymmetrisches Krypotsystem. Laut Wikipedia wird dies so definiert:

Ein asymmetrisches Kryptosystem ist ein Kryptosystem, bei dem jede der kommunizierenden Parteien ein Schlüsselpaar besitzt, das aus einem geheimen Teil (privater Schlüssel) und einem nicht geheimen Teil (öffentlicher Schlüssel) besteht. Der öffentliche Schlüssel ermöglicht es jedermann, Daten für den Inhaber des privaten Schlüssels zu verschlüsseln, dessen digitale Signaturen zu prüfen oder ihn zu authentifizieren. Der private Schlüssel ermöglicht es seinem Inhaber, mit dem öffentlichen Schlüssel verschlüsselte Daten zu entschlüsseln, digitale Signaturen zu erzeugen oder sich zu authentisieren.

Der Aufbau der Root-CA ist ein wichtiger Meilenstein bei der Einführung der eGK in Deutschland. Denn der  Grundgedanke für die Sicherheit des gesamten Systems ist, dass Patientenkarte und Arztausweis nicht unabhängig voneinander genutzt werden können. Will der Arzt beispielsweise auf die Daten einer eGK zugreifen, müssen beide Karten ausgelesen werden. Die Karten erkennen sich gegenseitig als echt an und erst anschließend können die Daten auf der eGK ausgelesen werden. Mit anderen Worten: Nur durch den Aufbau der Root-CA bei D-TRUST kann die Echtheit von Karten im Gesundheitswesen verifiziert werden.

Für den Betrieb der Public–Key–Infrastruktur der Gesundheitskarte hat sich die Projektgesellschaft Gematik entschieden, die Root-CA als Dienstleistung an die zur Bundesdruckerei gehörende Firma D-Trust zu vergeben. Dabei wird ein Hardware-Sicherheitsmodul verwendet, das die Schlüssel ausgehend von einer Root-CA (Root Certificate Authority) ausgibt, die letztlich dafür sorgt, dass alle ausgegebenen Schlüssel auf eGK und HBA sich gegenseitig als echt anerkennen.
In diesem Hardware-Sicherheitsmodul ist es zu einem Datenverlust gekommen, so dass nun eine neue Root-CA erzeugt werden muß. Damit erkennen sich zwar alle bisher ausgegebenen Karten weiterhin gegenseitíg als echt an, neue Karten müssten aber auf Grundlage einer neuen Root-CA produziert werden und diese neuen Karten würden die mit der alten Root-CA produzierten nicht erkennen.
In einem Rundschreiben der gematik, das Heise online vorliegt und dort zitiert wird, heisst es:

In der Konsequenz heißt dies, dass zu den derzeit im Umlauf befindlichen korrekten eGK-Musterkarten der Generation 1 insbesondere keine Muster-HBA der Generation 1 mehr produziert werden können, die mit den bereits existierenden eGKs eine erfolgreiche Card–to–Card–Authentifizierung durchführen können. Bitte beachten Sie daher, dass die für den nordrheinischen Interoperabilitätstest verteilten korrekten Muster-eGKs ausschließlich für Tests im Basis-Rollout-Szenario verwendet werden können und nach den Basis-Rollout-Tests zu vernichten sind. Obwohl die Muster-eGKs korrekt sind, müssen sie für Tests in künftigen Stufen der Telematik–Infrastruktur noch einmal ersetzt werden.

Heise meint dazu:
Das Hickhack um die Datensicherheit einer Root-CA, die eine relativ kleine Menge von Testkarten stützt, mag trivial erscheinen. Indessen überrascht, das ein zentraler Dienst, der auf alle Testkarten einer Generation ausstrahlt, so vernachlässigt wurde. Die Versicherung, dass beim echten System alles richtig gesichert wird, muss man erst einmal glauben – oder auch nicht. Ein System verteilter Root–CAs, wie sie vom Karlsruher Gesundheitskarten-Kritiker Thomas Maus vorgeschlagen wurde, könnte hier Abhilfe bringen.

Quelle: Heise Artikel

D-Trust

Details zum neuen Arztausweis

Wie ich berichtete, wurde mein neuer HBA 4 Monate nachdem ich ihn beantragt hatte  an mich ausgeliefert. Damit er aber benutzt werden kann,  müssen die Transport-PINs (es gibt eine Karten- und eine Signatur-PIN) geändert werden. Diese wurden in getrennter Post am Folgetag geliefert zusammen mit 2 eleganten Aludosen, eine für die Installations-CD mit allen PIN Codes und der Installationsanleitung, eine weitere mit dem KAAN SECOVID Reader III, den ich glücklicherweise seinerzeit mitbestellt hatte. Wozu dieser Reader notwendig ist wird nun klar: um die Karte freizuschalten, braucht man einen solchen Reader.  Wie ich in meinem seinerzeitigen Artikel schilderte, wurde dies damals nicht erklärt, so dass sicher manch einer das Lesegerät und die Software nicht gekauft haben und nun ihre Karte nicht freischalten können. Ich hatte mir den mobilen Reader „gegönnt“.

Nach Einlegen der Installations-CD muss man zunächst einen mitgelieferten Code eingeben, dann gelangt man in ein Übersichtsmenue. Zunächst wird das Kartenlesegerät installiert (sofern man es mitbestellt hatte…..) dann die Transport PINs geändert in  frei gewählte PINs, schließlich ggf. die mitbestellte OPENLIMIT Signcubes Signatursofteware installiert. Zuletzt kann man den Firefox-Browser um eine Signaturkomponente erweitern, der MS Internetexplorer braucht angeblich nicht erweitert zu werden.

Zuletzt erfolgte der Test der Karte mit der einzigen Funktion, die im Moment existiert: das Einloggen in die Ärztekammer Nordrhein Seite mit Hilfe des HBA. Dies ist die gleiche Seite, die man zum Antrag für den HBA hat aufrufen müssen, dort kann man nun mit Arztausweis einloggen und wird erstmalig zur Eingabe der neuen Karten PIN in den angeschlossenen Reader aufgefordert. Anschließend gelang ich problemlos auf die Ärztekammerhomepage und konnte beispielsweise meine Fortbildungspunkte einsehen.

Damit hat die Karte ihren ersten Test bestanden.

Die gesamte Installation kann übrigens problemlos auf mehreren Rechnern durchgeführt werden, z.B. zu Hause und in der Praxis. Nach telefonischer Auskunft von Medisign wird zur Freischaltung mehrerer HBAs in einer Gemeinschaftspraxis  oder Praxisgemeinschaft auch nur eine derartige Installation gebraucht, nicht etwa pro Karte eine weitere Installation, was wegen der Signatur denkbar gewesen wäre.

Verwandte Artikel:

Der neue Heilberufeausweis ist angekommen – 4 Monate nach dem Antrag

Probleme beim Förderprojekt “Online Abrechnung mit HBA”

Nachtrag zum Artikel über das Antragsverfahren zum neuen Arztausweis

Das Antragsverfahren zum neuen Arztausweis – ein Erfahrungsbericht

KOBIL SecOVID Reader III

OPENLiMiT® CC Sign 2.1.6.1

Ziel der elektronischen Gesundheitskarte ist der Aufbau einer Telematikinfrastruktur

Foto: Ein Konnektor stellt die Verbindung der Arztpraxis zur geschützten Netzwerkumgebung her.

Das Bild verdanke ich  Michael Brockt von der Concat AG

Wie ich bereits mehrfach in meinem blog betont hatte (1, 2, 3, u.a.) geht es bei der Einführung der elektronischen Gesundheitskarte im Wesentlichen um die Vorbereitungen zur Einführung einer zentralen, allgemein verbindlichen und sicheren Telematikinfrastruktur im deutschen Gesundheitswesen.
Ich möchte im folgenden ausführen, welche Vorteile daraus langfristig  für Krankenkassen, Ärzte und Patienten resultieren könnten.
Aus Sicht eines niedergelassenen Arztes, aber auch letztlich einer Klinik, ist die momentane Situation eines Arztes mit der eines Autofahrers vergleichbar, der ohne Tachometer fahren muss, aber eine maximale Geschwindigkeit einhalten sollte, die Fahrgeschwindigkeit aber erst 2 Kurven nach dem „Starenkasten“, also der Geschwindigkeitskontrolle angezeigt bekommt.  Will er einen genauen Wert sofort haben, wird die Geschwindigkeit extern gemessen und er muss diese Messung auch noch bezahlen.
Damit ist die Situation eines niedergelassenen Arztes sehr treffend beschrieben, der für Medikamentenausgaben haftbar ist, diese offiziell aber erst ein halbes Jahr nach der konkreten Veranlassung der Kosten mitgeteilt bekommt und aktuelle Werte nur kostenpflichtig von „Goldgräbern“, die es auf Kosten der Ärzte im Gesundheitswesen massenhaft gibt, mitgeteilt bekommt, sofern er denen seine Daten aushändigt.
Dass die Praxissoftware hier aktuelle Näherungswerte ausgeben kann ist keine Erleichterung, da diese zum einen nur grob sind, zum anderen auch nicht umsonst zu bekommen sind, immerhin lassen sich die Hersteller der PVS Systeme sich dies sehr teuer bezahlen.

Langfristig führt die Online Phase der elektronischen Gesundheitskarte, also die Telematikstruktur, aber zu einem elektronischen Rezept. Das heißt aber auch, dass die Kosten, die aus einem Rezept resultieren, sofort elektronisch gespeichert und damit verfügbar sein dürften. Es gibt also keinen Grund mehr, dem Arzt die kumulativen, tagesaktuelle Kosten nicht zur Verfügung zu stellen, zumal durch den signaturfähigen Heilberufeausweis eine gesicherte Umgebung für einen solchen Datentransfer bereitgestellt wird!

Das aber wiederum wird bedeuten, dass damit dem Auto eine Tachometer endlich eingebaut worden ist und zwar ohne Kosten durch „Goldgräber“ und alleine dadurch die Zahl der „Geschwindigkeitsüberschreitungen“ (um im Bild zu bleiben) deutlich sinken wird. Alleine das wird den Krankenkassen massiv Geld sparen.
Es kommt etwas anderes hinzu.
Man muss sich klar machen, dass bisher jede Änderung der Adresse eines Versicherten oder Änderungen des Status (Mitglied, Familie, Rentner) jedesmal zu einer Neuausgabe, das heißt aber auch neuen Herstellung einer Karte führte. Und das kostet Geld. Die elektronische Gesundheitskarte jedoch wird in der Onlinephase ggf. aktualisiert, die Daten also auf der Karte korrigiert und zwar mit Hilfe der gesicherten, signierfähigen Umgebung der neuen Lesegeräte nach Eingabe von PIN Codes des Patienten und des Arztes.
Dieses wiederum bedeutet eine weitere Kostenersparnis.
Die Telematikinfrastruktur verbindet aber auch Kliniken, Praxen, Krankenkassen und über den Weg der Telemedizin auch ggf. den Patienten miteinander.
Telemedizin Projekte habe ich mehrfach in meinem blog besprochen. Im Wesentlichen geht es darum, Messwerte von Patienten (z.B. Blutdruck, EKG, Gewicht und je nach Technik vieles mehr) drahtlos zum Arzt oder Klinik zu übermitteln, ohne dass der Patient seine häusliche Umgebung verlassen müsste. Diese Datenübertragung erfordert aber eine gesicherte, geschützte Umgebung, um deren Einführung es im Zusammenhang mit der elektronischen Gesundheitskarte geht. Diese Form der Telemedizin ist bei sinkender Arztdichte, auf dem Land, in Alters- und Pflegeheimen, bei seltenen Erkrankungen, deren Behandlung nur von wenigen Ärzten beherrscht wird, aber auch in der häuslichen Rehabilitation sehr interessant, selbstverständlich aber auch in allen Notfallsituationen bei chronisch kranken Patienten, wo beispielsweise eine eingreifende Therapie lebenslang täglich überwacht werden muss.
Es gibt zahllose Einsatzgebiete für die Telemedizin, die aber ohne eine gesicherte Telematikinfrastruktur nicht einführbar wäre.
Aus meiner Sicht resultiert also langfristig in der Einführung der elektronischen Gesundheitskarte eine win–win–win Situation für Ärzte, Krankenkassen und Patienten, sofern alle Sicherheitsaspekte berücksichtigt werden. In dem Zusammenhang sei daran erinnert, dass das BSI eine zentrale Stelle in der Einführung dieser Technik ist also alle Sicherheitsaspekte in diese Technik mit einfließen.

Die geplante Telematikinfrastruktur der Arztpraxis in der Onlinephase des eGK rollouts. Teil 1

Autor der Bilder: Gilbert Mohr KV Nordrhein, Leiter Stabsstelle IT in der Arztpraxis, Verwendung mit Genehmigung des Autors. Anklicken für vergrößerte Darstellung

Das Schaubild zeigt eine schematische Darstellung der geplanten Infrastruktur einer Arztpraxis mit Beginn der Onlinephase. Mit Primärsystem ist die Praxisverwaltungssoftware (PVS) bezeichnet, der Konnektor stellt die Verbindung zum Netz dar, es ist eine Art Router mit Sicherheitssystemen.  Das Kartenterminal dient zu Aufnahme des HBAs (Heilberufeausweises / Arztausweises) und der eGK (elektronischen Gesundheitskarte). Er ist direkt oder in einem Netzwerk mit dem Konnektor verbunden.

Die SMC-A wird sowohl als Zugriffskarte auf die eGK wie auch als Karte für den qualifizierten Remote-Zugriff auf einen „zentral gesteckten HBA“ verwendet. Auf diese Weise können nur autorisierte Geräte in einem Netz auf die eGK zugreifen. Man muss hier z.B. an eine Klinik mit einem großen Netzwerk denken, nur Geräte mit einem SMC-A können in einem solchen Netz mit einer eGK kommunizieren.

SMC-B :Praxisausweis, Institutionsausweis. Karte, die im Konnektor eingefügt wird, um die Institution des Leistungserbringers in der Telematik-Infrastruktur zu repräsentieren. Nur die SMC-B garantiert den Zugriff auf die geschlossene Netzstruktur mit den Anwendungsdiensten.

Der Zugangsdienst wäre z.B. D2D oder KV Safenet