Tipps und Tricks KV Connect Nachrichten. Was man bei der Anbindung an KV-Connect nicht falsch machen muss

Transkript

1 Tipps und Tricks KV Connect Nachrichten Was man bei der Anbindung an KV-Connect nicht falsch machen muss

2 Motivation Zunehmender Traffic Entstehendes Monitoring auffällige Fehler größtenteils einfach zu beseitigen

3 Einschränkungen bruchstückhaft, d.h. kein Anspruch auf Vollständigkeit, aus dem Verständnis des Autors, in Auswertung konkreter Beispiele

4 Themen: Sendersystemkennung Dienstkennung Kryptographie Attachments Nicht erwartete Nachrichten

5 Sendersystem-Kennung Die Sendersystem-Kennung soll erkennen lassen, von welchem Primärsystem (PVS / AIS / KIS) die jeweilige Transaktion gesteuert wird. GUSbox;V256, DMP-Assist, Massenclient CGM-Connect erfüllen diese Anforderung nicht Aktuelle Maßnahme: Audit mit Auflage

6 Dienstkennung Dienstkennungen sind case-sensitiv V groß Schreibweise der Versionsnummer wie in Spezifikation: ;V1.0 Richtung etc. nicht vergessen: 1ClickAbrechnung;Lieferung;V2.0 DALE-UV;Einsendung;V1.0 abd-dia;einsendung;v1.0 earztbrief;vhitg-versand;v1.0 edmp;einsendung;v1.0 sqs;einsendung;v1.0 Kein Leerzeichen Sendungen ohne gültige Dienstkennung werden möglicherweise langfristig vom Server abgelehnt

7 Codierungen MIME-Format: MIME-konforme Zeilenumbrüche <CR><LF> (wichtig bei Beteiligung von Unix- Systemen) Attachments: Im Zweifel Base64-codieren Unterschied zwischen Content-Type und Content-Description : Content-Type: in MIME-RFCs spezifiziert, z.b. text/plain oder application/pdf, im Zweifel application/octet-stream Content-Description: in KVC-Anwendungen spezifiziert, z.b. edmp;einsendung;v1.0

8 Konkret bei edmp: Content-Type des ZIP-Archivs: Content-Type: edmp-bericht Falsch! Kein gültiger Content-Type lt. MIME Content-Type: application/x-zip-compressed Content-Type: application/octet-stream Falsch! XKM ist kein ZIP! Richtig!

9 Nachrichten-Verschlüsselung Aktuell gilt für die symmetrische Mail-Verschlüsselung noch die Nutzung von AES- 128 als verbindlich. Im Laufe 2016 wird die Kryptographie schrittweise auf AES 256 erhöht, Systeme sollten frühestmöglich in die Lage versetzt werden, solche Nachrichten zu entschlüsseln (viele Kryptobibliotheken tun das automatisch) Zum Testen werden die Test- bzw. Audit-Clients zeitnah so umgestellt, dass Empfang mit AES-128 noch geprüft wird, aber Rückmeldungen (Quittungen, Prüfberichte, ) bereits mit AES-256 verschlüsselt werden. Die Umstellung auf AES-256 für den Versand sollte nach Vorankündigung durch einfaches Parametrisieren möglich sein.

10 Toleranz auch bei Body und Attachments Es gibt bei KV-Connect-Nachrichten keine Vorgabe für die Gestaltung des Nachrichten-Body s. Dieser kann vorhanden sein oder nicht. In der Regel ist er zu ignorieren. Unterscheidungsmerkmal: Content-Disposition: attachment; filename= so kommen die Dokumente! Es gibt bei KV-Connect-Nachrichten keine Vorgabe für die Reihenfolge von Attachments! Das heißt: Die Identifikation eines Dokuments in der Nachricht sollte immer anhand des angegebenen Content-Type im jeweiligen MIME-Segment erfolgen und keinesfalls nach der Position.

11 Umgang mit unerwarteten Nachrichten Bezüglich des Feldes "X-KVC-Dienstkennung" können folgende Fehler auftreten: Es wurde keine Dienstkennung in den MIME-Header eingefügt. Die Dienstkennung entspricht nicht den anwendungsspezifischen Vorgaben (Anwendungs-übergreifende Identifikatoren), d.h. der Inhalt des Feldes ist falsch: Es wurde die falsche Dienstkennung verwendet. Die Dienstkennung wurde falsch geschrieben (case-sensitive)

