als pdf - KV Telematik

Transcription

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. (https://creativecommons.org/licenses/by-sa/3.0/de/legalcode)
Inhaltsverzeichnis
1
Vorbemerkungen
6
1.1
Zweck des Dokumentes
6
1.2
Inhalt
6
1.3
Geltungsbereich
6
1.4
Referenzen
6
1.5
Ziel
6
1.6
Ausgangssituation
7
1.7
Lösungsansatz
7
1.8
Allgemeine Voraussetzungen
7
1.9
Grundlage: KV-Connect
7
2
Prozess-Beschreibung
8
2.1
Anforderungen
8
2.2
Geschäftsvorfälle (Use Cases)
8
2.2.1
Gesamtablauf aus Sicht der Teilnehmer
9
2.2.2
Ablauf "eNachricht "
9
2.2.3
Erstellung der "eNachricht"
10
2.2.4
Übermittlung der "eNachricht"
10
2.2.5
Kenntnisnahme der "eNachricht"
11
3
Beschreibung der KV-Connect Nachrichten
12
3.1
Nachrichtenformate
12
3.2
Inhalt der Nachrichten
12
3.3
KV-Connect Nachricht
12
3.4
Aufbau der KV-Connect Nachrichten
12
3.4.1
Verwendete Segment- und X-Attribute
12
3.5
Struktur der Nachricht "eNachricht"
13
3.5.1
Die Nachrichten-Struktur
13
3.5.2
Die Struktur des signierten S/MIME-Nachrichteninhalts
14
3.5.3
Die Struktur der verschlüsselten S/MIME-Nachricht
15
3.6
Struktur der Nachricht "MDN"
16
4
Spezifikation der Datenübermittlung
18
4.1
Festlegung des Empfängers
18
4.2
Der Nachrichten-Header
18
5
Anforderungen an die Software-Systeme
21
5.1
Anforderungen an die Systeme zum Empfang von "eNachrichten"
21
5.2
Anforderungen an die Systeme zum Versand von "eNachrichten"
22
Spezifikation KV-Connect Anwendungsdienst "eNachricht;V2.0"
Änderungshistorie
Vers.
Datum
Autor
Kap.
Änderung
Status
1.1;B
04.01.2016
Volker
Dentel
alle
Erstellung Version 2.0
intern
1.2;B
10.02.2016
Volker
Dentel
alle
Einarbeitung Änderungen Aufbau
Mustermails
intern
1.3;B
18.04.2016
Volker
Dentel
alle
Einarbeitung Änderungen
in Arbeit
1.4;K
18.04.2016
Volker
Dentel
Freigabe interne Kommentierung
interne
Kommentierung
1.5;K
28.04.2016
Volker
Dentel
Freigabe Kommentierung
in Kommentierung
1.6;B
30.05.2016
Volker
Dentel
Einarbeitung
Kommentierungsergebnisse
intern
2.0
11.07.2016
Volker
Dentel
Freigabe
in Kraft
alle
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
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
[PP KVC]: Dokumentation zu KV-Connect
[AN_KVC]: Anbindung an KV-Connect, ftp://ftp.kbv.de/ita-update/Stammdateien/SDKVCA/KVConnect.zip
[MDN]: Spezifikation MDN (anwendungsübergreifend)
[RFC5322]: RFC 5322 „Internet Message Format"
[MIME]: Übersicht der MIME-Typen
1.5 Ziel
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" E-Mail, 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
1.6 Ausgangssituation
KV-Connect ermöglicht schon mit seiner Basisfunktionalität die Übermittlung von Nachrichten, die
gemäß gängiger E-Mail-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 E-Mail-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 KVConnect 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
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
2. 8
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.
2.2.1 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.
2.2.2 Ablauf "eNachricht "
Abbildung 1: Relevanter Workflow "eNachricht"
Seite 9
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-ConnectTeilnehmer 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 1
2.2.3 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.
2.2.4 Übermittlung der "eNachricht"
Auswahl des Adressaten: Als Vorbereitung für den Versand der "eNachricht" sind der oder die KVConnect Teilnehmer, an die die "eNachricht" übermittelt werden soll, aus dem Adressverzeichnis von KVConnect (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
geeigneter
Seite 10 Form anbieten. Die Implementierung muss sicherstellen, dass alle Attribute, die für eine
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.
2.2.5 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
3 Beschreibung der KV-Connect Nachrichten
3.1 Nachrichtenformate
Die "eNachrichten" sind verschlüsselte S/MIME-Nachrichten.
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-TransferEncoding: 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, TextdateienContent-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-FormatContent-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, ContentTransfer-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
3.4.1 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
eNachricht
Seite 12
Header-Attribute
Erklärung
Nachrichten-Typ: eNachricht
X-KVC-Dienstkennung: eNachricht;Lieferung;
V2.0
MDN
X-KVC-Dienstkennung: eNachricht;
Eingangsbestaetigung;V2.0
eNachricht und X-KVC-Sendersystem: <Systemname>;
<Version>
MDN
Nachrichten-Typ: MDN
(Eingangsbestätigung)
Bezeichnung und Version der
Software des Senders
Tabelle 2
3.5 Struktur der Nachricht "eNachricht"
3.5.1 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 PDFDatei).
Content-Type: multipart/mixed;
boundary="------------090503050308020008070506"
--------------090503050308020008070506
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sehr geehrter Herr Kollege,
TextTextTextTextTextTextTextTextTextTextTextTextTextText
TextTextTextTextTextTextTextTextTextTextTextTextTextText
--------------090503050308020008070506
Content-Type: application/pdf; name="Musteranhang.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Musteranhang.pdf"
JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIv
TGFuZyhkZS1ERSkgL1N0cnVjdFRyZWVSb290IDI0IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0
...
...
Pgo8MUZBQkI1QzM4QzVFNUM0QUYxOEM4RkRDRkY1QUZDRTc+IF0KL0RvY0NoZWNrc3VtIC85
ODQxM0M0ODRGNDBEMUQwQTZENzkzMkE4MTVEMkU1QQo+PgpzdGFydHhyZWYKMzc3MDQ5CiUl
RU9GCg==
--------------090503050308020008070506--
Abbildung 2: Nachrichtenstruktur mit einer PDF-Datei als Anlage
Dieser gesamte MIME-Block ist die Basis der nun folgenden Signatur.
Seite 13
[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.
3.5.2 Die Struktur des signierten S/MIME-Nachrichteninhalts
Aus der so erzeugten MIME-Datei wird im nächsten Prozessschritt durch Hinzufügen einer S/MIMESignatur 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
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol="application/pkcs7-signature"; micalg=sha-256;
boundary="------------ms060308000506080109010903"
This is a cryptographically signed message in MIME format.
--------------ms060308000506080109010903
Content-Type: multipart/mixed;
boundary="------------020009040507010605000602"
--------------020009040507010605000602
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sehr geehrter Herr Kollege,
TextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTextTex
--------------020009040507010605000602
Content-Type: application/pdf; name="Musteranhang.pdf"
Content-Disposition: attachment; filename="Musteranhang.pdf"
JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIv
TGFuZyhkZS1ERSkgL1N0cnVjdFRyZWVSb290IDI0IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0
...
...
Pgo8MUZBQkI1QzM4QzVFNUM0QUYxOEM4RkRDRkY1QUZDRTc+IF0KL0RvY0NoZWNrc3VtIC85
ODQxM0M0ODRGNDBEMUQwQTZENzkzMkE4MTVEMkU1QQo+PgpzdGFydHhyZWYKMzc3MDQ5CiUl
RU9GCg==
--------------020009040507010605000602
----------------ms060308000506080109010903
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
FGgwggQuMIIDFqADAgECAgIBDDANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEcMBoG
...
...
s4PExlMulzN767FG9mpDuq+t0HVK9eiPaZbMmzHsgFIqeDXDR2z814Vl5+zctqQapA0z+wOi
8HKMQ2crladleE8uSn5jG1iS3B4fqjP8fzKdwYdFHWkjFrQAAAAAAAA=
--------------ms060308000506080109010903--
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.
3.5.3 Die Struktur der verschlüsselten S/MIME-Nachricht
Seite 15
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.p7m"
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
ENASM113: Der Nachrichten-Header MUSS ein Attribut "In-Reply-To" mit der Message-ID
enthalten, auf die sich diese MDN bezieht.
Seite 17
4 Spezifikation der Datenübermittlung
4.1 Festlegung des Empfängers
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
https://partnerportal.kv-telematik.de/display/KVCSERVERSPEC/RESTInterface+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
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 2014 10:46:57
From: [email protected]
MIME-Version: 1.0
To: [email protected]
Message-ID: < [email protected] >
Subject: eNachricht
Return-Path: [email protected]
Disposition-Notification-To: [email protected]
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-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 E-Mail-Datei (Endung: .eml) abgelegt und direkt
an einen Mail-Server weiter geleitet werden.
Seite 19
[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 „DispositionNotification-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-KVCDienstkennungsfeld unbedingt erforderlich.
Seite 20
5 Anforderungen an die Software-Systeme
In diesem Kapitel sind die Anforderungen zusammengestellt, die die verschiedenen beteiligten SoftwareSysteme 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 KVConnect 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 KVConnect 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
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,
um welche Nachricht es sich handelt (in der Regel durch Angabe von Adressat (KVConnect Adresse) und Versanddatum),
ob sie erfolgreich gesendet worden ist,
Seite 22
Spezifikation KV-Connect
Anwendungsdienst
"eNachricht;V2.0"
ob sie erfolgreich
gesendet worden
ist,
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

als pdf - KV Telematik

Transcription

Similar documents

der Audit-Anforderungen als pdf

Schulinterne Lehrerfortbildung (SchiLF)

Alternative UCITS

tactical mounts - Glaser

Verteilte Systeme Überblick Standardanwendungen

- KV Telematik

Antiquariat Wilhelm Hohmann