Feinkonzept. Kommunikationsserver

Transkript

1 Feinkonzept Kommunikationsserver Stand der Spezifikation: Version: Redaktion: Informationstechnische Servicestelle der Gesetzlichen Krankenversicherung GmbH Heusenstamm, Seligenstädter Grund 11 Telefon 06104/ Telefax 06104/ info@itsg.de Anmerkung: Die Spezifikationen stehen unter dem Vorbehalt der Aufnahme in die technischen Anlagen der Verträge und Richtlinien für den Datenaustausch mit den gesetzlichen Krankenkassen. Stand: Seite: 1 von 48

2 Inhaltsverzeichnis 1 EINLEITUNG DIE SITUATION HEUTE AUFGABENSTELLUNG ÜBERBLICK ÜBER DIE LÖSUNG ANFORDERUNGEN AUS DEN FACHVERFAHREN SOZIALVERSICHERUNGSMELDUNGEN NACH DEÜV BEITRAGSNACHWEISE ARBEITGEBER UND ZAHLSTELLEN MELDUNGEN ZUR BEITRAGSERHEBUNG DER BERUFSSTÄNDISCHEN VERSORGUNGSEINRICHTUNGEN ENTGELTBESCHEINIGUNGEN ZAHLSTELLEN ELENA WEITERE FACHVERFAHREN Erstattungsverfahren nach dem Aufwendungsausgleichgesetz (AAG) Beitragsnachweise der Bundesagentur für Arbeit Beitragsnachweise der Optionskommunen ANFORDERUNGEN AN DIE TECHNIK ALLGEMEINE ANFORDERUNGEN UND RAHMENBEDINGUNGEN Unterstützte Verschlüsselungsverfahren Authentifizierung Multizertifikatsproblem Zertifikatswechsel vor Abruf der Rückmeldung Einheitlicher Umgang verschiedener Rückmeldestatus Übermittlung AG an Kommunikationsserver Weiterleitung der Meldung Kommunikationsserver an DAV Übermittlung DAV an AG über den Kommunikationsserver Nachweis der Übermittlung der Rückmeldungen Löschung der Dateipärchen auf dem Kommunikationsserver VERARBEITUNG UND KOMMUNIKATION AUF DEM MELDEWEG ÜBERBLICK SCHNITTSTELLEN MELDEWEG extra-schnittstelle - Meldung des AG an den Kommunikationsserver extra-schnittstelle - Antwort Kommunikationsserver an AG Aufbau der http-kommunikation zwischen AG und Kommunikationsserver ftp-schnittstelle - Weiterleitung Kommunikationsserver an DAV AUFGABEN DES KOMMUNIKATIONSSERVERS Entgegennahme der Meldung AG vom Kommunikationsserver Generierung Trackingnummer Erstellung der Annahmequittung an den AG Konvertierung der Daten für die DAV Weiterleitung der Meldung an die DAV VERARBEITUNG UND KOMMUNIKATION AUF DEM RÜCKMELDEWEG SCHNITTSTELLEN RÜCKMELDEWEG AG KOMMUNIKATIONSSERVER extra-schnittstelle - Anfrage der Rückmeldung inkl. der Authentisierung des AG extra-schnittstelle - Antwort Rückmeldungen Kommunikationsserver an AG Stand: Seite: 2 von 48

3 5.1.3 extra-schnittstelle - Quittung AG an Kommunikationsserver SCHNITTSTELLEN - RÜCKMELDEWEG DAV KOMMUNIKATIONSSERVER ftp-schnittstelle - Weiterleitung Rückmeldungen DAV an Kommunikationsserver http-schnittstelle - Weiterleitung Anfrage Rückmeldungen Kommunikationsserver an DAV http-schnittstelle - Antwort Rückmeldungen DAV an Kommunikationsserver ftp-schnittstelle - Anforderung zur Neuverschlüsselung Kommunikationsserver an DAV ftp-schnittstelle Rückmeldung Neuverschlüsselung DAV an Kommunikationsserver http-schnittstelle - Quittung Kommunikationsserver an DAV ftp-schnittstelle - Quittung Kommunikationsserver an DAV ftp-schnittstelle - Löschauftrag DAV an Kommunikationsserver Returncodes von DAV zum Kommunikationsserver AUFGABEN DES KOMMUNIKATIONSSERVERS Prüfung Ersteller-Authentisierung Pufferung ftp-rückmeldungen Analyse der AG-Anfrage Konvertierung Anfrage des AG für http-davn Zusammenstellung Rückmeldungen ftp-davn aus interner Datenbank Prüfung Verschlüsselungszertifikat <-> Authentisierungszertifikat Auftrag zur Neuverschlüsselung inkl. Rückmeldung an den AG Mitteilung an den AG bei Verwendung eines älteren Zertifikats Zusammenführung und Konvertierung der Antworten in extra-format Analyse der Quittung Konvertierung der Quittung Durchführung Löschauftrag Verarbeitung der Rückantwort zur Neuverschlüsselung Ausblick: Cockpit-Funktion FEHLERMELDUNGEN XML FEHLER XML DATENFEHLER (NUR EXTRA!) KRYPTO- UND KOMPRIMIERUNGSFEHLER FTP-RÜCKMELDUNG-FEHLER (AN DAVEN) ANFRAGEN QUITTUNGEN XML-SCHEMATA KOMMUNIKATION KOMSERVER UND DAV KOMMUNIKATION AG UND KOMSERVER EXTRA-BASIS-SCHEMATA EXTRA-DATENTRANSFER DUA-VERFAHREN GLOSSAR Stand: Seite: 3 von 48

4 Abbildungsverzeichnis Abbildung 1: Rückmeldeverfahren Ausgangssituation...8 Abbildung 2: Rückmeldeverfahren bei übergreifender Betrachtung der GKV-Fachverfahren Abbildung 3: Verarbeitung und Kommunikation Meldeweg bis zur Speicherung der Rückmeldedatei in der DAV Abbildung 4: Verarbeitung und Kommunikation Rückmeldeweg http Abbildung 5: Verarbeitung und Kommunikation Rückmeldeweg ftp (1) Abbildung 6: Verarbeitung und Kommunikation Rückmeldeweg ftp (2) Stand: Seite: 4 von 48

5 Dateieigenschaften Dateiname: Feinkonzept Kommunikationsserver V_1_2_6ä.doc Version: Stand: Autor(en): Gregor Grebe Tel.: +49 (0) Fax +49 (0) Dokumentenreferenz Nr. Name des Dokumentes (alle Dokumente in der aktuell gültigen Version) 1 Richtlinien für den Datenaustausch mit den gesetzlichen Krankenkassen 2 Datenaustausch mit Leistungserbringern und Arbeitgebern im Internet Spezifikation für das Verfahren 3 Anlage 9 zum gemeinsamen Rundschreiben Gemeinsames Meldeverfahren zur Kranken-, Pflege-, Renten- und Arbeitslosenversicherung 4 Besprechung der Spitzenverbände der Krankenkassen, der Deutschen Rentenversicherung Bund und der Bundesagentur für Arbeit zu Fragen des gemeinsamen Meldeverfahrens 5 Spezifikation der Schnittstellen für die Übermittlung von Dateien mittels File-Transfer-Protokoll (FTP) in der Gesetzlichen Krankenversicherung 1 1 Dieses Dokument ist noch in der TAG final abzustimmen. Stand: Seite: 5 von 48

