KIM nach dem PC-Tausch: Vier Ursachen hintereinander

KIM, „Kommunikation im Medizinwesen“, ist der E-Mail-Dienst der Telematikinfrastruktur. Über ihn laufen eArztbrief, eAU und Nachrichten zwischen Praxen, Kassen und Laboren. In einer Zahnarztpraxis stand der Tausch des Empfangs-PCs an (Projektrückblick). Die Praxissoftware lief auf dem neuen Rechner, die Kartenterminals auch, nur KIM verweigerte den Dienst.

Am Ende waren es vier Ursachen, die hintereinander lagen. Jede für sich ist einfach. Zusammen sind sie ein gutes Beispiel dafür, warum man bei TI-Störungen Schicht für Schicht vorgehen sollte, statt an mehreren Stellen gleichzeitig zu drehen.

Ein Hinweis vorab, der die ganze Arbeit prägt: Nach drei fehlgeschlagenen Anmeldeversuchen sperrt der KIM-Anbieter das Postfach. Jeder Test muss also sitzen. Blindes Ausprobieren ist keine Option.

Wie KIM technisch funktioniert

Die Praxissoftware spricht nicht direkt mit dem KIM-Server. Dazwischen sitzt das KIM-Clientmodul, ein lokaler Dienst, der sich für die Praxissoftware wie ein normaler Mailserver verhält (POP3 auf Port 995, SMTP auf Port 465). Das Modul übernimmt Verschlüsselung und Signatur über den Konnektor und leitet die Nachrichten an den Fachdienst des KIM-Anbieters weiter, der nur über die TI erreichbar ist.

Ursache 1: Die Praxissoftware zeigte auf den alten PC

Die erste Fehlermeldung war eindeutig: Connection rejected beim Verbindungsaufbau zu einer IP-Adresse im Praxisnetz. Diese Adresse gehörte nicht zum Konnektor, sondern zum alten Empfangs-PC. Die Einstellung „IP des KIM-Hosts“ war aus der alten Konfiguration übernommen worden.

Dazu kam: Das Clientmodul auf dem alten PC war nur an localhost gebunden und nimmt grundsätzlich keine Verbindungen von anderen Rechnern an. Auf dem neuen PC war noch gar kein Modul installiert.

Lösung: Clientmodul auf dem neuen PC über die Praxissoftware installiert (aktuelle Version mit KIM 1.5) und den KIM-Host auf localhost umgestellt.

Ursache 2: DNS kannte `.telematik` nicht

Die nächste Testnachricht scheiterte an der Anmeldung. Das Protokoll des Moduls war deutlich:

Der Eintrag _fdkimpop._tcp.<anbieter>.kim.telematik des Typs SRV konnte nicht aufgelöst werden.

Neuere Clientmodule für KIM 1.5 ermitteln den zuständigen Mailserver per DNS-SRV-Eintrag. Das alte Modul hatte den Server fest hinterlegt und brauchte das nicht. Namen unter .telematik kennt aber nur der DNS-Server des Konnektors, nicht der Internetrouter der Praxis.

Der Gegentest mit nslookup machte es sichtbar: Direkt am Konnektor gefragt, kam der SRV-Eintrag mit Server und Port zurück. Am Router gefragt, hieß es „Non-existent domain“.

Lösung: Im Router eine bedingte DNS-Weiterleitung eingerichtet. Die Domains telematik und splitdns.ti-dienste.de werden an den Konnektor weitergeleitet. Die Anleitungen der Praxissoftware-Hersteller nennen diese Weiterleitung übrigens ausdrücklich als Voraussetzung. In der Praxis fehlt sie trotzdem oft, weil es mit älteren Modulen auch ohne ging.

Ursache 3: Kein Konnektor im Modul

Auch nach der DNS-Korrektur scheiterte der Test weiterhin, wieder vor der Anmeldung. Ein Gegentest mit der Java-Laufzeit und der DNS-Bibliothek, die das Modul selbst verwendet, zeigte: Die Auflösung funktionierte jetzt einwandfrei. DNS war also nicht mehr die Ursache.

Der Blick in das Konfigurationsverzeichnis des Moduls zeigte den eigentlichen Befund: Die Konnektor-Konfiguration fehlte vollständig. Das neu installierte Modul wusste schlicht nicht, welchen Konnektor es für Signatur und Verschlüsselung verwenden soll.

Lösung: In der Administrationsoberfläche des Moduls (lokal im Browser) den Konnektor mit Adresse, Mandant, Clientsystem und Arbeitsplatz angelegt. Die Werte entsprechen dem Aufrufkontext der Praxissoftware und lassen sich aus der alten Installation übernehmen.

Ursache 4: Das Fachdienst-Zertifikat

Die letzte Hürde ist keine echte Störung, sondern ein normaler Schritt nach jeder Neuinstallation: Das Modul braucht ein TLS-Clientzertifikat für den Fachdienst. Es wird bei der ersten Anmeldung des Postfachs im Modul selbst bezogen („Login KIM-Benutzer“), und dabei gibt der Postfachinhaber sein Kennwort ein.

Danach ging die Testnachricht aus der Praxissoftware durch, versendet und empfangen.

Was man daraus mitnehmen kann

Beim PC-Tausch das Clientmodul mitdenken. Es ist eine eigene Installation mit eigener Konfiguration, kein Bestandteil der Praxissoftware, der automatisch mitzieht.
Vor jedem Test die Ursache belegen. Wegen der Postfachsperre nach drei Fehlversuchen haben wir jeden Schritt erst mit Protokoll, nslookup oder Portprüfung bestätigt und erst dann die Testnachricht ausgelöst.
DNS-Weiterleitung für .telematik gehört zur Grundausstattung. Spätestens mit KIM 1.5 funktioniert es ohne sie nicht mehr.
Die Protokolldatei des Moduls lesen. Die Fehlermeldungen in der Praxissoftware sind generisch. Das Log des Moduls sagt fast immer genau, welcher Schritt scheitert.