780 lines
68 KiB
Markdown
780 lines
68 KiB
Markdown
# Fachliche Anforderungen
|
||
|
||
> **Dokumentversion:** v4
|
||
> **Stand:** 08.04.2026
|
||
> **Status:** verbindlicher fachlicher Soll-Rahmen für Version 1
|
||
> **Projekt:** ASV-Format-Validator
|
||
> **Bezugsspezifikation:** Technische Anlage ASV (Vertragsärztliche Abrechnung), Version 1.09, Stand 09.10.2025, anzuwenden ab Leistungserbringungsquartal 2/2026
|
||
> **Begleitdokument:** `technik-und-architektur.md` v5
|
||
|
||
## 1. Zweck und Rolle dieses Dokuments
|
||
|
||
Dieses Dokument beschreibt die **verbindlichen fachlichen Anforderungen für Version 1** des Projekts **ASV-Format-Validator**.
|
||
|
||
Es ergänzt das technische Dokument `technik-und-architektur.md` um die **fachlich-normative Sicht**, die für die Ableitung von **Meilensteinen**, **Arbeitspaketen** und anschließender **Implementierung** erforderlich ist.
|
||
|
||
Dieses Dokument ist für die Nutzung durch **Mensch und KI** geschrieben. Deshalb werden Regeln:
|
||
|
||
- **präzise**
|
||
- **eindeutig**
|
||
- **quellenbezogen**
|
||
- **ohne stille Annahmen**
|
||
- **möglichst feldgenau**
|
||
- **mit offizieller Fehlercode-Zuordnung, soweit eindeutig möglich**
|
||
|
||
formuliert.
|
||
|
||
## 2. Normative Grundlagen und Rangfolge
|
||
|
||
### 2.1 Primärquelle
|
||
|
||
Maßgebliche fachliche Wahrheit ist ausschließlich die **Technische Anlage ASV 1.09**.
|
||
|
||
### 2.2 Sekundärquelle
|
||
|
||
Das Dokument `technik-und-architektur.md` ist der bereits festgelegte **technische Soll-Rahmen** für Version 1.
|
||
Es darf die Spezifikation **nicht abschwächen** oder **umdefinieren**.
|
||
|
||
### 2.3 Rangfolge
|
||
|
||
Bei Spannungen gilt immer folgende Reihenfolge:
|
||
|
||
1. **Technische Anlage ASV 1.09**
|
||
2. **dieses Dokument**
|
||
3. **technik-und-architektur.md**
|
||
|
||
### 2.4 Geltungsbereich von Version 1
|
||
|
||
Version 1 ist **fachlich verbindlich** auf genau diese Zielversion ausgerichtet:
|
||
|
||
- **Technische Anlage 1.09**
|
||
- **Stand 09.10.2025**
|
||
- **anzuwenden ab Leistungserbringungsquartal 2/2026**
|
||
|
||
Mehrversionssupport ist **nicht** Gegenstand dieses Dokuments.
|
||
|
||
## 3. Leitprinzipien der fachlichen Modellierung
|
||
|
||
### 3.1 Grundsatz
|
||
|
||
Der Validator soll **so viel wie fachlich belastbar prüfbar** prüfen und **so hilfreich wie möglich** ausgeben.
|
||
|
||
### 3.2 Keine Verharmlosung
|
||
|
||
Alles, was der Spezifikation **belastbar widerspricht**, ist als **Verstoß** zu behandeln.
|
||
|
||
### 3.3 Saubere Abgrenzung der Aussagekraft
|
||
|
||
Es ist strikt zu unterscheiden zwischen:
|
||
|
||
1. **harter fachlicher Muss-Vorgabe laut Spezifikation**
|
||
2. **V1-verbindlicher fachlicher Umsetzungsentscheidung**
|
||
3. **fachlich existierender Regel, die ohne Referenzbestände oder Verfahrenskontext nicht belastbar entscheidbar ist**
|
||
|
||
### 3.4 Keine stillen Annahmen
|
||
|
||
Wo die Spezifikation etwas nicht ausdrücklich festlegt, darf dies nicht stillschweigend „ergänzt“ werden.
|
||
Interpretative V1-Entscheidungen sind explizit zu markieren.
|
||
|
||
## 4. Begriffe, Regelarten und V1-Entscheidungskategorien
|
||
|
||
## 4.1 Muss- und Kann-Logik
|
||
|
||
### Muss-Feld
|
||
|
||
Ein Muss-Feld ist immer zu liefern, sofern die betreffende Strukturvariante vorliegt.
|
||
|
||
### Kann-Feld
|
||
|
||
Ein Kann-Feld ist:
|
||
|
||
- bei ausdrücklich genannter Bedingung: **zwingend zu liefern, wenn die Bedingung erfüllt ist**
|
||
- ohne ausdrücklich genannte Bedingung: **zu liefern, wenn die erforderliche Information dem Absender vorliegt**
|
||
|
||
### Vertraglich bedingte Felder
|
||
|
||
Felder mit Hinweisen wie **„wird erst geliefert, wenn vertraglich vereinbart“** sind fachlich existent, aber in Version 1 **nicht als generell hart verpflichtend** zu erzwingen, sofern kein Vertragskontext vorliegt.
|
||
|
||
## 4.2 V1-Entscheidungskategorien
|
||
|
||
Jeder Regeleintrag wird genau einer V1-Kategorie zugeordnet:
|
||
|
||
| Kategorie | Bedeutung |
|
||
|---|---|
|
||
| **V1-V** | verbindlich in Version 1 zu prüfen |
|
||
| **V1-T** | in Version 1 nur teilweise bzw. lokal prüfbar |
|
||
| **V1-N** | fachlich existent, aber in Version 1 bewusst nicht belastbar prüfbar |
|
||
| **V1-K** | konventionsbasiert: nicht direkt aus der ASV-Spezifikation ableitbar, sondern aus angrenzenden GKV-/KKS-/EDIFACT-Standards übernommen; für V1 verbindlich, aber bei Spec-Konflikt nachrangig |
|
||
|
||
### Kennzeichnung konventionsbasierter Regeln
|
||
|
||
Wo eine Regel nicht direkt aus dem Wortlaut der Technischen Anlage ASV 1.09 ableitbar ist, sondern aus angrenzenden Standards (KKS-Auftragssatzformat, EDIFACT-Service-Sätze, KBV-Fehlerkatalog, ICD-10-GM-Diagnosesicherheiten, GKV-Verwaltungsorganisation), wird dies in der Quellenspalte mit dem Präfix **„Konvention:"** kenntlich gemacht. Solche Regeln dürfen einer eindeutigen Spec-Aussage **niemals widersprechen**.
|
||
|
||
## 4.3 Interne Regel-ID
|
||
|
||
Jede Regel erhält zusätzlich zu Feld-ID, Quellenreferenz und Fehlercode eine **stabile interne Regel-ID**.
|
||
|
||
Schema:
|
||
|
||
`R-<BEREICH>-<FELD_ODER_THEMA>-<NNN>`
|
||
|
||
Beispiele:
|
||
|
||
- `R-UNB-0020-001`
|
||
- `R-REA-7.2.1-001`
|
||
- `R-FHL-2.6-001`
|
||
- `R-CROSS-REA-LEA-SAC-001`
|
||
|
||
Diese IDs sind für spätere Arbeitspakete, Reviews und Nachbesserungen verbindlich referenzierbar.
|
||
|
||
## 4.4 Fehlercode-Darstellung
|
||
|
||
Wo die Spezifikation einen offiziellen Fehlercode eindeutig zuordenbar vorgibt, wird dieser mitgeführt:
|
||
|
||
- **Fehlercode**
|
||
- **deutsche Klarbeschreibung**
|
||
- **Prüfstufe**
|
||
- **fachliche Bedeutung**
|
||
|
||
Wo kein eindeutiger offizieller Fehlercode zuordenbar ist, wird dies ausdrücklich vermerkt:
|
||
|
||
**„kein eindeutiger offizieller Fehlercode in der Spezifikation zuordenbar“**
|
||
|
||
## 5. Fachliches Zielbild von Version 1
|
||
|
||
Version 1 soll fachlich in der Lage sein, lokal vorliegende ASV-Artefakte so zu validieren, dass aus dem Ergebnis unmittelbar ableitbar ist:
|
||
|
||
- welche Artefaktart vorliegt
|
||
- welche fachliche Strukturvariante vorliegt
|
||
- welche Regeln belastbar eingehalten sind
|
||
- welche Regeln belastbar verletzt sind
|
||
- welche Regeln fachlich existieren, aber lokal nicht belastbar geprüft werden können
|
||
- welche offiziellen Fehlercodes der Spezifikation einschlägig sind
|
||
- welche Besonderheiten, Ausnahmen oder Sonderfälle vorliegen
|
||
|
||
## 5.1 Globale fachliche Rahmenregeln
|
||
|
||
Diese Regeln gelten **artefaktübergreifend** und sind unabhängig davon zu prüfen, ob ein KKS-Auftragssatz oder eine Nutzdatendatei vorliegt:
|
||
|
||
| Regel-ID | Quelle | Regel | V1 | Fehlercode |
|
||
|---|---|---|---|---|
|
||
| `R-GLOBAL-ZEICHENSATZ-001` | Allgemeines, „Für das Verfahren ist der Zeichencode ISO 8859-15 festgelegt" | Sämtliche ASV-Artefakte sind grundsätzlich als ISO 8859-15 (Level C, 8 Bit) zu interpretieren. Eine stillschweigende UTF-8- oder Plattform-Default-Dekodierung ist unzulässig. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-GLOBAL-ZEICHENSATZ-002` | Allgemeines | Es sind ausschließlich darstellbare Zeichen des ISO-8859-15-Codes zu verwenden. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-GLOBAL-UNKOMPRIMIERT-001` | Grundsätze Datenübermittlung | ASV-Dateien werden unkomprimiert übertragen. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-GLOBAL-EINE-KASSE-001` | Grundsätze Datenübermittlung | Pro Kasse (unterschiedliches Abrechnungs-IK) wird genau eine Datei erstellt; eine Bündelung mehrerer Kassen in einer Datei ist unzulässig. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-GLOBAL-SORTIERUNG-001` | Hinweis zur Nachrichtenstruktur | Die Sortierreihenfolge der Nachrichten innerhalb einer Datei ist gemäß Spezifikation willkürlich. V1 darf keine Sortierregel erzwingen. | V1-V | kein offizieller Fehlercode, da kein Verstoß bei beliebiger Reihenfolge |
|
||
|
||
## 6. Fachlich relevante Eingabeartefakte und Nachrichtentypen
|
||
|
||
Version 1 muss fachlich mindestens folgende Artefakte bzw. Nachrichtentypen unterscheiden:
|
||
|
||
1. **KKS-Auftragsdatei / AUF**
|
||
2. **ASV-Nutzdatendatei**
|
||
3. **ASVREC** (Abrechnung)
|
||
4. **ASVFEH** (Fehlernachricht)
|
||
5. **Storno** als spezielle Strukturvariante von `ASVREC`
|
||
|
||
## 6.1 Fachliche Abgrenzung ASVREC / ASVFEH / Storno
|
||
|
||
### ASVREC
|
||
|
||
Fachliche Abrechnungsnachricht eines Falls.
|
||
|
||
### ASVFEH
|
||
|
||
Fachliche Fehlerrückmeldung zu einer ursprünglichen Übermittlung.
|
||
Sie bildet **keine Rechnung**, sondern eine Fehlerkommunikation.
|
||
|
||
### Storno
|
||
|
||
Storno ist **keine eigene Nachrichtentypkennung**, sondern eine **fachliche Sonderausprägung einer ASVREC-Nachricht** mit:
|
||
|
||
- Rechnungskennzeichen = Storno (`REA 7.2.4 = 1`)
|
||
- reduzierter Segmentstruktur (nur Muss-Segmente und Muss-Felder)
|
||
- ursprünglicher Rechnungsnummer als Bezug zur stornierten Nachricht
|
||
- Rechnungsbetrag gemäß `REA 7.2.1` bei Storno `0,00`
|
||
|
||
## 7. Fachliche Prüfstufen 0 bis 4
|
||
|
||
## 7.1 Überblick
|
||
|
||
| Prüfstufe | Fachliche Bedeutung laut Spezifikation | Relevanz für V1 |
|
||
|---|---|---|
|
||
| **0** | physikalische Lesbarkeit / Entschlüsselbarkeit | fachlich relevant, lokal nur artefaktbezogen prüfbar |
|
||
| **1** | Datei- und Service-Segment-Struktur, Kommunikationspartner, Referenzgleichheiten | in V1 weitgehend für lokale Struktur, nur teilweise für Partnerprüfungen |
|
||
| **2** | Syntax der Nutzdatenstrukturen | in V1 verbindlich für lokal prüfbare Struktur- und Feldsyntax |
|
||
| **3** | formale Feldinhalte und Schlüssel-/Bestandsbezug | in V1 nur formal bzw. teilweise |
|
||
| **4** | Fachverfahren der Krankenkassen | fachlich existent, in V1 nicht belastbar prüfbar |
|
||
|
||
## 7.2 Normative Folge
|
||
|
||
Für spätere Implementierung und Arbeitspakete gilt:
|
||
|
||
- **Stufe 1 bis 3** sind der fachliche Kern von Version 1, soweit lokal prüfbar.
|
||
- **Stufe 4** ist fachlich zu dokumentieren, aber **nicht Bestandteil belastbarer Dateivalidierung in V1**.
|
||
- **Verfahrenslogik** über mehrere Übermittlungen, Fristen oder bilaterale Kommunikation ist von **Dateivalidierung** zu trennen.
|
||
|
||
## 8. Normative Strukturmatrizen
|
||
|
||
## 8.1 Gesamtstruktur einer Übertragungsdatei
|
||
|
||
| Strukturposition | Segment | Status | Regel |
|
||
|---|---|---|---|
|
||
| 1 | `UNA` | optional | Wenn vorhanden, muss das Segment fachlich korrekt sein. |
|
||
| 2 | `UNB` | Muss | Übertragungskopf. |
|
||
| 3 | `UNH`…`UNT` | Muss, mindestens 1 Nachricht | Eine Datei enthält mindestens eine Nachricht. |
|
||
| 4 | `UNZ` | Muss | Übertragungsende. |
|
||
|
||
## 8.2 Strukturmatrix ASVREC regulär
|
||
|
||
| Reihenfolge | Segment | Status | Bemerkung |
|
||
|---|---|---|---|
|
||
| 1 | `UNH` | Muss | Nachrichtentyp `ASVREC` |
|
||
| 2 | `IFA` | Muss | einmal pro Nachricht |
|
||
| 3 | `DGN` | Kann, 0..n | bei Rechnung fachlich regelmäßig erforderlich; bei Storno unzulässig |
|
||
| 4 | `LEA` | Kann, 0..n | bei Rechnung fachlich regelmäßig erforderlich; bei Storno unzulässig |
|
||
| 5 | `SAC` | Kann, 0..n je `LEA` | nur innerhalb einer Leistung |
|
||
| 6 | `GEN` | Kann, 0..n je `LEA` | nur innerhalb einer Leistung |
|
||
| 7 | `OPA` | Kann, 0..n je `LEA` | nur innerhalb einer Leistung |
|
||
| 8 | `REA` | Muss | einmal pro Nachricht |
|
||
| 9 | `IVA` | Muss | einmal pro Nachricht |
|
||
| 10 | `UNT` | Muss | Nachrichtenende |
|
||
|
||
**Wichtig:**
|
||
`SAC`, `GEN` und `OPA` sind **leistungsbezogene Untersegmente** und dürfen nicht frei außerhalb eines `LEA` auftreten.
|
||
|
||
## 8.3 Strukturmatrix ASVREC Storno
|
||
|
||
| Reihenfolge | Segment | Status | Bemerkung |
|
||
|---|---|---|---|
|
||
| 1 | `UNH` | Muss | Nachrichtentyp weiterhin `ASVREC` |
|
||
| 2 | `IFA` | Muss | nur Muss-Felder relevant |
|
||
| 3 | `REA` | Muss | nur Muss-Felder relevant; Storno-Kennzeichen `1`; Rechnungsbetrag gemäß `R-REA-7.2.1-001` = `0,00` |
|
||
| 4 | `IVA` | Muss | nur Muss-Felder relevant |
|
||
| 5 | `UNT` | Muss | Nachrichtenende |
|
||
|
||
**Bei Storno unzulässig:** `DGN`, `LEA`, `SAC`, `GEN`, `OPA`
|
||
|
||
## 8.4 Strukturmatrix ASVFEH Prüfstufe 1
|
||
|
||
| Reihenfolge | Segment | Status | Bemerkung |
|
||
|---|---|---|---|
|
||
| 1 | `UNH` | Muss | Nachrichtentyp `ASVFEH` |
|
||
| 2 | `FHL` | Muss, 1..99 | mindestens ein Fehlersegment |
|
||
| 3 | `UNT` | Muss | Nachrichtenende |
|
||
|
||
**Originalnachricht:** nicht zu übertragen.
|
||
|
||
## 8.5 Strukturmatrix ASVFEH Prüfstufen 2 bis 4
|
||
|
||
| Reihenfolge | Segment | Status | Bemerkung |
|
||
|---|---|---|---|
|
||
| 1 | `UNH` | Muss | Nachrichtentyp `ASVFEH` |
|
||
| 2 | Originalnutzdaten ohne `UNH`/`UNT` | grundsätzlich mitzuführen | darf fehlen, wenn Originalnutzdaten nicht lesbar oder syntaktisch nicht übertragbar waren |
|
||
| 3 | `FHL` | Muss, 1..99 | mindestens ein Fehlersegment |
|
||
| 4 | `UNT` | Muss | Nachrichtenende |
|
||
|
||
## 9. Feldgenauer Regelkatalog – KKS-Auftragssatz / AUF
|
||
|
||
## 9.1 Allgemeine Regeln KKS
|
||
|
||
| Regel-ID | Quelle | Feld | Fachliche Regel | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|
|
||
| `R-KKS-GLOBAL-001` | Abschnitt KKS-Auftragssatz, Hinweise 1/2 | alle KKS-Felder | Der KKS-Auftragssatz ist eigenständiger fachlicher Prüfgegenstand. Alle Muss-Felder sind auf Belegung, Feldtyp, Feldlänge und formale Festwerte zu prüfen. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-GLOBAL-002` | Hinweis 1 | numerische Kann-Felder | Nicht belegte numerische Kann-Felder sind mit `0` (`HEX 30`) zu füllen. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-GLOBAL-003` | Hinweis 2 | alphanumerische Kann-Felder | Nicht belegte alphanumerische Kann-Felder sind mit Blanks (`HEX 20`) zu füllen. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
|
||
## 9.2 Feldregeln KKS
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Bedeutung / Bedingung | Verbindliche V1-Prüfung | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|---|
|
||
| `R-KKS-IDENTIFIKATOR-001` | KKS-Auftragssatz | `IDENTIFIKATOR` | M | Konstante `500000` | exakter Festwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-VERSION-001` | KKS-Auftragssatz | `VERSION` | M | Version der Auftragssatzstruktur, hier `01` | exakter Festwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-LAENGE-AUFTRAG-001` | KKS-Auftragssatz | `LÄNGE_AUFTRAG` | M | Bei Version `01` Konstante `00000348` | exakter Festwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-SEQUENZ-NR-001` | KKS-Auftragssatz | `SEQUENZ_NR` | M | Konstante `000`; ASV kennt keine Teillieferungen | exakter Festwert; jede andere Ausprägung unzulässig | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-VERFAHREN-KENNUNG-001` | KKS-Auftragssatz | `VERFAHREN_KENNUNG` | M | Stelle 20 `E`/`T`, Stellen 21–23 `ASV`, Stelle 24 `0` | Teilkomponenten exakt prüfen | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-TRANSFER-NUMMER-001` | KKS-Auftragssatz, Stellen 25–27, M | `TRANSFER_NUMMER` | M | Dreistelliger Zähler `001`–`999` gemäß Abschnitt 3.5.4. Muss exakt dem Zähler im Dateinamen der verschlüsselten Datei (Stellen 26–28) entsprechen. | Wertebereich, Numerik, Crosscheck mit Dateinamen-Zähler | V1-V | `10047` (nur lokale Teilprüfung) oder kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-VERFAHREN-KENNUNG-SPEZ-001` | KKS-Auftragssatz | `VERFAHREN_KENNUNG_SPEZIFIKATION` | K | Wenn geliefert: `ASVA0` für Abrechnung, `ASVF0` für Fehlermeldung | Blank zulässig; gelieferter Inhalt nur aus zulässiger Wertemenge | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-ABSENDER-EIGNER-001` | KKS-Auftragssatz | `ABSENDER_EIGNER` | M | Zertifizierungs-IK des Eigners | Struktur, Länge, formales IK-Format | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-ABSENDER-PHYS-001` | KKS-Auftragssatz | `ABSENDER_PHYSIKALISCH` | M | physikalischer Absender | Struktur, Länge, formales IK-Format | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-EMPFAENGER-NUTZER-001` | KKS-Auftragssatz | `EMPFÄNGER_NUTZER` | M | Zertifizierungs-IK des Nutzers | Struktur, Länge, formales IK-Format | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-EMPFAENGER-PHYS-001` | KKS-Auftragssatz | `EMPFÄNGER_PHYSIKALISCH` | M | physikalischer Empfänger | Struktur, Länge, formales IK-Format | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-FEHLER-NUMMER-001` | KKS-Auftragssatz | `FEHLER_NUMMER` | M | Konstante `000000` | exakter Festwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-FEHLER-MASSNAHME-001` | KKS-Auftragssatz | `FEHLER_MAßNAHME` | M | Konstante `000000` | exakter Festwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-DATEINAME-001` | Abschnitt 3.5.1, KKS DATEINAME | `DATEINAME` | M | unverschlüsselter Dateiname gemäß Abschnitt 3.5.1 | Format und Crosscheck mit Nutzdatei/UNB 0020 | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-DATUM-ERSTELLUNG-001` | KKS-Auftragssatz | `DATUM_ERSTELLUNG` | M | 14-stelliges Datum/Zeit im Format `JJJJMMTThhmmss` (Erstellungsdatum der Datei aus der Anwendung) | Typ, Länge, formales Datums-/Zeitmuster | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-DATUM-SENDET-001` | KKS-Auftragssatz | `DATUM_ÜBERTRAGUNG_GESENDET` | K | numerisches Kann-Feld | Wenn leer, Nullfüllung; wenn belegt, formatgerecht | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-DATUM-EMPF-START-001` | KKS-Auftragssatz | `DATUM_ÜBERTRAGUNG_EMPFANGEN_START` | K | numerisches Kann-Feld | Wenn leer, Nullfüllung; wenn belegt, formatgerecht | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-DATUM-EMPF-ENDE-001` | KKS-Auftragssatz | `DATUM_ÜBERTRAGUNG_EMPFANGEN_ENDE` | K | numerisches Kann-Feld | Wenn leer, Nullfüllung; wenn belegt, formatgerecht | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-DATEIVERSION-001` | KKS-Auftragssatz | `DATEIVERSION` | M | Konstante `000000` | exakter Festwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-KORREKTUR-001` | KKS-Auftragssatz | `KORREKTUR` | M | Konstante `0` | exakter Festwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-DATEIGROESSE-NUTZ-001` | KKS-Auftragssatz | `DATEIGRÖßE_NUTZDATEN` | M | Größe der unverschlüsselten Nutzdatei in Bytes | exakter Byte-Crosscheck, soweit unverschlüsselte Schicht lokal vorliegt | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-DATEIGROESSE-UEBERTR-001` | KKS-Auftragssatz | `DATEIGRÖßE_ÜBERTRAGUNG` | M | Größe der verschlüsselten Übertragungsdatei in Bytes | exakter Byte-Crosscheck mit physischer Datei | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-ZEICHENSATZ-001` | KKS-Auftragssatz | `ZEICHENSATZ` | M | Festwert `I5` = ISO 8859-15 | exakter Festwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-KOMPRIMIERUNG-001` | KKS-Auftragssatz | `KOMPRIMIERUNG` | M | Festwert `00` = keine | exakter Festwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-VERSCHLUESSELUNG-001` | KKS-Auftragssatz | `VERSCHLÜSSELUNGSART` | M | Festwert `03` | exakter Festwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-ELEKTR-UNTERSCHRIFT-001` | KKS-Auftragssatz | `ELEKTRONISCHE_UNTERSCHRIFT` | M | Festwert `03` | exakter Festwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-SATZFORMAT-001` | Hinweis 2 | `SATZFORMAT` | K | alphanumerisches Kann-Feld | Leer = Blanks; sonst Strukturprüfung | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-SATZLAENGE-001` | Hinweis 1 | `SATZLÄNGE` | K | numerisches Kann-Feld | Leer = Nullfüllung; sonst Strukturprüfung | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-BLOCKLAENGE-001` | Hinweis 1 | `BLOCKLÄNGE` | K | numerisches Kann-Feld | Leer = Nullfüllung; sonst Strukturprüfung | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-STATUS-001` | Hinweis 1 | `Status` | K | numerisches Kann-Feld | Leer = Nullfüllung; sonst Strukturprüfung | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-WIEDERHOLUNG-001` | Hinweis 1 | `Wiederholung` | K | numerisches Kann-Feld | Leer = Nullfüllung; sonst Strukturprüfung | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-UEBERTRAGUNGSWEG-001` | Hinweis 1 | `Übertragungsweg` | K | numerisches Kann-Feld | Leer = Nullfüllung; sonst Strukturprüfung | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-VERZOEGERTER-VERSAND-001` | Hinweis 1 | `Verzögerter Versand` | K | numerisches Kann-Feld | Leer = Nullfüllung; sonst Strukturprüfung | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-INFO-FEHLERFELDER-001` | Hinweis 1 | `Info und Fehlerfelder` | K | numerisches Kann-Feld | Leer = Nullfüllung; sonst Strukturprüfung | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-VARIABLES-INFO-001` | Hinweis 2 | `Variables Info-Feld` | K | alphanumerisches Kann-Feld | Leer = Blanks; sonst Strukturprüfung | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-DATEINAME-PHYS-001` | Hinweis 2 | `DATEINAME_PHYSIKALISCH` | K | alphanumerisches Kann-Feld | Leer = Blanks; sonst Strukturprüfung | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-KKS-DATEI-BEZEICHNUNG-001` | Hinweis 2 | `DATEI_BEZEICHNUNG` | K | alphanumerisches Kann-Feld | Leer = Blanks; sonst Strukturprüfung | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
|
||
## 10. Feldgenauer Regelkatalog – Service- und Hüllsegmente
|
||
|
||
## 10.1 UNA
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|
|
||
| `R-UNA-GLOBAL-001` | Datensatzbeschreibung Service-Sätze | `UNA` Segment | optional | Wenn `UNA` vorhanden ist, muss es exakt die gültigen Trennzeichenvorgaben enthalten. | V1-V | `10030`, `10031`, `10007`, `1A008` |
|
||
| `R-UNA-TZ-INNER-001` | UNA | TZ innerhalb Datenelemente | M in vorhandenem UNA | Muss `IS1` sein. | V1-V | `10030` – unbekanntes/falsches Trennzeichen |
|
||
| `R-UNA-TZ-ELEMENT-001` | UNA | TZ Datenelemente | M in vorhandenem UNA | Muss `IS3` sein. | V1-V | `10030` |
|
||
| `R-UNA-DEZIMAL-001` | UNA | Dezimalzeichen | M in vorhandenem UNA | Muss `,` sein. | V1-V | `10030` |
|
||
| `R-UNA-AUFHEBUNG-001` | UNA | Aufhebungszeichen | M in vorhandenem UNA | Muss Leerzeichen sein. | V1-V | `10030` |
|
||
| `R-UNA-RESERVIERT-001` | UNA | Reserviert | M in vorhandenem UNA | Muss Leerzeichen sein. | V1-V | `10030` |
|
||
| `R-UNA-SEGMENTENDE-001` | UNA | Segmentendezeichen | M in vorhandenem UNA | Muss `IS4` sein. | V1-V | `10030`, `1A008` |
|
||
|
||
## 10.2 UNB
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel | V1 | Fehlercode / Klarbeschreibung |
|
||
|---|---|---|---|---|---|---|
|
||
| `R-UNB-GLOBAL-001` | Service-Sätze | `UNB` Segment | M | `UNB` muss vorhanden sein und an richtiger Position stehen. | V1-V | `10001` – Segment UNB fehlt bzw. folgt nicht auf UNA |
|
||
| `R-UNB-S001-0001-001` | UNB | Syntax-Kennung | M | Muss `UNOC` sein. | V1-V | `10040` – verwendete Syntax falsch/unbekannt |
|
||
| `R-UNB-S001-0002-001` | UNB | Syntax-Versionsnummer | M | Muss `3` sein. | V1-V | `10040` |
|
||
| `R-UNB-S002-0004-001` | UNB | Identifikation Sender | M | IK des physikalischen Senders | formales IK; Kommunikationspartnerinhalt nur teilweise prüfbar | V1-T | `10041` – IK Absender nicht als Kommunikationspartner bekannt |
|
||
| `R-UNB-S002-0007-001` | UNB | Qualifikation Sender-ID | M | Muss fachlich zum Partnertyp passen (`L` oder `K`). | V1-T | `10099` oder kein eindeutiger offizieller Fehlercode |
|
||
| `R-UNB-S003-0010-001` | UNB | Identifikation Empfänger | M | IK des physikalischen Empfängers | formales IK; annehmende Stelle nur teilweise prüfbar | V1-T | `10043` – IK Empfänger nicht annehmende Stelle |
|
||
| `R-UNB-S003-0007-001` | UNB | Qualifikation Empfänger-ID | M | Muss fachlich zum Partnertyp passen (`L` oder `K`). | V1-T | `10099` oder kein eindeutiger offizieller Fehlercode |
|
||
| `R-UNB-S004-0017-001` | UNB | Datum | M | Format `JJJJMMTT` | formatgerecht | V1-V | `10037` – Datenelement nicht im Format JJJJMMTT |
|
||
| `R-UNB-S004-0019-001` | UNB | Uhrzeit | M | Format `HHMM` | formatgerecht | V1-V | `10038` – Datenelement nicht im Format HHMM |
|
||
| `R-UNB-0020-001` | UNB | Übertragungsreferenz | M | Muss dem Dateinamen gemäß Abschnitt 3.5.1 entsprechen. | Crosscheck mit physischem Dateinamen und UNZ 0020 | V1-V | `10064`, `1A010` |
|
||
| `R-UNB-0035-001` | UNB | Testindikator | K | Nur für Testzwecke erforderlich; `1` = Test | bei Echtdaten leer, bei Test fachlich konsistent | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
|
||
## 10.3 UNZ
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|
|
||
| `R-UNZ-GLOBAL-001` | Service-Sätze | `UNZ` Segment | M | `UNZ` muss vorhanden sein. | V1-V | `10006` – Segment UNZ fehlt |
|
||
| `R-UNZ-0036-001` | UNZ | Anzahl Nachrichten | M | Muss exakt der Zahl der `UNH`-Segmente entsprechen. | V1-V | `20070` – Anzahl Nachrichten stimmt nicht |
|
||
| `R-UNZ-0020-001` | UNZ | Übertragungsreferenz | M | Muss `UNB 0020` entsprechen. | V1-V | `1A010` – Übertragungsreferenzen in UNB und UNZ nicht identisch |
|
||
|
||
## 10.4 UNH
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|
|
||
| `R-UNH-GLOBAL-001` | Service-Sätze | `UNH` Segment | M | `UNH` muss vorhanden sein und korrekt auf `UNB` bzw. `UNT` folgen. | V1-V | `10003` – Segment UNH fehlt bzw. falsche Position |
|
||
| `R-UNH-0062-001` | UNH | Nachrichtenreferenznummer | M | Laufende Nummer der Nachricht innerhalb der Datei | Muss vorhanden sein; Paarigkeit mit `UNT 0062` | V1-V | `20071` – Referenz in UNH/UNT stimmt nicht überein |
|
||
| `R-UNH-S009-0065-001` | UNH | Nachrichten-Typ | M | Nur `ASVREC` oder `ASVFEH` zulässig. | V1-V | `10061` – Nachrichtentyp unbekannt |
|
||
| `R-UNH-S009-0052-001` | UNH | Versionsnummer | M | Muss eine zulässige Hauptversion der Nachrichtenstruktur tragen. | V1-T | `10062` – ungültige Versionsnummer |
|
||
| `R-UNH-S009-0054-001` | UNH | Releasenummer | M | Muss eine zulässige Releasenummer der Nachrichtenstruktur tragen. | V1-T | `10063` – ungültige Releasenummer |
|
||
| `R-UNH-S009-0051-001` | UNH S009 0051 | Verwaltende Organisation | M | Muss `SV` sein. | V1-V | `2A001` – unbekannter Schlüsselwert laut TA |
|
||
|
||
## 10.5 UNT
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|
|
||
| `R-UNT-GLOBAL-001` | Service-Sätze | `UNT` Segment | M | `UNT` muss vorhanden sein. | V1-V | `10004` – Segment UNT fehlt |
|
||
| `R-UNT-0074-001` | UNT | Anzahl Segmente | M | Muss die Zahl aller Segmente zwischen `UNH` und `UNT` inklusive `UNH`/`UNT` enthalten. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-UNT-0062-001` | UNT | Nachrichtenreferenznummer | M | Muss `UNH 0062` entsprechen. | V1-V | `20071` – Nachrichtenreferenznummer stimmt nicht |
|
||
|
||
## 11. Feldgenauer Regelkatalog – ASVREC
|
||
|
||
## 11.1 Segment IFA – Fallinformation
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel / Bedingung | V1-Prüfung | V1 | Fehlercode / Klarbeschreibung |
|
||
|---|---|---|---|---|---|---|---|
|
||
| `R-IFA-SEG-001` | ASV-Abrechnung 1/ | `IFA` Segment | M | Genau einmal pro Nachricht | Segment vorhanden; richtige Position | V1-V | `2A012` – Segmentreihenfolge falsch / `10099` bei unbekannter Segmentlage |
|
||
| `R-IFA-1.2.1-001` | IFA 1.2.1 | Teamnummer | M | Teamnummer des Erbringers | Typ/Länge lokal; Bestandsbezug zum ASV-Verzeichnis nur teilweise | V1-T | `3A029` – fachlich einschlägig, lokal in V1 ohne ASV-Verzeichnis nicht belastbar auslösbar |
|
||
| `R-IFA-1.2.2-001` | IFA 1.2.2, Hinweis 10 | BSNR Erbringer | M | Betriebsstättennummer des Erbringers; muss im ASV-Verzeichnis oder Arztstammdaten vorhanden sein | Format/Länge lokal; Bestandsabgleich nicht belastbar in V1 | V1-T | `3A031` – fachlich einschlägig, lokal in V1 ohne Referenzbestände nicht belastbar auslösbar |
|
||
| `R-IFA-1.2.3-001` | IFA 1.2.3 | LANR Erbringer | M | Lebenslange Arztnummer des Erbringers | Format/Länge lokal; Bestandsabgleich nicht belastbar in V1 | V1-T | `3A030` – fachlich einschlägig, lokal in V1 ohne Referenzbestände nicht belastbar auslösbar |
|
||
| `R-IFA-1.2.4-001` | IFA 1.2.4 | Erkrankungs-/Leistungsbereich | M | Muss gültigen Bereich gemäß Anlage 4 tragen | formaler Schlüsselwert soweit lokal; externe Perioden-/Bestandsbezüge nicht belastbar | V1-T | `3A003`, `3A014` |
|
||
| `R-IFA-1.2.5-001` | IFA 1.2.5, Hinweis 9 | Teamebene | M | `1`, `2`, `3`; im Vertretungsfall gilt Teamebene des Vertretenen | lokaler Schlüsselwert prüfbar; Vertretungsbezug nur teilweise | V1-T | `3A004`, `4A007` oder kein eindeutiger offizieller Fehlercode |
|
||
| `R-IFA-1.3.1-001` | IFA 1.3.1 | BSNR externer Überweiser | K | nur bei externer Überweisung | Format/Länge lokal; Bestandsabgleich nicht belastbar | V1-T | `3A034` – fachlich einschlägig, lokal in V1 ohne Referenzbestände nicht belastbar auslösbar |
|
||
| `R-IFA-1.3.2-001` | IFA 1.3.2 | Teamnummer interner Überweiser | K | nur bei interner Überweisung | Format/Länge lokal; Bestandsabgleich nicht belastbar | V1-T | `3A032` – fachlich einschlägig, lokal in V1 ohne Referenzbestände nicht belastbar auslösbar |
|
||
| `R-IFA-1.3.3-001` | IFA 1.3.3 | LANR Überweiser | K | bei Vorlage einer Überweisung | Format/Länge lokal; Bestandsabgleich nicht belastbar | V1-T | `3A033` – fachlich einschlägig, lokal in V1 ohne Referenzbestände nicht belastbar auslösbar |
|
||
| `R-IFA-1.3.4-001` | IFA 1.3.4 | Beginn ASV-Behandlung | K | Muss belegt sein, wenn `1.3.1` gefüllt ist | formales Datum; Bedingung mit 1.3.1 | V1-V | `3A005` – Beginn ASV-Behandlung fehlt trotz externer Überweisung; `20021` / `3A011` |
|
||
| `R-IFA-OVER-001` | Hinweis 9 | Teamebene Vertretung | Regel | Bei Vertretung (Teamebene 4 im ASV-Verzeichnis) ist die Teamebene des Vertretenen anzugeben. | ohne Referenzbestand nur eingeschränkt prüfbar | V1-N | `4A007` – Teamnummer/LANR/Teamebene entspricht nicht ASV-Verzeichnis |
|
||
| `R-IFA-OVER-002` | IFA Hinweise | Überweiserfelder | Regel | `1.3.1` und `1.3.2` dürfen nicht gleichzeitig belegt sein. | lokale Crosscheck-Regel | V1-V | `3A035` – externer und interner Überweiser gleichzeitig |
|
||
|
||
## 11.2 Segment DGN – Diagnosedaten
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel / Bedingung | V1-Prüfung | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|---|
|
||
| `R-DGN-SEG-001` | ASV-Abrechnung 2/ | `DGN` Segment | 0..n | Wiederholbar pro Fall; bei Storno generell unzulässig | Vorkommen und Stornoverbot | V1-V | `3A025` – DGN vorhanden obwohl Storno |
|
||
| `R-DGN-2.2.1-001` | DGN 2.2.1, Hinweis | Diagnose codiert | M/bedingt | Bei Diagnoseart `1` (Behandlungsdiagnose) ist die ICD-codierte Diagnose ein Muss-Feld. Bei Diagnoseart `2` (Diagnose der Überweisung) ist sie zu liefern, sofern sie aus der Überweisung übernommen werden kann. | Feldtyp/Länge; Bedingungsprüfung gegen Diagnoseart in 2.2.5 | V1-V | `20001`, `20033`, `3A006` |
|
||
| `R-DGN-2.2.1-002` | Hinweis ICD | Diagnose codiert | Regel | Sonderzeichen der ICD-10-GM für Kreuz/Stern/Ausrufezeichen dürfen nicht übertragen werden. | lokale Zeichensatz-/Wertprüfung | V1-V | `3A006` oder `3A004` |
|
||
| `R-DGN-2.2.2-001` | DGN 2.2.2 | Diagnosesicherheit | M | Nur `A` (ausgeschlossene Diagnose), `G` (gesicherte Diagnose), `V` (Verdachtsdiagnose), `Z` (symptomloser Zustand nach) zulässig. | lokaler Schlüsselwert | V1-V | `3A004` – unbekannter Schlüsselwert |
|
||
| `R-DGN-2.2.3-001` | DGN 2.2.3 | Seitenlokalisation | K | Falls angegeben: `R`, `L`, `B` | lokaler Schlüsselwert | V1-V | `3A004` |
|
||
| `R-DGN-2.2.4-001` | DGN 2.2.4 | Leistungsdokumentation | K | Freitext, derzeit z. B. TNM-Status | Länge/Typ; Plausibilität nicht belastbar | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-DGN-2.2.5-001` | DGN 2.2.5 | Diagnoseart | M | `1` = Behandlungsdiagnose, `2` = Diagnose der Überweisung | lokaler Schlüsselwert | V1-V | `3A004` |
|
||
| `R-DGN-2.2.5-002` | DGN 2.2.5, IFA 1.3 | Diagnoseart 2 | Regel | Diagnoseart `2` darf nur im Kontext einer Überweisung verwendet werden. | lokale Bedingungsprüfung mit IFA-Überweiserfeldern | V1-V | `3A007` |
|
||
| `R-DGN-OVER-001` | REA 7.2.4, DGN Segment | DGN-Vorkommen | Regel | Bei Rechnung (`REA 7.2.4 = 0`) muss mindestens ein DGN vorhanden sein. | lokale Crosscheck-Regel | V1-V | `3A023` – DGN fehlt obwohl Rechnung |
|
||
| `R-DGN-OVER-002` | Hinweise / Fehlercode | ICD-Bestandsprüfung | Regel | ICD muss zum Leistungszeitpunkt im gültigen Katalog enthalten sein. | ohne Katalog nicht belastbar | V1-N | `3A006` |
|
||
| `R-DGN-OVER-003` | Fehlerkatalog Stufe 4 | Alter/Geschlecht vs. ICD | Regel | Zuordnung von ICD zu Alter oder Geschlecht kann unzulässig sein. | ohne medizinische Referenz-/Plausibilitätslogik nicht belastbar | V1-N | `3A021`, `3A022`, `4A010`, `4A011` |
|
||
|
||
## 11.3 Segment LEA – Leistungsdaten
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel / Bedingung | V1-Prüfung | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|---|
|
||
| `R-LEA-SEG-001` | ASV-Abrechnung 3/ | `LEA` Segment | 0..n | Wiederholbar pro Fall; bei Storno unzulässig | Vorkommen und Stornoverbot | V1-V | `3A026` – LEA vorhanden obwohl Storno |
|
||
| `R-LEA-3.2.1-001` | LEA 3.2.1, Hinweise 6/7/8 | GOP | M | Muss abrechnungsfähige GOP oder zulässige Pseudo-GOP tragen | Format/Länge lokal; fachliche Abrechenbarkeit ohne Referenz teilweise | V1-T | `3A008`, `4A003`, `4A009` |
|
||
| `R-LEA-3.2.1-002` | Hinweis 6 | Pseudo-GOP 88999 / regionale Pseudo-GOP | Regel | Wenn Sachkosten ohne Sachzusammenhang zu einer Leistung am Behandlungstag vorliegen oder keine Leistung am Behandlungstag existiert, ist `88999` oder regionale Pseudo-GOP mit Anzahl `1` und Preis `0` zu übertragen. | lokale Teilprüfung für vorhandene Kombinationen; regionale Pseudo-GOP ohne Katalog nur teilweise | V1-T | `3A016`, `3A017` |
|
||
| `R-LEA-3.2.1-003` | Hinweis 8 | GOÄ-Übermittlung | Regel | Bei GOÄ-Übermittlung ist in `3.2.1` die Pseudo-GOP zu übertragen. | lokale Strukturregel | V1-V | `3A028` in Kombination mit 3.2.5 |
|
||
| `R-LEA-3.2.2-001` | LEA 3.2.2 | Datum | M | logisches Datum `JJJJMMTT` | lokale Format- und Zukunftsprüfung | V1-V | `20021`, `3A011` |
|
||
| `R-LEA-3.2.3-001` | LEA 3.2.3 | Anzahl_GOP | M | numerischer Multiplikator | Typ/Länge und spezifische Pseudo-GOP-Regeln | V1-V | `20002`, `20033`, `3A016` |
|
||
| `R-LEA-3.2.4-001` | LEA 3.2.4 | Preis_GOP | M | regionaler Euro-Wert der GOP | numerisches Format lokal; regionaler GO-Bezug nicht belastbar | V1-T | `3A017`, `4A001` |
|
||
| `R-LEA-3.2.5-001` | LEA 3.2.5 | Dokumentation | K | Abrechnungsbegründung/Uhrzeit(en) | Typ/Länge lokal; Plausibilität nur eingeschränkt | V1-T | `4A013` |
|
||
| `R-LEA-3.2.5-002` | Konvention/KBV-Fehlerkatalog 3A028, Hinweis 8 | Dokumentation bei GOÄ | K/bedingt | Bei GOÄ-Pseudoziffern (in der KBV-Konvention typischerweise im Bereich `885xx`) ist die zugehörige GOÄ-Ziffer bzw. Abrechnungsbegründung in `3.2.5` erforderlich. Die konkrete Pseudo-GOP-Range ist in der Technischen Anlage ASV nicht wörtlich abgegrenzt. | lokale Bedingungsprüfung | V1-K | `3A028` |
|
||
| `R-LEA-OVER-001` | REA 7.2.4 | LEA-Vorkommen | Regel | Bei Rechnung (`REA 7.2.4 = 0`) muss mindestens ein LEA vorhanden sein. | lokale Crosscheck-Regel | V1-V | `3A024` – LEA fehlt obwohl Rechnung |
|
||
| `R-LEA-OVER-002` | Fehlerkatalog Stufe 4 | GOP-Nebeneinander | Regel | Bestimmte GOP können nicht nebeneinander abrechnungsfähig sein. | ohne Referenz-/Regelwerk nicht belastbar | V1-N | `4A009` |
|
||
| `R-LEA-OVER-003` | Fehlerkatalog Stufe 4 | Fachgruppe / Teamebene / Appendix | Regel | Bezug Fachgruppe/Teamebene zu GOP kann fachlich unplausibel sein. | ohne Referenzbestand nicht belastbar | V1-N | `4A003`, `4A004` |
|
||
|
||
## 11.4 Segment SAC – Sachkosten
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel | V1-Prüfung | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|---|
|
||
| `R-SAC-SEG-001` | ASV-Abrechnung 4/ | `SAC` Segment | 0..n je LEA | Nur innerhalb einer Leistung; bei Storno unzulässig | Strukturbindung an LEA | V1-V | `2A012` oder kein eindeutiger offizieller Fehlercode |
|
||
| `R-SAC-4.2.1-001` | SAC 4.2.1 | Sachkosten | M | Euro-Betrag der Sachkosten | numerisches Format | V1-V | `20002`, `20033` |
|
||
| `R-SAC-4.2.2-001` | SAC 4.2.2 | Sachkostenbezeichnung | M | Bezeichnung der Sachkosten | Typ/Länge | V1-V | `20001`, `20033` |
|
||
| `R-SAC-4.2.3-001` | SAC 4.2.3 | Anzahl_Sachkosten | M | numerischer Multiplikator | Typ/Länge | V1-V | `20002`, `20033` |
|
||
| `R-SAC-4.2.4-001` | Hinweis 12 | Hersteller/Lieferant | M | Ab Q1/2020 fachlich obsolet, aber weiterhin mit beliebigem Inhalt zu füllen; nicht ausschließlich Leerzeichen | Blank-only unzulässig; Inhalt sonst nicht fachlich auswerten | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-SAC-4.2.5-001` | Hinweis 12 | Artikel-/Modellnummer | M | Ab Q1/2020 fachlich obsolet, aber weiterhin mit beliebigem Inhalt zu füllen; nicht ausschließlich Leerzeichen | Blank-only unzulässig; Inhalt sonst nicht fachlich auswerten | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-SAC-OVER-001` | Hinweis 6, Stufe 4 | Sachkostenbezug | Regel | Sachkosten müssen fachlich plausibel zum Abrechnungsfall passen. | ohne externe Fachlogik nur teilweise | V1-N | `4A012` – Sachkosten im Bezug zum Fall nicht plausibel |
|
||
|
||
## 11.5 Segment GEN – Gennummer
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel | V1-Prüfung | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|---|
|
||
| `R-GEN-SEG-001` | ASV-Abrechnung 5/ | `GEN` Segment | 0..n je LEA | Nur innerhalb einer Leistung; bei Storno unzulässig | Strukturbindung an LEA | V1-V | `2A012` oder kein eindeutiger offizieller Fehlercode |
|
||
| `R-GEN-5.2.1-001` | GEN 5.2.1 | Gennummer codiert | M | Gennummer zur GOP | Typ/Länge | V1-V | `20001`, `20033` |
|
||
| `R-GEN-5.2.1-002` | Fehlerkatalog | Gennummer Pflichtbezug | Regel | Bei EBM-Ziffern `11320`, `11321`, `11322` ist eine Gennummer erforderlich. | lokale Bedingungsprüfung auf GOP möglich | V1-V | `3A018` – Gennummer fehlt bei bestimmter EBM-Ziffer |
|
||
|
||
## 11.6 Segment OPA – OP-Schlüssel
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel | V1-Prüfung | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|---|
|
||
| `R-OPA-SEG-001` | ASV-Abrechnung 6/ | `OPA` Segment | 0..n je LEA | Nur innerhalb einer Leistung; bei Storno unzulässig | Strukturbindung an LEA | V1-V | `2A012` oder kein eindeutiger offizieller Fehlercode |
|
||
| `R-OPA-6.2.1-001` | OPA 6.2.1 | OPS codiert | M | Muss gültigen OPS tragen | Typ/Länge lokal; Katalogabgleich nicht belastbar | V1-T | `3A009` – OPS-Code nicht im gültigen Katalog |
|
||
| `R-OPA-6.2.2-001` | OPA 6.2.2 | Seitenlokalisation | K | Falls angegeben: `R`, `L`, `B` | lokaler Schlüsselwert | V1-V | `3A004` |
|
||
| `R-OPA-6.2.2-002` | Fehlerkatalog | Seitenlokalisation Pflicht | Regel | Für bestimmte OPS-Codes ist Seitenlokalisation erforderlich. | ohne OPS-Regelbestand nicht belastbar | V1-N | `3A020` – Seitenlokalisation zum OPS-Code fehlt |
|
||
| `R-OPA-6.2.3-001` | OPA 6.2.3 | OPS-Datum | K | Datum `JJJJMMTT` | lokale Format- und Zukunftsprüfung | V1-V | `20021`, `3A011` |
|
||
|
||
## 11.7 Segment REA – Rechnungsdaten
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel | V1-Prüfung | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|---|
|
||
| `R-REA-SEG-001` | ASV-Abrechnung 7/ | `REA` Segment | M | Genau einmal pro Nachricht | vorhanden; richtige Position | V1-V | `2A012` |
|
||
| `R-REA-7.2.1-001` | REA 7.2.1 | Rechnungsbetrag | M | Bei regulärer Rechnung Summe aus `LEA(Preis*Anzahl)` plus `SAC(Betrag*Anzahl)`. Bei Storno ist das Feld gemäß Spezifikation mit `0,00` zu befüllen. | lokaler Summencrosscheck (regulär); Festwertprüfung `0,00` bei Storno | V1-V | `3A019`, `3A027` |
|
||
| `R-REA-7.2.2-001` | REA 7.2.2 | Leistungserbringungsquartal | M | Format `JJJJQ` | Typ/Länge/Format | V1-V | `2A008` – Datenelement nicht JJJJQ |
|
||
| `R-REA-7.2.3-001` | REA 7.2.3 | Rechnungsnummer | M | Rechnungsnummer je Rechnungssteller je Fall | Muss vorhanden sein; Storno/Korrektur-Bezug relevant | V1-V | `20001`, `20033`; in FHL-Kontext auch 2.14 |
|
||
| `R-REA-7.2.4-001` | REA 7.2.4 | Rechnungskennzeichen | M | `0` = Rechnung, `1` = Storno | lokaler Schlüsselwert | V1-V | `3A004` |
|
||
| `R-REA-7.2.4-002` | REA 7.2.4, Storno | Rechnungskennzeichen vs. Struktur | Regel | Bei `0` müssen DGN und LEA fachlich vorhanden sein; bei `1` dürfen DGN/LEA nicht vorkommen. | lokale Crosscheck-Regel | V1-V | `3A023`, `3A024`, `3A025`, `3A026` |
|
||
| `R-REA-7.2.5-001` | REA 7.2.5 | Rechnungsdatum | M | Datum `JJJJMMTT` | lokale Format- und Zukunftsprüfung | V1-V | `20021`, `3A011` |
|
||
| `R-REA-7.2.6-001` | REA 7.2.6 | IK_logischer_Absender | K | IK des direktabrechnenden Arztes | formales IK lokal; Bestandsabgleich nicht belastbar | V1-T | `3A001` – IK unbekannt |
|
||
| `R-REA-7.2.7-001` | REA 7.2.7 | IK_physikalischer_Absender | M | IK des Absenders (KV bzw. Direktabrechner) | formales IK lokal; Partnerprüfung nicht belastbar | V1-T | `3A001` |
|
||
| `R-REA-7.2.8-001` | REA 7.2.8 | IK_Abrechnender_Kostenträger | M | Abrechnungs-IK der Krankenkasse | formales IK lokal; Bestandsabgleich nicht belastbar | V1-T | `3A001` |
|
||
| `R-REA-7.2.9-001` | REA 7.2.9 | IK_Zahlungsempfänger | M | IK des Zahlungsempfängers | formales IK lokal; Bestandsabgleich nicht belastbar | V1-T | `3A001` |
|
||
|
||
## 11.8 Segment IVA – Versicherter
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel | V1-Prüfung | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|---|
|
||
| `R-IVA-SEG-001` | ASV-Abrechnung 8/ | `IVA` Segment | M | Genau einmal pro Nachricht | vorhanden; richtige Position | V1-V | `2A012` |
|
||
| `R-IVA-8.2.1-001` | IVA 8.2.1 | Versichertenart | M | Zulässige Werte `1/3/5` = Mitglied/Familienangehöriger/Rentner. | lokaler Schlüsselwert | V1-V | `3A004` |
|
||
| `R-IVA-8.2.2-001` | IVA 8.2.2 | Besondere Personengruppe | M | Zulässige Werte `00/04/06/07/08/09`. | lokaler Schlüsselwert | V1-V | `3A004` |
|
||
| `R-IVA-8.3-001` | IVA 8.3 | Versichertenbezug Nummer | K | Anzugeben bei eingelesener eGK, optional auch im Ersatzverfahren | Typ/Länge; Bedingung dokumentieren | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-IVA-8.3.1-001` | IVA 8.3.1, Hinweis 3 | Versichertennummer | M | Muss im eGK-Format übermittelt werden: 1. Stelle Alpha-Zeichen (A–Z, ohne Umlaute), 2. bis 9. Stelle 8-stellige laufende Zählnummer (in der Praxis numerisch), 10. Stelle Prüfziffer | Strukturprüfung verbindlich; algorithmische Prüfziffervalidierung in V1 nicht verpflichtend (Algorithmus außerhalb der ASV-Spezifikation) | V1-V | `3A010` – Format Versichertennummer nicht korrekt |
|
||
| `R-IVA-8.3.1-002` | Fehlerkatalog Stufe 4 | Versichertennummer / Ersatzverfahren | Regel | Nummer und Angaben Ersatzverfahren dürfen fachlich nicht unbekannt sein. | ohne Kassendatenbestand nicht belastbar | V1-N | `4A002` |
|
||
| `R-IVA-8.4-001` | IVA 8.4 | Versichertenbezug Name | K | Im Ersatzverfahren relevant | Strukturkontext mit Ersatzverfahren | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-IVA-8.4.1-001` | IVA 8.4.1 | Nachname | M | Muss-Feld bei Ersatzverfahren | Typ/Länge; Bedingung aus Ersatzverfahren | V1-T | `20001`, `20033` oder kein eindeutiger offizieller Fehlercode |
|
||
| `R-IVA-8.4.2-001` | IVA 8.4.2 | Vorname | M | Muss-Feld bei Ersatzverfahren | Typ/Länge; Bedingung aus Ersatzverfahren | V1-T | `20001`, `20033` oder kein eindeutiger offizieller Fehlercode |
|
||
| `R-IVA-8.4.3-001` | IVA 8.4.3, Hinweis 4 | Geburtsdatum | M | Im Ersatzverfahren sind beliebige numerische Werte im Format `JJJJMMTT` zulässig; zusätzlich `00`, `0000`, `00000000` erlaubt. Logisches Kalenderdatum ist **nicht** erforderlich. | nur zulässige Spezialformate/Zeichenmuster prüfen; **keine** Datumsplausibilisierung | V1-V | `3A012` – Geburtsdatum nicht im zulässigen Format |
|
||
|
||
## 12. Feldgenauer Regelkatalog – ASVFEH / FHL
|
||
|
||
## 12.1 Allgemeine Regeln ASVFEH
|
||
|
||
| Regel-ID | Quelle | Feld/Thema | Fachliche Regel | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|
|
||
| `R-ASVFEH-GLOBAL-001` | Datensatzbeschreibung ASV-Fehlernachricht | Nachrichtentyp | `ASVFEH` ist eigenständiger Nachrichtentyp für Fehlerrückmeldungen. | V1-V | `10061` |
|
||
| `R-ASVFEH-GLOBAL-002` | ASVFEH, Originalnachricht | Originalnachricht | Bei Prüfstufe 1 nicht zu übertragen. Bei Prüfstufe 2–4 grundsätzlich zu übertragen. Fehlen ist jedoch zulässig, wenn die Originalnutzdaten nicht lesbar oder nicht syntaktisch übertragbar waren. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-ASVFEH-GLOBAL-003` | Fehlerverfahren | Mitgelieferte Originalnachricht | Die Prüfung einer Fehlernachricht erstreckt sich **nicht** auf die mitgelieferte Originalnachricht. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-ASVFEH-GLOBAL-004` | Fehlerverfahren | Fehler auf Fehler | Eine Fehlernachricht darf nicht mit einer Fehlernachricht beantwortet werden. Diese Regel ist verfahrensbezogen und nicht an einer isolierten Datei belastbar prüfbar. | V1-N | kein eindeutiger offizieller Fehlercode |
|
||
|
||
## 12.2 Segment FHL
|
||
|
||
| Regel-ID | Quelle | Feld | Muss/Kann | Fachliche Regel / Bedingung | V1-Prüfung | V1 | Fehlercode |
|
||
|---|---|---|---|---|---|---|---|
|
||
| `R-FHL-SEG-001` | ASVFEH 2/ | `FHL` Segment | M, 1..99 | Fehlersegment wiederholbar, maximal 99 mal | Vorkommen und Obergrenze | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-FHL-2.2-001` | FHL 2.2 | Segment | K | Name des Segments, dem Fehler zugeordnet ist | wenn ermittelbar, zu Muss | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-FHL-2.3-001` | FHL 2.3 | Segmentposition | K | Nummer des fehlerhaften Segments gleicher Art | wenn ermittelbar, zu Muss | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-FHL-2.4-001` | FHL 2.4 | Feldposition | K | Nummer des fehlerhaften Feldes | wenn ermittelbar, zu Muss | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-FHL-2.5-001` | FHL 2.5 | Text | K | Fehlertext aus Schlüsselverzeichnis 8.1 | wenn ermittelbar, zu Muss; Plausibilität mit Code nur teilweise | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-FHL-2.6-001` | FHL 2.6, Schlüsselverzeichnis 8.1 / Fehlercodes | Fehlercode | M | offizieller Fehlercode aus dem Fehlercode-Schlüsselverzeichnis der Technischen Anlage; Sammelcodes (`xx999`, `3A998`, `4A998`) nur nachrangig zu spezifischeren Codes verwenden | Muss vorhanden; Format und Existenz im Fehlercodekatalog | V1-V | `3A004` analog nur für unbekannte Schlüsselwerte; kein eigener FHL-Code definiert |
|
||
| `R-FHL-2.7-001` | FHL 2.7 | Anwendungsreferenz / Dateiname | M | ursprünglicher Dateiname | Typ/Länge; Crosscheck soweit Originalkontext vorliegt | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-FHL-2.8-001` | FHL 2.8 | Ersteller-IK der Originaldatei | M | IK der KV oder des Leistungserbringers | formales IK; Bestandsabgleich nicht belastbar | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-FHL-2.9-001` | FHL 2.9 | Ersteller-IK der Fehlermeldung | M | IK der Krankenkasse | formales IK; Bestandsabgleich nicht belastbar | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-FHL-2.10.1-001` | FHL 2.10.1 | Datum der Erstellung | M | Datum aus Originalnachricht `JJJJMMTT` | Format | V1-V | `10037`/`20021` analog; kein FHL-spezifischer Code |
|
||
| `R-FHL-2.10.2-001` | FHL 2.10.2 | Uhrzeit der Erstellung | M | Uhrzeit aus Originalnachricht `HHMM` | Format | V1-V | `10038` analog; kein FHL-spezifischer Code |
|
||
| `R-FHL-2.11-001` | FHL 2.11 | Nachrichtenreferenznummer | K | aus `UNH 0062` der Originalnachricht; wenn ermittelbar zu liefern | Bedingungsprüfung | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-FHL-2.12-001` | FHL 2.12 | Übertragungsreferenz | K | aus `UNB 0020` der Originalnachricht; wenn ermittelbar zu liefern | Bedingungsprüfung | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-FHL-2.13-001` | FHL 2.13 | Anforderungskennzeichen Korrektur/Storno | M | `1` = Korrektur, `2` = Storno (nur bei Fehlern der Stufe 4 relevant). | lokaler Schlüsselwert | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-FHL-2.14-001` | FHL 2.14 | Rechnungsnummer | K | anzugeben, sofern aus Originalnachricht lesbar | Bedingungsprüfung | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
|
||
## 13. Segment-, nachrichten- und dateiübergreifende Beziehungsregeln
|
||
|
||
## 13.1 Datei- und Transportebene
|
||
|
||
| Regel-ID | Quelle | Regel | V1 | Fehlercode |
|
||
|---|---|---|---|---|
|
||
| `R-CROSS-DATEINAME-001` | Abschnitt 3.5.1, UNB 0020, KKS DATEINAME | Physischer Dateiname, `UNB 0020` und KKS-`DATEINAME` müssen konsistent sein. | V1-V | `10064`, `1A010` oder kein eindeutiger KKS-Code |
|
||
| `R-CROSS-DATEINAME-002` | Abschnitt 3.5.2 | Name der verschlüsselten Datei muss dem Schema `<IK>_<IK>_<E|T>ASV0<ZZZ>` entsprechen. | V1-V | `10064` – Dateiname nicht korrekt |
|
||
| `R-CROSS-DATEINAME-003` | Abschnitt 3.5.3 | Name der Auftragsdatei muss Basisname der verschlüsselten Datei + `.AUF` sein. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-CROSS-DATEINAME-004` | Abschnitt 3.5.4 | Zähler im Dateinamen ist dreistellig `001`–`999`; bei Überlauf Neustart mit `001`. | V1-V | `10047` – Dateinummernfolge nicht korrekt (nur lokale Teilprüfung) |
|
||
| `R-CROSS-DATEINAME-005` | Abschnitt 3.5.4 | Echte lückenlose Folgeprüfung über mehrere Übermittlungen ist ohne Verlauf nicht belastbar. | V1-N | `10047` |
|
||
| `R-CROSS-ECHT-TEST-001` | KKS, UNB 0035, Abschnitt Testverfahren | Test-/Echtkennzeichnung muss zwischen Dateiname, KKS und UNB-Testindikator konsistent sein. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-CROSS-KASSE-001` | Grundsätze Durchführung der Datenübermittlung | Pro Kasse ist genau eine Datei zu erstellen; kassenübergreifende Bündelung in einer Datei ist unzulässig. Die lokale Prüfung erfolgt anhand der im Artefakt vorhandenen Kassenbezüge (insbesondere Abrechnungs-IK). | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
|
||
## 13.2 Nachrichtenebene
|
||
|
||
| Regel-ID | Quelle | Regel | V1 | Fehlercode |
|
||
|---|---|---|---|---|
|
||
| `R-CROSS-UNH-UNT-001` | UNH/UNT | `UNH 0062` und `UNT 0062` müssen je Nachricht identisch sein. | V1-V | `20071` |
|
||
| `R-CROSS-UNZ-UNH-001` | UNZ 0036 | `UNZ 0036` muss der Anzahl der `UNH`/`UNT`-Paare entsprechen. | V1-V | `20070` |
|
||
| `R-CROSS-SORTIERUNG-001` | Hinweis zur Nachrichtenstruktur | Die Sortierung der Nachrichten innerhalb einer Datei ist willkürlich; V1 darf keine Sortierreihenfolge erzwingen. | V1-V | kein offizieller Fehlercode, da kein Verstoß bei beliebiger Reihenfolge |
|
||
| `R-CROSS-ASVFEH-001` | Fehlerverfahren | Eine ASVFEH darf fachlich nicht wie eine reguläre ASVREC validiert werden. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
|
||
## 13.3 Fall- und Inhaltsbeziehungen innerhalb ASVREC
|
||
|
||
| Regel-ID | Quelle | Regel | V1 | Fehlercode |
|
||
|---|---|---|---|---|
|
||
| `R-CROSS-IFA-DGN-001` | DGN/IFA/REA | Bei Rechnung muss mindestens ein DGN vorhanden sein. | V1-V | `3A023` |
|
||
| `R-CROSS-IFA-LEA-001` | LEA/REA | Bei Rechnung muss mindestens ein LEA vorhanden sein. | V1-V | `3A024` |
|
||
| `R-CROSS-LEA-SAC-001` | REA 7.2.1 | Rechnungsbetrag = Summe der LEA- und SAC-Beträge. | V1-V | `3A019` |
|
||
| `R-CROSS-REA-STORNO-001` | REA 7.2.4, Stornoabschnitt | Bei Storno muss Rechnungskennzeichen `1` sein. | V1-V | `3A004` oder kein eindeutiger spezifischer Code |
|
||
| `R-CROSS-REA-STORNO-002` | REA 7.2.1 | Bei Storno muss der Rechnungsbetrag `0,00` sein. | V1-V | `3A027` |
|
||
| `R-CROSS-STORNO-SEG-001` | Struktur Storno | Bei Storno dürfen DGN, LEA, SAC, GEN, OPA nicht vorkommen. | V1-V | `3A025`, `3A026` |
|
||
| `R-CROSS-STORNO-SEG-002` | Verfahren nach Fehlerfeststellung | Storno muss die ursprüngliche Rechnungsnummer als Bezug führen. | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
| `R-CROSS-UEBERWEISUNG-001` | IFA 1.3, DGN 2.2.5 | Überweiserkontext und Diagnoseart müssen fachlich konsistent sein. | V1-V | `3A005`, `3A007`, `3A035` |
|
||
| `R-CROSS-GOA-001` | Hinweise 7/8 | GOÄ-Sonderfall muss gleichzeitig korrekt über 3.2.1 und 3.2.5 abgebildet sein. | V1-V | `3A028` |
|
||
| `R-CROSS-SACHKOSTEN-001` | Hinweis 6 | Sachkosten ohne Sachzusammenhang erfordern Pseudo-GOP `88999` oder regionale Pseudo-GOP mit Anzahl `1` und Preis `0`. | V1-T | `3A016`, `3A017` |
|
||
| `R-CROSS-GEN-001` | Hinweis 7 / Fehlerkatalog | Für bestimmte GOP ist GEN verpflichtend. | V1-V | `3A018` |
|
||
|
||
## 14. Sonderregeln, Ausnahmen und Fallstricke
|
||
|
||
| Regel-ID | Quelle | Sonderregel | V1 | Fehlercode |
|
||
|---|---|---|---|---|
|
||
| `R-SPECIAL-GEBURTSDATUM-001` | Hinweis 4 zu IVA 8.4.3 | Im Ersatzverfahren sind auch `00`, `0000`, `00000000` und sonstige numerische Werte im Format `JJJJMMTT` zulässig; kein logisches Kalenderdatum erforderlich. | V1-V | `3A012` |
|
||
| `R-SPECIAL-PSEUDO-GOP-001` | Hinweis 6 | Pseudo-GOP `88999` bzw. regionale Pseudo-GOP ist in Sachkosten-Sonderfällen zulässig und erforderlich. | V1-T | `3A016`, `3A017` |
|
||
| `R-SPECIAL-GOA-001` | Hinweis 8 | GOÄ-Übermittlung verwendet Pseudo-GOP in `3.2.1` und GOÄ-Ziffer/Begründung in `3.2.5`. | V1-V | `3A028` |
|
||
| `R-SPECIAL-VERTRETUNG-001` | Hinweis 9 | Bei Vertretung ist die Teamebene des Vertretenen anzugeben. | V1-N | `4A007` |
|
||
| `R-SPECIAL-SAC-OBSOLET-001` | Hinweis 12 | `4/4.2.4` und `4/4.2.5` bleiben trotz fachlicher Obsoleszenz füllpflichtig; nicht ausschließlich Leerzeichen. | V1-V | kein eindeutiger offizieller Fehlercode |
|
||
| `R-SPECIAL-NEGATIVE-001` | Erläuterung Datensatzbeschreibungen | Minuszeichen negativer numerischer Werte zählt nicht zur maximalen Feldlänge. | V1-V | `20033` nur bei tatsächlicher Längenverletzung |
|
||
| `R-SPECIAL-DEZIMAL-001` | Erläuterung Datensatzbeschreibungen | Dezimalzeichen `,` zählt nicht zur maximalen Feldlänge. | V1-V | `20033` nur bei tatsächlicher Längenverletzung |
|
||
| `R-SPECIAL-VERTRAGLICH-001` | Hinweis „wird erst geliefert, wenn vertraglich vereinbart“ | Solche Felder sind fachlich existent, aber ohne Vertragskontext in V1 nicht hart zu erzwingen. | V1-T | kein eindeutiger offizieller Fehlercode |
|
||
|
||
## 15. Fachlich existente, aber ohne Referenzbestände nicht belastbar prüfbare Regelbereiche
|
||
|
||
Dieser Abschnitt ist bewusst eigenständig, damit spätere KIs **nicht versehentlich aus fachlicher Existenz eine V1-Pflichtprüfung ableiten**.
|
||
|
||
| Regelbereich | Beispiele | Fachlich existent | V1-Status | Zugehörige Fehlercodes |
|
||
|---|---|---|---|---|
|
||
| **IK-Bestände / Kommunikationspartner** | UNB-Sender/Empfänger, REA 7.2.6–7.2.9, FHL 2.8/2.9 | ja | nur formal / nicht vollständig belastbar | `10041`, `10043`, `3A001` |
|
||
| **ASV-Verzeichnis** | Teamnummern, Teamebene, Berechtigungseintritt | ja | nicht belastbar ohne Referenzbestand | `3A029`, `3A032`, `4A005`, `4A006`, `4A007`, `4A008` |
|
||
| **Arztstammdaten** | BSNR, LANR, externer Überweiser | ja | nicht belastbar ohne Referenzbestand | `3A030`, `3A031`, `3A033`, `3A034` |
|
||
| **ICD-Katalog** | DGN 2.2.1 | ja | nicht belastbar ohne Katalogbestand | `3A006`, `3A021`, `3A022`, `4A010`, `4A011` |
|
||
| **OPS-Katalog** | OPA 6.2.1 / 6.2.2 | ja | nicht belastbar ohne Katalog-/Regelbestand | `3A009`, `3A020` |
|
||
| **Regionale Euro-Gebührenordnung** | LEA 3.2.4 | ja | nicht belastbar ohne regionalen Bestand | `4A001` |
|
||
| **Appendix / Fachgruppenbezug / Kombinatorik** | GOP-Fachgruppen-/Teamebenen- und Nebeneinanderregeln | ja | nicht belastbar ohne Referenzlogik | `4A003`, `4A004`, `4A009` |
|
||
| **Krankenkassen-Fachverfahren** | zusätzliche Fallkonsistenz | ja | nicht Bestandteil belastbarer V1-Dateivalidierung | `4A998` |
|
||
|
||
## 16. Verfahrensorganisatorische Regeln außerhalb direkter Dateivalidierung
|
||
|
||
Diese Regeln sind fachlich Teil der Spezifikation, aber **nicht** als direkte Prüflogik einer isolierten Datei in Version 1 umzusetzen.
|
||
|
||
| Regel-ID | Quelle | Verfahrensregel | V1 |
|
||
|---|---|---|---|
|
||
| `R-PROC-STUFE0-001` | Fehlerverfahren Stufe 0 | Bei physikalisch nicht lesbarer Datei erfolgt unmittelbare Klärung per Telefon/E-Mail. | V1-N |
|
||
| `R-PROC-STUFE0-002` | Stufe 0 Dateinummer | Bei Stufe-0-Fehlern gilt Datei als nicht übermittelt; Dateinummer wird nicht hochgezählt. | V1-N |
|
||
| `R-PROC-STUFE0-003` | Beispiele zur 14-Tages-Frist | Nach Fristüberschreitung können erneut zu liefernde Dateien vom letzten erfolgreichen Anker abhängen. | V1-N |
|
||
| `R-PROC-FEHLER-001` | Fehlerverfahren | Fehlernachricht darf nicht mit Fehlernachricht beantwortet werden; bilaterale Klärung stattdessen. | V1-N |
|
||
| `R-PROC-STORNO-001` | Verfahren nach Fehlerfeststellung | Nach Stufe 2 oder 3 ist Korrektur ohne Storno möglich, nach Stufe 4 Korrektur oder Storno abhängig von Anforderung. | V1-N |
|
||
| `R-PROC-TEST-001` | Testverfahren | Testverfahren und Umfang sind bilateral zu vereinbaren. | V1-N |
|
||
|
||
## 17. Konsolidierter Fehlercode-Katalog
|
||
|
||
## 17.1 Leselogik
|
||
|
||
Der Katalog enthält:
|
||
|
||
- alle für Version 1 fachlich relevanten offiziellen Fehlercodes aus der Spezifikation
|
||
- eine deutsche Klarbeschreibung
|
||
- Prüfstufe
|
||
- V1-Kategorie
|
||
- typische betroffene Felder/Segmente
|
||
|
||
**Wichtige Leseregel für KIs:**
|
||
Die V1-Kategorie im Fehlercode-Katalog beschreibt die **lokal belastbare Auslösbarkeit des offiziellen Fehlercodes in V1**. Ein feldgenauer Regeleintrag kann deshalb `V1-T` sein, obwohl ein zugeordneter offizieller Fehlercode im Katalog `V1-N` ist: Dann ist der Feldkontext lokal teilweise prüfbar, der offizielle Fehlercode selbst setzt jedoch einen externen Referenz- oder Bestandsabgleich voraus.
|
||
|
||
## 17.2 Fehlercodes Stufe 1
|
||
|
||
| Fehlercode | Klarbeschreibung | Prüfstufe | Typische Felder/Segmente | V1 |
|
||
|---|---|---|---|---|
|
||
| `10001` | `UNB` fehlt oder steht an falscher Position | 1 | UNB | V1-V |
|
||
| `10003` | `UNH` fehlt oder steht an falscher Position | 1 | UNH | V1-V |
|
||
| `10004` | `UNT` fehlt | 1 | UNT | V1-V |
|
||
| `10006` | `UNZ` fehlt | 1 | UNZ | V1-V |
|
||
| `10007` | `UNA` ist mehrfach vorhanden | 1 | UNA | V1-V |
|
||
| `10030` | Verwendetes Trennzeichen ist unbekannt oder falsch | 1 | UNA / Parser | V1-V |
|
||
| `10031` | Anzahl der Trennkennzeichen in `UNA` ist fehlerhaft | 1 | UNA | V1-V |
|
||
| `1A008` | Segmentendezeichen fehlt | 1 | UNA / Datei | V1-V |
|
||
| `10037` | Datumselement ist nicht im Format `JJJJMMTT` | 1 | UNB S004_0017, FHL 2.10.1 analog | V1-V |
|
||
| `10038` | Uhrzeitelement ist nicht im Format `HHMM` | 1 | UNB S004_0019, FHL 2.10.2 analog | V1-V |
|
||
| `10040` | Syntaxkennung oder Syntaxversion ist ungültig | 1 | UNB S001 | V1-V |
|
||
| `10041` | Absender-IK der Datei ist nicht als Kommunikationspartner bekannt | 1 | UNB S002_0004 | V1-T |
|
||
| `10043` | Empfänger-IK der Datei ist nicht annehmende Stelle | 1 | UNB S003_0010 | V1-T |
|
||
| `10047` | Dateinummernfolge ist nicht korrekt | 1 | Dateiname / Verlauf | V1-T |
|
||
| `10061` | Nachrichtentyp in `UNH` ist unbekannt | 1 | UNH S009_0065 | V1-V |
|
||
| `10062` | Versionsnummer in `UNH` ist ungültig | 1 | UNH S009_0052 | V1-T |
|
||
| `10063` | Releasenummer in `UNH` ist ungültig | 1 | UNH S009_0054 | V1-T |
|
||
| `10064` | Dateiname entspricht nicht der Spezifikation | 1 | physischer Dateiname / UNB 0020 | V1-V |
|
||
| `1A010` | Übertragungsreferenzen in `UNB` und `UNZ` sind nicht identisch | 1 | UNB 0020 / UNZ 0020 | V1-V |
|
||
| `10099` | Segment nicht bekannt | 1 | Service-/Fremdsegment | V1-V |
|
||
| `1A999` | Übergangsfehlercode für bilateral zu klärenden Stufe-1-Fehler | 1 | diverse | V1-T |
|
||
|
||
## 17.3 Fehlercodes Stufe 2
|
||
|
||
| Fehlercode | Klarbeschreibung | Prüfstufe | Typische Felder/Segmente | V1 |
|
||
|---|---|---|---|---|
|
||
| `20001` | Muss-Datenelement ist unzulässig leer | 2 | diverse Muss-Felder | V1-V |
|
||
| `20002` | Datenfeld ist nicht numerisch, obwohl numerisch definiert | 2 | diverse numerische Felder | V1-V |
|
||
| `20021` | Datumsfeld ist nicht im Format `JJJJMMTT` | 2 | IFA 1.3.4, LEA 3.2.2, OPA 6.2.3, REA 7.2.5 | V1-V |
|
||
| `20033` | Datenfeldlänge ist nicht korrekt | 2 | diverse Felder | V1-V |
|
||
| `2A001` | Unbekannter Schlüsselwert laut TA im `UNH`-Kontext | 2 | UNH S009_0051 | V1-V |
|
||
| `2A008` | Quartalsfeld ist nicht im Format `JJJJQ` | 2 | REA 7.2.2 | V1-V |
|
||
| `2A012` | Segmentreihenfolge ist falsch | 2 | Segmentstruktur | V1-V |
|
||
| `20070` | Anzahl `UNH` in Datei stimmt nicht mit Zähler überein | 2 | UNZ 0036 | V1-V |
|
||
| `20071` | Nachrichtenreferenzen in `UNH` und `UNT` stimmen nicht überein | 2 | UNH/UNT 0062 | V1-V |
|
||
| `2A999` | Übergangsfehlercode für bilateral zu klärenden Stufe-2-Fehler | 2 | diverse | V1-T |
|
||
|
||
## 17.4 Fehlercodes Stufe 3
|
||
|
||
| Fehlercode | Klarbeschreibung | Prüfstufe | Typische Felder/Segmente | V1 |
|
||
|---|---|---|---|---|
|
||
| `3A001` | IK ist unbekannt | 3 | REA 7.2.6–7.2.9 | V1-T |
|
||
| `3A003` | Erkrankungs-/Leistungsbereich ist nicht in Anlage 4 enthalten | 3 | IFA 1.2.4 | V1-T |
|
||
| `3A004` | Schlüsselwert laut TA ist unbekannt oder unzulässig | 3 | IFA 1.2.5, DGN 2.2.2/2.2.3/2.2.5, OPA 6.2.2, REA 7.2.4, IVA 8.2.1/8.2.2, FHL 2.6 | V1-V |
|
||
| `3A005` | Beginn ASV-Behandlung fehlt trotz externer Überweisung | 3 | IFA 1.3.4 zu 1.3.1 | V1-V |
|
||
| `3A006` | ICD-Code ist im gültigen Katalog nicht enthalten | 3 | DGN 2.2.1 | V1-N |
|
||
| `3A007` | Diagnoseart ist in Bezug auf Überweiserkontext falsch | 3 | DGN 2.2.5 / IFA 1.3.1 | V1-V |
|
||
| `3A008` | GOP ist in der ASV nicht abrechnungsfähig | 3 | LEA 3.2.1 | V1-T |
|
||
| `3A009` | OPS-Code ist im gültigen Katalog nicht enthalten | 3 | OPA 6.2.1 | V1-N |
|
||
| `3A010` | Format der Versichertennummer ist falsch | 3 | IVA 8.3.1 | V1-V |
|
||
| `3A011` | Datumsangabe liegt unzulässig in der Zukunft | 3 | 1.3.4, 3.2.2, 6.2.3, 7.2.5 | V1-V |
|
||
| `3A012` | Geburtsdatum entspricht nicht dem zulässigen Sonderformat | 3 | IVA 8.4.3 | V1-V |
|
||
| `3A014` | Erkrankungs-/Leistungsbereich ist in diesem Quartal nicht zulässig | 3 | IFA 1.2.4 | V1-N |
|
||
| `3A016` | Anzahl bei Pseudo-GOP ist fachlich falsch | 3 | LEA 3.2.3 / 3.2.1 | V1-T |
|
||
| `3A017` | Preis bei Pseudo-GOP ist fachlich falsch | 3 | LEA 3.2.4 / 3.2.1 | V1-T |
|
||
| `3A018` | Gennummer fehlt bei bestimmter EBM-Ziffer | 3 | GEN 5.2.1 | V1-V |
|
||
| `3A019` | Rechnungsbetrag entspricht nicht der Summe der Einzelbeträge | 3 | REA 7.2.1 | V1-V |
|
||
| `3A020` | Seitenlokalisation zum OPS-Code fehlt | 3 | OPA 6.2.2 | V1-N |
|
||
| `3A021` | ICD-Code ist bezogen auf das Alter unzulässig | 3 | DGN | V1-N |
|
||
| `3A022` | ICD-Code ist bezogen auf das Geschlecht unzulässig | 3 | DGN | V1-N |
|
||
| `3A023` | DGN fehlt, obwohl Rechnungskennzeichen `0` ist | 3 | DGN / REA 7.2.4 | V1-V |
|
||
| `3A024` | LEA fehlt, obwohl Rechnungskennzeichen `0` ist | 3 | LEA / REA 7.2.4 | V1-V |
|
||
| `3A025` | DGN ist vorhanden, obwohl Rechnungskennzeichen `1` ist | 3 | DGN / REA 7.2.4 | V1-V |
|
||
| `3A026` | LEA ist vorhanden, obwohl Rechnungskennzeichen `1` ist | 3 | LEA / REA 7.2.4 | V1-V |
|
||
| `3A027` | Rechnungsbetrag ist nicht `0,00`, obwohl Storno vorliegt | 3 | REA 7.2.1 / 7.2.4 | V1-V |
|
||
| `3A028` | Bei GOÄ-Pseudoziffern fehlt erforderliche Dokumentation | 3 | LEA 3.2.5 | V1-V |
|
||
| `3A029` | Teamnummer ist nicht im ASV-Verzeichnis enthalten | 3 | IFA 1.2.1 | V1-N |
|
||
| `3A030` | LANR ist nicht im ASV-Verzeichnis oder in Arztstammdaten enthalten | 3 | IFA 1.2.3 | V1-N |
|
||
| `3A031` | BSNR ist nicht im ASV-Verzeichnis oder in Arztstammdaten enthalten | 3 | IFA 1.2.2 | V1-N |
|
||
| `3A032` | Teamnummer des internen Überweisers ist nicht im ASV-Verzeichnis enthalten | 3 | IFA 1.3.2 | V1-N |
|
||
| `3A033` | LANR des Überweisers ist nicht im ASV-Verzeichnis oder in Arztstammdaten enthalten | 3 | IFA 1.3.3 | V1-N |
|
||
| `3A034` | BSNR des externen Überweisers ist nicht in Arztstammdaten enthalten | 3 | IFA 1.3.1 | V1-N |
|
||
| `3A035` | Externer und interner Überweiser dürfen nicht gleichzeitig übermittelt werden | 3 | IFA 1.3.1 / 1.3.2 | V1-V |
|
||
| `3A998` | Sonstiger fachlicher Fehler, bilateral zu klären | 3 | diverse | V1-T |
|
||
|
||
## 17.5 Fehlercodes Stufe 4
|
||
|
||
| Fehlercode | Klarbeschreibung | Prüfstufe | Typische Felder/Segmente | V1 |
|
||
|---|---|---|---|---|
|
||
| `4A001` | GOP-Preis entspricht nicht regionaler Euro-Gebührenordnung | 4 | LEA 3.2.4 | V1-N |
|
||
| `4A002` | Versichertennummer und Ersatzverfahrensangaben sind unbekannt | 4 | IVA 8.3.1 / 8.4 | V1-N |
|
||
| `4A003` | Fachgruppenbezug und abgerechnete GOP passen nicht zusammen | 4 | LEA / Appendix | V1-N |
|
||
| `4A004` | Teamebene und abgerechnete GOP sind nicht plausibel | 4 | IFA / LEA | V1-N |
|
||
| `4A005` | Teamnummer/Berechtigungseintritt und Leistungsdatum sind unplausibel | 4 | IFA / ASV-Verzeichnis | V1-N |
|
||
| `4A006` | Teamnummer und LANR entsprechen nicht dem ASV-Verzeichnis | 4 | IFA | V1-N |
|
||
| `4A007` | Teamnummer, LANR und Teamebene entsprechen nicht dem ASV-Verzeichnis | 4 | IFA | V1-N |
|
||
| `4A008` | Teamnummer/LANR/Berechtigungseintritt und Leistungsdatum sind unplausibel | 4 | IFA / ASV-Verzeichnis | V1-N |
|
||
| `4A009` | GOP sind nicht nebeneinander abrechnungsfähig | 4 | LEA | V1-N |
|
||
| `4A010` | Diagnose darf nur mit Status „gesichert“ angegeben werden | 4 | DGN | V1-N |
|
||
| `4A011` | Seitenlokalisation und Diagnose sind nicht plausibel | 4 | DGN / OPA | V1-N |
|
||
| `4A012` | Sachkosten sind im Bezug zum Fall nicht plausibel | 4 | SAC | V1-N |
|
||
| `4A013` | Inhalt von LEA 3.2.5 ist nicht plausibel | 4 | LEA 3.2.5 | V1-N |
|
||
| `4A998` | Sonstiger fachlicher Fehler, bilateral zu klären | 4 | diverse | V1-N |
|
||
|
||
## 17.6 Übergangs- und Sammelfehlercodes
|
||
|
||
| Fehlercode | Fachliche Regel | V1 |
|
||
|---|---|---|
|
||
| `1A999` | Nur verwenden, wenn kein spezifischerer offizieller Stufe-1-Code existiert. | V1-T |
|
||
| `2A999` | Nur verwenden, wenn kein spezifischerer offizieller Stufe-2-Code existiert. | V1-T |
|
||
| `3A998` | Nur verwenden, wenn kein spezifischerer offizieller Stufe-3-Code existiert. | V1-T |
|
||
| `4A998` | Nur verwenden, wenn kein spezifischerer offizieller Stufe-4-Code existiert. | V1-N |
|
||
|
||
**Normative Vorrangregel:**
|
||
Die Sammelcodes dürfen **nicht** verwendet werden, wenn für den konkreten Sachverhalt ein spezifischer offizieller Fehlercode existiert.
|
||
|
||
## 18. Fachliche Mindestanforderungen an spätere Arbeitspaketbildung
|
||
|
||
Dieses Dokument selbst enthält **keine technische Priorisierung**. Für spätere Meilensteine und Arbeitspakete ist jedoch normativ vorauszusetzen:
|
||
|
||
1. Der feldgenaue Regelkatalog ist die maßgebliche Quelle für fachliche Umsetzungsanforderungen.
|
||
2. Strukturmatrizen und Beziehungsregeln sind **gleichrangig** mit Feldregeln.
|
||
3. Sonderregeln und Ausnahmen sind **nicht optional**, sondern verbindlicher Teil der Fachlichkeit.
|
||
4. Bereiche mit Kategorie `V1-N` dürfen **nicht fälschlich als harte V1-Validierungslogik** umgesetzt werden.
|
||
5. Offizielle Fehlercodes sind zu bevorzugen; Sammelcodes nur nachrangig.
|
||
6. Fehlende eindeutige Fehlercodes entbinden **nicht** von fachlicher Regelmodellierung.
|
||
|
||
## 18.1 Konsistenz mit dem technischen Soll-Rahmen
|
||
|
||
Die fachlichen Anforderungen dieses Dokuments und der technische Soll-Rahmen `technik-und-architektur.md` v5 sind aufeinander abgestimmt:
|
||
|
||
- Beide Dokumente beziehen sich auf dieselbe Zielversion **Technische Anlage ASV 1.09, Stand 09.10.2025**.
|
||
- Beide Dokumente trennen **Spec-konformes Prüfurteil** von **diagnostischer Weiteranalyse**; das Spec-Urteil darf durch Diagnose niemals in ein erfolgreiches Urteil umgedeutet werden.
|
||
- Beide Dokumente kennzeichnen denselben Bereich von Stufe-3-Schlüsselverzeichnisabgleichen (IK/ICD/OPS/BSNR/LANR/Teamnummer) als nicht belastbar prüfbar in V1.
|
||
- Beide Dokumente behandeln `VERFAHREN_KENNUNG_SPEZIFIKATION` als Kann-Feld.
|
||
- Beide Dokumente fordern den Crosscheck `TRANSFER_NUMMER` ↔ Zähler im Dateinamen, `physischer Dateiname` ↔ `UNB 0020` ↔ KKS-`DATEINAME`, `UNB 0020` ↔ `UNZ 0020`, `UNZ 0036` ↔ Anzahl `UNH/UNT`-Paare und `UNH 0062` ↔ `UNT 0062`.
|
||
- Beide Dokumente fordern den Bytegrößen-Crosscheck der KKS-Felder `DATEIGRÖSSE_NUTZDATEN` und `DATEIGRÖSSE_ÜBERTRAGUNG`.
|
||
- Beide Dokumente verlangen ISO 8859-15 als Eingabezeichensatz und schließen stillschweigende UTF-8-Dekodierung aus.
|
||
- Beide Dokumente behandeln Geburtsdatum-Sonderwerte, Pseudo-GOP `88999`, GOÄ-Sonderfall, Vertretungs-Teamebene `4`, obsolete Felder `4/4.2.4`/`4/4.2.5` (mit „nicht ausschließlich Leerzeichen"), negative numerische Werte und Dezimalzeichen identisch.
|
||
- Beide Dokumente behandeln die Verfahrensregel „Fehlernachricht darf nicht mit Fehlernachricht beantwortet werden" als nicht-V1-prüfbar.
|
||
- Echte konventionsbasierte Annahmen werden nur dort als `V1-K` markiert, wo die Spezifikation den genauen Wertebereich oder die konkrete technische Abgrenzung nicht selbst festlegt. Dies betrifft in v3 nur noch die Hilfskonvention zur GOÄ-Pseudoziffern-Range `885xx` in `R-LEA-3.2.5-002`; bei einem Spec-Konflikt wäre diese Annahme nachrangig.
|
||
|
||
## 18.2 Dokumenthistorie
|
||
|
||
| Version | Wesentliche Änderungen |
|
||
|---|---|
|
||
| v1 | Erstfassung mit feldgenauem Regelkatalog für KKS, Service-Segmente, ASVREC, ASVFEH und Storno; Fehlercode-Konsolidierung; V1-Kategorien V/T/N |
|
||
| v2 | Neue V1-Kategorie `V1-K` für konventionsbasierte Regeln; neuer Abschnitt 5.1 „Globale fachliche Rahmenregeln" mit ISO 8859-15 als artefaktübergreifender Pflicht; `R-KKS-TRANSFER-NUMMER-001` als fehlende Muss-Feldregel des KKS ergänzt; Tippfehler `ssmmss` → `hhmmss` in `R-KKS-DATUM-ERSTELLUNG-001`; Kennzeichnung mehrerer Regeln als konventionsbasiert; Versichertennummer-Format an Spec-Wortlaut angeglichen („Zählnummer, in der Praxis numerisch"); FHL 2.6 Spec-Referenz überarbeitet; DGN 2.2.1 Bedingungsformulierung präzisiert; Konsistenzabschnitt zu `technik-und-architektur.md` v5 |
|
||
| v3 | Rückführung fälschlich als `V1-K` markierter, tatsächlich direkt spec-gedeckter Regeln (`SV`, Diagnosesicherheiten `A/G/V/Z`, Versichertenart `1/3/5`, Personengruppe `00/04/06/07/08/09`, FHL-Anforderungskennzeichen `1/2`); Storno-Rechnungsbetrag `0,00` überall wieder als direkte Spec-Regel geführt; `R-CROSS-KASSE-001` mit globaler Regel harmonisiert; Fehlercode-Leseregel in §17.1 ergänzt; referenzbestandsabhängige Codes `3A029`–`3A034` in den Feldregeln als fachlich einschlägig, aber lokal in V1 nicht belastbar auslösbar präzisiert; §18.1 und Dokumenthistorie bereinigt. |
|
||
| v4 | Reine Mikro-Korrektur: Tabellenbruch in der Dokumenthistorie (§18.2) durch versehentliche Leerzeile zwischen den Versionsreihen v2 und v3 behoben. Keine inhaltlichen Änderungen, keine neuen Regeln, keine Umklassifizierungen. |
|
||
|
||
## 19. Zusammenfassung
|
||
|
||
Version 1 des ASV-Format-Validators hat fachlich folgende verbindliche Aufgabe:
|
||
|
||
- lokale ASV-Artefakte gegen die Technische Anlage ASV 1.09 zu prüfen,
|
||
- dabei `AUF/KKS`, Service-Segmente, `ASVREC`, `ASVFEH` und Storno fachlich sauber zu unterscheiden,
|
||
- Regeln feldgenau, strukturgenau und beziehungsgenau anzuwenden,
|
||
- Sonderfälle und Ausnahmen ausdrücklich zu berücksichtigen,
|
||
- referenzbestandsabhängige Regeln sauber von belastbar lokalen Regeln abzugrenzen,
|
||
- und das Ergebnis so präzise aufzubereiten, dass daraus nachgelagert **Meilensteine**, **Arbeitspakete** und **Implementierung** ohne erneute fachliche Grundsatzklärung abgeleitet werden können.
|