6 Versionshistorie Version Datum Bearbeiter Bemerkung Gregor Grebe Erstellt Gregor Grebe, Ulrich Einarbeitung Feedback des LSV SpV Keller, Helmut Oppitz und der Bitmarck und Erkenntnisse aus Gregor Grebe, Helmut Oppitz Teilnehmer der AG Kommunikationsserver dem Fachkonzept Einarbeitung div. Feedbacks der DAVn und Ergänzungen aus dem Meeting mit den SWE, Ergänzung Kapitel 6 (technische Infrastruktur) Einarbeitung der Ergebnisse der Arbeitsgruppen-Sitzung, Einarbeitung Vorschlag Returncodes der Knappschaft Redaktionelle Überarbeitung und Freigabe Einarbeitung der Ergebnisse der Arbeitsgruppensitzung vom Teilnehmer der AG Kommunikationsserver Gregor Grebe, Dirk Drees Gregor Grebe Einarbeitung der Ergebnisse der Arbeitsgruppensitzungen vom uns Dirk Drees Einarbeitung der Kommentare Tobias Wagner Einfügen XML-Strukturbilder, Anpassen der XML-Beispiele Dirk Drees Einfügung FTP-Server-Struktur, Fehlermeldungen Dirk Drees Finale redaktionelle Anpassungen Dirk Drees Ergänzung Beispiele FTP-Dateinamen, Anpassung XML-Schema-Versionen, Ergänzungen/Klarstellungen Dirk Drees Rückmeldung nach der AG Sitzung vom , Entfernung technischer Aspekte Gregor Grebe Einarbeitung Ergebnisse der AG- Sitzung vom Carsten Boelts, Gregor Grebe Einarbeitung Ergebnisse der AG- Sitzung vom Stand: Seite: 6 von 48

7 1 Einleitung 1.1 Die Situation heute Arbeitgeber oder andere Meldepflichtige sind seit dem gesetzlich verpflichtet, Sozialversicherungsmeldungen und Beitragsnachweise, seit dem auch Meldungen zur Beitragserhebung der berufsständischen Versorgungseinrichtungen, (im Folgenden Datenlieferungen ) ausschließlich verschlüsselt elektronisch an die Datenannahme- und -verteilstellen (DAV) der gesetzlichen Krankenversicherung und der berufsständischen Versorgungseinrichtungen zu übermitteln. Die Zustellung basiert auf den Richtlinien für den Datenaustausch mit den gesetzlichen Krankenkassen [1]. Die Erstellung und Übermittlung der Meldungen kann durch den Meldepflichtigen an einen Dritten delegiert werden, der in diesem Fall als Ersteller der Datei in allen Sätzen der Datenlieferung auftritt. In der Praxis treten zudem Fälle auf, in denen der Verschlüsseler und Absender der Datenlieferung vom Ersteller abweicht. Zur Vereinfachung wird in diesem Dokument durchgehend die Bezeichnung Arbeitgeber (AG) verwendet. Nur wenn ein Vorgang an eine bestimmte Funktion wie Ersteller oder Absender gebunden ist, wird diese benannt. Die Datenlieferungen bei der DAV werden in Abhängigkeit vom Übermittlungsverfahren den entsprechenden Kommunikations- und Entschlüsselungsverfahren zugeführt. Die technische Annahme der Datenlieferung wird maschinell quittiert (Annahmebestätigung). Die DAV führt die Fehlerprüfung der Datensätze durch und leitet die erfolgreich geprüften Daten an die zuständigen Rechenzentren der Krankenkassen bzw. der berufsständischen Versorgungseinrichtungen weiter. Fehlerhafte Meldungen werden zurückgewiesen und dem AG in einem Fehlerprotokoll mit der Aufforderung zu korrigierter Neumeldung übermittelt. Mehr als 90 % aller AG nutzen heute das -Verfahren zur Zustellung der Datenlieferungen. Übermittelt werden pro Datenlieferung eine Auftragssatzdatei und eine verschlüsselte Nutzdatendatei. Das derzeitige Rückmeldeverfahren ist im folgenden Schaubild dargestellt. Stand: Seite: 7 von 48

8 Abbildung 1: Rückmeldeverfahren Ausgangssituation Fehlerhafte Datenlieferungen werden dem AG gegenüber, wenn sie die Datenlieferung selbst betreffen, mittels nachrichtlicher , wenn sie einzelne Datensätze betreffen, mittels gelber Post oder verschlüsselter dokumentiert. Dabei werden elektronische Rückantworten seitens der DAV mittels an die im Datensatz Kommunikation (DSKO, siehe [3]) ausgewiesene -Adresse versandt. 1.2 Aufgabenstellung Der Gesetzgeber fordert in einem nächsten Schritt, ein kostengünstiges und praktikables Verfahren für den Rückmeldeweg zu nutzen, das die heutigen Medienbrüche (gelbe Post) vermeidet. Die Umsetzung muss als einheitliches Verfahren von allen Stellen der gesetzlichen Krankenversicherung (GKV) betrieben werden. Andere Verfahrensteilnehmer können sich dem anschließen. Stand: Seite: 8 von 48

9 Die Ersteller von Entgeltabrechnungsprogrammen fordern für diesen Dienst einen Kommunikationsserver (im Pilotprojekt Statusserver genannt), der von Seiten des Entgeltabrechnungsprogramms oder einer Ausfüllhilfe maschinell abgerufen werden kann und die Rückmeldungen zum Download bereithält. In der 56. Sitzung des Lenkungsausschusses Arbeitgeberverfahren (LA AG) am hat der LA AG der Einrichtung eines zentralen Statusservers für Testzwecke zugestimmt. Da sich das Testverfahren nicht in dem angestrebten Funktions- und Zeitrahmen entwickelt hat, wurde es bis zum verlängert. Die gewonnenen Erkenntnisse haben gezeigt, dass eine umfassendere als die ursprünglich geplante Lösung notwendig sein wird, um allen Anforderungen an eine moderne, ausbaufähige und kostengünstige Kommunikationsplattform gerecht zu werden. Richtungweisend wurde der Ausbau des Statusservers zum Kommunikationsserver als die zentrale Anlaufstelle für die Kommunikation mit den AG beschlossen. 1.3 Überblick über die Lösung Es ist das Ziel, den Kommunikationsserver auf Dauer zu einer umfassenden Dialogplattform auszubauen. XML allgemein und damit auch der von der Arbeitsgemeinschaft für wirtschaftliche Verwaltung (AWV) propagierte Standard extra gewinnt zunehmend an Bedeutung - auch für die GKV. Dazu soll proaktiv der Kommunikationsserver nicht nur für den Rückmeldeweg, sondern auch als Tor zu den Datenaustauschverfahren konzipiert werden. Dieses Tor kann neben den etablierten Verfahren auch Meldungen in einem extra- Light Standard (Transport XML analog KKS, Inhalt flat File) annehmen. Der extra-standard stellt alle Felder, die heute bereits im Auftragssatz existieren, zur Verfügung. Somit können die Transportinformationen aus dem Auftragssatz im XML-Format und die Nutzdaten (beispielsweise im gängigen Aufbau: Vorlaufsatz, Datensätze, Nachlaufsatz) wie bisher geliefert werden. Der Kommunikationsserver übernimmt im Datenaustauschverfahren die Rolle einer neutralen Datendrehscheibe; die DAV dahinter nimmt die Lieferungen entgegen, d.h. auf dem Weg vom Tor zur DAV bleibt KKS als bewährtes Verfahren weiter bestehen. Im Außenverhältnis wird die Unterstützung des extra-standards durch dieses einheitliche Portal für AG angeboten. Im Sinne eines Full-Service-Portals (für alle Datenlieferungen innerhalb des Arbeitgeber- Meldeverfahrens) können auch Datenlieferungen-an-eine-Adresse an die DAV weitergeleitet werden. Dies stellt eine erhebliche Vereinfachung für AG unter der Federführung der GKV dar. Stand: Seite: 9 von 48

