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.

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.

KV-Connect – Erfahrungsbericht Teil 3

Im dritten Teil meines Erfahrungsberichtes werde ich auf die Berührungspunkte zwischen KV-Connect und der Praxissoftware, in meinem Falle ISYNET von medatixx eingehen.

Im Wesentlichen gibt es zwei Punkte: den Aufruf der Liste mit den abgerufenen Rückantworten der KV zu den eingesandten Dateien und die 1-klick-Abrechnung.

Da KV-Connect D2D noch nicht vollständig ersetzt (DMP beispielsweise muss noch im D2D Verfahren übertragen werden), ist es leider notwendig in den Systemparametern die Einstellung zu verändern, je nachdem, was man grade machen will. Das führte im Verlauf zu Problemen, da die momentane Einstellung nicht herausgehoben auf der Benutzeroberfläche ersichtlich ist, man also nicht leicht erfährt, was grade eingestellt ist, zumal auf mehreren Arbeitsplätzen.

Die anfangs noch nicht einwandfrei durchgezogene Mandantentrennung bei der Liste ist mittlerweile verbessert. Auf kleine Unschönheiten, wie nicht verdeckt einzutippende Passwörter etc. will ich nicht eingehen, sie werden sicher bald korrigiert.

Problematischer war, dass beim Aufruf der Liste keine Rückantwort darüber zu bekommen ist, ob KV Connect überhaupt noch als Task läuft (siehe hierzu Teil 2 meines Berichtes) oder nur den alten Listeninhalt wiedergibt. Zum zweiten wurde in den Parametereinstellungen später noch eine Pfadeinstellung kritisch, ändert man diese, werden die Listeninhalte systemintern an dem neuen Ort (also dem neuen Pfad) abgespeichert, die Dateien sind dann aber auf mehrere Pfade verteilt, die Liste gibt den gesamten Inhalt wieder, abrufbar ist aber nur der jeweils neue Inhalt im zuletzt abgespeicherten Pfad. Aufruf anderer Inhalte führt einfach zum Absturz des Programmes.

Wie sich später herausstellte ist die Pfadeinstellung in den Systemparametern wie folgt gelöst: Es gibt einen Hauptpfad der an anderer Stelle vorgegeben ist, der in den Systemparametern eingestellte Pfad ist also ein Unterpfad dieses Hauptpfades. Daraus folgt, dass bei der Pfadangabe eine Angabe wie „I:/“ nicht eingestellt werden darf, da das System sonst beim Versuch scheitert, den Pfad zusammenzusetzen aus Hauptpfad und dem Unterpfad, der in den Systemeinstellungen anzugeben ist. Genau das aber wird erst beim Versuch einer Echtabrechnung wichtig, fällt also erst am Quartalsende auf. Jede normale Testabrechnung benutzt diese Parameter nicht, so dass es erst bei der Echtabrechnung am Quartalsende zu Problemen kommt.

Wenn sich dann noch die KV weigert zum technischen Test mal eine „Echtabrechnung“ mitten im Quartal in Empfang zu nehmen, einfach nur um den technischen Ablauf zu kontrollieren, weil sie sich nicht in der Lage sieht, diese „Test-Echtabrechnung“ zu löschen, oder das zu viel Arbeit macht (was wohl eher der Wahrheit entspricht) ahnt man bereits, was passieren wird.

Folgerichtig kam es zum Crash der Software bei der Abrechnung. Fatalerweise ist der Pfad auch für die D2D Abrechnung wichtig, die ja als Alternative noch machbar ist, „der alte Weg“. Erst als nach Stunden von Fernwartungssitzungen, dieses kleine Pfad-Detail gefunden und aus der Welt geschafft wurde, lief alles einwandfrei.

Mittlerweile ist nun Test- und Echtabrechnung problemlos möglich und ich bin sicher, dass die verbliebenen Probleme noch beseitigt werden.

