Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

KOM-LE-Clientmodul

    

     

      
Version
      
1.17.0
     
     

      
Revision
      
791229
     
     

      
Stand
      
11.12.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_CM_KOMLE
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Das vorliegende Dokument spezifiziert die Anforderungen an den Produkttyp KOM-LE-Clientmodul. Das Clientmodul ist verantwortlich für das Signieren und Verschlüsseln von KOM-LE-Nachrichten beim Versenden sowie für die Entschlüsselung und Signaturprüfung beim Abholen von KOM-LE-Nachrichten.

Aus den Kommunikationsbeziehungen mit Clientsystem, Konnektor, Verzeichnisdienst und KOM-LE-Fachdienst resultieren vom Clientmodul anzubietende Schnittstellen, die in diesem Dokument normativ beschrieben werden. Vom Clientmodul genutzte Schnittstellen liegen zumeist in anderen Verantwortungsbereichen (Konnektor, Verzeichnisdienst). Diese werden in den entsprechenden Produkttypspezifikationen definiert.

1.2 Zielgruppe

Dieses Dokument richtet sich an

• Entwickler des KOM-LE-Clientmoduls,
• Primärsystemhersteller und
• Verantwortliche für Zulassung und Test.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren werden durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

1.4 Arbeitsgrundlagen

Grundlagen für die Ausführungen dieses Dokumentes sind

• Lastenheft Adressierte Kommunikation Leistungserbringer
• Systemspezifisches Konzept KOM-LE [gemSysL_KOMLE]
• KOM-LE S/MIME-Profil [gemSMIME_KOMLE]
• Gesamtarchitektur der TI [gemÜK_Arch_TI]
• Konzept Architektur der TI-Plattform [gemKPT_Arch_TIP]
• Spezifikation PKI [gemSpec_PKI]
• Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur [gemSpec_Krypt]
• Spezifikation Konnektor [gemSpec_Kon]

1.5 Abgrenzung des Dokuments

Spezifiziert werden in dem Dokument die vom Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert.

Die Systemlösung der Fachanwendung KOM-LE ist im systemspezifischen Konzept [gemSysL_KOMLE] beschrieben. Dieses Konzept setzt die fachlichen Anforderungen des Lastenheftes auf Systemebene um, zerlegt die Fachanwendung KOM-LE in die zugehörigen Produkttypen, darunter das KOM-LE-Clientmodul und der KOM-LE-Fachdienst. Ferner definiert es die Schnittstellen zwischen den einzelnen Produkttypen. Für das Verständnis dieser Spezifikation wird die Kenntnis von [gemSysL_KOMLE] vorausgesetzt.

Die Anforderungen am Fachdienst werden separat in der Spezifikationen Fachdienst KOM-LE [gemSpec_FD_KOMLE] beschrieben.

Die Anforderungen an das Format der KOM-LE-Nachrichten, die zwischen dem Clientmodul und dem Fachdienst übermittelt werden, werden separat im KOM-LE-S/MIME-Profil [gemSMIME_KOMLE] beschrieben.

Abbildung 1 zeigt schematisch die Einbettung des vorliegenden Dokuments in die Dokumentenlandschaft der Lastenheft- und Pflichtenheftphase in Form einer Dokumentenhierarchie.

Abbildung 1: Abb_Dok_Hierarchie Dokumentenhierarchie KOM-LE

1.6 Methodik

1.6.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche innerhalb der Afo-ID und der Textmarke angeführten Inhalte.

1.6.2 Diagramme

Die Darstellung der Spezifikationen von Komponenten erfolgt auf der Grundlage einer durchgängigen Use-Case-Modellierung als

• technische Use Cases (eingebundene Graphik sowie tabellarische Darstellung mit Vor- und Nachbedingungen gemäß Modellierungsleitfaden),
• Sequenz- und Aktivitätendiagramme sowie
• Klassendiagramme
• XML-Strukturen und Schnittstellenbeschreibungen.

1.6.3 Nomenklatur

