KIM4charly Konfiguration (für Systembetreuer)

Über diese Anleitung

KIM4charly ist die Schnittstelle zwischen charly und dem KIM-Dienst.

Hinweis: Diese Anleitung beschreibt die Konfiguration von KIM4charly. Sie richtet sich an Systembetreuer und setzt Grundkenntnisse zur E-Health- Telematikinfrastruktur voraus.
Hinweis: Diese Anleitung setzt voraus, dass die Telematikinfrastruktur in der Praxis bereits eingerichtet und in charly der Konnektor sowie die Aufrufkontexte konfiguriert sind, siehe Konnektor (TI), Aufrufkontext (TI).
Hinweis: Alle notwendigen Informationen rund um den prinzipiellen Aufbau sowie die Verwaltung des Servers, haben wir in dem Kapitel Server für Sie zusammengefasst.

 


Voraussetzungen

Telematikinfrastruktur

Für die Verwendung des KIM-Dienstes benötigen Sie folgende, von der gematik zugelassene, Komponenten und Dienste:

Tipp: Das Fachportal der gematik bietet u.a. eine Liste aller zugelassenen Komponenten und Dienste.

Software

Für KIM4charly benötigen Sie mindestens folgende Software-Versionen:

Ports

Übersicht der Ports, die für die Kommunikation zwischen den Komponenten erforderlich sind:

Port Beschreibung
10443 Standard für den SSL-Proxy. Wird vom charly-Updater in der Firewall geöffnet. Kann im charly-Updater umkonfiguriert werden. Führen Sie dazu den charly-Updater erneut aus.
14711 (HTTP) Standard für den Messaging-Service. Wird vom charly-Updater in der Firewall geöffnet. Kann im charly-Updater umkonfiguriert werden. Führen Sie dazu den charly-Updater erneut aus.
14712 (STOMP) Standard für den Messaging-Service. Kann in der „application.yml“-Datei des Messaging-Services geändert werden.

Für Änderungen an den Ports, siehe

Erforderliche charly-Rechte

Für die Konfiguration von KIM4charly benötigt Ihr charly-Benutzer mindestens folgende Zugriffsrechte in charly:

Die Zugriffsberechtigungen definieren Sie in den Stammdaten > Praxis > Gruppen > Rechte.

 


Konfiguration

Falls einer oder mehrere der erforderlichen Ports für DICOM4charlyerforderlichen Ports für KIM4charly bereits belegt sind, konfigurieren Sie diese um.

How-to

In charly: Telematikinfrastruktur (TI) einrichten

Hinweis: Diese Anleitung setzt voraus, dass die Telematikinfrastruktur in der Praxis bereits eingerichtet und in charly der Konnektor sowie die Aufrufkontexte konfiguriert sind, siehe Konnektor (TI), Aufrufkontext (TI).
Hinweis: Entsprechend der Anforderungen der IT-Sicherheitsrichtlinie empfiehlt die solutio GmbH & Co. KG die Konfiguration mittels TLS mit Zertifikatsprüfung.

Konfiguration des Konnektors sowie der Aufrufkontexte testen

In charly können Sie in dem Fenster Konnektor-Operationen verschiedene Operationen durchführen, um die Konfiguration der Telematikinfrastruktur zu testen.

How-to

KIM-Clientmodul installieren und konfigurieren

Hinweis: Das KIM-Clientmodul erhalten Sie von Ihrem KIM-Provider. Installieren Sie das KIM-Clientmodul auf dem charly-Server. Für die Installation und Konfiguration des KIM-Clientmoduls lesen Sie bitte die Dokumentation Ihres KIM-Providers.

Ports

Für das Empfangen und Senden von Nachrichten über das KIM-Clientmodul, müssen in KIM4charly bei der Konfiguration eines KIM-Kontos entsprechend die URLs für POP3 sowie SMTP eingegeben werden.

Hinweis: Unter macOS können Ports mit einer Portnummer < 1024 vom KIM-Cientmodul nicht aufgerufen werden (auch nicht mit Admininstrator-Rechten). Bitte ändern Sie die Ports im KIM-Clientmodul für POP3 und SMTP auf eine freie Portnummer > 1024.

In KIM4charly: KIM-Konto erstellen

Die KIM-Konten erstellen Sie in KIM4charly in der Ansicht Kontoverwaltung.

Tipp: Für möglichst automatisierte Abläufe im Praxisalltag, empfiehlt es sich, mindestens ein Praxiskonto in KIM4charly einzurichten. Durch die Verknüpfung des Praxiskontos mit dem Praxisausweis (SMC-B), werden die folgenden Aktionen für dieses Praxiskonto i.d.R. ohne weiteres Zutun des Praxispersonals durchgeführt:
  • Synchronisierung der Postfächer
  • Entschlüsselung eingehender KIM-Nachrichten mit dem SMC-B
  • Verschlüsselung ausgehender KIM-Nachrichten mit dem SMC-B
  • Optionale Signierung von Anhängen mit „Nicht“-QES
  • Automatischer Versand von eAU, sofern das Praxiskonto bei der eAU-Erstellung für den Versand gewählt wurde.

Die automatisierten Abläufe sind mit einem Praxiskonto möglich, da der verknüpfte Praxisausweis (SMC-B) i.d.R. dauerhaft im Kartenterminal steckt. Durch die (fast) täglichen eGK-Einlesungen befindet sich der SMC-B im Status „verified“ und erfüllt damit die Voraussetzungen für die Funktionalitäten im Praxiskonto.

How-to

FAQ

 


Server

charly-Java-Server

Der charly-Java-Server (ncjs) bezeichnet die Summe aller Microservices und die für deren Betrieb erforderliche Infrastruktur, welche auf dem Server der Zahnarztpraxis betrieben wird.