Abschließend sei erwähnt, dass KV-Connect offenbar in Java programmiert wurde und in der bei uns installierten Version 2 das veraltete Java 7 braucht und beim Update auf Java 8 kurzerhand seinen Dienst einstellt.

Eine verfügbare Version 3 des KV Connect läuft unter Java 8, ist aber nach meiner Kenntnis noch nicht mit ISYNET kompatibel.

Zusammenfassend sollte folgendes vordringlich geändert werden:

1. Die „falsche Pfadeinstellung“ muss schon in den Parametereinstellungen abgefangen werden, also technisch unmöglich sein
2. In ISYNET muss eine Kontrollanzeige erstellt werden, die anzeigt, ob D2D oder KV-Connect eingestellt ist
3. Das Abrufen der Listeninhalte über mehrere Order hinweg muss geändert werden.
4. Es wird eine Anzeige benötigt, ob der KV-Connect Task überhaupt noch läuft
5. Es sollte ein Upgrade auf KV-Connect Version 3 ermöglicht werden, um auf die neue Version 8 von Java updaten zu können

Hier finden sie die anderen Teile des Berichtes:

Teil 1 des Berichtes

Teil 2 des Berichtes

KV Connect – Erfahrungsbericht Teil 2

Im zweiten Teil meines Erfahrungsberichtes geht es um die Erfahrungen im Alltagsbetrieb und die Einbindung in MCS-IYNET.

Wir betreiben in der Praxis einen Windows Terminal Server (WTS), die Installation von KV Safenet erfolgt im Administratormodus. Dabei werden drei Icons auf dem Desktop im Administratormodus abgelegt, je eines zum Start und Beenden des Tasks und ein Icon mit einem voreingestellten Pfad im Internetexplorer, der zum KV Server führt.

Das anfängliche Problem bestand darin, dass es keine einfache Kontrolle darüber gibt, ob der Task überhaupt noch ausgeführt wird oder nicht, eine Benutzeroberfläche gibt es nicht und ISYNET gibt intern dazu keine Auskunft.

Ist der Server nur über KV Safenet angebunden und hat keinen eigenen Internetzugang – so ist es bei uns aus Sicherheitsgründen gelöst – kann man einzig mit dem oben abgebildeten Internetexplorer – Icon kontrollieren, ob sich das dort eingerichtete Eingabefenster der KV öffnet. Dies ist nur bei hergestellter KV-Connect Verbindung möglich, ist also die einzige Kontrollmöglichkeit.

Das zweite Problem bestand darin zu begreifen, das der KV – Connect Task zwar im Administratormodus installiert und eingerichtet wird, aber auf dem normalen Arbeitsplatz ohne Administratormodus betrieben werden muss.

Es stellte sich nämlich heraus, dass ein im Administratormodus gestarteter KV-Connect Task nach Beenden der remote Desktop Verbindung ebenfalls beendet wird, sozusagen das Schließen des Fensters nicht überlebt. Und das bekommt man schlicht nicht mit, da es ISYNET intern keinerlei Kontrolle hierüber gibt.

Erst nachdem ich mir die oben abgebildeten Pfade bzw. Icons auch auf dem normalen Arbeitsplatz ohne Administratorrechte eingerichtet hatte und KV Safenet von dort morgens, sozusagen mit dem ISYNET, gestartet hatte, war die Verbindung stabil und blieb es, solange dieses Fenster nicht geschlossen wurde, was im Alltagsbetrieb erst mit dem Verlassen der Praxis passiert.

Aus genau diesem Grunde gelang es mehreren Technikern auch nicht, den Task als „Auto start“ auf dem Server im Administratormodus einzurichten. Wir haben dann schlicht darauf verzichtet, da es offenbar nicht möglich ist, oder keiner wusste, wie es geht.

