Spezifikation enachricht 2.0 Spezifikation KV-Connect Anwendungsdienst "enachricht;v2. 0"

Transkript

1 Spezifikation enachricht 2.0 Spezifikation KV-Connect Anwendungsdienst "enachricht;v2. 0" Herausgeber: KV Telematik GmbH Dieses Dokument der KV Telematik GmbH wird unter der Lizenz CC-BY-SA 3.0 veröffentlicht. (

2

3 Inhaltsverzeichnis 1 Vorbemerkungen Zweck des Dokumentes Inhalt Geltungsbereich Referenzen Ziel Ausgangssituation Lösungsansatz Allgemeine Voraussetzungen Grundlage: KV-Connect 7 2 Prozess-Beschreibung Anforderungen Geschäftsvorfälle (Use Cases) Gesamtablauf aus Sicht der Teilnehmer Ablauf "enachricht " Erstellung der "enachricht" Übermittlung der "enachricht" Kenntnisnahme der "enachricht" 11 3 Beschreibung der KV-Connect Nachrichten Nachrichtenformate Inhalt der Nachrichten KV-Connect Nachricht Aufbau der KV-Connect Nachrichten Verwendete Segment- und X-Attribute Struktur der Nachricht "enachricht" Die Nachrichten-Struktur Die Struktur des signierten S/MIME-Nachrichteninhalts Die Struktur der verschlüsselten S/MIME-Nachricht Struktur der Nachricht "MDN" 16 4 Spezifikation der Datenübermittlung Festlegung des Empfängers Der Nachrichten-Header 18

4 5 Anforderungen an die Software-Systeme Anforderungen an die Systeme zum Empfang von "enachrichten" Anforderungen an die Systeme zum Versand von "enachrichten" 22

5 Änderungshistorie Vers. Datum Autor Kap. Änderung Status 1.1;B Volker Dentel alle Erstellung Version 2.0 intern 1.2;B Volker Dentel alle Einarbeitung Änderungen Aufbau Mustermails intern 1.3;B Volker Dentel alle Einarbeitung Änderungen in Arbeit 1.4;K Volker Dentel Freigabe interne Kommentierung interne Kommentierung 1.5;K Volker Dentel Freigabe Kommentierung in Kommentierung 1.6;B Volker Dentel alle Einarbeitung Kommentierungsergebnisse intern Volker Dentel Freigabe in Kraft Hier können Sie die Spezifikation als PDF downloaden. Herausgeber: KV Telematik GmbH Diese Spezifikation wird unter CC-BY-SA 3.0 veröffentlicht. (, Vollständiger Lizenztext Allgemein verständliche Erklärung) Seite 5

6 1 Vorbemerkungen 1.1 Zweck des Dokumentes Dieses Dokument dient der Spezifikation des KV-Connect Anwendungsdienstes enachricht in der Version 2.0. Mittels des KV-Connect Anwendungsdienstes "enachricht" können Nachrichten, die nicht im Kontext zu anderen, bereits spezifizierten KV-Connect Anwendungsdiensten stehen, zwischen den Kommunikationspartnern im Sicheren Netz der KVen (SNK) übertragen werden. 1.2 Inhalt Kapitel 2 Prozess-Beschreibung gibt einen Überblick über den Gesamtprozess der abzubildenden Anwendung einschließlich der per KV-Connect auszutauschenden Daten. Kapitel 3 Beschreibung der KV-Connect Nachrichten beschreibt in unterschiedlicher Detaillierungstiefe die auszutauschenden Daten. Kapitel 4 Spezifikation der Datenübermittlung beschreibt den Aufbau der KV-Connect-Nachrichten zur Übertragung der vorher beschriebenen Daten. Kapitel 5 Anforderungen an die Software-Systeme beschreibt die durch die Software-Systeme umzusetzenden Anforderungen. 1.3 Geltungsbereich Die vorliegende Spezifikation gilt für alle IT-Systeme im Gesundheitswesen, die die elektronische Kommunikation im Bereich der vertragsärztlichen Versorgung unterstützen. Sie beschreibt den Prozess vom Nachrichtenaufbau über den Versand und Empfang der enachrichten sowie den Inhalt von und den Umgang mit Eingangsbestätigungen (MDN). 1.4 Referenzen 1.5 Ziel [PP KVC]: Dokumentation zu KV-Connect [AN_KVC]: Anbindung an KV-Connect, ftp://ftp.kbv.de/ita-update/stammdateien/sdkvca/kv- Connect.zip [MDN]: Spezifikation MDN (anwendungsübergreifend) [RFC5322]: RFC 5322 Internet Message Format" [MIME]: Übersicht der MIME-Typen Ziel ist die Spezifikation eines Dienstes, der es den KV-Connect Teilnehmern ermöglicht, sich unter Nutzung von KV-Connect als sicherem Kommunikationskanal Nachrichten zuzusenden, die nicht unmittelbar zu einem vom jeweiligen Primärsystem unterstützten Prozess gehören, sondern vom Nutzer frei" erstellt werden. Die Nutzung solcher Nachrichten ist insbesondere dann sinnvoll, wenn der der Nachricht zugrundeliegende Vorgang (noch) nicht von einem existierenden KV-Connect Anwendungsdienst unterstützt wird. Die "enachrichten" ähneln in ihrem Charakter einer normalen" , werden jedoch nicht mittels eines handelsüblichen Mail-Programms, wie Thunderbird oder Microsoft Outlook erzeugt, versendet bzw. empfangen, sondern werden wie alle anderen KV-Connect Nachrichten direkt im Primärsystem des Nutzers erstellt, von dort medienbruchfrei versendet und durch das Primärsystem empfangen und ggf. weiterverarbeitet. Seite 6

7 1.6 Ausgangssituation KV-Connect ermöglicht schon mit seiner Basisfunktionalität die Übermittlung von Nachrichten, die gemäß gängiger -Standards aufgebaut sind. Zur Integration in das Primärsystem ist KV-Connect flexibel konzipiert und bietet je nach Anforderung grundsätzlich zwei unterschiedliche Schnittstellen an: Integration KV-Connect Client über Standard -Schnittstellen (smtp/pop3), Integration KV-Connect Serverschnittstelle (REST) und native Anbindung. 1.7 Lösungsansatz Um es den KV-Connect Nutzern zu ermöglichen, Nachrichten mit Inhalten, die nicht bereits in veröffentlichten Spezifikationen der KV Telematik GmbH beschrieben sind, direkt aus ihren Primärsystemen über KV-Connect an andere Teilnehmer zu versenden, sind die grundlegenden Möglichkeiten zur Erstellung einer "enachricht", ihrem Versand, Empfang und Darstellung auf Empfängerseite als Komponente der Primärsysteme zu implementieren. Die erlaubten Mail-Formate werden dabei so beschränkt, dass die Implementierung mit geringem Aufwand durchgeführt werden kann. 1.8 Allgemeine Voraussetzungen Die Teilnahme an einem sicheren und vertrauenswürdigen elektronischen Kommunikationsprozess setzt die Identifikation und Registrierung der Kommunikationspartner zwingend voraus. Dieser Prozess wird bei der Anmeldung für KV-Connect einmal durchlaufen, unabhängig davon, welche Anwendung der Nutzer initial wählt. Mit dieser einmaligen Anmeldung stehen damit auch alle anderen Anwendungsdienste der Plattform ohne weitere administrative Aktionen zur Verfügung. Sobald die KV- Connect Registrierung erfolgreich abgeschlossen, der KV-Connect Zugang verfügbar ist und der Anbieter des verwendeten Praxisverwaltungs-, Labor-, Kommunikations- bzw. Krankenhausinformationssystems das Audit für den Anwendungsdienst "enachricht;v2.0" erfolgreich abgeschlossen hat, kann das Versenden/Abholen von enachrichten beginnen. Eine vorherige rechtzeitige Absprache mit den Kommunikationspartnern vor dem erstmaligen Einsatz des Anwendungsdienstes "enachricht" mit KV-Connect ist dringend geraten. 1.9 Grundlage: KV-Connect Wie für jeden Dienst auf Basis von KV-Connect gelten auch für den Dienst "enachricht" die generellen Festlegungen für KV-Connect, ohne dass darauf in diesem Dokument im Detail hingewiesen wird (vgl. [PP KVC]). Seite 7

8 2 Prozess-Beschreibung 2.1 Anforderungen Der Anwendungsdienst "enachricht" kann zur Kommunikation zwischen beliebigen KV-Connect Teilnehmern im Rahmen sehr unterschiedlicher Anwendungsfälle genutzt werden. Deshalb werden hier nur Annahmen, die der Konzeption zugrunde liegen, angeführt, ohne jedoch einen konkreten Anwendungsfall vorzugeben: Der Zweck einer KV-Connect "enachricht" sollte immer beruflicher Natur sein. KVen können den Dienst für die Kommunikation mit ihren Mitgliedern nutzen, wobei neben Einzelnachrichten auch der Versand von Massensendungen", d.h. gleichen "enachrichten" (Serienbriefen) an viele Mitglieder möglich ist. Es wird davon ausgegangen, dass für die "enachrichten" die Möglichkeit, Text zu formatieren, kaum benötigt wird, da komplexere Inhalte wie Tabellen oder graphische Darstellungen als Anhänge übermittelt werden können. Formatierungsmöglichkeiten entfallen deshalb zugunsten der Sicherheit, der Interoperabilität und der Vereinfachung der Implementierung. Versender einer "enachricht" haben unter Umständen den Bedarf zu erfahren, ob ihre "enachricht" empfangen wurde. Diese Kenntnis kann, z. B. dazu genutzt werden den Inhalt einer offenbar nicht empfangenen "enachricht" dem Adressaten zusätzlich auf anderem Wege zuzustellen. Für diesen Zweck ist es ausreichend, dass eine Eingangsbestätigung (MDN) dann gesendet wird, wenn die "enachricht" empfangen wurde und der Versender eine Eingangsbestätigung (MDN) angefordert hat. Es kann hingenommen werden, dass der Empfänger evtl. das Senden einer Bestätigung verhindert, d. h. der Empfänger hat die "enachricht" erhalten, obwohl keine Bestätigung zurückgesendet wurde. Bei Bedarf kann das Versenden von Eingangsbestätigungen mit organisatorischen Festlegungen geregelt werden. Die Kommunikation zwischen einer KV und ihren Mitgliedern stellt in der Regel keine besonderen Anforderungen an den Dienst. Insbesondere gibt es keine allgemeingültigen Anforderungen an die Weiterverarbeitung einer "enachricht" oder ihres Inhaltes, so dass es keiner Kennzeichnung einer "enachricht" als KV-Mail" o.ä. bedarf. Der Empfänger kann die Herkunft einer "enachricht" der KV-Connect Adresse des Absenders entnehmen; sie benötigt also ebenfalls keine zusätzliche Auszeichnung der "enachricht". 2.2 Geschäftsvorfälle (Use Cases) Die Spezifikation der "enachricht" beschreibt derzeit zwei Geschäftsvorfälle, die sich für das Kommunikationssystem unterscheiden lassen. Die Geschäftsvorfälle ergeben sich aus den spezifischen Anforderungen der kassenärztlichen Versorgung. Der Gesamtvorgang beschreibt den Informationsvorgang zwischen dem Versender und Empfänger einer "enachricht". Versender enachricht Empfänger (1 - n) Die Geschäftsvorfälle teilen sich bei Benutzung eines serverbasierten Kommunikationssystems, wie es KV-Connect ist, technisch in zwei Teilvorgänge auf: 1. Versand einer "enachricht" an das Postfach des Empfängers auf dem KV-Connect Server Das Primärsystem erzeugt eine KV-Connect "enachricht" an den/die Empfänger und verschickt sie an das/die Postfach/Postfächer des/der Empfänger(s) auf dem KV-Connect Server. Als zweiten Schritt, insgesamt aber periodisch, fragt das System den KV-Connect Server nach Eingangsbestätigungen (MDN) zu den versandten "enachrichten" ab und ergreift je nach Status oder, ob überhaupt MDNs empfangen werden, geeignete Maßnahmen. Seite 8

9 Spezifikation KV-Connect Anwendungsdienst "enachricht;v2.0" 2. Abholen einer "enachricht" vom KV-Connect Server Das Primärsystem der empfangenden Stelle fragt den KV-Connect Server nach vorliegenden "enachrichten" mit der zutreffenden X-KVC-Dienstkennung (s.u.) ab und holt diese ab. Nach erfolgreichem Abholen kann eine MDN erzeugt und für den Absender der jeweiligen "enachricht" an den KV-Connect Server versendet werden. Die empfangenen Daten werden in geeigneter Weise intern verarbeitet Gesamtablauf aus Sicht der Teilnehmer Wie in der obigen Kurzbeschreibung erkennbar existieren bei den derzeitigen use cases zwei Teilnehmer, der Versender und der/die Empfänger. Die Prozesse, Dokumente und Schnittstellen der Teilnehmer werden in den folgenden Abschnitten zusammengefasst. Der faktisch ebenfalls beteiligte Teilnehmer KVC-Server (KV-Connect Server) wird nicht gesondert betrachtet, sondern durch die Schnittstellenbeschreibungen abstrahiert. KV-Connect ist ein Nachrichtendienst ohne PUSH-Funktionalität. Deshalb gibt es keine aktive Benachrichtigung des Systems an den Nutzer, wenn Nachrichten für ihn vorliegen. KV-Connect bietet jedoch die Funktionen, diese Information aktiv zu beschaffen, indem die Header der auf dem Server liegenden Nachrichten (für den jeweiligen Nutzer) abgefragt und lokal ausgewertet werden können Ablauf "enachricht " Abbildung 1: Relevanter Workflow "enachricht" Seite 9

10 enachricht versenden Schritt 0 (Vorbedingungen) Beide kommunizierenden Systeme müssen gewisse Voraussetzungen erfüllen, um ihre Aufgaben erledigen zu können. Das empfangende System (also das System, von dessen Seite, "enachrichten" erwartet werden) muss in einer für den internen Fachprozess angemessenenen Rate nachfragen, ob eine "enachricht vorliegt" (PE01). Das System, das die "enachricht" liefert, muss es dem Versender ermöglichen, eine entsprechende "enachricht" zu erstellen (PS01). Schritt 1 Für den Versand der "enachricht" müssen der/die Adressaten / KV-Connect- Teilnehmer ausgewählt werden. Schritt 2 Die entstehende multipart-mixed -MIME-Struktur wird zuerst signiert, dann verschlüsselt (es entsteht D01) und als S/MIME enveloped-data an den betreffenden Adressaten gesendet (PS02). Schritt 3 Der Empfänger der "enachricht" generiert mit Hilfe seines Systems (im Allgemeinen des jeweiligen Primärsystems) eine oder periodische Anfragen (PE01), ob "enachrichten" mit dem entsprechenden header-feld aus Tabelle 5 vorliegen. Falls ja holt er sie vom Server (PE02 mit D01) ab. Schritt 4 Die abgeholte "enachricht" wird entschlüsselt, ihre Signatur wird geprüft und die "enachricht" wird für die Weiterverarbeitung bereitgestellt (PE02). Schritt 5 Der Empfänger der "enachricht" generiert, wenn vom Versender gewünscht, mit Hilfe seines Systems (im Allgemeinen des Primärsystems) eine MDN mit der Referenz auf die abgeholte "enachricht" (PE03, Ergebnis D02). Schritt 6 Der Versender der "enachricht" prüft fortlaufend auf MDNs zu versandten "enachrichten" (PS03). Schritt 7 Liegen für den Versender MDNs zu "enachrichten" auf dem Server vor, werden diese abgeholt, entschlüsselt, die Signatur wird überprüft und die Information weiterverarbeitet (PS04 bis PS06). Tabelle Erstellung der "enachricht" Für den Inhalt des Mail-Body der "enachricht" wird als Content-Type ausschließlich text/plain" mit dem Zeichensatz " UTF-8" erlaubt. Beliebige Dateien können zusätzlich als Anhänge hinzugefügt werden. Bei der Erstellung von "enachrichten" muss der Text-Inhalt (Mail-Body) frei editierbar sein. Da der Dienst nicht der Unterstützung eines speziellen Prozesses dient, werden keine fachlichen Metadaten benötigt Übermittlung der "enachricht" Auswahl des Adressaten: Als Vorbereitung für den Versand der "enachricht" sind der oder die KV- Connect Teilnehmer, an die die "enachricht" übermittelt werden soll, aus dem Adressverzeichnis von KV- Connect (aus dem verfügbaren LDAP oder der Suchfunktion der REST-Schnittstelle zum Server) zu identifizieren und auszuwählen. Das System muss dem Nutzer eine Suche im Adressverzeichnis in Seite 10

11 geeigneter Form anbieten. Die Implementierung muss sicherstellen, dass alle Attribute, die für eine sichere Identifikation des Empfängers notwendig sind, angezeigt werden können. Bei Systemen, die der Versendung von Massennachrichten dienen, kann stattdessen auf vorbereitete Adresslisten zurückgegriffen werden. Die Existenz einer KV-Connect Adresse sagt alleine noch nichts darüber aus, dass die damit verbundene Person auch tatsächlich bereit ist, über diesen Briefkasten" "enachrichten" entgegen zu nehmen. Sowohl die technischen Möglichkeiten (Implementierung im Primärsystem) als auch die persönliche Bereitschaft des Teilnehmers können dem entgegenstehen. Deshalb darf sich der sendende Teilnehmer a priori nicht auf die Zustellung der "enachricht verlassen"; er muss bei Bedarf selber sicherstellen, dass der Empfänger über seine KV-Connect Adresse "enachrichten" empfangen möchte und auch technisch dazu in der Lage ist. Versand: Für den Versand der "enachricht" erzeugt das Primärsystem eine MIME-Nachricht gemäß [RFC5322] und allgemeiner KV-Connect Vorgaben [PP KVC] und versendet sie mittels KV-Connect; zu Details vergleiche Kapitel "Spezifikation der Datenübermittlung". Speicherung der "enachricht": Sowohl beim Sender als auch beim Empfänger ist die "enachricht" zu speichern (default-einstellung) und bei Bedarf wieder zugänglich zu machen. Die Speicherung erfolgt unverschlüsselt (bezogen auf die Verschlüsselung durch KV-Connect), d.h. in der Form, in der die "enachricht" vom Primärsystem an KV-Connect übergeben bzw. von dort abgeholt wird, auf dem lokalen System. Je "enachricht" muss erkennbar sein, ob sie schon versandt wurde (auf Seite des Senders) bzw. ob sie schon gelesen wurde (auf Seiten des Empfängers). Außerdem ist die Dienstkennung der "enachricht" anzuzeigen, so dass der Nutzer auch ohne Öffnen der "enachricht" erkennen kann, dass es sich bei der Nachricht um eine "enachricht" handelt. Eingangsbestätigung: In der KV-Connect "enachricht" kann angegeben werden, ob der Sender eine Eingangsbestätigung erhalten möchte. Eine solche kann vom Empfänger versendet werden, wenn die "enachricht" erfolgreich von KV-Connect entgegengenommen wurde (sofern der Empfänger dem nicht widerspricht). Der Sender erhält damit eine Eingangsbestätigung über die erfolgte Übermittlung der "enachricht"; er weiß jedoch nicht, ob der Empfänger die "enachricht" auch gelesen hat Kenntnisnahme der "enachricht" Das empfangende Primärsystem muss den Empfänger über den Eingang der "enachricht" informieren und ihm den Inhalt und ggf. die Anhänge zum Lesen anbieten. Die Anzeige der Inhalte von Anhängen ist nur dann zu ermöglichen, wenn auf dem empfangenden System eine Anwendung zur Verfügung steht, die für das Öffnen von Dateien vom Typ des Anhangs vorgesehen ist. Es liegt in der Verantwortung der Kommunikationspartner, untereinander zu klären, welche Art von Dateien für den Informationsaustausch verwendet werden können. Da Inhalt bzw. Bedeutung einer "enachricht" dem System nicht bekannt sind, wird die weitere Behandlung der "enachrichten" und möglicher Anhänge alleine dem Nutzer überlassen. Das schließt nicht aus, dass das empfangende System Regelwerke zum Handling von "enachrichten" anhand des Absenders oder Subjects zur Verfügung stellt. Seite 11

12 3 Beschreibung der KV-Connect Nachrichten 3.1 Nachrichtenformate Die "enachrichten" sind verschlüsselte S/MIME-Nachrichten. Spezifikation KV-Connect Anwendungsdienst "enachricht;v2.0" Im Inneren der Container befinden sich Textkomponenten im Mail-Body sowie optional Dateien als Anhang. Die Textkomponenten im Mail-Body der "enachricht" liegen als text/plain vor. Eine Nachricht, die dieser Anforderung nicht entspricht, genügt nicht der Spezifikation des Anwendungsdienstes enachrichten" und kann nicht den Anspruch erheben, von der Gegenseite gelesen zu werden. 3.2 Inhalt der Nachrichten Der Inhalt wird von "Text" im Mail-Body gebildet.content-type: text/plaincontent-transfer- Encoding: 8bit [ENASM013]: Der Mail Body MUSS mit "text/plain" in Zeichencodierung " UTF-8" gefüllt sein. Werden Dokumente im Anhang übermittelt, gilt:content-type: multipart/mixed Für die einzelnen Dateien im Anhang gilt für " Content-type": Content-Type: text/plain, - Textdateien Content-Type: image/jpeg, - Bilddateien im JPEG-Format Content-Type: image/bmp, - Bilddateien im BMP-Format Content-Type: image/xy, - Bilddateien im xy-format Content-Type: application/pdf, - Dateien im PDF-Format Content-Type: application/ppt, - Dateien im PPT-Format Content-Type: application/xy, - Dateien im xy-format Content-Type: video/xy, - Videodateien im xy-format Content-Type: audio/xy, - Audiodateien im xy-format Content-Type: message/xy, - Nachrichtendateien im xy-format Beispiel: PDF-Datei in base64-codierung Content-Type: application/pdf, Content- Transfer-Encoding: base64 Eine Übersicht der definierten MIME-Typen finden Sie z.b. unter diesem Link. Hinweis! Dateinamen sollten keine Komponenten von personenbezogenen Informationen enthalten. Auch andere semantische Inhalte sollten bei der Namensgebung vermieden werden. 3.3 KV-Connect Nachricht 3.4 Aufbau der KV-Connect Nachrichten Verwendete Segment- und X-Attribute Zur Erleichterung der Verarbeitung von KV-Connect Nachrichten werden diese mit anwendungs- und nachrichtenspezifischen Attributen angereichert, die die Nachrichten als Ganzes aber auch deren einzelne Bestandteile kennzeichnen. Die eingesetzten Attribute entstammen einem Pool von Attributen, die zentral für alle KV-Connect Anwendungen hier dokumentiert und gepflegt werden. In der hier beschriebenen Anwendung "enachricht" kommen die folgenden Attribute zur Anwendung: Nachrichtenart Header-Attribute Erklärung enachricht Nachrichten-Typ: enachricht Seite 12

13 X-KVC-Dienstkennung: enachricht;lieferung; V2.0 MDN X-KVC-Dienstkennung: enachricht; Eingangsbestaetigung;V2.0 Nachrichten-Typ: MDN (Eingangsbestätigung) enachricht und MDN X-KVC-Sendersystem: <Systemname>; <Version> Bezeichnung und Version der Software des Senders Tabelle Struktur der Nachricht "enachricht" Die Nachrichten-Struktur Alle Nachrichten sind äußerlich ähnlich aufgebaut (siehe "Die Nachrichten-Header" ). Sie bestehen aus einem Header mit Metainformationen und einem Nachrichten- oder Mail-Body. Die Gesamtnachricht vor dem Signieren ist als Content-Type: text/plain oder als Content-Type: multipart/mixed angelegt. Als Content-Type: multipart/mixed kann die Nachricht weitere zu übermittelnde Dokumente beinhalten - technisch gesehen als Anhänge (im nachfolgenden Beispiel mit einer PDF- Datei). Content-Type: multipart/mixed; boundary=" " Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sehr geehrter Herr Kollege, TextTextTextTextTextTextTextTextTextTextTextTextTextText TextTextTextTextTextTextTextTextTextTextTextTextTextText Content-Type: application/pdf; name="musteranhang.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="musteranhang.pdf" JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIv TGFuZyhkZS1ERSkgL1N0cnVjdFRyZWVSb290IDI0IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB Pgo8MUZBQkI1QzM4QzVFNUM0QUYxOEM4RkRDRkY1QUZDRTc+IF0KL0RvY0NoZWNrc3VtIC85 ODQxM0M0ODRGNDBEMUQwQTZENzkzMkE4MTVEMkU1QQo+PgpzdGFydHhyZWYKMzc3MDQ5CiUl RU9GCg== Abbildung 2: Nachrichtenstruktur mit einer PDF-Datei als Anlage Dieser gesamte MIME-Block ist die Basis der nun folgenden Signatur. Seite 13

14 [ENASM001]: Jede "enachricht" KANN ein oder mehrere MIME-Segmente mit je einer Datei enthalten. Die Segmente MÜSSEN mindestens die folgenden Metainformationen enthalten :Content-Type:, Content-Transfer-Encoding:. Implementierungshinweis! Die im Weiteren beschriebenen Schritte: Signatur des Gesamtinhalts, Verschlüsselung und Aufbereitung zum Versand können bei Verwendung des KV-Connect Clients diesem überlassen werden. Es muss sichergestellt sein, dass die Anbindung des KV-Connect-Clients an das System entsprechend der Vorgaben realisiert wurde. Bei der Implementierung der REST-Schnittstelle durch das Softwarehaus müssen alle diese Schritte selbst implementiert werden Die Struktur des signierten S/MIME-Nachrichteninhalts Aus der so erzeugten MIME-Datei wird im nächsten Prozessschritt durch Hinzufügen einer S/MIME- Signatur die Transportsicherung erzeugt. Dabei ist die Signatur als detached-pkcs#7-signatur auszuführen. Für die Signatur ist ein Signaturzertifikat und der dazu gehörige private Schlüssel erforderlich. Beides wird nach der Anmeldung an KV-Connect erzeugt. Zum Schlüsselhandling wird auf die Dokumentation von KV-Connect allgemein, insbesondere auf das Kapitel "Public Key Infrastruktur PKI" verwiesen. Im Ergebnis entsteht eine S/MIME-Datei mit folgendem Aufbau: Seite 14

15 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary=" ms " This is a cryptographically signed message in MIME format ms Content-Type: multipart/mixed; boundary=" " Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sehr geehrter Herr Kollege, TextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTe Content-Type: application/pdf; name="musteranhang.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="musteranhang.pdf" JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIv TGFuZyhkZS1ERSkgL1N0cnVjdFRyZWVSb290IDI0IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB Pgo8MUZBQkI1QzM4QzVFNUM0QUYxOEM4RkRDRkY1QUZDRTc+IF0KL0RvY0NoZWNrc3VtIC85 ODQxM0M0ODRGNDBEMUQwQTZENzkzMkE4MTVEMkU1QQo+PgpzdGFydHhyZWYKMzc3MDQ5CiUl RU9GCg== ms Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC FGgwggQuMIIDFqADAgECAgIBDDANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEcMBoG s4pexlmulzn767fg9mpduq+t0hvk9eipazbmmzhsgfiqedxdr2z814vl5+zctqqapa0z+woi 8HKMQ2crladleE8uSn5jG1iS3B4fqjP8fzKdwYdFHWkjFrQAAAAAAAA= ms Abbildung 3: S/MIME-Datei mit einer PDF-Datei als Anlage [ENASM002]: Jedes System, das "enachrichten" versendet, MUSS sicherstellen, das der erzeugte MIME-BLOB für den Absender nach den Regeln von KV-Connect signiert wird. Seite 15

16 3.5.3 Die Struktur der verschlüsselten S/MIME-Nachricht Die bis zu diesem Schritt erzeugten S/MIME-Datei wird im nächsten Schritt verschlüsselt. Dazu ist das Zertifikat des Empfängers erforderlich. KV-Connect bietet zahlreiche Funktionen zum Umgang und zum Suchen von Zertifikaten von möglichen Empfängern. Eine KV-Connect Nachricht muss immer mindestens für den Empfänger verschlüsselt werden. Durch die Verschlüsselung entsteht ein S/MIME-File mit relativ einfacher Struktur: Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; name="smime Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: Mit S/MIME verschluesselte Nachricht MIAGCSqGSIb3DQEHA6CAMIACAQAxggF+MIIBegIBADBiMFwxCzAJBgNVBAYTAkRFMRYwFAYD VQQKDA1tZWRpc2lnbiBHbWJIMRQwEgYDVQQLDAtUZXN0YmV0cmllYjEfMB0GA1UEAwwWREVN FUSTD3KIG+AEKLfPFcpxZz4ddVydDirGJL0h0gpDUtTPGevn15Em3DRsGpKAktfrgsAEGIAk tlsvyc2wgjsjpaay+rwc7atqafezkqaaaaaaaaaaaaa= Abbildung 4: verschlüsselte S/MIME-Datei Der verschlüsselte Inhalt der oben gezeigten Dateien ist eine von außen gesehen unstrukturierte binäre Datei, die zur Übertragung Base64-kodiert wird. Mit den gezeigten Metainformationen entsteht eine S /MIME-Datei, die von geeigneter Software als Container mit verschlüsseltem Content erkannt wird. [ENASM003]: Jedes System, das "enachrichten" versendet, MUSS eine gültige KV-Connect-Adresse als Adressaten auswählen und sicherstellen, dass der erzeugte und signierte S/MIME-BLOB für diesen Adressaten verschlüsselt wird. 3.6 Struktur der Nachricht "MDN" Um den Sender darüber zu informieren, dass seine "enachricht" beim Empfänger eingegangen ist, kann eine "Message Disposition Notification" (MDN) als Eingangsbestätigung versendet werden, wenn sie vom Sender der "enachricht" angefordert wird. Eine detaillierte Beschreibung der MDNs befindet sich im Dokument "Spezifikation MDN (anwendungsübergreifend)". Im Folgenden werden die anwendungsspezifischen Anforderungen der MDNs für den Kontext der vorliegenden Spezifikation "enachricht" definiert. ENASM109: Das Element " X-KVC-Dienstkennung: " MUSS im Header der MDNs eingerichtet sein und den Wert " enachricht;eingangsbestaetigung;v2.0" haben. ENASM110: Das Element " Subject" MUSS im Header der MDNs eingerichtet sein und den Wert " enachricht-eingangsbestaetigung" haben. ENASM112: Der Nachrichten-Header MUSS ein Attribut " X-KVC-Sendersystem" entsprechend [AN_KVC] enthalten. Seite 16

17 ENASM113: Der Nachrichten-Header MUSS ein Attribut " In-Reply-To" mit der Message-ID enthalten, auf die sich diese MDN bezieht. Seite 17

18 4 Spezifikation der Datenübermittlung 4.1 Festlegung des Empfängers Spezifikation KV-Connect Anwendungsdienst "enachricht;v2.0" Die Empfänger von "enachrichten" sind bei der Kommunikation mit KV-Connect im Allgemeinen medizinische Einrichtungen oder Health-Professionals. Insbesondere sind sie alle als Teilnehmer von KV-Connect registriert und Nutzer des SNK. Aus diesem Grund können sie immer aus dem Adressverzeichnis von KV-Connect (sei es über den verfügbaren LDAP oder die Suchfunktion der REST-Schnittstelle zum Server) identifiziert und ausgewählt werden. Die Ermittlung der KV-Connect Adresse des Empfängers ist Teil der Funktionalität der REST-Schnittstelle (Kommando Account in der Spezifikation des KV-Connect-Servers in Interface+Einstiegspunkt+und+Navigation). Bei der Abfrage über diese Schnittstelle ist gesichert, dass ausschließlich ein KV-Connect Teilnehmer ausgewählt wird und dass damit eine Verschlüsselung möglich ist. Es ist Aufgabe des Primär-, Warenwirtschafts-, Laborinformations- oder Kommunikationssystems, dem Nutzer die Informationen zu präsentieren (siehe unten), die die richtige Auswahl der Adressaten ermöglichen. Es sind nur diejenigen Teilnehmer auffindbar, die sich mindestens einmal an ihrem Konto angemeldet und ein Zertifikat erzeugt haben. Für Nachrichten mit vielen Adressaten kann ggf. zusätzlich auf vorab zusammengestellte Adresslisten zurückgegriffen werden. Es bleibt dem umsetzenden Software- bzw. Systemhaus überlassen, ob es aus Vertragsinformationen des Arztes die für den jeweiligen Arzt relevanten KV-Connect Adressen vorkonfiguriert und im Workflow zwingend auswählt, diese als Default-Einstellung in einer Auswahl-Box setzt oder dem Anwender die Auswahl aus der Adressliste vollständig überlässt. Die Systeme sollten zur Vermeidung von Zuordnungsfehlern möglichst die automatisierte Ermittlung der Empfängeradresse mit der Möglichkeit des manuellen Änderns vorsehen. Die Verschlüsselungszertifikate der Adressaten dürfen nicht gespeichert werden. Es besteht die Möglichkeit, dass sich zwischen zwei KV-Connect Nachrichten die Zertifikate des Adressaten ändern. Der Fall eines Rückrufs infolge Korrumpierung oder der Anforderung eines neuen Zertifikats (vor dem Ablauf der Gültigkeit) könnte zu einer derartigen Situation führen. In diesem Fall muss immer das neueste Zertifikat benutzt werden. Beim lokalen Speichern eines Zertifikats kann es also zu Problemen kommen, die vermieden werden, sofern das gültige Zertifikat zu einer bekannten Adresse immer aktuell mit den Werkzeugen von KV-Connect abgefragt wird. 4.2 Der Nachrichten-Header Die in den bisher beschriebenen Schritten erzeugte S/MIME-Datei muss vor ihrem Versand mit weiteren Informationen angereichert werden, um beim Empfänger anzukommen und dort zielgerichtet verarbeitet werden zu können. Dazu muss ein Mail-Header vorangestellt werden, der die benötigten Angaben zur Transaktion enthält: Die Unterscheidung der Nachrichten, insbesondere bei der Abholung vom Server, ergibt sich aus den Inhalten der Metadaten-Items " Subject: " und " X-KVC-Dienstkennung: ". Die Headereinträge " Disposition-Notification-To: " und " Return-Path: " kennzeichnen eine "enachricht", für die eine MDN angefordert wird. Ob eine MDN angefordert wird, wird bei der Erstellung der jeweiligen Nachrichten so angegeben, wie vom Absender der Nachricht gewünscht. Ist keine MDN vorgesehen, so wird der Headereintrag " Disposition-Notification-To: " nicht genutzt (siehe dazu auch "Spezifikation MDN" ). Das Element "Subject" muss, entsprechend der Vorgaben (siehe Tabelle 3) befüllt werden, um zu verhindern, dass im Betreff datenschutzrelevante Informationen übermittelt werden. Seite 18

19 Nachrichtentyp Subject enachricht enachricht Eingangsbestätigung (MDN) enachricht-eingangsbestaetigung Tabelle 3: Vorgaben für das Element "Subject:" Die " Message-ID: " muss gemäß Spezifikation in RFC 5322 vom Anwendungssystem erzeugt und im Header der Nachricht eingetragen werden. Falls eine Eingangsbestätigung (MDN, Message Disposition Notification) angefordert werden soll, ist in den Header der Nachricht das Feld " Disposition-Notification-To: " aufzunehmen. Als Wert ist die KV-Connect Adresse des Senders anzugeben. Diese Adresse ist zusätzlich im Feld " Return-Path: " anzugeben. (Siehe RFC 3798 für Details.) Im Header muss das Feld " X-KVC-Dienstkennung: " gesetzt und mit dem Wert " enachricht; Lieferung;V2.0" gefüllt werden. Im Header muss das Feld " X-KVC-Sendersystem: " gesetzt und mit dem Namen des sendenden Softwaresystems und seiner Version nach dem Syntax "<Sotwaresystem>; <Version>" gefüllt werden. Date: Tue, 14 Oct :46:57 From: MIME-Version: 1.0 To: Message-ID: < > Subject: enachricht Return-Path: Disposition-Notification-To: X-KVC-Dienstkennung: enachricht;lieferung;v2.0 X-KVC-Sendersystem: Beispiel-PVS;V3.78 Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: Mit S/MIME verschluesselte Nachricht MIAGCSqGSIb3DQEHA6CAMIACAQAxggF+MIIBegIBADBiMFwxCzAJBgNVBAYTAkRFMRYwFAYD VQQKDA1tZWRpc2lnbiBHbWJIMRQwEgYDVQQLDAtUZXN0YmV0cmllYjEfMB0GA1UEAwwWREVN FUSTD3KIG+AEKLfPFcpxZz4ddVydDirGJL0h0gpDUtTPGevn15Em3DRsGpKAktfrgsAEGIAk tlsvyc2wgjsjpaay+rwc7atqafezkqaaaaaaaaaaaaa= Abbildung 5: Beispiel "enachricht" (Mail-Header und verschlüsselter Inhalt) Die auf diese Weise vervollständigte Struktur kann als -Datei (Endung:.eml) abgelegt und direkt an einen Mail-Server weiter geleitet werden. Seite 19

20 [ENASM004]: Der Nachrichten-Header MUSS die " X-KVC-Dienstkennung: enachricht; Lieferung;V2.0" enthalten. [ENASM005]: Der Nachrichten-Header MUSS ein Attribut " X-KVC-Sendersystem" entsprechend [AN_KVC] enthalten. [ENASM006]: Das Element " Subject" der Einsendung MUSS mit dem Wert enachricht gefüllt sein. [ENAEN007]: Der Empfänger MUSS für jede vom KV-Connect Server abgeholte "enachricht", die in den Attributen Disposition-Notification-To: und " Return-Path: " angegebene Adresse auf ihre Gültigkeit überprüfen. Sollte die Adresse über die von KV-Connect zur Verfügung gestellten Werkzeuge nicht positiv überprüfbar sein, so ist eine Fehlermeldung auszugeben. Die MDN an diese Adresse ist dann nicht zu erzeugen. [ENASM008]: Der Empfänger MUSS für jede vom KV-Connect Server abgeholte "enachricht" genau eine MDN nach den Maßgaben dieser Spezifikation an die in den Attributen Disposition- Notification-To: und " Return-Path: " angegebene Adresse versenden, sofern diese Attribute vorhanden und die Inhalte identisch sind. Anhand der Feldinhalte der X-Attribute kann das empfangende Anwendungssystem entscheiden, ob und wie es diese Dienst-Nachricht verarbeiten kann, und ggf. welches seiner Komponenten die Verarbeitung übernimmt. Beim Versand von "enachrichten" sollte zwar sichergestellt sein, dass nur Adressaten angegeben werden, die diese Nachrichten auch verarbeiten können; um Konformität mit anderen Diensten zu erreichen. Da diese Bedingung technisch nicht gesichert werden kann, ist das X-KVC- Dienstkennungsfeld unbedingt erforderlich. Seite 20

21 5 Anforderungen an die Software-Systeme In diesem Kapitel sind die Anforderungen zusammengestellt, die die verschiedenen beteiligten Software- Systeme erfüllen müssen. Die Anforderungen sind immer im Kontext, der in den vorangegangenen Kapiteln gegebenen Erläuterungen zu verstehen, auch wenn nicht in jedem Einzelfall darauf verwiesen wird. Zur Verbindlichkeit der Anforderungen: Die Worte muss und kann sind gezielt eingesetzt, um die Verbindlichkeit der einzelnen Anforderungen anzugeben. Insbesondere sind kann -Anforderungen solche, deren Umsetzung empfohlen wird, um allen beteiligten Systemen und Personen eine möglichst komfortable und sichere Handhabung des Dienstes zu erlauben; sie sind aber nicht zwingend notwendig, um am Anwendungsdienst enachricht teilnehmen zu können. Die "muss"-anforderungen sind auf jeden Fall umzusetzen. 5.1 Anforderungen an die Systeme zum Empfang von "enachrichten" Die Software-Systeme, die "enachrichten" empfangen möchten, müssen folgende Anforderungen erfüllen um erfolgreich auditiert zu werden: Das System muss es dem Nutzer ermöglichen, aktiv oder automatisiert (periodisch) den KV- Connect Server nach "enachrichten" abzufragen, diese abzuholen und dem lokalen System im ursprünglichen Format (Fo rmat vor der Verschlüsselung) zur weiteren Verarbeitung zur Verfügung zu stellen. Das System muss zu jeder empfangenen "enachricht" eine MDN erzeugen und an den Absender der Nachricht zurücksenden können, wenn dieser eine MDN angefordert hat (ohne weitere Auswahl der Empfängeradresse). Das System kann den Eingang einer "enachricht" unabhängig davon anzeigen, ob der KV- Connect Posteingang oder ein anderes KV-Connect Fenster geöffnet ist. Das System muss dem Nutzer eingehende "enachrichten" so anzeigen, dass der Nutzer den Absender und das Versanddatum gemäß Angabe im header-feld Date" (orig-date) angezeigt bekommt (ggf. nach weiterer Aktion wie Details anzeigen") erkennen kann, dass es sich bei der Nachricht um eine "enachricht" handelt, die "enachricht" öffnen kann, erkennt, ob die "enachricht" Anhänge enthält. Das System muss dem Nutzer die Möglichkeit bieten, sich den Inhalt der "enachricht" (Text) anzeigen zu lassen. Das System speichert die eingegangenen "enachrichten" in einem Posteingangsordner" und gibt dem Nutzer die Möglichkeit, sich die "enachrichten" erneut anzeigen zu lassen. Die "enachrichten" sind so gekennzeichnet, dass der Nutzer auch ohne Öffnen einer "enachricht" erkennen kann, ob sie schon geöffnet worden ist, ob es sich um eine enachricht" oder eine Nachricht eines anderen Dienstes handelt, ob sie Anhänge enthält von wem und wann sie gesendet worden ist. [ENAEN014]: Das System MUSS es dem Nutzer ermöglichen, aktiv oder automatisiert (periodisch) den KV-Connect-Server nach "enachrichten" abzufragen, diese abzuholen und dem lokalen System im ursprünglichen Format zur weiteren Verarbeitung zur Verfügung zu stellen. [ENAEN015]: Das System MUSS dem Nutzer eingehende "enachrichten" so anzeigen, dass der Nutzer: Seite 21