10 Das folgende Schaubild veranschaulicht die Rolle eines Kommunikationsservers mit Tor - bzw. Maklerfunktion: Stand: Seite: 10 von 48

11 Abbildung 2: Rückmeldeverfahren bei übergreifender Betrachtung der GKV-Fachverfahren Stand: Seite: 11 von 48

12 2 Anforderungen aus den Fachverfahren 2.1 Sozialversicherungsmeldungen nach DEÜV Seit ist die elektronische Rückmeldung der Versicherungsnummer (VSNR) an den AG vorgesehen. Durch dieses Verfahren kann ein Sonderfall vorliegen, wenn eine Meldung ohne VSNR eingeht und dadurch eine Anfrage an die DSRV zur Ermittlung einer Versicherungsnummer gestellt wird. Nach Aussage der Datenstelle der Träger der Rentenversicherung (DSRV) führen ca. 90 % der Anfragen zu einer positiven Rückmeldung. In 10% der Fälle findet die DSRV keine VSNR. Diese Sonderfälle können mit hoher Wahrscheinlichkeit nicht in einem Dialogbetrieb durch die DSRV bearbeitet werden, sondern müssen manuell (papiergebundene Anfragen an Einwohnermeldeämter etc.) geprüft werden. Die elektronische Rückmeldung der VSNR erfolgt dadurch verzögert. Anforderung aus dem Fachverfahren für die zu übermittelnden Informationen: Dateiabweisung (der Datenlieferung) Dateihinweise (nur zum DSKO, ohne Datensatzhinweise- und -abweisungen) Datensatzhinweise (zu DSKO und/oder DSBD, DSME ohne Datensatzabweisungen) Datensatzabweisungen (Fehlerprotokoll, eventuell zusammen mit Datensatzhinweisen) Verarbeitungsbestätigung (der Datenlieferung) Rückmeldung der Versicherungsnummer (ab nicht DASBV) Rückmeldung der Mitgliedsnummer (nur DASBV) Die Anforderungen gelten auch für Sofortmeldungen an die DSRV und Meldungen an die DASBV Datenservice für berufsständische Versorgungseinrichtungen GmbH (DASBV). 2.2 Beitragsnachweise Arbeitgeber und Zahlstellen Anforderung aus dem Fachverfahren für die zu übermittelnden Informationen: Dateiabweisung (der Datenlieferung) Datensatzabweisung (Fehlerprotokoll) Verarbeitungsbestätigung (der Datenlieferung) Stand: Seite: 12 von 48

13 2.3 Meldungen zur Beitragserhebung der berufsständischen Versorgungseinrichtungen Anforderung aus dem Fachverfahren für die zu übermittelnden Informationen: Dateiabweisung (der Datenlieferung) Dateihinweise (nur zum DSKO, ohne Datensatzhinweise- und -abweisungen) Datensatzhinweise (zu DSKO und/oder DSBE ohne Datensatzabweisungen) Datensatzabweisungen (Fehlerprotokoll, eventuell zusammen mit Datensatzhinweisen) Verarbeitungsbestätigung (der Datenlieferung) Rückmeldung der Mitgliedsnummer 2.4 Entgeltbescheinigungen Im Entgeltbescheinigungsverfahren ist der Pilotbetrieb ab dem vorgesehen. Anforderung aus dem Fachverfahren für die zu übermittelnden Informationen: Dateiabweisung (der Datenlieferung) Datensatzabweisung (Fehlerprotokoll) Verarbeitungsbestätigung (der Datenlieferung) Rückmeldung der Fachinformation die Vorerkrankungszeiten den Brutto- und Nettobetrag der Entgeltersatzleistung 2.5 Zahlstellen Betriebe, die an ihre ehemaligen Mitarbeiter Versorgungsbezüge (z.b. Betriebsrenten) zahlen, erfüllen als sogenannte Zahlstelle arbeitgeberähnliche Verpflichtungen. Im Verfahren wird die Zahlstelle über die Zahlstellennummer identifiziert. Diese entspricht im Aufbau der Betriebsnummer, wird jedoch nicht in der Betriebsstättendatei, sondern in einer Zahlstellendatei geführt. Anforderung aus dem Fachverfahren für die zu übermittelnden Informationen: Dateiabweisung (der Datenlieferung) Datensatzabweisung (Fehlerprotokoll) Verarbeitungsbestätigung (der Datenlieferung) Rückmeldung der Fachinformation den Beginn der Beitragspflicht, die Höhe des maximal beitragspflichtigen Betrages (Berücksichtigung der Beitragsbemessungsgrenze), Stand: Seite: 13 von 48

14 den Beitragssatz (auch Veränderungen) und das Ende der Beitragspflicht 2.6 ELENA Im ELENA-Verfahren werden der Multifunktionale Verdienstdatensatz (MVDS) und der Datensatz zur Vergabe einer Verfahrensnummer (DSVV) vom AG gemäß [1] an die Zentrale Speicherstelle (ZSS) übermittelt. Nach den gesetzlichen Vorgaben startet der Meldebetrieb im ELE- NA-Verfahren am Ab dem ist der Testbetrieb für die Softwareersteller vorgesehen. Per Gesetz ist vorgeschrieben, die Rückmeldungen elektronisch zu übermitteln. Anforderung aus dem Fachverfahren für die zu übermittelnden Informationen: Dateiabweisung (der Datenlieferung) Datensatzabweisung (Fehlerprotokoll) Verarbeitungsbestätigung (der Datenlieferung) Rückmeldung der Verfahrensnummer 2.7 Weitere Fachverfahren Erstattungsverfahren nach dem Aufwendungsausgleichgesetz (AAG) Seit besteht die gesetzliche Vorgabe, dass der Arbeitgeber Anträge auf Erstattungen nach dem AAG elektronisch an die Umlagekassen senden kann. Das Verfahren ist derzeit in Abstimmung, die Planung sieht einen Start für den vor. Derzeit ist hier nur der Meldeweg festgelegt; der Rückmeldeweg ist noch nicht geklärt. Anforderung aus dem Fachverfahren für die zu übermittelnden Informationen: Dateiabweisung (der Datenlieferung) Datensatzabweisung (Fehlerprotokoll) perspektivisch: Rücktransport der Fachinformation, Antragsbescheid Beitragsnachweise der Bundesagentur für Arbeit Die Bundesagentur für Arbeit hat ab das Verfahren der Beitragsnachweise für Bezieher von Arbeitslosengeld umgestellt. Die Beitragsnachweise werden dann maschinell an das Bundesversicherungsamt (BVA) bzw. an die DAV übermittelt. Beitragsnachweise für Bezieher von Übergangsgeld sollen im Laufe des Jahres 2009 elektronisch übermittelt werden. Dieses Fachverfahren wird derzeit nicht betrachtet. Stand: Seite: 14 von 48

