Spezifikation LDT 3.0 (Befund) Spezifikation KV-Connect Anwendungsdienst LDT 3.0 (Befund) mit KV-Connect

Transkript

1 Spezifikation LDT 3.0 (Befund) Spezifikation KV-Connect Anwendungsdienst LDT 3.0 (Befund) mit KV-Connect Herausgeber: KV Telematik GmbH Dieses Dokument der KV Telematik GmbH wird unter der Lizenz CC-BY-SA 3.0 veröffentlicht. (

2

3 Inhaltsverzeichnis 1 Vorbemerkungen Zweck des Dokumentes Inhalt Referenzen Ziel Ausgangssituation Mehrwerte durch den Einsatz elektronischer Laborkommunikation mit KV-Connect Beseitigung bekannter Probleme Zusatznutzen Allgemeine Voraussetzungen Bezug zu anderen Spezifikationen und Dokumenten Vorgehensweise/Zeitplan Geltungsbereich Bezug zur Zertifizierung der KBV 9 2 Prozess-Beschreibung Geschäftsvorfälle (Use Cases) Gesamtablauf aus Sicht der Teilnehmer Ablauf Laborbefund Ablauf Laborbefund (Option Befundabruf durch beide Kommunikationspartner umgesetzt) Ablauf Laborbefund (Option Befundabruf durch Labor nicht unterstützt) Erstellung des Befundes 20 3 Beschreibung der KV-Connect Nachrichten Nachrichtenformate Inhalt der Nachrichten Nachrichten zu Laborbefunden Aufbau der KV-Connect Nachrichten Verwendete Segment- und X-Attribute Struktur der Nachricht "Laborbefund" Die Struktur der Nachricht "Laborbefund" Die Nachrichten-Struktur Die Struktur des signierten S/MIME-Nachrichteninhalts Die Struktur der verschlüsselten S/MIME-Nachricht Struktur der -Nachricht Implementierungsbemerkung Struktur der Nachricht "MDN" Die Struktur der Nachricht MDN Die Struktur des signierten S/MIME-Nachrichteninhalts (MDN) 35

4 3.5.3 Die Struktur der verschlüsselten S/MIME-Nachricht (MDN) Struktur der -Nachricht (MDN) Struktur der Nachricht "Trigger" (Befundabruf) Die Struktur der Nachricht Trigger (Befundabruf) Die Struktur des signierten S/MIME-Nachrichteninhalts (Trigger) Die Struktur der verschlüsselten S/MIME-Nachricht (Trigger) Struktur der -Nachricht (Trigger) Struktur der Nachricht "Status" Die Struktur der Nachricht Status Die Struktur des signierten S/MIME-Nachrichteninhalts (Status-Nachricht) Die Struktur der verschlüsselten S/MIME-Nachricht (Status-Nachricht) Struktur der -Nachricht (Status-Nachricht) 45 4 Spezifikation der Datenübermittlung Vorbedingungen Festlegung des Empfängers Der Nachrichten-Header Die Header der fachlichen Nachrichten Die Header der automatischen Quittungen Fachliche Inhalte Metainformationen KV-Connect Nachricht 51 5 Anforderungen an die Software-Systeme Anforderungen an die Systeme zum Empfang von Befunden Anforderungen an die Labor-Software 53

5 Änderungshistorie Vers. Datum Autor Kap. Änderung Status B. Bresser/V. Dentel 1-5 Änderungen aus Kommentierung eingearbeitet, veröffentlicht Optionale Funktion "Befundabruf" beschrieben Hier können Sie die Spezifikation als PDF downloaden. Herausgeber: KV Telematik GmbH Diese Spezifikation wird unter CC-BY-SA 3.0 veröffentlicht. (, Vollständiger Lizenztext Allgemein verständliche Erklärung) Seite 5

6 1 Vorbemerkungen 1.1 Zweck des Dokumentes Spezifikation KV-Connect Anwendungsdienst LDT 3.0 (Befund) mit KV-Connect Dieses Dokument dient der Spezifikation des KV-Connect Anwendungsdienstes LDT 3.0 (Befund) mit KV-Connect. Basis dieser Spezifikation ist die aktuell gültige Spezifikation des LDT (LaborDatenTräger) in der Version 3.0. Der LDT 3.0 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.0 gemeint. Sollte eine andere Version gemeint sein, so ist dies an den entsprechenden Stellen explizit ausgewiesen. Der LDT in der Version 3.0 wendet sich im Gegensatz zu den vorhergehenden Versionen nicht mehr explizit an die Kassenärztliche Gemeinschaft. Das Anwendungsfeld des LDT wurde auf zahlreiche andere Gebiete der Laborkommunikation erweitert. Die Spezifikation LDT 3.0 (Befund) mit KV-Connect umfasst unter Umständen nicht den gesamten Umfang der Use-Cases des LDT 3.0 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 Inhalt Kapitel 2 gibt einen Überblick über den Gesamtprozess der abzubildenden Anwendung einschließlich der per KV-Connect auszutauschenden Daten. Kapitel 3 beschreibt in unterschiedlicher Detaillierungstiefe die auszutauschenden Daten. Sofern diese in anderen Spezifikationen definiert sind, wird z.t. lediglich auf diese externen Spezifikationen verwiesen. Bei anwendungsspezifischen Dokumenten werden diese hier detailliert spezifiziert. Kapitel 4 beschreibt den Aufbau der KV-Connect-Nachrichten zur Übertragung der vorher beschriebenen Daten. Kapitel 5 beschreibt die Anforderungen an die Software-Systeme Referenzen 1.2 Ziel [LDT 3.0]: Datensatzbeschreibung LDT [KVCA_Dienste_Adressen]: Stammdatei KVCA-Dienste-Adressen (ftp://ftp.kbv.de/ita-update /Stammdateien/SDKVCA/) [PP KVC]: Dokumentation zu KV-Connect im KV-Connect Partnerportal ( ) [KVC-Anb]: Anbindung an KV-Connect (in: ftp://ftp.kbv.de/ita-update/stammdateien/sdkvca/kv- Connect.zip) Mit KV-Connect und dem SNK (Sicheres Netz der KVen) ist in Deutschland eine flächendeckende Infrastruktur zur sicheren Kommunikation medizinischer Daten verfügbar. Die Labordatenfernübertragung wird seit vielen Jahren in den niedergelassenen Praxen eingesetzt und gehört quasi zum Standardumfang eines Praxiscomputer-, Labor- oder Krankenhausinformationssystems. Ca. 70% aller Praxen und sonstigen medizinischen Einrichtungen in Deutschland verwenden den LDT-Datensatz in seiner alten Form. Der LDT, der von der KBV in den 90er Seite Jahren 6 entwickelt worden ist, beschreibt das Datenformat, auf dessen Basis die Labor-Daten codiert

7 Jahren entwickelt worden ist, beschreibt das Datenformat, auf dessen Basis die Labor-Daten codiert werden. Seit dieser Zeit haben sich viele der Voraussetzungen im Gesundheitswesen, aber auch in anderen Bereichen, die mit Labordaten arbeiten, geändert, so dass eine Überarbeitung des LDT geboten erschien. Aus dieser Notwendigkeit heraus ist der LDT 3.0 entstanden. Durch die Nutzung von KV-Connect wird die Datensicherheit auf dem Übertragungsweg auf einen qualitativ und datenschutztechnisch hohen Standard gehoben. 1.3 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 39, oder ein Auftrag an die Laborgemeinschaft (LG) mittels Formular Muster 10A oder ein Auftrag an andere Labore, erstellt. Auftrag und Probe werden an das beauftragte Labor übermittelt. (Die Auftragsübermittlung ist nicht Bestandteil dieser Spezifikation!) Befundübermittlung: Nach Abschluss der Untersuchungen im Labor (Laborfacharzt oder LG) werden die Ergebnisse dem Auftraggeber im LDT-Format zur Verfügung gestellt. Derzeit bieten (praktisch) alle Labore im humanmedizinischen Umfeld ihren Kunden Modelle der elektronischen Datenübertragung an. Insbesondere der Weg der Befundergebnisse vom Labor zum Auftraggeber ist im hohen Maß auf elektronische Verfahren portiert worden. Eine nicht unwesentliche Herausforderung besteht derzeit in der außerordentlich heterogenen kommunikationstechnischen Anbindung der Auftraggeber an die Labore. Hier werden durchaus noch akustische Modems eingesetzt. 1.4 Mehrwerte durch den Einsatz elektronischer Laborkommunikation mit KV- Connect Beseitigung bekannter Probleme KV-Connect als Transportmechanismus für Labordaten hilft, eine Reihe bekannter Probleme im Laborumfeld zu minimieren bzw. zu beseitigen: Datenschutz: Im Rahmen der Labordatenfernübertragung haben sich eine Vielzahl von z.t. auch datenschutzrechtlich bedenklichen Übertragungsmechanismen etabliert. Zur Harmonisierung des Übertragungsweges und zur besseren Einhaltung datenschutzrechtlicher Vorgaben kann KV- Connect eine Lösung anbieten. Insbesondere deshalb, weil KV-Connect ausschließlich mit der für die erforderliche Vertraulichkeit geeigneten Verschlüsselung kommuniziert. Supportentlastung: Das Aufsetzen des Transportmechanismus auf eine bestehende Infrastruktur kann den Supportaufwand bzgl. DFÜ (Datenfernübertragung) - vor allem 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. Mailbox/Hardware: Veraltete Mailbox-Verfahren können abgelöst werden. Hardware (Server, TK- Anlagen, Modems) kann in den Laboreinrichtungen abgebaut werden. Durch den Umbau der Infrastruktur der Telekommunikationsprovider (IP-basierte Telefonie, Abbau der klassischen Leitungen) erhöht sich der Druck zur Umstellung. Seite 7

8 1.4.2 Zusatznutzen Neben dem Versand von standardisierten Empfangsquittungen bietet KV-Connect ergänzend zu der Übertragung von LDT-Daten die Möglichkeit weitere Dokumente z.b. im Layout des jeweiligen Labors als (optional qualifiziert signierte) PDF-Datei zu übermitteln: optionaler Quittungsbetrieb: KV-Connect ermöglicht mit seinen Standardfunktionen den Versand /das Abholen von Empfangsquittungen also einen Quittungsbetrieb im Falle einer erfolgreichen Übermittlung einer KV-Connect-Nachricht vom Labor an die Arztpraxis und/oder von der Arztpraxis zum Labor. Der besondere Fokus liegt beim Quittungsbetrieb auf der Empfangsbestätigung von Laborbefunden. Damit erzielen vor allem Laboreinrichtungen einen Vorteil im Support und eine Stärkung ihres Unternehmensprofils. Realisieren und Anwenden dieser Funktion obliegt der bilateralen Absprache zwischen den jeweiligen Kommunikationspartnern. optionale Übermittlung von schriftlichen Befunden: Die Arztpraxis möchte dem Patienten einen Laborbericht mit originalem Briefkopf des Labors (Corporate Identity!) überreichen. Neben dem Versand von LDT-Dateien als maschinenlesbarer Befund ermöglicht KV-Connect optional die Übermittlung des Befundes als PDF-Datei. Realisieren und Anwenden dieser Funktion obliegt der bilateralen Absprache zwischen den jeweiligen Kommunikationspartnern. 1.5 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 die KBV- Zertifizierung für "LDT 3.0 (Befund)" 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. 1.6 Bezug zu anderen Spezifikationen und Dokumenten Die Konvention zur Erzeugung einer LDT-Datei nach den Vorgaben der KBV und des QMS bleibt unberührt. Für die Erzeugung der LDT-Datei gelten die anwendbaren Vorgaben der KBV und des QMS. 1.7 Vorgehensweise/Zeitplan Im Lauf des Jahres 2015 wird von den für die Spezifikation des LDT 3.0 zuständigen Stellen (KBV für den Bereich GKV-abrechenbare Leistungen, QMS e.v. für alle anderen Einsatzgebiete (IGeL, PKV, )) die finale Version der Spezifikation LDT 3.0 veröffentlicht. Die KBV hat festgelegt, dass die Zulassung des für die Abrechenbarkeit von Laborleistungen für den GKV-Bereich vorgeschriebenen LDT 2.x zum erlischt. Für die Übertragung der GKV-LDT 3.0-Befunde wird aus Sicherheitsgründen die Übertragung über KV-Connect empfohlen. In der vorliegenden Spezifikation wird ausschließlich der Weg der Befundübertragung spezifiziert. Achtung: In der vorliegenden Spezifikation wird ausschließlich der Weg der Befundübertragung spezifiziert. Seite 8

9 1.8 Geltungsbereich Die vorliegende Spezifikation gilt für alle IT-Systeme im Gesundheitswesen, die die elektronische Kommunikation von Labordaten im Bereich der kassenärztlichen Versorgung unterstützen. Sie beschreibt den Prozess von der Aufbereitung der vorher erzeugten Befunddokumente über den Nachrichtenaufbau, den Versand sowie den Empfang und den Inhalt von Quittungsdateien und optionaler Befundabruf-Nachrichten. 1.9 Bezug zur Zertifizierung der KBV Die Implementierung der KV-Connect-Anwendung "LDT 3.0 (Befund)" durch die Softwarehäuser wird im Rahmen der LDT 3.0 (Befund) - Zertifizierung der KBV überprüft. Zertifizierungs-Kriterien, die sich auf die vorliegende Spezifikation beziehen, werden in den nachstehenden Kapiteln explizit als Zertifizierungs- Kriterien hervorgehoben. Wie z.b. [LDTSM030]: Jede Sendung MUSS mindestens eine LDT-Datei enthalten. Das Beispiel hat an dieser Stelle keinen Bezug zur Fachlichkeit der Spezifikation. Seite 9

10 2 Prozess-Beschreibung Spezifikation KV-Connect Anwendungsdienst LDT 3.0 (Befund) mit KV-Connect Die Datensatzbeschreibung des LDT 3.0 des QMS e.v. und der KBV dient hier als Referenz, da sie neue Möglichkeiten der Beschreibung von Aufträgen und Befunden enthält, die in der alten Spezifikation (des LDT 2.0) nicht oder nur schwer möglich waren. Hier steht die Datensatzbeschreibung zum Download bereit. KV-Connect ist ein Kommunikationsdienst, der in geeigneter Weise Daten dokumenten- bzw. dateibasiert versendet oder empfängt. Der LDT ist ein Datenformat, das es erlaubt, fachliche Inhalte in geeigneter Weise zu strukturieren und für eine Weiterverarbeitung geeignet zusammenzufassen und abzulegen. Diese Spezifikation beschreibt die technische Realisierung einiger wesentlicher Use-Cases im humanmedizinischen Umfeld, bei der Labordaten, die nach den Regeln des LDT 3.0 erzeugt worden sind, mittels KV-Connect sicher und datenschutzkonform an ihren Bestimmungsort zu transportieren sind. Die Spezifikation beschreibt naturgemäß nur einen Teil aller möglichen Szenarien. Sollte die Erfordernis bestehen, so kann sie problemlos im Rahmen der Möglichkeiten von KV-Connect und der aktuellen Version des LDT erweitert werden. 2.1 Geschäftsvorfälle (Use Cases) Die Spezifikation der Labor-Befundübertragung beschreibt in der im LDT 3.0 definierten Begrifflichkeit derzeit zwei Geschäftsvorfälle, die sich für das Kommunikationssystem unterscheiden lassen. Sie ergeben sich aus den spezifischen Anforderungen, wobei Anforderungen der kassenärztlichen Vertragssysteme, darüber hinausgehender humanmedizinischer Anwendungen, aber auch allgemeiner Anwendungen oder parallel existierenden weiteren Geschäftsbeziehungen zwischen möglichen Auftraggebern und den Laboren berücksichtigt werden können. Der Gesamtvorgang beschreibt den zurücklaufenden Informationsvorgang (Labor-Befundübermittlung), der durch einen vorher durchgeführten Informationsvorgang (Labor-Auftrag) initiiert worden ist. Der Auftragsweg wird hier nicht definiert. (Er muss jedoch stattgefunden haben und es wird vorausgesetzt, dass die Laborinformations- bzw. Kommunikationssysteme alle für die Befundübertragung erforderlichen Informationen intern vorliegen haben.) Labor Nachricht: LDT-Befund Satzart 8205 Einsender Die Geschäftsvorfälle teilen sich bei Benutzung eines serverbasierten Kommunikationssystems, wie es KV-Connect ist, technisch in zwei Teilvorgänge auf. Dabei ist ein wesentlicher Unterschied zu den derzeit praktizierten Verfahren fest zu halten: Die Übertragung erfolgt nicht Peer-to-Peer sondern Peerto-Server-to-Peer. Das heißt, es erfolgt ein Messaging über einen Zwischenserver. Diese neue Infrastruktur bedingt Änderungen am bisherigen System Seite 10 Versand einer Laborbefund-Nachricht an den KV-Connect-Server Das Labor erzeugt eine LDT-Datei (genaueres siehe unten), erzeugt daraus eine KV-Connect- Nachricht an den Auftraggeber und verschickt sie an den KV-Connect-Server. Als zweiten Schritt, insgesamt aber periodisch, fragt das System den KV-Connect-Server nach Quittungen zu den versandten Nachrichten ab und ergreift, je nach Status der Quittungen oder danach, ob überhaupt Quittungen empfangen werden, geeignete Maßnahmen. Abholen einer Laborbefund-Nachricht vom KV-Connect-Server Das System der anfordernden Stelle (das kann ein niedergelassener Arzt, ein Krankenhaus, aber auch ein beauftragendes Labor sein) fragt den KV-Connect-Server nach vorliegenden Nachrichten mit der zutreffenden X-KVC-Dienstkennung (s.u.) ab und holt diese gegebenenfalls ab. Nach erfolgreichem Abholen kann eine Quittung (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 verarbeitet. Optional: Initiieren des Befundversandes durch den Empfänger Das System der anfordernden Stelle (das kann ein niedergelassener Arzt, ein Krankenhaus, aber auch ein beauftragendes Labor sein) sendet über den KV-Connect-Server eine Nachricht "Trigger" an das Labor, die den Befundversand im Labor initiiert. Das Labor reagiert auf diese Nachricht immer mit einer Status-Nachricht. Mit dieser Status-Nachricht informiert das Labor über den aktuellen Status in Bezug auf den Versand einer Befund-Nachricht (Befundversand erfolgt umgehend, aktuell keine Befunde vorhanden, Funktion wird nicht unterstützt).

11 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 Befundübertragung beschrieben. 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 Die Voraussetzung für einen Laborbefund ist der Laborauftrag. Der Laborauftrag wird hier nicht behandelt. Als Basis für den nächsten Schritt sind allerdings eine Reihe von Vorbedingungen zu beachten. Es wird im Folgenden davon ausgegangen, dass der Laborauftrag in einer Form im Laborsystem vorliegt, dass die Aufgaben des Labors zur Bearbeitung, Beurteilung und zur Datenübertragung durchgeführt werden können. Die ordnungsgemäße Durchführung der Anforderung und die Aufnahme in das Laborsystem (im Allgemeinen auf klassische Art, Papier und Röhrchen) wird als realisiert vorausgesetzt. Laborbefund Der elektronische Versand der Ergebnisse eines Laborauftrags, im Folgenden als Befund bezeichnet, stellt heute und in absehbarer Zeit den Löwenanteil der elektronischen Laborkommunikation dar. Dabei wird bei der Transportdefinition zwischen den einzelnen Befundarten nicht differenziert. Die in den LDT- Dateien (auch im LDT 3.0) vorgesehenen Befundarten bleiben davon unbeeinflusst. Seite 11

12 Spezifikation KV-Connect Anwendungsdienst LDT 3.0 (Befund) mit KV-Connect Ablauf Laborbefund Abbildung 1: Relevanter Workflow Laborbefund Seite 12

13 LDT-Laborbefund 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, eine Laboranforderung generiert wurde) muss in einer für den internen Fachprozess angemessenenen Rate nachfragen, ob ein Befund vorliegt (PS05 und PS11). Das System, das die Befunde liefert (also im Allgemeinen das Laborsystem) muss eine Auftragserfassung und -verarbeitung enthalten, die die Stammdaten des Laborauftrags vorhält und aus dem Auftrag die fachlichen Arbeitsschritte registriert, die zur Abarbeitung des Auftrags erforderlich sind. Diese Arbeitsschritte müssen in der fachlich erforderlichen Weise parallel zueinander oder nacheinander durchgeführt werden, solange bis der Auftrag abgeschlossen ist (L10, L17 mit D01). Schritt 1 Das Labor/der Auftragnehmer einer Laborleistung generiert mit Hilfe des Laborsystems (LIS, ) einen Laborbefund als LDT-Datei. Aus den Daten der LDT- Datei geht die Befundart hervor. Parallel zur LDT-Datei kann eine menschenlesbare PDF-Datei mit den semantisch gleichen Inhalten wie die des LDT erzeugt werden. Diese kann/sollte qualifiziert signiert werden (L11, es entsteht D06). Schritt 2 Die LDT-Datei wird vom LDT-Prüfmodul geprüft und muss den Gesamt-Prüfstatus OK haben (L12 mit D06). Die LDT-Datei wird nicht verschlüsselt. Schritt 3 Adressaten / KV-Connect-Teilnehmer auswählen. Falls die Auftragsdaten elektronisch zu diesem Befund vorliegen, so muss der Adressat diesem Auftraggeber automatisch zugeordnet werden können. Schritt 4 Die LDT-Datei (und (optionale) PDF-Datei) sind als Anhang/Teil einer multipartmixed -MIME-Struktur. Diese wird zuerst signiert, dann verschlüsselt (L13, es entsteht D07) und als S/MIME enveloped-data an den betreffenden Adressaten gesendet (L14). Schritt 5 Der Empfänger des Befunds generiert mit Hilfe seines Systems (im Allgemeinen des jeweiligen Primärsystems) eine oder periodische Anfragen (PS06), ob Nachrichten mit dem entsprechenden header-feld aus Tabelle 5 vorliegen. Falls ja holt er sie vom Server (PS08 mit D07). Schritt 6 Die abgeholte Nachricht wird entschlüsselt und ihre Signatur wird geprüft (PS09). Schritt 7 Der Einsender generiert mit Hilfe seines Systems (im Allgemeinen des Primärsystems) eine MDN mit der Referenz auf die abgeholte Nachricht. (PS09, Ergebnis D09) Schritt 8 Das Labor prüft fortlaufend auf MDNs zu versandten Nachrichten (L15, L16) und steuert so die interne Auftragsverwaltung/-buchführung (L17). Tabelle 1 Seite 13

14 Spezifikation KV-Connect Anwendungsdienst LDT 3.0 (Befund) mit KV-Connect Ablauf Laborbefund (Option Befundabruf durch beide Kommunikationspartner umgesetzt) Mit der Funktion "Befundabruf", welche optional umgesetzt werden kann, wird es dem Einsender ermöglicht, aktiv beim Labor Befunde abzurufen. Damit wird der Einsender des Laborauftrage s in die Lage versetzt, individuell nach seinen Wünschen alle für ihn im Labor bereitgestellten Befunde abzufordern. Das Labor versendet alle zum Zeitpunkt des Eingangs der Befundabruf-Nachricht für den Versender vorliegenden Befunde an diesen (der Validierungsgrad und die Befundart der zu versendenden Befunde ist nicht Teil dieser Spezifikation, sondern liegt in der Verantwortung des jeweiligen Labors). Im folgenden Kapitel ist der Ablauf beschrieben, wenn beide Kommunikationspartner die Funktion "Befundabruf" umgesetzt haben. Abbildung 2: Relevanter Workflow Laborbefund (Option Befundabruf durch beide Kommunikationspartner umgesetzt) Seite 14

15 Seite 15

16 LDT-Befundabruf versenden und Befund versenden ( Option Befundabruf durch beide Kommunikationspartner umgesetzt ) 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, eine Laboranforderung generiert wurde) muss in einer für den internen Fachprozess angemessenenen Rate nachfragen, ob ein Befund vorliegt (PS05 und PS11). Das System, das die Befunde liefert (also im Allgemeinen das Laborsystem) muss eine Auftragserfassung und -verarbeitung enthalten, die die Stammdaten des Laborauftrags vorhält und aus dem Auftrag die fachlichen Arbeitsschritte registriert, die zur Abarbeitung des Auftrags erforderlich sind. Diese Arbeitsschritte müssen in der fachlich erforderlichen Weise parallel zueinander oder nacheinander durchgeführt werden, solange bis der Auftrag abgeschlossen ist (L10, L17 mit D01). Schritt 1 Das Labor/der Auftragnehmer einer Laborleistung generiert mit Hilfe des Praxisverwaltungs- oder Laborsystems (PVS, LIS, ) einen LDT-Laborbefund als LDT-Datei. Aus den Daten der LDT-Datei geht die Befundart hervor. Parallel zur LDT-Datei kann eine menschenlesbare PDF-Datei mit den semantisch gleichen Inhalten wie die des LDT erzeugt werden. Diese kann/sollte qualifiziert signiert werden. (L11, es entsteht D06) Option Schritt 1 Das empfangende System (also das System, von dessen Seite, egal auf welchem Weg, eine Laboranforderung generiert wurde), erlaubt es seinem Nutzer eine Trigger-Nachricht (Befundabruf) an das Labor zu generieren (PS12, D10) und zu versenden (PS13). Option Schritt 2 Das Labor prüft fortlaufend auf das Vorhandensein von Trigger-Nachrichten (Befundabruf) auf dem Server (L18) Option Schritt 3 Liegt eine Trigger-Nachricht (Befundabruf) auf dem Server vor, holt das System diese ab (L19), entschlüsselt diese und prüft die Signatur. Die Nachricht wird vom LIS übernommen. Es erfolgt im LIS eine Prüfung, ob aktuell für den Versender der Trigger-Nachricht (Befundabruf) Befunde vorliegen. Option Schritt 4 Liegen Befunde für den Versender der Trigger-Nachricht (Befundabruf) vor, wird eine Status-Nachricht mit dem Subject "LDT-Laborbefund-Status-Sendung-in- Arbeit" erstellt (L20, L21) und an den Server versendet (D11). Weiter Schritt 2ff. Option Schritt 5 Liegen keine Befunde für den Versender der Befundabruf-Nachricht vor, wird eine Status-Nachricht mit dem Subject "LDT-Laborbefund-Status-keine-Sendungvorhanden" erstellt (L22, L23) und an den Server versendet (D12). Weiter Option Schritt 2ff. Schritt 2 Die LDT-Datei wird vom LDT-Prüfmodul geprüft und muss den Gesamt-Prüfstatus OK haben (L12 mit D06). Die LDT-Datei wird nicht verschlüsselt. Schritt 3 Adressaten / KV-Connect-Teilnehmer auswählen. Falls die Auftragsdaten elektronisch zu diesem Befund vorliegen, so muss der Adressat diesem Auftraggeber automatisch zugeordnet werden können. Schritt 4 Seite 16

17 Die LDT-Datei (und (optionale) PDF-Datei) sind als Anhang/Teil einer multipartmixed -MIME-Struktur. Diese wird zuerst signiert, dann verschlüsselt (L13, es entsteht D07) und als S/MIME enveloped-data an den betreffenden Adressaten gesendet (L14). Schritt 5 Der Empfänger des Befunds generiert mit Hilfe seines Systems (im Allgemeinen des jeweiligen Primärsystems) eine oder periodische Anfragen (PS06), ob Nachrichten mit dem entsprechenden header-feld aus Tabelle 5 vorliegen. Falls ja holt er sie vom Server (PS08 mit D07). Schritt 6 Die abgeholte Nachricht wird entschlüsselt und ihre Signatur wird geprüft (PS09). Schritt 7 Der Einsender generiert mit Hilfe seines Systems (im Allgemeinen des Primärsystems) eine MDN mit der Referenz auf die abgeholte Nachricht. (PS09, Ergebnis D09) Schritt 8 Das Labor prüft fortlaufend auf MDNs zu versandten Nachrichten (L15, L16) und steuert so die interne Auftragsverwaltung/-buchführung (L17). Tabelle Ablauf Laborbefund (Option Befundabruf durch Labor nicht unterstützt) Mit der Funktion "Befundabruf", welche optional umgesetzt werden kann, wird es dem Einsender ermöglicht, aktiv beim Labor Befunde abzurufen. Seite 17

18 Spezifikation KV-Connect Anwendungsdienst LDT 3.0 (Befund) mit KV-Connect Im folgenden Kapitel ist der Ablauf beschrieben, wenn das Labor die Funktion "Befundabruf" nicht unterstützt. Abbildung 3: Relevanter Workflow Laborbefund ( Option Befundabruf durch Labor nicht unterstützt) Seite 18

19 LDT-Befundabruf versenden und Befund versenden ( Option Befundabruf durch Labor nicht unterstützt ) 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, eine Laboranforderung generiert wurde) muss in einer für den internen Fachprozess angemessenenen Rate nachfragen, ob ein Befund vorliegt (PS05 und PS11). Das System, das die Befunde liefert (also im Allgemeinen das Laborsystem) muss eine Auftragserfassung und -verarbeitung enthalten, die die Stammdaten des Laborauftrags vorhält und aus dem Auftrag die fachlichen Arbeitsschritte registriert, die zur Abarbeitung des Auftrags erforderlich sind. Diese Arbeitsschritte müssen in der fachlich erforderlichen Weise parallel zueinander oder nacheinander durchgeführt werden, solange bis der Auftrag abgeschlossen ist (L10, L17 mit D01). Schritt 1 Das Labor/der Auftragnehmer einer Laborleistung generiert mit Hilfe des Praxisverwaltungs- oder Laborsystems (PVS, LIS, ) einen LDT-Laborbefund als LDT-Datei. Aus den Daten der LDT-Datei geht die Befundart hervor. Parallel zur LDT-Datei kann eine menschenlesbare PDF-Datei mit den semantisch gleichen Inhalten wie die des LDT erzeugt werden. Diese kann/sollte qualifiziert signiert werden. (L11, es entsteht D06) Option Schritt 1 Das empfangende System (also das System, von dessen Seite, egal auf welchem Weg, eine Laboranforderung generiert wurde), erlaubt es seinem Nutzer eine Trigger-Nachricht (Befundabruf) an das Labor zu generieren (PS12, D10) und zu versenden (PS13). Option Schritt 2 Das Labor prüft fortlaufend auf das Vorhandensein von Trigger-Nachrichten (Befundabruf)auf dem Server (L18). Option Schritt 3 Liegt eine Trigger-Nachricht (Befundabruf) auf dem Server vor, holt das System diese ab (L19), entschlüsselt diese und prüft die Signatur. Option Schritt 4 Für den Versender der Trigger-Nachricht (Befundabruf), wird eine Status- Nachricht "LDT-Laborbefund-Status-nicht-unterstuetzt" erstellt (L20, L21) und an den Server versendet (D11). Schritt 2 Die LDT-Datei wird vom LDT-Prüfmodul geprüft und muss den Gesamt-Prüfstatus OK haben (L12 mit D06). Die LDT-Datei wird nicht verschlüsselt. Schritt 3 Adressaten / KV-Connect-Teilnehmer auswählen. Falls die Auftragsdaten elektronisch zu diesem Befund vorliegen, so muss der Adressat diesem Auftraggeber automatisch zugeordnet werden können. Schritt 4 Die LDT-Datei (und (optionale) PDF-Datei) sind als Anhang/Teil einer multipartmixed -MIME-Struktur. Diese wird zuerst signiert, dann verschlüsselt (L13, es entsteht D07) und als S/MIME enveloped-data an den betreffenden Adressaten gesendet (L14). Schritt 5 Der Empfänger des Befunds generiert mit Hilfe seines Systems (im Allgemeinen des jeweiligen Primärsystems) eine oder periodische Anfragen (PS06), ob Nachrichten mit dem entsprechenden header-feld aus Tabelle 5 vorliegen. Falls ja holt er sie vom Server (PS08 mit D07). Seite 19