Sofern im Text dieser Spezifikation auf die Ausgangsanforderungen verwiesen wird, erfolgt dies in eckigen Klammern, z.B. [KOMLE-A_2015]. Wird auf Eingangsanforderungen verwiesen, erfolgt dies in runden Klammern, z.B. (KOMLE-A_202).

2 Systemüberblick

Das Clientmodul bietet die Funktionalität, die für Anwendungsfälle KOM-LE_AF_1 „Nachricht senden“ und KOM-LE_AF_2 „Nachricht empfangen“ (siehe [gemSysL_KOMLE]) relevant ist. Die Aufgabe des Clientmoduls ist das Aufbringen und Aufheben des Schutzes der Integrität und Vertraulichkeit der zwischen den KOM-LE-Teilnehmern ausgetauschten E-Mail-Nachrichten. Dabei kommuniziert das Clientmodul mit dem Clientsystem, dem KOM-LE-Fachdienst und nutzt mehrere Dienste der TI-Plattform. Optional kann das Clientmodul in das Clientsystem integriert werden. Abbildung 2 stellt die grundlegenden Elemente der KOM-LE-Architektur dar.

Abbildung 2: Abb_KOMLE_Komp KOM-LE-Komponenten

Die im Clientmodul zu bearbeitenden originalen MIME-Nachrichten von einem Clientsystem, die kleiner oder gleich 15 MiB sind, werden beim Senden entsprechend dem KOM-LE-S/MIME-Profil gemäß [gemSMIME_KOMLE] digital signiert und verschlüsselt und im empfangenden Clientmodul entschlüsselt und deren Signatur geprüft. Die originalen MIME-Nachrichten, die von einem Clientsystem an das Clientmodul übergeben werden, werden im KIM-Kontext als Client-Mails bezeichnet. Bei Client-Mails größer 15 MiB wird die gesamte Client-Mail auf einem separaten Speicherort (Fachdienst) verschlüsselt abgelegt (E-Mail-Daten). Das KOM-LE-S/MIME-Profil konkretisiert die S/MIME-Spezifikation und stellt sicher, dass die Interoperabilität zwischen den verschiedenen KOM-LE-Komponenten sowie der Schutz von Integrität und Vertraulichkeit für alle personenbezogenen medizinischen Daten gewährleistet werden.

Jede dem KOM-LE-S/MIME-Profil entsprechende Nachricht hat die in Abbildung 3 dargestellte Struktur. Die äußere Nachricht ist eine entsprechend dem S/MIME-Standard signierte und verschlüsselte E-Mail-Nachricht. Die innere Nachricht ist die vom Clientmodul verarbeitete Client-Mail (signiert und verschlüsselt) die gemäß message/rfc822 als Anhang in die äußere Nachricht angehangen wird. Die so erzeugte Mail wird im KIM-Kontext als KOM-LE-Nachricht bezeichnet.

Abbildung 3: Abb_Struk_KOMLE_Msg Struktur einer KOM-LE-Nachricht

Die durch das Clientmodul versendeten Nachrichten können vom Client optional gekennzeichnet werden. Es wird empfohlen eine Dienstkennung zu setzen. Andernfalls werden Nachrichten mit einer standardisierten Dienstkennung versehen. Das hierfür notwendiges Attribut im Header der Mail (X-KIM-Dienstkennung) wird im Kapitel 3.6 beschrieben. Erfolgte durch den Client keine Belegung dieses Attributes, wird durch das Clientmodul eine Default-Kennung gesetzt. Um die Abholung der auf dem Mail-Server ankommenden Nachrichten inhaltsabhängig durchführen zu können, wird das Header-Feld "X-KIM-Dienstkennung" aus der inneren Nachricht, die signiert und verschlüsselt ist, in den äußeren Header der Nachricht übernommen.

Zusätzlich wird das Clientmodul um das Administrationsmodul erweitert (siehe auch Kap. 3.7). Mit Hilfe des Administrationsmoduls kann sich der KOM-LE-Teilnehmer beim Fachdienst registrieren oder eine Deregistrierung vornehmen. Zugleich kann über das Administrationsmodul das benötigte Clientzertifikat (PKCS#12 - Datei) heruntergeladen werden.