15 2.7.3 Beitragsnachweise der Optionskommunen Dieses Fachverfahren wird ebenfalls nicht weiter betrachtet, da ausschließlich Beitragsnachweise für den Zeitraum vor dem gemeldet werden. Stand: Seite: 15 von 48

16 3 Anforderungen an die Technik 3.1 Allgemeine Anforderungen und Rahmenbedingungen Unterstützte Verschlüsselungsverfahren Der Kommunikationsserver unterstützt ausschließlich das PKCS#7-Format nach der Security Schnittstelle für den Datenaustausch im Gesundheitswesen in der aktuell gültigen Version. Das PEM-Format wird nicht vom Kommunikationsserver unterstützt Authentifizierung Im Testverfahren Statusserver wurde lediglich eine schwache Authentifizierung realisiert. Der AG registriert sich auf einer Webseite unter der Angabe seiner Betriebsnummer (BBNR) und der Adressdaten und erhielt nach Sichtprüfung einen Benutzernamen und ein Passwort. Mit dieser Benutzerkennung wurde die Berechtigung zum Abruf des Status auf dem damaligen Statusserver überprüft. Zukünftig ist eine stärkere Authentifizierung der AG gefordert. Zur Überprüfung der Identität soll auf dem Rückmeldeweg wie auf dem Meldeweg das jeweilige Zertifikat des AG herangezogen werden. Es ist zu berücksichtigen, dass gerade bei den Meldungen der Krankenkassen an die AG, denen keine direkte AG-Meldung vorausging, aber bereits vorher eine Meldung des AG durchgeführt wurde (z.b. im Zahlstellenverfahren), die DAVn verwalten müssen, welcher Empfänger (AG-Kommunikationspartner) für diese BBNR zuständig sind. Dabei wurde in der Technischen Arbeitsgruppe (TAG) beschlossen, dass der Ersteller der letzten vorausgegangenen Meldung als Empfänger anzugeben ist. In der Praxis existieren Fälle, in denen der Ersteller vom Verschlüsseler und Absender der Daten abweicht. In der TAG-Sitzung vom und in der Sitzung des Lenkungsausschusses Arbeitgeberverfahren (LAAG) vom wurde beschlossen, dass künftig der Ersteller der Datenlieferung auch der Absender sein muss Multizertifikatsproblem Derzeit gibt es einige wenige AG, die von unterschiedlichen Stellen mit derselben BBNR und mehreren Zertifikaten (Multizertifikatsproblem) melden. Bei der Rückmeldung ist es erforder- Stand: Seite: 16 von 48

17 lich, die Nachricht dem zur BBNR passenden Zertifikatsschlüssel zuzuordnen und zu verschlüsseln. Hier ist eine organisatorische Lösung vorgesehen. Im gemeinsamen Rundschreiben Gemeinsames Meldeverfahren zur Kranken-, Pflege-, Renten- und Arbeitslosenversicherung in der aktuellen Fassung ist im Datenaustausch mit Arbeitgebern geregelt worden, dass für die Verschlüsselung einer Rückmeldung jeder Betriebsnummer ein Zertifikat zugeordnet werden können muss und ausschließlich das aktuellste Zertifikat verwendet wird. Durch die ergänzende Entscheidung der TAG und des LAAG (siehe 3.1.2) muss jede Meldestelle mit einer eigenen BBNR und einem eigenen Zertifikat agieren. Diese organisatorische Regelung ist sehr positiv zu bewerten. Zum einen schafft sie auf Seite der AG Klarheit und Verbindlichkeit, zum anderen vermeidet sie auf der GKV-Seite eine sehr aufwändig zu realisierende IT-basierte Lösung. Die BBNR des Absenders kann somit als eindeutige Identifikation für die Rückmeldungen für die Verschlüsselung der Rückmeldedateien mittels oder Kommunikationsserver und als Abrufkriterium für den Kommunikationsserver zur Zuordnung der richtigen Rückmeldungen genutzt werden Zertifikatswechsel vor Abruf der Rückmeldung Im Rahmen der Verschlüsselung der Rückmeldung ist der Fall zu berücksichtigen, dass sich durch die Verzögerung, die zwischen Meldungseingang und Abruf beim Kommunikationsserver auftritt, bei einem AG das Zertifikat ändern kann. Dieses Problem tritt dann auf, wenn die Lieferung der Daten von der DAV an den Kommunikationsserver asynchron erfolgt (Lieferung mittels ftp). Bei einer synchronen Kommunikation (http) kann die DAV online mit dem Zertifikat des AG verschlüsseln, mit dem sich der AG zum Datenabruf am Kommunikationsserver authentifiziert hat (siehe hierzu auch 5.3.6). Das Problem kann minimiert werden, wenn der AG neben der Authentifizierung alle weiteren gültigen Zertifikate meldet, deren private Schlüssel er ebenfalls im Zugriff hat. In den restlichen Fällen, in denen der AG nicht mehr über den zugehörigen Schlüssel verfügt oder das Zertifikat abgelaufen ist, ist eine Neuverschlüsselung notwendig. Hier muss der AG vom Kommunikationsserver darüber informiert werden, dass Daten für ihn vorliegen, diese aber Stand: Seite: 17 von 48

18 durch den Zertifikatswechsel erst am nächsten Tag verfügbar sind. Die DAV erhält zeitgleich einen Auftrag zur Neuverschlüsselung der Daten mit dem neuesten Zertifikat Einheitlicher Umgang verschiedener Rückmeldestatus Bisher bestehen keine einheitlichen Vorgaben für den Umgang mit Dateiabweisungen oder Verarbeitungsbestätigungen. Einige DAVn versenden diese Informationen derzeit als - Anhang im pdf-format, der für eine automatisierte Weiterverarbeitung nicht geeignet ist. Mit Einführung des Kommunikationsservers können die betreffenden Informationen bei Dateiabweisungen und Verarbeitungsbestätigungen analog zu den Fehlerrückmeldungen in den für die DAV leicht zu erstellenden Auftrags- und Nutzdaten in der angehängt bzw. über den Kommunikationsserver zurück gemeldet werden. Für das DEÜV-Verfahren wurde hierzu folgender Vorschlag für eine Ergänzung des Fehlerkatalog der Anlage 9 zum Gemeinsamen Rundschreiben erarbeitet: Am Ende des Nachlaufsatzes (NCSZ) ist der Datenbaustein Fehler (DBFE) mit entsprechenden Hinweisen auch im Positivfall zu liefern. Der Aufbau der Rückmeldung wurde folgendermaßen abgestimmt: Rückmelde-Typ Aufbau Rückmeldedatei (** von der DAV erstellte Sätze) Dateiabweisung: VOSZ** (VOSZ + n DBFE 2 DSKO 3 + n DBFE 4 NCSZ 5 + n DBFE 6 ) NCSZ** Datensatzabweisung: VOSZ** (VOSZ DSKO + n DBFE 7 n (DSXX 8 + n DBFE) NCSZ) NCSZ** Verarbeitungsbest.: VSNR-Vergaben: VOSZ** (VOSZ DSKO NCSZ + DBFE) NCSZ** VOSZ** (n DSME) NCSZ** Im Falle einer fehlerfreien Meldung wird im DBFE der Rückmeldung ausschließlich der Hinweis NCSZH10 Datei wurde fehlerfrei verarbeitet zurückgegeben. 2 optional, n<10 3 optional 4 optional 5 optional 6 optional, n<10 7 optional 8 alle Datensätze außer DSKO (z.b DSME, DSBD, ) Stand: Seite: 18 von 48

