Inhaltsverzeichnis

1. Fortschreibung vom 31.10.1995

1 Allgemeines

(1) Diese Technische Anlage zur Datenübermittlungs-Vereinbarung gemäß § 301 Abs. 3 SGB V regelt organisatorische und technische Sachverhalte, die zur Erfüllung der Vereinbarung einer Regelung bedürfen.

(2) Die Pflege der Anlage erfolgt durch Austausch/Ergänzung einzelner Seiten oder Abschnitte. Die Änderung muß nach Abstimmung zwischen den Vertragsparteien beschlossen werden.

(3) Die Regelungen dieser Technischen Anlage entsprechen im wesentlichen den Grundsätzen für Datenübermittlung und Datenträgeraustausch in der Fassung von Dezember 1990, die von der Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (KBSt) herausgegeben wurde.

(4) Für den Abschnitt zur Datenübermittlung wird des weiteren auf das EPHOS-Handbuch der KBSt, Stand 1992, Bezug genommen.

(5) Bei der Datenübermittlung werden die relevanten internationalen, EG-weiten und nationalen Normen und ggf. Standards zur Anwendung gebracht.

2 Teilnahme

(1) Die Einzelheiten zur Durchführung der Datenübermittlung sind rechtzeitig vor der erstmaligen Durchführung oder Änderung zwischen dem Absender und dem Empfänger der Daten abzustimmen.

(2) Durch ein zwischen Absender und Empfänger abgestimmtes Testverfahren vor der erstmaligen Durchführung und vor Änderung des Verfahrens der Datenübermittlung ist die ordnungsgemäße Verarbeitung sicherzustellen.

3 Abwicklung der Datenübermittlung

(1) Die übermittelten Daten müssen den vereinbarten Inhalten und Strukturen entsprechen.

(2) Über die Datenübermittlung ist eine Dokumentation zu führen (siehe 4.2.4 bzw. 4.3.4).

(3) Der Absender hat sicherzustellen, daß nur geprüfte Datensätze übermittelt werden. Der Umfang der Prüfung ist in Abschnitt 6.1 festgelegt.

(4) Der Absender hat die Datenübermittlung innerhalb der vereinbarten Fristen vorzunehmen. Er hat für die Möglichkeit der Rekonstruktion der Daten im Falle eines Dateiverlustes auf dem Transportweg oder einer Dateirückweisung Sorge zu tragen.

(5) Der Empfänger hat die Übernahme der Daten zu bestätigen.

(6) Werden bei oder nach der Übermittlung Mängel festgestellt, die eine ordnungsgemäße Verarbeitung der Daten ganz oder teilweise beeinträchtigen, werden vom Empfänger nur die fehlerfreien Daten weiterverarbeitet. Das Fehlerverfahren ist in Abschnitt 6 geregelt.

(7) Der Absender ist über die festgestellten Mängel unverzüglich zu unterrichten. Dieser ist verpflichtet, seinerseits unverzüglich die zurückgewiesenen Daten zu berichtigen und die korrigierten Daten erneut zu übermitteln. Jede erneute Datenlieferung nach Rückweisung fehlerhafter Daten hat ggf. eine erneute Terminsetzung zur Folge.

(8) Datenträger mit personenbezogenen Daten sind nach der Datenübernahme grundsätzlich zu löschen. Der Volume-Kennsatz muß erhalten bleiben. Magnetbänder und Magnetbandkassetten sind dem Absender zurückzugeben. Damit verbunden ist gleichzeitig die Quittierung der Übernahme der Daten. Für die Zurückweisung fehlerhafter Datenträger oder Dateien gelten besondere Regelungen (siehe Abschnitt 6).

4 Übermittlungsarten

(1) Die für die Übermittlung von Daten verwendeten Medien werden zwischen Absender und Empfänger vereinbart.

(2) Grundsätzlich soll angestrebt werden, die Datenfernübertragung (DFÜ) als Übermittlungsart zu verwenden. Soweit eine Datenfernübertragung aus technischen/wirtschaftlichen Gründen nicht realisiert werden kann, können als Datenträger die Medien nach Abschnitt 4.3 verwendet werden. Einigen sich Absender und Empfänger nicht auf eines dieser Medien, so sind Disketten zu verwenden.

(3) Soweit für die Datenübermittlung anstelle der vorgesehenen Medien andere, besonders vereinbarte, maschinell verwertbare Datenaustauschmedien verwendet werden, müssen diese mindestens die gleiche Datenübermittlungssicherheit bieten und es muß eine maschinelle Weiterverarbeitung mit weitgehend gleicher Qualität durch die Empfänger bei vergleichbarer Wirtschaftlichkeit möglich sein.

(4) Die Kosten für die Datenübermittlung übernimmt der Absender.

4.1 Zeichenvorrat

(1) Der Bezugscode für den Austausch digitaler Daten ist der Code gemäß DIN 66303 - DRV8 (Deutsche Referenzversion des 8-Bit-Code). Dieser Code enthält die Ziffern, die Groß- und Kleinbuchstaben, Sonderzeichen sowie nationale Buchstaben, so daß eine korrekte deutschsprachige Namensschreibung ermöglicht wird.

(2) Soweit und solange die technischen Voraussetzungen eine Verwendung des 8-Bit-Codes nicht unterstützen, kann der Code gemäß DIN 66003 DRV (Deutsche Referenzversion des 7-Bit-Code) verwendet werden.

(3) Der jeweils verwendete Code ist zwischen Absender und Empfänger zu vereinbaren.

4.1.1 Komprimierung

Die Daten können vor der Übermittlung komprimiert werden, wenn Absender und Empfänger dies vereinbaren. Sobald genormte und herstellerunabhängige Komprimierungsverfahren vorhanden sind, sollten diese vorrangig verwendet werden.

4.1.2 Verschlüsselung

- siehe Anhang -

4.1.3 Dateiname

- siehe Anhang -

4.2 Datenfernübertragung

(1) Die Festlegungen zur Regelung der Datenübermittlung sollen dem Referenzmodell für die offene Kommunikation (OSI), ISO 7498, entsprechen. Die transportorientierten Funktionen werden durch die Ebenen 1 bis 4, die anwendungsorientierten Funktionen durch die Ebenen 5 bis 7 abgedeckt.

(2) Die einzelnen Spezifikationen lehnen sich besonders an das "EPHOS-Europäisches Beschaffungshandbuch für offene Systeme" (Phase 1) der KBSt, Stand 1992, an.

(3) Für die Realisierung der anwendungsorientierten Funktionen können "File Transfer, Access and Management" (FTAM) zur Datenübermittlung sowie "Message Handling System" (MHS; X.400 Version 92) als Nachrichtenübermittlungssystem gemäß ISO/OSI verwendet werden.

(4) Für die Realisierung der Transportfunktionen wird als Medium das ISDN der Telekom verwendet. Es können auch andere Medien und Techniken, z. B. DATEX-P, das analoge Fernsprechnetz als Zugang zum nächsten DATEX-P-Knoten oder Standleitungen, vereinbart werden. Die Krankenkassen erklären sich bereit, sofern notwendig bei ihren Datenannahme- und Verteilstellen ein DFÜ-Verfahren gemäß CCITT X.25 vorzuhalten.

(5) Für jedes Transportmedium sind geeignete Mechanismen zur Zugriffskontrolle zu vereinbaren, um den Ansprechpartner zu identifizieren und authentifizieren.

(6) Im Rahmen bilateraler Absprachen ist die Übertragung mittels weiterer Verfahren möglich. In diesen Fällen muß die gleiche Datensicherheit gewährleistet sein wie beim Einsatz der Datenübertragung mittels der nachfolgenden Festlegungen.

4.2.1 Anwendungsorientierte Funktionen

(1) Für die Verwendung anwendungsorientierter Funktionen werden folgende Normen zugrundegelegt, unabhängig von der gewählten Zugriffsart:

OSI-Ebene 7: ISO IS 8571 OSI-FTAM-Standard

ISO IS 8649/8650 Funktionselement für Anwendungen (ACSE)

OSI-Ebenen 5/6 ISO IS 8822/8823 Darstellung

ISO IS 8326/8327 Kommunikationssteuerung

(2) Zur Verwendung des FTAM-Dienstes müssen folgende Normen und Profile beachtet werden:

ENV 41204 Vollständige Übermittlung einfacher Dateien

ENV 41205 Dateiverwaltung

FTAM Typ 3 Unstructured binary files

(3) Zur Verwendung des MHS-Dienstes müssen folgende Normen und Profile beachtet werden:

MHS: CCITT X.400 X.400-Standard
Die Festlegung der Version erfolgt im Rahmen des Sicherheitskonzeptes.

Pedi (P35) CCITT X.435 Übertragung von EDIFACT-Nachrichten

Verbindung ENV 41201 Private Verwaltungsbereiche

Verbindung ENV 41202 Öffentlicher Verwaltungsbereich

