diff --git a/README.adoc b/README.adoc
index 7a5ec16..d98c6f5 100644
--- a/README.adoc
+++ b/README.adoc
@@ -3,7 +3,6 @@
image:gematik_logo.svg[width=70%]
-image:https://img.shields.io/badge/dynamic/json?url=https%3A%2F%2Fraw.githubusercontent.com%2Fgematik%2Fapi-kim%2Fdevelop%2Fsrc%2Fjson%2Fbadges.json&query=%24.badges.releaseNotes.version&prefix=%20&style=plastic&logo=github&logoColor=red&label=ReleaseNotes&labelColor=%24.badges.releaseNotes.color&color=red[link="ReleaseNotes.adoc"]
image:https://shields.io/badge/AccountManager-v2.3.0-blue?style=plastic&logo=github&logoColor=lightblue[link="https://github.com/gematik/api-kim/blob/main/src/openapi/AccountManager.yaml"]
image:https://shields.io/badge/AttachmentService-v2.3.0-blue?style=plastic&logo=github&logoColor=lightblue[link="https://github.com/gematik/api-kim/blob/main/src/openapi/AttachmentService.yaml"]
image:https://shields.io/badge/AccountLimit-v1.1.0-blue?style=plastic&logo=github&logoColor=lightblue"[link="https://github.com/gematik/api-kim/blob/main/src/openapi/AccountLimit.yaml"] +
@@ -24,7 +23,9 @@ Der Funktionsumfang der KIM Version 1.5 erweitert sich gegenüber KIM 1.0 wie fo
* das Einrichten von Abwesendheitsnotizen
-* die Unterstützung syntaktischer Nachrichtenkategorien
+* das Einrichten von Anwendungskennzeichen
+
+* die Unterstützung syntaktischer Nachrichtenkategorien (Dienstkennungen)
* die Unterstützung von Multikonnektor-Umgebungen
@@ -54,14 +55,14 @@ link:docs/Fachdienst.adoc[*Fachdienst*]
Der Mail Server stellt die Schnittstelle `I_Message_Service` bereit und wird über die Protokolle SMTP und POP3 angesprochen. In der KIM Version 1.5 wurden am Mail Server keine Änderungen vorgenommen.
* *Account Manager:* +
-Für die einfache Verwaltung des Accounts sowie das Einrichten von Abwesenheitsnotizen eines KIM-Teilnehmers bietet der Account Manager ab der KIM Version 1.5 zwei Webservices (`I_AccountManager_Service` und `I_AccountLimit_Service`) an.
+Für die einfache Verwaltung des Accounts, das Einrichten von Abwesenheitsnotizen eines KIM-Teilnehmers und für die Abfrage von Konfigurationsparametern des jeweiligen KIM Fachdienstes bietet der Account Manager ab der KIM Version 1.5 drei Webservices (`I_AccountManager_Service`, `I_AccountLimit_Service` und `I_ServiceInformation`) an.
-* *KOM-LE Attachment Service:* +
-Der Fachdienst wird um die Komponente KOM-LE Attachment Services (KAS) erweitert, der die sichere Speicherung größerer Client-Mails (E-Mail-Daten) ermöglicht. Die Komponente kann über die REST-Schnitstelle `I_Attachment_Service` erreicht werden.
+* *KIM Attachment Service:* +
+Der Fachdienst wird um die Komponente KIM Attachment Services (KAS) erweitert, der die sichere Speicherung größerer Client-Mails (E-Mail-Daten) ermöglicht. Die Komponente kann über die REST-Schnitstelle `I_Attachment_Service` erreicht werden.
link:docs/Verzeichnisdienst.adoc[*Verzeichnisdienst*]
-* Um die Kompatibilität von KIM 1.5 zu früheren Versionen zu gewährleisten, wird der Verzeichnisdienst um eine neue Datenstruktur `komLeData` ergänzt.
+* Um die Kompatibilität von KIM 1.5 zu früheren Versionen zu gewährleisten, wird der Verzeichnisdienst um die zusätzlichen Datenstrukturen `komLeData` und `kimData` ergänzt.
* Der Verzeichnisdienst wird um die REST-Schnittstelle `I_Directory_Application_Maintenance` erweitert.
== Ordnerstruktur
@@ -79,6 +80,7 @@ KIM-API
│ ├──── openapi
│ │ ├── AccountLimit.yaml
│ │ ├── AccountManager.yaml
+│ │ ├── AccountLimit_past.yaml
│ │ └── AttachmentServices.yaml
│ ├──── plantuml
│ │ └── Fachdienst
@@ -86,7 +88,8 @@ KIM-API
│ └── Attachment_schema.json
├── LICENSE
├── README.adoc
-└── ReleaseNotes.md
+├── ReleaseNotes.md
+└── SECURITY.adoc
----
== Ausbaustufen
@@ -96,7 +99,7 @@ Mit der Einführung von KIM unterstützt die gematik das Gesundheitswesen durch
|===
|KIM 1.0 |KIM 1.5
-|https://fachportal.gematik.de/schnelleinstieg/downloadcenter/releases#c6557[R3.1.3-2] |https://fachportal.gematik.de/schnelleinstieg/downloadcenter/releases#c6557[KIM 1.6.2-2]
+|https://fachportal.gematik.de/schnelleinstieg/downloadcenter/releases#c6557[R1.3.3-2] |https://fachportal.gematik.de/schnelleinstieg/downloadcenter/releases#c6557[KIM 1.6.2-2]
|===
Weitere Informationen zu den Versionen finden Sie hier: https://fachportal.gematik.de/anwendungen/kommunikation-im-medizinwesen[KIM]
@@ -114,7 +117,8 @@ Die nachfolgende Tabelle enthält die in der vorliegenden Online Dokumentation r
|*[gemSpec_FD]* |gematik: Spezifikation Fachdienst KOM-LE
|*[gemSpec_VZD]* |gematik: Spezifikation Verzeichnisdienst
|*[gemSpec_OM]* |gematik: Übergreifende Spezifikation Operations und Maintenance
-|*[gemProdT_CM_KOMLE_PTV]* | gematik: Produkttypsteckbrief Prüfvorschrift KOM-LE-Clientmodul
+|*[gemProdT_CM_KOMLE_PTV]* |gematik: Produkttypsteckbrief Prüfvorschrift KOM-LE-Clientmodul
+|*[gemProdT_iCM_KIM]* |gematik: Produkttypsteckbrief Prüfvorschrift Integriertes Clientmodul KIM
|===
== Weiterführende Seiten
diff --git a/docs/Anwendungsfaelle.adoc b/docs/Anwendungsfaelle.adoc
index ecc94ca..c92bdce 100644
--- a/docs/Anwendungsfaelle.adoc
+++ b/docs/Anwendungsfaelle.adoc
@@ -38,7 +38,7 @@ IMPORTANT: Alle Operationen die vom Administrationsmodul am Account Manager üb
=== Registrierung durchführen
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. 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).
+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.
@@ -62,7 +62,7 @@ Im folgenden Sequenzdiagramm ist die Interaktion zwischen Administrationsmodul u
++++
=== Deregistrierung zurücknehmen
-KIM-Teilnehmer können über das Frontend (GUI) des Administrationsmoduls eine ausgelöste Deregistrierung innerhalb von 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.
+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.
++++
@@ -105,6 +105,17 @@ Im folgenden Sequenzdiagramm ist die Interaktion zwischen Administrationsmodul u
++++
+== Anwendungskennzeichen
+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 Anwendungskennzeichens ruft das Administrationsmodul `setAccount()` am Account Manager auf. Für das Abfragen von konfigurierten Anwendungskennzeichen wird die Operation `getAccount()` 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.
+
+++++
+
+
+
+++++
+
== Abwesenheitnotizen
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.
@@ -128,7 +139,7 @@ Das Senden bzw. Empfangen von KIM-Mails wird durch die Schnittstelle `I_Message_
=== KIM-Mail senden
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 und mit dem asymmetrischen Schlüssel des Empfängers verschlüsselt und als KOM-LE Mail an den Fachdienst versendet. +
+Ü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:
@@ -141,7 +152,7 @@ Die folgende Abbildung veranschaulicht den beschriebenen Ablauf:
=== KIM-Mail empfangen
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, um mittels der Operation `read_Attachment()` die verschlüsselte Client-Mail vom KAS herunterzuladen. Anschließend wird die Client-Mail mit dem in der KOM-LE-Mail enthaltenen symmetrischen Schlüsseln entschlüsselt, der Hashwert berechnet und mit dem in der KIM-Attachment-Datenstruktur enthaltenen Hashwert 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. +
+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:
@@ -152,9 +163,12 @@ Das folgende Sequenzdiagramm stellt den Ablauf des Empfanges einer Nachricht dar
++++
== KIM-Dienstkennung
-Der KIM-Teilnehmer kann eine zu versendende Nachricht mit einer Dienstkennung - z. B. "eAU;Lieferung;v1.0" - versehen. Wird durch den Mailclient keine Dienstkennung übergeben wird vom Clientmodul ein default-Dienstkennung eingetragen ("KIM-Mail;Default;V1.0").
+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 Anwendungskennzeichen
+Der KIM-Teilnehmer kann für seinen e-Mail Account Anwendungskennzeichen konfigurieren, die dann durch den Acount Manager seines KIM Fachdienstes im Verzeichnisdienst in den KIM-Fachdaten für die betroffene Mail-Adresse eintragen werden. Der KIM-Teilnehmer nutzt dazu die in seinem KIM Clientmodule angebotene Konfigurations-Option. Für die Übertragung zum Verzeichnisdienst stellt der KIM Fachdienst eine Operation an der Schnittstelle `I_AccountManager_Service` des Account Manager zur Verfügung.
+
== Multikonnektor Umgebungen
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:
diff --git a/docs/Authentisierung.adoc b/docs/Authentisierung.adoc
index 7fcfe6c..bc7a352 100644
--- a/docs/Authentisierung.adoc
+++ b/docs/Authentisierung.adoc
@@ -23,5 +23,5 @@ Der Mail-Server nimmt SMTP-Nachrichten von Clientmodulen entgegen und leitet die
=== Account Manager
Der Accout Manager bietet für die Registrierung sowie die Kontoverwaltung eine Reihe von Operationen an. Die Operationen werden durch zwei REST-Schnittstellen (`I_AccountManager_Service` und `I_AccountLimit_Service`) am Account Managers bereitgestellt. Für den Aufruf der Operationen an der Schnittstelle `I_AccountManager_Service` durch das Administrationsmodul ist eine Authentifizierung des KIM-Teilnehmers notwendig. Für die Authentisierung erzeugt das Administrationsmodul ein JSON-Web-Token (JWT) gemäß *[RFC7519]* mit von der gematik definierten Elementen und übersendet dies mit dem Passwort des Nutzers an den Account Manager. Anschließend überprüft der Account Manager das ihm übergebene JWT auf Gültigkeit und Zugehörigkeit zur KIM-Mail-Adresse (Account). Die Anforderungen sind in *[gemSpec_CM_KOMLE#3.7.1]* und *[gemSpec_FD_KOMLE#4.3]* spezifiziert. Für den Aufruf der Operationen an der Schnittstelle `I_AccountLimit_Service` durch das Clientmodul ist eine HTTP-Basic-Authentifizierung mit Username und Passwort als Credentials am Account Manager erforderlich
-=== KOMLE-Attachment Service (KAS)
-Der KOMLE-Attachment Service (KAS) des Fachdienstes dient als Speicherort für verschlüsselte Anhänge von Mails. Das sendende Clientmodul legt Anhänge in verschlüsselter Form auf dem KAS ab. Hierfür ruft das Clientmodul die Operation `add_attachment()` auf. Um nur berechtigten KIM-Teilnehmern die Ablage von Anhängen zu ermöglichen, erfolgt eine Authentifizierung am KAS seines Anbieters. Hierfür wird bei Aufruf der Operation `add_attachment()` eine HTTP-Basic-Authentifizierung mit Username und Passwort als Credentials gefordert. Die Anforderungen sind in *[gemSpec_FD_KOMLE#4.2]* spezifiziert.
+=== KIM-Attachment Service (KAS)
+Der KIM-Attachment Service (KAS) des Fachdienstes dient als Speicherort für verschlüsselte E-Mail-Daten. Das sendende Clientmodul legt die E-Mail-Daten in verschlüsselter Form auf dem KAS ab. Hierfür ruft das Clientmodul die Operation `add_attachment()` auf. Um nur berechtigten KIM-Teilnehmern die Ablage von Anhängen zu ermöglichen, erfolgt eine Authentifizierung am KAS seines Anbieters. Hierfür wird bei Aufruf der Operation `add_attachment()` eine HTTP-Basic-Authentifizierung mit Username und Passwort als Credentials gefordert. Die Anforderungen sind in *[gemSpec_FD_KOMLE#4.2]* spezifiziert.
diff --git a/docs/Email_Verarbeitung.adoc b/docs/Email_Verarbeitung.adoc
index e98428d..5e07376 100644
--- a/docs/Email_Verarbeitung.adoc
+++ b/docs/Email_Verarbeitung.adoc
@@ -108,7 +108,7 @@ fHx3d3cuZGFzaW50ZXJuZXQubmV[...]
====
=== Client-Mail hochgeladen
-Von der korrigierten(*_From_* Header) und um die Dienstkennung erweiterte Mail wird eine Kopie angelegt, die die Basis für die an den Fachdienst zu übermittelnde KOM-LE Nachricht bildet. Anschließen wir modifizierte Client-Mail signiert und verschlüsselt und das binäre Ergebnis und durch Aufruf der Methode addAttachment auf den KIM Attachment Service hochgeladen. Nach einem erfolgreichen Upload ersetzt das KOM-LE Modul den Body der KOM-LE Nachricht durch die KIM Attachment Datenstruktur.
+Von der korrigierten (*_From_* Header) und um die Dienstkennung erweiterte Mail wird eine Kopie angelegt, die die Basis für die an den Fachdienst zu übermittelnde KOM-LE Nachricht bildet. Anschließen wir die modifizierte Client-Mail signiert und verschlüsselt und das binäre Ergebnis und durch Aufruf der Methode addAttachment auf den KIM Attachment Service hochgeladen. Nach einem erfolgreichen Upload ersetzt das KOM-LE Modul den Body der KOM-LE Nachricht durch die KIM Attachment Datenstruktur.
.KOM-LE Nachricht mit Attachment Datenstruktur
[%collapsible%open]
diff --git a/docs/Fachdienst.adoc b/docs/Fachdienst.adoc
index 4e3c901..fd84cf7 100644
--- a/docs/Fachdienst.adoc
+++ b/docs/Fachdienst.adoc
@@ -9,7 +9,7 @@ image:gematik_logo.svg[width=70%]
toc::[]
= Fachdienst
-Der Fachdienst besteht aus den drei Teilkomponenten Account Manager, Mail Server und dem KOM-LE-Attachment Service. Dieser stellt dem Clientmodul verschiedene Schnittstellen bereit, um die Kommunikations mit der jeweiligen Teilkomponente zu ermöglichen. In der folgenden Abbildung (links) sind alle Schnittstellen, die der Fachdienst anbietet, mit der jeweiligen Teilkomponente, dargestellt.
+Der Fachdienst besteht aus den drei Teilkomponenten Account Manager, Mail Server und dem KIM-Attachment Service. Dieser stellt dem Clientmodul verschiedene Schnittstellen bereit, um die Kommunikations mit der jeweiligen Teilkomponente zu ermöglichen. In der folgenden Abbildung (links) sind alle Schnittstellen, die der Fachdienst anbietet, mit der jeweiligen Teilkomponente, dargestellt.
++++
@@ -20,16 +20,17 @@ Der Fachdienst besteht aus den drei Teilkomponenten Account Manager, Mail Server
Im folgenden Kapitel werden die Teilkomponenten weiter beschrieben.
== Mail-Server
-Die Teilkomponente Mail-Server stellt die Schnittstelle `I_Message_Service` bereit. Diese wird über die Protokolle SMTP und POP3 aufgerufen. Die beim Mail-Server ankommenden E-Mails sind verschlüsselt, sodass nicht auf deren Inhalt geschlossen werden kann. Gehört eine dem Mail-Server übergebene E-Mail nicht zu einem lokalen Nutzer-Account, wird diese an den zuständigen KOM-LE Mail-Server weitergeleitet. Die Teilkomponente Mail Server des Fachdienstes ist in *[gemSpec_FD_KOMLE#4.1]* spezifiziert.
+Die Teilkomponente Mail-Server stellt die Schnittstelle `I_Message_Service` bereit. Diese wird über die Protokolle SMTP und POP3 aufgerufen. Die beim Mail-Server ankommenden E-Mails sind verschlüsselt, sodass nicht auf deren Inhalt geschlossen werden kann. Gehört eine dem Mail-Server übergebene E-Mail nicht zu einem lokalen Nutzer-Account, wird diese an den zuständigen KIM Mail-Server weitergeleitet. Die Teilkomponente Mail Server des Fachdienstes ist in *[gemSpec_FD_KOMLE#4.1]* spezifiziert.
== Account Manager
-Die Teilkomponente Account Manager ermöglicht die Konfiguration von Nutzer-Accounts am Fachdienst. Beginnend mit KIM 1.5 müssen die verschiedenen Clientmodule zu jedem Fachdienst interoperabel sein. Um dies zu gewährleisten, werden die Schnittstellen des Account Managers durch die gematik normiert. Die Schnittstelle `I_AccountManager_Service` ermöglicht eine einheitliche Durchführung der Registrierung eines KIM-Teilnehmers sowie die Verwaltung der Nutzer-Accounts. Für die Registrierung bzw. Kontoverwaltung wird das im Clientmodul integrierte Administrationsmodul genutzt, welches die Schnittstlle `I_AccountManager_Service` am Account Manager des Fachdienstes aufruft. Weitere Funktionen des Account Managers sind das Einstellen von Abwesenheitsnotizen durch einen KIM-Teilnehmer sowie die Portierung einer KIM-E-Mail zu einer neuen Telematik-ID. Für die Abfrage von technischen Konfigurationsparametern eines Nutzer-Accounts bietet der Account Manager dem Clientmodul die Schnittstelle `I_AccountLimit_Service` an. Für die Pflege der Fachdaten in den Verzeichniseinträgen ruft der Account Manager die REST-Schnittstelle `I_Directory_Application_Maintenance` auf. Die Teilkomponente Account Manager des Fachdienstes ist in *[gemSpec_FD_KOMLE#4.3]* spezifiziert.
+Die Teilkomponente Account Manager ermöglicht die Konfiguration von Nutzer-Accounts am Fachdienst. Beginnend mit KIM 1.5 müssen die verschiedenen Clientmodule zu jedem Fachdienst interoperabel sein. Um dies zu gewährleisten, werden die Schnittstellen des Account Managers durch die gematik normiert. Die Schnittstelle `I_AccountManager_Service` ermöglicht eine einheitliche Durchführung der Registrierung eines KIM-Teilnehmers sowie die Verwaltung der Nutzer-Accounts. Für die Registrierung bzw. Kontoverwaltung wird das im Clientmodul integrierte Administrationsmodul genutzt, welches die Schnittstlle `I_AccountManager_Service` am Account Manager des Fachdienstes aufruft. Weitere Funktionen des Account Managers sind das Einstellen von Abwesenheitsnotizen durch einen KIM-Teilnehmer sowie die Portierung einer KIM-E-Mail zu einer neuen Telematik-ID. Für die Abfrage von technischen Konfigurationsparametern eines Nutzer-Accounts bietet der Account Manager dem Clientmodul die Schnittstelle `I_AccountLimit_Service` an. Für die Abfrage von technischen Konfigurationsparametern des Fachdienstes bietet der Account Manager dem Clientmodul die Schnittstelle `I_ServiceInformation` an. Für die Pflege der Fachdaten in den Verzeichniseinträgen ruft der Account Manager die REST-Schnittstelle `I_Directory_Application_Maintenance` auf. Die Teilkomponente Account Manager des Fachdienstes ist in *[gemSpec_FD_KOMLE#4.3]* spezifiziert.
Die Beschreibung der REST-Schnittstelle `I_AccountManager_Service` ist hier zu finden: link:../src/openapi/AccountManager.yaml[AccountManager.yaml] +
-Die Beschreibung der REST-Schnittstelle `I_AccountLimit_Service` ist hier zu finden: link:../src/openapi/AccountLimit.yaml[AccountLimit.yaml]
+Die Beschreibung der REST-Schnittstelle `I_AccountLimit_Service` ist hier zu finden: link:../src/openapi/AccountLimit.yaml[AccountLimit.yaml] +
+Die Beschreibung der REST-Schnittstelle `I_ServiceInformation` ist hier zu finden: link:../src/openapi/ServiceInformation.yaml[ServiceInformation.yaml]
-== KOM-LE Attachment Service (KAS)
-Ab KIM 1.5 werden die E-Mail-Daten einer Mail, die größer 15 MiB ist, ausgelagert. Für die Ablage der E-Mail-Daten wird der Fachdienst um die Teilkomponente KOM-LE Attachment Service (KAS) erweitert. Die Teilkomponente KAS des Fachdienstes stellt dem Clientmodul die REST-Schnittstelle `I_Attachment_Service` bereit. Die Teilkomponente KAS ist in *[gemSpec_FD_KOMLE#4.2]* spezifiziert.
+== KIM Attachment Service (KAS)
+Ab KIM 1.5 werden die E-Mail-Daten einer Mail, die größer 15 MiB ist, ausgelagert. Für die Ablage der E-Mail-Daten wird der Fachdienst um die Teilkomponente KIM Attachment Service (KAS) erweitert. Die Teilkomponente KAS des Fachdienstes stellt dem Clientmodul die REST-Schnittstelle `I_Attachment_Service` bereit. Die Teilkomponente KAS ist in *[gemSpec_FD_KOMLE#4.2]* spezifiziert.
Die Beschreibung der REST-Schnittstelle `I_Attachment_Service` ist hier zu finden: link:../src/openapi/AttachmentService.yaml[AttachmentService.yaml]
diff --git a/docs/KIM_API.adoc b/docs/KIM_API.adoc
index 7199c91..10ee288 100644
--- a/docs/KIM_API.adoc
+++ b/docs/KIM_API.adoc
@@ -10,12 +10,12 @@ toc::[]
= Clientsystem
-Beginnend mit der KIM Version 1.5 werden weitere Funktionalitäten im Clientmodul bereitgestellt, die im folgenden Kapitel weiter beschrieben werden. Darüberhinaus kann ab dieser Version das Clientmodul optional in das Primärsystem integriert werden. Zur Sicherstellung der Interoperabilität zwischen den Clientmodulen und den Fachdiensten wird eine weitere Schnittstelle durch die gematik am Account Manager normativ festgelegt. Diese wird durch das Administrationsmodul aufgerufen und ermöglicht die Konfiguration der Nutzer-Accounts.
+Beginnend mit der KIM Version 1.5 werden weitere Funktionalitäten im Clientmodul bereitgestellt, die im folgenden Kapitel näher beschrieben werden. Darüber hinaus kann ab dieser Version das Clientmodul optional in das Primärsystem integriert werden. Zur Sicherstellung der Interoperabilität zwischen den Clientmodulen und den Fachdiensten wird eine Schnittstelle (`I_AccountManager_Service`) durch die gematik am Account Manager normativ festgelegt. Diese wird durch das Administrationsmodul aufgerufen und ermöglicht die Konfiguration der Nutzer-Accounts.
== Änderungen im Clientmodul ab KIM 1.5
=== Optionale Integration in das Clientsystem
-Ab der KIM Version 1.5 ist es möglich das Clientmodul in ein Clientsystem zu integrieren. Ein seperates Clientmodul ist in diesem Fall nicht mehr notwendig.
+Ab der KIM Version 1.5 ist es möglich das Clientmodul in ein Clientsystem zu integrieren. Ein seperates Clientmodul ist in diesem Fall nicht mehr notwendig. Zur Sicherstellung einer spezifikationskonformen Umsetzung der Intergration in das Clientsystem wird durch die gematik ein entsprechender Prokttypsteckbrief (gemProdT_iCM_KIM) bereitgestellt.
=== Umgang mit E-Mail-Kategorien
@@ -25,11 +25,11 @@ Eine Übersicht über alle Dienstkennungen kann hier eingesehen werden: link:htt
=== Umgang mit großen Anhängen
-E-Mails mit einer Gesamtgröße bis zu 15 MiB werden entsprechend den Festlegungen im KIM 1.0 behandelt. Übersteigt die Größe einer E-Mail die 15 MiB Grenze, wird die gesamte Client-Mail auf dem KOM-LE-Attachment-Service (KAS) des Fachdiensts des Absenders abgelegt. Das Clientmodul ersetzt den Body der originalen Mail mit der KIM-Attachment Datenstruktur und versendet diese nach der weiteren Verarbeitung durch das Clientmodul als KOM-LE Nachricht an den Fachdienst. Das KIM-Clientmodul des Empfängers erkennt den Link in der KIM-Attachment Datenstruktur, lädt die E-Mail-Daten vom KAS des Absenders und entschlüsselt sie. Die damit wieder hergestellte originale Client-Mail wird dem Mail-Client des Empfängers zugestellt. Der Umgang mit großen Anhängen ist in *[gemSpec_CM_KOMLE#3.2]* spezifiziert. Die vom KAS dazu bereitgestellte Schnittstelle wird im folgenden genauer beschrieben.
+E-Mails mit einer Gesamtgröße bis zu 15 MiB werden entsprechend den Festlegungen im KIM 1.0 behandelt. Übersteigt die Größe einer E-Mail die 15 MiB Grenze, wird die gesamte Client-Mail, durch das Clientmodul des Senders verschlüsselt, auf dem KIM-Attachment-Service (KAS) des Fachdiensts des Absenders abgelegt. Das Clientmodul ersetzt den Body der originalen Mail mit der KIM-Attachment Datenstruktur (*[gemSpec_CM_KOMLE#Tabelle 2]*) und versendet diese nach der weiteren Verarbeitung durch das Clientmodul als KIM Nachricht an den Fachdienst. Das KIM-Clientmodul des Empfängers erkennt den `link` in der KIM-Attachment Datenstruktur, lädt die E-Mail-Daten vom KAS des Absenders und entschlüsselt sie. Die damit wieder hergestellte originale Client-Mail wird dem Mail-Client des Empfängers zugestellt. Der Umgang mit großen Anhängen ist in *[gemSpec_CM_KOMLE#3.2]* spezifiziert. Die vom KAS dazu bereitgestellte Schnittstelle wird im folgenden genauer beschrieben.
==== I_Attachment_Service
-Über die Schnittstelle `I_Attachment_Service` stellt der KAS dem Clientmodul die logischen Operationen `add_Attachment()`, und `read_Attachment()` zum Hoch- und Herunterladen von verschlüsselten E-Mail-Daten zur Verfügung. Im folgenden Kapitel wird der Aufruf der Operationen beschrieben.
+Über die Schnittstelle `I_Attachment_Service` stellt der KAS dem Clientmodul die logischen Operationen `add_Attachment()`, und `read_Attachment()` zum Hoch- und Herunterladen von verschlüsselten E-Mail-Daten sowie die Operation `delete_Maildata` für das Löschen der E-Mail-Daten, unmittelbar nach dem Hochladen, zur Verfügung. Im folgenden Kapitel wird der Aufruf der Operationen beschrieben.
//image:I_KAS.png[width=45%]
@@ -166,6 +166,56 @@ Body:
|Internal Server Error
|===
+===== delete_Maildata() +
+Mit Hilfe der Opertion `delete_Maildata()` kann ein Clientmodul die auf dem KAS abgelegten E-Mail Daten, im Falle des fehlerhaften Versands der dazugehörenden KIM-Nachricht, wieder löschen.
+
+*Beispiel einer HTTP Nachricht*
+
+[cols="h,a",]
+|===
+|URI |\https://kas.hrst1.kim.telematik/attachments/v2.3/attachment/+{attachmentId}+ +
+[normal]#`attachmentId` - Freigabelink, unter dem die E-Mail-Daten gespeichert wurden#
+|Method |DELETE
+|Header |
+[source, bash]
+----
+HTTP-Version: "HTTP/1.1"
+Content-Type: "multipart/form-data"
+Authorization: "Basic Z2VtYXRpazpraW0="
+----
+|Body |
+keine Parameter
+|===
+
+*Beispielabfrage:*
+[source, bash]
+-----------------
+curl -X 'DELETE' \
+'https://kas.hrst1.kim.telematik/attachments/v2.3/attachment/b2deea19-c37f-4ef0-a95f-d4e8b5817824' \
+-H 'accept: application/octet-stream' \
+-----------------
+
+*Beispielantwort*
+[source, ruby]
+-----------------
+Code: 200
+-----------------
+
+*HTTP-Status Codes:*
+|===
+|Status |Bedeutung
+
+|200 | OK +
+[small]#Daten wurden gelöscht#
+|400 | Bad Request +
+[small]#Fehler in den Eingangsdaten, Beschreibung des Fehlers erfolgt in dem Fehlertext#
+|401 | Unauthorized +
+[small]#Authentifizierung fehlgeschlagen.#
+|404 |no Ressource +
+[small]#Ressource unter dem angegebenen Link nicht gefunden#
+|500
+|Internal Server Error
+|===
==== I_AccountLimit_Service
Über die Schnittstelle `I_AccountLimit_Service` stellt der Account Manager dem Clientmodul die logische Operationen `getLimits()` zur Abfrage von technisch konfigurierbaren Parametern eines Nutzer-Accounts zur Verfügung.
@@ -215,6 +265,7 @@ Body:
{
"dataTimeToLive": 90,
"maxMailSize": 734003200,
+ "kasMailSizeThreshold": 15728640;
"quota": 160000000000,
"remainQuota": 112000000000
}
@@ -274,15 +325,17 @@ Mittels der Operation `registerAccount()` wird die Registrierung eines KIM-Teiln
"username": "user@example.kim.telematik",
"password": "new_password",
"kimVersion": "1.5"
+ "appTags": ""
}
----
[normal]#`referenceID` - Referenz eines KIM-Teilnehmers# +
[normal]#`username` - E-Mail Adresse eines KIM-Teilnehmers# +
[normal]#`password` - Neues Passwort festlegen# +
-[normal]#`kimVersion` - Die vom Clientmodul eingesetzte KIM-Version#
+[normal]#`kimVersion` - Die vom Clientmodul eingesetzte KIM-Version# +
+[normal]#`appTags` - Die vom KIM-Teilnehmers unterstützte/n Anwendung/en#
|===
-*Beispielabfrage:*
+*Beispielaufruf:*
[source, bash]
-----------------
curl -X 'POST' \
@@ -295,6 +348,7 @@ curl -X 'POST' \
"username": "user@example.kim.telematik",
"password": "new_password",
"kimVersion": "1.5"
+ "appTags": "eAU"
}'
-----------------
@@ -460,6 +514,7 @@ Die Operation `setAccount()` ermöglicht die Verwaltung eines Accounts eines KIM
"username": "user@example.kim.telematik",
"password": "password",
"kimVersion": "1.5",
+ "appTags": ""
"dataTimeToLive": 90
}
----
@@ -467,6 +522,7 @@ Die Operation `setAccount()` ermöglicht die Verwaltung eines Accounts eines KIM
[normal]#`username` - E-Mail Adresse eines KIM-Teilnehmers# +
[normal]#`password` - Neues Passwort festlegen# +
[normal]#`kimVersion` - Die vom Clientmodul eingesetzte KIM-Version# +
+[normal]#`appTags` - Die vom KIM-Teilnehmers unterstützte/n Anwendung/en# +
[normal]#`dataTimeToLive` - Speicherdauer in Tagen von Mails und Anhängen auf dem Fachdienst#
|===
@@ -483,6 +539,7 @@ curl -X 'PUT' \
"username": "user@example.kim.telematik",
"password": "password",
"kimVersion": "1.5",
+ "appTags": "eAU",
"dataTimeToLive": 90
}'
-----------------
@@ -555,7 +612,10 @@ Body:
"username": "user@example.kim.telematik",
"kimVersion": "1.5",
"regStat": "registered",
- "deregDate": 1616588543
+ "deregDate": 1616588543,
+ "maxMailSize": 734003200,
+ "appTags": "eAU",
+ "dataTimeToLive": 90
}
-----------------
diff --git a/docs/Primaersystem.adoc b/docs/Primaersystem.adoc
index 99a6045..e6c999e 100644
--- a/docs/Primaersystem.adoc
+++ b/docs/Primaersystem.adoc
@@ -49,8 +49,8 @@ Das folgende Komponentendiagramm stellt die Abhängigkeitsbeziehungen zwischen d
//image:Int_PS-KOMLE.png[width=50%]
++++
-
-
+
+
++++
@@ -66,21 +66,11 @@ In der folgenden Abbildung sind die vom Primärsystem umzusetzenden KIM-Anwendun
//image:UC_PS-KOMLE.png[width=40%]
++++
-
-
+
+
++++
-=== Nachrichten generieren und übernehmen
-Die Eingabe des Nachrichtentextes der vom Nutzer erzeugten E-Mail und/oder das Anfordern einer Zustellbestätigung wird im Primärsystem vorgenommen.
-Als Anhänge einer KIM-Nachricht kommen neben unsignierten Dokumenten auch signierte Dokumente (qualifizierte) in Frage. Alle Anhänge können, abhängig vom verwendeten Schlüsselmaterial, separat für Leistungserbringer oder Leistungserbringerinstitutionen verschlüsselt werden.
-
-* *Nachrichtengenerierung im Primärsystem* +
-Es ist erforderlich, dass das Primärsystem dem Benutzer ermöglicht eine KIM-E-Mail (inkl. weiterer Anhänge) zu erzeugen. Insbesondere Arztbriefe, wie der VhitG-Arztbrief, können direkt aus dem Primärsystem bzw. der Behandlungsdokumentation heraus erzeugt und editiert werden.
-
-* *E-Mail-Kategorisierung im Primärsystem* +
-Es ist erforderlich, dass das Primärsystem dem Benutzer ermöglicht, eine KIM-E-Mail entsprechend zu kategorisieren. Erfolgt keine Kategorisierung durch den Nutzer, wird automatisch vom Clientmodul eine Standard-Kategorie verwendet. Die Kategorien können aus dem link:https://fachportal.gematik.de/service/dienstkennung-kim-kom-le/[Fachportal] der gematik entnommen werden.
-
=== Empfänger ermitteln
Es können nur KIM-E-Mails an Empfänger versendet werden, die als Teilnehmer im Verzeichnisdienst aufgenommen und deren Verschlüsselungszertifikate sowie deren KIM-E-Mail-Adressen hinterlegt sind.
@@ -112,12 +102,27 @@ Mittels der Suchkriterien kann das Primärsystem die KIM-E-Mail-Empfänger im Ve
Aus den Resultaten der LDAP-Suche übernimmt das Primärsystem die E-Mail-Adresse des gewünschten Empfängers. Falls es mehrere
Suchergebnisse gibt, werden die Ergebnisinformationen dem Nutzer vollständig angezeigt, damit dieser die gewünschte E-Mail-Adresse auswählt.
+* *Berücksichtigung des/der Anwendungskennzeichen des Empfängers* +
+Es ist erforderlich, dass das Primärsystem die im Suchergebnis enthaltenen Anwendungskennzeichen, die ein KIM Teilnehmer im VZD für seinen Eintrag hinterlegt hat, berücksichtigt. Erkennt das Primärsystem, dass für die verwendete Anwendung kein Eintragung im VZD Eintrag des beabsichtigten Empfängers vorliegt, dann ist es erforderlich den Nutzer darüber zu informieren und der Versand per Mail ist abzulehnen.
+
+=== Nachrichten generieren und übernehmen
+Die Eingabe des Nachrichtentextes der vom Nutzer erzeugten E-Mail und/oder das Anfordern einer Zustellbestätigung wird im Primärsystem vorgenommen.
+Als Anhänge einer KIM-Nachricht kommen neben unsignierten Dokumenten auch signierte Dokumente (qualifizierte) in Frage. Alle Anhänge können, abhängig vom verwendeten Schlüsselmaterial, separat für Leistungserbringer oder Leistungserbringerinstitutionen verschlüsselt werden.
+
+* *Nachrichtengenerierung im Primärsystem* +
+Es ist erforderlich, dass das Primärsystem dem Benutzer ermöglicht eine KIM-E-Mail (inkl. weiterer Anhänge) zu erzeugen. Insbesondere Arztbriefe, wie der VhitG-Arztbrief, können direkt aus dem Primärsystem bzw. der Behandlungsdokumentation heraus erzeugt und editiert werden.
+Die Nachrichten müssen konform zu RFC5322 erzeugt werden (https://www.rfc-editor.org/rfc/rfc5322.html[RFC5322]). Dies gilt insbesondere für die Header-Elemente der Mail-Nachricht.
+Die message-id ist für KIM-Nachrichten nicht optional und muss gemäß https://www.rfc-editor.org/rfc/rfc5322.html#section-3.6.4[RFC5322 Kapitel 3.6.4] erzeugt werden.
+
+* *E-Mail-Kategorisierung im Primärsystem* +
+Es ist erforderlich, dass das Primärsystem dem Benutzer ermöglicht, eine KIM-E-Mail entsprechend zu kategorisieren. Erfolgt keine Kategorisierung durch den Nutzer, wird automatisch vom Clientmodul eine Standard-Kategorie verwendet. Die Kategorien können aus dem link:https://fachportal.gematik.de/service/dienstkennung-kim-kom-le/[Fachportal] der gematik entnommen werden und abhängig von der zu versendenden Nachricht in dem Attribut `X-KIM-Dienstkennung` als zusätzliches Header Element in die Nachricht eingetragen.
+
=== Nachrichten versenden
Der Versand von KIM–Nachrichten erfolgt über das Clientmodul, das die Nachricht für jeden Empfänger zuerst signiert und anschließend verschlüsselt. +
TIP: In der KIM Version 1.0 darf die Gesamtgröße einer KIM-Nachricht inkl. Anhänge 15 MiB nicht überschreiten.
-Die Einschränkung auf 15 MiB ist auf die Leistung des Konnektors zurückzuführen, der für die Ausführung von kryptographischen Operationen größer 15 MiB nicht ausgelegt ist. Ab KIM 1.5 ist es möglich Nachrichten mit größeren Anhängen zu versenden. Hierfür übernimmt das Clientmodul, anstelle des Konnektors, die Verschlüsselung der auf den KAS ausgelagerten E-Mail-Daten.
+Die Einschränkung auf 15 MiB ist auf die Leistung des Konnektors zurückzuführen, der für die Ausführung von kryptographischen Operationen größer 15 MiB nicht ausgelegt ist. Ab KIM 1.5 ist es möglich Nachrichten mit einer Gesamtgröße größerals 15 MiB zu versenden. Hierfür übernimmt das Clientmodul, anstelle des Konnektors, die Verschlüsselung der dann auf den KAS ausgelagerten E-Mail-Daten.
* *E-Mail-Versand als Funktion des Primärsystems* +
Es ist erforderlich, dass das Primärsystem die zu versendende Nachricht aus seinem E-Mail-Modul heraus versendet.
@@ -204,6 +209,8 @@ _„Die Nachricht wurde nur an einen Teil der gewünschten Adressaten versendet,
=== Nachrichten empfangen
Der Empfang von KIM-Nachrichten erfolgt über das Clientmodul, das die Nachricht für den Empfänger entschlüsselt, sofern die dafür erforderliche Smartcard/HSM im System registriert und freigeschaltet ist.
+==== Voraussetzungen
+
* *Nutzerkreis der KIM-E-Mail-Adresse beim Nachrichtenempfang* +
Es ist erforderlich, dass die Nutzerverwaltung des Primärsystems sicherstellt, dass der Zugriff auf empfangene KIM-Nachrichten nur durch autorisierte Personen erfolgt.
@@ -211,6 +218,21 @@ Es ist erforderlich, dass die Nutzerverwaltung des Primärsystems sicherstellt,
Für den Empfang entschlüsselter Nachrichten ist es erforderlich, dass Smartcards/HSMs freigeschaltet vorliegen. Ohne diese Freischaltung können Nachrichten nicht entschlüsselt entgegengenommen werden. Es ist erforderlich, dass das Primärsystem den Status der Freischaltung
der Smartcards sichtbar macht. Ebenfalls ist es erforderlich, dass der Benutzer darauf aufmerksam gemacht wird, dass er zum Empfang entschlüsselter Nachrichten diese Smartcards freischalten muss.
+* *Nachrichten mittels POP3 abholen* +
+Es ist erforderlich, dass das Primärsystem gemäß *[RFC2449]* dem Clientmodul POP3-Anfragen zusenden kann sowie POP3-Antwortcodes von ihm erhält.
+
+* *Anzeige entgegengenommener Nachrichten* +
+Es ist erforderlich, dass das Primärsystem empfangene Nachrichten entgegennehmen kann sowie eine Anzeige der Nachricht ermöglicht.
+
+* *E-Mail-Anhänge darstellen* +
+Es ist erforderlich, dass das Primärsystem mindestens E-Mail-Anhänge in den Standardformaten `PDF`, `JPEG`, `GIF`, `TXT` und `DOC` anzeigen kann.
+
+* *E-Mail-Anhänge verarbeiten* +
+Es ist erforderlich, dass das Primärsystem E-Mail-Anhänge, wie zum Beispiel den VhitG-Arztbrief, weiter verarbeiten kann und dabei Methoden der
+Patientenidentifikation benutzt.
+
+==== Login
+
Das Primärsystem übergibt dem Clientmodul in der POP3-Kommunikation alle zum Nachrichtenempfang erforderlichen Informationen.
Auch für die Abholung von Nachrichten ist es erforderlich, dass Angaben über die Ansteuerung der Smartcards des Empfängers
innerhalb der POP3-Authentifizierung übergeben werden.
@@ -242,30 +264,26 @@ erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:995#1#KOM_LE
TIP: Erfolgt die Einbindung von KIM in ein bestehendes Mail-Systeme, kann ein übergebener Delimiter ":" zwischen dem Serveranteil und dem Port (z. B. hrst_domain.kim.telematik:9959) des POP3-Benutzernamens zu Fehlern bei der Interpretation im Bestandsystem führen. Es werden daher weitere Delimiter im Benutzernamen unterstützt, sofern die Funktionalität gemäß der Bestandsanforderungen zu den Benutzernamen, in semantischer Abgrenzung, uneingeschränkt erhalten bleiben. Es gilt, dass die Bestandteile des POP3-Benutzernames in ihrem semantischen Bezug gemäß [RFC1123, RFC2822] einhalten müssen.
+==== Ablauf
+
Die folgende POP3-Kommunikation erfolgt gemäß POP3-Protokoll über das Clientmodul.
Das Clientmodul leitet die POP3-Anfragen des Primärsystems an den KIM-Fachdienst (MTA) weiter und entschlüsselt abgeholte Nachrichten,
um sie in entschlüsselter und verifizierter Form an das Primärsystem weiterzugeben.
-Enthält eine KIM-Nachricht externe Anhänge die auf einem KAS abgelegt wurden, so werden diese in KOM-LE 1.5 vom Clientmodul automatisch heruntergeladen und für das Primärsystem in die KIM-E-Mail eingefügt.
+Primärsysteme dürfen nur bisher unbekannte KIM-Nachrichten abrufen. Durch den folgenden Ablauf können die unbekannten KIM-Nachrichten abgefragt werden:
-* *Nachrichten mittels POP3 abholen* +
-Es ist erforderlich, dass das Primärsystem gemäß *[RFC2449]* dem Clientmodul POP3-Anfragen zusenden kann sowie POP3-Antwortcodes von ihm erhält.
-
-* *Anzeige entgegengenommener Nachrichten* +
-Es ist erforderlich, dass das Primärsystem empfangene Nachrichten entgegennehmen kann sowie eine Anzeige der Nachricht ermöglicht.
+* Das PS sendet POP3 LIST an das Clientsystem. Es werden alle Message-IDs und die Größe der Nachrichten abgefragt
+* Das PS prüft anhand der empfangenen Message-IDs ob die Nachricht im PS bekannt ist und ermittelt so die Message-IDs der unbekannten Nachrichten
+* Das PS sendet POP3 RETR an das Clientsystem für alle unbekannten Message-IDs. Die Message-ID der empfangenen Nachricht wird lokal gespeichert, damit sie bei folgenden Nachrichtenabrufen nicht erneut abgefragt wird.
-* *E-Mail-Anhänge darstellen* +
-Es ist erforderlich, dass das Primärsystem mindestens E-Mail-Anhänge in den Standardformaten `PDF`, `JPEG`, `GIF`, `TXT` und `DOC` anzeigen kann.
+Im KIM-Postfach eines Nutzers können Nachrichten mit verschiedenen, für das Primärsystem bekannten oder unbekannten, Dienstkennungen eingehen. Das bedeutet, dass unter Umständen die Nutzung weiterer Dienstkennung als die link:https://fachportal.gematik.de/toolkit/dienstkennung-kim-kom-le[hier] genannten möglich sein muss. KIM Nachrichten werden vom Primärsystem i.d.R. innerhalb einer bestimmten Primärsystemanwendungen angezeigt bzw. verarbeitet, sofern die Dienstkennung unterstützt wird.
-* *E-Mail-Anhänge verarbeiten* +
-Es ist erforderlich, dass das Primärsystem E-Mail-Anhänge, wie zum Beispiel den VhitG-Arztbrief, weiter verarbeiten kann und dabei Methoden der
-Patientenidentifikation benutzt.
+Die KIM-Adresse kann an mehreren Primärsystem-Arbeitsplätzen genutzt werden. Daher kann es erforderlich sein, dass die Nachrichten nach dem Empfang nicht auf dem Server gelöscht werden, damit sie auch von anderen Arbeitsplätzen empfangen werden können. Nachrichten älter als 90 Tage werden auf dem Mail-Server automatisch gelöscht. Der Nutzer kann die Aufbewahrungszeit der Nachrichten über die Administrationsoberfläche des Clientmoduls anpassen.
-Im KIM-Postfach eines Nutzers können Nachrichten mit verschiedenen, für das Primärsystem bekannten oder unbekannten, Dienstkennungen eingehen. Das bedeutet, dass unter Umständen die Nutzung weiterer Dienstkennung als die link:https://fachportal.gematik.de/toolkit/dienstkennung-kim-kom-le[hier] genannten möglich sein muss. KIM Nachrichten werden vom Primärsystem i.d.R. innerhalb einer bestimmten Primärsystemanwendungen angezeigt bzw. verarbeitet, sofern die Dienstkennung unterstützt wird.
+Es ist erforderlich, dass das Primärsystem auch KIM-Nachrichten von nicht unterstützten Dienstkennungen dem Anwender zur Anzeige bringen kann, sodass der Anwender in jedem Fall Kenntnis über alle KIM-Nachrichten in seinem KIM-Postfach erhalten kann.
-* *Umgang mit unbekannten Dienstkennungen* +
-Es ist erforderlich, dass das Primärsystem auch KIM-Nachrichten von nicht unterstützten Dienstkennungen dem Anwender zur Anzeige bringen, sodass der Anwender in jedem Fall Kenntnis über alle KIM-Nachrichten in seinem KIM-Postfach erhält.
+TIP: Um nur bestimmte KIM Nachrichten an einem Arbeitsplatz zu verarbeiten, muss das PS dem Nutzer ermöglichen auszuwählen, welche KIM-Anwendungen an einem bestimmten PS-Arbeitsplatz verwendet werden (KIM Dienstkennungen). Für den Nachrichtenabruf kann das PS anstatt POP3 RETR zunächst mit POP3 TOP 0 nur die Header der Nachricht abfragen, um zu prüfen, welche Dienstkennung die Nachricht hat. Falls die Nachricht eine Dienstkennung hat, die an diesem Arbeitsplatz verarbeitet werden soll, kann die vollständige Nachricht mit POP3 RETR empfangen werden. Die Message-ID der Nachricht muss lokal gespeichert werden, um einen erneuten Abruf zu verhindern.
== Integration des Clientmoduls in das Primärsystem
Ab KIM 1.5 ist es möglich, die Funktionalität des Clientmoduls in das Primärsystem zu integrieren. Somit ist kein separates Clientmodul mehr notwendig. Die folgende Abbildung stellt eine mögliche Integration dar:
diff --git a/docs/Verzeichnisdienst.adoc b/docs/Verzeichnisdienst.adoc
index 3110a29..d4e1085 100644
--- a/docs/Verzeichnisdienst.adoc
+++ b/docs/Verzeichnisdienst.adoc
@@ -17,7 +17,7 @@ image:gematik_logo.svg[width=70%]
toc::[]
== Verzeichnisdienst
-Ab der KIM Version 1.5 können zur Abfrage der KIM-Fachdaten ausschließlich die Protokolle LDAPv3 und HTTP (REST) an der Schnittstelle `I_Directory_Application_Maintenance` am Verzeichnisdienst verwenden werden. Zu den Fachdaten gehören die KIM-Mail-Adressen, sowie die verwendete KOM-LE-Version der Clientmodule. Ausgehend von dieser Version entscheidet das Clientmodul des Senders, ob das Clientmodul des Empfängers kompatibel ist. Die neue Datenstruktur `komLeData` ist in *[gemSpec_VZD#5]* spezifiziert.
+Ab der KIM Version 1.5 können zur Abfrage der KIM-Fachdaten ausschließlich die Protokolle LDAPv3 und HTTP (REST) an der Schnittstelle `I_Directory_Application_Maintenance` am Verzeichnisdienst verwenden werden. Zu den Fachdaten gehören die KIM-Mail-Adressen, die verwendete KOM-LE-Version der Clientmodule sowie ein oder mehrere Anwendungskennzeichen. Ausgehend von dieser KOM-LE-Version entscheidet das Clientmodul des Senders, ob das Clientmodul des Empfängers kompatibel ist. Mit dem Hinterlegen eines oder mehrerer Anwendungskennzeichen signalisiert der jeweilige KIM Teilnehmer die Möglichkeit Nachrichten im Rahmen spezieller Anwendungen (z. B. eAU, eArztbrief u.a.) entgegenzunehmen und zu verarbeiten. Ein Primär- bzw. Clientsystem kann, mit Kenntnis der für einen geplanten Empfänger hinterlegten Anwendungskennzeichen, bereits bei der Erstellung einer Nachricht entscheiden ob diese vom Empfänger verarbeitet werden kann und die Bearbeitung im Negativfall abbrechen. Die neuen Datenstrukturen `komLeData` und `kimData` sind in *[gemSpec_VZD#5]* spezifiziert.
Die Beschreibung der REST-Schnittstelle `I_Directory_Application_Maintenance` für KIM ist hier zu finden: link:https://github.com/gematik/api-vzd/blob/main/src/openapi/DirectoryApplicationMaintenance.yaml[DirectoryApplicationMaintenance.yaml]
@@ -26,8 +26,8 @@ Im Folgenden sind die LDAP-Directory-Attribute der KIM-Fachdaten dargestellt: +
//image:KOMLE_Fachdaten.PNG[width=45%]
++++
-
-
+
+
++++
diff --git a/images/CM_Integration.png b/images/CM_Integration.png
index 9bceaa7..00c7603 100644
Binary files a/images/CM_Integration.png and b/images/CM_Integration.png differ
diff --git a/images/I_Fachdienst.png b/images/I_Fachdienst.png
index e2c6366..c5f2951 100644
Binary files a/images/I_Fachdienst.png and b/images/I_Fachdienst.png differ
diff --git a/images/I_KAS.png b/images/I_KAS.png
index 3174734..f262f76 100644
Binary files a/images/I_KAS.png and b/images/I_KAS.png differ
diff --git a/images/Int_PS-KIM.svg b/images/Int_PS-KIM.svg
new file mode 100644
index 0000000..e0a1741
--- /dev/null
+++ b/images/Int_PS-KIM.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/images/KOMLE_Fachdaten.svg b/images/KOMLE_Fachdaten.svg
new file mode 100644
index 0000000..e8e5d5e
--- /dev/null
+++ b/images/KOMLE_Fachdaten.svg
@@ -0,0 +1,129 @@
+
+
+
+
diff --git a/images/Seq_acc_anwendungskennzeichen.png b/images/Seq_acc_anwendungskennzeichen.png
new file mode 100644
index 0000000..c1c7062
Binary files /dev/null and b/images/Seq_acc_anwendungskennzeichen.png differ
diff --git a/images/UC_PS-KIM.svg b/images/UC_PS-KIM.svg
new file mode 100644
index 0000000..d08b05e
--- /dev/null
+++ b/images/UC_PS-KIM.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/images/diagrams/Fachdienst/Seq_acc_anwendungskennzeichen.png b/images/diagrams/Fachdienst/Seq_acc_anwendungskennzeichen.png
new file mode 100644
index 0000000..c1c7062
Binary files /dev/null and b/images/diagrams/Fachdienst/Seq_acc_anwendungskennzeichen.png differ
diff --git a/images/diagrams/Fachdienst/Seq_acc_anwendungskennzeichen.svg b/images/diagrams/Fachdienst/Seq_acc_anwendungskennzeichen.svg
new file mode 100644
index 0000000..7e8740f
--- /dev/null
+++ b/images/diagrams/Fachdienst/Seq_acc_anwendungskennzeichen.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/images/diagrams/Fachdienst/Seq_kas_email_senden.svg b/images/diagrams/Fachdienst/Seq_kas_email_senden.svg
index b11eab5..580c15d 100644
--- a/images/diagrams/Fachdienst/Seq_kas_email_senden.svg
+++ b/images/diagrams/Fachdienst/Seq_kas_email_senden.svg
@@ -1,82 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/images/diagrams/eMail_status_empfangen.svg b/images/diagrams/eMail_status_empfangen.svg
index c4d331f..dbe1128 100644
--- a/images/diagrams/eMail_status_empfangen.svg
+++ b/images/diagrams/eMail_status_empfangen.svg
@@ -1,46 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/images/kas_overview.png b/images/kas_overview.png
index 27a2ed5..7463b11 100644
Binary files a/images/kas_overview.png and b/images/kas_overview.png differ
diff --git a/images/kim_overview.png b/images/kim_overview.png
index 6678146..4f81a82 100644
Binary files a/images/kim_overview.png and b/images/kim_overview.png differ
diff --git a/src/plantuml/Fachdienst/Seq_acc_anwendungskennzeichen.puml b/src/plantuml/Fachdienst/Seq_acc_anwendungskennzeichen.puml
new file mode 100644
index 0000000..086189f
--- /dev/null
+++ b/src/plantuml/Fachdienst/Seq_acc_anwendungskennzeichen.puml
@@ -0,0 +1,58 @@
+/'
+# KIM 1.5
+# Account Manager
+# Sequence Diagram
+# Name: Operation Abwesenheitsnotiz
+'/
+
+@startuml
+skinparam sequenceMessageAlign direction
+skinparam minClassWidth 200
+skinparam BoxPadding 15
+skinparam sequenceReferenceHeaderBackgroundColor palegreen
+scale max 2048 width
+hide footbox
+
+skinparam sequence {
+ArrowColor black
+ArrowFontSize 17
+ActorBorderColor black
+LifeLineBorderColor black
+LifeLineBackgroundColor Gainsboro
+
+ParticipantBorderColor Motivation
+ParticipantBackgroundColor Motivation
+ParticipantFontSize 20
+ParticipantFontColor black
+ParticipantBorderColor Black
+ParticipantBackgroundColor MOTIVATION
+
+ActorBackgroundColor Gainsboro
+ActorFontColor black
+ActorFontSize 20
+ActorFontName Aapex
+}
+ actor L as "Leistungserbringer"
+ box Clientmodul\n #WhiteSmoke
+ participant A as "Administrationsmodul"
+ end box
+ box Fachdienst\n #WhiteSmoke
+ participant AM as "Account-Manager"
+ end box
+
+L->A: Anwendungskennzeichen \nkonfigurieren
+ activate A
+ A->AM: getAccount
+ activate AM
+ AM --> A: Konfiguration
+ deactivate AM
+
+ opt Anwendungskennzeichen bearbeiten
+ A->AM: setAccount
+ activate AM
+ AM --> A: status
+ deactivate AM
+ end
+ A-->L: status
+ deactivate A
+@enduml
\ No newline at end of file
diff --git a/src/plantuml/Fachdienst/Seq_kas_email_senden.puml b/src/plantuml/Fachdienst/Seq_kas_email_senden.puml
index dd087e1..5ff3bb4 100644
--- a/src/plantuml/Fachdienst/Seq_kas_email_senden.puml
+++ b/src/plantuml/Fachdienst/Seq_kas_email_senden.puml
@@ -64,7 +64,7 @@ L->P: Email mit großen\n Anhängen erzeugen
K->K: Berechtigung prüfen
K->K: Dateigröße prüfen
K->K: Freigabelink erzeugen
- K->K: E-Mail ablegen
+ K->K: E-Mail Daten ablegen
K-->KM: Freigabelink
deactivate K
KM->KM: KIM-Attachment-Datenstruktur \nim Body der KOM-LE-Mail einfügen
@@ -76,4 +76,4 @@ L->P: Email mit großen\n Anhängen erzeugen
deactivate KM
P-->L:status
deactivate P
-@enduml
\ No newline at end of file
+@enduml
diff --git a/src/plantuml/Int_PS-KIM.puml b/src/plantuml/Int_PS-KIM.puml
new file mode 100644
index 0000000..f5a7aaf
--- /dev/null
+++ b/src/plantuml/Int_PS-KIM.puml
@@ -0,0 +1,57 @@
+@startuml
+/'
+# KIM 1.5.x
+# Primaersystemleitfaden
+# KIM Schnittstellen
+'/
+
+
+skinparam actorStyle awesome
+left to right direction
+scale 6/3
+
+skinparam sequence {
+ ArrowColor black
+ ArrowFontSize 17
+ ActorBorderColor black
+ LifeLineBorderColor black
+ LifeLineBackgroundColor Gainsboro
+
+skinparam component {
+ FontSize 10
+ BackgroundColor<> LightCoral
+ BorderColor<> #FF6655
+ FontName Courier
+ BorderColor black
+ BackgroundColor gold
+ ArrowFontName Impact
+ ArrowFontSize 8
+ ArrowColor #FF6655
+ ArrowFontColor #777777
+}
+
+ParticipantBorderColor Motivation
+ParticipantBackgroundColor Motivation
+ParticipantFontName Impact
+ParticipantFontSize 20
+ParticipantFontColor black
+ParticipantBorderColor Black
+ParticipantBackgroundColor MOTIVATION
+
+ActorBackgroundColor Gainsboro
+ActorFontColor black
+ActorFontSize 13
+ActorFontName Aapex
+}
+
+package SchnittstellenPS-KIM {
+[Primärsystem] ..> [POP3-Proxy\n[KIM-Clientmodul]] :use
+[Primärsystem] ..> [SMTP-Proxy\n[KIM-Clientmodul]] :use
+[Primärsystem] ..> [LDAPv3-Proxy\n[Konnektor]] :use
+[LDAPv3-Proxy\n[Konnektor]] ..> [Verzeichnisdienst] :use
+[SMTP-Proxy\n[KIM-Clientmodul]] ..> [Verzeichnisdienst] :use
+[POP3-Proxy\n[KIM-Clientmodul]] ..> [KIM-Provider] :use
+[SMTP-Proxy\n[KIM-Clientmodul]] ..> [KIM-Provider] :use
+}
+
+@enduml
\ No newline at end of file
diff --git a/src/plantuml/UC_PS-KIM.puml b/src/plantuml/UC_PS-KIM.puml
new file mode 100644
index 0000000..58c971e
--- /dev/null
+++ b/src/plantuml/UC_PS-KIM.puml
@@ -0,0 +1,51 @@
+@startuml
+/'
+# KIM 1.5.x
+# Primaersystemleitfaden
+# Use Case Diagram
+# Anwendungsfaelle
+'/
+
+
+skinparam actorStyle awesome
+left to right direction
+scale 6/3
+
+skinparam sequence {
+ArrowColor black
+ArrowFontSize 17
+ActorBorderColor black
+LifeLineBorderColor black
+LifeLineBackgroundColor Gainsboro
+
+ParticipantBorderColor Motivation
+ParticipantBackgroundColor Motivation
+ParticipantFontName Impact
+ParticipantFontSize 20
+ParticipantFontColor black
+ParticipantBorderColor Black
+ParticipantBackgroundColor MOTIVATION
+
+ActorBackgroundColor Gainsboro
+ActorFontColor black
+ActorFontSize 13
+ActorFontName Aapex
+}
+
+package Clientsystem {
+ actor "Leistungserbringer" as le
+}
+
+package Anwendungsfälle {
+ usecase "Empfänger ermitteln" as UC1 #AliceBlue
+ usecase "Nachricht generieren \nund übernehmen" as UC2 #AliceBlue
+ usecase "Nachricht versenden" as UC3 #AliceBlue
+ usecase "Nachricht empfangen" as UC4 #AliceBlue
+}
+
+le --> UC1
+le --> UC2
+le --> UC3
+le --> UC4
+
+@enduml
\ No newline at end of file
diff --git a/src/plantuml/eMail_status_empfangen.puml b/src/plantuml/eMail_status_empfangen.puml
index 5b93aa5..597e40c 100644
--- a/src/plantuml/eMail_status_empfangen.puml
+++ b/src/plantuml/eMail_status_empfangen.puml
@@ -2,8 +2,8 @@
scale max 2048 width
state "KOM-LE Mail empfangen" as rkm
-rkm: do / Prüfung der Signatur
rkm: do / Entschlüsselung des Mail Bodys
+rkm: do / Prüfung der Signatur
rkm: exit / Entschlüsselung erfolgreich abgeschlossen
state "KOM-LE Mail prozessiert" as dkm
@@ -12,8 +12,8 @@ dkm: do / Binary vom KAS herunterladen
dkm: exit / Download erfolgreich
state "Client-Mail heruntergeladen" as kdcm
+kdcm: do / Entschlüsselung der heruntergeladenen Mail-Daten
kdcm: do / Prüfen der Signatur der heruntergeladenen Mail
-kdcm: do / Entschlüsselung der heruntergeladenen mail
kdcm: do / Integritätsprüfung
kdcm: do / Nachverarbeitung (z.B. hinzufügen der KIM-header Felder)
kdcm: exit / Nachverarbeitung abgeschlossen
+
+
+
+