19 3.1.6 Übermittlung AG an Kommunikationsserver Im Sinne des zuvor erwähnten Full-Service-Portals sendet der AG seine Meldungen an den Kommunikationsserver im KKS- oder extra-format, der diese direkt im Anschluss im KKS- Format an die DAV weiterleitet. Daher wird der Fokus im ersten Schritt der Umsetzung des Kommunikationsservers auf die Datenannahme im extra-standard gelegt. Die bestehenden KKS-Verfahren (z.b. und FTAM) können zu einem späteren Zeitpunkt ebenfalls vom Kommunikationsserver unterstützt werden. Für den AG ist der Kommunikationsserver somit eine zusätzliche Möglichkeit, die Meldungen komfortabler zu versenden. Beim Versand über den Kommunikationsserver erhält der AG zusätzlich eine zentral vergebene Trackingnummer. Diese Trackingnummer kann dem AG zusätzlich dazu dienen, den Status der Meldung direkt bei der DAV abzufragen. Zukünftig könnte sie auch für eine Cockpit-Funktion auf dem Kommunikationsserver genutzt werden. Der etablierte direkte Kommunikationsweg zwischen AG und DAV im bewährten KKS-Format wird parallel weiter aufrechterhalten. Die kassenartenübergreifende Weiterleitung von Sozialversicherungsmeldungen zwischen den DAVn wird zum eingestellt, da die AG nach 23 Abs. 1 DEÜV ihre Meldungen grundsätzlich der zuständigen DAV zu erstatten haben. Ein weiterer Grund für die Etablierung des Kommunikationsservers ist die Verpflichtung der Krankenkassen, die Fehlermeldung und die Vergabe der VSNR dem AG, elektronisch zu melden. Weiterhin wurde gefordert, nicht wie im Testverfahren das Feld -AP im DSKO für die Ermittlung des Rückmeldewegs zu missbrauchen. Der Rückmeldeweg (Kommunikationsserver, oder gelbe Post) wird vom Ersteller im DSKO-Feld KENNZ-FEHLRUECK (Stelle 412) für das jeweilige Verfahren festgelegt Weiterleitung der Meldung Kommunikationsserver an DAV Der Kommunikationsserver konvertiert die extra-meldung des AG in ein oder mehrere KKS- Dateipärchen und leitet diese an den FTP-Server der jeweils zuständigen DAV weiter. Diese Kommunikation ist durch ein virtuelles privates Netzwerk (VPN über IPSec) abgesichert. Stand: Seite: 19 von 48

20 3.1.8 Übermittlung DAV an AG über den Kommunikationsserver Der Rückweg via oder gelber Post erfolgt direkt von der DAV an den AG, in diesem Fall wird der Kommunikationsserver nicht zwischengeschaltet. Für die Kommunikation zwischen DAV und Kommunikationsserver haben sich zwei verschiedene Verfahren herauskristallisiert: Eine synchrone Kommunikation über das http-protokoll und eine asynchrone Kommunikation über das ftp-protokoll. Beide Varianten werden durch ein IPSec-VPN abgesichert. Jede DAV kann entscheiden, welche Variante sie bei dem Rückmeldeverfahren einsetzt. Im http-modus erfolgt die Übermittlung folgendermaßen: Die Ergebnisse der Fehlerprüfung derjenigen AG, die ihre Daten vom Kommunikationsserver abrufen möchten, werden bei der jeweiligen DAV in einer internen Abrufdatenbank gespeichert. Bei einer Anfrage des AG an den Kommunikationsserver werden die Daten in Form eines Dateipärchens (Auftrags- und Nutzdatendatei) vom Kommunikationsserver online bei der DAV abgerufen, die diese Daten mit dem in der Anfrage verwendeten Zertifikat verschlüsselt und an den Kommunikationsserver zur Weiterleitung übermittelt. Falls die Daten innerhalb eines definierten Zeitraums nicht vom AG abgeholt werden, kann die DAV durch regelmäßiges Prüfen ihres internen Bestands diesen Umstand feststellen und den AG aktiv informieren. Eine Interaktion des Kommunikationsservers ist hierbei nicht notwendig. Im ftp-modus wird die Rückmeldung direkt nach der Erstellung mit dem neuesten Zertifikat des AG verschlüsselt und an den Kommunikationsserver übermittelt. Ist zu diesem Zeitpunkt kein gültiges Zertifikat zu dieser Betriebsnummer vorhanden, wird die Rückmeldung im Ersatzverfahren (gelbe Post) dem AG zugestellt. Beim Datenabruf durch den AG wird das Dateipärchen automatisch aus der internen Datenbank des Kommunikationsservers geladen und in die Rückantwort integriert. Eine Kommunikation zwischen Kommunikationsserver und DAV ist bei diesem Schritt nicht notwendig. Falls der AG beim Datenabruf über ein neueres Zertifikat verfügt und der private Schlüssel des seinerzeit zur Verschlüsselung verwendeten Zertifikates nicht mehr zur Verfügung steht (oder das Zertifikat inzwischen abgelaufen ist), wird vom Kommunikationsserver ein Auftrag zur Neu- Stand: Seite: 20 von 48

21 verschlüsselung der Daten mit dem aktuellen Zertifikat des AG an die DAV gesendet. Parallel wird der AG vom Kommunikationsserver über diesen Vorgang informiert. Fragt der AG mit einem älteren Zertifikat an, erhält er eine Nachricht, dass die Abfrage mit dem neuesten Zertifikat zu wiederholen ist. Dabei ist zu beachten, dass es bei dieser Rückmeldung möglich ist, dass der AG zeitgleich von den DAVn, die das http-verfahren unterstützen, eine Positiv-Rückmeldung erhält Nachweis der Übermittlung der Rückmeldungen DAVn haben eine Verpflichtung zur nachweislichen Übermittlung der Fehlermeldungen und benötigen hierfür einen entsprechenden Beleg. Dazu wird jeder Abruf in seinen einzelnen Schritten protokolliert. Entscheidend für den erforderlichen Nachweis ist in diesem Zusammenhang die als letztes zu übermittelnde Empfangsquittung des AG. Diese ist vom AG nach erfolgreicher Entschlüsselung der Daten über den Kommunikationsserver an die DAV zu melden. Nach dem Empfang dieser Quittung werden die Dateipärchen bei der DAV gelöscht Löschung der Dateipärchen auf dem Kommunikationsserver In der ftp-variante muss nach dem Empfang der Quittung oder wenn die DAV nach Ablauf der 40-Tages-Frist die Rückmeldung in einem Ersatzverfahren (gelbe Post) an den AG versendet, ein Löschauftrag für dieses Dateipärchen von der DAV an den Kommunikationsserver gesendet werden. Dieser Wert muss durch die DAV parametrisierbar sein, so dass die Änderung dieser Frist kurzfristig vorgenommen werden kann. Für die Weiterentwicklung des Verfahrens im Jahr 2010 wird zusätzlich vorgesehen, dass diese Frist pro Verfahren parametrisierbar ist. Stand: Seite: 21 von 48

22 4 Verarbeitung und Kommunikation auf dem Meldeweg 4.1 Überblick Die folgende Abbildung fasst die Verarbeitung und Kommunikation Meldeweg zusammen: Stand: Seite: 22 von 48

23 Stand: Seite: 23 von 48