Hat man es nämlich irgendwie fertig gebracht einen Task so einzurichten, dass er dauernd weiter läuft, solange der Server eingeschaltet ist – so war es zunächst beabsichtigt – stellt man fest, dass nach Rücksetzen der dynamischen IP Adresse irgendwann in der Nacht im Telekom Router, der die DSL Verbindung aufrechterhält, die KV Connect Verbindung abreißt, da KV Connect diese Änderung nicht mitbekommt. Ohne einfache Kontrolle darüber, ob eine Verbindung besteht, oder nicht, fällt das aber lange nicht auf.

Aus diesen Gründen haben wir uns zuletzt zu der oben beschriebenen Einrichtung entschlossen: KV Connect morgens auf dem normalen Arbeitsplatz starten, über Internet Explorer kontrollieren und eben nicht als Dauertask auf dem Server einrichten, da letzteres zumindest bei uns schlicht nicht praktikabel war.

Ich würde mich sehr über Ihre Rückmeldung freuen, wenn Sie hierzu ein paar Tipps haben.

Innerhalb der Praxissoftware ISYNET gibt es im Prinzip zwei Bereiche, die mit KV-Connect zu tun haben: der Aufruf der Listen mit den eingegangenen Rückmeldungen und die 1-Klick Abrechnung.

Darüber werde im dritten Teil in den nächsten Tagen berichten.

Links:

Teil 1 des Berichtes

KV-Connect Erfahrungsbericht – Teil 1

Ich habe bereits kurz zu KV-Connect Stellung bezogen und so wird es nun Zeit für einen ersten Erfahrungsbericht.

In einem ersten Teil berichte ich über die Systemvoraussetzungen und den Antragsweg bis zur fertigen Installation im Bereich KV Nordrhein.

Wie bekannt, sind die Methoden zur elektronischen Übermittlung von Abrechnungsdaten einer Kassenarztpraxis zu der jeweils zuständigen Bezirksstelle regional erheblich unterschiedlich, hier ist absehbar noch nichts vereinheitlicht.

In der KV-Nordrhein wurde bislang überwiegend D2D („doctor-to-doctor“) bis Mitte des Jahren sogar noch via ISDN, seither ausschließlich per DSL durchgeführt. Das andernorts bereits gut eingeführte KV-Connect ist hier noch in den allerersten Anfängen.

Perspektivisch soll über dieses System nicht nur die Abrechnung, sondern auch DMP und z.B. Hautkrebsscreening Daten übermittelt werden und sogar elektronische Arztbriefe, dies ist bislang aber noch nicht realisiert.

Bis da hin wird also eine Abrechnung über KV-Connect, die anfallenden Daten von z.B. DMP aber weiterhin über D2D übermittelt. Dies scheint mir auch der Grund für die nach meiner Meinung bevorstehende Verlängerung der „Abschaltefrist“ von D2D zu sein, die zumindest bisher für Anfang 2016 in Nordrhein vorgesehen war.

Ich werde in nächster Zeit sporadisch über meine Erfahrungen als Testkunde in Nordrhein für KV-Connect im Zusammenhang mit meinem Abrechnungssystem medatixx-ISYNET berichten.

Wer sich einen ersten Überblick über das System verschaffen will, kann dies hier tun. Das Antragsformular für den Bereich KV-Nordrhein bekommt man hier. (pdf Datei)

Erste Voraussetzung ist KV Safenet. Dafür ist ein geeigneter KV-SafeNet-Anbieter auszuwählen, der einen vorkonfigurierten KV-SafeNet-Router zur Verfügung stellt. Informationen hierzu bekommt man hier (pdf Datei). Dabei handelt es sich im Wesentlichen um einen Router, der nur eine gesicherte Verbindung zum KVSafenet zulässt. Technisch ist das über verschiedene Provider mit durchaus unterschiedlichen Geräten zu realisieren. Die Bundes KV stellt auch eine vergleichende Preisliste zur Verfügung.

Für KV SafeNet fallen geringe monatliche Gebühren an. Die Installation lässt man am Besten durch das Systemhaus durchführen, welches die Betreuung des Arztinformationssystems (bei mir ISYNET) übernimmt.