20 Schritt 6 Die abgeholte Nachricht wird entschlüsselt und ihre Signatur wird geprüft (PS09). Schritt 7 Der Einsender generiert mit Hilfe seines Systems (im Allgemeinen des Primärsystems) eine MDN mit der Referenz auf die abgeholte Nachricht. (PS09, Ergebnis D09) Schritt 8 Das Labor prüft fortlaufend auf MDNs zu versandten Nachrichten (L15, L16) und steuert so die interne Auftragsverwaltung/-buchführung (L17). Tabelle Erstellung des Befundes Erstellung des Befundes im LDT-Format Der Befund wird im Format LDT 3.0 vom Laborsystem erstellt. Diese Funktion ist eine essentielle Komponente jeder Laborsoftware, die im deutschen Gesundheitswesen eingesetzt werden soll. Die Erstellung des Befundes ist nicht Gegenstand dieser Spezifikation und wird als gegeben vorausgesetzt. Die Referenz für die (formale) Richtigkeit des Befundes sind die Spezifikationsteile des LDT 3.0 der zuständigen Prüfstellen, der KBV und des QMS e.v.. Achtung! Eine LDT-Befund-Datei kann einen oder mehrere Befunde (Satzart 8205) enthalten! Erstellung des Befundes im PDF-Format Die Daten des Befundes oder der Befunde sind in der reinen LDT-Datei, die oben angesprochen ist, gespeichert. Die Visualisierung der Daten des LDT-Befundes erfolgt in der Verantwortung des jeweiligen Labors bzw. dessen Softwarekomponente bzw. auf Basis einer Vereinbarung zwischen Befund- Anforderer und Labor. Zur rechtssicheren Kommunikation ist es empfehlenswert, ein inhaltlich mit dem strukturierten LDT-Befund identisches PDF-Dokument zu erzeugen. Der PDF-Befund kann/sollte mit einer qualifizierten elektronischen Signatur versehen werden. Das entstehende PDF-Dokument wird in Form eines Anhangs (siehe LDT-Spezifikation Kap Obj_Anhang Obj_0010 ) in den Befund integriert. Es darf auch als S/MIME-Anhang an die KV-Connect-Nachricht angehängt werden. Achtung! Falls die LDT-Befund-Datei mehrere Befunde (Satzart 8205) enthält, dann müssen die PDF- Dokumente nach der Spezifikation des LDT 3.0 als Anhang in den jeweiligen Befund (Satzart 8205) eingebettet werden. Prüfung des Befundes Vor der Erzeugung der KV-Connect-Nachricht muss der Befund durch das LDT 3.0-Prüfmodul geprüft werden. Die Prüfung ist zwingend durchzuführen für das Basismodul und das KBV-Modul bei Inhalten, die die GKV-Versorgung betreffen. Bei Inhalten, die nicht die GKV-Versorgung betreffen wird aus Gründen der Qualitätssicherung empfohlen, das QMS-Modul einzusetzen. Abhängig vom Inhalt der Befunddatei sind drei Prüfstrategien zu beachten: 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 Seite 20