24 Abbildung 3: Verarbeitung und Kommunikation Meldeweg bis zur Speicherung der Rückmeldedatei in der DAV 4.2 Schnittstellen Meldeweg extra-schnittstelle - Meldung des AG an den Kommunikationsserver Der AG meldet seine Daten über die extra Schnittstelle (vgl. extra-schnittstellenentwurf GKV) an den Kommunikationsserver. In der Datenlieferung werden im Paketbody eine oder mehrere verschlüsselte Nutzdatendateien übermittelt. Die Übermittlung mehrerer Nutzdatendateien in einer gemeinsamen Sendung birgt das Risiko, dass bei einer Ablehnung der Daten durch den Kommunikationsserver die komplette Sendung abgelehnt wird, d.h. auch die korrekten Nutzdaten können nicht verarbeitet werden. Die Nutzdatendateien enthalten den DSKO in der Version 2.0, der in der Anlage zu den jeweiligen Gemeinsamen Grundsätzen der Arbeitgebermeldeverfahren beschrieben ist. Der DSKO spielt eine zentrale Rolle für die weitere Verarbeitung. Der DSKO enthält neben dem Feld -AP (Stelle ) auch die Kennzeichen VER- BEST (Stelle 411) und FERUECK (Stelle 412). Neben der Angabe der -Adresse des Ansprechpartners wird mit diesen Pflichtfeldern gesteuert, ob eine Bestätigung der fehlerfreien Verarbeitung und die Übermittlung der Rückmeldungen mittels Datensatz im -Verfahren (verschlüsselt) gewünscht ist. Das Feld FERUECK (Stelle 412) wurde so angepasst, dass neben den Kennzeichen J/N der Ersteller mit dem Kennzeichen K steuern kann, dass die Rückmeldungen auf dem Kommunikationsserver bereitgestellt werden. Wird die Stelle 411 auf J gesetzt und 412 auf K, so werden auch die Verarbeitungsbestätigungen auf dem Kommunikationsserver bereitgestellt. Ist Stelle 412 auf N gesetzt, so werden für alle Verfahren, bei denen ausschließlich eine verschlüsselte elektronische Rückmeldung vorgesehen oder zugelassen ist (z.b. bei der Rückmeldung der Versicherungsnummer), die Rückmeldung auf dem Kommunikationsserver bereitgestellt. Stand: Seite: 24 von 48

25 Ist im DSKO die Stelle 412 unzulässig gefüllt, so werden die Rückmeldungen auf dem Kommunikationsserver bereitgestellt extra-schnittstelle - Antwort Kommunikationsserver an AG Der AG erhält nach dem Versand ein sogenanntes Acknowledgement (vgl. extra- Schnittstellenentwurf GKV) vom Kommunikationsserver. Im Feld ResponseID wird pro Nutzdatendatei die vom Kommunikationsserver vergebene Trackingnummer an den AG zurück gemeldet. Zusätzlich vergibt der Kommunikationsserver eine Sendungsnummer für das Gesamtpaket Aufbau der http-kommunikation zwischen AG und Kommunikationsserver Die Kommunikation zwischen AG und Kommunikationsserver basiert auf einem POST-Request ohne die Angabe von Namen-Wert-Paaren und ohne die Angabe von http-argumenten in der URL. Der HTTP-Request und die HTTP-Response müssen als Binary-Request ausgeführt werden, wobei der Request-Header lediglich die Attribute "Content-Type" und "Content- Length" enthalten muss. Der Request-Body enthält ausschließlich die zu übermittelnden Daten. Inhalt des Request-Headers: Content-Type: application/octet-stream Content-Length: <Größe des http-body in Bytes) Inhalt des Request-Body: Der Inhalt des Request-Body ist das extra-datenpaket ftp-schnittstelle - Weiterleitung Kommunikationsserver an DAV Diese Schnittstelle wird nach der Spezifikation der Schnittstellen für die Übermittlung von Dateien mittels File-Transfer-Protokoll (FTP) in der Gesetzlichen Krankenversicherung [5] in der aktuell gültigen Version betrieben. Der Kommunikationsserver leitet das Dateipärchen im KKS-Format an den FTP-Server der DAV. Stand: Seite: 25 von 48

