Skip to content

Latest commit

 

History

History
414 lines (284 loc) · 34.8 KB

Primaersystem.adoc

File metadata and controls

414 lines (284 loc) · 34.8 KB
Raw

Primärsystem

Der folgende Leitfaden beschreibt, wie das Primärsystem die Funktionalitäten von KIM umsetzt.

💡
 Die Nutzung der in diesem Leitfaden geschilderten Funktionalitäten ist abhängig von der Verfügbarkeit eines QES-fähigen Konnektors.

Hinweis: Die Primärsystemschnittstellenversion sowie der Wertebereich von Datenfeldern kann sich im Laufe der Zeit ändern, insbesondere aufgrund von Änderungen/Updates am Konnektor. In diesem Leitfaden werden nur Änderungen aufgeführt, die für das sichere Übermittlungsverfahren KIM wichtig sind. Informationen zu den Unterschieden zwischen Primärsystemschnittstellenversionen veröffentlicht die gematik auf ihrem Fachportal.

1. Übersicht

Das sichere Übermittlungsverfahren KIM stellt Primärsystemen die Möglichkeit zur Verfügung, mit anderen KIM-Teilnehmern (Ärzten, Arztpraxen, Krankenhäusern usw.) eine Ende-zu-Ende-gesicherte E-Mail-Kommunikation zu führen. Die Ver-/Entschlüsselung sowie die Erstellung der Signatur und Signaturprüfung werden unter Nutzung der Smartcards (SM-B und HBA) vollständig vom KIM-Clientmodul übernommen.

2. Voraussetzungen

Für die Nutzung von KIM müssen die folgenden Punkte erfüllt sein:

💡
 - die Basisdaten (z. B. Zertifikat) des KIM-Nutzers sind in dem Verzeichnisdienst eingetragen,
- der Nutzer hat sich bei einem KIM-Provider registriert,
- die Fachdaten (z. B. KIM-E-Mail-Adresse) für den Nutzer sind im Verzeichnisdienst hinterlegt,
- der Nutzer verfügt über eine freigeschaltete SM-B (bzw. einen freigeschalteten HBA)
- der Konnektor ist für den Online-Modus konfiguriert.

  • Umkonfigurieren in den Online-Modus
    Es ist erforderlich, dass das Primärsystem den Anwender darüber informiert, wenn sich der Konnektor im Offline-Modus befindet. In diesem Fall ist eine Umkonfiguration des Konnektors durch den Anwender vorzunehmen.

3. Schnittstellen

Das Primärsystem nutzt die Schnittstellen des Konnektors sowie des KIM-Clientmoduls. Die LDAP-Schnittstelle des Konnektors wird durch das Primärsystem genutzt, um mit dem Verzeichnisdienst zu kommunizieren. Damit ist es dem Primärsystem möglich, die KIM-Mailadresse eines Empfängers zu ermitteln. Das Primärsystem kommuniziert mit dem KIM-Clientmodul unter Verwendung der gängigen E-Mail–Standards (SMTP und POP3). Dabei agiert das Clientmodul als Mail Transport Agent (MTA).

Das folgende Komponentendiagramm stellt die Abhängigkeitsbeziehungen zwischen den einzelnen Komponenten dar.

  • Verwendung des LDAP-Proxys im Konnektor
    Es ist erforderlich, dass das Primärsystem mit der LDAP-Schnittstelle des Konnektors kommuniziert, um Verzeichnisdienstabfragen durchzuführen.

  • Verwendung des KIM-Clientmoduls
    Es ist erforderlich, dass das Primärsystem mit dem KIM-Clientmodul kommuniziert, um E-Mails zu versenden (SMTPS) und zu empfangen (POP3S).

4. Anwendungsfälle

In der folgenden Abbildung sind die vom Primärsystem umzusetzenden KIM-Anwendungsfälle dargestellt.

4.1. 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.

💡
 E-Mail-Nachrichten können nur für KIM-Teilnehmer verschlüsselt werden.

  • Verwendung von KIM-E-Mail-Adressen
    Zum Versand einer E-Mail ist es erforderlich, dass das Primärsystem die Header-Felder to, cc gemäß [RFC822] mit KIM-E-Mail-Adressen aus dem Verzeichnisdienst befüllt. Die Empfänger-Adressen können dabei aus dem Verzeichnisdienst abgefragt werden.