Man erhält dabei übrigens ein Konfigurationsblatt mit wichtigen Daten zur Einstellung, da man unbedingt aufbewahren sollte. Ich habe es eingescannt und auf den Server gelegt, damit es nicht verloren geht.

Ist KV SafeNet installiert, kommt der nächste Schritt. Man füllt nun das oben bereits verlinkte Anmeldeformular aus und erhält einige Tage späte Zugangsdaten per Postident Verfahren zugeschickt. Dies ähnelt dem Verfahren beim elektronischen Arztausweis.

Hat man diese Daten bekommen, wird es Zeit sich beim Systemhaus um einen Installationstermin für KV-Connect zu bemühen. Die Installation ist nicht trivial und kann nicht selbst durchgeführt werden. Mit den erhaltenen Zugangsdaten (wie oben beschrieben per Postident-Verfahren zuvor erhalten) meldet man sich während der Installation einmalig beim Server an und ist von da an als einsendende Adresse dort registriert.

Wie sich später herausstellen sollte, ist die die Installation bislang noch ein rein manueller Vorgang (keine regelrechte Installationsdatei, die einfach zu starten wäre) und ist damit leider fehleranfällig. Außerdem können die Systemhäuser das KV Connect somit nicht mit ihrer übrigen Software ausliefern und installieren lassen, sondern es muss zumindest bislang immer ein Techniker ins Haus kommen, der die Installation manuell durchführt.

Es soll aber Bestrebungen geben, dies in Zukunft zu ändern.

Im zweiten Teil werde ich über erste Erfahrungen in der Anwendung berichten.

NRW plant flächendeckenden elektronischen Arztbrief, falls notwendig unabhängig vom Stand der bundesweiten Telematikinfrastruktur

Nach Informationen der Ärztezeitung und einer Pressemitteilung des NRW Gesundheitsministeriums zu Folge ist in NRW eine flächendeckende Versogung mit einem elektronischem Arztbrief geplant, wenn die Modellversuche in Düren erwartungsgemäß erfolgreich sein sollten.

Die Briefe werden mit dem in NRW eingeführten elektronsichen Arztausweis signiert, der ebenso schon zur rechtsgültigen Signatur der elektronischen KV Abrechnung im niedergelassenen Bereich (Signatur der Gesamtaufstellung) verwendet wird.  Die Übermittlung soll offenbar über KV Safenet erfolgen.

Soweit zu erfahren war,  soll die Anwendung in Nordrhein und Westfalen-Lippe ausgerollt werden – unabhängig vom Stand der Entwicklung einer bundesweiten Telematik-Infrastruktur unter Führung der gematik, wie es in der Ärztezeitung heisst.

Quelle:

Pressemitteilung NRW Gesundheitsministerium

Ärztezeitung

Versichertenstammdatenmanagement und qualifizierte Signatur wird eingeführt.

Die als Alternative 2012 bezeichnete beschleunigte Einführung des VSDM (Versichertenstammdatenmanagement) wurde am Montag von der Gesellschafterversammlung der gematik mit einigen Änderungen beschlossen. So soll zusätzlich die qualifizierte Signatur eingeführt werden.

In der Meldung der gematik heisst es dazu:

Mit der Anwendung Versichertenstammdatenmanagement wird technisch die gesetzliche Vorgabe des § 291 Abs. 2b SGB V umgesetzt, nach der an der vertragsärztlichen Versorgung teilnehmende Ärzte, Zahnärzte und Einrichtungen verpflichtet sind, die vorgelegte eGK bei der erstmaligen Inanspruchnahme von Leistungen im Quartal auf Gültigkeit und Aktualität der Versichertendaten zu prüfen.

und weiter heisst es:

Dazu gehört zum einen die Anwendung des Versichertenstammdatenmanagements (VSDM). Zum anderen aber als Mehrwert die qualifizierte elektronische Signatur (QES). Sie ist in der elektronischen Kommunikation und Datenhaltung als Äquivalent zu einer handschriftlichen Unterschrift des (Zahn-)Arztes unerlässlich und bildet die sichere Basis für nahezu jegliche medizinische Anwendung, z. B. für Arztbriefe oder den Notfalldatensatz. Auch die Abrechnung kann damit weitergehend elektronisch umgesetzt werden.

Über Details werde ich berichten, sobald sie vorliegen.

Quelle:

gematik

Deutches Ärzteblatt

Pressemitteilung GKV Spitzenverband

Schwachstelle in den eGK Lesegeräten? [Update]

Elektronische Gesundheitskarte – Tests haben eine Schwachstelle in den Kartenterminals des laufenden Basis-Rollouts entdeckt. Sie ist umgehend zu beheben, fordern KBV, KZBV, BÄK und BZÄK. Patientendaten sind nicht betroffen. So oder ähnlich lauteten die Meldungen in der letzten Woche. Der originale Artikel im Merkur kann hier nachgelesen werden.

Meine Kommentare hierzu:

1. Im aktuellen Basis Rollout der eGK werden PINs überhaupt nicht verwendet. Die Karte hat zunächst keine andere Funktion als die alte KVK. Wo keine PIN ist, kann auch keine ausgespäht werden.
2. PINs werden nämlich erst im zukünftigen Online Szenario gebraucht und dessen technische Spezifikationen werden aktuell in der Pflichtenheft-Phase überhaupt erst entwickelt. Was genau kommen wird wissen wir erst nach Ende der Pflichtenheftphase, wohl Anfang 2012. Dann erst stehen die genauen Spezifikationen für den Onlinebetrieb fest. Viel Zeit für Sicherheitsupdates.
3. Die Kartenlesegeräte waren von Anfang an auf ein Update ausgelegt, schon deshalb, weil sie im aktuellen Zustand nur für den Offline Rollout gedacht sind. Erst durch ein Update, das schon immer vorgesehen war, sind die Lesegeräte auf die Online Situation vorbereitet. Es dürfte leicht sein, hier in Zukunft ein Sicherheitsupdate einzubinden, um das aktuelle Problem aus der Welt zu schaffen.
4. Die Lesegeräte, mit den heute die meisten Ärzte arbeiten, um ihre Abrechnungen zu signieren, haben in dieser Hinsicht die gleiche Funktionalität wie die eHealth-BCS-Geräte für die eGK, so dass auch hier die PIN theoretisch ausgespäht werden könnte. Dazu sagt aber keiner was.
5. Das geschilderte Angriffsszenario stellt ein Sicherheitsmangel beim Arztrechner dar und nicht bei der eGK.  Ein Zugriff auf die PIN wäre über den Praxis-PC nämlich nur dann – theoretisch – denkbar, wenn ein entsprechender Virus (Trojaner) den Rechner des Arztes infiziert hat. Und der muss da erst mal hinkommen. Denn das wäre nur durch eine Nicht-Einhaltung der KBV Bestimmungen denkbar.  Denn die sehen vor, dass ein Arztrechner etwas verkürzt dargestellt nur über Hardwarefirewall, VPN Tunnel und Virenchecker überhaupt ans Internet darf. Bei einer Praxis, die diese Hinweise der KBV ernst nimmt, dürfte das Szenario der Leistungserbringerorganisationen theoretisch bleiben.
6. Die PIN alleine nützt wenig. Um an Patientendaten zu kommen muss man zumindest in der alten Spezifikation auch die eGK selbst haben und im Einzelfall einen Heilberufeausweis nebst dessen PIN, je nachdem was man ausspähen will. Um es an dieser Stelle deutlich zu sagen: Patientendaten sind überhaupt nicht betroffen

[Update] Mitlerweile gibt es eine Stellungnahme des BSI, das im Wesentlichen in die gleiche Richtung argumentiert

 Artikel im Merkur

Pressemitteilung der KBV

