Spezifikation LDT 3.x (Auftrag) Spezifikation KV-Connect Anwendungsdienst LDT 3 (Auftrag) mit KV-Connect 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.1.1 Inhalt 6 1.2 Referenzen 6 1.3 Ziel 6 1.4 Ausgangssituation 7 1.5 Mehrwerte durch den Einsatz elektronischer Laborkommunikation mit KV-Connect 7 1.5.1 Beseitigung bekannter Probleme 7 1.5.2 Zusatznutzen 7 1.6 Allgemeine Voraussetzungen 7 1.7 Geltungsbereich 8 1.8 Bezug zum Audit 8 2 Prozess-Beschreibung 9 2.1 Use Cases 9 2.1.1 Gesamtablauf aus Sicht der Teilnehmer 9 2.1.2 Ablauf Laborauftrag 11 2.1.3 Ablauf Laborauftrag (Option Status-Nachrichten zum Stand der Analytik) 13 3 Beschreibung der KV-Connect Nachrichten 17 3.1 Nachrichtenformate 17 3.2 Aufbau der KV-Connect Nachrichten 17 3.2.1 Verwendete X-Attribute, Segment-Attribute und Subject-Inhalte 17 3.3 Fachliche Inhalte der Nachrichten 18 3.3.1 Erstellung des LDT-Auftrages 18 3.3.2 Die LDT-Datei 19 3.3.3 Digitales Muster 10/10A 19 3.4 Struktur der Nachricht "Laborauftrag" 20 3.4.1 Die Nachrichten-Struktur 20 3.4.2 Die Struktur des signierten S/MIME-Nachrichteninhalts 22 3.4.3 Die Struktur der verschlüsselten S/MIME-Nachricht 24 3.4.4 Der Nachrichten-Header 24 3.5 Struktur der Nachricht "MDN" 26 3.6 Struktur der Nachricht "Status" (optional) 26 3.6.1 Status-Nachricht für Zustand 1 (Material ist vollständig im Labor angekommen): 27 3.6.2 Status-Nachricht für Zustand 2 (Material fehlt): 27 3.6.3 Status-Nachricht für Zustand 3 (Frei - Vereinbarung zwischen Kommunikationspartnern notwendig): 27 3.6.4 Die Struktur des signierten S/MIME-Nachrichteninhalts (Status-Nachricht) 28
3.6.5 Die Struktur der verschlüsselten S/MIME-Nachricht (Status-Nachricht) 29 3.6.6 Der Nachrichten-Header 30 4 Festlegung des Empfängers 34 5 Anforderungen an die Software-Systeme 35 5.1 Anforderungen an die Systeme zum Empfang von Aufträgen 35 5.2 Anforderungen an die Software zum Versand von Aufträgen 36
Änderungshistorie Vers. Datum Autor Kap. Änderung Status 0.2;K 15.02.2017 Volker Dentel Veröffentlichung zur Kommentierung in Kommentierung 0.2;E 07.02.2017 Volker Dentel 1-5 Einarbeitung Vorgaben Anlage 2b BMV-Ä nicht veröffentlicht 0.1;E 13.07.2016 Volker Dentel 1-5 initiale Erstellung nicht veröffentlicht 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 Spezifikation KV-Connect Anwendungsdienst LDT 3 (Auftrag) mit KV-Connect Dieses Dokument dient der Spezifikation des KV-Connect Anwendungsdienstes LDT 3 (Auftrag) mit KV- Connect. Basis dieser Spezifikation ist die aktuell gültige Spezifikation des LDT (LaborDatenTräger) in der Version 3.x. Der LDT 3 wurde vom QMS e.v. (Qualitätsring Medizinische Software) und der KBV gemeinsam erstellt und wird von Beiden weiter gepflegt. Achtung! Wird in dieser Spezifikation das Kürzel LDT ohne weitere Konkretisierung genutzt, so ist immer der LDT 3 in seiner aktuellen Version gemeint. Sollte eine andere Version gemeint sein, so ist dies an den entsprechenden Stellen explizit ausgewiesen. Die Spezifikation LDT 3 (Auftrag) mit KV-Connect umfasst unter Umständen nicht den gesamten Umfang der Use-Cases des LDT 3 sondern fokussiert primär (allerdings nicht unbedingt ausschließlich) auf das Laborgeschehen im humanmedizinischen Umfeld. Weiterhin sind die anwendbaren Teile der Spezifikation von KV-Connect Grundlage dieses Dokumentes. 1.1.1 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 und den Aufbau der KV-Connect-Nachrichten. Kapitel 4 Spezifikation der Datenübermittlung beschreibt die Schritte, die für eine erfolgreiche Übermittlung der Nachrichten erforderlich sind. Kapitel 5 Anforderungen an die Software-Systeme beschreibt die durch die Software-Systeme umzusetzenden Anforderungen. 1.2 Referenzen 1.3 Ziel [LDT 3]: Datensatzbeschreibung LDT 3, ftp://ftp.kbv.de/ita-update/labor/ldt3.0/ [PP KVC]: Dokumentation zu KV-Connect, https://partnerportal.kv-telematik.de/x/dia6 [KVC-Anb]: Anbindung an KV-Connect, ftp://ftp.kbv.de/ita-update/kv-connect [MDN]: Spezifikation MDN (anwendungsübergreifend) https://partnerportal.kv-telematik.de/x /dwwpaq [RFC5322]: https://tools.ietf.org/html/rfc5322 [BMV-Ä]: Bundesmantelvertrag-Ärzte, http://www.kbv.de/html/bundesmantelvertrag.php [KBV_ITA_VGEX_Technisches_Handbuch_DiMus]: Technisches Handbuch Digitale Muster [REST]: Beschreibung der REST-Schnittstelle des KV-Connect-Servers https://partnerportal.kvtelematik.de/x/kgkpaq [ANWID]: Anwendungs-übergreifende Identifikatoren https://partnerportal.kv-telematik.de/x /3YJTAQ 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 im Kontext der Beauftragung von Laborleistungen mittels LDT 3 stehen. Seite 6
1.4 Ausgangssituation Die Kommunikation zwischen Auftraggeber und Labor besteht im Allgemeinen aus (mindestens) zwei Vorgängen: Auftraggeber kommuniziert mit dem Labor und Labor kommuniziert mit dem Auftraggeber. Auf Spezifika wird später genauer eingegangen. Inhaltlich wird in Auftrags- und die Befundübermittlung strukturiert: Auftragsübermittlung: In der Praxis wird die Überweisung an einen Laborfacharzt mittels z.b. Formular Muster 10, Muster 10 (digital),... oder eine Anforderung an die Laborgemeinschaft (LG) mittels Formular Muster 10A, Muster 10 A (digital) oder eine Überweisung an andere Labore, erstellt. Der Auftrag (Überweisung bzw. Anforderung) und Probe werden an das beauftragte Labor übermittelt. Befundübermittlung: Nach Abschluss der Untersuchungen im Labor (Laborfacharzt oder LG) werden die Ergebnisse dem Auftraggeber im LDT-Format zur Verfügung gestellt. Die Befundübermittlung ist nicht Bestandteil dieser Spezifikation! (siehe dazu "Spezifikation LDT 3.x (Befund) mit KV-Connect") 1.5 Mehrwerte durch den Einsatz elektronischer Laborkommunikation mit KV- Connect Derzeit bieten medizinische Laboratorien ihren Kunden verschiedenste Modelle der elektronischen Übermittlung von Auftragsdaten an. Eine nicht unwesentliche Herausforderung besteht derzeit in der außerordentlich heterogenen kommunikationstechnischen Anbindung der Auftraggeber an die Labore. Durch die Definition von digitalen Mustern in der Anlage 2b des BMV-Ä wurde die Möglichkeit geschaffen, den gesamten Workflow der Auftragserstellung, Übermittlung und Auftragsannahme von Laboranforderungen komplett medienbruchfrei zu gestalten. 1.5.1 Beseitigung bekannter Probleme KV-Connect als Transportmechanismus für Labordaten hilft, eine Reihe bekannter Probleme im Laborumfeld zu minimieren bzw. zu beseitigen: Datenschutz: Durch KV-Connect werden alle zu übertragenden Nachrichten ausschließlich mit der für die erforderliche Vertraulichkeit geeigneten Verschlüsselung Ende-zu-Ende verschlüsselt. Supportentlastung: Das Aufsetzen des Transportmechanismus auf eine bestehende Infrastruktur kann den Supportaufwand durch die Laboreinrichtungen erheblich entlasten. Verzicht auf weitere kryptografische Werkzeuge und eigene PKI: Auf deren Einsatz kann verzichtet werden, da in KV-Connect bereits eine datenschutzkonforme Verschlüsselung umgesetzt ist. Damit entfällt auch der Zwang zum Aufbau einer PKI-ähnlichen Struktur, da bereits eine PKI mit der KV-Connect-Registrierung über die jeweilige KV frei Haus geliefert wird. 1.5.2 Zusatznutzen optionale Eingangsbestätigungen: KV-Connect ermöglicht mit seinen Standardfunktionen den Versand/das Abholen von Eingangsbestätigungen (MDN) also eine Bestätigung im Falle einer erfolgreichen Übermittlung einer KV-Connect-Nachricht von der Arztpraxis zum Labor und/oder vom Labor an die Arztpraxis. Der besondere Fokus liegt hier auf der Eingangsbestätigung zum Laborauftrag. optionale Übermittlung von zusätzlichen Nachrichten: Das Laboratorium kann mittels sog. KV- Connect-Status-Nachrichten den Auftraggeber über den Status der Bearbeitung des Auftrages informieren. Realisieren und Anwenden dieser Funktion obliegt der bilateralen Absprache zwischen den jeweiligen Kommunikationspartnern. Seite 7
1.6 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 Dienste 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. Krankenhausinformationssystem das Audit für den Anwendungsdienst "LDT 3 (Auftrag)" erfolgreich abgeschlossen hat, kann das Versenden/Abholen von LDT-Daten beginnen. Eine vorherige rechtzeitige Absprache mit den Kommunikationspartnern vor dem erstmaligen Einsatz des LDT-Versandes mit KV-Connect ist dringend geraten. Für die Erzeugung der LDT-Datei gelten die Vorgaben der LDT-Datensatzbeschreibung in der jeweils aktuellen Version [LDT 3]. In der vorliegenden Spezifikation wird ausschließlich der Weg der Auftragsübertragung spezifiziert. Achtung: In der vorliegenden Spezifikation wird ausschließlich der Weg der Auftragsübertragung spezifiziert. 1.7 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 Nachrichten, den Inhalt von und den Umgang mit Eingangsbestätigungen (MDN) sowie den optionalen Status-Nachrichten. 1.8 Bezug zum Audit Die Implementierung der KV-Connect-Anwendung "LDT 3 (Auftrag)" durch die Softwarehäuser kann im Rahmen des LDT 3 (Auftrag) - Audits durch die KV Telematik GmbH überprüft werden. Audit-Kriterien, die sich auf die vorliegende Spezifikation beziehen, werden in den nachstehenden Kapiteln explizit als Audit-Kriterien hervorgehoben. Wie z.b. [LDTSM530]: Jede Sendung MUSS genau eine LDT-Datei enthalten. Das Beispiel hat an dieser Stelle keinen Bezug zur Fachlichkeit der Spezifikation. Seite 8
2 Prozess-Beschreibung Die Datensatzbeschreibung des LDT 3 [LDT 3] des QMS e.v. und der KBV dient hier als Grundlage für die Beschreibung der zu übertragenden Daten. Die Datensatzbeschreibung in der jeweilig aktuellen Version steht hier zum Download bereit. 2.1 Use Cases Die Spezifikation der Labor-Auftragsübertragung beschreibt in der im LDT 3 definierten Begrifflichkeit derzeit zwei Use Cases, die sich für das Kommunikationssystem unterscheiden lassen. Sie ergeben sich aus den spezifischen Anforderungen der Labordatenkommunikation. Der Gesamtvorgang beschreibt den Informationsvorgang (Labor-Auftrag), der einen Workflow im beauftragten Laboratorium zur Analytik und letzendlich Befunderstellung und -übertragung initiiert. Der Befundweg wird hier nicht beschrieben. Einsender (Auftraggeber) Nachricht: LDT-Auftrag Satzart 8215 Laboratorium (Auftragnehmer) Die Use Cases teilen sich bei Benutzung eines serverbasierten Kommunikationssystems, wie es KV- Connect ist, technisch in mindestens zwei Teilvorgänge auf. 1. 2. 3. Versand einer Laborauftrags-Nachricht an den KV-Connect-Server Der Einsender (Arztpraxis, Krankenhaus, Labor, sonstige Einrichtung) erzeugt eine LDT-Datei mit den Satzarten 8230, 8215 und 8231. Daraus wird eine KV-Connect-Nachricht an das zu beauftragende Laboratorium (Auftragnehmer) erstellt und an den KV-Connect-Server verschickt. Als zweiten Schritt, insgesamt aber periodisch, fragt das System den KV-Connect-Server nach Eingangsbestätigungen zu den versandten Nachrichten ab und ergreift, je nach Status der Bestätigungen oder danach, ob überhaupt Bestätigungen empfangen werden, geeignete Maßnahmen. Abholen einer Laborauftrags-Nachricht vom KV-Connect-Server Das System des Auftragnehmers (medizinisches Laboratorium) fragt den KV-Connect-Server nach vorliegenden Nachrichten mit der zutreffenden X-KVC-Dienstkennung (Tabelle 3) ab und holt diese ab. Nach erfolgreichem Abholen kann eine Eingangsbestätigung (MDN) erzeugt und für den Absender der jeweiligen Nachricht an den KV-Connect-Server versendet werden. Die empfangenen Daten werden in geeigneter Weise intern weiter verarbeitet. Optional: Nachrichten zum aktuellen Status des Bearbeitung des Auftrages Das System des medizinischen Laboratoriums kann mittels spezieller Status-Nachrichten die beauftragende Stelle über den Stand der Bearbeitung des erhaltenen Auftrages informieren. Hier können Nachrichten vom Auftragnehmer an den Auftraggeber versandt werden, wenn z.b. das benötigte Material für den Auftrag eingetroffen ist, die Analytik abgeschlossen ist oder auch die Information, dass betimmte Materialien nicht beim Auftragnehmer angekommen sind. Hierzu ist eine Abstimmung zwischen den Kommunikationspartnern zu den Nachrichteninhalten notwendig. 2.1.1 Gesamtablauf aus Sicht der Teilnehmer Wie in der obigen Kurzbeschreibung erkennbar existieren bei den derzeitigen Use Cases zwei Teilnehmer, der Einsender[1] und das Labor. Die Prozesse, Dokumente und Schnittstellen der beiden 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. Achtung: In der vorliegenden Spezifikation wird nur die Auftragsübertragung beschrieben. Seite 9
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[2]. 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 werden und lokal ausgewertet werden können. Laborauftrag Der Laborauftrag wird beim Auftraggeber elektronisch als LDT-Datei erzeugt und mit dem LDT- Prüfmodul geprüft. Für die notwendige Identifikation der Probengefäße werden entweder vom jeweiligen Auftragnehmer vorgefertigte maschinenlesbare Etiketten (Barcode) zur Verfügung gestellt, bzw. aus dem den Auftrag erstellendem System ausgedruckt. Ein digitales Muster (siehe Anlage 2b BMV-Ä) kann im Obj_0010 (Anhang) des LDT-Datensatzes als base64-kodierte Anlage eingefügt werden. Vor dem Einfügen des digitalen Musters müssen die Inhalte des LDT und des dazugehörigen digitalen Musters mittels des KBV-Prüfmoduls auf semantische Übereinstimmung geprüft werden. Eine Weiterverarbeitung des LDT und des/der dazugehörigen digitalen Muster ist nur zulässig, wenn die Prüfung keine "Fehler" ergeben hat. Die LDT-Datei wird als KV-Connect-Nachricht an das zu beauftragende Laboratorium versendet. Die Probengefäße, die mit den entsprechenden Identifikationsetiketten versehen sind, werden physikalisch dem Laboratorium zugestellt (Kurierdienste, Postversand etc.). Laborbefund Der elektronische Versand der Ergebnisse eines Laborauftrags ist in der Spezifikation KV-Connect Anwendungsdienst LDT 3.x (Befund) beschrieben. Seite 10
Spezifikation KV-Connect Anwendungsdienst LDT 3 (Auftrag) mit KV-Connect 2.1.2 Ablauf Laborauftrag Abbildung 1: Relevanter Workflow Laborauftrag Seite 11
LDT-Laborauftrag 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, egal auf welchem Weg, ein Laborauftrag erwartet wird) muss in einer für den internen Fachprozess angemessenenen Rate nachfragen, ob ein Auftrag vorliegt (L01). Das System, das die Aufträge erstellt (also im Allgemeinen das PVS/KIS/LIS/System zur Erstellung LDT- Auftragsdateien), muss es dem Nutzer ermöglichen, einen Laborauftrag, ggf. das bzw. die digitalen Muster und die Etiketten für die Probengefäß-Identifikation zu erzeugen bzw. zu verwalten (PS01 - PS03). Schritt 1 Der Einsender/der Auftraggeber einer Laborleistung generiert mit Hilfe des PVS /KIS/LIS/System zur Erstellung LDT-Auftragsdateien einen Laborauftrag als LDT- Datei und ggf. das bzw. die digitalen Muster (PS01). Schritt 2 Die LDT-Datei und ggf. das bzw. die digitalen Muster werden vom Prüfmodul geprüft und müssen den Gesamt-Prüfstatus OK haben (PS02). Schritt 3 Der Einsender/der Auftraggeber einer Laborleistung erstellt mit Hilfe des PVS/KIS /LIS/Systems die KV-Connect-Nachricht "LDT-Auftrag;Lieferung" (PS03a, es entsteht D01). Das System erstellt bzw. verwaltet die Etiketten für die Identifikation der Probengefäße. Die Probengefäße werden mit den jeweiligen Etiketten beklebt (PS03b). Die Probengefäße werden an das Labor übersandt (Kurier, Post o.ä.). Schritt 4 Die KV-Connect-Nachricht "LDT-Auftrag;Lieferung" wird zuerst signiert, dann verschlüsselt (PS05) und als S/MIME enveloped-data an den betreffenden Adressaten gesendet (PS05). Schritt 5 Der Empfänger des Auftrags generiert mit Hilfe seines Systems (im Allgemeinen des jeweiligen LIS) eine oder periodische Anfragen (L01), ob Nachrichten mit der entsprechenden X-KVC-Dienstkennung "LDT-Auftrag;Lieferung;V1.0" vorliegen. Falls ja holt er sie vom Server (L02 mit D01). Schritt 6 Die abgeholte Nachricht wird entschlüsselt und ihre Signatur wird geprüft (L02). Schritt 7 Die LDT-Datei wird an das LIS zur weiteren Verarbeitung übergeben (L03). Schritt 8 Der Empfänger der Nachricht "LDT-Auftrag;Lieferung" generiert, wenn vom Versender gewünscht, mit Hilfe seines Systems (im Allgemeinen des jeweiligen LIS) eine MDN mit der Referenz auf die abgeholte Nachricht (L04, Ergebnis D02) und versendet diese an den jeweiligen Empfänger. Schritt 9 Der Einsender/der Auftraggeber einer Laborleistung prüft fortlaufend auf MDNs zu versandten Nachrichten (PS06 - PS08), holt diese ab und kann so die interne Auftragsverwaltung steuern (PS08). Tabelle 1 Seite 12
2.1.3 Ablauf Laborauftrag (Option Status-Nachrichten zum Stand der Analytik) Mit der Funktion "Status-Nachrichten", welche optional umgesetzt werden kann, wird es dem Laboratorium ermöglicht, seinen Einsender über den Status des Probeneinganges zu informieren. Hierbei sind folgende Status-Meldungen Bestandteil dieser Spezifikation: Material zu Auftrag... vollständig im Labor eingetroffen Material... zu Auftrag... fehlt Mittels dieser Funktion wird die Kommunikation zwischen Einsender und Laboratorium auf eine neue Stufe gehoben. Informationen zu fehlenden Materialien zu einem Auftrag können dem Einsender zeitnah mitgeteilt und entsprechende Maßnahmen eingeleitet werden, damit die Analytik zeitnah erfolgen kann. Hinweis: Zwischen den Kommunikationspartnern können weitere Status-Nachrichten vereinbart werden. Diese müssen im Grundaufbau den spezifizierten Nachrichten entsprechen. Über die Inhalte im Feld "subject" werden die Status-Nachrichten unterschieden. Im Folgenden ist der Ablauf für den Versand einer LDT 3.x (Auftrag) - Nachricht und die optionale Funktion "Status-Nachrichten" beschrieben. Seite 13
Spezifikation KV-Connect Anwendungsdienst LDT 3 (Auftrag) mit KV-Connect Abbildung 2: Relevanter Workflow Laborauftrag (Option "Status-Nachrichten" umgesetzt) Seite 14
LDT-Laborauftrag und Option Status-Nachrichten 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, egal auf welchem Weg, ein Laborauftrag erwartet wird) muss in einer für den internen Fachprozess angemessenenen Rate nachfragen, ob ein Auftrag vorliegt (L01). Das System, das die Aufträge erstellt (also im Allgemeinen das PVS/KIS/LIS/System zur Erstellung LDT- Auftragsdateien), muss es dem Nutzer ermöglichen, einen Laborauftrag, ggf. das bzw. die digitalen Muster und die Etiketten für die Probengefäß-Identifikation zu erzeugen bzw. zu verwalten (PS01 - PS03). Schritt 1 Der Einsender/der Auftraggeber einer Laborleistung generiert mit Hilfe des PVS /KIS/LIS/System zur Erstellung LDT-Auftragsdateien einen Laborauftrag als LDT- Datei und ggf. das bzw. die digitalen Muster (PS01). Schritt 2 Die LDT-Datei und ggf. das bzw. die digitalen Muster werden vom Prüfmodul geprüft und müssen den Gesamt-Prüfstatus OK haben (PS02). Schritt 3 Der Einsender/der Auftraggeber einer Laborleistung erstellt mit Hilfe des PVS/KIS /LIS/Systems die KV-Connect-Nachricht "LDT-Auftrag;Lieferung" (PS03a, es entsteht D01). Das System erstellt bzw. verwaltet die Etiketten für die Identifikation der Probengefäße. Die Probengefäße werden mit den jeweiligen Etiketten beklebt (PS03b). Die Probengefäße werden an das Labor übersandt (Kurier, Post o.ä.). Schritt 4 Die KV-Connect-Nachricht "LDT-Auftrag;Lieferung" wird zuerst signiert, dann verschlüsselt (PS05) und als S/MIME enveloped-data an den betreffenden Adressaten gesendet (PS05). Schritt 5 Der Empfänger des Auftrags generiert mit Hilfe seines Systems (im Allgemeinen des jeweiligen LIS) eine oder periodische Anfragen (L01), ob Nachrichten mit der entsprechenden X-KVC-Dienstkennung "LDT-Auftrag;Lieferung;V1.0" vorliegen. Falls ja holt er sie vom Server (L02 mit D01). Schritt 6 Die abgeholte Nachricht wird entschlüsselt und ihre Signatur wird geprüft (L02). Schritt 7 Die LDT-Datei wird an das LIS zur weiteren Verarbeitung übergeben (L03). Schritt 8 Der Empfänger der Nachricht "LDT-Auftrag;Lieferung" generiert, wenn vom Versender gewünscht, mit Hilfe seines Systems (im Allgemeinen des jeweiligen LIS) eine MDN mit der Referenz auf die abgeholte Nachricht (L04, Ergebnis D02) und versendet diese an den jeweiligen Empfänger. Schritt 9 Der Einsender/der Auftraggeber einer Laborleistung prüft fortlaufend auf MDNs zu versandten Nachrichten (PS06 - PS08), holt diese ab und kann so die interne Auftragsverwaltung steuern (PS08). Die etikettierten Probengefäße werden beim Laboratorium angeliefert. Im Probeneingang des Laboratoriums wird das eingegangene Material erfasst. Option 1 Prüfung: Kann mit dem eingegangenen Material die beauftragte Analytik durchgeführt werden. Seite 15
Option 1.1 Ergebnis der Prüfung ist positiv (L08). Das Laboratorium generiert eine Status- Nachricht mit dem Inhalt: "Material zu Auftrag <Auftragsnummer des Einsenders (8310)> vollständig im Labor eingetroffen" (D03). Option 1.2 Ergebnis der Prüfung ist negativ (L09). Das Laboratorium generiert eine Status- Nachricht mit dem Inhalt: "Material <Bezeichnung (8430)> zu Auftrag <Auftragsnummer des Einsenders (8310)> fehlt!" (D04). Option 2 Die Status-Nachrichten werden zuerst signiert, dann verschlüsselt und an den betreffenden Adressaten gesendet. Schritt 10 Der Einsender/der Auftraggeber einer Laborleistung prüft fortlaufend auf Status- Nachrichten zum Auftrag (PS09 - PS10), holt diese ab und verarbeitet die Nachrichteninhalte so, dass dem Nutzer die Informationen in übersichtlicher Weise präsentiert werden (PS11). Analytik im Laboratorium verläuft nach dem intern festgelegten Workflow. Tabelle 2 [1] Einsender sind nicht zwingend ausschließlich Ärzte (es können z.b. auch Labore sein)[2] Sollte PUSH erforderlich sein, so kann diese Funktionalität nur außerhalb KV-Connect und nur ohne Übermittlung von personenbezogenen Inhalten realisiert werden. Seite 16
3 Beschreibung der KV-Connect Nachrichten 3.1 Nachrichtenformate Die KV-Connect-Nachrichten "LDT-Auftrag" sind verschlüsselte S/MIME-Nachrichten. Für die Anwendung "LDT-Auftrag" werden im Folgenden drei Nachrichtentypen spezifiziert: Nachricht "LDT-Auftrag;Lieferung": Mittels der Nachricht wird die LDT-Datei, die entsprechend der Vorgaben der jeweils aktuellen Version der LDT 3 - Datensatzbeschreibung erstellt wurde, übertragen, Nachricht "LDT-Auftrag;Eingangsbestaetigung": Die MDNs (Eingangsbestätigungen) sind üblicherweise reine Textnachrichten und optional die Nachricht "LDT-Auftrag;Status": Die Status-Nachrichten sind ebenfalls reine Textnachrichten. 3.2 Aufbau der KV-Connect Nachrichten 3.2.1 Verwendete X-Attribute, Segment-Attribute und Subject-Inhalte 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 [ANWID] dokumentiert und gepflegt werden. In der hier beschriebenen Anwendung kommen die folgenden Attribute zur Anwendung: Nachrichtenart (Teil 1) Header-Attribute Erklärung Laborauftrag X-KVC-Dienstkennung: LDT-Auftrag; Lieferung;V1.0 Nachrichten-Typ: LDT-Auftrag; Lieferung MDN X-KVC-Dienstkennung: LDT-Auftrag; Eingangsbestaetigung;V1.0 Nachrichten-Typ: LDT-Auftrag; Eingangsbestaetigung Status-Nachricht X-KVC-Dienstkennung: LDT-Auftrag; Status;V1.0 Nachrichten-Typ: LDT-Auftrag;Status übergreifend in allen Nachrichten Software des Senders X-KVC-Sendersystem: <Systemname>;<Version> Bezeichnung und Version der zertifizierten Software des Senders Dokumentenart (Teil 2) Segment-Attribute Zusatz-Metainfos: Content-Description nach RFC LDT-Laborauftrag Content-Description: LDT-Labor- Auftrag MIME-Segment der LDT-Auftragsdatei Tabelle 3 Das Element "Subject" muss, entsprechend der folgenden Vorgaben befüllt werden, um zu verhindern, dass im Betreff datenschutzrelevante Informationen übermittelt werden. Seite 17
Nachrichtentyp Subject Laborauftrag LDT-Laborauftrag Eingangsbestätigung (MDN) zum Laborauftrag LDT-Laborauftrag-Eingangsbestaetigung Status-Nachricht (Material vollständig) LDT-Laborauftrag-Status-Material-vollstaendig Status-Nachricht (Material fehlt) LDT-Laborauftrag-Status-Material-fehlt Status-Nachricht (frei) LDT-Laborauftrag-Status-<Inhalt wird durch Kommunikationspartner festgelegt>* * siehe dazu Bemerkungen zu Zustand 3 unter Struktur der Nachricht "Status" (optional) Tabelle 4: Vorgaben für das Element "Subject:" 3.3 Fachliche Inhalte der Nachrichten 3.3.1 Erstellung des LDT-Auftrages Der Auftrag wird im Format LDT 3.x vom PVS/KIS/LIS oder Kommunikationssystem erstellt. Die Erstellung der LDT-Auftrags-Datei ist nicht Gegenstand dieser Spezifikation und wird als gegeben vorausgesetzt. Die Referenz für die (formale) Richtigkeit des Auftrages sind die Spezifikationsteile des LDT 3.x der zuständigen Prüfstellen, der KBV und des QMS e.v.. Achtung! Eine LDT-Auftrags-Datei kann einen oder mehrere Aufträge (Satzart 8215) enthalten! Prüfung des Auftrages Vor der Erzeugung der KV-Connect-Nachricht muss die LDT-Auftrags-Datei aus Gründen der Qualitätssicherung durch das LDT 3-Prüfmodul geprüft werden. Abhängig vom Inhalt der Auftragsdatei sollten dabei die folgenden Prüfstrategien beachtet werden: Einsatz von: Basismodul KBV-Modul QMS-Modul Reine GKV-Daten x x GKV-Daten und Nicht-GKV-Daten gemischt x x x Reine Nicht-GKV-Daten x x Tabelle 5 Seite 18
3.3.2 Die LDT-Datei Die LDT-Datei enthält die Informationen zum Laborauftrag in strukturierter, maschinenverarbeitbarer Form. 01380008230 0188132Kopfdaten 0178002Obj_0032 0258151Sendendes_System 0178002Obj_0051 0170001LDT3.0.6 0198315Labor27/12 0198316Arzt123456 0250105V/31/1512/24/aaa 0190103Muster PVS 01801328.12.0.95 0178003Obj_0051 0408218Timestamp_Erstellung _Datensatz 0178002Obj_0054 017727820151212 0157279123020 0298235Person_zum_Timestamp 0178002Obj_0047 011742002 0193101Musterarzt 0143102Klaus 0183104Dr. med. 0178003Obj_0047 0178003Obj_0054 0178003Obj_0032 01072651 0328122Einsenderidentifikation...... 01380018215 01380008231 049930b6d6b48aeeff9b41e0dd1b7005a1c81b4fd8fc1d 01380018231 Abbildung 3: LDT-Datensatz (Beispiel) 3.3.3 Digitales Muster 10/10A Die Datensatzbeschreibung lässt es zu, dass in den Obj_0010 (Objekt Anhang) auch ein PDF-Dokument als Base64-kodierte Datei enthalten sein kann. Dies kann für den Auftragsdatensatz auch ein gemäß den Vorgaben der Anlage 2b des BMV-Ä erstelltes digitales Muster 10 bzw. 10A sein. Dabei ist zu beachten, dass die Feldkennung 9970 mit dem festgelegten Inhalt für das jeweilige Muster (Muster 10 = 010, Muster 10A = 10A) gefüllt ist. Seite 19
0158110Anhang 0178002Obj_0010 0129970010 0318242base64-kodierte_Anlage 0178002Obj_0068 0696329JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFn 0696329ZXMgMiAwIFIvTGFuZyhkZS1ERSkgL1N0cnVjdFRyZWVSb290IDI0IDAgUi9N 0696329YXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+Pg0KZW5kb2JqDQoyIDAgb2JqDQo8 0696329PC9UeXBlL1BhZ2VzL0NvdW50IDEvS2lkc1sgMyAwIFJdID4+DQplbmRvYmoN...... 0696329eHJlZg0KMCAwDQp0cmFpbGVyDQo8PC9TaXplIDIzNy9Sb290IDEgMCBSL0lu 0696329Zm8gMjMgMCBSL0lEWzwxNEYyMDM2N0VBRDZBODQ1QTU0QzhGQTA3Q0M2N0Iy 0696329MT48MTRGMjAzNjdFQUQ2QTg0NUE1NEM4RkEwN0NDNjdCMjE+XSAvUHJldiAy 0696329ODI3NDAvWFJlZlN0bSAyODIwNjU+Pg0Kc3RhcnR4cmVmDQoyODc2NDANCiUl 0136329RU9G 0178003Obj_0068 0126303PDF 0178003Obj_0010 Abbildung 4: Obj_0010 (Anhang) mit Base64-kodiertem digitalen Muster 10 3.4 Struktur der Nachricht "Laborauftrag" Die Nachricht "LDT-Auftrag;Lieferung" besteht (neben den minimal erforderlichen MIME-Komponenten) aus nur einer LDT-Datei. Wie im vorherigen Kapitel beschrieben kann diese Datei mehr als einen Auftrag (Satzart 8215) enthalten. Abbildung 5: Struktur einer Auftrags-Nachricht 3.4.1 Die Nachrichten-Struktur Die Nachricht "LDT-Auftrag;Lieferung" besteht aus einem Header mit Metainformationen und einem Nachrichten- oder Mail-Body, der auch leer sein darf. Die Gesamtnachricht vor dem Verschlüsseln ist als Content-Type: multipart/mixed angelegt und enthält die zu übermittelnde LDT-Datei technisch gesehen als Anhang. Seite 20
Content-Type: multipart/mixed; boundary="------------090503050308020008070506" This is a multi-part message in MIME format. --------------090503050308020008070506 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Body des LDT-Auftrages --------------090503050308020008070506 Content-Type: text/plain; name="z01auftrag_8215.ldt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="z01auftrag_8215.ldt" Content-Description: LDT-Labor-Auftrag MDEzODAwMDgyMjANCjAxODgxMzJLb3BmZGF0ZW4NCjAxNzgwMDJPYmpfMDAzMg0KMDI1ODE1 MVNlbmRlbmRlc19TeXN0ZW0NCjAxNzgwMDJPYmpfMDA1MQ0KMDE3MDAwMUxEVDMuMC4xDQow...... CjAzMjgyMDBFaW5zZW5kZXJpZGVudGlmaWthdGlvbiANCjAxMTczMjEwMQ0KMDEzODMxMjA0 NTINCjAwOTgyMDENCjAwOTgwMDE= --------------090503050308020008070506-- Abbildung 6: Nachrichtenstruktur [LDTSM500]: Jede LDT-Auftrags-Nachricht MUSS genau ein MIME-Segment mit einer base64- kodierten, geprüften LDT-Datei enthalten. Das Segment MUSS die folgenden Metainformationen enthalten ( Content-Type: text/plain, Content-Transfer-Encoding: base64, Content- Disposition: attachment, Content-Description: LDT-Labor-Auftrag). Der angegebene Dateiname MUSS den Konventionen der LDT 3 -Spezifikation mit der Endung.ldt (Großoder Kleinschreibung erlaubt) entsprechen. Dieser gesamte MIME-Block ist die Basis der nun folgenden Signatur. 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. Seite 21
3.4.2 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 22
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" This is a multi-part message in MIME format. --------------020009040507010605000602 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Body des LDT-Auftrages --------------020009040507010605000602 Content-Type: text/plain; charset=utf-8; name="z01auftrag_8215.ldt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="z01auftrag_8215.ldt" Content-Description: LDT-Labor-Auftrag MDEzODAwMDgyMjANCjAxODgxMzJLb3BmZGF0ZW4NCjAxNzgwMDJPYmpfMDAzMg0KMDI1ODE1 MVNlbmRlbmRlc19TeXN0ZW0NCjAxNzgwMDJPYmpfMDA1MQ0KMDE3MDAwMUxEVDMuMC4xDQow...... CjAzMjgyMDBFaW5zZW5kZXJpZGVudGlmaWthdGlvbiANCjAxMTczMjEwMQ0KMDEzODMxMjA0 NTINCjAwOTgyMDENCjAwOTgwMDE= --------------020009040507010605000602 ----------------ms060308000506080109010903 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= --------------ms060308000506080109010903-- Abbildung 7: S/MIME-Datei Für die Signatur ist bei KV-Connect der Hash-Algorithmus SHA-256 vorgeschrieben. Seite 23
[LDTSM501]: Jedes System, das "LDT-Auftrag"-Nachrichten versendet, MUSS den erzeugten MIME- BLOB für den Absender nach den Regeln von KV-Connect signieren. 3.4.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 mit 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-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: Mit S/MIME verschluesselte Nachricht MIAGCSqGSIb3DQEHA6CAMIACAQAxggF+MIIBegIBADBiMFwxCzAJBgNVBAYTAkRFMRYwFAYD VQQKDA1tZWRpc2lnbiBHbWJIMRQwEgYDVQQLDAtUZXN0YmV0cmllYjEfMB0GA1UEAwwWREVN...... FUSTD3KIG+AEKLfPFcpxZz4ddVydDirGJL0h0gpDUtTPGevn15Em3DRsGpKAktfrgsAEGIAk tlsvyc2wgjsjpaay+rwc7atqafezkqaaaaaaaaaaaaa= Abbildung 8: 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. [LDTSM502]: Jedes System, das "LDT-Auftrag"-Nachrichten versendet, MUSS eine gültige KV- Connect-Adresse als Adressaten auswählen und den erzeugten signierten S/MIME-BLOB für diesen Adressaten verschlüsseln. 3.4.4 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: Seite 24 Die Unterscheidung der Nachrichten, insbesondere bei der Abholung vom Server, ergibt sich aus den Inhalten der Metadaten-Items " Subject: " und " X-KVC-Dienstkennung: ". Das Element "Subject" muss, entsprechend der Vorgaben (siehe Tabelle 4) befüllt werden, um zu verhindern, dass im Betreff datenschutzrelevante Informationen übermittelt werden. Im Header muss das Feld " X-KVC-Dienstkennung: " gesetzt und entsprechend der Vorgaben [LDTSM503] 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. Die " " muss gemäß Spezifikation in vom Anwendungssystem erzeugt Message-ID: RFC 5322 und im Header der Nachricht eingetragen werden.
Die Headereinträge " Disposition-Notification-To: " und " Return-Path: " kennzeichnen eine Nachricht, 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" ). 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.) Nachricht "LDT-Auftrag;Lieferung;V1.0" Date: Tue, 14 Dec 2016 10:46:57 From: ArztABC@kv-safenet.de MIME-Version: 1.0 To: LaborXY.kvno@kv-safenet.de Message-ID: <20161014104657.703@kv-safenet.de> Subject: LDT-Laborauftrag Return-Path: ArztABC@kv-safenet.de Disposition-Notification-To: ArztABC@kv-safenet.de X-KVC-Dienstkennung: LDT-Auftrag;Lieferung;V1.0 X-KVC-Sendersystem: Beispiel-PVS;V1.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 9: Beispielhafte Nachricht "LDT-Auftrag;Lieferung;V1.0" Die auf diese Weise vervollständigte Struktur kann als E-Mail-Datei (Endung:.eml) abgelegt und direkt an einen Mail-Server weiter geleitet werden. [LDTSM503]: Der Nachrichten-Header MUSS die " X-KVC-Dienstkennung: LDT-Auftrag; Lieferung;V1.0" enthalten. [LDTSM504]: Der Nachrichten-Header MUSS ein Attribut " X-KVC-Sendersystem" entsprechend [KVC-Anb] enthalten. [LDTSM505]: Das Subject der Einsendung MUSS LDT-Laborauftrag sein. Seite 25
3.5 Struktur der Nachricht "MDN" Um den Sender darüber zu informieren, dass seine Nachricht beim Empfänger eingegangen ist, kann eine "Message Disposition Notification" (MDN) als Eingangsbestätigung versendet werden, wenn sie vom Sender der Nachricht angefordert wurde. 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 "LDT 3.x (Auftrag)" definiert. [ LDTEM600] : Das Element " X-KVC-Dienstkennung: " MUSS im Header der MDNs eingerichtet sein und den Wert " LDT-Auftrag;Eingangsbestaetigung;V1.0" haben. [ LDTEM601] : Das Element " Subject" MUSS im Header der MDNs eingerichtet sein und den Wert " LDT-Laborauftrag-Eingangsbestaetigung" haben. [ LDTEM602] : Der Nachrichten-Header MUSS ein Attribut " X-KVC-Sendersystem" entsprechend [AN_KVC] enthalten. [ LDTEM603] : Der Nachrichten-Header MUSS ein Attribut " In-Reply-To" mit der Message-ID enthalten, auf die sich diese MDN bezieht. 3.6 Struktur der Nachricht "Status" (optional) Um den Versender der Laborauftrag-Nachricht über den Eingang des Materials zum Auftrag zu informieren, können durch das Software-System des Labors entsprechende Status-Nachrichten erzeugt und versendet werden. Die "Status-Nachricht" kann folgende Zustände signalisieren: Zustand 1: Das Material für die Durchführung der Analytik zum Auftrag <Auftragsnummer des Einsenders> ist vollständig im Labor angekommen. Zustand 2: Das Material <Bezeichnung des Materials> für die Durchführung der Analytik zum Auftrag <Auftragsnummer des Einsenders> fehlt! Zustand 3: Weitere Status-Nachrichten können zwischen den Kommunikationspartnern vereinbart werden. Dabei ist zu beachten, dass der Inhalt des header-feldes " Subject" durch die Partner definiert wird und keine datenschutzrelevanten Inhalte bekommt. Die Status-Nachricht besteht aus einem kurzen, informativen Texteil für den menschlichen Empfänger. Seite 26
3.6.1 Status-Nachricht für Zustand 1 (Material ist vollständig im Labor angekommen): Content-Type: text/plain Content-Transfer-Encoding: 8bit Dies ist die Status-Nachricht. Das Material für die Durchführung der Analytik zum Auftrag <Auftragsnummer des Einsenders> ist vollständig im Labor angekommen. Abbildung 10: Nachrichteninhalt der Status-Nachricht für Zustand 1 3.6.2 Status-Nachricht für Zustand 2 (Material fehlt): Content-Type: text/plain Content-Transfer-Encoding: 8bit Dies ist die Status-Nachricht. Das Material <Bezeichnung des Materials> für die Durchführung der Analytik zum Auftrag <Auftragsnummer des Einsenders> fehlt! Abbildung 11: Nachrichteninhalt der Status-Nachricht für Zustand 2 3.6.3 Status-Nachricht für Zustand 3 (Frei - Vereinbarung zwischen Kommunikationspartnern notwendig): Content-Type: text/plain Content-Transfer-Encoding: 8bit Dies ist die Status-Nachricht.... (Text durch Kommunikationspartner zu vereinbaren)... Abbildung 12: Nachrichteninhalt der Status-Nachricht für Zustand 4 Dieser gesamte Inhalt ist die Basis der nun folgenden Signatur. Die weiteren Darstellungen werden am Beispiel der Status-Nachricht für Zustand 1 dokumentiert. Die Status-Nachrichten der anderen Zustände werden in gleicher Weise erzeugt, der Unterschied bezieht sich ausschließlich auf die unterschiedlichen Inhalte der Statusinformationen. Seite 27
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.6.4 Die Struktur des signierten S/MIME-Nachrichteninhalts (Status-Nachricht) 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 28
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="------------ms060409080900050402020608" --------------ms060409080900050402020608 Content-Type: text/plain Content-Transfer-Encoding: 8bit Dies ist die Status-Nachricht. Das Material für die Durchführung der Analytik zum Auftrag <Auftragsnummer des Einsenders> ist vollständig im Labor angekommen. ----------------ms060409080900050402020608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUaDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK...... r2ocvnee/5rrlh8kekgzvievjsm8gylganobkwea8ehbfz+1g43gdd+al/+o6qyle+t1bj61 o+lfa5ywxehxt81fmlq6aaaaaaaa ----------------ms060409080900050402020608-- Abbildung 13: S/MIME-Datei Für die Signatur ist bei KV-Connect der Hash-Algorithmus SHA-256 vorgeschrieben. 3.6.5 Die Struktur der verschlüsselten S/MIME-Nachricht (Status-Nachricht) Die bis zu diesem Schritt erzeugte 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 mit und zum Suchen von Zertifikaten von möglichen Empfängern. Eine KV-Connect-Nachricht muss immer mindestens für den Empfänger verschlüsselt sein. Durch die Verschlüsselung entsteht ein S/MIME-File mit relativ einfacher Struktur: Seite 29
Content-Type: application/pkcs7-mime; name="smime.p7m"; smime-type=enveloped-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message MIAGCSqGSIb3DQEHA6CAMIACAQAxggGRMIIBjQIBADB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMT F0ZyYXVuaG9mZXIgVXNlciBDQSAyMDA3AgogQ/EjAAAAAMrfMA0GCSqGSIb3DQEBAQUABIIBAEQe...... 2RBeZ+IywlnycspKdFIR+aasbMbTNEB9nz3XnVMGHxhtXjc6uVR2pH35IdydWCOVNIK9459XhWYm nfiyrgksy8kidd6itlufkipnzzq7uokgo7rklbu6rxlaryphvbbhtbdkclh2um7841hzj+6ddzss g5qjrsx6/qqirqmlhkpsaaiaaaaaaaaaaaaa Abbildung 14: 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. 3.6.6 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: ". Das Element "Subject" muss, entsprechend der Vorgaben (siehe Tabelle 4) befüllt werden, um zu verhindern, dass im Betreff datenschutzrelevante Informationen übermittelt werden. Im Header muss das Feld " X-KVC-Dienstkennung: " gesetzt und entsprechend der Vorgabe [LDTEM505] gefüllt werden. Im Header muss das Feld " X-KVC-Sendersystem: " gesetzt und mit dem Namen des sendenden Softwaresystems und seiner Version nach der Syntax "<Sotwaresystem>; <Version>" gefüllt werden. Die " Message-ID: " muss gemäß Spezifikation in RFC 5322 vom Anwendungssystem erzeugt und im Header der Nachricht eingetragen werden. Zur Beachtung Die Headereinträge werden um das Headerfeld " In-Reply-To: " (siehe RFC 5322) erweitert. Das Feld verweist auf auf die Message-ID der "LDT-Auftrag;Lieferung;V1.0" Nachricht, die den Laborauftrag ausgelöst hat und muss wie folgt befüllt werden: "In-Reply- To: <messageid der zu bestätigenden Nachricht (Original-Message-ID)>". Ab hier werden die Zustände der Status-Nachrichten wieder getrennt betrachtet. Zustand 1: Seite 30
Date: Tue, 14 Oct 2016 10:48:55 From: LaborXY.kvno@kv-safenet.de MIME-Version: 1.0 To: ArztABC@kv-safenet.de Message-ID: <201623114244676.803@kv-safenet.de> Subject: LDT-Laborauftrag-Status-Material-vollstaendig Return-Path: LaborXY.kvno@kv-safenet.de In-Reply-To: <201614114544676.803@kv-safenet.de> Content-Type: application/pkcs7-mime; name="smime.p7m"; smime-type=enveloped-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message X-KVC-Dienstkennung: LDT-Auftrag;Status;V1.0 X-KVC-Sendersystem: Beispiel-LIS;V1.2 MIME-Version: 1.0 MIAGCSqGSIb3DQEHA6CAMIACAQAxggGRMIIBjQIBADB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMT F0ZyYXVuaG9mZXIgVXNlciBDQSAyMDA3AgogQ/EjAAAAAMrfMA0GCSqGSIb3DQEBAQUABIIBAEQe...... 2RBeZ+IywlnycspKdFIR+aasbMbTNEB9nz3XnVMGHxhtXjc6uVR2pH35IdydWCOVNIK9459XhWYm nfiyrgksy8kidd6itlufkipnzzq7uokgo7rklbu6rxlaryphvbbhtbdkclh2um7841hzj+6ddzss g5qjrsx6/qqirqmlhkpsaaiaaaaaaaaaaaaa Abbildung 15: verschlüsselte, signierte Status-Nachricht (Zustand 1) mit Mail-Header Header für Zustand 2: Seite 31
Date: Tue, 14 Oct 2016 10:48:55 From: LaborXY.kvno@kv-safenet.de MIME-Version: 1.0 To: ArztABC@kv-safenet.de Message-ID: <201623114244676.803@kv-safenet.de> Subject: LDT-Laborauftrag-Status-Material-fehlt Return-Path: LaborXY.kvno@kv-safenet.de In-Reply-To: <201614114244676.803@kv-safenet.de> Content-Type: application/pkcs7-mime; name="smime.p7m"; smime-type=enveloped-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message X-KVC-Dienstkennung: LDT-Auftrag;Status;V1.0 X-KVC-Sendersystem: Beispiel-LIS;V1.2 MIME-Version: 1.0 MIAGCSqGSIb3DQEHA6CAMIACAQAxggGRMIIBjQIBADB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMT F0ZyYXVuaG9mZXIgVXNlciBDQSAyMDA3AgogQ/EjAAAAAMrfMA0GCSqGSIb3DQEBAQUABIIBAEQe...... 2RBeZ+IywlnycspKdFIR+aasbMbTNEB9nz3XnVMGHxhtXjc6uVR2pH35IdydWCOVNIK9459XhWYm nfiyrgksy8kidd6itlufkipnzzq7uokgo7rklbu6rxlaryphvbbhtbdkclh2um7841hzj+6ddzss g5qjrsx6/qqirqmlhkpsaaiaaaaaaaaaaaaa Abbildung 16: verschlüsselte, signierte Status-Nachricht (Zustand 2) mit Mail-Header Header für Zustand 3: Seite 32