12 Umgang mit unerwarteten Nachrichten (II) Daraus ergeben sich somit folgende Probleme: Filterung ist nicht mehr möglich Zuordnung zum System nicht möglich (beim Einsatz von mehreren Systemen) Ablage in Posteingangsordner ggf. nicht möglich In vielen Fällen wird die Nachricht nicht abgeholt, wenn das empfangende System seine Prozesse (Filterung, Zuordnung oder Ablage) konsequent an der Dienstkennung orientiert hat und Nachrichten mit falscher oder ohne Dienstkennung ignoriert. Dem Anwender können so wichtige Informationen entgehen, bspw. erhält er keine Arztbriefe oder Befunde bzw. Meldungen, dass Dokumentationen von Datenannahmestellen nicht angenommen wurden Nicht abgeholte Nachrichten werden i.d.r. auch nicht gelöscht, diese bleiben als Zombies im Postfach liegen

13 Umgang mit unerwarteten Nachrichten (III) Zu empfehlen ist eine Differenzierung nach der empfangenen Dienstkennung in drei Kategorien von Nachrichten: Nachrichten mit Dienstkennungen, die das lokale System erwartet (und also auch verarbeiten kann), Nachrichten mit Dienstkennungen, die ein anderes System unter derselben Adresse erwartet und verarbeiten kann und Nachrichten mit Dienstkennungen, die keines der eingesetzten Systeme erwartet und die keins der Systeme, die ein bestimmtes Postfach abrufen, interpretieren kann.

14 Die Default-Nachricht für Unerwartetes Die Default-Nachricht wird vom System des Anwenders erstellt. Die Default-Nachricht enthält nur die Header der Nachricht, die nicht zugeordnet werden kann. Damit liegen dem Anwender alle Informationen vor, die notwendig sind, um die Nachricht einordnen zu können. Die Nachricht kann aus der Default-Nachricht heraus aufgerufen oder gelöscht werden. Dem Anwender obliegt selbst die Auswahl, ob er die angebotene Nachricht liest oder ggf. löscht. Die Default-Nachricht wird standardmäßig angezeigt, wenn der Anwender sich am System anmeldet und Nachrichten abgerufen werden. In jedem Fall sollte die Nachricht schlussendlich gelöscht werden.

15 Beispiel: Eine Krankenhaus-Ambulanz ist am KIS angeschlossen und macht darüber DALE- UV (und sonst nichts per KV-Connect). Gleichzeitig steht in der Ambulanz ein PVS, mit dem die Kassenabrechnung gemacht wird (und sonst nichts per KV- Connect). Im Postfach laufen DALE-Quittungen ein, aber auch Abrechnungsquittungen und (unerwartet) Arztbriefe und enachrichten. Wie muss eine sinnvolle Reaktion aussehen? Das KIS muss die Abrechnungsquittungen ignorieren und auf dem Server liegen lassen. Das PVS muss die DALE-UV-Quittungen ignorieren und auf dem Server liegen lassen. Mindestens eins der Systeme (besser beide) sollen die restlichen Nachrichten (einschließlich solcher ganz ohne Dienstkennung) - so wie oben beschrieben - als "Default-Nachricht" behandeln.

16 Realisierungs-Vorschlag Realisieren lässt sich ein solches Verhalten mit Hilfe von zwei Listen: einer Positiv-Liste (enthält die Dienstkennungen aller Anwendungen, die das empfangende System erwartet und verarbeiten kann) und einer Negativ-Liste (enthält die Dienstkennungen aller Anwendungen um die sich "ein anderes System kümmert und die somit tabu sind).

17 Listen-gesteuerte Verarbeitungslogik Die Listen sind ausschließlich für das empfangende System bestimmt und müssen dort bei der Konfiguration gefüllt/angepasst werden. Die Wirkung der Listen ist folgende: Für Nachrichten, deren Dienstkennungen auf der "Positiv-Liste" steht, wir die Bearbeitung ganz normal fortgesetzt, diese werden Angezeigt, gespeichert, verarbeitet,... (und final vom Server gelöscht). Nachrichten, deren Dienstkennungen auf der "Negativ-Liste" stehen, werden ignoriert und auf dem Server belassen. Nachrichten, deren Dienstkennung in keiner der beiden Listen vorkommen, werden entsprechend der oben beschriebenen "Default-Nachrichten"-Regel behandelt.

18 Exakt senden, tolerant empfangen Filter gerade für Dienstkennungen sollten so eingerichtet sein, dass sie nur so exakt sind wie erforderlich. z.b. ist zu bedenken, ob die in der Dienstkennung mitgelieferte Versions-Information relevant ist, ob Groß- und Kleinschreibung ignoriert werden kann

19 Vielen Dank!