Leitfaden „Anforderungen an Hard- und Software in der Praxis Hinweise zum Datenschutz – Ein Leitfaden für Ärzte und Psychotherapeuten“ vom Februar 2010

Pressemitteilung der gematik

Stellungnahme des BSI

Concat liefert die KoCo Box mit Support

Die KoCo Connector AG wurde im August 2007  gegründet. Sie entwickelt im Kerngeschäft einen spezifikationskonformen Serienkonnektor. Er ist eine der wichtigsten Komponenten in der Telematikinfrastruktur für die elektronische Gesundheitskarte (eGK) in der kommenden Onlinephase des eGK rollouts.

Die im Moment politisch diskutierten Hausarztverträge mit dem Hausärzteverband sehen im Vertragstext (Beispiel Vertrag mit der TK, §3 (2) g)  eine Onlineanbindung vor, sobald diese zur Verfügung steht.  Hierfür werden ebenfalls die gematik konformen Konnektoren eingesetzt. Die benötigte Konformitätsbescheinigung vom Hausärzteverband wurde nun erteilt.

Die KoCo-Box ist somit einsatzfähig für die Vernetzung im Rahmen von Selektivverträgen nach § 73c SGB V und für die  Hausarztvernetzung nach § 73b SGB V und steht zertifizierten Providern für KV-SafeNet offen. Zukünftig bindet sie die Primärsysteme sicher in die zentrale Telematikinfrastruktur des Gesundheitswesens ein.

Vor Einführung der Telematikinfrastruktur (TI) bindet sie Arztpraxen an Hausarztvernetzung und Selektivverträge an.  Zukünftige Anwendungen sehen nach Einführung der IT Infrastruktur u.a. die Aktualisierung der Versichertendaten (VSDD) sowie das Abrufen/Aufspielen elektronischer Arztbrief (MWK-LE) und von  elektronische Formulare mit qualifizierter Signatur vor. Weiteres ist in Vorbereitung.

Auf Basis höchster Sicherheitsstandards können Haus- und Fachärzte die genannten Verträge mit der Krankenkasse online verwalten oder Abrechnungen übermitteln.

Im Gegensatz zur noch ausstehenden Finanzierungsvereinbarung im Bundesprojekt ist in Baden-Württemberg die Investition der Infrastruktur bereits geregelt und umgesetzt. Die Anschaffung der notwendigen Komponenten wird durch den Arzt getragen und durch die extrabudgetäre Vergütung amortisiert. Schnellere Quartalsabrechnung, geringere Abzüge sowie die extrabudgetäre Vergütung sind nur einige Vorteile, die die teilnehmenden Ärzte durch die Selektivverträge haben, berichtet Emily Andreae von der KoCo Konnector AG  in einem Interview.

Meines Erachtens nach sollte in der aktuellen Diskussion der angeblich zu hohen Honorare, die diese neuen Verträge für den Hausarzt bedeuten, berücksichtigt werden, dass zumindest im Moment  der Arzt die notwendige TI Infrastruktur, also den Konnektor, noch selbst bezahlen muß und natürlich durch die höheren Honorare gegenfinanziert, die diese Verträge bedeuten,  zumindest solange, bis eine bundesweite Finanzierungsvereinbarung existiert.  Der momentane Angebots-Preis von Concat (abhängig vom Dollarkurs) ist incl. Installation und 3 Jahre Softwaresupport bei 1.861,16€ incl. Mwst.

Nachtrag vom 23.7.10: Ich habe das Bild des Konnektors gegen ein aktuelles Bild des Herstellers ersetzt. Herzlichen Dank an Herrn Brockt von der concat AG.

Nachtrag vom 27.7.10: Der Produktflyer wurde aktualisiert sowie die Stempel

Quelle:

Pressemitteilung

weitere Pressemitteilung

Produktflyer

Homepage der KoCo Connector AG

Concat AG

Interwiew zum Thema

Bestellschein KoCoKonnector mit Preis

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