26 Die Leitung wird mit einem IPSec-VPN abgesichert. 4.3 Aufgaben des Kommunikationsservers Entgegennahme der Datenlieferung AG vom Kommunikationsserver Die Datenlieferung des AG wird auf dem Webserver des Kommunikationsservers unter einer dedizierten URL zur Datenannahme entgegen genommen und syntaktisch gegen das vorgegebene Schema geprüft. Tritt ein technischer Fehler auf oder schlägt die Schemaprüfung fehl, kann der Kommunikationsserver keine sinnvolle extra-nachricht erstellen, da wesentliche Daten hierfür fehlen. In diesem Fall wird die Fehlermeldung als Textdatei zurückgesendet. Eine Prüfung der Nutzdaten erfolgt in diesem Fall nicht, da die notwendigen Schlüssel nur der jeweiligen DAVn zur Verfügung stehen und keine Weiterleitung erfolgt Generierung Trackingnummer Nach erfolgreicher Prüfung erstellt der Kommunikationsserver eine eindeutige Trackingnummer zu jeder Nutzdatendatei (TimeStamp bis zur Nanosekunde) sowie zum Gesamtpaket (siehe hierzu auch 4.2.2) Erstellung der Annahmequittung an den AG Die Rückantwort an den AG wird nach der in Punkt genannten Schnittstelle erstellt. Dabei wird je nach Ergebnis der Prüfung in Punkt im Element Report auf Package-Ebene die Rückantwort Error erstellt. Hier werden lediglich die mit der Kommunikation verbundenen Fehler zurückgemeldet (z.b. Der AG ist für das Verfahren nicht zugelassen. Weder fachliche (siehe hierzu auch Punkt 3.1.5) noch technische (siehe hierzu auch Punkt 4.3.1) Fehler werden berücksichtigt. Stand: Seite: 26 von 48

27 4.3.4 Konvertierung der Daten für die DAV Aus der extra-meldung wird die verschlüsselte Nutzdatendatei herausgelöst und Base64- decodiert. Aus den Header-Informationen wird der Auftragssatz gemäß Anhang Auftragsdatei_eXTra_V_1_0_2.doc erstellt. Der Dateiname des konvertierten Dateipärchens wird um die Trackingnummer ergänzt. Der Dateiname hat somit folgenden Aufbau: <BBNR der DAV>_<Dateiname aus Auftragssatz [aus extra-plugin DataSource]>_<TimeStamp bis zur Nanosekunde>. Der Auftragssatz erhält den gleichen Dateinamen mit der zusätzlichen Endung.AUF. Gültiger Zeichenvorrat und Länge: Beschreibung Länge Zeichenvorrat und gültiger Inhalt <BBNR der DAV> Betriebsnummer der DAV _ Trennzeichen 1 _ <Dateiname > Dateiname bestehend 8 A-Z0-9 aus Verfahrenskennung Aufbau: [TE]{1}[A-Z]{3}0[0-9]{3} und Transfer- nummer _ Trennzeichen 1 _ <Trackingnummer> TimeStamp bis zur Nanosekunde Beispiel: _EDUA0123_ [.AUF] Weiterleitung der Meldung an die DAV Die Weiterleitung wird nach der in Punkt genannten Schnittstelle erstellt. Stand: Seite: 27 von 48

28 5 Verarbeitung und Kommunikation auf dem Rückmeldeweg Die folgenden Abbildungen fassen die Verarbeitung und Kommunikation Rückmeldeweg zusammen: Abbildung 4: Verarbeitung und Kommunikation Rückmeldeweg http Stand: Seite: 28 von 48

29 Abbildung 5: Verarbeitung und Kommunikation Rückmeldeweg ftp (1) Stand: Seite: 29 von 48

30 Abbildung 6: Verarbeitung und Kommunikation Rückmeldeweg ftp (2) Stand: Seite: 30 von 48

31 5.1 Schnittstellen Rückmeldeweg AG Kommunikationsserver extra-schnittstelle - Anfrage der Rückmeldung inkl. der Authentisierung des AG Die Anfragen werden vom Kommunikationsserver verarbeitet und müssen deswegen direkt am Kommunikationsserver durch eine geeignete Authentifizierung geprüft werden. Dadurch sind zum einen SPAM-Attacken besser abzuwehren, zum anderen sind durch die Authentifizierung nur Anfragen berechtigter AG zugelassen. Die Authentifizierung der Anfrage wird implizit durch Übermittlung eines verschlüsselten Anfragedokumentes erfolgen. Das ausgefüllte XML-Dokument der Anfrage wird laut Schema erstellt und gemäß dem bestehenden Verfahren im Datenaustausch in der GKV signiert und verschlüsselt. Somit ist eine einheitliche und erprobte Authentisierung gewährleistet. Die zu verwendenden öffentlichen Schlüssel für die Verschlüsselung des XML-Dokumentes werden in den öffentlichen Annahmelisten bereitgestellt. Der Kommunikationsserver stellt dazu den folgenden öffentlichen Schlüssel bereit: Verfahren BN Kommunikationsserver Die komplette Anfrage wird als extra-nachricht übertragen. Als Rahmen wird die extra- Spezifikation (vgl. extra-schnittstellenentwurf GKV) verwendet. Der Kommunikationsserver entschlüsselt die Nachricht und prüft die Authentizität der gelieferten Anfrage. Diese Datenschnittstelle wird XML-basiert betrieben. Die XML-Schnittstelle ist als Anlage in Form einer XSD-Datei beschrieben. Der Inhalt des Elementes Base64CharSequence wird KKS-verschlüsselt und base64-codiert in die extra-nachricht eingehängt. Das zugehörige Schema ist als XSD-Datei im Anhang zu finden. Stand: Seite: 31 von 48

32 Es ist zu beachten, dass es im Verfahren DAVn gibt, die mit mehreren Betriebsnummern innerhalb einer DAV agieren (z.b. Knappschaft-Bahn-See). In diesem Fall dürfen Anfragen, bei denen keine Betriebsnummer einer DAV angegeben ist, nur einmal an diese Annahmestellen übergeben werden. Daher muss jede DAV bei der Registrierung einer Betriebsnummer auf dem Kommunikationsserver mit angeben, ob Anfragen, die keine Ziel-Betriebsnummer enthalten, an diese Betriebsnummer weiter geleitet werden sollen extra-schnittstelle - Antwort Rückmeldungen Kommunikationsserver an AG Als Rahmen wird die extra-spezifikation extra-schnittstellenentwurf GKV verwendet. Dabei werden alle zur Anfrage gehörenden Rückantworten in einem gemeinsamen extra-schema zurück geliefert. Der Inhalt der fachlichen Rückantworten ist in den jeweiligen Fachverfahren definiert. Zusätzlich können zwei weitere Rückmeldestatus zurückgegeben werden: Die Anfrage erfolgte nicht mit dem neuesten Zertifikat des AG. Bitte fragen Sie erneut mit diesem Zertifikat an, es liegen Daten für dieses Zertifikat vor. Es liegen Daten vor, die neu verschlüsselt werden müssen, bitte fragen Sie in 24 Stunden noch einmal an. Rückmeldungen dieser Art werden als zusätzliches Flag im Report der ResponseDetails auf Transportebene übertragen. Dabei ist der entsprechende Statuscode und Text anzugeben. Die Datei ist als Anlage in Form einer XSD-Datei beschreiben extra-schnittstelle - Quittung AG an Kommunikationsserver Die Quittung wird vom AG an den Kommunikationsserver analog zu Punkt als XML-Datei erstellt und gemäß dem bestehenden Verfahren im Datenaustausch in der GKV signiert und verschlüsselt. Die komplette Quittung wird als extra Nachricht übertragen. Als Rahmen wird die extra- Spezifikation (vgl. extra-schnittstellenentwurf GKV) verwendet. Der Aufbau der XML-Datei ist als Anlage in Form eine XSD-Datei beschrieben. Stand: Seite: 32 von 48

33 Das zugehörige Schema ist als XSD-Datei im Anhang zu finden. 5.2 Schnittstellen - Rückmeldeweg DAV Kommunikationsserver ftp-schnittstelle - Weiterleitung Rückmeldungen DAV an Kommunikationsserver Diese Schnittstelle wird nach der Spezifikation der Schnittstellen für die Übermittlung von Dateien mittels File-Transfer-Protokoll (FTP) in der Gesetzlichen Krankenversicherung [5] in der aktuell gültigen Version betrieben. Der Dateiname hat dabei folgenden Aufbau: <BBNR der DAV>_<Eindeutige von der DAV vergebene Trackingnummer>_<ursprünglicher_ Dateiname der Rückmeldung>. Der Auftragssatz hat den gleichen Dateinamen mit der Endung.AUF. Gültiger Zeichenvorrat und Länge: Beschreibung Länge Zeichenvorrat und gültiger Inhalt <BBNR der DAV> Betriebsnummer der DAV _ Trennzeichen 1 _ <Trackingnummer> Eindeutige von der max. 200 A-Z0-9 DAV vergebene Trackingnummer _ Trennzeichen 1 _ <ursprünglicher_ Dateiname ursprünglicher_ Da A-Z0-9 der Rückmelteiname der Rück- Aufbau: [TE]{1}[A-Z]{3}0[0-9]{3,6} dung> meldung, erstellt von der DAV Beispiel: _ _EDUA0123[.AUF] Stand: Seite: 33 von 48

34 5.2.2 FTP-Schnittstelle - Antwort Rückmeldungen Kommunikationsserver an DAV Der Kommunikationsserver erstellt nach erfolgreichem Einstellen der Rückmeldung eine Antwortdatei mit dem Dateinamen <BBNR der DAV>_<Eindeutige von der DAV vergebene Trackingnummer>_ <ursprünglicher_ Dateiname der Rückmeldung>_OK. Der Inhalt der Antwortdatei beträgt 1 Byte und besteht aus einem Leerzeichen. Im Fehlerfall wird eine Antwortdatei mit dem Dateinamen <BBNR der DAV>_<Eindeutige von der DAV vergebene Trackingnummer>_<ursprünglicher_ Dateiname der Rückmeldung>_FEHLER erstellt. Die Fehlermeldung wird als ASCII-Text in die Datei geschrieben. Diese Datei wird auf dem FTP-Server der jeweiligen DAV abgelegt. Gültiger Zeichenvorrat und Länge: Beschreibung Länge Zeichenvorrat und gültiger Inhalt <BBNR der DAV> Betriebsnummer der DAV _ Trennzeichen 1 _ <Trackingnummer> Eindeutige von der max. 200 A-Z0-9 DAV vergebene Trackingnummer _ Trennzeichen 1 _ <ursprünglicher_ ursprünglicher_ Dateiname 8-11 A-Z0-9 Dateiname der der Rückmel- Aufbau: [TE]{1}[A-Z]{3}0[0-9]{3,6} Rückmeldung> dung, erstellt von der DAV _ Trennzeichen 1 _ <Status> Status 2 oder 6 A-Z gültiger Inhalt: FEHLER oder OK Beispiele: Stand: Seite: 34 von 48

35 _ _EDUA0123_OK _ _EDUA0123_FEHLER http-schnittstelle - Weiterleitung Anfrage Rückmeldungen Kommunikationsserver an DAV Diese Datenschnittstelle wird XML-basiert betrieben. Der Aufbau der XML-Schnittstelle ist als Anlage in Form einer XSD-Datei beschrieben. Die XML-Anfrage wird im VPN zwischen Kommunikationsserver und DAV übertragen. Die Antwort (vgl ) wird als HTTP-Response von der DAV an den Kommunikationsserver gesendet http-schnittstelle - Antwort Rückmeldungen DAV an Kommunikationsserver Diese Datenschnittstelle wird XML-basiert betrieben. Der HTTP-Request und die HTTP-Response müssen als Binary-Request ausgeführt werden, wobei der Response-Header lediglich die Attribute "Content-Type" und "Content-Length" enthalten muss. Der Response-Body enthält ausschließlich die zu übermittelnden Daten. Inhalt des Response-Headers: Content-Type: application/xml Content-Length: <Größe des http-body in Bytes> Inhalt des Response-Body: Der Inhalt des Response-Body ist das jeweilige-datenpaket. Der Aufbau der XML-Schnittstelle ist als Anlage in Form einer XSD-Datei beschrieben. Dabei ist von der DAV entweder der Teilast Rückmeldedaten (beim Vorliegen entsprechender Daten) oder der Teilast Statusinformation (wenn keine Daten vorliegen oder ein Fehler auftrat) zu befüllen. Es werden maximal 100 Nutzdatendateien pro extra-datenpaket von der DAV an den Kommunikationsserver zurück gesendet. Sofern mehr als 100 Nutzdatendateien für diese BBNR vorhanden sind, werden diese bei der nächsten Anfrage gesendet. Das zugehörige Schema ist als XSD-Datei im Anhang zu finden. Stand: Seite: 35 von 48

36 Die XML-Rückmeldung wird im IPSec-VPN zwischen DAV und Kommunikationsserver als Antwort auf die Weiterleitung der Anfrage (vgl. Punkt 3) in der gleichen Session gesendet ftp-schnittstelle - Anforderung zur Neuverschlüsselung Kommunikationsserver an DAV Die Anforderung zur Neuverschlüsselung erfolgt folgendermaßen: Der Kommunikationsserver stellt in das FTP-Eingangsverzeichnis der DAV eine Datei mit dem Dateinamen: NEU_<BBNR der DAV>_<Trackingnummer der neu zu verschlüsselnden Datei>_<Ursprünglicher Dateiname>ein. Gültiger Zeichenvorrat und Länge: Beschreibung Länge Zeichenvorrat und gültiger Inhalt <Status> Status 3 A-Z gültiger Inhalt: NEU _ Trennzeichen 1 _ <BBNR der DAV> Betriebsnummer der DAV _ Trennzeichen 1 _ <Trackingnummer> Eindeutige von der DAV max. 200 A-Z0-9 vergebene Trackingnummer _ Trennzeichen 1 _ <ursprünglicher_ ursprünglicher_ Dateiname 8-11 A-Z0-9 Dateiname> Aufbau: [TE]{1}[A-Z]{3}0[0-9]{3,6} Beispiel: NEU_ _ _EDUA0123 Der Inhalt der Antwortdatei beträgt 1 Byte und besteht aus einem Leerzeichen ftp-schnittstelle Rückmeldung Neuverschlüsselung DAV an Kommunikationsserver Die Rückmeldung zur Neuverschlüsselung erfolgt folgendermaßen: Die DAV stellt in das FTP-Eingangsverzeichnis des Kommunikationsservers ein neues Dateipärchen ein. Dieses hat folgenden Dateinamen: RUECKNEU_<BBNR der Stand: Seite: 36 von 48

37 DAV>_<ursprüngliche Trackingnummer der neu zu verschlüsselnden Datei>_<Trackingnummer der neuen Datei>_<Name der ursprünglichen Datei>. Der Auftragssatz hat den gleichen Dateinamen mit der Endung.AUF. Gültiger Zeichenvorrat und Länge: Beschreibung Länge Zeichenvorrat und gültiger Inhalt <Status> Status 8 A-Z gültiger Inhalt: RUECKNEU _ Trennzeichen 1 _ <BBNR der DAV> Betriebsnummer der DAV _ Trennzeichen 1 _ <Trackingnummer> ursprüngliche Trackingnummer max. 200 A-Z0-9 der neu zu verschlüsselnden Datei _ Trennzeichen 1 _ <Trackingnummer> Trackingnummer der max. 200 A-Z0-9 neuen Datei _ Trennzeichen 1 _ <ursprünglicher_ ursprünglicher_ Dateiname, 8-11 A-Z0-9 Dateiname> erstellt von der DAV Aufbau: [TBE]{1}[A-Z]{3}0[0-9]{3,6} Beispiel: RUECKNEU_ _ _ _EDU0123[.AUF] http-schnittstelle - Quittung Kommunikationsserver an DAV Diese Datenschnittstelle wird XML-basiert betrieben. Der Aufbau der XML-Schnittstelle ist als Anlage in Form einer XSD-Datei beschreiben. Das zugehörige Schema ist als XSD-Datei im Anhang zu finden. Die XML-Daten werden im VPN zwischen Kommunikationsserver und DAV übertragen ftp-schnittstelle - Quittung Kommunikationsserver an DAV Die Quittung über ftp hat den gleichen XML-Aufbau wie die Schnittstelle in Punkt Der Dateiname hat den Aufbau: Stand: Seite: 37 von 48

38 QUITTUNG_<BBNR der DAV>_<eindeutige Trackingnummer, die vom Kommunikationsserver vergeben wird>.xml. Gültiger Zeichenvorrat und Länge: Beschreibung Länge Zeichenvorrat und gültiger Inhalt <Status> Status 8 A-Z gültiger Inhalt: QUITTUNG _ Trennzeichen 1 _ <BBNR der DAV> Betriebsnummer der DAV _ Trennzeichen 1 _ <Trackingnummer> eindeutige Trackingnummer, die vom Kommunikationsserver vergeben wird. Trennzeichen 1. <Dateisuffix> Dateisuffix 3 A-Z gültiger Inhalt: XML Beispiel: QUITTUNG_ _ XML Die Übertragung erfolgt gemäß der Spezifikation der Schnittstellen für die Übermittlung von Dateien mittels File-Transfer-Protokoll (FTP) in der Gesetzlichen Krankenversicherung [5] in der aktuell gültigen Version ftp-schnittstelle - Löschauftrag DAV an Kommunikationsserver Die Löschung geschieht folgendermaßen: Die DAV stellt in das FTP-Eingangsverzeichnis des Kommunikationsservers eine Datei ein. Diese hat folgenden Dateinamen: LOESCH_<BBNR der DAV>_<Trackingnummer der zu löschenden Datei>_<ursprünglicher Dateiname der Rückmeldung>. Der Inhalt der Antwortdatei beträgt 1 Byte und besteht aus einem Leerzeichen. Gültiger Zeichenvorrat und Länge: Stand: Seite: 38 von 48