21 Tabelle 4 Die Weiterverarbeitung der Daten ist nur erlaubt, wenn die Gesamtprüfung durch das LDT-Prüfmodul fehlerfrei abgeschlossen wird.[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 (z.b. Befund zum Auftrag ist fertig ) realisiert werden. Seite 21

22 3 Beschreibung der KV-Connect Nachrichten In Kapitel 3 werden die Details des Ablaufs und der Daten- und Dokumentenerzeugung (Laborbefunde) zwischen Einsender und Labor beschrieben. Andere Transfers, wie z.b. die Übertragung der Abrechnungsdaten zwischen einem der Beteiligten und den KVen, werden in dieser Spezifikation nicht betrachtet. 3.1 Nachrichtenformate Sowohl die Nachrichten vom Einsender an das Labor als auch die Nachrichten vom Labor an den Einsender sind verschlüsselte S/MIME-Nachrichten. Im Inneren der Container befindet sich bei der Nachricht "Lieferung" eine Datei im Format LDT 3.0, Textkomponenten (der Nachrichten- oder Mail- Body) sowie optional eine PDF-Datei. Die PDF-Datei kann eine qualifizierte Signatur enthalten. Die MDNs (Eingangsbestätigung), Trigger- und Status-Nachrichten (Funktion "Befundabruf") sind üblicherweise reine Textnachrichten. 3.2 Inhalt der Nachrichten Die Komponenten der Nachrichten (außer den MDNs) sind im vorherigen Kapitel beschrieben. Die MDNs sind im Normalfall (so auch in dieser Spezifikation spezifiziert) einfache Textnachrichten, die in Form von Attributen Informationen übermitteln. Sie werden weiter unten genauer beschrieben. Die Trigger- und Status-Nachrichten sind einfache Textnachrichten, die im Subject entsprechende Informationen übermitteln. Sie werden weiter unten genauer beschrieben Nachrichten zu Laborbefunden Der Befund Der Befund, also das Ergebnis der Labor-Analytik, besteht aus zwei, maximal drei Komponenten. Die erste Komponente ist ein Textanteil, der Anteil des Mail-Body. Die zweite Komponente ist eine LDT-Datei, die die Ergebnisse der Laborarbeit in strukturierter, maschinenverarbeitbarer Form enthält. Diese Datei ist unsigniert Kopfdaten Obj_ Sendendes_System Obj_ LDT Arzt Labor27/ a/nn/JJMM/MM/aaa MusterLIS Obj_ Timestamp_Erstellung _Datensatz Obj_ Obj_ Obj_ Laborkennung Seite 22

23 Obj_ Laborbezeichnung Obj_ Laborarztpraxis Mueller/Meier Person Obj_ b6d6b48aeeff9b41e0dd1b7005a1c81b4fd8fc1d Abbildung 4: LDT-Datensatz (Beispiel) Die Datensatzbeschreibung lässt es zu, dass im Obj_0010 (Objekt Anhang) ein PDF-Befund als Base64- codierte Datei enthalten sein kann: Anhang Obj_ base64-kodierte_Anlage Obj_ JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFn ZXMgMiAwIFIvTGFuZyhkZS1ERSkgL1N0cnVjdFRyZWVSb290IDI0IDAgUi9N YXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+Pg0KZW5kb2JqDQoyIDAgb2JqDQo PC9UeXBlL1BhZ2VzL0NvdW50IDEvS2lkc1sgMyAwIFJdID4+DQplbmRvYmoN eHJlZg0KMCAwDQp0cmFpbGVyDQo8PC9TaXplIDIzNy9Sb290IDEgMCBSL0lu Zm8gMjMgMCBSL0lEWzwxNEYyMDM2N0VBRDZBODQ1QTU0QzhGQTA3Q0M2N0Iy MT48MTRGMjAzNjdFQUQ2QTg0NUE1NEM4RkEwN0NDNjdCMjE+XSAvUHJldiAy ODI3NDAvWFJlZlN0bSAyODIwNjU+Pg0Kc3RhcnR4cmVmDQoyODc2NDANCiUl RU9G Obj_ PDF Befund Obj_0010 Abbildung 5: Obj_0010 (Anhang) mit Base64-codiertem PDF-Dokument mit QES Bei der Codierung der Anhänge von LDT-Dateien, hier der PDF-Datei, muss beachtet werden, dass die Länge des Base64-Codes maximal 60 Zeichen pro Zeile beträgt, mit Längenangabe, Feldkennung und CRLF also 69 Zeichen (siehe dazu " Datensatzbeschreibung LDT 3.0.1, Kapitel 6.4.2). Die optional dritte Komponente besteht aus einer PDF-Datei, die die Inhalte der zweiten Komponente, der LDT-Datei, semantisch gleich und vollständig in für den Menschen in leicht lesbarer Form enthält, die auch in der LDT-Datei in kodierter Form enthalten ist. Diese Form der Nachricht ist nur zulässig, wenn nur genau ein Befund (1 x Satzart 8205 in LDT-Datei) in der Nachricht übertragen wird. Dann kann auch genau eine PDF-Datei in der Nachricht enthalten sein. Die PDF-Dateien werden vom Labor- bzw. Kommunikationssystem in eigener Verantwortung in Form von PDF/A-Dokumenten erzeugt. Diese PDF-Dateien können/sollen mit einer qualifizierten Signatur versehen sein. Seite 23

24 Wie bereits beschrieben besteht der wesentliche Teil der Nachricht aus einer LDT 3.0-Datei. Diese Datei kann nach der LDT 3.0-Spezifikation (siehe dazu " Datensatzbeschreibung LDT 3.0.1, Kapitel 6.2.3) einen oder mehrere Befunde (Satzart 8205) auch für einen oder mehrere Patienten enthalten. Abbildung 6: LDT 3.0 Einzelbefund In Abbildung 6 ist die Struktur der LDT-Datei dargestellt. Die im Befund eingepasste PDF-Datei ist, wie oben beschrieben, optional. Nach der LDT-Spezifikation kann eine LDT-Datei jedoch auch mehrere Befunde (Satzart 8205) enthalten. Auch bei dieser Art der Befunddatei können zusätzliche Dokumente eingebettet mitgeliefert werden. Die mitgelieferten Dokumente sind dabei den Befunden zuzuordnen und im Obj_Anhang (Obj_0010) zu integrieren, zu denen sie vom Auftrag her gehören. Es ist zulässig, dass ein Teil der Befunde Zusatzdokumente enthält (z.b. PDF-Befund, Bild des Entnahmegefäßes), ein anderer Teil jedoch nicht. Abbildung 7: LDT 3.0 Mehrfachbefund Seite 24

25 Abbildung 7 zeigt graphisch den Aufbau einer derartigen Datei. Die LDT-Datei darf eine maximale Dateigröße von 15 MB nicht überschreiten! [LDTSM002]: Jede LDT-Nachricht MUSS genau eine LDT-Datei enthalten. [LDTSM003]: Jede LDT-Nachricht KANN eine PDF-Datei enthalten. [LDTSM004]: Die Dateigröße einer LDT-Datei DARF nicht größer, wie 15 MB sein. 3.3 Aufbau der KV-Connect Nachrichten Verwendete Segment- und X-Attribute Zur Erleichterung der Verarbeitung von KV-Connect Nachrichten werden diese mit anwendungs- und nachrichtenspezifischen Attributen angereichert, die die Nachrichten als Ganzes aber auch deren einzelne Bestandteile kennzeichnen. Die eingesetzten Attribute entstammen einem Pool von Attributen, die zentral für alle KV-Connect Anwendungen hier dokumentiert und gepflegt werden. In der hier beschriebenen Anwendung kommen die folgenden Attribute zur Anwendung: Nachrichtenart (Teil 1) Header-Attribute Erklärung Laborbefund X-KVC-Dienstkennung: LDT- Befund;Lieferung;V1.0 Nachrichten-Typ: Laborbefund MDN X-KVC-Dienstkennung: LDT- Befund;Eingangsbestaetigung;V1. 0 Nachrichten-Typ: MDN-Quittung für einen Laborbefund Trigger X-KVC-Dienstkennung: LDT- Befund;Trigger;V1.0 Nachrichten-Typ: Initiale Nachricht für den Versand der Befundnachricht "Datenlieferung" Status- Nachricht X-KVC-Dienstkennung: LDT- Befund;Status;V1.0 Nachrichten-Typ: Status (Antwort auf optionale Funktion "Befundabruf") 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- Laborbefund Content-Description: LDT-Labor- Befund MIME-Segment der LDT-Befunddatei PDF- Laborbefund Content-Description: PDF-Labor- Befund MIME-Segment der PDF-Befunddatei Tabelle 3 Seite 25

26 3.4 Struktur der Nachricht "Laborbefund" Die Struktur der Nachricht "Laborbefund" Der Hersteller des Laborinformations- bzw. Kommunikationssystems hat bei der Erzeugung des Laborbefundes eine Reihe von Freiheiten. Diese sollte er im Sinne eines reibungslosen und mit seinen Kunden abgestimmten Workflows wahrnehmen. Die möglichen Optionen werden in den folgenden Grafiken dargestellt. Die einfachste Form der Laborbefund-Nachricht besteht (neben den minimal erforderlichen MIME- Komponenten) aus nur einer LDT-Datei. Wie im vorherigen Kapitel beschrieben kann diese Datei mehr als einen Befund (Satzart 8205) enthalten. Abbildung 8: Struktur einer einfachen Befund-Nachricht Sollte mit dem Befund jedoch ein rechtsverbindliches Dokument als (signiertes) PDF-Dokument übermittelt werden, so sieht eine derartige Nachricht so aus, wie in der nächsten Grafik dargestellt. Zu beachten ist, dass die angehängte PDF-Datei auch als Anhang im LDT-Befund integriert, vorhanden sein muss (s.o., insbesondere, um der LDT 3.0 Spezifikation zu entsprechen). Die beiden PDF- Dokumente im LDT- und S/MIME-Anhang müssen binär identisch sein. Abbildung 9: Struktur einer Labor-Befund-Nachricht mit Anhang Seite 26

27 Sollten mit einer Labordatenübertragung mehrere Befunde mit zugehörigen Anhängen übertragen werden, so ist der MIME-konforme Übertragungsweg nicht mehr möglich, da in diesem Fall die Zuordnung der MIME-Anhänge zu den Einzelbefunden innerhalb der LDT-Datei verloren geht Die Nachrichten-Struktur Alle Nachrichten mit fachlichen Inhalten sind äußerlich ähnlich aufgebaut (siehe 4.3). Sie bestehen 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 übermittelnden Dokumente technisch gesehen als Anhänge (in diesem Beispiel mit einer optionalen PDF-Datei). Content-Type: multipart/mixed; boundary=" " This is a multi-part message in MIME format Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Body des LDT-Befundes Content-Type: text/plain; name="z01befund_8205_mit_pdf.ldt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="z01befund_8205_mit_pdf.ldt" Content-Description: LDT-Labor-Befund MDEzODAwMDgyMjANCjAxODgxMzJLb3BmZGF0ZW4NCjAxNzgwMDJPYmpfMDAzMg0KMDI1ODE1 MVNlbmRlbmRlc19TeXN0ZW0NCjAxNzgwMDJPYmpfMDA1MQ0KMDE3MDAwMUxEVDMuMC4xDQow CjAzMjgyMDBFaW5zZW5kZXJpZGVudGlmaWthdGlvbiANCjAxMTczMjEwMQ0KMDEzODMxMjA0 NTINCjAwOTgyMDENCjAwOTgwMDE= Content-Type: application/pdf; name="befund_8205_mit_pdf.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="befund_8205_mit_pdf.pdf" Content-Description: PDF-Labor-Befund JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIv TGFuZyhkZS1ERSkgL1N0cnVjdFRyZWVSb290IDI0IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0 Pgo8MUZBQkI1QzM4QzVFNUM0QUYxOEM4RkRDRkY1QUZDRTc+IF0KL0RvY0NoZWNrc3VtIC85 ODQxM0M0ODRGNDBEMUQwQTZENzkzMkE4MTVEMkU1QQo+PgpzdGFydHhyZWYKMzc3MDQ5CiUl RU9GCg== Abbildung 10: Nachrichtenstruktur Dieser gesamte MIME-Block ist die Basis der nun folgenden Signatur. Seite 27

28 [LDTSN005]: Jedes System, das LDT-Befund-Nachrichten versendet, MUSS die erzeugte LDT-Datei (mit einem oder mehreren Befunden) mit dem LDT-Prüfmodul prüfen und DARF diese Datei nur weiter verarbeiten, falls die Prüfung das Gesamtergebnis OK ergibt. [LDTSM006]: Jede LDT-Befund-Nachricht MUSS genau ein MIME-Segment mit einer base64- codierten, geprüften LDT-Datei enthalten. Das Segment MUSS die oben aufgeführten Metainformationen enthalten (Content-Type:, Content-Transfer-Encoding:, Content-Disposition:, Content-Description: ). Der angegebene Dateiname MUSS den Konventionen der LDT 3.0- Spezifikation mit der Endung.ldt (Groß- oder Kleinschreibung erlaubt) entsprechen. [LDTSM007]: Jede LDT-Befund-Nachricht KANN ein MIME-Segment mit einer base64-codierten PDF- Datei enthalten. Das Segment MUSS die oben aufgeführten Metainformationen enthalten (Content- Type:, Content-Transfer-Encoding:, Content-Disposition:, Content-Description: ). Der angegebene Dateiname MUSS mit der Endung.pdf (Groß- oder Kleinschreibung erlaubt) versehen sein 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 28

29 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary=" ms " This is a cryptographically signed message in MIME format ms Content-Type: multipart/mixed; boundary=" " This is a multi-part message in MIME format Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Body des LDT-Befundes Content-Type: text/plain; charset=utf-8; name="z01befund_8205_mit_pdf.ldt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="z01befund_8205_mit_pdf.ldt" Content-Description: LDT-Labor-Befund MDEzODAwMDgyMjANCjAxODgxMzJLb3BmZGF0ZW4NCjAxNzgwMDJPYmpfMDAzMg0KMDI1ODE1 MVNlbmRlbmRlc19TeXN0ZW0NCjAxNzgwMDJPYmpfMDA1MQ0KMDE3MDAwMUxEVDMuMC4xDQow CjAzMjgyMDBFaW5zZW5kZXJpZGVudGlmaWthdGlvbiANCjAxMTczMjEwMQ0KMDEzODMxMjA0 NTINCjAwOTgyMDENCjAwOTgwMDE= ms Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC FGgwggQuMIIDFqADAgECAgIBDDANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEcMBoG s4pexlmulzn767fg9mpduq+t0hvk9eipazbmmzhsgfiqedxdr2z814vl5+zctqqapa0z+woi 8HKMQ2crladleE8uSn5jG1iS3B4fqjP8fzKdwYdFHWkjFrQAAAAAAAA= ms Abbildung 11: S/MIME-Datei Seite 29

30 Für die Signatur ist bei KV-Connect der Hash-Algorithmus SHA-256 vorgeschrieben. Äquivalent zu der Beschreibung des MIME-Körpers entsteht aus der zweiten Form der MIME-Realisierung (der mit maximal einem zusätzlichen PDF-Dokument) folgende S/MIME-Darstellung: Seite 30

31 MIME-Version: 1.0 Content-Type:multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary=" ms " This is a cryptographically signed message in MIME format ms Content-Type: multipart/mixed; boundary=" " This is a multi-part message in MIME format Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Body des LDT-Befundes Content-Type: text/plain; charset=utf-8; name="z01befund_8205_mit_pdf.ldt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="z01befund_8205_mit_pdf.ldt" Content-Description: LDT-Labor-Befund MDEzODAwMDgyMjANCjAxODgxMzJLb3BmZGF0ZW4NCjAxNzgwMDJPYmpfMDAzMg0KMDI1ODE1 MVNlbmRlbmRlc19TeXN0ZW0NCjAxNzgwMDJPYmpfMDA1MQ0KMDE3MDAwMUxEVDMuMC4xDQow CjAzMjgyMDBFaW5zZW5kZXJpZGVudGlmaWthdGlvbiANCjAxMTczMjEwMQ0KMDEzODMxMjA0 NTINCjAwOTgyMDENCjAwOTgwMDE= Content-Type: application/pdf; name="befund_8205_mit_pdf.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="befund_8205_mit_pdf.pdf" Content-Description: PDF-Labor-Befund JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIv TGFuZyhkZS1ERSkgL1N0cnVjdFRyZWVSb290IDI0IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0 Pgo8MUZBQkI1QzM4QzVFNUM0QUYxOEM4RkRDRkY1QUZDRTc+IF0KL0RvY0NoZWNrc3VtIC85 ODQxM0M0ODRGNDBEMUQwQTZENzkzMkE4MTVEMkU1QQo+PgpzdGFydHhyZWYKMzc3MDQ5CiUl RU9GCg== ms Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Seite 31