Zur Abfrage der Empfänger-Adressen aus dem Verzeichnisdienst, agiert das Primärsystem als LDAP-Client gegenüber dem LDAP-Proxy des Konnektors. Falls die Verbindung zwischen Primärsystem und Konnektor über TLS abgesichert wird, ist LDAPS zu verwenden.

  • VZD-Suchanfragen mittels LDAP
    Es ist erforderlich, dass das Primärsystem als LDAP-Client aus den LDAPv3 Standard die LDAP-Operationen Bind, Unbind, Search, Abandon gemäß [RFC4510] nutzt, um ein LDAP search durchzuführen.

Der Verzeichnisdienst ist für LDAP-Suchoperationen des Primärsystems über den Konnektor erreichbar, der als LDAP-Proxy agiert.

  • Nutzung des LDAP-Proxys des Konnektors
    Es ist erforderlich, dass das Primärsystem die LDAP search-Operation gemäß [RFC4511#4.5.1] über den LDAP-Proxy des Konnektors ausführt.

Die Suche nach der KIM–E-Mail-Adresse des Nachrichtenempfängers erfolgt primär über den Namen des Empfängers – also den Personennamen oder den Namen der Institution – aber auch über zusätzliche Informationen wie Adressen, Fachgebiet oder Institutionstyp.

  • Search Operation mittels des LDAP-Directory-Basisdatensatz-Attributs
    Es ist erforderlich, dass das Primärsystem die E-Mail-Adressen der Empfänger über die Suchkriterien des Namens, der Postadresse der Leistungserbringerinstitution oder des Fachgebiets in einer LDAP search-Operation gemäß [RFC4511#4.5.1] nach einem entsprechenden LDAP-Directory-Basisdatensatz-Attribut gemäß Tabelle [gemSpec_VZD#Tab_VZD_Datenbeschreibung] suchen kann.

Mittels der Suchkriterien kann das Primärsystem die KIM-E-Mail-Empfänger im Verzeichnisdienst ermitteln. Diese Suchkriterien sind in [gemSpec_VZD#Tab_VZD_Datenbeschreibung] aufgeführt. Über die LDAP-Suche sind Einträge ohne Zertifikate nicht erreichbar.

  • Auswahl der E-Mail-Adresse des gewünschten Empfängers
    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.

  • Prüfung der Empfängeradressen
    Es ist erforderlich, dass das Primärsystem lokal gespeicherte KIM-Adressen regelmäßig mit den Daten im VZD vergleicht und nicht mehr im VZD vorhandene KIM-Adressen aus dem lokalen Speicher entfernt und gegebenenfalls durch aktuelle KIM-Adressen aus dem VZD ersetzt. Die lokal gespeicherten KIM-Adressen sollen einmal täglich aktualisiert werden.

4.2. 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 (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äß 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 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.

4.3. 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.

💡
 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 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.

Die zu versendenden Dokumente können vor dem Versand vom Primärsystem über einen Aufruf der Signaturschnittstelle des Konnektors vom Leistungserbringer signiert werden.

  • Erstellung von MIME-Nachrichten
    Es ist erforderlich, dass das Primärsystem eine E-Mail-Nachricht als message/rfc822 MIME Einheit erzeugt und in eine multipart/mixed MIME-Nachricht verpackt. Für die Gruppierung von E-Mail-Nachrichten zu Konversationsverläufen, wird jede E-Mail mit einer einzigartigen Message-ID versehen. Die Message-IDs der Nachrichten dürfen keine datenschutzrelevanten Informationen - wie z. B. FQDNs - enthalten.

Die E-Mail-Nachricht wird anschließend über das Clientmodul versendet. Dabei signiert das Clientmodul die Nachricht automatisch mit der SM-B der Organisation des Absenders und verschlüsselt diese für alle Empfänger. Hierbei wird der S-MIME-Standard verwendet.

  • Antworten auf MIME_Nachrichten
    Beim Antworten fügt der E-Mail-Client die erhaltenen Message-IDs in das 'In-Reply-To'-Feld der Antwortnachricht ein. Zusätzlich kann das References-Feld genutzt werden, um eine Verbindung zu allen vorherigen Nachrichten in der Konversation herzustellen. Diese strukturierte Verwendung von Message-ID, In-Reply-To und References ermöglicht es, Nachrichten effektiv in Konversationsverläufen zu organisieren.

  • SMTP-Kommunikation über das KIM-Clientmodul
    Es ist erforderlich, dass das Primärsystem ausschließlich mit dem Clientmodul mittels SMTP-Kommandos kommuniziert.

  • SMTP-Authentifizierung über KIM–Clientmodul
    Für die SMTP-Authentifizierung über das Clientmodul ist es erforderlich, dass das Primärsystem die SASL-Mechanismen PLAIN und LOGIN verwendet.

Beim Aufbau der SMTP-Verbindung ist es erforderlich, Kartenverwaltungsinformationen zur SM-B mitzuliefern, die zum Integritätsschutz der Nachricht verwendet werden sollen. Dazu müssen MandantId, ClientsystemId und WorkplaceId, der Kartensitzung der erforderlichen SM-B, über den SMTP-Benutzernamen dem Clientmodul mitgeteilt werden.

  • Nutzerkreis der KIM-E-Mail-Adresse beim Nachrichtenversand
    Es ist erforderlich, dass die Nutzerverwaltung des Primärsystems sicherstellt, dass der Nachrichtenversand nur durch autorisierte Personen erfolgt. Die autorisierten Personen werden mit dem KIM-Antrag festgelegt.

  • Angaben zum Aufbau der SMTP-Verbindung zum KIM-Clientmodul
    Bei Anwendung der SASL-Mechanismen PLAIN und LOGIN für die SMTP-Authentifizierung ist es erforderlich, dass das Primärsystem einen persistent gespeicherten SMTP-Benutzernamen gemäß der Tabelle: Tab_ILF_PS_Bildungsregel_SMTP_Benutzername verwendet. Das Passwort, das zur Authentifizierung gegenüber dem KIM-Dienst (MTA) verwendet wird, wird ebenfalls dem persistenten Datensatz entnommen. Die Attribute der Tabelle Tab_ILF_PS_Bildungsregel_SMTP_Benutzername werden durch das „#“ – Zeichen getrennt.

Table 1. Tab_ILF_PS_Bildungsregel_SMTP_Benutzername
Attribut Beispiel

Benutzername des Absenders am KIM-Dienst (E-Mail-Adresse)

erik.mustermann@hrst_domain.kim.telematik

Domain Adresse des KIM-Dienstes (des MTAs) inkl. Portnummer

hrst_domain.kim.telematik:465

MandantId

1

ClientsystemId

KIM

WorkplaceId

7

KonnektorId (optional - erforderlich für Multikonnektor-Umgebungen)

Konn_1

  • Nutzung optionaler Parameter im SMTP-Benutzername
    Der SMTP-Benutzername muss immer vollständig sein auch wenn nicht alle optionalen Parameter verwendet werden. Daher ist es erforderlich, dass das Primärsystem sicherstellt, dass bei später folgenden optionalen Bestandteilen die davor fehlenden Positionen durch den Platzhalter ("*") ersetzt werden. Der Aufbau des SMTP-Benutzernames ist in [gemSpec_CM_KOMLE#3.3.2.2] definiert.

Beispiel für einen vollständigen SMTP-Benutzernamen

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:465#1#KIM#7
💡
 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 SMTP-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 SMTP-Benutzernames in ihrem semantischen Bezug gemäß [RFC1123, RFC2822] einhalten müssen.

Als Ergebnis der Authentisierung erhält das Primärsystem die SMTP-Antwortcodes vom Clientmodul, das die Verbindung zum KIM-Dienst (MTA) als Proxy offen hält.

  • Nutzung des SMTP-DATA-Kommandos
    Es ist erforderlich, dass das Primärsystem das DATA-Kommando zum Versenden einer KIM-Nachricht verwendet. Mit der Zeichensequenz „<CRLF>.<CRLF>“ wird das Ende der Nachricht markiert und anschließend weiterverarbeitet.

  • Schließung der SMTP-Verbindung mit QUIT
    Es ist erforderlich, dass das Primärsystem die SMTP-Verbindung mit dem QUIT-Kommando beendet.

  • Aufnahme des Sendersystems
    Es ist erforderlich, dass das Primärsystem (z.B. PVS oder andere Software-System der Kassen) das Header Element X-KIM-Sendersystem befüllt. Das Header Element muss der Notation <name des systems>;<version> entsprechen. Der Inhalt muss erkennen lassen, welches Software-System für die Erstellung der fachlichen Inhalte und in diesem Zusammenhang mit dem Umgang eventueller Rückmeldungen und deren Inhalten verantwortlich ist.

  • Aufnahme der Supportadresse
    Es ist erforderlich, dass das Primärsystem das Header Element X-KIM-Support befüllt. Das Header Element muss die Supportadresse des Herstellers des Primärsystems enthalten. Dadurch wird es möglich, dass Hersteller des Empfänger-Systems bei Fehlern Kontakt mit dem Hersteller des Sender-Systems aufnehmen können.

  • Verwendung von Zustellbestätigungen
    Es ist erforderlich, dass das Primärsystem so konfigurierbar ist, dass es beim Versenden einer Nachricht eine Zustellbestätigung gemäß [RFC3461] anfordern kann. Die Übermittlung zur Anforderung einer Zustellbestätigung erfolgt im Verlauf des SMTP Verbindungsaufbaus zum KIM Fachdienst und wird über das Kommando "NOTIFY" pro e-Mail angefordert.

  • Informieren über gescheiterten Nachrichtenversand
    Wenn das Clientmodul für alle Empfänger der zu versendenden Nachricht keine Verschlüsselungszertifikate ermitteln kann, bricht es den Versand ab und liefert dem Primärsystem den Antwortcode „451“ zurück. Es ist erforderlich, dass das Primärsystem beim Erhalt dieses Antwortcodes den Nutzer über das Scheitern des Nachrichtenversandes mit folgendem Fehlertext informiert:

„Die Nachricht konnte nicht gesendet werden, weil für keinen Empfänger gültige Verschlüsselungszertifikate ermittelt werden konnten.“

Wenn nur ein Teil des gewünschten Empfängerkreises adressiert werden konnte, da nicht für alle Empfänger das notwendige Verschlüsselungszertifikat ermittelt werden konnte, wird der Nutzer mit einer entsprechenden Meldung darüber informiert:

„Die Nachricht wurde nur an einen Teil der gewünschten Adressaten versendet, denn es konnten nicht für alle Empfänger gültige Verschlüsselungszertifikate ermittelt werden.“

4.4. 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.

4.4.1. 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.

  • Freischaltung der für KIM erforderlichen Smartcards
    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 und TXT 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.

4.4.2. 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.

  • Angaben zum Aufbau der POP3-Verbindung zum Clientmodul
    Zur POP3-Authentifizierung gegenüber dem KIM-Dienst (MTA als POP3-Server) ist es erforderlich, dass das Primärsystem einen persistent gespeicherten POP3-Benutzernamen gemäß der Tabelle: Tab_ILF_PS_Bildungsregel_POP3_Benutzername verwendet. Das Passwort, das zur Authentifizierung gegenüber dem KIM-Dienst (MTA) verwendet wird, wird ebenfalls dem persistenten Datensatz entnommen. Die Attribute der Tabelle werden durch das „ # “ – Zeichen getrennt. Ist die KIM-E-Mail-Adresse des Empfängers nicht einer SM-B, sondern einem HBA zugeordnet, ist es erforderlich, an das Ende des POP3-Benutzernamens zusätzlich ein „#“ - Zeichen sowie die UserId für den Zugriff auf den HBA anzuhängen.

Table 2. Tab_ILF_PS_Bildungsregel_POP3_Benutzername
Attribut Beispiel

Benutzername des Absenders am KIM-Dienst (E-Mail-Adresse)

erik.mustermann@hrst_domain.kim.telematik

Domain Adresse des KIM-Dienstes (des MTAs) inkl. Portnummer

hrst_domain.kim.telematik:995

MandantId

1

ClientsystemId

KIM

WorkplaceId

7

UserId (optional - nur für HBA erforderlich)

13

KonnektorId (optional - erforderlich für Multikonnektor-Umgebungen)

Konn_1

  • Nutzung optionaler Parameter im POP3-Benutzername
    Der POP3-Benutzername muss immer vollständig sein auch wenn nicht alle optionalen Parameter verwendet werden. Daher ist es erforderlich, dass das Primärsystem sicherstellt, dass bei später folgenden optionalen Bestandteilen die davor fehlenden Positionen durch den Platzhalter ("*") ersetzt werden. Der Aufbau des POP3-Benutzernames ist in [gemSpec_CM_KOMLE#3.4.2.2] definiert.

Beispiel für einen vollständigen POP3-Benutzernamen

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:995#1#KOM_LE#7#*#Konn_1
💡
 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.

4.4.3. 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.

Primärsysteme dürfen nur bisher unbekannte KIM-Nachrichten abrufen. Durch den folgenden Ablauf können die unbekannten KIM-Nachrichten abgefragt werden:

  • Das PS sendet POP3 UIDL an das Clientsystem. Es werden alle Message-Nummern und die eindeutigen IDs (UID) der Nachrichten abgefragt

  • Das PS prüft anhand der empfangenen UID-Nummern ob die Nachricht im PS bekannt ist und ermittelt so die Message-Nummern der unbekannten Nachrichten

  • Das PS sendet POP3 RETR <Message-Nummer> an das Clientsystem für alle unbekannten Message-Nummern. Die UID-Nummer der empfangenen Nachricht wird lokal gespeichert, damit sie bei folgenden Nachrichtenabrufen nicht erneut abgefragt wird.

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 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.

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.

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.

💡
 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 <Message-Nummer> 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-Nummer der Nachricht muss lokal gespeichert werden, um einen erneuten Abruf zu verhindern.

Das Primärsystem muss eine Möglichkeit anbieten, die Abholung von Nachrichten auch außerhalb konfigurierter fester Abrufzeiträume auszulösen. Dies muss bezogen auf eine bestimmte Dienstkennung möglich sein (z. B. eEB) um solchen Anwendungen die zeitnahe Abholung von Antworten zu ermöglichen.

4.4.4. Umgang mit HTML Mails

Für KIM-Nachrichten, für die es keine sektorspezifischen Festlegungen gibt, ist es erforderlich, dass das Primärsystem robust implementiert ist: Bei Multipart-Mails muss das Primärsystem den text/plain Teil anzeigen. Idealerweise kann der Empfänger festlegen ob Multipart-Mails als HTML ODER text/plain im Primärsystem dargestellt werden.

Primärsysteme müssen für Nachrichten mit der Dienstkennung KIM-Mail den MIME type text/plain verwenden. Multipart- bzw. HTML-Mails sind nicht zugelassen. Anhänge sind erlaubt.

Weitere Informationen zu Multipart finden Sie in RFC 2387.

5. 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:

Wenn das Clientmodul in das Primärsystem integriert wird, richten sich die Anforderungen des Clientmoduls an das Primärsystem. Durch die optionale Integration entfallen alle Anforderungen an die Schnittstelle zwischen Primärsystem und Clientmodul, da diese nicht mehr existiert.

Die zu erfüllenden Anforderungen für die Integration des Clientmoduls in das Primärsystem können dem Produkttypsteckbrief für das Primärsystem mit integrieten Clientmodul [gemProdT_KIM_iCM] entnommen werden.

6. Fehlernachrichten

Kommt es bei der Verarbeitung vom Nachrichten durch das Clientmodul zu Fehlern, werden durch das Clientmodul fallbezogene Fehlernachrichten erzeugt. Durch das Clientmodul wird in jeder Fehlernachricht ein Mail-Header-Attribut X-KIM-Fehlermeldung in den Header der Fehlernachricht mit einem entsprechenden Fehlercode befüllt. Eine Liste der möglichen Fehlercodes wird in der Spezifikation des KOM-LE-Clientmodul gezeigt. Zusätzlich zu den dort festgelegten Fehlercodes sind auch herstellerspezifische Fehlercodes erlaubt. Diese herstellerspezifischen Fehlercodes welche mit einem „x“ beginnen, werden zusätzlich zu den von der gematik festgelegten Fehlercodes verwendet. Treten mehrere negative Ergebnisse auf, kann das Mail-Header-Attribut X-KIM-Fehlermeldung mehrmals verwendet werden. Ein Primärsystem kann diese im Mail-Header-Attribut X-KIM-Fehlermeldung übergebenen Fehlercodes auswerten und dem Nutzer dazu passende Fehlermeldungen im System anbieten.

7. Zentraler Anti-Viren-Service (AV-Service)

Im folgenden Kapitel werden Lösungen beschrieben, wie ein zentraler Anti-Viren-Service (AV-Service) zusammen mit KIM genutzt werden kann.

💡
 Da KIM-Nachrichten Ende-zu-Ende verschlüsselt sind, kann ein AV-Service mit angebundenem AV-Programm erst nach der Entschlüsselung der Nachricht eingesetzt werden.

7.1. Integrierter AV-Service im Clientmodul

Einige KIM Anbieter unterstützen die Einbindung eines zentralen AV-Service bzw. AV-Programm direkt in ihrem KIM-Clientmodul. Für eine solche Lösung sind keine zusätzlichen Änderungen am Primärsystem erforderlich. Bitte erfragen Sie bei Ihrem KIM-Anbieter, ob und in welcher Weise eine solche Lösung unterstützt wird.

7.2. Mailserver und AV-Scanner zwischen Primärsystem und Clientmodul

In dieser Lösung wird ein Mailserver und ein AV-Scanner zwischen das Primärsystem/Clientsystem und dem KIM-Clientmodul geschaltet. Bei der Lösung wird der AV-Service über den Mailserver angesprochen. In der folgenden Abbildung ist eine mögliche Implementierungsvariante dargestellt:

Der Mailserver ruft die KIM-Nachrichten vom KIM-Fachdienst per POP3 ab. Nach Entschlüsselung der Nachrichten im KIM-Clientmodul prüft der AV-Service die Nachrichten. Liegt kein Virenbefund vor, speichert der Mailserver die Nachrichten, bis das Primärsystem/Clientsystem die KIM-Nachrichten vom Mailserver abholt. Auch zu versendende KIM-Nachrichten lassen sich über diese Konstellation auf Viren prüfen, wobei der Versand per SMTP vom Primärsystem über den Mailserver und AV-Scanner über das Clientmodul erfolgt. Alternativ kann der Versand auch ohne Viren-Prüfung erfolgen (ohne Ansprache des AV-Service via SMTP direkt zum KIM-Clientmodul).

Diese Lösung setzt voraus, dass im Primärsystem konfiguriert werden kann, wie der Benutzername an den Mailserver übergeben wird, unabhängig vom verwendeten Protokoll zwischen Primärsystem und Mailserver, da marktübliche Mailserver den in KIM verwendeten SMTP/POP3-Benutzernamen (mail-adresse#Aufrufkontext) nicht unterstützen. Der Mailserver muss so konfiguriert werden, dass ein Mapping der Benutzernamen, die im Primärsystem konfiguriert sind, auf die Benutzernamen mit Aufrufkontext erfolgt, sodass der Mailserver das Clientmodul korrekt ansprechen kann.

  • Unterstützung mehrerer Aufrufvarianten
    Es ist erforderlich, dass das Primärsystem die Aufrufvarianten SMTP-/POP3-Benutzername ohne Aufrufkontext und SMTP-/POP3-Benutzername mit Aufrufkontext unterstützt, unabhängig davon welche Schnittstelle zwischen Primärsystem und Mailserver verwendet wird (z. B. IMAP, POP3, SMTP). Die Aufrufvarianten müssen pro Protokoll, also getrennt für SMTP und POP3 ausgeführt werden können, um eine unterschiedliche Konfiguration der Aufrufparameter für das Senden und das Empfangen von KIM-Nachrichten zu ermöglichen.

7.3. Lastverteilung und Performance beim Einsatz von KIM 1.0

8. Umgang mit Middleware

Grundsätzlich ist die Implementierung einer Middleware, die mit verschiedenen Anwendungen oder Komponenten kommuniziert, in der KIM-Architektur erlaubt. Dies gilt für den Transportweg zwischen dem Mailclient beim Leistungserbringer und dem Fachdienst beim Anbieter. Hierbei ist zu beachten, dass die Middleware zusätzlich das Attribut X-KIM-Middleware im Header Element in die Nachricht einträgt.

9. Umgang mit Multikonnektor-Umgebungen

Um in einer Umgebung mit mehreren Konnektoren mit dem für das Schlüsselmaterial (SMC-B) notwendigen Konnektor zu kommunizieren, muss dieser eindeutig adressierbar sein. Aus diesem Grund wird zusätzlich im SMTP/POP3-Benutzername ein weiterer Parameter vom Clientsystem an das Clientmodul übergeben. Das folgende Bild zeigt beispielhaft in einer Multikonnektor-Umgebung, wie das Clientmodul mit Hilfe des optionalen Parameters mit dem Konnektor (A) kommuniziert.

Beispielhaft wird für das Senden einer KIM-Mail der SMTP-Benutzername um den optionalen Parameter KonnektorId erweitert. Mit diesem kann das Clientmodul den notwendigen Konnektor adressieren. Der Paramter wird im Aufrufkontext für SM-B optional hinter den Parameter WorkplaceId angehägt.

MTA SMTP Benutzername

Beispiel SMTP-Benutzername

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:465#1#KIM#7#Konn_1

Wenn der Parameter KonnektorId im SMTP-Benutzernamen enthalten ist wird dieser vom Clientmodul extrahiert. Dieser Parameter wird mit Hilfe einer im Clientmodul hinterlegten Clientmodul-Konfigurationsdatei ausgewertet.

Im folgenden Beispiel ist ein Auszug einer möglichen Clientmodul-Konfigurationsdatei dargestellt. In dieser sind die unterschiedlichen Konnektoren konfiguriert, die mittels der DVDUri adressiert werden können. Wird der Parameter mit dem Inhalt KonnektorId = Konn_1 übergeben, wird der Diensteverzeichnisdienst (DVD) dieses Konnektors (A) aufgerufen.

Beispiel einer Clientmodul-Konfigurationsdatei

<Connectors>
  <Connector KonnektorID="Konn_1" default="true">
    <SOAP>
     <DVDUri>http://<MGM_KONN_A_HOSTNAME>/connector.sds</DVDUri>
    </SOAP>
  </Connector>
  <Connector KonnektorID="Konn_2" default="true">
    <SOAP>
     <DVDUri>http://<MGM_KONN_B_HOSTNAME>/connector.sds</DVDUri>
    </SOAP>
  </Connector>
</Connectors>

Weitere Informationen bzw. die entsprechenden Anforderungen sind in [gemSpec_CM_KOMLE#3.3.2.2] und [gemSpec_CM_KOMLE#3.4.2.2] beschrieben.

Um die Erreichbarkeit von Diensten in der Telematik Infrastruktur zu ermöglichen, bei denen kein bestimmter Konnektor verwendet werden muss, ist es notwendig im Clientmodule eine "default" Route in Richtung der Telematik Infrastruktur zu konfigurieren. Das Clientmodule kann für diesen Fall unterschiedlich gewichtete Routen vorhalten, um ein möglichst ausfallsicheres Routing zu ermöglichen. Um ein Load-Balancing für den Netzwerk-Verkehr in das zentrale Netz der TI zu ermöglichen kann ein Network Load-Balancer zwischen Clientmodul und Konnektoren geschaltet werden.

10. Implementierungshinweise

Aufgrund von vereinzelten Rückmeldungen zur schlechten Performance und Bedienbarkeit von Primärsystemen sollen hier einige allgemeine Implementierungshinweise gegeben werden.

Hinweis: Zeitlimits, die durch menschliche Wahrnehmungsfähigkeiten bestimmt werden, und die bei der Web -und Anwendugsprogrammierung beachtet werden sollten, werden unter Zeitlimits beschrieben.

Die Benutzeroberfläche sollte immer auf Eingaben reagieren können und der Benutzer durch geeignete Hinweise zum Stand der Bearbeitung informiert werden. Für die Aufrechterhaltung der Reaktionsfähigkeit der Oberfläche hat jedes UI-Framework eigene Konzepte, üblicherweise wird das Rendern der UI in einem eigenen Thread ausgelagert. Dieser Thread darf nicht durch andere Operationen, wie z.B. Konnektor-Operationen, blockiert werden.

Außerdem muss gewährleistet sein, dass der Benutzer während länger andauernder Operationen weiterarbeiten kann. Das kann durch Verwendung von asynchronen APIs und Auslagern der Arbeit in Hintergrundthreads erreicht werden. Nach Beendigung der Arbeit wird der Benutzer geeignet informiert.

Hinweis: Informationen zu diesen Themen werden z.B. unter Aufrechterhalten der Reaktionsfähigkeit des UI-Threads und Threading und asynchrone Programmierung gegeben.