Die hier beschriebenen Anwendungsfälle gelten ab KIM 1.5. Die dargestellen Sequenzdiagramme dienen nur zum allgemeinen Verständnis und berücksichtigen nicht alle Kommunikationspartner (z. B. DNS-Services-Lokalisierung). Die in den Sequenzdiagrammen dargestellten Operationen sollen lediglich den Ablauf des Anwendungsfalles verdeutlichen.
|
💡
|
Auf die Angaben der zu übergebenden Parameter bei den hier beschriebenen Operationen wird der Übersichtlichkeit halber verzichtet. Diese können in der KIM-API (Link) nachgelesen werden. |
|
❗
|
Bei den hier dargestellten Sequenzdiagrammen handelt es sich um erfolgreich durchgelaufene Anwendungsfälle. Auf die Beschreibung bei einer fehlerhaften Ausführung der Anwendungsfälle wird an dieser Stelle verzichtet. |
Über das Administrationsmodul kann ein KIM-Teilnehmer am Account Manager des gewählten Fachdienstes seine Registrierung durchführen, seinen Account verwalten oder Abwesenheitsnotizen einstellen. Die durch das Administrationsmodul am Account Manager im Rahmen des jeweiligen Anwendungsfalles aufgerufenen Operationen sind in der folgenden Abbildung dargestellt.
|
❗
|
Alle Operationen die vom Administrationsmodul am Account Manager über die REST-Schnittstelle I_AccountManager_Service aufgerufen werden, benötigen eine Authentifizierung über ein JSON Web Token.
|
Zukünftige KIM-Teilnehmer registrieren sich im ersten Schritt am Account Manager über das Frontend (GUI) des Administrationsmoduls (optional ist dies auch über das Primärsystem möglich - das Clientsystem mit dem Administrationsmodul ist in diesem Fall Bestandteil des Primärsystems). Bei Aufruf der Operation registerAccount() baut das Administrationsmodul eine TLS-Verbindung zum Account Manager auf.
Informationen mit den für die Registrierung benötigten Parametern erhält der Teilnehmer vorab von seinem gewählten KIM-Anbieter. Dazu gehören die referenceID, das initiale Passwort (iniPassword) und ggf. eine vom Anbieter festgelegte KIM-E-Mail-Adresse, die dann als referenceID genutzt wird. Das an der Registrierung beteiligte Clientmodul kann über eine Abfrage an der Schnittstelle I_ServiceInformation prüfen, welche Paramater für die Registrierung am jeweiligen KIM Fachdienst benötigt werden und dem Nutzer eine dem entsprechende Eingabemaske anbieten. Nach erfolgreicher Registrierung wird die PKCS#12-Datei mit dem Zertifikat vom Account Manager heruntergeladen, automatisiert entpackt und dem Clientmodul zur Verfügung gestellt. Das Zertifikat wird nur beim Account Manager durch den Aufruf der Operation createCert() beantragt, wenn im Clientmodul nicht bereits ein Zertifikat hinterlegt wurde. Das Administrationsmodul muss vor Ablauf dieses Zertifikates ein neues Zertifikat beim Account Manager beantragen und dem Clientmodul zur Verfügung stellen, welches damit das abgelaufene Zertifikat ersetzt. Die während der Registrierung übergebenen KIM-Fachdaten des Nutzers werden vom Account Manager in den zum Nutzer gehörenden Eintrag im Verzeichnisdienst eingetragen (z. B. KIM-Version).
Im folgenden Sequenzdiagramm ist die Interaktion zwischen Administrationsmodul und dem Account Manager dargestellt.
KIM-Teilnehmer können über das Frontend (GUI) des Administrationsmoduls eine Deregistrierung an ihrem Fachdienst veranlassen. Dafür baut das Administrationsmodul eine TLS-Verbindung durch den Aufruf der Operation deregisterAccount() zum Account Manager auf.
Nach einer erfolgreichen Deregistrierung ist der KIM-Account für eine definierte Zeit ausschließlich zur Abholung vorhandener E-Mails erreichbar. Nach Ablauf dieser Zeitspanne werden alle zu diesem Mail-Account gehörenden Daten gelöscht. Der KIM-Teilnehmer kann zu einem späteren Zeitpunkt die erneute Verwendung dieser E-Mail-Adresse nur dann beantragen, wenn er unter Angabe seiner Telematik-ID eine Berechtigung nachweisen kann.
Im folgenden Sequenzdiagramm ist die Interaktion zwischen Administrationsmodul und dem Account Manager dargestellt.
KIM-Teilnehmer können über das Frontend (GUI) des Administrationsmoduls eine ausgelöste Deregistrierung bis mindestens nach 30 Tagen zurücknehmen. Dafür baut das Administrationsmodul eine TLS-Verbindung durch den Aufruf der Operation revokeDeregistration() zum Account Manager auf. Nach einem erfolgreichen Aufruf der Operation steht dem Anwender der Account wieder in vollem Umfang zur Verfügung.
Ein KIM-Teilnehmer kann über das Administrationsmodul Nutzerdaten von seinem Account abrufen oder ändern (z. B. sein Passwort). Zum Abrufen von Nutzerdaten wird die Operation getAccount() am Account Manager aufgerufen. Für das Ändern von Nutzerdaten erfolgt dies über die Operation setAccount() am Account Manager. Für beide Operationen baut das Administrationsmodul eine TLS-Verbindung zum Account Manager auf.
Im folgenden Sequenzdiagramm ist die Interaktion zwischen Administrationsmodul und dem Account Manager dargestellt.
Zusätzlich zu den hier beschriebenen Operationen getAccount() und setAccount() besteht die Möglichkeit durch den Aufruf der Operation listAccounts(), am Account Manager, eine Liste aller, für eine Telematik ID, existierenden Accounts zu erhalten.
Am Administrationsmoduls kann ein KIM-Teilnehmer eine Portierung seiner KIM-E-Mail-Adresse zu einer anderen Telematik-ID (neue Smartcard) durchführen. Dafür ruft das Administrationsmodul die Operationen getOTP() und setTID() mit einer TLS gesicherten Verbindung am Account Manager auf.
Im Anwendungsfall wird ein One-Time Password (OTP) vom Account Manager generiert (getOTP()), welches für die einmalige Authentisierung bei der Portierung vom Administrationsmodule verwendet werden muss. Über das ausgestellte One-Time-Passwort besteht die Möglichkeit des Nachweises über den Besitz der alten Smartcard (alte Telematik-ID). Das One-Time-Password ist eine Woche lange gültig. Nach der erfolgreichen Portierung wird durch den Account Manager der Eintrag mit der neuen Telematik-ID zur bisheriegen KIM-Mail-Adresse im Verzeichnisdienst angepasst (setTID()).
Im folgenden Sequenzdiagramm ist die Interaktion zwischen Administrationsmodul und dem Account Manager dargestellt.
Das bei der erstmaligen Registrierung eines KIM-Teilnehmers vom Account Manager erzeugte TLS-Zertifikat hat nur eine begrenzte Gültigkeit. Einen Monat vor Ablauf der Gültigkeit des Zertifikates muss das Administrationsmodul beim Account Manager ein neues Zertifikat beantragen und herunterladen. Dazu ruft das Administrationsmodul die Operation createCert() am Account Manager auf. Die Überprüfung der Gültigkeit des aktuell benutzten TLS-Zertifikates übernimmt das Clientmodul bei jedem TLS-Verbindungsaufbau.
Im folgenden Sequenzdiagramm ist die Interaktion zwischen Administrationsmodul und dem Account Manager dargestellt.
Das Senden bzw. Empfangen von KIM-Mails wird durch die Schnittstelle I_Message_Service am Mail Server ermöglicht. Für den Umgang mit Client-Mails, die größer 15 MiB sind, bietet der KIM-Fachdienst einen KOMLE-Attachment Service (KAS) an. Auf diesen werden über den Aufruf der Schnittstelle I_Attatchment_Service die großen Client-E-Mails (E-Mail-Daten) verschlüsselt ausgelagert und später auf Empfängerseite, nach dem Herunterladen vom KAS des Absenders, wieder entschlüsselt und an das Clientsystems des Empfängers übergeben. Das dem Nutzer zu Verfügung stehende Speichervolumen für das Hochladen der verschlüsselten Client-Mails wird über die Schnittstelle I_AccountLimit_Service am Account Manager abgefragt. Somit sind alle drei Teilkomponenten des Fachdienstes an den Anwendungsfällen "Mail senden" und "Mail empfangen" beteiligt. Die durch das Clientmodul am Fachdienst im Rahmen des jeweiligen Anwendungsfalles aufgerufenen Operationen sind in der folgenden Abbildung dargestellt.
Will der KIM-Teilnehmer eine E-Mail versenden, wird im ersten Schritt die erstellte KIM-Nachricht vom Primärsystem/Mail-Client an das Clientmodul übergeben. Das Clientmodul überprüft zunächst die Größe der übergebenen Nachricht. Ist die Nachricht kleiner als 15 MiB behandelt das Clientmodul die Nachricht wie in KIM 1.0 beschrieben.
Übersteigt die Größe der Nachricht die 15 MiB, dann wird zunächst das Header-Element X-KOM-LE-Version: 1.5 in den E-Mail-Header hinzugefügt. Anschließend prüft das Clientmodul die maximal zulässige Mailgröße für den Nutzer-Account. Danach erzeugt das Clientmodul für die Client-Mail einen symmetrischen Schlüssel, sowie einen Hashwert. Mit Hilfe des symmetrischen Schlüssels wird die Client-Mail verschlüsselt. Anschließend wird die Operation add_Attachment() am KAS seines Anbieters aufgerufen, um die verschlüsselte Client-Mail (E-Mail-Daten) hochzuladen. Danach befüllt das Clientmodul die KIM-Attachement Datenstruktur und fügt diese als Ersatz in den Body der originalen Client-Mail ein. Anschließend wird die Client-Mail durch das Clientmodul weiter verarbeitet (z.B. weitere Header Elemente), durch den Konnektor signiert, mit dem asymmetrischen Schlüssel des Empfängers verschlüsselt und als KIM Mail an den Fachdienst versendet.
Die folgende Abbildung veranschaulicht den beschriebenen Ablauf:
Will ein KIM-Teilnehmer eine KIM-E-Mail abrufen, überprüft das Clientmodul im ersten Schritt ob beim Mailserver eine neue Nachricht im Postfach vorliegt. Ist dies der Fall, werden die zur Abholung selektierten Nachrichten vom Mailserver an das Clientmodul übergeben. Anschließend wird die Nachricht mit dem asymmetrischen Schlüssel des Empfängers entschlüsselt und die Signatur der Nachricht geprüft. Weiterhin prüft das Clientmodul, um welche KIM-Version es sich bei der Nachricht handelt. Bei einer KIM 1.0 Nachricht wird diese vom Clientmodul entsprechend den Vorgaben aus KIM 1.0 bearbeitet.
Handelt es sich um eine KIM 1.5 Nachricht, verwendet das Clientmodul den in der KIM-Attachment-Datenstruktur hinterlegten Freigabelink link, um mittels der Operation read_Attachment() die verschlüsselte Client-Mail vom KAS herunterzuladen. Anschließend wird die Client-Mail mit dem in der KIM-Mail enthaltenen symmetrischen Schlüsseln k entschlüsselt, der Hashwert berechnet und mit dem in der KIM-Attachment-Datenstruktur enthaltenen Hashwert hash verglichen. Im letzten Schritt wird die entschlüsselte Client-Mail durch das Clientmodul an das Primärsystem oder den E-Mail Client des Leistungserbringers übermittelt.
Das folgende Sequenzdiagramm stellt den Ablauf des Empfanges einer Nachricht dar:
KIM-Teilnehmer können über das Frontend (GUI) des Administrationsmoduls Anwendungskennzeichen für ihren e-Mail Account konfigurieren oder einsehen. Für das konfigurieren eines oder mehrerer Anwendungskennzeichen ruft das Administrationsmodul die Operation setAccount() an der Schnittstelle I_AccountManager_Service des Account Managers seines KIM Fachdienstes auf, der diese dann im Verzeichnisdienst in den KIM-Fachdaten für die betroffene Mail-Adresse einträgt. Für das Abfragen von konfigurierten Anwendungskennzeichen wird die Operation getAccount() an der Schnittstelle I_AccountManager_Service am Account Manager verwendet. Für jede Operation baut das Administrationsmodul eine TLS-Verbindung zum Account Manager auf.
Im folgenden Sequenzdiagramm ist die Interaktion zwischen Administrationsmodul und dem Account Manager dargestellt.
Der KIM-Teilnehmer kann eine zu versendende Nachricht mit einer Dienstkennung - z. B. "eAU;Lieferung;v1.0" - versehen. Wird durch den Mailclient in der für den Versand durch das Clientmodul übergebenen Mail keine Dienstkennung eingetragen, wird vom Clientmodul ein default-Dienstkennung nachträglich ergänzt ("KIM-Mail;Default;V1.0").
Die Dienstkennung wird in den Nachrichten-Header eingetragen, und kann auf der Empfängerseite für eine automatisierte Bearbeitung verwendet werden. Der Bezeichner des hierfür vorgesehenen Header-Feldes lautet X-KIM-Dienstkennung. Die Dienstkennung der ursprünglichen Mail wird nach der Verschlüsselung in den Header der verschlüsselten Mail übernommen. Ein Empfänger kann auf Basis der Dienstkennung entscheiden, wie er mit den zur Abholung auf dem Mail-Server bereitstehenden Nachrichten verfahren möchte.
KIM-Teilnehmer können über das Frontend (GUI) des Administrationsmoduls Abwesenheitsnotizen für einen definierten Zeitraum konfigurieren oder einsehen. Für das konfigurieren einer Abwesenheitsnotiz ruft das Administrationsmodul updateOutOfOffice() am Account Manager auf. Für das Abfragen von konfigurierten Abwesenheitsnotizen wird die Operation getOutOfOffice() am Account Manager verwendet. Für jede Operation baut das Administrationsmodul eine TLS-Verbindung zum Account Manager auf.
Im folgenden Sequenzdiagramm ist die Interaktion zwischen Administrationsmodul und dem Account Manager dargestellt.
Ab KIM 1.5 ist es möglich, dass mehrere Konnektoren in einer Umgebung von einem Clientmodul unterstützt werden. Dies ist vor allem im Krankenhausumfeld im Interesse einer notwendigen Lastverteilung sinnvoll. Das folgende Bild veranschaulicht den Einsatz von mehreren Konnektoren in einer Umgebung:
In der Zeichenkette SMTP- bzw. POP3-Benutzername, die der Mail Client zum Clientmodul schickt, wird zusätzlich die KonnektorID des zu verwendenden Konnektors übergeben. Dem Clientmodule wird dadurch die Auswahl eines bestimmten Konnektors vorgegeben. Die Umsetzung von mehreren Konnektoren in einer Umgebung kann hier: (Link) nachgelesen werden.