22 den Absender und das Versanddatum lesen kann, erkennen kann, dass es sich bei der Nachricht um eine "enachricht" handelt, die "enachricht" öffnen kann, erkennen kann, ob die "enachricht" Anhänge enthält. [ENAEN016]: Das System MUSS dem Nutzer die Möglichkeit bieten, sich den Inhalt der "enachricht" (Text) anzeigen zu lassen. [ENAEN017]: Das System MUSS die eingegangenen "enachrichten" in einem Posteingangsordner" speichern und dem Nutzer die Möglichkeit geben, sich die "enachrichten" erneut anzeigen zu lassen. Die "enachrichten" sind so gekennzeichnet, dass der Nutzer auch ohne Öffnen einer "enachricht" erkennen kann, ob sie schon geöffnet worden ist, ob es sich um eine enachricht" oder eine Nachricht eines anderen Dienstes handelt, ob sie Anhänge enthält von wem und wann sie gesendet worden ist. 5.2 Anforderungen an die Systeme zum Versand von "enachrichten" Die Software-Systeme, die "enachrichten" versenden möchten, müssen folgende Anforderungen erfüllen um erfolgreich auditiert zu werden: Das System muss es dem Nutzer ermöglichen, eine "enachricht" in dem im Kapitel "Beschreibung der KV-Connect Nachrichten" beschriebenen Format zu erstellen. Das System erlaubt es dem Benutzer, den Inhaltstext frei zu editieren sowie anzugeben, ob er eine Eingangsbestätigung (MDN) erhalten möchte. Zusätzlich ermöglicht das System dem Nutzer, beliebige Dateien als Anhänge anzufügen. Das System muss es dem Nutzer ermöglichen, den Adressaten der Nachricht zu bestimmen. Dies kann durch Auswahl aus dem KV-Connect Adressverzeichnis (LDAP) erfolgen. Bei der Auswahl muss das System dem Benutzer ermöglichen, sich alle Informationen anzeigen zu lassen, die notwendig sind, um den gewünschten Adressaten zu identifizieren. Jede Nachricht kann mit mehreren Empfängern auch im Cc-Feld versehen werden. Das System muss es dem Nutzer ermöglichen, die "enachricht" inkl. Anhängen (sofern vorhanden) mittels KV-Connect an die ausgewählten Adressaten zu übertragen. Dazu erzeugt das System eine KV-Connect MIME-Nachricht mit den im Kapitel "Spezifikation der Datenübermittlung" spezifizierten Attributen, trägt als Absender die KV-Connect Adresse des aktuellen Nutzers ein und übergibt die Nachricht zum Versand an den KV-Connect-Server. Das System muss auf dem KV-Connect-Server vorliegende MDNs identifizieren und abholen (hier nur die MDNs zur "enachricht") und sie dem Nutzer in geeigneter Form automatisch oder auf Anforderung anzeigen können. Dazu soll das System eingehende MDNs prüfen, ob sie sich auf den Anwendungsdienst enachricht beziehen, und die Nachricht, auf die sich die MDN bezieht, als bestätigt markieren und dem Nutzer die Möglichkeit bieten, sich die (noch) nicht bestätigten "enachrichten" anzeigen zu lassen. (Der Bezug kann über die Message-ID hergestellt werden.) Das System speichert alle ausgehenden Nachrichten in einem Postausgangsordner" und gibt dem Nutzer die Möglichkeit, sich die "enachrichten" erneut anzeigen zu lassen. Die "enachrichten" sind so gekennzeichnet, dass der Nutzer auch ohne Öffnen einer Nachricht erkennen kann, Seite 22 um welche Nachricht es sich handelt (in der Regel durch Angabe von Adressat (KV- Connect Adresse) und Versanddatum), ob sie erfolgreich gesendet worden ist,

23 ob es sich um eine enachricht" oder eine Nachricht eines anderen Dienstes handelt. [ENASN018]: Das System MUSS auf dem Server vorliegende MDNs (zur "enachricht") identifizieren und abholen. [ENASN019]: Das System MUSS es dem Nutzer ermöglichen, den Adressaten der Nachricht zu bestimmen. [ENASN020]: Das System MUSS alle ausgehenden Nachrichten in einem Postausgangsordner" speichern und dem Nutzer die Möglichkeit bieten, sich die "enachrichten" erneut anzeigen zu lassen. Die "enachrichten" sind so gekennzeichnet, dass der Nutzer auch ohne Öffnen einer Nachricht erkennen kann, um welche Nachricht es sich handelt (in der Regel durch Angabe von Adressat (KV-Connect Adresse) und Versanddatum), ob sie erfolgreich gesendet worden ist, ob es sich um eine enachricht" oder eine Nachricht eines anderen Dienstes handelt. Achtung! Durch die Software-Häuser MÜSSEN die Anforderungen für den Empfang und den Versand von "enachrichten" umgesetzt werden. Seite 23