4.2.2 Transportorientierte Funktionen

(1) Die ISO-Normen IS 8072/8073 definieren die zu verwendenden Transportdienste und -protokolle.

(2) Als Protokolle für den D-Kanal sind E-DSS1 (Euro-ISDN) und 1 TR6 zu unterstützen. Im B-Kanal wird gemäß der Telekom-Richtlinie 1TR24 das Schicht3-Protokoll ISO 8208 (entspricht X.25 PLP) genutzt.

(3) Der Transport über DATEX-P der Telekom erfolgt nach ENV 41104/41105/CCITT X.25.

4.2.3 Transportsicherung

(1) Die Initiative für den Kommunikationsvorgang übernimmt der Absender.

(2) Der Absender hat sicherzustellen, daß der Kommunikationspartner die für den Empfang der Daten berechtigte Stelle ist. Dies kann über die Vergabe entsprechender Paßworte geschehen.

(3) Einigen sich Absender und Empfänger nicht auf das automatische Recovery gemäß ISO IS 8571 FTAM, gilt für Übertragungsabbrüche, daß die betroffene Datei vom Absender erneut übertragen wird.

(4) Innerhalb des ISDN/DATEX-P wird die Rufnummer des aktiven Partners übergeben und vom passiven Partner geprüft. Deshalb muß die ISDN/DATEX-P-Nummer jedes möglichen aktiven Partners den passiven Partnern gemeldet werden; jede Änderung ist unverzüglich und rechtzeitig im voraus den beteiligten Stellen bekanntzugeben.

4.2.4 Dokumentation

Für die Datenübermittlung ist eine Dokumentation zu führen. Sie ist mindestens bis zum Abschluß des jeweiligen Vorgangs (Bezahlung der Schlußrechnung) vorzuhalten. Die Dokumentation muß die folgenden Mindestinhalte umfassen:

- Inhalt der Datenübermittlung (Dateiname)

- Laufende Nummer der Datenübermittlung

- Eindeutige Bezeichnung der Kommunikationspartner

- Beginn und Ende der Datenübermittlung

- Übermittlungsmedium

- Dateigröße

- Verarbeitungshinweise

. Senden/Empfangen

. Verarbeitungskennzeichen (fehlerfrei/fehlerhaft)

. wenn fehlerhaft: Fehlerstatus aus Übertragungsprogramm

4.3 Datenträgeraustausch

4.3.1 Magnetbänder oder Magnetbandkassetten

(1) Magnetbänder müssen in ihrem Aufbau DIN 66011/ISO 1864 (Beiblatt 1, Teil 2 und Teil 3) entsprechen. Das Aufzeichnungsverfahren hat nach DIN 66282/ISO 5652 zu erfolgen, d. h. mit 9 Spuren im GCR-Verfahren und einer Zeichendichte von 246 Zeichen/mm (= 6250 bpi). Die Daten sind auf dem Band gemäß DIN 66004 - Teil 3 darzustellen.

(2) Als Magnetbandkassetten sind 1/2-Zoll-Kassetten, Bandbreite 12,7 mm mit 18 oder 36 Spuren zu verwenden (entsprechend den derzeit gängigen Typen IBM-3480 und Siemens-3490). Die Aufzeichnungsdichte beträgt 1491 Datenbytes/mm entsprechend DIN ISO 9661. Die Darstellung des 7-Bit- oder des 8-Bit-Codes erfolgt analog zu DIN 66004, Teil 4.

4.3.1.1 Kennsätze und Dateianordnung

(1) Für die Datenübermittlung auf Magnetbändern sind die Kennsätze nach DIN 66029 zu verwenden (VOL 1, HDR 1, HDR 2, EOV 1, EOV 2, EOF 1, EOF 2).

(2) Für die Datenübermittlung auf Magnetbandkassetten sind die Kennsätze nach DIN 66229-A (Ausbaustufe) zu verwenden (VOL 1, HDR 1, HDR 2, ETR 1, STR 1, EOV 1, EOV 2, EOF 1, EOF 2).

4.3.2 Disketten

(1) Disketten müssen DOS-formatiert sein, ohne gefüllten Bootsektor. Andere Formate (z. B. UNIX-tar-Format) können vereinbart werden. Akzeptiert werden 3 1/2 Zoll-Disketten.

(2) Die Daten sind sowohl beim Absender als auch beim Empfänger mittels eines aktuellen Virus-Prüfprogrammes zu prüfen.

4.3.3 Transportsicherung

(1) Die Magnetbänder, Magnetbandkassetten oder Disketten sind mit Etiketten zu versehen, aus denen Name und Adresse sowie das Datenträgerkennzeichen hervorgehen. Unmittelbar nach der Erstellung des Datenträgers ist der Schreibschutz zu aktivieren.

(2) Falls das Transportunternehmen besondere Möglichkeiten zur Transportsicherung bietet, sind diese unter Beachtung des Grundsatzes der Verhältnismäßigkeit zu nutzen, z. B. sollte der Versand mit der Deutschen Bundespost als Wertpaket ohne Wertangabe erfolgen.

4.3.4 Dokumentation

(1) Für den Datenträgeraustausch werden Transportbegleitzettel in Anlehnung an DIN 31632 verwendet. Eine Durchschrift/Kopie des Begleitzettels geht mit getrennter Post an den Empfänger.

(2) Der Transportbegleitzettel muß die folgenden Mindestinhalte umfassen:

- Überschrift: Datenträgerbegleitzettel

- Datenübermittlungsverfahren: § 301

- Absender

- Empfänger

- Inhalt der Datenlieferung

- Lfd. Nummer der übermittelten Datenlieferung/Dateinummer

- Dateinamen

- Art des Datenträgers

- Erstellungsdatum

- Datum, Unterschrift

5 Austauschformate

5.1 Dateibeschreibung

(1) Zur Minimierung des Austauschvolumens wird eine hierarchische Strukturierung in Pakete mit Kopf- und -endesegmenten verwendet. Innerhalb einer Datei können Pakete mehrfach erscheinen.

(2) Die einzelnen Datensatzarten (Nachrichtentypen) werden durch Satzkennzeichen und Versionsnummern gekennzeichnet bzw. unterschieden. Die Nachricht selbst ist in eine definierte Folge von anwendungsbezogenen Segmenten gegliedert, die wiederholbar sein kann und durch ihre Kennung identifiziert werden. Segmente enthalten Datenelemente (Felder). Datenelemente (Felder) und Segmente werden durch vereinbarte Steuerzeichen begrenzt, so daß innerhalb eines Feldes nur signifikante Daten zu übermitteln sind und am Segmentende nicht gefüllte Felder weggelassen werden können.

(3) Zu den Steuerzeichen werden folgende Festlegungen getroffen:

Seg-       Feldbezeichnung       Feld  Feld  Anz.             Bemerkungen              
ment                             -
Ar -Typ
Ste t ll. UNA Festlegungssegment M C 3 'UNA' TZ innerh. Datenelemente M C 1 ':' (Trennkennzeichen innerhalb zu-
sammengesetzter Datenelemente) TZ Datenelemente M C 1 '+' (Trennkennzeichen Datenelemente) Dezimalzeichen M C 1 ',' Aufhebungszeichen M C 1 '?' (für Steuerzeichen) Reserviert M C 1 leer Segmentendezeichen M C 1 '''
(Das Festlegungssegment muß nicht jedesmal übermittelt, sondern kann für einen längeren Zeitraum vereinbart werden.)

Abweichend von allen anderen Segmenten werden im UNA keine Trennzeichen verwendet. Aufbau des UNA-Segmentes:

UNA:+,?b'

Soll eines der hier vereinbarten Steuerzeichen (Doppelpunkt, Plus-Zeichen, Komma, Fragezeichen, Apostroph) innerhalb eines Feldes als Textzeichen übermittelt werden, so muß das Aufhebungszeichen vorangestellt werden. Es gilt jeweils für das unmittelbar nachfolgende Zeichen.

Beispiele:

Für den Patienten Luigi D'Angelo müßten die Felder Nachname und Vorname folgendermaßen übermittelt werden:

D?'Angelo+Luigi+

Das Textfeld Berechnungsgrundlage: Betrag = Honorarsumme + Einzelvergütung sähe wie folgt aus:

Berechnungsgrundlage?: Betrag = Honorarsumme ?+ Einzelvergütung+

5.2 Struktur der Datei

(1) Jede Datei beginnt mit einem "Kopfsegment Datei" (UNB) und endet mit einem "Endesegment Datei" (UNZ).

(2) Alle übermittelten Nachrichten (Datensätze) eines Absenders (Krankenhaus oder Krankenkasse) an einen bestimmten Empfänger werden jeweils pro Nachrichtentyp (z. B. Aufnahmesatz, Rechnungssatz) mit einem "Kopfsegment Absender und Nachrichtentyp" (UNH) eingeleitet und mit einem "Endesegment Absender und Nachrichtentyp" (UNT) beendet. Innerhalb dieser beiden Segmente befinden sich alle Datensegmente eines Nachrichtentyps (Datensatz) des Absenders für einen (mit dem Institutionskennzeichen) bestimmten Empfänger.

(3) "Kopfsegment Absender und Nachrichtentyp", die zugehörigen Datensegmente und das "Endesegment Absender und Nachrichtentyp" bilden ein Paket. Innerhalb einer Datei können Pakete mehrfach erscheinen.

5.2.1 Dateistruktur bei Übermittlung durch das Krankenhaus


UNB
Kopfsegment Datei
UNH Kopfsegment Absender (Krankenhaus) und Nachrichtentyp
FKT Segment Funktion (siehe 7.2.4)
weitere Datensegmente des Nachrichtentyps
UNT Endesegment Absender (KH) und Nachrichtentyp
UNZ Endesegment Datei

Kopfsegment Datei

Seg-       Feldbezeichnung       Feld  Feld  Anz.             Bemerkungen              
ment                             -
Ar -Typ
Ste t ll. UNB Kennung M C 3 'UNB' Syntax
--
M
M
C
N
4
1 'UNOC:2' Syntax-Kennung
-- Syntax-Versionsnummer Absender der Datei M C 9 IK Krankenhaus/Rechenzentrum Empfänger der Datei M C 9 IK Krankenkasse/Rechenzentrum Erstellungstag und
M
M
N
N
6
4 JJMMTT:HHMM Uhrzeit
-- Datum der Erstellung
-- Uhrzeit der Erstellung Dateinummer M C 5 fortlaufende Nummer Freifeld K C 1 leer Dateiname M C 11 siehe 4.1.3
Kopfsegment Absender (Krankenhaus) und Nachrichtentyp
Seg-       Feldbezeichnung       Feld  Feld  Anz.             Bemerkungen              
ment                             -
Ar -Typ
Ste t ll. UNH Kennung M C 3 'UNH' Nachrichtenreferenznummer M C 5 laufende Nummer (innerhalb UNB/UNZ) Nachrichtenkennung --
M


C


4

Beispiel: AUFN:01:000:00 AUFN, Typ

-- Version
-- M
M
C
C
2
3
VERL, MBEG, RECH, ENTL, AMBO oder Freigabenummer
-- M C 2 FEHL
01
000
00 Verwaltende Organisation

Nachrichtentyp: Datensegmente:

AUFN: FKT, INV, NAD, AUF, EAD
oder VERL: FKT, INV, NAD, DAU, FAB
oder MBEG: FKT, INV, NAD, TXT
oder RECH: FKT, INV, NAD, REC, ZLG, FAB, ENT
oder ENTL: FKT, INV, NAD, DAU, ETL, EBG, FAB, RBG
oder AMBO: FKT, INV, NAD, REC, RZA, ENA, EZV
oder FEHL: FHL


Endesegment Absender und Nachrichtentyp

Seg-       Feldbezeichnung       Feld  Feld  Anz.             Bemerkungen              
ment                             -
Ar -Typ
Ste t ll. UNT Kennung M C 3 'UNT' Anzahl Segmente im M N 6 Anzahl der Segmente von UNH bis Nachrichtentyp UNT (einschl. UNH und UNT) Nachrichtenreferenznummer M C 5 wie in UNH

Endesegment Datei
Seg-       Feldbezeichnung       Feld  Feld  Anz.             Bemerkungen              
ment                             -
Ar -Typ
Ste t ll. UNZ Kennung M C 3 'UNZ' Anzahl Nachrichtentypen M N 6 Anzahl der Nachrichtentypen in Datei der Datei Dateinummer M C 5 siehe Kopfsegment Datei

5.2.2 Dateistruktur bei Übermittlung durch die Krankenkasse

UNB Kopfsegment Datei
UNH
Kopfsegment Absender (Krankenkasse) und Nachrichtentyp
FKT Segment Funktion (siehe 7.2.4)
weitere Datensegmente des Nachrichtentyps
UNT Endesegment Absender (Krankenkasse) und Nachrichtentyp
UNZ Endesegment Datei

Kopfsegment Datei

Seg-       Feldbezeichnung       Feld  Feld  Anz.             Bemerkungen              
ment                             -
Ar -Typ
Ste t ll. UNB Kennung M C 3 'UNB' Syntax
--
M
M
C
N
4
1 'UNOC:2' Syntax-Kennung
-- Syntax-Versionsnummer Absender der Datei M C 9 IK Krankenkasse/Rechenzentrum Empfänger der Datei M C 9 IK Krankenhaus/Rechenzentrum Erstellungstag und
M
M
N
N
6
4 JJMMTT:HHMM Uhrzeit
-- Datum der Erstellung
-- Uhrzeit der Erstellung Dateinummer M C 5 fortlaufende Nummer Freifeld K C 1 leer Dateiname M C 11 siehe Festlegungen in 4.1.3

Kopfsegment Absender (Krankenkasse) und Nachrichtentyp
Seg-  Feldbezeichnung            Feld  Feld  Anz.             Bemerkungen              
ment                             -
Ar -Typ
Ste t ll. UNH Kennung M C 3 'UNH' Nachrichtenreferenznummer M C 5 laufende Nummer (innerhalb UNB/UNZ) Nachrichtenkennung --
M


C


4

Beispiel: KOUB:01:000:00 KOUB, Typ

-- Version
-- M
M
C
C
2
3
ANFM, ZAHL, ZAAO oder Freigabenummer
-- M C 3 FEHL
01
000
00 Verwaltende Organisation

Nachrichtentyp: Datensegmente:

KOUB: FKT, INV, NAD, KOS, TXT
oder ANFM: FKT, INV, NAD, TXT
oder ZAHL: FKT, INV, NAD, REC, ZPR, ZLG, ENT
oder ZAAO: FKT, INV, NAD, REC, ZPR, ENA, EZV
oder FEHL: FHL

Endesegment Absender und Nachrichtentyp

Seg-       Feldbezeichnung       Feld  Feld  Anz.             Bemerkungen              
ment                             -
Ar -Typ
Ste t ll. UNT Kennung M C 3 'UNT' Anzahl Segmente im M N 6 Anzahl der Segmente von UNH bis Nachrichtentyp UNT (einschl. UNH und UNT) Nachrichtenreferenznummer M C 5 wie in UNH

Endesegment Datei
Seg-       Feldbezeichnung       Feld  Feld  Anz.             Bemerkungen              
ment                             -
Ar -Typ
Ste t ll. UNZ Kennung M C 3 'UNZ' Anzahl Nachrichtentypen M N 6 Anzahl der Nachrichtentypen in Datei der Datei Dateinummer M C 5 wie in UNB

6 Fehlerverfahren

Um die Datenübermittlung ohne zeitliche Verzögerung durchzuführen, ist bei Fehlern eine sofortige Reaktion erforderlich. Das bedeutet, daß die als fehlerhaft erkannten Daten umgehend zurückgeschickt werden müssen. Dabei ist grundsätzlich das gleiche Medium zu verwenden, auf dem die ursprüngliche Datenlieferung erfolgte (Ausnahme: physische Nichtlesbarkeit eines Datenträgers).

Die per DFÜ oder auf Datenträgern übermittelten Daten werden einer mehrstufigen Prüfung unterzogen.

6.1 Stufe 1 - Prüfung von Datei und Dateistruktur

Dateien werden auf ihre physikalische Lesbarkeit, korrekte Reihenfolge und Syntax der Kopf- und Endesegmente (UNA, UNB, UNH, UNT, UNZ) sowie auf Gültigkeit der Kommunikationspartner geprüft.

Sollte die übermittelte Datei (DFÜ) nicht lesbar sein, so wird eine eigene Fehlerdatei, die als Nachrichtentyp ausschließlich 'FEHL' (mit einem oder mehreren Fehlersegmenten) enthält, erzeugt (Struktur der Datei: UNB, UNH mit Satzkennzeichen FEHL, Datensegment(e) FHL; UNT, UNZ) und an den Absender zurückübermittelt.

Bei Abweisung eines Datenträgers erfolgt die Rückmeldung an den Absender in Papierform mit Angabe des Fehlers und Kopie des Transportbegleitzettels zusammen mit dem nicht lesbaren Datenträger. In diesem Fall wird dieser nicht gelöscht, um dem Absender die Fehleranalyse zu erleichtern.

6.2 Stufe 2 - Prüfung der Syntax

Je Nachrichtentyp wird die Reihenfolge der Segmente geprüft, innerhalb eines Segmentes erfolgen die Prüfungen auf Feldebene in Bezug auf Typ, Länge und Vorkommen (Kann- oder Muß-Feld).

Wenn die Syntax verletzt ist, z. B. bei falschen Segmenten, zu großer Feldlänge oder alphanumerischen Inhalten in numerisch definierten Datenelementen, ist das gesamte Nachrichtenpaket von UNH bis UNT zurückzuweisen.

Es wird dann eine Fehlernachricht als eigenes Datenpaket mit dem Nachrichtentyp `FEHL' (Segmentfolge UNH, FHL, UNT) erzeugt und an den Absender übermittelt.

6.3 Stufe 3 - Formale Prüfung auf Feldinhalte

Die einzelnen Felder eines Segmentes werden auf plausiblen Inhalt geprüft (z. B. Datum, Uhrzeit).

Schlüsselausprägungen müssen korrekt sein im Hinblick auf das Schlüsselverzeichnis (Anlage 2) bzw. auf die Informationsstrukturdaten (IK, ICD, Amtlicher OP-Schlüssel). Weiter finden Kombinationsprüfungen über mehrere Felder statt. Ein als fehlerhaft erkannter Satz wird um Fehlersegmente ergänzt und an den Absender zurückübermittelt.

Kassenartenspezifisch ist zu entscheiden, ob in diesen Fällen außer der Zurückweisung des Satzes zusätzlich eine Information an das Fachverfahren erfolgen soll (Hinweis an den Sachbearbeiter, daß der Absender eine Nachricht mit Fehlersegment(en) zurückübermittelt bekommen hat).

6.4 Stufe 4 - Prüfung in den Fachverfahren der einzelnen Krankenkassen

Die vertrags- und leistungsrechtlichen Prüfungen werden individuell bei den einzelnen Krankenkassen durchgeführt. Für diesen Bereich werden keine kassenartenübergreifenden Regelungen vereinbart. Ein als fehlerhaft erkannter Satz wird um Fehlersegmente ergänzt und an den Absender zurückübermittelt.

7 Korrekturverfahren

7.1 Funktionalität

Das Korrekturverfahren gilt für inhaltlich falsch übermittelte Daten innerhalb der Datenübermittlung zwischen Krankenhäusern und Krankenkassen nach § 301 SGB V. Es berührt nicht das Fehlerverfahren für programmtechnisch festgestellte Fehler, die zu Rückweisungen von einzelnen Nachrichten, Nachrichtenpaketen oder Dateien führen.

Das Korrekturverfahren schafft die DV-technische Voraussetzung, um formal richtige, aber durch Erfassungs- oder Softwarefehler inhaltlich falsche Daten, die auch in Plausibilitätsprüfungen nicht als falsch erkannt werden, zu korrigieren oder zu stornieren. Es dient auch zur nachträglichen Übermittlung inhaltlicher Änderungen.

7.2 Technische Umsetzung

Voraussetzung für die Korrektur bereits übermittelter Daten ist deren eindeutige Identifizierung, d. h. die Zuordnung zum jeweiligen Fall. Darüber hinaus müssen Nachrichten des gleichen Typs zu einem Fall - z. B. mehrere Verlängerungsanzeigen - voneinander unterschieden werden können.

7.2.1 Identifizierende Merkmale

Ein Krankenhausfall ist durch das Institutionskennzeichen des Krankenhauses in FKT und das KH-interne Kennzeichen des Versicherten in INV eindeutig identifiziert. Das KH-interne Kennzeichen muß eine eindeutige Identifizierung des Behandlungsfalles sicherstellen. Das IK des Krankenhauses darf - bezogen auf einen Krankenhaus-Behandlungsfall - nicht geändert werden. Nach einem Fallstorno (siehe 7.3.3) darf das KH-interne Kennzeichen für die Übermittlung an dieselbe Kasse nicht noch einmal verwendet werden, es ist dann ein neues KH-internes Kennzeichen zu vergeben. Werden nach einem Fallstorno aufgrund falscher Kostenträgerzuordnung die Daten an die tatsächlich zuständige Krankenkasse übermittelt, so kann das KH-interne Kennzeichen beibehalten werden.

Zur Steuerung der DV-technischen Korrektur wird das Funktionssegment FKT verwendet, das jede Nachricht einleitet.

7.2.2 Mehrfach vorkommende Nachrichten

Einige Geschäftsvorfälle wie z. B. die Verlängerungsanzeige können innerhalb eines Krankenhausfalles mehrfach vorkommen.

Das Funktionssegment FKT enthält das Feld `Laufende Nummer des Geschäftsvorfalls', das zur Unterscheidung von mehrfach vorkommenden Nachrichten (lückenlos fortlaufend ab `01') verwendet werden kann.

7.2.3 Mehrfachänderungen zu einer Nachricht

Aus technischen Gründen, z. B. weil eine Datei wegen Nichtlesbarkeit zurückgeschickt werden muß, kann es vorkommen, daß übermittelte Nachrichten nicht in der zeitlichen Reihenfolge des Absendens beim Empfänger ankommen bzw. verarbeitet werden. Dies kann auch durch mehrfache Änderungen in kurzem Abstand eintreten.

In solchen Fällen soll bilateral geklärt werden, ob der vom Absender gewünschte Dateninhalt auch tatsächlich als aktueller Stand beim Empfänger vorliegt.

7.2.4 Aufbau des Segments Funktion (FKT)

Seg-       Feldbezeichnung       Feld  Feld  Anz.              Bemerkungen              
ment                             -
Ar -Typ
Ste t ll. FKT Kennung M C 3 'FKT' Verarbeitungskennzeichen M N 2 Schlüssel 9 Laufende Nummer des M N 2 '01', bei mehrfach vorkommenden Geschäftsvorfalls Meldungen: fortlaufend IK des Absenders M N 9 IK des Krankenhauses / der Krankenkasse IK des Empfängers M N 9 IK der Krankenkasse / des Krankenhauses

7.3 Allgemeine Verfahrensregeln

Im Datenübermittlungsverfahren können einzelne Nachrichten korrigiert werden, wobei das Institutionskennzeichen und das KH-interne Kennzeichen des Versicherten als identifizierende Felder nicht geändert werden dürfen (Sicherstellung durch Plausibilitätsprüfungen in den Fachverfahren).

Müssen die identifizierenden Felder geändert werden, ist ein `Fallstorno' erforderlich. Die Fachverfahren haben den Nachweis von Änderungen und Fallstorni zu gewährleisten.

7.3.1 Normalfall

Im Funktionssegment (FKT) ist das Verarbeitungskennzeichen auf `10' zu setzen.

Wenn es sich um mehrfach vorkommende Nachrichten handelt - z. B. Verlängerungsanzeigen zu einem Krankenhausfall -, ist die laufende Nummer im FKT ab 01 lückenlos hochzuzählen.

7.3.2 Änderung

Änderungen werden nachrichtenbezogen durchgeführt. Wurde z. B. bei einer Krankenhausaufnahme die Fachabteilung in dem Aufnahmesatz falsch verschlüsselt, so ist vom Krankenhaus über einen erneuten Aufnahmesatz eine Änderung zu übermitteln. Im Funktionssegment (FKT) ist dann das Verarbeitungskennzeichen auf `20' zu setzen.

Eine automatische Fortschreibung in andere Nachrichten erfolgt nicht. Diese sind ggf. ebenfalls mit dem Verarbeitungskennzeichen `20' zu ändern.

7.3.3 Fallstorno

In folgenden Fällen ist durch das Krankenhaus ein Fallstorno durchzuführen:

Þ KH-internes Kennzeichen des Versicherten falsch

Þ IK des Krankenhauses fehlerhaft

Þ Kostenträgerzuordnung nicht zutreffend

Þ Softwarefehler

Das Fallstorno ist in der ersten Nachricht zu einem Fall (Aufnahmeanzeige oder Rechnungssatz Ambulante Operation) mitzuteilen. Im Funktionssegment (FKT) ist das Verarbeitungskennzeichen auf `30' bis `34' (siehe Schlüssel 9) zu setzen.

Die Fachverfahren der Krankenkassen stellen bei einem Fallstorno sicher, daß alle bisher übermittelten und ggf. noch folgenden Nachrichten zum Fall als ungültig gekennzeichnet werden.

7.3.4 Rechnungsstorno

Rechnungen - auch Zwischenrechnungen und Rechnungen für Ambulante Operationen - dürfen nicht geändert werden.

Änderungen von Datenfeldern in Rechnungen erfordern zunächst ein Rechnungsstorno durch das Krankenhaus über den Schlüssel 11, Rechnungsart `05' (Stornierung). Das Verarbeitungskennzeichen in FKT ist zugleich auf `20' zu setzen (Änderung), die laufende Nummer wird nicht erhöht. Der dann richtig gestellte Rechnungssatz ist mit Verarbeitungskennzeichen `10' (Normalfall) in FKT zu übermitteln, die laufende Nummer wird um 1 erhöht.

7.3.5 Nachtragsrechnung

Wurde bei einer bereits übermittelten Rechnung für einen bestimmten Zeitraum ein Entgelt versehentlich nicht berechnet, so kann dieses über eine Nachtragsrechnung (Schlüssel 11, Rechnungsart `03' / '53') mit dem Verarbeitungskennzeichen `10' (Normalfall) nachträglich übermittelt werden, die laufende Nummer in FKT ist dabei um 1 zu erhöhen.

7.3.6 Gutschrift

Ist eine Gutschrift erforderlich, so wird diese über den Schlüssel 11 (Rechnungsart `04') mit dem Verarbeitungskennzeichen `10' (Normalfall) übermittelt, die laufende Nummer in FKT wird um 1 erhöht.

7.3.7 Fallstorno nach Rechnungsstellung

Die Funktionalität des Datenaustausches nach § 301 SGB V endet mit der Übermittlung des Fallstornos, weil die Verfolgung des bilateralen Geldflusses nur über die hausinterne Buchhaltung möglich ist. Es ist den Fachverfahren überlassen, inwieweit hier programmtechnische Unterstützung geleistet wird.

7.4 Änderungen von Versichertendaten außerhalb des Korrekturverfahrens

Das Korrekturverfahren bezieht sich auf die Änderungen von selbsterzeugten Nachrichten. Die Möglichkeit der Änderung von Versichertendaten wird nicht im Korrekturverfahren geregelt.

7.4.1 Notwendigkeit des Verfahrens

Bei den Versichertendaten in den Segmenten INV und NAD

Þ Krankenversicherten-Nummer

Þ Name des Versicherten

Þ Vorname des Versicherten

Þ Geburtsdatum des Versicherten

ist damit zu rechnen, daß bei einer manuellen Datenerfassung (z. B. bei Nichtvorlage der Krankenversichertenkarte) fehlerhafte Angaben übermittelt werden. Andererseits können Änderungen bei Versichertendaten auftreten, auf die die Krankenkasse noch nicht mit der Ausgabe einer neuen Krankenversichertenkarte reagieren konnte. Es handelt sich hier z. B. um:

Þ Namensänderung infolge Heirat, Scheidung oder auf Antrag

Þ Namensgebung bei Neugeborenen nach stationärer Aufnahme

Þ Änderung des Versichertenstatus bei gleichzeitiger Neuvergabe einer Krankenversichertennummer

7.4.2 Technische Umsetzung

Ist eine eindeutige Identifizierung des Versicherten durch die Krankenkasse erfolgt, reagiert sie mit der Übermittlung ihrer eigenen Versichertendaten an das Krankenhaus in den Segmenten INV und NAD. Im Fachverfahren der Krankenkasse ist sicherzustellen, daß ggf. notwendige Anpassungen der persönlichen Daten des Versicherten nach Prüfung der Sachlage im Mitgliederbestand durchgeführt werden.

Stellt das Krankenhaus aufgrund der Rückmeldung der Krankenkasse fest, daß sich identifizierende Merkmale des Versicherten geändert haben - z. B. Name/Vorname -, so übernimmt das Krankenhaus diese Daten in den folgenden Übermittlungen.

Wenn das Krankenhaus eine falsche Krankenversicherten-Nummer übermittelt hat, die Krankenkasse den Versicherten anhand weiterer Daten im Aufnahmesatz aber trotzdem zuordnen kann, ist nach Empfang des Kostenübernahmesatzes mit der richtigen Krankenversicherten-Nummer die Übermittlung weiterer Nachrichten durch das Krankenhaus mit dieser Nummer durchzuführen.

Bei einer Änderung der Krankenversicherten-Nummer während eines laufenden stationären Aufenthaltes, z. B. durch Änderung des Versichertenstatus von `Mitglied' auf `Familienversicherter' oder umgekehrt ist eine DV- technische Lösung nicht mit angemessenem Aufwand realisierbar. Die ursprünglich übermittelte Krankenversicherten-Nummer wird daher bis zum Abschluß der Behandlung beibehalten. Eine nachträgliche Trennung des Falles (aus Gründen der Kontierung) ist im Fachverfahren der Krankenkassen sicherzustellen.

8 Informationsstrukturdaten

- noch zu erstellen -

9 Datenflüsse

Nach § 4 der Vereinbarung erfolgt die Datenübermittlung durch das Krankenhaus / die Krankenkasse oder die jeweils vom Krankenhaus / von der Krankenkasse benannte Stelle (Entscheidung bei der örtlich zuständigen Kasse).

Die GKV-Spitzenverbände streben kassenartenbezogen die Bildung von zentralen Datenannahme- und - verteilstellen an. Folgende Annahmestellen sind zur Zeit benannt worden:

Ortskrankenkassen: siehe nachfolgende Aufstellung

bei DFÜ: interne Weiterleitung

   IK          Bereich / Annahmestelle               Straße          PLZ         Ort       
            Berlin (Gesamtbereich der AOK       Mehringplatz 15               Berlin       
10951900    Berlin) Rechenzentrum der AOK                           10969                  
5                  Berlin IKT-4-DAV                                                        
                            Ansprechpartner:  Frau Renate Maneke                           
                            Telefon: Fax:     030 / 2531-2219 030                          
                                              / 2531-2146                                  
               Rheinland AOK Rheinland         Machabäerstr. 19 -    50667   Köln          
10421250       Informationsverarbeitung       27                                           
5                                                                                          
                            Ansprechpartner:  Herr Eberhardt 0221                          
                            Telefon: Fax:     / 1618-1767 0221 /                           
                                              1618-1610                                    
           Niedersachsen AOK Rechenzentrum     Hans-Böckler-Allee    30173   Hannover      
10211093            Niedersachsen             30                                           
9                                                                                          
          Technische        Ansprechpartner:  Herr Bierbach 0511                           
          Betreuung         Telefon: Fax:     / 285-4566 0511 /                            
                                              285-4567                                     
          Fachliche         Ansprechpartner:  Herr Gerstmann 0511                          
          Betreuung         Telefon: Fax:     / 883076 0511 /                              
                                              889148                                       
                  Schleswig-Holstein             Woldegker Str. 12                         
98070009    Mecklenburg-Vorpommern Hamburg                          17033   Neubrandenbur  
6          AOK-Rechenzentrum Neubrandenburg                                 g              
                            Ansprechpartner:  Herr Adler 0395 /                            
                            Telefon: Fax:     5587-447 0395 /                              
                                              5587-533                                     
              Saarland AOK Rechenzentrum       Halbergerstr. 1       66121   Saarbrücken   
10931930             Saarbrücken                                                           
9                                                                                          
                            Ansprechpartner:                                               
                            Telefon: Fax:                                                  
                Baden-Württemberg AOK          Schwarzwaldstr. 39    77933   Lahr          
10801800          Rechenzentrum Lahr                                                       
7                                                                                          
                            Ansprechpartner:  Herr Gerold Geisert                          
                            Telefon: Fax:     07821 / 937-264                              
                                              07821 / 937-229                              
              Brandenburg Sachsen-Anhalt        Potsdamer Straße              Teltow       
10069602            AOK-ISC Teltow            20 Lieferanschrift:   14513                  
3                                             Rheinstraße 2a                               
                            Ansprechpartner:  Herr Michael                                 
                            Telefon: Fax:     Thierbach 03328 /                            
                                              45-3026 03328 /                              
                                              45-3125                                      
               Bayern AOK Rechenzentrum        Rudolf-Diesel-Ring    83607   Holzkirchen   
10831040              Oberbayern              23a                                          
0                                                                                          
                            Ansprechpartner:                                               
                            Telefon: Fax:                                                  
           Thüringen AOK Rechenzentrum Suhl    Am Fröhlichen Mann    98528   Suhl          
10619862                                                                                   
6                                                                                          
                            Ansprechpartner:                                               
                            Telefon: Fax:                                                  
            Bremen AOK Bremen/Bremerhaven                                     Bremen       
10311919    Abteilung EDV - Datenannahme -    Bürgermeister-Smidt-  28195   Bremen         
9                                             Str. 95 Postfach      28079                  
                                              107963                                       
                            Ansprechpartner:  Herr Werner                                  
                            Telefon: Fax:     Horstmann 0421 /                             
                            Ansprechpartner:  1761-180 0421 /                              
                            Telefon: Fax:     1761-176 Herr                                
                                              Hermann Reising                              
                                              0421 / 1761-206                              
                                              0421 / 1761-176                              
          Westfalen-Lippe AOK Rechenzentrum     Nortkirchenstr.               Dortmund     
10351011   Westfalen-Lippe Geschäftsbereich   105                   44263                  
6                 Datenverarbeitung                                                        
                            Ansprechpartner:  Herr Ralf Lücke                              
                            Telefon: Fax:     0231 / 41906-54                              
                                              0231 / 41906-59                              
          Rheinland-Pfalz AOK Rechenzentrum    Rizzastr. 11          56068   Koblenz       
10731037               Koblenz                                                             
3                                                                                          
                            Ansprechpartner:                                               
                            Telefon: Fax:                                                  
               Hessen AOK Rechenzentrum        Fünftenweg            35613   Schwalmstadt  
10581061             Schwalmstadt                                                          
5                                                                                          
                            Ansprechpartner:                                               
                            Telefon: Fax:                                                  
          Sachsen AOK Rechenzentrum Dresden    Sternplatz 7          01067   Dresden       
10729900                                                                                   
5                                                                                          
                            Ansprechpartner:                                               
                            Telefon: Fax:                                                  

Betriebskrankenkassen: 1 zentrale Annahmestelle } eine

Innungskrankenkassen: 1 zentrale Annahmestelle } gemeinsame

Bundesknappschaft: 1 zentrale Annahmestelle } Daten-

See-Krankenkasse: 1 zentrale Annahmestelle } annahme-

Landwirtschaftliche Krankenkassen: 1 zentrale Annahmestelle } stelle

Angestellten-Krankenkassen: 1 zentrale Annahmestelle:

debis Systemhaus GmbH

für Datenträgerannahme: Postfach 11 01 20
28081 Bremen

für DFÜ: Telefonnummern werden noch bekanntgegeben

Arbeiter-Ersatzkassen: wie Angestellten-Krankenkassen

10 Testverfahren

Regelungen für ein flächendeckendes Verfahren werden im Rahmen einer zentral koordinierten Pilotphase (Datenaustausch zwischen einigen Krankenhäusern und Krankenkassen) erarbeitet.

11 Anhang zur Technischen Anlage

11.1 Definition der Security Schnittstelle für das Gesundheitswesen

Die folgende Definition einer Security Schnittstelle ist als festgeschriebene, jedoch offengelegte Schnittstelle für das Gesundheitswesen ausgelegt.

Ziel dieser Definitionen ist es, eine Minimalanforderung festzulegen, die durch einen Hersteller erfüllt werden kann, der DFÜ-Applikationen für das Gesundheitswesen anbieten möchte.

Als Basis für die Verschlüsselung soll ein asymmetrisches Verfahren für die Kommunikation eingesetzt werden, das folgenden Ansprüchen genügt:

- Das Verfahren soll auf RSA/DES beruhen.

- Die Schlüsselerzeugung erfolgt dezentral.

- Das Schlüsselmanagement kann zentral über ein Trust-Center oder dezentral über ein bilaterales Verfahren erfolgen.

11.1.1 Vorbemerkungen

Es werden derzeit auf dem Markt verschiedene Verfahren für die Generierung von Sicherheitsfunktionen angeboten. Die seriösen Verfahren haben im allgemeinen gleiche Konstruktionsmerkmale, unterscheiden sich jedoch in Details, die eine Kompatibilität der Verfahren verhindern. ln zunehmendem Maße zeichnet sich ab, daß bestimmte Definitionen im Rahmen der Security-Funktionalitäten mit großer Wahrscheinlichkeit als internationaler Standard anerkannt werden. Die hier getroffenen Festlegungen entsprechen diesen Standards.

Unter der Voraussetzung, daß öffentliche Schlüssel (Public Keys) entsprechend der ASN.1 Syntax und der X.509 Namenskonvention verwendet werden, ergibt sich die Möglichkeit, beim Lesen des Public Key die lnformationen bezüglich der Schlüssellänge des Exponenten und des Signaturalgorithmus zu übergeben. Die lesende lnstanz ist also über den zu verwendenden Parameter informiert und kann entsprechend reagieren. Dies setzt jedoch voraus, daß ein Toolkit verwendet wird, das alle in Frage kommenden Algorithmen und Parameter kennt.

Das SECUDE-Toolkit ist ein solches Werkzeug.

Die umfassende Funktionalität des SECUDE-Toolkits soll jedoch nicht vorausgesetzt werden. Vielmehr ist es Ziel, eine Absprache bezüglich einiger Parameter zu treffen, die für eine Einbindung der Security im Gesundheitswesen einen kleinsten gemeinsamen Nenner darstellt, der geeignet ist, eine auch im Hinblick auf die Zukunft sichere Kommunikation zu gewährleisten.

11.1.2 Detaildefinitionen

Datenformate

Die Datenformate sind entsprechend PEM (1) zu strukturieren. Hier ist ein Stufenplan vorzusehen, der es in der Zukunft ermöglicht, Datenformate entsprechend PKCS#7 (2) zu verwenden.

Derzeit kommen im Gesundheitswesen nur Daten zur Anwendung, die textbasierend sind. Da in der Zukunft nicht ausgeschlossen ist, daß auch binäre lnformationen übertragen werden, soll hier bereits der zukünftige Standard definiert werden.

Die Definitionen unter PKCS#7 umfassen die von PEM, sind daher also als anspruchsvoller zu werten.

Session-Key

Als Session-Key ist DES-CBC (beschrieben in PEM) vorzusehen.

Interchange Key

Als Interchange Key ist RSA mit den unten beschriebenen Parametern einzusetzen.

Hashfunktion/Signaturalgorithmus
Als Hash Funktion ist MD5 (3) vorzusehen.
RSA Schlüssellänge
Die RSA Schlüssellänge soll derzeit 768 Bit betragen (siehe auch RFC 1423 Kap. 4.1.1).

Öffentlicher Exponent des RSA Algorithmus

Als RSA Exponent soll die Fermat-4 Zahl (216+1) gewählt werden (siehe X.509, Annex C).

Public Key Format

Hier ist die ASN. 1 Syntax Notation (4) (wie bei SECUDE (5) definiert) sowie X.509 (6) einzuhalten.

Zertifikate

Zertifikate sind ebenfalls in ASN.1 Syntax Notation (4) (wie bei SECUDE (5) definiert) sowie entsprechend X.509 (6) zu implementieren. Bei der Codierung der Zertifikate sind die Distinguished Encoding Rules (DER) entsprechend X.509, Kapitel 8.7 einzuhalten.

Die Schlüsselverwaltung kann bilateral erfolgen. Bei der Größe des zu betrachtenden Kommunikationsverbundes ist eine Lösung entsprechend X.500 (7) (gegebenenfalls als Stufenkonzept) vorzusehen.

Die unter X.500 vorzuhaltende Namenskonvention lautet:

C = DE

O = Firma

OU1 = KKS-LE

OU2 = IK-Nummer

CN = Ansprechpartner

11.1.3 Abschließende Bemerkungen

Die hier vorliegenden Definitionen stimmen mit den in der Zukunft zu erwartenden Standardisierungen überein und entsprechen andererseits den Definitionen des Teletrust Arbeitskreises, in dem sich eine Reihe von namhaften Herstellern von Security-Funktionen zusammengeschlossen haben.

11.1.4 Grafische Darstellung der Schnittstelle

Datenformate:             PEM, da bisher textbasierend
PKCS#7 (binär) als Stufenkonzept Hash: MD5 RSA Schlüssellänge: 768 RSA Exponent: Fermat-Zahl: (216 + 1) Public Key Format: ASN.1 (wie bei SECUDE)
X.509 Private Key Format: nicht definiert Zertifikate: ASN.1 / X.509

11.1.5 Literaturhinweise

1 RFC 1421 J. Linn. RFC 1421: Privacy Enhancement for Internet

Electronic Mail: Part 1: Message Encryption and Authentication Procedures. February 1993

RFC 1422 S. Kent. RFC 1422: Privacy Enhancement for Internet

Electronic Mail: Part 2: certificate-Based Key Management, February 1993.

RFC 1423 D. Balenson. RFC 1423: Privacy Enhancement for Internet Electronic Mail: Part 3: Algorithms, Modes and Identifiers February 1993.

RFC 1424 B. Kaliski. RFC 1424: Privacy Enhancement for Internet Electronic Mail: Part 4: Key Certification and Related Services. February 1993.

PEM (Privacy Enhancement Mail)

2 PKCS#7 RSA Laboratories. PKCS#7: Cryptographic Message Syntax Standard, Version 1.5, November 1993

3 RFC1321 R. Rivest. RFC 1321; The MD5 Message Digest Algorithm

4 ASN.1 X.208 CClTT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988

X.209 CClTT Recommendation X.209: Specification of basic encoding rules for Abstract Syntax Notation One (ASN.1), 1988

5 SECUDE SECUDE 4,4 GMD lnstitut für TeleKooperationstechnik

Darmstadt, Germany, Oktober 1994

6 X.509 CClTT. Recommendation X.509: The Directory-Authentication Framework. 1988.

7 X.500 CClTT. Recommendation X.500: The Directory Overview and Concepts, Models and Services. 1988.

Anmerkung

Die hier angeführte Literatur ist größtenteils über das Internet verfügbar.

11.2 Struktur der Übertragungsdateien

11.2.1 Voraussetzungen und Forderungen

Im Datenaustausch per DFÜ und über Datenträger sind zwischen zwei Partnern Nutzdatendateien auszutauschen. Dabei kann je nach Übertragungsweg eine oder mehrere Stellen als Vermittlungsstellen fungieren. Unabhängig von der Art der Daten soll dabei in der Dateistruktur die für die Vermittlungsstellen notwendige Information enthalten sein, die es erlaubt, Nutzdaten, ohne Untersuchung der Nutzdateninhalte, zuzustellen.

Diese Struktur soll erlauben,

· mehrere Nutzdatendateien (auch für unterschiedliche Adressaten) pro Datenträger zu übertragen.

· eine Nutzdatendatei über mehrere physikalische Datenträger zu verteilen.

· das bestehende KKS-Verfahren leicht in das neue Verfahren zu integrieren.

· Daten von zwischenverarbeitenden Stellen (Übertragungseinrichtung wie z. B. Debis oder AOK-RZ) entgegenzunehmen und an den Absender weiterzuverteilen. Dabei ist für die zwischenverarbeitende Stelle festzulegen, wie die Verteilung zu geschehen hat (Routing). Je nach eingesetztem Verfahren (festgelegt durch die Nutzdaten: z. B. DÜVO) sollte dabei ein unterschiedliches Routing möglich sein. Für die zwischenverarbeitende Stelle ist es nicht möglich, weitere Informationen aus den Nutzdaten zu erhalten (Verschlüsselung).

· Nutzdatendateien eines beliebigen Binärformates zu übertragen. Diese Forderung ist notwendig, da Nutzdaten je nach Anforderung verschlüsselt zu übertragen sind.

· flexibel und für weitere Anforderungen erweiterbar zu sein.

· dieselbe Struktur möglichst auch als internes Format innerhalb einer Organisation zur Weiterverteilung an die verarbeitenden Systeme zu nutzen. So ist z. B. denkbar, daß ein Vorschaltrechner genutzt wird, um den Inhalt der Nutzdatendateien zu entschlüsseln und anschließend dieselbe Struktur zur Weiterverarbeitung im LAN weiterzugeben.

Um diese Dateistruktur möglichst auf allen Hardware- und Software-Systemen lesen zu können, soll dabei der Auftragssatz in fixer Satzlänge erstellt werden.

Damit das Verfahren übergreifend für möglichst alle Anwendungsarten genutzt werden kann, sollen die verwendeten Adreßfelder ausreichend groß bemessen werden, um in allen Verfahren benutzt werden zu können (zur Zeit IK oder Betriebsnummer).

11.2.2 Verfahrensbeschreibung

11.2.2.1 Übertragung der Auftragsdatei und der Nutzdatendatei

Zu jeder Nutzdatendatei muß für die Übertragung die nachfolgend definierte Auftragsdatei generiert werden, die z. B. für das Routing benutzt wird.

Die Übertragung jeder Nutzdatendatei erfolgt als separate Datei. Vor der Übertragung einer Nutzdatendatei wird die dazugehörige Auftragsdatei übertragen.

Übertragung per DFÜ

Im Rahmen einer DFÜ-Verbindung wird zunächst die Auftragsdatei und hiernach die Nutzdatendatei übermittelt.

Ein Übertragungsvorgang besteht aus der Übertragung dieser zwei Dateien in der festgelegten Reihenfolge.

Übertragung per Datenträger

Magnetband/Magnetbandkassette:

Die Datenübertragung mittels dieser Datenträger kann mehrere Nutzdatendateien beinhalten, jedoch jeweils versehen mit der zugehörigen Auftragsdatei in der festgelegten Reihenfolge.

Im jeweiligen Datei-Anfangskennsatz (HDR1) ist in dem Feld "Dateiname” der Transferdateiname (Festlegung siehe unten) einzutragen.

Diskette:

Die Datenübermittlung per Diskette kann mehrere Nutzdatendateien beinhalten, jedoch jeweils versehen mit der zugehörigen Auftragsdatei in der festgelegten Reihenfolge.

Festlegung der Dateinamen

Auf der Seite des Absenders besteht der Transferdateiname aus der Dateitypbezeichnung (Feld VERFAHREN_KENNUNG) und einer laufenden Nummer (Feld TRANSFER_NUMMER).

Der Name der zugehörigen Auftragsdatei besteht aus dem vorstehend beschriebenen Transferdateinamen mit dem Zusatz `.AUF'.

Bild:

Auftragsdatei 1 | Nutzdatendatei 1 | Auftragsdatei 2 | Nutzdatendatei 2 |

z. B.:

DATP1007.AUF| DATP1007 | DATP1008.AUF | DATP1008 |

11.2.2.2 Format der Auftragsdatei

Nachfolgend ist das Format der Auftragsdatei beschrieben, die den Auftragssatz beinhaltet.

Der Auftragssatz ist nur aus logischen Gründen in mehrere Tabellen (Objekte) aufgeteilt worden. Physikalisch handelt es sich um einen zusammenhängenden Satz. Alle Objekte müssen vorhanden sein.

Die Abkürzungen in den Spalten haben folgende Bedeutung:

Nutzungtypen:

· R: Routing-Informationen

· L: Logging- und Statusinformationen

· K: Information für KKS-Verfahren

· D: Datenträgerspezifische Informationen

· I: Interne Nutzung

· A: Allgemeine Informationen

· S: Informationen zur Verschlüsselung

Feldtypen:

· N: Numerisch (0-9)
Rechtsbündig mit führenden Nullen.

· A: Alpha

· AN: Alphanumerisch
Linksbündig mit Leerzeichen aufgefülllt

Feldarten:

· M: Muß versorgt werden

· K: Kann versorgt werden

1. Teil "Allgemeine Beschreibung der Krankenkassen-Kommunikation”

Bezeichnung       Stellen   Länge  Nutzu  Feldty  Feldar  Beschreibung                        
                                   ngsty  p       t                                           
                                     p                                                        
IDENTIFIKATOR     01 - 06   6        A    N       M       Identifikator des Objektes          
                                                          "Krankenkassen-Kommunikation”.
Kon stante `500000'. Für die Kompatibiltät mit Objektstruktur der DATEV. VERSION 07 - 08 2 A N M Version der Dateistruktur.
`01': erste Version des Verfahrens. Für die Kompatibiltät mit Objektstruktur der DATEV. LÄNGE_AUFTRAG 08 - 15 8 A N M Länge der Auftragsdatei in Bytes (Objekt "Krankenkassen-Kommunikation”). SEQUENZ_NR 16 - 18 3 A N M Laufende Transfernummer. Gibt die Sequenznummer der Datei an, sofern eine Nachricht auf mehrere Datenträger oder physikalische Dateien bei DFÜ verteilt werden muß.
`000' Nachricht ist komplett vorhanden `001' erster Teil der Nachricht.
n n-ter Teil der Nachricht. '999' Letzter Teil der Nachricht.
Es folgt keine Nachricht mehr. VERFAHREN
_KENNU 19 - 23 5 R AN M Kennung des Verfahrens: `DUEVJ': NG
(Dateityp) DÜVO jährlich .... wie im KKS-Verfahren als Dateitypkurzbeichnung unter `Bezeichnung der Anwendungsdateien' festgelegt....
`DATP1': Datenaustausch TP1 `DATP2': Datenaustausch TP2 `DATP3': Datenaustausch TP3 `DATP4': Datenaustausch TP4 `DATP5': Datenaustausch TP5 TRANSFER
_NUMMER 24 - 26 3 A N M Laufende Transfernummer bei der Übertragung zwischen zwei direkt verbundenen Kommunikationspartnern. Gemäß KKS-Verfahren.
Stellt sicher, daß die Namen der Dateien bei der Übertragung zwischen zwei unmittelbaren Kommunikationspartnern eindeutig sind.
Dazu wird der Dateiname aus VERFAHRENS_KENNUNG und der TRANSFERNUMMER erzeugt. VERFAHREN
_KENNU 27 - 31 5 R AN K Weitere Spezifikation des NG
_SPEZIFIKATIO Verfahrens innerhalb des in N
VERFAHREN_KENNUNG festgelegten Verfahrens. Die Werte werden eindeutig pro Verfahren (bei Datenaustausch z. B. der Nachrichtentyp, sofern eindeutig pro Lieferung) festgelegt. Damit ist pro Verfahren eine weitere Unterscheidung der Nachrichtenart möglich.
Dieses Feld wird derzeit beim Datenaustausch mit Arbeitgebern nicht benutzt. Dieses Feld kann benutzt werden, um die Verarbeitungspriorität auszudrücken. ABSENDER
_EIGNER 32 - 46 15 R AN M Absendender Eigner der Nutzdaten.
Identifikation des Absenders.
(IK: 9 Stellen, Betriebsnummer: 9 Stellen) Der Eigner ist für die Korrektheit der Daten verantwortlich und nimmt die Verschlüsselung vor. ABSENDER
_PHYSIK 47 - 61 15 R AN M Tatsächlicher physikalische ALISCH Absender der Nutzdaten.
Z. B. Abrechnungsrechenzentrum oder Vermittlungsstelle. EMPFÄNGER
_NUTZE 62 - 76 15 R AN M Empfänger, der die Daten nutzen R soll. Dieser Empfänger ist in Besitz des Schlüssels, um verschlüsselte Informationen zu entschlüsseln. EMPFÄNGER
_PHYSI 77 - 91 15 R AN M Empfänger, der Daten physikalisch KALISCH empfangen soll. FEHLER
_NUMMER 92 - 97 6 R N M Fehler-Nr. laut Fehlerkatalog bei Rücksendungen von Dateien.
`000000': kein Fehler
Für das noch festzulegende Fehlerverfahren ist bei fehlerhaften Dateilieferungen oder sonstigen Fehlern anzugeben, um welchen Fehler es sich handelt. Der Empfänger oder die zu übermittelnde Stelle kann fehlerhafte Lieferungen ohne Änderung des Dateninhaltes mit einer Fehler-Nr. zurücksenden. Analog kann die Fehler-Nr genutzt werden, damit der physikalische Empfänger dem physikalischen Absender Fehler von zurückgesendeten Dateien anzeigt. Der Fehlerkatalog ist entsprechend festzulegen. FEHLER
_MAßNAHME 98 - 103 6 R N M Durchzuführende Maßnahme laut Fehlerkatalog. `000000': keine Maßnahme erforderlich Siehe Feld FEHLER_NUMMER. Gemäß dem Fehlerverfahren festzulegen.
Kommentar:

- ABSENDER_EIGNER gibt die verantwortliche Stelle für die Daten an, die mit dem ABSENDER_PHYSIKALISCH übereinstimmen kann.
- ABSENDER_EIGNER verschlüsselt die Nutzdaten.
- EMPFÄNGER_NUTZER ist die Stelle, die die Daten zur Auswertung verwendet und kann mit EMPFÄNGER_PHYSIKALISCH übereinstimmen.
- EMPFÄNGER_NUTZER entschlüsselt die Nutzdaten.

Bezeichnung       Stellen   Länge   Nutzu  Feldty  Feldar  Beschreibung                       
                                    ngsty  p       t                                          
                                      p                                                       
DATEINAME         104 -     11        A    AN      M       Der vom Anwendungssystem           
                  114                                      vergebene Dateiname.               
DATUM
_ERSTELLUN 115 - 14 L N M Erstellungsdatum der Datei aus G 128 der Anwendung. Format JJJJMMTTssmm (Jahr, Monat, Tag, Stunde, Minute). DATUM
_ÜBERTRAGU 129 - 14 L N K Start der Übermittlung der NG _GESENDET 142 Datei. Format JJJJMMTTssmmss (Jahr, Monat, Tag, Stunde, Minute, Sekunde). Diese Zeit kann als Logging-Information oder auch für Wiederaufsatzverfahren zwischen zwei Partnern genutzt werden.
Muß vom Absender ausgefüllt werden. DATUM
_ÜBERTRAGU 143 - 14 L N K Start des Empfangs der Datei. NG
_EMPFANGEN
_S 156 Format JJJJMMTTssmmss (Jahr, TART Monat, Tag, Stunde, Minute, Sekunde). Wird vom Empfänger ausgefüllt. DATUM
_ÜBERTRAGU 157 - 14 L N K Ende der Empfangsübertragung der NG
_EMPFANGEN
_E 170 Datei. Format JJJJMMTTssmmss NDE (Jahr, Monat, Tag, Stunde, Minute, Sekunde).
Wird vom Empfänger ausgefüllt. DATEIVERSION 171 - 6 A N M Versionsnummer der Datei. 176 KORREKTUR 177 1 A N M Ist bereits eine Datei mit derselben Dateiversion verschickt worden? `0': Nein `1': Dies ist die Korrekturdatei. Die bereits erhaltene Datei kann gelöscht werden. DATEIGRÖßE
_NUTZ 178 - 12 A N M Dateigröße der Anwendungsdatei DATEN 189 in Bytes
(unverschlüsselt und unkomprimiert). DATEIGRÖßE
_ÜBER 190 - 12 A N M Dateigröße der übertragenen TRAGUNG 201 Anwendungsdatei in Bytes (Länge bei eventueller Verschlüsselung und Komprimierung). ZEICHENSATZ 202 - 2 A AN M `I7': ASCII 7-Bit,
Code gemäß 203 DIN 66003 DRV (Deutsche Referenzversion) `I8': ASCII 8-Bit,
Code gemäß DIN 66303 DRV8 `EB': EBCDIC KOMPRIMIERUNG 204 - 2 A N M `00' keine `02' für LE-Verfahren 205 aufgrund der
TeleTrust-Definitionen VERSCHLÜSSELUNGS 206 - 2 A N M `00' keine `02' für LE-Verfahren ART 207 im PEM-Format ELEKTRONSICHE 208 - 2 A N M `00' keine `02' für UNTERSCHRIFT 209 LE-Verfahren im PEM-Format
2. Teil "Spezifische Information zur Bandverarbeitung”

Bezeichnung       Stellen   Länge   Nutzu  Feldty  Feldar  Beschreibung                       
                                    ngsty  p       t                                          
                                      p                                                       
SATZFORMAT        210 -     3         D    A       M       Satzformat der Datei auf dem       
                  212                                      Datenträger: F=FIX, V=Variabel,    
                                                           U=Undefiniert, FB=FIX_geblockt,    
                                                           FBA=FIX_geblockt_, VB=Variabel     
                                                           geblockt, ...                      
SATZLÄNGE         213 -     5         D    N       M       Satzlänge bei fixem Satzformat.    
                  217                                                                         
BLOCKLÄNGE        218 -     8         D    N       M       Blockänge in Bytes, sofern         
                  225                                      geblockt.                          

3. Teil "Spezifische Informationen für das KKS-Verfahren”

Spezifische Informationen zur Verarbeitung mit dem KKS-Verfahren (Kommentare siehe KKS-Verfahren, Felder müssen vom Absender nicht ausgefüllt werden):

Bezeichnung       Stellen   Länge   Nutzu  Feldty  Feldar  Beschreibung                       
                                    ngsty  p       t                                          
                                      p                                                       
Status            226       1         K    N       K       Bei Anlieferung durch das          
                                                           Abrechnungssystem:                    
                                                           Leerzeichen
Verarbeitungskennzeic hnung (Anwendung, FTAM): 0 Einstellung in Ordnung
1 Ändern
2 Suspendieren
3 Löschen
4 Übertragen
5 Transferphase
6 keine Verbindung
7 fehlerhafter Transfer
8 Statusabfrage Wiederholung 227 - 2 K N K Hier wird die maximale Anzahl 228 der Übertragungswiederholungen bei fehlerhaften Übertragungen angegeben. Wenn der angegebene Zähler überschritten wird oder ein nicht-behebarer Fehler beim Übertragungsversuch aufgetreten ist, wird der Auftrag als nicht durchführbar mit einem Diagnosecode gekennzeichnet. Übertragungsweg 229 1 K N K Mögliche Wege sind: 1 X.25 2 ISDN 3 ISDN, bei Übertragungsproblemen
erneuter Versuch über X.25 4 X.25, bei Übertragungsproblemen
erneuter Versuch über ISDN
5 anderer Weg Verzögerter 230 - 10 K N K Hier wird der Zeitpunkt Versand 239 eingetragen, zu dem der Auftrag ausgeführt werden soll. Wird das Feld nicht vom Abrechnungssystem gefüllt oder ist der angegebene Ausführungszeitpunkt bereits überschritten, wird der Auftrag vom KKS zum nächstmöglichen Zeitpunkt ausgeführt. Format JJMMTTSSmm (Jahr, Monat, Tag, Stunde und Minute). Info und 240 - 6 K N K Fehlernummer aus FTAM. Bei Fehlerfelder 245 erfolgreich ausgeführten Aufträgen ist das Feld leer. Variables 246 - 28 K AN K Klartextfehlermeldung. Bei Info-Feld 273 erfolgreich ausgeführten Aufträgen ist das Feld leer.

4. Teil "Spezifische Information zur Verarbeitung innerhalb eines RZ”

Spezifische Informationen zur Verarbeitung innerhalb eines Rechenzentrums (Felder müssen vom Absender nicht ausgefüllt werden):

Bezeichnung       Stellen   Länge   Nutzu  Feldty  Feldar  Beschreibung                       
                                    ngsty  p       t                                          
                                      p                                                       
DATEINAME
_PHYSI 274 - 44 I AN K Verarbeitungsinterner physischer KALISCH 317 Dateiname DATEI 318 - 30 I AN K Variabler Bereich, um _BEZEICHNUNG 347 Zusatzinformationen zur Datei bereitzustellen.

5. Teil "Spezifische Information zur Verschlüsselung”

Die Informationen für die Verschlüsselung (DES-Session-Key, ...) werden gemäß der Definition der Security-Schnittstelle für das Gesundheitswesen in den dafür definierten Feldern in der Nutzdatendatei festgelegt.