Hinweis: Der charly-Java-Server ist automatisch in charly enthalten und wird im Rahmen der charly-Updates laufend aktualisiert.

Installationspfad charly-Java-Server (ncjs)

Alle Komponenten des charly-Java-Servers befinden sich auf dem charly-Server unter folgendem Pfad:
<charly-Installationspfad>\Solutio\Server\ncjs

Konfigurationsdatei "application.yml"

Microservices werden mit Hilfe der Datei application.yml konfiguriert. Für jeden Microservice gibt es eine eigene „application.yml“-Datei.

Kundenspezifische Konfigurationen müssen unter ncjs in dem Verzeichnis conf2 abgelegt werden, da dieses Verzeichnis durch charly-Updates nicht überschrieben wird. Innerhalb des Verzeichnisses conf2 muss für jeden Microservice, für den eine kundenspezifische Konfiguration hinterlegt wird, ein weiteres Verzeichnis mit dem Namen des Microservices angelegt werden. Dort wird die kundenspezifische „application.yml“-Datei abgelegt.

Beispiel: Pfad einer kundenspezifischen „application.yml“-Datei mit Konfigurationen für den Soldicom-Service:
\Solutio\Server\ncjs\conf2\soldicom\application.yml

Service-Registry

Die Service-Registry fasst die Microservices, ihre Instanzen und ihre Lokationen in einer Datenstruktur zusammen. Die Microservices werden unter einem logischen Namen registriert und lassen sich anschließend über diesen Namen ansprechen.

Eine Liste aller registrierter und gestarteter Microservices ist auf der Weboberfläche einsehbar. Diese können Sie wie folgt aufrufen:

  1. Öffnen Sie auf dem Server ein Browserfenster.
  2. Geben Sie folgende URL ein: http://localhost:8087

    Tipp: Wenn Sie die Microservices gerade neu gestartet haben, dauert es ca. 1-2 Minuten, bis alle registrierten Microservices zur Verfügung stehen.
    Hinweis: Falls Sie den Port für den Discovery-Service über den charly-Updater geändert haben, geben Sie stattdessen diesen geänderten Port in der URL an.

Kommandozeilenwerkzeug für Serversteuerung

Alle Microservices werden im Rahmen eines charly-Updates durch den charly-Updater registriert und gestartet. Für den Fall, dass ein Microservice z.B. für eine Konfigurationsänderung manuell gestoppt und wieder gestartet werden muss, gibt es das Tool ACD.

Das ACD-Tool besteht aus jeweils einer Skriptdatei für Windows (acd.bat) und macOS (acd.sh). Die Skriptdateien sind grundsätzlich in Funktion und Oberfläche identisch. Das Skript muss über die Kommandozeile im Administratormodus ausgeführt werden. Dazu muss in der Kommandozeile der Pfad zu dem Verzeichnis geöffnet sein, in dem die Skripdateien (acd.bat bzw. acd.sh) liegen.

Die Skriptdateien befinden sich unter: \Solutio\Server\ncjs.

Aufruf

Der Aufruf beginnt immer mit der Angabe des Skripts gefolgt von dem eigentlichen Befehl. Die Syntax lautet wie folgt:

Es gibt Befehle, die für alle bekannten Microservices gleichzeitig durchgeführt werden und Befehle, mit denen Sie nur einen bestimmten Microservice ansprechen. Für diese „Einzelbefehle“ müssen Sie den Short Name des Microservices angeben. Die Short Names der Microservices finden Sie heraus, indem Sie in der Kommandozeile folgenden Befehl eingeben:

Als Ergebnis erhalten Sie eine Liste aller bekannten Microservices.

Beispiel: Im Folgenden ein Beispiel für den Auth-Microservice. Der Short Name ist die Angabe hinter Name. In diesem Fall auth:
     Name: auth
   Memory: 32m/256m
 Filename: auth-service-app-1.3.0-SNAPSHOT.jar
Full name: NCJS Auth
    State: RUNNING

Mit dem Short Name können Sie nun einen „Einzelbefehl“ für den Auth-Microservice absetzen.

Beispiel: Der Microservice mit dem Short Name auth soll über ACD gestoppt werden.
  • Windows

    acd.bat stop auth
  • macOS

    sudo ./acd.sh stop auth

Befehle

Befehl Beschreibung
list Listet alle bekannten Microservices mit folgenden Informationen: Name (= Short Name), Speicher, Dateiname, voller Name und Status.
register Registriert einen Microservice als Systemdienst. Der Name (= Short Name) des Microservices muss angegeben werden.
registerall Funktioniert wie der Befehl register, wird jedoch für alle bekannten Microservices ausgeführt.
start Startet einen Microservice. Der Name (= Short Name) des Microservices muss angegeben werden. Um den Start-Befehl erfolgreich auszuführen, muss der Microservice bereits registriert sein.
startall Funktioniert wie der Befehl start, wird jedoch für alle bekannten Microservices ausgeführt. Um den Start-Befehl erfolgreich auszuführen, müssen die Microservices bereits registriert sein.
stop Stoppt einen Microservice als Systemdienst. Der Name (= Short Name) des Microservices muss angegeben werden.
stopall Funktioniert wie der Befehl stop, wird jedoch für alle bekannten Microservices ausgeführt.
unregister Meldet einen Microservice als Systemdienst ab. Der Name (= Short Name) des Microservices muss angegeben werden. Falls der Microservice noch läuft, führt diesen Befehl vor dem unregister ein stop durch.
unregisterall Funktioniert wie der Befehl unregister, wird jedoch für alle bekannten Microservices ausgeführt. Für Microservices, die noch laufen, führt diesen Befehl vor dem unregister ein stop durch.

How-to

Windows

Mac